On 03/01/2018 11:52 AM, Kevin Kofler wrote: > Vít Ondruch wrote: >> Speaking of that, it seems that the Rawhide compose failed yesterday due >> to some KDE/QT soname bump: > [actually a typo in a Requires, as was already pointed out] >> >> 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 > > Well, the real issue is that the entire Rawhide compose fails just because > one release-blocking deliverable failed to compose. In this case, it was the > KDE Spin, but it has been happening with any other release-blocking > deliverable, e.g., Atomic ostree composes. FYI: atomic ostree composes are not release blocking so that is not why a compose will fail. > > Why can we not just deliver the parts that succeeded and keep the last > working version of the deliverables that failed to compose this time? In > other words, why can we not just upload the 20180228 compose and keep the > 20180227 or whatever KDE ISO that last built? Why does it have to be all or > nothing? > > 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
