[01:03] <tedg> Hello, I need someone to delete some binaries for me.
[01:03] <tedg> I have a branch of ubuntu-app-launch which adds a dependency on libmir
[01:03] <tedg> Which means it can't build on PPC until Mir does.
[01:04] <tedg> (which sucks, but eh, can't solve that one)
[01:05] <infinity> tedg: That seems like an odd dependency for what the package claims to be...
[01:05] <tedg> infinity, It is for a test tool to run applications, it uses a Mir trusted prompt session.
[01:06] <infinity> Certainly odd for it to be required.
[01:06] <tedg> It's so they can run the applications with autopilot more easily.
[01:06] <infinity> tedg: And this can't be conditional?
[01:07] <tedg> Hmm, it probably could be.
[01:07] <tedg> Not sure it's worth it, no one is going to use it on PPC without Mir anyway...
[01:07] <tedg> I might have to learn something about cmake, which would be painful :-)
[01:08] <infinity> tedg: To be fair, u-a-l doesn't appear to have any revdeps on non-Mir arches anyway, I'm just continually annoyed with the "Mir isn't ported, so let's pretend it's not portable, and make everything else depend on it and also become unported" thing.
[01:08] <infinity> tedg: And while people keep propping up "who wants Mir on PPC anyway?" as the excuse, they keep ignoring arm64, which is kinda the future of Mir-targetting devices.
[01:08] <tedg> I'm annoyed too. We should really make Mir deal with this.
[01:09] <tedg> infinity, It built on arm64
[01:09] <tedg> Just not PPC and PPC64
[01:09] <infinity> It did?  Is that new?
[01:09]  * tedg just works here
[01:10] <infinity> Ahh, indeed, the arm64 porting happened.
[01:10] <infinity> Well, that's proof that ppc could as well. :P
[01:10] <tedg> Cool.
[01:10] <tedg> Yeah, I think it's just an effort thing.
[01:10] <tedg> Someone should put it on their backlog or sprint or rave or something.
[01:11] <infinity> tedg: Oh, and I lied, there are non-Mir-arch revedeps for libubuntu-app-launch2.  A few of them.
[01:11] <infinity> Could take a while to untangle all of that and not raise the unstallable count. :/
[01:11] <tedg> Hmm, hadn't thought about the lib results.
[01:12] <tedg> Okay, I'll figure out CMake then.
[01:12] <infinity> tedg: If you could make the libmir dep conditional on libmir-dev being installed, that would be much simpler.
[01:12] <tedg> That's going to be easier.
[01:12] <infinity> Then just arch-restrict the build-dep for now until Mir gets its act together.
[01:13] <tedg> So then I make the libmir build-deb architecture specific?
[01:13] <tedg> dep
[01:15] <infinity> tedg: Yeah, that would do the trick.
[01:15] <infinity> tedg: Make CMake DTRT depending on if the library is or isn't installed, and then make the build-dep [arch qualified] and you're set.
[01:16] <tedg> K, will do.
[01:16] <tedg> Thanks infinity!
[15:47] <slangasek> FYI the Canonical CI team is ready to deploy a new layer of testing as part of proposed-migration, which will add boot-testing of packages that are on the phone before promotion from vivid-proposed to vivid
[15:47] <slangasek> they'd like to land this today, so that if there are any problems they can be debugged before the weekend
[15:47] <slangasek> any objections here?
[15:48] <ScottK> slangasek: Will this be overridable by the release team?
[15:48] <slangasek> good question
[15:49] <slangasek> cjwatson: ^^ was there an equivalent of force-badtest for boot tests?
[15:49] <ScottK> If the answer is we can override it if needed, then no objection from me.
[15:49] <slangasek> ScottK: we could disable the tests as a class by pushing changes to britney
[15:50] <slangasek> I'm not sure it makes sense to disable it via per-package hints
[15:50] <ScottK> Depends on what we're doing when.
[15:50] <slangasek> since the test is the same across packages ("does it boot?"), I don't think we want to override a failed boot test on a per-package basis
[15:50] <ScottK> I don't think it makes any less sense than per package overrides in other cases.
[15:51] <ScottK> Depends on if the boot failure is actually related to the package.
[15:51] <ScottK> If you've got 5 relevant packages in proposed and one causes the failure, doesn't make sense to  block them all.
[15:51] <cjwatson> slangasek: Same, force-badtest
[15:52] <cjwatson> I made sure of that
[15:52] <slangasek> ok
[15:52] <ScottK> I'm fine with it then.
[15:52] <ScottK> Riddell: ^^^
[15:52] <cjwatson> Excuse me, sorry, it's force-skiptest.
[15:53] <cjwatson> force-badtest is the one that skips a single dispatched test for a causing package out of many; in this case there's only one boottest so it doesn't make sense to support force-badtest.
[15:53] <cjwatson> But force-skiptest works.
[15:53] <cjwatson> I think?  In fact the code seems to support both so I could be out of date.  Anyway this is tangential to the basic point. :-)
[15:54] <slangasek> ScottK: ah, for the case where we've root-caused the failure to a particular package but the test failures are blocking other packages and we want to let them through... check
[15:54] <slangasek> ScottK: fwiw I would be more comfortable in that case removing the broken package from vivid-proposed and re-testing, to make sure the test *actually* passes
[15:54] <slangasek> but both options are available if needed
[22:43] <ScottK> slangasek: Not that it would have affected my opinion, but how long do we expect the addition of the boot test to delay package migration when there aren't errors?
[22:44] <slangasek> ScottK: I haven't seen any benchmarks on that yet; but I know for instance that systemd already successfully passed a test: https://jenkins.qa.ubuntu.com/job/vivid-boottest-systemd/lastBuild/?
[22:45] <ScottK> OK.
[22:45] <slangasek> 14 minutes to run the whole test isn't bad, provided the system scales - which is a known pain point for CI and something they're working on this month
[22:45] <ScottK> Yeah.
[22:46] <ScottK> Thanks.
[22:46] <slangasek> however, the set of source packages included in the phone is pretty small - so I'm confident that any problems will be minor and short-lived
[22:47] <slangasek> ScottK: btw it seems that the jobs are in fact per-source package... so other packages in -proposed *won't* be entangled in the test results, further reducing the need for overrides
[22:47] <ScottK> Ah.  Good.