| === superm1_ is now known as superm1 | ||
| === maclin__ is now known as maclin | ||
| psivaa | infinity: cjwatson: curious if we could re-enable daily precise iso's ? | 11:03 |
|---|---|---|
| === doko_ is now known as doko | ||
| cjwatson | psivaa: I guess that's reasonable. Done | 11:47 |
| psivaa | cjwatson: ack, thanks :) | 11:48 |
| === debfx_ is now known as debfx | ||
| ScottK | Queue bot doesn't seem to show trusty SRUs. | 11:59 |
| cjwatson | ScottK: Probably because it's not here | 12:08 |
| cjwatson | stgraber: queuebot needs to be resurrected | 12:09 |
| ScottK | That'd do it. | 12:10 |
| === oSoMoN_ is now known as oSoMoN | ||
| stgraber | cjwatson: done | 13:30 |
| cjwatson | thanks | 13:31 |
| ypwong | could someone from SRU team kindly please take a look at bug 1314471? | 14:00 |
| === rtg is now known as Guest24298 | ||
| === rtg_ is now known as Guest77551 | ||
| doko | jibel, pitti: please restart the python-numpy autopkg test (sorry, didn't setup my vpn yet) | 16:20 |
| pitti | doko: already done | 16:22 |
| pitti | the dreaded "hash sum mismatch" again | 16:23 |
| pitti | darn, python3.4 amd64 still failed | 16:23 |
| 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? | 16:24 |
| 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:31 |
| 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:32 |
| slangasek | I tried twice before and LP was sassing me | 17:33 |
| bdmurray | I've been seeing more lp timeouts recently | 17:33 |
| 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:17 |
| 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:18 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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. | 18:25 |
| === Guest67468 is now known as Logan_ | ||
| 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:37 |
| 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:41 |
| 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 | 19:42 |
| doko | pitti, yes, applied your work-around | 20:33 |
| === jhodapp is now known as jhodapp|afk | ||
| === rtg_ is now known as Guest1208 | ||
| rsalveti | slangasek: ^ in case you got some time to help reviewing and accepting them | 23:07 |
| rsalveti | after them get accepted I just need to update the meta package | 23:08 |
| rsalveti | will get some food, bbl | 23:11 |
| slangasek | rsalveti: why does qtbase-opensource-src-gles build-depend on the libs from the non-gles build? | 23:15 |
| rsalveti | slangasek: otherwise some of the libraries will fail when linking | 23:16 |
| 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 | 23:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!