Fedora-Cloud-30-20200514.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
Fedora-IoT-33-20200513.0 compose check report
Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Passed openQA tests: 8/8 (x86_64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: Used mem changed from 169 MiB to 147 MiB Peak task count changed from 121 to 103 Previous test data: https://openqa.fedoraproject.org/tests/595828#downloads Current test data: https://openqa.fedoraproject.org/tests/597767#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: Used mem changed from 169 MiB to 148 MiB Peak task count changed from 118 to 104 Previous test data: https://openqa.fedoraproject.org/tests/595829#downloads Current test data: https://openqa.fedoraproject.org/tests/597768#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
flatpak / KDE question
I have little experience if any with flatpaks on KDE. I just installed flatpak on my new Rawhide KDE The list below shows some of the dependencies: gnome-desktop3-3.37.1-1.fc33.x86_64 low-memory-monitor-2.0-4.fc32.x86_64 p11-kit-server-0.23.20-1.fc32.x86_64 pipewire-0.3.4-2.fc33.x86_64 pipewire-libs-0.3.4-2.fc33.x86_64 plasma-discover-flatpak-5.18.5-1.fc33.x86_64 xdg-desktop-portal-1.7.2-1.fc33.x86_64 xdg-desktop-portal-gtk-1.7.1-1.fc33.x86_64 xdg-desktop-portal-kde-5.18.5-1.fc33.x86_64 So there is the gnome-desktop and the xdg-desktop-portal-gtk in there. I assume that is necessary, in order to use flatpaks that were designed for gnome.Right ? Is there a way to make flatpak itself a flatpak ? Meaning to nest the dependencies in a 2nd level of sandboxing ? How is one to know that those dependencies above are not worse than what you would get if you just ran the software natively ?? David Locklear 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
Fedora-IoT-32-20200512.0 compose check report
No missing expected images. Passed openQA tests: 8/8 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
Fedora-Cloud-31-20200513.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
Fedora-Cloud-32-20200513.0 compose check report
No missing expected images. Soft failed openQA tests: 1/1 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 597167 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/597167 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
Re: a question for Rawhide users ( Rawhiders ?? )
On Wed, May 13, 2020 at 10:56:33AM -0500, David wrote: > It looks or appears to me that many if not all packages in Rawhide are > slightly > more recent versions that the ones available via flatpak.I know some > flatpaks > also offer a choice of a nightly version. > > I was just wondering or pondering, which packages Rawhiders, > prefer to run as a flatpak or vice-versa. It's up to your preference. In some cases you might want both. > Would Rawhide be more stable to run all available packages in flatpak > ? > Or is that too cumbersome ? Or does that defeat the > purpose of testing packages ? It would yes. You would be testing flatpak's and their platforms instead. Which isn't completely a bad thing, just different. > I used flatpaks for over a year, but I am not yet a flatpak-lover, or > flatpak-fanboy > or whatever they call themselves. I do not really have a need for the > extra-security > of a sandboxed program. The number one thing about flatpaks that I > like, is that they > are so easy to delete, so I like to install a flatpak of a program that I > am not familiar > with. Well, rpms should be easy to remove as well. flatpaks are handy if you are running silverblue, they are also sometimes nice because the stack some application uses in rawhide is broken somwhere, and you can just use the flatpak until it's fixed. The sandboxing is a nice bonus. Just my 2c. kevin signature.asc Description: PGP signature ___ 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
Fedora-Cloud-32-20200512.0 compose check report
No missing expected images. Soft failed openQA tests: 1/1 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 596122 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/596122 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
Fedora-Cloud-31-20200512.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
Fedora-Cloud-30-20200512.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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 Wed, 2020-05-13 at 12:22 -0400, pmkel...@frontier.com wrote: > 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)? 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... I've kinda wobbled around a few different styles for this when writing in the wiki over the years, you'll find different test cases and common bugs entries and so on that do it differently depending on when they were written :) Sometimes I've wanted to write some kind of template for it, but never get enough roundtuits... > Is using the > approach I took a problem for the test? Not at all. > Is their a better approach I could take to this? It sounds like you're dealing with it fine :) We do have this test case fully automated in openQA too, but it's always good to have confirmation from someone testing a different way. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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
a question for Rawhide users ( Rawhiders ?? )
It looks or appears to me that many if not all packages in Rawhide are slightly more recent versions that the ones available via flatpak.I know some flatpaks also offer a choice of a nightly version. I was just wondering or pondering, which packages Rawhiders, prefer to run as a flatpak or vice-versa. Would Rawhide be more stable to run all available packages in flatpak ? Or is that too cumbersome ? Or does that defeat the purpose of testing packages ? I used flatpaks for over a year, but I am not yet a flatpak-lover, or flatpak-fanboy or whatever they call themselves. I do not really have a need for the extra-security of a sandboxed program. The number one thing about flatpaks that I like, is that they are so easy to delete, so I like to install a flatpak of a program that I am not familiar with. 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
Re: user switching criterion proposal
On Tue, May 12, 2020 at 5:56 PM Adam Williamson wrote: > I think we don't need the weasel form in this criterion as we actually > do want to block on user switching *fully working*. So I think I'd > agree with Lukas (and Brandon) that this can be changed to "perform", > but keeping the reference to conditional violations if you like - but > I'd change the link to this part of the blocker bug FAQ: > > > https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues.3F > > which is what we usually use as the target for such references. > Thanks, Adam. That link is much better, and I'm happy to follow your advice on wording as you're our number one criterion lawyer ;-) Here's an updated criterion proposal. I marked adjusted parts with an asterisk. ~ User switching User switching must work using the mechanisms offered (if any) by all release-blocking desktops in their default configuration. What is user switching? User switching is a process of changing the currently presented desktop session between concurrent sessions of two or more different users. The user sessions keep running in the background, and users can switch between them repeatedly without losing any running application state. For the purpose of this criterion, user switching doesn't include switching between different sessions of the *same* user. Work? The switching mechanism must correctly perform* the requested operation. If the operation doesn't succeed* on a subset of graphical drivers, the release blocking decision should be based on the number of affected users, the problem severity and available workarounds (as is our [standard procedure](Blocker_Bug_FAQ#What about hardware and local configuration dependent issues?)*). Default configuration?* This is supposed to cover only cases where the system hasn't been modified in a substantial (and relevant) way. This excludes cases where people e.g. install multiple desktop environments, replace their display manager for a different one, tweak relevant systemd settings, or install a non-default graphics driver. ~~ * denotes a change in wording ___ 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
