[00:00] 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] and the prepending of the changelog happens before this, right? [00:01] Indeed [00:01] yep, the broken clean rule is eating the changelog message [00:04] fantastic, now the source upload is failing because the kernel wants to rewrite its own debian/changelog during the build [00:05] I really don't want to clean up this packaging, but I want to contend with the ubuntu kernel packaging even less [00:07] wait, that actually worked [00:08] rewrite its own debian/changelog> /me hides under the duvet [00:08] cjwatson: yeah. Yeah, it's not the best. but these are kernel devs, so....? [00:09] I'm not going to throw rocks in case they throw them back at my inefficient userspace code [00:09] concur [07:33] howdy all [07:42] sigh, now i have a build running out of disk space [07:44] cjwatson, wgrant: how much disk do builders have? it's not smaller for xenial or anything insane like that, right? [07:50] worse luck, is your /var/cache full? [08:34] 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] mwhudson: 60G [08:59] mwhudson: and there's no difference between series, no [09:00] cjwatson: is there any way to see how much disk a succesful build used? [09:01] wonder if my failing build is just nudging over that (it fails pretty close to the end) or something bad is happening [09:02] mwhudson, afaik at the end of a successful build-log the used disk space is shown [09:02] 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] That's the best available though [09:04] launchpad builds say "build-space: n/a" :/ [09:04] 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] ricotz: Fixed now [09:40] (lcy01's ntp was down) [09:40] mwhudson: Build needed 03:10:53, no disk space ;p [09:41] doko: i think this may be a lie [09:42] you should be happy about such an efficient compiler [10:06] cjwatson, thank you === ddstreet_away is now known as ddstreet === ijohnson is now known as ijohnson|lunch === ijohnson|lunch is now known as ijohnson [22:29] Is Launchpad git expected to be slow at the moment? [22:30] If not, libvirt could looks like it could use a repack please. [22:30] Ah [22:30] fatal: write error: No space left on device2.76 MiB | 3.31 MiB/s [22:30] fatal: index-pack failed [22:30] That's just from a clone [22:30] 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] Yeah I think that means something's broken [22:53] Oh [22:53] That's local [22:56] (to me) [22:57] Fetch is still really slow though [22:58] 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] Yeah my network is fine. [22:59] It's not bandwidth [22:59] remote: Counting objects: 40% (150223/375557) [22:59] That's the sort of place it gets stuck at [22:59] Before any real transfer takes place [22:59] Having said that, something just changed and it's suddenly normal speed [23:33] Our git performance graphs look normal, except for a minor spike at 2300 ish [23:35] But file a ticket with the URL to the repository to repack and we can ask for that