[01:38] <kgunn> fginther: are you on?...we've had some MP's on our dev-branch ci trying to land for ~10hrs, just need someone to help unstick that
[02:04] <imgbot> [02:22] <sergiusens> robru: hey, can I get a silo for line 35?
[02:40] <sergiusens> robru: same for line 36 please
[02:40] <sergiusens> or cyphermox :-) ^^
[03:08] <robru> sergiusens, hey, sure
[03:10] <robru> sergiusens, ok, you got 1 and 6 ;-)
[03:29] <imgbot> [03:29] <imgbot> [03:50] <Mirv> good morning once again
[06:18] <ToyKeeper> ... still no silos apparently ready for QA.  Two are close, but one says it's waiting on a bugfix from jhodapp, and the other says it's waiting on a test plan.
[06:19] <didrocks> ToyKeeper: hey, you mean, line 16?
[06:19] <didrocks> (not sure if it's waiting on jhodapp or missing test plan)
[06:19] <ToyKeeper> Lines 11 and 16.
[06:19] <didrocks> yeah, which one is waiting on a test plan?
[06:20] <ToyKeeper> didrocks: Line 16 -- test plan, line 11 -- bugfix.
[06:21] <didrocks> ok, thanks for looking!
[06:21] <didrocks> saw that you set that in the comment
[06:21] <ToyKeeper> I just moved om26er's comment over, because yesterday's delay has been fixed and isn't relevant any more.
[06:21] <didrocks> ok
[06:22] <ToyKeeper> I'm not really sure what om26er did with it today though; he didn't put anything in the log we've been using to sync with each other.
[06:23] <didrocks> I can't really tell you as well. Maybe send him an email so that you get more details tomorrow?
[06:29] <Mirv> didrocks: it seems sil2100's appmenu-qt5 got rejected from the queue, do you know what we should do with the landing in this situation?
[06:29] <Mirv> the train says it's in no space or time because of that
[06:32] <didrocks> Mirv: if sil2100 wants to add a new MP, he can add it, reconfigure, and rebuild
[06:32] <didrocks> Mirv: if he wants to abandon the silo, we can m&c "only free silo"
[06:32] <Mirv> ok, I'll ask him when he's here
[06:32] <didrocks> thanks!
[06:33] <didrocks> Mirv: yeah, I designed the train for this sort of things ;)
[06:33] <didrocks> you can either always iterate
[06:33] <didrocks> or abandon
[06:33] <didrocks> (hence the dangerous "m&c ignore package not in destination")
[06:34] <Mirv> right
[07:07] <sil2100> Mirv: hi! Do you maybe know why my appmenu-qt5 release landed in the rejected queue?
[07:08] <Mirv> sil2100: hi, I noticed it's in there, but I did not find discussion linked to the rejection from the release channel
[07:10] <sil2100> Mirv: thanks, will try to ask around
[07:10] <Mirv> sil2100: I tried to think of means to have some additional info from some logs or such, but at least I don't remember now
[07:10] <Mirv> if a package is deleted, then there's an explanation on the LP
[07:17] <sil2100> I wonder what could have been wrong with it
[07:22] <sil2100> Too bad it doesn't say anything about who did the rejection
[07:22] <sil2100> At least I would know who I should wait for
[07:26] <Mirv> sil2100: I believe you'll get an answer to your query at some point today
[07:26] <Mirv> they tend to follow the release channel's discussion closely
[07:32] <asac> o/
[07:35] <sil2100> hm, two failures on dialer-app, that's something new
[07:36] <sil2100> Let me take a look at that
[07:36] <Mirv> sil2100: it's diaper-app now
[07:36] <sil2100> ;p ?
[07:37] <Mirv> sil2100: see mailing list, there was a typoed message :)
[07:38] <sil2100> Ahah, from Julien - now I see it ;)
[07:54] <didrocks> I need to send to jibel a dell Canonical laptop. Going to the post office (quite urgent)
[07:55] <didrocks> I should be back on time for the meeting
[07:55] <sil2100> Ok, good luck
[07:55] <sil2100> o/
[07:55] <didrocks> thanks ;)
[07:59]  * Mirv dist-upgraded one machine from precise to trusty
[08:02] <dbarth> good morning
[08:02] <dbarth> o/ silo 004 ready to land
[08:02] <dbarth> seb128: i think the branch fixes the crasher for updates ^^
[08:03] <seb128> dbarth, great, thanks
[08:06] <dpm> hi vila, would it be possible to retrigger Jenkins for https://code.launchpad.net/~popey/dropping-letters/fix-1288885/+merge/210179 ? I believe Francis dropped the raring test that's failing, as we're no longer using it
[08:06] <vila> dpm: do you have the corresponding jenkins job url ?
[08:07] <dpm> vila, is that the one in the last comment? I.e. http://<IP_ADDRESS>:8080/job/dropping-letters-autolanding/9/ ?
[08:07] <vila> dpm: should be, let me look
[08:08] <dpm> cool, thanks
[08:08] <sil2100> dbarth: will have a look, thanks o/
[08:09] <vila> dpm: the raring job is still there AFAICS
[08:09] <vila> dpm: did fginther told you he will drop it and didn't have time for that ?
[08:10] <dpm> vila, ok, nevermind then, thanks. I'll have a chat about removing it when fginther is back online :)
[08:10] <vila> dpm: I'm not really familiar on how these jobs are handled, the description says it's generated
[08:11] <dpm> I think it should be ok to drop it, as we're not really supporting raring in the core apps PPA anymore
[08:11] <vila> dpm: ack, thanks, we're documenting that kind of stuff as we go to allow vanguard to act as backups, let me check if I can find something about that
[08:12] <dpm> cool, thanks vila. Let me know if there is anything I can help with regarding documenting anything related to core apps
[08:13] <vila> dpm: nope, nothing in the playbook, well, ask fginther to document what it needs to do for your case and that should help ;)
[08:15] <vila> dpm: what I *can* do right now is modifying the job in jenkins (changes will be lost/validated when fginther do his magic) so we can run it this morning ?
[08:15] <dpm> vila, that'd be good, thanks
[08:15] <asac> sil2100: figured dialer?
[08:16] <ogra_> anything new about dialer ?
[08:16] <asac> ogra_: tests fail?
[08:16] <ogra_> still has two errors
[08:16] <ogra_> sure, since quite a while
[08:16] <asac> ah
[08:16] <asac> 09:35 < sil2100> hm, two failures on dialer-app, that's something new
[08:16] <asac> 09:36 < sil2100> Let me take a look at that
[08:17] <asac> thats what i was looking at
[08:17] <ogra_> nah, unless they are suddenly different ones :)
[08:17] <asac> guess those are the flaky ones didrocks is complaining about
[08:17] <ogra_> these are the failures that didrocks mentioned in his mail ... happen in the infra but arent reproducable at home
[08:18] <asac> sigh
[08:18] <didrocks> back
[08:18] <ogra_> front
[08:18] <vila> dpm: done, track http://<IP_ADDRESS>:8080/job/dropping-letters-autolanding/10/ and let me and fginther know
[08:18] <asac> where are we with aligning infra with local tooling? whats still different?
[08:19] <didrocks> :p
[08:19] <asac> middle
[08:19] <asac> hehe
[08:19] <didrocks> tssss ;)
[08:19] <asac> top
[08:19] <asac> :P
[08:19] <asac> lol
[08:19] <ogra_> asac, not sure, but ofono-phonesim-autostart has always been a little fragile
[08:20] <ogra_> especially if you already have a SIM (like the phones in the lab)
[08:20] <ogra_> (though i dont want to blame it right away)
[08:20] <sil2100> ogra_: usually only one test was failing, it all seems to be flakyness related to the same thing
[08:21] <sil2100> First test run on my local devices passed normally...
[08:21] <ogra_> in any case, diealer and messaging both use phonesim ... which adds extra variables (do you have a sim or not etc)
[08:21] <ogra_> (does the test pick the emulated or the real SIM ...)
[08:22] <vila> dpm: that was fast... and green. Success ?
[08:22] <sil2100> ogra_: I think it picks up the emulated one, I guess? But yeah, there might be indeed differences as I have a sim-card present at all times
[08:23] <ogra_> sil2100, well, we have dual SIM support now ...
[08:23] <ogra_> and for the callback test AP dails 119 for example ... then phonesim simulates an incoming call
[08:24] <ogra_> if it dials with the real SIM there wont be coming a call back
[08:24] <dpm> vila, the executed test runs show SUCCESS, but there is a FAILED: autolanding message that I'm not too sure about -> https://code.launchpad.net/~popey/dropping-letters/fix-1288885/+merge/210179/comments/512946
[08:24] <Laney> ev: Can you see if<EMAIL_ADDRESS>gets mail from Launchpad when uploads are rejected from the queue please?
[08:27] <vila> dpm: hmm, me neither :-/ I tried to copy some parameters from the previous job, some may need more adjustments. But given the changes I made to the job, may be the easiest is to top-approve again to resume the normal workflow ?
[08:28] <vila> dpm: the worrying part is that 'Approved revid is not set in launchpad. ' which is obscure to me
[08:28] <dpm> vila, this one was never top-approved, but I can do it if that helps. Yes, I've no idea what that means either
[08:29] <vila> dpm: never top-approved ? The mystery thickens...
[08:29] <sil2100> psivaa: do you know if the devices in the lab have SIM cards in them?
[08:29] <vila> dpm: is that yet another workflow ? I thought top-approving was what triggered the autolanding >-/
[08:30] <dpm> oh, wait, let me have a look. I think I never did, but perhaps someone else did
[08:31] <psivaa> sil2100: mako devices should have iirc. needs confirmation though
[08:31] <popey> dpm: vila did I break dropping letters?
[08:32] <didrocks> popey: sil2100: coming?
[08:32] <dpm> popey, I don't think so, we're just trying to figure things out. Did you top-approve the MP?
[08:32] <vila> dpm: great, popey feels he's responsible ! ;) We're done \o/
[08:33] <popey> hah
[08:33] <popey> ignore me ☻
[08:33] <vila> popey: kidding, what dpm said of course ;)
[08:39] <didrocks> Saviq: mind looking at this flaky test: http://ci.ubuntu.com/smokeng/trusty/touch/mako/298:20140415.2:20140411.3/7758/unity8/1035719/ ?
[08:40] <Saviq> didrocks, it failed to drag down the indicators, first time we've seen that, will have a look
[08:40] <Saviq> didrocks, is this the first time you've seen that?
[08:51] <didrocks> dbarth: can you pease add to your testing plan the new cases?
[08:51] <didrocks> Saviq: yeah, as well
[08:51] <didrocks> for the crasher
[08:52] <Saviq> unity8 in silo 008 ready for QA sign off (nothing major, but a lot of branches)
[08:55] <ogra_> Saviq, is the indicator startup reordering in that one ?
[08:55] <Saviq> ogra_, yes
[08:55] <ogra_> oooh !
[08:55] <ogra_> someone land it immediately !!!
[08:55] <ogra_> :P
[08:56] <zsombi> guys, do we have different JS engines running on different HW architectures?
[08:57] <zsombi> yesterday we've been facing some weird issues on arm64 builds, now we're getting warnings on wait() JS function on powerpc... https://launchpadlibrarian.net/172924234/buildlog_ubuntu-trusty-powerpc.ubuntu-ui-toolkit_0.1.46%2B14.04.20140416-0ubuntu1_FAILEDTOBUILD.txt.gz
[08:59] <zsombi> ogra_ didrocks: anybody... ^
[09:00] <dbarth> didrocks: i think they should go on system-settings/update, the code was calling a null object
[09:00] <dbarth> seb128: ^^
[09:01] <seb128> dbarth, the issue was not only visible on settings/update, the update-manager app had similar problems
[09:02] <dbarth> hmm, then we're not fixing all of the bugs, ie there can be other parts that call a null object
[09:03] <ogra_> zsombi, you should talk to someone working with these areches like infinity or cjwatson
[09:05] <didrocks> Saviq: is there the bug fix for the perf issue?
[09:05] <didrocks> like scrolling scopes and so on
[09:05] <Saviq> didrocks, not yet
[09:06] <didrocks> Saviq: do you think you will have time for another landing before tomorrow with it?
[09:06] <Chipaca> popey: did you file a bug about [##]?
[09:06] <Saviq> didrocks, and don't expect it to be "just fixed" in the coming day
[09:06] <Chipaca> popey: (good morning, etc :) )
[09:06] <didrocks> asac: FYI ^ (if you want to prepare the meeting tonight)
[09:06] <didrocks> asac: it will mean we'll have perf regressions I guess on the "trusty" image (the one that the press will probably test with)
[09:06] <Saviq> didrocks, I will review the branch that we have already and make a landing with it
[09:07] <didrocks> asac: I wonder if we should take any unity8 version in between and the linked risks, wdyt?
[09:07] <popey> Chipaca: bug 1308145
[09:07] <Saviq> didrocks, but we traded flexibility for performance with the new dash concepts, is all
[09:07] <didrocks> Saviq: yeah, but TBH, the trade is really unbalanced, just try an older image and compare side-by-side
[09:07] <Saviq> didrocks, now we need to go back, and one by one, reduce the impact, but it's not a "ah, here's the problem, let's fix it now" thing
[09:07] <didrocks> Saviq: let's see what asac thinks about it, I'll be eager to have more opinions
[09:08] <Chipaca> popey: thanks
[09:11] <Saviq> didrocks, TBH I don't understand how things like this suddenly become so pressing, after it's been like that for a few weeks already :[
[09:11] <didrocks> Saviq: it was said to be easily fixable and not track it until a promoted image went in
[09:12] <Saviq> well, nobody asked me...
[09:12] <didrocks> Saviq: popey mentionned it a couple of times on the ML
[09:12] <Saviq> didrocks, sorry, I'm not following the whole of the ML, have plenty of things to do apart from that, obviously you know who to talk to about scopes UI
[09:13] <Saviq> and using "regression" as a keyword for everything is already rather annoying
[09:13] <didrocks> Saviq: you mean that the rendering speed is as good as it was in saucy ?
[09:13] <didrocks> or before the new scopes?
[09:14] <didrocks> Saviq: especially when we were told that the scopes were blocked by the LT for 3 weeks and was ready (while seeing the number of crashes and subsequent issues, it was not)
[09:15] <didrocks> so please don't start on that field, we accepted it to help you and we are here to help you
[09:15] <didrocks> not against you
[09:15] <didrocks> however, you have to admit that from an user perspective, this is rather annoying
[09:15] <Saviq> didrocks, no, I mean that when rewriting a whole portion of the system, you can't expect it to be more performant every time, especially when you bring as much flexibility as we did
[09:16] <didrocks> Saviq: I'm not telling you didn't do the right thing, just that I think the current effort, trying to get something that people will test in 2 days, should maybe focus on this rather than other bugs (or you can argue the other bugs are way more important and should then)
[09:17] <Saviq> didrocks, sure, it is a problem, we're on it, but it doesn't result in the phone being unusable, maybe not as pleasant
[09:17] <didrocks> Saviq: TBH, the scrolling issue doesn't seem to be a bad one, I'm more annoyed by the switching scope one as sometimes, the animation is blocked in the middle for multiple seconds
[09:17] <didrocks> yeah, not unusable, but will give bad PR
[09:18] <Saviq> didrocks, multiple seconds? that's not something I'm aware of
[09:18] <Saviq> didrocks, and as I said, we have improvements in store already, we have more on our minds, we'll get there
[09:19] <Saviq> didrocks, if 14.04 was such an important milestone, we should've stopped working on features over a month ago
[09:19] <didrocks> Saviq: I don't know TBH, I keep having contradictory info as well
[09:20] <didrocks> like I thought as you did
[09:20] <Saviq> but as far as I've been told, the traditional ubuntu deadlines don't apply to Touch as much
[09:20] <didrocks> but now, seems we want to have a release email
[09:20] <didrocks> (news from yesterday)
[09:20] <didrocks> still trying to decipher what people want
[09:20] <Saviq> eh...
[09:22] <dbarth> seb128: do you have a pointer to the system-update code branch maybe?
[09:23] <dbarth> seb128: i'm struggling to find the right project
[09:23] <seb128> dbarth, http://bazaar.launchpad.net/~system-settings-touch/ubuntu-system-settings/trunk/files/head:/plugins/system-update/
[09:26] <dbarth> seb128: ty!
[09:26] <seb128> dbarth, yw
[09:26] <asac> 11:07 < didrocks> asac: I wonder if we should take any unity8 version in between and the linked risks, wdyt?
[09:26] <asac> that suggests to go back on unity8?
[09:27] <didrocks> asac: what do you mind by "go back"
[09:27] <didrocks> asac: just that we don't have the perf enhancement which is the remaining one we track, should we continue and iterate on unity8 meanwhile, wdyt?
[09:27] <didrocks> I just want other opinions on this
[09:28] <asac> didrocks: ah asking if we should continue landing of unity8 goodies
[09:28] <didrocks> yep
[09:28] <ogra_> if it fixes issues
[09:28] <asac> right
[09:28] <didrocks> indeed
[09:28] <ogra_> (and passes testing)
[09:29] <didrocks> ogra_: it doesn't yet? I didn't see QA signing off
[09:29] <asac> the currently discussed alert levels and rules are here: https://docs.google.com/a/canonical.com/presentation/d/1FOqa6jqGEFPgJ2Ghxgkb7Cqi774IujImPHfYFEYnJgc/edit#slide=id.p
[09:29] <ogra_> right, but it will have to regardless
[09:29] <asac> what would that say?
[09:29] <asac> (thats not set in stone, so just checking what this would answer :))
[09:30] <asac> so if unity8 is the affected component it would say in TRAINCON-0:
[09:30] <asac> - isolated bugfixes with Max Velocity rules
[09:30] <didrocks>  - non-isolated bugfixes of affected components with Max Care rules
[09:30] <asac>  - non-isolated bugfixes of affected components with Max Care rules
[09:30] <asac>  - features for affected components cannot land
[09:30] <asac> though even that can be discussed
[09:30] <asac> are the unity8 fixes pending isolated?
[09:31] <asac> or non?
[09:31] <didrocks> asac: the MP between them you mean?
[09:31] <didrocks> or between components?
[09:32] <asac> isolated is not really defined i think
[09:32] <asac> i think it basically could mean two things:
[09:32] <asac> 1. the MP is only about the bug fix (e.g. nothing else is piggybacked)
[09:32] <asac> 2. the MP does not span multiple components
[09:32] <didrocks> exactly
[09:32] <didrocks> so if 2. -> it's a clear "No", and we can remove the QA double checking
[09:33] <asac> didrocks: under those rules only if the MP doesnt piggyback other stuff
[09:33] <asac> we could kill 1. from the equation
[09:33] <asac> kgunn was challenging that part
[09:34] <asac> feels its better for him to deliver more stuff
[09:34] <didrocks> asac: well, there are some code cleanup
[09:35] <ogra_> well, it brings us back in sync with fixes that are supposed to land anyway
[09:36] <ogra_> if they pass QA i think its worth getting them in to not start the U cycle with to much debt
[09:36] <didrocks> ogra_: I guess the question is do we ask QA or not. Seems from the rules asac set, it shouldn't
[09:36] <ogra_> if they dont pass we can still reject (or roll back)
[09:37] <asac> right, so if its isolated bugfix we can land without QA according the rules in there
[09:37] <ogra_> i think one day before release we should ask QA for cross checking all landings
[09:37] <ogra_> we're getting short on time and rolling back costs more
[09:37] <asac> i dont know. i kind of dont like the special case of "one day before release" :)
[09:37] <ogra_> so better test once more in advance
[09:38] <ogra_> well its simply math :) an equation between testing in advance and what it costs to roll back
[09:38] <asac> yeah in principal you are right i guess
[09:38] <asac> but... i dont know
[09:38] <ogra_> rolling back steals more of our time
[09:38] <asac> we could stop landing 1 day before release
[09:39] <asac> which mean we would be able to back out everything that causes damage in worst case
[09:39] <ogra_> well but that would have been nice to announce :)
[09:39] <ogra_> (before that last day is here)
[09:39] <asac> not good to announce that
[09:39] <asac> then people rush
[09:39] <ogra_> well
[09:39] <asac> always announce lock-downs the day after :P
[09:39] <asac> j.k.
[09:39] <ogra_> announce it 2 months before release indeed
[09:40] <asac> its gruel, but better :P
[09:40] <asac> cruel
[09:40] <ogra_> so people can plan
[09:40] <ogra_> doing it now out of the blue is bad
[09:40] <ogra_> because we trash peoples plans
[09:40] <asac> well, there is a tendency of folks to rush
[09:40] <didrocks> so… for that one?
[09:40] <didrocks> do we rely on QA or not?
[09:40] <asac> didrocks: which one are we talking exactly about?
[09:41] <didrocks> asac: line 17
[09:41] <asac> didrocks: i think if there is additional code cleanup, we can say its non-isolated and get QA :P
[09:41] <asac> until we understand it better
[09:41] <asac> so we avoid that problem
[09:41] <asac> hehe
[09:41] <didrocks> ok
[09:41] <didrocks> sounds good to me
[09:41] <asac> unless you feel its safe
[09:41] <asac> to land and backout in worst case
[09:42] <sil2100> Need to jump out to the pharmacy for a jiffy
[09:44] <didrocks> QA only has that one ready to test
[09:44] <didrocks> so can be ok
[09:44] <didrocks> asac: sounds ok? ^
[09:48] <asac> didrocks: you mean they will have time?
[09:48] <asac> sure
[09:49] <didrocks> asac: I guess om26er has, there is nothing else to double check now
[09:49] <asac> sure
[09:49] <didrocks> (or ready to be doubled check rather)
[09:49] <asac> then put them on it
[09:49] <ogra_> line 35 is safe btw
[09:50] <ogra_> (tested by multiple people in advance already)
[09:51]  * om26er downloads the latest image.
[09:55] <didrocks> ogra_: how that is? it's not built?
[09:55] <didrocks> ogra_: you merge both locally and built?
[09:56] <ogra_> didrocks, nope, just used the patches on the existing package ...
[09:57] <didrocks> ok
[10:10] <ogra_> whee ! under 29sec http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-299.png (the screen is up around 20-22)
[10:11] <popey> dpm: vila did we get a conclusion of what's wrong with https://code.launchpad.net/~popey/dropping-letters/fix-1288885/+merge/210179 ?
[10:12] <popey> "Approved revid is not set in launchpad." is obscure to me
[10:12] <vila> popey: same here, it's a tarmac thing AFAIK so top-approving may just do the right thing (I can't do that, no access rights)
[10:13] <dpm> no idea, vila, we can top-approve and try
[10:13] <popey> done
[10:13] <vila> and the approved revision appeared magically...
[10:22] <vila> dpm, popey: ... and http://<IP_ADDRESS>:8080/job/dropping-letters-autolanding/11/console running
[10:23] <om26er> didrocks, Saviq regarding the unity8 landing did anyone do the testing ?
[10:23] <om26er> with the silo in question
[10:23] <didrocks> om26er: upstream testing is done by upstream… most of the time Saviq
[10:23] <didrocks> as testing pass is set to yes, I would say they did
[10:24]  * ogra_ files bug 1308459 for cyphermox
[10:25] <Saviq> om26er, it says "Yes" to testing, so yeah, I did go through our TestPlan, did some exploratory testing and ran autopilot
[10:25] <Saviq> om26er, QA Sign-off is a secondary run
[10:25] <om26er> Saviq, ok, just wanted to make sure:)
[10:26] <didrocks> om26er: as told on the ML, you won't see the orange color if upstream didn't set "test pass" to Yes.
[10:28] <om26er> didrocks, right, I know that. I just wanted to check what level of testing was done.
[10:28] <om26er> seems pretty thorough
[10:34] <davmor2> didrocks: is it just me or have all the landing afternoon meetings vanished from the calendar?
[10:35] <didrocks> davmor2: hum, seems you're right
[10:35] <davmor2> didrocks: I see yesterdays but none for today onwards
[10:36] <didrocks> yeah, same
[10:36] <didrocks> let me reschedule it, someone probably mislead
[10:36] <dbarth> o/ line 37 with a new silo request
[10:37] <sil2100> didrocks: if I want to 're-publish' something, all I have to do is re-run publish with 'ignore_step'?
[10:37] <didrocks> hum, fail
[10:37] <didrocks> :p
[10:38] <ogra_> blame asac
[10:38] <sil2100> dbarth: will look into that ;)
[10:38] <didrocks> better ;)
[10:38] <didrocks> sil2100: you did rebuild it?
[10:38] <sil2100> didrocks: no, I just need to republish, since the rejection got rejected, and a new sync request for the same package is needed ;p
[10:38] <didrocks> sil2100: not possible without a rebuild or asking webops
[10:39] <sil2100> Ah, boo
[10:39] <didrocks> sil2100: I can fake and have a sync req. on snakefruit if needed
[10:39] <sil2100> Oh :)
[10:39] <didrocks> sil2100: well, you published it… you can republish with other components
[10:39] <didrocks> but not the same
[10:39] <didrocks> if it was rejected, they must be a reason?
[10:39] <didrocks> (and so why republish the same?)
[10:39] <sil2100> didrocks: could you do it? Pretty please? Yeah, the reason was that it introduced the gtk2.0 dep, but they didn't notice that qt5gui already has that dependency
[10:40] <didrocks> ok
[10:40] <sil2100> (due to the qgtk2 plugin which I'm emulating)
[10:40] <sil2100> So they thought it's a new dependency in overall, but it's just an extension of the status quo
[10:40] <sil2100> didrocks: thank you o/
[10:40] <didrocks> sil2100: what silo was it?
[10:41] <sil2100> 005 - it's still there if anything
[10:41] <sil2100> https://launchpad.net/~ci-train-ppa-service/+archive/landing-005/
[10:42] <didrocks> sil2100: done
[10:43] <Mirv> sil2100: nice that it got resolved!
[10:53] <sil2100> Thank you
[10:58] <asac> ogra_: w00t?
[10:58] <ogra_> ?
[10:58] <asac> i still have landing calls on mycalendar
[10:58] <asac> the afternoon one
[10:59] <ogra_> they just re-appeared
[11:00]  * didrocks readded them
[11:01] <vila> dpm, popey : and merged, so landed correct ?
[11:01] <popey> vila: yup
[11:02] <sil2100> dbarth, Laney: silo assigned o/
[11:02] <dpm> vila, yes, looks good, thanks!
[11:02] <Laney> happy daze
[11:06] <Laney> dbarth: pressing build
[11:10] <davmor2> popey: Facebook are links opening for you?
[11:12] <popey> davmor2: no
[11:12] <davmor2> didrocks: ^
[11:13] <popey> twitter works nicely now!
[11:13] <popey> scrolls properly
[11:13] <davmor2> popey: same for g+ just FB
[11:13] <didrocks> davmor2: not a regression, but dbarth would know more (they fixed twitter)
[11:14] <popey> yeah, links work in twitter
[11:20] <mhr3> didrocks, you're the one who reported slow rendering when swiping between scopes, right?
[11:21] <mhr3> didrocks, can you record a video of that pls?
[11:21] <didrocks> mhr3: yeah
[11:21] <didrocks> mhr3: hum, sure, if you can tell me how to do on phone :)
[11:21] <mhr3> didrocks, and attach to the bug
[11:21] <mhr3> didrocks, you hold a different phone on top of it :P
[11:22] <didrocks> mhr3: that's technology… :p
[11:22] <om26er> Saviq, one autopilot test failed, it does pass if I run it again though http://paste.ubuntu.com/7260904/
[11:28] <didrocks> mhr3: I got it when unlocking the greeter itself, I guess the scope cache is "hot"
[11:29] <davmor2> popey: also what happen if you let some music play beyond the screen blanking?  For me it seems to judder, stop and then carry on playing
[11:31] <ogra_> asac, seb128 isnt off, he is just hiding from -touch :P
[11:31] <didrocks> mhr3: got on small jittery
[11:31] <asac> seems he is testing somethin (lurked on -desktop)
[11:31]  * didrocks waits to transmit the videos
[11:31] <asac> seb128: hey
[11:31] <seb128> ogra_, I was restarting session to test an upgrade
[11:31] <asac> 13:28 < asac> "Only issue I observed so far is that upgrade screen shows 13.10 when actually it is downloading 14.04 trusty image. This is bit of misleading.
[11:32] <seb128> asac, hey
[11:32] <asac> "
[11:32] <ogra_> excuses
[11:32] <asac> 13:29 < asac> gatox: we tested upgrading from 13.10 to latest 14.04 image and observed the above
[11:32] <asac> seb128: ^
[11:32] <seb128> lol
[11:32] <seb128> asac, where do you see 13.10 written?
[11:32] <asac> any idea if we need to change something?
[11:32] <asac> seb128: i think in the upgrade dialog
[11:32] <asac> seb128: i will loop u into the thread
[11:34] <didrocks> mhr3: waiting on google to upload the video…
[11:35] <gatox> asac, is that in system settings?
[11:36] <asac> gatox: are there other ways to upgrade?
[11:36] <asac> i am really confident he used the UI
[11:36] <asac> for that test
[11:36] <gatox> asac, if it's related to that, maybe you should talk with barry, he is the one that made the update daemon, and the daemon is sending the strings to show
[11:37] <popey> davmor2: testing
[11:38] <popey> davmor2: nope, didnt happen here.
[11:39] <popey> davmor2: only had music open after clean boot though, no other apps
[11:39] <davmor2> popey: yeah it's not for me now I wonder if it was just something else in the background
[11:40] <popey> yeah, probably
[11:44] <asac> mandel: ^^
[11:45] <asac> mandel: we tested upgrading from 13.10 to latest devel
[11:45] <asac> mandel: 13:31 < asac> 13:28 < asac> "Only issue I observed so far is that upgrade screen shows 13.10 when actually it is downloading 14.04 trusty image. This is bit of misleading.
[11:45] <asac> mandel: 13:36 < gatox> asac, if it's related to that, maybe you should talk with barry, he is the one that made the update daemon, and the daemon is sending the strings to show
[11:45] <asac> mandel: can you check if there is something on the daemon we would have to do?
[11:45] <seb128> asac, ogra_, mandel: the string is coming from the service
[11:45] <asac> i assume the bug is already in 13.10 image
[11:45] <seb128> right, likely
[11:45] <asac> so we can only fix it so that next upgrade will be good, but surely should be done now
[11:45] <ogra_> seb128, which one ? locally ?
[11:46] <asac> so we dont have the same next time we ship stable :P
[11:46] <asac> ogra_: yeah, the one barry and mandel are doing
[11:46] <ogra_> right
[11:46] <gatox> asac, that is not coming from the download manager daemon, but from the update dbus daemon
[11:46] <ogra_> just wanted to be sure he doesnt mean the server
[11:46] <asac> right
[11:46] <asac> imo that info should come from server :)
[11:46] <ogra_> asac, i bet it just reads from /etc/system-image/channel.ini
[11:46] <gatox> asac, system settings doesn't talk directly to the ubuntu download manager for image upgrade
[11:46] <asac> thats they only way to really not have to update before you can fix it :)
[11:46] <asac> ogra_: but that feels wrong approach
[11:47] <asac> ogra_: if you download an upgrade the version etc. displayed before you do the upgrade or during needs to come from server somehow
[11:47] <asac> agreed?
[11:47] <ogra_> asac, ah, no, that info isnt in there
[11:47] <asac> well lets wait for mandel and barry check
[11:47] <asac> mandel: can you check what exactly is done now?
[11:47] <asac> :)
[11:47] <ogra_> yeah
[11:47] <asac> thanks
[11:48] <asac> did the crash get fixed for syustem settings?
[11:48] <asac> the one rick had yesterday?
[11:48] <asac> dbarth: ?
[11:48] <asac> can we please test the hell out of this?
[11:48] <asac> we MUST NOT have any chance that updates dont work
[11:48] <seb128> asac, it's supposed to be fixed
[11:48] <asac> in all cases
[11:48] <asac> so all condititions need to be stressed
[11:49] <asac> if you dont have anything else to deliver for release, just sit down and test test test all cases you can imagine :)
[11:49] <asac> hehe
[11:49] <asac> dbarth: ^
[11:50] <asac> seb128: who fixed it?
[11:50] <asac> would like to also get him the message above directly :)
[11:50] <asac> mardy: ^^
[11:50] <asac> it was you i guess
[11:51] <seb128> asac, mardy
[11:52] <dbarth> what's up
[11:52] <dbarth> (back from lunch, easy please)
[11:52] <seb128> asac, in fact https://launchpad.net/ubuntu/+source/ubuntuone-credentials/14.04+14.04.20140415
[11:52] <seb128> so alecu
[11:53] <seb128> asac, not sure anyone was able to reproduce rick's issue to confirm the fix works for that one as well though
[11:53] <asac> dbarth: read the 15 lines above :)
[11:53] <dbarth> asac: so yes, i think the crash is fixed, i landed a fix this morning, and try to retrigger the crash in various conditions
[11:54] <asac> dbarth: right. on top try everything to break it; taer down networking while updating, unmount disk
[11:54] <asac> remove file while download happens :)
[11:54] <asac> etc.
[11:54] <dbarth> inspected the code also of the update-manager plugin and i don't hink it can bypass the fix anymore
[11:54] <asac> powercyucle in the middle
[11:54] <asac> etc.
[11:54] <asac> we have to work on big upgrade testing next
[11:55] <mardy> asac, seb128: no I didn't fix it, it was alecu: https://code.launchpad.net/~alecu/ubuntuone-credentials/missing-identity/+merge/215903
[11:56] <seb128> mardy, yeah, I corrected my statement if you read the backlog ;-)
[11:56] <mardy> seb128: oops, right :-)
[11:56] <asac> alecu: ^ read the log starting :47
[11:56] <asac> as well. thx
[11:58] <didrocks> mhr3: 2 videos (tried to keep them short) attached to the bug report
[11:59] <mhr3> didrocks, thanks!
[11:59] <didrocks> yw
[12:00] <Saviq> om26er, right, we get this sometimes
[12:01] <Saviq> om26er, basically means ap failed to connect with unity8
[12:01] <om26er> Saviq, hmm, so I figured the problem is here http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/tests/autopilot/unity8/process_helpers.py#L92
[12:01] <om26er> it fails to turn on the screen sometimes with evdev
[12:01] <om26er> so if at that moment i press the power button by hand that can result in the test success
[12:02] <om26er> Saviq, I had a crash which I am trying to report but seems its not reporting to launchpad, do you want the .crash file ?
[12:02] <om26er> well I am not sure if its new or old unless we can retrace it
[12:03] <Saviq> om26er, please, yes, send it up somewhere for me
[12:03] <Saviq> om26er, pre-process it with apport-cli first, please
[12:04] <alecu> hi asac: was my fix added to the phone image? should I test that?
[12:13] <sergiusens> sil2100: Mirv can we publish silo 1?
[12:14] <davmor2> didrocks, popey: so it seems dbarth and co are aware of the FB issue and a possible fix is on route, /me crosses fingers.
[12:15] <didrocks> davmor2: ok, but not a regression right?
[12:15] <didrocks> we had it for a while
[12:15] <dbarth> didrocks: there is a regression in fact
[12:15] <didrocks> dbarth: him, since when?
[12:15] <dbarth> didrocks: due to various factors, but it was working in twitter and FB for certain links
[12:15] <didrocks> ah
[12:15] <dbarth> but here we have most links broken
[12:16] <dbarth> i'm testing the new oxide build that should fix that
[12:16] <didrocks> dbarth: ok, do you know when the issue started to occur?
[12:16] <dbarth> hope we won't have to revert things
[12:16] <dbarth> ~2 days ago
[12:16] <dbarth> but affecting desktop as well
[12:16] <didrocks> dbarth: so, latest promoted image got it?
[12:16] <didrocks> seems a good candidate for -updates
[12:17] <didrocks> davmor2: mind double checking? ^
[12:17] <dbarth> didrocks: what's the promoted #? please i can check that real quick
[12:17] <didrocks> or popey, who has it? ^
[12:17] <didrocks> dbarth: #296
[12:17] <dbarth> ok
[12:17] <didrocks> we didn't get a new oxide update in between
[12:17] <didrocks> dbarth: also, please a bug ref :)
[12:17] <asac> alecu: test the latest image, test the hell out of it
[12:17] <didrocks> and add that as part of your testing plan
[12:17] <asac> all kind of nasty things etc. :)
[12:18] <asac> at least i would think thats indicated given how bad a broken updater is
[12:18] <davmor2> didrocks: I can test it but it will be after I take wife to visit mother-in-law at the hospice.
[12:18] <asac> alecu: check if your fix is in
[12:18] <asac> i dont know
[12:18] <dbarth> https://bugs.launchpad.net/webbrowser-app/+bug/1307735
[12:18] <didrocks> davmor2: sure! did you finish your dogfooding?
[12:18] <didrocks> davmor2: before you get there
[12:18] <didrocks> thanks dbarth, keep us posted
[12:18] <alecu> asac: ack
[12:18] <didrocks> sil2100: Mirv: FYI ^
[12:19] <ogra_> alecu, http://people.canonical.com/~ogra/touch-image-stats/299.changes
[12:20] <Mirv> sergiusens: I think so, yes. in a bit.
[12:20] <dbarth> didrocks: yup; that's on the blocker list for me
[12:20] <davmor2> didrocks: yes so that was the last thing I was looking at before I post my findings, on the whole the image is feeling pretty sound.  I'm assuming though that there will be an image spin today for the QT bug right?
[12:21] <didrocks> davmor2: I doubt about it
[12:21] <didrocks> davmor2: so, for promoting, this would be a +1?
[12:21] <didrocks> (compared to previous promoted one)
[12:23] <davmor2> didrocks: yeah it's pretty stable, not perfect but usable daily :)
[12:23] <didrocks> davmor2: thanks for the feedback!
[12:25] <popey> didrocks: hmm? facebook links broken in latest devel and devel-proposed alike
[12:26] <didrocks> popey: yeah, we agree then
[12:26] <davmor2> popey: thanks dude save me having to reinstall it :)
[12:27] <om26er> Saviq, http://ubuntuone.com/03OJoMWsj85IZ6yjh8eflO
[12:28] <om26er> "and then they said UbuntuOne is sunsetting"
[12:28] <Saviq> om26er, thanks
[12:28] <Saviq> om26er, looks like I'll be backing out that landing - per the two issues you noticed - thanks about those
[12:30]  * sil2100 has a bad kitchen day
[12:30] <sil2100> Mirv: I'll take care of silo 001 then...
[12:30] <om26er> sil2100, pressure cooker hit the ceiling ?
[12:30] <om26er> ;)
[12:30] <didrocks> sil2100: did you get anywhere on the dialer-app AP test failure?
[12:30] <om26er> Saviq, glad to help :)
[12:30] <didrocks> (maybe 1st a bug report? ;))
[12:33] <sil2100> didrocks: the previous bug report wasn't really closed, should I fill a new one? Or just update the existing one? I tried the tests with my sim-card removed
[12:33] <Mirv> sil2100: just did it!
[12:33] <didrocks> sil2100: it's not the same than previous one, right?
[12:33] <sil2100> Oh, and it doesn't seem that the number is the problem here as well
[12:33] <didrocks> sil2100: so you think that it's just a flaky test and busted ogra's theory?
[12:34] <ogra_> *sniff*
[12:34] <sil2100> didrocks: it seems to be the same thing... since test_outgoing_answer_local_hangup gets the same DBus error as in the bug report I filled
[12:35] <didrocks> sil2100: ok, so please update the other one
[12:35] <sil2100> Since the number is made specifically for the emulator, serving a given purpose - like, hangup after x seconds etc.
[12:36] <sil2100> ACK :)
[12:36] <sil2100> om26er: almost, spilled oil all over the kitchen
[12:36] <alecu> asac: I've tested #299, and the bug is not fixed there. I'm looking at the list of changes that ogra pasted, and a few versions back, and the changed package is not there either.
[12:37] <sil2100> While carrying the deep fryer I spilled most of it
[12:37] <om26er> sil2100, uhh :/
[12:37] <alecu> asac: are we talking about the same bug? https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1307608
[12:37] <asac> alecu: we are talkinga bout system update crash
[12:38] <asac> dbarth: ^^
[12:38] <asac> can you help him?
[12:38] <om26er> sil2100, btw regarding dialer-app i peaked at it yesterday (just peaked) so the issue is with fake incoming call thing, maybe another way to create a fake call needs to be created
[12:38] <asac> alecu: system setting crashing because of signon
[12:38] <asac> bug
[12:38] <asac> from yesterday
[12:38] <asac> didrocks: do you have the bug?
[12:38] <didrocks> asac: never got it
[12:38] <asac> seb128: ^^ seems alecu doesnt know what we are talking about
[12:38] <asac> can you help
[12:38] <didrocks> (popey neither)
[12:39] <didrocks> and I didn't hear dave mentionning it
[12:39] <didrocks> so, only rick & jason AFAIK
[12:39] <asac> didrocks: no. what was the bug id
[12:39] <asac> alecu seems to not remember :)
[12:39] <didrocks> ah :)
[12:39] <didrocks> sure, can find it, one sec
[12:40] <didrocks> it's the one alecu linked to
[12:40] <didrocks> bug #1307608
[12:40] <asac> ok
[12:40] <ogra_> asac, alecu  asked you if his changes were in the latest image ... and you aswered he should test latest :) ... you are mixing up things
[12:40] <asac> ogra_: i asked him to find out
[12:40] <ogra_> right
[12:40] <asac> the engineers should be able to track if their patch landed etc.
[12:40] <ogra_> but it wasnt about the update issue
[12:41] <asac> the bug above ttalksa bout install button
[12:41] <asac> but not about crash
[12:41] <asac> really weird bug summary tbh
[12:41] <didrocks> asac: the same line from dbarth mention https://bugs.launchpad.net/ubuntu/+source/signon/+bug/1308164
[12:41] <alecu> asac: the bug above is about click-scope crashing because libubuntuonecredentials was passing a NULL to signon
[12:41] <didrocks> which should be a private bug I guess
[12:41] <asac> ogra_: i want that alecu dbarth and everyone involved in system updates test the hell out of this and ensure we dont have other issues
[12:41] <didrocks> but not linked to the branch (the other bug # is linked to the branch)
[12:42] <ogra_> asac, sure
[12:42] <asac> that can't be so hard to interpret right
[12:42] <didrocks> asac: this ubuntuone-credentials have been accepted this morning
[12:42] <didrocks> so it's not in any image
[12:42] <asac> didrocks: i dont want to know really :)
[12:42] <didrocks> hum?
[12:42] <asac> i want to ensure that dbarth and alecu verify that their fix fixes things and test the rest of the day
[12:42] <asac> :)
[12:43] <ogra_> didnt we have enough uploads to actually justify an image build again ?
[12:43] <didrocks> but if it's not in any image
[12:43] <asac> well
[12:43] <didrocks> how can they test it?
[12:43] <ogra_> or do we want to hold back for the magic 300
[12:43] <didrocks> seems like you want to know
[12:43] <asac> they must have ways to install it to est it?
[12:43] <didrocks> sure, they can turn in rw mode
[12:43] <didrocks> and install the package
[12:43] <didrocks> ogra_: well, forget about magic 300 as told this morning :p
[12:43] <didrocks> we won't get it
[12:43] <ogra_> :)
[12:43] <alecu> asac: I want to do testing, it sounds reasonable. But I'd like to know what I need to be checking, and that bug is about click scope and signon, not about system updates like you mentioned
[12:44] <ogra_> didrocks, well, if we dont wait for any specific landings we should probably roll one now and one later in the day
[12:44] <asac> alecu: its not good if i micro explain what you need to do. dbarth said "he thinks its fixed" but doesnt know
[12:44] <didrocks> ogra_: yeah, I would like to have this unity8 acked by QA and landed
[12:44] <asac> so i think that there can be do more
[12:44] <asac> test test test
[12:44] <asac> ensure that there is an image with it etc.
[12:44] <asac> if you need that
[12:44] <ogra_> didrocks, oh, i thought that was just NACKed above by om26er
[12:44] <didrocks> ogra_: oh, I didn't see that?
[12:44] <asac> if you dont thats also fine; but i dont know if you need
[12:44] <didrocks> om26er: ?
[12:45] <ogra_> Saviq, ^^
[12:45] <asac> if i was asked to do that, i would take the latest image, install whatever will be in next image and start testing all kind of crazy things
[12:45] <asac> all day long
[12:45] <seb128> didrocks, ogra_: 14:28 in the backlog
 om26er, thanks
[12:45] <seb128>  om26er, looks like I'll be backing out that landing - per the two issues you noticed - thanks about those
[12:45] <asac> if i feel that i need a fresh image with the change i would ask didrocks to spin the image now
[12:45] <om26er> didrocks, it introduced new bugs, and maybe a crash as well
[12:45] <dbarth> didrocks: the bug is in the promoted image
[12:45] <didrocks> asac: actually, I would go on image -2 to get an update prompt
[12:45] <didrocks> but again, I shouldn't get into this as well :)
[12:46] <asac> i dont know
[12:46] <asac> if our engineering team doesnt even know how to test system updates
[12:46] <asac> its too late
[12:46] <didrocks> om26er: ah ok, please turn upstream testing done to no and add a comment
[12:46] <asac> to invent it now; but i really really hoped this wasnt the case
[12:46] <didrocks> asac: seems it was a good pick to get unity8 tested btw ^
[12:46] <Mirv> sil2100: I first read "almost spilled oil all over the kitched" and thought "well that doesn't sound too bad", but then I noticed the ", " in there
[12:46] <asac> what surely ain't right is sitting back and doing nothing :)
[12:47] <sil2100> ;)
[12:47] <asac> didrocks: kk
[12:47] <sil2100> Everything is still slippery as hell
[12:47] <om26er> didrocks, ok, done
[12:47] <didrocks> om26er: thanks :)
[12:48] <sil2100> Ah, I have an idea on how to enhance the test a bit
[12:48] <asac> dbarth: alecu: so do you guys know how to test system updates?
[12:50] <dbarth> asac: no, i didn't found a test plan, so i did that:
[12:50] <dbarth> re-create u1 account -> system-settings -> update
[12:50] <sergiusens> Mirv: sil2100 silo 6 is already ready for landing
[12:50] <dbarth> deleted account -> same
[12:50] <asac> dbarth: dont tell me; talk to alecu and figure out how to stress things
[12:50] <dbarth> disabled account -> same
[12:50] <dbarth> i couldn't trigger a crash
[12:50] <alecu> dbarth: what image are you using for this?
[12:51] <dbarth> who's in charge of system-updates UI?
[12:51] <dbarth> trusty-proposed
[12:51] <asac> dbarth: seb?
[12:51] <Mirv> sergiusens: sil2100: alright
[12:51] <alecu> dbarth: is there a bug for this?
[12:52] <sil2100> Mirv: are you checking that one?
[12:52] <om26er> mandel, the u-d-m silo has a problem, system-image-cli gives http://paste.ubuntu.com/7261293/
[12:52] <asac> seb128: can you drive this?
[12:52] <dbarth> alecu: yes
[12:52] <Mirv> sil2100: yes
[12:52] <asac> seb128: you seem to own the top level entry point for system updates and someone needs to drive that this thing gets tested to death
[12:53] <sil2100> Archiving landings
[12:53] <asac> seb128: i dont know whoelse could own it
[12:53] <asac> seb128: you have dbarth alecu mandel barry at your command on this i guess
[12:53] <dbarth> alecu: https://bugs.launchpad.net/ubuntu/+source/signon/+bug/1308164
[12:53] <dbarth> uh
[12:53] <dbarth> private
[12:54] <seb128> asac, I would prefer if somebody else would own it, things are busy on the desktop side with the LTS release this week
[12:54] <dbarth> alecu: you're subscribed now
[12:54] <alecu> dbarth: thanks
[12:54] <seb128> asac, gatox wrote the panel
[12:54] <Mirv> sergiusens: also that one (like 001) published
[12:54] <seb128> so somebody between gatox alecu barry and dbarth would be good
[12:54] <dbarth> seb128: is gatox around yet?
[12:54] <seb128> dbarth, no idea
[12:54] <seb128> he should
[12:54] <dbarth> right, i wanted his opinion on the code i read today
[12:55] <gatox> here
[12:55] <sergiusens> Mirv: thanks; will continue on more bug fixes now
[12:55] <asac> seb128: well, you can delegate
[12:55] <alecu> dbarth: great, thanks. Only now I can see how my unrelated fix can solve this.
[12:56] <Mirv> nice that indicator-datetime is in -proposed now
[12:56] <alecu> dbarth: and now I know how to test this.
[12:56] <seb128> asac, ok
[12:56] <asac> seb128: i need someone to own it who has good ties into all teams into UE
[12:56] <asac> yuou can delegate and supervise
[12:56] <seb128> asac, alright, I can do that
[12:57] <seb128> dbarth, let me know if you get the infos you need from gatox or if you need more details from me
[12:57] <alecu> dbarth: the steps to reproduce are in the related ubuntuone-credentials bug
[12:57] <dbarth> just pinged me, shared bug and code comments
[12:58] <dbarth> seb128: ^^
[12:58] <alecu> dbarth: "enter user name, then enter wrong password ....without correcting..." is the key part
[12:59] <seb128> dbarth, alecu: the segfault Rick was getting would happen when trying to open the software update app or the system settings update panel, deleting/adding back his u1 account fixed it
[12:59] <alecu> seb128: right
[12:59] <seb128> not sure how to similate a buggy u1 state though
[12:59] <seb128> simulate*
[12:59] <alecu> seb128:  "enter user name, then enter wrong password ....without correcting..." is the key part
[12:59] <seb128> could be that maybe changing the password on the server would do it or something
[12:59] <seb128> k
[12:59] <seb128> dbarth said it wouldn't segfault for him though
[12:59] <alecu> seb128: it's explained in the steps of the related bug: https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1307608
[13:00] <seb128> alecu, that bug says it leads to a wrong button, not to a segfault though, what's the difference in state between those 2 outcomes?
[13:00] <alecu> that was the bug I fixed, I did not know it affected system updates too
[13:01] <seb128> it seems it did
[13:01] <seb128> alecu,  see https://bugs.launchpad.net/ubuntu/+source/signon/+bug/1308164
[13:01] <alecu> seb128: it's the same bug in ubuntuone-credentials affecting both the click scope and system updates
[13:01] <seb128> k
[13:01] <dbarth> right, cause some subsequent code was dereferencing a null pointer
[13:01] <seb128> so it should be possible to confirm the issue on the current image
[13:01] <alecu> seb128: yes, I saw that 5 minutes ago :-)
[13:01] <seb128> then update ubuntuone-credentials
[13:01] <seb128> then confirm the fix
[13:01] <alecu> seb128: good point, I'll check that.
[13:02] <dbarth> seb128: that's what i did this morning, but double checking won't hurt
[13:02] <dbarth> ;)
[13:10] <dbarth> seb128, alecu: gatox confirmed that the patch for the null token is effectively leading the code path to the right signal
[13:10] <dbarth> where as previously it was bypassing thta and ran into that null pointer de-ref issue rick experienced yesterday
[13:10] <seb128> dbarth, great
[13:10] <seb128> asac, ^
[13:11] <seb128> dbarth, thanks for testing/confirming
[13:11] <dbarth> he will comment on the bug with his code audit observations
[13:13] <didrocks> ogra_: as no unity8 is in pipe, wdyt about kicking an image now?
[13:13] <ogra_> yeah
[13:13] <didrocks> depends on the ETA on the facebook fix, maybe?
[13:13] <didrocks> dbarth: ^
[13:14] <asac> after we have validated that this bug is fixed, we want to test the rest of the day
[13:14] <asac> all kind of weird things
[13:15] <didrocks> asac: is that for the webapps links issue?
[13:15] <asac> no for system-updates
[13:15] <asac> i am always on system-updates :)
[13:15] <didrocks> you are lucky to only have this one to track ;)
[13:19] <didrocks> dbarth: keep us posted, if when I'm back, we don't have a fix, I'll suggest that we go back to a working webbrowser-app for links
[13:19] <didrocks> (~1h30)
[13:19] <imgbot> [13:19] <seb128> same as didrocks
[13:20] <seb128> time for some exercice here
[13:20] <didrocks> ogra_: ? we did want to know about webbrowser beforehand? ^
[13:20] <didrocks> anyway… let's see
[13:20] <dbarth> didrocks: +1, trying to figure out the fastest path back to green
[13:21] <ogra_> didrocks, ah, dang ... i understood you wanted one and was busy in the other window when you discussed webbrowser
[13:22] <didrocks> ogra_: well, no worry, seems it's not there yet anyway ^
[13:22] <ogra_> right, but we'll step on our toes wrt testing
[13:22] <didrocks> ogra_: yeah…
[13:26] <alecu> seb128: dbarth: asac: I can confirm that updating libubuntuoneauth-2.0-0 on mako solves the issue in system updates
[13:26] <seb128> alecu, thanks
[13:26] <alecu> I've tested #299: it breaks; I install that lib, it gets fixed
[13:27] <mandel> om26er, looking
[13:27] <asac> awesome! thanks alecu
[13:27] <alecu> didrocks: asac: if you spin a new image, let me know and I'll test it
[13:27] <mandel> seb128, can you give me some info about what is going on with upgrades?
[13:27] <asac> alecu: the image has started afaics
[13:27] <asac> 15:19 < imgbot> [13:28] <alecu> great
[13:28] <seb128> mandel, you mean?
[13:29] <mandel> om26er, hm.. looks like the service is not starting yet the click scope works, I'm taking a look
[13:30] <asac> rsalveti: so media-hub is waiting for qa sign off? do we wnt to try ?
[13:31] <mandel> seb128, no worries, I saw om26er message, looks like the daemon is not started on the system bus, looking into it
[13:31] <seb128> mandel, ok, let me know if I can help with something
[13:31] <mandel> seb128, I mentined you because I read => <asac> 12:53:32> seb128: you have dbarth alecu mandel barry at your command on this i guess
[13:31] <mandel> seb128, I'm on it, I know how to fix it :
[13:31] <mandel> :)
[13:32] <rsalveti> asac: there's still one blocker to solve, and finish the apparmor integration, so no
[13:32] <seb128> mandel, we were discussing the update panel segfaulting due to a bug in ubuntuone-credentials
[13:32] <seb128> mandel, but dbarth and alecu managed to reproduce and test the fix since
[13:32] <seb128> mandel, so we should be good, thanks for replying though ;-)
[13:32] <rsalveti> 300 already?
[13:33] <ogra_> yeah
[13:33] <rsalveti> ogra_: noticed yesterday we didn't end yup building armhf and x86 images at the same time
[13:33] <mandel> seb128, oh, for one day that I arrive late.. sorry for that :-/
[13:33] <ogra_> we need to manage to build 33 more until tomorrow
[13:33] <rsalveti> so the x86 image is behind again
[13:33] <rsalveti> wonder why
[13:33] <seb128> mandel, no worry!
[13:33] <ogra_> rsalveti, yeah, me too
[13:33] <mandel> om26er, looking at your issues then
[13:33] <rsalveti> ogra_: how are you triggering new builds?
[13:33] <rsalveti> ogra_: also, how is the ci team triggering new builds?
[13:33] <om26er> mandel, good, thanks
[13:34] <ogra_> rsalveti, http://people.canonical.com/~ubuntu-archive/livefs-build-logs/trusty/ubuntu-touch/20140416/livecd-i386.out
[13:34] <ogra_> seems it built fine
[13:34] <ogra_> rsalveti, iso.qa.ubuntu.com ... for moth questions
[13:34] <ogra_> *both
[13:35] <ogra_> rsalveti, cdimage has all img files at http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20140416/
[13:35] <ogra_> rsalveti, looks like a system-image issue
[13:35] <rsalveti> ogra_: yesterday I noticed that the timestamp in cdimage was older
[13:35] <rsalveti> the x86 one
[13:35] <rsalveti> so not system-image
[13:36] <rsalveti> I had to build one image just for x86
[13:36] <ogra_> well, weeks older or hours ?
[13:36] <rsalveti> 1 day
[13:36] <ogra_> above its 30min
[13:36] <rsalveti> it seems the one from cron gets both published at the same time
[13:36] <ogra_> which seems liek a normal delay between arches
[13:36] <rsalveti> but the ones started during the day, by devs, ended up generating only the armhf one
[13:36] <ogra_> hmm
[13:37] <mandel> om26er, can you take a look at /etc/dbus-1/system-services and check that you have a file named com.canonical.applications.Downloader.service
[13:38] <ogra_> rsalveti, i wonder if the script from iso.qa.u.c sets ARCHES=
[13:38] <ogra_> cron definitely doesnt
[13:38] <rsalveti> ogra_: that's probably the issue
[13:38] <Saviq> fginther, shall we disable otto for unity8? it's not really useful at this point :/
[13:39] <ogra_> rsalveti, http://iso.qa.ubuntu.com/qatracker/milestones/308/builds
[13:39] <ogra_> yeah
[13:39] <ogra_> it doesnt even offer an x86 version
[13:39] <ogra_> dang
[13:39] <rsalveti> ogra_: right, how can we fix that?
[13:39] <ogra_> dunno who owns iso.qa.u.c
[13:39] <ogra_> qa team ?
[13:40] <om26er> mandel, yes that file is there
[13:40] <Saviq> om26er, couldn't get anything out of your .crash :/, gdb chokes on it...
[13:41] <Saviq> om26er, I backed out the greeter MP, added a scope optimizations one and will go through another testing round now
[13:41] <Saviq> or well... when it builds...
[13:42] <om26er> Saviq, ok, do let me know when you think its ready
[13:43] <cjwatson> ogra_: stgraber should be able to help you out
[13:43] <Saviq> om26er, we could parallelize testing, so I'll let you know when it's built? should be 20 mins from now or so
[13:43] <ogra_> cjwatson, poor guy ... so many requests for him today from touch :)
[13:43] <om26er> Saviq, ok, makes sense.
[13:43] <ogra_> cjwatson, thanks
[13:44] <stgraber> ogra_: I need to disappear for 20-30min, then I'll cleanup system-image and then look at whatever you need on the tracker
[13:44] <ogra_> stgraber, thanks ... no hurry, as long as it happens before release :)
[13:45] <stgraber> ogra_: so yes, the rebuild feature on the tracker sets ARCHES=
[13:46] <ogra_> stgraber, can we unset that for touch builds ?=
[13:46] <ogra_> it is unlikely that we ever want per arch builds
[13:46] <stgraber> ogra_: and I suspect nobody bothered to create an x86 entry in the product list on the tracker (+ matching cdimage code) so it doesn't know about x86
[13:46] <ogra_> right
[13:47] <stgraber> ogra_: well, it also does grouping so once we have x86 on there, selecting both and clicking rebuild will set ARCHES="i386 armhf" which should DTRT
[13:47] <stgraber> it's just that apparently we're missing both cdimage and tracker support for the i386 one
[13:47] <mandel> om26er, can you please pastebin it?
[13:47] <ogra_> yes, but thats nothing we need, and people will always have to check both boxes
[13:47] <mandel> om26er, although it is there it should be ok
[13:47] <cjwatson> you should be able to check the box at the top of the whole product iirc
[13:47]  * ogra_ would prefer if we could keep the build UI as simple as is
[13:48] <om26er> mandel, http://paste.ubuntu.com/7261569/
[13:48] <ogra_> ah, never noticed that one :)
[13:48] <cjwatson> right, the box to the left of "Product (Ubuntu Touch)" will check everything under it
[13:48] <stgraber> ogra_: I don't like making unobvious exceptions, all the other products work like that and the cdimage team expects them to all work like that. As cjwatson said, it'll technically be the exact same amount of clicks, just not the same box :)
[13:49] <stgraber> anyway, I'll look into the missing product + cdimage integration in a bit, shouldn't be too difficult to fix
[13:49] <ogra_> ok
[13:55] <mandel> om26er, I just installed udm from the ppa and test it with the following script: http://paste.ubuntu.com/7261603/
[13:56] <fginther> Saviq, yeah, I'll get that done
[13:56] <mandel> om26er, can you please do the same, it will download some stupid img from imgur several times
[13:56] <mandel> om26er, but it uses the system bus, which is the same as the one used by system image updates
[13:56] <sil2100> psivaa: hi! How is it in the end? Do we have some cameras in the smoketesting lab?
[13:57] <om26er> mandel, ok, trying that in a few. in a hangout right now :)
[13:58] <mandel> om26er, ok, let me know 'cause I cannot reproduce the issue :-/
[13:58] <mandel> om26er, I'll have to use you as a testing machine, sorry
[14:03] <psivaa> sil2100:   i'm not entirely sure if we have cameras that's usable now. rfowler or retoaded might  know more?
[14:08] <retoaded> psivaa, sil2100: we have a camera in the lab but it is mounted outside of the racks and doesn't have a view of anything in the racks.
[14:09] <psivaa> retoaded, ack, thx
[14:09] <fginther> kgunn, I fixed an issue that was causing much of the ci trouble you mentioned last night. There's still a backlog of 3 branches that are in line to land. They should go in without further trouble
[14:10] <kgunn> fginther: thnak you sir
[14:11] <sil2100> retoaded, psivaa: thanks
[14:19] <om26er> mandel, it says ImportError: No module named gobject
[14:19] <om26er> mandel, what am i missing
[14:19] <om26er> python-gobject probably, installing it
[14:20] <mandel> om26er, oh, sorry, python-gobject and python-dbus are needed
[14:20] <om26er> mandel, ok, it gives http://paste.ubuntu.com/7261747/
[14:20] <mandel> om26er, ok, so we have an easier way to reproduce the issue, may I know img number and how you installed udm?
[14:22] <om26er> mandel, image# 299 and adding the silo ppa, and performed dist-upgrade
[14:22] <om26er> rebooted and tried
[14:23] <mandel> om26er, ok, so the correct way would have been not to do a dist-upgrade 'cause that is going to grab everything and not only udm. I would recommend doing sudo apt-get update && sudo apt-get install ubuntu-download-manager unity-scope-click
[14:23] <mandel> om26er, that will install only what we are changing and have to test, dist-upgrade is to drastic
[14:23] <om26er> mandel, ok
[14:24] <mandel> om26er, having said that, before you reflash etc.. which is a lot of work
[14:24] <mandel> om26er, can you do sudo ubuntu-download-manager and try the script again?
[14:24] <imgbot> [14:24] <imgbot> [14:24] <mandel> om26er, you might have found a problem (in something else) :)
[14:25] <davmor2> popey: on sms notifications do you see sms from +441234567890 first then it change to a contact after?  Also if you get the notification and click it on the sms from +441234567890 do you get any notifications that you have a new message?
[14:25] <ogra_> yay, 300
[14:25] <ogra_> hmm, not offered to me in system-settings :(
[14:25] <popey> for the first, yes
[14:26] <popey> ogra_: I just got it
[14:26] <ogra_> weird
[14:26] <popey> davmor2: i cant parse the second issue
[14:26] <ogra_> (the bot also only announces it if it is available for the phones)
[14:26] <ogra_> nope
[14:27] <ogra_> system-settings says "Software is up to date"
[14:27] <ogra_> GRR+
[14:27] <davmor2> popey: while the notification is still on the sms from +441234567890 rather than the name click it and then send another sms and see if the envelope goes blue
[14:28] <Saviq> om26er, it's built, same silo (008)
[14:28] <popey> davmor2: so click the notification, and reply to the sms?
[14:28] <om26er> mandel, http://paste.ubuntu.com/7261788/
[14:29] <om26er> Saviq, ok, on it in parallel. mako or flo ?
[14:29] <Saviq> om26er, mako is our driver
[14:30] <mandel> om26er, ah, nice, so the distupgrade broke the way we create the daemon, lets try without the dist-upgrade and see if everything goes ok :)
[14:31] <davmor2> popey: no phone a = current build, phone b = stable.  On phone a add phone b as a contact.  From phone b text phone a.  Phone a will say sms from +441234567890 click the notification while it says that and before it say sms from phone b.  Then send another sms from phone b
[14:31] <davmor2> Does phone a then show the blue envelope
[14:35]  * alecu installs 300
[14:35] <mandel> om26er, let me know when you have been able to test udm just doing the apt-get install
[14:36] <om26er> mandel, sure, device is being flashed
[14:37] <popey> davmor2: actually mine says "SMS from Alan Pope"
[14:37] <popey> davmor2: http://popey.com/~alan/phablet/device-2014-04-16-153731.png
[14:39] <davmor2> popey: try it with the receiving phone asleep maybe that is it
[14:40] <popey> nope
[14:40] <popey> however, check out my avatar ☻ http://popey.com/~alan/phablet/device-2014-04-16-154019.png
[14:41] <davmor2> popey: yes it is sorry it's kinda like your clock issue it is there for a split second
[14:41] <popey> interesting, i just sent a text and it didnt go blue
[14:41] <davmor2> ha bingo
[14:41] <popey> when on welcome screen, screen on
[14:42] <davmor2> so the no blue issue appears for you then
[14:42] <popey> seems to happen after a while
[14:42] <popey> and no notifications anymore either
[14:42] <popey> screen wakes up but no noise,no popup
[14:42] <davmor2> popey: that's the one
[14:42] <davmor2> weird rigth
[14:43] <ogra_> no update for me :(((
[14:43]  * ogra_ cries
[14:43] <davmor2> right even
[14:43] <ogra_> my flo got it ... my mako doesnt offer it at all
[14:47] <didrocks> dbarth: so, did you get to anywhere or do we revert?
[14:56] <asac> didrocks: how do landers test silos?
[14:56] <didrocks> asac: wdym?
[14:56] <asac> do we have a recommended procedure how to ugprade to what is in the silo?
[14:56] <didrocks> asac: we usually just tell to turn in rw mode and dist-upgrade
[14:56] <didrocks> asac: people introducing new components know what to apt-get install generally
[14:58] <sergiusens> heh I never do that
[14:58] <dbarth> didrocks: nope :/ the change is buried into a larger merge set
[14:58] <didrocks> dbarth: so, you told we can revert? what's the impact/what do we reintroduce?
[14:59] <didrocks> dbarth: can you point me as well to the bug report? I didn't see any yet
[14:59] <dbarth> didrocks: i will ping again to see if there's a solution in sight, otherwise we should get back to bzr501+that link fix
[14:59] <sergiusens> didrocks:  asac I do something like this http://paste.ubuntu.com/7261199/ with a mount -o remount,rw / in between (just had this pastebin handy)
[14:59] <sergiusens> that way I ensure I don't get anything extra that landed in between
[14:59] <dbarth> didrocks: https://bugs.launchpad.net/webbrowser-app/+bug/1307735
[15:00] <asac> didrocks: shouldnt we be clear that if they want to test a silo against he image, they should not use dist-upgrade as that might bring in other stuff?
[15:00] <asac> or do we want the other stuff to be in - lets say for QA sign off of silos?
[15:01] <didrocks> asac: we would need a tool analyzing the binary packages in the ppa and installing only those available on the device, agreed
[15:01] <dbarth> didrocks: and the rev we want is that one: http://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/revision/507
[15:01] <asac> didrocks: not all those that are in the silo?
[15:01] <didrocks> dbarth: can we get it then?
[15:01] <asac> could be new stuff in the silo as well?
[15:01] <didrocks> asac: yeah, we need to have an override to add optional new packages
[15:01] <didrocks> asac: but not all
[15:01] <didrocks> asac: you don't want to install -dev
[15:02] <didrocks> asac: and you want to handle library transition
[15:02] <didrocks> dbarth: what's blocking us to get the oxide rev?
[15:03] <dbarth> a decision to revert
[15:03] <didrocks> well, I can take that decision…
[15:03] <didrocks> we waited for multiple hours already
[15:03] <dbarth> didrocks: can you clarify it's a stop-ship issue and that we need a revert?
[15:03] <didrocks> I don't think it's sane to wait more
[15:04] <dbarth> agreed
[15:04] <didrocks> dbarth: so, revert what to where?
[15:04] <didrocks> I want:
[15:04] <didrocks> - a list of components
[15:04] <didrocks> - a list of bugs that the revert will reintroduce
[15:04] <didrocks> - the assurance that previous version was working
[15:05] <cjwatson> I think any oxide reversion would have to go in -updates at this point
[15:05] <didrocks> cjwatson: yeah, agreed
[15:05] <cjwatson> It's on other images, and we've already started the hopefully-last candidate build
[15:05] <didrocks> cjwatson: I think -updates is fine, you need network to experience it anyway
[15:05] <didrocks> (experience the feature and bug)
[15:09] <didrocks> dbarth: ?
[15:09] <didrocks> still with me?
[15:11] <dbarth> didrocks: on a hangout to determine exactly where back we need to revert
[15:11] <dbarth> didrocks: i've gathered everyone involved, just bear with me for a bit more time
[15:11] <didrocks> I would have hoped that analyze to be ready by now, hours after it was discovered :(
[15:12] <didrocks> ok, please really keep us posted…
[15:12] <didrocks> once you know what to do, we'll have 8 hours of delay to have that in a tested image
[15:12] <didrocks> we don't have that much luxury before trust
[15:12] <didrocks> trusty*
[15:13] <dbarth> i know
[15:19] <om26er> Saviq, I dont see a silo for unity8, where has it gone ?
[15:20] <Saviq> om26er, hum? silo 008 still
[15:20] <om26er> Saviq, no, whats the line number ?
[15:20] <Saviq> om26er, row 17
[15:20] <Saviq> om26er, it's a large one, probably doesn't fit and spreadsheet is stoopid
[15:20] <om26er> Saviq, yeah spreadsheet problem
[15:21] <davmor2> didrocks: So I just put my flo onto 297, I see images updates and I see application updates what I don't see is a message saying install these things now
[15:21] <davmor2> didrocks: ubuntu-push-client is installed
[15:21] <didrocks> davmor2: did you ask upstream first?
[15:23] <davmor2> didrocks: I can now I was asking on u1 channel and there was no Chipaca there
[15:23]  * Chipaca hides
[15:24] <didrocks> ogra_: meanwhile, promoting #299? davmor2 +1 on the dogfooding and the tests results are good
[15:24] <mandel> didrocks, asac doing a dist-upgrade brings changes that are not related to the silo and we are breaking the isolation of the silo, for example, software in the silo is ok yet a new versions makes it fail, are we going to block the silo because of it?
[15:24] <asac> yeah
[15:24] <didrocks> which silo?
[15:24] <mandel> didrocks, asac that way we are blocking a software from landing when it is not the culprit
[15:24] <davmor2> Chipaca: 297 ubuntu-push-client is installed if I open updates it shows apps for updates, and if I open settings it immediately tells me there are system updates But I see no notifications
[15:25] <mandel> didrocks, I'm talking about a general idea, not a precise silo atm
[15:25] <asac> didrocks: if you do silo testing and you use dist-upgrade to test the silo you are not isolated anymore :)
[15:25] <didrocks> asac: mandel: is it the day to really discuss this?
[15:25] <asac> but i think we already agreed
[15:25] <ogra_> didrocks, in a meeting, will do it before the landing meeting
[15:25] <didrocks> I guess we have a release to do
[15:25] <didrocks> told what needs to be done
[15:25] <Chipaca> davmor2: notifications, when we send them out, are only for system updates
[15:25] <mandel> didrocks, not the day, probably not :)
[15:25] <Chipaca> davmor2: and we haven't set the cron up yet to do that :)
[15:25] <asac> didrocks: if the QA practice of using dist-upgrade creates risk that we might get false positive acks from them, then yes
[15:25] <asac> otherwise no :)
[15:26] <didrocks> asac: especially when the archive is frozen and we don't enable proposed, this is somewhat flawed
[15:27] <davmor2> Chipaca: ah okay so that will be why then.  Won't a cron job be unreliable as to the release of an image though?
[15:27] <davmor2> Chipaca: I guess end users won't notice
[15:27] <Chipaca> davmor2: I'm not sure it's an actual cronjob -- but if it were, why would it be unreliable?
[15:27] <didrocks> asac: ok, if you want to continue discussing on that
[15:27] <didrocks> asac: as the silo is building against -proposed
[15:27] <didrocks> we need to add -proposed as well
[15:28] <didrocks> in that tool
[15:28] <didrocks> because we may be in a library transition
[15:28] <didrocks> and that's what the component is built against
[15:28] <Chipaca> davmor2: we could also have imgbot send them out, but some people didn't like that idea
[15:28] <plars> rsalveti: I was running some tests locally with 299 and got stuck at the google screen. Do I need to boot into recovery to grab /proc/last_kmsg or see if it will let me fully boot?
[15:28] <didrocks> and what if the soname change wasn't spot on?
[15:28] <didrocks> maybe we should install all rdepends as well?
[15:28] <asac> didrocks: so you say we shouldnt tackle it before release; fine by me
[15:29] <didrocks> asac: exactly, it's clearly not "one obvious answer to fit them all"
[15:29] <davmor2> Chipaca: if it's run hourly and we release at 10 past then a user updates at 20 past and then the cron job picks it up on the next hour and pushes a notification about an update wont that be confusing?
[15:29] <didrocks> neither something we didn't think about
[15:29] <didrocks> (or at least not something I didn't think about)
[15:29] <Chipaca> davmor2: if they're already updated, the client would filter it out
[15:29] <didrocks> I had another approach in daily release
[15:29] <didrocks> but hard to maintain
[15:29] <Chipaca> davmor2: or the server, depending :)
[15:29] <asac> mandel: ok,so seems we have not a good enough answer to set a better standard right now
[15:29] <davmor2> Chipaca: ah nice :)
[15:29] <Chipaca> davmor2: filtering by channels and such does happen
[15:29] <sil2100> It was already one of the things that didn't enable cu2d doing a dist-upgrade during each test run in the past
[15:30] <asac> mandel: just poke us next week or so so we dont loose this track
[15:30] <sil2100> Because of those certain edge cases that could happen
[15:30] <didrocks> asac: it's exactly why I want us to build images and test images
[15:30] <mandel> asac, ack, I'll make sure that we take a look at this with enough time
[15:30] <plars> ogra_:: I was running some tests locally with 299 and got stuck at the google screen. Do I need to boot into recovery to grab /proc/last_kmsg or see if it will let me fully boot?
[15:30] <didrocks> which will be the more realistic approach
[15:30] <didrocks> asac: and this part of the airline proposal
[15:31] <ogra_> plars, adb should come up in any case (after 60sec or so)
[15:31] <plars> ogra_: ok, but it doesn't matter which mode I'm in for grabbing that proc file
[15:31] <ogra_> plars, that only has the "last boot" so it matters
[15:32] <ogra_> plars, you need to reboot immediately into recovery for it ... after the crash
[15:32] <plars> ok, that's what I was asking
[15:32] <plars> crap, too late
[15:33] <plars> I powered down the device and it autobooted... I guess I didn't have my fingers on the vol buttons in time
[15:35] <ogra_> sad
[15:35] <ogra_> hwo did it get into that state ?
[15:36] <rsalveti> plars: that would be nice to get (last_kmsg)
[15:36] <rsalveti> but it could be a different issue
[15:36] <rsalveti> as we have a trigger to reboot the kernel in case of crashes
[15:36] <ogra_> to late anyway
[15:37] <asac> are there any active landing intends still?
[15:37] <ogra_> asac, i think dowenload-manager
[15:37] <ogra_> mandel, ^^^^
[15:37] <plars> rsalveti, ogra_: well, it looks like what was there after booting was really short (which would be consistent) want to take a look just in case? http://paste.ubuntu.com/7262146/
[15:38] <plars> otherwise, I'll try to reproduce after letting this run continue
[15:38] <asac> ok, is that bullet proof?
[15:38] <asac> we should really stop landing stuff
[15:38] <asac> and wait for the oxide thing to maybe come along
[15:38] <ogra_> asac, not sure it was obviously falsely tested
[15:38] <asac> right
[15:38] <mandel> asac, we can wait until tuesday
[15:38] <asac> so go back and triple test
[15:38] <asac> mandel: what will this fix?
[15:38] <asac> anything important?
[15:38] <mandel> asac, since the new features are for mms and those are not there until tuesday
[15:38] <ogra_> plars, thats a proper boot i guess
[15:38] <mandel> asac, nothing that will impact anyone atm
[15:39] <plars> ok
[15:39] <asac> mandel: anything beyond mms we would not get?
[15:39] <asac> right, lets not do it then i guess
[15:39] <asac> is everything that landed captured in 300?
[15:39] <ogra_> plars, hmm, or not !
[15:39] <mandel> asac, no, lets block 'til next week
[15:39] <asac> or do we have stuff still in landing?
[15:39] <mandel> asac, is not a bad idea to play it safe
[15:39] <asac> right
[15:40] <asac> if there is no value coming out of this, it can wait
[15:40] <asac> will be a bit awful i think
[15:40] <asac> because it will have to go into u
[15:40] <asac> e.g. might need respin
[15:40] <didrocks> ogra_: not sure if you miss with our discussion on #299 promotion?
[15:40] <ogra_> plars, http://paste.ubuntu.com/7262161/ this is definitely not normal ... rsalveti should take a look
[15:40] <mandel> asac, we can wait unless sergiusens says otherwise
[15:40] <asac> and you might fight imports hailstorms :P
[15:40] <asac> but :)
[15:40] <asac> didrocks: did anything land since 300 image was produced?
[15:40] <ogra_> didrocks, [17:25] <ogra_> didrocks, in a meeting, will do it before the landing meeting
[15:40] <Saviq> om26er, I'm +1, the issues you mentioned are not there, TestPlan completed fine
[15:41] <Saviq> gtg, back in 3h or so
[15:41] <didrocks> asac: nothing for us
[15:41] <didrocks> ogra_: thanks, it's me missing it then :p
[15:41] <sil2100> asac: I don't remember we landed anything that would affect touch
[15:41] <ogra_> :)
[15:41] <asac> didrocks: ok so we dont need to spin an image before we land a potential oxide fix
[15:41] <asac> ?
[15:41] <didrocks> asac: yep
[15:42] <didrocks> asac: #300 is really fresh anyway (testing starting)
[15:42] <ogra_> so they have til 2AM UTC :)
[15:42] <didrocks> asac: but I don't get any info from dbarth still…
[15:42]  * sil2100 also poked oSoMoN
[15:42] <sil2100> But it seems they're all in a meeting
[15:43] <didrocks> ok, let's hope they are all busy discussing it :)
[15:44] <dbarth> didrocks: we're narrowing that down to between rev 501 and 506
[15:45] <dbarth> didrocks: at this stage we're on doing a rebuild of 501 +507 to get back to a known good version, with the rev. 507 fix that re-enables external links in the browser
[15:45] <dbarth> in between there was a chromium update, and that's most probably the reason we need to go back that deep
[15:46] <om26er> didrocks, unity8 is ready to land now
[15:46] <rsalveti> plars: those are fine
[15:46] <dbarth> didrocks: that will require a rebuild of ~1h to get that clear now
[15:47] <didrocks> dbarth: the rev as oxide rev or webbrowser-app?
[15:47] <didrocks> sil2100: publishing om26er's unity8? ^
[15:48] <mandel> om26er, we are blokcing silo 11 until after the release, do not waste your time on it today :)
[15:48] <mandel> om26er, I'll keep track of it
[15:48] <didrocks> mandel: put upstream test pass to no?
[15:48] <didrocks> mandel: that way, it will be off their list
[15:48] <om26er> mandel, good, thanks
[15:49] <om26er> didrocks, I did that already
[15:49] <didrocks> sweet!
[15:49] <sil2100> Oh, it suddenly got turned to tested on?
[15:50] <sil2100> Let me publish then
[15:50] <sil2100> didrocks: we're not stopping the line for the oxide fix? Just to make sure
[15:50] <didrocks> sil2100: as asac told, we are in traincon0, max velocity + checking
[15:51] <dbarth> didrocks: oxide revs sorry
[15:51] <didrocks> dbarth: why can't we shipe latest oxide trunk?
[15:51] <didrocks> ship*
[15:51] <dbarth> didrocks: cause it does not start
[15:52] <didrocks> urgh
[15:52] <dbarth> chromium update
[15:52] <dbarth> we tested the build 5 min. after it was ready in the ppa
[15:54] <popey> davmor2: you seeing oddness with webapps?
[15:54] <davmor2> popey: how do you mean?
[15:55] <popey> bbc news was blank when it loaded
[15:55] <popey> gmail was blank for ages then eventually appeared
[15:58] <sil2100> didrocks: if we are to publish unity8, a packaging ACK is needed! https://ci-train.ubuntu.com/job/landing-008-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity8_7.85+14.04.20140416-0ubuntu1.diff <- looks ok, seems the don't need libupstart anymore
[16:00] <didrocks> Saviq: does this makes sense to you? ^
[16:01] <sil2100> It builds correctly, so I guess it should make sense!
[16:01] <didrocks> sil2100: tests are passing as well, so yeah
[16:01] <didrocks> +1
[16:01] <popey> hangout?
[16:01] <popey> \o/ not late for once
[16:01] <didrocks> hang in! :p
[16:01] <didrocks> on
[16:01] <didrocks> out
[16:01] <didrocks> robru: coming?
[16:03] <jdstrand> didrocks, pmcgowan, chrisccoulson: fyi, I spoke with dbarth, et al and we decided that oSoMoN will update oxide-qt 1.0.0~bzr501-0ubuntu1 (ie, what is in the archive currently), cherrypick oSoMoN's patch, rev the version to 1.0.0~bzr501-0ubuntu2 and upload to their ppa
[16:03] <pmcgowan> jdstrand, great
[16:04] <jdstrand> that will allow the regression to be fixed and for chrisccoulson to keep working on fixing the version we've prepared in our ppa
[16:04] <jdstrand> oh, and by 'their ppa', I meant 'their silo'
[16:04] <jdstrand> dbarth: is landing that regression fix, and will have the full details
[16:04] <jdstrand> s/://
[16:04] <pmcgowan> asac, fyi ^^
[16:05] <asac> ogra_: coming?
[16:05] <dbarth> on the release meting to get a silo
[16:07] <asac> jdstrand: maybe you could join the landing meeting and explain exactly what the plan is so there is no confusion?
[16:07] <asac> jdstrand: its running right now
[16:08] <jdstrand> ok
[16:08] <asac> jdstrand: invited you...
[16:08] <jdstrand> can I just pop in and out?
[16:08] <jdstrand> :)
[16:08] <dbarth> sil2100: can you assign the silo for landing request 21 as well?
[16:08] <asac> jdstrand: sure, just speak up loud so we can stop the agenda :)
[16:09] <sil2100> dbarth: ok, but first let me assign the one with just oxide-qt
[16:09] <sil2100> dbarth: it's the last line, right?
[16:09] <dbarth> sil2100: and line 25 as well
[16:09] <dbarth> sil2100: right the last line
[16:09] <sil2100> dbarth: I added oxide-qt as the 'additional sources to land' there
[16:10] <sil2100> And assigning
[16:10] <dbarth> awesome
[16:10] <dbarth> sil2100: waht are the dput rights to upload here? osomon is the one needing access
[16:10] <dbarth> sil2100: or will scp to you if neede
[16:10] <dbarth> d
[16:11] <sil2100> dbarth: not too many people have access... but if you have a branch with the fix as a cherry-picked patch or some source package, I can dput it quickly
[16:11] <sil2100> dbarth: 001 assigned for you!
[16:11] <dbarth> sil2100: will be a source package
[16:11] <dbarth> ok
[16:12] <sil2100> dbarth: about 21 - should I remove the 'oxide-qt' from that line before assigning?
[16:12] <dbarth> let me check again
[16:20] <dbarth> sil2100: o/ line 26, if we're not short on silos
[16:20] <dbarth> sil2100: that one is for the desktop, 0-day SRU or update
[16:20] <dbarth> fix for https://bugs.launchpad.net/ubuntu/+source/unity-firefox-extension/+bug/1308625 mentioned by seb128 on #ubuntu-desktop
[16:21] <robru> dbarth, ok you got silo 4
[16:21] <dbarth> wow that was super fast! :)
[16:21] <robru> dbarth, I live to give ;-)
[16:21] <dbarth> gdocs doesn't even keep up
[16:21] <sil2100> ;)
[16:21] <sil2100> 'I live to give' <- love this one, hah ;)
[16:22] <robru> dbarth, oh yeah, the spreadsheet is slow to notice the new silo. you can still click the jenkins build link though, jenkins knows in advance of the spreadsheet ;-)
[16:22] <Laney> it's a quote for the gravestone for sure
[16:22] <robru> sil2100, I heard it from infinity ;-)
[16:33] <didrocks> rsalveti: did we get mms support? I can't remember?
[16:33] <rsalveti> didrocks: nops, not yet
[16:33] <didrocks> rsalveti: ok, thanks (/me uses that time to note things for the release note)
[16:33] <fginther> t1mp, do you ever figure out the evdev issue? (I just now saw your message while looking for something related in my logs)
[16:34] <fginther> t1mp, python-evdev was removed from the image, but it appears to still be needed for autopilot tests using python2
[16:35] <sil2100> Yeah, it got removed from autopilot under the assumption that all tests are already using python3
[16:35] <sil2100> While smoketesting uses 2.7 for almost all tests I guess
[16:36] <fginther> sil2100, well, I noticed that python-evdev is getting pulled in as a consequence of the unity unlock script
[16:36] <dbarth> ogra_: https://bugs.launchpad.net/webbrowser-app/+bug/1308644 just in case
[16:36] <ogra_> dbarth, thanks !
[16:46] <sil2100> Had to take off  the load from my PC
[16:50] <sil2100> didrocks: I'll join the hangout once I'm done with dputting this monster to the PPA
[16:54] <didrocks> ogra_: and don't forget!
[16:54] <didrocks> sil2100: we just finished
[16:54] <didrocks> ogra_: PROMOTE!
[16:54] <didrocks> :)
[16:54] <didrocks> (#299)
[16:55] <sil2100> :| What is my system doing?!
[16:55] <robru> sil2100, dbarth : so what is the status of oxide? who has the source package to upload? i don't see it in the silo yet
[16:56] <sil2100> I have it, but the key was wrong so I need to re-sign it
[16:56] <sil2100> But it takes ages with this monster
[16:56] <robru> ah ok
[16:56] <imgbot> [16:56] <didrocks> ;)
[16:56] <ogra_> :)
[16:56] <didrocks> ogra_: you're obviously cheating ;)
[16:56] <sil2100> ;)
[16:56] <ogra_> haha
[16:56] <ogra_> for promotions, yeah
[16:57] <ogra_> the bot is only a handfull of shellscript lines ... no intelligence to be found there
[16:57] <sil2100> I told you! It's ogra_ printing manually through imgbot all the time!
[16:57] <cjwatson> You wrote an IRC client in *shell*?
[16:57] <ogra_> (it knows about start and stop of image builds ... and changelgs)
[16:57] <cjwatson> I know, I'll use assembly
[16:57] <ogra_> cjwatson, yeah, always wanted to do that :)
[16:57] <dbarth> robru: what sil2100 said
[16:58] <dbarth> oh, signature wrong hmm
[16:58] <cjwatson> Or BBC BASIC
[16:58] <ogra_> lol
[16:58] <didrocks> ahah :)
[16:58] <dbarth> Sinclair Basic FTW
[16:58] <ogra_> geez
[16:58] <cjwatson> Yeah, that's my heritage too, but I was quoting :)
 Bah.  Emacs has given up too.
 mathematica couldn't do it, so you tried /emacs/?
 I know, I'll try vim next. Or BBC BASIC.
 Emacs can do almost everything.  Didn't you know?
[16:58] <ogra_> VIC20 is the only true computer !
[16:59] <ogra_> you and your rubber kbds ... tsk
[16:59] <cjwatson> I had the Spectrum+, it didn't have a rubber keyboard
[16:59]  * sil2100 was an atari/C64 guy
[16:59] <cjwatson> That was only the original 48K and the ZX81 (maybe ZX80 too, I forget)
[17:00] <davmor2> dbarth: I think you mean dragon32 basic ftw
[17:00] <ogra_> the zx80/81 didnt even have keys
[17:10] <davmor2> ogra_: yes it did it just didn't have "Regular" Keys :P
[17:11] <davmor2> it had bigtrack keys
[17:11] <ogra_> well, it had a printed dream of real keys on a plastic foil :P
[17:12] <davmor2> ogra_: http://ww1.prweb.com/prfiles/2010/02/02/2284674/BACK.jpg
[17:13] <ogra_> haha, yeah
[17:13] <davmor2> ogra_: It had BigTrak Keys I tell you :D  Well technically I guess the zx80/81 was out first so BigTrak had ZX keys :)
[17:13] <sil2100> dbarth: dputted, phew, this is such a big monster that re-building the source packages took really long, I think my system is thrashed as well
[17:14] <sil2100> dbarth: but it should appear in the ppa soonish and start building
[17:16] <dbarth> sil2100: ok
[17:16] <dbarth> sil2100: hope it's a fast one
[17:16] <dbarth> the ppa
[17:17] <sil2100> It has the archive builders, so I guess it's as fast as it gets on LP
[17:19] <dbarth> cool
[17:20] <cjwatson> they're fairly decent, yes
[17:20] <ogra_> and idly
[17:20] <ogra_> (hopefully at that point of release)
[17:21] <dbarth> (building oxide on a z80,that just crossed my mind... o_O)
[17:22] <ogra_> hehe
[17:22] <ogra_> might need some swap
[17:26] <t1mp> fginther: I solved the evdev problem by installing python-evdev on my device
[17:26] <t1mp> fginther: but in general for click packages with python2 it still needs to be there.
[17:27] <t1mp> fginther: so the apps need to switch to python3 or python-evdev should be in the image or installed with the click packages. I don't know which project should take care of that
[17:34] <Chipaca> anybody here know what alphyn (in the Lexington qa lab) is doing?
[17:38] <fginther> t1mp, from what I gather, the solution is for apps to use python3. I know Barry Warsaw was working on porting, but I don't see him around to poke
[17:38] <sergiusens> t1mp: should be in the autopilot-touch deps
[17:39] <sergiusens> that's where it used to be
[17:40] <fginther> sergiusens, it was removed from autopilot-touch within the past weekd
[17:40] <sergiusens> fginther: I wonder how testing passed
[17:40] <sergiusens> I was told that testing of readonly was done first and then read/write
[17:41] <sergiusens> so if testing of readonly was done first; no image should of been in a promotable state for the past wek
[17:41] <sergiusens> week
[17:41] <sergiusens> fginther: barry might be at pycon
[17:43] <fginther> sergiusens, I don't have a complete picture yet, but I found that python-evdev is getting installed during the unlock screen script
[17:44] <sergiusens> fginther: yeah; that's another issue to add to the list of problems of using writable image <- ogra_ rsalveti
[17:44] <sergiusens> fginther: we need to add it back to the autopilot-touch meta
[17:45] <ogra_> yeah
[17:45] <ogra_> i think some change from xnox dropped it
[17:49] <sergiusens> ogra_: fginther I created 1308661
[17:49] <sergiusens> bug 1308661
[17:50] <ogra_> k
[17:50] <sergiusens> would be bad if trusty is released without that
[17:51] <robru> ogra_, what's our plan for unity8? are we kicking a new image as soon as that lands?
[17:51] <ogra_> i think thats what didrocks and asac said
[17:52] <robru> ogra_, ok, because launchpad just said it's landed (but not rmadison just yet). so that'll be ready soon
[17:52] <ogra_> ah, thanks
[17:52] <robru> you're welcome
[17:52] <fginther> sergiusens, I'll push an MP to backout the change
[17:55] <sergiusens> fginther: ty
[17:56] <sergiusens> robru: hey can I get a silo for line 27?
[17:57] <xnox> ogra_: it was not my upload.
[17:58] <ogra_> xnox, hmm, i thought it was
[17:58] <ogra_> but sorry then
[18:00] <asac> ogra_: robru: yes, please image for every shot :)
[18:00]  * asac out for running for a bit
[18:00] <ogra_> yeah, already have the watcher script running to ping me
[18:02] <robru> sergiusens, you got silo 5
[18:02] <sergiusens> fginther: ogra_ xnox it's this http://bazaar.launchpad.net/~autopilot/autopilot/trunk/revision/480
[18:03] <robru> ogra_, seems unity8 landed, please kick image build if you haven't already ;-)
[18:03] <ogra_> robru, doing
[18:03] <ogra_> sergiusens, thanks for looking it up
[18:03] <robru> ogra_, thanks
[18:03] <xnox> sergiusens: if you need it back, seed it in ubuntu-touch-meta.
[18:04] <xnox> sergiusens: don't upload autopilot, please.
[18:04] <ogra_> well, autopilot needs it
[18:04] <davmor2> popey: care to confirm when you are about https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1308667
[18:04] <ogra_> xnox, next week :)
[18:04] <sergiusens> xnox: well it seems the python part of autopilot also got removed
[18:04] <xnox> ogra_: no, it's a third party script that needs it.
[18:04] <ogra_> ah
[18:04] <sergiusens> ogra_: that means we have a very broken trusty for app testing
[18:05] <ogra_> sergiusens, hmm, cant it be a dep of the test package ?
[18:05] <xnox> sergiusens: sure, but autopilot ships a backdoor into the seeds =) i want all of autopilot-touch go, and instead packages seeds into the seed.
[18:05] <sergiusens> ogra_: the tests are on read only images
[18:05] <ogra_> hmpf
[18:05] <xnox> sergiusens: people who have upload rights for autopilot, do not have rights to edit touch seed, and that's bad =)
[18:05] <ogra_> sergiusens, why wasnt that brought up earlier :/
[18:06] <sergiusens> ogra_: I didn't notice and our ci image testing is broken as it installs the world before starting tests
[18:06] <xnox> sergiusens: the quickest upload is to upload seed update (quicker built-time than autopilot and does not trigger autopackage tests)
[18:06] <ogra_> 1h after the final landing team meeting before release is pretty much the worst time
[18:06] <sergiusens> which is why I asked for all the clicks to be run in a vanilla image without going into writable image
[18:06] <ogra_> sergiusens, lets wait for asac to return and let him sign it off
[18:07] <sergiusens> ogra_: I noticed an hour ago :-P
[18:07] <ogra_> yeah
[18:07] <ogra_> sergiusens, that wasnt meant personally indeed :)
[18:07] <sergiusens> I hope this proves to asac that doing writable image just hides bugs
[18:08] <sergiusens> and we need to test without that
[18:08] <ogra_> yeah, we do
[18:09] <ogra_> but we also need to lose weight as well
[18:09] <rsalveti> we'll still spin another image anyway
[18:10] <ogra_> right
[18:13] <sergiusens> robru: ty
[18:13] <sergiusens> xnox: ogra_ if it needs seeing, I guess you guys can look into that; I don't seed myself here
[18:14] <ogra_> yeah, we can
[18:23] <Chipaca> the AP tests, what do they run on?
[18:23] <Chipaca> and where?
[18:24] <imgbot> [18:25] <davmor2> Oh exciting
[18:25] <ogra_> :)
[18:25] <ogra_> unity love :)
[18:26] <davmor2> ogra_: you got the chant wrong,  You need flames and pitchforks and it's unity "hate" ;)
[18:26] <ogra_> they dont know unity8 yet :P
[18:27] <davmor2> Muhahahahaha look at what we unleash on the mortals :D
[18:27] <ogra_> :)
[18:45] <ToyKeeper> davmor2: Does 301 have oxide updates too?
[18:46] <ogra_> nope
[18:46] <ogra_> that will be 302
[18:46] <davmor2> ToyKeeper: No this is the unity fixes 302 I assume will be the oxide fix
[18:46] <ToyKeeper> Anything in particular I should look for?  (or just a general dogfood-everything run?)
[18:49] <davmor2> ToyKeeper: general testing but using the components that are fixed,  so for oxide open all the webapps, open the browser got to some sites that have various content planet.ubuntu.com tends to be good for that but I'm sure you have some too :)  For unity8 general dogfooding should be enough you should notice that the scopes are faster.
[18:57] <ogra_> asac, did you see above ? we seemingly need to seed python-evdev
[18:57] <rsalveti> ogra_: going to make another build for x86-only
[18:57] <rsalveti> ogra_: out of sync anyway
[18:57] <ogra_> rsalveti, there is a build running atm
[18:58] <rsalveti> ogra_: for x86 as well?
[18:58] <asac> ogra_: we need to?
[18:58] <ogra_> yes
[18:58] <asac> why?
[18:58] <ogra_> rsalveti, and stgraber brought them in sync
[18:58] <asac> i dont think i want that :)
[18:58] <rsalveti> ogra_: great then
[18:58] <ogra_> asac, tests wont work
[18:58] <asac> which tests? all?
[18:58] <ogra_> asac, sergiusens can expand on that
[18:59] <asac> shouldnt this be pulled in by the test framework?
[18:59] <asac> e.g. autopilot-qt
[18:59] <asac> of autopilot-touch?
[18:59] <ogra_> not on readonly tests (click)
[18:59] <asac> so how did we loose that?
[18:59] <asac> what change made this package go away?
[18:59] <ogra_> ap-touch dropped the dependency
[19:00] <asac> ogra_: can we revert that?
[19:00] <asac> thats what i think we should do
[19:00] <ogra_> asac, noipe
[19:00] <asac> why?
[19:00] <ogra_> seeded
[19:00] <sergiusens> asac: if you install packages during image testing; you basically lose track of pulling in things that make it work but don't in it's vanilla state
[19:00] <ogra_> would block in desktop ...
[19:00] <asac> so one se
[19:00] <asac> c
[19:00] <asac> why did we loose it?
[19:00] <asac> which upload caused it? why was that upload do0ne?
[19:00] <ogra_> asac, also autopilot itself doesnt need python-evdev
[19:01] <sergiusens> asac: ogra_the best way to solve this is to do manual dependency resolution; so if a dep is brought in and not declared, it should be an error; that's the only quick fix I can think of to prevent this
[19:01] <ogra_> asac, http://bazaar.launchpad.net/~autopilot/autopilot/trunk/revision/480
[19:01] <sergiusens> ogra_: yes it does
[19:01] <asac> before i want to solve it i want to know why we lost it
[19:01] <asac> we didnt want to land anything
[19:01] <Saviq> robru, do you know why silo 008 lost its OK status? :/
[19:01] <asac> so autopilot landed? throw it out again
[19:01] <sergiusens> asac: dropping python2 from the phone
[19:01] <ogra_> sergiusens, oh, i thought only a third party tool does
[19:01] <cjwatson> this was autopilot from ages ago
[19:01] <ogra_> ah, xnox claimed that above
[19:01] <cjwatson> not (aiui) a recent regression
[19:02] <sergiusens> ogra_: nope; it's entrenched into the input handlers for autopilot
[19:02] <asac> cjwatson: do you know about this?
[19:02] <asac> :)
[19:02] <cjwatson> I'm only going from chatter here
[19:02] <asac> right
[19:02] <ogra_> yeah, not recent
[19:02] <asac> so before we do anything, we should find out what happened
[19:02] <ogra_> a week old or older
[19:02] <cjwatson> but given that autopilot-touch now depends on python3-evdev not python-evdev, it makes sense
[19:02] <asac> then consider why we landed that in the last 6 hours and if we really want that
[19:02] <ogra_> 10th actually
[19:02] <cjwatson> we did not land it in the last six hours
[19:02] <asac> ok so you say we want it?
[19:03] <sergiusens> https://code.launchpad.net/~thomir/autopilot/trunk-remove-py2-from-touch/+merge/213914
[19:03] <cjwatson> I have no idea whether we want it, just trying to make sure we're working off accurate data :)
[19:03] <sergiusens> merge date says a week ago
[19:03] <ogra_> right
[19:03] <cjwatson> right, it would have been https://launchpad.net/ubuntu/+source/autopilot/1.4+14.04.20140410-0ubuntu1
[19:04] <asac> so which upload changed it so we can ask the uploader if we want it :)?
[19:04] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/288.changes
[19:04] <ogra_> droppeed in 288
[19:04] <cjwatson> and there's been another upload since
[19:04] <asac> ogra_: so we had no tests running since 12 images?
[19:04] <asac> our dashboard is green though for all those images?
[19:04] <ogra_> asac, readonly tests of app devs at home
[19:05] <cjwatson> it seems probable that simply reverting (losing the python3-* versions) would break other things by now
[19:05] <asac> ok so to be clear
[19:05] <asac> its not breaking our tests
[19:05] <ogra_> app developers will have to make their phone writable to test their app
[19:05] <cjwatson> oh, although the diff was
[19:05] <cjwatson> http://launchpadlibrarian.net/172505255/autopilot_1.4%2B14.04.20140409-0ubuntu1_1.4%2B14.04.20140410-0ubuntu1.diff.gz
[19:05] <asac> it breaks tests for devs at home :)
[19:05] <ogra_> and install python-evdev
[19:05] <cjwatson> do we need python-autopilot, or just python-evdev?
[19:05] <asac> so that means it ius a late coming release critical bug
[19:05] <ogra_> thats how i understand sergio
[19:05] <asac> rather than a regression
[19:05] <ogra_> not sure if we do any redonly tests in the infrastructure
[19:05] <cjwatson> we can't land autopilot in release at this point - we don't have respin time
[19:06] <fginther> asac, the smoke tests have to pull in unity8-autopilot to unlock the screen. This was also pulling in python-evdev and masking the issue.
[19:06] <asac> so i defer to cjwatson on what is the best way to resolve this. either seeding, or adding dependency somewhere etc.
[19:06] <cjwatson> we could work around by seeding it, as was suggested
[19:06] <Saviq> robru, oh, it looks like silo 008 got confused... it was already landed, but its status in the spreadsheet is inconsistent
[19:06] <cjwatson> or we could land autopilot in -updates
[19:06] <ogra_> cjwatson, we could just seed it
[19:06] <cjwatson> either works, I don't care
[19:06] <asac> but what risks do we run? if we do the seed and it makes our image explode, can we bavck that out?
[19:06] <ogra_> and fix it in U in a week :)
[19:06] <asac> i feel it should be autopilot dep
[19:06] <cjwatson> backing out a seed change is trivial enough
[19:06] <cjwatson> but as I say, don't really care
[19:07] <asac> just feeling that our seed shouldnt start pulling in stuff needed implicitely by our tests
[19:07] <cjwatson> if it's autopilot it may not be in the trusty release pocket, that's all
[19:07] <asac> i dont think we care as long as our image build picks it up
[19:07] <asac> and we can backout in case it goes bad
[19:07] <cjwatson> your image build will pick up -updates, as far as I know - we've never done it before but -updates showed up in the build log (from apt-get update) last I checked
[19:07] <asac> ogra_: does our image build pick up -updates?
[19:07] <ogra_> asac, yes
[19:08] <sergiusens> asac: well as xnox mentioned seed is fine; we just need a ubuntu-touch-test meta; kind of like the sdk and click framework
[19:08] <ogra_> at least if i can belive the build logs :)
[19:08] <cjwatson> sergiusens: I wouldn't advise rearranging metapackages for trusty at this point
[19:08] <ogra_> lol
[19:08] <cjwatson> that would need a livecd-rootfs upload as well - rather more cumbersome
[19:08] <sergiusens> cjwatson: oh, not saying we should do that now :-)
[19:08] <sergiusens> makes sense to not do it
[19:08]  * ogra_ imagines asac having heart attach over heart attach watching this conversation
[19:09] <ogra_> *attack
[19:09] <asac> no i am fine :)
[19:09] <asac> i think we should just keep app devs broken :)
[19:09] <asac> they didnt complain for 12 images
[19:09] <cjwatson> wait, autopilot isn't actually on desktop images
[19:09] <asac> j.k.
[19:09] <ogra_> thats mean
[19:09] <cjwatson> so you can totally land that
[19:09] <asac> well, you guys should be on top ... we are moving fast :P
[19:09] <asac> yeah
[19:09] <asac> so letes do autopilot, use a silo
[19:09] <ogra_> what an effort !
[19:09] <asac> get triple testing as i just dont want to risk that we have to backout
[19:10] <asac> because we are waiting for something very important
[19:10] <asac> the oxide thing
[19:10] <ogra_> thats why you should definitely take the seed change instead
[19:10] <ogra_> way less variables
[19:10] <asac> if we dont have the time to iterate that once because we have to back it out i would feel responsible for making a bad touch release
[19:10] <asac> seed change also with testing
[19:10] <asac> in silo
[19:10] <asac> as i said, if we have to backout its a worst case
[19:10] <asac> because oxide is a key upload
[19:10] <asac> without that we dont have working URLs
[19:10] <cjwatson> does anyone care desperately about unity-firefox-extension?
[19:11] <ogra_> not sure what you want to test wrt a seed change
[19:11] <sergiusens> asac: they didn't complain because they run off from devel
[19:11] <ogra_> you just apt-get install python-evdev
[19:11] <sergiusens> asac: it's some peoples daily phones
[19:11] <asac> ogra_: i wnt to test the image because of the changed packages on it
[19:11] <asac> not because whether its a seed
[19:11] <asac> or autopiulot no change upload
[19:11] <cjwatson> ogra_: I tend to agree with asac that an autopilot change is more elegant and appropriate
[19:11] <asac> its about the changed set of packages that are on the image.
[19:11] <ogra_> asac, well, but the package chgange can be done with apt-get
[19:11] <asac> who knows what runtime side effects python-evdev hast
[19:11] <cjwatson> seeing as autopilot isn't on desktop so it shouldn't be hard to change it
[19:11] <asac> ogra_: yes, do it in a silo
[19:11] <asac> get QA give a sign off
[19:12] <asac> or we dont get this fixed.
[19:12] <cjwatson> ogra_: it seems silly to work around one of our source packages in another when there isn't actually a pressing reason to do so
[19:12] <asac> we are like 2 hours before midnight here... any mistakes will cost us a lot
[19:12] <ogra_> cjwatson, well ... if anything breaks because some depending package autopilot uses changed and thats only picked up by this rebuild we might be pretty busy tomorrow ... whicle a seed change is a one liner thats easily reverted
[19:13] <davmor2> ogra_: you did turn off the nightly cron right?
[19:13] <sergiusens> asac: midnight is when main is frozen for real?
[19:13] <cjwatson> ogra_: that doesn't seem like a realistic risk to me, but shrug
[19:13] <ogra_> davmor2, no, not yet
[19:13] <cjwatson> sergiusens: anything on non-touch images is frozen for real now
[19:13] <asac> sergiusens: not it was a metaphor
[19:13] <cjwatson> main vs. universe isn't a thing for this
[19:13] <Saviq> om26er_, thanks, btw!
[19:13] <asac> sergiusens: its not like we have any time for any mistakes, so triple checking is the theme
[19:13] <cjwatson> what matters is whether it makes us go through another multi-hour respin cycle
[19:14] <om26er_> Saviq, aah, 3hours are up for you ;)
[19:14] <ogra_> [19:14] <asac> ogra_: is 301 out with the unity8 landing?
[19:14] <ogra_> davmor2, ^^
[19:14] <ogra_> asac, nope, still building
[19:14] <asac> what is building? the image or the uniuty?
[19:14] <cjwatson> dbarth: so, unity-firefox-extension - how critical is this?
[19:15] <ogra_> asac, image
[19:15] <asac> ogra_: sergiusens: so go the silo route please
[19:15] <davmor2> ogra_: I was only making sure it wasn't forgotten :)
[19:15] <asac> ogra_: sergiusens: if oxide is ready it will come first
[19:15] <cjwatson> ah, https://bugs.launchpad.net/ubuntu/+source/unity-firefox-extension/+bug/1308625
[19:15] <ogra_> davmor2, yeah, i had the crontab open in another window already
[19:15] <davmor2> ogra_: :)
[19:15] <cjwatson> dbarth: so IMO that can be -updates at leisure
[19:16] <davmor2> asac: at a guess about 30 minutes-ish
[19:16] <asac> ogra_: sergiusens: so autopilot dep -> silo, test test test, ask for QA review
[19:16] <asac> wait
[19:16]  * ogra_ has not even a clue what to test there
[19:17] <asac> est test test -> autopliot test plan
[19:17] <sergiusens> asac: I would expect QA to fix
[19:17] <asac> 1. all APs
[19:17] <asac> :)
[19:18] <asac> sergiusens: ask them if they want to fix it :()
[19:18] <dbarth> cjwatson: sorry, it's annoying, not critical, updates is fine
[19:18] <asac> jfunk: so it seems autopilots for tests outside our image are broken
[19:18] <asac> jfunk: for that we need to readd a dependency
[19:19] <ogra_> asac, well, inside works only due to a hack
[19:19] <asac> jfunk: do you have anyone from your autopilot team awake that can drive such a landing?
[19:19] <asac> jfunk: seems its broken since 12 images, sergiusens only noticed it now
[19:19] <asac> jfunk: the problem is not doing coding etc. its about getting the change into a silo and testing it
[19:19] <sergiusens> asac: to be fair, fginther noticed; I just raised the criticality
[19:19] <asac> and then getting your other QA half to sign it off
[19:20] <asac> sergiusens: can we have a bug?
[19:20] <ogra_> asac, the screen unlock code is about to change ... that dropped a hack they used ... this then exposed the actual issue
[19:20] <asac> wait
[19:20] <fginther> https://bugs.launchpad.net/ubuntu/+source/autopilot/+bug/1308661
[19:20] <asac> is "about to change"?
[19:20] <asac> nothing will change
[19:20] <asac> surely not for release
[19:20] <ogra_> in U
[19:20] <asac> so i dont see thomi online yet
[19:20] <sergiusens> asac: already logged, https://launchpad.net/bugs/1308661
[19:20] <asac> if you guys want to start prepping the silo
[19:20] <asac> i can ask him to bless that
[19:20] <asac> when he comes on
[19:21] <asac> jfunk: will thomi come on?
[19:21] <fginther> sergiusens, I do have an MP ready linked to the bug
[19:21] <asac> this is not even what we discussed
[19:21] <asac> http://bazaar.launchpad.net/~fginther/autopilot/restore-python2-deps/revision/484
[19:21] <asac> we discussed just adding python-evdev
[19:21] <asac> now that MP brings in other stuff
[19:22] <ogra_> asac, it reverts the change in question
[19:22] <asac> well, but that was what i asked
[19:22] <asac> if we could back out
[19:22] <ogra_> asac, http://bazaar.launchpad.net/~autopilot/autopilot/trunk/revision/480
[19:22] <asac> and cjwatson said we cant most likely :)
[19:23] <asac> so now its again highly suspicious that we dont know what we are doing
[19:23] <ogra_> ?
[19:23] <ogra_> we revert exactly the landing that caused this
[19:23] <asac> someone go to an image
[19:23] <asac> run apt-get install python-autopilot, 148         python-evdev
[19:23] <asac> and tell me what it brings back please
[19:24] <cjwatson> dbarth: ok, thanks
[19:24] <asac> you guys said above you want to add python-evdev to the seed
[19:24] <asac> so can we just add python-evdev ?
[19:24] <asac> or was that something that wouldn't have worked?
[19:24] <ogra_> http://paste.ubuntu.com/7263269/
[19:24] <ogra_> there you go
[19:24] <cjwatson> asac: I said we can't back out by brute-force reverting the package, but it's pretty trivial to revert that one line from Depends
[19:24] <cjwatson> *shrug* whatever
[19:24] <asac> ok
[19:24] <ogra_> python-autopilot is still installed
[19:24] <asac> ok fine
[19:24] <asac> jfunk: !!
[19:25] <asac> so if someone wants he can prep silo with this change i guess
[19:26] <dbarth> asac: fyi, testing ubuntu2 and 516 right now, with the packages that start appearing in ppas
[19:26] <asac> anybody knows anyone beyond thomi and veebers?
[19:26] <asac> who work on autopilot?
[19:27] <dbarth> so far so good, ie ubuntu2 gets us back to work where it runs
[19:27] <nuclearbob> asac: I do some work on autopilot, but I don't have any permissions for landing stuff
[19:27] <dbarth> and 516 seems to be a far better release
[19:27] <asac> nuclearbob: who has that?
[19:27] <asac> just thomi and veebers?
[19:27] <nuclearbob> asac: I think cgoldberg did at one point, but I'm not sure if he still does
[19:29] <AlbertA> fginther: we are hitting some landing issues
[19:29] <AlbertA> fginther: ex. https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/1117/console
[19:29] <AlbertA> fginther: and https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/1116/console
[19:30] <asac> cgoldberg: nuclearbob: so what we need to do is land http://bazaar.launchpad.net/~fginther/autopilot/restore-python2-deps/revision/484
[19:31] <nuclearbob> asac: I can approve that mp if we need someone to do that, but I can't do any of the spreadsheet stuff for the train.  if cgoldberg can't, thomi and veebers I think will be on on about 30 minutes
[19:32] <asac> nuclearbob: we need someone to take autopilot in the silo and test it
[19:32] <asac> validate that nothing regressed, also check that the image doesnt regress
[19:32] <fginther> AlbertA, looking
[19:32] <nuclearbob> asac: I can run the release gatekeeper job on it, but I don't have a supported device to test the image
[19:33] <nuclearbob> asac: is the silo ready?
[19:33] <asac> no its not
[19:33] <asac> ogra, robru and friends can help
[19:33] <nuclearbob> once that's ready I can run the release gatekeeper and try to find someone with a mako to test the image
[19:34] <asac> ogra_: sergiusens: so can you drive this into a silo?
[19:34] <asac> then nuclearbob can take over
[19:35] <robru> ogra_, asac: hi, what? (was on lunch, lots of scrollback...)
[19:35] <asac> robru: autopilot landing
[19:35] <asac> a new one
[19:35] <asac> http://bazaar.launchpad.net/~fginther/autopilot/restore-python2-deps/revision/484
[19:35] <asac> thats it
[19:35] <asac> robru: can you setup such landing in spreadsheet? the AP folks are not awake
[19:35] <asac> the AP landers
[19:35] <asac> robru: its for https://launchpad.net/bugs/1308661
[19:35] <asac> so you can put that in as a comment
[19:36] <asac> lander should be thomi i guess
[19:36] <nuclearbob> asac: we're checking, but I think thomi may be out for a national holiday today
[19:36] <asac> on release day? no way
[19:36] <robru> asac, hmmm, somebody was saying not to add those back? i thought we were supposed to seed evdev instead?
[19:36] <nuclearbob> asac: I may be wrong, I'm not sure
[19:37] <asac> robru: we dont want to seed
[19:37] <asac> robru: who was saaying that?
[19:37] <asac> robru: if it was ogra then it was already discussed
[19:37] <asac> if someone else i would like to know so i can check with him why
[19:37] <ogra_> i have a package ready in a minute
[19:37] <robru> asac, i can't remember who, but it was in this channel today
[19:37] <asac> ogra_: ok so do a manual package, upload to silo and dont use the MP path? thats fine i guess
[19:38] <asac> robru: yeah, so above we discussed option to seed or add to ap
[19:38] <asac> i feel we s
[19:38] <asac> ignore
[19:38] <asac> so we add it to ap
[19:38] <asac> now
[19:39] <ogra_> line 29, i have no clue what the testplan is ...
[19:39] <robru> asac, ok, just grepped, turns out it was xnox promoting the seed change originally
[19:39] <asac> ogra_: maybe find old archived autopilot landings
[19:40] <ogra_> which seed change ?
[19:40] <asac> robru: ok
[19:40] <ogra_> oh, that
[19:40] <asac> xnox: any strong reasons you see why adding pythong-evdev to seed rather to autopilot?
[19:40] <ogra_> yeah, and i think he was right :)
[19:40] <asac> xnox: otherwise we would go for autopilot
[19:40] <asac> ogra_: explain it to me
[19:40] <asac> you didnt explain it
[19:41] <asac> also if we do seed who is doing the testing?
[19:41] <asac> thats being you then :)
[19:41] <asac> all AP tests
[19:41] <ogra_> asac, less variables ... autopilot might build stuff ... touch-meta doesnt etc
[19:41] <robru> asac, well, the benefit of the seed change is that it's faster to build, and easier to revert if there's a problem. rebuilding autopilot takes time, runs autopkgtests, etc. seed change is much faster to accomplish
[19:41] <asac> right, but still you end up being the one to test and drive the landing
[19:41] <fginther> AlbertA, 1116 ran into a transient archive update failure, 1117 ran into a failed device. I've restarted both mako tests to get results. Are either of these MPs urgent to land?
[19:41] <cjwatson> the only reason I can see for doing it in the seed is some fear that autopilot is somehow going to misbuild now when it built fine a day ago
[19:41] <ogra_> if all we need is the package on the image i prefer a seed change because it has less risk
[19:41] <asac> right
[19:41] <cjwatson> this seems vanishingly unlikely and I don't think it should be a concern at all
[19:41] <asac> i dont want this in the seed
[19:41] <ogra_> right, thats my worry
[19:42] <cjwatson> I don't think this is something you should worry about :)
[19:42] <asac> i am worried that noone is driving this landing... thats all
[19:42] <ogra_> well, we live from AP interacting with the testing infra
[19:42] <asac> nuclearbob: cgoldberg: so jfunk said you are now in charge of driving the landing
[19:42] <ogra_> if something breaks there that will cause lots of extra work
[19:42] <asac> ogra and robru are here to help you
[19:42] <nuclearbob> asac: cgoldberg is going to be afk for about 90 minutes, I can run tests but I don't have landing permissions
[19:42] <asac> nuclearbob: cgoldberg but i will not continue to micro manage this, so its now in yuour hands
[19:43] <asac> jfunk: ^^
[19:43] <ogra_> asac, ok, then i'll refrain from doing a package upload .. and let them merge the MP instead
[19:43] <asac> ogra_: seems they cant
[19:43] <ogra_> i thought cgoldberg can
[19:43] <cgoldberg> ogra_, i'm not sure.. i just know I have spreadsheet access to ask for a silo
[19:43] <cgoldberg> on launchpad lainding-team
[19:43] <sergiusens> robru: can we publish silo 5
[19:44] <sergiusens> ?
[19:44] <asac> i dont know. i feel that cgoldberg cannot go afk
[19:44] <ogra_> cgoldberg, https://code.launchpad.net/~fginther/autopilot/restore-python2-deps/+merge/216169
[19:44] <AlbertA> fginther: kgunn: urgent I suppose...but I'll let kgunn have a say on that
[19:44] <nuclearbob> ogra_, cgoldberg, asac: if somebody has created the silo, I can run the autopilot gatekeeper job, and I can find someone to run the image
[19:44] <asac> if we have a critical regression a day before release
[19:44] <ogra_> are you in autopilot hackers ?
[19:44] <nuclearbob> I am
[19:44] <robru> sergiusens, published
[19:44] <cgoldberg> i will cancel my appointment and stay to push this thorugh
[19:44] <ogra_> nuclearbob, then you should be able to approve the MP
[19:44] <elopio> ping fginther: I think the jenkins in <IP_ADDRESS> is not using the latest autopilot version.
[19:44] <cgoldberg> asac, nuclearbob ^^
[19:44] <asac> cgoldberg: what is that appointment?
[19:45] <elopio> but I don't know how to confirm that. Can you check for me?
[19:45] <asac> if its life threatening dont do it
[19:45] <ogra_> fginther, the bot doesnt like your MP btw
[19:45] <cgoldberg> asac, it's not work related.. it's for taxes.. not that big of a deal
[19:45] <asac> ok yeah. your effort will be remembered
[19:45] <jfunk> cgoldberg: thank you
[19:45] <ogra_> asac, if nuclearbob is in the right team he can approve the MP
[19:45] <cgoldberg> no
[19:45] <asac> thanks! and sorry, but it wasn't me not noticing it for so long
[19:45] <cgoldberg> np
[19:45] <nuclearbob> ogra_, asac, I am on the team and I can approve the mp
[19:45] <ogra_> so cgoldberg can go
[19:45] <asac> i dont know. someone should be the lander
[19:46] <asac> drive this
[19:46] <asac> and ensure it happens
[19:46] <asac> whoever that is
[19:46] <asac> i will be back in 10 minutes
[19:46] <asac> and will not annoy more folks
[19:46] <nuclearbob> asac, ogra_, in the past we've been told we need core-dev approval for any changes to the debian directory, can somebody get that on that mp, or are we skipping it?
[19:46] <cgoldberg> i'll stay here anyway.. i don't wanna flub this :)
[19:46] <ogra_> asac, well nuclearbob already said he will test it ... so he can be the lander too ... probably needs someone from the landing team to click through the silo stuff
[19:47] <asac> yes, as long as he knows how to preoperly test it
[19:47] <sergiusens> I will do that ogra_
[19:47] <ogra_> nuclearbob, done
[19:47] <sergiusens> ogra_: where's the MP?
[19:47] <asac> and we get another QA review that it didnt regress anything on the image (e.g. ToyKeeper etc.) then yes
[19:47] <ogra_> https://code.launchpad.net/~fginther/autopilot/restore-python2-deps/+merge/216169
[19:47] <nuclearbob> sergiusens, https://code.launchpad.net/~fginther/autopilot/restore-python2-deps/+merge/216169
[19:47] <asac> so this landing should have "needs QA sign off"
[19:47] <asac> robru: ^^
[19:47] <asac> its just too late to not do that
[19:47] <ogra_> sergiusens, though the bot doesnt like it ... failed CI
[19:47] <asac> ok bbiab
[19:47] <asac> (10-15)
[19:47] <nuclearbob> asac, I've done the testing before, and I'm working with ToyKeeper on qa sign-off for testing on the image
[19:47] <sergiusens> ogra_: I'm taking over your line; let me check the bot
[19:48] <ogra_> sergiusens, thanks :)
[19:48] <asac> nuclearbob: awesome
[19:48] <nuclearbob> okay, mp is top-approved, once it's in a silo I can start the testing
[19:48] <nuclearbob> thanks ogra_
[19:48] <asac> cgoldberg: so guess you are really off the hook :)
[19:48] <asac> thanks!
[19:48] <ogra_> thanks for taking it :)
[19:48] <robru> boiko, you got silo 6
[19:49] <fginther> sergiusens, there are 3 individual test failures.
[19:49] <sergiusens> ogra_: nuclearbob fginther something is wrong with otto? 18:27:17.742 ERROR proxies:410 - Introspect error on :1.655:/com/canonical/Autopilot/Introspection: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)
[19:49]  * ogra_ wonders why the image build takes so long
[19:49] <robru> ogra_, what's happening? are you doing a manual dput for autopilot?
[19:49] <nuclearbob> sergiusens, is that from the jenkins bot?  I'
[19:49] <robru> ogra_, silo 7 anyway
[19:50] <ogra_> robru, niope, sergiusens does the landing, nuclearbob does testing etc
[19:50] <nuclearbob> m looking at that now
[19:50] <ogra_> sergiusens, silo 7 :)
[19:50] <robru> sergiusens, nuclearbob: ok silo 7 is ready for autopilot upload
[19:51] <fginther> sergiusens, nuclearbob, there have been intermittent test failures on otto. I'll do a rerun of both that and the mako test
[19:51] <nuclearbob> fginther, thanks
[19:54] <sergiusens> nuclearbob: I'm going to be building it in the silo just in case everything goes fine (preempting)
[19:54] <sergiusens> ah, nice :-) WARNING:requests.packages.urllib3.connectionpool:Retrying (0 attempts remain) after connection broken by 'error(101, 'Network is unreachable')': /a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&output=csv
[19:54] <sergiusens> retrying works at least
[19:55] <ogra_> lovely
[19:55] <ogra_> the world falls apart right before release :)
[19:56] <sergiusens> heh; nothing like a little stress to start off the long weekend
[19:56] <ogra_> haha, yeah
[19:57] <boiko> robru: thanks
[19:57] <robru> boiko, you're welcome
[19:58] <fginther> AlbertA, the retest for those 2 mir jobs passed. As this is considered urgent I can get the MPs landed
[19:58] <AlbertA> fginther: ok
[19:58] <AlbertA> fginther: thanks!
[20:04] <jdstrand> hey, so I updated the spreadsheet fot silo 17 (media-hub) to add apparmor-easyprof-ubuntu as an additional package, then dput 1.1.17 to the ppa. it hasn't shown up yet in the ppa. do I need to do something special?
[20:04] <jdstrand> perhaps reconfigure?
[20:07] <robru> jdstrand, i'll have to reconfigure for you since you're adding a new project
[20:08] <jdstrand> robru: once you reconfigure, it'll show up in the ppa?
[20:08] <robru> jdstrand, no, once I reconfigure, it'll not freak out when it sees that you've uploaded it to the ppa yourself.
[20:08] <jdstrand> robru: does that mean I will need to reupload?
[20:09] <robru> jdstrand, mmmmmmm... did the first upload build ok?
[20:09] <jdstrand> robru: well, that's just it. it never showed up: https://launchpad.net/~ci-train-ppa-service/+archive/landing-017/+packages
[20:10] <robru> jdstrand, the silo is a standard ppa. citrain has no power to stop things uploading there. if it never showed up, then something else went wrong somewhere.
[20:10] <jdstrand> robru: and I didn't get an email saying anything went wrong
[20:10] <robru> jdstrand, not sure, try uploading again.
[20:10] <jdstrand> ok
[20:11] <jdstrand> robru: you reconfigured it though?
[20:11] <robru> jdstrand, yep, should be fine
[20:15] <ogra_> stgraber, could it be that you forgot to re-enable import-images ?
[20:16] <stgraber> ogra_: could be, checking
[20:16] <ogra_> 301 builds sine 2h or so :)
[20:16] <stgraber> ogra_: yep, fixed, will import again in 5min
[20:16] <ogra_> thanks
[20:20] <robru> alright everybody, I have to head to a doctors appointment, should be back within 2 hours. anything urgent, ping cyphermox
[20:25] <ToyKeeper> It seems like image 301 is taking a while to build.
[20:25] <ogra_> ToyKeeper, yeah, there was a cron entry accidentially disabled
[20:25] <ogra_> should be ready soon
[20:26] <ToyKeeper> (er, catching up on scrollback, didn't see the comments right before mine)
[20:26] <ogra_> :)
[20:32] <dbarth> o/ we will need that silo on line 21 in fact
[20:32] <dbarth> oxide "ubuntu2" gives us links in webapps again, but for the browser on unity8 desktop, we will need those extra branches anyway
[20:34] <dbarth> cyphermox: hi ^^  ;)
[20:36] <sergiusens> fginther: how long do those AP tests take?
[20:37] <sergiusens> nuclearbob: cgoldberg ogra_ the silo finished building btw https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=25
[20:40] <fginther> sergiusens, they're done, the otto tests passed, it's just stuck waiting for the prior run to complete - http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty-autopilot/128/console
[20:40] <fginther> sergiusens, the mako re-run hit the same 2 failures: http://s-jenkins.ubuntu-ci:8080/job/generic-mediumtests-runner-mako/6418/
[20:41] <fginther> sergiusens, the mako test had been disabled until yesterday, so I don't have any recent runs where these tests are shown two tests are shown to pass :-(
[20:42] <sergiusens> fginther: hmmm well maybe when this landed it wasn't taken into account either?
[20:43] <sergiusens> fginther: given that the guys are manually going to go through this; and that the train doesn't depend on this I'm not worried as long as there's some human judgement
[20:43] <t1mp> huh?!
[20:43] <t1mp> tim@ideapad:~/dev/landing-tests$ adb shell
[20:43] <t1mp> root@ubuntu-phablet:/# apt-get
[20:43] <t1mp> apt-get: error while loading shared libraries: libapt-pkg.so.4.12: cannot open shared object file: No such file or directory
[20:43] <t1mp> is that normal with image 300?
[20:44] <fginther> sergiusens, silly me... I do another run with trunk to get a comparison
[20:49] <imgbot> [20:49] <imgbot> [20:50] <ogra_> yay
[20:50] <asac> new image, yay
[20:50] <asac> more changes than expected, but well :P
[20:51] <davmor2> \o/
[20:51] <ToyKeeper> bsdutils?  Huh.
[20:52] <rsalveti> system settings is just a rebuild
[20:53] <pmcgowan> ogra_, does the image get noticed before its ready for download? I see it but cant get it
[20:55] <ogra_> pmcgowan, should be downloadable and in your sw upgrader
[20:55] <pmcgowan> let me try again
[20:56] <ogra_> mine is downloading already
[20:56] <pmcgowan> so it downloaded but never updated the progress bar
[20:56] <ToyKeeper> Regardless, I've got a fresh batch of manual tests as soon as it finishes flashing.
[20:56] <ogra_> i think popey or davmor2 had a bug open for that
[20:56] <pmcgowan> seems famiiar
[20:57] <davmor2> ogra_: it's a popey bug I believe
[20:57] <ToyKeeper> I think I saw that bug too.  I forget where though.
[20:58] <davmor2> ogra_: OMG Speeeddddddddddd
[21:01] <dbarth> o/ can i ask again about this silo on line 21 please? cyphermox, rsalveti, when you guys see this
[21:01] <rsalveti> dbarth: sorry, what do you need?
[21:02] <rsalveti> just a new silo?
[21:02] <rsalveti> robru: ^
[21:02] <dbarth> rsalveti: yes
[21:03] <dbarth> rsalveti: robru is off to doctor for 1.5h or so
[21:03] <rsalveti> dbarth: sure
[21:05] <rsalveti> cyphermox: can you take this one? don't remember how to get the request_id from the spreadsheet
[21:05] <rsalveti> last time I allocated a silo was a bit long ago
[21:05] <asac> dbarth: how is ubuntu2 testing going?
[21:07] <sergiusens> nuclearbob: any luck with the silo testing?
[21:07] <nuclearbob> sergiusens: it's running now
[21:07] <sergiusens> great
[21:07] <dbarth> asac: fine on desktop, still waiting for packages on armhf
[21:08] <dbarth> asac: same for 516, it's taking ages
[21:08] <asac> dbarth: are the packages building?
[21:08] <dbarth> oh yes, 3h for armhf already
[21:08] <asac> dbarth: do you guys have ways to cross build this stuff for development?
[21:08] <asac> (just curious)
[21:08] <dbarth> we're building this thing twice on each platform, to get the codecs we miss for videos
[21:09] <dbarth> it's cross-building afaict
[21:09] <dbarth> ah, but not for devel
[21:09] <asac> wait
[21:09] <rsalveti> probably not in the builder itself
[21:09] <asac> its cross building?
[21:09] <dbarth> we don't have the horse power for that
[21:09] <asac> i doubt that its cross building in ppas
[21:09] <asac> anyway
[21:10] <dbarth> on ppa i see mentions of gcc-arm-none-eabi thing, but maybe that's normal and native; not sure here
[21:10] <dbarth> theat's the normal build process, so this is not a factor of risk, at least
[21:21] <asac> dbarth: which silos are the builds running in?
[21:24] <jdstrand> robru: so, I could never get my apparmor-easyprof-ubuntu to go into silo 17. everything looked fine, but it wouldn't show up. I then uploaded to the security ppa and copied it over
[21:25] <jdstrand> robru: that seems to be working
[21:25] <dbarth> asac: silo 1 for ubuntu2, and 516 went into the security-team proposed ppa
[21:25] <asac> not silo testing?
[21:25] <asac> why that?
[21:25] <dbarth> asac: if you want just webapps fixed, i'm fine, but if you want webbrowser as well, i will need that extra silo in line 21 ;)
[21:26] <asac> i surely didnt think we would intend to land one version through one machinary and the other through another, but guess... :)
[21:26] <dbarth> asac: 516 is the extra bet, ubuntu2 is in silo2
[21:26] <asac> no mind
[21:26] <asac> sure
[21:26] <asac> but should just have gone to a silo
[21:26] <asac> well. doesnt matter
[21:26] <asac> just would have been good to keep both on the same radar
[21:26] <asac> for coordination reasons
[21:26] <dbarth> plan is top bin. copy to a silo once ready in that other ppa
[21:26] <dbarth> if i rememer the discussion from earlier
[21:26] <ogra_> as long as it lands in -updates in the end :)
[21:26] <dbarth> yeah
[21:27] <asac> but why did we not upload to a silo?
[21:27] <asac> directly?
[21:27] <dbarth> armhf packages seem to be close now
[21:27] <asac> if we bincopy it from secyurity ppa?
[21:27] <dbarth> asac: that's a source package, cause that was safer than a branch revert
[21:27] <dbarth> asac: to do 501 + 1 liner cherry pick
[21:27] <dbarth> bzr501 rev. + 1 line of patch
[21:28] <asac> jdstrand: dbarth: i just dont understand why we use two different machinaries to land the two versions
[21:28] <dbarth> we use silo-1for the safe bet
[21:28] <asac> sounds odd not to keep both on the same radar
[21:28] <jdstrand> asac: it is just how it worked out
[21:28] <asac> so by accident?
[21:28] <jdstrand> asac: we don't have MP autocommits yet
[21:28] <jdstrand> no it was intentional
[21:28] <asac> jdstrand: yhou can upload packages to silos
[21:28] <asac> at least you would have an entry in the landing sheet
[21:29] <jdstrand> right, but chris can't
[21:29] <asac> where we can get the QA etc. organized
[21:29] <asac> and tracked
[21:29] <jdstrand> and oxide is a monster
[21:29] <asac> ok thats the reason
[21:29] <asac> so when wwill the silo1 build be finished?
[21:29] <jdstrand> so I have him upload oxide to the security ppa, then I copy the packages to a silo
[21:29] <asac> righyt