[01:08] <JackYu> stgraber, done:).
[04:46] <darkxst> anyone able to look at gnome-online-miners in NEW?
[10:00] <apw> jibel, i think the linux autopkgtest testing for amd64 has broken at the testbed stage, we really ought to make that not a test failure, but a third type
[10:11] <ogra> test failre, test success and test wonky ?
[10:13] <xnox> ogra: if no tests managed to run the state is unknown. it tells nothing about the test success-rate. I'd expect wonky to be something that is flapping between pass & fail, with no good reason (e.g. racy)
[10:13] <jibel> apw, right. BTW it will likely fail again with no space left on device. But the disk size is already set to 40G and there is only 96GB left on the machine so if 2 tests run in parallel it'll quickly kill the host.
[10:14] <ogra> xnox, heh, ok
[10:14] <jibel> apw, is there any change in -14 that made the kernel become much bigger on amd64?
[10:15] <jibel> in this case it is not wonky or unknown, it is ENOSPC
[10:16] <apw> jibel, checking
[10:17] <apw> jibel, nothing stands out, the resulting binaries seem in the normal ball park, and the changes to the source are minimal
[10:21] <apw> jibel, how much space are we allowed to consume when building
[10:21] <jibel> apw, 40GB, how much space do you need?
[10:21] <apw> about 5 i would say
[10:23] <jibel> apw, it is already 37G Feb 28 10:22 trusty-amd64-linux-20140228_085329.GIxHVG.img and will crash in 3
[10:27] <xnox> apw: launchpad tells me that build needed "1747884k disk space" is that lies, or was there cleanup done along the way? what does adt test do to require so much space?
[10:28] <xnox> apw: can we do intermediate clean-ups at all?
[10:28] <jibel> apw, actually the build tree is 12GB, we need twice that size because adt does a copy but we run out of inodes
[10:28] <apw> jibel, ok based on what i have here, it is 11G per flavour, and you have the thing set to say it is autopkgtest which only builds one flavour
[10:28] <xnox> jibel: would declaring access to writable tree help? (then no copy is done?!)
[10:29] <apw> yeah 12GB is believeable, we do have a heck of a lot of files and always more
[10:31] <apw> so somewhere we have doubled from 5ish to 11ish, which i suspect is the new module signing stuff
[10:31] <apw> but we should cap out at that
[10:33] <apw> to be honest this is one of those cases where the testing config is not rich enough, and we don't want linux testing run on linux, only on deps of linux
[10:33] <apw> (or is that rdeps, but you get my drift)
[10:34] <apw> can we test which package we are testing on behalf of ?
[10:50] <jibel> apw, we have this info but no exclusion rule like "don't test myself". Currently when a new kernel is uploaded it triggers a test of the kernel and eglibc
[10:52] <ockham> could someone grant me an FFe, please? https://bugs.launchpad.net/ubuntu/+source/gourmet/+bug/1286073
[10:52] <ubot2`> Launchpad bug 1286073 in gourmet (Ubuntu) "[FFe] Please update gourmet to 0.17.0" [Undecided,New]
[10:58] <xnox> jibel: but can the trigger reason be included in the environment? e.g. that way adt tests in linux package whould check that environment variable and do "exit 0" straight away without doing anything.
[11:04] <jibel> xnox, yes, I can probably extend the system of overrides used to define a specific environment to support this, and add something like if the cause is myself then skip the test. But I need to think a little bit because the causes of the test and the definition of the environment are physically in 2 different places. And I don't want to spread too many configuration files all over the place.
[11:05] <ockham> ^ anyone, pls?
[11:05] <xnox> jibel: i don't think it's a good idea to define policy in the infrastructure. it's just a test is free to act/test different things depending on what triggered it.
[11:43] <apw> xnox, jibel, if i knew via environment or whaever in my test i assume i could write one to do it right
[11:48] <infinity> ockham: So, a few things: (a) why the added ipython Recommends?  (b) can you get it updated in Debian instead and ask for a sync?
[11:48] <infinity> ockham: None of the upstream changes look like they need an FFe, it's just simple bugfixes.
[11:49] <infinity> ockham: But the ipython Recommends is a bit heavy unless that one file/interface is a critically important part of the overall package.  If it's not, I'd suggest dropping that to Suggests.
[11:49] <infinity> ockham: And I'd definitely suggest forwarding any packaging improvements to Debian instead of forking in Ubuntu.
[13:29] <ockham> infinity: thx a bunch for reviewing this! answered your questions over at the bug report.