[04:50] are we frozen already? [05:04] still trying to get the verdict on mesa [05:08] slangasek: ping? [06:18] infinity, cjwatson: can either of you take a look at mesa? the new version has seen a lot of testing during the past few weeks (and months before that on a smaller scale) as pointed out on the ffe bug [06:24] tjaalton: I'll have a look. Point me at the bug again? [06:24] infinity: thx, https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1164093 [06:24] Launchpad bug 1164093 in mesa (Ubuntu) "FFe: new upstream release 9.1.1" [Wishlist,Triaged] [06:31] whoa :) [06:31] tjaalton: I'd already gone over the source diff a few times in the last day or two. Just needed to look at the testing trail on the bug to make a decision. [06:32] tjaalton: So, thanks for being verbose. [06:32] tjaalton: And please do watch very closely for regressions in the next few days. [06:32] infinity: sure thing, we'll (ab)use the awesome balloons again in the future for point-releases too :) [06:33] and yeah, mesa is top-priority now [06:33] there's 9.1.2 in the works, so the stable branch might have cherry-pickable stuff until we sru the point-release [06:34] Oh bah. And this pulls llvm-3.2-dev into main. [06:35] hmm [06:35] it wasn't already? :/ [06:36] Nah, 3.1 is. Not that I'm against moving to 3.2 [06:36] if it wasn't so late I'd push glamor-egl (new) for newer radeons too [06:36] Curious if mesa is the only rdep of either. [06:36] I think it is actually [06:36] Yeah, it is. So this is a simple flip. No big deal. [06:36] phew [06:37] * infinity promotes 3.2 and lets the world sort itself. [06:38] Actually, that brings mesa in line with llvm-defaults and clang. [06:38] Maybe we can start dropping old llvm versions. [06:38] \o/ [07:04] tjaalton: ... was this not tested in a devirt PPA? :/ [07:04] tjaalton: It's FTBFS on powerpc. [07:07] hrm [07:07] (A good reason to push this stuff to experimental too, it's good to get all-arch build test coverage) [07:08] it was on two separate ppa's, but neither had powerpc [07:08] the debian-x folks are busy with getting wheezy out :/ [07:08] Sure, but one could still upload a mesa to experimental, surely. [07:08] there wasn't an upload of 9.0 either [07:08] Anyhow, no big deal. Just need to fix it. [07:09] right.. [07:09] I can look at it in the morning. [07:09] Or give you a PPC machine to play with tonight. [07:09] yeah [07:09] gimme [07:10] could be one of the additional lib trickery patches by mlankhorst broke it, I'll let him have a look [07:12] tjaalton: Oh, I took your "gimme" at face value and was setting you up on a host here. :P [07:12] heh, that's ok [07:12] I guess this is something dead-simple anyway [07:13] probably building too much on ppc [07:13] Grr. Why does this machine come up in 1930? [07:13] And, more importantly, why does dhclient flip out about that? [07:14] (Which leads to no IP, which leads to no ntpdate, which leads to...) [08:02] infinity: ghc's still stuck on llvm-3.0, I fear, though hopefully that'll be sorted out in the next mega-transition ... [08:04] cjwatson: Right, but I don't think anything wants 3.1 anymore. [08:04] cjwatson: So, maybe we can keep 3.0 and 3.2. [08:05] erk, kapok dead in an RT-requiring way says #webops? [08:05] not that I can find the ticket [08:06] * infinity taps his foot waiting for this mesa test build on leviathan to finish. [08:10] tjaalton: Looks good. Want to double-check file lists at the end of the build log look sane and upload ASAP? [08:10] infinity: yep [08:54] infinity, still awake ? [08:54] ogra_: Not that I'm willing to admit to. [08:54] heh [08:55] so now thgat i slept (or rather didnt) sleep over it, i think packaging it is as insane as using a livefs builder ... we should have a dedicated android cross build machine i think [08:56] Why? [08:56] Using the package builders is an effective re-use of resources. [08:56] A dedicated machine would be idle half the time. [08:56] because it will eb really hard to automate and to just quickly shove 2G around [08:56] more than half [08:57] but we will also build a lot more images in the future on it [08:57] And if we're generating binaries that we're shipping to people, we need to be able to provide the matching source. [08:57] thats on phablet.u.c already [08:57] (Sure, that can be done via other methods, but the archive works well for that) [08:57] i know that the archive works well [08:58] but you still force someone to shovel 2.1G through the net for every build [08:58] its not like it needs to be an overly expensive machine or anything [08:59] http://phablet.ubuntu.com/export/ has snapshot tarballs now ... [08:59] every new device will add to that and there will very likely be more over time [08:59] Alright, but that's not forcing any uploader to jam 2.1G across their link then, is it? [08:59] so we might end up with 5G or so ... thats just crazy for moving it around [08:59] You can build a source package remotely, and sign the .dsc and .changes locally. [09:00] well, if you only rebuild when git changes it means you need the new upstream tarball for every build [09:00] Yeah, it sucks if you want to test-build, but you can do that with a local git clone as an approximation. [09:00] not talking about tests [09:01] a standard change in git will force you ro a new upstream tarball [09:01] That's not true, that depends on how you package it. [09:01] unless yu want to pile up patches and merge them every now and then [09:01] you need regular upstream pulls [09:01] Your orig could be an export based on the 4.2.1 tag (or whatever), and you could ship a git-updates.diff patch. [09:01] (eglibc is packaged this way) [09:03] still, that stuff is not designed like being packaged, its a cross build tree and i would prefer to just have it cross built on a dedicated machine ... [09:03] it ends up to be a hell of a package and even if you package it with multiple tarballs you will have to merge regulary [09:04] even if you would do one tarball per git repo ... you will have to regulary upload the whole thing at times [09:05] no matter how you twist it, its 2G+ of data [09:06] (seems kapok took it swerious yesterday though .... its still not back) [09:06] -w [09:08] I think it's unlikely you'll get a dedicated machine; IS budget is very very very squeezed [09:08] My understanding is that for anything new it's canonistack or go home [09:10] And Ricardo's numbers indicated more like 1G than 2.1G (that was for source, but it's rare that binaries come out significantly bigger than source) [09:10] cjwatson: http://phablet.ubuntu.com/export/ came out to 2Gish. [09:11] (Though xz instead of bz2 could potentially shrink that a fair bit) [09:11] That might include some bits rsalveti was planning to cull, though. [09:12] Including prebuilt toolchains... [09:12] Man, this stuff is a mess. [09:13] cjwatson, see the tarball [09:13] its android ... [09:13] we should simply treat it like that [09:18] Well, OK; but you still don't need to transfer binary components across the network to the livefs builder for bits of the source you don't build. [09:18] yeah [09:18] but they are massively smaller [09:19] http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/current/ [09:19] Ricardo's numbers from last night don't really support "massively". Somewhat, maybe. [09:19] its all the armel files [09:19] Unless you mean that the binary components we need to transfer around are massively smaller. [09:19] yes [09:19] Right. So that's not really shovelling lots of data around all that often, then. [09:20] i need the source first [09:21] and i would prefer if that wouldnt have to leave the datacenter for building [09:22] No reason it should. [09:23] * ogra_ is just downloading the tarball locally here for test builds ... 2h+ [09:23] This was why I suggested a pristine-tar/get-orig-source type thing. [09:23] Locally, you should just have a git clone. [09:24] ogra_: 12.3MB/s in 2m 53s ;-) [09:24] As for how much data is shoved around the DC for builds, surely a 2.1G orig beats a 15G git clone (which is the current method). [09:24] xnox, :P [09:24] oh, no doubt in that [09:26] though i'm not sure it will just work without networking since you need to do a repo sync first to make the brunch tool happy [09:26] (i'll see in 2h) [09:26] one can totally rsync .repo off somewhere. it just works =) [09:26] Surely that can all be done as part of preparing the source before building the source package? [09:26] (and indeed lillipily cant see phablet.u.c so that i could play in the DC) [09:27] imho one actually just needs .repo as that's where all the git repos are and one does a "repo checkout" to unfold a working forest of git trees. [09:27] infinity, yes, my concern is what repo sync does ... i might end up with a 5G tarball in the end :) [09:27] adjust manifest for source-builds to exclude pre-build toolchain and et.al. as was suggested yesterday. [09:28] which would make the whole effort moot [09:28] ogra_: http_proxy=http://squid.internal:3128/ [09:28] xnox, we cant exclude the toolchain ... which one would you use then (ubuntus doesnt work) [09:28] or is this git protocol rather than http? [09:28] cjwatson, ! [09:28] for the tarball its just http :) [09:29] ogra_: ah, ok right. I'd upload toolchain separately as a separate package, as I don't think it moves as fast as daily android builds. [09:29] * xnox "don't think" as in "would not expect" [09:29] Hmm, doesn't seem to work through squid.internal either. I think that's RT-worthy [09:30] porter-amd64 gets a response through squid.internal but it's 403 [09:31] * xnox we could have https git repos.... with reasonable performance these days via smart git protocols [09:36] lillypilly doesnt even seem to get a response [09:38] Proxy request sent, awaiting response... 504 Gateway Time-out [09:38] 2013-04-17 09:36:40 ERROR 504: Gateway Time-out. [09:38] there we go [09:41] Riddell: If you're going to make smokeqt build-dep on qwt5, were you planning on filing an MIR for the latter? [09:44] hmm, same thing from nusakan ... i thought we had a resolved RT that allows it to see phablet.u.c [09:45] but that was probably only kapok [09:47] infinity: oh, ug [09:47] cjwatson: xnox: not sure if you already know about amd64 raring server image: http://cdimage.ubuntu.com/ubuntu-server/daily/pending/report.html [09:47] psivaa: the builder machine is dead [09:47] psivaa, the livefs builder is dead ... [09:47] webops is on it (at least i hope there was a proper handover to the next vanguard) [09:48] Riddell: Or you might just want to revert that upload, given that we're a day from final freeze. [09:49] yes, I might [09:49] cjwatson: ogra_ ahh ok, thanks [09:52] infinity, cjwatson: please review the icedtea-web upload, security related release [09:54] * infinity was hoping to see " * SECURITY: Stop allowing Java to run in browser plugins." [09:58] tjaalton, infinity: I don't know who did promote llvm-3.2. if the desktop teams wants to support 3.1 and 3.2, fine with me. but it won't be my task ... [09:59] doko: I promoted it so mesa can build, once it migrates, 3.1 should be able to demote (or be removed). [10:33] * ogra_ twiddles thumbs watching the 2G drip through his DSL [10:36] ogra_: $ du --si phablet-ubuntu-20130417.tar.xz [10:36] 1.4G phablet-ubuntu-20130417.tar.xz [10:36] that's with -9 and extreme compression algo. [10:36] yeah [10:37] still way to big imho [10:37] but good to know we save 600M [10:37] ogra_: it would be nice to cut out some cull that was proposed yesterday, maybe we can get down <<1GB with xz then. [10:37] cut out what exactly ? [10:38] (we will rather add a few G over time ... ) [10:44] * xnox vaguelly remembers something mentioned last night. Maybe it was "cut out toolchain" when discussing some alternative plan. [10:46] xnox, the toolchain is built during the process .(like everything else of teh OS) .. while it might be possible to cut it out it wont gain us much and just add maintenance overhead imho [10:47] i see. [10:48] we could re-introduce armel and package the whole :) but that will take months i guess [10:48] (the whole in proper abndroid packages) [10:49] We have an armel cross-compiler in the archive ... [10:50] with bionic toolchain ? :) [10:51] ... maybe not [10:51] i know what we have and i know all that might be better to be done properly in lots of singel packages etc ... but getting the source to that point would cost us more time than we have [10:52] and given how temporary all that stuff is yet i doubt it would be clever to invest much time into modifications today [10:55] On the other hand the attempt to do all this on kapok has apparently broken our ability to build amd64 images a week in advance of release ... [10:55] yeah [10:55] Which isn't exactly ideal either [10:56] i honestly didnt expect that, sorry [10:56] RT#60878 is opened ... [11:23] yay, download done [11:27] cjwatson, could you have a look at python2.7? brings all the changes from the last python3.3 upload, plus (hopefully) error free autopkg tests [11:30] Looks fine, thanks [11:50] wow, even unpacking on my fastest SSD takes 10min [11:59] * ogra_ amusedly watches it building chromium libssl and busybox ... [12:00] hmm, i wuld have put my bets on it being faster to build than to unpack ... but seems i would have lost [12:01] ... wpa_supplicant ... [12:01] *twiddle* [12:01] oh, openssl *again* === cjohnston_ is now known as cjohnston [12:05] and there we go ... 12min for building ... [12:05] (10 for unpacking) [12:06] so now ... how do i add multiarch build deps to a package ? [12:06] since it needs a lot of mixed i386/amd64 stuff [12:07] ogra_: not supported as far as I know =) [12:08] oh, lovely ... so we can trash the idea or i hack around it by stacking chroots and scripted hacks [12:08] sigh [12:09] we don't have :native. I guess if you are building $ dpkg-buildpackage -ai386 on the amd64 machine, then "Build-dep: foo:any, foo" will give you i386 & amd64 versions...... but you cannot e.g. "Build-dep: foo:i386" [12:09] ogra_: pre-installing build-deps is the way to go =/ [12:10] i had to do it for libnih. [12:10] preinstalling ? [12:10] from an included script ? [12:20] ogra_: well in my case I had an sbuild chroot variant with a few things installed. [12:20] well, my package needs to build on a std amd64 builder [12:26] cjwatson, same please for python3.3 [12:32] doko: done [12:48] ogra_: xnox the toolchain used to build android is a linaro toolchain, prebuilt [12:49] * sergiusens says sorry for eavesdropping [12:49] sergiusens, ah [12:49] well [12:49] http://phablet.ubuntu.com/gitweb?p=platform/prebuilts/linaro-4.7.2.git;a=summary [12:49] sergiusens, it needs bionic support though, no [12:49] sergiusens: hola =) it's the full bionic based? [12:50] * ogra_ really wonders what all these mp4's in the android tree are and why we ship them [12:52] thats easily 100M we could save [12:52] ogra_: not really sure about the bionic stuff [12:52] ogra_: I can strip those [12:53] /frameworks/base/media/tests/contents/media_api/videoeditor/ is full of them [12:53] ogra_: we only ever had a git repo we could use in March, before that we had the full tree and applied patches ;-) [12:53] /frameworks/base/data/videos/ too ... and there are even some in the docs [12:53] yeah [12:54] sergiusens, not sure you got the news, but using the livefs builder doesnt work for building [12:54] ogra_: good, now you hace a necessity for me to work on that, I'll get working on making the repo leaner [12:54] ogra_: no I haven't [12:54] my build attempt killed the amd64 builder badly enough that it is still not back up again [12:54] so suggestion is to actually roll a package [12:55] from a daily export from http://phablet.ubuntu.com/export/ [12:55] (which ricardo set up last night) [12:55] and have the package spit out the right binary images which we can then just pull into a live-build build [12:56] sergiusens, ogra_: so why use yet another gcc? [12:56] doko, android requires it [12:56] it will likely not stay like it is today after all though [12:56] ogra_, but it's the linaro one [12:56] linaro-bionic [12:57] i dont think the toolchain has much effect in the tree ... size wise [12:57] is this patches on top of gcc-linaro? [12:57] that we cross build a whole OS with all its deps has though [12:57] doko, no idea [12:57] yeah [12:57] i'm sitting at the end of the chain here and just try to produce images before S opens [12:58] from the giant tree i'm given :) [12:58] that it is all armel and needs a mixed x86/amd64 build env doesnt help much either :) [12:59] but well ... shrug ... android ... [13:00] it is like it is [13:02] (i would just prefer to just build it as intended by its creators though) [13:09] hmm, how is haskell-platform missing from raring even though there is no mention it having been removed? https://launchpad.net/ubuntu/+source/haskell-platform/+publishinghistory [13:11] Mirv: did you check the binary publishing history as well? one can remove binaries without removing source package. [13:12] Mirv: see https://launchpad.net/ubuntu/raring/amd64/haskell-platform [13:12] clearly removed with a comment and bug reference. [13:12] xnox: awesome, thanks.. I've always lived in a +source world in LP before this [13:13] funny. I need to bookmark that in order to remember that part of LP existing. [13:13] Mirv: it's a brave new world! [13:13] * xnox usually fiddles with the urls. [13:13] starting from the: http://pad.lv/u/$srcpackage [13:14] ogra_: sorry, internet crashed... [13:15] ogra_: so why can't you build is as intended by _it's creators_? [13:16] sergiusens: no place to do it securely. [13:16] ogra_: we do scp wubi from ev's machine & publish onto CDs =))))) [13:16] which is like uber-secure =) [13:20] xnox: does that require /win 15 [13:20] meh, sorry [13:21] sergiusens: one needs to become evalicious first =) [13:21] haha [13:22] well, i would just do it on lillypilly ... if i could actually get the source over somehow [13:22] it isnt like the build is massively demanding or so [13:23] its just the gigantic source tree thats disturbing [13:24] Please don't build stuff on lillypilly [13:24] i would even do it in my home on nusakan ... but same issue there and beyond that i dont want to make cjwatson grumpy [13:24] Use a porter box if you must [13:24] (porter-amd64) [13:25] You can bounce files around within the DC with nc, even if there isn't a direct path [13:25] hmm [13:26] is the porter box suitable for doing automated stuff (possibly several times a day) [13:27] * ogra_ always thought it was only for one time things like porting stuff :) [13:27] ogra_: can't we keep on using our ps-jenkins? Or does that not meet security requirements either? [13:28] sergiusens, i'm close to propose that yeah ... (i actually did to infinity yesterday when he came up with all that) [13:29] sergiusens, the point is that the cdimage team needs to be able to trigger it and that it needs to be chronnable once we build the rootfs in the cdimage infrastructure [13:31] ogra_: well, the jenkins thing is the cron we use, but it can be anything [13:31] and iit is currebntly a black box from cdimage POV [13:32] ogra_: well we can change that :-) [13:32] ogra_: so the limitation is not hardware, but more so networking in your DC? [13:32] no, the limitation is actually hardware ... (imho) [13:32] if i would have a choice we would just have a dedicated android build machine [13:33] but that costs money which doesnt seem to be there [13:34] ogra_: oh... that's too bad... well we should work on consolidating infrastructure [13:34] so the alternatives are: package builders (meaning someone has to regulary re-roll the source package with fresh tarballs) ... porter-box (same issue, and i dont think it is desired to use it for automation) or ... keep it at jenkins breaking the cdimage workflow and control [13:35] ogra_: the porter box is strictly less unsuitable than either lillypilly or nusakan :-) [13:35] sure [13:35] But it's probably still basically unsuitable [13:35] but its still not thoguht for doing daily image builds [13:40] ogra_: does cdimage workflow mean that cdimage triggers the build, or does it imply more? [13:40] it means that the cdimage team has control over the machines building as well as the code producing the builds [13:57] xnox: technically, there's nothing preventing you lot from doing wubi builds. You just have to update cdimage to look somewhere other than my public_html directory. [13:58] Yeah, but we do need to know we're doing them in a reproducibly similar way [13:59] Sure [14:00] hi everybody, any news on the FFe for this bug? https://bugs.launchpad.net/unity-lens-music/+bug/1168674 [14:00] Launchpad bug 1168674 in Music Lens "Purchased songs won't download when not logged to U1" [Critical,New] === hggdh_ is now known as hggdh [14:15] alecu: Hey, looking [14:15] can this go today? [14:16] Laney: no, tomorrow, the datacenter is broken for running autopilot tests and it's currently being fixed [14:16] wah [14:16] before Final Freeze then? [14:16] Laney: hardware failure… [14:16] :-) [14:16] yeah, that's why I put pressure that it's done before FF ;) [14:16] Final* [14:17] still a review to sort out on the unity branch anyway it seems [14:17] Laney: right [14:17] Laney: so you can give a conditional +1 if you want, then I think alecu needs to have merged it today, before 00 UTC [14:17] that's the condition, I was quite clear with him about it :) [14:18] commented [14:19] thanks Laney [14:19] alecu: now get it fixed/reviewed/merged before 00 UTC ^ :) [14:20] why 00 ? freezes are traditionally on thursdays at 21:00 [14:20] plenty of time :P [14:20] ogra_: you need to build the whole stack [14:20] ogra_: have tests running [14:20] ogra_: this is before the upload [14:20] ah, long build, k [14:20] well, if the hardware remains broken it'll be a manual upload [14:20] but yes [14:20] Laney: the hardware is the hardware to *test* it [14:20] Laney: so no, if the hardware remains broken, we won't know the test status [14:21] sure [14:21] so it's rather no upload than upload with no tests? [14:21] nothing to do with daily release/manual uploads [14:21] Laney: right [14:21] even though it's a "Critical" bug [14:21] ... [14:21] Laney: well, it's in quantal TBH, so I don't agree with the urgency definition [14:21] but that's another story ;) [14:21] (and it's known for months by design) [14:22] but still good to have it fixed in raring [14:22] hrm [14:22] yet only filed 4 days ago [14:22] Laney: talk to design and their bugs handling :p [14:23] could you lower it? [14:23] to be fair they hoped to have it fixed by the "buy in the dash" feature [14:23] Laney: I think high will make more sense [14:23] which didn't land at the end [14:23] I don't like severity inflation on release bugs - makes me feel like I'm being pressured into approving [14:24] Laney, johnlea will start arguing with you over the bug importance I'm sure ;-) [14:24] Laney: High it is :) [14:24] haha [14:24] thanks didrocks [14:24] Laney, the bug leads to have the money taken from users' bank account and not get the song they bough downloaded in exchange [14:24] yw ;) [14:25] Laney, which you can argue over the importance, but would be good to be fixed ;-) [14:25] pfft, whiners ... we'll send them a reciept for their tax declaration in return [14:25] ;-) [14:25] if we wouldn't upload out of process to fix it then I can't say that it's critical [14:25] maybe it's a case for distro/upstream importance though [14:26] * Laney moves on [14:26] anyway, alecu will get it in a mergeable state, and we'll have the hardware replaced today :) [14:26] so everything's fine [14:29] oh, friends has the fix for notification spamming [14:29] popey will be pleased! [14:30] \o/ [14:31] there's only so many times I can see "Happy birthday Alan" from my cousins [14:32] it seems slightly curious that it doesn't consider whether you've seen the notification before [14:32] it just says "no notifications older than 5 days" [14:32] robru: ^? is that accurate? [14:42] Laney, it is accurate [14:42] * Laney nods [14:42] Laney, friends doesn't keep track if notifications have been seen or not, so to prevent spamming the user he limited it to the past 5 days [14:42] kenvandine, so you will still get 5 days of backlog display every time? [14:42] no [14:42] it is just the first time the service starts [14:43] I thought some people were complaining that they saw them at every startup [14:43] it only notifies for new content downloaded [14:43] the every startup was fixed separately, i think [14:44] it caches what has been downloaded and doesn't download new content again [14:44] so shouldn't notify for that [14:44] alright, well I never saw it myself anyway [14:44] but on first run you would get notifications for private messages and mentions from long ago... maybe even years :) [14:44] I think popey was affected, hence the ping earlier, so maybe he can say if it still happens [14:44] if i use it for twitter in a guest session i got notified for private messages from 3 years ago :) [14:45] \o/ [14:45] not useful :) [14:45] next cycle we want to implement a queue of some sort [14:45] * popey updates [14:45] same for errors [14:45] so the UI can also present some of it [14:45] and ack them [14:45] etc [14:46] * Laney petitions for twitter "list" support [15:02] Laney: yeah, upon first upgrade I got popups for every @ mention I ever had. Since I'm a very active twitter user the total amount of popups was 8 bubbles. [15:02] but I haven't seen anything since..... [15:03] that's alright then - IIRC some people reported getting them again and again but if that's fixed then cool [15:06] Laney, didrocks: thanks! [15:07] ogra_: sergiusens: xnox: as I said yesterday, we can remove quite a few files there, like docs, video, kernel sources duplicates and such [15:08] the work I did yesterday was just to dump the stuff at this point, we can work cleaning it up a bit at least [15:08] rsalveti, right, i noticed that when unpacking here [15:08] also xz would help a lot [15:08] i guess we can melt it down to ~1G compressed [15:09] ogra_: yup, can easily change here [15:09] xnox: what compress options did you use? [15:09] it builds just fine btw [15:09] at least mako [15:09] ogra_: yeah, cool, built for mako and manta here [15:09] didnt try others but i dont expect them to be different [15:09] ogra_: also, see that platform-api and hybris is not there by default [15:10] rsalveti: -9e, that is maximum extreme compression, but without my host CPU specific optimisations. [15:10] rsalveti: doing it as we speak... [15:10] rsalveti, ow ... how do we handle that [15:10] ogra_: because they are from bzr [15:10] check phablet-dev-bootstrap [15:10] right [15:10] we basically clone that after cloning the tree [15:10] so you'd need to do something similar [15:10] hmm, that would have to become part of building the source package then [15:10] sergiusens: cool, let's sync then after the call [15:11]