[00:00] maxb: my non-flippant answer is in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204; that would be automatable in bzr-builddeb, I'm sure [00:00] Debian bug 572204 in dpkg-dev "dpkg-dev: maintainer workflow problems with 3.0 (quilt) and VCS" [Wishlist,Open] [00:02] * cjwatson -> bed [00:04] * maxb drops a quick mail to u-distributed-devel@ about this [00:05] I think at the time it seemed quite intrusive, but now bzr-builddeb is doing lots of quilt munging already ... [02:20] * skaet --> EOd [02:28] skaet: 'night [03:25] Nice. caph and chort both building the same package on the same arch at the same time. [05:00] slangasek: as I said, I don't veto gnome-session, I just don't think it's very useful or wise [05:01] pitti: yep - I understand your position, my point is merely that the arguments here are no different during a freeze than not [05:01] slangasek: yes, I agree [05:01] it's not risky at all [05:02] oh, someone rejected it? [05:02] anyway, I would love for there to be a non-sucky session manager solution that upstream would back... in the meantime, I'll take what I can get ;) [05:02] I reject one of the two kubunut-default-settings (identical), leaving the other one as per pad [05:03] * slangasek nods [05:03] I really don't think kubuntu-default-settings needs to block on plymouth, but it shouldn't matter as plymouth should come later today (according to cjwatson) [05:04] slangasek: [05:04] -Command: /usr/lib/update-notifier/package-data-downloader [05:04] +Command: gksudo /usr/lib/update-notifier/package-data-downloader [05:04] slangasek: does that file not apply to Kubuntu? [05:04] (also, "gksu" is the canonical command, but not a biggie) [05:06] argh, so once again powerpc backlog is causing trouble [05:06] pitti: well.... I don't see any available alternative that works in kubuntu (see changelog, & bug comments about policykit not happening for final) [05:06] so calling gksudo, so that it fails only on Kubuntu, is better than calling the raw command and having it fail everywhere [05:07] hm, but these two changes together don't make much sense to me [05:08] sudo does not keep the proxy variables from the user, so we rely on the user to have clicked "apply system wide" when configuring the proxy [05:08] but wouldn't that set the proxy in apt, too? [05:09] ah, you hope that the general proxy in /etc/environment is better for the auxiliary downloads than apt's, I see [05:11] yeah [05:12] it's imperfect, but, well, apparently there are some large deployments of Ubuntu whose proxy usage conflicts with my previous assumption [05:13] users relying on the apt proxy setting for package data downloads before couldn't get ubuntu-restricted-extras anyway... because msttcorefonts implemented this one way, flashplugin-nonfree implemented it the other way [05:17] didrocks: good morning [05:17] didrocks: is the unity FTBFS on arm due to the nux changes? [05:17] hey pitti :) [05:18] pitti: hum, can be yeah, let me look [05:19] slangasek: I'll move some built -proposed stuff to release now (eglibc, etc.), ok? [05:20] pitti: if powerpc is caught up, sure - it wasn't last I'd looked [05:20] yes, for glibc; it's currently chewing on the KDE rebuilds [05:21] I guess infinity nudged it a bit :) [05:24] pitti: so: [05:24] https://launchpadlibrarian.net/101498332/buildlog_ubuntu-precise-armhf.unity_5.8.0%2Bbzr2276ubuntu0%2B677_FAILEDTOBUILD.txt.gz didn't built on armhf [05:24] https://launchpadlibrarian.net/101346712/buildlog_ubuntu-precise-armhf.unity_5.8.0%2Bbzr2275ubuntu0%2B677_BUILDING.txt.gz built [05:24] the libnux version commit between the two isn't meaningfull [05:24] looking for compiz [05:24] as linaro changed compiz as well [05:25] (the packaging is the same, so it's not the nux change) [05:25] erk, accidentally copied to -updates; please ignore the following flood of new/rejects in -updates [05:26] pitti: the only thing that seems to be have meaningfully changes is compiz [05:26] pitti: so it's the linaro patch for compiz [05:26] pitti: can try in a ppa building unity with the previous compiz (without their patch) [05:26] didrocks: you have an arm PPA? [05:27] pitti: I do ;) [05:27] (well, the unity one) [05:27] not really done for that, but I guess it can be used for that [05:27] didrocks: ok, please prod me for build score bumps if needed [05:28] pitti: it's already a priority ppa, heh ;) [05:28] ok, compiz first [05:28] * pitti hugs didrocks [05:29] * didrocks hugs pitti back [05:30] so, -proposed flushed as much as possible [05:36] did samba make it into the flushed set? I see that it's published now, and I was watching for it [05:38] pitti: oh wait [05:38] slangasek: yes [05:38] ok, cool [05:38] pitti: https://launchpad.net/ubuntu/+source/compiz/1:0.9.7.6-0ubuntu1 no give back done? [05:38] pitti: it seems to be some archive skew to me [05:38] erk, that looks bad; these can be retried? [05:38] yeah, failing due to kde-workspace-dev [05:39] so I guess some arch skew because of kde? [05:39] retried, bumping [05:39] thanks [05:39] pitti: that still doesn't fix the FTBFS on armel, I uploaded compiz in the ppa [05:39] waiting for armhf to build to retry unity [05:40] (in the ppa) [05:41] weird, maybe the unity issue might be related with the compiz changes [05:41] let me rebuild compiz locally to see if I can also reproduce it here [05:42] rsalveti: thanks! I can say that from my build logs, armhf started to fail to build once the compiz version with the armel patch was made available [05:42] libnux just had an irrelevant commit change between the two [05:42] and the rest of the stack didn't change [05:43] yeah [05:53] pitti: thanks for the give back, compiz rebuilt on amd64 in the archive [05:54] pitti: maybe you will till be able to score the build a little bit more for the ppa: https://launchpad.net/~unity-team/+archive/ppa/+build/3402499 [05:54] didrocks: done [05:55] sweet! :) [06:01] pitti: argh, I need to remove some build-dep as well on armel for the ppa, one sec [06:02] * didrocks not really happy with the intrusive changes that linaro introduced at the last minute… [06:08] hm, locally compiz failed to build because of the way the extra patch is applied [06:08] when generating the source it failed to remove the already applied patches, because the gles related one was not removed before the others [06:09] rsalveti: interesting, it built on the ppa, so I guess the way the patch is applied/unapplied is right (and ogra checked it) [06:09] pitti: a small help? https://launchpad.net/~unity-team/+archive/ppa/+build/3402518 ;) [06:09] didrocks: yeah, could be related with my local options [06:09] didrocks: I can't get it below 27 minutes, sorry [06:09] the buildds seem all busy [06:09] I got the debs, just failed in the end [06:10] pitti: ok, let's see how it goes [06:10] let me check compiz-plugins-main now [06:10] rsalveti: seeing the source, the failure seems to really be due to an interface that compiz proposed that has been removed for unity [06:10] seems that the patch wasn't tested against unity [06:11] that's weird, I know alf tested it with unity as well [06:11] maybe because of an upstream update? [06:11] rsalveti: can be yeah [06:12] rsalveti: however, the first version we had a failure on armhf is not touching the file which is failing [06:12] (and not including it) [06:13] splendid, amd64 builders build three gccs in parallel [06:13] so the only obvious diff I can see between the two builds is this compiz armel patch [06:13] hm, ok [06:13] * rsalveti loves icecc, building compiz in minutes [06:14] I know that ogra_ was fighting with an upstream rebase/update [06:14] rsalveti: yeah, and alf_ reupdated the patch [06:14] maybe something was removed or missed during the patch update [06:14] the patch update was done by alf, so I though he tested it against last unity :) [06:16] compiz-plugins-main also built fine, trying unity now [06:26] rsalveti: unity isn't that fast to build even with icecc, isn't it? ;) [06:26] (and be happy, the tests are not building, which doubles the compilation time ;)) [06:26] didrocks: seems the unity package is not yet enabling gles compatible builds [06:26] not using BUILD_GLES nor USE_GLES [06:27] well, it's a lot better than using one single host :-) [06:27] rsalveti: well, nothing was merged upstream for opengles, that's what I was telling yesterday [06:27] got 5 different machines here [06:27] the support seems to be already avialable at upstream, just not enabled at the package [06:27] let me try to build it with GLES [06:27] rsalveti: ok, keep me posted [06:28] (nobody told me anything about the new option, I thought ogra will take care of this as it was part of the deal) [06:29] nux was still building for GL until yesterday, so that's seems to still be a wip [06:29] the focus was more at compiz, because it needed the extra big patch [06:29] right ;) let's figure unity out now [06:29] if there is an option to enable for unity on armhf, we can do that [06:29] yup [06:29] (as anyway, before, it was simply useless on that arch) [06:30] yeah [06:36] my evo-exchange upload reverts the previous upload which can't possibly work (FTBFS) [06:37] review appreciated [06:40] infinity: if you have a sec, can you please look at evolution-exchange? [06:41] wrt. http://people.canonical.com/~ubuntu-archive/testing/precise_outdate.html, I pinged ev about whoopsie, uploaded fix for evo-exchange, retried network-manager (arch skew), and compiz is needs buildl [06:42] and ran NBS for the old linux bits [06:43] didrocks: compiz built everywhere (in precise) [06:43] didrocks: when that's published, does it make any sense to retry unity, or are you still figuring that out? [06:44] pitti: I don't think so, as the diff of the FTBFS I showed before was with the new compiz (and the armel patch was already here) [06:44] pitti: not yet, it'll fail [06:44] so, two choices from here: [06:44] hm, got the following now: [06:44] ok, so we'll either need a new unity, or revert compiz? [06:44] - either rsalveti enabled the right option in upstream unity [06:44] /home/linaro/compiz/unity-5.8.0/plugins/unityshell/src/unityshell.cpp:610:2: error: #warning Panel shadow not properly implemented for GLES2 [-Werror=cpp] [06:44] and this work [06:44] - either my ppa test build shows that the armel patch is guilty (compiz is still building) and we revert the armel patch [06:44] I think everyone will prefer #1 [06:45] ok, I'll let you guys figure this out [06:45] * pitti toddles off for a bit [06:45] ironically this means that for a week, we couldn't rebuild unity if we needed due to the compiz armel patch ;) [06:46] rsalveti: your warning is happening with the opengles option enabled? [06:46] yup, and it's part of the code [06:46] but it's failing because of -Werror [06:47] so I believe this is expected [06:47] yeah, we try to keep the source cleaned :) [07:03] rsalveti: any progress? [07:03] didrocks: still building [07:03] ok, unity's story ;) building builing ;) [07:10] didrocks: check bug 980544 [07:10] Launchpad bug 980544 in unity "Unity should be built with OpenGL ES2.0 support at ARM " [High,In progress] https://launchpad.net/bugs/980544 [07:10] didrocks: added a debdiff with the packaging changes there [07:10] and finally got it to build here [07:10] with gles we need to use -DDISABLE_MAINTAINER_CFLAGS=ON [07:11] rsalveti: ok, so no additional patch, what about the warning you had? [07:11] ah [07:11] because it's not completely implemented [07:11] you disbale maintainer cflags [07:11] so no Werror [07:11] fine with me anyway, as its on arm only :) [07:11] it's* [07:11] yeah [07:11] rsalveti: need sponsoring? [07:11] arm/gles support is kind of experimental at this phase, so should be fine [07:11] didrocks: yup [07:11] doing then [07:12] didrocks: thanks [07:12] (just changing debian/changeog to target -proposed) [07:12] sure [07:12] ah, rejection before you didn't pick the last changelog, fixing that :) [07:13] there's a new release on proposes, right? [07:13] proposed [07:13] yeah ;) [07:13] done, no worry! [07:13] great, thanks [07:14] thank to you for the quick look :) [07:14] np [07:21] pitti: available and waiting approval ^ [07:21] wohoo [07:22] ok, looks like a no-change for x86 [07:22] indeed [07:22] didrocks: I guess I should wait until compiz is published everywhere in precise? or does it have b-deps? [07:23] (still pending publishing on armhf and i386) [07:23] pitti: maybe better to wait, the armel patch changed. I know there is no ABI change for x86, but as we saw, the armel diff is big ;) [07:23] ok, I'll better wait [07:39] pitti: evo-exchange is straightforward enough. [08:19] didrocks, ouch, i was somewhat relying on upstream to include an arch sepcific default when they included the patch, sorry [08:19] ogra_: no worry, all sorted out now :) [08:19] ogra_: but this whole arm story hasn't been painless ;) [08:19] yeah, i see, thanks so much and sorry again [08:20] didrocks, no, it hasnt, thats why i asked for having all patches ready by last UDS so we could have them in before A1 :P [08:20] well, at least we'll have it in Q [08:20] from the beginning [08:20] ogra_: yeah, it's just the timing which made it worse… but well, it's in now, let's hope that the story in Q will be better :) [08:20] right! [08:47] has final freeze been announced yet? piloting this morning and want to ensure that I'm focussed on the right things... [08:56] didrocks: ok, compiz is published, accepting unity [08:56] pitti: sweet! [08:56] * pitti bumps build score [08:57] We're not in final freeze yet, right? [08:57] we are supposed to be [08:58] Shall someone update the topic in #ubuntu-devel, then? [08:59] * ogra_ guesses once kate gets up we are [08:59] RAOF, there was no official announcement yet [08:59] (unless i missed it) [09:01] cjwatson: should we move linux-ti-omap4 from -proposed to release, or do you want to stage d-i in -proposed for that as well? [09:01] Ok :) [09:01] RAOF: in practice we've been frozen for a week already anyway [09:02] Right, but final freeze changes whether or not I upload this xxi-synatpics [09:02] RAOF, -proposed is open as well ;) [09:16] maas-enlist incoming, basically a Arch s/all/any change. My upload, please can someone else review. [09:17] (also accept the bin NEW's) [09:19] didrocks: meh @ unity armhf FTBFS :/ [09:19] OPENGL_gl_LIBRARY (ADVANCED) [09:19] rsalveti: ^ [09:19] not found [09:20] missing build dep? [09:20] rsalveti: any special build-dep for opengles? [09:20] rsalveti: the compiz-dev and nux are supposed to provide everything [09:20] pitti: ^ [09:20] ogra_: maybe you have a clue on this stack [09:21] didrocks: we'll keep control-center in -proposed until unity and -2d are released, right? [09:21] pitti: yeah, because it's using an unity-2d new gsettings key [09:21] so will crash without it [09:22] I didn't want to put an explicit dep or breaks just for that [09:22] right, that's what I meant [09:23] pitti: ok, I'm not found of to have unity stalled on proposed forever. The deal was that if arm fails because of the linaro patch, we can go ahead and they have to fix it [09:23] pitti: if it's not fixed in one hour, should we revert all the linaro changes? [09:23] didrocks: WFM [09:24] ogra_: in case you didn't see ^ [09:24] i did have a reconnect [09:24] seems i miss the beginning [09:24] You didn't give people much chance to respond. :P [09:24] * ogra_ just noticed that lubuntu-desktop doesnt have armhf support at all :/ [09:25] didrocks, whats the issue ? how can i help ? [09:25] ogra_: At a quick glance, it looks like compiz-dev is missing dependencies. [09:26] hmm, it shouldnt, i used the linaro branches for the deps ... [09:26] Though, maybe not.. [09:26] * ogra_ downloads the source package [09:26] OPENGL_gl_LIBRARY (ADVANCED) [09:26] ogra_: it's unity which FTBFS [09:27] hmpf [09:27] Kay, compiz-dev's deps are fine. [09:27] So, it's the CMake test that's wrong, I assume. [09:27] yeah, can be the CMake one I guess [09:29] * tumbleweed hopes we get a name for Q soon [09:29] Or is the GLES support in Unity not mutually exclusive with GL? If so, then it just needs libgl1-mesa-dev installed too. [09:29] no. it should have the same !armhf/armhf setup as compiz [09:30] ogra_: Kay, then I contend that the CMake test is wrong, and probably looking for libgl unconditionally, even if the source doesn't need it when building for EGL. [09:30] right [09:31] pitti: I see no advantage in leaving the ti-omap kernel in -proposed... [09:31] pitti: We kinda want it for image builds too. [09:32] infinity: right, but it's an ABI bump, so needs to go along with a d-i upload and seed changes [09:32] pitti: Yeahp. [09:33] * ogra_ pinged alf, i think he has a unity packaging branch somewhere [09:35] ogra_: keep us posted, I wanted to have feedback on the upgrade before the week-end, but I guess this won't happen :( [09:36] didrocks, lets see ... i found the linaro packaging branch, doesnt seem it touches any cmake stuff nor deps [09:39] didrocks, hmm, are all compiz builds published already ? could be that compiz-dev is to old [09:39] yes, I waited for that [09:40] (seems the versioned dep is outdated) [09:40] ok [09:40] ogra_: well, it's not a versioned dep because there is no ABI change [09:40] at least on i386/amd64 not sure what happened on arm [09:41] GLES support was added ... i reflected that in the versioned dep in compiz-dev but indeed not in unity [09:41] but if compiz is up to date that doesnt matter anyway [09:41] Well, you can tell from the build log if it was. [09:41] ogra_: right [09:43] (and it was) [09:45] AHA ! [09:45] http://bazaar.launchpad.net/~linaro-maintainers/unity/overlay/revision/20 [09:45] "Disable standalone-clients as it forces opengl (testing related)" [09:46] ogra_: so we will need your quilt hack [09:46] yup, looks like [09:46] for arm only [09:46] ogra_: I can give it a try, but not build to confirm [09:47] apart from pushing to a ppa [09:47] right, let me make sure thats the only missing thing first though [09:47] yep [09:47] did you plan to have that -proposed upload in the release ? [09:48] ogra_: what do you mean? [09:48] or is that a zero day update ? [09:48] ogra_: oh, it's in the release [09:48] ok [09:48] just wanted to know about the time pressure ;) [09:48] well, I guess it's high :p I rushed to get everything in shape yesterday evening [09:49] and hoped I can have a quiet Friday :p [09:49] yeah [09:49] but pinged 5s after connection because of arm :( [09:49] i only noticed it was uploaded to -proposed [09:49] so i thought i'd better ask [09:49] ogra_: yeah, please upload with -v also [09:49] (to include the 2 previous ones) [09:50] anyway, doesnt look like there is anything in the linaro branch that touches any other cmake stuff [09:50] so that bugs are closed when syncing [09:50] so i guess that patch is it, let me add the quilt stuff and to an armel testbuild [09:50] great ;) [09:50] ogra_: Please do test locally in a clean chroot before uploading another FTBFS. ;) [09:50] infinity, indeed :P === debfx_ is now known as debfx [10:13] slangasek: gksudo> you could use something like ubiquity's wrapper that tries to escalate using whatever means is available [10:13] pitti: no point staging d-i in -proposed for ti-omap4, we should just move it [10:13] cjwatson: ack, doing that then [10:22] gah, ricardo made his -Werror dircetly in the code [10:22] +change [10:23] * infinity notes that doing all the proposed->release copies as syncs makes pitti looks very active on -changes... [10:23] I hope in the not too distant future that's going to be done by a bot :) [10:26] what? pitti isn't a bot? how can he possibly achieve that much work then? ;) [10:29] phew, finally building ... [10:29] and passed the error :) [10:29] sweet, let's wait for it to successfully finish building [10:29] indeed :) [10:51] didrocks, do you think we could disable -Werror across the board for the release ? seemingly that option leaves me with a modified Cmake setup, so dpkg-source complains about upstream changes when trying to roll a source package on arm [10:53] ogra_: I prefer keeping -Werror for non arm if possible (and so, please ask linaro to fix the arm case), it saved us from some issues that happened in the pasts [10:53] ok [10:54] i dont think its that important :) [10:55] ogra_: TBH, dpkg-source should already complain when I'm cherry-picking patches from upstream, it just enables us to see what files are touched ;) [10:56] (I bzr merge upstream-branch in packaging branch) [10:58] didrocks, i pushed my changes (UNRELEASED yet) to lp:~ubuntu-desktop/unity/ubuntu/ ... so you could start a PPA build i suppose if you want [10:58] oh crap ! [10:58] hum? [10:58] failed [10:58] ah :( [10:59] ogra_: aren't the linaro guys around to help us on this? [10:59] apparently not [10:59] I'm just about considering reverting if that can't be fixed [10:59] alf is greek ... its good friday in the greek chruch today [10:59] pitti: wdyt? ^ [10:59] * ogra_ found another patch ... gimme a sec [10:59] ok [11:00] ah, no, seems unrelated [11:01] didrocks, would you keep my package changes but drop the patch ? that way we can easily SRU a new patch in ... [11:02] ogra_: I want the release team to agree first, but yeah, dropping the patch and the custom .install file in compiz should be enough, right? [11:02] didrocks, err, why compiz ? [11:02] compiz is fine [11:03] i'm only talking about unity, i would like to have the package prepared as well as we can so i only need to dump that single quilt patch in [11:03] ogra_: no, it's compiz on arm which doesn't provided the opengl-es dep [11:03] ogra_: you are talking about the revert first, right? [11:03] i'm only talking about unity [11:03] ogra_: right, but basically, since you landed the compiz patch a week ago, we can't build unity on armel [11:04] if there need to be fixes in compiz i would prefer to keep them as small as possible ... as long as it builds it wont do no harm [11:04] because compiz is providing opengles build-dep [11:04] so unity has opengles build-dep only on arm [11:04] it doesnt build if you revert the changes ricardo made ? [11:04] hmpf [11:04] ogra_: no, ricardo did those changes because it FTBFS [11:04] right, that was the bit of the conversation i missed above [11:05] * ogra_ curses loudly [11:05] so that would mean: reverting compiz and c-p-m [11:05] the arm part [11:05] yeah, thats a very bad idea [11:05] well, unity can't build for a week since those patches were introduced into ubuntu [11:06] (on arm) [11:06] you didnt tell me ... i thought all was fine (though i also though the unity changes were in since ages since i was told everything for this was done upstream and we wouldnt need to care) [11:07] ogra_: well I didn't know until this morning, remember that you uploaded it in the archive whereas we were testing a newer version in the ppa? :) [11:07] yeah [11:07] so we never got the issue until this morning [11:07] didrocks, do you mind if we wait until ricardo gets up again, probably he has an easy fix in the drawer [11:07] ogra_: let's see with the release team [11:07] I was hoping getting feedback on the new release today [11:08] it survives 80% of the build and fails in a single declaration atm [11:08] but seems that despite rushing and working like mad yesterday, it's not possible [11:08] or we can as well declare the armel image failing to build this week-end [11:08] and copying to the release pocket for now [11:08] i'm really sorry for that, i hinestly was 100% convinced we dont need to touch the unity package at all [11:09] i dont think LP allows that ... we had a similar issue in B2 [11:09] ogra_: no worry, I would have prefered that linaro gave the patch to you sooner and not at the last minute ;) [11:09] ah? [11:09] you need to copy over all arches or you lose [11:09] ok [11:10] intrestingly the build seems to fail in a nux function [11:11] hmm, how did libglu1-mesa end up in the chroot, that cant work [11:12] seems the former nux version pulled that in [11:13] * ogra_ retires the build [11:13] *retries [11:13] :) [11:14] both were valid :p [11:14] haha [11:18] ogra_: https://code.launchpad.net/~linaro-graphics-wg/unity/fix-gles2-build/+merge/101087 [11:18] * ogra_ looks [11:18] I saw that patch pending, told to ricardo this morning that some patchs were not approved (as we agreed) in unity and he answered that nothing was pending for him [11:18] * ogra_ hugs didrocks, thats the one [11:19] well, at least thats the file it failed in [11:19] ogra_: testing with it? ;) [11:19] ok, let's cross fingers [11:19] not yet, let me add it [11:19] ogra_: you can bzr merge it directly [11:19] k [11:19] (as it's an ifdef) [11:20] it that works, I'll accept it upstream, even if that's not what we agreed on first :/ [11:20] yeah, pretty much nothing is ... [11:22] building again [11:37] didrocks: I don't think we can copy unity to precise without completely breaking arm, can we? [11:37] not if the binaries are missing, no [11:37] pitti: no, we can't, let's hope that the branch I pointed ogra too will fix it [11:37] right, we'd potentially end up releasing with NBS [11:37] will break -desktop deps [11:38] * ogra_ is confident the patch will make it work [11:38] I think we should upload a reversion of compiz, then build unity against it, move both to release [11:38] and then we can re-stage compiz/unity with gles in -proposed [11:38] build is at 34% [11:38] pitti: it's compiz, compiz-plugins-main, nux and then unity [11:38] pitti, that measn SRUing a 300-400k patch [11:38] so not that straightforward :) [11:38] *means [11:38] i would love to avoid that [11:39] well, if you SRU something that jst enables a 300 k patch in debian/patches/series, the net effect is the very same [11:39] SRUs are bound by regression potential, not primarily by patch size (although the two certainly correlate) [11:39] its also package changes that have to be reverted across the chain ... [11:39] (and re-enabled for the SRU) [11:40] well, other suggestions appreciated [11:40] pitti: I pointed ogra to an unity patch that can help [11:40] but we are supposed to have a releasable image since today, and right now we don't [11:40] i would really prefer to get it into a building state now ... keep possible fixes for SRUs then [11:40]