Hi,
So today I found out that I caused a serious problem for Fedora 27 users, I did an innocent looking soundtouch security update, but I did not realize that F27 was at an older version and this implied a soname build.
In the past we would get a mail about updates which broken dependencies, but apparently this no longer happens.
IMHO problems with updates which can be detected automatically and with 100% reliability like these should block the update from going to stable, or at a minimum require me to click to a scary looking warning dialog in the updates web UI, that I'm pushing something which is known to be broken.
It seems that ATM there is no sort of dependency check running for updates at all, which is really bad IMHO. I double checked, it is not there in the "Automated Tests" tab in bodhi, nor did I get any mails from notifications@fedoraproject.org about a dep check failing either.
Note I'm not trying to shift blame here, the soundtouch problem is entirely my fault. But as this shows, mistakes happen and this one really should have been caught by our tooling/processes.
Regards,
Hans
@dperpeet is this something CI can help with?
well, as far as I can remember, there has never ever been a broken deps report for stable releases, unless it was manually run by someone. There is a rpmdep check in the taskotron checks, as well as a abi change test.
I assume we are talking about https://bodhi.fedoraproject.org/updates/FEDORA-2018-4197fff086 ?
I am very curious why the tests didn't catch this...
There is a abi change test: https://taskotron.fedoraproject.org/artifacts/all/043dcefe-8086-11e8-85cc-525400fc9f92/tests.yml/soundtouch-2.0.0-3.fc27.log
ABI changes between build soundtouch-2.0.0-3.fc27 and its latest stable build ================================================================================ This file contains possible ABI changes which have occurred due to this package update against latest stable build available in koji for the given Fedora release. If you want to filter out these kind of ABI changes in the future, you can add a proper .abignore file to this package. To know more about how to write one, please look at the wiki page https://fedoraproject.org/wiki/Taskotron/Tasks/dist.abicheck#filtering . On x86_64 architecture ************************* * No ABI change between: soundtouch-1.9.2-6.fc27.x86_64.rpm soundtouch-2.0.0-3.fc27.x86_64.rpm ABI comparison took 0.34 second(s). * No ABI change between: soundtouch-devel-1.9.2-6.fc27.x86_64.rpm soundtouch-devel-2.0.0-3.fc27.x86_64.rpm ABI comparison took 0.30 second(s). * No ABI change between: soundtouch-debugsource-1.9.2-6.fc27.x86_64.rpm soundtouch-debugsource-2.0.0-3.fc27.x86_64.rpm ABI comparison took 0.36 second(s).
and a dependency check: https://taskotron.fedoraproject.org/artifacts/all/e2e888e0-87db-11e8-9be3-525400fc9f92/tests.yml/itemlogs/soundtouch-2.0.0-3.fc27.x86_64.log
results: - arch: x86_64 checkname: dist.rpmdeplint item: soundtouch-2.0.0-3.fc27 outcome: PASSED scenario: x86_64 type: koji_build
So, something is wacky here. @kparal and/or @adamw any ideas why these tests passed here?
I fired up my F27 VM. This is the dependency error:
Problem: package gstreamer1-plugins-bad-free-1.12.4-1.fc27.x86_64 requires libSoundTouch.so.1()(64bit), but none of the providers can be installed - cannot install both soundtouch-2.0.0-3.fc27.x86_64 and soundtouch-1.9.2-6.fc27.x86_64 - cannot install both soundtouch-1.9.2-6.fc27.x86_64 and soundtouch-2.0.0-3.fc27.x86_64 - cannot install the best update candidate for package soundtouch-1.9.2-6.fc27.x86_64 - cannot install the best update candidate for package gstreamer1-plugins-bad-free-1.12.4-1.fc27.x86_64
This does not remove any packages when running dnf update or using gnome-software. dnf shows this by default:
dnf update
gnome-software
dnf
Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): soundtouch x86_64 2.0.0-3.fc27 updates 72 k
Only if you use --best --allowerasing, then it erases a lot of packages. I would be interested to know how this can happen to anyone by accident (is there a use case I'm missing?).
--best --allowerasing
I believe the rpmdeplint test didn't catch this, because it currently only runs rpmdeplint check-sat. And this RPM is installable, it's just incompatible with a lots of RPMs that people have on their system by default. If we also ran rpmdeplint check-repoclosure, it should catch this (IIUIC), but we haven't implemented that yet (here's the ticket for it).
rpmdeplint
rpmdeplint check-sat
rpmdeplint check-repoclosure
Abicheck should have caught this, I think. @dodji, can you please look into why it hasn't?
@jwrdegoede do you have a proposal for Fedora to decide on?
@till, no I just wanted to bring this issue to FESco's attention.
Metadata Update from @psabata: - Issue tagged with: meeting
At the meeting today we decided to close this issue. Thanks for bringing it to us. If you believe there's something to investigate and/or fix, file it with Fedora QA.
Metadata Update from @psabata: - Issue untagged with: meeting - Issue close_status updated to: Invalid - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.