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.

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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to