=== Logan is now known as FelipeJuanPabloA === FelipeJuanPabloA is now known as Logan [01:03] Hello, I need someone to delete some binaries for me. [01:03] I have a branch of ubuntu-app-launch which adds a dependency on libmir [01:03] Which means it can't build on PPC until Mir does. [01:04] (which sucks, but eh, can't solve that one) [01:05] tedg: That seems like an odd dependency for what the package claims to be... [01:05] infinity, It is for a test tool to run applications, it uses a Mir trusted prompt session. [01:06] Certainly odd for it to be required. [01:06] It's so they can run the applications with autopilot more easily. [01:06] tedg: And this can't be conditional? [01:07] Hmm, it probably could be. [01:07] Not sure it's worth it, no one is going to use it on PPC without Mir anyway... [01:07] I might have to learn something about cmake, which would be painful :-) [01:08] 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] 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] I'm annoyed too. We should really make Mir deal with this. [01:09] infinity, It built on arm64 [01:09] Just not PPC and PPC64 [01:09] It did? Is that new? [01:09] * tedg just works here [01:10] Ahh, indeed, the arm64 porting happened. [01:10] Well, that's proof that ppc could as well. :P [01:10] Cool. [01:10] Yeah, I think it's just an effort thing. [01:10] Someone should put it on their backlog or sprint or rave or something. [01:11] tedg: Oh, and I lied, there are non-Mir-arch revedeps for libubuntu-app-launch2. A few of them. [01:11] Could take a while to untangle all of that and not raise the unstallable count. :/ [01:11] Hmm, hadn't thought about the lib results. [01:12] Okay, I'll figure out CMake then. [01:12] tedg: If you could make the libmir dep conditional on libmir-dev being installed, that would be much simpler. [01:12] That's going to be easier. [01:12] Then just arch-restrict the build-dep for now until Mir gets its act together. [01:13] So then I make the libmir build-deb architecture specific? [01:13] dep [01:15] tedg: Yeah, that would do the trick. [01:15] 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] K, will do. [01:16] Thanks infinity! === rcj is now known as Guest82790 === Guest82790 is now known as rcj === rcj is now known as Guest563 === doko__ is now known as doko === Guest563 is now known as rcj === henrix_ is now known as henrix [15:47] 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] they'd like to land this today, so that if there are any problems they can be debugged before the weekend [15:47] any objections here? [15:48] slangasek: Will this be overridable by the release team? [15:48] good question [15:49] cjwatson: ^^ was there an equivalent of force-badtest for boot tests? [15:49] If the answer is we can override it if needed, then no objection from me. [15:49] ScottK: we could disable the tests as a class by pushing changes to britney [15:50] I'm not sure it makes sense to disable it via per-package hints [15:50] Depends on what we're doing when. [15:50] 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] I don't think it makes any less sense than per package overrides in other cases. [15:51] Depends on if the boot failure is actually related to the package. [15:51] If you've got 5 relevant packages in proposed and one causes the failure, doesn't make sense to block them all. [15:51] slangasek: Same, force-badtest [15:52] I made sure of that [15:52] ok [15:52] I'm fine with it then. [15:52] Riddell: ^^^ [15:52] Excuse me, sorry, it's force-skiptest. [15:53] 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] But force-skiptest works. [15:53] 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] 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] 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] but both options are available if needed [22:43] 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] 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] OK. [22:45] 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] Yeah. [22:46] Thanks. [22:46] 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] 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] Ah. Good.