[10:41] <cjwatson> oops, sorry, I ran daily-checks manually with the wrong arguments so some of you will probably have got some duplicate image-health-check mail
[10:47] <cjwatson> not sure I can do much about the precise image oversizing
[10:50] <cjwatson> so, fortunately not many tests have been run yet as I need to respin most things for 12.04.4, I think
[10:50] <cjwatson> there's an updated wubi.exe, which is on the live and DVD images
[10:51] <ogra_> it seems to improve in each mail .... we should always run it multiple times :)
[10:51] <cjwatson> there's an updated partman-crypto, which is on the d-i-based images
[10:51] <cjwatson> ogra_: different series
[10:51] <cjwatson> and the last one was quantal so wouldn't expect output there
[10:51] <ogra_> dont trash my dreams :)
[10:51] <cjwatson> there's an updated ltsp, which intersects with both the above
[10:51] <cjwatson> and I still need to investigate why the wubi filesystem images are failing to build
[10:52] <cjwatson> or more specifically why they stopped building on 2013-08-23
[10:53] <xnox> cjwatson: i thought last couple of precise point releases, release team agreed that there is not much we can do about precise image growth, since hwe stacks get larger / gain additional dependencies.
[10:53] <cjwatson> well, 2013-08-26 actually
[10:53] <cjwatson> xnox: I think that's right
[10:53] <cjwatson> but worth mentioning anyway
[10:55] <xnox> (standing point-release item ;-) kind of reminds me debian's back in the day "kabbalah" vote on non-free linux kernel shortly before each release)
[10:55] <xnox> (not any more, as default debian kernel is free these days)
[11:03] <cjwatson> wubi fs builds probably fixed, retrying
[11:04] <cjwatson> http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/revision/1360
[11:25] <cjwatson> Fix texinfo files for makeinfo-5.1
[11:25] <cjwatson> oops, sorry
[11:44] <cjwatson> ok, that looks a bit better now.  respinning precise world
[11:45] <cjwatson> except core, which hasn't changed
[12:25] <ogra_> stgraber, i just had import-images running while starting copy-image ...
[12:25] <ogra_> stgraber, it worked fine, but i got some traceback stuff
[12:25] <ogra_> Waiting for other process to release the global lock
[12:25] <ogra_> Traceback (most recent call last):
[12:25] <ogra_>   File "/srv/system-image.ubuntu.com/bin/copy-image", line 299, in <module>
[12:25] <ogra_>     os.remove(lock_file)
[12:25] <ogra_> OSError: [Errno 2] No such file or directory: '/srv/system-image.ubuntu.com/state/global.lock'
[12:26] <ogra_> smells like copy-image didnt wait long enough to claim the new lock so the end of import-images removed the valid lockfile
[12:52] <apw> ogra_, that description implies that we are lock breaking, which means the lockfile is basically worthless
[12:53] <ogra_> apw, right ... i think it got torn out underneath the second command
[12:53] <ogra_> it helpd to hold it back until the first one was done though
[12:53] <apw> ahh, i see, it was "end of wait" recovery which failed
[12:54] <ogra_> right
[12:54] <apw> thats less frightening
[12:54] <ogra_> just a race wiht the lock removal
[12:57] <xnox> 12.04.4 -> wubi is all good now.
[14:16] <stgraber> ogra_: oh, yes, I saw that one before, should be easy to fix when I have a minute. At least the os.remove is the last thing to happen so the stacktrace isn't too concerning (nothing was skipped due to it)
[14:16] <ogra_> yeah, no worries
[14:16] <ogra_> as long as the race is on removal :)
[15:21] <shadeslayer> could someone force cantor https://launchpad.net/ubuntu/+source/cantor/4:4.12.1-0ubuntu1 to the release pocket?
[15:21] <shadeslayer> it depends on things like gcl which haven't been bootstrapped on arm64 and ppc64el
[15:22] <cjwatson> So why is it built on the architectures where it doesn't work?
[15:22] <cjwatson> In general I'm not prepared to force uninstallable packages in
[15:23] <cjwatson> But you could easily just not build cantor-backend-maxima on the arches that don't have gcl, no?
[15:23] <cjwatson> (Or suggest how we might go about bootstrapping gcl, which is also a possibility ...)
[15:28] <shadeslayer> cjwatson: I actually don't see a way to selectively not build the maxima backend just by build dep twiddling
[15:29]  * shadeslayer looks at CMake
[15:29] <cjwatson> you could arch-restrict it
[15:29] <cjwatson> but I'm looking to see how hard it is to port gcl now
[15:30] <shadeslayer> ok
[15:31] <cjwatson> it's not a self-build-dep, so it might just be a straightforward porting job
[15:31] <shadeslayer> interestingly the maxima, octave and scilab backends will always be built
[15:37] <cjwatson> Fedora has a thoroughly unconvincing patch set that basically just updates config.{guess,sub}
[15:37] <cjwatson> (claiming to fix this, but I don't think it does)
[15:41] <shadeslayer_> cjwatson: let me know the situation wrt gcl
[15:42] <shadeslayer_> I have http://paste.kde.org/pb337eb3d ready to be pushed
[18:47] <cjwatson> shadeslayer: I had a look at this; I don't think the patch would be huge, but I'm not enough of a toolchain hacker to find it easy.  I think you should go ahead with that arch-restriction patch for now.
[18:48] <shadeslayer> ack
[19:38] <rsalveti> slangasek: hey, we're trying to land latest mir, which requires a rebuild of the xorg-server package, which was just uploaded (new upstream release), but unfortunately failing to build as it got some additional dependencies from universe
[19:40] <rsalveti> slangasek: mlankhorst uploaded it while we were about to land mir, and I believe we can either drop the new release or try to include the newer dependencies in main
[19:40] <rsalveti> but I believe the MIR process might not necessarily happen so soon
[19:41] <rsalveti> slangasek: how should we proceed?
[19:42]  * ogra_ thought there was a decision to stay with xorg 1.14 
[19:42] <rsalveti> well, 1.15 was just uploaded :-)
[19:42] <ogra_> yes, i see that
[19:42] <ogra_> surprising
[19:43] <rsalveti> kgunn: besides this issue with xorg, are we good to land latest mir?
[19:43] <kgunn> rsalveti: ogra_ can i have like ....mmm....15 min...almost through ap testing...
[19:44] <rsalveti> kgunn: sure, just to know if you already found any other issue with it :-)
[19:44] <kgunn> it all looks ok...
[19:44] <ogra_> kgunn, well, with the xorg issue it will probably take more than 15min anyway
[19:44] <kgunn> so far
[19:44] <rsalveti> yeah
[19:44] <rsalveti> great
[19:45] <rsalveti> asac: we might need your help as well
[19:45] <rsalveti> seems you're the admin of https://launchpad.net/~ci-train-ppa-service/+archive/landing-002, and I believe we'd need a new xorg-server upload there once we know how to proceed
[19:45] <rsalveti> unless we remove the newer version from proposed
[19:47] <Sarvatt> xserver will need a huge transition of packages once it builds in proposed, probably better off removing it if its urgent
[19:48] <rsalveti> yeah
[19:48] <ogra_> right
[19:48] <rsalveti> well, we're trying to land mir for almost 2 weeks already
[19:48] <rsalveti> if not more
[19:48] <ogra_> if it blocks Mir that means it essentially blocks mobile development until Mir can land
[19:49] <rsalveti> yup
[19:49] <ogra_> and the mobile stuff produced a lot of backlog already due to delayed landings
[19:49] <ogra_> keeping it artificially delayed due to an unexpected xserver bump seems bad
[19:59] <Sarvatt> so i'm guessing the xserver update is going to need a FFe because MWC isn't until after feature freeze? :P
[20:00] <Sarvatt> it would have been in much earlier but only just got an fglrx driver for it today
[20:09] <slangasek> ogra_: mm, do you know where it was discussed to stay with xorg 1.14?
[20:10] <ogra_> slangasek, no, i just had the impression
[20:10] <slangasek> ok
[20:10] <ogra_> (that we dont want to invest much extra work into new xorg versions)
[20:13] <slangasek> is there an MIR bug open for libxshmfence?
[20:14] <slangasek> yes, bug #1276103, which is marked approved by the MIR team
[20:14] <ubot2`> Launchpad bug 1276103 in x11proto-present (Ubuntu) "[MIR] libxshmfence, x11proto-present and x11proto-dri3" [Undecided,Fix committed] https://launchpad.net/bugs/1276103
[20:15] <slangasek> rsalveti: ^^ so this will be unblocked as soon as we promote those packages to main (doing so now)
[20:15] <ogra_> ya
[20:15] <ogra_> y
[20:15] <rsalveti> slangasek: awesome
[20:16] <slangasek> (done)
[20:21] <rsalveti> great
[20:21] <rsalveti> kgunn: we should be good then, just need a rebuild once we're able to land mir
[20:23] <kgunn> rsalveti: ack ...on it
[21:57] <kgunn> rsalveti: ok...sorry for the delay...all good on mir testing...i only had one AP failure on unity8 suite...and it was some notification test that seems completely unrelated to mir
[21:58] <kgunn> i say its good
[21:59] <rsalveti> kgunn: alright, so +1 on your side
[22:00] <rsalveti> kgunn: which slot, 2?
[22:01] <kgunn> rsalveti: yes...002
[22:01] <rsalveti> kgunn: alright, will try to publish it
[22:02]  * rsalveti crosses his fingers
[22:02]  * kgunn crosses every limb and digit
[22:03] <rsalveti> packaging changes, let me quickly review those
[22:04] <rsalveti> looks fine
[22:05] <rsalveti> failed when publishing xorg, which was kind of expected, need to bump xorg in the ppa
[22:06] <rsalveti> slangasek: there's a new for xorg-server
[22:12] <slangasek> rsalveti: looking
[22:17] <slangasek> rsalveti: accepted
[22:18] <rsalveti> slangasek: thanks