Automatic update for dnf5-5.0.15-1.fc39.
* Thu Jun 29 2023 Packit <hello@packit.dev> - 5.0.15-1
- Add `module enable` subcommand
- Add `--repofrompath` option
- Add `--forcearch` option to multiple commands
- Add `reinstall --allowerasing` option
- Add `repoquery --sourcerpm` option
- Add `repoquery --srpm` option
- Add `chacheonly` configuration option
- Add `--cacheonly` option
- Add `--refresh` option
- Change default value for `best` configuration to true
- Change default value for `allow_vendor_change` configuration to false
- changelog: Fix behavior of `--since` option
- builddep: Fix handling BuildRequires in spec files
- swig: Return None for unset options in Python
- Verify transaction PGP signatures automatically
- Fix checking whether updateinfo metadata are required
- Fix handling empty epoch when comparing nevra
- Fix building with upcoming fmt-10 library
- Rename namespace, includes and directories from libdnf to libdnf5
- Provide /var/cache/libdnf5 instead of /var/cache/libdnf (RhBug:2216849)
* Wed Jun 28 2023 Vitaly Zaitsev <vitaly@easycoding.org> - 5.0.14-2
- Rebuilt due to fmt 10 update.
- Added upstream patches with fmt 10 build fixes.
Please login to add feedback.
This update was automatically created
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
Tests seem to fail on dnf commands that are still missing. Should still get this in to fix the zuul ci
The openQA tests are not failing on missing commands. They are failing because dnf is not updating a package when it should.
The openQA test that is failing installs a dummy low-versioned acpica-tools package from this repo, then does
dnf -y --disablerepo=openqa-testrepo* --disablerepo=updates-testing update acpica-tools, and expects it to update to the 'real' version of acpica-tools from the repos (which will always be higher versioned).Without this dnf5 update, the same test passes. See https://openqa.fedoraproject.org/tests/1996138#next_previous - note that other runs of the same test on other updates both before and after this update are passing. The test is only failing on this update.
There's a tarball of
/var/logat https://openqa.fedoraproject.org/tests/1996138/file/base_update_cli-var_log.tar.gz , butdnf5.logis not very enlightening. I think the relevant transaction is the one at 2023-06-29T10:22:33, but that one just peters out somehow:we suddenly jump to another transaction 24 seconds later (part of the post-fail log dump process). We never register an 'end' to the transaction that should have updated acpica-tools but didn't, and it doesn't seem to log anything enlightening.
Oh, indeed. Didn't know how to read the openqa tests. I was referring to the testing-farm tests. One thing I notice in previous runs is that it was pulling from f38 instead of rawhide
Hello, sorry for maybe a dumb question, but I was looking into results of the previous bodhi update of dnf5-5.0.14 and there for the same testing module a different package was used ("pandoc-common"): https://openqa.fedoraproject.org/tests/1984487#step/base_update_cli/14. There the test has passed. Is it because of a change in test scenarios?
But I guess the cause of not upgrading the package in this case could be the change of the default
bestoption value toTruewhich was not used before in Fedora.Commit: https://github.com/rpm-software-management/dnf5/commit/42fd5777ec91d82f376af2bfb158e9b447385d3d. Discussion: https://github.com/rpm-software-management/dnf5/discussions/564.
I changed the test from using pandoc-common to using acpica-tools recently because I wanted to run the test on ELN, and pandoc-common isn't in ELN. Finding a good sacrificial package for this test is actually quite hard now - it has to not be in the Fedora critical path so it won't be tested itself (when we run a related test on the sacrificial package itself it fails, because PackageKit doesn't like updating unsigned packages, as best as I can tell), be a very 'stable' package with minimal dependencies to make it unlikely to fail due to a bug with the 'real' package, and be in both Fedora and ELN. There aren't a whole load of those.
One thing about acpica-tools which I didn't notice when I switched to it, it's an arch package, not noarch. The dummy package is noarch. So when we update, we're switching arches. That should work, and it does work with other versions of dnf, but it's a wrinkle.
I'll try reproducing this manually and see what happens...
oh, forgot to mention: the switch itself is not the cause of the problem, though. I switched several days ago, so there've been several days of the test successfully passing with the previous build of dnf5 and acpica-tools.
I can reproduce this in a mock chroot, and it doesn't seem to be 'best' that's the problem:
I'm not sure what I can run to get more info out of dnf about why it's just refusing to see an update here.
I also tested it with pandoc-common, with the same result:
so it doesn't appear to be about acpica-tools vs. pandoc-common, or some issue with switching arches when updating a package.
However, it seems to work with a 'real' package. I downgraded bash from
5.2.15-3.fc38.x86_64to5.2.15-2.fc38.x86_64, randnf update bash, and it worked. (We can't do the test this way in openQA because it's never safe to assume a downgrade for any specific package is either available or installable).If I run the update with
--debugsolver, I get a zero-lengthsolver.resultand this assolver.result:Sorry, that should have said
...and this as testcase.t.Hum, this is interesting. If I start with the current
pandoc-commoninstalled and try to use dnf5 to downgrade to the mock package, it fails like this:if I have it downgrade from 2.19.2-21.fc39 to 2.19.20-20.fc39 (the previous 'real' build), it succeeds. But I can't see why it would try to install both packages. There is no dependency that would cause this - dnf will happily remove pandoc-common entirely. But it refuses to downgrade from a 'real' version of the package to our 'dummy' version (that is, https://fedorapeople.org/groups/qa/openqa-repos/openqa-testrepo-1/pandoc-common-1-1.noarch.rpm ).
This update has been obsoleted by dnf5-5.0.15-2.fc39.
Could it be the missing repo-release in the
pandoc-common-1-1.noarch. Fedora review and rpminspect/rpmlint do enforce specifying repo-release. Although that might be a bit tricky with with release upgrades.About sacrificial packages, why not have a custom repo with both base and update packages? It might not catch problems like these, but at least it would be a reproducible environment.
We do have one of those, but we don't use it for this test because we want it to be as close as possible to a 'real' test. We want to catch, e.g., problems with the default repo definitions.
I don't see why dnf should care whether a package has a dist tag or not, and indeed, some Fedora packages do not - at least
fedora-releasedoes not have one.So, as the obvious followup to the above, I tested downgrading and upgrading fedora-release, but that works:
Let's move further discussion to https://bodhi.fedoraproject.org/updates/FEDORA-2023-6ddca9885a - I did a bump/rebuild for the fmt soname bump that landed in Rawhide now.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.