[01:01] anybody from the release team around/ [01:28] ScottK: so, I looked at php-codecoverage, apparently, the version in precise requires an earlier version of php-codecoverage, the dependencies of that should be backportable hopefully... [01:28] *version of phpunit in precise [01:28] the alternative would be to backport the newer version of phpunit as well [01:29] it has 2 rdeps though, so I'm not sure I want to do that [01:36] When it was all new packages to fix the bug, I was comfortable. [01:36] If it's updating existing packages with rdeps, that's different. [01:36] micahg: How about fix it backports and then see how it goes. [01:38] ok [06:49] +debootstrap --omponents=ain,universe $release $builddir $MIRROR [06:49] ogra_: ^- really? :) [06:50] (two typos) [07:45] hum, nobody U.S based reviewed the unity stack during the night :-( [07:45] can we get somebody reviewing those this morning? ;-) [07:45] Laney, ^? [08:01] seb128: yeah sure [08:01] Laney, thanks [08:37] cjwatson, wow, no idea how that happened, before adding $MIRROR to that line it had no typos (i still have the pastebin here) === doko_ is now known as doko [09:10] cjwatson, fix uploaded ... (thanks for spotting) [09:44] ogra_: is there a specifc reason to mix mount/chroot mount in livecd-rootfs? [09:45] mix ? [09:45] ogra_: you mount devpts from outside the chroot, then mount proc and sys from within [09:45] ah, that ... i wasnt sure if there isnt something looking at mtab [09:46] so i always make sure to mount proc and sys inside ... while i dont care for devpts apart from it being writable [09:46] old habit :) [09:47] ok :) [09:47] ogra_: build-android.sh uses /bin/bash because there are bashisms in what it sources? [09:48] yeah :( [09:48] especially about 1300 lines of arrays [09:48] i tried to make the android build system POSIX but gave up at some point [09:49] ok... unlikely to make any significant difference on a long build like that anyway [09:49] yeah [09:49] well, it isnt long ... takes ~20min ... but its big (the source tree is 15G) [09:51] ok, only other potential problem I'm seeing is the rm -rf still happening if one of the umount fails, though it shouldn't cause any dammage even if that happens (you can't rm stuff in proc/sys and devpts is a clean instance) [09:52] yeah ... well, it might block ... i'll add an -l to the umount in a later upload [09:53] ogra_: I think we'd want "umount ... || (echo "Failed to cleanly umount ..." && umount -l ...)" so we have a trace of what happened [09:53] anyway, that's fine for a latter upload [09:53] yeah [09:53] let me get at least one image out of it first :) [09:53] optimizationcan always happen later [09:54] thanks ! [09:54] np [11:00] * cjwatson finds a stale lock that was stopping the seed mirrors from updating for the last eight days - that probably caused an assortment of random weirdness [11:00] including, certainly, component-mismatches madness [11:00] images probably weren't affected as they're configured to prefer using bzr directly [11:42] Ursinha: I've finally got round to sorting out the code for the extra germinate run and thus have deployed http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt - thanks! [11:47] perl: warning: Setting locale failed. [11:47] perl: warning: Please check that your locale settings: [11:47] LANGUAGE = (unset), [11:47] LC_ALL = (unset), [11:47] LC_TIME = "de_DE.UTF-8", [11:47] heh [11:48] calling BuildLiveCD directly on nusakan ... i guess i should force LC_ALL to C in the script :) [11:50] * ogra_ wonders about the ton of autoremovable packages in the log ... thats weird [11:51] bah [11:51] and mount doesnt get along with $builddir-proc [11:52] sigh [12:01] and anothe upload ... [12:01] +r [12:02] :/ [13:01] slangasek: ^ [13:02] slangasek: uploaded mesa to raring, all testing seems good, FFE bug description updated to match https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1164093 [13:02] Launchpad bug 1164093 in mesa (Ubuntu) "FFe: new upstream release 9.1.1" [Wishlist,Triaged] [13:26] Has anyone filed an LP bug about the difficulty of getting hold of diffs / original source for copies? [13:27] (When they show up in queues) [13:27] Ah, of course, asking about it caused me to find it. Bug 851562 [13:27] Launchpad bug 851562 in Launchpad itself "Diff's not available for sync's on +queue page like for regular uploads" [High,Triaged] https://launchpad.net/bugs/851562 [13:29] is there some other tool also called queue? [13:29] when I searched for this before I found bug #924537 [13:29] Launchpad bug 924537 in Launchpad itself ""queue fetch" requires a changes file which copies sometimes lack" [Low,Fix released] https://launchpad.net/bugs/924537 [13:32] Laney: that's the old one that used to be in LP and run from the archive master system [13:33] so it poked internal APIs presumably [13:33] Laney: once I got the API version working, I killed the internal one [13:33] Laney: Yes [13:33] if you're fixing stuff in this are, can you make the PPA name into a link to the PPA too? :-) [13:34] Laney: See my question in #launchpad-dev 12 minutes ago ... [13:35] cjwatson: excellent [14:23] cjwatson: hi, would you please help us check the FFE of #1169525 and 1169517? [14:25] If ~ubuntu-release is subscribed, it's in the queue [14:30] cjwatson: well, thanks. it seems that 18, Apr is the deadline. [14:38] thanks ! [14:40] JackYu: well, approved, although to be honest I don't think those needed feature freeze exceptions [14:42] JackYu: I don't think the core ubuntu-docs show Kylin UI, but if you have any of your own screenshots and such then obviously they'll need to be updated [14:43] cjwatson: thanks. [15:09] cjwatson, \o/ thanks :) [15:21] Laney, can you review gvfs in the queue? the diff is non trivial and I would prefer it to be reviewed rather than earlier and while I'm around to answer questions [15:22] Laney, https://git.gnome.org/browse/gvfs/log/?h=gnome-3-8 might be useful to see the list of changes [15:22] Laney, the changes from alex should avoid quite some segfaults we are receiving [15:23] seb128: sure, will look at it [15:23] Laney, thanks === mbarnett` is now known as mbarnett [16:08] * ogra_ twiddles thumbs ... come on publisher ... [16:08] i wonder why BuildLiveCD doesnt send mails for my failing build attempts [16:08] (i'm happy it doesnt spam the world, but curious why it doesnt) === iulian is now known as Guest6437 [16:40] ARGH ! [16:41] mkdir -p $builddir/dev/pts [16:41] .... [16:41] mkdir: invalid option -- 'b' [16:41] Try 'mkdir --help' for more information. [16:42] i dont get it [16:42] builddir=$codename-build .... [16:42] $codename is "mako" [16:43] ref to full log? [16:44] kapok.buildd in the mako-android dir under raring [16:45] and the last BuildLive.out indeed [16:46] $codename comes from $1 ... which effectively is $SUBARCH in the calling script ... [16:47] codename=$1 [16:47] builddir=$codename-build [16:47] So you'll get that if $1 is empty [16:47] yeah [16:47] but $1 is obviously mako ... else i wouldnt have the sruff ending up in the mako dir [16:47] Are you sure -s is being passed? [16:48] ph sigh [16:48] *oh even [16:48] mako is ${FS} surely? [16:48] ssh -n -o StrictHostKeyChecking=no -o BatchMode=yes buildd@kapok.buildd /home/buildd/bin/BuildLiveCD -d raring -t android -r android mak [16:49] thats how i call it atm [16:49] and yeah, i didnt call -s [16:49] silly me [16:50] cjwatson, thanks ... [16:50] lets try with just adding -s [16:50] Consider whether the right answer is to use -s or to pass ${FS} instead [16:51] If you pass -s mako then you'll get mako-android-mako [16:51] Which is pretty weird [16:51] thats fine for now [16:51] but yeah i will surely need to tweak that stuff a bit ... [16:51] for now i just want to see the sub script working [16:51] Sure [16:53] bah, and now i ended up in the queue ... [16:54] * ogra_ goes to look for dinner [17:00] hi, I'd like to ping this channel regarding https://bugs.launchpad.net/unity-lens-music/+bug/1168674 [17:00] Launchpad bug 1168674 in Music Lens "Purchased songs won't download when not logged to U1" [Critical,New] [17:19] hmm [17:20] i wonder what the HW specs of kapok are ... i kind of assumed it would at least be as powerful as a std desktop ... [17:20] seems my build started but it has probs ot answer http requests [17:21] ah, no, its still the former build === james_ is now known as Guest69845 [17:53] infinity, do you happen to know what HW specs kapok has ? [17:53] it seems really slow even when only building normal livefses ... [17:53] * ogra_ starts to doubt it was a clever idea to use it for cross compiling [17:54] It should be a reasonably beefy DL380 G5 or G6, I assume. [17:54] But we probably shouldn't be compiling on the livefs builders... [17:54] well [17:55] we want to do it from cdimage builds [17:55] Is there a reason we didn't just package this, so you can build once on a buildd, then pull the binaries into your image build? [17:55] err [17:55] its a 15G android source tree [17:55] you dont want to package this :) [17:55] Smaller compressed, I assume. :P [17:55] it is what generates the HW layer of ubuntu touch images [17:55] I'd rather package it than rebuild it every day for no reason. [17:56] yeah, i dont plan to rebuild it unconditionally [17:56] but atm the tree needs a multiarch capable amd64 to even build ... and you can not just pull parts of it but need the full thing locally to roll the "hwpack" [17:57] I still question the absolute truth of the first bit. [17:57] Needing the full thing is fine. And I get a shallow export is smaller than 15G (and much smaller compressed). [17:58] s/get/bet/ [17:58] it builds a full OS [17:58] Sure. [17:58] armel also :) [17:58] But if you're saying the git clone is 15G, I'm saying an export is much smaller. [17:58] That's just how VCSes work. [17:59] the only thing you gain when doing an export is that you doknt transfer the three other kernels for the arches you currently dotn build [17:59] thats in max 500M [17:59] the rest is all OS stuff you need during the build [18:00] including all deps [18:01] anyway, i'm not really concerned by the disk requirements ... i'm confident there is enough diskspace [18:02] but seeing the behavior of the machine while just rolling a rootfs image and not even answering to http requests for minutes makes me worry [18:06] ogra_: I think you're not understanding what I mean by export. [18:07] infinity, apparently not ... i just know what it does when it builds ... it compiles the whole dependency chain like gentoo [18:07] and it needs the full tree for this [18:07] Yes, but it doesn't need the history. [18:08] transferring the 15G from onbe machine in the DC to another isnt really an issue imho [18:08] (probably muddies the waters that, unlike cvs, bzr, or svn, git doesn't have an "export" command, but it does have "archive") [18:08] ogra_: No, but if we were to package it (as I'm suggesting), it should be a shallow export/archive, not 15G of uselessness. [18:08] and it needs the history for generating the chabnbgelog we ship alongside the images [18:08] ogra_: And I still think packaging it is the sane thing to do. [18:09] how do you package a whole OS ? [18:09] Eh? [18:09] You build the bits and put the result in a deb that you later download and tear apart? [18:09] No different than asking "how do you package a bootloader that you intend to use later on cdimage?" [18:09] it is the android layer ... it spits out four img zips and needs to work with the android update/flash mechanism [18:10] And we don't cross-build u-boot for every ARM image build. [18:10] no, and i dont intend to do that for the "hwpack" either [18:11] if i trigger a rootfs build for UTouch it should check if there are changes on the HW layer ... if not just use the existing last one [18:11] If it's not meant to be built without a manual trigger, it should be packaged, not on the image builders. That's sort of my point. [18:12] it is meant to be built like any other image [18:12] Not to mention that we've put none of the same thought into making sure that image builders are clean buildd environments for anything other than live-build. [18:12] automated by chrontab [18:12] daily ... [18:12] Daily, except not if it hasn't changed. [18:13] we do this already in OBS/jenkins [18:13] So, not really daily. [18:13] currently it is daily [18:13] to make sure hybris and the platform api are fully in sync with the rootfs [18:13] else it wont boot [18:14] since the android side of both isnt packaged and links against the android bits during build [18:16] in the converged world that might even become more hairy ... since we need to build for all arches and all possible device types if rolling one daily [18:16] infinity, i wouldnt mid leaving it in IBS/OBS/jenkins but then we have zero control over the builds [18:17] * ogra_ can never recall whats the right abbreviation for that black hole build system over there [18:17] IBS. [18:17] k [18:18] Do we actually have an OBS instance in-house somewhere, or are you just having TLA issues? :) [18:18] http://10.97.2.10:8080/view/Phablet/job/ubuntu-touch-image/ [18:18] OBS == OpenSuse Build System. [18:18] thats what we have atm [18:18] oh, right :) [18:18] heh [18:18] indeed i meant IBS [18:18] Pretty sure I'm not tunneled to the right VPN for that URL to be useful. [18:18] ah, ok [18:19] its the jenkins instance that also runs all QA tests [18:19] it spits out between one and five complete builds/day [18:20] (one automated, the others triggered manually on demand) [18:22] infinity, do you have any better idea than replicating whet they do over there atm ? to get dailies in place before S opens ? (we had UDS sessions and there is a spec btw) [18:22] https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-cdimage-android-builds [18:22] If only I hadn't been double-booked for UDS... [18:23] i thought we (you and me) even talked about it before UDS [18:23] None of this cross-building and compiling madness, certainly. :/ [18:24] This all needs to be packaged. [18:24] If something on the Ubuntu rootfs needs to be linked against the Android stuff, that needs to be packaged too. [18:24] you mean the whole OS or all of its armel bits ? [18:24] And that all solves the rather important (and glossed-over) bit about needing to provide source, too. [18:25] I mean, anything that's being rolled into an image that we give people should be coming from a package, not a random one-off compile hidden on a livefs builder. [18:25] the hybris bit in the ubuntu rootfs only talks to the provided hybris abi [18:25] that side is packaged [18:25] livefs builders should be taking binaries from the archive and turning them into images, not taking source from $somewhere and compiling it. [18:26] but thats not how android works sadly [18:26] Uhm. Dude. Yes it is. [18:26] Android is source. That builds to binary bits. [18:26] And you want those binary bits. [18:26] yeah, bit no packages [18:26] not at that level of the OS [18:26] the system image of android is one big blob [18:27] Your "package" can just be something that builds the source and copies all the binaries you want to /usr/share/android-bits/ [18:27] You're looking at this too literally. We don't need dpkg on the TARGET machine to be able to "install Android". [18:27] no, we need the img files [18:27] We just need a conveyance to the buildd. [18:28] since all specs we did (image upgrades etc) revolve around the existing android design atm [18:28] This is exactly no different than building a bootloader into a package and then tearing out the binaries we want to put them on a VFAT. [18:28] You get that, right? Calling it "a whole OS" doesn't change that it's just some random binary blob(s) spit out from a compile job. [18:28] yes i understand ... still if you want all pieces packaged to just merge them into one big blob in the end, whats the usecase ? [18:29] we *need* the one big blob [18:29] ogra_: You've just argued that we shouldn't publish packaged software at all, but recompile the archive for every ISO build. [18:29] if you start ripping it into single packages you will invest several months [18:29] ogra_: In short, that's just not how we do things. [18:30] ogra_: Plus, we already have an established avenue for providing source to people to keep with our GPL requirements, etc. [18:30] well, all designs we have atm revolve around exactly that setup [18:30] ogra_: Who said anything about "single packages"? I didn't. [18:30] ogra_: You can do exactly what you're doing on kapok, but in a package. And without the git clone stage, since that's the bit you upload (though a git archive instead, so it's much smaller). [18:31] ogra_: I'm not talking about refactoring Android or any such insane time investment. [18:31] ah [18:31] i slowly get you ... though that would still be gigabytes of source [18:31] So is libreoffice. [18:31] *shrug* [18:32] given you need the kernel for your HW inside it, binary blobs etc etc [18:32] what we have here is the whole android without dalvik [18:32] including the blobs [18:32] s/including/but including/ [18:33] But humor me, do a 'git archive --format=tar --prefix=cyanogen-0.2013-04-16/ | gzip > ../cyanogen-0.2013-04-16.orig.tar.gz' [18:34] And see how big it is. [18:34] infinity, let me finish what i'm doing atm ... and lets revisit it during S [18:34] (Or whatever/wherever that git tree is actually from) [18:34] phablet.ubuntu.com [18:34] Oh, that might need a HEAD in there before the pipe. [18:35] well, its not one git tree ... [18:35] its repo/brunch/breakfast [18:35] slangasek, cjwatson infinity -- any of you have access to the script that auto-increments the version number for new builds on the isotracker? If so could you add a couple new products to it for me? === Guest6437 is now known as iulian [18:35] ogra_: Sure, then you tar up multiple trees and make it a dpkg-v3 multi-orig package. [18:35] if i call git in the repo toplevel i just get an error [18:35] right [18:36] rsalveti, ^^^ if you have a spare minute please read the backlog [18:37] balloons: I'm not sure I know what you're asking. Builds get the build numbers assigned when built, but that has nothing to do with the isotracker or products therein. [18:37] infinity, i'm all for easier solutions, but for now i need images when S opens [18:37] * rsalveti checking [18:37] and assume the current setup will work ... lets revisit it and rip it apart during the cycle [18:38] rsalveti: TL;DR, it's insanity for image builders to be doing long (and often redundant) compiles of Android, that junk should be packaged (even if it's just one massive package that spits out the blobs you need at the end) and the results sourced by the image builders. [18:39] infinity, the prob here will be that we would actually have to put it into multiverse ... [18:39] rsalveti: This is functionally no different than saying "image builders need u-boot to make a nice bootable VFAT, so we'll pull it from a .deb from the archive" instead of "I guess we'll cross-compile u-boot on every build". [18:39] ogra_: That's not a problem. Why would it be? [18:39] dunno [18:39] just saying ... we have binary blobs inside [18:39] ogra_: We can't and shouldn't lie to our users about the freeness of this crap. Putting it in multiverse drives that home just fine. :P [18:40] heh [18:41] infinity, when a new build hits cdimage, a new version for that build needs to be entered into the tracker -- this is tracked via a script [18:41] balloons: Well, that's all part of the same thing. cdimage just pings the tracker when a build happens. [18:41] infinity: ogra_: problem currently is that the resulted image is hardware dependent [18:41] balloons, thats the /pending vs /current thing ? [18:41] and we're also investigating how to properly flip the container [18:42] I'm sure that's the way to go [18:42] rsalveti, yeah [18:42] it's just that currently we still need to build them the way we're currently building at jenkins [18:42] ogra_, the pending vs current isn't what I'm talking about here :-) [18:42] rsalveti: Multiple hardware-dependant images is just more argument for making this a packaged thing, not less. [18:42] I don't mind building them outside cdimage while the "proper work" is not yet finished [18:42] infinity, ok :-) Well I need that script to ping the tracker about the ubuntu-touch-preview images [18:42] rsalveti: Cause blocking an image builder for hours/days to iterate over all of that is nuts. [18:43] infinity: it's hard as they are bit, the build system is changing at the same time we're improving things and we need to avoid breaking the porters [18:43] rsalveti, infinity i do mind ... since we're nearly there with the current concept [18:43] i dont mind re-doing it later [18:44] it'll be improved over the time, and we hope to separate the needed components into packages [18:44] but i doubt moving to a completely new concept at the dawn of an archive freeze and with the expectation that it is there as soon as the new release iopens isnt feasible [18:44] and make that available at the archive, so it can be consumed by our builders [18:44] balloons: Ahh, that's different. Despite it being published to cdimage, it's not actually from there. In fact, this is what Oli and I are arguing about right now. :P [18:44] we're just not there *yet* [18:44] right [18:44] thats why i say that we should move to infinity's idea ... just not right now [18:44] rsalveti: I wasn't arguing for refactoring into smaller packages. [18:45] * balloons feels sheepish.. I should have read your backlog a bit more [18:45] even building them in big packages [18:45] rsalveti: Just for taring up the mess, making it an orig, and doing some like packaging that builds what you need and dumps it into /usr/share/whatever. [18:45] yeah [18:45] the android part is currently generating all the images, so it's not easy to replace it [18:45] currently android is still the main os [18:45] not ubuntu [18:46] rsalveti: Not that refactoring is a bad idea, but settling for the worst solution because "it's basically done" and arguing that we can't do better because "it needs to be perfect before we do" is a pretty big disconnect. [18:46] balloons: it's certainly possible to post additional images to the tracker from nusakan manually; but stgraber would need to set up the product first, really [18:46] so having them at /usr/share/whatever will not help us at this moment [18:46] (on the tracker) [18:46] rsalveti: I think you're not understanding what I mean. [18:46] infinity: I'm not arguing that we can't do better [18:46] balloons: but yes, as infinity says, this has nothing to do with build identifiers / version numbers [18:46] rsalveti, he means having a debian/rules that runs: phablet-foo-bar; repo sync, brunch $target ... and puts the zips into /usr/liv/foo [18:46] I'm arguing that we'll do better, but currently we still need to build them this way (android-way) [18:46] and just use the whole repo as source package [18:47] rsalveti: I know that Android builds these blobs you need. I'm arguing that you build them ONCE in a package, then our image builder can tear apart that .deb and put them together how you need. [18:47] not sure if that is a good idea [18:47] and i like the idea, its just not the time to change to it now [18:47] rsalveti: Not arguing that a package magically make your final product, or that the target device be able to "dpkg -i android_thing.deb". [18:47] (took me a while to get that)( [18:47] :) [18:47] or at least, not sure if we should spend time moving to a deb way of building it if we'll be replacing it later with something better anyway [18:48] thats true though [18:48] rsalveti: It gets proper source publication for free, which is also pretty important. [18:48] infinity: sure, but why solving this now? [18:48] rsalveti: But mostly, this came about because we're compiling massive jobs on our one amd64 livefs builder, and that's (a) a bad idea, and (b) a bad idea. [18:48] and not invest the time at the proper solution already [18:48] infinity, he is right though, the whole thing is a moving target that can change within weeks [18:49] balloons: where are those products being built? if they [18:49] if we'd stick with this for months, I'd be +1, but this might change completely during the this/next month [18:49] nothing is finalized ... we could change it in two weeks from the ground up [18:49] and we'll be discussing it at the sprint again, based on the container flip work [18:49] rsalveti: it's quite possible that pushing the current design to our current build infrastructure will cause blocking problems during release week, next week [18:49] livefs buildds are not in any way guaranteed to be sane and clean compilation environments. Plus, there's just the resource contention. [18:49] balloons: *if they're built on nusakan, then we'll add them to the python magic, if not, whatever builds them should push the new builds to the tracker [18:49] depending on just how long it takes [18:50] stgraber: they're mirrored on nusakan [18:50] cjwatson, i dont plan to do builds once i know it works [18:50] this is S material [18:50] stgraber, yes not built on nusakan [18:50] that's not so bad I guess [18:50] cjohnston: so if I understand properly the issue right now is consuming the cpu resources from cdimage to bulid the android part [18:50] it just should be ready in advance [18:50] rsalveti: I'm not cjohnston [18:50] crap [18:50] rsalveti, from the livefs builder [18:50] rsalveti: If this could change again in the next month, I seriously don't see the point in Oli's work at all here. Can't we just keep copying the Jenkins output to cdimage and then discuss this all in person in two weeks? [18:50] rsalveti, i didnt even do a build yet ... [18:50] need a hard link for cjwatson [18:50] rsalveti: and no, it's not CPU resources on cdimage, it's CPU resources on kapok (livefs builder). But if it's not going to be running during release week I'm less immediately concerned [18:50] so lets wait for the first smoketest :) [18:51] cjwatson, i never planned to :) [18:51] its all for S [18:51] but i want to have alll livecd-rootfs bits in before freeze [18:51] infinity: right, ogra_ was just working on moving the infra to another machine [18:52] to be better integrated with the way we're currently publishing them [18:52] stgraber: I'd prefer to post from nusakan, since the intent is for ubuntu-touch to eventually be coordinated from nusakan like everything else and I don't see the point in setting up a post-qa-a-like elsewhere [18:52] but if that's indeed an issue (which we thought it would be ok during uds), we can postpone [18:52] rsalveti: it's a little more than moving infrastructure to another machine [18:52] infinity, i promise you if we still have that design a week after S openend i will try to implement your idea [18:52] he's doing integration work with the livecd-rootfs system [18:52] I'd agree with cjwatson to keep everything synced in one place. [18:53] cjwatson: is it something pushing to nusakan or something on nusakan pulling from the outside? if the latter, then indeed it'd make sense for nusakan to just push the new version to the tracker. [18:53] ogra_: If we don't have that design a week after S opens, your work was a waste of time. [18:53] ogra_: So, no matter how you look at it, you're promising to rewrite it in two weeks? :P [18:53] the livecd-rootfs thing is a quick and dirty temporary solution to get the images moved over under cdimage control [18:54] infinity, if needed [18:54] we might even have a completely different concept in two weeks [18:54] Right, see, I honestly don't see the point then. [18:54] Either it changes in two weeks, or it stays the same and changes in two week. [18:54] like android living in a separate container [18:54] stgraber: the latter [18:54] Either way, how is implementing something that's untenable as an interim solution any better than just copying the currently-functional jenkins output? [18:55] You could just stop altogether, cut your losses, stop making sunk cost arguments, and find something more fun to do. [18:56] To be fair Steve has asked Oli to do this in order to keep momentum up - there's a problem that the build in Jenkins is effectively hidden from most Ubuntu developers [18:56] Moving it into livecd-rootfs at least means that we can see what it's doing more easily, even if what it's doing is expected to change [18:57] indeed [18:57] Sure. And moving it to a package would be even less opaque. And wouldn't be a resource issue. [18:57] And would be a few more hours of work. Not unlike arguing on IRC. :P [18:58] I generally agree with having binary outputs in packages as long as we advertise that the result is purely for image builder consumption [18:58] (in package descriptions or whatever) [18:58] * infinity nods. [18:58] As you say, it's much like how boot loaders are handeld [18:58] Or debian-installer initrds, although those are a bit weirder [18:59] so lets just do it that way [18:59] that might be easier than moving stuff directly to cdimage indeed [18:59] once we are not three days before a freeze though [18:59] rsalveti: To be clear, neither approach is directly on cdimage [18:59] right [19:00] cdimage doesn't do livefs builds - it triggers other machines to do them [19:00] (you would notice if you would read the phablet sync logs i mail you every day :P ) [19:00] right, I'm not technically pointing the right machine, just saying to move to the cdimage infra or whatever we can call them [19:00] yeah [19:00] I don't think final freeze is particularly relevant here, given that this isn't output for rarin [19:00] g [19:01] i like infinity's idea, it will just not work with the current goals [19:01] which means to have images building once S opens [19:01] Why not? [19:02] you mean i should just ignore the freeze and upload until the archive closes down ? [19:02] It's possible it'll actually be faster, since everything will be more visible and the image-build phase will be faster [19:03] though that also means that rsalveti needs to prodice regular archive tarballs on phablet.u.c [19:03]