| wgrant | Ah, right. | 00:02 |
|---|---|---|
| wgrant | Missed that bit. | 00:02 |
| wgrant | bdmurray: Hm, so it only fails in zesty? | 00:04 |
| 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:05 |
| bdmurray | Its sigill on yakkety too | 00:06 |
| 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:07 |
| 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:24 |
| bdmurray | wgrant: Okay, thanks for looking at it | 00:25 |
| === ahoneybun_ is now known as ahoneybun | ||
| === salem_ is now known as _salem | ||
| 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:11 |
| 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. | 05:35 |
| === pbek_ is now known as pbek | ||
| === _salem is now known as salem_ | ||
| 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:02 |
| * cjwatson answers | 12:35 | |
| rbasak | Thanks! | 12:43 |
| * rbasak reads | 12:43 | |
| 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:51 |
| cjwatson | Indeed | 12:52 |
| rbasak | That unblocks us nicely for now then. Thanks! | 12:53 |
| 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:54 |
| 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:55 |
| cjwatson | No, they won't. | 12:57 |
| cjwatson | We don't have an explicit fork action right now; object sharing works by sharing with default repositories. | 12:58 |
| 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. | 12:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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 | 13:10 |
| === RD is now known as Guest27562 | ||
| clivejo | Is there any way to search for a git repo under Launchpad? | 20:53 |
| clivejo | We have almost 400 repo's - https://code.launchpad.net/~kubuntu-packagers/+git and need a way to search them? | 20:54 |
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!