[00:33] <AlbertA> ribru: the fix is already in rtm:https://launchpad.net/ubuntu-rtm/14.09/+source/unity-system-compositor/+changelog
[00:33] <AlbertA> ribru: hence why I put that comment there
[00:51] <ribru> AlbertA: kgunn: ah yes, the version in rtm does seem to be higher than the one in distro. should I free silo rtm 1 then?
[00:51] <AlbertA> ribru: yeah
[00:52] <ribru> hm, the version in rtm is even newer than utopic/vivid, seems like a sync the other way is needed ;-)
[03:04] <imgbot> [04:19] <imgbot> [04:19] <imgbot> [08:40]  * Mirv frees up 015 (utopic)
[09:30] <ogra_> err
[09:41] <Chipaca> asac: if you ever think you should've gotten a notification and didn't, get me the logs :)
[09:41] <Chipaca> asac: also if you open system settings and see the update downloading, that's why you didn't get the notification -- you get it once it's downloaded
[09:57] <asac> Chipaca: i got notification this morning; +1 for the feature
[10:00]  * ogra_ got it too, OTAed and now his phone restarted the session already 4 times in 2h
[10:00] <ogra_> with really really mild usage ... (two webapps and onyl switching between them at times)
[10:01] <asac> yeah like 50Kb :)
[10:07] <brendand> ogra_, sil2100 - i'm trying out silo 13 to see if it helps
[10:07] <sil2100> brendand: ok, I'll check the media-hub revert in some moments
[10:07] <ogra_> brendand, ++
[10:26] <brendand> sil2100, i think our first blocker might be that flight mode is pretty broken
[10:26] <brendand> davmor2, can you confirm?
[10:30] <dbarth> good morning
[10:30] <dbarth> sil2100: for bugs on the whishlist list, should we go straight for an rtm landing? or vivid + sync
[10:31] <sil2100> Morning
[10:31] <sil2100> dbarth: are you only targeting rtm landings for now?
[10:32] <dbarth> sil2100: actually, we'll want vivid + rtm sync for line 79; so forget that, we'll do the normal process
[10:32] <sil2100> dbarth: you have one trunk right now, right?
[10:32] <dbarth> besides, silo 8 will stay on the side while oSoMoN lands the new silo
[10:32] <brendand> davmor2, also location not working
[10:33] <brendand> hmm i wonder is this silo at fault
[10:33] <dbarth> sil2100: 2 for webbrowser-app, oSoMoN just created an rtm branch for it
[10:33] <oSoMoN> sil2100, webbrowser-app is going to diverge between trunk and 14.09, so we now have two branches, and as a consequence, no sync anymore
[10:34] <sil2100> Right, this is the recommended approach
[10:55] <davmor2> brendand: right back, what do you want me to check other than flight mode
[10:55] <brendand> davmor2, location
[10:55] <brendand> oh wait, location worked in the end
[10:55] <brendand> but not sure if assisted location is working
[10:56] <davmor2> brendand: so flightmode just worked fine here what was the issue you saw?
[10:56] <brendand> davmor2, i turned it off and it still shows the icon and the sim is Offline
[10:56] <brendand> davmor2, but i have a tvoss silo installed
[11:01] <davmor2> brendand: http://people.canonical.com/~davmor2/flight-mode.png http://people.canonical.com/~davmor2/flight-mode1.png http://people.canonical.com/~davmor2/flight-mode2.png
[11:01] <brendand> Mirv, can i request that if you or lorne are planning to do manual testing on silo 22, can you ping me beforehand?
[11:08] <Saviq> sil2100, ogra_, better late than never, congratz!
[11:08] <ogra_> Saviq, thanks !
[11:08] <davmor2> brendand: location is working here too, although it did take longer than normal
[11:09] <davmor2> brendand: took about 10 seconds rather than the 5-7 it normally takes
[11:10] <popey> Mirv: when you have a moment could you please upload http://s-jenkins.ubuntu-ci:8080/job/sudoku-app-click/lastSuccessfulBuild/artifact/generic-click-builder-utopic-armhf/output/com.ubuntu.sudoku_1.1.312_all.click to the store?
[11:11] <brendand> davmor2, does indicator-network show all the networks you'd expect? mine just shows one
[11:13] <davmor2> brendand: http://people.canonical.com/~davmor2/network-ind.png
[11:13] <davmor2> brendand: pretty much what I expect to see
[11:13] <Mirv> brendand: ok, adding a note to the spreadsheet too. I've done a new build in the PPA, but the code reportedly still needs more fixing so no use to test yet.
[11:13] <Mirv> popey: done.
[11:14] <brendand> Saviq, is silo 15 landing today/tomorrow (or hoping to at least)?
[11:14] <Saviq> brendand, yeah, I'm working on that right now
[11:14] <Saviq> brendand, I need to verify one thing and rebuild to be sure and will start testing
[11:14] <brendand> Saviq, will you test it or someone else?
[11:15] <Saviq> but bzr's crapping out on me today...
[11:16] <popey> thanks Mirv
[11:35] <brendand> thostr_, pete-woods - still waiting for instructions on silos 19 and 7. if they aren't going anywhere you should probably free them up
[11:42] <Saviq> sil2100, hey, ~rtm in the version is now unavoidable?
[11:42] <sil2100> Saviq: thanks!
[11:42] <sil2100> Saviq: yeah, basically yes
[11:43] <Saviq> sil2100, ok, /me retargets the silo to vivid then...
[11:43] <sil2100> Saviq: so, last time we ended up with many binary packages with the same version but different contents last time
[11:43] <sil2100> Saviq: which is bad
[11:43] <Saviq> sil2100, different *source* content or?
[11:44] <Saviq> sil2100, or different binary content as well?
[11:44] <sil2100> Saviq: sometimes different source content, sometimes just different binaries (when people were doing source syncs without ~rtm or simply source copies)
[11:44] <Saviq> sil2100, ok, thought it was ok to have the same source build for both
[11:45] <sil2100> You need to have a different version then, as the binaries that get generated are basically different
[11:45] <Saviq> sil2100, yeah understand
[11:45] <Saviq> sil2100, can you please help me retarget the silo quickly then
[11:45] <Saviq> sil2100, line 30
[11:46] <Saviq> sil2100, I'm cleaning the rtm one
[11:46] <sil2100> Ok, let's clean it then and re-assign (that's the only way right now)
[11:53] <oSoMoN> sil2100, if I add/remove branches from a silo, I need to reconfigure it, right?
[11:55] <sil2100> oSoMoN: yes :)
[11:57] <sil2100> Saviq: ok, having problems with jenkins right now
[11:57] <Saviq> sil2100, cleaned
[11:57] <Saviq> sil2100, ok, please let me know when ready
[11:57] <sil2100> Saviq: I'm trying to re-assign, but I think SSO does some problems again
[11:57] <Saviq> sil2100, right, try going to https://ci-train.ubuntu.com/job
[11:57] <Saviq> sil2100, and log in there
[11:58] <Saviq> sil2100, I had to do that with "reconfigure silo" whenever I was not logged in
[11:58] <sil2100> I am logged in but some redirects don't seem to work
[11:58] <Saviq> sil2100, oh :/
[11:59] <sil2100> Mirv: can you help me out?
[11:59] <sil2100> Mirv: can you try going to line 30 in the spreadsheet and trying to assign that?
[12:27] <jdstrand> davmor2: hey, so I was supposed to push rtm silo 3 to rtm, so that cwayne could build the custom tarball so that you could test, but the silo is awaiting qa team signoff
[12:28] <jdstrand> davmor2: I'm happy to walk through the changes with someone from qa if that would help
[12:33] <davmor2> jdstrand: I'm testing it now, so far only issue I've hit is that the news scope isn't displaying anything which I would assume would get fixed in the tarball but I could be wrong looking into that now though
[12:33] <jdstrand> davmor2: ok cool. are there any denials? (this should be unrelated, btw)
[12:35] <davmor2> jdstrand: there are some I've been tailing syslog, but I'll paste you the log after
[12:35] <jdstrand> ok
[12:36] <jdstrand> we aren't really fixing any policy here-- just one for apps that use udm's qml interface
[12:37] <davmor2> jdstrand: so all the apps that are in the list to test so far have been fine, I need to do the incoming out going calls, but got caught up on why the news scope was blank
[12:39]  * sil2100 is retrying the silo assignment
[12:40] <Mirv> sil2100: ok..
[12:40] <sil2100> Still cannot do that ;/
[12:40] <sil2100> It doesn't do the POST it seems, doesn't want to redirect me
[12:40] <sil2100> Mirv: can you try?
[12:42] <Mirv> sil2100: same here..
[12:42] <sil2100> Maybe we need help from webops?
[12:42] <Mirv> sil2100: I've seen similar once before two weeks or ago or so. then I just filled pepare-silo manually.
[12:46] <sil2100> Will do that then
[12:51] <pete-woods> trainguards: hi guys! could I get RTM silo 19 totally reconfigured? I've stripped out the non MRs that fix non-RTM bugs now
[12:52] <sil2100> pete-woods: sure, looking
[12:54] <boiko> sil2100: can I get row 51 of the spreadsheet changed from rtm to vivid?
[12:54] <sil2100> pete-woods: reconfigured and switched to tested: no
[12:54] <sil2100> Please re-build and retest ;)
[12:54] <pete-woods> yep. all good fun
[13:01] <pete-woods> sil2100: sorry could you help out with that?
[13:14] <sil2100> pete-woods: uh, strange, it said it removed that
[13:14] <sil2100> Looking
[13:14] <pete-woods> thanks :)
[13:15] <sil2100> pete-woods: ok, should be good now, but I think something is b0rken in CI Train then ;)
[13:15]  * sil2100 goes prepare lunch o/
[13:21] <abeato> sil2100, Mirv I need a silo for line 73
[13:21] <abeato> gst-plugins-bad
[13:30] <Mirv> abeato: ok
[13:31] <abeato> Mirv, thanks
[13:36] <boiko> trainguards: can I get row 51 switched from rtm to vivid? I have an rtm silo assigned already
[13:48] <psivaa_> ogra_: for health-check tests to run we think psutil is needed in the image: http://dashboard.ubuntu-ci:8080/smokeng/utopic/touch_stable/krillin/135:20141029:20141028-3ca60be/640/health-check/224356/
[13:48] <psivaa_> ogra_: any chance that it was removed along with autopilot
[13:48] <psivaa_> ?
[13:48] <ogra_> psivaa_, where did that come from before ?
[13:48] <ogra_> ah, that might be
[13:49] <ogra_> cant you just install it in the setup phase of health-check ?
[13:49] <Mirv> boiko: it'd mean the PPA rtm-026 would be emptied? (it can't be converted on the fly)
[13:50] <psivaa_> ogra_: we could if that's not needed by anything else
[13:50] <psivaa_> and yes it does not look like being needed
[13:50] <dbarth> trainguards: ping, can we get a silo for line 79
[13:51] <seb128> bah, unity8 segfault while replying to sms using the indicator
[13:51] <ogra_> i doubt it is ... we dont really support python programming for app devs ... and system bits should properly define a dependency
[13:51] <ogra_> seb128, yeah, all the time currently :(
[13:51] <seb128> ogra_, is anyone working on that?
[13:51] <seb128> Saviq?
[13:51] <ogra_> seb128, yeah, indeed :)
[13:51] <Saviq> seb128, got .crash?
[13:52] <seb128> Saviq, maybe, apport still busy doing its thing
[13:53] <boiko> Mirv: yep
[13:53] <seb128> shrug, unity8 respawned but I started the messaging app and it's spinning endlessly now
[13:54] <boiko> Mirv: I will land this stuff only on vivid, and check with bfiller what is worth adding to rtm's wishlist
[13:54] <ogra_> seb128, yes
[13:54] <Saviq> seb128, that might be because the app was left around
[13:54] <ogra_> seb128, apps are not killed along with the session
[13:54] <Saviq> seb128, close and launch again
[13:54] <ogra_> seb128, kill it once and it will work again
[13:55] <Mirv> dbarth: done
[13:55] <Mirv> boiko: ok!
[13:55] <dbarth> thanks
[13:55] <boiko> Mirv: thanks!
[13:57] <seb128> ogra_, Saviq: thanks
[13:57] <seb128> oh, another fallout/fail
[13:57] <seb128> unity respawned, I opened the indicator and the message was still there, and I replied inline
[13:57] <seb128> which acted like that worked
[13:58] <seb128> but apparently it didn't, the message is not in the log nor counted on the lock screen stats
[13:58] <ogra_> and didnt because the messaging app was stuck in bg
[13:58] <Saviq> sil2100, getting the redirect issue when trying to reconfigure, do you have a solution?
[13:58] <seb128> well, isn't that done by a service?
[13:58] <ogra_> that service is called unity8
[13:58] <ogra_> (managing apps)
[13:59] <seb128> no, sending sms
[13:59] <seb128> I though telephony-service was doing that
[13:59] <ogra_> oh, yeah
[13:59] <seb128> e.g that the feature was not relying on the app to run
[13:59] <ogra_> but if the messaging app held that hostage ...
[14:00] <seb128> k
[14:00] <seb128> oh, another fail
[14:00] <ogra_> lol
[14:00] <seb128> replying from the messaging menu, it asks me what sim to use
[14:00] <ogra_> stop that !
[14:00] <seb128> SIM2 SIM1
[14:00] <seb128> or I only have one sim in that phone
[14:00] <ogra_> iirc i heard about a bbug for that one
[14:00] <seb128> whose issue is that?
[14:01] <dbarth> Mirv: of note, oxide is still building in the phablet ppa, but i'll need a binary copy later in the day to silo 15 btw
[14:02] <ogra_> bfiller, ^^^wasnt there a bug for the SIM1/2 selection popup if you only have one SIM ?
[14:04] <seb128> Saviq, no dump no :-/
[14:04] <Saviq> :/
[14:04] <seb128> why the heck is apport failing to collect those?
[14:04] <seb128> SegvAnalysis: Skipped: missing required field "Disassembly"
[14:04] <seb128> bah
[14:05] <ogra_> funny, i definitely have a bunch of .crash files for unity8
[14:05] <seb128> I do
[14:05] <ogra_> and it gets properly updated all the time
[14:05] <seb128> they just are 100k and without gdb dump
[14:05] <seb128> so they are useless
[14:06] <ogra_> errors.u.c should do the processing on a retracer, no ?
[14:06] <seb128> no, they don't have the dump
[14:06] <ogra_> weird
[14:06] <seb128> nothing that can be used for retracing
[14:06] <ogra_> https://errors.ubuntu.com/bucket/?id=/usr/bin/unity8%3A6%3A__assert_fail_base%3A__GI___assert_fail%3A__GI___pthread_mutex_lock%3A__gthread_mutex_lock%3Astd%3A%3Amutex%3A%3Alock
[14:06] <ogra_> thats definitely one of mine
[14:06] <seb128> not that weird, apport doesn't collect those if the dump is larger than some % of the free memory
[14:07] <seb128> so it depends of your free memory
[14:07] <ogra_> ah
[14:08] <dbarth> trainguards, i have line 80 also ready for a silo
[14:08] <dbarth> eh, as the queuebot said
[14:09] <dbarth> i'll prep rtm landing requests targetting backport branches real soon
[14:11] <seb128> shrug, medi-hub eating 100% cpu now
[14:11] <seb128> I think I should properly reboot
[14:11] <seb128> things are weird after unity8 goes down
[14:12] <ogra_> yep
[14:12] <ogra_> i always do a reboot then
[14:13] <Saviq> oh my
[14:13] <seb128> oh, telephony-service segfaulted 10 minutes ago
[14:13] <seb128> could be one of the issues with the replying from menu weirdness
[14:13] <Saviq> I think I exceeded available size of the silo POST header for reconfigure
[14:14] <Saviq> sil2100, ↑
[14:14] <Saviq> sil2100, getting 413 when trying to reconf silo 5
[14:14] <Saviq> which suggests to me the amount of data I'm trying to pass through is too much?
[14:17] <jdstrand> cwayne: davmor2 tells me the silo passed. shall I push now?
[14:17] <cwayne> jdstrand: please
[14:17] <cwayne> ogra_: once apparmor-easyprof-ubuntu gets into the archive can we kick a build? we need it to land a new custom tar
[14:17] <ogra_> Saviq, exceeded the 512 branches limit for a single landing ? :)
[14:18] <Saviq> ogra_, that's what I'm worried indeed
[14:18] <jdstrand> ogra_ (and cwayne): it is apparmor, click-apparmor and apparmor-easyprof-ubuntu
[14:18] <ogra_> cwayne, if sil2100 doesnt object
[14:18] <jdstrand> sil2100: ^
[14:18] <jdstrand> all three :)
[14:18]  * ogra_ doesnt mind doing as many builds as the builders can bear 
[14:19] <ogra_> iw would prefer to do them back to back in a constant flow ...
[14:19] <ogra_> sadly smoketesting wouldnt cope with that
[14:19]  * jdstrand doesn't care how it goes-- I just want to make sure cwayne has all three when he does his custom tarball
[14:20]  * Saviq managed to reconfigure... had to copy the data manuall
[14:20] <Saviq> y
[14:21] <Mirv> dbarth: ok, to both oxide binary copy and line 80
[14:22] <Mirv> landing-029 (vivid) for line 80
[14:22] <jdstrand> can we not reconfigure our silos any more?
[14:23] <jdstrand> I need rtm 003 reconfigured since the apparmor in there is not the version the silo was configured with (we should not rebuild anything though-- it is all tested. this is just to get past the build step)
[14:23] <jdstrand> err
[14:23] <jdstrand> the publish step
[14:24] <jdstrand> "Can't publish: Some packages in the ppa are not at the latest version
[14:24] <jdstrand> Please rerun the prepare job, eventually only with that project."
[14:24] <jdstrand> istr I used to be able to do that ^
[14:25] <jdstrand> ah, it is in the spreadsheet
[14:38] <dbarth> trainguards: i think you can also unload silo rtm 020, which won't be accepted for landing this week
[14:39] <dbarth> trainguards: also, vivid silo 008, the status is really: in testing, not stuck in publishing state
[14:42] <Mirv> jdstrand: publishing worked now . I think build with watch_only alone would have been enough.
[14:42] <jdstrand> cwayne: ok, pushed to proposed. they are finding their way now
[14:42] <jdstrand> Mirv: oh rather than the reconfigure? good to know
[14:56] <bfiller> brendand: I rebuilt the click for camera-app and updated the link in the spreadsheet (also emailed to you)
[15:08] <cyphermox> Wellark: poke, you responsible for rtm landing 013?
[15:08] <dbarth> trainguards: i have verified silo 009, but it seems the spreadsheet is out of sync: i can't mark it tested there, can you help
[15:09] <asac> sil2100: did we get to the bottom of the unity instability yet?
[15:09] <dbarth> it should correspond to line 28, for landing in vivid
[15:10] <dbarth> it is also silo rtm 20 which is verified, but should *not* land on rtm
[15:11] <cwayne> jdstrand: what version of click-apparmor should be in 14.09?
[15:11] <Wellark> cyphermox: dunno
[15:11] <Wellark> cyphermox: lemme check
[15:11] <cyphermox> Wellark: if you're not touching it then all is fine
[15:12] <Wellark> cyphermox: tvoss is
[15:12] <Wellark> but apparently he got ebola or something
[15:12] <cyphermox> I just want to make sure it doesn't clash with the vivid landing for other dbus-cpp fixes..
[15:12] <Wellark> cyphermox: other dbus-cpp fixes?
[15:12] <Wellark> cyphermox: I don't even know how that should relate to them
[15:12] <cyphermox> http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=dbus
[15:12] <Wellark> cyphermox: that branch fixes two top blockers
[15:12] <Wellark> *silo
[15:13] <Wellark> so we need them in
[15:13] <cyphermox> you can't build dbus-cpp separately and land one without telling someone about the other
[15:13] <cyphermox> ie. the second to land needs to get rebuilt
[15:13] <Wellark> cyphermox: I'm not landing anything
[15:13] <asac> ChickenCutlass: do you know that folks think that unity crashing might be media-hub related?
[15:13] <cyphermox> Wellark: that's all I wanted to know, thanks
[15:13] <Wellark> cyphermox, thostr_: please figure out what to do with rtm-013 silo
[15:13] <ChickenCutlass> asac: I asked kgunn yesterday and that was not the case
[15:14] <ChickenCutlass> asac: and if it is.  That is a real problem — how could that happen
[15:14] <cyphermox> thostr_: how ready are you changes to land? also, have they landed in vivid yet?
[15:14] <asac> ChickenCutlass: i think its a different thread if media-hb can bring down unity, but still doesnt make it less important
[15:15] <kgunn> ChickenCutlass: yeah, so theory is notifications are effectively audio clients, so create/kill...causes "left overs" to hang around on dbus
[15:15] <thostr_> Wellark: cyphermox: this is tvoss... anyhow, I just started to rebuild as it had a strange build error...
[15:15] <kgunn> at least the signature matches
[15:16] <jdstrand> cwayne: click-apparmor 0.2.11.2, apparmor-easyprof-ubuntu 1.2.38 and apparmor 2.8.96~2652-0ubuntu5.3
[15:16] <kgunn> for a fix that is comming from tvoss
[15:16] <ChickenCutlass> kgunn: asac  so that is not media-hub.  That is prob the sbud client
[15:16] <ChickenCutlass> right
[15:16] <ChickenCutlass> ok
[15:16] <cyphermox> thostr_: so you're not driving the landing right now, just rebuilding out of interest?
[15:16] <kgunn> ChickenCutlass: yeah...the bug currently reflects this theory/thinking
[15:16] <jdstrand> cwayne: your custom tarball will include the 'touch -t' change on /var/lib/apparmor/profiles/click_*?
[15:16] <ChickenCutlass> kgunn: ok thanks
[15:17] <kgunn> ChickenCutlass: people just aren't reading :)
[15:17] <ChickenCutlass> lol
[15:17] <thostr_> cyphermox: well, this might be the root cause also for the unity crashes we're seeing... so just trying to help while tvoss is away
[15:17] <cyphermox> alright
[15:17] <cyphermox> I think we should possibly look into landing this in vivid first...
[15:19] <cwayne> jdstrand: yep, it will
[15:19] <jdstrand> nice
[15:19] <cwayne> sil2100:  ogra_: so all the bits for apparmor are ready, could we kick a build?
[15:20] <cyphermox> thostr_: can I ask you what crashes? there's other changes which might help too..
[15:20] <ogra_> sure ... sil2100 ?
[15:20] <sil2100> Yeah, sorry guys, had lunch and then UE Live
[15:20] <sil2100> ogra_, cwayne: looking at the backlog, but I think it's +1
[15:20] <ogra_> i just want a "yes" :)
[15:20] <thostr_> cyphermox: it's still the issue of not having a dash
[15:20] <cyphermox> hum, what bug is that?
[15:21] <ogra_> sil2100, apparmor needed in image before custom tarball can land
[15:21] <cyphermox> is there a stack trace on it?
[15:21] <ogra_> thats what this build is for
[15:21] <thostr_> cyphermox: https://bugs.launchpad.net/ubuntu/+source/unity-scope-scopes/+bug/1386653
[15:21] <sil2100> ogra_: yeah, as I thought
[15:21] <cyphermox> ah, thanks
[15:21] <sil2100> dbarth: still having problems setting the silo to tested yes?
[15:22] <dbarth> sil2100: yeah, i guess so
[15:22] <dbarth> sil2100: i was trying to clean up the various silos i have around
[15:23] <dbarth> sil2100: so if we take 020(rtm) and 009(utopic/vivid)
[15:23] <ogra_> cwayne, sil2100 build triggered
[15:23] <dbarth> sil2100: i'd like to delete 020(rtm) and land 009
[15:23] <cwayne> ogra_: thanks
[15:23] <cwayne> davmor2: so once the build is done, would you still have time for custom test?
[15:24] <cwayne> there were a few more changes that leaked in, but most are quite trivial
[15:24] <oSoMoN> dbarth, sil2100: do you remember if a binary copy from the phablet-team PPA (for oxide-qt) is enough, or if a source copy is needed?
[15:24] <sil2100> dbarth: ok, so delete 20 you say - let me free that up then
[15:24] <sil2100> And check sil0 009
[15:24] <oSoMoN> trainguards: can I haz a silo for line 81, please?
[15:24] <sil2100> oSoMoN: where do you want to land it?
[15:24] <dbarth> sil2100: yup
[15:25] <oSoMoN> sil2100, rtm
[15:25] <dbarth> incidentally, oxide is now finished building in https://launchpad.net/~phablet-team/+archive/ubuntu/ppa/+packages
[15:25] <davmor2> cwayne: in theory yes, as we are looking to use it to check for issues in the image but it depends how long
[15:25] <sil2100> oSoMoN: if the phablet-team PPA oxide-qt has been built for utopic then a binary copy to the ubuntu-rtm silo should be enough
[15:25] <oSoMoN> dbarth, which is why I was asking :)
[15:25] <dbarth> it was for utopic indeed
[15:26] <dbarth> nice, more silos ready
[15:26] <oSoMoN> excellent, a binary copy will save us time (5+ hours to be precise)
[15:27] <sil2100> dbarth: can you try changing the tested field now?
[15:27] <dbarth> ok
[15:28] <dbarth> marked tested, let's see what the bot says
[15:29] <imgbot> [15:29] <bdmurray> sil2100: what needs to happen next for fixing bug 1339916 in ubuntu-rtm?
[15:31] <ogra_> bdmurray, do you have a silo already with lxc-android-config in it ?
[15:33] <sil2100> bdmurray: oh! Ok, let me help out with that landing, I think we forgot you didn't do any landings before :) So, that's a whoopsie upload + something else, right?
[15:39] <bdmurray> sil2100: yes, a whoopsie sync from utopic and an upload of lxc-android-config
[15:39] <sil2100> Excellent
[15:39] <sil2100> Preparing
[15:44] <sil2100> bdmurray: now we need to upload lxc-android-config
[15:44] <sil2100> bdmurray: can you check if you can upload to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-009 ?
[15:46] <bdmurray> sil2100: I don't see the "You can upload packages to this PPA using" message from Launchpad
[15:47] <sil2100> hmmm... ok, then the easiest way would be for you to provide me a source package for lxc-android-config
[15:47] <sil2100> And I'll upload
[15:47] <sil2100> (since I have no power to grant upload powers)
[15:49] <ogra_> make sure you use the lxc-android-config from rtm as base actually
[15:49] <ogra_> rtm and utopic diverged
[15:50] <bdmurray> ogra_: right, you'd pointed me at rtm4 previously
[15:51] <ogra_> :)
[15:51] <oSoMoN> sil2100, ribru: can I have a rtm silo for line 81, pretty please?
[15:52] <Mirv> oSoMoN: ok
[15:57] <oSoMoN> trainguards: can you please publish silo 4 (vivid) ?
[15:58] <Mirv> bfiller: can you arrange that the same camera-app being published from rtm-018 is uploaded as .click to the store? (I can also upload, if just given .click url)
[15:58] <Mirv> oSoMoN: MP not approved
[15:59] <Mirv> oh, it's "Merged". that should be pretty approved...
[15:59] <Saviq> ogra_, are there no vivid images yet? ;|
[15:59] <Saviq> how am I supposed to test anything...
[15:59] <Mirv> ogra_: hey ogra, were there any vivid images yet? how about questions about whether there are vivid images? ;)
[16:00] <Mirv> Saviq: he has had around 40 requests in 24h about the topic :)
[16:00] <Saviq> ogra_, are there no vivid images yet?
[16:00] <Saviq> 41
[16:00] <oSoMoN> Mirv, d’oh, I was pretty sure I had removed the MR from the list this morning, sorry about that
[16:00] <Saviq> ogra_, are there no vivid images yet?
[16:00] <Saviq> 42
[16:00] <Saviq> now that's a good number
[16:00] <oSoMoN> Mirv, can we force the publication, or do I need to manually revert the state of the MR to "approved" ?
[16:00] <Mirv> oSoMoN: we can force, no problem
[16:01] <oSoMoN> Mirv, excellent, thanks
[16:02] <oSoMoN> sil2100, Mirv, ribru: can one of you please do the binary copy of oxide-qt from https://launchpad.net/~phablet-team/+archive/ubuntu/ppa/+packages to ubuntu-rtm/landing-015 ?
[16:04]  * ogra_ throws little paperballs at Saviq and Mirv 
[16:04] <ogra_> i'm working on it ...
[16:05] <ogra_> (should be ready later tonight ... no promise that they boot though ... there is a good bunch of systemd services now)
[16:05] <Mirv> oSoMoN: done. required command line usage.
[16:06] <oSoMoN> Mirv, thanks!
[16:07] <ogra_> Saviq, there were build machine issues til late last night ... and today i already spent all day fixing up the build scripts ... but it will still take a while, each iteration of changes takes hours
[16:09] <ogra_> asac, bug 1387231
[16:09] <ogra_> :)
[16:09] <cyphermox> Mirv: hey, I top-approved the merge that wasn't approved yet in ubuntu silo 12
[16:10] <cjwatson> Not build machine issues as such, I just didn't write the livefs copying script quite right (this was the first cycle we had to do this, since livefs-in-LP was new last cycle) and so the livefs objects had the wrong require_virtualized setting
[16:10] <brendand> plars, why are terminal and dropping letters still on the krillin dashboard?
[16:11] <ogra_> cjwatson, yeah, i tried to simplify :)
[16:11] <cjwatson> I've since fixed the script so that this won't be a problem next time
[16:11] <ogra_> issues with building on the wrong machine :)
[16:11] <cjwatson> Yeah
[16:11] <Mirv> cyphermox: there's the other branch still https://code.launchpad.net/~thomas-voss/dbus-cpp/fix-1361642/+merge/236820
[16:12] <cyphermox> AGH, people changed it
[16:12] <cyphermox> this is ridiculous
[16:12] <ogra_> slap the people
[16:12] <ogra_> :)
[16:12] <cyphermox> I'll just scrap that branch and make a new one
[16:13] <asac> ogra_: thx. commented on it; i dont think it is mine though
[16:13] <asac> mine is about disabling, not deleting
[16:13] <asac> deleting helped/worked in the end
[16:14] <ogra_> cyphermox, see line 55 on eth spreadsheet (and silo 13)
[16:14] <cyphermox> that was added
[16:14] <cyphermox> I'm getting tired of this
[16:15] <cyphermox> Mirv: you can scrap lines 74 and 75
[16:15] <brendand> kgunn, there is a problem with silo 13 - it seems i can't get out of flight mode once i enable it
[16:15] <brendand> kgunn, on the bright side it makes the crashes go away!
[16:16] <kgunn> brendand: sort of good news :)
[16:16] <ogra_> there is a million of things in that silo
[16:17] <Mirv> cyphermox: maybe just reuse the silos for the new branches?
[16:17] <kgunn> a million ?
[16:17] <ogra_> its like it is its own distro :)
[16:17] <cyphermox> Mirv: no
[16:17] <kgunn> ogra_: you talkin' bout silo 13v?
[16:17] <Mirv> cyphermox: ok. so, freeing up silos landing-012 and rtm-009
[16:17] <cyphermox> thanks
[16:17] <ogra_> kgunn, indicators, media-hub, location-service dbus-cpp
[16:17] <ogra_> kgunn, no, rtm 13
[16:17] <Mirv> cyphermox: rtm-011, that is...
[16:17] <kgunn> right
[16:18] <cyphermox> correct
[16:18] <ogra_> kgunn, who cares about v silos ... cant test them anyway
[16:18] <kgunn> ogra_: it was acutally a typo....my thumb spas'd
[16:18] <kgunn> or is it spazzed
[16:18] <ogra_> oh, heh
[16:18] <kgunn> but yeah, that's not a million....but does unblock a lot of criticals
[16:19] <ogra_> yeah
[16:20] <dbarth> trainguards: please don't publish silo 029, it needs a rebuild now that silo 9 is landing
[16:21] <dbarth> trainguards: i may also need to manual help for silo 9 landing (it should really go onto vivid, even if marked as a utopic build)
[16:26]  * Mirv starts executing a late "do eod" plan
[16:28] <dobey> dbarth: eh? if for silo 9 you mean row 28 in the spreadsheet, it's built on vivid, not utopic
[16:29] <Mirv> bfiller: right, the branches were in that rtm landing, so now published + m&c:d plus kicked a new .click build at s-jenkins to build from the now updated trunk. just get someone to upload it to the store when it's ready.
[16:30] <dbarth> dobey: ah ok, so fine; i'll just wait for it to exit the -proposed pocket
[16:30] <dbarth> is there something i can do to speed that up? i have another silo to rebuild just after that
[16:32] <dobey> dbarth: no, that's pretty automated at this point, but can be slow for some packages, waiting on archive builders and publishing. but it should copied to release pocket once it's published in proposed within 30 minutes at most, generally
[16:32] <dbarth> ok, perfect; thanks
[16:33] <dobey> at least, that's my understanding of how often the automated pocket copy works for in-development ubuntu series
[16:34] <imgbot> [16:34] <imgbot> [16:34] <davmor2> cwayne: ^
[16:34] <ogra_> hurry up
[16:34] <ogra_> where is the tarball ?
[16:35] <cwayne> built i like 30 mins ago
[16:35] <dobey> come on debootstrap
[16:35] <cwayne> should have been imported by now probably, version 1414598646
[16:35] <oSoMoN> trainguards: it looks like https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-015/+packages is full, and it prevents building packages, can its size be increased?
[16:37] <Saviq> brendand, can you please confirm that without rtm silo 13 flight mode works fine for you? I don't think the change there could've caused that
[16:37] <brendand> Saviq, it does work fine for sure
[16:38] <brendand> Saviq, i'll do another cycle of testing to make sure
[16:38] <brendand> Saviq, but i've already done two
[16:39] <Saviq> brendand, ok, I just have seen flight mode trouble all over the place
[16:40] <brendand> Saviq, well yeah flight mode is troublesome
[16:40] <brendand> Saviq, this is pretty reproducible for me though
[16:44] <cwayne> davmor2: looks like import-images hasn't finished yet
[16:45] <cwayne> oh nm maybe it has, just got an ota
[16:45] <sil2100> oSoMoN: oh! I think we'll need IS for that...
[16:45] <oSoMoN> :/
[16:45] <davmor2> cwayne: no worries, just let me know I'm busy writing a test plan :)
[16:48] <cwayne> davmor2: i think it's all in now
[16:48] <cwayne> doing a fresh flash here to check
[16:49] <oSoMoN> sil2100, can you do the request to IS?
[16:49] <davmor2> cwayne: right what is the image number so I know I'm on the right one please
[16:49] <cwayne> davmor2: let me verify it on a fresh flash first so I don't waste your time :)
[16:49] <cwayne> will get you the image number soon as its done
[16:50] <ogra_> davmor2, ust be 137
[16:50] <ogra_> *must
[16:50] <dbarth> trainguards: can i get a silo for line 82 please; this is an rtm silo for a bug that has now been approved for landing
[16:54] <ogra_> jdstrand, hmpf ...
[16:54] <davmor2> cwayne: flashing version 175 does that sound right
[16:54] <sil2100> oSoMoN: sure
[16:55] <jdstrand> ogra_: ?
[16:55] <sil2100> dbarth: ok!
[16:55] <cwayne> davmor2: yep, just verified it
[16:55] <oSoMoN> sil2100, thanks!
[16:55] <davmor2> ogra_: no cwayne 's channel is way ahead when it is released it is the next image on rtm
[16:55] <ogra_> jdstrand, 5min boot in 137
[16:55] <jdstrand> that is expected until cwayne's tarball lands
[16:55] <ogra_> ah
[16:56] <ogra_> then i'm fine :)
[16:56] <jdstrand> as discussed here earlier
[16:56] <cwayne> 13 sec bq screen on -customized :)
[16:56] <cwayne> jdstrand: Modify: 2013-12-31 11:59:00.000000000 +0000
[16:56] <cwayne> :)
[16:56] <ogra_> that sounds better
[16:56] <jdstrand> ogra_: so, that 5 minute boot time is actually down quite a bit from other times when it had to recompile all the policy, no?
[16:57] <jdstrand> cwayne: nice :)
[16:57] <ogra_> jdstrand, i have seen up to 13min, yeah
[16:57] <jdstrand> right
[16:57] <jdstrand> that was part of that upload
[16:57] <sil2100> slangasek, ogra_: so, I think I have generated a list of missing landings for both distros, just need to double check still if the script does it right
[16:57] <ogra_> well, not boot but only bootlogo
[16:57] <jdstrand> of course, we want to avoid those even if they are faster then before, hence the coordination with cwayne
[16:58] <ogra_> yeah, well, i knew it ... just didnt think of it
[17:04] <sil2100> bzoltan_: any ETA for landing the AP test fix?
[17:04] <sil2100> We need it in ASAP
[17:16] <brendand> Saviq, i have a slightly unusual config in that i have two locked sims
[17:16] <Saviq> brendand, how is that unusual? :)
[17:16] <Saviq> same here, actually
[17:16] <ogra_> you guys are so unusual !
[17:16] <brendand> Saviq, well joc who only has one can't reproduce the same failure with silo 13
[17:16] <brendand> Saviq, can you?
[17:16] <Saviq> brendand, testing another silo now
[17:17] <brendand> Saviq, ok
[17:20] <slangasek> ogra_: I've got confirmation from asac that we're good to redirect the 'stable' channel to ubuntu-rtm/14.09 now
[17:20] <ogra_> slangasek, great, i havent had any system-image training so this time stgraber will still have to do it
[17:20] <slangasek> ogra_: yeah, I just got the rundown from stgraber on how to do it; I'll send an email first
[17:21] <ogra_> cool
[17:21] <ogra_> hopefully with the next build i should also have vivid images
[17:21] <slangasek> john-mcaleely: ^^ this channel name change impacts how we should be flashing the devices going forward, I believe
[17:22] <ogra_> and the build will now spit the info thats needed for new passwd and friends directly in the log
[17:22] <john-mcaleely> maybe. depends which channel name... slangasek ^
[17:22] <ogra_> so you dont need to do a build at how to get the md5 etc
[17:22] <ogra_> slangasek, be carefule though, i dont think we had krillin in stable before, that might require extra tweaking
[17:23] <ogra_> (at least adding the arch)
[17:26] <slangasek> john-mcaleely: the channel name will be 'ubuntu-touch/stable' going forward
[17:26] <ogra_> rather ubuntu-touch/ubuntu-rtm/stable ?
[17:26] <ogra_> 'ubuntu-touch/stable' would be "vivid stable"
[17:27] <cwayne> wouldnt ubuntu-touch/stable be utopic
[17:27] <ogra_> cwayne, utopic is dead
[17:27] <ogra_> it is composting already
[17:28] <sil2100> oSoMoN: bumped :)
[17:28] <cwayne> right, but wasn't the last released usually what was put in stable
[17:28] <sil2100> slangasek:
[17:28] <sil2100> \o/
[17:28] <ogra_> well, stable should have our last stable image
[17:28] <ribru> AlbertA: do you know what's happening with silo rtm 10? I can't find it in the spreadsheet.
[17:28] <cwayne> i.e. stable was trusty all throughout the utopic cycle
[17:28] <sil2100> slangasek: give us a sign once it's done and I'll include the info in the e-mail
[17:28] <slangasek> ogra_: no, not ubuntu-rtm/stable because as discussed elsewhere we don't want that name to persist
[17:28] <oSoMoN> sil2100, awesome, I didn’t think it would be that fast, thanks man!
[17:28] <sil2100> I'll have to update the developer documentation as well though
[17:28] <ogra_> utopic surely isnt at a quality to become stable
[17:29] <sil2100> oSoMoN: thanks go to cjwatson, he's always so fast in doing things ;)
[17:29] <slangasek> ogra_: and no, stable doesn't point to vivid because that's the devel channel that will become "stable" only around OTA-3
[17:29] <ogra_> slangasek, ok, it just doesnt match the existing channel structure, curious how s-i will handle the delta for this
[17:29] <slangasek> ogra_: this is a false choice; there's nothing *else* that's more stable
[17:30] <ogra_> yeah, it is actually the only "stable" channel we have
[17:30] <ogra_> under rtm we never created a stable one
[17:31] <AlbertA> ribru; you can release that one
[17:32] <brendand> Saviq, it's working better now. maybe it was rebuilt since i tried it earlier
[17:32] <ogra_> slangasek, looking at http://system-image.ubuntu.com/ubuntu-touch/stable/ we should probably consider ripping out all the arches that fell behind though ... manta and  flo are most likely not at the quality level of mako or krillin (and i'm not soure there are QA resources to even test them)
[17:33] <ogra_> and maguro would even only get you a trusty image ... we should consider obsoleting that imho
[17:33] <ogra_> thats to far behind already
[17:33] <bdmurray> which channel do I want to install from to test my rtm whoopsie changes?
[17:33] <slangasek> bdmurray: ubuntu-touch/ubuntu-rtm/14.09
[17:34] <ribru> AlbertA: by 'release' do you mean 'free'?
[17:34] <ribru> AlbertA: as in 'not publish it' ;-)
[17:34] <slangasek> bdmurray: sorry, I mean ubuntu-touch/ubuntu-rtm/14.09-proposed
[17:34] <ogra_> bdmurray, rtm-proposed ... see --list-channels in ubuntu-device-flash
[17:34] <AlbertA> ribru: sorry yes...:)
[17:34] <bdmurray> okay, I'd chosen the former and it seemed old to me
[17:34] <ribru> AlbertA: ok thanks
[17:34] <cwayne> davmor2: ive got to go afk for a bit, ping/email me when testing of custom is done and I'll push the magic button when I return
[17:34] <cwayne> sil2100: ^
[17:34] <slangasek> ogra_: right, yes; let's definitely clean up those devices that should no longer be on the channel, but also let's worry about that after this initial switch
[17:35] <ogra_> yeah
[17:36] <davmor2> cwayne: will do
[17:36] <john-mcaleely> um, so ubuntu-touch/stable alias' to what? slangasek
[17:36] <cwayne> davmor2: thanks man
[17:36] <slangasek> john-mcaleely: ubuntu-touch/stable will alias to ubuntu-touch/ubuntu-rtm/14.09 for now
[17:36] <AlbertA> ribru: and rtm silo 001 can also be freed
[17:36] <john-mcaleely> slangasek, that sounds good
[17:38] <john-mcaleely> slangasek, let me know when I can try that?
[17:38] <john-mcaleely> so will we be adding a stable-proposed alias?
[17:38] <john-mcaleely> (I don't believe there is one today)
[17:39] <slangasek> john-mcaleely: not planning to add one at the moment, as I assume that nobody needs to track stable-proposed as a thing right now
[17:39] <john-mcaleely> hrm. I think we need it to test stuff, but I'll defer that to others
[17:39] <slangasek> john-mcaleely: we need a -proposed channel for testing stuff, but it doesn't necessarily have to be /called/ stable-proposed which would just be an alias
[17:40] <john-mcaleely> true enough
[17:44] <ogra_> john-mcaleely, we will never build any images into stable or devel ... the only place where we build them is -proposed ... then they get copied into devel or stable ... so there is no need to have more than actually one proposed channel from which we can populate the others
[17:45] <ribru> AlbertA: oh yeah. ok done
[17:47] <ogra_> oooh shiny !!!
[17:47] <ogra_> https://launchpadlibrarian.net/188621599/buildlog_ubuntu_vivid_armhf_ubuntu-touch_FAILEDTOBUILD.txt.gz
[17:47]  * ogra_ likes that 
[17:48] <ogra_> ... now it gives you exact instructions what to do to make the next build not fail at the end of the log :)
[17:48] <cjwatson> s/crated/created/
[17:48] <ogra_> bah !
[17:49] <ogra_> will fix with the next iteration :)
[17:50] <ribru> Saviq: ok you got rtm 10
[17:51] <Saviq> ribru, (did you change your name to Ribert?), thanks
[17:51] <ogra_> Saviq, well, matching the topic :)
[17:51] <Saviq> ribru, oupsikesy
[17:52] <Saviq> ribru, don't laugh (or cough... or sneeze... breathing is not really necessary either, is it?)
[17:52] <ribru> Saviq: A witch turned me into a frog, now I can only say 'ribbit'
[17:52] <ribru> ribbit ribbit
[17:55] <sil2100> brendand: sorry, got a bit distracted, but here's the bug for the UITK: https://bugs.launchpad.net/qtmir/+bug/1382414
[17:55]  * sil2100 seems to have internet problems again
[17:56]  * ogra_ sends some cans full of internet to sil2100 
[17:56] <ogra_> oh ... and a can opener ... in case you dont have one
[17:56] <sil2100> Yeah, please!
[18:03] <john-mcaleely> ogra_, I think the time we need 'stable proposed' will be to test ota from previous stable builds to the one we want to release. There other ways we can do that though
[18:03] <ogra_> john-mcaleely, where would that ota image come from ?
[18:03] <ogra_> i mean, i guess you would just build it from the rtm archive after you landed some fixes
[18:04] <john-mcaleely> ogra_, I think it depends on if there have been multiple private builds, and so we need to test what public handsets will see
[18:04] <ogra_> which will make the image pop out in ubuntu-touch/ubuntu-rtm/devel-proposed ... where you can test
[18:04] <john-mcaleely> ogra_, to be honest, I'm happy to suck it and see
[18:04] <ogra_> yeah
[18:05] <ogra_> we wont have "multiple private builds" of the rootfs
[18:05] <john-mcaleely> what, no images testing fixes one by one?
[18:05] <ogra_> you will perhaps have additional changes in custom or device tarballs
[18:05] <john-mcaleely> which we roll into one build for stable handsets?
[18:05] <ogra_> but these can also iterate over devel-proposed
[18:06] <ogra_> and once QAed can be copied into stable
[18:07] <ogra_> if you have different custom tarballs (unlikely ot ever have different devvice tarballs for the same device in one release) you can indeed have stable-custom-foo
[18:07] <ogra_> but that would again come out of devel-custom-foo
[18:07] <ogra_> or devel-custom-foo-proposed
[18:08] <ogra_> rootfs and device tarballs will always just move forward ... custom might move sideways at tiimes though
[18:16] <ogra_> grr, in my shiny livecd-rootfs change i forgot the md5 for /etc/group and gshadow :(
[18:18] <AlbertA2> fginther: we are getting a CI failure for i386 builds: https://jenkins.qa.ubuntu.com/job/mir-android-utopic-i386-build/2297/console
[18:18] <AlbertA2> fginther: any ideas?
[18:18] <fginther> AlbertA, looking
[18:18] <josharenson> fginther, were you, or anyone else, ever able to re-enable the mi-performance-test- job?
[18:20] <fginther> josharenson, yes it was re-enabled on Monday. The latest runs show results (I think I sent you an email earlier today)
[18:22] <josharenson> fginther, cool thanks
[18:23] <fginther> AlbertA2, this is very strange. there are several failures and each appears to mention a different missing package
[18:32] <sil2100> slangasek: I just got the 'Landing pipeline:' e-mail - wasn't that supposed to be sent out last week? ;)
[18:32] <sil2100> slangasek: as it mentions the sprint ;)
[18:32] <sil2100> slangasek: ARGH
[18:32] <sil2100> slangasek: ok, scratch that
[18:33]  * sil2100 needs more coffee or a kick in the butt
[18:33] <slangasek> sil2100: ok - I was gonna say, I didn't send any such mail today ;)
[18:33] <sil2100> slangasek: yeah, I think I'm braindead today or something
[18:38]  * ribru -> lunch
[18:42] <bdmurray> sil2100: so my silo looks good to me. Is there anything I need to do? update the spreadsheet?
[18:43] <ogra_> bdmurray, test it on a device ... then set the spreadsheet to testing done
[18:43] <slangasek> john-mcaleely: ubuntu-touch/stable now points to 14.09
[18:44] <sil2100> bdmurray: if you have tested it on an 14.09 image, then please change the K column to 'Yes (#image_number device your_nick)'
[18:44] <sil2100> And then it's all up to QA :)
[18:46] <bdmurray> sil2100: okay, done. thanks for the help!
[18:46] <sil2100> \o/
[18:46] <ogra_> yay
[18:47]  * ogra_ looks forward to eventually finding his error reports by lcicking the button in system-settings
[18:49] <thomi> licking the button? O.0
[18:50] <dobey> it's just like OS X
[18:52] <sergiusens> slangasek: hah, the stable channel is finally useful!
[18:52] <fginther> AlbertA2, I noticed that all the failures are coming from the same node (although it also had plenty of successful builds as well), so as a first step I've disabled that node.
[18:52] <sergiusens> u-d-f's default too
[18:53] <AlbertA2> fginther: ack
[18:55] <fginther> AlbertA2, also, debootstrap which the mir cross compile uses does not appear to have any built-in retry mechanism. So if the apt repository (ports.ubuntu.com in this case) is ever unreliable, the entire bootstrap will fail. The cross-compile scripts should take this into account
[18:57] <ogra_> sergiusens, oh, we still default to that ?
[18:57] <ogra_> nice
[18:57] <slangasek> ogra_: I guess you have a handle on livecd-rootfs, nothing you need help with?
[18:58] <ogra_> slangasek, well, if this upload has landed and the nnext image fails i will
[18:58] <cwayne> davmor2: hows custom lookin?
[18:58] <ogra_> slangasek, i *belive* it is fixed with this last upload ...
[18:59] <slangasek> ok
[19:00] <sil2100> cwayne: it might take some time still I suppose, as davmor2 is performing some extra testing there
[19:00] <AlbertA2> fginther: aah.....I'll check with the team...why are we even calling cross_compile_chroot for CI - that doesn't seem right...
[19:01] <cwayne> sil2100: right, i wasnt trying to rush you guys, just wanted to check in and see if there's anything i needed to fix :)
[19:02] <oSoMoN> trainguards: I’ll need your help reconfiguring ubuntu-rtm/landing-015, I added a MR for webbrowser-app and the silo won’t let me reconfigure it myself
[19:06] <davmor2> cwayne: tea got in the way too :)
[19:10] <cwayne> davmor2: :)
[19:16] <oSoMoN> trainguards, sil2100, ribru, anyone?
[19:16] <sil2100> oSoMoN: hey!
[19:16] <sil2100> oSoMoN: so, let me try helping you inbetween :)
[19:17] <oSoMoN> sil2100, sorry if I sound insistent, trying to land urgent stuff… :/
[19:17] <sil2100> oSoMoN: no worries! ribru is on lunch so he would only take care of your request a bit later
[19:18] <sil2100> oSoMoN: reconfiguring :)
[19:22] <ribru> just back!
[19:22] <ribru> sil2100: thanks
[19:24] <oSoMoN> sil2100, thanks!
[19:25]  * sil2100 goes off to exercise a bit
[19:25] <sil2100> oSoMoN: yw!
[19:25] <sil2100> Sorry it took so long ;)
[20:13] <barry> sil2100: if you're still around, i *finally* have an mp for si 2.5.1-0u1.  i'm going to add it to the spreadsheet for ubuntu and we'll go from there
[20:13] <barry> sil2100: i'm going to try to get this into tomorrow's image if i can get at least one other person to test it
[20:17] <ribru> barry: I'm around to assign and help test, just need some testing instructions
[20:18] <barry> ribru: awesome, thanks.  just got assigned silo ubuntu/landing-004.  i'll ping you for testing when the ppa build finishes
[20:18] <barry> ribru: the row has a link to the test plan
[20:18] <barry> ribru: Test G will be the one specifically addressing this bug (but the other tests are good to ensure no regressions)
[20:19] <ribru> barry: cool
[20:20] <alecu> thanks!
[20:20] <barry> aw crap
[20:22] <barry> yeah yeah, thanks queuebot
[20:28] <ribru> barry: weird error, I guess it's a side effect of your non-standard versioning scheme ;-)
[20:29] <barry> ribru: yeah ;)  i deleted the tag on the mp branch and hit rebuild
[20:29] <barry> seems to be making progress now
[20:33] <ribru> barry: ugh, how do I reboot into the bootloader? 'fastboot reboot-bootloader' just says 'waiting for device' (even though adb shell works), and no amount of power+volume up/down fiddling seems to want to do it for me today
[20:34] <barry> ribru: gosh, i'm not sure any more
[20:34] <ribru> between my vacation and broken ribs, it's been a couple weeks since I've updated one of these, wanted to start with a fresh flash ;-)
[20:35] <barry> yeah, that's a good idea.  does ubuntu-device-flash not work for you?
[20:37] <ribru> barry: with --wipe and --bootstrap it says 'waiting to be in bootloader'
[20:37] <ribru> ...
[20:38] <ribru> but when I specify --device it magically starts working
[20:38] <ribru> even with wipe and bootstrap. huh
[20:40] <barry> yay
[20:50] <barry> wow, the silo actually built on the first try
[20:55] <ribru> barry: uh, flashing didn't seem to work. seems like it just downloaded the image and stopped.
[20:56] <barry> ribru: i'm trying it now with my krillin.  will let you know how it goes
[20:56] <ribru> barry: seems to actually flash if I don't use wipe and bootstrap. bah
[20:56] <barry> weird
[21:00] <ribru> barry: oh wow, just reading test G, that sounds intense ;-)
[21:01] <barry> ribru: yeah ;)  took a bit of work to get the staging server up on stgraber's domain, since we don't have an official one
[21:02] <barry> ribru: i'm flashing right now w/o --wipe or --bootstrap
[21:02] <ribru> argh wtf! The flash said it was pushing the image to my device, and then it rebooted to recovery to flash etc, now system settings reports I'm running an image from september. bah
[21:03] <barry> ribru: are you on channel ubuntu-touch/ubuntu-rtm/14.09-proposed?
[21:03] <barry> (i suppose i should update that instruction
[21:03] <barry> )
[21:03] <ribru> barry: apparently not, but that's the channel I tried to flash
[21:18] <ogra_> \o/
[21:19] <ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/
[21:19] <ogra_> slangasek, so we have a vivid ...
[21:19] <pmcgowan> nice
[21:19] <ogra_> now i wonder if we can just bend the devel channel over to this and system-image will cope on devices
[21:20] <ogra_> (obviously once s-i has imported it)
[21:20] <slangasek> excellent
[21:20] <ogra_> well, curious if it will boot :)
[21:21] <slangasek> I guess you mean the devel-proposed channel, since you need a proper image promotion to get it onto devel :)
[21:21] <ogra_> do you knwo if the systemd daemons we ship will stay no-op's ?
[21:21] <ogra_> heh. indeed i meant -proposed
[21:21] <slangasek> I don't know anything about the delta, which systemd daemons do you mean?
[21:22] <ogra_> well, the whole breakage was caused by systemd-timedated and three other daemons we ship in minimal now adding their users to /etc/passwd
[21:22] <ogra_> i wonder if they just stay on the image and dont start or if they actually interfere
[21:23] <slangasek> ah; yes, those certainly aren't started via upstart
[21:23] <slangasek> systemd-timedated is a dbus service anyway
[21:23] <ogra_> ah
[21:24] <ogra_> well, then i assume it wll just work like utopic ...
[21:24] <ogra_> just with extra cruft on the fs
[21:24] <ogra_> (i doubt i will stay awake long enough to actually test one of these images tonight)
[21:25] <sil2100> o/
[21:25] <slangasek> ogra_: systemd-timedated itself isn't new, only the user is new
[21:28] <ogra_> ah
[21:29]  * ogra_ mailed about image status and will fall dead now 
[21:30]  * asac hugs ogra for vidid images
[21:30] <ogra_> :)
[21:31] <asac> sleep well!
[21:31] <ogra_> oh i will !
[21:31] <ogra_> i'm seriously behind on sleep :)
[21:31] <barry> slangasek: ping
[21:32] <asac> ogra_: go for it. wanted to ask if i shall try image, but lets just tru ...
[21:32] <slangasek> barry: hi
[21:32] <asac> ... together tomorrow morning!!
[21:32] <asac> cu
[21:32] <asac> try
[21:32] <ogra_> asac, well, in ~30-45min you should see something in the channel
[21:32] <barry> slangasek: hi.  interesting possible observation, re: the udm timeouts we see during ppa builds
[21:32] <asac> ogra_: yeah, dont worry. just go off!!!!!
[21:32] <ogra_> asac, if you feel brave ;)
[21:32]  * asac sends an electric outage to ogras home
[21:32] <ogra_> haha, yeah
[21:33] <barry> slangasek: we just build s-i 2.5.1 in a vivid ppa.  it finished quickly, and no timeouts on first try
[21:33] <barry> slangasek: then ribru source copied it to rtm silo, which is running more slowly, and i *suspect* (tho it hasn't happened yet) that it will timeout
[21:33] <slangasek> mm, so
[21:33] <slangasek> how does that help us? :)
[21:33] <barry> slangasek: what's the difference between vivid ppas and rtm ppas?... :)
[21:34] <barry> i386 vs amd64
[21:34] <barry> slangasek: it doesn't immediately, but i wonder if udm is crashing on i386
[21:34] <slangasek> ok
[21:34] <slangasek> should be reproducible in an i386 chroot?
[21:35] <barry> slangasek: it's just a thought right now.  let's see how this ppa build finished, and then i'll put this theory on the udm bug
[21:35] <barry> but yeah
[21:36] <barry> slangasek: i wonder how much testing udm gets on i386
[21:37] <slangasek> well, if you can get upgrades working in the emulator, it'll get more
[21:37] <barry> indeed
[21:38] <bdmurray> slangasek: do you think I should add bug 1386752 to the RTM wishlist?
[21:40] <slangasek> bdmurray: why is it a problem for the id to be world-readable?
[21:41] <slangasek> bdmurray: fwiw I think this is ok to defer to post-RTM
[21:41] <slangasek> even if it's not meant to be world-readable, there won't be many people reading it before OTA-1 :)
[21:41] <cjwatson> this system-image source copy you mention
[21:42] <bdmurray> slangasek: It was inconsistent as the dbus call to get the identifier required root.
[21:42] <cjwatson> that seems to be compounding the problem we identified and discussed with sil2100 at the sprint, of binaries with the same version but different contents between ubuntu and ubuntu-rtm, which is making it difficult for us to produce a new ubuntu-rtm/14.10 branch
[21:43] <cjwatson> this is going to need discussion with sil2100, I know, we probably aren't all on the same page, but would it be possible to drop 2.5.1-0ubuntu1 from the rtm PPA here and do a 2.5.1-0ubuntu1~rtm or whatever the convention is instead?
[21:43] <slangasek> oh indeed
[21:43] <slangasek> barry: ^^
[21:43] <cjwatson> I know that doesn't really help your specific problem at hand, just noticed it on the way past
[21:43] <cjwatson> (and I'm off to bed)
[21:44] <ribru> slangasek: in this case s-i doesn't follow the citrain versioning conventions so barry will have to manually mangle the version himself.
[21:44] <slangasek> that's fine; but he has to do it
[21:44] <slangasek> and not have two separate packages floating around with the same version number but different binary contents :)
[21:44] <cjwatson> the plan is to modify LP to prevent this kind of thing happening by accident, but we were only hatching this plan at the tail-end of the sprint and so haven't put it into effect yet
[21:44] <barry> sil2100 and i discussed this yesterday. i actually did have an rtm version number and was going to only go to rtm-14.09 but he talked me into going vivid then sync'ing with the same version number
[21:44] <ribru> barry: I guess best to manually upload to the PPA. we'll treat it like a source release (as opposed to a silo sync or an MP build)
[21:45] <cjwatson> barry: a binary sync would have been fine, but not a source sync
[21:45] <cjwatson> barry: maybe sil2100 meant the former?
[21:45] <cjwatson> which I think would have been reasonable here given that it's python
[21:45] <ribru> cjwatson: the funny thing is I specifically told citrain to do a binary sync here but for some reason the package rebuilt anyway. I blame the train itself for being stupid.
[21:45] <cjwatson> we have to be a bit careful about binary syncs from vivid to ubuntu-rtm/14.09, but they're certainly possible if the dependencies aren't too complex/whatever
[21:45] <barry> also, ribru thought he did do a binary sync, so neither of us are sure why it ended up doing a source sync
[21:45] <cjwatson> ribru: curious
[21:46] <cjwatson> well, I'm not investigating now, trying to do better about being off the clock in the evenings :)
[21:46] <cjwatson> night
[21:46] <ribru> barry: cjwatson: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-016-1-build/50/parameters/ here is the proof that I did a "binary copy" note that REBUILD_SOURCES_FOR_SYNC is unchecked.
[21:46] <ribru> cjwatson: goodnight
[21:46] <barry> cjwatson: gn
[21:47] <cjwatson> yeah, was intentionally not saying "oh hai ribru you broke it" because I hadn't investigated the situation at hand at all :)
[21:47] <brendand> plars, fginther - i filed this just now - https://bugs.launchpad.net/ubuntu-test-cases/+bug/1387391 it's probably a dupe i guess, but it's something i think we need to look at so i just wanted to make sure - didn't find anything similar in ubuntu-test-cases
[21:47] <barry> cjwatson, slangasek btw, if it will make others lives easier, i'll change my workflow or whatever for uploading new s-i versions
[21:47] <barry> but i'm really not sure what The Right Thing To Do Is, as i get somewhat conflicting recommendations
[21:47] <slangasek> ribru, barry: well, for the moment the takeaway is "it was a source sync, that shouldn't have happened, dump the silo and try again"
[21:48] <barry> slangasek: wfm.  ribru can you do that?
[21:48] <slangasek> barry: it can be a binary sync if we know that it's safe, but we're generally telling people not to do that at all because it takes a core-dev to know that it's safe
[21:48] <slangasek> and if binary syncing isn't working right, that's something else
[21:48] <barry> yeah
[21:49] <slangasek> barry: so you can do a sourceful upload with a ~rtm version number, or you and ribru can try to work out what went wrong with the binary sync... but the latter would need a different silo now, since you can't reuse that version number in that particular ppa :)
[21:49] <barry> slangasek: for now, si in vivid will be the same as in rtm, but once rtm happens, i'm hoping to start landing new features, so they will diverge (and i have a new upstream branch just for rtm)
[21:49] <slangasek> path of least resistance: source upload with manual mangling of version number
[21:50] <barry> or maybe i was talking to ogra_, but anyway the same applies
[21:51] <barry> slangasek: so, you're saying 2.5.1-0ubuntu1~rtm1 sourceful upload to the existing ppa?  (that'll sort lower than the current in flight package though)
[21:51] <slangasek> yes
[21:51] <barry> ribru: do you want to retry a binary copy for giggles?  and if it doesn't work again, then i can prep a source package
[21:51] <barry> slangasek: wfm
[21:51] <slangasek> can't retry a binary copy without allocating a separate silo
[21:51] <barry> oh right
[21:51] <fginther> brendand, Thanks for the bug description and example, I've added it to the list of things to work on
[21:52] <slangasek> version numbers are launchpad's diamonds
[21:52] <slangasek> (they're forever)
[21:52] <barry> slangasek: that was actually my first suggested version number for rtm.  i wasn't even going to upload to vivid ;)
[21:52] <barry> slangasek: yeah, i've been bitten by that too many times before
[21:52] <barry> ribru: let me know your preference for proceeding
[21:53] <barry> slangasek: but i guess either way, this might not make it into tomorrow's image, unless i can get ribru and maybe one other person (hint, hint) to test the new version
[21:57] <ribru> barry: I guess easiest if you can bump the version number and ~rtm it for the same silo. I'm not really inclined to try the binary sync again since it's discouraged anyway (I want to just rip all that code out, I don't want to debug it)
[21:57] <ribru> barry: or if you really need that version number I guess we have to toss the silo and start a fresh one either way
[21:57] <ribru> barry: fwiw, test G passed perfectly for me.
[21:57] <barry> ribru: the version number is really unimportant
[21:58] <barry> ribru: awesome, thanks!
[21:58] <barry> i think i'll just prep a new ~rtm version for the silo and do a sourceful upload
[21:58] <ribru> barry: you're welcome. yeah I guess upload version as 0ubuntu2~rtm then
[22:00] <barry> ribru: that'll sort higher than the vivid version.  not sure if that's a problem or not, but frankly i don't even care if 2.5.1 is published to vivid or not
[22:00] <sergiusens> slangasek: barry if you ask nicely and own the ppa, webops can make versions not be the tough diamonds we thought they are... (not saying we should do that here though)
[22:01] <ribru> barry: yeah but if you just do 0ubuntu1~rtm it won't be accepted as a newer package, right? so you have to do 0ubuntu2 just to get the package even accepted in the PPA.
[22:01] <barry> sergiusens: for my own ppas in the past i've just blown the whole ppa away.  it *does* make for more inconvenient testing, but it's not that big of a deal
[22:02] <barry> ribru: i think i can delete the -0ubuntu1 version
[22:02] <ribru> barry: also are you in the team to be able to do uploads to silo PPAs? if not ask slangasek to add you
[22:02] <barry> worth a try and if it fails i'll bump it
[22:02] <barry> ribru: hmm, i may not be
[22:02] <slangasek> ribru, barry: remove the existing package from the ppa first, upload the new version with a version number that sorts earlier
[22:03] <barry> slangasek: yep.  of course: "Package deletion can take some time before the packages are actually removed. See more about deleting a package."
[22:03] <ribru> ok package is deleted
[22:03] <slangasek> barry: you are a member (~ci-train-ppa-service)
[22:03] <ribru> barry: my experience lately is that deletion is actually pretty quick despite the warning. less than a couple minutes
[22:04] <slangasek> I assume wgrant has optimized launchpad for deletion in the face of librarian pressure ;-)
[22:04] <barry> slangasek, ribru: cool.  let me build the rtm srcpkg and try an upload.  will follow up soon
[22:06] <ribru> ok, good time for me to make a smoothie ;-)
[22:06] <barry> hang on a sec.  i won't be able to upload an UNRELEASED right?  should that be ubuntu-rtm/14.09 ?
[22:07] <barry> slangasek, ribru ^^
[22:07] <slangasek> barry: '14.09', then upload to the right ppa target
[22:07] <barry> slangasek: ack
[22:08] <barry> lalalala: bad-distribution-in-changes-file 14.09 :)
[22:08] <davmor2> cwayne: so everything is looking okay on the tarball
[22:10] <barry> slangasek: Unable to find distroseries: 14.09
[22:10] <cwayne> davmor2: \o/
[22:10] <barry> rejected
[22:10] <cwayne> davmor2: so do I push it? or do I need to wait for sil?
[22:11] <davmor2> ribru: are you spin up any images right now?
[22:11] <slangasek> barry: rejected from where?
[22:11] <barry> slangasek: soyuz
[22:11] <slangasek> barry: 14.09 is definitely the right syntax; what was your upload target?
[22:11] <barry> slangasek: dput ppa:ci-train-ppa-service/landing-016 system-image_2.5.1-0ubuntu1~rtm1_source.changes
[22:12] <slangasek> barry: yeah, that's the wrong target :)
[22:12] <slangasek> barry: you need 'ubuntu-rtm/' in the middle of that ppa name
[22:12] <slangasek> otherwise it's uploading to the ubuntu ppa of the same name
[22:12] <barry> oh, i guess the ppa page lies then ;)
[22:12] <barry> slangasek: dput ppa:ci-train-ppa-service/ubuntu-rtm/landing-016 system-image_2.5.1-0ubuntu1~rtm1_source.changes  ...?
[22:13] <slangasek> yes
[22:14] <barry> cool.  i blame launchpad :)
[22:16] <barry> oh ffs.  File system-image_2.5.1.orig.tar.gz already exists in Landing PPA 016 (RTM), but uploaded version has different contents.
[22:17] <barry> i guess i should just dump the silo and try again
[22:18] <barry> brb
[22:18] <ribru> heh
[22:18] <ribru> davmor2: I was just gonna let cron do it, do you need one sooner?
[22:19] <davmor2> ribru, cwayne: ^ so no images till 3:00am  so hit the button I guess
[22:20] <ribru> barry: oops ok I'll flush and reassign
[22:20] <cwayne> davmor2: done
[22:20] <cwayne> thanks for testing man
[22:21] <ribru> barry: ok when you get back, pls upload to rtm 4
[22:24] <barry> ribru: awesome, thanks.  will upload then continue prepping dinner
[22:24] <ribru> barry: you're welcome!
[23:57] <ribru> barry: hm, is it supposed to take this long to build? looks like it's still running tests