[00:02] <wgrant> Ah, right.
[00:02] <wgrant> Missed that bit.
[00:04] <wgrant> bdmurray: Hm, so it only fails in zesty?
[00:05] <bdmurray> wgrant: Let me check, there is actually a bug in gdb where generate-core doesn't work in an armhf chroot on arm64
[00:06] <bdmurray> Its sigill on yakkety too
[00:07] <bdmurray> SIGSEGV on xenial though https://launchpadlibrarian.net/304016495/buildlog_ubuntu-xenial-armhf.apport-test-crashes_0.20170126-1~69~ubuntu16.04.1_BUILDING.txt.gz
[00:24] <wgrant> bdmurray: Let me just root a buildd to see if I can repro it.
[00:24] <wgrant> The main difference is that rugby's an HWE 4.4, while LP buildds are a real 4.4 with a tiny patch of mine.
[00:24] <wgrant> The patch can't really change anything, but the non-HWEness might.
[00:25] <bdmurray> wgrant: Okay, thanks for looking at it
=== ahoneybun_ is now known as ahoneybun
=== salem_ is now known as _salem
[05:11] <wgrant> bdmurray: Uh well so
[05:11] <wgrant> bdmurray: "gdb cat", "run" on a buildd is enough to get a SIGILL.
[05:11] <wgrant> cat on its own is fine, as you might imagine.
[05:35] <wgrant> bdmurray: This should be reproducible in a zesty armhf chroot in a stock xenial arm64 KVM guest. Happens even without my custom kernel.
[05:35] <wgrant> I'll try to poke a little further, but this isn't an LP issue and I think you should be able to reproduce it on a local VM.
=== pbek_ is now known as pbek
=== _salem is now known as salem_
[12:02] <rbasak> Could someone please take a look at https://answers.launchpad.net/launchpad/+question/426641? I don't mind it taking a while but it's frustrating having to keep reopening it.
[12:02] <rbasak> (it's about the git importer and ~ubuntu-branches)
[12:35]  * cjwatson answers
[12:43] <rbasak> Thanks!
[12:43]  * rbasak reads
[12:51] <rbasak> cjwatson: so IIUC, we'd have a separate importer Launchpad account, say ~ubuntu-git-importer, and lp:ubuntu/+source/package could be made to point to lp:~ubuntu-git-importer/ubuntu/+source/package? If so, then we can create and use ~ubuntu-git-importer now, right, and add the magic later without having to rearrange things?
[12:52] <cjwatson> Indeed
[12:53] <rbasak> That unblocks us nicely for now then. Thanks!
[12:54] <cjwatson> The magic will be important for either possible path, but in very different ways: in one, it's required for push and storage efficiency; in the other, it'd likely be required for the ability to set ACLs associated with upload permissions.
[12:55] <rbasak> Ah - we won't get that storage efficiency right now? If the importer pushes to lp:~ubuntu-git-importer/ubuntu/+source/package, and I push to lp:~racb/ubuntu/+source/package, they won't share storage right now?
[12:57] <cjwatson> No, they won't.
[12:58] <cjwatson> We don't have an explicit fork action right now; object sharing works by sharing with default repositories.
[12:59] <cjwatson> https://git.launchpad.net/launchpad/tree/lib/lp/code/xmlrpc/git.py#n245 has the logic
[12:59] <rbasak> I see, OK. We're already running test automatic imports for a set of packages (873) at the moment. Will there be an issue if we start ramping this up?
[12:59] <rbasak> That won't affect duplication much, I suppose, since we wouldn't get duplication until uploaders really start pushing.
[13:00] <cjwatson> Right, it's not an issue for the importer pushing stuff, but it would be an issue once we start seeing more uploaders pushing their clones.
[13:01] <rbasak> Understood. So should we just progress as we are for now, and as we ramp up, we will address it then?
[13:01] <cjwatson> I think we need to sort this out soon; there will be some lead time in working it all out.
[13:01] <cjwatson> And there isn't a particularly reasonable way to fix object sharing on existing repositories.
[13:02] <rbasak> OK
[13:02] <cjwatson> It's not a hard blocker, but it shouldn't be delayed much.
[13:02] <rbasak> So not fixing object sharing will cause future issues, so we should address that now.
[13:02] <cjwatson> The alternative would be figuring out and implementing an explicit fork action.
[13:03] <rbasak> For the ACL side of things, that's OK to leave for now, right?
[13:03] <rbasak> I'll file a bug for the object sharing case.
[13:03] <cjwatson> (In which case LP would have explicit knowledge about which repository it needs to share with, and doesn't need to guess based on defaults - so that would be a way to sidestep the question of blessing lp:ubuntu/+source/package if we felt we needed to sidestep that)
[13:04] <cjwatson> Certainly file a bug, but like I say I think it will need external contribution if it's to be done in the next couple of months
[13:04] <rbasak> Understood. I'll add a task against our project too.
[13:10] <rbasak> I've filed bug 1661600. Nice number!
[13:10] <ubot5> bug 1661600 in usd-importer "git object sharing is suboptimal in Launchpad" [High,Triaged] https://launchpad.net/bugs/1661600
=== RD is now known as Guest27562
[20:53] <clivejo> Is there any way to search for a git repo under Launchpad?
[20:54] <clivejo> We have almost 400 repo's - https://code.launchpad.net/~kubuntu-packagers/+git and need a way to search them?
=== salem_ is now known as _salem