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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
