[00:00] <Lord-Kamina> I see.
[00:00] <Lord-Kamina> Do I need to do anything special to authenticate when doing something on my ppas?
[00:36] <Lord-Kamina> 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] <Lord-Kamina> 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.
[07:49] <cjwatson> Lord-Kamina: Yeah, it's not really user-facing so hasn't had that sort of kink worked out.
[10:02] <vila> Hello there !
[10:03] <vila> The git backend seems to have issues scanning branches (I get
[10:03] <vila> Updating repository...
[10:03] <vila> Launchpad is processing new changes to this repository which will be available shortly. Reload to see the changes.
[10:03] <vila> ) Is this a known issue ? (It was working fine yesterday)
[10:03] <vila> https://code.launchpad.net/~vila/byoci-test-project/+git/target-6405 for example
[10:12] <cjwatson> Yes, known, https://bugs.launchpad.net/launchpad/+bug/1783315
[10:12] <cjwatson> 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] <vila> cjwatson: ack, subscribed. Will be patient. Have a nice day !
[10:14] <cjwatson> you too :)
[14:31] <Lord-Kamina> 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] <Lord-Kamina> https://launchpad.net/~litenstein/+archive/ubuntu/toolchain/+packages I'm not sure it actually deleted anything XD
[14:32] <cjwatson> 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] <cjwatson> 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] <Lord-Kamina> I see.
[14:35] <Lord-Kamina> I tried clicking on one yesterday (in the webapp), thought I'd get a 404 or something.
[14:36] <Lord-Kamina> But maybe it linked to the original repo instead?
[14:41] <cjwatson> It linked to the file in the librarian, which isn't scoped to the repo
[14:41] <cjwatson> 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] <cjwatson> So the link is still good
[14:50] <Lord-Kamina> I see.
[14:51] <Lord-Kamina> 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] <cjwatson> Yes
[15:04] <Lord-Kamina> 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] <cjwatson> Yes
[15:53] <Lord-Kamina> What happens if I copy binaries from one repository to another and select a different series?
[15:53] <cjwatson> Then they'll be published in that series and it's up to you to make sure they're actually installable there
[16:00] <Lord-Kamina> I see. I'm wondering if that might help an issue I'm having with porting debhelper.
[16:00] <Lord-Kamina> I'll try more traditional means first of course.
[17:03] <Lord-Kamina> Anybody know why this could be happening? https://launchpadlibrarian.net/380024964/buildlog_ubuntu-xenial-amd64.dh-autoreconf_17ppa-xenial1_BUILDING.txt.gz
[17:04] <Lord-Kamina> 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] <teward> Lord-Kamina: that looks like the debhelper version string is set to 11
[17:07] <teward> i had that issue when I was working on a backport in a PPA
[17:07] <teward> check the debian/compat version number?
[17:07] <cjwatson> Oh wow, pkgbinarymangler does some weird stuff
[17:07] <cjwatson> teward is on the wrong track I'm afraid
[17:07] <cjwatson> This is much stranger
[17:07] <teward> ah i'm wrong then :)
[17:07] <teward> cjwatson: that said, the error message is unclear if that's the case
[17:08] <cjwatson> I'm clear on what the cause is
[17:08] <cjwatson> Just investigating the right fix
[17:08] <teward> no i meant in general
[17:09] <cjwatson> 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] <cjwatson> 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] <cjwatson> 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] <cjwatson> Strange gotcha, but most people don't do major backports of debhelper :)
[17:23] <Lord-Kamina> Hahaha I see.
[18:03] <Lord-Kamina> https://launchpad.net/~litenstein/+archive/ubuntu/debhelper11-3-2-xenial/+packages there we go.
[18:03] <Lord-Kamina> Thanks cjwatson.
[20:55] <Lord-Kamina> Great. There's a circular dependency issue in the package I'm trying to port now
[20:56] <nacc> Lord-Kamina: sometimes you have to do bootstrapping in that case
[20:56] <nacc> 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] <Lord-Kamina> I don't really know how to do that.
[20:57] <Lord-Kamina> Although I did find a bug-report for it under some debian mailing list.
[20:57] <nacc> Lord-Kamina: i do wonder what you're doing that is putting you in such a ppa nightmare
[20:57] <Lord-Kamina> Ah yeah ok, I see, I didn't know THAT was called bootstrapping.
[20:57] <Lord-Kamina> The end-game is getting libicu60 in xenial (and eventually trusty)
[20:58] <Lord-Kamina> 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] <Lord-Kamina> I think I might have found the issue.
[21:18] <Lord-Kamina> Is there a way to make dh_install not die if it can't find a file?
[21:20] <nacc> Lord-Kamina: --list-missing, maybe?
[21:33] <Lord-Kamina> Seems like that will do the trick, thanks.
[21:33] <Lord-Kamina> I'm following some debian threads.
[21:33] <Lord-Kamina> And it seems like it's an issue for them as well.
[21:35] <Lord-Kamina> 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] <Lord-Kamina> And up-to-what-I've-read, it seems most everybody agrees the best solution for now is bootstrapping like you said.
[21:39] <Lord-Kamina> Is it possible to use --list-missing with dh_auto_install?
[21:44] <nacc> Lord-Kamina: well, sure just pass it after -- ?
[21:44] <nacc> Lord-Kamina: or override it and do it yourself
[21:46] <Lord-Kamina> As you can probably tell, I'm sorta new at this.
[21:46] <Lord-Kamina> :P
[21:46] <Lord-Kamina> Going out for some coffee, will try it when I get back.
[23:13] <nacc> Lord-Kamina: yeah, just seems like a helluva lot of work for someone "new" :)