bkerensaanybody from the release team around/01:01
micahgScottK: 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
micahg*version of phpunit in precise01:28
micahgthe alternative would be to backport the newer version of phpunit as well01:28
micahgit has 2 rdeps though, so I'm not sure I want to do that01:29
ScottKWhen it was all new packages to fix the bug, I was comfortable.01:36
ScottKIf it's updating existing packages with rdeps, that's different.01:36
ScottKmicahg: How about fix it backports and then see how it goes.01:36
cjwatson+debootstrap --omponents=ain,universe $release $builddir $MIRROR06:49
cjwatsonogra_: ^- really? :)06:49
cjwatson(two typos)06:50
seb128hum, nobody U.S based reviewed the unity stack during the night :-(07:45
seb128can we get somebody reviewing those this morning? ;-)07:45
seb128Laney, ^?07:45
Laneyseb128: yeah sure08:01
seb128Laney, thanks08:01
ogra_cjwatson, wow, no idea how that happened, before adding $MIRROR to that line it had no typos (i still have the pastebin here)08:37
=== doko_ is now known as doko
ogra_cjwatson, fix uploaded ... (thanks for spotting)09:10
stgraberogra_: is there a specifc reason to mix mount/chroot mount in livecd-rootfs?09:44
ogra_mix ?09:45
stgraberogra_: you mount devpts from outside the chroot, then mount proc and sys from within09:45
ogra_ah, that ... i wasnt sure if there isnt something looking at mtab09:45
ogra_so i always make sure to mount proc and sys inside ... while i dont care for devpts apart from it being writable09:46
ogra_old habit :)09:46
stgraberok :)09:47
stgraberogra_: build-android.sh uses /bin/bash because there are bashisms in what it sources?09:47
ogra_yeah :(09:48
ogra_especially about 1300 lines of arrays09:48
ogra_i tried to make the android build system POSIX but gave up at some point09:48
stgraberok... unlikely to make any significant difference on a long build like that anyway09:49
ogra_well, it isnt long ... takes ~20min ... but its big (the source tree is 15G)09:49
stgraberok, 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:51
ogra_yeah ... well, it might block ... i'll add an -l to the umount in a later upload09:52
stgraberogra_: I think we'd want "umount ... || (echo "Failed to cleanly umount ..." && umount -l ...)" so we have a trace of what happened09:53
stgraberanyway, that's fine for a latter upload09:53
ogra_let me get at least one image out of it first :)09:53
ogra_optimizationcan always happen later09:53
ogra_thanks !09:54
* 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 weirdness11:00
cjwatsonincluding, certainly, component-mismatches madness11:00
cjwatsonimages probably weren't affected as they're configured to prefer using bzr directly11:00
cjwatsonUrsinha: 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:42
ogra_perl: warning: Setting locale failed.11:47
ogra_perl: warning: Please check that your locale settings:11:47
ogra_        LANGUAGE = (unset),11:47
ogra_        LC_ALL = (unset),11:47
ogra_        LC_TIME = "de_DE.UTF-8",11:47
ogra_calling BuildLiveCD directly on nusakan ... i guess i should force LC_ALL to C in the script :)11:48
* ogra_ wonders about the ton of autoremovable packages in the log ... thats weird11:50
ogra_and mount doesnt get along with $builddir-proc11:51
ogra_and anothe upload ...12:01
tjaaltonslangasek: ^13:01
tjaaltonslangasek: uploaded mesa to raring, all testing seems good, FFE bug description updated to match https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/116409313:02
ubot2Launchpad bug 1164093 in mesa (Ubuntu) "FFe: new upstream release 9.1.1" [Wishlist,Triaged]13:02
cjwatsonHas anyone filed an LP bug about the difficulty of getting hold of diffs / original source for copies?13:26
cjwatson(When they show up in queues)13:27
cjwatsonAh, of course, asking about it caused me to find it.  Bug 85156213:27
ubot2Launchpad 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/85156213:27
Laneyis there some other tool also called queue?13:29
Laneywhen I searched for this before I found bug #92453713:29
ubot2Launchpad bug 924537 in Launchpad itself ""queue fetch" requires a changes file which copies sometimes lack" [Low,Fix released] https://launchpad.net/bugs/92453713:29
cjwatsonLaney: that's the old one that used to be in LP and run from the archive master system13:32
Laneyso it poked internal APIs presumably13:33
cjwatsonLaney: once I got the API version working, I killed the internal one13:33
cjwatsonLaney: Yes13:33
Laneyif you're fixing stuff in this are, can you make the PPA name into a link to the PPA too? :-)13:33
cjwatsonLaney: See my question in #launchpad-dev 12 minutes ago ...13:34
Laneycjwatson: excellent13:35
JackYucjwatson: hi, would you please help us check the FFE of #1169525 and 1169517?14:23
cjwatsonIf ~ubuntu-release is subscribed, it's in the queue14:25
JackYucjwatson: well, thanks. it seems that 18, Apr is the deadline.14:30
ogra_thanks !14:38
cjwatsonJackYu: well, approved, although to be honest I don't think those needed feature freeze exceptions14:40
cjwatsonJackYu: 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 updated14:42
JackYucjwatson: thanks.14:43
Ursinhacjwatson, \o/ thanks :)15:09
seb128Laney, 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 questions15:21
seb128Laney, https://git.gnome.org/browse/gvfs/log/?h=gnome-3-8 might be useful to see the list of changes15:22
seb128Laney, the changes from alex should avoid quite some segfaults we are receiving15:22
Laneyseb128: sure, will look at it15:23
seb128Laney, thanks15:23
=== mbarnett` is now known as mbarnett
* ogra_ twiddles thumbs ... come on publisher ...16:08
ogra_i wonder why BuildLiveCD doesnt send mails for my failing build attempts16:08
ogra_(i'm happy it doesnt spam the world, but curious why it doesnt)16:08
=== iulian is now known as Guest6437
ogra_ARGH !16:40
ogra_mkdir -p $builddir/dev/pts16:41
ogra_mkdir: invalid option -- 'b'16:41
ogra_Try 'mkdir --help' for more information.16:41
ogra_i dont get it16:42
ogra_builddir=$codename-build  ....16:42
ogra_$codename is "mako"16:42
cjwatsonref to full log?16:43
ogra_kapok.buildd in the mako-android dir under raring16:44
ogra_and the last BuildLive.out indeed16:45
ogra_$codename comes from $1 ... which effectively is $SUBARCH in the calling script ...16:46
cjwatsonSo you'll get that if $1 is empty16:47
ogra_but $1 is obviously mako ... else i wouldnt have the sruff ending up in the mako dir16:47
cjwatsonAre you sure -s <something> is being passed?16:47
ogra_ph sigh16:48
ogra_*oh even16:48
cjwatsonmako is ${FS} surely?16:48
ogra_ssh -n -o StrictHostKeyChecking=no -o BatchMode=yes buildd@kapok.buildd /home/buildd/bin/BuildLiveCD -d raring -t android -r android mak16:48
ogra_thats how i call it atm16:49
ogra_and yeah, i didnt call -s16:49
ogra_silly me16:49
ogra_cjwatson, thanks ...16:50
ogra_lets try with just adding -s16:50
cjwatsonConsider whether the right answer is to use -s or to pass ${FS} instead16:50
cjwatsonIf you pass -s mako then you'll get mako-android-mako16:51
cjwatsonWhich is pretty weird16:51
ogra_thats fine for now16:51
ogra_but yeah i will surely need to tweak that stuff a bit ...16:51
ogra_for now i just want to see the sub script working16:51
ogra_bah, and now i ended up in the queue ...16:53
* ogra_ goes to look for dinner16:54
alecuhi, I'd like to ping this channel regarding https://bugs.launchpad.net/unity-lens-music/+bug/116867417:00
ubot2Launchpad bug 1168674 in Music Lens "Purchased songs won't download when not logged to U1" [Critical,New]17:00
ogra_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
ogra_seems my build started but it has probs ot answer http requests17:20
ogra_ah, no, its still the former build17:21
=== james_ is now known as Guest69845
ogra_infinity, do you happen to know what HW specs kapok has ?17:53
ogra_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 compiling17:53
infinityIt should be a reasonably beefy DL380 G5 or G6, I assume.17:54
infinityBut we probably shouldn't be compiling on the livefs builders...17:54
ogra_we want to do it from cdimage builds17:55
infinityIs 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
ogra_its a 15G android source tree17:55
ogra_you dont want to package this :)17:55
infinitySmaller compressed, I assume. :P17:55
ogra_it is what generates the HW layer of ubuntu touch images17:55
infinityI'd rather package it than rebuild it every day for no reason.17:55
ogra_yeah, i dont plan to rebuild it unconditionally17:56
ogra_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:56
infinityI still question the absolute truth of the first bit.17:57
infinityNeeding the full thing is fine.  And I get a shallow export is smaller than 15G (and much smaller compressed).17:57
ogra_it builds a full OS17:58
ogra_armel also :)17:58
infinityBut if you're saying the git clone is 15G, I'm saying an export is much smaller.17:58
infinityThat's just how VCSes work.17:58
ogra_the only thing you gain when doing an export is that you doknt transfer the three other kernels for the arches you currently dotn build17:59
ogra_thats in max 500M17:59
ogra_the rest is all OS stuff you need during the build17:59
ogra_including all deps18:00
ogra_anyway, i'm not really concerned by the disk requirements ... i'm confident there is enough diskspace18:01
ogra_but seeing the behavior of the machine while just rolling a rootfs image and not even answering to http requests for minutes makes me worry18:02
infinityogra_: I think you're not understanding what I mean by export.18:06
ogra_infinity, apparently not ... i just know what it does when it builds ... it compiles the whole dependency chain like gentoo18:07
ogra_and it needs the full tree for this18:07
infinityYes, but it doesn't need the history.18:07
ogra_transferring the 15G from onbe machine in the DC to another isnt really an issue imho18:08
infinity(probably muddies the waters that, unlike cvs, bzr, or svn, git doesn't have an "export" command, but it does have "archive")18:08
infinityogra_: 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
ogra_and it needs the history for generating the chabnbgelog we ship alongside the images18:08
infinityogra_: And I still think packaging it is the sane thing to do.18:08
ogra_how do you package a whole OS ?18:09
infinityYou build the bits and put the result in a deb that you later download and tear apart?18:09
infinityNo different than asking "how do you package a bootloader that you intend to use later on cdimage?"18:09
ogra_it is the android layer ... it spits out four img zips  and needs to work with the android update/flash mechanism18:09
infinityAnd we don't cross-build u-boot for every ARM image build.18:10
ogra_no, and i dont intend to do that for the "hwpack" either18:10
ogra_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 one18:11
infinityIf 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:11
ogra_it is meant to be built like any other image18:12
infinityNot 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
ogra_automated by chrontab18:12
ogra_daily ...18:12
infinityDaily, except not if it hasn't changed.18:12
ogra_we do this already in OBS/jenkins18:13
infinitySo, not really daily.18:13
ogra_currently it is daily18:13
ogra_to make sure hybris and the platform api are fully in sync with the rootfs18:13
ogra_else it wont boot18:13
ogra_since the android side of both isnt packaged and links against the android bits during build18:14
ogra_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 daily18:16
ogra_infinity, i wouldnt mid leaving it in IBS/OBS/jenkins but then we have zero control over the builds18:16
* ogra_ can never recall whats the right abbreviation for that black hole build system over there 18:17
infinityDo we actually have an OBS instance in-house somewhere, or are you just having TLA issues? :)18:18
infinityOBS == OpenSuse Build System.18:18
ogra_thats what we have atm18:18
ogra_oh, right :)18:18
ogra_indeed i meant IBS18:18
infinityPretty sure I'm not tunneled to the right VPN for that URL to be useful.18:18
ogra_ah, ok18:18
ogra_its the jenkins instance that also runs all QA tests18:19
ogra_it spits out between one and five complete builds/day18:19
ogra_(one automated, the others triggered manually on demand)18:20
ogra_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
infinityIf only I hadn't been double-booked for UDS...18:22
ogra_i thought we (you and me) even talked about it before UDS18:23
infinityNone of this cross-building and compiling madness, certainly. :/18:23
infinityThis all needs to be packaged.18:24
infinityIf something on the Ubuntu rootfs needs to be linked against the Android stuff, that needs to be packaged too.18:24
ogra_you mean the whole OS or all of its armel bits ?18:24
infinityAnd that all solves the rather important (and glossed-over) bit about needing to provide source, too.18:24
infinityI 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
ogra_the hybris bit in the ubuntu rootfs only talks to the provided hybris abi18:25
ogra_that side is packaged18:25
infinitylivefs builders should be taking binaries from the archive and turning them into images, not taking source from $somewhere and compiling it.18:25
ogra_but thats not how android works sadly18:26
infinityUhm.  Dude.  Yes it is.18:26
infinityAndroid is source.  That builds to binary bits.18:26
infinityAnd you want those binary bits.18:26
ogra_yeah, bit no packages18:26
ogra_not at that level of the OS18:26
ogra_the system image of android is one big blob18:26
infinityYour "package" can just be something that builds the source and copies all the binaries you want to /usr/share/android-bits/18:27
infinityYou're looking at this too literally.  We don't need dpkg on the TARGET machine to be able to "install Android".18:27
ogra_no, we need the img files18:27
infinityWe just need a conveyance to the buildd.18:27
ogra_since all specs we did (image upgrades etc) revolve around the existing android design atm18:28
infinityThis 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
infinityYou 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
ogra_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:28
ogra_we *need* the one big blob18:29
infinityogra_: You've just argued that we shouldn't publish packaged software at all, but recompile the archive for every ISO build.18:29
ogra_if you start ripping it into single packages  you will invest several months18:29
infinityogra_: In short, that's just not how we do things.18:29
infinityogra_: Plus, we already have an established avenue for providing source to people to keep with our GPL requirements, etc.18:30
ogra_well, all designs we have atm revolve around exactly that setup18:30
infinityogra_: Who said anything about "single packages"?  I didn't.18:30
infinityogra_: 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:30
infinityogra_: I'm not talking about refactoring Android or any such insane time investment.18:31
ogra_i slowly get you ... though that would still be gigabytes of source18:31
infinitySo is libreoffice.18:31
ogra_given you need the kernel for your HW inside it, binary blobs etc etc18:32
ogra_what we have here is the whole android without dalvik18:32
ogra_including the blobs18:32
ogra_s/including/but including/18:32
infinityBut humor me, do a 'git archive --format=tar --prefix=cyanogen-0.2013-04-16/ | gzip > ../cyanogen-0.2013-04-16.orig.tar.gz'18:33
infinityAnd see how big it is.18:34
ogra_infinity, let me finish what i'm doing atm ... and lets revisit it during S18:34
infinity(Or whatever/wherever that git tree is actually from)18:34
infinityOh, that might need a HEAD in there before the pipe.18:34
ogra_well, its not one git tree ...18:35
ogra_its repo/brunch/breakfast18:35
balloonsslangasek, 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?18:35
=== Guest6437 is now known as iulian
infinityogra_: Sure, then you tar up multiple trees and make it a dpkg-v3 multi-orig package.18:35
ogra_if i call git in the repo toplevel i just get an error18:35
ogra_rsalveti, ^^^ if you have a spare minute please read the backlog18:36
infinityballoons: 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
ogra_infinity, i'm all for easier solutions, but for now i need images when S opens18:37
* rsalveti checking18:37
ogra_and assume the current setup will work ... lets revisit it and rip it apart during the cycle18:37
infinityrsalveti: 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:38
ogra_infinity, the prob here will be that we would actually have to put it into multiverse ...18:39
infinityrsalveti: 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
infinityogra_: That's not a problem.  Why would it be?18:39
ogra_just saying ... we have binary blobs inside18:39
infinityogra_: 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. :P18:39
balloonsinfinity, when a new build hits cdimage, a new version for that build needs to be entered into the tracker -- this is tracked via a script18:41
infinityballoons: Well, that's all part of the same thing.  cdimage just pings the tracker when a build happens.18:41
rsalvetiinfinity: ogra_: problem currently is that the resulted image is hardware dependent18:41
ogra_balloons, thats the /pending vs /current thing ?18:41
rsalvetiand we're also investigating how to properly flip the container18:41
rsalvetiI'm sure that's the way to go18:42
ogra_rsalveti, yeah18:42
rsalvetiit's just that currently we still need to build them the way we're currently building at jenkins18:42
balloonsogra_, the pending vs current isn't what I'm talking about here :-)18:42
infinityrsalveti: Multiple hardware-dependant images is just more argument for making this a packaged thing, not less.18:42
rsalvetiI don't mind building them outside cdimage while the "proper work" is not yet finished18:42
balloonsinfinity, ok :-) Well I need that script to ping the tracker about the ubuntu-touch-preview images18:42
infinityrsalveti: Cause blocking an image builder for hours/days to iterate over all of that is nuts.18:42
rsalvetiinfinity: 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 porters18:43
ogra_rsalveti, infinity i do mind ... since we're nearly there with the current concept18:43
ogra_i dont mind re-doing it later18:43
rsalvetiit'll be improved over the time, and we hope to separate the needed components into packages18:44
ogra_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 feasible18:44
rsalvetiand make that available at the archive, so it can be consumed by our builders18:44
infinityballoons: 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. :P18:44
rsalvetiwe're just not there *yet*18:44
ogra_thats why i say that we should move to infinity's idea ... just not right now18:44
infinityrsalveti: I wasn't arguing for refactoring into smaller packages.18:44
* balloons feels sheepish.. I should have read your backlog a bit more18:45
rsalvetieven building them in big packages18:45
infinityrsalveti: 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
rsalvetithe android part is currently generating all the images, so it's not easy to replace it18:45
rsalveticurrently android is still the main os18:45
rsalvetinot ubuntu18:45
infinityrsalveti: 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
cjwatsonballoons: it's certainly possible to post additional images to the tracker from nusakan manually; but stgraber would need to set up the product first, really18:46
rsalvetiso having them at /usr/share/whatever will not help us at this moment18:46
cjwatson(on the tracker)18:46
infinityrsalveti: I think you're not understanding what I mean.18:46
rsalvetiinfinity: I'm not arguing that we can't do better18:46
cjwatsonballoons: but yes, as infinity says, this has nothing to do with build identifiers / version numbers18:46
ogra_rsalveti, he means having a debian/rules that runs: phablet-foo-bar; repo sync, brunch $target ... and puts the zips into /usr/liv/foo18:46
rsalvetiI'm arguing that we'll do better, but currently we still need to build them this way (android-way)18:46
ogra_and just use the whole repo as source package18:46
infinityrsalveti: 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
rsalvetinot sure if that is a good idea18:47
ogra_and i like the idea, its just not the time to change to it now18:47
infinityrsalveti: 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
ogra_(took me a while to get that)(18:47
rsalvetior 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 anyway18:47
ogra_thats true though18:48
infinityrsalveti: It gets proper source publication for free, which is also pretty important.18:48
rsalvetiinfinity: sure, but why solving this now?18:48
infinityrsalveti: 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
rsalvetiand not invest the time at the proper solution already18:48
ogra_infinity, he is right though, the whole thing is a moving target that can change within weeks18:48
stgraberballoons: where are those products being built? if they18:49
rsalvetiif we'd stick with this for months, I'd be +1, but this might change completely during the this/next month18:49
ogra_nothing is finalized ... we could change it in two weeks from the ground up18:49
rsalvetiand we'll be discussing it at the sprint again, based on the container flip work18:49
cjwatsonrsalveti: it's quite possible that pushing the current design to our current build infrastructure will cause blocking problems during release week, next week18:49
infinitylivefs buildds are not in any way guaranteed to be sane and clean compilation environments.  Plus, there's just the resource contention.18:49
stgraberballoons: *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 tracker18:49
cjwatsondepending on just how long it takes18:49
cjwatsonstgraber: they're mirrored on nusakan18:50
ogra_cjwatson, i dont plan to do builds once i know it works18:50
ogra_this is S material18:50
balloonsstgraber, yes not built on nusakan18:50
cjwatsonthat's not so bad I guess18:50
rsalveticjohnston: so if I understand properly the issue right now is consuming the cpu resources from cdimage to bulid the android part18:50
ogra_it just should be ready in advance18:50
cjwatsonrsalveti: I'm not cjohnston18:50
ogra_rsalveti, from the livefs builder18:50
infinityrsalveti: 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
ogra_rsalveti, i didnt even do a build yet ...18:50
rsalvetineed a hard link for cjwatson18:50
cjwatsonrsalveti: 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 concerned18:50
ogra_so lets wait for the first smoketest :)18:50
ogra_cjwatson, i never planned to :)18:51
ogra_its all for S18:51
ogra_but i want to have alll livecd-rootfs bits in before freeze18:51
rsalvetiinfinity: right, ogra_ was just working on moving the infra to another machine18:51
rsalvetito be better integrated with the way we're currently publishing them18:52
cjwatsonstgraber: 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 elsewhere18:52
rsalvetibut if that's indeed an issue (which we thought it would be ok during uds), we can postpone18:52
cjwatsonrsalveti: it's a little more than moving infrastructure to another machine18:52
ogra_infinity, i promise you if we still have that design a week after S openend i will try to implement your idea18:52
cjwatsonhe's doing integration work with the livecd-rootfs system18:52
balloonsI'd agree with cjwatson to keep everything synced in one place.18:52
stgrabercjwatson: 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
infinityogra_: If we don't have that design a week after S opens, your work was a waste of time.18:53
infinityogra_: So, no matter how you look at it, you're promising to rewrite it in two weeks? :P18:53
ogra_the livecd-rootfs thing is a quick and dirty temporary solution to get the images moved over under cdimage control18:53
ogra_infinity, if needed18:54
ogra_we might even have a completely different concept in two weeks18:54
infinityRight, see, I honestly don't see the point then.18:54
infinityEither it changes in two weeks, or it stays the same and changes in two week.18:54
ogra_like android living in a separate container18:54
cjwatsonstgraber: the latter18:54
infinityEither way, how is implementing something that's untenable as an interim solution any better than just copying the currently-functional jenkins output?18:54
infinityYou could just stop altogether, cut your losses, stop making sunk cost arguments, and find something more fun to do.18:55
cjwatsonTo 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 developers18:56
cjwatsonMoving 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 change18:56
infinitySure.  And moving it to a package would be even less opaque.  And wouldn't be a resource issue.18:57
infinityAnd would be a few more hours of work.  Not unlike arguing on IRC. :P18:57
cjwatsonI generally agree with having binary outputs in packages as long as we advertise that the result is purely for image builder consumption18:58
cjwatson(in package descriptions or whatever)18:58
* infinity nods.18:58
cjwatsonAs you say, it's much like how boot loaders are handeld18:58
cjwatsonOr debian-installer initrds, although those are a bit weirder18:58
ogra_so lets just do it that way18:59
rsalvetithat might be easier than moving stuff directly to cdimage indeed18:59
ogra_once we are not three days before a freeze though18:59
cjwatsonrsalveti: To be clear, neither approach is directly on cdimage18:59
cjwatsoncdimage doesn't do livefs builds - it triggers other machines to do them19:00
ogra_(you would notice if you would read the phablet sync logs i mail you every day :P )19:00
rsalvetiright, I'm not technically pointing the right machine, just saying to move to the cdimage infra or whatever we can call them19:00
cjwatsonI don't think final freeze is particularly relevant here, given that this isn't output for rarin19:00
ogra_i like infinity's idea, it will just not work with the current goals19:01
ogra_which means to have images building once S opens19:01
cjwatsonWhy not?19:01
ogra_you mean i should just ignore the freeze and upload until the archive closes down ?19:02
cjwatsonIt's possible it'll actually be faster, since everything will be more visible and the image-build phase will be faster19:02
ogra_though that also means that rsalveti needs to prodice regular archive tarballs on phablet.u.c19:03
rsalvetiogra_: can't we make that to happen when creating the source packagE?19:03
ogra_the image build phase will ... but the paperwork around it wont19:03
cjwatsonGiven that this is something users aren't expected to use and is just build support for something not in raring, I don't think it's subject to freeze19:03
ogra_rsalveti, hmm, that means  what 15G uploads for me ?19:03
rsalvetino, the git export, which is way less19:03
balloonscjwatson, stgraber ok so it sounds like you'll add the build notice for ubuntu-touch-preview to the python magic on nusakan?19:04
ogra_cjwatson, its subjejct to the archive ... which freezes19:04
rsalvetibut sure, we can probably make that happen automatically there19:04
infinityThe archive is already frozen, nothing really changes in two days on that front, we can keep uploading things.19:04
ogra_infinity, it will hard freeze and lock down ... i'm not referring to artificial frezes19:05
rsalvetiright, and this will only take effect at s anyway19:05
infinityogra_: It's already hard frozen and locked down. :P19:05
ogra_infinity, nah19:05
infinityogra_: Unless you mean when we RELEASE in a week and a half, and then you just start uploading to S instead.19:06
ogra_i mean the hard freeze once we have a release candidate19:06
ogra_which usually adds an extra week of no uploads19:06
ogra_and i mean *no* uploads19:06
infinityPast -changes lists disagree with you.19:07
ogra_or do we plan to do that differently this time19:07
infinityWe upload right up to release day.19:07
ogra_i'm probably to main focused :P19:07
infinityEspecially for things like this that don't exist on shipping images.19:07
cjwatsonrsalveti: Can you confirm the size of the archive tarballs that would be produced?19:10
rsalveticjwatson: yup, checking now how this can be done19:10
rsalvetiand the size19:10
cjwatsonballoons: stgraber will need to add a product to iso.qa; I can then add support for it to lp:ubuntu-cdimage19:10
* ogra_ guesses with repo involved thats trikier than just one git tree19:11
infinitydebian/rules get-orig-source can be made to do multiple git archive runs and build a multi-orig source, that's about 2 minutes of work.19:11
rsalvetiogra_: yup19:11
infinity(And a lot more than two minutes to actually do the exports, but whatever)19:12
rsalvetiinfinity: but it'd be better to grab the list from the manifest and etc19:12
ogra_infinity, execpt that i still only have a 2M line here :P19:12
ogra_pulling the repo to make a port took me 3 days19:12
infinityogra_: Sure, but once you have a copy of the repo, you're just doing a quick git pull before a fresh git archive.19:13
ogra_i think i killed kapok19:13
infinityUnless you're deleting it and re-cloning every time.19:13
infinityI which case, Double-U Tee Eff, mate.19:13
ogra_infinity, well, i still produce tarballs that i need to upload19:13
cjwatsonCan't you build the orig tarball on a porter box in the DC?19:14
* ogra_ odered a vdsl 50M line this week ... but it will still take 4 weeks until that switch happens19:14
ogra_cjwatson,  i fear i will have to19:14
rsalvetiI'm checking if that can be automatically published by phablet.u.c19:14
rsalvetithat will make it way easier19:14
infinityOr have Ricardo produce tarballs for you, sure.19:14
cjwatsonThen dput it from there, or nc it to chinstrap and dput from there19:14
infinityThen you can build the .dsc in the DC and sign it at home.19:14
ogra_thats the reason my original idea was to use kapok19:14
* cjwatson <- also ~2M line, well used to this sort of thing :)19:15
ogra_to not have to shovel gigs around through the internet19:15
infinityI suspect that sort of thing is the libreoffice workflow for some people.19:15
ogra_heh, yeah19:15
infinityThough I just download the full source and play locally, cause I'm silly.19:15
ogra_i fixed OO.o once for arm ... took half a day to upload19:15
* infinity wonders how many more times libnss-myhostname will bounce between main and universe.19:15
ogra_cjwatson, didnt you get fiber once ?19:16
cjwatsonI wish19:16
cjwatsonhttp://cjwatson.dreamwidth.org/2827.html is part of the joys involved in attempting (and failing) to get fibre here19:16
ogra_eek ADLS ?19:17
ogra_i at least have SDSL19:17
balloonscjwatson, ahh a link to the magic! thanks! So when say add a product to iso.qa is there something more that needs to be done than what is there now? (aka "ubuntu touch" product)19:17
cjwatsonogra_: SDSL is roughly unknown in the UK19:17
ogra_yeah, i have to pay a hilarious price for it even in germany its rare19:17
cjwatsonballoons: There's a bit in lp:ubuntu-cdimage that maps cdimage's idea of images onto iso.qa products19:17
cjwatsoniso.qa came much later and does things rather differently19:18
ogra_but so are fixed IPs nowadays ... finding the VDSL optiuon with IP wasnt easy19:18
infinityI don't bother paying for a static IP because I get the same one from DHCP for a year or two at a time between network reorgs.19:20
infinityAnd changing DNS once every two years doesn't seem like a big deal.19:20
ogra_well, german telekom isnt that reliable ... and i like to have my mailserver recieve the mail19:21
ogra_and since i have the space here i decided to not pay for a hosting provider anymore19:21
ogra_(we dont even actively use a quater of the house ...  so i can run server cabinets and whatnot)19:22
balloonscjwatson, of course. Just want to do as much as a can to help out -- if it's something I can accomplish, I'm happy to do it. And to understand of course :-) I think I'm understanding what has to change.. a new cron entry, potentially a new config (daily-preinstalled might work) and adding a ubuntu touch entry to the tree.. interesting :-)19:23
* slangasek eyes component-mismatches19:40
TheDrumsWould there be a chance that http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679911#25 will make it into raring?  It is a bug fix.19:45
ubot2Debian bug 679911 in sendemail "[sendemail] Fails when tls is enabled" [Important,Fixed]19:45
infinityTheDrums: Done.19:59
TheDrumsinfinity: Thank you!19:59
antarusheh, I read that as 'sendmail' and i was very confused20:00
infinityI did too, initially.20:00
balloonssendmail bug fixed. yay!20:01
slangasekit's the Old English locale version of sendmail20:15
slangasekyou know, the updated one20:15
stgraberogra_: gah, does that mean I'll have to stop making fun of your silly slow internet connection? :)20:17
rsalveticjwatson: ogra_: infinity: 6.7G for the bare files, but can be reduced once we drop our own kernel (and use the one provided by the kernel team)20:21
rsalveti2.1G just for the kernel sources20:22
rsalveti407M for the darwin-x86 prebuilt toolchain20:22
rsalvetiwhich I believe we can probably remove20:22
cjwatsonWhy is the kernel source so much bigger than the standard kernel source?20:23
cjwatson107018407 linux_3.8.0.orig.tar.gz20:23
rsalvetiwell, that's compressed20:23
cjwatsonAh, what's the compressed figure?20:23
rsalvetiit's probably around 500MB20:23
rsalveticjwatson: still in progress20:24
cjwatson$ zcat /mirror/ubuntu/pool/main/l/linux/linux_3.8.0.orig.tar.gz | wc -c20:24
cjwatsonThat's still a factor of 4 difference20:24
rsalvetiwe have kernel sources for 4 devices20:24
rsalvetibut in the archive we already have kernel packages for nexus 4 and 720:25
rsalveticjwatson: ogra_: 2.4G for the tar.gz file20:32
cjwatsonHm.  I admit that's quite a lot.20:33
cjwatsonIs that with or without kernels?20:34
rsalvetiwe can probably reduce it a bit, not sure how much though, let me remove the obvious20:34
rsalveticjohnston: with20:34
rsalvetiwill remove that and some prebuilt files to see20:34
rsalveticjwatson: ^20:34
=== NCommander is now known as Guest64348
rsalveticjwatson: 1.2G after removing most of the low hanging fruits (3.0G uncompressed)20:43
rsalvetiless, but still quite big20:44
infinityrsalveti: Big, but not unreasonable.  Could be smaller still if it was xz.20:57
rsalvetiinfinity: yup, just didn't want to kill my host :-)20:58
rsalvetibut probably around 1g still20:58
=== davidm` is now known as davidm
ogra_rsalveti, thx22:18
rsalvetiogra_: still trying to get the auto-dump at phablet, but facing firewall issues as usual22:20
cjwatsonogra_: Certainly kapok is unhappy - were you chasing up recovery with IS already?22:32
ogra_cjwatson, oops, nope, didnt yet22:37
* ogra_ notices the mail ... stale lock ... 22:37
ogra_cjwatson, pinged #webops22:38
ogra_rsalveti, hmm22:39
ogra_i'm just wondering ... if we could have the whole of phablet.u.c pulled in to a bzr branch on LP ... and set up a PPA autobuild job for a "package" we could probably get around having to shove around sourcecode at all22:42
ogra_anyway ... calling it a day now22:45
cjwatsonLaney: https://code.launchpad.net/~cjwatson/launchpad/queue-copy-archive-links/+merge/159250, since you were asking23:20

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!