[11:03] <psivaa> infinity: cjwatson: curious if we could re-enable daily precise iso's ?
[11:47] <cjwatson> psivaa: I guess that's reasonable.  Done
[11:48] <psivaa> cjwatson: ack, thanks :)
[11:59] <ScottK> Queue bot doesn't seem to show trusty SRUs.
[12:08] <cjwatson> ScottK: Probably because it's not here
[12:09] <cjwatson> stgraber: queuebot needs to be resurrected
[12:10] <ScottK> That'd do it.
[13:30] <stgraber> cjwatson: done
[13:31] <cjwatson> thanks
[14:00] <ypwong> could someone from SRU team kindly please take a look at bug 1314471?
[16:20] <doko> jibel, pitti: please restart the python-numpy autopkg test (sorry, didn't setup my vpn yet)
[16:22] <pitti> doko: already done
[16:23] <pitti> the dreaded "hash sum mismatch" again
[16:23] <pitti> darn, python3.4 amd64 still failed
[16:24] <pitti> FAIL: test_no_args_respects_force_flag (test.test_compileall.CommandLineTests)
[16:24] <pitti> AssertionError: Process return code is 1, stderr follows:
[16:24] <pitti> (nothing)
[16:24] <pitti> doko: that was one of the tests you reenabled, right?
[17:31] <slangasek> 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] <bdmurray> slangasek: it's acceptable? if so I'll give it a try
[17:32] <bdmurray> slangasek: and what revision are you on?
[17:32] <slangasek> bdmurray: oh, this time it went through
[17:32] <slangasek> so n/m :)
[17:33] <slangasek> I tried twice before and LP was sassing me
[17:33] <bdmurray> I've been seeing more lp timeouts recently
[18:17] <xnox> 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] <cjwatson> Daily, but the update process is buggy and sometimes races with the now-much-more-frequent publisher.
[18:18] <cjwatson> It looks as though nowadays it loses the race more often than not.
[18:18] <infinity> Definitely could use some TLC.
[18:21] <cjwatson> 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] <infinity> We could attempt to copy to dists.in-progress, and then fall back to dists.
[18:21] <cjwatson> 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] <infinity> Or that.
[18:22] <apw> that sounds much saner
[18:22] <cjwatson> I did think of your option but I think I prefer mine.
[18:22] <apw> let the publisher, like, publish it :)
[18:22] <infinity> Yeah, I prefer yours too.
[18:22] <infinity> I'd prefer even more if contents generation could actually happen from the main a-f run, but...
[18:23] <cjwatson> 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] <infinity> This barely qualifies as LP work.
[18:24] <infinity> Your solution could be sorted with a tiny LP patch and a new publisher-parts snippet.
[18:24] <xnox> infinity: well i've never run soyuz portion of the launchpad dev environment.
[18:24]  * infinity goes poking at the former.
[18:24] <cjwatson> I'd prefer it to be in LP since generate-contents-files is
[18:24] <cjwatson> All in LP proper I mean
[18:24] <cjwatson> And then it could be unit-tested fairly easily
[18:25] <infinity> Sure, so tack the contents copy on right before the dists move.
[18:25] <cjwatson> 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.
[19:37] <stokachu> cjwatson: if you have a few seconds would you mind looking over bug 1311274
[19:37] <stokachu> its basically the same thing you did for me in london but for the cloud seed
[19:41] <cjwatson> 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] <stokachu> cjwatson: no worries just needed a nod, thanks :)
[19:42] <cjwatson> python-six isn't a particular problem, says the maintainer ;-)
[19:42] <cjwatson> Though this is actually python3-six, right?
[19:42] <stokachu> cjwatson: yea
[20:33] <doko> pitti, yes, applied your work-around
[23:07] <rsalveti> slangasek: ^ in case you got some time to help reviewing and accepting them
[23:08] <rsalveti> after them get accepted I just need to update the meta package
[23:11] <rsalveti> will get some food, bbl
[23:15] <slangasek> rsalveti: why does qtbase-opensource-src-gles build-depend on the libs from the non-gles build?
[23:16] <rsalveti> slangasek: otherwise some of the libraries will fail when linking
[23:17] <rsalveti> we're not duplicating every package
[23:17] <slangasek> but a build-dep on libqt5gui5?  Surely it should use the internal copy that it's building
[23:17] <rsalveti> indeed, that one might not be needed, let me remove that and check