[01:32] <robru> hurr durr i'm a shurr
[04:48] <Mirv> morning again
[04:52] <robru> Mirv: oh hello! I *just* merged some experimental stuff into production, so watch out for weird failures. I'll stay up for a bit to revert it if anything goes wrong, just ping me
[04:53] <robru> Mirv: builds were tested in preprod but publishing and cleaning is totally untested and may explode
[04:54] <robru> indeed I've broken cleaning. excellent!
[04:55] <robru> tedg: false alarm, I'm breaking stuff
[04:55] <Mirv> robru: ok :)
[05:01] <robru> heh, check-publication-migration is working ;-)
[05:01] <Mirv> robru: publishing seems to be working, too
[05:01] <robru> Mirv: oh sweet
[05:02] <robru> Mirv: ok I'm gonna try to fix cleaning instead of reverting everything...
[05:02] <robru> Mirv: but if I can't fix it in an hour then I'll revert and try again tomorrow
[05:02] <Mirv> sounds good
[05:03] <Mirv> eh, that's not true though ^
[05:04] <Mirv> it's not yet anywhere, the keyboard
[05:04] <Mirv> the rsync line looks correct so I'd expect it to appear soon though
[05:06] <Mirv> yes, now it appeared
[05:06] <Mirv> robru: but the check-publication-migration failed there ^. it's still pending https://launchpad.net/ubuntu-rtm/+source/ubuntu-keyboard/0.99.trunk.phablet2+14.10.20141104~rtm-0ubuntu1
[05:07] <robru> shit
[05:09] <robru> damnit
[05:09] <robru> I didn't really touch check-publication-migration though.
[05:11] <robru> oh, I did tinker with a function that check_publication_migration calls. damn. ok I'm loading with debugging statements!
[05:19] <robru> hm
[05:20] <robru> ok well i've fixed merge & clean
[05:20] <robru> Mirv: ok I think I fixed check_publication_migration as well, but silo rtm 6 now really is published so it's tough to say. let's keep an eye on that...
[05:22] <robru> hmmm
[05:24] <robru> wut
[05:25] <robru> cihelp did citrain jenkins just get rebooted or something? strange anonymous job termination plus I got logged out just seconds after submitting a job
[05:25] <robru> oh well that's good at least ;-)
[05:26] <robru> Mirv: ok check_publication_migration is fixed ^
[05:26] <robru> I like how check_publication_migration's default thing is to claim all packages are migrated in the event of an error. "oh something broke? all packages are migrated!!"
[05:27] <robru> ugh
[05:27] <Mirv> robru: ok, great!
[05:28] <Mirv> nice defaults
[05:28] <Mirv> a bit like these "Error! Success!" of the past
[05:29] <robru> Mirv: yeah it's the same old architectural deficiency shining through various cracks
[05:30] <robru> tedg: ok sorry for the highlight spamming there, your silo was successfully merged & cleaned despite that strange signal 15 message there. I confirmed your trunk branch has the right stuff in it ;-)
[05:54] <robru> sweet this is looking really good.
[05:54] <robru> Mirv: ok I'm gonna land this
[05:56] <Mirv> robru: sure, all seems good now so far
[06:44] <robru> Mirv: ok I'll be around for a little bit, but if anything explodes, just run the deploy job with DEPLOY_PROD_REVISION set to -3 to get it back to a known working state. -2 will put it into a state where syncs don't work
[07:31] <Mirv> robru: everything seems still fine, although I'm only playing with the qt silo atm
[07:32] <Mirv> probably there will be no reason to deploy the older version
[07:33] <robru> Mirv: yeah dunno, my last branch also seemed fine but then some corner car came up that was broken. The train is a fickle mistress
[07:34] <robru> *case
[07:36] <Mirv> that she is
[07:51] <popey> Mirv: when you get a moment could you please upload  http://s-jenkins.ubuntu-ci:8080/job/calendar-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.calendar_0.4.534_all.click - I think balloons may have tried last night, but I don't see it in the store.
[07:56] <tvoss> good morning
[09:01] <Mirv> popey: calendar uploaded
[09:05] <popey> thanks Mirv
[09:06] <sil2100> Damn, I feel like a zombie
[09:09] <ogra_> hmm, unity8 is still freaking out in topbefore/after everywhere
[09:10]  * Mirv has loads of crashes in /var/crash from playing around for the morning
[09:10] <Mirv> or had, rather, just reflashing
[09:10] <ogra_> we have only 3 in smoke-testing
[09:12] <ogra_> my volume overlay comes up at the very top of the screen again (covering the panel)
[09:12] <ogra_> this happens every other image to me ... totally random
[09:14] <popey> ogra_: on krillin? not seen that here
[09:16] <ogra_> popey, yeah, on krillin, i showed it to john-mcaleely at the sprint ... it was gone for a while but now i have it randomly back after every other OTA
[09:17] <ogra_> havent seen it for at least three images though
[09:23] <ogra_> hah, fun
[09:23] <ogra_> now it is gone
[09:24] <ogra_> (i disconnected my BT speaker)
[09:25] <sil2100> We still didn't get the CPU-load-fixes in, right?
[09:26] <tvoss> sil2100, nope, one part of them is on the way in rtm 9
[09:27] <sil2100> brendand, davmor2: for QA, how many people do we have now in the EU timezone? Just 2 people?
[09:27] <sil2100> tvoss: thanks :)
[09:27]  * Mirv bootstrap flashed latest vivid, stares at spinning Ubuntu logo
[09:28] <brendand> sil2100, 4
[09:28]  * Mirv waits for the step 1 from the new QA plan to be implemented (only release images to -proposed that boot & run unity8)
[09:28] <ev> robru: it ran out of space
[09:28] <brendand> Mirv, ?
[09:28] <ev> See #is-outage
[09:29] <ev> And https://bugs.launchpad.net/ci-train/+bug/1389968
[09:29] <brendand> Mirv, oh vivid. pfff
[09:29] <Mirv> brendand: it was discussed during the sprint that there should be a gatekeeper that non-booting images wouldn't be released. I assume that would make sense (when it's available) on vivid too.
[09:29] <Mirv> brendand: ;)
[09:29] <brendand> Mirv, it would indeed
[09:30] <Mirv> brendand: how much before you wanted this "rtm-022 ping"? there's something to test there now, I just find it a bit hard to test with the unity8 crashes and scope unreliability in general.
[09:31] <brendand> Mirv, whenever you're ready to test it
[09:31] <sil2100> ev: hey! I'll comment on that in a minute
[09:31] <ev> Thanks sil2100
[09:33] <Mirv> brendand: I'm ready to test it in the sense that lorn could use feedback on the bug whether there's an improvement or not. I did get music scope image downloads over 3G, but I also had problems that I don't know if they are related to the qtbase or the unity8 problems.
[09:34] <john-mcaleely> ogra_, did we decide it was a difference with OTA vs clean flashes?
[09:35] <ogra_> john-mcaleely, iirc we firstly did but then discovered someone else who had OTAed and didnt see it
[09:35] <ogra_> and set the bug to incomplete
[09:35] <sil2100> davmor2: ping! Meetong
[09:38] <john-mcaleely> cjwatson, I need to ask for updates to system-image.u.c, so it takes different tarballs for rtm & vivid
[09:38] <john-mcaleely> cjwatson, I've tried to find that file you sent me at the sprint in my logs
[09:38] <john-mcaleely> cjwatson, but have failed to find it :-(
[09:49] <brendand> Saviq, i was testing silo 4 yesterday
[09:49] <Saviq> brendand, yes, I know you did not like the indicator syncing
[09:50] <Saviq> brendand, we're looking into it now, all else fails I'll pull the relevant changes from silo 4
[09:54] <brendand> Saviq, thanks. i also felt like it was crashing more often, but they were the same crashes as usual, not new ones
[09:54] <Saviq> brendand, I think the qtubuntu-media fix only landed later than when you were testing
[09:56] <brendand> Saviq, well i don't think i had landed yet
[09:56] <Saviq> or even..
[09:57] <alan_g> cihelp in the transition to vivid mir-ci seems to have lost some builds: specifically mir-mediumtests-utopic-touch has no vivid equivalent. Before: https://jenkins.qa.ubuntu.com/job/mir-ci/2008/console, after: https://jenkins.qa.ubuntu.com/job/mir-ci/2022/console. What's going on?
[09:58] <popey> stupid webcam
[09:58]  * Mirv flashes vivid 9
[09:59] <davmor2> popey: you should have a warning "May contain flashing images" as your lower 1/3 ;)
[09:59] <popey> heh
[09:59] <popey> yes!
[10:04] <imgbot> [10:06] <cjwatson> john-mcaleely: http://paste.ubuntu.com/8849582/
[10:06] <cjwatson> (that's nusakan:/srv/system-image.ubuntu.com/etc/config)
[10:07] <john-mcaleely> cjwatson, thanks
[10:17] <vila> alan_g: looks like the mir-mediumtests-vivid-touch doesn't exist, will ping fginther
[10:18] <alan_g> vila: thanks
[10:24] <ev> robru, sil2100, Ursinha-afk: public service announcement: if you move files around in lp:cupstream2distro's citrain directly, do be sure to update the jenkins charm and/or lp:ci-train
[10:24] <ev> as this has broken the production deployment
[10:27] <pstolowski> brendand, hello, fyi the topblocker bug from #50 has been tested by us and is ready for qa sign off
[10:27] <john-mcaleely> cjwatson, here's how I think it should look http://paste.ubuntu.com/8849746/
[10:28] <john-mcaleely> cjwatson, there are now 3 tarballs available for system-image.u.c: utopic, ubuntu-rtm-14.09, master (vivid)
[10:28] <john-mcaleely> cjwatson, right now, all three are identical, and contain what is in the single lookup now
[10:28] <john-mcaleely> cjwatson, I believe I need to publish separate updates today for vivid & ubuntu-rtm
[10:28] <john-mcaleely> cjwatson, does the update make sense to you?
[10:35] <ev> robru, sil2100, Ursinha-afk: this is also why while having a remote branch that production pulls from gives you flexibility, it's a fundamentally broken approach as it's all too easy to get out of sync when things aren't carefully coordinated. Tar'ing up the code and making that part of the deployment fixes this.
[10:36] <ev> obviously not blaming you guys for any of this - it's a creation you've inherited - but I want to make sure we take the right lessons from it
[10:39] <ev> fix cowboy'ed onto production. jacekn is working on doing an upgrade-charm to pick up the real fix in the jenkins charm
[10:41] <cjwatson> john-mcaleely: I'm at a conference right now.  Could you please mail me a diff (*not* the whole new file)?
[10:41] <john-mcaleely> cjwatson, sure
[10:43] <popey> ogra_: vivid 10 on mako known broken?
[10:43] <ogra_> popey, ask Mirv and davmor2 :P
[10:43] <ogra_> they showed it in the meeting
[10:44] <davmor2> popey: yeap ogra_ is meant to be fixing it though
[10:44] <ogra_> popey, i triggered 11 (see above) to make sure we are not missing anything from the android update, 11 might or might not work
[10:44] <davmor2> ogra_: fix it faster
[10:45] <ogra_> :P
[10:45] <popey> kk
[10:45] <davmor2> ogra_: no faster not more sarcastically :P
[10:45] <ogra_> haha
[10:45] <sil2100> ev: ACK
[11:11] <ogra_> heh
[11:11] <ogra_> the bootchart for vivid 10 looks interesting
[11:11] <ogra_> http://people.canonical.com/~ogra/ubuntu-phablet-vivid-10.png
[11:11] <ogra_> looks like media-hub is in a crashing loop .... tearing down unity8 with it
[11:12] <Mirv> popey: I went back to 9 to test qt
[11:12] <popey> ta
[11:12] <popey> will revert
[11:18] <tvoss> ogra_, do you have the new device tarball?
[11:18] <ogra_> tvoss, where ? krillin ? yes, since yesterday
[11:19] <Ursinha> ev: understood, but not sure if files were moved around, robru was working on changing relative/absolute paths in the code, I wonder if that broke things?
[11:22] <tvoss> ogra_, the one that is required for https://launchpad.net/ubuntu/+source/media-hub/2.0.0+15.04.20141105.1-0ubuntu1
[11:22] <tvoss> ogra_, also: got crash file for media-hub?
[11:23] <ogra_> tvoss, note the above is vivid on mako ... that should have the changes in the new android package
[11:23] <ogra_> and yes, i have crashes
[11:23] <Ursinha> ev: if you are talking about bug 1389968, then the problem seems to be that the charms weren't updated to reflect how setup_citrain gets parameters (not that files were moved around), but your point still stands -- thanks for pointing that out
[11:23] <tvoss> ogra_, did you upload them, yet? oops idea would be helfpul
[11:23] <tvoss> s/idea/id
[11:23] <ogra_> tvoss, https://errors.ubuntu.com/oops/5bdbf2a4-65a4-11e4-80e5-fa163e525ba7
[11:25] <tvoss> ogra_, ouch, somehwere in android
[11:26] <ogra_> yes
[11:27] <ogra_> ricmm, ^^^
[11:27] <ogra_> (oh, i think he is flying today)
[11:27] <ogra_> we might have to wait for rsalveti
[11:29] <imgbot> [11:29] <imgbot> [11:29] <ogra_> tvoss, ^^ looks like hybris simply had not migrated for image 10
[11:29] <ogra_> 11 should boot
[11:31] <ogra_> Mirv, popey ^^^^
[11:31] <popey> dammit, 9 just finished ☻
[11:32] <popey> huh, no volume overlay when changing up/down
[11:32] <davmor2> popey: but now you can ota to 11
[11:32] <popey> ya
[11:33] <Mirv> ogra_: thanks.
[11:36]  * popey updates
[11:42] <popey> 111 is good
[11:42] <popey> er, 11
[11:42] <popey> got a bit excited there
[11:45] <ogra_> haha
[11:45] <john-mcaleely> +100
[11:50] <brendand> popey, nope that never landed in vivid
[11:50] <brendand> popey, as i found out yesterday
[11:53] <ev> Ursinha: already fixed :)
[11:53] <ev> Ursinha: what broke it was renaming files, yeah
[11:53] <ev> but what's more fundamentally broken is that this production environment references a remote bzr branch that can change underneath it
[11:54] <ev> it really should've been that the code got bundled with the deployment
[11:54] <ev> and requests were made to webops for further updates
[11:54] <Ursinha> ev: got it
[12:13] <davmor2> brendand, sil2100, ogra_: Mako vivid 11 has buttons not swipe http://people.canonical.com/~davmor2/buttons.png
[12:14] <brendand> sil2100, isn't stuff meant to land in vivid first?
[12:14] <brendand> Saviq, ^
[12:14] <Saviq> brendand, davmor2, it's the telephony service that needs adapting
[12:15] <Saviq> and yeah, they did not land it in vivid yet
[12:15] <Saviq> we did our part
[12:15] <davmor2> Saviq, brendand: it hasn't landed in RTM either this is buttons too
[12:16] <brendand> davmor2, well no - i'm testing that now
[12:16] <sil2100> davmor2: yeah, it's silo 4 that has that actually
[12:16] <ricmm> ogra_: so no breakage? :)
[12:16] <ricmm> slow migration bots ;)
[12:16] <ogra_> ricmm, yeah, just out-of-sync
[12:17] <Saviq> davmor2, it's in silo
[12:18] <Saviq> so yeah, the telephony bit landed in rtm, not in vivid, unity8 bits the other way round
[12:19]  * davmor2 blames ogra_ obviously for vivid 10 being broken ;)
[12:19] <ogra_> yeah, my hybris fiddling broke everything
[12:20] <brendand> Saviq, so what about silo 4 then?
[12:20] <Saviq> brendand, dednick pung you somewhere, will come here shortly
[12:20] <brendand> Saviq, i didn't get anything
[12:21] <dednick> brendand: hi
[12:21] <brendand> dednick, hello
[12:21] <Saviq> fight!
[12:21] <Saviq> ;)
[12:21] <Saviq> /food
[12:21] <ogra_> food fight ?
[12:21] <Saviq> ogra_, you kinky you
[12:21] <ogra_> :D
[12:21] <dednick> brendand: pinged you on touch awhile ago. nevermind :)
[12:21] <dednick> brendand: i've tried out silo 16 but can't get the sound out of sync? what are your steps?
[12:22] <brendand> dednick, sound?
[12:22] <dednick> brendand: kgunn said the flight mode and sound settings in system settings were stll getting out of sync with indicators
[12:23] <brendand> dednick, the problem i have is that flight mode toggles back and forth when you switch it on
[12:23] <Saviq> brendand, ah, that's an indicator-network issue
[12:23] <dednick> brendand: i think it's because of the backend
[12:24] <brendand> Saviq, is there a fix pending for it?
[12:24] <Saviq> brendand, we tell it "go to flight mode", a second or so later we check the value, but it's still "no flight mode", then another second after that it comes back with "yeah, I turned flight mode on"
[12:25] <brendand> Saviq, it looks crappy though
[12:25] <Saviq> brendand, it does, I agree, and no I don't think there's a fix, but then that's required for the switches to remain in sync
[12:26] <Saviq> Wellark, so, indicator-network taking a long time (like multiple seconds) to acknowledge flight mode setting, what can be done?
[12:26] <kgunn> Saviq: dednick ....but with silo 16, i can toggle flight mode quickly and get it to "stick" seemingly
[12:27] <Saviq> kgunn, I think it depends on your setup, basically the network indicator is waiting for urfkill (?) to say "yeah, you're in flight mode"
[12:27] <Saviq> and it's switching hardware about that might take some time I think
[12:27] <dednick> kgunn: the indicators and settings use a differnt method to working the flight mode. i think something is getting screwy somewhere in the backend
[12:27] <john-mcaleely> so, does 'rtm silo 9' have a pair for (I'm guessing) vivid?
[12:27] <john-mcaleely> and how would I find out?
[12:28] <john-mcaleely> rsalveti, ^ ?
[12:28] <kgunn> john-mcaleely: grep the sheet for landing-009
[12:28] <john-mcaleely> oh, are the numbers the same on both distros?
[12:29] <Saviq> no
[12:29] <kgunn> dednick: also, for sound, if i select silent mode...the little speaker+sound wave icons stays...
[12:29] <john-mcaleely> kgunn, no luck :-(
[12:30] <Saviq> tvoss, is there a vivid silo for what rtm 9 is?
[12:30] <Saviq> john-mcaleely, but also, that silo looks like a sync, meaning that is already *in* vivid
[12:30] <brendand> dednick, i can get the sound toggles to be out of sync here too
[12:30] <john-mcaleely> aha. interesting.
[12:30] <john-mcaleely> Saviq, thanks
[12:30] <Saviq> john-mcaleely, if you look at http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=009
[12:30] <brendand> dednick, without the silo
[12:30] <Saviq> john-mcaleely, it says "spreadsheet row 62"
[12:30] <john-mcaleely> it does indeed
[12:30] <dednick> brendand: yeah.. that's what the silo fixes
[12:31] <Saviq> john-mcaleely, you can then go to https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc&pli=1#gid=0
[12:31] <brendand> dednick, ok
[12:31] <dednick> kgunn: do you mean the icon?
[12:31] <Saviq> john-mcaleely, and see how the silo is set up, it says "sync:ubuntu,vivid" there, meaning it simply picked all the packages up from vivid
[12:31] <kgunn> dednick: yep gimme a sec...will video
[12:32] <Saviq> /reallyfood
[12:32] <john-mcaleely> Saviq, aha, thanks. makes some sense.
[12:32] <john-mcaleely> unping rsalveti  :-)
[12:33] <dednick> kgunn: i dont think silent mode is connceted to an icon. it doesnt change if i change in indicators either.
[12:34] <dednick> unless you mean the really annoying icon which pops up in the system settings page.
[12:35] <kgunn> dednick: then how the heck is a user supposed to glance at phone and see he's on silent mode ? :P
[12:35] <kgunn> sholdn't the icon change to a speaker+'X' instead of sound waves
[12:35] <dednick> kgunn: hehe. yeah, well it should. bug in indicator-sound i guess
[12:37] <brendand> kgunn, so i really don't want to land this unless i hear that either a fix is imminent (like in a silo almost ready for sign-off), or that this is the desired behaviour for RTM
[12:44] <kgunn> brendand: it might be that we're not the ones to fix it
[12:44] <dednick> kgunn: hm. so apparently "mute" and "silent mode" are not the same things...
[12:44] <Saviq> brendand, kgunn, dednick, we could pull the sync branch from the silo and come up with a proper fix afterwards, but that will mean breakage, as opposed to visual awkwardness
[12:45] <Saviq> dednick, yeah, but we don't do <|× for either ;)
[12:45] <Saviq> so def. a bug in indicator-sound
[12:45] <dednick> Saviq: pull the u8 sync branch you mean?
[12:45] <Saviq> dednick, yes
[12:45] <kgunn> Saviq: breakage how ?
[12:45] <dednick> Saviq: no breakage. will be same as before
[12:46] <Saviq> kgunn, same breakage we have now I mean
[12:46] <kgunn> :)
[12:46] <Saviq> so we're getting out of sync, with dednick's branch we're in sync, but visually awkward
[12:46] <dednick> right. so the indicator will just be wrong.
[12:46] <kgunn> dednick: but it's eventually right
[12:46] <dednick> ya
[12:46] <kgunn> i mean it does correct eventually
[12:46] <Saviq> kgunn, with dednick's branch, not without it
[12:46] <kgunn> (but awkward indeed)
[12:47] <kgunn> Saviq: got it....
[12:47] <Saviq> so yeah, IMO it's better to be correct but awkward vs. wrong
[12:47] <Saviq> brendand, ↑?
[12:47] <kgunn> man Saviq said it better....that's what i tried to say to brendand y'day
[12:47] <dednick> worth noting that i dont think the settings corrects itself :/
[12:49] <Saviq> dednick, not before your branch in silo 16 that is?
[12:49] <dednick> Saviq: silo16 doesnt add autocorrecting.
[12:49] <dednick> Saviq: the USS branch i mean
[12:50] <dednick> with the timer thingy
[12:50] <Saviq> dednick, should it?
[12:50] <dednick> Saviq: well, for the same reason we have done in u8.
[12:51] <kgunn> dednick: so i'm on silo 16....and system-settings seems to follow
[12:51] <kgunn> even eventually
[12:53] <kgunn> hmmm dednick this seems way better than last night (flight mode toggling)
[12:54] <kgunn> ah...cause i installed ofono sim stuff
[12:54] <kgunn> faster than a real radio
[12:55] <dednick> kgunn: https://bugs.launchpad.net/indicator-sound/+bug/1390067
[12:55] <dednick> kgunn: yeah, that would do it. probably works every time as well...
[13:01] <Mirv> boiko: bfiller: https://code.launchpad.net/~boiko/history-service/save_timestamps_utc/+merge/240337 not approved, ready for publishing otherwise
[13:01] <Saviq> brendand, so, just to restate: with silo 4 we're correct, but awkward, without it we're wrong (in what the indicator shows), so if you ask me it's still better
[13:01] <boiko> Mirv: oups, I think I will wait for bfiller to approve it
[13:01] <Saviq> and that's the only two choices we have right now
[13:07]  * sil2100 lunch o/
[13:09] <Saviq> brendand_, looks like your connection's flaky today
[13:09] <Saviq> brendand_, brendand, so, just to restate: with silo 4 we're correct, but awkward, without it we're wrong (in what the indicator shows), so if you ask me it's still better
[13:09] <Saviq> brendand_, and that's the only two choices we have right now
[13:10] <Mirv> why do I have ~80 systemd-logind process on my mako... vivid I guess
[13:10] <mdeslaur> ogra_, bzoltan, cjwatson: https://codereview.qt-project.org/#/c/99054/
[13:11] <mdeslaur> ogra_, bzoltan, cjwatson: please also fix this issue: https://bugreports.qt-project.org/browse/QTCREATORBUG-13339
[13:12] <Mirv> and why does the mirscreencast stall all the time
[13:12] <tvoss> Saviq, yup, the changes landed to vivid last night
[13:12]  * Mirv wants an oracle to answer all his questions
[13:15] <Mirv> cjwatson: do things break if I CI Train would try to sync 5.3.2-2 of qtimageformats _with binaries_ from landing PPA, while 5.3.2-2 is in proposed already without binaries (because build dependencies not matched)? with 5.3.0, I removed the synced packages from PPA right before publishing and let them build in the archive, which was a bit slow.
[13:20] <tvoss> rsalveti, around?
[13:20] <Mirv> core-dev question also here, if anyone up for acking a single liner for vivid: https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-ui-toolkit_1.1.1311+15.04.20141102-0ubuntu1.diff
[13:22] <brendand_> Saviq, it needs to be passed by product management/design then. if that's the final behaviour they prefer to have then so be it
[13:23] <sil2100> Mirv: ogra_ can you take a look at Mirv's question reg. packaging ^ ?
[13:24] <Saviq> kgunn, ↑
[13:26] <ralsina> trainguards pretty please a silo for row #70?
[13:26] <rsalveti> tvoss: yes
[13:26] <ralsina> oops, trainguards meant row #56
[13:27] <Mirv> ralsina: rtm-006
[13:27] <ralsina> thx Mirv!
[13:35] <Chipaca> can somebody translate https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-006-1-build/86/console to human? what do we need to do?
[13:36] <Mirv> Chipaca: your rtm bzr branch https://code.launchpad.net/~ubuntu-push-hackers/ubuntu-push-qml/rtm does not match what's actually in rtm at the moment https://launchpad.net/ubuntu-rtm/+source/ubuntu-push-qml
[13:36] <brendand_> kgunn, did you say yesterday that when you used dednick's silo that the flight mode toggle worked normally?
[13:37] <Chipaca> Mirv: is this checking versions, or actual branches?
[13:37] <ralsina> Mirv: That's because this is my first time landing this to rtm after vivid opened
[13:37] <Mirv> Chipaca: versions
[13:37] <Chipaca> ralsina: ^
[13:37] <Chipaca> Mirv: thanks
[13:37] <ralsina> so I need to dch and change the version?
[13:38] <Mirv> ralsina: preferably you should dget the rtm archive version and make sure the rtm branch matches that content exactly, and parse the meaningfulness of any delta. most probably it's just the last changelog entry not being rtm mangled in the bzr.
[13:38] <ralsina> ack, thx Mirv!
[13:38] <kgunn> brendand_: define normal... :) i was trying to say what saviq said
[13:39] <kgunn> that is, it is correct behavior however "visually awkward" b/c the ui is checking to be in sync with what the backend acgtually does
[13:39] <kgunn> whereas...before these silos, the ui would reflect incorrectly what the state of the backend is
[13:40] <kgunn> brendand_: think of it as bad visual design with silos, we're using toggle & icons to be both for theuser to input desire & reflect the current state
[13:40]  * Mirv is sad not being able to publish UITK
[13:40] <brendand_> kgunn, so one problem is that if you toggle the switch on > off > on
[13:41] <brendand_> kgunn, then it ends up in off
[13:41] <brendand_> kgunn, the ui shouldn't do what the backend says, the backend should do what the ui says
[13:42] <brendand_> kgunn, anyway i'm not going to make the call on this, somebody from product management/design should
[13:42] <kgunn> brendand_: i don't think you understand...the ui has to reflect what the backend state is, e.g. you turn off flight mode, but it takes 10 seconds to get out of flight mode
[13:43] <kgunn> and what it failed to get out of flight mode completely
[13:43] <kgunn> how would the use know that ?
[13:43] <kgunn> can't just redraw the ui and hope for the best...b/c that is exactly the original bug
[13:43] <kgunn> so if i follow your argument, you should mark the top blocker invalid
[13:45] <sil2100> Can't we have an intermediate state?
[13:45] <brendand_> kgunn, so the TOPBLOCKER refers to switches getting out of sync in general
[13:45] <sil2100> Like, after switching the flight mode, disabling the button until we get confirmation from the backend or wait some timeout (in case that fails)?
[13:46]  * olli waives
[13:46] <brendand_> kgunn, not specifically flight mode
[13:46] <brendand_> olli, hey
[13:47] <olli> how can I help
[13:47] <brendand_> olli, there's an attempted fix for a TOPBLOCKER which makes the flight mode switch behaviour very obviously broken looking from a user point of view
[13:47] <sil2100> olli: hello! btw. can I send out a draft e-mail for proof-reading in a moment? :)
[13:48] <brendand_> olli, kgunn and Saviq's argument is that it's necessary to ensure correct behaviour
[13:48] <brendand_> note i said broken *looking*
[13:48] <olli> brendand_,  iwas reading the backscroll
[13:49] <kgunn> sil2100: yes, we need an intermediate state really...but with 1 day to go that's rough
[13:49] <sil2100> kgunn: true...
[13:49] <kgunn> not to mention it's more than ui...it'd be a whole new meta state to perpetuate throughout
[13:49] <Saviq> olli, basically, what happens: user taps flight mode, the indicator starts doing things; the UI then asks "is flight mode on?", and gets "no", so it switches back; then backend says "dude, flight mode is on now", and it settles on On
[13:49] <olli> brendand_, I haven't seen it myself... but doesn't it improve the state where the button state was pointless as it was out of sync?
[13:49] <Saviq> olli, yes, it does, it's actually correct, but visually awkward
[13:50]  * kgunn takes video to avoid explaining like 10 times today :)
[13:50] <rsalveti> john-mcaleely: yeah, the changes for vivid already landed :-)
[13:51] <rsalveti> john-mcaleely: so feel free to just push the vivid tarball
[13:51] <rsalveti> ogra_: thanks for building 11, 10 was indeed out of sync
[13:51] <brendand_> olli, out of sync with what? the system state, or out of sync between the indicator and system-settings?
[13:51] <rsalveti> it got the new android tarball, but not latest hybris
[13:51] <olli> brendand_, the situation on #140
[13:52] <olli> where iirc the indicator is out of sync with pretty much everything easily
[13:53] <brendand_> olli, depending on exactly what issue you're taking about, i believe there were some ofono fixes to eliminate the chance of that happening
[13:53] <kgunn> ...i'm totally pushing for an actual indicator alert with "dude, flight mode is on now"
[13:53] <brendand_> olli, if you mean when it gets permenantly out of sync, rather than temporarily
[13:54] <brendand_> kgunn, if you look at the way android does it then it almost instantly turns off wifi and bluetooth, but takes a little for cellular
[13:54] <brendand_> kgunn, when turning off at least
[13:54] <Saviq> brendand_, don't get me wrong, the indicator service should just go "yes, flight mode is on" straight away, and, if failed (?), come back with "oh dude, I failed"
[13:55] <kgunn> yeah
[13:55] <olli> should have, would have, could have... I think the question is...
[13:55] <kgunn> brendand_: we're not arguing we're done and dusted....we're saying what we're wanting to land is "better" than broken
[13:55] <Saviq> brendand_, which needs fixing in the network indicator service or urfkill at least
[13:55] <brendand_> olli, do you have an exact bug number for the issue you're thinking of? is it this one? https://bugs.launchpad.net/indicator-network/+bug/1336715
[13:55] <olli> what's worse... the previous state of the system or the current
[13:55] <Saviq> right
[13:55] <kgunn> but we need time to add design into the mix for a meta-state/transistion for radios and sucj
[13:55] <kgunn> such
[13:56] <brendand_> olli, well not current - it hasn't landed yet
[13:56] <kgunn> Saviq: crap, how do i get this ofono meego sim off my phone now :P
[13:56] <Saviq> kgunn, uninstall it
[13:56] <kgunn> i removed ofono-phonesim-autostart but that no help
[13:56] <Saviq> kgunn, uninstall ofono-phonesim
[13:56] <Saviq> kgunn, and reboot
[13:56] <kgunn> did
[13:56] <olli> brendand_, intended current
[13:57] <Saviq> -phonesim, too, or just -autostart?
[13:57] <kgunn> my bad...
[13:57] <kgunn> doing phonesim (no autostart now)
[13:57] <brendand_> olli, personally i think the previous was better but there appears to be a specific bug i wasn't aware of
[13:58] <Saviq> brendand_, that's where we disagree, you could end up with flight mode permanently saying "yes" when it was, in fact, not enabled
[13:58] <kgunn> exactly...rude surprise for user
[13:58] <Saviq> and then if you toggled, it would say "no", but was actually getting enabled Oo
[13:59] <brendand_> Saviq, i know that was possible in the past, but i do believe a fix was landed to ofono to make that extremely unlikely
[13:59] <brendand_> Saviq, i'll do some testing on the base image
[14:00] <olli> brendand_, to me the improvement was a combination of both bugs
[14:00] <brendand_> tvoss, btw lets get your silo landed, it works beautifully here
[14:02] <brendand_> olli, i think the new behaviour will be extremely confusing for the user because there can be a significant period where the toggle state is not what it's going to be soon in the future
[14:03] <brendand_> olli, so they look at it and go "didn't i just switch that on?"
[14:03] <cjwatson> Mirv: that won't be allowed.  you could upload 5.3.2-2build1 to the relevant silo though
[14:04] <tvoss> brendand_, it is set to testing done, awaiting qa
[14:04] <dbarth> trainguards: hello, can i have a new silo for line 68 ?
[14:06] <brendand_> kgunn, olli, Saviq - it just feels like we are swapping a big issue that happens rarely with a minor issue that is obvious and always there
[14:06] <Saviq> it was happening to me all too often...
[14:06] <Saviq> olli, so yeah, your call, I can back that change out from the silo and give ourselves a few more days to straighten it all out
[14:07] <olli> brendand_, talking to Joe atm
[14:07] <olli> I am inclined to take the fix
[14:07] <olli> but then I might be biased, so getting a 2nd opinion
[14:07] <brendand_> olli, have you seen the new behaviour?
[14:09] <olli> checking it out with KG
[14:13] <brendand_> Saviq, so the bad behaviour you're right is not *that* hard to reproduce, but it does only seem to occur in 'abnormal' use
[14:14] <fginther> alan_g|lunch, vila, I've restored the missing job, apologies for missing this the first time through
[14:14] <olli> brendand_, I think unreliable state is worse than visually confusing
[14:15] <pmcgowan> ogra_, you about?
[14:15] <olli> at least it heals itself
[14:15] <alan_g> fginther: no worries - it made CI a *lot* faster
[14:15] <vila> fginther: thanks
[14:15] <brendand_> olli, if that's your final decision, ok
[14:17] <olli> brendand_, still awaiting feedback from Joe
[14:17] <olli> as I said, I could be seen as biased
[14:18] <bfiller> sil2100: can you republish rtm 5, merges are now approved
[14:18] <sil2100> bfiller: o/
[14:18] <brendand_> olli, i'm just preparing for the inevitable, which is that this lands, then someone notices it in the sanity/regression testing and makes a fuss about it. then i need to say that it landed in silo 4 and i tested it - to which the response will be 'why did you allow that?'
[14:19] <brendand_> olli, better to say 'because product management decided that was the preferred behaviour given the constraints'
[14:19] <olli> brendand_, totally understand your position
[14:20] <sil2100> bfiller: done o/
[14:20] <bfiller> sil2100: thank you
[14:20] <Wellark> Saviq: sorry, was not paying attention to freenode for a while
[14:20] <Wellark> so, what's the problem?
[14:20] <Wellark> Saviq: actually, let's move to #ubuntu-touch
[14:20] <brendand_> olli, fwiw the issue with flight mode getting stuck is not something that i regularly hear mentioned in testing
[14:21] <brendand_> olli, i'm sure there will be a flood of people mentioning this on the mailing list once it lands
[14:21] <brendand_> if it lands
[14:26] <Saviq> brendand_, olli, Wellark is having a look at fixing it indicator-sid
[14:26] <Saviq> e
[14:26] <Wellark> working around!
[14:27] <Wellark> the indicator is not broken strictly speaking
[14:27] <Saviq> nothing is, strictly speaking
[14:27] <Saviq> olli, brendand_, kgunn, let's back out that commit from the silo, land it and give ourselves some time to fix it proper with no visual artifacts?
[14:28] <olli> Saviq, talking to ben/joe/pat atm
[14:28] <Wellark> Saviq: well, the whole indicator framework is broken by (technical) design, but that's another discussion
[14:28] <Saviq> always
[14:44] <kgunn> Saviq: brendand_ dednick ok, so decision is to land this "improvement" but then fix issue in ota1
[14:44] <kgunn> olli: ^
[14:45] <kgunn> that's per prod management aka board of elders
[14:45] <olli> stahp
[14:45] <olli> kgunn, is accelerating my midlife crisis
[14:45] <kgunn> bug has been updated to include ubuntu-ux for design of meta state
[14:46]  * kgunn imagines olli as sort of mace windu on jedi council in his role on board of elders
[14:48] <john-mcaleely> ok, so when we need one, I have a device tarball ready to publish for silo9 + rtm
[14:48] <john-mcaleely> sil2100, ^
[14:49] <sil2100> john-mcaleely: thanks for the info! Victor is  testing the silo 9 right now
[14:49] <sil2100> john-mcaleely: is the device tarball required for silo 9 to work correctly?
[14:49] <sil2100> Since we need to make sure Victor is aware
[14:49] <sil2100> brendand_, davmor2: ^
[14:49] <john-mcaleely> sil2100, it is. and victor was just hassling me for the right permissions. so I think he's away
[14:49] <john-mcaleely> away? aware.
[14:50] <brendand_> kgunn, ok i'm satisfied(ish) ;)
[14:50] <sil2100> ;)
[14:50] <sil2100> olli: ;)
[14:52] <ogra_> olli, wanna buy my porsche ? its not red though
[14:52] <olli> ogra_, 911?
[14:52] <olli> lightly used?
[14:52] <ogra_> (you could make kgunn pay half of it if he is the reason for the crisis)
[14:53]  * olli eyeballs brother in laws dirt bike atm
[14:53] <ogra_> olli, nah, i'm not getting manager salary ... 944S2 well used :)
[14:53] <olli> heh
[14:54]  * olli just bought an family car... with 8 seats...
[14:54] <ogra_> heh, yeah, thats what you get being a father
[14:56] <sil2100> olli: you have a porsche? ;)
[14:56] <sil2100> I mean, ogra_ ^
[14:56] <ogra_> yep
[14:56] <ogra_> old one ...
[14:57] <ogra_> (well, i have three, but only one that drives :) )
[14:57] <sil2100> What kind? Out of curiosity, might snatch it from you if it's good enough
[14:57]  * cwayne is jealous
[14:57] <brendand_> olli, one last thing - can we have a bug raised and tagged for OTA1 to track the UI fix?
[14:57] <sil2100> ...;)
[14:57] <brendand_> olli, i'd like to point the team to it
[14:58] <ogra_> sil2100, http://de.wikipedia.org/wiki/Porsche_944#mediaviewer/File:Porsche_944_rear_20080130.jpg
[14:58] <ogra_> but in white
[14:58] <cjwatson> john-mcaleely: OK, so I'm fine with your patch and can apply it; looks like all those URLs have identical contents right now so it shouldn't cause a new image number to be generated
[14:59] <sil2100> ogra_: oh, looking nice!
[14:59] <cjwatson> sil2100: Are you OK with me going ahead and applying John's patch to the system-image config to use different URLs for the device_krillin tarball for utopic/vivid/14.09?
[14:59] <ogra_> since i dont need to drive to work every day i considered cars are just for fun which made me buy it :)
[14:59] <ogra_> (and its a lot of fun :) )
[15:00] <sil2100> cjwatson: I should be fine, as it's not something that would break any workflow - but to which URL will it change?
[15:00]  * sil2100 lacks context about the change
[15:01] <cjwatson> sil2100: http://people.canonical.com/~jhm/barajas/device_krillin.tar.xz -> http://people.canonical.com/~jhm/barajas/{utopic,master,ubuntu-rtm-14.09}/device_krillin.tar.xz
[15:01] <cjwatson> if you'll excuse the brace-expansion there
[15:01] <sil2100> ogra_: hah, indeed! I'm still looking for a garage - once I do that I want to buy a motorcycl actually
[15:02] <john-mcaleely> cjwatson, sounds good - the same contents was my aim :-)
[15:02] <sil2100> cjwatson, john-mcaleely: then a big +1 on that!
[15:02] <ogra_> sil2100, cool ...
[15:02] <brendand_> olli, i can raise the bug if you're tight for time
[15:02] <ogra_> pmcgowan, i'm back now
[15:03]  * ogra_ finds it funny that once he leaves IRC during a workday for 30min the ping hell breaks lose 
[15:03] <cjwatson> john-mcaleely,sil2100: ok, that's applied now
[15:03] <brendand_> kgunn, or maybe you can raise a bug giving an idea of what the intended fix is?
[15:04] <john-mcaleely> cjwatson, thank you!
[15:05] <kgunn> brendand_: design already updating bug 1336715
[15:06] <brendand_> kgunn, so you're using a different task in the same bug?
[15:07] <Saviq> tvoss, jhodapp, om26er, there's a q-m conflict between silos 2 and 9
[15:07] <brendand_> kgunn, it's a different bug now so to me that's starting to get a bit messy. but whatever you prefer
[15:07] <Saviq> tvoss, jhodapp, om26er, I don't think 2 can land before 9
[15:07] <Saviq> as it would bring with it commits that are in trunk that are not yet in rtm (and are being synced in silo 9)
[15:08] <tvoss> Saviq, ack
[15:08] <brendand_> kgunn, either way confirm for me if you're going to stick with adding a task there or raise a new bug, i want to link to the right thing
[15:08] <Saviq> jhodapp, also, in general, we try to land to vivid first, or at least have a silo into vivid before we land into rtm
[15:08] <kgunn> Saviq: should we do a new bug ? or keep the one ? indicator out of sync
[15:08] <om26er> Saviq, hmm, ok. So how can we "stop" 2 from landing ?
[15:08] <om26er> do you know ?
[15:09] <Saviq> om26er, yeah, don't test it! ;)
[15:09] <kgunn> design supposed to update the existing one...hate to move it
[15:09] <om26er> Saviq, I already did, I need to change it back to needs QA sign-off
[15:09] <jhodapp> Saviq, indeed, though vivid wasn't open when we first tried to land it
[15:09] <om26er> Saviq, or not, I missed that with another silo.
[15:09] <Saviq> jhodapp, but now it is...
[15:10] <jhodapp> Saviq, yep, although it doesn't really matter which you land in first
[15:10] <Saviq> we're in a huge mess of stuff landed in one of {rtm,vivid} now :/
[15:10] <Saviq> jhodapp, kinda does
[15:10] <kgunn> bbiab
[15:10] <Saviq> jhodapp, because if you land in rtm, your trunk will then get ~rtm in the changelog
[15:10] <jhodapp> Saviq, yeah, our team was targeting rtm first for a while, so again not something I just randomly decided
[15:11] <Saviq> jhodapp, ok, seems process is all over the place, contrary to the landing team's recommendation, then :|
[15:11] <Saviq> but that's why we have the conflict problem now
[15:11] <jhodapp> Saviq, the landing process wasn't working well for a while
[15:12] <Saviq> jhodapp, being the person who lands roughly 20-30 MPs a week, I must disagree ;)
[15:13] <Saviq> the only problem was utopic being closed, but that's an exception
[15:13] <jhodapp> Saviq, point noted :)
[15:13] <ogra_> Saviq, there was some agreement that phonedations should be allowed to land in rtm first as an experiment
[15:14] <Saviq> ogra_, oh ok, IMO the experiment failed ;P
[15:14] <ogra_> experiment failed obviously :)
[15:14] <Saviq> because *first* became *only* almost
[15:14] <ogra_> yeah
[15:15] <rsalveti> it was only like that when utopic was closed
[15:15] <rsalveti> or in freeze, depending on the package
[15:18] <brendand_> kgunn, Saviq - any decision about the bug?
[15:20] <rsalveti> qtubuntu-media against trunk and scopes agains the rtm branch
[15:21] <rsalveti> landing madness between 2 distros
[15:21] <ogra_> well, things should still have gone to -proposed for utopic in that case
[15:22] <ogra_> and afaik the plan was that vivid gets utopic-proposed synced on opening
[15:23] <rsalveti> right, but landing first on rtm was not causing issues from that perspective
[15:23] <rsalveti> depending on the project, it's fine to have both landings and land it first on rtm
[15:23] <rsalveti> problem is not having the landing for utopic/vivid
[15:24] <Mirv> ah, ken published the uitk now finally
[15:25] <Mirv> I guess the core-dev application would be a good idea some year after all
[15:25] <Mirv> ogra_: wow!
[15:25] <Mirv> ogra_: looks like fun indeed!
[15:25] <sil2100> Mirv: I'm thinking the same thing ;)
[15:26] <sil2100> Saviq: yeah, regarding that - we're now trying to see how many things we're missing in vivid that landed in ubuntu-rtm
[15:26] <sil2100> And it's not super easy
[15:27] <Saviq> sil2100, you'd think the landers knew ;)
[15:27] <Mirv> oh, right, that migration check is broken in ci train
[15:27] <sil2100> Mirv: migration check..?
[15:28] <Mirv> sil2100: robru updated ci train code, and when he ended in the morning (his night) it all seemed pretty good to me but the migration check probably would still need a bit of fixing. good enough anyway that no need to revert the revert of the revert.
[15:29] <sil2100> o_O
[15:29] <Mirv> sil2100: ci train told vivid 010 would have migrated, while it has not
[15:29] <sil2100> Mirv: ok, let's make sure there's a bug for that and assigned to robru then!
[15:30] <Mirv> sil2100: filing
[15:30] <ogra_> sil2100, so not sure you saw the other discussion ... bug 1387214is currently our worst blocker and needs fixing before final golden master ...
[15:32] <sil2100> ogra_: thanks, this looks serious indeed
[15:32] <sil2100> ogra_: we'll tag it as [TOPBLOCKER] asap as well
[15:32]  * sil2100 adds it to the list for LT
[15:49] <Mirv> bzoltan: Text conflict in po/ubuntu-ui-toolkit.pot when trying to m&c, looking at solving manually
[15:52] <Mirv> bzoltan: sil2100: merged UITK manually, there was .pot file change directly in trunk that had only its comment headers that needed fixing
[15:53] <sil2100> Mirv: thanks! I think there's not much other choices when that happens...
[15:55] <john-mcaleely> incoming device tarball, for vivid channels:
[15:55] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20141106-4f167c4.changes
[15:55] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20141106-4f167c4.tar.xz
[15:55] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-testresults-20141106-4f167c4.ods
[15:55] <john-mcaleely> sil2100, ^ do you want to QA sign of that? (vivid  only device tarball)
[15:55] <john-mcaleely> (I assume you do)
[15:56] <brendand_> john-mcaleely, he's not getting it even if he wants it :)
[15:57] <john-mcaleely> ha
[15:57] <john-mcaleely> well, krillin vivid is broken without it
[15:57] <john-mcaleely> so maybe I should just push it?
[15:58] <sil2100> john-mcaleely: it's for vivid, right?
[15:58] <john-mcaleely> sil2100, yes
[15:58] <ogra_> oh, shiny
[15:59] <ogra_> more log quietening \o/
[15:59] <sil2100> john-mcaleely: I think this can go just as it is, as we don't do sign-off for QA
[15:59]  * ogra_ likes that !
[15:59] <sil2100> (only if QA wants that)
[15:59] <john-mcaleely> ok, so ogra_ is now a good time to push a new vivid tarball?
[15:59] <ogra_> john-mcaleely, sure ...
[16:00] <john-mcaleely> ogra_, sil2100 pushed.
[16:00] <john-mcaleely> should be, lucky-for-some, 13 when it lands
[16:00] <john-mcaleely> rsalveti, ^ hybris sync for vivid/krillin landing
[16:01] <rsalveti> john-mcaleely: great
[16:01] <brendand_> john-mcaleely, if there's absolutely 0 chance it could impact RTM then just land it
[16:02] <john-mcaleely> brendand_, noted. good job, because I just did :-)
[16:05] <popey> plars: i lost the link to those scripts for doing local ci.. do you have the lp link handy?
[16:05] <plars> popey: lp:ubuntu-test-cases/touch
[16:06] <popey> aha! thanks!
[16:13] <ogra_> john-mcaleely, erm ... so why did my rtm krillin just get an update notification ?
[16:13] <ogra_> for image 147 ....  o_O
[16:14] <ogra_> sil2100, did we have a custom tarball today ?
[16:14] <sil2100> ogra_: hm, no, I don't think we did
[16:14] <john-mcaleely> interesting ogra_
[16:14] <sil2100> john-mcaleely, ogra_: did the device tarball get published already?
[16:14] <sil2100> Oh, maybe that's what cjwatson mentioned earlier?
[16:15] <ogra_> sil2100, i understood what john published was vivid only
[16:15] <cjwatson> I just applied a patch to change URLs; at the time I did so the resulting contents should've been identical
[16:15] <john-mcaleely> ogra_, so you do
[16:15] <cjwatson> But I know John was intending to change them shortly afterwards
[16:15] <john-mcaleely> ogra_, darn. cjwatson any idea why that ended up in rtm?
[16:15] <cjwatson> The point of the URL changes was so that we could update vivid without changing utopic or 14.09
[16:15] <cjwatson> no
[16:15] <ogra_> description": "ubuntu=20141106,device=20141106-4f167c4,custom=20141104-399-18,version=147",
[16:15] <cjwatson> Somebody not at a conference will have to debug that
[16:16] <ogra_> and "description": "ubuntu=20141106,device=20141105-4a6bca7,custom=20141104-399-18,version=146",
[16:16] <john-mcaleely> I know at least one reas
[16:16] <john-mcaleely> on
[16:16] <john-mcaleely> looks like it might have been me
[16:16] <ogra_> 146 looks like what cjwatson describes
[16:16] <ogra_> it is identical to 145
[16:16] <ogra_> 147 looks like a new device tarball
[16:17] <john-mcaleely> ogra_, interesting - it seems to be a mixture
[16:17] <cjwatson> I hadn't expected the patch I applied to result in a new image number since the contents were identical, but I guess import-images might have noticed the change and tried; an extra identical image shouldn't have been a problem
[16:17] <john-mcaleely> the device_krillin.build has been touched by me here:
[16:17] <ogra_> cjwatson, yeah, no worries, that should be fine
[16:17] <john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin.build
[16:18] <ogra_> the device tarball that was intended for vivid only is wrong though
[16:18] <john-mcaleely> but the tarball next to it has not
[16:18] <john-mcaleely> ah
[16:18] <john-mcaleely> my mistake
[16:18] <cjwatson> The config looks right.  http://paste.ubuntu.com/8853786/ FWIW
[16:18] <john-mcaleely> ln foiled me
[16:19] <cjwatson> Ha
[16:19] <ogra_> john-mcaleely, so just take the old tarball and bump the version ?
[16:20] <ogra_> to replace the wrong one
[16:20] <john-mcaleely> ogra_, yeah. doing it now
[16:23] <robru> ev: when you say 'fix cowboyed into production' what exactly did you do?
[16:24] <john-mcaleely> ogra_, sil2100 cjwatson sorry about that
[16:24] <john-mcaleely> over keen use of ln when setting up three copies of the same file to start with
[16:24] <john-mcaleely> all now broken to unique files
[16:25] <john-mcaleely> and for rtm & utopic, I've bumped the revision, and linked the correct tarball
[16:25] <john-mcaleely> so new builds, I assume, but fixed ones
[16:26] <sil2100> john-mcaleely: no worries, glad it's fixed now
[16:27] <john-mcaleely> as ever: zero chance of impact, where zero takes non-zero values :-)
[16:28] <sil2100> hah ;)
[16:29] <Saviq> brendand_, are you still waiting for something from us re: silo 4?
[16:31] <brendand_> Saviq, no - i'm kind of hoping silo 9 will land at the same time because i had a gut feeling 4 on its own was making the unity8 crasher slightly more common, but i'll land it tonight regardless
[16:31] <brendand_> thanks kgunn for filing the new bug
[16:32] <Saviq> brendand_, ok thanks
[16:35]  * ogra_ upgrades to 148
[16:35] <ogra_> heh, with that the flashing only flashed my screen (and rebooted)
[16:39] <brendand_> john-mcaleely, my my
[16:39] <davmor2> robru: he got a cowboy call Fix and pushed him into production, ev is like that
[16:39] <brendand_> john-mcaleely, i should always remember what 'zero chance' really means :)
[16:39] <john-mcaleely> brendand_, :-)
[16:40] <davmor2> brendand_: you didn't believe a developer did you, that was mistake number one ;)
[16:41] <davmor2> john-mcaleely: would that be why my phone took forever to boot and say 14.10 on my ota testing then?
[16:42] <john-mcaleely> davmor2, hrm. for 147, yes
[16:42] <john-mcaleely> 147 never existed
[16:42] <john-mcaleely> or shouldn't :-)
[16:50] <tvoss> trainguards, can I get silo for line 71?
[16:56] <sil2100> tvoss: o/
[16:56] <tvoss> sil2100, o/
[16:57] <sil2100> tvoss: with pleasure, this is one of the recently approved bugs for ubuntu-rtm as well
[16:57] <sil2100> (and I like the idea you land it first to vivid0
[16:57] <sil2100> )
[16:57] <bfiller> sil2100: need a silo for line 70 as well
[16:58] <sil2100> bfiller: sure thing, the same thing here - assigning, just make sure that the same fix gets into vivid as well
[16:58] <bfiller> sil2100: will do
[16:58] <tvoss> sil2100, ack
[17:00] <popey> landing call?
[17:02] <sil2100> davmor2: meetong
[17:02] <sil2100> plars: same here ^
[17:02] <davmor2> trying to login in
[17:02] <dbarth> o/ if there is a vivd silo available for line 68
[17:02] <dbarth> thanks ;)
[17:03] <davmor2> sil2100: Trying to join the call. Please wait...
[17:12] <robru> Mirv: what symptoms did you observe in check-publication-migration during your shift? I thought I fixed that...
[17:14] <balloons> ping joespht .. is something up with core apps jenkins?
[17:15] <plars> sergiusens: I never saw any new ubuntu-device-flash or phablet tools for trusty in the ppa yet...
[17:17] <sergiusens> plars: yeah, I thought I'd ping you before doing that (it's for trusty, right?)
[17:17] <plars> sergiusens: yes
[17:22] <popey> plars: http://paste.ubuntu.com/8854525/ what am I doing wrong here?
[17:22] <popey> it just hangs at that point and the phone is in recovery mode
[17:24] <olli> sil2100, Saviq, kgunn, so do we have the u8 and tvoss' silos come through now?
[17:24] <plars> popey: no idea, it's just doing ubuntu-device-flash at that point. The scripts don't have any control over what udf does internally
[17:26] <sil2100> olli: they're in QA :)
[17:26] <sil2100> olli: so the status is:
[17:26] <sil2100> olli: the u8 silo is basically signed-off, but it's waiting on tvoss's silo, since brendand_ suspected that u8 actually makes the crashes appear more frequently
[17:27] <sil2100> olli: while the tvoss silo fixes those completely
[17:27] <olli> are they good for rtm
[17:27] <olli> or just vivid?
[17:27] <sil2100> olli: so brendand_ wants to wait for silo 9 to finish the sign-off to make sure that both of them land in the same moment
[17:27] <sil2100> olli: that's for RTM now, I think those landed in vivid already
[17:27] <olli> k
[17:27] <sil2100> olli: anyway, ETA is today still
[17:27] <olli> good
[17:28] <olli> sil2100, what else are you expecting to land for the Fri image?
[17:28] <john-mcaleely> sil2100, you'll need to ping me to land silo9, so you can get a device tarball
[17:30] <sil2100> john-mcaleely: sure :)
[17:31] <sil2100> olli: there's one more silo with telepathy-ofono which we need
[17:31] <sil2100> The others are not super required
[17:38] <balloons> fginther, is there something up with the core jenkins? No pages seem to be loading for me
[17:38] <balloons> *community core apps jenkins
[17:42] <fginther> balloons, please ping the vanguard josepht
[17:42] <balloons> fginther, aye, I did, just didn't get anything bug..
[17:43]  * balloons patiently waits
[17:43] <fginther> balloons, ohhh
[17:43] <robru> urgh wtf
[17:45] <fginther> balloons, should be back now. the jenkins process appeared to be wedged
[17:49] <robru> bzoltan: yeah sorry shit's broken right now, gimme a sec
[17:50] <fginther> balloons, sorry about the run-around. Will see if we can handle this better in the future.
[17:51] <balloons> fginther, no worries. It was just really impactful so I felt the need to ping you
[17:51] <balloons> thanks
[17:51] <ev> robru: I came up with a diff to the jenkins charm and asked webops to deploy that to the production jenkins instance
[17:52] <ev> then committed that
[17:52] <ev> I'll follow up to your email tomorrow. Running out of time today
[17:53] <ev> to be clear, I'm not trying to blame anyone for this, just mention that it's shining a light on how our architecture/process is wrong - we shouldn't be referring to an external branch that can change at any time from a production service
[17:53] <ev> code deployments should be bundled with the charms themselves
[17:53] <ev> but all things for us to carve out a story for
[17:55] <robru> ev: thanks, no worries, I'm not feeling blamed, and I agree that citrain is essentially a case study in "what not to do". I'm looking forward to ditching it and appreciate your help
[17:55] <ev> :)
[17:55] <ev> I am responsible for much of this mess, so do know I feel equally invested in its improvement
[17:56] <robru> ev: oh really? this whole time I've been blaming a certain frenchman...
[17:56] <ev> hahaha
[17:59] <robru> Mirv: sil2100: I have a hotfix for check-publication-migration, it's in production already, just waiting for it to automerge into trunk
[18:06] <bfiller> robru: would you mind deleting vivid silo 27 and allocating vivid silo for line 73
[18:08] <pmcgowan> sil2100, are the commit logs generated automatically, there seems to be a long lag between an image being installable and the log being available
[18:08] <ogra_> pmcgowan, well, it uses my changelogs as input ... mine get generated/linked only 5min after an image was built
[18:09] <sil2100> pmcgowan: they're generated automatically on a remote host, but they're not synced to any public place automatically - my machine does it currently
[18:09] <pmcgowan> ok thanks
[18:09] <robru> bfiller: sure
[18:09] <sil2100> pmcgowan: there is a ticket for an automatic copy to people.canonical.com, but I didn't have time to push people on moving that forward
[18:09] <pmcgowan> sil2100, thanks
[18:09]  * ogra_ guesses we need a landing team sprint some day ... with only the focus to move all our tools away from our home desktops :P
[18:09] <pmcgowan> ogra_, where are your logs?
[18:09] <pmcgowan> +1
[18:10] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/rtm/
[18:10] <ogra_> one level up there is devel (vivid)
[18:10] <sil2100> ogra_: hah, my scripts are running on a canonistack instance!
[18:10] <ogra_> and there are archives too
[18:10] <robru> bfiller: ok you got 7 now
[18:10] <sil2100> ogra_: so that's not on my home desktop ;)
[18:10] <bfiller> robru: cheers
[18:10] <robru> bfiller: you're welcome
[18:11] <ogra_> sil2100, hah
[18:11] <pmcgowan> sois the 148 I just got actually 145? so confused
[18:11] <ogra_> pmcgowan, before you start to wonder, these changelogs are only rootfs changes ...
[18:11] <ogra_> so all custom tarball or device tarball uploads generate nothing
[18:12] <sil2100> pmcgowan: basically, yes ;)
[18:13] <ogra_> pmcgowan, yes, 146 was 145 renamed when colin made a change on tehserver config ... 147 was a wrongly landed device tarball, and 148 was the reversion of that tarball ... which gets you back to 145 with shiny new version number
[18:13] <pmcgowan> pooooof
[18:13] <pmcgowan> head exploding
[18:13] <ogra_> lol
[18:14] <ogra_> yeah, better stick to sil2100's executive summary
[18:15] <sil2100> hah ;p
[18:33] <josepht> balloons: sorry, I must've missed your ping
[18:35] <josepht> balloons: my highlight didn't catch it :) 12:14 < balloons> ping joespht .. is something up with core apps jenkins?
[18:35] <balloons> josepht, ahh fun!
[18:36] <balloons> you should remember to turn off those ignore balloons settings whenon vanguard :p
[18:38] <ogra_> pmcgowan, i think i saw somone else with bug 1390170 yesterday
[18:39] <popey> plars: omg... it was a dodgy usb cable!
[18:40] <ogra_> pmcgowan, ah, that was seb128
[18:40] <pmcgowan> ogra_, yeah thats a first for me
[18:40] <pmcgowan> now getting 0 or 2 it seems
[18:40] <ogra_> so he can confirm your bug :)
[18:40] <ogra_> iirc there was already some log collecting going on with Chipaca
[18:41] <seb128> ogra_, pmcgowan, yeah, just commented on it, Chipaca said it was an indicator bug, the push helper log suggest it send a clear order to the indicator and that seems to fail
[18:41] <Chipaca> pmcgowan: if you've got that again, talk with larsu
[18:42] <Chipaca> (larsu agreed it's a bug, asked for a way to reproduce, or a crash)
[18:43] <seb128> Chipaca, larsu said the warning in the messaging log was a bug right?
[18:43] <seb128> we have no proof that the "didn't clear" issue was the same one
[18:44] <Chipaca> well, we have push asking for a clear, the clear not happening, and a warning in the log about a delete out-of-bounds error
[18:44] <seb128> well, maybe the way push ask for the clear is buggy?
[18:44] <seb128> the indicator didn't change for a while and we never had clear failing
[18:44] <pmcgowan> is there a messaging log I should grab?
[18:45] <seb128> pmcgowan, cf my command on the bug
[18:45] <seb128> comment even
[18:45] <Chipaca> yes, which is why i asked larsu, and his response was that it shouldn't ever happen
[18:45] <seb128> k
[18:45] <seb128> is there any way we can "emulate" the situation?
[18:45] <seb128> would make easier debugging
[18:47] <Chipaca> seb128: i don't know how the situation comes about
[18:47] <Chipaca> once it's in there, it's easy enough to see the failure
[18:47] <Chipaca> just call ClearPersistent on the right endpoint
[18:47] <Chipaca> see it return 0 (as if there were nothing in the indicator)
[18:47] <Chipaca> hmmm... well, that's only after the first. so no.
[18:47] <Chipaca> seb128: i don't know of one.
[18:48] <seb128> I guess the question is "do we have a script that do 'add entry, clear, add entry'" the same way that's done in the scenario logged in those logs
[18:48] <Chipaca> seb128: i can give you a command that does "clear, add entry" and you can call it repeatedly
[18:49] <seb128> Chipaca, that would be a start ;-)
[18:49] <seb128> then I can see if I can get the indicator to print that warning again
[18:49] <seb128> pmcgowan, note that the dup doesn't happen all the time, I got it once this week
[18:49] <seb128> just got an update notification and it's not duplicated
[18:49] <pmcgowan> seb128, this is the only time I ever saw it
[18:50] <pmcgowan> I added a coupe logs around the time
[18:50] <ogra_> pmcgowan, but you usually dont wait til two images have built
[18:50] <ogra_> today we actually had two really close in succession ... we rarely have that
[18:51] <pmcgowan> ogra_, thats true, although 147 had downloaded already
[18:54] <rsalveti> sil2100: ogra_: john-mcaleely: we can land silo rtm 9, but we need to coordinate it with the device tarball
[18:54] <rsalveti> how to proceed?
[18:55] <john-mcaleely> I think sil2100 had a cunning plan earlier
[18:55] <ogra_> rsalveti, once the silo migrated we switch off the s-i auto-importer
[18:55] <john-mcaleely> or possibly ogra_ did
[18:55] <ogra_> once the rootfs is built and the tarball is in place, we switch it back on
[18:55] <rsalveti> alright, let me publish it then
[18:56] <plars> popey: hah!
[18:56] <sil2100> rsalveti, ogra_, john-mcaleely: right, we publish silo 9, silo 4, ogra_ disables the auto-importer and we kick a new image
[18:57] <ogra_> ah, i forgot about 4
[18:57] <ogra_> that was so tiny ... easily missed :P
[18:58] <sil2100> Would be best to have 4, but brendand said it's signed-off too
[18:58] <sil2100> I mean, it was just waiting for silo 9
[18:58] <sil2100> ...and that telephony silo
[18:58] <sil2100> brendand: ping ^
[18:58] <rsalveti> argh, having issues publishing it
[18:58] <sil2100> uh
[18:59] <rsalveti> that was after doing a watch only build
[18:59] <sil2100> hmmm
[19:01] <rsalveti> sil2100: no idea of what is going on in there
[19:01] <rsalveti> can't publish
[19:01] <sil2100> rsalveti: will try looking into that as well
[19:01] <robru> slangasek: sil2100: meeting? https://plus.google.com/hangouts/_/canonical.com/landing-team?authuser=1
[19:01] <ogra_> just dput :P
[19:05] <sil2100> rsalveti: strange, CI Train doesn't find those packages at all
[19:07] <rsalveti> nice
[19:07] <sil2100> rsalveti: even though the backend has that configured
[19:07] <sil2100> hmmm
[19:07] <sil2100> Maybe the state got lost on the jenkins instance
[19:07] <sil2100> Let me take a look there
[19:08] <rsalveti> alright
[19:15] <sil2100> robru: hmm... you might need to look into that yourself ^
[19:15] <sil2100> robru: since it seems that before doing watch-ppa for silo 009 citrain doesn't seem to copy the .dsc files for watch-ppa anymore
[19:15] <sil2100> So it doesn't recognize those
[19:15] <sil2100> robru: did you test your changes for source uploads?
[19:23] <sil2100> robru: might not be caused by your changes, but as we relied on paths there, I suspect it might
[19:39] <robru> sil2100: hm, I guess I forgot to test source uploads. I made sure mps and syncs were working though. they all copy the dscs into the right place. Ok I can take a look at that now. :-/
[19:42] <sil2100> robru: thanks! :)
[19:42] <sil2100> ogra_: and still no archive link for my e-mail ;/
[19:42] <ogra_> the last two days it was pretty fast
[19:43] <robru> rsalveti: sorry are you in a hurry to publish? I really need to take lunch...
[19:44] <slangasek> lool: interesting... why does spreadsheet line 18 have a testing sign-off from you against an RTM image for an Ubuntu silo?
[19:44] <ogra_> robru, the next image build waits for it ..
[19:44] <robru> rsalveti: if you're in a hurry just binary-copy the packages. but please don't free the silo, I need to poke at it.
[19:44] <robru> ogra_: ugh it will not be quick to fix. can you just binary copy the packages from the silo to distro?
[19:45] <ogra_> i'll leave that to ricardo, but yeah
[19:45] <ogra_> get your lunch
[19:45] <ogra_> :)
[19:45] <robru> ok, brb
[19:47] <rsalveti> robru: I can give you some time, no worries
[19:47] <rsalveti> as long we have people around that knows what needs to be done with the device tarball
[19:48] <ogra_> rsalveti, well, can you find someone else to coordinate the image then ? i dont want to do an all-nighter
[19:49] <rsalveti> ogra_: let me just publish that by hand then :-)
[19:49] <ogra_> :)
[19:49] <ogra_> thanks :)
[19:53] <brendand-nexus5> sil2100 did you hear anything about 9 yet?
[19:54] <rsalveti> landing as we speak
[19:54] <brendand-nexus5> 4 and 17 will join it then
[19:55] <ogra_> if they can
[19:55] <rsalveti> ogra_: robru: alright, just manually copied all packages from silo 9
[19:55] <ogra_> great
[19:56] <rsalveti> silo 4 is still waiting QA to sign it off it seems
[19:56] <ogra_> lets hope the other silos dont need that too
[19:56] <ogra_> rsalveti, brendand-nexus5 gave that hours ago ...
[19:56] <ogra_> not sure why the spreadsheet isnt updated then
[19:56] <rsalveti> right, looking at the spreadsheet
[19:57] <rsalveti> should I publish both now then?
[19:58] <brendand-nexus5> ogra i did not. I was waiting for 9
[20:00] <Ursinha> slangasek, sil2100: I've requested access for both of you, it's not an RT but bootstack support instead -- unfortunately only the person that filed the request can see it
[20:00] <Ursinha> I'll update you once they update the request
[20:01] <sil2100> brendand-nexus5: so, we seem to have a train issue
[20:02] <sil2100> brendand-nexus5: once robru investigates, we might have it released
[20:02] <brendand-nexus5> sil2100 - :/
[20:02] <sil2100> robru: if it takes too long, please soft revert the change and publish silo 9 and 4
[20:02] <sil2100> Those are crucial for our images
[20:04] <rsalveti> already manually published silo 9
[20:04] <ogra_> sil2100, we can just copy-package the others too i guess
[20:05] <olli> sil2100, jhodapp do you guys know if this is in flight?
[20:05] <olli> https://bugs.launchpad.net/ubuntu/+source/unity-scope-mediascanner/+bug/1381930
[20:05] <ogra_> sil2100, rob seems to only need the stuff to stay in there for investigation
[20:05] <jhodapp> olli, should be, Saviq's team is working to land that
[20:06] <rsalveti> we just landed a few changes to qtubuntu-media
[20:06] <rsalveti> wonder if we need to rebase it
[20:06] <rsalveti> or land it first on vivid
[20:06] <rsalveti> jhodapp: we can safely land https://code.launchpad.net/~jhodapp/qtubuntu-media/fix-1381930/+merge/240327 on vivid, right?
[20:07] <jhodapp> rsalveti, yes
[20:07] <rsalveti> let me create a silo for that one
[20:08] <sil2100> Ok, so make sure that silo 4 and the telephony changes land as well
[20:08] <sil2100> And do the image kick
[20:08] <robru> rsalveti: sil2100 ogra_ other than 9, are the other urgent silos source uploads, syncs, or mps?
[20:09] <sil2100> robru: not sure if 4 is not mixed
[20:09] <rsalveti> seems we need 4 and 17
[20:09] <rsalveti> 14 is also ready to go
[20:10] <sil2100> ogra_: and still no archive entry of my e-mail...
[20:10] <sil2100> Ok, I need to AFK now, see you tomorrow
[20:10] <sil2100> ogra_: I'll keep my eyes opened for that and post when I see it
[20:10] <sil2100> o/
[20:11] <rsalveti> ogra_: robru: will try landing 4 and 17 then
[20:11] <jhodapp> quite the backlog of things to land :)
[20:11] <rsalveti> Saviq: https://code.launchpad.net/~unity-team/unity8/rtm-14.09-staging/+merge/240664 is not yet approved
[20:13] <om26er> ralsina, Hi!
[20:13] <rsalveti> 17 is in, can't publish 4 though
[20:13] <rsalveti> until the MR is approved
[20:13] <rsalveti> kgunn: ^
[20:13] <robru> rsalveti: wtf? 9 is a sync silo, I specifically tested that, it was working yesterday!
[20:13] <om26er> ralsina, I am trying to test silo for bug 1384855 -- I am not sure what was the issue exactly ?
[20:14] <ralsina> om26er: there was a bug that caused a push-client crash when a certain function was called.
[20:14] <ralsina> om26er: nothing used that function before so noone noticed. The suggested test is adding the crashing call on startup of the hello app. If you can start it and push-client doesn't crash, it's fixed
[20:15] <kgunn> rsalveti: thanks...hmmm which MR
[20:15]  * kgunn goes to look
[20:16] <om26er> rsalveti, so no potential of regression then, you are just fixing an API that nothing was using before  ?
[20:16] <rsalveti> kgunn: https://code.launchpad.net/~unity-team/unity8/rtm-14.09-staging/+merge/240664
[20:16] <olli> Saviq, is this in flight?
[20:16] <olli> https://bugs.launchpad.net/dialer-app/+bug/1378043
[20:17] <robru> rsalveti: ogra_ oh ok I see what's happening, i changed the code to save certain files in a different place, this silo was assigned before the change so the files are in the wrong place. I can fix this live in production without any code changes
[20:17] <kgunn> rsalveti: ok, approved just an oversight
[20:17] <kgunn> olli: we're all good
[20:17] <olli> kgunn,
[20:17] <olli> ?
[20:18] <kgunn> olli: oops, nvmd
[20:18] <kgunn> lemme read
[20:18] <om26er> ralsina, oops that message above was for you :) wrongly sent to ricardo.
[20:18] <kgunn> rsalveti: we're still good on the approval topic tho
[20:18] <om26er> rsalveti, mis-typed :)
[20:18] <rsalveti> alright, 4 just got published
[20:18] <kgunn> olli: that bug isn't us
[20:18] <ralsina> om26er: exactly, just fixes that API, noone uses it yet, telegram will after this lands
[20:18] <kgunn> chicken
[20:19] <ralsina> om26er: no regression possible at all
[20:19] <rsalveti> robru: ogra_: guess we just wait them to hit release, trigger a new image and copy the device tarball
[20:19] <rsalveti> ogra_: is that something you can take care of?
[20:19] <olli> kgunn, it has an rtm u8 task
[20:19] <om26er> ralsina, cool.
[20:19] <robru> rsalveti: right, well now there's this: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-009-2-publish/23/console
[20:20] <kgunn> olli: my bad...i see he added a chicken branch for u8
[20:20] <rsalveti> wtf
[20:20] <ogra_> rsalveti, thats why i'm still here, we need to stop the auto-importer
[20:20] <kgunn> olli: yes, it was part of the mega load
[20:20] <robru> rsalveti: version bs. did you binary copies get accepted? seems like you were uploading versions 14.10 when 15.04 was already in rtm
[20:20] <ogra_> (to have everything be imported together)
[20:20] <kgunn> so silo4
[20:21] <pmcgowan> kgunn, which has landed already? i cant reproduce it
[20:21] <rsalveti> robru: silo 9 was fine, did a binary copy and it worked fine it seems
[20:21] <kgunn> pmcgowan: actually...silo4 rtm is _just_ now landing
[20:21] <kgunn> only landed on vivid 2 days ago
[20:22] <robru> rsalveti: oh wait, I think I'm reading the log backwards. I think it's just complaining that it found your manual uploads already at the destination and it didn't expect that
[20:22] <rsalveti> robru: right, that would make more sense :-)
[20:23] <pmcgowan> kgunn, it was merged on the 20th, seems it must have landed before now
[20:23] <pmcgowan> anyway I cant see the issue occur
[20:23] <kgunn> pmcgowan: on trunk
[20:23] <robru> rsalveti: ok ignore the errors coming from silo 9, it's confused. once the packages are in destination we can just free that
[20:23] <kgunn> we've got 2 branches
[20:23] <kgunn> already
[20:23] <robru> rsalveti: I'll check other silos for this same problem and pre-emptively fix those
[20:23] <rsalveti> alright
[20:24] <pmcgowan> kgunn, I guess I am concerned as the bug seems fixed, so whats the MR for
[20:24] <pmcgowan> ChickenCutlass, you around?
[20:24] <kgunn> at any rate, bug updated
[20:25] <kgunn> pmcgowan: you're right...it was in the last mega load (end of sprint week)
[20:25] <pmcgowan> kgunn, oh good
[20:25] <pmcgowan> thanks
[20:25] <kgunn> sorry, thot it was this one
[20:25] <kgunn> i just see big silo, i think it's this one :D
[20:25] <pmcgowan> you and your big silos
[20:26] <Ursinha> robru: are these bugs we are introducing with our changes? or only bugs our changes are uncovering?
[20:26] <rsalveti> I just landed so many things I'm scared
[20:26] <rsalveti> lol
[20:26]  * kgunn wants a tshirt that says "unity8: we've got big silos"
[20:26] <rsalveti> 10 packages + new device tarball
[20:26] <Ursinha> kgunn: hahaha
[20:27] <olli> kgunn, so https://bugs.launchpad.net/dialer-app/+bug/1378043 this one is fix released then
[20:27] <olli> wondering why it wasn't cleaned up
[20:27] <rsalveti> isn't this part of the one that is just landing?
[20:27] <kgunn> olli: i think actually it was linked after the bot ran ?
[20:27] <robru> Ursinha: a little bit of both
[20:27] <olli> hm
[20:27] <kgunn> or the bots semi-reliable
[20:27] <olli> kgunn, mind updating the status?
[20:28] <robru> rsalveti: ok same issue fixed in 2 other silos, initial guess is that's all of them, will double check now
[20:28] <kgunn> i did, hit refresh ?
[20:28] <kgunn> olli: ^
[20:28] <olli> good boy
[20:28] <olli> thx!
[20:28] <rsalveti> wtf
[20:28] <rsalveti> lol
[20:28]  * kgunn sits up and pants
[20:28] <olli> :)
[20:29]  * ogra_ looks for bleach to get these pics gone
[20:30] <robru> Ursinha: so the thing is, there is just a literal truckload of code that accesses files using relative paths, and depends on the cwd being set correctly somewhere else in the code. In most cases you can just change the relative path to an absolute path and it's fine. but some bits of the code were so obscure that I literally was not able to trace back from
[20:30] <robru> the relative path to the previous call to os.chdir to figure out what directory it was supposed to be in. so I just hardcoded 'ok these files live in the silo root dir now', and that's great when you assign a new silo from scratch, but unfortunately existing silos had those files in bizarre subdirectories that I didn't expect. so I had to just dig in the
[20:30] <robru> server and move those files into their new canonical path in order for the new code to find those
[20:32] <ogra_> rsalveti, is 009 completely in ?
[20:34] <rsalveti> ogra_: yes
[20:34] <ogra_> great, let me kick of a rootfs then ... will john-mcaleely be around later to push the tarballl ?
[20:34] <john-mcaleely> he will ogra_
[20:34] <ogra_> yay
[20:34] <ogra_> :)
[20:35] <john-mcaleely> how long do you think?
[20:35] <john-mcaleely> (before I do my bit)
[20:35] <ogra_> 45min for the rootfs or so ...
[20:35] <ogra_> max 1h
[20:35] <john-mcaleely> ok, I'll return to a beer for a while then :-)
[20:36] <ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu-rtm/14.09/ubuntu-touch/
[20:36] <ogra_> :)
[20:38] <john-mcaleely> how many times can I hit reload?
[20:38] <john-mcaleely> :-)
[20:38] <ogra_> heh, try DOSing the server ;)
[20:38] <ogra_> the estimated times are really just rough guesses
[20:38] <ogra_> armhf usually takes longer
[20:39] <imgbot> [20:39] <davmor2> ToyKeeper: ^ one for you to review on sanity when it builds I think :)
[20:40] <asac> i guess we could parse the backlog of the imgbot and use the times to get real data on how long it takes
[20:40] <ogra_> asac, well, thats combined times of s-i and rootfs
[20:40] <olli> kgunn, mind having a look at https://bugs.launchpad.net/ubuntu-ux/+bug/1384749
[20:40] <ogra_> the url above has the plain rootfs
[20:40] <asac> ogra_: guess thats what we really care about, no?
[20:41] <ogra_> asac, indeed
[20:41] <kgunn> olli: doing
[20:41] <asac> "time to final image"
[20:41] <ogra_> asac, though john waits to upload the device tarball at tthe right time
[20:41] <ogra_> for that tthe rootfs build time is the measure
[20:41] <asac> oh an "alley oop" basically
[20:41] <davmor2> asac: from experience 1:30-2hours
[20:41] <asac> nice move
[20:41] <asac> lol
[20:42] <ogra_> asac, right ... coordinated device tarball and silo landing ... so we spare one broken image
[20:42] <asac> yeah alley-oop :)
[20:42] <ogra_> right, 1:30 -2h ... this time it will take longer because i'm driving the s-i importer manually
[20:43] <asac> guess we should think about how to make infra smarter so doing what we try to do is less of a stunt
[20:43] <kgunn> olli: so wrt bug, my understanding is, there's really nothing to be done from our end
[20:43] <asac> l8tr
[20:43] <ogra_> at some point we need one s-i server per project
[20:43] <olli> kgunn, can we remove the tasks then
[20:43] <ogra_> then its gets easy
[20:43] <kgunn> olli: the related mir bug could be considered an "enhancement"
[20:43] <kgunn> olli: ack
[20:49] <ChickenCutlass> pmcgowan: yes
[20:50] <pmcgowan> ChickenCutlass, we closed that bug we were discussing
[20:50] <pmcgowan> where the phone locked on a call
[20:50] <ChickenCutlass> pmcgowan: right cool
[20:50] <ChickenCutlass> pmcgowan: that should have been fixed with the last big unity upload
[20:50] <pmcgowan> yep
[21:05] <ToyKeeper> Ah hah, I *did* hear a beep somewhere.
[21:05] <ToyKeeper> asac: It might be hard to get data from IRC logs, since imgbot hasn't been very reliable lately.
[21:05] <ToyKeeper> Anyway, I'll get the 149 testing going soon after it finishes building.
[21:05] <ogra_> yeah, sorry for that
[21:06] <ogra_> (imgbot)
[21:18] <bfiller> robru: could you publish rtm14 when you get a chance? thanks!
[21:25] <robru> ogra_: is it safe to publish rtm14 yet? how's that image build going?
[21:26] <ogra_> robru, just go ahead, it is in the final stages
[21:26] <om26er> robru, do you know when does the next rtm build will happen ? i.e. 149
[21:27] <ogra_> om26er, in the works :)
[21:27] <john-mcaleely> ogra_, page says built. do I push yet?
[21:27] <ogra_> john-mcaleely, yeah, go ahead
[21:27] <om26er> ogra_, as in building ? great!
[21:28] <ogra_> well, more as in"being-hand_puzzled-together"
[21:28] <ogra_> :)
[21:28] <john-mcaleely> ogra_, next puzzle piece slid in
[21:28] <john-mcaleely> ogra_, tarball pushed
[21:29] <ogra_> awesome ... firing the importer back up
[21:30] <john-mcaleely> this will be 149, right?
[21:30] <ogra_> thats what the bot said, yes :)
[21:31] <ogra_> and the importer runs again ...
[21:31] <ogra_> ~30min now, then we are done
[21:32] <john-mcaleely> nice
[21:34] <ogra_> plars, the 146 krillin tests seem to hang in address_book
[21:34] <ogra_> (or at least the dashboard does)
[21:46] <plars> ogra_: I'll take a look
[21:46] <ogra_> thx
[21:51] <ogra_> importer done ... should show up any minute
[21:53] <plars> ogra_: argh, 147 is up now I think... so the one I just started will pull that
[21:53] <plars> oh, no it's getting 146, we're good
[21:54] <plars> ogra_: it seems that device went offline in the middle of the run and the job timed out. I'm curious to hear what state the device ended up in
[21:54] <imgbot> [21:54] <imgbot> [21:54] <john-mcaleely> \o/
[21:55] <asac> 1:15h
[21:55]  * john-mcaleely upgrades impatiently
[21:55] <asac> not too bad
[21:55] <ogra_> go wild hapy testing :)
[21:55] <plars> we skipped 147 and 148?
[21:55] <ogra_> asac, well, that was hand driven ... check the bot notes tonight with the auto-build ... thats mpore realistic
[21:57] <asac> hand driven should be slower in average, no?
[21:57] <ogra_> wow ... what a changelog
[21:57] <asac> anything unexpected in that changelog?
[21:57] <ogra_> asac, not necessarily ... the different cron jobs are not all in sync ... so you have dealays ... i actually never measured the difference
[21:58] <ogra_> s/you have delays/you can have... /
[21:58] <asac> right. cron can only go so far. better is trigger driven :)
[21:58] <asac> hehe
[21:58] <asac> so is this image potentially the best ever?
[21:58]  * asac checks for update
[21:58] <ogra_> the compononets surely are
[21:58] <john-mcaleely> unquestionably
[21:58] <ogra_> dont ask about the whole ;)
[21:59] <john-mcaleely> just booted for me
[21:59] <asac> the components alone are not worse a lot; what counts is the melting pot of all in one unique awesome experience that is more than just software :)
[21:59] <john-mcaleely> what else could go wrong?
[21:59] <ogra_> right, but we dontn know how well all of them interact :)
[21:59] <ogra_> you only see that in the full image at the end :)
[22:02] <ChickenCutlass> ogra_: not seeing 149 when I check for  updates
[22:02] <ChickenCutlass> ogra_: does it take a little while
[22:02] <ChickenCutlass> ?
[22:04] <robru> ChickenCutlass: in my experience it's available as soon as the bot pings about it, but maybe that's no longer the case (I haven't tried recently)
[22:04] <ChickenCutlass> robru: that’s what I thought — systems settings saying nothing there.
[22:04] <ChickenCutlass> anyway
[22:04] <ChickenCutlass> I will wait
[22:05] <rsalveti> at least ubuntu-device-flash already found 149 here
[22:05] <ogra_> ChickenCutlass, tell Chipaca
[22:05] <Chipaca> hello hello
[22:05] <ChickenCutlass> ogra_: I am manually checking as well
[22:05] <ogra_> the system-settings updater too
[22:05] <Chipaca> drat
[22:05] <ogra_> ChickenCutlass, ah, then you most likely trashed the data for Chipaca
[22:05] <Chipaca> goodbye goodbye
[22:06] <ogra_> heh
[22:06] <ChickenCutlass> ogra_: I rebooted and now its there
[22:06] <ogra_> ChickenCutlass, i have it flashing here
[22:06] <ChickenCutlass> weird
[22:06] <ogra_> when i had that last i saw a hanging system-image process
[22:06] <ogra_> check the next time
[22:06] <ChickenCutlass> ok
[22:08] <ogra_> well, it boots ...
[22:08] <ogra_> hmm, registering my SIMs seems to take quite long
[22:09] <ogra_> ah, now it has both
[22:09] <john-mcaleely> worked for me - hit update after the bot announced it. now enjoying it...
[22:09] <ToyKeeper> I wonder why xchat stopped pinging me when imgbot says something, but I still get notifications when someone mentions the word "imgbot".  Odd.
[22:10] <ogra_> yeah
[22:11] <ogra_> matching "[22:37] <robru> bfiller: 17, 14, and 10
[22:37] <bfiller> robru: nice
[22:56] <dobey> there's still no way for jenkins to build click-packaged projects without having debian/ right?
[22:57] <robru> dobey: correct, jenkins does not build click packages. If you put in a debian/ directory it'll build you a deb
[22:58] <dobey> i think jenkins does build click packages
[22:58] <dobey> https://jenkins.qa.ubuntu.com/job/generic-click-builder-vivid-armhf/12/?
[22:58] <dobey> at least, that looks like a click package to me
[22:58] <dobey> but it looks like in the console output, that it's using dpkg stuff to install the necessary dependencies, to build the thing
[23:53] <rsalveti> robru: hey, line 51 is not reflecting the reality in there