[00:00] <cjwatson> But actually not now that I look harder, because sbuild also runs debian/rules clean at the start of the binary package build.
[00:01] <realtime-neil> and the prepending of the changelog happens before this, right?
[00:01] <cjwatson> Indeed
[00:01] <realtime-neil> yep, the broken clean rule is eating the changelog message
[00:04] <realtime-neil> fantastic, now the source upload is failing because the kernel wants to rewrite its own debian/changelog during the build
[00:05] <realtime-neil> I really don't want to clean up this packaging, but I want to contend with the ubuntu kernel packaging even less
[00:07] <realtime-neil> wait, that actually worked
[00:08] <cjwatson> rewrite its own debian/changelog> /me hides under the duvet
[00:08] <realtime-neil> cjwatson: yeah. Yeah, it's not the best. but these are kernel devs, so....?
[00:09] <cjwatson> I'm not going to throw rocks in case they throw them back at my inefficient userspace code
[00:09] <realtime-neil> concur
[07:33] <Fudge> howdy all
[07:42] <mwhudson> sigh, now i have a build running out of disk space
[07:44] <mwhudson> cjwatson, wgrant: how much disk do builders have? it's not smaller for xenial or anything insane like that, right?
[07:50] <Fudge> worse luck, is your /var/cache full?
[08:34] <ricotz> hello, looks like many amd64 are silently failing currently (at least the ones my builds are getting assigned to) -- builds of https://launchpad.net/~mozillateam/+archive/ubuntu/ppa/+packages
[08:34]  * ricotz retried them now
[08:59] <cjwatson> mwhudson: 60G
[08:59] <cjwatson> mwhudson: and there's no difference between series, no
[09:00] <mwhudson> cjwatson: is there any way to see how much disk a succesful build used?
[09:01] <mwhudson> wonder if my failing build is just nudging over that (it fails pretty close to the end) or something bad is happening
[09:02] <ricotz> mwhudson, afaik at the end of a successful build-log the used disk space is shown
[09:02] <cjwatson> Yeah, sbuild shows it, though I think it's only what's left at the end rather than the high-water mark (in case a build removes intermediary outputs along the way)
[09:02] <cjwatson> That's the best available though
[09:04] <mwhudson> launchpad builds say "build-space: n/a" :/
[09:04] <mwhudson>  https://launchpadlibrarian.net/510323509/buildlog_ubuntu-bionic-s390x.rustc_1.47.0+dfsg1+llvm-1ubuntu1~18.04.1~ppa1_BUILDING.txt.gz for example (warning a bit large)
[09:40] <cjwatson> ricotz: Fixed now
[09:40] <cjwatson> (lcy01's ntp was down)
[09:40] <doko> mwhudson: Build needed 03:10:53, no disk space ;p
[09:41] <mwhudson> doko: i think this may be a lie
[09:42] <doko> you should be happy about such an efficient compiler
[10:06] <ricotz> cjwatson, thank you
[22:29] <rbasak> Is Launchpad git expected to be slow at the moment?
[22:30] <rbasak> If not, libvirt could looks like it could use a repack please.
[22:30] <rbasak> Ah
[22:30] <rbasak> fatal: write error: No space left on device2.76 MiB | 3.31 MiB/s
[22:30] <rbasak> fatal: index-pack failed
[22:30] <rbasak> That's just from a clone
[22:30] <rbasak> Ah, and not the main libvirt, but ~paelzer's libvirt
[22:31]  * rbasak tries again
[22:31]  * pappacena got scaried about that "no space left on device"
[22:32] <rbasak> Yeah I think that means something's broken
[22:53] <rbasak> Oh
[22:53] <rbasak> That's local
[22:56] <rbasak> (to me)
[22:57] <rbasak> Fetch is still really slow though
[22:58] <pappacena> I did a git pull here, and it seems to be ok to me. Load average seems to me normal on the machines. Is your network fine for other things?
[22:59] <rbasak> Yeah my network is fine.
[22:59] <rbasak> It's not bandwidth
[22:59] <rbasak> remote: Counting objects:  40% (150223/375557)
[22:59] <rbasak> That's the sort of place it gets stuck at
[22:59] <rbasak> Before any real transfer takes place
[22:59] <rbasak> Having said that, something just changed and it's suddenly normal speed
[23:33] <cjwatson> Our git performance graphs look normal, except for a minor spike at 2300 ish
[23:35] <cjwatson> But file a ticket with the URL to the repository to repack and we can ask for that