[01:11] barry: utopic landing-006 is ready to publish [01:22] trainguards: utopic landing-006 is ready to publish [01:23] AlbertA: you just caught me, i will publish for you [01:23] barry: cool thanks! [01:26] AlbertA: ^^ the packaging changes need review. can you look? (i will too) [01:27] AlbertA: https://launchpadlibrarian.net/186938422/trust-store_1.1.0%2B14.10.20141008.1-0ubuntu1_1.1.0%2B14.10.20141009-0ubuntu1.diff.gz [01:28] barry: yeah looks ok to me [01:28] AlbertA: i will ack the pack [01:29] AlbertA: good night! [01:29] barry: thanks! [01:29] barry: good night [01:49] cjwatson: where is "http://archive-team.internal/click_packages" and how is it maintained? [01:57] oh, snakefruit [02:09] === trainguards: IMAGE 276 building (started: 20141010 02:10) === [02:45] trainguards, can you please assign a silo for line 48 ? [02:50] barry, Are you still up by chance? ^ [03:09] === trainguards: RTM IMAGE 95 building (started: 20141010 03:10) === [04:13] tedg: sure [04:13] and morning [04:14] tedg: there are other indicator-landings still in rtm, but it's not completely problematic since they've landed in utopic so the trunks are up-to-date. [04:19] tedg: right, the rtm-008 is not your silo actually, but sergiusens' - that has indicator-transfer and needs to go in before this new sync silo. [04:34] tedg: you'll need to reland https://code.launchpad.net/~ted/indicator-sound/silent-mode/+merge/236971 since you landed "Revert notifications on volume change." in-between. [04:35] oh, actually, it was rebuilt but just not picked by the CI Train. interestingly complex case here. [04:43] ~200 clicks later, still clicking... [04:47] phew, finally [04:48] tedg: ok, ignore all above and be happy you don't need to operate the Train :) 017 has landed towards utopic, and rtm-012 is a sync of it. [07:14] morning [07:14] would it be possible to get permissions for the spreadsheet? [07:34] sil2100, morning, would it be possible to get permissions for the spreadsheet? [07:35] abeato: sure! [07:35] abeato: one moment [07:36] sil2100, thanks [07:43] bzoltan: so. you maybe want to forget about line 20 (01.10. landing) and go straight to the line 31 to sync the rtm uitk, test that on utopic and publish. [07:43] bzoltan: tell me if you want to arrange like that. [07:44] Mirv: I started to lend the next round to the RTM. We havbe two critical bug fixes there. [07:44] Mirv: I am not sure if it has any value to run my 6-8 hours tests on Utopic. [07:45] Mirv: I would just simple release the line 31 as it is exactly as good as it was for RTM [07:45] bzoltan: sil2100: shall we start waiting for v-series for UITK? [07:45] bzoltan: right, that's another option, one more release since that was already built, and then focus on rtm for a moment. [07:45] final freeze is anyway next Thu [07:46] hmm [07:46] bzoltan: oh right 31, so sync that, then publish. maybe you'd need to smoke-test it anyhow, but 6-8h maybe overkill. [07:46] Mirv: let's do a real and big Utopic/RTM landing with this round... [07:48] bzoltan: so, your next landing with critical fixes? include the gles, and when it lands to rtm also sync to utopic. but abandon these two landings from utopic? === dpm_ is now known as dpm [07:51] So you want to skip a release for utopic? I think the archive admins won't like that... [07:52] sil2100: so there is already a second UITK landed in rtm that has not landed in utopic. so the question is whether to land the first one (line 20, built, not tested), the second one (line 31, not built/synced, not tested) or the next one (upcoming rtm release with critical fixes) [07:52] grrr [07:52] hmm [07:52] if "no skipping" is the method, then line 20 should see testing and publishing, then line 31, then the newest one [07:53] Mirv, bzoltan: so, I would at least only test line 31 and just drop 20, since 31 has both versions anyway [07:53] We don't require exhaustive testing for utopic so this should be fine, but I wouldn't want to delay it landing to utopic any longer [07:54] seems the image builder ran out of space once again [07:54] (i killed the hanging import process and cleaned /tmp ... import-images is re-running now) [07:55] ogra_: I wonder why earlier this was not a problem, since I'm pretty sure UTF8 characters were present in files we were removing from the images for sure [07:55] Mirv: yes, that is the plan [07:55] bzoltan: read the whole thread :) https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-019 will have the "current RTM versions" in about 20 minutes published. you could smoke test those and mark line 31 ready for landing. [07:55] sil2100, there were still a few tmp dirs left around from last time ... and i think we got new custom channels [07:56] bzoltan: but I'll anyway remove line 20, since it's older [07:56] (if ok) [07:57] ARGH ! [07:57] File "/srv/system-image.ubuntu.com/bin/../lib/systemimage/diff.py", line 199, in generate_diff_tarball [07:57] removed_files = "%s\n" % removed_files.encode('utf-8') [07:57] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 27881: ordinal not in range(128) [07:57] damn ! [07:58] Mirv: yes, it is OK [08:00] trainguards, hey, for some reason row 43 doesn't get marked for QA signoff [08:00] Saviq: let me loook [08:00] Saviq: fixed! Spreadsheet ate a formula [08:00] ;p [08:01] sil2100, thanks [08:02] Saviq: I even restorted the formula once today already [08:02] Mirv, hmpf [08:03] who do I bribe to put my rtm silo on top of the queue? ;P [08:04] Saviq: probably brendand :) [08:04] but I believe that HERE landing is important too [08:04] I'm not asking what's important TO YOU ;P [08:04] Saviq: ;) [08:05] this'll be the last sync silo for unity8 I imagine [08:10] Saviq, let me here your offer [08:11] s/here/hear/ [08:11] brendand, you're selling, you set the price ;) [08:11] "mapping" error :) [08:11] ogra_, yeah what an appropriate typo [08:12] Saviq, it's going to get looked at soon anyway, so don't worry [08:13] brendand, hey, is rtm/landing-010 (line #30) on your radar? can you add it to your queue? [08:13] brendand, sure, j/k ;) [08:13] brendand, it would've been up for testing since last night... but spreadsheet was hungry :| [08:14] pstolowski, it will be when it's built and tested [08:17] brendand, it was built, and i marked it as tested [08:19] pstolowski: ok, the same thing - spreadsheet ate a formula from your landing [08:19] So the status wasn't visible [08:20] Now it's all ok [08:20] Morningall [08:20] Morning [08:20] pstolowski, there you go - in our queue now [08:22] brendand, thanks [08:30] Mirv, bzoltan: before assigning the silo for the new landing of UITK, I would really like to see all the previous releases landing in utopic now [08:31] Since the assumption of allowing landing first in RTM before utopic is that it gets *instantly* synced up to utopic [08:31] bzoltan: ^ so, land line 31 [08:32] Not in batches, as then the main principle of RTM will be broken [08:32] i.e. that everything in RTM needs to be in utopic [08:32] sil2100: ah, so first 20, then 31. ok. bzoltan <- both 20 and 31 are built. [08:33] Mirv: well, if bzoltan tests only 31, it includes 20 already, right? [08:34] sil2100: yes, it includes, but I thought if you mean that both need to land to have the same publishing history. [08:34] Mirv, bzoltan: since my only requirement here is that we have ubuntu and ubuntu-rtm in sync [08:34] sil2100: ok [08:34] Mirv: well, in theory the second landing shouldn't land without landing the first one in utopic, so it's anyway bad now ;p [08:35] bzoltan: sil2100: therefore only landing 019 / line 31 [08:35] sil2100: FYI CI Train has just allocated a silo that was already allocated :S [08:35] WTH?! [08:35] abeato: I need to kill your ofono and reassign a silo [08:35] o_O [08:35] sil2100: that 019 where uitk synced to.. it's now allocated to ofono somehow [08:35] Mirv, ok, I was trying to reconfigure but it did not seem to work :/ [08:36] the uitk packets were in the silo and I did not find a way to remove them [08:36] Mirv: sil2100: just tell me what should I do :) Do I start testing the line 31 or line 20 or what? [08:36] bzoltan: line 31 please! :) As 31 already has 20 in it, we can trash 20 and just land 31 (which has 2 releases in it) [08:37] Mirv, great, thanks [08:38] bzoltan: final decision! :) test landing-019 utopic (line 31). it's ready already, don't mind the messages that flow here currently. [08:38] Mirv: OK [08:39] * bzoltan goes away to his test cave [08:39] === trainguards: IMAGE 276 DONE (finished: 20141010 08:40) === [08:39] === changelog: http://people.canonical.com/~ogra/touch-image-stats/276.changes === [08:39] === trainguards: RTM IMAGE 95 DONE (finished: 20141010 08:40) === [08:40] === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/95.changes === [08:40] davmor2: ping [08:40] Mirv, so now I need to wait for another silo? [08:41] abeato: yeah, sorry about that. CI Train did something really funny and combined yours and zoltan's silos. [08:41] Mirv, ok, hmm, weird... [08:41] "Trying to reach google.com..."... [08:52] abeato: sorry, also in hangout at the same time :) building now at https://ci-train.ubuntu.com/job/ubuntu-landing-021-1-build/13/console [08:53] Mirv, no worries, thanks [08:57] sil2100: Mirv: what image should be my testing baseline? [08:57] bzoltan: latest utopic I suppose! [08:58] bzoltan: latest utopic yes [09:01] Mirv: sil2100: Sorry, but i am lost -> http://ci.ubuntu.com/smokeng/utopic/ [09:03] bzoltan: yeah I understand. touch_stable is actually rtm. http://ci.ubuntu.com/smokeng/utopic/touch/ has the utopic builds. [09:03] so 275 is latest [09:03] oh, the results are quite crappy. 271 has the latest full results. [09:04] Mirv: 271 it is.. thanks [09:05] ogra_: https://code.launchpad.net/~popey/ubuntu-seeds/ubuntu-touch.utopic-remove-evernote can that merge asap pls? [09:10] * ogra_ installs 95 [09:13] seems ok [09:28] ogra_, you had the sshebang to list OOM scores somewhere? [09:28] found it [09:30] ogra_, davmor2, could you guys please try the dash oom-killed with the .debs from https://code.launchpad.net/~unity-team/qtmir/dash-killed-less-likely/+merge/237915/comments/583630 [09:30] not qtmir-desktop, of course [09:31] * Saviq can't play videos in the BBC app [09:31] Saviq: maybe [09:32] Saviq, try tagesschau.de ... i think thiat works in poland [09:32] or any other news site that has videos === vrruiz_ is now known as rvr [09:37] hmm, i cant get it to crash now [09:37] (s/crash/restart/) [09:39] * ogra_ starts moar apps [09:39] THat's good, right..? [09:39] no [09:40] ah, finally it restarted [09:40] ok, now lets try the new packages [09:46] Mirv, question, is any action required on my side to get the silo for rtm? [09:49] abeato: currently yes, there's the second line I added for you beneath your line, for rtm. once you've tested the utopic landing, a trainguard will assign you an rtm silo and sync the utopic landing to there. then you need to test the rtm silo again. [09:49] more automated dual landings are however coming really soon now, possibly today [09:51] Mirv, so I test, then mark Test pass in spreadsheet, and I ping some trainguard? [09:51] ogra_, seems to be working, couldn't get the dash to get killed [09:51] Saviq, yep, same here [09:52] the score never goes above 502 too [09:52] err 505 [09:52] abeato: yes, for example. the utopic one will be published, and rtm silo synced from there. [09:52] vs 802 for everything else thats backgrounded [09:52] abeato: yes, once you switch it to tested done, we will publish it for you [09:52] sil2100, Mirv , awesome, thanks [09:52] Saviq, i'd say land it :) [09:53] ogra_, now I need to make greyback approve it is all [09:53] ogra_, and then camako needs to deal with the mir landing... [09:53] * greyback takes the hint [10:01] Saviq: doesn't crash here [10:02] trainguards - I have a device tarball to go with ubuntu/landing-003 [10:02] john-mcaleely: hm, we'll need to get this silo to ubuntu-rtm then [10:03] davmor2, awesomes [10:03] sil2100, so, the device tarball can land after the silo safely [10:03] davmor2, BUT IT WASN'T CRASHING!!! :P [10:03] sil2100, john-mcaleely the image builder is broken though ... that will need a bit of manual massaging [10:03] heh [10:03] Saviq: restarting then :P It felt like a crash and that is what people would of thought it was :P [10:03] sil2100, ogra_ I'll get a set of formal test results for the device tarball, and then we can go from there [10:04] john-mcaleely: ok, thanks! [10:04] john-mcaleely, ok [10:05] ogra_: if you mean system-image, Stéphane is on the case now [10:05] hmmm [10:05] tvoss: ping [10:05] sil2100, pong [10:05] sil2100, how can I help? [10:06] tvoss: so, I have a question - since there is silo ubuntu/landing-003 with location-service that's required for the device tarball bits, so I wanted to fill in a sync silo for it to ubuntu-rtm [10:06] tvoss: but I see there's ubuntu-rtm/landing-001 already [10:06] tvoss: which has dbus-cpp and location-service [10:06] sil2100, I think that's lool's and superseded by rtm 5 [10:06] lool, ^? [10:07] cjwatson, yay ... i had to run it once with py2 til it fails and then re-run it with py3 to make it publish ... it had filled up /tmp again over night [10:17] ogra_: https://code.launchpad.net/~sil2100/phablet-tools/citrain_custom_distro/+merge/237935 <- that's a quickie, but do you think this would manage? [10:18] sil2100, yeah, looks ok [10:18] ogra_: I tested both cases and it doesn't seem to break anything [10:19] approved [10:19] Thanks! We need this released now through the train, right? You use MPs? [10:20] tvoss: I would need to know, since as you see there are at least 2 silos with location-service, while in utopic there's a new one ready for release that's needed by the device tarball [10:21] sil2100, the device tarball does not need the silo [10:21] lool, ping [10:34] when was the last promoted utopic image? [10:34] was it really 243? [10:36] It's been a long time... [10:36] We don't have the resources for that right now [10:37] also http://paste.ubuntu.com/8532116/ [10:37] ogra_: do you normally release phablet-tools through MPs? [10:37] emulator seems broken. [10:37] sil2100, yes, but only to utopic (and once it hits the archive it needs to be copied to the PPA for trusty and precise) [10:37] ogra_: ACK [10:38] sil2100, ogra_ new device tarball [10:38] http://people.canonical.com/~jhm/barajas/device_krillin-20141009-ba11639.tar.xz [10:38] http://people.canonical.com/~jhm/barajas/device_krillin-20141009-ba11639.changes [10:38] http://people.canonical.com/~jhm/barajas/device_krillin-testresults-20141009-ba11639.ods [10:38] (plus results in other places) [10:38] john-mcaleely: is it safe to land without that silo 003? [10:39] this is the *exact* tarball tvoss used to test silo 003 [10:39] and it is safe to land before or after [10:39] john-mcaleely, cool, after cjwatson said above that stgraber is on the case i'm not sure i should fiddle manually with the image builder though [10:39] sil2100, ogra_ ^ [10:39] I'm in no hurry for it to be published. so long as it's in a queue :-) [10:39] john-mcaleely: how did he test it if silo 003 is an utopic silo? I thought he was testing things on ubuntu-rtm? [10:39] (so it might take a bit ... not sure where we stand atm) [10:40] sil2100, device tarballs work with either [10:40] tvoss: pong [10:40] sil2100: hey [10:40] sil2100: device tarball is landed by hand [10:41] sil2100: yes, I think you can dispose rtm silo 1 with dbus-cpp and location-service; superseded by the other one [10:41] sil2100: Mirv: the silo19 gave full OK results for UITK, browser and address book app tests. It looks good too. So I would flip that tested switch. [10:41] bzoltan: \o/ [10:41] sil2100: I'm ready to land the updated custom tarballs for rtm; I did it a couple of times before; just waiting for the qa go ahead and yours [10:41] bzoltan: excellent, please switch it and we publish! [10:42] ogra_: I said at the beginning all this image builder stuff was all your fault ;) [10:42] davmor2, definitely [10:42] sil2100: done [10:42] sil2100: I store the AP logs to the same place [10:43] hey, did the new pin unlock dialog got to utopic yet? [10:44] trainguards: hi; for note, silo rtm-002 is ready for qa signoff, but i noted that it needs to be reconfig'ed before landing, just in case [10:44] seems from a report from abeato that it's at least not on mako image 274 [10:44] Mirv: ^ [10:44] let me know if that needs to happen before qa or after [10:44] sil2100: when was the last promoted rtm image? [10:44] popey: 3 days ago I think? [10:45] found it [10:45] ta [10:47] Saviq: not sure I like the dots [10:48] davmor2, I'm sure I don't [10:48] davmor2, they're ugly as hell, and communicate not a gram more of what they mean [10:49] davmor2, they'll go away completely when we only have favourite (and poking) apps on the launcher [10:49] sil2100: where is the mako equivalent of http://people.canonical.com/~ogra/touch-image-stats/rtm/ ? (I assume that's krillin?) [10:49] Saviq: well I guess it is meant to be a pin head for when you pin stuff [10:49] davmor2, yeah, but that only works when you know what it means [10:49] Wellark: dual sim? yes. [10:50] Saviq: indeed, not liking it, I wonder if I block on it being ugly if design will change their mind ;) [10:50] davmor2, !!! [10:51] popey: we don't have those... :| [10:51] sil2100, silo 21 tested (line 66), could you assign an rtm silo? [10:51] Saviq: Don't worry I'll use your They're ugly as hell quote in the bug :D [10:51] sil2100: ugh. so I can't tell whether a package is in a particular image or not ☹ [10:52] popey: we generate those scripts through ogra_'s script, which only is set up for two cases ;< [10:52] it doesnt matter for which device it generates ... the rootfs is the same for all of them [10:52] davmor2, it's a case of "we don't care" I'm afraid [10:52] popey: just blame ogra_ ;) [10:53] popey, you can ... you "just" need to map it to the right rootfs [10:53] popey, by comparing http://system-image.ubuntu.com/ubuntu-touch/ubuntu-rtm/14.09-proposed/krillin/index.json with http://system-image.ubuntu.com/ubuntu-touch/ubuntu-rtm/14.09-proposed/mako/index.json [10:54] abeato: can you make sure https://code.launchpad.net/~phablet-team/ofono/rtm-bug-fix-update-2/+merge/237879 is approved now? [10:54] abeato: we can't release without approved branches :) [10:54] sil2100, sure [10:54] done [10:55] ogra_: hah! yeah, no thanks ☻ [10:56] sil2100, the MP is now approved, could you try again the publish step? [10:57] abeato: sure! [10:57] sil2100, thanks lot :) [10:58] abeato: done! Thanks - sync silo assigned and packages building btw. [10:58] abeato: as you saw from queuebot it's silo 006 for rtm [10:58] sil2100, yup, thanks [10:58] Mirv: ok, soooo... I'll merge this strange branch in a moment - for now don't assign any dual silos, just check if it's releasing normal silos correctly ;) [10:59] Mirv: I'll jump out for lunch soon, so in case you notice that all is broken and dying in agony, then we have a nifty thing in deploy-citrain [11:00] sil2100: ok :) [11:02] sil2100, hey, sorry, the MP still had a pending "Approval" tick, could you try again to publish? [11:02] dbarth: can probably happen after, but I'm not sure what's it about if cjwatson needs to be pinged? [11:03] Mirv: so, after I merge this, deploy-citrain in jenkins has an option to revert to a given revision (DEPLOY_PROD_REVISION) [11:03] cjwatson: so that rtm-002 silo has a comment "IMPORTANT: ping cjwatson to put silo back in canonical form", I don't know what it's about [11:04] Mirv: so just write -2 there (or the exact revision number of before my change) [11:04] sil2100: ok, if everything explodes and something really important would need to be landed right now [11:04] otherwise any problem can wait for your return [11:06] popey, http://paste.ubuntu.com/8532237/ [11:06] * popey hugs ogra_ [11:06] :) [11:07] Mirv: is that silo ready to land then? [11:07] cjwatson: it's ready for QA signoff, david wasn't sure if it can be done now or only when it's going to be published [11:08] cjwatson: so, in other words, contact you when about to publish? [11:08] Mirv: I used +edit-dependencies to make it not build against -proposed, to avoid the mir build currently there; need to set it back to -proposed before anything else uses that silo [11:08] Mirv: contact me when about to merge+clean [11:08] Mirv: or sometime between publish and merge+clean [11:08] cjwatson: ok, clear, I'll make the comment slightly more understandable [11:11] tvoss: I'm going to remove line 21 with https://code.launchpad.net/~thomas-voss/location-service/fix-1373281/+merge/236822 to utopic since it seems it was part of the trunk 115 commit [11:12] or well, I'll mark it as Landed manually [11:13] geh, pep8 compliance... [11:14] sil2100: it seems we've a bunch of landings in the spreadsheet that say "Gave up this landing" while they actually landed. [11:14] they seem to be in trunks, but once again it seems a bit scary [11:15] Mirv: it might be some aftermaths after moving parts of the functionality to the dashboard... Probably some strange race, but we would need Robert for that best [11:16] sil2100: I don't see Mir 0.8.0 release anywhere though... [11:17] WTH [11:18] mir was given up as a consequence of the arm64 failure [11:18] it should be relanded with the fix for that [11:18] cjwatson: it landed in rtm though [11:18] yes [11:18] and none of the trunks have the code [11:18] it's in -proposed [11:18] Mirv: it's in -proposed [11:18] the silo should not have been given up, that was somebody misdriving the train [11:18] but it doesn't hugely matter ... [11:18] Ah, right [11:19] It's the yesterday's issue [11:19] right, so I will leave Mir 0.8.0 lines alone, with again just more clarifying comments, and they will reland [11:19] because it'll all end up being landed separately on utopic with one extra branch, AIUI, and can be merged from there [11:19] Mirv, yup [11:19] but needs the mir folks to be around to do that [11:19] hard to otherwise notice from the other "Cleaned silo, actually landed" cases [11:22] alecu: I assigned silo for your "Add support for multiple currencies" sync to utopic [11:22] jhodapp: rsalveti: line 9 + 10 there's a question for utopic landings on whether those lines are relevant or can be deleted, please answer at some point [11:23] Mirv: ok; and i see you have the full answer now ;) [11:23] * sil2100 watches as his change is merging [11:23] Soon all this confusion will be gone, ha hahhahahah! [11:24] tvoss: is "Land Network Manager WiFi timestamp/scan results fix from tvoss to rtm" line still relevant? the last landing to rtm was https://lists.canonical.com/archives/rtm-14.09-changes/2014-September/000549.html [11:25] Mirv, ah no, that should have landed [11:25] tvoss: thanks, I wasn't sure based on the wording of the landed version [11:29] popey, LOL [11:29] http://www.golem.de/news/html5-videostreaming-netflix-bietet-volle-linux-unterstuetzung-1410-109765.html ... "this is reported by different sources such as the Canonical development boss Alan Pope." [11:30] * ogra_ will call you "the boss" from now on [11:30] tvoss: one more line, I'll mark line 47 with no target distro specified, "Fix #1373281 & #1367244", as Landed manually, as it has landed in utopic and I assume you'll have the big sync to rtm with all the fixes. please tell if that's wrong and it should be another rtm location-service sync silo. [11:31] * Mirv once again feels spreadsheet is an almost adequate state, until the next day [11:31] sweeeeeet! [11:32] popey: du bist Entwicklungschef! [11:32] Mirv: thank you! :) [11:32] That's me! [11:32] The spreadhseet would die without Mirv around :< [11:33] it's a zombie anyhow [11:33] as long as it keep walking ... whi cares if it smells [11:33] *who [11:33] Mirv, yup, I'm planning another rtm sync soonish anyway [11:34] tvoss: thanks [11:35] any ETA on new images for utopic proposed and rtm-proposed? [11:36] Wellark, every night :) [11:39] ogra_: not good enough! [11:39] ;) [11:39] just make it run in constant loop :P [11:39] Wellark, well, we also get new ones if new custom or device traballs land, but they go with unmodified rootfs [11:40] and indeed we *do* build some on demand ... but not regulary [11:40] (every time there is a risky enough landing we build an image specifically for this) [11:41] and yes ... i agree it should be a constant stream ... the prob is that the smoke tests take several hours to run [11:41] speaking of custom, https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/split-custom-tarball/+merge/237905 has a proposed landing procedure for moving a bunch of apps out of rootfs into custom [11:42] ogra_: I though we have indefinite computing power ;) [11:42] cjwatson, hmm, does that make us a seconf custom tarball ? (or do i read that wrong) [11:42] *second [11:42] ogra_: it'll replace the current one for utopic{,-proposed} [11:43] cf. https://bugs.launchpad.net/barajas/+bug/1367332 [11:43] Error: ubuntu bug 1367332 not found [11:43] has anyone tested how fast you could build main using armhf crosscompilation on amazon cloud? :) [11:43] i thought the current one gets applied at system-image level [11:43] yes it does [11:43] would be a fun exercise [11:43] I have modified system-image to be able to deal with this [11:43] then i dont get it [11:43] Wellark: about 35% of main cross-compiled cleanly last I checked [11:43] so s-i stops pulling that tarball and only pulls the one from live-build ? [11:43] correct [11:44] ah [11:44] ok [11:44] that's the configuration change I refer to [11:44] but that also means we need a full image build now when a new custom tarball should land [11:44] the necessary support code is deployed already [11:44] ogra_: that's right, custom tarball building will now be in sync with regular builds [11:44] cjwatson: ugh.. that's depressingly low percentage [11:44] cjwatson, cool [11:45] Wellark: depends on your viewpoint of course, it's quite a step up from where it used to be :) [11:45] sure :) [11:45] I bet [11:45] (more time consuming though ... but i guess thats ignorable ) [11:45] ogra_: that's where the cloud comes in [11:45] ogra_: cjwatson: wait, so we will still be able to do the second custom tarball on jenkins though, right? [11:45] cwayne: for images that contain non-free elements, yes [11:46] cwayne, as i understand nothing changed for your side [11:46] or customer-specific things [11:46] cwayne: you'd need to ensure to include any of the packages being removed from the rootfs that you want to have [11:46] on our side we need to actually trigger an image build to have it picked up [11:47] right any image that still has a custom tarball configured to download with an http method remains as before [11:47] ogra_: well you'd have to trigger an image if you wanted a new set of clicks before anyway [11:47] but this lets us make the default community Ubuntu images have the rootfs/custom split we want [11:47] cwayne, well, click updates are also deployed out of the rootfs, but yeah [11:47] Steve argues the case in comment #31 on that bug [11:48] Wellark: I'd love to spend more time improving this, and have made the case for that a couple of times, but it kind of got sidelined by the rush to phone [11:49] Wellark: I think the next step is to make it possible to configure selected PPAs to use cross-building, so that the auto-cross-builder is less painful to maintain [11:49] * ogra_ is sure the next cycle will be a bit less stressful regarding the phone [11:49] I do hope so [11:49] as we now have something to base oon [11:50] these constant architectural changes everywhere (from phone UI to infrastructure) were what was biting us [11:52] cjwatson: yep. [11:53] and once we would hit the 100% crossbuild state we would never run out of "armhf" builders [11:53] which are slowing us down conciderably [11:54] Wellark: I expect we'll have better hardware well before then [11:54] yeah === karni is now known as karni-afk [11:54] due to get midway-class at some point ... [11:54] cjwatson: were have been counting for "better hardware" for a decade already [11:54] I'm not expecting it arriving soon [11:54]