Good morning, Yesterday I got a new ISP. I have a new email address and I changed my email address in the Fedora Account System. I just checked it this morning and the new address is still there. However this morning the meeting announcements and test reports came to my old email address. Fortunately I haven't discontinued that ISP with it's associated email address yet. What else do I need to change for the QA related email to come to me new email address? Have a Great Day! tablepc Pat ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: new criterion proposal: Window manager functionality
On 3/22/23 03:57, Kamil Paral wrote: Here's a second draft. I took feedback here and also from the QA meeting [1]. The split between the milestones makes this harder to read and compare. If you have better ideas on how to do it, please tell me :-) The only suggestion I have is for the foot notes under Final. Combine the second note into the first. Perhaps something like: What does this cover?: The goal of this criterion is to ensure general desktop-related functionality for different types of applications. A small number of on-working applications (caused by applications themselves or the desktop environment) is not a violation of this criterion. An example of a violation would be if a significant number of QT applications couldn't be resized (but they should be), or if all Java applications failed to display any content. This criteria applies to all applications (including third-party ones), not just preinstalled ones. More window operations are required to work, For example the explicitly stated virtual workspaces workflows. Otherwise this looks fine. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Possible new test day
This morning when I saw the call for test days e'mail I had an idea that I want to get some feedback on before I propose it as a test day. I manage multiple systems and for each new release of Fedora Workstation, I do installs (clean storage) rather that updates. This gets rid of the trash in the system space and users get a chance to clean the trash out of their home directory before it's copied to their new home directory. The automation (script) I use for configuring these systems after the base Anaconda install not only installs and removes software packages, but also does setting of desktop preferences, service settings, and user setting such as groups. I start using the script with what I call As Deployed Testing which typically starts a little before branching of the new version. This happens for pre-release drops as testing is called for or for other drops as something peaks my interest. Good things can be discovered about the readiness of the new release for deployment with this as deployed configuration. For instance: Unreported bugs can sometimes show up. Besides reporting the bug I can understand the impact of the bug and plan for a workaround or other measure given that the bug may not be a priority. An application may be retired or have a new version that is delayed. Such situations can lead to the deployment being delayed or working with users to decide if we might need to be tolerant of a bug or picking a new application. A Gnome setting (gsettings) may work differently or no longer be available. Their may be new settings available I would guess that most folks that deploy new Fedora Workstation releases for a group of users do something similar. So why then have a test day for this? I see the following benefits: On the test day results pages each tester can report the number of users they support and list by number any new bugs or issues they found that were seen after their as deployed configuration, but not with with the base anaconda installed configuration. This provides an indication of the impact of the bugzilla bugs and Gnome issues that were found. They can be encouraged to post on Fedora Discussion about any new or different gsettings or service configurations they found. This will raise visibility of new, changed, and removed settings. They can tell about replacement application(s) they are using in place of ones that are retired or otherwise not available. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Thoughts welcome: interface between automated test gating and the "critical path"
On 10/17/22 8:45 PM, Adam Williamson wrote: On Fri, 2022-09-02 at 10:26 -0700, Adam Williamson wrote: If we don't think it's worth doing that work, then we're kinda stuck with openQA glomming onto the critpath definition to decide which updates to test and gate, because I don't have any other current viable choices for that, really. And we'd have to figure out a critpath definition that's as viable as possible for both purposes. BTW, one other thought I've had in relation to all this is that we could enhance the current critpath definition somewhat. Right now, it's built out of package groups in comps which are kinda topic-separated: there's a critpath-kde, a critpath-gnome, a critpath-server, and so on. But the generated critical path package list is a monolith: it doesn't distinguish between a package that's on the GNOME critpath and a package that's on the KDE critpath, you just get a big list of all critpath packages. It might be nice if we actually did distinguish between those - the critpath definition could keep track of which critpath topic(s) a package is included in, and Bodhi could display that information in the web UI and provide it via the API. That way manual testers could get a bit more info on why a package is critpath and what areas to test, and openQA could potentially target its test runs to conserve resources a bit, though this might require a bit more coding work on the gating stuff now I think about it. That sounds useful. We only need a volunteer to figure out the details and do the work ;) I actually did a huge rewrite of the thing that generates the critpath data this week, and it probably wouldn't be to much work, honestly. The most annoying bit would be the Bodhi frontend stuff, but that's because I'm bad at frontend dev in general. :P But yeah, this is definitely off in sky-castle land. I'll add it to my ever-growing list of sky-castle projects to do when I get a couple of years of spare time... So, an update on this whole area! First off, I'm actually finding the time to do the sky-castle work. The releng critpath script now outputs critpath data by group: https://pagure.io/releng/c/621caa542acc142d57f1247e7644846f737f8eee?branch=main Bodhi (git HEAD Bodhi, anyway) can now read data in that format: https://github.com/fedora-infra/bodhi/pull/4755 and when this PR is merged, it will be able to mark updates as critpath by groups: https://github.com/fedora-infra/bodhi/pull/4759 This has the handy bonus effect of enabling us to remove one of our remaining uses of PDC. Once the Bodhi work is merged, I can send a PR for the releng ansible repo to define per-group greenwave policies, run the critpath.py script nightly on the Bodhi boxes, and switch to the 'json' critpath type in Bodhi config, and finally I can then enhance the openQA scheduler to only run the necessary tests for each update. Second, since nobody really opposed the idea of extending the critpath definition slightly, here's a formal proposal to implement that. I want to edit the wiki critpath page: https://fedoraproject.org/wiki/Critical_path_package and change it as follows: 1. Under Background, change "The packages required to sustain these actions make up the critical path." to: "The packages required to sustain these actions initially made up the critical path. Later, it was agreed that the maintainers of Editions, spins, and labs can also declare packages that provide other key functionality to be part of the ''critical path'' for that Edition, spin or lab." 2. Under Actions, change the first two sentences to read: "Packages required to perform the most fundamental actions on a system are always considered part of the ''critical path''. Those actions include: " Does anyone object to these proposed changes? Thanks! I think this is a great improvement over what we had. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Video issue
This is something I first saw at first branch and I have continued monitoring it since. There has been no change. The problem is that MP4, and AVI videos will not play on Totem. This is probably not a blocker based on the current criteria. I doubt that a bug report is even a proper thing to do. However this seems likely to cause some discontent and commentary. My current clean install is from Fedora-WS-Live-37-20221013-n-0. It is fully updated. I have also loaded the Free video codecs from RPMFusion.org. In Software --> Codecs when I try to install the the gstreamer-libav Software says it's not available. So it can't be installed. I've looked for it on RPMFusion.org with no luck. I found gstreamer1-plugin-libav in the fedora repo then installed in and did a reboot. This solved the problem. MP4, and AVI videos now play in totem. Software --> Codecs still says that gstreamer-libav is not available. I think this either needs to be installed by default and remove it from Software --> Codecs or put it back in RPMFusion.org where it can be installed the way users are used to. For now I'll just add it to my install script. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Extensions information
Good morning everyone, I know Gnome Shell Extension issues are not considered bugs. This is just information. Earlier when the discussion was going on about not being able to install extensions I sent an e'mail to this list that mentioned this and said I would check it out more when Gnome had a version number. Now that Gnome is 43.0 I went ahead with my checks. Three of the extensions used here are Freon, NetSpeed, and System Monitor. To this point these would not run reporting an error of not being compatible with the current Gnome version. Today I patched that and verified the patches as follows: sudo sed -i 's/40.0/43.0/g' /usr/share/gnome-shell/extensions/freon@UshakovVasilii_Github.yahoo.com/metadata.json sudo sed -i 's/42/43.0/g' /usr/share/gnome-shell/extensions/netsp...@hedayaty.gmail.com/metadata.json sudo sed -i 's/42/43.0/g' /usr/share/gnome-shell/extensions/system-moni...@paradoxxx.zero.gmail.com/metadata.json cat /usr/share/gnome-shell/extensions/freon@UshakovVasilii_Github.yahoo.com/metadata.json cat /usr/share/gnome-shell/extensions/netsp...@hedayaty.gmail.com/metadata.json cat /usr/share/gnome-shell/extensions/system-moni...@paradoxxx.zero.gmail.com/metadata.json Now Freon and Net Speed seem to be working fine. If someone could update the Gnome version in their metadata.jason files in the RPM they should be fine as installed. Should these be reported as Gnome issues? System Monitor now shows a different error "StatusArea aggregateMenu is undefined". Is this a Gnome Issue or do extension issues get reported at another location? Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Release criteria proposal: require GNOME Shell extension install/remove to work
On 9/12/22 3:35 PM, Adam Williamson wrote: We have a handful of extensions packaged, though I'm not sure how well they're kept up to date. Aside from those, I don't know of any other really practical way for regular users to install extensions besides https://extensions.gnome.org . Is there one? My uers and I need Gnome extensions. The ones used here are in the Fedora 37 repo, that's where I get them, but there are some that won't run. The Extensions app. says they are not compatable with the current version of Gnome. I've looked into this for the Extension Freon. Freon actually queries the Gnome verion and compares it to the version in a file that comes with the extensiion. I've been able to fix the issue for F36 with: sudo sed -i 's/40.0/42.2/g' /usr/share/gnome-shell/extensions/freon@UshakovVasilii_Github.yahoo.com/metadata.json I've been waiting to see what the Gnome version in F37 will be. This may be the problem with the others that won't run, but I haven't had a chance to look into that yet. I think the intension of this is to ensure that someone has tested the extension to be sure it works then they put the current Gnome version in the file to enable it to work. Of course this little patch bypasses that assurance. Have a Great Day! Pat tablepc Assuming for now that there isn't, I'm gonna propose this as a Final release criterion to see how people feel about it, to come after "Default panel functionality": # === GNOME extensions === On Fedora Workstation, it must be possible to install and remove extensions by visiting https://extensions.gnome.org in the default web browser, after installing the required browser extension. # Do folks think this is important enough to block Final release on? Desktop folks, do you consider it "supportable"? Thanks! ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Thoughts welcome: interface between automated test gating and the "critical path"
On 8/29/22 6:50 PM, Adam Williamson wrote: Hi folks! I have one of those definitional quandaries and I figured I'd throw it at the lists for some input. I spent some years as a project manager and I have lots of experience with schedules. The term Crital Path was formalized in the business world when project managers learned to use Gantt Charts for their scheduling. The Critical Path was fluid and changed as various task dependancies were actually or potentially impacting the project completion date. The tasks and resources on the critical path got special attention to mitigate the delay. This usually led to changes in the critical path or new a critical path would come up. Redefining the term is is not a clean solution ot this problem. First, I think the terminology needs to change. I propose having a critical package list. The critical package list would be defined as something along the lines: "These packages should be working in Fedora as released as Beta or Final. Failing packages must have blocker bugs and/or freeze exceptions." Notice the should gives room for making exceptions as packages fail near release time. After that all critical packages should be tested and evaluated with openQA and Gating. To adopt this approach their two tasks: First decide what packages are on the Critical Package List. The reasons will be many and I don't see a need to document the reasons. A small group of people can make up the list and put it before the comunity for agreement. Second change the testing and gatiing so they work from the list Have Great Day! Pat tablepc ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Testing FWS F37 branched 20220816.n.0
Good day everyone, Testing FWS F37 branched 20220816.n.0. This was a bare metal install on a Lenovo M53 with a i5-4570 CPU. The ISO was check summed and passed then loaded to a thumb drive using Media Writer. The test machine booted to Live normally when the (start F37 live) was selected in Grub. Anaconda started normally. Options to delete all and reclaim space were selected for the hard drive. Install ran normally. The reboot to the hard drive was normal. Part two of the install was normal. When the (test media then start F37) was selected in Grub the media test would not run due to lack of files "[ 5.973632] dracut-pre-udev[501]: sh: line 1: /sbin/sysctl: No such file or directory The media check is complete, the result is: NA. No checksum information available, unable to verify media". this has been the case since I started testing F37 branched. I did not file a bug report since I think this is probably already receiving lots of attention. From my results F37 seems in rather good condition at this stage. I'm particularly please by the fact that my HL-L6200DW printer installs during the Fedora install process and the only thing I have to do is set double sided printing. It even works with Firefox. The only unique problems (don't already have a bug report) I found had to do with things that aren't in the repository yet so I can't install them. These were codecs and OBS-Studio. The packages for F37 seem to be available, but aren't in the F37 repo yet. Not a problem at this stage. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Test request: Gnome Text Editor infinite loop (RHBZ 2071228)
On 4/26/22 09:52, Ben Cotton wrote: Hi folks, I saw RHBZ 2071228 [1] proposed as a freeze exception, but it looks blockery to me. The report specifically mentions the fa_IR locale. It would be very helpful for the purposes of blocker decision to know if the problem is specific to that locale or if others are affected. I've tried to reproduce it using the steps in the bug, but I haven't been able to. That could be entirely a Me Problem™ though. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2071228 A bit more data I didn't set fa_IR but using my usual US English settings I opened a file made some edits and click the x in the windpr cprner to close gedit without saving and it came up with the warning asking me if I wanted to save first. I clicked discard and it closed normally. When I reopened the file the edits were not present as I would expect. Have a Great Day! tablepc Pat ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal: revise "Default application functionality" final criterion to be clearer
On 1/20/22 19:08, Adam Williamson wrote: Hi folks! So I've had this action item at meetings forever now: "adamw to try and clarify intent of "default application functionality" criterion regarding arches" For all release-blocking desktop / arch combinations, the following applications must start successfully and withstand a basic functionality test: * web browser * file manager * package manager * image viewer * document viewer * text editor * archive manager * terminal emulator * problem reporter * help viewer * system settings If there are multiple applications of the same type (e.g. several web browsers), the primary/default one must satisfy the requirements. If the primary/default application can't be determined, at least one of said applications must satisfy the requirements. Additionally, for Fedora Workstation on the x86_64 architecture, '''all''' applications installed by default must meet this requirement. === Thoughts? Is this an improvement? Anyone have a better idea? Thanks! I like it! It's straight forward, understandable, and brief. There will be lots of different opinions on what a "basic functionality test" is so they'll get tested lots of ways and that's a good thing. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
In regard to testing Fedora 36 Rawhide 20220114.n.0
Testing for Fedora 36 Rawhide 20220114.n.0 has started out a bit rough. I booted the install media and the check passed, but while it was booting the live I got the "Oh no!" sad face. I just waited for a while then clicked the "Log Out" and after a bit the Anaconda started as a very small window in the upper left corner of the sad face screen. Anaconda is currently running the install so I'll see what else interesting happens. Is this known or should I file a bug? Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 retrospective follow-up: proposed actions
On 11/26/21 19:04, Adam Williamson wrote: 3. "Ahmedalmeleh - Bugzilla is challenging to me and still getting used to it. I wish I was able to learn how to operate OpenQA's automated tests, in the given timeframe and was given guidance sooner.", also Ahmed's 'wishlist' item and Matt's item - I'll plan to file a ticket for improved guidance on using Bugzilla, and ask Ahmed for specific input on what might help. I wonder if it might be a good idea to drag ourselves into the 21st century and record some videos covering common QA activities too, that might be something some folks would appreciate more than text instructions? For openQA, I'll ask Ahmed for more detail on specifically what he'd like to do with it here, as "operating" the tests isn't something we envisage most contributors typically needing to do. From the "helper's" point of view I find videos to be very good. I use OBS-Studio. When I have "how do you" questions from a user, I use OBS-Studio to record the screen and my voice as a short video while I do a "show and tell" of how to do whatever it is they want to do. The added benefits are that I rarely get followup questions and I can answer any repeat or duplicate questions very quickly. How does this sound to everyone? Please add any suggestions you have! And there's still time to add new items to the retrospective itself, if any new ones show up, I'll update this list of proposed actions. To begin with this will be a bit off topic. I've spent most of my free time in the last year learning about servers. The application is "home servers" Most of the folks I know have multiple devices they use but they don't have storage to hold all the documents, code snips, images, etc. they may want to access from a given device at a given time. A home server is a good answer The folks on Ask Fedora were very helpful. I summarized the initial results in this post: https://discussion.fedoraproject.org/t/fun-home-project/34347 The hurtles for setting up a home server are daunting for the uninitiated. I estimate that I spent around 200 hours in the last year looking for doc's, asking questions, understanding the answers, trying things, etc. I expect that this is due to the expectation that servers are for businesses that hire people with specific skills and training to setup and manage servers. I'm hoping, that when it's done, the information presented in my follow up posts will lower the time investment and pre-answer many of the questions involved with such an effort. Getting more people familiar with more ways to use fedora and provide them with a trail of bread crumbs to follow seems like a good thing to me. We probably have more opportunities to lower the hurtles for people to use various Fedora offerings. Have a Great Day! tablepc Pat ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Blocker on Cockpit Machines
In regard to the blocker I proposed on Cockpit Machines: https://bugzilla.redhat.com/show_bug.cgi?id=2007775 Martin Pit has added a note to the bug: "This was fixed upstream a few days ago. It will be part of Wednesday's c-machines 253 release." https://github.com/cockpit-project/cockpit-machines/pull/387 I suggest we punt this one until next time; so the new version can be tested. I won't be able to attend the blocker meeting today. Have a Great Day! Pat(tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Test-Announce] 2021-09-27 @ 16:00 UTC - Fedora 35 Blocker Review Meeting
On 9/24/21 20:30, Adam Williamson wrote: # F35 Blocker Review meeting # Date: 2021-09-27 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.libera.chat In regard to the blocker I proposed on Cockpit Machines: https://bugzilla.redhat.com/show_bug.cgi?id=2007775 Martin Pit has added a note to the bug: "This was fixed upstream a few days ago. It will be part of Wednesday's c-machines 253 release." https://github.com/cockpit-project/cockpit-machines/pull/387 I suggest we punt this one until next time; so the new version can be tested. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Basic criterion proposal: g-i-s shouldn't take 2 minutes to launch
On 9/17/21 07:29, Lukas Ruzicka wrote: What if we replaced the "10 seconds" with something like "reasonably fast". With different machines people could have different expectations, so somebody could consider 10 seconds a long time, while others could take 20 for normal. This could make more room for usual experience and expectations. On Fri, Sep 17, 2021 at 1:13 PM Ben Cotton wrote: Providing for the varied experience and expectations also provides room for more bug reports. Some of those reports will likely be for times we either can't or won't fix. Personally I like having a number. I start noticing a restart taking longer than expected when there are no signs of progress and around 10 seconds have passed. I start thinking "this is taking too long at around 20 seconds, and by 30 seconds I start thinking this needs a bug report. Have a Great Day! Pat (tablepc) On Fri, Sep 17, 2021 at 3:35 AM Kamil Paral wrote: But I also missed his announcement, and when this discussion was renewed, I thought the criterion still wasn't finalized and in effect. It seems I wasn't the only one :o) I also forgot that I had done it when the discussion picked back up. But yeah, I'm definitely flexible on the timing. I think the reason we went with a number was to avoid getting bogged down in what "reasonable" meant. But the existing criterion has its own ambiguity, so if we can make it better*, we should. * But what does "better" mean?! :-D -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora-Server-dvd-x86_64-35-20210908.n.0 issue
On 9/9/21 20:14, Adam Williamson wrote: On Thu, 2021-09-09 at 15:19 -0400, pmkel...@frontier.com wrote: In regard to: Fedora-Server-dvd-x86_64-35-20210908.n.0 Today I thought I would see if the old issue with wireless networking not being available in Fedora Linux Server is making progress toward being resolved. This was a bare metal install on a Lenovo M53 with a i5-4570 CPU. The ISO was check summed and loaded to a thumb drive using Media Writer. The test machine booted, ran the media check and started Anaconda normally. There was no wired connection to the system, but the system has wireless capability. The network link on the main Annaconda page showed that there was no network connection. I did open the Network page in the installer. The only thing it showed was the eno1 port. There didn't seem to be a way to add the wireless. It showed adding Bridge, Team, etc. I couldn't get the wireless connected. I tried Configuration and couldn't see a way to connect the wireless there. After Server was installed and rebooted, I logged in and tried "sudo dnf upgrade --refresh" and got the errors about it couldn't get the mirrors. This, for me, demonstrated that the wireless was not working. Then I connected the PC to a wired internet connection. Well, the server can't access the wired connection now; so I guess that has to be set up manually now. After I got the wired network running I ran the updates (wanted to save time). I just wanted to see if we are getting closer to wireless working on Server. After the updates and reboot the wireless was available and worked. I checked and both NetworkManager-wifi and wpa_supplicant were installed My theory is that the wpa_supplicant was loaded during the updates. The old bug said that for F34 Server the NetworkManager-wifi was installed, but wpa_supplicant was not. The plan was to make sure it all worked in F35 Server. I'm hoping that by Beta for Server that the installer will connect to wireless when that is all that is available so it will work with server after the install and reboot are done; just like it does with wired. Is that likely or am I having a peasent dream? I'm having trouble parsing your email, but as far as I can tell, it reads like at no point did you actually try to connect to a wireless network in the installer. But then your conclusion is that it doesn't work. I'm a bit confused? Sorry! Sorry, I had some distractions while writing this. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Server-dvd-x86_64-35-20210908.n.0 issue
In regard to: Fedora-Server-dvd-x86_64-35-20210908.n.0 Today I thought I would see if the old issue with wireless networking not being available in Fedora Linux Server is making progress toward being resolved. This was a bare metal install on a Lenovo M53 with a i5-4570 CPU. The ISO was check summed and loaded to a thumb drive using Media Writer. The test machine booted, ran the media check and started Anaconda normally. There was no wired connection to the system, but the system has wireless capability. After Server was installed and rebooted, I loged in and tried "sudo dnf upgrade --refresh" and got the errors about it couldn't get the mirrors. Then I connected the PC to a wired internet connection. Well, the server can't access the wired connection now; so I guess that has to be set up manually now. After I got the wired network running I ran the updates (wanted to save time). I just wanted to see if we are getting closer to wireless working on Server. After the updates and reboot the wireless was available and worked. I checked and both NetworkManager-wifi and wpa_supplicant were installed I'm hoping that by Beta for Server that the installer will connect to wireless when that is all that is available so it will work with server after the install and reboot are done; just like it does with wired. Is that likely or am I having a peasent dream? Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Testing Fedora 35 Branched 20210831.n.1
With F34 Workstation, I've been using a VM I set up with Cockpit to run F34 Server. Here are then packages I install and settings I did to do this. sudo dnf install cockpit sudo dnf install cockpit-machines sudo dnf install virt-viewer sudo systemctl enable --now cockpit.socket sudo firewall-cmd --add-service=cockpit --permanent sudo firewall-cmd --reload I download the F34 Server ISO and put it in /var/lib/libvirt/ I set up a bridge and then I setup a VM with F34 server. Everything works fine. Today I decided to try this with F35 Workstation. I did everything that same way as with F34, but when I started to set up a VM I got "Virtualization service (libvirt) is not active" as soon as I clicked on the "VirtualMachines" in cockpit. I tried starting it with the button in the Cockpit VM screen, but it would not start. I looked and saw that libvirtd was not installed so I installed it. at lot of other virt items got installed with it. I tried the cockpit button again and it failed to start, I tried starting libvirtd.service with systemctl and that did not work. When I click the "troubleshoot" link on the Cockpit VM screen, it shows that there apparently several virt related items not running. Is this a bug or do I need to install more/different things to geting this to work? Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Basic criterion proposal: g-i-s shouldn't take 2 minutes to launch
My guess is that we start counting when the wall paper is up and the top bar is displayed. Have a Great Day! Pat (tablepc) On 8/25/21 06:43, Kamil Paral wrote: On Wed, Aug 25, 2021 at 12:00 AM Adam Williamson wrote: On Sun, 2021-03-14 at 11:13 -0400, Ben Cotton wrote: In the wake of the BZ 1924808[1] discussion in Thursday's Go/No-Go meeting[2], I am proposing an addition to the Basic Release Criteria[3]. This would go into Post-Install Requirements -> Expected installed system boot behavior -> First boot utilities (appended after the existing sentence): If a utility for creating user accounts and other configuration is configured to launch, it must be visible within 10 seconds of the first boot reaching the launch point. I'm not exactly clear on what "the launch point" is, i.e. when I should start counting. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
packages are in bad shape issue 131
I've just read through: #131 Red Hat Bugzilla: GNOME packages are in bad shape. https://pagure.io/fedora-workstation/issue/131 I always like to know the background of people who are talking to me so here's a little, appropriate to this topic, background on me. I'm one of those who help out with testing. My involvement with RHBZ bugs is filing them and providing information to help with trouble shooting. I've been an engineer working on hardware design and software for my whole career. I'm very familiar with the processing of bug and reports with other titles that basically said either I or someone else had a problem to solve. I fully understand many bugs are never resolved and the reasons why. I've attended and led many meetings where bugs were discussed, prioritized, etc. That was hard enough to manage, in the context of a company where everyone was an employee working on a single project, but as I consider the number of teams of people and individuals who are involved with the software in Fedora Linux I am greatly impressed that the bug systems involved work as good as they do. I agree though, that improvements can be made. One advantage that the company environments have is that when a bug is not going to be worked on, everyone knows it and why. In RHBZ or GitLab Issues bugs just hang around. Perhaps this could be improved by requiring all bugs to be triaged at least to the extent where it can be determined if it will be worked on and if not give a reason such as "no bandwith for this release please reassign to Rawhide", "Please file upstream". This initial triage could probably be best done by the person that a bug is initially assigned to. I understand that their are likely hundreds of new bugs filed each release cycle. If other fedora folks could be invested with the general reasons why bugs don't get worked on they could help with this initial triage and avoid filing such bugs. One thing I've learned is not to file bugs on applications that are not installed by Anaconda in RHBZ. Even for those installed by Anaconda it seems best to only file bugs on "system" items rather that those that are "general user". These might be triage points. Another suggestion is that at the beginning of a cycle someone could check the groups to see what sort of bugs they will or won't have bandwidth for. This sort of approach might be more achievable than trying to get the report systems to work together. I suspect that a major problem for the bug / issue database clutter is lack of person hours. So quick, but intelligent sort outs may help. Even an automated system could check for "Is this bug against something Anaconda installed?" Yes, I agree, closing bugs for such reasons might be harmful to moral of those filing bugs. However, having their bugs just hang around with no apparent action isn't good for moral. At least the early sort out keeps the database cleaner so developers don't need to have so many sorts on their view of RHBZ, let folks know status, and maybe some bugs get fixed that wouldn't have been seen due to view sorts in RHBZ. I have tried filing bugs in both directions (RHBZ and GitLab Issues) with mixed results. I have one I have been watching for a while now (over a year). I filed the bug with RHBZ and I have considered filing a report with upstream with Firewalld. I'm not a member of any of their teams so I doubt I could even file a report. My experience with trying to file reports with other upstream teams has not been good; so I've been ambivalent about trying it with the Firewalld team. I have from time to time, when I have bugs that have been hanging around for two or more revisions, just closed them. I don't like cluttering up databases with reports that are of no value to the team. I have been able to find other ways to accomplish what I need to do; so I can live without software that has the unresolved bug. Please let me know if there are things I can do to help. Also, please let me know if this kind of input is useful. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Wayland apparently not compatible with new UHD Graphics CPUs
On 3/17/21 21:03, Adam Williamson wrote: On Wed, 2021-03-17 at 15:59 -0400, pmkel...@frontier.com wrote: I know I'm the one who always runs the old PCs, but I recently decided I should have one new one in the mix. The one I got has an ASUS Z590-A motherboard and an Intel i5-10400 processor. Well Fedora won't run a Wayland session on it. It will only run a Gnome-xorg session. I even had to run the install from Basic Graphics mode. I asked about it on AskFedora. I have no useful response yet, but another person wrote about a similar experience, but different motherboard; the processor was different, but the same gen and also a UHD type. This needs to be addressed as all the Intel processors have been UHD for quite a while now. I'm thinking I should be writing a bug against mutter. Please let me know if you think I've got something wrong. In general marketing terms like "UHD" aren't important. If you have a graphics adapter that isn't properly supported, you know one thing: that graphics adapter isn't supported. :D Between you and that other reporter...you know that the two models you have don't work. I'd recommend you file a bug, not against mutter, but against probably the kernel (and then CC a...@redhat.com) or xorg-x11-drv-intel (which isn't technically correct but should find the right people). Include the information requested in https://fedoraproject.org I promised an update on the resolution. As it turns out I won't be filing a bug report. I bypassed the earlier problems. I've kept the Intel i5-10400 processor, but exchanged the ASUS Z590-A mother board for an MSI MPG Z490 motherboard. There was another issue with this board; it had non-intel network. I bought an intel based PCI-e to network card and it works great. Problem solved. I now have an up to date PC and it's working fine. It's noticeably faster than the 3Ghz Core Duo it replaced :-) Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Shotwell question
On 3/28/21 11:30, David wrote: I just installed Shotwell on a Rawhide WS install. I assume the first mirror it tried to contact ( twice ? ), and then went to look in a different mirror ?? Here is a partial readout: Downloading Packages: [MIRROR] shotwell-0.31.3-5.fc35.x86_64.rpm: Status code: 404 for https://mirror.genesisadaptive.com/fedora/development/rawhide/Everything/x86_64/os/Packages/s/shotwell-0.31.3-5.fc35.x86_64.rpm (IP: 64.250.112.70) [MIRROR] shotwell-0.31.3-5.fc35.x86_64.rpm: Status code: 404 for http://mirror.genesisadaptive.com/fedora/development/rawhide/Everything/x86_64/os/Packages/s/shotwell-0.31.3-5.fc35.x86_64.rpm (IP: 64.250.112.70) shotwell-0.31.3-5.fc35.x86_64.rpm 175 kB/s | 3.6 MB 00:21 Total 172 kB/s | 3.6 MB 00:21 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing: 1/1 Installing : shotwell-0.31.3-5.fc35.x86_64 1/1 Running scriptlet: shotwell-0.31.3-5.fc35.x86_64 1/1 Verifying: shotwell-0.31.3-5.fc35.x86_64 1/1 Installed: shotwell-0.31.3-5.fc35.x86_64 Complete! Is that helpful information to anybody ? David Locklear ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure David, THe mirrors are servers that make software available. their are LOTs of them. As far as I know they all do it voluntarily. The mirrors spread the traffic so no server or group of servers get overloaded. This mirror is one which hasn't been available much lately from my experience. Several mirrors have either stopped service or have been less available since COVID. Many are hosted by colleges and universities. With no students and few others on hand the mirrors don't get much attention. You seem to have gotten the software you wanted: > Installed: >shotwell-0.31.3-5.fc35.x86_64 Though it doesn't show it, DNF just got the software from the next mirror in the list. So life is good. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Wayland apparently not compatible with new UHD Graphics CPUs
On 3/17/21 21:03, Adam Williamson wrote: On Wed, 2021-03-17 at 15:59 -0400, pmkel...@frontier.com wrote: I know I'm the one who always runs the old PCs, but I recently decided I should have one new one in the mix. The one I got has an ASUS Z590-A motherboard and an Intel i5-10400 processor. Well Fedora won't run a Wayland session on it. It will only run a Gnome-xorg session. I even had to run the install from Basic Graphics mode. I asked about it on AskFedora. I have no useful response yet, but another person wrote about a similar experience, but different motherboard; the processor was different, but the same gen and also a UHD type. This needs to be addressed as all the Intel processors have been UHD for quite a while now. I'm thinking I should be writing a bug against mutter. Please let me know if you think I've got something wrong. In general marketing terms like "UHD" aren't important. If you have a graphics adapter that isn't properly supported, you know one thing: that graphics adapter isn't supported. :D Between you and that other reporter...you know that the two models you have don't work. The graphics are the native on the motherboard standard intel graphics as supported by the processor and the chip set. Here are the links to the Intel documents: https://ark.intel.com/content/www/us/en/ark/products/199271/intel-core-i5-10400-processor-12m-cache-up-to-4-30-ghz.html https://www.intel.com/content/www/us/en/products/sku/196612/intel-z590-chipset/specifications.html The chip set number is why ASUS named their motherboard PRIME Z590-A. Here the link to the motherboard: https://www.asus.com/us/Motherboards-Components/Motherboards/All-series/PRIME-Z590-A/ I'd recommend you file a bug, not against mutter, but against probably the kernel (and then CC a...@redhat.com) or xorg-x11-drv-intel (which isn't technically correct but should find the right people). Include the information requested in https://fedoraproject.org/wiki/How_to_debug_Wayland_problems#Information_to_include_in_your_bug_report (more or less; that hasn't been updated for a while, but it's the best reference we've got). At least include the system journal and the lspci -nn output. Well, I got things a bit out of order. I actually returned the PC to the local company that assembled it for me last Thursday. They are going to get a motherboard with different chip-set and try it with the F33 WS Live install. If it turns out they can't get a combination that will run a Wayland session. I will take it back and and run it with Gnome-xorg until Fedora is more up to date. As for filing the bug: Though I can't provide the technical items (logs, journals, etc) since I don't currently have the PC. I am still inclined to file the bug. with just the information I have in this e'mail chain; so the appropriate folks can have a heads up. Please let me know if you think I should wait. Well at least I can still run Wayland on my test machine. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Wayland apparently not compatible with new UHD Graphics CPUs
I know I'm the one who always runs the old PCs, but I recently decided I should have one new one in the mix. The one I got has an ASUS Z590-A motherboard and an Intel i5-10400 processor. Well Fedora won't run a Wayland session on it. It will only run a Gnome-xorg session. I even had to run the install from Basic Graphics mode. I asked about it on AskFedora. I have no useful response yet, but another person wrote about a similar experience, but different motherboard; the processor was different, but the same gen and also a UHD type. This needs to be addressed as all the Intel processors have been UHD for quite a while now. I'm thinking I should be writing a bug against mutter. Please let me know if you think I've got something wrong. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Basic criterion proposal: g-i-s shouldn't take 2 minutes to launch
On 3/15/21 11:57, Kevin Fenzi wrote: On Sun, Mar 14, 2021 at 11:13:45AM -0400, Ben Cotton wrote: In the wake of the BZ 1924808[1] discussion in Thursday's Go/No-Go meeting[2], I am proposing an addition to the Basic Release Criteria[3]. This would go into Post-Install Requirements -> Expected installed system boot behavior -> First boot utilities (appended after the existing sentence): If a utility for creating user accounts and other configuration is configured to launch, it must be visible within 10 seconds of the first boot reaching the launch point. Why 10 seconds? Why not? That sort of feels like the maximum length of time someone could reasonably be expected to wait. A shorter time might be better. I don't particularly love the wording here, but I wanted to make it clear that it's not 10 seconds from power on, but 10 seconds from the time the boot up reaches the state where we expect gnome-initial-setup or its counterparts to appear. Sounds reasonable to me. +1 I mean, I'd be fine changing the time a little or wording, but I agree with the general gist of it. kevin I agree. Speaking as someone who restarts often; especially when running tests. That extra time was becoming very annoying. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Basic criterion proposal: g-i-s shouldn't take 2 minutes to launch
On 3/15/21 10:45, Ben Cotton wrote: On Mon, Mar 15, 2021 at 10:41 AM Brandon Nielsen wrote: Can we also add a "and displayed without error" clause, or maybe "completes with no visible error"? Something to explicitly capture the "sad face" bug[0]. [0] - https://bugzilla.redhat.com/show_bug.cgi?id=1924908 I thought about that and decided to leave it off as a Basic criterion. I'd be fine with it for Final, but I was worried it would be too strict for Beta, where we expect some degree of sad face from time to time. But maybe this isn't one of those cases? If the consensus is to include a "no errors!", I won't object. A Beta is something that we release to the general public. I don't think it's good for Fedora's reputation to have the Oops sad face screen show up during the installation / setup. Sure there will be bugs in a Beta. I and I think most folks expect to see a small number of SE alerts and/or Abrt notifications, but not something that Shouts "I'm Broken!"; especially during install / setup. Perhaps a middle position would be to say the sad face screen can't be displayed. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Testing F34 WS Beta candidate 1.2
In regard to testing F34 WS Beta candidate 1.2: I was glad to see the white screen sad face gone. Everything went fine through testing the SA basics. I did see the continuing SELinux bugs, but I figure those are being worked on. I set up a second user and logged the account in using Gnome-xorg. After the desktop was up I saw the SE Alerts and their is a new one: https://bugzilla.redhat.com/show_bug.cgi?id=1938563 I'm not halfway with y testing yet. I'll write again if I find anything more that's new. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
video problem
I've been trying to load F33 in a machine with an i5-10400 processor (UHD graphics). The video only works in Gonme xorg mode. I have to run the install from Basic Graphics mode. Is that a known problem? Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Reboot Unmount test case
On 2/28/21 16:24, Chris Murphy wrote: On Sat, Feb 27, 2021 at 9:37 AM pmkel...@frontier.com wrote: I noticed that the QA Basic test case for reboot unmount has apparently been removed. Is this no longer necessary with btrfs? When I go to: https://fedoraproject.org/wiki/Test_Results:Current_Summary QA:Testcase_base_reboot_unmount is listed 7 times, and 5 times it's as milestone basic. There is a btrfs specific portion of that test case that likewise lets us know if previous reboots involved an unclean unmount, thus indicating some kind of reboot problem. Sorry I grabbed an old link to the QA Basic by mistake. When I read your email I cleaned out my old links. Back when I first joined the QA group I saved links to the test cases. At the time, my thinking was that they would be quite stable. Well I learned better, but I never cleared out the old links. Well they're all gone now. I will only look them up from the reference links on: https://fedoraproject.org/wiki/QA:Release_validation_test_plan From now on. Even if this page changes I think the links will stay current. If I'm wrong about this please let me know. Sorry to bother you with such a silly mistake. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Reboot Unmount test case
I noticed that the QA Basic test case for reboot unmount has apparently been removed. Is this no longer necessary with btrfs? Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: when to btrfs scrub, was: Need help with btrfs.
On 2/26/21 14:53, pmkel...@frontier.com wrote: On 2/25/21 15:24, Chris Murphy wrote: An alternative is 'btrfs scrub start -BdR' which will not background the scrub, and will give a detailed report upon completion. Well I think tried all the combinations of scrub status with and without -B, -BdR, -dR to try and get status to report while scrub was running. I was trying to make a combined command (with the &&) that included both the scrub start and the status. I was just going to make it an alias. I couldn't get it to work. scrub would run, but I never got the status. At the end I just made a little script: #!/bin/bash sudo btrfs scrub start -BdR /mnt sudo btrfs scrub status -dR /mnt then I made an alias to the script. Now when I type the alias scrub runs and when its done I get the results. I don't get any progress, but That's better than what I was doing. I don't plan to run it often, but now I can run it easily and at the end know what the results are. Related: We don't seem to be using the drive dismount test in the QA Basic tests any more. At least I didn't see it there. Is that no longer necessary with btrfs? Okay today I noticed that I was getting two reports and the end of scrub. Then it occurred to me that I hadn't tried: sudo btrfs scrub start -BdR /mnt by itself. Sorry, I'll chalk it up to distractions. It works fine. Thank you. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: when to btrfs scrub, was: Need help with btrfs.
On 2/25/21 15:24, Chris Murphy wrote: An alternative is 'btrfs scrub start -BdR' which will not background the scrub, and will give a detailed report upon completion. Well I think tried all the combinations of scrub status with and without -B, -BdR, -dR to try and get status to report while scrub was running. I was trying to make a combined command (with the &&) that included both the scrub start and the status. I was just going to make it an alias. I couldn't get it to work. scrub would run, but I never got the status. At the end I just made a little script: #!/bin/bash sudo btrfs scrub start -BdR /mnt sudo btrfs scrub status -dR /mnt then I made an alias to the script. Now when I type the alias scrub runs and when its done I get the results. I don't get any progress, but That's better than what I was doing. I don't plan to run it often, but now I can run it easily and at the end know what the results are. Related: We don't seem to be using the drive dismount test in the QA Basic tests any more. At least I didn't see it there. Is that no longer necessary with btrfs? Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: when to btrfs scrub, was: Need help with btrfs.
On 2/24/21 20:48, Chris Murphy wrote: On Tue, Feb 23, 2021 at 2:26 PM pmkel...@frontier.com wrote: I recall a long and detailed discussion on this list before F33 was released concerning what disk maintenance would be required with BTRFS. As I recall, the final word was along the lines the running Scrub and the other BTRFS utilities wouldn't be necessary since it was being set up so maintenance shouldn't be needed. Correct. Most of the time, for most users, what's provided is self maintaining in Brfs kernel code. If there's necessary maintenance not provided by the kernel, then it should be scheduled, e.g. a systemd timer kicks off a service unit. Out of curiosity I ran scrub on the four machines I have handy here. I always do clean installs so the btrfs doesn't have a lot of time on it; just since F33 was released. Scrub gives no indication that it's running other than the PID. Nor does it indicate when it's complete; so I had to monitor the PID to know when it was done. Then I had to run: sudo btrfs scrub status -dR /mnt to find the results. Do you know if anyone has some code that runs scrub and gets the status and reports it after scrub is complete? None of the four machines showed any problem. Running scrub and getting the status might be good for people who do upgrade instead of doing clean installs. Maybe even a before and after upgrade might be revealing. Perhaps a special test day for machines that have been running the prior version for 6 months. There was also some hesitancy to call for running scrub because, depending on how often it's run Scrub can be hard on SSDs (they wear out faster). Scrub is mostly a read-only operation involving the verification of checksums for all file system metadata and file data. There's no concern on wear, you could run it every day if you wanted to. I thought sure that there was one of the btrfs utilities that was hard on SSDs if run regularly. Please refresh my memory. But other considerations are how long it will take, how much CPU is used, and will it slow down the computer until it completes? Yes hence the need to know when it's done. Progress indication might be good too. One of the machines I ran it on yesterday was an old Core Duo. Running scrub wasn't noticeable, but the FS content is small on that machine, the run time was seconds. On an AMD machine with 8 cores, but a big (not huge) FS content took minutes maybe 3. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Need help with btrfs.
On 2/23/21 10:58, Matthew Miller wrote: On Tue, Feb 23, 2021 at 10:18:13AM -0500, Neal Gompa wrote: sudo btrfs scrub start /mnt It's kind of unfortunate that we also have a command (in the distro since 2007) called just "scrub" which will destroy al of your data. :-/ Not going to lie, it took three tries to read this to understand what was being said here. :) Sorry, just... don't accidentally leave "btrfs" out of the above command. :) We *do* have btrfsmaintenance[1] which provides what you're asking for. However, we don't install it by default or have presets set up for the timers. There were arguments for and against shipping and enabling them by default[2]. Ah, thanks. I recall a long and detailed discussion on this list before F33 was released concerning what disk maintenance would be required with BTRFS. As I recall, the final word was along the lines the running Scrub and the other BTRFS utilities wouldn't be necessary since it was being set up so maintenance shouldn't be needed. There was also some hesitancy to call for running scrub because, depending on how often it's run Scrub can be hard on SSDs (they wear out faster). Hmmm... Now that seems to be changing. I guess we better revisit the BTRFS maintenance issue again. The first part is: Was this a surprise one-off due to operator error or similar? Do we have a problem and BTRFS maintenance will be required? Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Blocker bugs
On 2/21/21 16:18, Chris Murphy wrote: On Sun, Feb 21, 2021 at 6:18 AM pmkel...@frontier.com wrote: I'm sitting here thinking about F34 Beta being just two days away and what I have observed in my testing. I must admit being more than a little concerned. Beta freeze starts Tue 2021-02-23. Beta Release (Preferred Target) is Tue 2021-03-16. We've got 3-4 weeks to stabilize before we'd be out of the lane. https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html Yes, I understand, but Tuesday is the Freeze. During the Freeze, the only things that can be changed are Exceptions. None of those I mentioned are Blockers or Exceptions. Oh, From what I can see 0221 is in the same state as the prior drops. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Test-Announce] 2021-02-22 @ 17:00 UTC - Fedora 34 Blocker Review Meeting
I wholeheartedly agree with the proposal this needs to be approved. I just added my encouragements to the discussion. We must not let the approval for this get stalled. The words can be tweaked later if it turns out to be necessary. Have a Great Day! Pat (tablepc) On 2/22/21 03:56, Kamil Paral wrote: On Sun, Feb 21, 2021 at 10:18 PM Chris Murphy wrote: On Sun, Feb 21, 2021 at 12:24 PM Tom Seewald wrote: If Gnome is still hanging for 2 minutes on reboot [1] then I think we may want to consider that a blocking bug for F34. I can at least confirm that this bug is still affecting Rawhide. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1909556 Under what criterion would it be a blocker? https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/QAKYTKLYBQS5OMBSATXHTYJA3RWS2U5P/ Never got approved :-/ Perhaps it's time to re-ignite the discussion? ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Blocker bugs
I'm sitting here thinking about F34 Beta being just two days away and what I have observed in my testing. I must admit being more than a little concerned. I have watched the blocker bugs and my concern stems from the fact that I don't see some troubling ones listed there. Also there doesn't seem to have been any discussion about these. Even if these don't technically qualify as blockers, if they are not fixed. they will certainly send a message to those those installing F34 Beta. https://bugzilla.redhat.com/show_bug.cgi?id=1924908 I know the white screen with the sad face at least appears to be cosmetic, but do we really want that. https://bugzilla.redhat.com/show_bug.cgi?id=1928565 This is apparently one of the alerts that if a user has installed setroubleshoot, they get alerts about every 2 seconds. Even if setroubleshoot was not installed my guess is that the SELinux violations are still occurring. GCC has had trouble for the last three drops. Excuse me, I still have to download 0221 for testing. Our beta's are usually pretty sound, but from what I see these may change that impression. If I have gotten something wrong or missed something please let me know if I am worried for no good reason. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F34 WS Beta testing
In regard to my continued testing of F34 Workstation Beta. I am currently at drop 0220.n.0 These are bare metal installs on a Lenovo M53 with a i5-4570 CPU. The ISO was check summed and loaded to a thumb drive using Media Writer. The test machine booted to Live normally. Anaconda started normally. Options to delete all and reclaim space were selected for the hard drive. Install ran normally. I have NOT seen boot from thumb drive problems for a few drops now. During First Boot, I still get the white screen sad face coming up then the window to complete the install appears and the install can be completed. The sad face disappears when Start Using Fedora is clicked. For the last three drops GCC has not run reliable. It either won't start or it crashes when a tab is clicked. I tried to use text editor, but it crashed on start. I'm still seeing the long delays for restarts and shutdown. Have a Good Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
testing ws beta
In regard to testing F34 WS Beta 0214.n.0: This was a bare metal install on a Lenovo M53 with a i5-4570 CPU. The ISO was check summed and loaded to a thumb drive using Media Writer. The test machine booted to Live normally. I haven't seen any No Boots for a couple of drops now. Anaconda started normally. Options to delete all and reclaim space were selected for the hard drive. Install ran normally. The reboot to the hard drive for completing the install started fine, but after the gnome desktop appeared, there was a long pause. Then the White sad face screen appeared. Then after another delay the window to start the complete install appeared on top of the white screen. After the complete the install steps were done and the start using Fedora appeared and was clicked. The white screen disappeared and the normal gnome desktop appeared and works normally. The white sad face screen has been a feature of several prior drops. Following up on some SELinux problems I had seen in prior drops I installed (sudo dnf install setoubleshoot). Alerts started popping up at a rapid rate. I opened the SELinux Alert Browser. I listed the alerts and reported the bugs (1928560, 1928561, and 1928563) were preexisting, but 1928565 was new. I have removed the setroubleshoot so I can continue testing. I do however install setroubleshoot as part of my as deployed configuration for all PCs I support. In regard to the prior drops that would not boot from the thumb drive. I did additional testing and I am convinced that the thumb drive was not the problem. Which is re-enforced buy the good boots I am getting from the last two drops with the same thumb drive. Have a Great Day! Pat(tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: so.... how solid is the f34 branch at branch time?
I'm still seeing this on every restart or shutdown. Currently 0212.n.0 WS Beta. Bare metal install on a Lenovo M53 with a i5-4570 CPU, Have a Great Day! Pat (tablepc) On 2/13/21 20:35, Chris Murphy wrote: On Sat, Feb 13, 2021 at 12:29 PM Adam Williamson wrote: On Sat, 2021-02-13 at 03:01 +0100, AV wrote: On Fri, 2021-02-12 at 17:02 -0800, Adam Williamson wrote: On Wed, 2021-02-10 at 11:30 -0500, Matthew Miller wrote: Last few releases, I've aggressively updated my systems to the branch very shortly after branching, and I have (mostly) not regretted it. If I do that with F34 this week... how's it looking? Well, it has the same somewhat-quirky early build of GNOME Shell / mutter that you already provided notes on from the COPR, so there's that. Aside from that it shouldn't be too bad right now. -- There are some minor quibbles but there is one very irritating problem: very long ( > 4 minutes ) waiting times till shutdown or restart (whatever method is used) on a bare metal install on 2 different laptops. Well, there's a known bug (though I don't have the number to hand) for something that delays 90 seconds on shutdown (it doesn't stop properly and the timeout is 90 seconds). 4 minutes is a lot though, so you might be seeing something else as well? This is the one I'm experiencing. https://bugzilla.redhat.com/show_bug.cgi?id=1925320 With recent updates it's become transient, but still happens often. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Useful tip from the electronics industry
All connectors both for power and signal have a finite life for mating and de-mating. This is because the actual mating surfaces abrade each other as they slide against each other. Also, any spring features in the connector that keep the mating contacts together loose their tension over repeated cycles. Connectors intended for high reliability specify the number of mate / de-mate cycles. Connectors used in "consumer" products are generally not specified for mate / de-mate cycles. Such connectors can be made at lower cost which is generally a high priority for any consumer product. Such connectors generally are designed so they will have a mate / de-mate life greater than the number of cycles a "typical" consumer will use. In the electronics business there are some products that are tested extensively prior to shipment to the customer. Sometimes these test involve the item being connected to and disconnected from systems used for testing several times. In these cases "connector savers" (sometimes called "socket savers" are employed. Savers are connected to all the connectors on the product before any testing begins and are maintain installed on the product until just before shipping. The saver is connector set that mates with the connector on the product. and provides a connector identical to the one on the product where test equipment can be plugged in. In this way the saver bears all the wear from the multiple mate / de-mate cycles. While the product only has one mate /de-mate cycle. I think many of us in the test group mate and de-mate USB connections with our test machines a lot. Some years ago when I first started using USB as the interface for the custom electronics I design. bought some short (15CM) USB extension cables for use as socket savers. They served me well. Over the ensuing years they have developed actual socket savers for USB with a length of about 5 to 7 CM (varies with brand). If you search on "USB connector saver" and "USB socket saver" you should be able to find some. In appearance they have the body of a connector with a male connector on one end and a female connector on the other. Just plug them into your test machine and leave them there. Let the saver take the wear. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Failure to boot Workstation live install images
On 2/9/21 18:11, Chris Murphy wrote: On Tue, Feb 9, 2021 at 3:29 PM pmkel...@frontier.com wrote: As I understand f3 it just writes files to the flash and reads them back checking for errors. I'll go ahead and try f3 on the same thumb drive. It can distinguish between different kinds of problems. I have no doubt, but the granularity of detecting faults on a formatted and mounted storage device by writing files must be less than a pattern test that does not use any preexisting disk data structure and the disk is even dismounted when the test is run. Well I only use Flash from reputable manufacturers and though I never trust any single flash drive with anything important they have provided good results for me. Also, it's not clear that the flash drive is the problem in this case. The fake flash folks have gotten very good at faking seemingly legit hardware down to the packaging. It's not so much reputable brand as it is reputable reseller. Yes, I fully understand and I always buy from the same reputable retailer. The good news is that the thumb drive I use for installing images for test passed both the f3 tests and the badblocks test. Way beyond flash drive fraud. Flash drives, especially the NOR types which seem to be the most common have a few error modes. Though some manufacturers advertise they have new designs good for millions of write cycles. Most of those available now only do about 100K cycles. Following my de-rating rules I never implement flash in any case where more than 50K cycles will be required. An install ISO puts a lot of data on the thumb drive. Then there are the wear leveling strategies to take into account to work out how all the spare blocks get used etc. Estimating the number of Live install cycles a thumb drive should be relied on will be hard and mostly guess work. Even so I would think they should be good for a thousand installs. This thumb drive only has about a hundred on it. Well it's a bit needle in a haystack trying to track down transient boot problems. Well I certainly understand the problems with flash. However I don't think they are quite as bad as that. Side note: With 0207 I once again encountered the white screen sad face. when I rebooted after the initial install to do the complete the install tasks. The complete the install windows popped up on top of the sad face and I was able to coomplete the install. I did a restart after completing the install. The restart ran normally and I have seen no problems. Though I havent tested 0207 extensively. I'll get started again when Branched F34 is available. This could also be transient corruptions on read. USB sticks notoriously do not report discrete read errors, they just return bad data. Well I don't have my thumb drive plugged into my test machine when power up or down. Restarts do not change the power supply state. At least that's the case on my Lenovo machines. My work area is fully static protected. I really doubt the +5VDC supply in my test machine is producing any transients. There would be other highly observable effects. Though with some trouble I could get a scope and monitor it if someone believes that might be the trouble. Oh I thought you were booting from that same stick, but it had been imaged with a different ISO. If the media is failing, the manifestation of the failure can be different between uses. I have one machine I use for testing (Lenovo M83 with i5-4570). I always use that machine and I have been using the same thumb drive (Sandisk 16GB USB 3). As I said before I would guess that it has about 100 Fedora Workstation Live install cycles on it. That's all that thumb drive gets used for. There are no power cycles involved during an install. I do a restart to get from the currently installed version on the system to running from the new version on the thumb drive. When the Live part of the install is complete, I use a restart to get from running Live to running the newly installed version on the hard drive to complete the install. I just pull out the thumb drive after Live is done and the machine is getting ready to start BIOS/UEFI for the boot. My clue is the monitor indicates that BIOS/UEFI has found the monitor but has not found the disk drives yet. This is the procedure I have used since we started using thumb drives with no issues. Come to think of it I used the same procedure back when we used DVDs and again with no problems. I have new thumb drives of the same make and model on hand. If I find time, I will retrain myself to use "dd" in the CLI to write the ISO to the thumb drive. I seem to recall it can be used for that. As long as I see these failures to boot I will keep working on it to see if I can come to a conclusion as if I need to change thumb drives more often, report a bug against Media Writer, or report a bug against the ISO images. A couple questions if I may. I've never taken the opportunity to look
Re: Failure to boot Workstation live install images
On 2/9/21 13:19, Chris Murphy wrote: On Tue, Feb 9, 2021 at 10:23 AM pmkel...@frontier.com wrote: I've seen several ISOs lately that after they were written to a thumb drive using media writer they wouldn't boot. I won't be recounting the details I sent in prior motes to @test, but here is a little more information. The last one I tried was Workstation Live 0207.n.0. It failed to boot initially, but I rewrote the same downloaded image to the same thumb drive with Media Writer again. After that it would boot. This might raise the possibility that Media Writer is involved with the boot problems. I guess I'll just keep track of this from now on. I have been using the same thumb drive plugged into the same USB port all along. Today just for grins I ran badblocks on the thumb drive and no bad blocks were found. "badblocks -w -s -o Thumberror.log /dev/sdb)" I would use f3. The gist is format the USB stick (file system doesn't matter) and mount it. Then sudo f3write /mnt sudo f3read /mnt Actually f3 is part of the Fedora repos now. I decided to use badblocks because I understand it's tests. It's the same basic tests I run on a new board prototype when there is ram or flash on the board. Besides testing the memory, it allows me to check the address and data buses too. Though this does not apply when testing a USB Flash decvice. As I understand f3 it just writes files to the flash and reads them back checking for errors. I'll go ahead and try f3 on the same thumb drive. I see that the file size is constant at 1.1GB except for the last one where it just uses up the left over space. There are 14 files of 1.1GB and 1 file of 5xxMB. so the size checked out. I'm wondering if they pick the file size based on the flash block size. That can make a difference testing flash. I checked out github to see if there is more info there. From what I read f3 seems to only verify size and basic functionality. I think badblocks with it's pattern testing is more likely to find problems. In any case f3read has finish running and pronounced my thumb drive I use for installs to be free of problems. The same result I got from badblocks. But the thing is, transient errors from USB sticks is a real thing. Also, I once had a USB stick that would transiently corrupt on writes if the dd bs size was too high. I forget the value. But somehow it'd either lose writes or reorder them, and I'd get a completely bootable USB stick but it'd spew piles of file system errors during the installation. https://github.com/AltraMayor/f3 https://fight-flash-fraud.readthedocs.io/en/latest/ Well I only use Flash from reputable manufacturers and though I never trust any single flash drive with anything important they have provided good results for me. Also, it's not clear that the flash drive is the problem in this case. Way beyond flash drive fraud. Flash drives, especially the NOR types which seem to be the most common have a few error modes. Though some manufacturers advertise they have new designs good for millions of write cycles. Most of those available now only do about 100K cycles. Following my de-rating rules I never implement flash in any case where more than 50K cycles will be required. An install ISO puts a lot of data on the thumb drive. Then there are the wear leveling strategies to take into account to work out how all the spare blocks get used etc. Estimating the number of Live install cycles a thumb drive should be relied on will be hard and mostly guess work. Even so I would think they should be good for a thousand installs. This thumb drive only has about a hundred on it. Another failure mode is that reads in adjacent cells can flip bits in other cells. They can also be sensitive to x-ray, and em fields depending on flux density. We could go back to using DVDs for testing or perhaps use net install. I think I'd pass on both of those. If it turned out that thumb drives were the issue. I guess we'd just have to change to a new thumb drive more frequently, but right now with the good test results I got on my thumb drive I don't think that will be necessary. I guess the two suspects for now are the ISO image's boot stuff, and Media Writer. Side note: With 0207 I once again encountered the white screen sad face. when I rebooted after the initial install to do the complete the install tasks. The complete the install windows popped up on top of the sad face and I was able to coomplete the install. I did a restart after completing the install. The restart ran normally and I have seen no problems. Though I havent tested 0207 extensively. I'll get started again when Branched F34 is available. This could also be transient corruptions on read. USB sticks notoriously do not report discrete read errors, they just return bad data. Well I don't have my thumb drive plugged into my test machine when power up or down. Restarts do not change the power supply state. At lea
Failure to boot Workstation live install images
I've seen several ISOs lately that after they were written to a thumb drive using media writer they wouldn't boot. I won't be recounting the details I sent in prior motes to @test, but here is a little more information. The last one I tried was Workstation Live 0207.n.0. It failed to boot initially, but I rewrote the same downloaded image to the same thumb drive with Media Writer again. After that it would boot. This might raise the possibility that Media Writer is involved with the boot problems. I guess I'll just keep track of this from now on. I have been using the same thumb drive plugged into the same USB port all along. Today just for grins I ran badblocks on the thumb drive and no bad blocks were found. "badblocks -w -s -o Thumberror.log /dev/sdb)" Side note: With 0207 I once again encountered the white screen sad face. when I rebooted after the initial install to do the complete the install tasks. The complete the install windows popped up on top of the sad face and I was able to coomplete the install. I did a restart after completing the install. The restart ran normally and I have seen no problems. Though I havent tested 0207 extensively. I'll get started again when Branched F34 is available. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
rawhide (F34) WS 0206.n.0
For rawhide (F34) WS 0206.n.0 I am back to: It will not boot the Live install thumb drive with no indication of why on my test machine (Lenovo M83 i5-4570). The download, check sum, and mediawriter transfer to the thumb drive showed no issues. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Rawhide (F34) Workstation drop 0128
On 2/4/21 16:07, Chris Murphy wrote: On Thu, Feb 4, 2021 at 6:16 AM pmkel...@frontier.com wrote: I have noticed that during a restart, the thermal daemon apparently doesn't respond to the stop and the system has to kill it after the 2 minute timeout. This makes restarts very slow. Is this a bug or just how things work now? It's not stuck on thermald, it's stuck on the user manager service. It's best evaluated following a reboot, and then looking at the previous boot with `journalctl -b -1` Feb 04 10:06:39 systemd[1]: Stopped Thermal Daemon Service. Feb 04 10:08:37 systemd[1]: user@1000.service: State 'stop-sigterm' timed out. Killing. See the 2 minute gap? There are a bunch of user services that didn't quit when SIGTERM was issued, for reasons we don't know. There is a 2 minute timer at which point systemd issues a SIGKILL to everything that's part of the user session. Those are: Feb 04 10:08:37 systemd[1]: user@1000.service: Killing process 1323 (systemd) with signal SIGKILL. Feb 04 10:08:37 systemd[1]: user@1000.service: Killing process 2176 (dbus-broker-lau) with signal SIGKILL. Feb 04 10:08:37 systemd[1]: user@1000.service: Killing process 2178 (dbus-broker) with signal SIGKILL. Feb 04 10:08:37 systemd[1]: user@1000.service: Killing process 1733 (pipewire) with signal SIGKILL. Feb 04 10:08:37 systemd[1]: user@1000.service: Killing process 1856 (pipewire-media-) with signal SIGKILL. Feb 04 10:08:37 systemd[1]: user@1000.service: Killing process 1858 (pipewire-media-) with signal SIGKILL. Feb 04 10:08:37 systemd[1]: user@1000.service: Killing process 1571 (pipewire-pulse) with signal SIGKILL. Feb 04 10:08:37 systemd[1]: user@1000.service: Main process exited, code=killed, status=9/KILL Feb 04 10:08:37 systemd[1]: user@1000.service: Killing process 1856 (pipewire-media-) with signal SIGKILL. Feb 04 10:08:37 systemd[1]: user@1000.service: Failed with result 'timeout'. Should bugs be filed? I honestly don't know, because they might legitimately be waiting on something else. But I'd probably start with filing a bug against pipewire. It might be hanging on because some unlisted application refuses to quit. But in that case, either pipewire or systemd needs to include in the journal the reason why pipewire is not responding to SIGTERM, so that we can trouble shoot further. I suspect that dbus-broker isn't quitting because pipewire isn't quitting. Should there be a bug for dbus-broker? I don't know. Maybe. https://bugzilla.redhat.com/show_bug.cgi?id=1925320 Thank you. This and the WS issue #163 were very informative. I never would have guessed the SIGTERM and SIGKILL operate completely open loop. I never would have guessed that it would be at all acceptable for a process to simply ignore SIGTERM. I would have thought that at least processes where data loss might be involved would have brief (conversations) with systemd about things like "need more time", "proccess is blocking my completion", or at least a simple ACK or NAK. In cases where data loss my be involved a popup would presented to the user with a brief explanation and options. Then just put a hold on the restart or shutdown until the user took action. Given that the above is highly unlikely to be implemented, perhaps an easier solution would be to do two things. First shorten the time out and most importantly modify the Gnome software that receives the click for shutdown or restart so the code checks for incomplete transactions for storage and network. If a problem is found inform the user of a delay and and reason. After the situation is resolved Gnome can sent the usual signal for shutdown or reboot. In any case thanks for the insight. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Rawhide (F34) Workstation drop 0128
On 2/2/21 21:23, Adam Williamson wrote: On Tue, 2021-02-02 at 13:30 -0500, pmkel...@frontier.com wrote: I forgot to mention in my last reply that my test PC is set up so it tries to boot BIOS mode first then tries UEFI. Secure Boot is disabled in the firmware setup of my test machine. Hum, well I tested a bit more and actually the box I have issues with isn't booting in UEFI native mode all the way back to F33 Final. So there must be something odd about that specific system, I guess, probably not the same issue you're seeing. It'd be good if everyone having boot issues could tell what's the most recent image they have that actually boots, and whether they're hitting problems in BIOS mode, UEFI native mode, or both. Thanks! I just tested 0201--- n.1 booting in BIOS mode and again in UEFI mode. The thumb drive booted fine in both modes the media check ran fine and the Live started with no problems. Is their a problem with the test list? Lately when I reply I don't get the reply sent back to me. I suppose this might be on purpose to save server bandwidth, but I thought I would check. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Rawhide (F34) Workstation drop 0128
Yesterday afternoon I downloaded (F34 WS) 0201...n.1) instead of n.0. The checksum passed. I loaded it to the same thumb drive with Mediawriter and that ran fine. I booted my test system to the thumb drive and it booted, the media test passed and Live Started. All without issues. I started Anaconda and it came up ready to install and I ran the install. The install ran with no issues. I seems something changed on 0201 between n.0 and n.1. My test system can run with just BIOS boot or UEFI boot instead of try one then try the other. I will do that in a bit to see if either fails and report the results. Have a Great Day! Pat (tablepc) On 2/2/21 21:23, Adam Williamson wrote: On Tue, 2021-02-02 at 13:30 -0500, pmkel...@frontier.com wrote: I forgot to mention in my last reply that my test PC is set up so it tries to boot BIOS mode first then tries UEFI. Secure Boot is disabled in the firmware setup of my test machine. Hum, well I tested a bit more and actually the box I have issues with isn't booting in UEFI native mode all the way back to F33 Final. So there must be something odd about that specific system, I guess, probably not the same issue you're seeing. It'd be good if everyone having boot issues could tell what's the most recent image they have that actually boots, and whether they're hitting problems in BIOS mode, UEFI native mode, or both. Thanks! ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Rawhide (F34) Workstation drop 0128
On 2/2/21 10:42, Chris Murphy wrote: On Mon, Feb 1, 2021 at 4:39 PM Adam Williamson wrote: On Mon, 2021-02-01 at 17:00 -0500, pmkel...@frontier.com wrote: As discussed in today's QA meeting I tried loading and installing Rawhide (F34) Workstation drop 0128. This was done on my test machine: This was an attempted bare metal install on a Lenovo M83 desktop with an i5-4570 CPU. The ISO was check summed and passed Then the ISO was loaded to a thumb drive using Media Writer. This was also successful. Then at attempt was made to boot the test system to the thumb drive. The boot to Live was not successful. The system fell back to booting to the system hard drive. This indicates that the thumb drive was not bootable. This entire process was repeated with the same result. The process was then repeated with the F33 WS Final ISO written to the same thumb drive with Media Writer. The media check ran normally and Live booted normally. I started Anaconda and it came up normally ready to start the install. I believe the 1028 ISO for F34 WS does not allow Media writer to produce a bootable thumb drive. Yeah, I'm actually seeing the same here on my test box with the 20210201.n.0 Workstation live. It boots as an ISO attached to a VM, but doesn't boot when dd'ed to a USB stick. Summary of my IRC jabber: I can boot baremetal Apple EFI and non-Apple UEFI from a dd'd USB stick with 20210201 Workstation image. And qemu-kvm both UEFI and BIOS, whether attached using the SATA CDROM or VirtIO drive. Since I'm unable to reproduce the problem, and I'm not sure from above reports so far, whether the failure is on UEFI (Secure Boot or not), or BIOS, and how the failure manifests on-screen if at all, I'm a bit lost where to keep looking. I'm not seeing anything unusual about LBA 0 where part 1 of the isolinux bootloader is located, or the EFI system partition. I forgot to mention in my last reply that my test PC is set up so it tries to boot BIOS mode first then tries UEFI. Secure Boot is disabled in the firmware setup of my test machine. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Rawhide (F34) Workstation drop 0128
On 2/1/21 21:32, Adam Williamson wrote: On Mon, 2021-02-01 at 15:39 -0800, Adam Williamson wrote: On Mon, 2021-02-01 at 17:00 -0500, pmkel...@frontier.com wrote: As discussed in today's QA meeting I tried loading and installing Rawhide (F34) Workstation drop 0128. This was done on my test machine: This was an attempted bare metal install on a Lenovo M83 desktop with an i5-4570 CPU. The ISO was check summed and passed Then the ISO was loaded to a thumb drive using Media Writer. This was also successful. Then at attempt was made to boot the test system to the thumb drive. The boot to Live was not successful. The system fell back to booting to the system hard drive. This indicates that the thumb drive was not bootable. This entire process was repeated with the same result. The process was then repeated with the F33 WS Final ISO written to the same thumb drive with Media Writer. The media check ran normally and Live booted normally. I started Anaconda and it came up normally ready to start the install. I believe the 1028 ISO for F34 WS does not allow Media writer to produce a bootable thumb drive. Yeah, I'm actually seeing the same here on my test box with the 20210201.n.0 Workstation live. It boots as an ISO attached to a VM, but doesn't boot when dd'ed to a USB stick. netinst images seem to have the same issue. If you still want me to try running 0128 in a VM I will. I just have to enable virtualization in the BIOS/UEFI on my test machine. ` Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Rawhide (F34) Workstation drop 0128
As discussed in today's QA meeting I tried loading and installing Rawhide (F34) Workstation drop 0128. This was done on my test machine: This was an attempted bare metal install on a Lenovo M83 desktop with an i5-4570 CPU. The ISO was check summed and passed Then the ISO was loaded to a thumb drive using Media Writer. This was also successful. Then at attempt was made to boot the test system to the thumb drive. The boot to Live was not successful. The system fell back to booting to the system hard drive. This indicates that the thumb drive was not bootable. This entire process was repeated with the same result. The process was then repeated with the F33 WS Final ISO written to the same thumb drive with Media Writer. The media check ran normally and Live booted normally. I started Anaconda and it came up normally ready to start the install. I believe the 1028 ISO for F34 WS does not allow Media writer to produce a bootable thumb drive. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
for qa meeting
Some points for today's QA meeting: Does Gnome have anything like the Fedora new version Change Proposals? If so do we have access to them? I know there are some Fedora folks that also work on Gnome. I have no doubt that they look out for potential issues, but that's not very transparent. I recall seeing discussions way late in our release cycle as to if the latest Gnome should be included in the pending Fedora release. I would venture that should be determined earlier in the release cycle. Say back when we are having Change Checkpoints. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Rawhide F34 observation
On 1/14/21 03:22, Harold Dost wrote: Essentially 4.0 === 40 and 40 is the new major version. https://9to5linux.com/the-next-major-gnome-release-will-be-gnome-40-coming-march-2021 On Thu 14 Jan 2021 at 00:25, Adam Williamson wrote: On Wed, 2021-01-13 at 13:24 -0500, pmkel...@frontier.com wrote: On 1/13/21 12:15, Matthew Miller wrote: On Wed, Jan 13, 2021 at 09:51:50AM -0500, pmkel...@frontier.com wrote: While testing Rawhide F34 I have observed that the gnome-tweaks application is missing the Extensions, Top Bar, and Workspaces setting windows. Is this a bug of omission or are these settings being removed or added to GCC? I don't see them in GCC. I expect that this is related to the upcoming GNOME redesign which affects these things. Wow, That is a big move especially since Gnome 4.0 seems to be currently set to release in March when F34 is set to release in April. I know we always seem to get the latest Gnome at the last minute, but this seems to be a much bigger change than usual. On the surface this seems like a potential for late F34 or other issues. I hope they have a fallback planned. It seems a bit early for them to be starting to take things out that people use. Rawhide F34 still shows Gnome as 3.38.2 (the same as F33). Yes I know gnome-tweaks is a separate package, in fact a few years back I suggested that it would be nice if GCC and gnome-tweeks were combined into a single tool, but this is an important setting tool and it's being changed well before Gnome 4 is a sure thing. We don't even know that such an integration of these tools is planned for Gnome 4. I hope someone has their arms around this. Saying it's "related" doesn't mean they're gone forever. It may just be that they need reworking for the new GNOME design, and have been taken out so they don't do anything weird or surprise people by not working. I'm not sure, honestly, but asking on desktop@ would probably be better. Wow! a Whole order of magnitude increase (40 instead of 4.0). I expect I will be able to talk with my PC and it will talk back when using the command line :) Seriously though, will we start seeing elements of G40 before we get to Branched or Beta? Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: firewall applet bug
On 1/14/21 03:49, Samuel Sieb wrote: On 1/14/21 12:30 AM, Ed Greshko wrote: On 14/01/2021 16:22, Samuel Sieb wrote: On 1/13/21 11:07 PM, Ed Greshko wrote: On 14/01/2021 13:54, Samuel Sieb wrote: Application icons stopped being generally supported in Gnome a few releases ago. Have you tried installing gnome-shell-extension-topicons-plus? FWIW, it took me 2 minutes to find that does work for Xorg but not for a Wayland session. Strange, it works for me in Wayland. (not the firewall applet which I've never used, but other ones) I don't use Gnome all that much. I'm a bit confused by the wording of your comment. I think you're saying other items which should appear on the upper bar do show in both Xorg and Wayland sessions. But, not the firewall applet. Which you to have tried? I'm saying that other icons from various other applications do show up, but I haven't tried the firewall applet. So, maybe QSocketNotifier: Can only be used with threads started with QThread This one I've seen elsewhere, I don't think it's relevant to this issue. "/proc/4050/root" No idea where that comes from. QObject::connect: No such signal QPlatformNativeInterface::systemTrayWindowChanged(QScreen*) is significant in the Wayland case? That one is possible, since by the name, it's related to the system tray. I will update the existing bug today. in the mean time, here is a little more information I will also add to the bug. Installing topicons-plus makes no difference. Also firewall applet has two main functions. One is the icon in the top bar that provides quick access to a menu firewall functions. The other is that it provides notifications in the notification area when a network connection is established or lost. On an inTel machine neither the icon or notifications work. On an AMD machine (A10-7800), though there is no icon on the top bar there are notifications in the notification area when a network connection is established or lost. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Rawhide F34 observation
On 1/13/21 12:15, Matthew Miller wrote: On Wed, Jan 13, 2021 at 09:51:50AM -0500, pmkel...@frontier.com wrote: While testing Rawhide F34 I have observed that the gnome-tweaks application is missing the Extensions, Top Bar, and Workspaces setting windows. Is this a bug of omission or are these settings being removed or added to GCC? I don't see them in GCC. I expect that this is related to the upcoming GNOME redesign which affects these things. Wow, That is a big move especially since Gnome 4.0 seems to be currently set to release in March when F34 is set to release in April. I know we always seem to get the latest Gnome at the last minute, but this seems to be a much bigger change than usual. On the surface this seems like a potential for late F34 or other issues. I hope they have a fallback planned. It seems a bit early for them to be starting to take things out that people use. Rawhide F34 still shows Gnome as 3.38.2 (the same as F33). Yes I know gnome-tweaks is a separate package, in fact a few years back I suggested that it would be nice if GCC and gnome-tweeks were combined into a single tool, but this is an important setting tool and it's being changed well before Gnome 4 is a sure thing. We don't even know that such an integration of these tools is planned for Gnome 4. I hope someone has their arms around this. I don't recall reading anything like this in the F34 change proposals. Seems like it might be good to have a big Gnome change like this in our change proposals so that Fedora folks can give it some thought and decide what's best for Fedora. If we do go with whatever comes in Gnome 4 we may have to release F34 with the prior version of gnome-tweaks in the F34 repo so users will still have the functionality they need. I guess one fallback could be to make sure that the prior version of gnome-tweaks will work with F34/Gnome4. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Rawhide F34 observation
While testing Rawhide F34 I have observed that the gnome-tweaks application is missing the Extensions, Top Bar, and Workspaces setting windows. Is this a bug of omission or are these settings being removed or added to GCC? I don't see them in GCC. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Bug 1888005
I filed a bug on an an application (kiten) on F33 Workstation back in October. The application worked fine in F32 WS and it is now working fine in Rawhide F34 WS, but the bug is still present in F33 WS on a fully updated system. I checked and F34 WS is using a newer version of kiten I checked Bodhi and added the following note to the bug report: (As of 01/13/2021 in fully updated F33 Workstation, Kiten still shows this bug. However Kiten works fine in Rawhide F34, but Kiten is a newer version in the Rawhide F34 repo (kiten-20.08.3-1.fc34) instead of (kiten-20.08.0-1.fc33) which is still in the F33 repo. Perhaps the solution is to update the version of Kiten in the F33 repo. Bodhi say the newer version was submitted for stable 2 months ago, but apparently it is not their yet. I would be will to help with whatever needs to be done, but I don't know what to do.) Any ideas on what I can do to help this along? Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
firewall applet bug
The firewall applet bug I originally posted about a year ago hasn't received much attention except for the Fedora version being updated. At this point the bug report is a bit messy. Today I decided to look around a bit and see if I could find some more information. The basic problem is that it doesn't show up on the screen though System Monitor shows the process running and it doesn't cause any Abrt errors. Today I poked around in the logs a bit and found the following: Jan 9 07:36:56 firewall-applet: QObject::connect: No such signal QPlatformNativeInterface::systemTrayWindowChanged(QScreen*) Jan 9 07:36:56 firewall-applet: QObject::connect: No such signal QPlatformNativeInterface::systemTrayWindowChanged(QScreen*) Jan 9 07:36:54 firewall-applet: "/proc/1989/root" Jan 9 07:36:53 firewall-applet: QSocketNotifier: Can only be used with threads started with QThread My question is: Should I close this bug and write a new one with this new information, or just add this to the existing bug. I'm wondering if this bug is reported against the correct Fedora component/package/module. https://bugzilla.redhat.com/show_bug.cgi?id=1791860 The bug is still present in fully updated F33 Workstation. Have a Great Day! Pat(tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
firewall applet bug
The firewall-applet bug I originally posted about a year ago hasn't received much attention except for the Fedora version being updated. At this point the bug report is a bit messy. Today I decided to look around a bit and see if I could find some more information. The basic problem is that it doesn't show up on the screen though System Monitor shows the process running and it doesn't cause any Abrt errors. Today I poked around in the logs a bit and found the following: Jan 9 07:36:56 firewall-applet: QObject::connect: No such signal QPlatformNativeInterface::systemTrayWindowChanged(QScreen*) Jan 9 07:36:56 firewall-applet: QObject::connect: No such signal QPlatformNativeInterface::systemTrayWindowChanged(QScreen*) Jan 9 07:36:54 firewall-applet: "/proc/1989/root" Jan 9 07:36:53 firewall-applet: QSocketNotifier: Can only be used with threads started with QThread My question is: Should I close this bug and write a new one with this new information, or just add this to the existing bug. I'm wondering if this bug is reported against the correct Fedora component/package/module. https://bugzilla.redhat.com/show_bug.cgi?id=1791860 The bug is still present in fully updated F33 Workstation. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: testcase base update cli
On 1/4/21 03:06, Kamil Paral wrote: On Sun, Jan 3, 2021 at 2:58 PM pmkel...@frontier.com wrote: While running tests on Fedora 34 Rawhide 20210102.n.0 When running test case QA:Testcase base update cli, it used to be that there was a single file (something not essential as I recall) that would be found so you could watch the update run and judge if it went okay. Such a file no longer seem to be available. If your system is fully up-to-date, there is of course nothing to update. Try again the next day (or the next day), there will be some updates. Or if you want to test it *right now*, you can downgrade some unimportant package (like htop) to a previous version - that's easier on stable Fedora with main+updates+updates-testing repos, but you can do it even on Rawhide by manually downloading an older package version from Koji. I understand. What I'm saying is that I think that an old version of a non-essential package was made part of the compose so their would be something to update in the case of someone running the test on the day the compose was nominated for test. I haven't found anything in the documentation saying to do that. So my guess is that is was something someone was just doing on their own or it was a long running mistake in the process of building a compose. I doubt this because even though I don't remember which package was updated, I do remember that it was always the same package. In any case it was handy because you didn't have to run the test day after day until their was something to update. I'm curious how Coconut runs this test when there isn't something to update. Is it happy with the Complete Nothing to do? As a side note, the command used in the test case is "dnf update". As I recall "update" was deprecated in favor of "upgrade". However, I see that "update" still works though it doesn't appear to be in the man pages anymore. Shall I prepare an update to the test case or did I miss something? Both 'update' and 'upgrade' keywords are supported and work the same way. I'm sure I saw that "update" was deprecated so I just checked and in: https://dnf.readthedocs.io/en/latest/command_ref.html I found "Upgrade Command Command: upgrade Aliases: up Deprecated aliases: update, upgrade-to, update-to, localupdate" Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
testcase base update cli
First!... Happy New Year Everyone. I hope you all had Great holidays. While running tests on Fedora 34 Rawhide 20210102.n.0, I saw a problem that has been present for about a year now. If it's considered a but, I am at a loss to understand what category to put it in. When running test case QA:Testcase base update cli, it used to be that there was a single file (something not essential as I recall) that would be found so you could watch the update run and judge if it went okay. Such a file no longer seem to be available (as I said for a long time now) The only result obtained is (complete nothing to do). Is this intentional or did that just get lost somehow? As a side note, the command used in the test case is "dnf update". As I recall "update" was deprecated in favor of "upgrade". However, I see that "update" still works though it doesn't appear to be in the man pages anymore. Shall I prepare an update to the test case or did I miss something? Have a Great 2021 Everyone! Pat(tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
QA:Testcase base update cli
First!... Happy New Year Everyone. I hope you all had Great holidays. While running tests on Fedora 34 Rawhide 20210102.n.0 today, I saw a problem that has been present for about a year now. If it's considered a but, I am at a loss to understand what category to put it in. When running test case QA:Testcase base update cli, it used to be that there was a single file (something not essential as I recall) that would be found so you could watch the update run and judge if it went okay. Such a file no longer seem to be available (as I said for a long time now) The only result obtained is (complete nothing to do). Is this intentional or did that just get lost somehow? As a side note, the command used in the test case is "dnf update". As I recall "update" was deprecated in favor of "upgrade". However, I see that "update" still works though it doesn't appear to be in the man pages anymore. Shall I prepare an update to the test case or did I miss something? Have a Great 2021 Everyone! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: F33 WS ISO checksum
On 10/28/20 11:44, Ankur Sinha wrote: On Wed, Oct 28, 2020 11:21:07 -0400, pmkel...@frontier.com wrote: Are you saying that the warning message about the 19 lines is a don't care or is their a problem with the way the checksum file is made? Does this mean that the OK message that comes first is in error? I guess you could call it a "don't care". That isn't completely accurate though---sha256sum cares about all lines in the file, but if it they don't fit the format it can understand it skips them and tells the user. The format is explained in the man page: `man sha256sum`. It finds the one line it does understand, uses it to verify the ISO and prints "OK". This is all expected. So, there is nothing wrong with the CHECKSUM file, and there's nothing wrong with the output. Try the GPG related steps listed here. Those are what the PGP signature in the CHECKSUM file is for. https://getfedora.org/en/security/ I'm guessing that those extra lines are data needed by a process that sha256sum calls (perhaps gpg), but sha256sum doesn't use them directly. Otherwise I have no idea what their purpose is. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: F33 WS ISO checksum
On 10/28/20 11:07, Ankur Sinha wrote: On Wed, Oct 28, 2020 10:55:28 -0400, pmkel...@frontier.com wrote: On 10/28/20 10:16, Ankur Sinha wrote: I think sha256sum is pointing out the 19 lines related to the PGP Signature in the CHECKSUM file, which it can't understand. https://getfedora.org/static/checksums/Fedora-Workstation-33-1.2-x86_64-CHECKSUM Perhaps the CHECKSUM files were not previously signed. Thanks for your reply. The checksum file you sent gives the same OK and Warning results as above; Yes, it also includes the 19 lines for the PGP signature, which sha256sum doesn't understand. So, this is expected. Are you saying that the warning message about the 19 lines is a don't care or is their a problem with the way the checksum file is made? Does this mean that the OK message that comes first is in error? Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: F33 WS ISO checksum
On 10/28/20 10:16, Ankur Sinha wrote: On Wed, Oct 28, 2020 09:32:51 -0400, pmkel...@frontier.com wrote: I wanted a fresh copy of the F33 ISO to use for the PCs I maintain. I went to the getfedora.org site. and downloaded the ISO and CHECKSUM files for F33 Workstation. When I run: sha256sum -c Fedora-Workstation-live-33-1;2-x86_64-CHECKSUM I get: Fedora-Workstation-live-x86_64-33-1.2.iso: OK But right under that I get: she256sum: WARNING: 19 lines are improperly formatted I went back to koji and downloaded the files for 1.2 that I originally got for testing 1.2. When I ran the check sum I got the same warning, but I did not get the worning when I originally downloaded 1.2 for testing. What's up? Is their a new bug in sha256sum -c? I think sha256sum is pointing out the 19 lines related to the PGP Signature in the CHECKSUM file, which it can't understand. https://getfedora.org/static/checksums/Fedora-Workstation-33-1.2-x86_64-CHECKSUM Perhaps the CHECKSUM files were not previously signed. Thanks for your reply. The checksum file you sent gives the same OK and Warning results as above; Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
F33 WS ISO checksum
I wanted a fresh copy of the F33 ISO to use for the PCs I maintain. I went to the getfedora.org site. and downloaded the ISO and CHECKSUM files for F33 Workstation. When I run: sha256sum -c Fedora-Workstation-live-33-1;2-x86_64-CHECKSUM I get: Fedora-Workstation-live-x86_64-33-1.2.iso: OK But right under that I get: she256sum: WARNING: 19 lines are improperly formatted I went back to koji and downloaded the files for 1.2 that I originally got for testing 1.2. When I ran the check sum I got the same warning, but I did not get the worning when I originally downloaded 1.2 for testing. What's up? Is their a new bug in sha256sum -c? Have a Great Day! Pat ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Testing F33 Workstation
I've been testing right along, but haven't been reporting since the problems I have encountered have been small compared to some of the issues currently on the table. I am currently running F33 Workstation-Live 0916.n.0. As usual my testing is on bare metal. The installs have been running fine. I've seen the printer problems go from bad to worse when I couldn't even install a printer with CUPS. Now I'm back to being able to install the printer with CUPS, but only using the generic driver. Settings Printer and Print Settings haven't been able to install a printer since when F33 was Rawhide. I've been trying to break btrfs, but only for cases applicable to my as deployed testing installing and uninstalling things trying to fragment the disk and doing "user" unfortunate things to files. So far I haven't seen any problems with btrfs. There is one package in the repo that has a problem. It doesn't seem to be retired. In fact the the version we are using in F32 is listed as the current version for F33. The package seems to be scrambled with items that don't seem to belong and some things missing. I don't know how this should be reported. The package is "pitivi". This bug still present, but as I said small issue. I'm wondering if I have reported this against the wrong package. Since the Firewall-Applet works in non-Gnome desktops should this be reported against one of the Gnome components or perhaps Mutter since I suspect this is a Wayland issue? I guess this could be an issue where the Firewall folks haven't updated this to be Wayland compliant. Clarifications and Suggestions are welcome. https://bugzilla.redhat.com/show_bug.cgi?id=1791860 Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: F33 printer
alciregi, I have a similar issue. Reference the bug below. https://bugzilla.redhat.com/show_bug.cgi?id=1812515 Try the following. Set up a root password. On the terminal use (sudo passwd). Enter a pass word and then verify it. Close the terminal. Open your browser and go to localhost:631 then click Administration. Then click Add Printer. Log into CUPS with User = root and your root password you just set up. You may need to click Add Printer again. Your printer should be listed. Select your printer and Continue. Follow through with the rest of the setup procedure to see if CUPS can directly setup your printer. If not you should should file a bug report at Bugzilla and an Issue at gitlab-gnome. Have a Great Day! Pat (tablepc) On 8/27/20 14:20, alcir...@posteo.net wrote: Hello. I have an HP Deskjet 3700 (WiFi). It is correctly listed when I go to add a new printer, and it works without any issue on F32 and F31 (Workstation). On F33 it is automatically discovered, but if I try to add it, I get a popup stating "Failed to add new printer". Looking at the logs, I can see Aug 27 20:05:13 pbale cupsd[1691]: REQUEST localhost - - "POST / HTTP/1.1" 200 6788911 CUPS-Get-PPDs - Aug 27 20:05:14 pbale cupsd[1691]: [CGI] Unable to create PPD file: Could not poll sufficient capability info from the printer (ipp://HP%20DeskJet%203700%20series%20%5B5B976D%5D._ipp._tcp.local/, ipp://HPF430B95B976D.local:631/ipp/print) via IPP! Aug 27 20:05:14 pbale cupsd[1691]: copy_model: empty PPD file Aug 27 20:05:14 pbale cupsd[1691]: [Client 18] Returning IPP server- error-internal-error for CUPS-Add-Modify-Printer (ipp://localhost/printers/DeskJet-3700) from localhost. Aug 27 20:05:14 pbale cupsd[1691]: REQUEST localhost - root "POST /admin/ HTTP/1.1" 200 450 CUPS-Add-Modify-Printer server-error- internal-error Aug 27 20:05:14 pbale gnome-control-c[3916]: cups-pk-helper: addition of printer DeskJet-3700 failed: server-error-internal-error Aug 27 20:05:15 pbale gnome-control-c[3916]: Installation of the new printer failed. Aug 27 20:05:15 pbale gnome-shell[2549]: g_variant_unref: assertion 'value != NULL' failed However, the printer appears as installed (but it doesn't work). If I try to go in "Printer details" and "Select from Database...", I can see the list of manufacturers, but for each of them the right panel (where printers models should be listed) is always empty. Does anyone has tested a printer with F33? I wonder if it is a problem with this specific printer or there is some bug in cups. Thanks, A. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Testing of Fedora 33 Rawhide 20200811.n.0
In regard to my testing of F33 Workstation Rawhide drop 20200811.n.0: This was a bare metal install on a Lenovo M53 with a i5-4570 CPU. The ISO was check summed and loaded to a thumb drive using Media Writer. The test machine booted to Live normally. Anaconda started normally. For the disk, Custome was chosen to install btrfs. The install ran and finished normally. I only ran a few of the standard tests since my main objective is to exercise btrfs. I concentrated on my as deployed testing. No problems were detected with btrfs. Two long standing bugs persist in this drop: Firewall Applet not working https://bugzilla.redhat.com/show_bug.cgi?id=1791860 Discovered printer won't run https://bugzilla.redhat.com/show_bug.cgi?id=1812515 This one has a serious regression which I will will add to the bug report after Branch. I also found one package that would not install. I found another package that would not run after and apparently successful install. I will pursue both of these after the Branch. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Rawhide (F33 WS) testing
I'm about done with the 0804 drop. Mostly I've been concentrating on my as deployed testing to see if btrfs would show a problem. So far though I'll say: Everything is Essentially, Virtually, Effectively, good. :) There are just a couple of old bugs that are still hanging around. https://bugzilla.redhat.com/show_bug.cgi?id=1791860 https://bugzilla.redhat.com/show_bug.cgi?id=1812515 This one has a major regression. The printer can not be set up at all with either "Settings -> Printers" or "Printer Settings". I can set it up with CUPS, but it won't work with the Brother "driver". I have to use one of the Generic "drivers" (PCL 6/PCL XL Printer Foomatic/PXLMono). that works fine. I'll wait until after the Branch to update the bug reports. Since the problem might just be a missing file in the rawhide repo's. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: agenda for todays QA meeting
On 7/22/20 12:41, Samuel Sieb wrote: Most compression algorithms are far more than "removing same value byte strings". Check out "huffman encoding" for example. I've never had a lossless compression program corrupt my data. Given your extreme mistrust of compression algorithms, it seems that you don't realize how much compressed data you deal with on a regular basis. tar.gz, gzip, zip, rpm, initramfs, kernel, web pages, etc. I know there are a variety of compression algorithms. I know they are used in many places and I have seen that there are many algorithms used in applications that can be trusted or changes tolerated at very low cost. My experience with them has led me to trust them in those applications. I also know from experience that their are applications of compression where the trustworthiness needs to be at least questioned. If this is extreme, well, all I can say is I don't mean to be extreme. My concern with btrfs Was that it uses compression my data. It could cause a lot of work if bits started changing in our files. My concern with btrfs has been addressed and I am now fine with it. Though I certainly know there are other problems that can cause bits to change. I just try to minimize risk where I can. I was trained early on in school to not take things for granted. I try to be data driven. Since I don't have time to become an expert in compression and have some bad history with it I became concerned with this general application, but that's over now. My experience with crc32 was in a hardware implementation. We needed good data integrity and the memory controller chip we chose had crc32 built in. I forget how many bits we added to each word to save the check bits, but I think it was four. I can imagine the uproarious laughter that would result if someone at a gathering of PC folks suggested that new memory modules should include extra bits to support hardware crc. You mean like ECC RAM? The hardware I mentioned was way back when PC were quite primitive let alone any ECC memory modules being available for them. The application had nothing to do with a PC. There was a lot going on with computing before PCs became popular. The only programmers were EEs that designed microprocessors into their boards. The mainframe folks just laughed at us and there weren't any folks graduating from school prepared to program micro's. They all wanted to program mainframes. I know ECC RAM is widely used in servers. but I've never owned or seen a desktop that had ECC capability let alone included it as the default configuration. To be fair though, my users and I use older rehabbed Lenovo machines because they are cheap and they work very well for us. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: agenda for todays QA meeting
On 7/21/20 18:06, Chris Murphy wrote: On Tue, Jul 21, 2020 at 3:36 PM pmkel...@frontier.com wrote: The only ones I've ever seen (not a large population since I've been a compression avoid-er) that approach lossless don't compress much and only take out strings of the same byte value. A very simple example is run length encoding. https://en.wikipedia.org/wiki/Run-length_encoding That's what I meant by "take out strings of the same byte value". I had just forgotten the name. That is variable depending on the source, but quite a lot of human produced material has a metric F ton of zeros in it, so it turns out we get a lot of compressibility. This is used by the current zram default algorithm, as well as lzo which handles the more complex data. This is typically a 3 to 1 upwards of 4 to 1 compression ratio in my testing, with a conservative 2 to 1 stated in the proposal. Wow... I would have never guessed that the ratios had gotten so high. I think I know why. Last holiday time I gave a show and tell to a group and part of it was titled File Bloat. I started with a simple text file that had a size of 475 bytes. Then I showed them the very same text saved as various other file types with very simple formatting and at the worst case (.odt) the file was 22KB with the exact same text. I had showed them printed and on screen examples of each and they were amazed at how little they got at the expense of their storage space. It didn't occur to me at the time, but I'm guessing that file bloat is a major source of the compression ratios you mentioned above. zstd is substantially more complex than lzo, or zlib, and produces similar compression ratios to zlib but at a fraction of the CPU requirement. You can compress and decompress things all day long for weeks and months and years and 100% of the time get back identical data bit for bit. That's the point of them. I can't really explain the math but zstd is free open source software, so it is possible to inspect it. https://github.com/facebook/zstd I've never written a compression algorithm; so I don't know anything about their innards, but I think I'll take a peak. JPEG compression, on the other hand, is intentionally lossy. I'll try to restrain myself from saying much about that particular blight on the land. I've talked to lots of folks about it; even walked some through it with examples. Most just don't care. It's doesn't seem to matter how bad the picture gets as long as they can recognize at all what the picture is of it's okay. The main concern seems to be being able to save LOTS of pictures. I am happy that my still camera has the ability to save Pictures as RAW or uncompressed TIF(F). I thought it was a sad day when they added compression to TIF. I'm off hand not aware of any lossy compression algorithms that claim Back when I was working on those compression analyses there were some very hot debates going on about lossless claims. I don't recall which ones or if they went to court, but I do recall reading some articles about it. As I recall it was in the late '80s. Anyway, short of hardware defects, you can compress and decompress data or images using lossless compression billions of times until the heat death of the universe and get identical bits out. It's the same as 2+2=4 and 4=2+2. Same exact information on both sides of the encoding. Anything else is a hardware error, sunspots, cosmic rays, someone made a mistake in testing, etc. I really like your description. I see now that if the compression is just removing same value byte strings how it really can be truly lossless. As someone who has had to deal with it I'll say that the extra intense radiation from sunspots really does matter. and cosmic rays are ignored only at peril. I don't think asking questions is silly or a problem at all. It's the jumping to conclusions that gave me the frowny face. :-) I try not to, but I have a lot of "buy in" to Fedora. When I read that there's a change coming and it's on a topic I've had some bad experience with... I apologize for jumping. What's considered the meta data. Path to file, file name, file header, file footer, data layout? In a file system context, the metadata is the file system itself. The data is the "payload" of the file, the file contents, the stuff you actually care about. I mean, you might also care about some of the metadata: file name, creation/modification date, but that's probably incidental to the data. The metadata includes the size of the data, whether or not it's compressed, its checksum, the inode, owner, group, posix permissions, selinux label, etc. Thanks I appreciate the help. Though I've written lots of software. this is my first time being involved with the innards of an OS. In my prior experience their either wasn't an OS or even an IDE, just my hex code, or I just got to take the OS for granted and wrote my code in a
Re: agenda for todays QA meeting
On 7/21/20 13:11, Chris Murphy wrote: Yeah, lossy algorithms are common in imaging. There are many kinds that unquestionably do not produce identical encoding to the original once decompressed. The algorithms being used by Btrfs are all lossless compression, and in fact those are also commonly used in imaging: LZO and ZLIB (ZIP, i.e. deflate) - and in that case you can compress and decompress images unlimited times and always get back identical RGB encodings to the original. Short of memory or other hardware error. At the risk of sounding skeptical, I've heard that word "lossless" applied to lots of algorithms and devices that I didn't think was an appropriate usage. As an approximate example, when we were doing that testing we were hoping to find something in the neighborhood of 10-6 probability of a single byte error in a certain structure / size file when exercised a certain number of times. Sorry for being so vague. Is there any statistical data on these algorithms that is publicly available? The only ones I've ever seen (not a large population since I've been a compression avoid-er) that approach lossless don't compress much and only take out strings of the same byte value. Since I'm never short of disk space I prefer not to use compression. I was very excited and pleased when I found out that btrfs check-sums files. However now I understand that it is a patch to make up for the compression. It seems like a zero sum gain to me. I'm not sure what you mean. Btrfs has always had checksumming from day 0. It was integral to the design, before the compression algorithms landed. It is to make up for the fact hardware sometimes lies or gets confused, anywhere in the storage stack. The default for metadata (the fs itself) and data (file contents) is crc32c, it is possible to disable it for data but not possible to disable it for metadata. Compression only ever applies to data. It's not applied to metadata. Checksumming has intrinsic value regardless of compression. Sorry, I have no knowledge of the history of btrfs; so please forgive me when I say or ask silly things. I know about check-summing and use it manually on files that are important. Ya I know about the hardware too. I'm an electrical engineer. If reliability really matters for a design one of the first things I look for when considering any new chip is to see if the manufacturer has any credible reliability data. The problem here is that anything to do with PCs or servers is largely driven by cost and there always has to be a new, better, more exciting model tomorrow. That environment produces very little in the way of parts with long histories with good proven reliability data. That's why I was originally so happy about check-summing being automatic with btrfs. What's considered the meta data. Path to file, file name, file header, file footer, data layout? Oh I just noticed crc32c. That's acceptable. Sorry for going on so much. Thanks and Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: BTRFS testing Rawhide 0703 WS
On 7/20/20 21:34, Michel Alexandre Salim wrote: That's a misleading log message; see e.g. this discussion https://bbs.archlinux.org/viewtopic.php?id=231884 You probably want to use this to check the actual RAID level. btrfs filesystem df / source: https://btrfs.wiki.kernel.org/index.php/UseCases#How_do_I_determine_the_raid_level_currently_in_use.3F Thanks! Now I have new tool to help with my understanding. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: agenda for todays QA meeting
On 7/20/20 13:31, Samuel Sieb wrote: First a bit of background all the PCs (Fedora WS) I maintain are bought with lots of ram 8GB is the min. I don't think I've ever seen swap move off zero and no one has reported any sort of slowdowns. Yet we do lots of memory intensive things. Of course all this is with ext4. That is surprising. Usually at least something ends up in the swap. I'm a convert from that proprietary "we know what's best for you" OS. One of the major things that annoyed me about it was that it horded all the RAM and Swapped everything. One day while talking with a colleague he suggested that I should switch to Linux and he recommended Fedora. I got a copy of Fedora 16 WS and loaded it. That fact that swapping was non-existent and Fedora didn't hord the RAM was one of the things that helped me decide to switch everything here to Fedora. On these machines Disks says that swap lives at /dev/fedora_localhost-live/swap00 and showns no usage. Monitor shows 0 bytes used for swap. I've never seen these move off zero. I haven't changed any of the disk parameters. They are all at their default values as installed. Careful what you're using to measure with. The only accurate measurement is "zramctl". That will tell you exactly how much RAM > the zram device is using. Thanks You really need to read more about zram. There is no dedicated space for it. It only uses RAM as swap is needed. And it uses less RAM than the pages that are getting swapped out, so there's a net reduction in RAM usage without hitting the disk. cmurf explained that to me yesterday, but thanks. These compression algorithms have been tested very hard and are used everywhere. I've never seen mention of any corruption issues. I must say that all of my compression experience has been with the algorithms used to compress images. I won't bore you with the details but we wrote software to build various image files with certain characteristics in pristine form. We did not use the standard test images that are sometimes used. The test files we used were structured to see how good a job the algorithms could do preserving data. Then we saved and opened them using the various standardized algorithms used for the associated file types and analyzed the results. The results were not impressive. We concluded that the results were fine for images. If some pixel values change, the average user will not notice it; so it's not critical. However there are many other kinds of data where such changes would be critical. Now I know the algorithms used for images are different from those used for general file compression on disk, but still, I try to minimize risk. Since I'm never short of disk space I prefer not to use compression. I was very excited and pleased when I found out that btrfs check-sums files. However now I understand that it is a patch to make up for the compression. It seems like a zero sum gain to me. If you really want to disable zram (there's no reason to), I believe the simplest method is "touch /etc/systemd/zram-generator.conf". And it's nothing to do with btrfs. Yes. I understand now that zram is not part of btrfs. It's just that it showed up with btrfs and was yet another thing that raised lot of questions. Now that I understand how zram works, I won't be shutting it off. I do want to have a swap space, and though it doesn't seem to get used, I want it just in case... Thanks and Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Results from install of old drop of WS
As promised in the QA meeting today I have installed an old drop of WS to find the place in Anaconda I thought was there to turn off or not select compression for a disk drive. As it turns out I must have been having a pleasant dream or mistakenly remembered the one for encryption and There was no such box. It's really strange. I have a strong recollection for seeing a box somewhere that had to be check to get data on a disk to be compressed. Sorry for the bad data. Anyway from the discussion, I am under the impression that btrfs uses compression by default for user's data files. If I am right will there be a way to turn that off? Have a Good Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
agenda for todays QA meeting
Let's talk about zram. I just got around to figuring out what zram is. I see it's automatically set up when Anaconda sets up btrfs. First a bit of background all the PCs (Fedora WS) I maintain are bought with lots of ram 8GB is the min. I don't think I've ever seen swap move off zero and no one has reported any sort of slowdowns. Yet we do lots of memory intensive things. Of course all this is with ext4. Now I see on my test machine (btrfs) that about 24% (2GB) of the 8GB of memory (according to monitor) (4GB according to disks) is dedicated to zram0. I imagine the difference in size reported to due to the compression used by zram. However there are two issues: First I can't think of any good reason why I should need or want to have any of my ram dedicated to swapping or other things that speed up btrfs. We've been very happy with swap being on disk since it's never been seen to move off zero. Second, a few years back, I looked over some of the compression algorithms. The probability of loss or corruption was low, but non-zero. I'm sure they have improved, but I'll bet those probabilities are still non-zero. I was taught back in my early years at school that unnecessary risk is foolish risk. So I've always avoided using compression where ever I had an option. If this is necessary to make btrfs work or get reasonable performance from it. That is a strike against btrfs. From this I conclude that to run btrfs on these machines and get the performance we're used to I have to up the minimum ram load to 12GB. Ram modules have a non-zero cost. Given the above this cost must be assigned to btrfs and are born by Fedora users. I'm hoping someone can tell me I'm wrong and why, or that there's a way to opt-out of zram without a hit to performance when using btrfs. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
brtfs by default
Over the past few days I have learned a little about btrfs. I have provided the links to the posts below: Magazine proposal: (1), Discussion: (2), Ticket 2429: (3) I've done some testing on 0703 with btrfs and I am just getting started with 0713 with btrfs. I think the only way to really get confidence is to run Workstation with btrfs; So my plan is to run all the drops I can between now and Beta Release Readiness with btrfs. I won't be doing any rituals, but in these very short cycles I wouldn't expect to see any need for such things. I wholeheartedly agree with cmurf. The need to perform rituals, or otherwise babysit an FS is an indication the something needs fixing and must be fixed rather than "papering" over the part that needs fixing. No I'm not an ordinary user, but when I use my computers for the non-ordinary things I do, I am an ordinary user in the sense that the FS is not on my mind, and shouldn't be. The FS is one of those wonderfully crafted pieces of technology "under the hood" that helps make it work and I don't have to give it a second thought. All that being said btrfs seems to be working great so far. I guess I won't really know about the babysitting part until after I've been running F33 WS for six months with btrfs. (1) https://pagure.io/fedora-magazine-proposals/issue/98 (2) https://discussion.fedoraproject.org/t/btrfs-on-fedora/21611 (3) https://pagure.io/fesco/issue/2429 Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
brtfs by default on F33
Over the past few days I have learned a little about btrfs. I have provided the links to the posts below: Magazine proposal: (1), Discussion: (2), Ticket 2429: (3) I've done some testing on 0703 with btrfs and I am just getting started with 0713 with btrfs. I think the only way to really get confidence is to run Workstation with btrfs; So my plan is to run all the drops I can between now and Beta Release Readiness with btrfs. I won't be doing any rituals, but in these very short cycles I wouldn't expect to see any need for such things. I wholeheartedly agree with cmurf. The need to perform rituals, or otherwise babysit an FS is an indication the something needs fixing and must be fixed rather than "papering" over the part that needs fixing. No I'm not an ordinary user, but when I use my computers for the non-ordinary things I do, I am an ordinary user in the sense that the FS is not on my mind, and shouldn't be. The FS is one of those wonderfully crafted pieces of technology "under the hood" that helps make it work and I don't have to give it a second thought. All that being said btrfs seems to be working great so far. I guess I won't really know about the babysitting part until after I've been running F33 WS for six months with btrfs. (1) https://pagure.io/fedora-magazine-proposals/issue/98 (2) https://discussion.fedoraproject.org/t/btrfs-on-fedora/21611 (3) https://pagure.io/fesco/issue/2429 Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: btrfs testing rawhide 0703
On 7/9/20 10:31, Chris Murphy wrote: On Tue, Jul 7, 2020 at 5:46 PM pmkel...@frontier.com wrote: However as I look at the journal it's not clear if this is a problem or if we need to update the testcase for btrfs. I've attached the journal file for your reading pleasure. This is a good point. The testcase needs two updates. The one previously mentioned which is not an fs journal recovery but about raid6 recovery algorithm, which we can ignore. The part of this I don't understand is how is btrfs a raid6 on a system with only one physical disk drive? I thought raid6 required two separate physical disk drives. But one to add is now btrfs now indicates it wasn't previously unmounted successfully. [9.401852] BTRFS info (device vda3): start tree-log replay Okay so I guess we leave the test alone for those running ext4 and add a test in the same test case document for those running btrfs. Is that right? Or would we drop the ext4 stuff since it would no longer be the "supported" fs and rewrite the test case to be for btrfs only? I foresee the need to a Fedora Magazine article to help people get started doing the btrfs maintenance. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: btrfs testing
On 7/6/20 19:53, Neal Gompa wrote: On Mon, Jul 6, 2020 at 7:43 PM pmkel...@frontier.com wrote: I was not successful in getting the disk configuration set in a configuration that Anaconda would accept for installation. Yeah, custom installation is a little bit of a mind-screw. :( You are too kind. I am a bit embarrassed that I did no see that group of buttons at the bottom. So, what you should try here is go to the Custom view, then select the existing partition on the left side, then click the "-" button. It should prompt you about deleting the partition, and provide a checkbox for deleting all related partitions. Check that, then click "OK". It should clear them out. If there's any more you want to delete, rinse and repeat. Then you can use the drop down menu to select Btrfs and have it create the layout as you attempted before. Thank you very much. It was very simple after I noted the "-" at the bottom. I am really surprised at myself since I saw the "-" on the Advanced Custom. I could delete the existing partitions there but ran into other problems. In any case thanks for taking the time to answer this silly question. I now have Rawhide 0703 WS running on btrfs. Let the testing begin :-) ありがとございました Gompa さま Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
btrfs testing
After the QA meeting today, I spent a few hours trying the get Rawhide 0703 WS Live installed with btrfs. I have Rawhide 0703 WS Live on a thumb drive. I know this works fine when taking the default for the disk. I was trying to do a bare metal install to my test machine (Lenovo M53 with a i5-4570 CPU). the boot and Anaconda start were normal. For the disk drive I selected "Custom" and that's when the problems started. Granted, this was the first time I ever attempted using the custom option. It displayed the existing mount points from the prior default install (ext4). I selected btrfs, but I could not find a way the delete the existing mount points or change them. I tried lots of things including the Advanced Custom. I was not successful in getting the disk configuration set in a configuration that Anaconda would accept for installation. Is this the sort of problem with Anaconda that was mentioned in the meeting? Or... I suppose these tools are not supposed to be very intuitive to use and I need some reading material. The test day instruction were of no aid. and I found nothing in the wiki that was helpful. Have a Great Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Testing of Rawhide F33 Workstation drop 00620.n.1
This is in regard to my testing of Rawhide F33 Workstation drop 00620.n.1: This was a bare metal install on a Lenovo M53 with a i5-4570 CPU. The ISO was check summed and loaded to a thumb drive using Media Writer. The test machine booted to Live normally. Anaconda started normally. Options to delete all and reclaim space were selected for the hard drive. Install ran normally. The reboot to the hard drive was normal. I ran many of the standard tests. They all passed. This included printing to my "no driver" (sort of IPP everywhere) printer (Brother HL-L6200DW). My test results were registered with relval. I noted that some of the Desktop tests have been renumbered. This resulted in one erroneous entry in relval. I have run most of my as configured tests and found that the following bugs still apply: https://bugzilla.redhat.com/show_bug.cgi?id=1791860 https://bugzilla.redhat.com/show_bug.cgi?id=1812515 Have a Great and Safe Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Curiosity in QA:Testcase base service manipulation
On 5/13/20 12:34, Adam Williamson wrote: I ended up putting (sudo su) at the top of each script and just ran the commands without the (su -c). That seemed to work fine. Is there a critical to the test reason to use (su -c)? No. It really just means "do this as root". There are various ways you can indicate this when writing instructions, all with benefits and drawbacks... Thanks it's nice to have suspicions confirmed. Sometimes I've wanted to write some kind of template for it, but never get enough roundtuits... I know all about the shortage of roundtuits. The change in the test case served as inspiration for me to see if I can get this done before F33 branches :-) Be Well Stay Safe Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Curiosity in QA:Testcase base service manipulation
In regard to: QA:Testcase base service manipulation Back about a year ago now I started fiddling around with this test case to see if I could make it a bit easier to run. A little background first. After I have my test machine set up and ready to start testing a new drop I always do the login tests first. Then I set the pass word to "none" and set the account to auto login. I do this because I find I end up doing lots of restarts while I am testing and prefer to not be bothered with the logins as security on my test machine is not an issue. I also set the root pass word, just because I always set a root password on my test machine. Now back to the test case. My approach to the test case is to have four (4) bash scripts that do each part of the test and reboot the system. I save the results for the commands in a file and have another file to keep track of which step last ran so I know which step to run next. I still have to write my top level script and write a little python code to parse the results file and report. While I was getting the four individual scripts running I had a problem with using the (su -c). I seem to recall that using (su -c) required a list being edited to allow the user to use (su -c) I ended up putting (sudo su) at the top of each script and just ran the commands without the (su -c). That seemed to work fine. Is there a critical to the test reason to use (su -c)? Is using the approach I took a problem for the test? Is their a better approach I could take to this? Be Well Stay Safe Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Testing of: Fedora-WS-Live-rawh-20200510-n-0
In regard to my testing of: Fedora-WS-Live-rawh-20200510-n-0 This was a bare metal install on a Lenovo M53 with a i5-4570 CPU. The ISO was check summed and loaded to a thumb drive using Media Writer. The test machine booted to Live normally. Anaconda started normally. Options to delete all and reclaim space were selected for the hard drive. Install ran normally. The reboot to the hard drive was normal. I ran several of the standard tests and my test results were registered with relval. These tests all passed. I ran many of my as configured tests. RHBZ # 1791860 is still present (since F30). https://bugzilla.redhat.com/show_bug.cgi?id=1791860 Be Well and Stay Safe Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: [Test-Announce] Fedora 32 Candidate RC-1.5 Available Now!
On 4/22/20 16:54, tmsta...@t-mittelstaedt.de wrote: Am 22.04.2020 11:54 schrieb Silvia Sánchez : But from *where* do I download the ISO ? On the wiki page are the download links. https://kojipkgs.fedoraproject.org/compose/32/Fedora-32-20200421.0/compose/Workstation/x86_64/iso/ Be Well and Safe! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Testing of F32 Workstation-Live x86-64 RC1.4
On 4/21/20 13:25, Adam Williamson wrote: stardict-dic-en stardict-dic-ja These were both retired as they were unmaintained. You can always check this in dist-git: https://src.fedoraproject.org/rpms/stardict-dic-ja https://src.fedoraproject.org/rpms/stardict-dic-en generally, the URL is src.fedoraproject.org/rpms/(srcpackgename) I would be curious to know what the criteria are for classing something as unmaintained. I believe these are just data file used by the stardict dictionary application. I see that stardict along with the dictionary data files stardict-dic-cs_CZ (Czech) and stardict-dic-hi (Hindi) are present in the repo. I would not expect that a dictionary data file would need periodic maintenance. It seems like unmaintained is just an arbirtary time limit since the last file was presented. Stay Well and Safe! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Testing of F32 Workstation-Live x86-64 RC1.4
In regard to my testing of F32 Workstation-Live x86-64 RC1.4: This was a bare metal install on a Lenovo M53 with a i5-4570 CPU. The ISO was check summed and loaded to a thumb drive using Media Writer. The test machine booted to Live normally. Anaconda started normally. Options to delete all and reclaim space were selected for the hard drive. Install ran normally. The reboot to the hard drive was normal. I ran many of the standard tests. They passed with one exception covered in: https://bugzilla.redhat.com/show_bug.cgi?id=1812515 My test results were registered with relval. I have run most of my as configured tests. So far I have found that the following packages are missing from the current F32 repo: stardict-dic-en stardict-dic-ja Also the following bug still applies: https://bugzilla.redhat.com/show_bug.cgi?id=1791860 What list should I be sending missing package items to? Stay Well and Safe! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
accounts-daemon - sys-nice
I've seen that SELinux is still not allowing the accounts-daemon access to sys-nice. I see there is a bug filed on this: https://bugzilla.redhat.com/show_bug.cgi?id=1811407 There seem to be two lines of thought about a solution. One to change SELinux granting daemons access and the other seems to be to change daemons so they don't ask for what they don't need. Authorizations and access seem to be working fine, so I'm wondering why accounts-daemon needs to change it's operating parameters. At first I wasn't really concerned about this since everything seems to be working nicely, but from what I've read in other places I'm also wondering if this issue and/or it's ultimate solution could be a security risk. By the way what does the Status POST on the bug report mean? Have a Safe and Healthy Day! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal to Change: Testcase base service manipulation
On 4/16/20 16:48, Adam Williamson wrote: On Thu, 2020-04-16 at 13:57 -0400, pmkel...@frontier.com wrote: It's not about interpretation or not, it's just about a preference for this: Test Steps -- 1. Step 1 2. Step 2 3. Step 3 Expected Results 1. Expected result 1 2. Expected result 2 3. Expected result 3 versus this: Test Steps and Expected Results --- 1. Step 1 2. Expected result 1 3. Step 2 4. Expected result 2 5. Step 3 6. Expected result 3 Our current template really only handles the first style, if you want to do the second style you have to do some kind of 'hack' like kparal did. I'm just saying if the second style is clearly better for some test, we should probably add an alternative template or tweak the existing template to have a 'mode' which works better for that style. Sorry for the misunderstanding. I think the second format would serve us best. 1. Step 1 2. Expected result 1 3. Step 2 4. Expected result 2 This makes the test case easier to read with lower chance of confusion. I think there are cases where each works better, there's no harm in supporting both. That's true Be Well and Safe Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal to Change: Testcase base service manipulation
It's not about interpretation or not, it's just about a preference for this: Test Steps -- 1. Step 1 2. Step 2 3. Step 3 Expected Results 1. Expected result 1 2. Expected result 2 3. Expected result 3 versus this: Test Steps and Expected Results --- 1. Step 1 2. Expected result 1 3. Step 2 4. Expected result 2 5. Step 3 6. Expected result 3 Our current template really only handles the first style, if you want to do the second style you have to do some kind of 'hack' like kparal did. I'm just saying if the second style is clearly better for some test, we should probably add an alternative template or tweak the existing template to have a 'mode' which works better for that style. Sorry for the misunderstanding. I think the second format would serve us best. 1. Step 1 2. Expected result 1 3. Step 2 4. Expected result 2 This makes the test case easier to read with lower chance of confusion. Be Well Be Safe Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal to Change: Testcase base service manipulation
On 4/16/20 11:21, Adam Williamson wrote: If we're gonna write test cases like that, we should probably just have an alternative template, or an alternative "mode" for the template we have. I don't like using a template which clearly expects the "Here are the steps, and here are the expected results" format but actually uses "Step 1, step 1 expected result, step 2, step 2 expected result..." format. Writing templates isn't that hard, so I feel like that would be nicer :) We certainly have test cases where the results are open to interprettation and so the test case results could be centralized and allow for that interpretation. We also have test cases where there are specific steps with specific actions that are required to produce specific results. An example is the Services Manipulation test case. In a tests like this, it has always served me well, to have the Expected Results for each step of the test case at the end of each test case step. This eliminates confusion over what the results for a step must be and so increases the accuracy of the test case results. In a test case like this, I don't think we want people interpreting the results. Two templates might be the right thing to do. One for exact tests and one for tests where interpretation is or is likely to be involved. Stay Well Stay Safe Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal to adjust final criterion for backgrounds
The approach the current criteria were intended to back was one where we would have something like rawhide-backgrounds or development- backgrounds which contained a background image that was very obviously a WORK IN PROGRESS kind of thing - picture of Beefy with "PRE RELEASE" written on it, or something like that - and this would be the *permanent* default background for Rawhide. 'Final' backgrounds would then be introduced for each release after it branched from Rawhide. This would have the happy side effect that if we didn't get around to doing anything by the Beta release, the Beta release would come out with the 'development' background, which we figured would be OK for a Beta, rather than with the same background as the previous release, which isn't. Aside from that one, the other advantage of this approach is that it means you only have to do work in each release branch, you don't also have to keep changing things in Rawhide. That sounds good to me. I always found it confusing to have the prior release background in the pre-release of the next version. Rawhide deserves its own background and as you say it will make it obvious that it's a pre-release version. Stay Safe Stay Well Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Testing of Workstation-Live RC1.3
In regard to my testing of Workstation-Live RC1.3: This was a bare metal install on a Lenovo M53 with a i5-4570 CPU. The ISO was check summed and loaded to a thumb drive using Media Writer. The test machine booted to Live normally. Anaconda started normally. Options to delete all and reclaim space were selected for the hard drive. Install ran normally. The reboot to the hard drive was normal. I ran several of the standard test cases and my test results were registered with relval. As I continued with my as deployed testing I noted packages missing from the repo. gimp-gap, stardict-dic-en, stardict-dic-ja, simplescan, obs-studio, and others. I doubt these are retired. Notable items: Could not run updates. I tried (sudo dnf upgrade --refresh) at the command line, Software, and dnfdragora. No updates were found. There is usually a token update just to test the update process. The usual repo's seemed to be enabled. I then enabled update-testing and found some I could run. So I guess the update process is working. Apparently there just wasn't any token update in the repo for testing. Stay Safe Stay Well Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Testing with NVMe
On 4/4/20 15:27, Richard Shaw wrote: On Sat, Apr 4, 2020 at 10:45 AM pmkel...@frontier.com wrote: I'm not sure the having UEFI is the differentiator... I have a 6th gen I5 computer which boots UEFI fine but predates NVMe. On that one I use a PCIEx4 adapter and have /boot and /boot/EFI on the HD and then the system on the NVMe drive. My test machine is a 4th gen. i5-4570. From what I can tell it wouldn't be able to boot to a NVMe on a PCI adapter. I could get a NVMe set up on an adapter like I was originally thinking, but I do testing on Workstation-Live and I take the defaults for installation; so is there someplace where I can learn how to split the installation like you've done it with the /boot and /boot/EFI on the HD and the System on the NVMe? Then there is the question: Would testing Workstation set up like that would be of value to the project? I'm thinking there aren't many users set up like that. Also, it might be a confusion factor for any bugs I find. Thanks for your help. Stay Safe and Stay Well Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
F32 Workstation-live 0401 drop
I just finished my testing of 0401 on my bare metal test system. The results were not reported because the current event is 0404. Everything looks good except for the bugs I already reported and they are not blockers. https://bugzilla.redhat.com/show_bug.cgi?id=1812510 https://bugzilla.redhat.com/show_bug.cgi?id=1812515 Stay Safe and Well Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Testing with NVMe
On 4/4/20 10:24, Richard Shaw wrote: On Sat, Apr 4, 2020 at 9:14 AM pmkel...@frontier.com wrote: One thing that seems rather puzzling is that NVMe is offered in three different connection configurations. PCI-E, USB (with a USB connector), and SSD via SATA (with an SATA connector. Since multichannel PCI-E is very much faster that either USB or SATA I don't really understand why the USB and SATA options are offered. It seems a bit like having a car that's designed and built for racing and only driving it on city streets. Are you sure you're not conflating M.2 and NVMe? From what I can tell NVMe is only for storage whereas M.2 is primarily used for storage but there are other types of M.2 cards. Sorry I wasn't more clear about that. Yes M.2 is a physical connector configuration with a specified key position on the connector. Modules with that connector are available in functional types I mentioned. M.2 SSD's can come in SATA and NVMe variants. As far as USB 3.0, it's pretty fast and someone may want compact a M.2 NVMe SSD in a USB 3.0 enclosure for convenience. I guess, but an ordinary SSD in an external box would do as well. USB 3 is the limiting factor for speed. Though being able to boot might be an advantage for test. In this case I would ask what is it we really want to test, high speed access and data flow, or just ordinary operation like booting and normal use at desktop kind of speeds? From the various conversations with the test folks over time, it seems many in the group test on laptops. Many of the newer lap tops have a connector on the motherboard that connects an NVMe to PCI-E. This and the above leads me to believe that the testing we want to do is with NVMe on PCI-E. That's what I'm planning at this time. Yes I think that would cover the vast majority of situations, but that includes many desktops today too, not just laptops. I'm running a Samsung 970 EVO on my Ryzen 5 2600 system. Is that your only "disk" for boot and whatever else you do? I have only desktops none of the ones I support have such a slot on the mother board. No worries; There are PCI-E adapter boards that NVMe modules can be plugged into then the board plugs into a standard PCI-E four channel slot. This is the route I'm planning to go. That should work for secondary storage (and testing) but frequently the system can't boot from a NVMe add-in card because the BIOS doesn't support it. Well that's certainly another point to consider. Do you happen to know if UEFI supports it? I'll have to reboot my test machine later to see if there is anything that looks like it in the config. pages. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Testing with NVMe
At last Monday's meeting there was mention of a need to start testing with NVMe. I volunteered to get some and help with that. Part of my motivation was the desire to become familiar with it and see if it's something I might have an application for. NVMe seems to have been created created mostly for servers and a few other applications that need extremely fast data access and flow from "disk". From what I've seen the newer 19" rack servers offer a NVMe slot on the board. One thing that seems rather puzzling is that NVMe is offered in three different connection configurations. PCI-E, USB (with a USB connector), and SSD via SATA (with an SATA connector. Since multichannel PCI-E is very much faster that either USB or SATA I don't really understand why the USB and SATA options are offered. It seems a bit like having a car that's designed and built for racing and only driving it on city streets. From the various conversations with the test folks over time, it seems many in the group test on laptops. Many of the newer lap tops have a connector on the motherboard that connects an NVMe to PCI-E. This and the above leads me to believe that the testing we want to do is with NVMe on PCI-E. That's what I'm planning at this time. I have only desktops none of the ones I support have such a slot on the mother board. No worries; There are PCI-E adapter boards that NVMe modules can be plugged into then the board plugs into a standard PCI-E four channel slot. This is the route I'm planning to go. The complication is that there are different kinds of NVMe modules and the PCI-E boards have different configurations as well. At this point I think I will get a board for "M.2" modules and a module to go with it. There are still some points I want to investigate before I go ahead. I want read some of the module data sheets in detail to see if there are any GotYas that need to be considered. Also I want to see what the "raw" formatting of the module looks like and if it changes from brand to brand or with module capacity. My observation has been that manufacturers always want a "competitive advantage" and sometimes those "advantages" can turn into "let the buyer beware". In regard to actual procurement. Many of the modules require heat sinking most of the adapter boards provide at least some minimal provision for adding a heat sink. Others come complete with all required hardware for heat sinking. This gets a bit tricky. The modules provide the specifications necessary to calculate temperature rise from modules heat dissipating surface. I still need to find an adapter card with the corresponding specifications. so a complete thermal analysis can be done. A final point of interest is that there are some NVMe modules that are being called SATA instead of just being called NVMe. I would be think that pretending to be an SATA-SSD drive would just a superficial matter the desktop would handle and the highs peed data access and flow would be handled in a very light weight protocol in the kernel. This is just a guess, but I would think that using the SATA protocol would slow things down. Since NVMes apparently exist for applications with a huge need to speed I guess I don't understand this. Any comments or suggestions are always welcome Stay Safe and Well! Pat (tablepc) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
