=== superm1_ is now known as superm1 === maclin__ is now known as maclin [11:03] infinity: cjwatson: curious if we could re-enable daily precise iso's ? === doko_ is now known as doko [11:47] psivaa: I guess that's reasonable. Done [11:48] cjwatson: ack, thanks :) === debfx_ is now known as debfx [11:59] Queue bot doesn't seem to show trusty SRUs. [12:08] ScottK: Probably because it's not here [12:09] stgraber: queuebot needs to be resurrected [12:10] That'd do it. === oSoMoN_ is now known as oSoMoN [13:30] cjwatson: done [13:31] thanks [14:00] could someone from SRU team kindly please take a look at bug 1314471? === rtg is now known as Guest24298 === rtg_ is now known as Guest77551 [16:20] jibel, pitti: please restart the python-numpy autopkg test (sorry, didn't setup my vpn yet) [16:22] doko: already done [16:23] the dreaded "hash sum mismatch" again [16:23] darn, python3.4 amd64 still failed [16:24] FAIL: test_no_args_respects_force_flag (test.test_compileall.CommandLineTests) [16:24] AssertionError: Process return code is 1, stderr follows: [16:24] (nothing) [16:24] doko: that was one of the tests you reenabled, right? [17:31] bdmurray: sru-review seems unwilling to accept libreoffice from the precise-proposed queue... I don't want to have to accept through the web ui and write bug comments by hand. any suggestions? [17:32] slangasek: it's acceptable? if so I'll give it a try [17:32] slangasek: and what revision are you on? [17:32] bdmurray: oh, this time it went through [17:32] so n/m :) [17:33] I tried twice before and LP was sassing me [17:33] I've been seeing more lp timeouts recently [18:17] how ofter are Contents-arch.gz files updated? amd64 appears to be last modified on 29th of april and i386 on 3rd of May [18:18] Daily, but the update process is buggy and sometimes races with the now-much-more-frequent publisher. [18:18] It looks as though nowadays it loses the race more often than not. [18:18] Definitely could use some TLC. [18:21] Basically the problem is that it installs the updated Contents files in the normal dists/ directory, but the publisher rsyncs dists to a working location at the start of its work and moves it into place at the end. [18:21] We could attempt to copy to dists.in-progress, and then fall back to dists. [18:21] Perhaps one option would be for generate-contents-files not to try to install the updated files at all, but for the publisher to check a known (and atomically-updated) location for updates that it should copy in. [18:22] Or that. [18:22] that sounds much saner [18:22] I did think of your option but I think I prefer mine. [18:22] let the publisher, like, publish it :) [18:22] Yeah, I prefer yours too. [18:22] I'd prefer even more if contents generation could actually happen from the main a-f run, but... [18:23] But I'm maxed out on LP work right now. Hey, xnox, you seemed to want to do a bit of LP stuff ... :-) [18:23] * xnox slowly backs away =))))))))) [18:23] This barely qualifies as LP work. [18:24] Your solution could be sorted with a tiny LP patch and a new publisher-parts snippet. [18:24] infinity: well i've never run soyuz portion of the launchpad dev environment. [18:24] * infinity goes poking at the former. [18:24] I'd prefer it to be in LP since generate-contents-files is [18:24] All in LP proper I mean [18:24] And then it could be unit-tested fairly easily [18:25] Sure, so tack the contents copy on right before the dists move. [18:25] xnox: You don't need to set up the whole publisher for this (and IMO doing so would be a waste of time); the relevant bits are amenable to unit-testing. === Guest67468 is now known as Logan_ [19:37] cjwatson: if you have a few seconds would you mind looking over bug 1311274 [19:37] its basically the same thing you did for me in london but for the cloud seed [19:41] stokachu: I'm fine with it and have approved the MP, but don't have time to do more than that at the moment [19:41] cjwatson: no worries just needed a nod, thanks :) [19:42] python-six isn't a particular problem, says the maintainer ;-) [19:42] Though this is actually python3-six, right? [19:42] cjwatson: yea [20:33] pitti, yes, applied your work-around === jhodapp is now known as jhodapp|afk === rtg_ is now known as Guest1208 [23:07] slangasek: ^ in case you got some time to help reviewing and accepting them [23:08] after them get accepted I just need to update the meta package [23:11] will get some food, bbl [23:15] rsalveti: why does qtbase-opensource-src-gles build-depend on the libs from the non-gles build? [23:16] slangasek: otherwise some of the libraries will fail when linking [23:17] we're not duplicating every package [23:17] but a build-dep on libqt5gui5? Surely it should use the internal copy that it's building [23:17] indeed, that one might not be needed, let me remove that and check