[02:07] <teward> Should I be highly concerned that almost all of the arm64 and armhf builders are marked as Disabled in the build farm?
[02:07] <teward> (12+ hours each for arm64 and armhf PPA queues, hence my asking...)
[02:08] <wgrant> We're working on an issue with one of our build clouds.
[02:08] <wgrant> Hopefully will be resolved soon.
[02:10] <teward> wgrant: didn't expect anyone to be alive this evening heh.  Thanks for the heads up.
[02:10] <teward> when I saw all that red, I was like "WOAH, Something blew up!" xD
[02:11] <wgrant> teward: Some of us are in Australia :)
[02:11] <teward> wgrant: ahhhhh, that explains things.  :P
[02:12] <teward> wgrant: I'm still awake because I'm busy trying to get Postfix working/patched, to get the SRU-pending patch into a Postfix build so I can mess around with it in a container, but eh.  I'm less concerned about arm64 and armhf as my arch is amd64, but meh.
[02:59] <wgrant> teward: All fixed.
[03:03] <tsimonq2> I was wondering about that too...
[03:03] <tsimonq2> Thanks a bunch wgrant!
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== JanC is now known as Guest77859
=== JanC_ is now known as JanC
[10:33] <rbasak> cjwatson: around? nacc and I have been talking about the plan to get things moving on Launchpad wrt. bug 1661600. We think we'd like to break the dependency loop by pointing the "official" branches to our imported repositories now. Do you have an opinion on this plan please? How much work would it be to do that?
[10:33] <ubot5> bug 1661600 in usd-importer "git object sharing is suboptimal in Launchpad" [High,Triaged] https://launchpad.net/bugs/1661600
[10:34] <rbasak> We'd announce to ubuntu-devel@ (or u-d-a, whichever is appropriate) that the branches are experimental and will be non-fast-forwarding (the hashes will change), but figure that as they're nothing there today (for git) it's the least worst option.
[10:35] <cjwatson> rbasak: I'm 1.5 days from going on holiday for two weeks, won't be available to help with that for some time
[10:35] <rbasak> Then we'd like to 1) widely accept and encourage automatic import whitelist additions from developers, and 2) with your permission, start ramping up to importing all packages.
[10:36] <rbasak> cjwatson: OK, no problem. Does this plan seem reasonable though?
[10:37] <cjwatson> it's not ideal but I guess it's not terrible and maybe there isn't a better option
[10:38] <rbasak> OK, thanks. Enjoy your holiday, and I'll ping you after you're back.
[10:38] <cjwatson> Maybe wgrant can help
[10:38] <cjwatson> What's the "automatic import whitelist"?
[10:39] <rbasak> We're automatically importing a (small) subset of packages at the moment, from a whitelist.
[10:39] <cjwatson> Ah right
[10:39] <cjwatson> Also do you not need per-ref ACLs before you go very much further?
[10:40] <cjwatson> rbasak: re "how much work", the answer is "some" - LP's going to need a few gaps filled in, mostly to grant some suitable permissions to some entity to set default repositories for packages
[10:40] <rbasak> If the "official" branches just symlink to our current trees, then we figured out a plan to do without them for a long time yet (we don't need them for 1.0). We'll be relying only on the fact that the set of people who can push to the repositories at all is ~usd-import-team.
[10:41] <rbasak> And the importer will take care of the rest, as the only pusher.
[10:41] <cjwatson> symlink isn't quite a thing but I know what you mean
[10:41] <rbasak> It'll harvest rich history from MPs.
[10:41] <rbasak> Yeah I should've said symlink* :)
[10:42] <cjwatson> let's say alias
[10:42] <rbasak> OK
[10:42] <cjwatson> another thing we might need to do is check for sufficient hosting space; we have a bit over a terabyte free on the relevant volume at the moment
[10:43] <cjwatson> which is hopefully fine but it'd be nice to not blow through it all at once :)
[10:43] <rbasak> Yeah we thought you might. We can manage a ramp up independently of setting up the aliases though, right?
[10:43] <cjwatson> indeed
[10:43] <rbasak> I don't have a good grasp of how much space we need. git is efficient, but as we're importing all history that still might be quite a bit.
[10:43] <cjwatson> it'd be package by package
[10:44] <rbasak> Right, so approximately the total size of the sources in the archive plus deduplicated history of those sources.
[10:44] <rbasak> (plus all sources that have been deleted and are no longer present in artful)
[10:44] <cjwatson> lp.git_repositories.setDefaultRepository(repository=foo, target='/ubuntu/+source/foo') basically, once that works
[10:46] <cjwatson> so the ramp-up would probably just be by way of setting up aliases as packages are imported
[10:46] <rbasak> You want us to do that one by one, rather than having some kind of global "all of /ubuntu/+source/* is at /~foo/.../*"?
[10:47] <cjwatson> Yes.
[10:47] <rbasak> OK, np. It'd be trivial for us to have the importer make the API call. I just wasn't expecting it.
[10:48] <rbasak> Or perhaps we should make the call manually as we ramp up. Either way, it is trivial.
[10:48] <cjwatson> Whether a repository is the default for its target is a flag on the repository
[10:48] <cjwatson> In database terms
[10:48] <rbasak> OK
[10:48] <cjwatson> So it couldn't be done as a pattern-match without significant reworking
[15:12] <nacc> rbasak: want to file a bug (or add a task for the importer if there is already a lp bug for the above)?
[15:41] <teward> wgrant: thanks.
[15:41] <teward> (sorry, slow reply)
=== JanC_ is now known as JanC