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