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-2018022...
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-2018022...
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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org