[00:26] ^- fixes Chinese edition amd64 image build failure, which is the last of our long-running failures [00:28] * stgraber looks [00:32] accepted [00:33] ta [00:33] (debdiff wasn't terribly useful with that one, took a bit more manual checking) [00:33] * cjwatson looks forward to less cronmail [00:36] cjwatson: Accepted d-i/precise [00:38] thanks [00:38] Anyone with @ on this channel want to fix the topic to stop lying about the state of the archive? [00:39] (Or fix the channel mode...) === cjwatson changed the topic of #ubuntu-release to: Quantal Quetzal Alpha 3 released! | Archive: Beta Freeze | Quantal Quetzal Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or birdseed | melior malum quod cognoscis [00:43] infinity: also you have @ (and @-less use of /topic) here now [00:44] (which probably means I didn't need to op myself to do that, but anyway ...) [00:45] remaining bits of the unity stack are now building [00:45] would be nice if someone could monitor and copy to the release pocket once they're done [00:47] cjwatson: I'm assuming that's for biosdevname? ^ [00:48] (waiting on very slow internet to download it) [00:50] Yeah [06:38] just did a very quick review of mountall, seems kind of reasonable but not confident enough (just got back from an open bar...) to actually accept it. Will do another review tomorrow morning if nobody got to it before then. [06:38] (having the autoconf generate stuff change doesn't really help) [07:42] hi, anybody from the -release team could have a look at this FFe? #1043654 === yofel_ is now known as yofel [15:16] * stgraber releases unity into the release pocket [15:28] hmm [15:28] * ogra_ meanwhile points at bug 1044709 [15:28] Launchpad bug 1044709 in compiz "compiz 0:0.9.8.0-0ubuntu1 from quantal-propsed crashed with SIGSEGV on omap4" [High,New] https://launchpad.net/bugs/1044709 [15:28] doh [15:29] ogra_: though my understanding is that even with this bug, it's no worse than what we had or am I wrong? [15:30] * ogra_ tries to find a fix but its not quick (testbuild takes 30min for every iteration) [15:30] stgraber, riht, it just crashes on start of the desktop [15:30] *right [15:30] compiz was compiled with gles: https://launchpadlibrarian.net/114154546/buildlog_ubuntu-quantal-armhf.compiz_1%3A0.9.8.0-0ubuntu1_BUILDING.txt.gz [15:30] yes [15:31] ok, good, so that definitely needs to be fixed ASAP but we don't need to try and figure out an immediate revert as it wouldn't actually improve things [15:31] but i fear the installing of the cmake file we tinkered with breaks it [15:32] right, leave it as is ... [15:32] ah! [15:32] ogra_: how is the release going? [15:32] ogra_: I don't think we did and cmakefile change for compiz, or do you mean unity? [15:32] ppisati, beyond the above bug its really fine [15:33] ogra_: cool [15:33] Mirv, i mean the debian/rules hack for FindGLES2.cmake [15:33] * ppisati is on its way to Rhodes, just did a pitstop @home and wanted to check [15:34] ogra_: ah, that [15:34] ogra_: I'll be leaving the hotel soonish as I have to get to the airport, but if you can figure out a fix, just upload directly to -proposed and I'll review + accept + pocket copy whenever I get connectivity again [15:34] we used to install it under Modules in the past, now it goes directly to the package target dir ... [15:34] and i suspect that changes something [15:34] stgraber, k [15:34] i suspect that will need testing on x86 then though [15:35] ogra_: I think the end result was the same, compiz-dev has the wanted too copies of both FindCompiz and FindOpenGLES2.cmake, under cmake-2.8 and cmake-2.8/Modules [15:35] (recently someone complained about that for plymouth even though there were only arm changes) [15:35] s/too/two/ [15:36] Mirv, FindOpenGLES2.cmake needs to be under cmake-2.8/Modules i think [15:36] ogra_: like I said it is [15:36] both there and the parent dir [15:36] hmm [15:36] (looking at http://launchpadlibrarian.net/114154559/compiz-dev_0.9.8.0-0ubuntu1_armhf.deb with file-roller) [15:37] yeah, i see that here too [15:38] i just dont get why it worked before [15:38] cant be the build itself [15:38] that's a pretty good question, maybe worth looking at the good ol' patch to see if there was some hard-coding or something somewhere still [15:38] right, thats what i did [15:39] inspecting the packagin bits ... [15:39] and the only real difference is the debian/rules stuff [15:40] I mean the patch itself, if you meant it worked back when it was patched on top of sources http://is.gd/qx7Nze [15:40] ah, no, the patch has nothing in common anymore with the actually landed code i think [15:40] afaik there was a lot re-written upstream [15:41] yes not really, just thought if there was something forgotten to be defined in the re-write [15:41] well, and when i tested the test4 package (but only by running binary-arch and binary-indep after applying teh change) it worked fine [15:41] oh... [15:41] so i dont think its the compiled code [15:42] very weird, though [15:42] at runtime compiz seems to try to use opengl ... [15:44] since I got up to test8, I wonder what phase the test4 was at.. [15:44] the one that was missing && [15:46] test4 was (possibly) this where I fixed the installed plugins at http://bazaar.launchpad.net/~timo-jyrinki/compiz/gles_arm_install_fix/revision/3283 [15:46] which you then fakeroot installed manually [15:46] hmm, no i dont think i did [15:47] ok :) hard to remember [15:47] anyway, the devil is once again in some very little detail, similar to that actual debian/rules fix to correct the packaging to work [15:47] must have been somewhere between 3283 and 3286 [15:50] actually between 3284 and 3285 [15:50] *but* .... [15:51] i think i didnt remove the compiz-dev.install.arm{el,hf} files when changing debian/rules [15:51] * ogra_ wonders if that could make any difference [15:53] oh, FFS. now libreoffice FTBFS on i386 [15:54] as long as armhf builds [15:55] looks like a packaging mistake, so I'm assuming the rest will fail too [15:56] dh_install: missing files, aborting [15:56] ogra_: they probably didn't exist at the time, since you were only debugging the test4 version that failed to build since I _hadn't_ yet added the compiz-dev.install.arm{el,hf}, and you fixed that with the debian/rules change [15:56] yeah, i wasnt serious [15:57] phase of the moon etc more likely [15:57] Mirv, well, still, there was a test i did that worked ... [15:57] I wonder if any runtime option would affect which backend is used [15:59] well, we ddint need one in the past [16:00] and i didnt need one when testing [16:10] oha ! [16:11] Mirv, ok, downgrading to the test4 packages doesnt help [17:27] The libreoffice failure just looks like mild dyxlexia. s/VX/XV/ on debian/rules would make it happy. [17:28] The diff makes it stick out fairly well: [17:28] http://launchpadlibrarian.net/114223440/libreoffice_1%3A3.6.1~rc2-1ubuntu1_1%3A3.6.1~rc2-1ubuntu2.diff.gz [17:29] I'd fix it, but I'm not uploading libreoffice from airport wireless. :P [17:46] ScottK: ^--- New telepathy-qt should actually build on all arches, if you'd like to accept it for me. [17:47] * infinity gets on his plane now. [19:02] * Laney starts a -j8 build in The Cloud [20:49] * ogra_ would appreciate if someone could let the new unity upload into the archive asap after it built (i just uploaded to -proposed) [20:49] it should fix the GLES issues [20:50] (one line fix) [20:55] ogra_: looking. does that mean something wasn't tested before upload that should have been? [20:56] slangasek, it wasnt tested from what was uploaded to proposed, right, i tested from PPA builds [20:56] (which apparently worked, i spent half the day poking on compiz because i thougth it was at fault, but then discovered debian/rules in unity) [21:00] * slangasek looks at the diff and sighs [21:00] yeah [21:00] ok, so is that fix committed to the right place now? [21:01] not yet in bzr (i found the upload more important, caring for bzr sync now) [21:02] ogra_: I notice the tree is not altogether clean (build cruft left behind); I'm going to scrub it and reupload [21:02] also, do you have any idea where the unity 6.4.0 orig.tar.gz is that should be here? [21:03] oh [21:03] intresting, no, and i dont have it in my test build chroot either [21:03] it wasn't in the previous version of the package that was uploaded, either [21:04] (which escaped notice when reviewing it, because queuediff doesn't show such things..) [21:04] seems that packae came down as a native one from the server already, i have a unity_6.4.0-0ubuntu1.tar.gz [21:04] phew [21:04] and all the desktop team gone ... i have no idea wheer the orgi tarballs come from [21:05] (and cant type) [21:05] did the ppa have one? [21:06] i dont even see 0.6.4 anymore https://launchpad.net/~unity-team/+archive/release/+packages?field.name_filter=&field.status_filter=published&field.series_filter=quantal [21:07] hmpf [21:09] slangasek, i'd say we leave that as a monday exercise for Mr. "foo" :) [21:09] i'll hunt him down on monday ... [21:15] yeah, I don't consider this a blocker [21:16] so why are there still separate patch series for arm vs x86 in the package? [21:18] good question, i havent looked into unity for a while apart from testing the binaries, the patch isonly a one line change to CMakeLists.txt though [21:18] i'll ask the linaro GLES guys if we still need it [21:20] i dont really get why the test stuff didnt get cleaned up, i know i ran debian/rules clean before rolling the srouce package [21:20] *source [21:31] ogra_: or maybe it's still needed but it should be made a conditional relative to some of the other stuff that's already set [21:32] ogra_: did you run ./debian/rules clean with the architecture set to armhf? :) [21:32] no, just "fakeroot debian/rules clean" but on an armhf builder [21:33] hmm [21:58] ogra_: ok, so it failed to build on i386+amd64 [22:05] err [22:06] [ 3%] [ 3%] /build/buildd/unity-6.4.0/obj-i686-linux-gnu/generated/networkarearegion.xml:1: parser error : Document is empty [22:06] ^ [22:06] [ 4%] ^ [22:06] unable to parse /build/buildd/unity-6.4.0/obj-i686-linux-gnu/generated/networkarearegion.xml [22:06] oh my [22:07] /build/buildd/unity-6.4.0/obj-i686-linux-gnu/generated/networkarearegion.xml:1: parser error : Start tag expected, '<' not found [22:09] i wonder why it didnt fail before, thats definitely not caused by my change [22:12] * ogra_ starts to suspect that the cruft in the former debdiff is actually needed somehow [22:13] no, the cruft truly was cruft [22:13] this may be an over-parallelization bug [22:13] well, i see the networkarearegion.xml.in file in the .pot [22:14] i did my build with -j4 on the mx6 ... not sure how many jobs the buildd assigns by default on x86 indeed, but i had no probs building multithreaded [22:15] the failed amd64 build was -j8 [22:15] hmm, k [22:16] so I actually didn't remove the changes to the .pot file, because those looked like a legitimate refresh rather than build cruft [22:16] but, double-checking [22:16] well, that must have been a refresh during my build [22:17] # SOME DESCRIPTIVE TITLE. [22:17] -# Copyright (C) YEAR Canonical\ Ltd [22:17] +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER [22:17] and that doesnt look so good [22:17] it also stripped the bugmail contact [22:17] it doesn't, but it was plausible that it was the legitimate output of a refresh [22:20] heh, the arm arches are both nearly done [22:25] * ogra_ waits for an x86 deboostrap to finish and gets coffee ... [22:26] yay for one line fixes that turn into nightshifts ... [22:34] :( [22:37] highvoltage, nick revert? [22:42] knome: yeah the new one didn't stick [22:44] highvoltage, are you sure you remembered to set it sticky? ;) [22:45] knome: ah that must what I've been doing wrong! [22:49] :) [23:04] hmm, builds fine with -j8 on my amd64 machine [23:11] same on x86 [23:11] ogra_: yeah, I gave the builds back [23:11] built fine for me here too; whatever it was, seems to be a latent problem [23:12] yup [23:15] and survived [23:19] hmm, each of my testbuilds has the same cruft in the debdiff [23:19] that package needs quite some love :) [23:20] i386 looks fine too now [23:26] I think the root problem for the mess was the non-updated lp:ubuntu/unity, which let to the original packaging branch being based off from earlier version and some merge wasn't then complete [23:27] or actually... the unity packaging was never right [23:28] ogra_: funny though that you had a "non-foo" unity build since only compiz ever had the architectures line specified correctly [23:52] Mirv, yeah, well, sorted for now ... [23:52] i'll talk to lukas next week [23:52] the clean target needs overhaul and it needs a proper tarball [23:53] * ogra_ is tired now and calls it a day