[05:16] slangasek: Can you accept that telepathy-qt build fix of mine in the queue? [05:17] let's see [05:21] infinity: accepted [05:25] slangasek: Shiny. Worked in a PPA, so here's hoping the no-determinstic world of C++ symbols doesn't break it again. :P [05:25] (I swear the list kept changing on every test build... Ridiculous) [09:36] argl ! [09:37] please someone let the nux upload in, it has the same issue unity had [09:37] (trivial one line fix to make arm work) [09:42] ogra_: Oops. [09:44] ogra_: Are we holding unity up on the bizarre .pot diff? [09:46] I guess queuebot answered that. :P [09:51] infinity, nah, slangasek said thats no stopper [09:57] GRRR [09:57] seems thats not enough for a buildd ... needs fixes for the deps too [09:58] I take it you didn't test in sbuild? Naughty Oli. [09:58] (it built in my chroot but that had unity b-deps already, grumble) [10:00] hmm, still doesnt work, i suspect we need a no-change upload for unity too after nux has built [10:00] sigh, thats such a mess [10:02] ogra_: Look on the bright side. You haven't wasted a long weekend with intense pain, foreign hospitals, and sitting in airports. [10:02] And uploading libreoffice... [10:02] oh, yeah, tha latter is worst ... [10:03] At least it gave me time to sort out the geis and friends library rename in oneiric. [10:03] no, i havent, but i promised my mom on friday to come back today ... so i dont have eternal time to hunt that mess down :/ [10:03] That was the last round of NEW for it. [10:05] i dont get why the packaging from precise was just carried over modulo the gles patch [10:05] *wasnt [10:22] infinity, now with fixed deps :) [10:27] thx [10:30] NP. [10:30] I need someone to review that LibO for me. [10:31] i can take a look for obvious stuff, but dont tryst my skills if it comes to C++ [10:31] It's make/shell. [10:31] Just debian/rules. [10:31] *trust even [10:32] link ? [10:32] http://launchpadlibrarian.net/114393345/libreoffice_1%3A3.6.1~rc2-1ubuntu2_1%3A3.6.1~rc2-1ubuntu3.diff.gz [10:33] well, looks sane ... what *is* ca-XV actually ? [10:33] chinese canadian ? [10:34] Hahaha. I have no clue. :P [10:34] ca is Catalan though, isn't it? [10:34] oh, indeed [10:35] its funny that the typo isnt in the rm line [10:35] The rm line was in the previous revision. [10:35] heh, k [10:35] The 4 lines I changed were all new. [10:36] (Well, the previous previous... You know what I mean) [10:36] we'll i'd say upload ... cant get worse anyway [10:36] It's uploaded. :P [10:36] But not accepted. [10:36] I suppose it's a given that we want libreoffice built on i386, so I can fudge release management to use your review to leverage my other hat... [10:37] * ogra_ wonders if slangasek's cats play with the cable [10:38] ogra_: I'll accept it and blame you. Welcome to the release team for the next 10 seconds. [10:38] haha, go ahead [10:42] hmm, with the right b-deps nux takes significantly longer to build on arm [10:45] ogra_: Hahaha. [10:45] ogra_: I'd say that's likely a good sign. :P [10:56] oh, nice, I was just going to upload LO [11:09] Laney: Does your diff match mine? That would be a nice sanity check. [11:38] ogra_: nux copied to -release [11:45] yeah, think so [11:46] Laney: So you caught the missing "cat" too? ;) [11:46] infinity, yeah, i saw, thanks [11:47] I lined up the &&s for sanity, then it stood out [11:48] Laney: Fair enough. ;) [11:49] that's about as far as the sanity goes [11:50] probably enough libreoffice for the next year ;-) [11:50] Amen. [11:56] infinity, one more unity upload and we're done ... [11:56] (no change ... should be in the queue in a second) [12:01] there it is [12:02] while there is a flickering issue when moving windows around (which i'm happy to release B1 with) it seems to all work fine ... yay [12:04] * ogra_ will leave that bit to rsalveti :) [12:17] ogra_: why the diff? [12:25] Laney, which diff ? [12:26] Laney, http://paste.ubuntu.com/1181348/ [12:26] thats what i uploaded [12:29] * ogra_ has to go now else my mom will get angry [12:29] ogra_: check the diff on Launchpad [12:29] url ? [12:29] sec [12:30] i can only see approved stuff usually [12:30] https://launchpad.net/ubuntu/quantal/+queue?queue_state=1 [12:31] https://launchpadlibrarian.net/114433172/unity_6.4.0-0ubuntu2_6.4.0-0ubuntu3.diff.gz [12:31] oh, ignore the diff.gz, better check with debdiff [12:31] 6.4.0 is a complete mess (accidentially uploaded as native etc) [12:32] the debdiff should be fine (there is no orig.tar.gz anywhere, not even in the unity PPA so we have to live with that mess until someone re-packages) [12:33] anyway, i'm hours late due to that sh*t and i'm out now [12:34] I see the same thing when I debdiff [12:34] yeah, gotta go fix my bike actually :P [12:34] * ogra_ really didnt plan to woth through for two days including a half nightshift [12:34] can look later [12:34] F*CK !!!! [12:34] go away! [12:34] /kick [12:34] why does LP show something different from what i see here [12:35] * ogra_ doesnt get that [12:35] anyway, out now, if it isnt fixed tonight when i return i'll take another look ... its just a rebuild after all [12:36] * ogra_ waves [15:32] is it intentional that the i386 quantal daily has the German language pack but amd64 doesn't? [16:20] ogra_: the unity tarball was uploaded to https://launchpad.net/unity on Friday [16:21] https://launchpad.net/unity/6.0/6.4/+download/unity-6.4.0.tar.bz2 [17:26] jbicha: yes [17:26] jbicha: there's more room on 32bit images than on 64bit [17:27] stgraber: what limit are we shooting for, for quantal? because if it's 800MB, we have room, right? [17:28] jbicha: it's usually something we tweak around release but yeah, we'll likely fill some of the remaining space on all images with langpacks [17:29] though i386 will still likely have more langpacks than amd64, just because the files tend to be smaller, leaving more room for langpacks [17:29] ok, cool [17:39] ogra_: rejecting yours, mine has the expected diff [17:39] stgraber: could you maybe look at unity please? (no-change rebuild) [17:47] Laney: sure [17:48] accepted [17:48] ogra_: nah; I seem to have been having some IPv6 routing problems last night [18:46] oh. argh. [18:47] https://launchpad.net/ubuntu/+source/unity/6.4.0-0ubuntu3 [21:02] Laney, thx, checking the log [21:04] * ogra_ scratches head [21:04] that cant be .. [21:06] it doesnt do that in a local build [21:13] hmm, i wonder why [21:14] given that dash/previews/CMakeLists.txt actually hadcodes the linker stuff [21:14] *hard [21:16] Mirv, any idea about https://launchpadlibrarian.net/114534081/buildlog_ubuntu-quantal-armel.unity_6.4.0-0ubuntu3_FAILEDTOBUILD.txt.gz woudl be appreciated [21:17] * ogra_ really isnt good at cmake [21:18] i understand that -lGL -lGLU is hardcoded in dash/previews/CMakeLists.txt [21:20] (i still dont understand why it builds locally ... i actually built that version twice successfully here ) [21:24] Why are new versions of packages being uploaded without a bug reference number? The diff is huge and impossible to review. :-( [21:25] what package are you referring to ? [21:26] ogra_: nemiver, caribou, genius. [21:27] They were uploaded just a few minutes ago. [21:27] well, its universe, does FF apply there ? [21:27] FF certainly does, beta freeze not [21:28] hrm, the cmale syntax doesnt seem to know "else" [21:28] They should've been approved first before uploaded. [21:28] *cmake [21:29] ogra_: I'm working on trying to get the kernel in place for a fully working unity on panda now [21:30] rsalveti, well, i would first like a working unity at all [21:30] caribou is a GNOME micro-release on the way to the next stable release so that should be fine [21:30] ogra_: what is the issue still? [21:30] * rsalveti just got back from plumbers [21:30] * ogra_ already spent his whole weekend to sort that mess [21:31] /usr/bin/ld: cannot find -lGL [21:31] /usr/bin/ld: cannot find -lGLU [21:31] https://launchpadlibrarian.net/114534081/buildlog_ubuntu-quantal-armel.unity_6.4.0-0ubuntu3_FAILEDTOBUILD.txt.gz [21:31] some new code that hardcodes GL [21:31] I just the bug you sent me, but I believe it was all lack of the right build dependencies? [21:31] :-(( [21:31] funnily i can build it locally in a clean chroot on armhf without *any* issue [21:32] jbicha: I can't see any bugs mentioned in the changelog. How are we supposed to know that? :( [21:32] rsalveti, looking at dash/previews/CMakeLists.txt ... there is .... set (LIBS ${CACHED_UNITY_DEPS_LIBRARIES} "-lunity-core-${UNITY_API_VERSION} -lm -lGL -lGLU") ... [21:32] oh, hardcoded [21:32] i could just override that with an if (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv7l") it seems ... [21:33] but there is no "else" command and i'm not sure if one set just overrides a formerly set one [21:33] I believe there's a way to depend on when you're building for gl or gles [21:33] read: i have not much clue about cmake [21:33] that seems to be our last showstopper [21:33] iulian: the NEWS entry in the caribou diff is rather small... [21:34] alright, will set my builders and machines so I can give it a try [21:34] my locally build unity works just fine (apart from an off flickering bug but i'm willing to live with that for B1) [21:34] ogra_: at least we have all the right packages in place already, right? [21:34] I mean, the version which all supposes support gles [21:34] rsalveti, yup, compiz and nux are fine now [21:34] yeah, cool [21:34] and the current desktop image has PVR OOTB [21:34] that's great :-) [21:34] right on first boot [21:36] ogra_: will take a look in a few [21:37] the kernel changes are also possible for b1, but not that critical I'd also say [21:37] and the changes are quite intrusive, so we'd probably need a few days for testing and such [21:37] rsalveti, thx, i'm really getting exhausted after the second day with the same crappy stuff [21:37] yeah, lets keep them for post beta [21:37] cool [21:38] the current kernel is ok ... it boots and all devices seem to work :) [21:38] yeah :-) [21:40] oh, if you touch unity, beware, it somehow turned into a native package with the last upstream dump [21:40] oh, ok [21:41] and the clean target doesnt seem to properly clean up, check your debdiffs ;) [21:41] haha, ok :-) [21:50] jbicha: I've just noticed it's a bug fix upload. It would've made my life a lot easier if I had seen "bug fix release" somewhere in the changelog. I personally first read debian/changelog when I review things so I know what to expect. [21:57] Laney: with the new ubuntu-gnome, beta freeze might indeed apply to those packages [21:59] micahg, why, does it apply to xubuntu or lubuntu (beyond what they define as freeze themselves) [21:59] ? [22:00] caribou is the only one out of that set that is part of ubuntu-gnome [22:00] ogra_: beta freeze applies to packages that affect all images (I was supposed to fix the wiki) [22:00] s/all/any/ [22:00] * micahg does that now [22:01] ah, k [22:01] i thought its up to the flavours to decide that for their packagesets [22:02] ogra_: flavors can decide if something should get in or not if it only affects them [22:02] yeah, thats what i remembered [22:03] but they still need to coordinate with the release team and not just blindly upload [22:08] if anyone wants to review https://wiki.ubuntu.com/BetaFreeze?action=diff&rev2=8&rev1=7 to make sure I didn't miscommunicate anything [22:09] * ogra_ finds it confusion that the wiki marks deletions in green [22:10] *confusing [22:10] micahg, i would add a line about flavurs [22:10] i.e. "this also applies to derivative flavour images built in the ubuntu infrastructure" or some such [22:10] ogra_: saying what? flavors ship images the same as anyone else [22:11] ok [22:12] done [22:14] perfect :) [22:17] micahg: ogra_: my understanding was that we were meant to use proposed somehow.... [22:18] well, yes and no :) [22:18] xnox: yeah, I didn't include anything about that as the previous version didn't :) [22:18] proposed in any case for sets of packages that have a dependency chain [22:18] proposed can be used during freeze to continue uploads as well [22:19] oh, hrm, maybe not this time around :) [22:19] wasn't included in the release announcement [22:19] well, it will still work as last time :) [22:46] ogra_: so in nux supposed to be fixed now in quantal? compiz still segfaults for me here [22:46] do you run compiz standalone without unity ? [22:47] ogra_: I'm trying to use the default desktop [22:47] (else its likely unity that segfaults ... unity being a set of compiz plugins somewhat hides where the crash actually comes from) [22:47] (thats actually why i spent so much time in looking into compiz instaed of unity in the beginning yesterday [22:47] ) [22:48] slangasek, i just updated bug 1044709 [22:48] Launchpad bug 1044709 in unity "unity-6.4.0 from quantal-proposed crashed with SIGSEGV on omap4" [Critical,Fix released] https://launchpad.net/bugs/1044709 [22:48] slangasek, and rsalveti is looking into fixing it [22:49] what i still dont get is why it builds properly in a local chroot on armhf here [22:49] i could give you properly working binaries :) my panda desktop runs just fine over here [22:55] ogra_: so that unity task should be reopened then? [22:56] yes [22:56] something like this should fix it i guess http://paste.ubuntu.com/1182513/ [22:57] (untested and not 100% sure since i dont speak cmake ...) [22:57] but i guess rsalveti has a better and cleaner way [22:58] (or will find one at least) [22:58] well, the first part shouldn't be done that way... -fPIC should be the default, not the exception [22:58] (and I wonder if they have a good reason for not using -fPIC on i386) [22:59] it is like that in all other CMakeLists.txt files in the source [22:59] that part i just took over from the others [22:59] oh; then I guess unity is completely broken on powerpc [22:59] because that sure isn't going to work on any !x86 arch :P [23:00] well, as i said, it works fine on armhf (even without that fix) over here ... i must have a magic chroot or something ... [23:01] i even re-rolled the chroot today to make sure its clean [23:03] (several times) [23:06] * ogra_ sets the bug back to triaged [23:25] ogra_: cmake syntax looks valid, but it is not very CMake'ish way to set -fPIC [23:26] slangasek: while I agree that -fPIC should be the default, but little does CMake care.... [23:47] xnox, yeah, starting a testbuild now, i have set up my build env completely from scratch now, we'll see how it goes