On Sat, 2018-02-17 at 23:13 +0100, Lars Seipel wrote: > On Fri, Feb 16, 2018 at 12:14:39PM -0800, Adam Williamson wrote: > > On Fri, 2018-02-16 at 14:34 +0100, Vít Ondruch wrote: > > > I wish the compose process was more transparent. May be it is > > > just me, > > > but I don't know where to start looking when I don't get the > > > daily > > > compose report. > > > > https://kojipkgs.fedoraproject.org/compose/ > > > > All composes initially happen there. Rawhide composes happen in the > > rawhide/ subdirectory. Branched happen in the branched/ > > subdirectory. > > Each compose directory contains logs. The usual process for > > debugging > > failed composes is to look at the pungi.global.log file, which > > usually > > indicates what the failed fatal task was, get the task ID or full > > task > > URL from that log, then go to Koji and look at the actual failed > > task > > and figure out what went wrong with it. > > Thank you, Adam. That was super-helpful. > > If I'm reading those correctly, all issues are due to live images, > container images or OSTree-related stuff. The composes seem to result > in perfectly fine netinstall images and they even appear to work. > > Why do we block the whole Rawhide repo for weeks on that? We didn't used to. It was changed a couple of years ago. The idea is basically that a change which causes release-blocking images to fail to compose is probably not a change we want to publish to the repos. The most recent issue we fixed that I know of was actually in the KDE live image, which is release-blocking. qt5-qtwebengine depends on libevent, which was inadvertently soname-bumped (see devel@), so it needed a rebuild. However, it failed to build with GCC 8. We had to work with both Chromium (the issue was ultimately in Chromium - qtwebengine includes a copy of Chromium) and GCC upstreams to get that one addressed. So, ultimately what this policy "means" there is: we don't want to ship the libevent soname bump out until it's at least not stopping release blocking images from composing any more. That seems like a fairly reasonable position to me, really - is it really 'better' if we sync out a Rawhide repo which contains a broken KDE (and, incidentally, a broken Chromium)? That one should have been addressed in the 20180217.n.1 compose, though, and someone's fired a 20180217.n.2 today, so they obviously found and fixed something else. I've been out all day today so I don't know specifically what that issue was. The major improvement we could really do with is blocking problematic changes *earlier* - before they are tagged into Rawhide at all. That's something people are actively working on ATM. If we could, for instance, have blocked the inadvertent libevent soname bump, that would have saved a lot of trouble. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
