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