| === Logan is now known as FelipeJuanPabloA | ||
| === FelipeJuanPabloA is now known as Logan | ||
| 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:03 |
| tedg | (which sucks, but eh, can't solve that one) | 01:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 | |
| 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:10 |
| 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:11 |
| 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:12 |
| tedg | So then I make the libmir build-deb architecture specific? | 01:13 |
| tedg | dep | 01:13 |
| 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:15 |
| tedg | K, will do. | 01:16 |
| tedg | Thanks infinity! | 01:16 |
| === 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 | ||
| 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:47 |
| ScottK | slangasek: Will this be overridable by the release team? | 15:48 |
| slangasek | good question | 15:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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 | 15:54 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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. | 22:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!