[Test-Announce] Fedora 35 Rawhide 20210428.n.1 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 35 Rawhide 20210428.n.1. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/35 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210428.n.1_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210428.n.1_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210428.n.1_Base https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210428.n.1_Server https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210428.n.1_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210428.n.1_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210428.n.1_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-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-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: post go upgrades (re)testing
On Wed, Apr 28, 2021 at 10:47:39AM +0100, Sérgio Basto wrote: > On Tue, 2021-04-27 at 11:39 -0700, Kevin Fenzi wrote: > > Hey folks. > > > > I wonder if we couldn't add in some (re)testing of upgrades after a > > release > > is 'go' but before it's actually released. We hit at least two issues I > > am aware of with f34 due to multilib. ;( > > > > I'm asking this for years and to not stress and delay to much the > release, I proposed do a second release in this case it would be 34.1 That would be prohibive on resources and there would be a lot of process that we do now once per 6 months that would need to be done in days/weeks. :( So no, I dont think thats a good answer unless we can't avoid it. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: post go upgrades (re)testing
On Tue, 2021-04-27 at 11:39 -0700, Kevin Fenzi wrote: > Hey folks. > > I wonder if we couldn't add in some (re)testing of upgrades after a release > is 'go' but before it's actually released. We hit at least two issues I > am aware of with f34 due to multilib. ;( > > first: > pipewire.i686 is in the base x86_64 repo and users had/have it installed. > > pipewire.i686 is pulled into the x86_64 base repo by mutter (mutter.i686 > is there and requires pipewire.i686). > > In any case it is not in the updates repo, so once an update of them > is pushed (which it has been), upgrades fail due to the missing > packages. > > I have modified the updates pungi config to whitelist pipewire for > multilib and it's in f34-updates now. > > second: > There's still an issue with iptables. > See https://bugzilla.redhat.com/show_bug.cgi?id=1953178 > basically the version in the base repo has a 'iptables' package. > The one in updates Obsoletes this for a iptables-compat, but yet it's > not doing things correctly as users are getting dnf errors. > > Anyhow, I think it might be good to perhaps schedule some re-resting of > upgrades after the 0 day updates repo is populated to try and catch > these and fix them before release day. > > We can't test this fully before there is an updates repo (I mean we kind > of can with updates-testing, but it's not the exact same repo). We do sort of have this already, because openQA tests all updates, and one of the tests it runs on them is an upgrade test. Now, the iptables thing is interesting, because the logs of that test on an F34 update show the issue: 2021-04-28T04:30:39-0400 WARNING Problem: cannot install both iptables-libs-1.8.7-3.fc34.x86_64 and iptables-libs-1.8.7-6.fc34.x86_64 - package iptables-1.8.7-3.fc34.x86_64 requires iptables-libs(x86-64) = 1.8.7-3.fc34, but none of the providers can be installed - cannot install the best update candidate for package iptables-libs-1.8.5-6.fc33.x86_64 - cannot install the best update candidate for package iptables-1.8.5-6.fc33.x86_64 but it's only logged as a WARNING and does not prevent the upgrade running. So the test passes. It doesn't even need to use `-- allowerasing` so it doesn't register as a soft fail. For the pipewire issue, we won't catch it with automation because the package isn't installed in any default F32 or F33 package sets. Doing some manual testing might be possible, but then we were already a bit tired from validating RC2 in five hours. People might have wanted a break. And of course, signing RC2 off on Friday meant there was virtually no office time for RH employees to do it in... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fcitx issues on Fedora 34
在 2021-04-24星期六的 23:48 -0400，Leander Hutton via test写道： > Here is the output from journalctl, it seems it is getting activated > but then gets signal 15 (SIGTERM) from somewhere else? If I manually > start fcitx in KDE Plasma it will happily stay running until logout. Try this workaround: edit /etc/xdg/startkderc, comment out systemdBoot=true (or set to false) -- Qiyu Yan GPG keyid: 0x4FC914F065F2DF12 signature.asc Description: This is a digitally signed message part ___ 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 35] Call for Test Days
Hi Fedora users, developers, and friends! It's time to start thinking about Test Days for Fedora 35. For anyone who isn't aware, a Test Day is an event usually focused around IRC for interaction and a Wiki page for instructions and results, with the aim being to get a bunch of interested users and developers together to test a specific feature or area of the distribution. You can run a Test Day on just about anything for which it would be useful to do some fairly focused testing in 'real time' with a group of testers; it doesn't have to be code, for instance, we often run Test Days for l10n/i18n topics. For more information on Test Days, see https://fedoraproject.org/wiki/QA/Test_Days . Anyone who wants to can host their own Test Day, or you can request that the QA group helps you out with organization or any combination of the two. To propose a Test Day, just file a ticket in fedora-qa pagure - here's an example https://pagure.io/fedora-qa/issue/624 . For instructions on hosting a Test Day, see https://fedoraproject.org/wiki/QA/SOP_Test_Day_management . You can see the schedule at https://pagure.io/fedora-qa/issues?tags=test+days . There are many slots open right now. Consider the development schedule, though, in deciding when you want to run your Test Day - for some topics you may want to avoid the time before the Beta release or the time after the feature freeze or the Final Freeze. We normally aim to schedule Test Days on Thursdays; however, if you want to run a series of related Test Days, it's often a good idea to do something like Tuesday / Wednesday / Thursday of the same week (this is how we usually run the X Test Week, for instance). If all the Thursday slots fill up but more people want to run Test Days, we will open up Tuesday slots as overflows. And finally, if you really want to run a Test Day in a specific time frame due to the development schedule, but the Thursday slot for that week is full, we can add a slot on another day. We're flexible! Just put in your ticket the date or time frame you'd like, and we'll figure it out from there. If you don't want to run your own Test Day, but you are willing to help with another, feel free to join one or more of already accepted Test Days: GNOME Test Day* i18n Test Day* Kernel Test Week(s)* Upgrade Test Day* IoT Test Week* Cloud Test Day* Fedora CoreOS Test Week* And don't be afraid, there are a lot of more slots available for your own Test Day! [*] These are the test days we run generally to make sure everything is working fine, the dates get announced as we move into the release cycle. If you have any questions about the Test Day process, please don't hesitate to contact me or any member of the Fedora QA team on test at lists.fedoraproject.org or in #fedora-qa on IRC. Thanks! -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED ___ 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-Announce] [Fedora 35] Call for Test Days
Hi Fedora users, developers, and friends! It's time to start thinking about Test Days for Fedora 35. For anyone who isn't aware, a Test Day is an event usually focused around IRC for interaction and a Wiki page for instructions and results, with the aim being to get a bunch of interested users and developers together to test a specific feature or area of the distribution. You can run a Test Day on just about anything for which it would be useful to do some fairly focused testing in 'real time' with a group of testers; it doesn't have to be code, for instance, we often run Test Days for l10n/i18n topics. For more information on Test Days, see https://fedoraproject.org/wiki/QA/Test_Days . Anyone who wants to can host their own Test Day, or you can request that the QA group helps you out with organization or any combination of the two. To propose a Test Day, just file a ticket in fedora-qa pagure - here's an example https://pagure.io/fedora-qa/issue/624 . For instructions on hosting a Test Day, see https://fedoraproject.org/wiki/QA/SOP_Test_Day_management . You can see the schedule at https://pagure.io/fedora-qa/issues?tags=test+days . There are many slots open right now. Consider the development schedule, though, in deciding when you want to run your Test Day - for some topics you may want to avoid the time before the Beta release or the time after the feature freeze or the Final Freeze. We normally aim to schedule Test Days on Thursdays; however, if you want to run a series of related Test Days, it's often a good idea to do something like Tuesday / Wednesday / Thursday of the same week (this is how we usually run the X Test Week, for instance). If all the Thursday slots fill up but more people want to run Test Days, we will open up Tuesday slots as overflows. And finally, if you really want to run a Test Day in a specific time frame due to the development schedule, but the Thursday slot for that week is full, we can add a slot on another day. We're flexible! Just put in your ticket the date or time frame you'd like, and we'll figure it out from there. If you don't want to run your own Test Day, but you are willing to help with another, feel free to join one or more of already accepted Test Days: GNOME Test Day* i18n Test Day* Kernel Test Week(s)* Upgrade Test Day* IoT Test Week* Cloud Test Day* Fedora CoreOS Test Week* And don't be afraid, there are a lot of more slots available for your own Test Day! [*] These are the test days we run generally to make sure everything is working fine, the dates get announced as we move into the release cycle. If you have any questions about the Test Day process, please don't hesitate to contact me or any member of the Fedora QA team on test at lists.fedoraproject.org or in #fedora-qa on IRC. Thanks! -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED ___ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-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-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: post go upgrades (re)testing
On Tue, 2021-04-27 at 11:39 -0700, Kevin Fenzi wrote: > Hey folks. > > I wonder if we couldn't add in some (re)testing of upgrades after a > release > is 'go' but before it's actually released. We hit at least two issues I > am aware of with f34 due to multilib. ;( > I'm asking this for years and to not stress and delay to much the release, I proposed do a second release in this case it would be 34.1 > first: > pipewire.i686 is in the base x86_64 repo and users had/have it > installed. > > pipewire.i686 is pulled into the x86_64 base repo by mutter > (mutter.i686 > is there and requires pipewire.i686). > > In any case it is not in the updates repo, so once an update of them > is pushed (which it has been), upgrades fail due to the missing > packages. > > I have modified the updates pungi config to whitelist pipewire for > multilib and it's in f34-updates now. > > second: > There's still an issue with iptables. > See https://bugzilla.redhat.com/show_bug.cgi?id=1953178 > basically the version in the base repo has a 'iptables' package. > The one in updates Obsoletes this for a iptables-compat, but yet it's > not doing things correctly as users are getting dnf errors. > > Anyhow, I think it might be good to perhaps schedule some re-resting of > upgrades after the 0 day updates repo is populated to try and catch > these and fix them before release day. > > We can't test this fully before there is an updates repo (I mean we > kind > of can with updates-testing, but it's not the exact same repo). > > kevin > ___ > 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 -- Sérgio M. B. ___ 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-Cloud-32-20210428.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20210427.0): ID: 871631 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/871631 ID: 871638 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/871638 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: post go upgrades (re)testing
I wonder what the best way to improve the situation would be. There are two
issues as a I see it:
a) Some packages (pipewire.i686) are not in the default installation and
therefore our automated checks don't catch it. The manual checks are often
done with default installations as well, but someone with a real-world
machine can stumble on it.
b) Some packages (I think this is the case of iptables) are in a default
installation, but are in updates-testing, which we ignore during upgrade
testing. On one hand, it makes sense, we want to make sure the stable repo
is functional, and updates-testing often includes broken stuff which could
prevent us from running the upgrade test completely. On the other hand, on
the release day, a lot of packages get pushed from updates-testing to
updates, and it might result in broken upgrades, while we had no knowledge
about it. To complicate it even further, it's a constantly moving target,
i.e. the set of packages which are "pending stable" (to be pushed to
updates when the freeze is over) can change literally every minute.
The true fix here for both cases would be a static test which would check
the installability of packages, and wouldn't allow pushing updates which
don't pass. Something similar to rpmdeplint which we used to run in
Taskotron (rpmdeplint itself had many issues, it would need to get much
improved or written differently, to be able to make it a reliable gating
test). But we don't have it and likely won't have it for a long time.
So what can we do which is easier and at least partly covers the issues?
For a) I think we need to depend on community reporting, because we can
hardly test a random combination of installed packages. But for b), we
could extend our upgrade testing matrices with two variants - one would
test with stable updates, the other would test with updates-testing
enabled. It is not perfect, because any broken update in updates-testing
can obscure other issues present ("dnf --exclude" is not always the
remedy), so we still can miss important problems. We can't force package
maintainers to unpush problematic updates just because we want to test the
rest of the repo. And even if we could, refreshing the repo takes at least
a day, so there's a very slow turnaround. However, it gives us more chance
to spot potential issues and make sure that they are reported and that they
don't get pushed stable (by giving them negative karma). Thoughts?
We can also test upgrades once the updates repo gets populated, as you
mentioned. It's pretty late to detect problems at this stage :-/ , but
better late than never, I guess. I wonder if we could use openQA for this
[1]. Adam?
[1] Which reminds me, we should make sure to run "dnf system-upgrade" with
"--best", to catch these issues.
___
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-Cloud-33-20210428.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210427.0): ID: 871505 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/871505 ID: 871512 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/871512 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
