Vít Ondruch wrote on 03/01/2018 06:44 PM:
Dne 1.3.2018 v 03:19 Kevin Kofler napsal(a):
Fabio Valentini wrote:
AFAICT, those "broken deps in rawhide" mails are only sent if there is a
compose, and during the past weeks, there have been few of those ... so
breakage is sometimes allowed to sit unnoticed (and grow increasingly
worse) for very long.
Isn't that the real issue to fix? Failed Rawhide composes used to be a rare
event.
Speaking of that, it seems that the Rawhide compose failed yesterday due
to some KDE/QT soname bump:
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/global/pungi.global.log
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/i386-x86_64/livemedia-Spins-KDE.i386-x86_64.log
https://kojipkgs.fedoraproject.org//work/tasks/8910/25368910/root.log
Were these announced? Are they handled? Why aren't these done in sidetag?
No, the above root.log does not mean some KDE/QT soname bump. You must
look at dnf complaint from the bottom to the top:
1. nothing provides gstreamer1-plugins-good5{?_isa} needed by phonon-qt5-backend-gstreamer-2:4.9.0-7.fc29.x86_64
Apparently 5{?_isa} is typo (5 should be %, perhaps)
2. So package phonon-qt5-4.10.0-1.fc29.x86_64 requires phonon-qt5-backend(x86-64) >= 4.7, but
(as phonon-qt5-backend(x86-64) is provided by phonon-qt5-backend-gstreamer but
phonon-qt5-backend-gstreamer cannot be installed because of gstreamer1-plugins-good typo)
none of the providers can be installed
3. package kf5-knotifyconfig-5.43.0-2.fc28.x86_64 requires libphonon4qt5.so.4()(64bit), but
(as libphonon4qt5.so.4 is provided by phonon-qt5-4.10.0-1.fc29.x86_64 but phonon-qt5
cannot be installed because ..... .... .....) none of the providers can be installed
4. is the same, from the top to bottom.
V.
Regards,
Mamoru
Now we have both Rawhide and Branched composes broken for days at a
time, e.g., currently since February 20. This is just not acceptable.
Something needs to be done to make the compose process more robust, e.g.:
* running createrepo on a stable release, so that we do not have to be able
to init a chroot of the target system to compose a repository. A broken
dependency, even in systemd or rpm, should NEVER be a reason for the
repository to fail to compose.
* publishing individual deliverables one at a time, i.e.:
1. compose the repositories,
2. sync the repositories out to the mirrors,
3. build the images (atomic ostrees, live images etc.) one at a time,
4. sync those images that succeeded out to the mirrors, keep the old
versions of the other ones (the matching SRPMs are in Koji anyway, so
it does not matter if the SRPMs in the tree don't match)
etc.
Right now, e.g., we have a known broken GCC (8.0.1-0.14) in the Rawhide and
Branched trees (which miscompiles the Chromium/QtWebEngine build tool GN on
x86_64), the fix (8.0.1-0.16) has already been in the right Koji tags for
days, but any third-party repository (RPM Fusion, Copr, etc.) will still get
the broken GCC. This is not acceptable.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
