[00:00] I see. [00:00] Do I need to do anything special to authenticate when doing something on my ppas? [00:36] cjwatson, remove-package works nicely but it's definitely got some kinks. Like, if it doesn't find a particular binary, it just exits. [00:54] Also, this might not be a bug but if you specify debug symbols or 32-bit/64-bit versions of a lib, it says it cannot find them, even if they are listed in the packages produced by that source. === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [07:49] Lord-Kamina: Yeah, it's not really user-facing so hasn't had that sort of kink worked out. === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [10:02] Hello there ! [10:03] The git backend seems to have issues scanning branches (I get [10:03] Updating repository... [10:03] Launchpad is processing new changes to this repository which will be available shortly. Reload to see the changes. [10:03] ) Is this a known issue ? (It was working fine yesterday) [10:03] https://code.launchpad.net/~vila/byoci-test-project/+git/target-6405 for example [10:12] Yes, known, https://bugs.launchpad.net/launchpad/+bug/1783315 [10:12] Ubuntu bug 1783315 in Launchpad itself "celery hung after long git repository scan" [Undecided,New] [10:12] It'll get there but will be backlogged; I've asked for a restart of the celery process to stop the bleeding for now [10:14] cjwatson: ack, subscribed. Will be patient. Have a nice day ! [10:14] you too :) [14:31] Also cjwatson, according to the cli yesterday, I deleted somewhere around 400 packages; it took several hours for the used space to actually go down, and even when it did... [14:31] https://launchpad.net/~litenstein/+archive/ubuntu/toolchain/+packages I'm not sure it actually deleted anything XD [14:32] Quota use is only updated a few times a day; and that figure is certainly well below what it was when I looked at it yesterday. [14:33] The excess builds are still listed in the webapp, but you'll see that they're no longer published in e.g. http://ppa.launchpad.net/litenstein/toolchain/ubuntu/pool/main/c/cloog/ [14:34] I see. [14:35] I tried clicking on one yesterday (in the webapp), thought I'd get a 404 or something. [14:36] But maybe it linked to the original repo instead? [14:41] It linked to the file in the librarian, which isn't scoped to the repo [14:41] When you copy packages around with the "copy existing binaries" flag, you just get a new reference to the existing file in the librarian, not a copy of it [14:41] So the link is still good [14:50] I see. [14:51] What happens if you copy existing binaries and then the original creator deletes them? They still exist as long as there is at least one reference? [14:51] Yes [15:04] Is it safe to remove build-time dependencies from a ppa after binaries have been built, if there's something that could replace them in the same ppa? [15:04] Yes [15:53] What happens if I copy binaries from one repository to another and select a different series? [15:53] Then they'll be published in that series and it's up to you to make sure they're actually installable there [16:00] I see. I'm wondering if that might help an issue I'm having with porting debhelper. [16:00] I'll try more traditional means first of course. [17:03] Anybody know why this could be happening? https://launchpadlibrarian.net/380024964/buildlog_ubuntu-xenial-amd64.dh-autoreconf_17ppa-xenial1_BUILDING.txt.gz [17:04] debhelper 11.3.2 appears to have been built and installed correctly, but for some reason it won't handle compatibility levels > 10. [17:06] Lord-Kamina: that looks like the debhelper version string is set to 11 [17:07] i had that issue when I was working on a backport in a PPA [17:07] check the debian/compat version number? [17:07] Oh wow, pkgbinarymangler does some weird stuff [17:07] teward is on the wrong track I'm afraid [17:07] This is much stranger [17:07] ah i'm wrong then :) [17:07] cjwatson: that said, the error message is unclear if that's the case [17:08] I'm clear on what the cause is [17:08] Just investigating the right fix [17:08] no i meant in general [17:09] Right, so basically, pkgbinarymangler is used on buildds for various odd purposes, and it copies a bit of debhelper into itself at build time [17:09] So when you backport a version of debhelper with a new maximum compat level, you need to rebuild pkgbinarymangler against the new debhelper package [17:10] A no-change rebuild should do - just download the version of pkgbinarymangler from trusty, append "ppa1" or so to its version, and upload that [17:10] Strange gotcha, but most people don't do major backports of debhelper :) [17:23] Hahaha I see. [18:03] https://launchpad.net/~litenstein/+archive/ubuntu/debhelper11-3-2-xenial/+packages there we go. [18:03] Thanks cjwatson. === Guest16049 is now known as karstensrage [20:55] Great. There's a circular dependency issue in the package I'm trying to port now [20:56] Lord-Kamina: sometimes you have to do bootstrapping in that case [20:56] Lord-Kamina: e.g., build a version without that support that's circular, upload it, build the other package dependenent on the first, then reupload the second with the functionality replaced [20:56] I don't really know how to do that. [20:57] Although I did find a bug-report for it under some debian mailing list. [20:57] Lord-Kamina: i do wonder what you're doing that is putting you in such a ppa nightmare [20:57] Ah yeah ok, I see, I didn't know THAT was called bootstrapping. [20:57] The end-game is getting libicu60 in xenial (and eventually trusty) [20:58] If the circular deps are actually a bug, I'm gonna look at a previous version of the library, compare the dependencies and mimic that structure. [20:59] I think I might have found the issue. [21:18] Is there a way to make dh_install not die if it can't find a file? [21:20] Lord-Kamina: --list-missing, maybe? [21:33] Seems like that will do the trick, thanks. [21:33] I'm following some debian threads. [21:33] And it seems like it's an issue for them as well. [21:35] There's a circular dependency issue because icu deprecated and removed a part of the engine, but kept some code that depended on it around for some reason. Then somebody made a library out of that removed code, and eventually abandoned it. [21:35] And up-to-what-I've-read, it seems most everybody agrees the best solution for now is bootstrapping like you said. [21:39] Is it possible to use --list-missing with dh_auto_install? [21:44] Lord-Kamina: well, sure just pass it after -- ? [21:44] Lord-Kamina: or override it and do it yourself [21:46] As you can probably tell, I'm sorta new at this. [21:46] :P [21:46] Going out for some coffee, will try it when I get back. [23:13] Lord-Kamina: yeah, just seems like a helluva lot of work for someone "new" :)