[03:39] <luke-jr> Is there a way to purge the disk space used by failed builds? eg "120 binary packages" for https://launchpad.net/~luke-jr/+archive/ubuntu/bitcoinknots/+packages even though only 4*5 of those are current
[08:33] <cjwatson> luke-jr: Your sums are wrong there - you have 4*5 builds, yes, but each build produces six binary packages (bitcoin{-qt,-tx,d}{,-dbgsym}), so that's 4*5*6=120
[13:39] <rbasak> Can I get some help with sorting out a blueprint and connecting it to status.ubuntu.com please? I never got familiar with how it works, what ACLs control what, etc. Right now we have https://blueprints.launchpad.net/ubuntu/+spec/servercloud-aa-server-core which I'd like to "take over" and hook up.
[13:39] <rbasak> Not sure who to ask.
[13:40] <cjwatson> I have very much forgotten how status.ubuntu.com works
[13:40] <cjwatson> One of the EMs or former EMs might remember, maybe slangasek?
[13:40] <rbasak> What's an EM?
[13:41] <cjwatson> engineering manager
[13:41] <rbasak> Ah. Thanks!
[13:42] <rbasak> I guess I'll have to wait until next week (which is fine).
[14:39] <luke-jr> cjwatson: aha, got it. and the debug ones are why it's so large :D
[14:40] <cjwatson> You can configure whether those are built/published in the "Change details" page of your PPA, in case they're simply useless to you
[14:40] <luke-jr> weird, the PPA dependency doesn't actually do anything useful for users? :/
[14:40] <luke-jr> they're probably useless, but if a user has a bug, they would quickly become useful XD
[14:40] <cjwatson> No, it's just for building; there's no defined way to propagate that to sources.list
[14:40] <cjwatson> Yeah
[14:41] <luke-jr> and sadly, AFAIK there's no way to deterministically regenerate the debug packages for previously built stuff?
[14:43] <cjwatson> Correct
[14:44] <cjwatson> If the build is otherwise exactly reproducible then you can, but there are lots of ways that might not be the case that are outside of Launchpad's control
[15:09] <luke-jr> cjwatson: well, I had deterministic binaries for other OSs, but AFAIK there's no way to get that for PPAs.. :/
[15:09] <luke-jr> s/had/have
[15:10] <cjwatson> It's not specific to PPAs as such; you "just" need to control the environment well enough
[15:10] <cjwatson> Nothing stopping that being done for PPAs
[15:11] <cjwatson> It'd be the same basic chain of tools as https://reproducible-builds.org/ has been doing for Debian
[15:12] <cjwatson> Of course any change in build-dependencies potentially invalidates it, so if you were doing that seriously then you might want to change the PPA's dependencies to use the release pocket only rather than the default (including updates), or possibly release+security for a compromise between having security updates and slowing down the rate of change
[15:13] <cjwatson> It'd likely also require backporting the basic packaging toolchain changes from the Debian reproducible-builds folks (dpkg, debhelper, etc.) and using those as build-deps in the PPA in question
[15:13] <cjwatson> So a certain amount of work, potentially, but nothing about PPAs prevents it
[15:13] <cjwatson> It's more about what's available in Ubuntu
[17:54] <acheronuk> LP git is being a bit flaky. Permission denied (publickey).
[17:54] <acheronuk> fatal: Could not read from remote repository.
[17:54] <acheronuk> Please make sure you have the correct access rights
[17:54] <acheronuk> and the repository exists.
[17:55] <acheronuk> the try to push again, and it works
[17:56] <jhobbs> acheronuk: i'm seeing the same thing
[17:56] <jhobbs> i thought it was my local network
[17:57] <acheronuk> jhobbs: nope. I also got a weird error try to view a git repo in a browser. did not keep the error message though, as assumed it was a one off glitch
[17:58] <acheronuk> and get this on an auto-merge cascade on our CI https://kci.pangea.pub/job/merger_akonadi/766/console
[17:59] <acheronuk> push 'origin' 'kubuntu_xenial_backports' 'kubuntu_stable' 'kubuntu_unstable'  2>&1:fatal: remote error: Connection was refused by other side: 111:
[18:00]  * acheronuk clicks the retry button
[18:00] <jhobbs> yeah i've got both connection refused and permission denied
[18:00] <jhobbs> cjwatson: ^^
[18:07] <jhobbs> having problems uploading packages too
[18:09] <acheronuk> jhobbs: an error, or the upload seems to go ok, but LP eats it without trace?
[18:09] <jhobbs> Rejected:
[18:09] <jhobbs> [lplibrarian-private-upload.internal:10006]: [Errno 111] Connection refused
[18:10] <jhobbs> got that in an email
[18:10] <acheronuk> ok. at least getting an error is better than nothing
[18:10] <jhobbs> acheronuk: also got an error on uploading.. tried again, seemed to accept it, then got that email instead of an accept email
[18:11] <acheronuk> wgrant: ??? ^^^^
[18:11] <cjwatson> One of our two frontends is down for upgrade to xenial, and it looks like it wasn't entirely taken out of DNS.
[18:12] <acheronuk> cjwatson: aha, thank you. I'll be patient
[18:12] <cjwatson> reported to the sysadmin doing the upgrade
[18:13] <acheronuk> understood. TY. :)
[18:14]  * acheronuk looks for something productive to do that doesn't involve git or uploads....
[18:14] <jhobbs> hehe
[18:14] <jhobbs> thanks cjwatson
[18:15]  * clivejo gives acheronuk a piece of rope which need untangled and unknotted
[18:17] <jhobbs> alright, i got a package accepted
[22:09] <nacc> cjwatson: is that upgrade also what just caused `pull-lp-source git` on my system to give back a 406 from lazr?
[23:05] <cjwatson> nacc: yes - I was away for a while, but from internal ops channel chatter it sounds like it should be fixed now
[23:16] <nacc> cjwatson: yep, looks resolved, thanks!