[06:42] Eickmeyer: it isn't stuck but it is a bit short on systems atm [06:42] plenty of systems are disabled [06:43] probably fixing the broken autopkgtest image https://lists.ubuntu.com/archives/ubuntu-devel/2020-March/040939.html [06:44] but in addition for the last few minutes the rest seems to be stuck in cleaning which sometimes happens [06:44] It might resolve on its own as usual, but if anyone is around to give to give them a bump that would be even better [06:44] cjwatson: wgrant: ^^ ? [06:44] Hm, what's this about autopkgtest? [06:45] wgrant: o/ [06:45] Launchpad and autopkgtest aren't particularly related, except that they run on some of the same clouds. [06:45] wgrant: just the builders being mostly disabled and the others seem to not get out of "cleaning" state [06:45] the magic link here is that cjwatson usually "knows what to do" and I'd expect to find him here [06:45] I have no other reason to use this chan for that question [06:46] well and that I thought I might reply to Eickmeyer who asked here as well [06:46] This is the correct channel for Launchpad issues. [06:46] But autopkgtest isn't related to Launchpad. [06:46] That's an Ubuntu service; #ubuntu-devel or #ubuntu-release are more appropriate points of contact. [06:47] hmm, my second guess would have been #IS* but you are right it is not an internal but a canonical service [06:47] Canonical IS do not maintain Ubuntu's autopkgtest service. [06:48] Anyway, I'm investigating the Launchpad build farm issues. But this isn't the right place to discuss services run by Ubuntu, such as autopkgtest. [09:08] cpaelzer: cjwatson uniformly redirects you to somebody else if you ask him about autopkgtest :-) [09:08] like, every time [09:08] and I do not know what to do about autopkgtest issues other than redirecting you [09:09] Constant dripping wears away the stone :-) [09:09] it really was about builders being stuck [09:10] not about anything "inside" autoblktests [09:10] wow - we might some day have aotoblktests for I/O but obviously I meant autopkgtests [09:10] that wasn't even close on the keyboard to mistype it that way ... [09:11] Well, more precisely about the system that resets builder VMs being stuck [09:11] agreed [09:36] morning - I foobared a new project setup this morning - is it possible to change its LP name - https://launchpad.net/trilio-data-mover [09:36] trilio-data-mover -> charm-trilio-data-mover [09:36] ? [09:41] jamespage: done [09:41] cjwatson: thankyou! [14:33] which team can set a distro's status (e.g. freezing the archive) and create new series? assuming it's the same role that can do both [14:33] is it the maintainer? i.e. ~techboard for Ubuntu [14:44] Laney: Exactly [14:45] (~ubuntu-drivers can create series too, I think. But ~techboard can do it all) [14:54] cpaelzer: No, I was just falling victim to pkgstripfiles being molasses-slow. Perhaps even glacial slow. I have yet to come up with the correct slow analogy. [15:09] hehe [15:09] Eickmeyer[m]: was it the lock loop that sometimes happens - or just standing at that lein for a loooong time? [15:10] cpaelzer: It was the lock loop. Easily reproducable if I update ubuntustudio-look in the archive. [15:11] Like, every time I updated it would take an hour to build, whereas it would take < 1min locally. [15:11] My computer is cool, but it's not THAT cool. [15:13] It should reproduce locally if you install pkgbinarymangler in the chroot. [15:13] This is a package that implements various bits of Ubuntu policy for builds. === epod is now known as luk3yx [15:13] Well, I could try that, but not sure it's worth it at this point. [15:13] But, is that a bug? [15:13] Wouldn't be too surprising for it to have some race issues. [15:14] We could debate semantics of what counts as a bug, but it doesn't sound like terribly desirable behaviour as it stands. [15:14] That's what I was thinking. It looked like some sort of race condition. [15:14] It's a long time since I looked at it though, and it's owned by Ubuntu rather than by Launchpad. [15:14] Right, that makes sense. [16:07] cjwatson, hey, thanks for reviewing/approving my launchpad change :) [16:07] I got a buildbot failure email, I guess that's following that mp approval [16:07] http://lpbuildbot.canonical.com/builders/lp-devel-xenial/builds/1099 ... is there anything I need to do about it? [16:11] seb128: Our test suite is sadly not 100% reliable. Not your problem in this case - I've retried the test [16:11] cjwatson, thanks! [16:12] (It's close, but with over 20000 tests it doesn't take much to trip it ...) [16:12] Thanks for the MP :) [16:33] cjwatson: does buildd-manager need a poke? === cjwatson changed the topic of #launchpad to: Help contact: SpecialK|Canon | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support and spam reporting: https://answers.launchpad.net/launchpad [16:44] * cjwatson moves the help contact to the start of the topic so that people are more likely to notice it [16:44] that said; requested a bounce [16:44] ohhh. sorry [16:50] Back up now, and I've filed https://bugs.launchpad.net/launchpad/+bug/1866868 [16:50] Ubuntu bug 1866868 in Launchpad itself "buildd-manager frequently gets stuck and stops gathering files from builders" [Critical,Triaged] [16:51] great :) [16:52] * RikMills subscribes [16:53] But yeah, we're trying to move a bit more towards a help contact system rather than it always being "ask Colin or William" [16:54] Which is less appropriate now that we have more people on the team