[08:15] <jamespage> ^^ that's only a minimal diff in the upstream codebase despite the version bump - and is needed for all of the rc's for openstack packages we're working in in debian and ubuntu
[11:03] <Laney> Mirv: What investigation of these unrelated failing tests did you do before deciding to skip them?
[11:06] <Mirv> Laney: they were OpenGL tests that failed on armhf only (and ran under software emulation on the builder under xvfb). if you want I could file a bug about making the skipping only on armhf.
[11:07] <Mirv> but since the patch touched networking and it's not too long since the last qtbase rebuild, the appearing failure is most likely due to changes in that software OpenGL on armhf
[11:07] <Laney> you consider it acceptable for this to be broken?
[11:07] <Laney> did you talk to tjaalton?
[11:08] <Mirv> Laney: yes, the OpenGL software emulation on armhf is hardly the most tested code path of Qt / Mesa and Qt more or less assumes hw acceleration and modern drivers (but I try to run most OpenGL tests anyhow)
[11:11] <Mirv> qtbase tests are a bit hard nut for our headless software rendering builders, that's why the original QA enablement resulted in a huge patch and Debian doesn't run the tests at all
[11:15] <Laney> It's a bit odd isn't it
[11:15] <Mirv> no pinging of the other timo before the above
[11:15] <Laney> We run the tests as long as they work - and if they don't, then we disable them
[11:15] <tjaalton> pong :)
[11:16] <Mirv> Laney: it's useful to run as many tests as possible, still a big amount of them, to catch clear regressions. but problematic tests with a code path that is not used in real life doesn't bring that much value.
[12:18] <flocculant> infinity: just a thought re your milestone words - if flavours could start and stop builds - then we'd keep the goodness of having something people can test - but lose the 'blessed build' stigma
[15:16] <jamespage> slangasek, hey - would you have time to review the dpdk package in the NEW queue for wily?
[15:16] <jamespage> I also need to upload a cut-down openvswitch-switch-dpdk package to support this objective for wily, but I'm a bit blocked right now
[16:41] <slangasek> jamespage: on vacation this week and driving much of today; I'll see if I can give it any useful review but stgraber is probably your best bet after all
[16:42] <Laney> stgraber: someone: second opinion on doing https://code.launchpad.net/~fginther/britney/disable-boottest/+merge/272442 ?
[16:47] <stgraber> Laney: any ETA on the proper fix (getting network-manager fixed)?
[16:51] <Laney> stgraber: awe_ apparently missed the bug assignment so is only working on it starting now-ish - which means probably not incredibly soon
[16:53] <stgraber> so stupid question, but why didn't boottest find that issue and cause network-manager to be held to begin with?
[16:54] <stgraber> in theory we could simply have removed the broken network-manager from proposed and be done with this
[16:55] <Laney> 25/09 17:49:20 <fginther> There have been no recent boottest passes for network manager, but it's unlikely that boottest would have caught the problem as the bug prevents networking, not booting.
[16:56] <stgraber> ok and what about reverting network-manager in the archive what's the problem with that?
[16:56] <Laney> And then the boottests got pinned to an earlier image before this NM...
[16:56] <Laney> which has now evidently expired
[16:57] <Laney> The release in question seems to be 0.9.10 -> 1.0...
[17:05] <stgraber> ok, fine, let's merge that then
[17:06] <Laney> stgraber: I commented - slangasek said in #ubuntu-ci-eng that a product team person should sign off on it
[17:06] <Laney> I don't actually know who that is apart from pmcgowan who is apparently not here today
[17:08] <Laney> fginther: any clue?
[17:11] <Laney> stgraber: Maybe JFDI it in a little while if nobody turns up
[17:11] <Laney> I've got to EOW now, hopefully you can handle merging it
[17:11] <Laney> see you
[17:11] <fginther> Laney, looking
[17:11] <fginther> Laney, later
[17:12] <fginther> Laney, stgraber, kgunn can give a +1 on this I believe
[17:13] <fginther> in pmcgowan's awayness
[17:21] <slangasek> stgraber, fginther: if the boottests are all now failing because networking is broken, why wouldn't the boottest have caught the failing networking?
[17:24] <infinity> flocculant: Define "start and stop".  You mean if you could disable the crontab entry?
[17:26] <infinity> slangasek: Many packages are unboottestable because "mark r/w and run apt" breaks system images miserably in some cases.  Not sure if NM falls in that group, but it might.  We certainly have always had a fairly nontrivially large set of packages where we have to go to the uploader and say "so, did you test this and can you sign off on it, cause the infra can't tell me anything useful".
[17:27] <slangasek> infinity: that is not what fginther was asserting
[17:27] <infinity> slangasek: Which, of course, entirely defeats the point of automated testing keeping the uploader honest.
[17:27] <slangasek> he asserted that this regression would not have been caught because it didn't break the boot
[17:27] <infinity> slangasek: Oh, that may well be the case for NM specifically.
[17:28] <infinity> slangasek: Though it doesn't make a lot of sense that if it doesn't break the boot, it then breaks the boot?
[17:28]  * infinity shrugs.
[17:28] <infinity> slangasek: Honestly, I see little point in running test infra for people who don't treat breakages in that infra as stop the line events.
[17:44] <cyphermox> so what's this NM issue?
[18:05] <fginther> cyphermox, https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1496434
[18:05] <cyphermox> fginther: yep, I'm aware
[18:05] <cyphermox> Tony said he was working on it.
[18:07] <flocculant> infinity: I guess so. Imagine someone from 'flavour release team' saying stop building my flavour - we're doing a few days testing foo and bar and what to keep that image, when done - start building dailies again
[18:07] <flocculant> so - no-one would get alphas or betas as such
[18:08] <flocculant> then close to the end - a global one done by *you*
[18:08] <infinity> flocculant: Yeah, letting you halt your dailies isn't an unreasonable request.  We could do it if/when we stop building from static cron entries (which is on a TODO, somewhere), but not really doable right now without you just poking someone who has a shell on that computer.
[18:08] <flocculant> s/what/want
[18:09] <flocculant> right - so was just a thought following on from your 'blessed image' last night (for me)
[18:09] <flocculant> there would just be one then - at the end
[18:11] <flocculant> be one global that is - RC or so
[18:25] <kgunn> Laney: fginther added approval in lieu of pat
[18:26] <fginther> stgraber, ^ for https://code.launchpad.net/~fginther/britney/disable-boottest/+merge/272442
[18:26] <fginther> kgunn, thanks
[18:29] <stgraber> merged
[19:43] <wxl> infinity: are the cron jobs for dailies back on?