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? V. > 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
