#ubuntu-ci-eng 2014-06-02
<imgbot> === trainguard: IMAGE 60 DONE (finished: 20140602 03:35) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/60.changes ===
<Mirv> cihelp jenkins full, can't even launch the clean jobs because also those fail from out of disk space.. :(
<popey> bug 1325467 for anyone on #60 who has an alarm any time soon.
<ubot5> bug 1325467 in unity8 (Ubuntu) "Alarms appear underneath greeter #60 mako" [Undecided,New] https://launchpad.net/bugs/1325467
<popey> if you can confirm pls
<sil2100> Morning!
<ogra_> hey hey
<sil2100> Now what the heck happened with test results of the recent images!
 * sil2100 looks at what has changed
<ogra_> seems there are timeouts in the tests with split greeter
<ogra_> sil2100, the landing wasnt complete, the unity8 bit only landed yesterday
<sil2100> hmm
<sil2100> ogra_: the split greeter one? How was it not complete? Not everything was present in the silo?
<ogra_> not sure why, but unity8 only made it into the archiove yesterday
<sil2100> Ah, hm
<sil2100> Interesting, as I thought the faux-package bumping was no longer required - maybe some autopkgtest failures?
<ogra_> https://launchpad.net/ubuntu/utopic/+source/unity8/7.87+14.10.20140530.1-0ubuntu1
<sil2100> Uh, something broke the CITrain backend I just noticed\
<ogra_> not sure what happened, but yeah, could be autopkgtests taking long
<sil2100> Holy sh... ci-train jenkins seems to be 'broken'
 * ogra_ isnt sure if the "published" date in the proposed pocket entry is actually the date when it entered proposed 
<sil2100> https://ci-train.ubuntu.com/
<sil2100> cihelp: hi guys! Does anyone know why all the ci-train executors are dead?
<sil2100> cihelp: as per https://ci-train.ubuntu.com/ <-
<ogra_> anyway ... there are now timeouts in the tests ... Saviq was fearing we could have issues with unlocking with the new greeter ... not sure it is that
<ogra_> (i didnt inspect to deeply yesterday, just made sure we get an image with the landed unity8)
<Saviq> ogra_, if we affected it, it would be *all* of them, is that the case?
<sil2100> Saviq: there are like many many test failing now, around 120 failures
<ogra_> Saviq, nope ... but only -app tests
<Saviq> ogra_, that shouldn't be the split greeter then, means we're indeed unlocking the screen if we can pass any of them
<ogra_> Saviq, thats the changeset after which it started ... seems the ailo only half migrated on friday ... http://people.canonical.com/~ogra/touch-image-stats/59.changes
<popey> sil2100: bug 1325467 is interesting
<ubot5> bug 1325467 in Unity 8 "Alarms appear underneath greeter #60 mako" [High,Triaged] https://launchpad.net/bugs/1325467
<sil2100> I don't see anything else that could have caused the failures
<popey> in that snap decisions appear underneath the greeter
<sil2100> In the changes
<Saviq> popey, commented on it already
<sil2100> popey: oh!
<ogra_> sil2100, well not sure if dbus-x11 is a dep of the greeter split
<popey> morning Saviq â»
<Saviq> ogra_, it is
<Saviq> popey, that's indeed fallout of split greeter
<ogra_> ok
<popey> nice one
<ogra_> Saviq, and the xlibs ?
 * sil2100 is too tired today to feel any pressure regarding the test results
<Saviq> ogra_, I believe so, it did bring some weird things with it
<ogra_> hmm, probably deps of the dbus-x11 package
 * Saviq looks
<Saviq> ogra_, my apt history.log entries from testing the silo: http://pastebin.ubuntu.com/7571253/
<Saviq> ogra_, so yeah, the x things are pulled in by split greeter
<ogra_> yeah, looking at the dependency chain of dbus-x11 shows similar results
<sil2100> ogra_: yeah, and in the ubuntu-touch-session changelog I only see the greeter added, so no new explicit deps have been filed
<Saviq> ogra_, direct dep for dbus-x11, too http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/933/debian/control#debian/control
<sil2100> I was chatting a lot with Mike on Friday, but I can't remember if he'll be around today or not...
<sil2100> Since he might be traveling
<Mirv> sil2100: I reported the jenkins problem to cihelp in the morning
<Mirv> sil2100: it's out of disk space, and also trying to free up disk space with that one job fails with not enough disk space..
<ogra_> i havent seen him at the bomb evacuation ... so he might not have hit one of the delays
<ogra_> (but he might just have been at another part of the airport)
<ogra_> so we have chances he traveled fine and is around later today
<ogra_> sil2100, my suspicion is more towards the infrastructure though
<ogra_> that we are either lacking something for these failed runs or that something is different from how mterry and Saviq tested
 * ogra_ bets on the latter 
<popey> t1mp / bzoltan do you have an ETA on when the fix for 1322527 will land in the image?
<popey> (morning btw)
<ogra_> popey, it is ready ...
<ogra_> bzoltan, pinged yesterday (assuming you talk about gallery)
<popey> Ready != on my phone â»
<Saviq> ogra_, now that I look through the diff, I'm not sure why dbus-x11 is a direct dep, we'll have to wait for mterry to comment :|
<ogra_> wheer is the bot ?
<Saviq> but then dbus-test-runner is used in a test, and isn't a build-dep...
<ogra_> Saviq, well, did you run all AP tests or just a selection ?
<popey> ubot5 is here.
<ogra_> then it doesnt like you :)
<ogra_> bug #123456
<ubot5> bug 123456 in xine-lib (Ubuntu) "podcast crashes amarok" [Undecided,Fix released] https://launchpad.net/bugs/123456
<sil2100> Mirv: morning! Now this is unexpected! Didn't he had the 'free disk space' job set up to be ran periodically?
<popey> common
<ogra_> hmm
<sil2100> Mirv: I suspect it was in plans and never happened, right?
<ogra_> bug 1322527
<ubot5> bug 1322527 in Ubuntu Terminal App "Terminal app shows no text in #44 on mako" [Critical,Triaged] https://launchpad.net/bugs/1322527
<Mirv> sil2100: I don't know, the apt-get clean job was at least disabled. that's probable.
<ogra_> Saviq, if you ran them all it must be something that is different in the infrastructure ...
<sil2100> Let's wait for CI to appear and resolve the problem
<Saviq> ogra_, indeed, we didn't run the whole suite with the latest builds, I got pressed for pushing the button...
<sil2100> Mirv: for now I disabled auto-refresh of the spreadsheet as it was failing because of the backend being broken
<Saviq> ogra_, in any case, http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/140/ was a run some time before, but nothing much changed that would warrant an  all-over-the-place fail
<sil2100> (mostly because of jenkins dying in the middle of some configuration save operation)
<sil2100> Saviq: do you know of any differences in how tests are ran at the gatekeeper and in smoketesting?
<Saviq> sil2100, in theory there shouldn't be
<Saviq> sil2100, they all use phablet-test-run by now
<sil2100> Since psivaa is not around today, we also basically have no CI to support us
<Saviq> sil2100, did you have a chance to try and reproduce the issue locally?
<sil2100> Saviq: not yet, but will try in a moment once my image flashes
<Saviq> sil2100, doing the same
<ogra_> Saviq, it seems to hit largely the same tests/app that fail  in both image that have the full landing (59 and 60)
<ogra_> sil2100, ^^^
<ogra_> the only one i dont see in the first image is clock app ... all the others are roughly the same
<Saviq> hmm "via upstart-app-launch", are we monitoring tedg's rename? it didn't happen yet did it?
<Saviq> looks like launch_click_package got screwed somehow
<Saviq> the common denominator
<Saviq> dialer fails on phonesim, so another issue
<Saviq> gallery has a sh*tload of sqlite errors and then an SDK exception ??
<bzoltan> popey: t1mp: ogra_: the fix is in the silo3
<sil2100> Saviq: yeah, so the name change didn't land yet if anything
<sil2100> hm, grrr, device problems
<Saviq> sil2100, ogra_, btw python2 is gone from the device, but phablet-test-run seems to be using it still
<popey> oh jeez
<ogra_> Saviq, for some deb tests thats ok ... it should pull it in
<ogra_> (if needed)
<Saviq> ogra_, well, sure, unity8-autopilot pulls it in... until it won't :P
<ogra_> Saviq, gallery is something else ... thats older, ignore it
<Saviq> aargh this whole click test setup is just crazy complex and delicate :|
<sil2100> Saviq: you mean, the downloading, looking up versions etc?
<Saviq> sil2100, yeah
<ogra_> Saviq, and thats fully in sergios hands ... who is on vac iirc
<ogra_> fun ...
<Saviq> huhm
<ogra_> and i think rolling back is also no option ...
<Saviq> my phablet-test-run is being prevented by apparmor ?!
<ogra_> oh ?
<popey> balloons mentioned that happened to him too last week iirc
<Saviq> although that would have ended up in the smoke logs if that was the case
<ogra_> yeah
<popey> Saviq: have you run "phablet-config autopilot --dbus-probe enable" ?
<Saviq> popey, ah
<sil2100> :)
<Saviq> this shit is CRAZY
<Saviq> may I remind https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1262879
<ubot5> Ubuntu bug 1262879 in Ubuntu CI Services "There should only be one, documented, way to run tests on devices" [Undecided,Confirmed]
<popey> heh
<Saviq> and yeah, phablet-config just hangs...
<popey> https://wiki.ubuntu.com/Touch/Testing is the "canonical" page
 * Saviq reboots
<popey> it takes a while
<popey> patience
<Saviq> ah probably rebuilds apparmor policies?
<popey> yes
<popey> so worse if you have lots of apps installed
<sil2100> Saviq: yeah, it can take even a minute sometimes
<ogra_> well, we usually only test preinstalled apps
<popey> takes more than a minute here
<ogra_> for these it should take 20-30sec only
<popey> alan@deep-thought:~$ time phablet-config autopilot --dbus-probe enable
<popey> real	1m36.286s
<ogra_> woah
<popey> but takes less time on subsequent runs
<popey> alan@deep-thought:~$ time phablet-config autopilot --dbus-probe enable
<popey> real	0m4.027s
<ogra_> yeah
<ogra_> it is the initial profile creation that takes ages
<ogra_> security has plans to ship some pre-created ones in the future
 * ogra_ goes to make meeting coffee
<ogra_> well seeing ToyKeeper's mail it seems the issues are really AP centric ... doesnt look like she found many issues in dogfooding
<ogra_> (a unity crash though)
<Saviq> I wonder if the unlock script is used at all in the end... and if it works...
<Saviq> maybe it's unreliable
<sil2100> Saviq: you mean like during the app tests?
<sil2100> Since there it should unlock the screen once I guess, if it would fail then all tests should fail
<Saviq> sil2100, I know :|
<ev> Mirv: where are you seeing ENOSPC? https://prodstack-nagios.admin.canonical.com/cgi-bin/nagios3/extinfo.cgi?type=1&host=ue-prodstack-ci-train-jenkins-0 suggests we have plenty, so maybe this is in a tmpfs?
<Saviq> so yeah... of course it's fine locally :|
<ogra_> well, all tests do fail for the affected apps
<ogra_> the 4 that you see passed there are systemsettle, setup and teardown
<ogra_> they always work
<ogra_> its not "all apps" but if it fails its "all tests" of an app
<ogra_> sil2100, teds renaming didnt land yet, did it ?
<sil2100> ogra_: no
<ogra_> 04:27:02.746 INFO _launcher:116 - Attempting to launch application 'com.ubuntu.calendar_calendar_0.4.296' with URIs '' via upstart-app-launch
<ogra_> ok
<sil2100> ogra_: after Mike's landing it required a rebuild
<sil2100> ogra_: so no one published it afterwards yet - it's not marked as tested even
<ogra_> because i see this for all failing tests
<ogra_> RuntimeError: Timed out while waiting for application to launch
<sil2100> Yeah, I was suspecting this to be the problem as well, but it doesn't seem so
<ogra_> ...
<ogra_> right, but the apps dont seem to start properly
<ogra_> Saviq, another thing i noticed is that your ram usage is quite high with the new greeter
<ogra_> its stable ... but high
<ogra_> 200M for unity8 ... another 90 or so for the greeter
<sil2100> How did it look like before?
<Saviq> calendar is OK locally ;|
<ogra_> i think i remember far below 200 for unity8 ...
<ogra_> 170 or 180 or so
<Saviq> ogra_, if anything, it should go down in unity8
<ogra_> and we didnt have a greeter
<Saviq> ogra_, can you file a bug please? we'll investigage
<ogra_> yeah
<Saviq> investigage...
<Saviq> nice word
<ogra_> :)
<ogra_> Ursinha, go away ! you are on vacation !!!
<Ursinha> lol
<ogra_> :)
<Ursinha> I'm not here :)
 * ogra_ pretends he hasnt seen anything 
<ogra_> *whistle*
<Ursinha> :P
<sil2100> ;p
<Mirv> ev: https://ci-train.ubuntu.com/computer/%28master%29/executors/5/causeOfDeath
<Mirv> ev: and first it was in this job output before the jobs also started failing to even start: https://ci-train.ubuntu.com/job/landing-010-2-publish/8/console
<ogra_> clientlogs touch (run.py:2245): WARNING **: Unable to connect to Upstart bus: Cannot autolaunch D-Bus without X11 $DISPLAY
<ogra_> hmm
<ogra_> 04:27:01.320 DEBUG __init__:187 - Patched home to fake home directory /home/phablet/autopilot/fakeenv/tmpyt7h1kxo
<ogra_> error: XDG_RUNTIME_DIR not set in the environment.
<ogra_> oha !
<sil2100> Uhh?
<sil2100> WTF
<ogra_> there seem to be more env issues
<Saviq> dialer = OK
<ogra_> initctl: Rejected send message, 1 matched rules; type="method_call", sender=":1.22" (uid=32011 pid=2242 comm="/sbin/initctl set-env HOME=/home/phablet/autopilot") interface="com.ubuntu.Upstart0_6" member="SetEnv" error name="(unset)" requested_reply="0"
<ogra_> rejected ...
<Mirv> ogra_: meeting
<ogra_> yeah
<Saviq> ogra_, sil2100, not sure what to say... I followed the standard testing process and everything's fine over here :|
<ogra_> Saviq, yeah, as i suspected ... most likely the infra
<ogra_> 04:27:01.079 WARNING emulators:26 - The ubuntuuitoolkit.emulators module is deprecated. Import the autopilot helpers from the top-level ubuntuuitoolkit module.
<Saviq> yeah, that's just a deprecation warning, though, should not affect anything
<ogra_> yeah, i was just mentioning it in the meeting :)
<ogra_> (abusin IRC for copy/paste)
<t1mp> popey: I'm checking the bug and our landing..
 * ogra_ wonders if dbus gets started differently with the new greeter 
<ogra_> not using the upstart job ...
<t1mp> bzoltan: what's the status of this landign? https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/landing_28-05/+merge/221199
<t1mp> popey: ^ the fix for terminal-app is included there^. We are currently trying to land it
<popey> kk
<popey> in silo3 bzoltan said earlier?
<t1mp> bzoltan: ^ the changelog of that landing is not complete, since we merged staging more stuff is in there
<t1mp> popey: yes, that's the one. trying to land it since last week.
<t1mp> popey: feel free to try a phablet-config writable-image --ppa ppa:ci-train-ppa-service/landing-003
<brendand> lots of ap test failures today
<popey> t1mp: will do!
<ogra_> sil2100, oh, are we in traincon until we get proper tests again ?
<ogra_> i think we shouldnt land anything til thats resolved
<sil2100> ogra_: for now we can't land anything anyway ;)
<sil2100> :D
<sil2100> (jenkins b0rken)
<ogra_> (well, probably the gallery fix, but i wouldnt go further)
<ogra_> yep, i know
<ogra_> but it might come back during the day
<bzoltan> t1mp:  what do you miss there?
<ogra_> brendand, yeah, some issue with the environment in the infrastructure ... and everyone who could help is either traveling, on vacation or otherwise not around
<sil2100> I wonder if Paul will be around today, or he also got stuck somewhere in transit
<sil2100> ev: do you know if Paul will be able to pop up today?
<t1mp> bzoltan: r1087, 1088 of staging
<ev> sil2100: I'm not sure which day he is taking as swap. What do you need him for?
<ogra_> ev, 150 failing AP tests :)
<ogra_> seems the environment is messed up and we need someone to help investigating ... tests pass fine locally
<ogra_> ah, well, i'm lying ... only 120
<t1mp> bzoltan: I think only those two are missing
<sil2100> ev: right, we would need someone with smoketesting infra experience/access to help us figure out what's wrong with the environment in smoketesting
<sil2100> ev: which is causing many app failures (which are false positives)
<ev> the whole team is meant to have access and understanding. We're constantly fighting against the silo effect. Unfortunately though we are very short staffed today.
<ogra_> yeah, like almost everyone
<ev> Siva is on swap. Vincent is out sick. I suspect a fair amount of the US contingent will be taking swap, but it's hard to tell without the new HR system :)
<ogra_> 04:27:01.287 INFO logging:45 - str: Set the value of an initctl environment variable. Arguments ('/home/phablet/autopilot/fakeenv/tmpyt7h1kxo',). Keyword arguments: {}.
<ogra_> initctl: Rejected send message, 1 matched rules; type="method_call", sender=":1.22" (uid=32011 pid=2242 comm="/sbin/initctl set-env HOME=/home/phablet/autopilot") interface="com.ubuntu.Upstart0_6" member="SetEnv" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")
<ogra_> error: XDG_RUNTIME_DIR not set in the environment.
<ogra_> clientlogs touch (run.py:2236): WARNING **: Unable to connect to Upstart bus: Cannot autolaunch D-Bus without X11 $DISPLAY
<ogra_> thats a summary of th re-occuring errors we see ... usually its these three lines
<ogra_> it started with the split greeter ... we assume the infra needs something updated for the new setup
<bzoltan> t1mp: I will fix it
<ogra_> (not sure what though ... and which versions of which tools are installed there)
<bzoltan> ogra_: sil2100: Mirv: is there any news about the UITK landing from the Silo3?
<ogra_> bzoltan, well, jenkins is dead ... nothing can land
<bzoltan> ogra_: what an excuse :)
<ogra_> bzoltan, and we have issues with the AP tests for the last two images
<sil2100> bzoltan: as per description on the spreadsheet, waiting on it to be resolved :)
<ogra_> so even if jenkins was working we would need to stop the line to get the infra back in shape
<sil2100> No worries, we'll land as soon as we can! We want to have the infra working and some test doubts solved first
<bzoltan> sil2100: ogra_: ohh.. I missed the yellow cell ... and added a new landing line. Should I delete it?
<ogra_> no, but you wont get a silo atm
<ogra_> adding entries is fine, they just wont be processed
<ogra_> oh, wait
<ogra_> well, probably better remove it so you get auto-update if you add it the next time
<ogra_> sil2100, does the "please dont fill new landings" apply to the pending page too ?
<ogra_> (/me thought we just cant process silos)
<sil2100> bzoltan: no no, leave it :) We'll just assign it once possible
<bzoltan> ogra_: how long this stop will last? Do I have time to rebuild the landing MRs in the silo?
<ogra_> sil2100, the text should be more clear ... it sounds like you shouldnt even add to the pending page
<sil2100> ogra_: you can fill in new landings, let me change the description as it's well... from the moment I didn't know what happened
<ogra_> yeah
<Mirv> sil2100: ok we should be more alive now..I'm restaring a few threads
<popey> t1mp: that fixes terminal for me, thanks.
<ogra_> bzoltan, up to sil2100 what and if he wants to land stuff even after jenkins is back up
<ogra_> bzoltan, we cant really get test results atm ... thats the second stopper imho, though sil2100 might still want to move ... he's the authority here :)
<sil2100> Mirv: so, what was the problem in the end?
<bzoltan> ogra_: sil2100: a full rebuild would need an hour
<Mirv> sil2100: old backups cleaning not working correctly
<ogra_> bzoltan, well, i think you have time ... it will take a while til we can get someone from the infra team who knows the AP testing infra enough ...
<sil2100> bzoltan: you can rebuild, it'll give me some time to try and recover from our earlier problems
<sil2100> (just remember that the SS does not auto-update itself for now)
<ogra_> hmm, i see a dbus-launch process on my flo ... we never used dbus-launch before
<ogra_> seems we are running two dbus-daemon processes for the phablet user
<ogra_> one from the dbus upstart job, the other started via ssh-agent by the greeter
<ogra_> phablet   1350  0.0  0.0   2700   188 ?        Ss   Jun01   0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session ubuntu-touch-session
<ogra_> phablet   1354  0.0  0.0   3360   604 ?        Ss   Jun01   0:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
<ogra_> phablet   1450  0.0  0.0   4308  1540 ?        Ss   Jun01   0:08 dbus-daemon --fork --session --address=unix:abstract=/tmp/dbus-wwyt1Zs6rI
<ogra_> the first two are spawned by the greeter ... the last one is our normal dbus ...
<t1mp> popey: great, thanks for testing :) I hope it will land today
<ogra_> heh, the boot animation is quite tiny on the flo screen
 * ogra_ just enabled it 
 * sil2100 sighs
 * sil2100 has to hack through jenkins to get the backend back to some usable state
<Mirv> sil2100: so the file that got corrupted is causing problems?
<sil2100> Mirv: yeah, I need to use the temporary jenkins job to at least recover some parts of the config so that I can reassign it once again :) Doing that
<Mirv> ogra_: could you say 'ack' on another "drop using the transitional package, instead use the real one that has been there since trusty": https://ci-train.ubuntu.com/job/landing-010-2-publish/lastSuccessfulBuild/artifact/packaging_changes_signon-ui_0.16+14.10.20140530-0ubuntu1.diff ..
<ogra_> Mirv, ackedy ack :)
<Mirv> ack! :)
<ogra_> Mirv, we still need to go over the seed one day ... i meant to do that at the sprint with you before i realized you wouldnt be there the same week
<Mirv> ogra_: indeed. so many renames.
<ogra_> yeah
<Mirv> ogra_: I was going to be there on the same week, but I got moved..
<ogra_> which probably made sense ...
<Saviq> ev, hey, do you need guinea pigs for the airline maybe?
 * sil2100 is grateful for the "cyphermox test" jenkins job
<sil2100> :)
<Saviq> sil2100, are we any closer to finding the issue in smoke?
<ev> Saviq: absolutely. Shall I get you on the list of people we need to engage with once we have the kinks knocked out of staging?
<Saviq> ev, please do!
<ogra_> Saviq, i see two sessuon dbus daemons ...
<Saviq> ogra_, oh
<Saviq> ogra_, well, wait
<Saviq> ogra_, the greeter has one, the session has one
<sil2100> Saviq: a little bit... but I guess it would be best if we had someone wit haccess here
<Saviq> ogra_, or are you seeing two on the usser?
<ogra_> Saviq, http://paste.ubuntu.com/7572007/
<ogra_> there is also one running as lightdm ... that should be the greeter owned one
<ogra_> the ssh-agent one is new
<ogra_> i'm just re-flashing 60 to get a clean env ...
<ogra_> (another 15min to download over my slow line)
<Saviq> ogra_, I don't have ssh-agent here
<brendand> does there happen to be a way, currently, that we can duplicate a test run from a jenkins job?
<ogra_> Saviq, on 59/60 ?
<Saviq> ogra_, 60, yes
<ogra_> hmm
<ogra_> that was 59 above
<Saviq> oh wait
<Saviq> FUX
<ogra_> ps aux|grep dbus|grep session|grep phablet
<Saviq> greyback, remember what I did in the room on Friday afternoon that we said it's gonna become interesting the next time I try to use it?
<ogra_> i think thats from lightdm ... i cant find any change in the landing that would make it use dbus-launch
<Saviq> ogra_, ignore everything I said since this morning... I had 55 flashed all the time :|
<Saviq> don't ask
<ogra_> oh my
<greyback> Saviq: yep!
<Saviq> greyback, guess what :P
<greyback> Saviq: noooo
<sil2100> OOoh
 * sil2100 runs some tests on his 59 then
<ogra_> i think we could easily go with dbus-launch but would need to drop the upstart job in the session *and* make sure that the dbus socket address ends up in the file in ~/.cache/upstart/dbus-session ... thats what the tests rely on
<mhr3_> sil2100, can  you check on 009? prod it so it gets into proposed?
<ogra_> seb128, do you remember of the top of your head where dbus-launch is called from in a lightdm session startup ? ... we end up with http://paste.ubuntu.com/7572049/ after the new greeter landed on the phone ... and somehow the AP tests get confused not finding the right dbus
<sil2100> mhr3_: hi, the hud one? Let me try :)
<ogra_> i fail to find where dbus-launch is called
<seb128> ogra_, I would say Xsession.d scripts
<ogra_> oh, i dont even have the dir on the old image !
<seb128> ?
<seb128> do you have it on the new one?
<ogra_> ah, no ... i'm to sleepy still ... its there
<ogra_> root@ubuntu-phablet:~# grep dbus /etc/X11/Xsession.d/*
<ogra_> root@ubuntu-phablet:~#
<seb128> dbus-x11 ships /etc/X11/Xsession.d/75dbus_dbus-launch
<ogra_> but no dbus stuff
<seb128> but I guess that binary is not installed on touch
<seb128> not sure how it's started there then
<ogra_> seb128, right, that landed together with the new greeter stuff
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/59.changes
<seb128> ok
<seb128> so that explains why you get a new one
<ogra_> in the old world we use an upstart job
<ogra_> now there are both
<seb128> right
<ogra_> though i wonder why the apps work fine ... they should get confused too
 * ogra_ waits for the flash to finish to try some things 
<seb128> well, do the apps need to use the session bus?
<ogra_> AP tests do
<ogra_> and they get the address from a fil that is pointing to the secondly started dbus
<ogra_> *file
<ogra_> i guess the session ises theone dbus-launch started
<ogra_> *uses
<ogra_> and the secondly started one is just cruft
<ogra_> seb128, thanks ! that got me on the right track i think
<seb128> yw!
<seb128> good luck debugging it
<ogra_> heh
<ogra_> well, i'm fine with dropping the upstart job ... but we need to create that file somehow so AP can read it to find the bus
<sil2100> But hm...
<sil2100> I'm running clock-app tests here now on my device and so far they seem to look ok (we'll see once they're finished)
<sil2100> Shouldn't it also make them fail on my device?
<sil2100> Oh, wait
<sil2100> hm, I got 5 failures, it's still less than what I should expect
 * ogra_ disables the dbus upstart job 
<ogra_> lets see if the session still comes back
<ogra_> hmm
<ogra_> doesnt
<ogra_> so lets try the other way round
<ogra_> disabling the Xsession.d script
<ogra_> yeah
<ogra_> thats fine
<ogra_> fun, i still get two dbus-daemon processes ... but they use the same address
<ogra_> sil2100, mount -o remount,rw / && mv /etc/X11/Xsession.d/75dbus_dbus-launch /home/phablet/ && mount -o remount,ro / && reboot
<ogra_> sil2100, then run your tests again
<sil2100> hah, ok, running
<ogra_> not sure what it uses dbus-x11 for ... i think we need mike to tell if it is important
<Mirv> sil2100: I'll probably mark line 9 as Landed manually, since it didn't pick that up
<sil2100> Ok :)
<sil2100> Mirv: thanks!
<sil2100> bzoltan: did you see the error in silo 003?
<Mirv> also, that means that the first Qt SRU to trusty finally is available to users <- bzoltan
<Saviq> sil2100, ogra_, in any case, tests work locally on 60, too
<Saviq> and whoa new calendar!
<popey> â»
<popey> Sans vomit. â»
<ogra_> Saviq, right ... but in the infra i think the tests try to connect to the wrong session dbus
<Saviq> lol
<ogra_> Saviq, i'm pretty sure /etc/X11/Xsession.d/75dbus_dbus-launch confuses them
<Mirv> mhr3_: do you have any better sightings than we do about the hud trusty SRU? it's nowhere to be found. it's not rejected either according to the queues.
<Saviq> mhm :|
<ogra_> i'm just not sure how to solve that without dropping the dbus-x11 dep
<Saviq> I did ask mterry whether it's correct that it pulls all that
<Saviq> and he said yes, didn't dig more, though
<ogra_> my session works just fine removing that file
<sil2100> Here it works fine as well, but tests didn't finish yet
<ogra_> i also see a session dbus running for lightdm
<ogra_> (which used dbus-launch before)
<ogra_> phablet@ubuntu-phablet:~$ ps aux|grep dbus|grep -v upstart|grep session
<ogra_> lightdm   1193  0.0  0.0   3892  1260 ?        Ss   10:29   0:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
<ogra_> phablet   1395  0.1  0.0   4320  1612 ?        Ss   10:29   0:01 dbus-daemon --fork --session --address=unix:abstract=/tmp/dbus-vrhmrTD7DQ
<mhr3_> Mirv, how would i know?
<Mirv> mhr3_: just in case it has been discussed before by eg. sil2100. I think I saw already last week that the line claimed "in no known space or time" for the hud 14.04+14.04.20140528, and it's surely isn't on its way to trusty at the moment
<ogra_> hmm
<ogra_> interesting
<mhr3_> Mirv, i rebuilt it since, but no idea what happened to it
<ogra_> if i put the file back in place i see that the greeter session doesnt use dbus-launch at all
<bzoltan> sil2100:  I have seen and I still see... But I do not get it
<cjwatson> Mirv: I rejected hud from trusty unapproved last week because its changelog delta made no sense and was no good for SRU tracking
<cjwatson> I talked to Pete Woods about it
<Mirv> cjwatson: ok, I thought this "round 2" was already after that, but maybe not
<Mirv> this was published on Thursday
<cjwatson> Mirv: hm, I don't remember dates, but I don't see it in unapproved, at least
<Mirv> cjwatson: does that changelog sound to you as not making sense or better: https://launchpad.net/~ci-train-ppa-service/+archive/landing-009/+sourcepub/4202156/+listing-archive-extra ?
<ogra_> Saviq, sil2100 ... so with dbus-x11 in place it not only starts one by dbus-launch and one via upstart ... it also starts the upstart driven daemons twice ... http://paste.ubuntu.com/7572218/
<cjwatson> Mirv: looks more plausible though I haven't diffed it against the old one
<cjwatson> Mirv: LP logs suggest that this package was copied from silo 9 to an "sru-staging" PPA
<Saviq> ogra_, ok, so obviously that's not good, we should get rid of the dbus-x11 dep
<ogra_> Saviq, right, but i dont know what else this could break
<cjwatson> Mirv: https://launchpad.net/~ubuntu-unity/+archive/sru-staging apparently
<Mirv> cjwatson: yes, the SRU:s have went through that and then it'd be copied from there to archives
<ogra_> Saviq, i see no ill effects when using teh system but i suspect some new greeter features i dont know about might be broken then
<cjwatson> Mirv: no sign of any copies after that
<Mirv> I wonder if that step never really happened
<Mirv> cjwatson: that's what I thought too
<ogra_> there must be a reason why dbus-x11 was added as a dep
<Mirv> maybe didrocks could again find it this time...
<Mirv> (moved to #ubuntu-touch)
<sil2100> ogra_: we need mterry to explain himself then...
<ogra_> sil2100, well, it would most likely only break new greeter features ... not existing ones
<ogra_> sil2100, so if he is off and doesnt show up today we should remove the dep and he can add it himself later again
<ogra_> that would prevent us from rolling back the whole ... in case he is off the whole week or some such
<ogra_> this is to big to easily roll it back ... but we also cant live without working AP tests for multiple days
<ogra_> (or even a week)
<sil2100> I wouldn't want to roll it back
<ogra_> sigh sigh sigh ... and *none* of his changelogs mention *any* of the dependency changes
<sil2100> Especially that it doesn't cause visible regressions on the phone itself
<sil2100> geh
<sil2100> I'm really considering automating this dependency changes
<ogra_> note that i wont ack any packages anymore where there are dep changes that are not mentioned ...
<sil2100> I mean, including a forceful changelog entry about deps being changed
<ogra_> this really makes life to hard
<sil2100> Right
 * sil2100 adds this to his todo list for today
<ogra_> sil2100, right, the ci should preferably do that ... but until thats possible people really need to care for tehir shit
<sil2100> ogra_: I wonder if we would have any means (if we got the right people) to try and you know, forcefully remove the dbus-x11 package from one of the machines and running some failing tests again
<ogra_> sil2100, first of all we need to find people where it breaks for them at home :p
<ogra_> seems Saviq cant reproduce the failures at home
<sil2100> Yeah ;) I can't as well
<sil2100> The 5 failures I got seem to be unrelated
<ogra_> right
<ogra_> and additionally i might even be on the wrong track ... while it is wrong to have multiple session dbuses running that might not cause the infra issue at all (it is very likely but we can only prove it when fiddling with the infra)
<ogra_> i would like to have at least some proof ...
 * ogra_ hopes plars is not off today ... that would help a lot
<ogra_> as he can log in to a device, manually remmove the file and re-run
<sil2100> Right
<sil2100> We would need at least one person with direct access to some of the machines
<ogra_> yep
<ogra_> hmm, so looking at the greeter code mike makes a lot use of gdbus
<dbarth> o/ line 39 for a new silo request
<ogra_> aha ...
<ogra_> /usr/bin/unity8-greeter-wrapper ... line 55 to 58 ... there he needs to use dbus to set some ofnono/pulse stuff ... and for that he uses the session bus
<ogra_> (which is the wrong session bus anyway i guess)
<ogra_> ah, no, that talks to the lightdm session bus
<ogra_> sigh, that landing is so gigantic
 * ogra_ tries to read the unity8 source changes but thats a *lot*
<sil2100> Yeah... I wonder if it wouldn't just be better to wait for mterry
<sil2100> But hm, we have no means of checking if he'll be around today
<ogra_> well
<sil2100> Robert or Kevin would know
<ogra_> sil2100, so here is another quick and dirty idea
<ogra_> since the silos and landing are stuck anyway ... how about i do a dput upload that only drops the dep ... we build an image and see if it fixes it
<ogra_> that costs 3-4h and we'll know for sure after that
<ogra_> and is easy to roll back
<popey> sil2100: have you droped mterry a mail? He replied to one of my bugs 4 hours ago.
<ogra_> would need Saviq to merge my change back and forth i guess ...
<sil2100> popey: oh, let me try that, he might be in transit now though
<popey> calendar shows him being a patch pilot today.
<sil2100> ogra_: hmmm... right, but this seems REALLY dirty
<sil2100> Not sure if it's worth it?
<ogra_> well, it wastes the least time
<Saviq> mterry should be around soon
 * ogra_ was just thinking we could do something while no landings can happen anyway
<ogra_> ah, cool
<Saviq> like within an hour or two
<sil2100> ogra_: let's wait a little bit then
<ogra_> then ignore my hackish idea :)
<sil2100> Ok, I have to jump now for that lunch
<Saviq> let me see what were his travel plans
<Saviq> oh actually
<dbarth> sil2100: hey, not sure if you saw my request above
<Saviq> he only *just* flew out of Malta
<sil2100> dbarth: let me get back to you after lunch
<Saviq> mterry is here: http://flightaware.com/live/flight/DLH1277/history/20140602/1100Z/LMML/EDDF
<Saviq> :|
<sil2100> Might take a bit
<Saviq> ogra_, back to your idea
<sil2100> Saviq: *sigh*
<ogra_> heh
<sil2100> Ok, ogra_ I leave the decision up to you if you think it's worth it, I would try getting some info on if Paul will be here today
<ogra_> i could quickly drive to frankfurt and ask him in person :)
<Saviq> he _will_ have 3h layover in FRA
<sil2100> Since if Paul would be around, we could do this without any hacks even
<dbarth> sil2100: ok
 * sil2100 goes now REALLY
<Saviq> I knew landing this on a Friday evening was not a great idea!
<ogra_> even if he has a 3h layover expecting him to do any work during travelling is evil
<Saviq> of course
<Saviq> I just meant that he might pop in, not that we should rely on that
<ogra_> Saviq, yeah, thats why i wanted to land on mon/tue ... execting fallout
<ogra_> (i think i told you in the bar already)
<Saviq> ogra_, when sil2100 and robru rounded me up at Friday afternoon, it didn't look like they wanted to wait :D
<ogra_> heh, yeah, my pusyness infected everyone ... sorry for that
<ogra_> i should have stopped asking for it on thursday
<Saviq> ogra_, in any case, I can't identify the need for dbus-x11 in that merge
<ogra_> *pushyness ... not pussyness
<ogra_> :P
<Saviq> ;)
<Saviq> ogra_, so let's just go for it - upload a dbus-x11-- version, I'll merge around
<ogra_> ok
<dpm> sil2100, Mirv, bzoltan tells me that the UITK fix for https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1322630 is already in the archives. Am I correct to assume it'll land in the next image (61)?
<ubot5> Ubuntu bug 1322630 in ubuntu-ui-toolkit (Ubuntu) "Setting i18n.domain breaks translation" [Undecided,Confirmed]
<ogra_> dpm, if it is not in 60 it wont be in 61 either ... landing is broekn
<ogra_> we are in TRAINCON-0
<ogra_> (see the ML)
<plars> ogra_: sil2100: I'm off today, but I'll be around on and off. I'll get a run going right now on 60 with that. Basically I should just remove dbus-x11 right?
<ogra_> plars, rm /etc/X11/Xsession.d/75dbus_dbus-launch
<plars> ogra_: ok, will do
<ogra_> plars, that should be sufficiaent
<ogra_> removing the package would get you dependency issues i guess
<ogra_> plars, i think sudoku_app should be a good test to re-run ... it was rock solid before for quite some time and only broke after this landing
<ogra_> Saviq, i'll hold back the upload for that ^^^
<plars> ogra_: do you want a full rerun or just a few to spot check it?
<ogra_> since we can get some real data
<dpm> ok, thanks ogra_
<ogra_> plars, whatever causes theleast work for you
<Saviq> ogra_, I'll do a run too
<ogra_> plars, if a full re-run is easier do that ... just one app that was known stable before the split would do too though
<plars> ogra_, sil2100: ok, I have sudoku running on one with that file removed right now
<ogra_> great
<plars> looking good so far :)
<ogra_> yay
<plars> ogra_, sil2100: sudoku passed completely
<ogra_> ok
<ogra_> i guess that proves the theory
<Mirv> dpm: sil2100: nope, there's just some confusion, the UITK build is still in the silo
<plars> I'll run a few other tests but looks good
<ogra_> thanks !
<plars> ogra_, sil2100: I tried a couple more and it seems good still :)
<ogra_> ok, i'll upload the dependency change and we can roll a new image
<ogra_> mterry can then sort out any possible fallout when he is back at work
<tedg> ogra_, With the dependency change do we drop out of traincon-0 ?
<ogra_> tedg, if we see the tests pass ... but even then there are jenkins issues with the silos
<tedg> Uhg, okay.
<ogra_> yeah, it came all together :)
<ogra_> (if the shit hits the fan it pours ... or how they say)
<ogra_> murphys monday ;)
<tedg> Heh, I just want to finally land the UAL name change.
<tedg> Tired of blocking other fixes.
<cjwatson> tedg: I haven't quite landed click yet for that but it should hopefully be on its way soon; there's an entry in the spreadsheet now
<tedg> cjwatson, Why don't you put it in silo 18?
<tedg> cjwatson, Then we can land them all at once. It has to be retested anyway.
<tedg> I'm guessing that silo will be blocked by traincon though. So that'll have to get resolves.
<tedg> resolved
<cjwatson> tedg: have a couple of other things in the same landing, ideally
<cjwatson> tedg: would rather test it independently
<tedg> cjwatson, Okay, if you want to test with the ubuntu-app* binaries you can get them in silo 18.
<Wellark> thostr_: landing-015 TESTING DONE.
<Wellark> now, we would really need that landed even though we are on TRAINCON-0
<Wellark> dpm and cwayne are preparing an image for upcoming expo
<Wellark> and getting that MP in would update the translations for chinese (tested that also)
<Wellark> the MP's are really small
<Wellark> so getting them through QA review would be easy
<ogra_> Wellark, even if we wouldnt be in TARINCON-0 ... jenkins is messed up
<Wellark> :(
<Wellark> dpm: ^
<ogra_> he knows
<dpm> thanks Wellark, it seems we'll need to wait until the infrastructure is back online
<ogra_> the unity8 fix to lift TRAINCON-0 is already building ... once we have test results we can lift TRAINCON-0
<t1mp> Wellark, dpm phablet-config writable-image --ppa ppa:ci-train-ppa-service/landing-018 for the demo images?
<t1mp> not ideal..
<ogra_> (but thats still a few hours)
 * Wellark sees what is in landing-018
<Wellark> dpm: but anyway. once landing-015 lands you will have the chinese translations
<Wellark> I tested them and they at least seem to work :)
<dpm> ok, excellent, thanks
<Wellark> dpm: seems that the pin unlock dialog is not translated though
<Wellark> but all those strings are coming from unity8 ATM
<Wellark> + I'm sure you have the sims unlocked anyway at the expo
<sil2100> Jenkins messed up again?
<ogra_> sil2100, dunno, was it ever fixed ?
 * ogra_ hanst heard any info on it except that it was broken this morning
<ogra_> sil2100, but worse, the archive is broken ... unity8 FTBFS due to broken deps of dbus-test-runner on gvfs-backends
<sil2100> ogra_: Mirv mentioned later that it got fixed, so I updated the header to indicate it being fixed
<ogra_> oh, ok
<sil2100> Well, before changing to TRAINCON-0 ;p
<sil2100> uh
<ogra_> seems -proposed is briken
<ogra_> *broken
<cjwatson> the archive isn't broken, ldb/libsmbclient is broken
<sil2100> Sucks, since I would like this to propagate already!
<cjwatson> just you know to clarify
<ogra_> i dont really get the relation when looking at the excuses page but accoing to pitti and cjwatson it has to do with libsmbclient
<sil2100> cjwatson: thanks :)
<ogra_> well, cant propagate something that doesnt build
<cjwatson> you can see it on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt by searching for ": ldb"
<cjwatson> this sort of thing is not on excuses
<ogra_> ah
<cjwatson> You can see the real error by attempting "apt-get install dbus-test-runner gvfs-backends libsmbclient samba-libs" in utopic-proposed
<cjwatson>  samba-libs : Depends: libldb1 (< 1:1.1.17~) but 1:1.1.17-1 is to be installed
<cjwatson> => samba merge needed
<ogra_> :(
<ogra_> ans zul just mentioned he wont have time to do that soon
<cjwatson> but if you can get a silo working then we can do a unity8 build that way
<ogra_> *and
<ogra_> well, according to sil2100 silos are working again
<ogra_> seems i missed the announcement
<cjwatson> it'll need webops assistance
<ogra_> Saviq, could you merge and push my diff to unity8 trunk ?
<cjwatson> get them to go to /+edit-dependencies on the relevant PPA and change "Ubuntu dependencies" to "Basic"
<sil2100> We have 2 silos free, so if needed we can assign
<cjwatson> and VERY IMPORTANT remember to get that switched back to "Proposed" before using the silo for anything else
<ogra_> sil2100, right, but i suppose we need that merged into the tree first
<ogra_> or should i just dput ?
<sil2100> ogra_: oh, why? Can't we propose a MR, assign a silo with it and build?
<sil2100> ogra_: since it's unity8, right?
<cjwatson> the vanguard in #webops should be able to sort you out with that
<ogra_> sil2100, well, there sits a source package in proposed now
<sil2100> Ah, k, right
<cjwatson> you'll have to make it be a newer version than the one currently in -proposed, I expect
<cjwatson> but -0ubuntu3 would do, dput to a silo
<ogra_> right
<ogra_> no change rebuild ...
<sil2100> ogra_: let me create a silo with unity8 as a source package then
<cjwatson> well, maybe you could do a source copy from the primary archive, and copy binaries back, but not 100% sure that would work
<ogra_> sil2100, yeah
<Saviq> ogra_, sil2100, so I'm not doing anything in trunk yet, right?
<cjwatson> as I say you should just need to get the silo reconfigured by a webop first
<ogra_> Saviq, right, lets do itt dput all the way
<Saviq> +1
<cjwatson> or actually, if you're in the team that owns the silo you can do it yourself
<ogra_> Saviq, and you merge back once we are successfull
<cjwatson> https://launchpad.net/~ci-train-ppa-service/+archive/landing-NNN and there's an "Edit dependencies" link in the top right
<oSoMoN> hi, I have a webbrowser-app branch that has debian packaging changes, Iâd welcome a review of those particular changes if a qualified ubuntu developer could take a look: https://code.launchpad.net/~osomon/webbrowser-app/official-api/+merge/221436
<sil2100> cjwatson: oh, let me check after assignment if I can do it then
<cjwatson> sil2100: Yeah, you should be able to
<cjwatson> sil2100: Like I say, just make sure it's reverted before reusing the silo
<sil2100> oSoMoN: hi! Will try taking a peak in a moment
<sil2100> cjwatson: right, will write it down as a 'must do' somewhere
<oSoMoN> sil2100, excellent, thanks!
<sil2100> cjwatson: switching to 'Basic' then
<ogra_> ++
<cjwatson> yep
<bzoltan> sil2100: May we release the SIlo8, as it is only a desktop package
<ogra_> i'm ready once you blow the horn :)
<sil2100> bzoltan: sure, on it!
<sil2100> Just trying to finish everythig else
<sil2100> ogra_: so, https://launchpad.net/~ci-train-ppa-service/+archive/landing-019 should only have Basic deps
<sil2100> ogra_: you can try dputting there
<ogra_> on its way :)
<ogra_> (takes a bit over 2Mbit)
<ogra_> unity8 grew quite a lot since i touched the package last
<ogra_> (which was admittedly quite a while ago)
<sil2100> ogra_: can I have a packaging +1 from you? Custom make check for testing, seems ok: https://ci-train.ubuntu.com/job/landing-008-2-publish/lastSuccessfulBuild/artifact/packaging_changes_qtcreator-plugin-ubuntu_3.0.1+14.10.20140602-0ubuntu1.diff
<ogra_> sil2100, hmm, not mentioned in the changelog ... but ack for now
<sil2100> asac: so, it might be a bit hard with the TRAINCON-0 situation, since I see that Omer is not here, same for Julien
<ogra_> we really need to train people more that they mention their packaging changes in the changelogs ... we will never be able to find such stuff in a year in case we need to
<sil2100> asac: (since he's on his way back home it seems)
<asac> sil2100: well, today is fine
<asac> sil2100: just dont land things that are not fixing the issues
<sil2100> ogra_: yeah, I guess the changelog entry about 'unittests' is more or less covering it
<asac> today most are on swap or something, so we just dont land stuff
<sil2100> ogra_: could be more explicit I guess
<sil2100> asac: right, not a big deal as we have a fix for the issue
<ogra_> sil2100, yeah, since it only talks about adb and lsb-release
<sil2100> Since ogra_'s suspicion seemed to be the right one :)
<asac> sil2100: TRAINCON-0 has the QA availability explicitely designed to be restricting landing capacity
<asac> if they are not available it means landing capacity is even more reduced :)
<sil2100> asac: ;)
<asac> guess just the fix for this issue can land
<asac> and tomorrow we can see
<asac> if selen comes on we can check
<ogra_> asac, we need a unity8 build and an image build/test to prove it ... then we can resume normal operation
<asac> maybe she can test 1 or 2 other silos that folks think are good and impotrtant
<asac> ogra_: sure, but that is part of the fix for the regression
<asac> no?
<ogra_> yes
<asac> if so it can land, but we should try to get extra testing on it
<asac> at best selene
<ogra_> but a regression that only affects the infra
<asac> if not someone of us should take it and test the hell locally
<asac> ogra_: doesnt matter, we are blind
<ogra_> she wont be able to test anything
<asac> she can test that nothing regressed further
<asac> e.g. zero test failures locally
<ogra_> the only thing that could (and did) help was plars trying the fix on the infra directly
<asac> and then we can land this and see if infra recovers
<asac> sure
<asac> so try land the fix, wait for plars
<ogra_> asac, that will just waste time, we have a plan already ... selene can test the imge we need for testing the infra fix
<asac> but ensure that we dont regress locally
<asac> ogra_: she can also test the landing silo
<asac> but if its just the fix landing, then we can also it after
<asac> especially if the landing can be backed out
<ogra_> pushing another block in that keeps us from producing an image with the fix will just delay everything for no good reason
<asac> if it creates further destructivty
<asac> well
<asac> not sure who is the lander
<asac> that guy should triple test the APs
<asac> until we have someone like plars we cannot test in infra anyway
<ogra_> asac, i'm the lander
<asac> as we have to resurrect that
<asac> well, then you should run all APs
<asac> that might get affected
<asac> as usualy
<asac> go through the landing plan etc.
<ogra_> dude
<asac> and if we are scared
<asac> we can double test
<ogra_> we wont be done before wed. if you follow that plan
<asac> there is a process
<asac> of landing
<ogra_> we have hadd plenty of testers already
<asac> we shouldnt skip that process
<asac> of the build you made? you ran through the testplan?
<ogra_> verified in the lab that the issue is fixed
<ogra_> there is no build yet
<asac> well, do a package build
<ogra_> it took half the day to even get to this point
<asac> ensure that that thing doesnt regress the image
<ogra_> it just started
<asac> if the component touched is unity8
<asac> https://wiki.ubuntu.com/Process/Merges/TestPlan/unity8
<asac> thats the plan
<ogra_> i cant do a package build because the archive is screwed
<asac> if its an isolated fix for the regression you dont need QA sign off
<asac> during TRAINCON-0
<asac> ogra_: so we have to wait till archive is fixed anyway, no?
<cjwatson> no, the archive is not screwed
 * ogra_ has the feeling asac doesnt understand the coomplexity 
<asac> you are right, i dont know what the landing is about
<cjwatson> one important package is broken and gets in the way, but we have a workaround permitting a package build
<asac> maybe elaborate
<cjwatson> please stop saying the archive is screwed :)
<ogra_> well, for me it is :P
<cjwatson> points in the wrong direction
<asac> so whats the 10k summary of the situation?\
<ogra_> asac, there is a wrong dependency in the split greeter landing
<asac> all i knwo is that unity8 got broken ... and that last week we had systemd related issues in archive
<ogra_> dropping that makes everything work as expected
<cjwatson> nothing to do with systemd
<asac> ogra_: so unity8 has to land with a new dependency?
<ogra_> asac, the prob is that a build dep is broken in proposed so we need to sneak around the issue to not FTBFS
<ogra_> asac, no, with the old dep model it used before
<ogra_> well
<ogra_> in fact the new package unity8-greeter has to drop an X11 dep
<ogra_> the test has been verified on all sides
<sil2100> asac: yeah, so once we get unity8 released, we can kick a new image and get stable test results
<asac> ok, i leave it to cjwatson and you to land the dependency fixes
<ogra_> right
<ogra_> the point is that we can only verify it against the leb
<ogra_> *lab
<asac> just dont start other landings until we have seen that the stable image is stable in infra too
<asac> or if that doesnt work, apply traincon-0 rules for other landings going forward
<sil2100> asac: right, no worries
<ogra_> having some QA guy install the package locally wont reveal a thing
<sil2100> That's why I'm actually waiting
<asac> until we have the infra ready :)
<ogra_> we need an image that runs through the full lab testing
<ogra_> right
<asac> sure
<asac> then do that
<sil2100> I'll work in the meantime on the changelog thing
<asac> and other landings are not happening unless QA is there :)
<ogra_> the future setup will give us exactly whet we need
<asac> and we can apply TC0
<asac> so the current issue is that we wait for plars?
<ogra_> no
<asac> ok, but would be good if we get the devices resurrected today still, right?
<ogra_> plars, actually jumped in today (even though he is on vac.) and helped us to verify the fix works
<asac> ok cool
<ogra_> now we just need an image with the fix
<ogra_> the rest will be automatic
<asac> plars: just take the swap day later this week then.
<asac> plars: even if you dont work fully
<ogra_> swap day for interrupted swap day
<asac> ogra_: ok, so we are just waiting for the image?
<ogra_> :)
<ogra_> right
<asac> not sure what the panic mode is about then
<ogra_> well, first for the package build
<asac> sounds all going well
<asac> hehe
<plars> Do I need to test something else? I can be around for whatever's needed to get this going
 * ogra_ slaps asac 
<asac> plars: guess later some hand holding ones we have the image and want to see it going through infrA
<asac> plars: but definitely go off for a while :)
<cjwatson> hmm, I think the samba build failure may be as simple as a missing build-dep
<plars> asac: thanks, but not necessary. It didn't take that long
<asac> plars: your call. for me it would be valid to take another day or at least half due to heroic actions
 * asac stops distracting folks
<ogra_> asac, its all fine ... stop stirring up :P
<sil2100> So far the build is going well, I see i386 and amd64 finished already
<ogra_> sil2100, yay
<plars> It's not a big deal. I had already planned to at least keep an eye out for results today
<ogra_> asac, come to the landing meeting if you want details
<ogra_> we'll give you a summary ;)
<asac> well, sil was concerneda bout lack of QA presence... so answer to that is: no big deal, landings dont continue unless we either have working infra or QA shows up to double check
<asac> L(
<asac> ogra_: thanks!
<ogra_> :)
<sil2100> Righto ;)
<ogra_> sil2100, hmm seems the silo has build all needed bits
<sil2100> ogra_: you want to use silo publishing? Or copy it yourself?
<sil2100> :)
<ogra_> lets use publishing
<sil2100> ogra_: since we can run the 'watch only' build and then press publish
<sil2100> Let me do that then
<ogra_> ah, i missed the watch-only part
<ogra_> sorry, could have done that while waiting
<popey> sil2100: I won't be around for the landing call, feel free to ping me after if there's some testing needed
<sil2100> Yeah, well, no problem as it will finish almost instantly now
<ogra_> popey, well, dogfooding 61 would be nice (once thats built)
<sil2100> ogra_: published
<sil2100> popey: ok, sure :)
<ogra_> great ... i'll kick an image as soon as it migrated
<sil2100> popey: we'll drop you an e-mail if anything
<sil2100> ogra_: thanks!
<popey> fire it at the list, I'll see it
<Wellark> sil2100: CI-SNCF claims unity-notifications is not part of any silo, but it's in landing-015
<sil2100> Wellark: let me take a look
<sil2100> hm, right
<Wellark> sil2100: and same for indicator-network
<sil2100> Damn, Didier's code is sometimes a bit complicated
<ogra_> i might be 5min late to the meeting ... some real life issues ...
<ogra_> unity8 is still in proposed ...
<ogra_> waiting for the next publisher i guess
<sil2100> Ok
<sil2100> I'm trying to add that auto-dependency changelog mention
<sil2100> In principle it should be easy, but in the end it's a bit hard!
<bfiller> does anyone know if the VPN configuration for Jenkins has changed? I can't connect anymore. Was working fine on Friday
<sil2100> bfiller: did you try reconnecting? I remember once I had a similar issue which resolved itself after a reconnect (but that might have been temporary bogus)
<bfiller> sil2100: I've tried multiple times and restarted network-manager as well
<sil2100> Ok, then unrelated
<sil2100> bfiller: I guess pinging cihelp might help, but not sure if there's anyone available as for today
<bfiller> sil2100: ok, can you connect?
<sil2100> bfiller: q-jenkins seems to work fine for me
<sil2100> s-jenkins as well
<retoaded> bfiller, you don't happen to have two VPN connections open do you? I have seen something similar when trying to establish a second VPN connection.
<retoaded> It works with the first connection but not so much with a second connection.
<bfiller> sil2100, retoaded: finally connected after 10 or so tries :) I did not have any other connections open
<sil2100> bfiller: phew, good to hear that!
<retoaded> bfiller, ack. was just throwing that out there as a possibility. glad to hear it's working now.
<cjohnston> retoaded: fwiw, I just had to restart openvpn in order to access..
<retoaded> cjohnston, ack.
<sil2100> ogra_: let's skip today's meeting, as no one seems to be around - robru is still in transit, plars is awayish etc.
<sil2100> (no one else connected after 7 minutes)
<sil2100> I'll still stick-around until we get the image unblocked, and besides we also basically don't have any US support today
<ogra_> sil2100, ok ... i'll just kick the image once unity migrated
<sil2100> So I'll try extending my stay a bit
<sil2100> ogra_: excellent, I'm watching rmadison as well :)
<ogra_> (and i'm alone in the meeting ... had just connected when you pinged)
<sil2100> Yeah ;)
<sil2100> I've been alone there for like 7 minutes
<sil2100> Felt really sad and lonely
<ogra_> heh, yeah, lots of tumbleweed
<ogra_> there we go
<ogra_> build triggered
<sil2100> ogra_: \o/
<stgraber> just added a click landing to the spreadsheet, would be great if we could get a silo (so we can get it built and tested, landing would have to wait until things are resolved)
<imgbot> === trainguard: IMAGE 61 building (started: 20140602 16:30) ===
<popey> bug 1325649 anyone else getting that?
<ubot5> bug 1325649 in indicator-messages (Ubuntu) "Notification displays phone number instead of a name" [Undecided,Confirmed] https://launchpad.net/bugs/1325649
<dbarth> sil2100: still around for that line 39 silo?
<sil2100> dbarth: righto! I guess it's safe now
<sil2100> Assigning in a moment
<dbarth> ah cool
<dbarth> sil2100: thanks sir!
<sil2100> dbarth: it seems assigned o/
<sil2100> cjwatson: how does the ldb/libsmbclient situation look like right now? Since I see it's still causing problems
<dbarth> ok, building now
<pete-woods> can someone help me figure out why my HUD silo packages are "in no known space and time"? :)
<pete-woods> https://ci-train.ubuntu.com/job/check-publication-migration/17381/console
<pete-woods> (silo #9)
<ogra_> did they assign you the multidimensional silo ? :)
<pete-woods> I guess I got the twilight zone silo :)
<ogra_> hehe
<ogra_> are you sure your package actually built ?
<pete-woods> pretty sure, yeah
<pete-woods> https://launchpad.net/~ci-train-ppa-service/+archive/landing-009/
<brendand> sil2100, i have a weird job failure in jenkins - can you have a look?
<sil2100> brendand: which jenkins and what kind of failure? :)
<brendand> sil2100, https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/1026/console
<popey> Saviq: i have a unity8 crash... "Your computer does not have enough free memory to automatically analyze the problem and send a report to the developers" - what can I do?
<sil2100> brendand: I think I can't help out here, you would need someone from CI I guess
<sil2100> brendand: try poking cihelp
<brendand> sil2100, cihelp doesn't seem to be in the channel
<sil2100> brendand: when you say cihelp anyone in the CI team on the channel will get a ping
<sil2100> So if there's no vanguard, cihelp is the way to ping
<sil2100> :)
 * sil2100 jumps out to the apothecary
<ogra_> but you said cihelp plenty of times
<ogra_> that will have pinged cihelp a lot already :P
<retoaded> ans this cihelp person will take a look at it but makes no guarantees :-)
<boiko> rsalveti: hi, I was trying to build telepathy-ofono in landing-002, but it failed with a dbus-test-runner dependency fail, do you think that could be a temporary issue and thus I should try a rebuild?
<sil2100> :)
<ogra_> boiko, a lot failed on that today
<ogra_> boiko, foundations seems to be working on a fix ...
<sil2100> Right, it still seems to be an issue
<ogra_> well, the proper fix would be to merge samba
<ogra_> but seems the server team doesnt have time for that yet
<sil2100> Ok, I go do some house cleaning in the meantime, hope the image will be done soon :)
<ogra_> well, i havent gotten a build failure mail
<ogra_> so i suspect its still building fine :)
<popey> uh, init crash
<ogra_> geez, dons say "crash" now you scared imgbot
<popey> hah
<popey> with a few apps open, basically the phone became completly unstable, unity crashed, then init, mediascanner..
<ogra_> well, might be related to bug 1325580
<ubot5> bug 1325580 in unity8 (Ubuntu) "after split greeter landing unity8 and the greeter consume a lot more memory" [Undecided,New] https://launchpad.net/bugs/1325580
<popey> could be
<popey> phone is red hot
<ogra_> sil2100, there seems to be an issue with the image builder ... might take a bit longer til we get an image
<boiko> ogra_: thanks
<sil2100> ogra_: thanks...
<ogra_> sil2100, new build running
<sil2100> ogra_: ah, so we had to start from scratch?
 * ogra_ is surprised imgbot copes with that ... i dont think i have added any logic for that 
<ogra_> sil2100, the builder was hung tonight and left a stale lockfile around
<ogra_> so the builds only got queued but never processed
<ogra_> you can sadly only see that if you dig deep into its guts ... which i only started when i noticed that it hadnt processed for a while ...
<sil2100> ugh
<ogra_> (well, in fact infinity dug ... i just moaned :P )
<sil2100> Thanks! :)
<sil2100> Ah that infinity..!
<ogra_> :)
<ogra_> if i ever talk about "murphys monday" on a monday morning, please kill me
<ogra_> this has certainly become true ...
<ogra_> what could go wrong went wrong :P
<sil2100> Murphys Monday and Fridays
<sil2100> Murphys weeks!
<ogra_> heh
<pmcgowan> imgbot, how is 61 coming
<ogra_> haha
<ogra_> pmcgowan, should be there soon
<pmcgowan> it worked!
<pmcgowan> ;)
<ogra_> imgbot, stunt
 * imgbot rolls on its back and purrs
<ChickenCutlass> lol
<ogra_> thats the only command it knows :)
<ogra_> (to check if its alive... beyond that its a dumb shellscript ... well a few)
<ogra_> after that disaster day and *all* infrastructure steps (from silos, to package builds to image builds) failing for that one fix i'm not watching it closely til it is done though
<ogra_> s/not/now/
<ogra_> brilliant typo :P
<imgbot> === trainguard: IMAGE 61 DONE (finished: 20140602 20:45) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/61.changes ===
<ogra_> \o/
 * ogra_ falls dead after 12h of handholding that sh*t
 * popey notes #61 is a bit broken in the welcome screen. bug 1325738
<ubot5> bug 1325738 in unity8 (Ubuntu) "indicators don't show on #61 mako" [Undecided,New] https://launchpad.net/bugs/1325738
<ogra_> thats weird
<ogra_> i have them here with dbus-x11 removed
<ogra_> (on flo though)
<popey> ah, try nexus 4
<ogra_> popey, sigh
<popey> i see telephony-service-indicator crashes
<ogra_> oh man
<ogra_> so even though we might get working AP results now we will likely have to revert
<ogra_> :(((
<ogra_> this is depressing
<ogra_> especially after investing so much time
<pmcgowan> popey, same here, telephony-service-indicator and indictor-network-service crashes
<popey> yes
<popey> filing bug now
<popey> bug 1325740
<ubot5> bug 1325740 in telephony-service (Ubuntu) "Telephony service crash on #61 mako" [Undecided,New] https://launchpad.net/bugs/1325740
 * ogra_ waits for the OTA on flo to finish 
<ogra_> i definitely didnt have any indicator issues with 60
<popey> me either
<ogra_> when removing the dbus-x11 activation
<popey> 61 has the same issue
<popey> sorry, flo 61 has the same issue
<popey> and manta
<ogra_> could you try reverting urfkill ?
<popey> got a deb I can use?
<ogra_> https://launchpad.net/ubuntu/+source/urfkill/0.5.0+20140512.223520.8d05071-0ubuntu1/+build/6006821
<popey> ok
<ogra_> yeah, flo has it here too
<popey> do i need all 4 files?
<popey> guess i dont need the -dev
<popey> nvm, done
 * popey reboots
<ogra_> only urfkill
<ogra_> sigh
<ogra_> nope
<popey> nope, that didnt fix it
<ogra_> SIGH
<ogra_> istalling dbus-x11 does though
<Saviq> ok... so that's why ;|
<ogra_> phablet@ubuntu-phablet:~$ ps ax|grep -c dbus
<ogra_> 12
<ogra_> GRRR
<ogra_> (well, a lot false positives)
<ogra_> phablet@ubuntu-phablet:~$ ps ax|grep -c dbus-daemon
<ogra_> 7
<ogra_> Saviq, i guess we need to roll back tomorrow then :(
<ogra_> i dont get why the heck removing the dbus starting helped then
<ogra_> /usr/bin/dbus-launch and /etc/X11/Xsession.d/75dbus_dbus-launch are the only relevant files dbus-x11 shiips
<Saviq> ogra_, well, there's a bunch of deps that installing dbus-x11 brings isn't there?
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/61.changes
<ogra_> only dbus-x11 was dropped
<ogra_> the only explanation i have that mterry somehow abuses dbus-launch to start the indicators
<Saviq> ogra_, hmm that's weird http://people.canonical.com/~ogra/touch-image-stats/59.changes
 * ogra_ removes /etc/X11/Xsession.d/75dbus_dbus-launch
<Saviq> ogra_, leave it, I'll dig a bit, and if nothing comes up, we'll roll back first thing tomorrow (if only we had a big "roll back" button somewhere)
<ogra_> yeah, that might take another two days :(
<ogra_> Saviq, so i definutely have the indicators when removing /etc/X11/Xsession.d/75dbus_dbus-launch
<Saviq> ogra_, so it might be part of dbus-x11 is good, but the second part isn't?
<ogra_> that points definitely to some code that abuses dbus-launch for the indicator start
<Saviq> ogra_, yeah, I'll be looking through the MPs now
<pmcgowan> ogra_, I dont have that file here?
<ogra_> well, dbus-x11 is for starting x11 sessions with dbus attached
<ogra_> pmcgowan, no, beacuse this image build was solely to remove it
<ogra_> pmcgowan, since it breaks the world ...
<ogra_> pmcgowan, but it seems the other relevant file from that package is in use
<pmcgowan> I see. will wait for the fix then
<ogra_> "<ogra_> /usr/bin/dbus-launch and /etc/X11/Xsession.d/75dbus_dbus-launch are the only relevant files dbus-x11 shiips"
 * ogra_ doesnt belive there is a fix ... unless someone implements dbus-launch standalone 
<Saviq> the only thing I'd like to know is how no-one experienced those issues before... :(
<ogra_> Saviq, there must be code using dbus-launch
<ogra_> in the new greeter
<ogra_> in one of the gazillion packages that landing consiste of
<ogra_> *consisted
<Saviq> ogra_, only mention I could find so far https://code.launchpad.net/~mterry/unity8/split/+merge/213149 - in a test :|
<ogra_> right, i was digging this morning and couldnt find anything either
<Saviq> 54	+emits indicator-services-start
<Saviq> that's how indicators are started
<ogra_> http://paste.ubuntu.com/7575846/
<ogra_> i dont see any other relevant file except these two
<ogra_> Saviq, hmm, did that actually get emitted ?
<ogra_> and did unity8-greeter-init actually get executed (before the actual session started)
<Saviq> ogra_, start on unity8-greeter-started
<ogra_> i would guess "unity8-greeter-started" never gets emitted
<Saviq> if (!QProcess::startDetached("/sbin/initctl emit --no-wait unity8-greeter-started")) {
<ogra_> does it reach that point ?
<Saviq> yeah, it's just in main()
 * ogra_ wonders how to even acess the lightdm init env 
<Saviq> ogra_, /proc/foo/environ
<Saviq> ogra_, on unity8-greeter
<ogra_> well, i want to get initctl output ...
<Saviq> yeah, get UPSTART_SESSION from there
<Saviq> ogra_, also, /var/lib/lightdm/ is persistent now - is home of the greeter (for upstart logs etc.)
<ogra_> yeah
<Saviq> ogra_, but yeah, there's just no dbus in the greeter session
<ogra_> ps axu |grep dbus-daemon|grep lightdm
<ogra_> i see one
<ogra_> properly started
<ogra_> but !!
<ogra_> gdbus may use dbus-launch
<ogra_> so the calls in the script might not work
<Saviq> yeah, I was thinking this might be a dbus auto-triggered activation or so
<ogra_> yeah ...
<ogra_> so we would need to split dbus-x11 into dbus-launch and a package that only contains the Xsession.d file
<Saviq> ogra_, or well, not rely on Xsession to launch dbus for us...
<ogra_> which would be a) super silly and b) cause a lot of other work to make sure X11 sessions dont break
<ogra_> we cant ...
<Saviq> ogra_, the greeter wrapper already manually starts upstart...
<Saviq> we can't?
<ogra_> /etc/X11/Xsession.d/ scripts will be processed if they exist
<Saviq> right, but if we only need them for the greeter session to have dbus (which seems to be the case now)
<Saviq> if we start dbus ourselves in the wrapper script, why can't we do that?
<ogra_> they will be processed by *any* non system upstart session
<Saviq> still don't get it
<Saviq> unity8-greeter-wrapper
<ogra_> the prob is not to get dbus up ...
<ahayzen> Hi, is it just me that cannot change the volume while the screen is locked on #61?
<ogra_> it starts fine as long as dbus-launch is there
<ogra_> ahayzen, no. it is broken
<Saviq> ahayzen, there's all kinds of issues with images 58+, it's not recommended to use (or report bugs against, for that matter)
<ogra_> Saviq, our prob is that Xsession.d processing starts a second dbus
<ahayzen> ogra_, Saviq, ah thanks just wanted to check it was an known issue, i'll check it has a bug
<Saviq> ogra_, yes, let's remove x11-dbus, as we did
<Saviq> ogra_, and then start dbus manually in the greeter session (so Xsession.d processing isn't involved)
<ogra_> Saviq, splitting the dbus-x11 package into dbus-launch and the Xsession script in separate packages would be the solution
<ogra_> and make dbus-x11 depend on dbus-launch
<Saviq> ogra_, ok, I punt, you obviously know better about this
<ogra_> then make the greeter depend on dbus-launch
<ogra_> the greeter works fine with only the dbus-launch binary
<Saviq> kgunn, yeah, we're analyzing here
<Saviq> (re: dbus-x11 dep)_
<Saviq> ogra_, ok, shall I start preparing rollback packages? I assume we don't want to try and do that split right now, but instead prepare for it and do another round of testing to land the split again?
<AlbertA> camako: ^
<ogra_> Saviq, yeah, i fear we have to ... even though it looks like the AP tests are all fine now
<ogra_> or at least the ones that have run yet
<ogra_> (gallery breakage is unrelated, the fix is stuck due to traincon)
<camako> AlbertA, thanks
<Saviq> ogra_, ok, I'm doing that, there's just too much time wasted on this already
<Saviq> ogra_, I'll go through the MPs and prep reverts and put them in a sile
<ogra_> yeah
<Saviq> silo
<ogra_> ok, sil can process that tomorrow, i'll explain to him in the meeting
<Saviq> since I don't have dput into silos anyway, and that'll be cleaner than to dput anyway
<Saviq> -anyway
<ogra_> Saviq, the issue will be that proposed is wonky ...
<ogra_> same thing we had with the dep dropping today
<ogra_> the workaround of not building against proposed worked for one package ... not sure if thats a clever idea for a whole silo
<ogra_> (filled with multiple packages)
<cjwatson> did the silo you used earlier get reconfigured back to normal?
<Saviq> ogra_, well, at least the rollback will be ready for when that's fixed?
<ogra_> not sure, sil2100 did handle that side of things
<ogra_> Saviq, true
<cjwatson> you can look in "Edit dependencies" from the PPA's page on LP
<ogra_> i still wonder if we shouldnt just split dbus-x11
<cjwatson> it should have been set back to "Proposed"
<ogra_> its ugly to split for a single file
<ogra_> but it seems to be the most appropriate fix
<ogra_> and we might end up with it anyway
<ogra_> cjwatson, points to default
<cjwatson> better set it back to Proposed
<ogra_> doing now
<cjwatson> otherwise it'll confuse somebody later
<ogra_> done
<cjwatson> thanks
<ogra_> man this is depressing
<ogra_> http://ci.ubuntu.com/smokeng/utopic/touch/mako/61:20140602.3:20140530/8360/
<ogra_> :( ... all formerly broken tests pass
<cjwatson> I think I have a workaround for samba - uploading shortly
<Saviq> ogra_, ok, this is silly... like 90% of these MPs can safely live without the split greeter in unity8... I'd want to be thorough and actually revert all of them, but that will only piss people off more to have to land the changes again...
<ogra_> yeah, its an awful mess
<Saviq> all that should've landed by itself :|
 * Saviq hits head with hammer, deserves it
 * ogra_ sends a mail
<cjwatson> hopefully https://launchpad.net/ubuntu/+source/samba/2:4.1.6+dfsg-1ubuntu6 will help
<ogra_> whee !
<ogra_> just saw it on -changes
<ogra_> (hidden in the haskell spam :) )
<cjwatson> I blame Clint
<ogra_> for the limit or for haskell ?
<ogra_> :)
<cjwatson> the latter
<Saviq> ogra_, let's do: I'll prepare all the reverts, but if the respective owners reject them by the time of the landing, we pull them out?
<ogra_> well ... can we be *sure* pulling them out wont break anything
<Saviq> or well... I can do the work to reinstate the changes for a separate landing in any case
<Saviq> ogra_, yeah, I know what you mean
<Saviq> ok, reverting all
<ogra_> i think we are in a messed up enough situation to consider moving forward
<Saviq> you mean with the split?
<ogra_> and fixing the bugs while doing the dbus-x11 split
<ogra_> in a joined effort
<Saviq> sure, I'd like that, too, is definitely better use of time, but who's to make the call
<ogra_> dunno, speak up on the ML :)
<ogra_> if all parties could agree we can do that ... but i would want bfiller and kgunn to at leas comment to the plan
<ogra_> *least
<ogra_> after all bills team seem to have the most bugs with it
<Saviq> indeed
<ogra_> (and he sounded really grumpy in his mail ... not actually bill-like)
<Saviq> had perfect reason, too
<ogra_> indeed
<Saviq> I only wonder how we did not see these when testing
<Saviq> I really pounded at calls and messages at some point
<Saviq> something must've moved below our feet, or we're just lame QA
<ogra_> well, with what image did you test ?
<ogra_> 55 ?
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/57.changes had many telephony related changes
<Saviq> not as extensive, since nothing changed )we thought) in between
<ogra_> 58 had the greeter ... but was missing unity8
<Saviq> so yeah, I dropped the ball, did the most extensive testing beginning of the first Malta week
<ogra_> 59 then had unity8
<ogra_> wow
<Saviq> and then we were just pounding out issues in greeter itself
<ogra_> you worked on that the first week already ?
<Saviq> yeah, that's when we started to want to land it, timezone split didn't really help
<ogra_> Saviq, right, i had discussed with mike before and had planned to help with the fallout after we landed on monday
<Saviq> ogra_, yeah, I know
<ogra_> i really feel bad that i was pushing it til the end of the week (though i was surprised when rob and sil wanted to land it on friday ... i should have spoken up)
<Saviq> ogra_, every one of us could have done something better
<ogra_> yeah, perhaps
<Saviq> that didn't sound right
<Saviq> but kinda true
<ogra_> definitely ... still i was kind of on top of that trying to keep the overview
<ogra_> and in that role i should have raised my hand in the landing team meeting on friday evening ... but i was so happy to finally get it in that i didnt ... it simply took so long
<Saviq> ogra_, yup, it tricked all of us
<ogra_> i dont belive you did bad QA ... not with that investment of time
<Saviq> it was just an elephant-ass of an architectural change
<Saviq> if anywhere - stuff like this will kick us in exactly those situations
<Saviq> and truth be told, we need to allow ourselves that
<Saviq> IMO
<Saviq> that's why we have image promotion as a fail safe
<ogra_> right
<cjwatson> I quite agree
<cjwatson> Nothing must ever go wrong => no velocity - there's a sensible middle ground to be had there
<ogra_> right
<cjwatson> dear samba builds, please beat the publisher
<ogra_> in any case #61 is back down to only 22 failures
<ogra_> (of which 19 are gallery for which we have a held back landing)
<Saviq> which would support the "let's only pull back real split greeter out"
<ogra_> UGH
<Saviq> and "split dbus-x11", too
<ogra_> otoh ... flo has tons of new failures
<ogra_> including all UITK tests
<ogra_> that makes no sense !
<Saviq> :|
<ogra_> must be an infra issue ...
<ogra_> manta and mako are back to normal seemingly
<Saviq> ogra_, message is the same as with the mako failures from 59/60
<Saviq> failed to start app
<ogra_> yeah
 * ogra_ checks if flo actually flashed 61 
<ogra_> hmm, looks like
<ogra_> that really makes no sense ... why would one arch behave so much different
<ogra_> hmm, seems not all makos ran their tests
<ogra_> (but the relevant ones all passed)
<popey> ogra_: can you delete your u1 account (I can't)
<ogra_> dunno, havent added it yet
<ogra_> ugh
<ogra_> my flo is pretty stuck
<ogra_> well, not stuck but a slideshow
<ogra_> no obvious processes consuming CPU
 * popey files bug
 * ogra_ reboots flo
<popey> #61 is quite broken
<popey> can't install apps either
<popey> guessing this is all dbus related
<ogra_> sigh
<Saviq> whaaaa? I tested flo, too, even ran ap tests on it ;(
<popey> ahaÂ¬
<popey> Your home partition has less than 0.0 MB of free space available, which leads to problems using applications and installing updates. Please free some space.
<popey> could be that!
<cjwatson> ok, I think ldb/samba will fail to migrate due to a gvfs autopkgtest regression, but that shouldn't actually matter - things that need it will be buildable in -proposed again after this publisher run
<cjwatson> and as far as the phone was concerned it was mostly being used as a build tool so that shouldn't have knock-on effects on migration of other builds
<cjwatson> ricmm: ^-
<t1mp> what's happening with the landing in silo 3?
<ogra_> t1mp, TRAINCON-0
<t1mp> ok, thanks
* ogra_ changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp - sprinting this week, slow to respond | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: TRAINCON-0
<ogra_> popey, wow, we have such a message ?
<ogra_> popey, adding/removing U1 account works fine ... and i just installed Here Maps
<ogra_> so yeah, could be that :)
<popey> ogra_: when i tried filing a bug
<ogra_> yes ?
<popey> yay! deleted some files
<popey> now I can remove my u1 account
<ogra_> good
<ogra_> here maps is pretty cool
<ogra_> apart from the fact that it misspells my hometown
<popey> hehe
<popey> file a bug
<ogra_> funny, seems all other germany cisties are correct
<ogra_> *cities
<ogra_> this town was called Cassel abut 1100 years ago ... but since then it has always been called Kassel ...
<ogra_> they probably just looked at an old map :P
<popey> â»
<popey> there's a guy on fb who posts loads of old pics from our local town
<popey> https://www.facebook.com/photo.php?fbid=583639105067396&set=gm.10152192444665963&type=1&theater
<popey> ye olde map
<popey> 1611
<ogra_> fences !
<popey> ye olde fences!
<ogra_> :)
<ogra_> http://de.wikisource.org/wiki/Kassel#mediaviewer/Datei:M%C3%BCllerplan_Kassel_1547.jpg
<ogra_> we had walls already :)
<ogra_> (1547)
<popey> get you with your walls
<ogra_> lol
 * ogra_ &
#ubuntu-ci-eng 2014-06-03
<kgunn> anyone around to provide some silo love ?...so we can start building for mir.
<kgunn> maybe Mirv when you come on? ^
<imgbot> === trainguard: IMAGE 62 building (started: 20140603 02:10) ===
<imgbot> === trainguard: IMAGE 62 DONE (finished: 20140603 03:35) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/62.changes ===
<Mirv> kgunn: assigned and kicked a build: https://ci-train.ubuntu.com/job/landing-008-1-build/83/console
<plars> ogra_: 61 and 62 still have dbus-x11 installed it seems, so they are still going to be broken. I guess from the suggests in dbus? That's the only rdepends I can find for it that we have installed
<Mirv> plars: I can see there's a new line for reverting the split greeter, I'm not sure if that's because this previous fix failed to work or if it's just in case it's needed
<Mirv> plars: Suggests: does not bring a package in, Recommends would
<Mirv> so, weird
<Mirv> oh, right, so it's in case the dbus split wouldn't be done
<Mirv> it does not seem that at least simply again installing dbus-x11 and removing /etc/X11/Xsession.d/75dbus_dbus-launch would make #62 show more than a black screen for me
<Mirv> it might be of course also because of my 5.3 experiments so I could need a fresh wipe
<Mirv> I'll assign a silo and kick a build of the revert anyhow, better to have it ready
<ToyKeeper> Nice.  Image 62 crashed four times after flashing, before I even turned the screen on to try it...  and all the indicators are missing.
<Mirv> interestingly, now that I upgraded my #62 + dbus-x11 - 75dbus_dbus-launch to the Qt 5.3 PPA, everything seems working correctly including indicators
<Mirv> so maybe it was that my black screen was because of non-clean wipe (I've seen it before), but that restoring dbus-launch binary makes things work. or alternatively Qt 5.3 is simply that much better :)
<Mirv> note that the unity8 rebuild does have the split greeter etc anyhow, everything's up-to-date.
<ToyKeeper> This was a fresh flash.  Maybe it was a boot fluke, but it's not a good sign when the phone tries to melt itself on first boot.
<ToyKeeper> It was getting hot enough that I worry it could cause damage...  so I shut it off completely for now.
<ToyKeeper> Er, and one of the crashed processes was /sbin/init ... which really worries me.
<Mirv> I seem to have /sbin/init .crash file from last Wednesday, so nothing totally new apparently
 * sil2100 sighs
<pete-woods> cihelp: can anyone help me figure out what happened to the packages in silo #009? https://ci-train.ubuntu.com/job/check-publication-migration/17381/console
<pete-woods> "WARNING hud (14.04+14.04.20140528-0ubuntu1) is in no known space (and time). We didn't find it anywhere. It could have been rejected, or you run it too quickly and it's not published in proposed yet, or a network issue happened. If this persistent some time after the publication, you need to ping a landing team member to get more informations."
<sil2100> ogra_: ok, I understand from the e-mails that the current unity8 and such are causing indicators not appearing, but I wonder why some application tests still fail completely
<sil2100> pete-woods: I will try looking at this, wanted to do it yesterday already but there was too much chaos
<sil2100> pete-woods: since the package is in -proposed now when ai last checked
<sil2100> pete-woods: actually, wait, no
<pete-woods> sil2100: that one was a failed SRU
<sil2100> pete-woods: ok, this needs some intervention
<pete-woods> sil2100: just let me know if I need to change anything
<Mirv> sil2100: read the backlog from #ubuntu-touch if you didn't yet, regarding pete's landing
<Mirv> it was probably filtered out ie never copied to archives
<sil2100> Mirv: will do that and poke some archive admins for help here
<Mirv> sil2100: poking was also done, so if you combine the #ci-eng and #touch discussion you should have the whole picture I think
<Mirv> so probably you'll need to let didrocks know if you want that filter changed or something else, and then probably republish is needed
<Mirv> sil2100: http://irclogs.ubuntu.com/2014/06/02/%23ubuntu-ci-eng.html#t10:42 + aha we don't have #ubuntu-touch logs??
<Mirv> + http://pastebin.ubuntu.com/7578497/ then
<sil2100> Mirv: thanks! I have this in my logs at least... but hm, why did it suddenly use the sru-staging PPA?
<sil2100> I didn't configure it to do so
<sil2100> I'll check the code and see what's going on
<sil2100> Mirv: so, I'll have to chat with didrocks again, since it seems to be the default behavior so it should have done the same the first time the SRU was published
<sil2100> Mirv: we don't have logs of that though since it was long ago
<sil2100> Mirv: so not sure why suddenly now it would get 'filtered out'
<Mirv> sil2100: ok, sounds good (to have a chat). I thought the abandoning of sru-staging was something you had agreed to last week or such.
<Mirv> so I didn't have much idea what should be the case
<sil2100> It was nothing that has been discussed with me around at least
<ogra_> sil2100, ugh ... that looked totally different last night, 61 was mostly green
<sil2100> ogra_: looking at 61 now it's similar though, makes me feel a bit uneasy
<ogra_> sil2100, yeah, dropping dbus-x11 didnt help at all it seems
<ogra_> sil2100, see the mail discussions though
<ogra_> sil2100, it seems we need 50% of dbus-x11
<sil2100> Yeah, saw that discussion more or less
<ogra_> (dbus-launch, but not the Xsession.d part)
<ogra_> and pitti seems to have a good suggestion for a fix by dropping a config option
<sil2100> ogra_: right, I see that now - need to read up about that option though
<sil2100> ogra_: ah, so this way the dbus session won't launch even with dbus-x11 installed?
<Saviq> o/
<Saviq> sil2100, can you kick https://launchpad.net/~ci-train-ppa-service/+archive/landing-019/+build/6064416 ? I hope for a flaky test - only failed on amd64
<ogra_> sil2100, gdbus uses dbus-launch to fire up a dbus when it first tries to connect and finds one
<ogra_> sil2100, the first gdbus call seems to happen before the Xsession script is processed
<ogra_> this then starts another dbus-daemon
<sil2100> Saviq: sure
<ogra_> hmm, no answer from bfiller at all ... so we have to roll back i guess
<ogra_> :(
<sil2100> He'll be like in around 5 hours
<sil2100> Which is quite long...
<sil2100> It's really a shame though, such a big landing reverted
<ogra_> sil2100, well, pitti just proposed a fix for which we need to roll back the dep dropping and he needs to upload a fix to dbus ...
<sil2100> ogra_: remember on Friday when I was saying about getting ready for this big thing landing and you were like "it's nothing risky, it was in testing for months!" ;) ?
<ogra_> but we will have the same prob as yesterday
<Mirv> I've #62 working just fine with Qt 5.3, after installing dbus-x11 back in and removing the X related script :)
<ogra_> needs to be tested in the lab
<ogra_> Mirv, right
<ogra_> Mirv, and thats what we tested with plars yesterday
<sil2100> Right
<ogra_> i didnt think of the fact that dbus-launch could play any role by being called directly
<ogra_> which means we need exactly 50% of dbus-x11
<sil2100> But what is the cause of all the current failures we have in smoketesting?
<ogra_> but pitti agrees its a dbus bug that the Xsession part gets processed at all
<ogra_> sil2100, that we completely dropped dbus-x11
<ogra_> we need to keep half of it
<sil2100> ogra_: wasn't is mentioned that 'smoketesting is fine after dropping dbus-x11' on the ML?
<ogra_> or in other words, make the Xsession script a no-op if gdbus fired one up already
<sil2100> Ok, so it's like, everything has one cause
<ogra_> sil2100, yes, before i went to bed mako was all green (not all tests had run)
<ogra_> http://paste.ubuntu.com/7578684/
<ogra_> thats the proposed fix ... i will test that in a minute and pitti will upload it
<sil2100> Let's wait for this to happen, the big revert silo might build itself in the meantime
<ogra_> but we still have to make a decision if we want to risk it or complketely roll back
<sil2100> So that we have a fallback in case of nothing helping
<ogra_> the prob is that we tested with dbus-launch installed ... where it worked fine ... my change dropped that alongside
 * ogra_ gets his flo and fresh coffee ...
<sil2100> I would try risking it, really, as such a big revert is never 100% sure as well
<ogra_> then i'll test
<ogra_> sil2100, i agree
<brendand> cihelp - can someone help me understand these jenkins failures? https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/1027/console
<sil2100> pete-woods: so, I need to change something in our CI Train code to get this moving
<sil2100> pete-woods: will try to finish it up today, but there's a lot going on
<pete-woods> sil2100: okay, thanks for the update :)
<vila> brendand: RO file system despite phablet-config writable-image, that's beyond my understanding, you want plars or doanac
<vila> brendand: is this a recent failure ?
<mandel> sil2100, I forgot the channel of the train, can you telll it to me?
<sil2100> mandel: #ubuntu-ci-choo-choo ? :)
<mandel> sil2100, thx!
<mandel> sil2100, malta has drained my brain
<brendand> vila, semi recent. a specific mr keeps failing for that reason
<brendand> vila, since the end of last week i think
<vila> brendand: add fginther to your ping then since it's a s-jenkins job
<vila> brendand: they are all in US
<brendand> vila, i'll take one more try and see if it happens again
<popey> sil2100: ogra_ landing meeting?
<sil2100> popey: yep
<ogra_> yeah, sorry, still in debug mode ... on my way
 * ogra_ cant connect ... 
<Saviq> sil2100, ogra_, train is happy with revert silo, what do we do?
<ogra_> Saviq, we have the landing meeting right now ... discussing that ... wanna join ?
<sil2100> Saviq: come over, let's have a chat
<ogra_> https://plus.google.com/hangouts/_/canonical.com/landing-meeting
<brendand> cihelp - i have my vpn up but can't reach s-jenkins
<ev> brendand: interesting. Having a look now
<sil2100> brendand, ev: bfiller had a similar issue yesterday already
<sil2100> It seems after relogging 10 times it started working...
<brendand> ev, some people mentioned similar yesterday
<ev> being able to reach it and being able to log in are different problems, no?
<vila> brendand: funny you mention that, I just had to fix my laptop and desktop configs following instructions from https://wiki.canonical.com/UbuntuEngineering/CI/VPN
<vila> brendand: I was using a config that didn't followed the updated instructions
<brendand> vila, but i used this yesterday
<brendand> vila, did it change in that time?
<vila> brendand: yeah, I used mine for months
<brendand> vila, ok i'll check the config
<vila> brendand: I suspect that some pieces were left in place to let people update to the new (long term supported) bits so nobody realized they had to change the relevant bits
<vila> brendand: for NM based config I had to change to 10.99.244.1 for the ubuntu-ci DNS server (I was using an old IP)
<vila> brendand: for the openvpn based I had to stop using my hand-crafted scripts and switch to /etc/openvpn/update-resolv-conf for 'up' and 'down'
<brendand> vila, so that seems to have done the trick
<brendand> vila, but all i did was remove some whitespace for the up and down lines
<brendand> vila, not even sure how the whitespace got there
<brendand> bad copy and paste i guess
<vila> brendand: and you did 'service openvpn restart' ?
<brendand> vila, no i just run openvpn from the command line
<vila> brendand: and you had a previous running but not giving you the right infos correct ?
<brendand> vila, well yes
<vila> brendand: so may be it was relying on some old IP that got cleaned up recently
<brendand> vila, perhaps
<vila> brendand: anyway, if it works now, I would keep that explanation in mind and ask retoaded for some confirming bits
<ev> thanks vila
<vila> ev: you didn't have any issues with your vpn I suspect ?
<ev> not at present
<vila> ev: right, so you probably had an up-to-date config already
<sil2100> pete-woods: ok, let's hope that now HUD goes forward
 * sil2100 did some hacks to push it without a rebuild
<sil2100> pete-woods: yesss! hud re-appeared in the unapproved queue :)
<pete-woods> sil2100: :D
 * Mirv gone for a while, will check irc etc still today
<sil2100> Mirv: o/
<popey> sil2100: was there not going to be another catch up?
<sil2100> popey: yeah, let's wait for the image first though
<popey> k
<pmcgowan> imgbot, stunt
 * imgbot rolls on its back and purrs
<ogra_> :)
<popey> hah
<ogra_> publisher has both packages in proposed now ...
 * pmcgowan waits for 62
<ogra_> next publisher run is ours
<ogra_> then we can start a build
 * sil2100 spams rmadison
<ogra_> popey, i guess we wont have the image before the evening meeting ... at least not much ... and we all worked together over the last few hours anyway
<ogra_> (in #ubuntu-devel mostly)
<ogra_> so i dont think we need another meeting right now
<popey> ok
 * ogra_ is afk for a moment
 * Mirv back
<sil2100> ogra_: it's in!
<sil2100> ogra_: or wait
<sil2100> hmmm
<sil2100> ogra_: ok, so actually rmadison says it's still in -propsoed, but citrain thinks otherwise
<Mirv> sil2100: citrain is too fast afaik
<sil2100> I thought that with the latest changes it should work similar to how rmadison works
<Mirv> it requires the usual 10-15min more so that rmadison agrees
<Mirv> ah, I don't know if it has changed recently
<sil2100> I remember it always being accurate since some time
<sil2100> But hm, dunno
<pmcgowan> Mirv, all set for that webkit landing? I just wanted to be sure it got properly tested
<Mirv> pmcgowan: oSoMoN is reviewing the webbrowser branch still (or maybe done now), I can start builds and testing as soon as traincon-0 is over.
<oSoMoN> Mirv, webbrowser-app branch reviewed and approved
<Mirv> oSoMoN: thanks!
<pmcgowan> Mirv, whats the webbrowser branch for?
<ogra_> === image triggered ===
<sil2100> o/
<sil2100> ogra_: thanks!
<ogra_> bot shoulld announce it soon
<mhr3> sil2100, reconf of 010 pls?
<sil2100> mhr3: done
<mhr3> ty
<sil2100> np
<imgbot> === trainguard: IMAGE 63 building (started: 20140603 14:00) ===
<ogra_> there we go
<ogra_> with luck we should have the first smoke results when the meeting starts
<Mirv> pmcgowan: https://code.launchpad.net/~dbarth/webbrowser-app/webapp-container.remove-qtwebkit-support/+merge/221773 <- oSoMoN can probably elaborate (or dbarth). I'm not 100% sure if it'd be required, since we do continue to have qtwebkit (just a newer version).
<pmcgowan> Mirv, we need some sort of test plan to validate that webkit is still working properly independent of our not using it anymore
<pmcgowan> Mirv, we didnt include it originally for a reason, to do with bad dpr, not sure thats an issue or not
<Mirv> pmcgowan: I think the DPR got fixed, the only issue we had with 5.2 (as we were going to ship it originally) at the end was that WebGL sites didn't work properly with it
<Mirv> but yes, I added now a tab to create a test plan at https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AjuCdq68GSyVdFI4QzNQdWpfME5aMEV2VXo0cUpOMkE#gid=23
<pmcgowan> Mirv, thanks
<sil2100> ogra_: as with every Tuesday, I might not be able to attend the meeting
<ogra_> ok
<sil2100> ogra_: but I will be back around 20 if anything
<Mirv> dbarth: can you check ^ url (it's editable). I'd mostly want at least one line for every theoretical webkit user, and status if it's something that is needed to be retested with 5.2 or has already switched to oxide
<ogra_> yeah, thats fine
 * sil2100 is battling the bot
<dbarth> Mirv: yup
<ogra_> sil2100, since the AP tests wont be done anyway we should probably skip ... unless people feel an urge to talk
<dbarth> Mirv: there is an additional apparmor change required to do a transparent switch though
<ogra_> i assume we'll be somewhere in the middle
<dbarth> trying to set that up properly
<Mirv> thanks, it's starting to look good. I wasn't sure if OA switched, but indeed it did.
<pmcgowan> Mirv, can you look at https://bugs.launchpad.net/qt/+bug/1318584, I cannot seem to assign it to you
<ubot5> Ubuntu bug 1318584 in Next Generation Checkbox (GUI) "checkbox-gui crashed when switching video out mode to external only mode" [Medium,Confirmed]
<mhr3> sil2100, could you click the rebuild button on https://launchpad.net/~ci-train-ppa-service/+archive/landing-010/+build/6065421 pls?
<mhr3> i was too quick to build it, the ppc -api pkg wasn't published yet
<mhr3> Mirv, or you ^?
<sil2100> mhr3: after my meeting
<sil2100> mhr3: click
<mhr3> thx
* retoaded changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp - sprinting this week, slow to respond | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: TRAINCON-0; QA Lab VPN connection issues
<mterry> kgunn, Saviq: how do I initiate a new silo request?  Ask here?
<Saviq> mterry, added to the spreadsheet?
<mterry> Saviq, no not yet, I'm new to "adding new silos to spreadsheet" -- wasn't sure of order of operations
<Saviq> mterry, so just add your data at the end of https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc#gid=0
<Saviq> mterry, now you want to set the "Ready" column to Yes
<Saviq> mterry, and start begging sil2100 to get us the last silo available ;)
<mterry> Saviq, well...  I'll have to poke tiagosh about getting the checklist right for his MP
<mterry> If I'm going by book
<Saviq> mterry, we'll probably have to wait until image 63 results are in, so there's time
<sil2100> ;p
<sil2100> I like the description!
<Saviq> sil2100, see!
<sil2100> Saviq, mterry: assigned! Silo 020 for you
<Saviq> sil2100, we'll be quick, promise
<mterry> heh, that's a bit confusing but makes sense since it was just cleared by us
<Saviq> indeed ;)
<mterry> Saviq, tiagosh is going to add a checklist to his merge
<Saviq> mterry, sure, we can build in the mean time
<Saviq> mterry, as that doesn't affect the process
<mterry> Saviq, yup, just saying
<Saviq> kk
<Saviq> mterry, you pushing the button on this?
<mterry> Saviq, the build button?  I guess the fact that landing-020 sheet has content means its configured with those 3 branches already?
<Saviq> mterry, when sil2100 says it's ready, that's when it's ready ;)
<sil2100> hm, should be safe to do operations
<sil2100> But the spreadsheet is behaving strangely
<sil2100> Could anyone of you press the build button?
<imgbot> === trainguard: IMAGE 63 DONE (finished: 20140603 15:25) ===
<sil2100> o/
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/63.changes ===
<ogra_> yippie !
<sil2100> Image testing begiiin!
<sil2100> \o\ /o/
<ogra_> now the anxious waiting til the smoke infra picks it up
<popey> updated to #63 and i have no wifi â¹
<sil2100> Reboot
<sil2100> Oh
<sil2100> On the other hand
<popey> bah
<popey> just did
<sil2100> My landing might have kicked us in the balls
 * ogra_ watches the update animation idly 
<sil2100> popey: still no internet?
<popey> works after reboot
<sil2100> Ah, phew
<sil2100> Still, let's see if ogra_ will have the same
<ogra_> wlan oon flo is fine here
<ogra_> right after upgrade ... no extra reboot
<ogra_> mtp also behaves
<sil2100> Indicators present?
<ogra_> yep
<popey> yes
<ogra_> all like it should here
<sil2100> Ossum
<ogra_> hmm, going back after adding a U1 account is weird
<ogra_> you see system settings for s split second ... then it slides away and shows you systme settings
<ogra_> on first sight it looks all fine
<ogra_> so lets hope the AP tests confirm that
<ogra_> popey, do you feel the need to have a landing meeting now ? would be only us two and i think we know what we wait for now to drop traincon-0
<popey> i do not
<ogra_> great, then lets skip
<ogra_> and just watch smoke tests to chug along
<ogra_> mediaplayer had no failures !
<ogra_> that hasnt happened in a while
* retoaded changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp - sprinting this week, slow to respond | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: TRAINCON-0
<pmcgowan> ogra_, 63 looks better then
<pmcgowan> nice job cross fingers
<ogra_> pmcgowan, from a user POV it looks ok
<pmcgowan> hah
<pmcgowan> implying not from an engineers I suppose
<ogra_> cant say much about the AP tests yet
<plars> sil2100: no landing meeting?
<ogra_> plars, we decided to skip ... all we wait for is anyway that the AP tests finish
<ogra_> plars, to drop TRAINCON-0
<ogra_> (i didnt know you are back today)
<plars> ah
<plars> ogra_: I am
<ogra_> ok
<plars> ogra_: fyi, I'm gone all next week though
<ogra_> well, we hpefull have all fixes proper now
<ogra_> so waiting for #63 to finish testing
<ogra_> if that looks okayish we'll drop TRAINCON-0
<ogra_> plars, why does mako look so much different while the tests are running ... i.e. the tablets both list all tests, mako seems to be missing 1/3
<plars> ogra_: so I didn't really look into or understand the fix for this yesterday, but I do see that dbus-x11 is still installed. is that expected?
<ogra_> it isnt installed
<plars> ogra_: could be part haven't started yet, I'll take a look
<plars> ogra_: it is installed, I'm looking at it right now on 63
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/61.changes
<plars> root@ubuntu-phablet:~# apt-cache policy dbus-x11
<plars> dbus-x11:
<plars>   Installed: 1.6.18-0ubuntu6
<ogra_> i definitely dont have it on a fresh flash on 63
<plars> that's running in the lab right now
<ogra_> ugh
<plars> so something is bringing it in then
<ogra_> thats evil
<plars> ogra_: that's what I was trying to say last night
<popey> yeah, my #63 has it
<plars> So I don't expect 63 to look any more green
<ogra_> root@ubuntu-phablet:~# dpkg -l |grep dbus-x11
<ogra_> root@ubuntu-phablet:~#
<ogra_> root@ubuntu-phablet:~# system-image-cli -i|grep "version version"
<ogra_> version version: 63
<ogra_> how can you have it ... i dont get that
<ogra_> popey, ?
<ogra_> did you install any AP tests ?
<popey> nope
<popey> oh hang on
<popey> it's possibly I'm an idiot
<popey>   Installed: (none)
<ogra_> PHEW !
<popey> sorry â»
<plars> ah, found it
<popey> carry on taking the pills
<plars> messaging-app-autopilot brought it in
<ogra_> plars, well, if that got pulled in by any AP this is super evil
<ogra_> it will cause all sorts of dbus flakyness
<ogra_> i hipe the autoremove at least purges it after testing ?
<plars> ogra_: http://paste.ubuntu.com/7581296/
<ogra_> there is a fixed dbus-x11 too, that shouldnt spawn any dbuses anymore
<ogra_> oh
<ogra_> ofono-phonesim
<plars> will find out, that's the one its on now
<ogra_> i think ofono-phonesim-autostart depends on it for whatever reason
<ogra_> if we get dbus-x11 1.6.18-0ubuntu8  in that shouldnt be an issue anymore though
<ogra_> but i see you are on ubuntu6 in the lab
<ogra_> so lets cross fingers
<ogra_> anyway, the trigger that made it start random dbus-daemons is gone so it shouldnt break
<ogra_> we re-ordered the greeter session startup so that you have a dbus before anything  wants to talk to it
<plars> ogra_: well, we don't apt-get update
<ogra_> which hopefully makes dbus-x11 less harmful
<ogra_> i dont think ubunt8 has migrated yet anyway
<ogra_> likely still in proposed ... it has a gazillion of deps for which it runs all tests
<ogra_> https://launchpad.net/ubuntu/utopic/+source/dbus/1.6.18-0ubuntu8
<ogra_> hah
<ogra_> Published 13 minutes ago
<ogra_> bad timing
<plars> ogra_: autoremove didn't take it out :(
<ogra_> crap
<ogra_> i wonder fi thats not responsible for flaky tests we saw in the past then
<plars> ogra_: quite possibly
<ogra_> well, messaging-app at least passed fine
<ogra_> ARGH!
<ogra_> dialer-app failed all tests
<ogra_> :((((
<robru> ogra_, also, no indicators on #62
<ogra_> robru, 62 is dead and buried
<ogra_> it was horribly broken
<robru> ogra_, is there a new one? I just flashed and got 62...
<ogra_> <ogra_> root@ubuntu-phablet:~# system-image-cli -i|grep "version version"
<ogra_> <ogra_> version version: 63
<robru> ogra_,
<robru> ogra_, ha!
<ogra_> robru, 63 is fine from locally running tests and from a few mins usage testing
<ogra_> but it seems dbus-x11 is still causing issues in the lab
<ogra_> sigh calendar is also failing
<ogra_> mterry, ^^^
<ogra_> http://ci.ubuntu.com/smokeng/utopic/touch/mako/63:20140603.1:20140530/8381/
<ogra_> plars, for a test, can you re-run any of the failing ones after manually purging dbus-x11 again ?
<ogra_> we definitely had them pass in local tests
<robru> ogra_, so what happened in 63? did that have the greeter revert?
<ogra_> nope
<ogra_> that would have been a gigantic revert
<ogra_> we didnt want to do that
<ogra_> we fixed it instead
<robru> ogra_, yeah, i don't want that either ;-)
<robru> great
<ogra_> apparently not enough though
<robru> ah
<ogra_> looking at the currently running AP tests
<ogra_> but thats seemingly caused by a leftover dbus-x11 package that should not be on the device at all
<plars> ogra_: sure, of course. I could do it locally right now, or I could do it in the lab after the runs are done
<ogra_> plars, in the lab please, i want to be sure you use the same env and setup
<ogra_> plars, we need to find a way to purge dbus-x11 though ... i dont get why teardown doesnt pull it out
<plars> ogra_: 'sudo apt-get autoremove --purge -y messaging-app-autopilot' was what got run, I suppose maybe because it didn't follow the dep chain far enough down
<ogra_> well, autoremove should actually follow the chain
<ogra_> plars, could we somehow ass dbus-x11 as a permanent entry to the teardown packageset ?
<ogra_> *add
<plars> :)
<ogra_> heh
<plars> probably, let me take a look - it would be a temporary hack I guess right?
<plars> ogra_: is it even worth it though? from what you said, in the version of dbus-x11 we pull in next it shouldn't have this problem
<ogra_> well, we definitely dont want that package ever installed ... except for ofono-phonesim tests ...
<ogra_> well, the new version will only make sure that the Xsession script wont run if there is already a dbus running
<ogra_> but if you have any code that calls gdbus this will spawn a session dbus via the dbus-launch binary which dbus-x11 ships
<ogra_> in which case you can end up with multiple dbuses again
<ogra_> which will get you flaky tests most likely
<ogra_> so it might or might not fix it in the lab
<ogra_> it will fix one case we know about
<ogra_> but there can be more ...
<ogra_> in whicch case it is safer to always purge it
<plars> ogra_, doanac: provided I didn't do something stupid, https://code.launchpad.net/~pwlars/ubuntu-test-cases/kill-dbus-x11/+merge/221925 ought to take care of it. Have to force that to pass in case we ever end a test where it didn't get installed, which will certainly happen
<plars> ogra_: when I get an ack on it I'll merge it and this branch will get used to test after 63 is done. since dialer app failed I'll include it, which should also bring in dbus-x11 and we'll make sure it gets removed properly
<ogra_> plars, looks ok to me, did you try it on a local device ...
<ogra_> not sue about the quoting now that you have multiple packages
<plars> not yet, about to. I just need to dig out my phone
<plars> actually...
<plars> I may have a better way
<ogra_> our issue is that we need to get out of TRAINCON-0 ... so even if you can re-run the tests with purging it manually after dialer-app and messaging-app have run would help a lot
<ogra_> we need some reliable data, things are piling up
<plars> ogra_: we'll get there, I'm testing that branch now and once 63 finishes I'll rerun things with this
<ogra_> awesome
<plars> it has my full attention right now
<ogra_> heh, thanks :)
<plars> well, except for part of my lunch sitting on my desk here
<ogra_> right, eat first, we dont want you to fall over starving, then we dont have anyone over there anymore :)
<plars> ogra_: hah, you just saw me last week, I would hardly describe me as "starving" :)
<ogra_> haha
<ogra_> we all gained some wieght over the years
<ogra_> a *little*
<mterry> ogra_, sorry was out to lunch.  63 is expected to have some rough edges.  silo 020 should fix them?  (i.e. work with dbus-x11)
<Saviq> huh, so we didn't get any improvement on 63 re: smoke testing...
<Saviq> ah, probably because it still has unity from yesterday...
<Saviq> or well, Friday, actually
 * sil2100 back
<sil2100> ogra_: do we have results?
<josharenson> cihelp, I need a parameter added to mir-mediumtests-runner-mako
<sil2100> ogra_: 63 doesn't look any better...
<plars> sil2100: we're working on it, turns out dbus-x11 gets installed with some of the AP tests, but autoremove doesn't clean them
<sil2100> phew
<doanac> josharenson: what sort of parameter are you needing?
<sil2100> plars: thanks! So there's still chance we might not have to revert? ;)
<josharenson> I need "mir_performance_tests" added to the test_suite section
<plars> sil2100: I just pushed a patch to force the removal, but trying to get complete results on mako first. I just noticed that one of the makos never installed though because it never went into fastboot. We seem to have a new problem...
<plars> ogra_: ^
<josharenson> ChrisGagnon and I added it last week, but it looks like it never stuck
<plars> ogra_: sometimes when I do 'adb reboot-bootloader', it looks like it just reboots the device back into the OS
<plars> so it never actually goes to fastboot, and it just gets stuck trying to run ubuntu-device-flash
<doanac> josharenson: i'll have to check with fginther about that. i'm not sure the exact mechanics involved for that
<josharenson> doanac, ok
<fginther> josharenson, doanac, hello. I can help with that
<plars> sil2100: I've restarted the failed ones (except gallery since we know that's a different problem) on mako, this time it should remove dbus-x11 by force
<fginther> josharenson, it sounds like all you need is to add another test to the list of test suites?
<josharenson> fginther, correct
<sil2100> plars: \o/
<sil2100> plars: thank you, you're our hero!
<plars> sil2100: :( I much prefer to play the villain. I must work harder on this handlebar mustache
<sil2100> hah!
<sil2100> ;)
<mterry> sil2100, I built silo 020, and it seemed to have worked (packages in PPA), but the status of the build job is aborted?
<fginther> josharenson, doanac, https://code.launchpad.net/~fginther/cupstream2distro-config/mir-perf-tests/+merge/221939
<fginther> josharenson, can you make sure that added test name is correct?
<sil2100> mterry: hm, let me take a look
<sil2100> huh
<sil2100> mterry: ok, now this creeps me out - it has been aborted by 'anonymous'
<sil2100> I don't remember we had a user like that, maybe that's some sabotage?
<josharenson> fginther, approved MP
<sil2100> mterry: if you re-run the build job with 'watch only' checked, it will finish what it started
<mterry> sil2100, ok
<sil2100> mterry: i.e. finish with success
<sil2100> :)
<fginther> josharenson, I'm leaving my wifi for a while. When I get back online, I'll deploy the job updates
<ogra_> plars, where does the dash in "adb reboot-bootloader" come from ?
<ogra_> (back btw... had some dinner)
<josharenson> fginther, sure thing. i'm about to go to lunch, but when I get back I'll monitor new builds.
<josharenson> fginther just ping me on irc when you deploy. Thanks for the help.
<plars> ogra_: we have to do that in our provisioning script because ubuntu-device-flash does not
<ogra_> plars, yes, but the command should be adb reboot bootloader without dash
<plars> ogra_: oh? I think both might be valid. That's always worked for us
<ogra_> hmm, i only know the no-dash version :)
<plars> ogra_: yeah, both of them are in the help
<ogra_> could be that maguro required a dash
<ogra_> ah, k
<plars> ogra_: I have one phone where the problem is pretty reproducible, let me play with it a bit
<plars> perhaps they are slightly different and the no-dash one is better now
<plars> nope
<plars> still getting right back to device mode
<ogra_> yeah, its a flag that gets handed to the kernel who hands it to the bootloader ... from there it ends up on the cmdline as value of bootreason=
<plars> I wonder if it's just this device... I've seen other devices work just fine
<ogra_> chekc the cmdline
<plars> bootreason=watchdog
<ogra_> hmm, never seen that
<plars> ogra_: I'm starting to fear maybe this device is doing bad
<ogra_> well, perhaps the bootloader is
<plars> ogra_: yeah, I took this device offline for now and I'll see if it shows up on any others
<ogra_> try re-flashing it with plain android ... also check the rest pf the cmdline and compare it with a working one
<ogra_> androidboot.bootloader= should be interesting
<plars> last successful flash on this phone was with 61
<plars> so it's worked recently
<ogra_> shoudl show you the version
<ogra_> right, but if the last android that was flasshed had a different bootloader version that could be related
<ogra_> so you might hit a bug with that ... we never touch bootloader or radio firmware
<ogra_> lol .. the watchdog logs are funny ...
 * ogra_ just looks into some 
<ogra_> [335722.400536] Watchdog bark! Now = 335722.400519
<ogra_> [335722.400908] Watchdog last pet at 335711.092920
<ogra_> [335722.401116] cpu alive mask from last pet 0-3
<ogra_> [335722.401314] Causing a watchdog bite!
<ogra_> *woof*
<bfiller> robru: trying to use citrain host-install 20 script and getting these errors: http://pastebin.ubuntu.com/7582208/
<bfiller> robru: any ideas?
<bfiller> robru: actually is that the right command? want to install silo 20 on my device
 * sil2100 prepares some dinner
<bfiller> nm
<robru> bfiller, hehe, no you want device-install. or probably device-upgrade for a unity silo
 * ogra_ goes afk for a bit again ... hopefully we have greener tests when i return :)
<bfiller> robru: ok right, got confused because when I ran citrain-slurp it said deprecated to use citrain host-install
<robru> bfiller, yeah... slurp and host-install are the same... ;-)
<robru> bfiller, you would have wanted citrain-push with the old tools
<bfiller> robru: ok got it, thanks
<robru> bfiller, you're welcome!
<robru> bfiller, although that error is odd anyway... it should have just installed those things on your computer, not sure why it wouldn't find the package.s
<plars> ogra_: interesting, I'm talking to sciri now, looks like we have 3 makos that appeared to be stuck at the google screen but they were booted. All of them are behaving this way
 * ToyKeeper wonders why apport keeps popping up and using half the CPU, with only like 10 seconds between instances.
<sil2100> plars, ogra_, robru: so far results seem really good!
<plars> sil2100: we haven't started to get to the interesting ones yet
<plars> sil2100: but I suspect this will make things improve quite a bit
<ogra_> sil2100, patience
<ogra_> i said the same thing last night
<ogra_> plars, well, take a close look at the bootloader version etc ... beyond that ... i would blame mmc wearout, take a look at syslog/dmesg on them ... its not like these phones get used "normal" :)
<plars> yeah, look for the 97 failures to start dropping before getting excited. That will be a bit longer
<ogra_> yup
<tedg> Hmm, why are silos rebuilding? Are we decided on the greeter in/out thing?
<tedg> Or is the bot just going crazy.
<ogra_> tedg, i would suspect the latter
<ogra_> the greeter in/out thing will be decided once we have complete test results
<ogra_> then the channel topic will also be updated
<ogra_> (it is looking promising  fwiw)
<tedg> ogra_, okay, thanks. Didn't realize that was in the topic, it was ellipsized for me.
<ogra_> yeah, topics arent a good place ... but easy to point to ;)
<ogra_> now there comes an exciting one ...
 * ogra_ sees clock-app running 
<ogra_> and passed !!!!
<ogra_> oooh ... thats looking so promising !!!
<ogra_> i terminal app failure ... we had that before ...
<sil2100> :D
 * sil2100 writes the e-mail
<sil2100> I guess the results look far better than before, so the chances of us going down from TRAINCON-0 are highish
<ToyKeeper> Hello jet lag...  how are you today?
<plars> sil2100: ok, weather is running now, after it completes we should actually see the failures start to drop quickly
<sil2100> plars: \o/
<plars> it appears to be passing now, and was completely failing before
<plars> sil2100: down to 77 now
<plars> filemanager will pass too
<sil2100> plars: so far it looks very similar to what we had before
<sil2100> So I'm really really happy!
<plars> sil2100: when will the next image build?
<sil2100> plars: the cronjob I think is around 3 UTC I guess?
<plars> sil2100: ok, since this experiment seems successful and mako is the one getting the most attention, are you ok to leave things as-is on flo/manta and let them run on the next image?
<plars> sil2100: mako will have a complete set of results with the workaround for the dbus-x11 removal in 63 though
<sil2100> plars: so the fix is only for mako for now, right?
<ogra_> looking good...
<sil2100> plars: what will we need to do to get all others working?
<plars> sil2100: no, it's generic enough. I can rerun them if you really need, will just require some babysitting on my part
<ogra_> nah
<ogra_> we'll get a new image by cron is a few hours
<sil2100> Nah
<sil2100> Just asked out of curiosity
<ogra_> should be enough to have proper data tomorrow
<sil2100> As long as other images will be ok
<ogra_> sil2100, first thing we land tomorrow should be the gallery-app fix
<sil2100> ogra_: right, I think we can land it even now
<ogra_> now that the rest looks so nice that red really sticks out :)
<sil2100> I mean, we wait until we get full results, we drop TRAINCON and BLAM, UITK lands!
<ogra_> i would like to see what dialer app does
<sil2100> Then BOOM and the image is broken
<ogra_> that behaved very odd
<sil2100> BOOOOOM AND BROKEN
<ogra_> and sadly uses dbus-x11
<sil2100> Sorry, got carried away
<ogra_> haha
<sil2100> btw.
<sil2100> ogra_, robru, Mirv: we might consider moving the landing-related discussions to -release
<ogra_> you mean in general ?
<sil2100> As slangasek mentioned, it's a release related thing, so it should be discussed somewhere more public
<sil2100> Yeah
<ogra_> ok
<ogra_> no prob with that
<sil2100> I know we were worried about spamming channels with our landing 'bla bla', but well... slangasek gave us the blessing!
<ogra_> prepare for a lot of critics from ScottK then :)
<sil2100> :|
<sil2100> He didn't vote for my MOTU application!
<sil2100> Yet!
<ogra_> he is a grumpy nitpicker ... but usually has a point
<ogra_> but while he is a pita he also kind of is our community conscience ... it is good to get reminded soemtimes that we dont forget about community
<sil2100> Indeed
<sil2100> But he's a bit rude I noticed, this is my only complaint about him
<cjwatson> I think this basically a result of feeling largely ignored
<ogra_> so how about i do something ... like ...
<cjwatson> *this is
* ogra_ changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp - sprinting this week, slow to respond | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<sil2100> ogra_: ++
<ogra_> weheee :)
<sil2100> Sending out the e-mail :)
<ogra_> (i removed TRAINCON-0 )
<cjwatson> (IOW, he feels he has to be, um, "direct" in order to get anywhere at all)
<ogra_> in case someone misse dit
<ogra_> cjwatson, yeah
<sil2100> robru: ^ and as per e-mail, we're off from TRAINCON-0
<ogra_> sil2100, so do you want to let the gallery-app fix in now so we get it in the cronned image ?
<sil2100> Yes :)
<sil2100> Pressing teh button
<ogra_> or if rob works today we can leave it to him :)
<ogra_> yay
<sil2100> (have some connectivity problems though)
 * ogra_ is so happ ywe finally got that sorted
<ogra_> that were two painful days and nights
<ToyKeeper> Hmm, 22 KiB/s from Click's servers to my phone.
<ToyKeeper> Er, unity8 probably shouldn't be sustaining 50% to 60% cpu load while the phone is idle with the screen off.
<sil2100> I published something, hope I published the right UITK landing ;p
<ogra_> ToyKeeper, it also shouldnt consume twice the amount of ram :)
<ogra_> ToyKeeper, what kept us in TRAINCON-0 and caused so many issues was a pretty giant landing ... watch out for more regressions there are surely some nobody has found yet
<ogra_> its like an easteregg hunt :)
<ToyKeeper> Seems that the app scope's app preview screen uses 50% to 70% of the CPU, regardless of whether the screen is on.
<ogra_> definitely worth a bug
<ToyKeeper> I think I'm going to be up rather late tonight filing all the bugs I found today.
<ogra_> well, i hope you test with 63
<ToyKeeper> This was on #63.
<ToyKeeper> Much better than 62, BTW.  :)
<ogra_> everything between 59 and 63 was konwn to have very serious issues
<ogra_> yeah, still not the final fixes, mterry is currently replacing the workarounds
<ogra_> but surely also wants to know about all regressions
<ogra_> *but he
 * ogra_ cant type anymore after two 16h days 
 * ToyKeeper facepalm...  just realized I flashed #63 over the notes for the bugs I found in #62 this morning
<ogra_> and on that note ...
<ogra_> oh my
<ToyKeeper> Yeah, sounds like bed time.
<ToyKeeper> I'm jetlagged and barely conscious, but nowhere near done with today's tasks.
<robru> hey i'm around, was just on lunch. what needs landing?
<robru> sil2100,  ^
<sil2100> robru: landed UITK just now
<robru> sil2100, what about gallery in silo 11?
<robru> sil2100, also do you know what's going on with the spreadsheet? seems the bot is going crazy pinging things
<sil2100> robru: it's not tested
<robru> sil2100, true.
<sil2100> robru: well, the spreadsheet does do some crazy stuff today
<sil2100> Ok, it's late now, time to get a life!
<sil2100> :D
<sil2100> robru: don't worry about the bot, the spreadsheet did break for me just now, so it can also be related...
<sil2100> robru: keep an eye on the spreadsheet reverting itself
<sil2100> You can find the backups here:
<sil2100> http://sil2100.vexillium.org/citrain-backups/
<slangasek> ogra_, sil2100: I don't think ScottK would object to having more of the discussions around things that are landing happening in the "traditional" channels; my guidance is that people should in general be less afraid of offending someone by talking in the "wrong" channel
<tedg> Hmm, it's late, but would test results for silo 18 be valid now?
<tedg> Do I need a rebuild?
<ogra_> slangasek, i didnt mean we would annoy him, i said sil2100 should be prepared for more critics in a channel where he is around (and will see the landing process or even occasionally look at patches)
<robru> tedg, when was the last build?
<tedg> robru, Sunday
<ogra_> slangasek, i aslo dont think thats a bad thing ... but he can be quite a nitpicker at times :)
<slangasek> ogra_: ah, you mean more community oversight ;-)
<ogra_> right :)
<tedg> robru, I believe you said there was a way to test a silo with upgrade only?
<robru> tedg, yeah, 'citrain device-upgrade 18'
<robru> tedg, I just checked your silo contents, of all the packages in your silo, I don't see any new releases for any of them since may 26th, so I guess you don't need a rebuild (it seems all the latest panic fixes didn't touch any pckages in your silo)
<tedg> robru, Great! I'll retest, but looking at the greeter changes I'm not too worried.
<tedg> Trying to get kenvandine off my back, he's heavy!
<tedg> ;-)
<robru> hmmmm, hang on a sec
<robru> tedg, I was checking the dates in the version numbers, which would be build dates, not publish dates...
<robru> should check again
<tedg> How does one get publish dates?
<robru> tedg, http://people.canonical.com/~rbpark/citrain/ click on the package names, it links to the lp source package pages, it shows version numbers and date uploaded
<robru> tedg, so ubuntu-touch-session was uploaded on the 1st... but according to the build log that's in there. so now I'm doubly sure your silo is safe to test ;-)
<tedg> Heh, great!
<slangasek> ogra_: regarding your latest mail on the smoke tests - could I talk you into writing something on https://wiki.ubuntu.com/LandingTeam/IncidentReports to explain how the test envs were different / why ?
<tedg> Reflashing first though.
<ogra_> slangasek, sure, but not tonight anymore :)
<slangasek> ogra_: ack - thanks
<ogra_> slangasek, i think it is still not clear to us why apt-get autoremove --purge didnt remove the package alongside though ... the workaround i wrote about is simply adding dbus-x11 to that apt command
<josharenson> fginther, looks like the new test is running and generating artifacts just fine. Thanks.
<slangasek> ogra_: alright
<cjwatson> tedg: if it's expired from robru's citrain pages, then https://launchpad.net/ubuntu/+source/SOURCE-PACKAGE/+publishinghistory is a good thing to have smart-bookmarked/memorised
<cjwatson> (for things that have been published to the primary archive and are no longer in silos)
<tedg> cjwatson, Ah, cool. Thanks!
<robru> cjwatson, hmmmm, suddenly I want to create a package that contains a ton of smart-bookmarks for all these little things (i have dozens...)
<robru> ogra_, hey, what's going on in silo 20? if the fix already landed, then what's this silo doing just being "built" without being published yet?
<ogra_> robru, the real fix hasnt landed ... its hacks all the way down ... 20 has the proper fixes
<robru> ogra_, ooooooh, ok thanks.
<ogra_> :)
<robru> mterry, Saviq you guys need any help testing silo 20?
<ogra_> talk to mterry and Saviq for details
<ogra_> heh, snap :=
<ogra_> :)
<robru> ;-)
<sil2100> o/
<tedg> robru, sil2100, testing looks good.
<tedg> robru, How do you want to handle landing 18?
<tedg> robru, I'm going to EOD. Bear in mind that a publish requires a NEW queue ack.
<tedg> Not sure if that means DO IT so it can get in the queue, or wait :-)
<robru> tedg, well, probably DO IT
<tedg> DO IT!
<robru> tedg, because everything else will just get stuck in -proposed anyway
<robru> ;-)
 * tedg invokes peer pressure
<robru> tedg, well we're out of TRAINCON-0, so there's no reason I can't. and I know it wont' get through NEW before the next image builds, so I think it's fine
<robru> ;-)
<tedg> Heh, okay.
<robru> tedg, https://ci-train.ubuntu.com/job/landing-018-2-publish/29/console ;-)
#ubuntu-ci-eng 2014-06-04
<mterry> silo 020 looks good to me in testing.  Branches still need approval though
<mterry> Saviq, I'm assuming you'll see this in the morning ^
<ToyKeeper> Hmm, no image 64 yet.  Thought that would have happened a few hours ago.
<Mirv> indeed
<sil2100> Morning!
<sil2100> hm, nice that we got rid of the gallery-app failures, but why suddenly so many other test suites are still failing to start apps
<ogra_> sil2100, looks like some landings only got in half
<ogra_> (once again)
<Mirv> yeah, the UAL rename
<ogra_> right
<brendand_> sil2100, all seem to be because those apps aren't launching
<Mirv> at least ubuntu-app-launch got from NEW queue 1.5h ago to proposed now
<ogra_> oh man
<robru> wtf? all that stuff in silo 18 had deps updated to the new package, how did they not migrate through proposed together?
<ogra_> robru, there were many new binaries
<ogra_> they need to be accepted by an archive admin to enter the archive
<robru> ogra_, but only UAL was NEW?
<ogra_> ... new name = new package
<ogra_> well, thats enough to block half the landing
<ogra_> everything that depends on it will go stuck
<robru> ogra_, yeah, that's the point. the *entire* landing was supposed to block on that because the entire landing depended on the new name. how can half of it still be in proposed? that doesn't make any sense
<sil2100> Ah!
<ogra_> robru, seems unity-greeter-session-broadcast went straight through
<sil2100> Yeah, I just checked my commit log and saw that only unity-greeter-session-broadcast got inside from the landing
<robru> well, if you guys are finding apps failing to launch, I don't think there's any surprise with a half-landed silo 18...
<ogra_> yes
<ogra_> lets see how long it takes for ual to get out of proposed now
<ogra_> in any case there was a missing dep
<robru> my plan was that silo 18 would entirely stick in proposed until after image 64 built, unfortunately a) image 64 never built and b) we set a world record on NEWing a binary package after I specifically pinged -release to *delay* that approval.
<ogra_> 64 built fine
<robru> oh i didn't see it
<sil2100> Yes, it's ok, and test results are terrible
<ogra_> right, my router hung ... so there was no bot
<robru> ah
<sil2100> Anyway, we need to build a new image as soon as the whole landing moves out of -proposed
<ogra_> *if*
<sil2100> Since right now again we ended up with everything broken...
<ogra_> yeah :(
<sil2100> Right, *if* it moves out successfully at all :|
<ogra_> lets hope the rest of  deps is correct
<ogra_> and tedg's changelog entries are as useless as possible ... that might again take hours to dig into everything if it get stuck
<ogra_> *sigh*
<sil2100> I really think it's an unlucky day, everytime I start my day, open up test results with hope it's like "*slap in the face* Nope"
<robru> ogra_, what's wrong with the changelog entries? ted basically did a global search and replace, it's technically a very simple landing... just touches a lot of components
<sil2100> ogra_: I have my dep-change detection almost ready, will deploy it today I think
<sil2100> Maybe that will help for the future
<ogra_> robru, a proper changelog mentiojs what was changed in which file *and* lists the dependency changes
<ogra_> sil2100, your dep-change script ... while nice doesnt help if someone just puts in "blh transition" in all changelogs ... it would probably add a bit of info, bu it wont tell you about code changes
<robru> ogra_, https://code.launchpad.net/~ted/unity-greeter-session-broadcast/ubuntu-app-launch/+merge/220947 I don't understand how this could have migrated so quickly. it's literally  1 line changing the dep. if it got through -proposed while UAL was in NEW, then proposed is broken
<ogra_> thats really the responsibility of the developer
<ogra_> robru, hmm, interesting ... wouldnt be proposed but the NEW queue being broken though
 * ogra_ wishes he had the backlog for #ubuntu-release ... damn router issue
<robru> ogra_, how so? proposed should have seen that the dep was missing and thus held it back. maybe this is some kind of trick with it just being a build dep and not a runtime dep...
<robru> ogra_, want me to pastebin it?
<ogra_> nope, got it on irclogs.u.c already
<ToyKeeper> Despite all the recent breakage, it's actually pretty reassuring to see that there are at least a few people actively addressing the technical and social issues which caused the issues.
<sil2100> ToyKeeper: ;)
<ogra_> robru, its a build dep, not a dep ... i guess thats the issue
<ToyKeeper> It seems like most of what needs to happen lately is already well-understood and covered, so I feel a bit less bad about being ridiculously busy with other tasks.
<ogra_> the package should have generated a proper dep from that duing build *if* it uses the right shlibdeps and miscdeps entried in debian/control
<ogra_> hmm, it does
<robru> ogra_, but read the comment. it doesn't actually link against UAL at all, it just build-deps on it as a trick to prevent it from building on wrong arches.
<ogra_> robru, yeah, tzhen it should also have gotten a dep
<robru> i see
<ogra_> ${misc:Depends} and ${shlibs:Depends} actually inspec the binary package ... if there is nothing they wont add a dep i guess
<robru> ogra_, irclogs.u.c doesn't have the queuebot notices, so in case you were interested in cross-referencing timestamps, here's a more complete log (in PST) http://paste.ubuntu.com/7585690/
<ogra_> robru, i was after the conversations to see if something with the infra was known wrong
<robru> ah
<ogra_> but the log ends with your discussion with stgraber
<ogra_> s/discussion/&conversation/
<ogra_> and there is nothing interesting before
<Mirv> ogra_: sil2100: I belive the remaining components are stuck because ubuntu-touch depends on upstart-app-launch-tools
<robru> right
<Mirv> although I'm not really expert in deciphering http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<ogra_> yeah, its super complicated to read
<robru> alright guys, sorry for the mess, one little dep just ruined everything... nearing 1AM here, I gotta go pass out
<ogra_> Mirv, well, if tedg did it right there should be a transitional package (or at least a provides) in the new package
<ogra_> since cjwatson asked him to still provide the old name i would expect either of these
 * ogra_ sighs and digs into the package 
<ogra_> http://launchpadlibrarian.net/176750267/ubuntu-app-launch_0.4%2B14.10.20140529-0ubuntu1_0.4%2B14.10.20140601-0ubuntu1.diff.gz
<ogra_> GRRRRRR !!!!
<sil2100> ogra_: wth
<ogra_> well, the rest are upstream changes it seems so i have to grab the tarball and unpack it to find out what changed
<sil2100> Right, it's ubuntu-app-launch, you won't find any useful diffs for that
<sil2100> geh
 * sil2100 tries to dig into the logs as well
<ogra_> https://code.launchpad.net/~ubuntu-branches/ubuntu/utopic/ubuntu-app-launch/utopic
<ogra_> argh !
<robru> ogra_, just click through to the merges at http://people.canonical.com/~rbpark/citrain/ much faster to see the diffs that way
<ogra_> so yeah, he took the old branch but wiped the whole history
<sil2100> btw. what other packages are we waiting for?
<ogra_> we'll never find out what changed
<sil2100> Ok, I see that
<sil2100> nm
<ogra_> robru, and they show more ? upstream wiped all history before making that timestamp bump
<ogra_> there is nothing to diff against
<sil2100> ogra_: wait, really? He cleaned the changelog?
<ogra_> this is annoying
<robru> ogra_, uh? yeah? I'm talking about the original diffs proposed against the original branches. they will show the complete diff from the old version to the new version
<ogra_> sil2100, he made a copy of the branch *after* he made all changes
<robru> ogra_, the diffs you're looking at get lost because the package was rebuilt in the PPA a few times, that's an LP PPA bug, not something malicious ted did
 * sil2100 sighs
<ogra_> oh, i see
<robru> ogra_, http://bazaar.launchpad.net/~indicator-applet-developers/ubuntu-app-launch/trunk.14.10/revision/150 is a special case, but the rest of the MPs have the complete diff
<robru> ogra_, so I'm just going to admit to this now, this is totally my fault for publishing. I thought I had gotten a core dev review for this in malta but I can't remember who, so it probably didn't happen. but I tested this and ted tested this, it looked really good at the time...
<ogra_> yeah, i see now ... there is a missing Conflicts/Replaces/Provides
<ogra_> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/ubuntu-app-launch/utopic/revision/2#debian/control
<ogra_> ubuntu-app-launch has it ... ubuntu-app-launch-tools doesnt
<ogra_> (and all the package descriptions talk about upstart app launch... not that that matters though)
<robru> i'm about to pass out though, 1AM here.... sorry again, 'night!
<ogra_> not your fault
<ogra_> whoever acked the packaging should have catched it ...
<ogra_> (though its not easy to catch if you dont have the whole picture and didnt work on it yourself)
<robru> ogra_, yeah, that guy.... oooooh! :-/
 * ogra_ wont ack anything anymore if there are no descriptive changelogs 
<ogra_> "added transitional package for foo" is an essential entry to have for example
<ogra_> GRRR
<Saviq> live another day, eh?
<ogra_> so i have http://paste.ubuntu.com/7585840/ but cant build a source package without utopic chroot and all build-deps installed because the clean target installs them ...
<ogra_> this is insane ...
 * ogra_ hates such packages ... we should forbid them
<sil2100> uh
<sil2100> I do have a utopic armhf chroot
<sil2100> Let me try
<ogra_> meanwhile my system crates one as well ...
<ogra_> *creates
<sil2100> Sadly I have no amd64 one, so this one might take things slower
 * ogra_ gets coffee
<sil2100> :|
<ogra_> for me its the 2M SDSL that makes things slow ... :P
<Saviq> ogra_, sil2100, can I help?
<Saviq> got some chroots lying around
<Saviq> (and 120M cable) :P
<sil2100> Saviq: I think we're fine, will have thr src package in a momeont
<sil2100> Yeah, just my default clean chroot seemed to be lacking a dependency!
<sil2100> Today sucks
<Mirv> Saviq: 20M faster than mine, /me sad !
<Saviq> Mirv, yeah, they give them out for free over here (well... ~â¬18)
<ogra_> wow
<Saviq> Mirv, if I signed up for a year (am renting now, so not great for long-term), I'd get 250M for that price
<Mirv> Saviq: nice, I've 29,90â¬ for that 100/10
<sil2100> ogra_: source package coming right up! (I hope so, since I was missing click-dev now...)
<sil2100> For dh-click ._.
<seb128> sil2100, do you have any plan to get silos back?
<seb128> like can we reclaim the one from the HUD SRU that got rejected?
<Saviq> sil2100, ogra_, so... libunity-mir1 upgrade breaking url-dispatcher, known?
<Saviq> is that the issue you've been fighting?
<sil2100> Saviq: I don't think it's the same thing - url-dispatcher is broken now?
<ogra_> Saviq, well, there seem to be some packages still depending upstart-app-launch-tools ...
<sil2100> But which libunity-mir1  broke it?
<Saviq> sil2100, https://launchpad.net/ubuntu/+source/unity-mir/0.4+14.10.20140601-0ubuntu1
<ogra_> thats what i'm currently poking at
<Saviq> sil2100, not yet in image 64
<sil2100> Ah
<sil2100> Ok, so we had a release of unity-mir inbetween?
<Saviq> but the next image will have it broken
<Saviq> sil2100, no, but it must not have sync'ed
<Saviq> sil2100, in time for 654
<Saviq> 64
<Saviq> sil2100, it comes from silo 018
<sil2100> Saviq: yeah, so from silo 18 the only thing that landed in 64 was unity-greeter-session-broadcast
<sil2100> Saviq: we're actually trying to migrate everything that's stuck in -proposed
<Saviq> sil2100, oh understood, so it will probably get fixed with that
<Saviq> sil2100, ok, over'n'out
<sil2100> Let's hope so ;)
<seb128> sil2100, did you see my question?
<sil2100> seb128: yes, we had a meeting - first of all we'll flush some of the silos that didn't move much during the last days
<sil2100> seb128: but we'll do that in some moments
<seb128> ok
<seb128> sil2100, I can m&c the indicator-printer SRU one if you want
<sil2100> seb128: the rejected HUD one I still want to wait for stgraber to appear and maybe give us the reasons for the rejection
<seb128> the SRU is only in proposed, but I don't expect issues to have it to migrate
<sil2100> seb128: verified? Or not yet?
<seb128> and I can sort out the vcs if that happens
<seb128> verified yes
<sil2100> Then let's m&c :)
<sil2100> THanks!
<seb128> yw!
<seb128> can I get that silo for ubuntu-system-settings then? ;-)
<sil2100> seb128: ;) Sure, let me assign one now
<seb128> sil2100, thanks!
<Saviq> sil2100, FWIW, silo 20 is ACK
<sil2100> o/
<sil2100> seb128: it will be assigned now in a moment, had to ignore conflicts due to a test silo
<seb128> sil2100, thanks
<seb128> test silo being the suru in 006 I guess?
<seb128> Saviq, ^ do you plan to land that soon or is that just a test one?
<sil2100> Yeah... forgot about that one completely and thought there are no conflicts
<Saviq> seb128, go for it
<sil2100> Saviq: would you mind if we free that one?
<Saviq> sil2100, go for it
<seb128> Saviq, go for landing it or freeing it? ;-)
<Saviq> seb128, free it ;)
<seb128> k
<seb128> thanks
<ogra_> psivaa, so looking at details of any of the failed tests there dont seem to be many logs at all
<ogra_> it seems to not have collected ~/.cache/upstart/
<sil2100> bregma: I'm m&c your unity7 SRU as well, as all bugs are verified to be fixed
<psivaa> sil2100: dbus-x11 was removed from all the mako devices.
<seb128> sil2100, +1
<psivaa> ogra_: yea, for dialer for e.g. only one file was pulled. /home/phablet/.cache/upstart/dbus-session. looks like there was no other file under ~/.cache/upstart/
<ogra_> ugh
<psivaa> let me rerun the test and see if there is any other files produced
<ogra_> ++
<ogra_> psivaa, bewtter take something else
<ogra_> sudoku is good
<ogra_> dialer will install and use dbus-x11 ... i dont want to taint the possible result
<psivaa> ogra_: ack, just about to run sudoku
<ogra_> great
<cjwatson> ogra_: surely the packages that depend on upstart-app-launch-tools also need the upstart-app-* program names, which ubuntu-app-launch-tools doesn't provide
<cjwatson> ogra_: I don't see the point in only adding the C/R/P
<ogra_> cjwatson, oh, i thought it was supposed to ship links for that
<cjwatson> ogra_: I would have preferred it that way, but meh, silo 3 cleans up the click case - are there others?
<ogra_> dunno, inspecting this landing is seriously hard no changelog entries etc, i havent digged through all the branches
<cjwatson> well, I just meant by current archive analysis
<ogra_> by current archive analysis it might be a seed issue
 * ogra_ checks 
<cjwatson> the only deps on upstart-app-launch-tools are the recommends from click (fixed by silo 3) and metapackages
<ogra_> bah, yeah ... seeds havent been in the silo
<ogra_> (or metapackages)
<sil2100> uh, wtf... just installed 64 and I have no indicators on the greeter
<ogra_> lovely
<sil2100> Now what the heck happened
<ogra_> sil2100, i would expect silo20 to fix that properly
<sil2100> Saviq: btw. did you see the warning for silo 20 when trying to publish? Is that true?
<sil2100> Saviq: since it would be really nice to have those fixes released
<sil2100> Since I'm worried with #64 not having those indicators
<Saviq> sil2100, hum? those packages are there...
<Saviq> sil2100, https://launchpad.net/~ci-train-ppa-service/+archive/landing-020/
<sil2100> Strange, maybe let's do a 'watch only' build then?
<Saviq> sil2100, kicked
<sil2100> (maybe the state will correct itself)
<sil2100> huh
<Saviq> sil2100, https://ci-train.ubuntu.com/job/landing-020-1-build/33/console not great
<sil2100> Saviq: so, it seems CI Train only thinks of unity8...
 * Saviq reconfigures
<sil2100> If this doesn't help, we might have to rebuild those two ;/
<Saviq> sil2100, did not :|
<Saviq> ok, rebuild
<ogra_> Saviq, hmm, looking at https://code.launchpad.net/~mterry/unity8/dbus-x11/+merge/221894 ... shouldnt there also be an initctl set-env in the code to actually hand the DBUS_SESSION_BUS_ADDRESS over to upstart ? or does it pick that up automatically if it exists in the env
 * sil2100 sighs
<Saviq> ogra_, it does
<ogra_> ok
<sil2100> Saviq: thanks! btw. any ideas why we again have no indicators on #64? Do you have #64 flashed? (maybe it's just a local issue)
<Saviq> sil2100, I did, and had indicators all the time
 * sil2100 reboots
<Saviq> sil2100, but om26er reported it as well, it might be intermittent, and actually should be better with silo 20
<Saviq> since we'll actually have dbus early again
<Saviq> sil2100, ah https://ci-train.ubuntu.com/job/landing-020-1-build/35/console
<Saviq> sil2100, we need to wait for silo 018 to be done with before we can land 020
<sil2100> Ah, right...
<sil2100> Saviq: btw. it's fine after a reboot
<ogra_> race !
<sil2100> Saviq: so I guess it might not be fixed all the time ;/
<Saviq> sil2100, it will be, in silo 020
<ogra_> well, the starting of dbus changed in 20
<ogra_> that hopefully improves it
<sil2100> ogra_: so, did you change the seed to include ubuntu-app-launch?
<ogra_> yes
<sil2100> \o/
<ogra_> (you should really subscribe to $release-changes ;) )
<sil2100> hm, I am!
<sil2100> Ah, wait
<sil2100> RIght, I'm subscribed to trusty ._.
<ogra_> heh
 * sil2100 changes that
 * sil2100 wonders when we'll finally be unblocked
<popey> ogra_: was it you reporting high memory usage by the browser?
<ogra_> popey, nope, by the split greeter
<popey> my phone was 436MiB after booting, starting one browser session bumped it to 603MiB
<ogra_> bug 1325580
<ubot5> bug 1325580 in unity8 (Ubuntu) "after split greeter landing unity8 and the greeter consume a lot more memory" [Undecided,New] https://launchpad.net/bugs/1325580
<psivaa> ogra_: so, the failures on 64 was only seen on one device, which i think failed on unlocking screen. i see both of these in the failed runs:
<psivaa> error: XDG_RUNTIME_DIR not set in the environment.
<ogra_> i mention the browser in there ... but didnt look specifically at browser for that bug
<psivaa> and /bin/bash: powerd-cli: command not found
<ogra_> i noticed that
<ogra_> only one device ? so if you run the same test on another one it works ?
<psivaa> ogra_: yes, it did for sudoku
<ogra_> well, that kind of goes with what sil2100 and om26er have seen ... seems there is still a race with dbus ... and sometimes the indicators dont come up due to that
<ogra_> what i dont get though is why the lightdm dbus would have any influence on the session dbus
<ogra_> it really should not
<sil2100> huh
<sil2100> Uh oh
<ogra_> lets see after silo 20 landed
<ogra_> an the UAL rename is finished
<ogra_> -meta just hit proposed
<sil2100> Yeah, we need the UAL rename to be finished to actually release silo 20 I guess
<ogra_> do we ?
<psivaa> one more thing is that that was the device which ran dialer_app test and the failures appear only on the tests ran after dialer app test.
<ogra_> that sounds like dbus-x11 wasnt removed ... if i wouldnt know better i would blame that
<ogra_> but i know it is hardcoded in teardown
<psivaa> yep :)
<ogra_> probably autoremove missed another package too
<ogra_> ofono-phonesim-autostart pulls in so much crap
<psivaa> yea, i'm going to run sudoku and dialer and then compare the packages in the device, unless there is a quicker way
<ogra_> looking in the setup and teardown logs perhaps ...
<ogra_> oh
<ogra_> https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/233/artifact/clientlogs/dialer_app/setup_setup.log/*view*/
<ogra_> do you see the top ?
<ogra_> The following packages were automatically installed and are no longer required:
<ogra_> there is a ton of stuff left over even before it installs any packages for the test
<ogra_> it should probably run autoremove --purge before it installs the test related packages
<ogra_> though ... hmm, these look all like valid packages ... why would apt offer that they get autoremoved
<ogra_> argh
<psivaa> mediaplayer and unity were the tests ran before dialer
<sil2100> ogra_: yeah, we need it since we need the UAL bits being merged and cleaned, since we need to release ubuntu-touch-session as well
<ogra_> and looking at teardown it *actually* removes them
<psivaa> lol
<sil2100> ogra_: so, for us to have a clean situation in trunks, we need UAL to land
<ogra_> so it rips out half our session
<ogra_> thats seriously bad !
<ogra_> cjwatson, are you working today ?
<sil2100> ogra_: uh, holy shit
<ogra_> seems something is clearly wrong with the way we build the image ... packages coming from the seed should never be autoremoved
<sil2100> They shouldn't, I mean that never happens normally right?
<cjwatson> ogra_: yes
<ogra_> Removing libsystemsettings1:armhf (0.1+14.10.20140521-0ubuntu1) ...
<ogra_> Purging configuration files for libsystemsettings1:armhf (0.1+14.10.20140521-0ubuntu1) ...
<ogra_> hedh, that would explain why we see errors in system-settings tests that arent explainable i guess
<sil2100> ogra_: I don't see that happening on my local image though?
<cjwatson> I don't see any autoremoving in the logs
<ogra_> sil2100, you dont use the teardown scripts
<ogra_> cjwatson, https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/233/artifact/clientlogs/dialer_app/setup_teardown.log/*view*/
<ogra_> cjwatson, or more interesting https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/233/artifact/clientlogs/dialer_app/setup_setup.log/*view*/
<ogra_> see what it offers for autoremoval at the top
<ogra_> these are all valid seeded packages
<ogra_> or depended on by a seeded package
<cjwatson> are the metapackages up to date?
<ogra_> they should
<ogra_> i just ran ./update after a seed change ... only teh bits i changed were picked up
<ogra_> so they should have been correct for the last image
<ogra_> hmm
<ogra_> i wonder if one of the autopilot-app tests tries to install all these ... that would likely mark them for autremoval, right ?
<cjwatson> so, let's take an example, I wonder why system-image-dbus is being autoremoved and yet it doesn't also feel the need to remove ubuntu-system-settings, which AFAICS depends on it
<ogra_> right
<ogra_> thats a thing we already noticed with dbus-x11
<cjwatson> is it possible that something has previously manually removed ubuntu-system-settings?
<ogra_> nothing should ... theoretically
<cjwatson> "apt-get autoremove" on my device shows none of these
<cjwatson> (image 64, all I did was mark it writable and upgrade from silo 3)
<ogra_> right, so i guess one of the tests touches them
<cjwatson> and "apt-get purge system-image-dbus" on my device wants to remove ubuntu-system-settings, ubuntu-touch, bunch of other stuff
<cjwatson> right, I don't think the image is broken, some test has removed things
<ogra_> very strange
 * ogra_ starts going through all setup_setup and setup_teardown logs
<ogra_> oh
<ogra_> https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/234/artifact/clientlogs/ubuntuuitoolkit/setup_setup.log/*view*/
<ogra_> this one is also interesting
<ogra_> "ubuntu-ui-toolkit-autopilot is already the newest version"
<ogra_> why would that ever be installed before the test runs
<sil2100> hm
<cjwatson> not relevant to this problem though
<psivaa> ogra_: thats installed by unity8-autopilot, which is needed for screen unlocking
<ogra_> psivaa, ah, thanks
<ogra_> https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/233/artifact/clientlogs/online_accounts_ui/setup_setup.log/*view*/
<ogra_> there we go
<sil2100> Interesting
<sil2100> It's installing those here?
<ogra_> why the heck does it install them ?
<ogra_> they should be there
<ogra_> and the teardown only pulls out the test https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/233/artifact/clientlogs/online_accounts_ui/setup_teardown.log/*view*/
<ogra_> psivaa, could you take a closer look at mako-10 and find out if the installed  system is actually complete ?
<ogra_> (is there a proper session running if you check with ps ... etc)
<sil2100> Right
<sil2100> system-image-dbus is on the image by default, so why the heck was it not installed on that one by default...
<ogra_> right
<ogra_> something either removed it or the complete installation is corrupt
<ogra_> psivaa, also take a look at dmesg/syslog if there are perhaps disk errors or so
 * ogra_ wonders if the MMC on that device is worn out ... 
<psivaa> ogra_: http://paste.ubuntu.com/7586603/ for ps aux | grep system
<ogra_> we dont actually use these devices like they are intended by re-flashing them so often
<ogra_> psivaa, can i get that without the grep filter ?
<ogra_> (i wnat to see unity8, indicators etc)
<psivaa> ogra_: http://paste.ubuntu.com/7586616/
<ogra_> psivaa, thats the same one ?
<ogra_> (i see the grep in the list :) )
<psivaa> ahh sorry: http://paste.ubuntu.com/7586626/
<dbarth> psivaa: hi, did you see my email about oxide builds?
<ogra_> yeah, no session
<ogra_> not even lightdm
<ogra_> wow, gross
<psivaa> dbarth: yea, i saw that. could not get a chance to reply. will do when i have some time if that's ok
<dbarth> psivaa: ok, but i just wanted to know if that's curently working (and i don't have access) or if you still need some help with it
<psivaa> dbarth: that's not working yet. awaiting a list of external web addresses that oxide needs for building from the security team for prodstack deployment
<psivaa> ogra_: http://paste.ubuntu.com/7586641/ seems to have some disk related errors ?
<sil2100> psivaa, ogra_: I don't see anything suspicious though
<ogra_> psivaa, disk seems fine there ...
<ogra_> [   21.382450] init: lightdm main process (2158) terminated with status 1
<ogra_> [   21.382633] init: lightdm main process ended, respawning
<ogra_> thats doesnt though
<ogra_> [   27.450785] init: lightdm main process (2183) terminated with status 1
<ogra_> [   27.450969] init: lightdm respawning too fast, stopped
<ogra_> neither does this
<psivaa> ogra_: sil2100: ok, i was thinking if 'EXT3-fs (mmcblk0p23): error: unrecognized mount option "discard" or missing value' is a real error
<ogra_> no, it isnt
<ogra_> if there is no fs specified the kernel loops over all known ones
<ogra_> you see that the next line properly mounts it as ext4
<psivaa> ack, i see that. thx
<ogra_> there we go ...
<ogra_> https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/233/artifact/clientlogs/unity8/setup_teardown.log/*view*/
<ogra_> there is a bug in your scripts ... it seems
<ogra_> + /var/lib/jenkins/slaves/mako-10/workspace/utopic-touch-mako-smoke-daily/touch/scripts/../jenkins/testconfig.py packages -a unity8
<ogra_> + pkgs=url-dispatcher-tools
<ogra_> + [ teardown = setup ]
<ogra_> + pkgs=url-dispatcher-tools dbus-x11
<ogra_> + adb-shell sudo apt-get autoremove --purge -y url-dispatcher-tools dbus-x11
<ogra_> it doesnt purge the unity8 test but picks url-dispatcher-tools
<ogra_> and then installs X11 metacity and a ton of other weird stuff
<sil2100> Oh!
<ogra_> psivaa, any idea from where it gets the value for "pkgs" ?
<sil2100> Yeah, and this causes ubuntu-touch to be removed...
<ogra_> right
<sil2100> ogra_: there was a configuration file for that, one moment
<psivaa> let me take a look
<ogra_> oh
<ogra_> https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/233/artifact/clientlogs/unity8/setup_setup.log/*view*/
<ogra_> it is already wrong in the setup step
<ogra_> i guess that should be unity8-autopilot instead
<ogra_> or some such
<sil2100> ogra_: http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/view/head:/jenkins/testconfig.py
<sil2100> Here the pkgs are defined
<sil2100> So yeah, there seems to be an error there
<ogra_> right, line 55
<sil2100> As it should be unity8-autopilot there I guess
<ogra_> yeah
<sil2100> Trying to fix that
<sil2100> But first
<sil2100> Let me bzr blame
<psivaa> http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/revision/203 fwiw :)
<sil2100> oh
<ogra_> http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/revision/203
<psivaa> force installing url-dispatcher-tools was to fix some unity8 test failures iirc
<ogra_> heh
<sil2100> Hah!
<sil2100> I'm to blame!
<sil2100> :O
<ogra_> that should become a dep of unity8-autopilot ;)
<psivaa> right
<sil2100> ogra_: there were some problems with that IIRC
<sil2100> Can't remember what that was
<ogra_> well, it is seeded
<psivaa> sil2100: that was some url-dispatcher related unity8 test failures
<sil2100> Now it is it seems, now this is complete BS
<ogra_> so no need for a dep as long as the AP test really only runs on the image
<sil2100> Right
<sil2100> psivaa: shouldn't we include unity8-autopilot there now?
<ogra_> we should
<sil2100> psivaa: since I see we never had that there, I think it's an error...
<ogra_> since "pkgs" is responsible for the removal
 * sil2100 fixes
<psivaa> sil2100: ogra_: unity8-autopilot is already there as a dep
<sil2100> psivaa: what do you mean?
<ogra_> psivaa, right, but we dont want it kept around after the test run
<sil2100> Right
<ogra_> teardown uses the value from $pkgs
<psivaa> ogra_: sil2100: http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/view/head:/jenkins/testconfig.py#L55 has unity8-autopilot
<ogra_> sil2100, what i dont get is ... you made that change in march
<psivaa> but screen unlock needs it iirc
<ogra_> sil2100, why didnt it bite us earlier
<sil2100> ogra_: when did we seed url-dispatcher-tools ?
<ogra_> dunno, but does that matter ?
<sil2100> ogra_: since I really can't remember what was going on, but it was something everyone agreed on
<ogra_> teardown pulls it out regardless
<sil2100> In the past url-dispatcher-tools wasn't really needed, it wasn't seeded so it wouldn't remove any necessary pacakges
<ogra_> it should have been purged all the time already
<sil2100> It was something that was only needed for unity8 AP tests
<ogra_> i dont get why that only started recently
<sil2100> I don't get it as well...
<sil2100> Let me look for context
<Saviq> sil2100, ogra_, we need url-dispatcher for split greeter, since it's proxying urls from greeter to session
<Saviq> sil2100, ogra_, granted, it should use liburl-dispatcher instead of the tool...
<ogra_> the only thing i could imagine is that the teardown code changed somehow
<ogra_> Saviq, right, but it is seeded
<Saviq> ogra_, oh, that I didn't know
<ogra_> it doesnt need to be in the list of packages to install for the test
<ogra_> well, s/be in/be/
<ogra_> :P
<sil2100> ogra_, psivaa: https://code.launchpad.net/~sil2100/ubuntu-test-cases/touch-fix-old-trouble/+merge/222014
<ogra_> who can ack that ?
<ogra_> psivaa, ?? ^^
<ogra_> sil2100, well, wait ... psivaa said above that package is needed for unlocking ?
<sil2100> Ah!
<sil2100> Wait!
<sil2100> ogra_: it's seeded now, isn't it? Or did I misunderstand? *checks*
<psivaa> ogra_: sil2100 : "Installing unity8-autopilot as a pre-req for unlocking screen"
<sil2100> Ok, it's not
<ogra_> it is installed on a fresh flash here
<sil2100> It is?
<sil2100> Ok, by some deps it seems
<ogra_> well, it is there :)
<sil2100> ogra_, psivaa: anyway, I got some context on that change of mine
<ogra_> who cares how ;)
<ogra_> sil2100, i think your change should just empty pkgs=
<ogra_> or drop it
<sil2100> So, I added url-dispatcher-tools to the pkgs in the config because in the past it wasn't installed by any deps (besides unity8-autopilot) and we run unity8 AP tests just like click app tests
<sil2100> Not like deb tests
<sil2100> Yes, that's what I think as well
<ogra_> though we should also split the unlocking stuff out of the unity8 AP package ... doesnt seem right to have that always installed
<sil2100> Since I remembered that installing unity8-autopilot won't make sense
<sil2100> ogra_: since we don't use unity8 AP tests from the unity8-autopilot package during the tests anyway
<sil2100> ogra_: since as I said, the infra uses methods as per click app testing
<ogra_> right, bt it might pull in something harmful
<sil2100> ogra_: i.e. downloads the AP source to ~/autopilot
<sil2100> Right
<sil2100> Let me change it back now
<sil2100> (to empty pkgs)
<ogra_> right, just drop the pkgs handling from that line
<sil2100> Done
<ogra_> psivaa, can you ack and merge that ?
<psivaa> ack, 1 sec pls
<ogra_> hmm, meta still sits in porposed
<sil2100> uh...
<ogra_> looks fine on the excuses page
<ogra_> ah, ubuntu--system-settings seems to be still doing its autopkg tests
<sil2100> phew
 * ogra_ grins 
<ogra_> the autopkgtest for autopkgtest failed
<sil2100> That's funny ;)
<psivaa> ogra_: sil2100: that's change is now merged. do you want me to kick a test run with that change or wait for the next image?
<ogra_> the next image is still far away it seems
<ogra_> just re-kick
<sil2100> psivaa: thanks :)
<psivaa> ack
<sil2100> ogra_: yeah, so... the problem started happening now because of the greeter upload
<sil2100> ogra_: as per what Saviq and reverse-depends says ;)
<ogra_> i dont get that
<ogra_> why would that have any influence on teardown ?
<ogra_> teardown is dumb, it just purges whats in pkgs=
<sil2100> So, yeah, it purges url-dispatcher-tools, which now is a dep of unity-greeter-session-broadcast, which is a dep of unity8 and such
<ogra_> url-dispatcher-tools is a dep of unity8-common
<ogra_> and was for a while it seems
<sil2100> root@amatsu:/# reverse-depends url-dispatcher-tools
<sil2100> Reverse-Depends
<sil2100> ===============
<sil2100> * unity-greeter-session-broadcast
<sil2100> * unity8-autopilot
<sil2100> This is the only thing I see on my utopic chroot
<sil2100> I don't see it as a dep of unity8-common, so where did you get this info?
<ogra_> oh
<sil2100> So, it wasn't a problem before as in the past only the -autopilot one was depping on it
<ogra_> sorry i looked at a diff and was cheated :P
<ogra_> http://launchpadlibrarian.net/176631625/unity8_7.86%2B14.10.20140527-0ubuntu1_7.87%2B14.10.20140530.1-0ubuntu1.diff.gz
 * ogra_ missed the @@ line above
<sil2100> Ahah!
<sil2100> Right ;)
<ogra_> yeah, so thats it
<sil2100> Damn diffs
<ogra_> great ... lets see the test results
<ogra_> seems all autopkgtests are done for the UAL bit ... lets see, next publisher should pick it up
<sil2100> YESS
<sil2100> :D
 * sil2100 can't wait
<ogra_> what a chaos
<sil2100> The last 3 days are terrible
<ogra_> yeah
<ogra_> well, happy we traced it down
<Chipaca> would now be a good time for me to pimp https://wiki.ubuntu.com/Chipaca/PPU ?
<Chipaca> :)
<ogra_> who would have thought we have no session anymore :)
* vila changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: vila | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<sil2100> Anyway, I guess we should really move this kinds of discussions to -release
<sil2100> We'll be spamming the channel a lot but I guess that's required
 * ogra_ wonders what to do with imgbot
<sil2100> Hug him?
<ogra_> no, i mean if it should move along etc
<sil2100> I wonder as well, I guess we should ask slangasek?
<ogra_> i need to rework it a bit as well so that people get it talks about touch images
* vila changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<ogra_> sil2100, you should write an announcement mail that the conversations will move over
<ogra_> so people know about ...
<ogra_> to -phone and -devel i guess
<sil2100> Yeah, we've been thinking about that, but hm, slangasek said we shouldn't
<ogra_> oh, hmm, k
<sil2100> Since we never really announced -ci-eng as the channel officialy anyway ;p
<ogra_> asac, and didrocks did ... they even asked people to join here
<asac> what?
<ogra_> asac, landing team is supposed to do its conversations in #ubuntu-release now
<asac> i dont think thats decided
<ogra_> and iirc there was a mail that pointed people here
<asac> we dont change anything until there is a plan
<ogra_> which is why i said we should have an announcement mail for the move
<asac> right, but we dont move right now
<ogra_> ah, i thought there was one
<asac> things are getting mixed up
<asac> long term goal is to merge the worlds
<asac> but we haven't even looked at what to do to get there
<ogra_> ah
<Laney> I think most of the things that the landing team talks about aren't really release matters
<asac> first step is to move LT operations into foundations, but keep things unchanged
<asac> second step is to think about how to get our landing process long term worked into the way ubuntu works and vice versa :)
<Laney> they're probably better suited to -touch or -devel
<asac> its perfect here
<ogra_> ok, what rob and sil2100 said sounded like the conversations were supposed to move along with them
<asac> for now
<asac> not perfect in general
<ogra_> when tehy move teams
<Laney> If you want to move it
<asac> ogra_: this channel is not owned by ev
<sil2100> Well, slangasek pointed -release as the best place for landing talk, as usually we're chatting about things landing in the archive and the image
<ogra_> no, but slangasek seemsed to want the conversations in release ... he didnt sound like that was a long term thing yesterday either
<sil2100> I'm fine with any channel TBH
<sil2100> Would prefer something from the likes of -devel or -touch
 * ogra_ doesnt care at all ... but i want the imgbot to run in the respective channel 
<asac> sil2100: yes, but thats mid/long term. for now we decided to not change anything, but home
<asac> :)
<ogra_> and i dont want scattered conversations across multiple channels
<asac> sil2100: and then once you guys have started n the new team, discuss how to improve things going further
<asac> one part is the channel, but thats probably not really a priority :)
<sil2100> Yeah, just wanted to make sure it's more public
<sil2100> As only landers and some core-devs know about -ci-eng
<sil2100> All others are living in oblivion and don't know anything about what's going on during our discussions
<sil2100> Not a priority, but still
<sil2100> It's more like a bikeshed problem
<asac> sil2100: sure, things can be discussed. but it should be put into a bigger plan
<asac> just moving channels wont help at all ... instead might cause frustration even of the current release team
<asac> as you can see by Laney's comment above :)
 * asac lunch
<sil2100> psivaa: is the calendar still running and presenting old test results, or did we get so many failures again?
<psivaa> sil2100: it's still running and the new results are not yet updated
<sil2100> Anyway, it looks good in overall!
<psivaa> sil2100: yea.
<psivaa> off to lunch
<sil2100> o/
 * sil2100 should eat something as well soon
 * ogra_ just had breakfast :) 
<sil2100> I had a carrot!
<ogra_> yummy
<jdstrand> psivaa-lunch: if you haven't already, when you respond to the oxide email can you be sure to tell us exactly what you need. I think there might have been miscommunication-- I for one didn't realize you were waiting on something from us (but, I could easily not be up to date, but better safe than sorry :)
<sil2100> Ok, time for lunch!
<sil2100> o/
<cjwatson> I'm confused about why we apparently need extensive discussions and planning to talk about things on a different IRC channel
<cjwatson> seems like bureaucracy
<cjwatson> looks like silo 18 needs some manual proposed-migration hinting; attempting to sort that out
<cjwatson> though actually I should wait for click to land first
<ev> sil2100, robru: can one of you find a time that works within the landing schedule: https://rt.admin.canonical.com/Ticket/Display.html?id=68826
<dbarth> Mirv, psivaa-lunch: to be clear, silo 4 should be deleted, we can't land this change anymore; qtwebkit 5.2 has to go alone
<Mirv> dbarth: psivaa-lunch: yeah I was going to ask for clarification. you mean, the webbrowser-app should be deleted, and qtwebkit alone?
<Mirv> I can reconfigure
<Mirv> in that case, it should be now ready for testing
* cprov changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cprov | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<elopio> ping cprov. I'm having a problem with the jenkins job for MPs in ubuntu-ui-toolkit
<elopio> it doesn't seem to install the ubuntu-ui-toolkit-autopilot package from the branch, it takes the one in the archive.
<cprov> elopio: which job ?
<elopio> cprov: https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/1081/artifact/clientlogs/ubuntuuitoolkit/dpkg-l.log
<elopio> on the log I see this
<elopio> Unpacking ubuntu-ui-toolkit-autopilot (0.1.46+14.10.20140602-0ubuntu1) over (0.1.46+14.10.20140520bzr1092pkg0trusty1235+autopilot0)
<elopio> I think the on I need is the one with bzr on the name.
<cjohnston> elopio: 20140602 > 20140520
<stgraber> sil2100: the reason for the rejection should have been in the reject message.
<cjohnston> Just my guess, but sounds like trunk may need to be merged...
<elopio> cjohnston: I get that, but why is the bzr version 20140520 instead of yesterday, when it was built?
<stgraber> sil2100: looking at the diff again, it probably was that you have changes in there without bug references so no testcase or anything to be used to verify the SRU in proposed
<popey> ogra_: you seeing bug 1326378 ?
<ubot5> bug 1326378 in webbrowser-app (Ubuntu) "webapp-container leaks memory over time on #63" [Undecided,New] https://launchpad.net/bugs/1326378
 * popey edits that to #64
<bfiller> sil2100: can we get a silo for line 22 now? was blocked on silo 18 but think that's released now
<cjohnston> elopio: what branch is this pulling from
<elopio> cjohnston: https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1326072-create_fake_xauthority/+merge/221953
<bfiller> elopio: will gallery still need this workaround branch after the proper ui-toolkit fix lands? https://code.launchpad.net/~elopio/gallery-app/workaround1324556-get_header/+merge/221415
<elopio> bfiller: no.
<bfiller> elopio: ok thanks
<elopio> bfiller: if you haven't merged it, please just reject it.
<bfiller> elopio: will do
<elopio> thanks.
<elopio> I'm sorry for the mess. If you still see something weird on your landing please let me know.
<cjohnston> elopio: the changelog lists ubuntu-ui-toolkit (0.1.46+14.10.20140520-0ubuntu1) utopic; urgency=medium, isn't that what we get the version number from?
<cjohnston> elopio: trunk has ubuntu-ui-toolkit (0.1.46+14.10.20140602-0ubuntu1) utopic; urgency=low
<ogra_> popey, way to high, but not rising here
<cjohnston> that seems to match why the 'wrong' one is being installed
<elopio> cjohnston: I'm lostttt. Where are you seeing that changelog?
<cjohnston> in the branc
<cjohnston> branch
<elopio> and anyway, shouldn't the job that builds the deb update that change log?
<cjohnston> not based on this commit: http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/revision/1030
<elopio> bzoltan: I need your help here ^
<elopio> we need the versions of the debs generated on the MPs to be higher than the ones in the archive.
<elopio> should I update the changelog for every MP ?
<cjohnston> elopio: the job appears to append the MP information to the version..
<cjohnston> you just need to merge trunk
<cjohnston> as long as you have trunk, you should be good to go
<cjohnston> because it will take 0.1.46+14.10.20140602-0ubuntu1 and turn it into 0.1.46+14.10.20140602-0ubuntu1bzr1092pkg0trusty1235+autopilot0
<cjohnston> so you would be good to go
<bzoltan> elopio:  a sec, I am on a call
<elopio> cjohnston: but I need to merge into staging. If I also have this branch merged with trunk, I will cause a mess.
<elopio> so the problem could be that staging is not merged with trunk.
<ogra_> popey, mem usage doesnt change here ...
<cjohnston> elopio: sounds like we need to wait for bzoltan and fginther
<elopio> cjohnston: I see they have now the same revision.
<elopio> so probably a new run will succeed.
 * elopio kicks jenkins.
<bzoltan> cjohnston:  shoot
<elopio> bzoltan: I think the problem was caused because when jenkins ran, staging was not up-to-date with trunk.
<elopio> cjohnston: helped me finding the cause, and I think that this new run will pass all the tests.
<bzoltan> elopio: possible... did we miss something?
<cjohnston> bzoltan: can you read scrollback between me and elopio please? I believe that in his MP, it isn't doing what he wants because his version number is lower than trunk
<bzoltan> elopio: cjohnston: this is the next landing https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/landing_04-06/+merge/221987
<elopio> bzoltan: and I'm talking about this branch: https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1326072-create_fake_xauthority/+merge/221953
<elopio> bzoltan: without it, you will get one error on mako on an xauthority test.
<bzoltan> elopio:  do you want me to merge this MR to the 04/06 landing MR?
<elopio> bzoltan: if jenkins confirms it fixes the bug, yes, it would be nice.
<elopio> otherwise you'll get one red on the dashboard ruining our almost perfect stats :)
<popey> ogra_: took some hours.
<seb128> sil2100, why are the comments cases in pink color starting l41?
<seb128> does it mean we shouldn't use those lines?
<ogra_> popey, ah, i'll leave it running then
<sil2100> seb128: uh, no, that's some spreadsheet bollocks
<sil2100> seb128: you can assign it normally
<seb128> sil2100, thanks
<fginther> cjohnston, elopio, sorry for being occupied elsewhere... It sounds like you think you have the issue resolved by rebuilding?
* plars changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: plars | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<dbarth> Mirv: yes please, just qtwebkit
<dbarth> Mirv: is that in the same silo still?
<Mirv> dbarth: yep, same silo landing-004, I built it earlier today. now it only has the qtwebkit and it's built ok for all archs.
<sil2100> hm, UAL still in proposed I see
<sil2100> ogra_: do you know why ubuntu-touch-meta doesn't migrate?
<bfiller> sil2100: need a silo for line 43 when you get a chance (ubuntu-keyboard)
<ogra_> sil2100, cjwatson is on it
<ogra_> sil2100, i think he still waits for click to finish
<sil2100> bfiller: sure
<sil2100> ogra_: ACK, thanks!
<dbarth> Mirv: ok, ready for testing then
<sil2100> brb
<cjwatson> ogra_: I committed the hint change, haven't checked its results
<ogra_> ah, LP says pending for meta now
<cjwatson> yeah, it worked
<sil2100> ogra_: things seem to have migrated \o/
<ogra_> have they ? i still see them on the excuses page
<ogra_> weird
<ogra_> its still all in proposed
<sil2100> LP says otherwise
<sil2100> So it should migrate out soon I guess?
<ogra_> dont trust lp ;)
<ogra_> yeah
<sil2100> At least before even LP didn't consider it migrated ;) So we're good
<sil2100> ...I guess
<robru> sil2100, yeah, lp reports the migration prematurely. fortunately I've never seen lp outright *lie* about it, just that lp reports the migration at the beginning of when it happens, and rmadison reports it at the end (eg, when it's actually done for real). this has bitten us a few times, but it's not like LP can say "it migrated!" and then it doesn't after that.
<sil2100> Let's hope this didn't change
<sil2100> As rmadison says it's not migrated :)
<robru> sil2100, yeah, lp says it migrated only 23 minutes ago, give it some time yet ;-)
<cjwatson> LP won't lie, no, but the database doesn't know when the publisher is entirely done (as in synced out to mirrors).
<cjwatson> Maybe once the work to allow LP to be a portal for non-database information is completed, we'll be able to have it show mirror state.
<cjwatson> The visible copy of update_excuses will typically update a couple of minutes after the copy is processed by LP, because proposed-migration does the copies and then spends a few minutes calculating various statistics before it publishes everything to the website.
<sil2100> cjwatson: ok, good to know :)
<robru> looks good in rmadison now
<sil2100> ogra_: hey, you got a moment for a packaging ACK? Although I'm afraid you'll -1 it ;)
<sil2100> ogra_: https://ci-train.ubuntu.com/job/landing-010-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-scopes-api_0.4.8+14.10.20140604.1-0ubuntu1.diff and https://ci-train.ubuntu.com/job/landing-010-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-scopes-shell_0.4.0+14.10.20140604.1-0ubuntu1.diff <- so, one depends on a newer version of the other, some symbols changing (only internal as always) aaaand: no 
<sil2100> ogra_: so I say +1 on all the other changes, but I remember you said you won't +1 anything that doesn't mention dep changes ;)
<ogra_> sil2100, well, thats minor enough to +1 ... i meant serious dep changes ... bumping a version is surely not serious :) and i'm willing to let that one added -dev lib through
<sil2100> ACK ;)
<sil2100> Thanks! But no worries, my change will make things much easier
<ogra_> sil2100, i thik i'll have to write a mail first, expressing that ... if people *then* dont mention their dep changes i'll nack
<sil2100> ogra_: hah! I'll also mention it in my mail today ;)
<ogra_> thanks :)
<ogra_> sil2100, btw, how about an image build
<sil2100> ogra_: I wanted to build an image with silo 20 in it...
<sil2100> :<
 * sil2100 is still waiting for that
<ogra_> ah, k
<sil2100> It was held back for UAL
<sil2100> mterry: how far are you with silo 20?
<ogra_> right. thats done
<sil2100> I want a new image NOOOOW
<mterry> sil2100, it's all built in PPA, just waiting to be published in PPA
<mterry> sil2100, I think when that happens, we'd be ready?
<sil2100> mterry: is this silo tested?
<mterry> sil2100, yes
<mterry> sil2100, well
<mterry> sil2100, it was before I just rebuilt ubuntu-touch-session with a merge from trunk.  I suppose I should retest
<sil2100> mterry: I guess a quick re-test might be enough, you know, if everything still works with the UAL and other bits
<sil2100> bfiller: silo assigned, in a moment the spreadsheet should refresh
<sil2100> bfiller: (sorry for the wait(
<sil2100> )
<sil2100> )
<sil2100> (wanted to close all the parentheses, don't like to leave any open)
<robru> (((((((((
<sil2100> mterry: just give us a poke once you're done, we're waiting for this!
<mterry> sil2100, understood
<sil2100> Argh! Syntax error!
<robru> lol
<sil2100> )))))))))
<ogra_> parentheses are so last decade ... curly brackets are the new shiny !
<cjwatson> robru: evil
<robru> sil2100, you're the greatest ;-)
<ogra_> {{{{{{{{
<robru> muahaha!
<sil2100> Aw come ooon, you stop trolling meeee!
<robru> cjwatson, some people just want to watch the world burn
<sil2100> }}}}}}}}
<sil2100> Ok ok enough
<ogra_> {
<ogra_> (SCNR)
<sil2100> Sometimes I'm happy we're not doing things like that on -release... }
<robru> }
<robru> sil2100, got your back on that one
<sil2100> Oh no! So now I introduced an error
<ogra_> now thats team work !
<sil2100> robru: once things calm down and no spreadsheet actions are happening, you can press the Archive button
<sil2100> Since we had a lot of Landed entries
<robru> sil2100, alright, I'll do it later
<mterry> sil2100, still good
<sil2100> mterry: publishing then!
<mterry> sil2100, yay!
<sil2100> ARGH
<robru> ?
<sil2100> mterry: did you build telephony-service ?
<mterry> sil2100, no just ubuntu-touch-session.  does telephony-service need a rebuild?
<sil2100> 2014-06-04 15:48:09,896 ERROR Some projects (telephony-service) that were in the silo configuration list were not built. Prepare either prepare the latest missing projects or use the ignore missing projects flag which will release the lock on them.
<robru> oh awesome
<sil2100> We need to press the build button for telephony-service...
<robru> sil2100, how much you wanna bet that a watch-only build won't work?
<mterry> sil2100, I'm confused on why (still new to final steps involved in landing a silo)
<sil2100> robru: we did that already
<robru> mterry, it's a glitch in the matrix
<robru> sil2100, so, what you're saying is.... i won the bet?
<sil2100> robru: with Saviq in the morning... we then wanted to build the whole silo again, but UAL blocked it
<sil2100> robru: ;)
<robru> ;-)
<sil2100> mterry: let me run the build job
<mterry> sil2100, so I should rebuild whole silo?
<mterry> sil2100, ok
<robru> mterry, basically the backend state of citrain got itself confused, it doesn't realize that telephony-service was already built, the only way to get out of this situation is to rebuild it. it really sucks
<sil2100> We could hack it in the backend, but...
<sil2100> It's risky and very uncomfortable, as we don't have direct SSH access
<sil2100> So I have to workaround it in really stupid ways :|
<mterry> OK
<sil2100> Let's hope it will be fast...
<dbarth> o/ silo 16 good to go
<sil2100> robru: ^ :)
<robru> dbarth, cool thanks, we can land that soon, i think we just want to get an image built first. right sil2100 ?
<sil2100> Is that something big?
<sil2100> Like, risky?
<robru> sil2100, well, webbrowser-app
<sil2100> I see it's a dormant landing
<sil2100> So I would say let's publish
<robru> sil2100, alright
<sil2100> robru, ogra_: meeting!
<dbarth> robru: np, not in a hurry there
<sil2100> plars: ^
<sil2100> popey: ^
<popey> sorry, was grabbing coffee
<robru> ogra_, https://ci-train.ubuntu.com/job/landing-016-2-publish/lastSuccessfulBuild/artifact/packaging_changes_webbrowser-app_0.23+14.10.20140602-0ubuntu1.diff packaging ack before you drift off to sleep?
<popey> sil2100: shall I just start a separate thread about memory on the list?
<popey> so people see it rather than it being lost in a landing mail thread?
<ogra_> robru, nice one ... even though it doesnt mention packaging changes directly it is actually descriptive enough to understand that there must be some ... ack
<robru> ogra_, thanks!
<ogra_> (i wont fall dead right now btw ... but earlier )
<robru> ogra_, ;-)
 * popey goes to make food, back later
<sil2100> popey: yes, please :)
<bfiller> robru, sil2100 : are we able to get a silo for line 22 now as the UAL stuff has landed?
<robru> bfiller, sure!
<robru> bfiller, ah, you got silo 12, please build
<bfiller> robru: thanks!
<robru> bfiller, you're welcome!
<sil2100> ogra_: ! Did you see the test results :O ?!
<sil2100> ogra_: only 5 failures!
<robru> sil2100, so what? mako is fine ;-)
<robru> sil2100, I'm not sure what's more incredible, the lack of failures on mako or the massive amount of failures on everything else ;-)
<sil2100> robru: the failures everywhere else are caused by the thing we mentioned on the meeting
<sil2100> We didn't re-run other than mako
<robru> oh ok
<robru> sorry must have missed that bit.
<sil2100> So flo and manta still have the b0rken a bit ;)
<sil2100> The next run will be fine
<robru> sil2100, should I publish 20 now that it rebuilt?
<sil2100> robru: yes, if it's done then yes ;) Be sure to mention mterry in that, and auto-ACK the packaging as mterry is a core-dev
<mterry> yay
<robru> sil2100, oh I like landings for core devs ;-)
<sil2100> Yeah, love them as well ;p
<sil2100> We can then act as normal monkeys, pushing buttons blindly
<robru> sil2100, oh goody! monkey mode!
<sil2100> ogra_, robru: in today's mail I won't yet add new AP failures as we only got proper test results not so long ago
<sil2100> So I didn't have time to check those
<robru> alright
<sil2100> robru: are you very busy toda?
<sil2100> *today?
<robru> sil2100, well I'm spending most of the day teaching myself some new tools. happy to help with anything you need
<sil2100> robru: since if you have a free moment, could you do some analyzing for me? Take a look at the dashboard for #64 and look at the failures we have for calendar_app, dialer_app and ubuntuuitoolkit on mako, try looking into the testcase and (if possible) try reproducing it manually
<sil2100> It might be hard, if some testcase is complicated you can just leave it as it is
<robru> sil2100, oh sure
<sil2100> Anyway, for each of those could you in the end fill in a bug and send me an e-mail?
<sil2100> With a quick note if you could reproduce it or not
<sil2100> robru: thanks! :)
<sil2100> It's nothing high-priority if anything, but still would be nice to have this
<sil2100> robru: if you could also more or less approximate how much time it took you then it would be nice, we need to benchmark this a bi
<sil2100> t
<robru> sil2100, sure thing
<sil2100> Since if it's a very time-consuming process, we might need to get someone else to do it... I'm already enough busy as it is
<sil2100> Ok, time to send the e-mail ;p
<robru> sil2100, alright, running uitk tests
<sil2100> robru: ok, remember to try running them manually - by manually I mean 'by hand', without AP
<sil2100> i.e. reading the test case in autopilot and trying to emulate the same movements/behavior
<sil2100> If a test case seems a bit too complex or big, then just drop it
<sil2100> Ok, I guess I go rest now a bit as well
<sil2100> See you tomorrow o/
<robru> ogra_, cyphermox, rsalveti: ok, so silo 20 landed for real (really for real, rmadison confirmed for real ;-) can whoever's around kick an image build? thx
* plars changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
* fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: fginther | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<robru> seb128, hey, any way that lines 45 and 46 can go in the same silo? I know they're unrelated but trusty SRUs lock the silos for a long time so if they don't conflict, you should be able to test them independently from the same silo
<robru> tedg, you got 14
<tedg> robru, cool, thanks!
<robru> tedg, you're welcome!
<seb128> robru, better to keep differents silos, we can m&c before they are in updates, those shouldn't create issues
<robru> seb128, ok
<popey> robru: planning on kicking an image tonight?
<robru> popey, i tried, nobody responded to my ping
<robru> seb128, ok you got 16 and 17
<robru> slangasek, hmm, can you kick images?
<slangasek> robru: kicking now
<robru> slangasek, ah, thank you!
<imgbot> === trainguard: IMAGE 65 building (started: 20140604 20:00) ===
<popey> \o/
<robru> this is gonna be a big one
<robru> UAL + split greeter fixes
<robru> plus a bunch of random other things
<imgbot> === trainguard: IMAGE 65 DONE (finished: 20140604 21:35) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/65.changes ===
* fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<robotfuel> cihelp, I've noticed I can't adb reboot bootloader on todays image, has anyone else reported this?
#ubuntu-ci-eng 2014-06-05
<tedg> robru, By chance are you still around?
<robru> tedg, hey, just got back. what's up?
<kenvandine> robru, he wants a silo for a ubuntu-app-launch fix
<robru> tedg, ok you got silo 2
<kenvandine> i just hassled tedg on IM :)
<tedg> Heh
<robru> kenvandine, hey hey. how was malta? such a shame we couldn't connect
<kenvandine> good, yeah missed you guys
<tedg> robru, Thanks!
<robru> tedg, you are welcome!
<kenvandine> i did get to hang out with seb, larsu and dsert though
<kenvandine> and of course tedg :)
<robru> kenvandine, i wish I could go to these things for both weeks
<kenvandine> tedg, that was some damn good carbonara!
<tedg> robru, You say that the first couple times ;-)
<tedg> kenvandine, It was.
<kenvandine> ha... i do not miss the 2 week trips, not at all :)
<kenvandine> tedg, thanks for the fix!
<tedg> kenvandine, The L'Artist restaurant was the best there though.
<kenvandine> i didn't get to try that place
 * kenvandine goes back to writing API docs for bacon2d :)
<kenvandine> which is not nearly as much fun as game hacking :)
<tedg> Oh, ogra uploaded a fix...
<kenvandine> ah... distro patch? :)
<tedg> Yeah...
<kenvandine> when?
<kenvandine> i don't see a change mail for it
<tedg> kenvandine, https://launchpad.net/ubuntu/+source/ubuntu-app-launch
<tedg> kenvandine, Not for this, for a packaging issue.
<kenvandine> ah
<robru> tedg, oh right, you have to sync distro back to trunk there.
<tedg> On it.
<robru> cool
<tedg> Who can review this? https://code.launchpad.net/~ted/qa-regression-testing/ubuntu-app-launch/+merge/222115
<robru> tedg,  these people? ;-) http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/changes
<tedg> Ewww, security people :-)
<tedg> Hmm, clock isn't starting for me now. "(process:3727): GLib-GIO-ERROR **: No GSettings schemas are installed on the system"
<imgbot> === trainguard: IMAGE 66 building (started: 20140605 02:10) ===
<tedg> Uhg, missed 66 I guess.
<robru> yeap
<robru> camako, hey
<camako> robru, hey so is there anything I need to do at this point?
<robru> camako, haha we're talking in two channels, bah ;-)
<robru> tedg, http://ci.ubuntu.com/smokeng/utopic/touch/mako/65:20140604.1:20140530/8401/music_app/ is this related to UAL?
<tedg> robru, I don't think so. Noticing that clock and terminal are also broken.
<tedg> robru, Okay, nope, I think at least terminal is mine.
<robru> tedg, ah
<tedg> robru, Rebuilding that silo with the fix.
<robru> tedg, cool
<plars> ugh
<plars> robru: something's wrong still
<plars> robru: I'm testing 65 at home with *just* music_app and it's working
<plars> unfortunately... I really hate that stupid song it plays
<robru> plars, what do you mean by "just music_app"?
<robru> plars, I think you can mute the phone while the test runs ;-)
<plars> robru: not running all the tests, just that one since it seems to fail everywhere
<robru> plars, oh, so you're suggesting that this is an infrastructure problem?
<plars> robru: that would involve getting out of the chair :)
<plars> robru: no
<plars> robru: but it could be like the other problems we've seen over the past couple of days where a package is messing things up
<robru> plars, right I see.
<robru> plars, anything I can do to help with that?
<plars> robru: going to try a few things, but I'm exhausted right now
<plars> I'll stay up as long as I can and try to sort it out
<robru> plars, alright, let me know if there's a specific test you want me to run on my mako or whatever, i've got a couple spare cycles.
<plars> robru: the changes list for 65 was enormous
<robru> plars, yeah, sorry abou that. are you bisecting it?
<plars> robru: no way
<plars> robru: I'd be up for the next few days
<robru> plars, I blame UAL for everything. revert that one first ;-)
<plars> :)
<tedg> I think a couple of the apps issues were based on not having all the env vars set.
<tedg> They were falling back to running as legacy apps, which doesn't set all the confinement variables.
<tedg> robru, I didn't change the tracepoints yet, was letting the application startup guys get off the ground before throwing them a twist.
<robru> tedg, ah sorry, didn't realize those were *all* tracepoints, I was just concerned by the length of that list
<robru> tedg, thanks for clarifying
<tedg> robru, almost all, most are inert, but going to fix them anyway. Stop the next person from getting confused.
<plars> tedg: does https://jenkins.qa.ubuntu.com/job/utopic-touch-flo-smoke-daily/144/artifact/clientlogs/calendar_app/_usr_lib_python3_dist-packages_autopilot_run.py.32011.crash/*view*/ mean anything to you?
<plars> tedg: specifically: DuplicateSignature: upstart-app-launch-invalid-appid
<plars> the apps that are crashing seem to all have this
<tedg> plars, It's basically a report saying that it can't find the app.
<plars> tedg: and http://paste.ubuntu.com/7592099/
<plars> tedg: is that the issue you were describing where not all the environment variables are set?
<tedg> plars, Hmm, not sure on that one.
<tedg> plars, That may just be from the app not starting though.
<plars> robru: hmm, I think I'm able to reproduce this now at home
<tedg> plars, It seems like that error is in autopilot, so my guess would be that it can't find widgets because there isn't a window.
<robru> plars, oh really?
<plars> wait, maybe not, too early
<veebers> tedg, plars: I overheard (incompletely) that there are some issues with upstart, autopilot and applications. I may be of service if it has something to do with autopilot
<plars> I thought it was farther along
<tedg> veebers, Not sure it's an autopilot issue specifically, but here's the trace: http://paste.ubuntu.com/7592099/
<plars> nope, it's still working here
<tedg> To really break things you're going to have to wipe.
<tedg> The problem is that the cache dir in ~/.cache/upstart-app-launch will stick around.
<veebers> tedg: hmm, all I can tell from that is that the app failed to launch :-) Is this issue (issues?) happening outside of the autopilot tests?
<veebers> i.e. is autopilot launching (or attempting to) the application correctly
<tedg> veebers, Yes, it is. So I don't think it's an AP issue.
<veebers> tedg: ah ok, I'll butt-out then :-) let me know if I can help out if there are AP issues
<plars> robotfuel: interesting, I've seen that off and on with a few devices lately
<plars> robotfuel: not on the one that was current when you said that (64 I think?) but with 65, and with some earlier ones too
<robotfuel> plars: are there any workarounds that you know of?
<plars> robotfuel: holding the volume down button while turning it on
<plars> robotfuel: I was getting suspicious that we just had some devices starting to go bad
<robotfuel> plars: interesting I had to do it 2 times, the phone went to recovery from the ubuntu-device-flash script after holding the volume button down, but it still wanted it in bootloader
<plars> robotfuel: oh, well if you specify --bootloader to ubuntu-device-flash it want's it in fastboot mode
<plars> robotfuel: but it won't try to reboot it to fastboot, you have to do that part
<tedg> K, so silo 2 seems to fix the issue of the click packages falling back to legacy.
<tedg> (and a related bug stemming from that)
<tedg> Clock is still broken for me though.
<tedg> Seems to be getting a GSettings error.
<tedg> robru, plars, so I think that silo2 fixes a bunch of the errors, not sure about all though.
<plars> well, I guess we'll see how 66 looks and see if silo2 provides any relief
<plars> I'm going to run the full set of tests from home with some hope of reproducing whatever's going on
<plars> in isolation, I can't seem to reproduce, but it could just be something that doesn't happen every time
<tedg> Makes sense. When would we have results for 67?
<tedg> 1000 UTC?
<tedg> I'm going to head to bed, if someone could publish 2 that'd be awesome. It definitely makes things better.
<plars> tedg: after it builds
<plars> tedg: 66 is the latest image right now
<plars> and it's looking bad for unity8 at the moment
<plars> I'm watching the carnage right now but I'm going to need sleep shortly... hopefully I won't have nightmares about this all night
<tedg> Heh, I hope not!
<tedg> 'night folks
<camako> robru, now status says "Migration, one pkg at least is not available at the dest.....". Do I need to intervene?
<plars> robru: well, I'm going to go try to get some sleep. expect unity8 failures in this image 66 at the very least. Not sure about the failures from 65 yet since I didn't manage to reproduce but I'll have a full run going tonight
<plars> robru: I'll be mostly off tomorrow, but will try to get back to my computer as soon as I can (probably mid-late afternoon)
<camako> Can anyone from CI team clarify what this means : "Can't merge: One package at least is not available at the destination......"
<Mirv> camako: did you get that sorted out? it means some package hasn't migrated yet to release pocket.
 * sil2100 sighs
<sil2100> So, the tests seem to be somewhat broken again - not sure if that's showing off a real bug or just some new problems
<sil2100> I wonder if the big landing of the UAL has something to do with it, as the apps fail on application start
<ogra_> sil2100, the two apps are UAL
<ogra_> missing the package rename in autopilot
<ogra_> no idea what uniy8 is though
<sil2100> ogra_: you think so? As I see other apps working fine without the rename
<ogra_> Attempting to launch application 'com.ubuntu.music_music_1.3.476' with URIs '' via upstart-app-launch
<sil2100> I see message "with URIs '' via upstart-app-launch" in others that pass
<ogra_> yes, i think so :)
<ogra_> oh ?
<ogra_> hmm
<sil2100> ogra_: if you open the console log and grep for 'via upstart' you'll see that it's used multiple times
<ogra_> ** (process:3263): WARNING **: Unable to find keyfile for application 'com.ubuntu.music_music_1.3.476'
<sil2100> So I thought that it's just a leftover name
<ogra_> could be indeed
<ogra_> _usr_lib_python3_dist-packages_autopilot_run.py.32011.crash
<ogra_> both crashed apps have that one
<sil2100> hmmm
<sil2100> Maybe screen unlock didn't work?
<sil2100> Oh, crash
<ogra_> yeah
<sil2100> First I thought about screen unlock failures, as it makes sense in the failure rate... i.e. if it fails for an application test suite, then all tests fail - for unity8 only certain tests fail as the unlock happens on each test
<ogra_> sil2100, hmm, could it be that your fix for the test setup yesterday used an old branch ?
<sil2100> hmm, what do you mean?
<ogra_> i see "ubuntu_filemanager_app" there ... that was changed to filemanager a while ago
<ogra_> looks like it rolled back a few versions or so
<sil2100> I was branching cleanly and pushing an MR, so hm
<ogra_> well, something is weird here
<sil2100> psivaa: hey, you around? :)
<psivaa> sil2100: yep, just coming in and looking at the results :/
<sil2100> psivaa: so we're wondering, do you have any idea why ubuntu_filemanager_app is there as per ogra_'s comment ? ^
<sil2100> psivaa: and do you think it could be the screen unlock failing?
<sil2100> (I remember Saviq or someone mentioning it as a possible problem)
<psivaa> sil2100: looking, but the filemanager is really weird
<ogra_> yeah
<ogra_> could the device pull from the wrong branch ?
<ogra_> there is no mention at all of ubuntu_filemanager_app anywhere in the current code
<Saviq> sil2100, I doubt there's any issue with unlocking, we'd see a *really* red result if that was the case
<Saviq> oh yay, crashes
 * Saviq retraces
<Saviq> (process:10790): GLib-GIO-ERROR **: No GSettings schemas are installed on the system
<Saviq> huh?
<psivaa> ogra_: sil2100: filemanager was run as ubuntu_filemanager_app accidentally in one of the reruns as far as i see. i'm running it as filemanager now.
<ogra_> psivaa, ah, ok,, that helps with the confusion at least
<sil2100> Saviq: where's that from?
<sil2100> psivaa: ok, thanks
<Saviq> sil2100, unity8 logs
<Saviq> sil2100, https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/245/artifact/clientlogs/unity8/unity8.log/*view*/
<Saviq> sil2100, that's what unity8 crashes with, at least
<sil2100> hmm
<sil2100> Maybe one of the devices has some broken state with packages missing and it causes unity8 and python-autopilot crashes?
<ogra_> The following NEW packages will be installed:
<ogra_>   gir1.2-upstart-app-launch-2 libpython-stdlib libpython2.7-minimal
<ogra_>   libpython2.7-stdlib libupstart-app-launch2 python python-autopilot
<ogra_>   python-contextlib2 python-dbus python-dbus-dev python-decorator python-evdev
<sil2100> ogra_: in which test case is that? python2...
<ogra_> https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/245/consoleFull
<ogra_> looks like mediaplayer-app
<sil2100> On 66 only one test failure on mediaplayer-app, but still strange it's pulling in that
<Saviq> ogra_, sil2100 "mediaplayer_app unity8 dialer_app calendar_app sudoku_app ubuntu_filemanager_app ubuntu_weather_app online_accounts_ui" is the list of suites that were run in that job
 * ogra_ checks if thats the same device the two broken apps were run on 
<Saviq> doesn't include music_app
<ogra_> mako-11
<Saviq> ogra_, music was on mako-02
<Saviq> there goes that theory
<ogra_> calendar-app is mako-11
<Saviq> why oh why don't we get the .crash files preprocessed!!!
<ogra_> Saviq, and unity8 was mako-02 too
<Saviq> ogra_, huh https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/245/consoleFull ?
<ogra_> oops, sorry
<ogra_> 11 too
<sil2100> Ok, the theory also has a problem since mako-11 also ran tests which passed fine
<ogra_> before mediaplayer ?
<ogra_> or after it installed all that cruft (which was never removed)
<sil2100> Well, unity8 was ran first from what I saw
<sil2100> And it failed, right?
<ogra_> right, not saying that we are not seeing two bugs
<sil2100> Ah, no
<sil2100> Actually...
<ogra_> psivaa, is there a way to find the order in which which tests were run on which device
<ogra_> (so many witches in that sentence :P )
<sil2100> But yeah, so the first thing ran was mediaplayer_app, then unity8 and then the others... so still, weather should have failed right?
 * ogra_ gets coffee
<psivaa> ogra_: yep, let me take a look
<ogra_> sil2100, unless it gets along with the old AP tests still
<sil2100> ogra_: that's actually true
<sil2100> But, why didn't we see it sooner then?
<ogra_> because UAL only landed in 65 ?
<sil2100> Ah, right! The gir1.2-upstart-app-launch-2 that's now installed
<ogra_> the same apps fail in 65 and 66
<sil2100> Ok, this starts to make sense
<ogra_> (question is ... were they run in the same order there)
 * sil2100 is checking the deps
<psivaa> so with 66, mako-02 ran gallery_app, notes, messaging, music, calc, shorts, uitoolkit in the order and music terribly failed
<psivaa> and with 66 mako-11 ran mediaplayer, unity8, dialer,calendar, sudoku, ubuntu_file_manager, weather, online_accounts_ui in the order
<sil2100> psivaa: could you give me a link to the logs from the mako-2 run?
<psivaa> sil2100: https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/244/consoleText
<psivaa> brt for the meeting
<popey> can someone reproduce bug 1326694
<ubot5> bug 1326694 in unity-scope-click (Ubuntu) "Can't un-install clicks #65 mako - missing uninstall button" [Undecided,New] https://launchpad.net/bugs/1326694
<popey> also, landing call
<Mirv> did you discuss https://code.launchpad.net/~ted/ubuntu-app-launch/confine-click-apps/+merge/222114 yet? ready for publishing from ted
<sil2100> Yeah, trying to log...
<ogra_> popey, no memory leakage on my flo over night ...
<ogra_> (on #64 that was)
<jibel> psivaa, bug 1326707 add any info you may have from smoke tests.
<ubot5> bug 1326707 in ubiquity (Ubuntu) "Ubiquity does't start, hangs in "/usr/lib/ubiquity/bin/ubiquity", line 426, in acquire_lock, test_debconf.stdout.readline()" [Undecided,New] https://launchpad.net/bugs/1326707
<psivaa> jibel: ack, thanks
<sil2100> HAH!
<sil2100> ogra_, psivaa: I found something
<ogra_> tell us
<Chipaca> How's the train doing? Can I ask for silos &c?
<ogra_> you can ask for silos but it is not clear if they can land
<sil2100> ogra_, psivaa: actually, it's less relevant than I thought, sadly, but it seems that different AP versions are used for different tests
<ogra_> there are still lots of issues with the upstart-app-launch rename that killl the tests
<sil2100> ogra_: did you kick a new image?
<Chipaca> that's ok, landing is overrated :-p
<sil2100> Chipaca: give us some additional minutes and we'll get back to you :)
<ogra_> sil2100, yeah, the bot should pick it up any minute
<imgbot> === trainguard: IMAGE 67 building (started: 20140605 09:10) ===
<Chipaca> sil2100: I'll go preparing a row :)
<Chipaca> or maybe I won't? has the spreadsheet changed?
<Laney> I keep getting to the old one
<Laney> Chipaca: http://wiki.ubuntu.com/citrain should take you to the current spreadsheet
<Chipaca> Laney: thanks :)
<Chipaca> ok, row #34 ready for a silo whenever a silo is ready for row #34 :)
<Chipaca> wow! that's a lot of green :D
<sil2100> Chipaca: ok, tried to assign, but the MP is not a valid MP ;)
<sil2100> Chipaca: could you modify that?
<Chipaca> d'oh!
<Chipaca> sil2100: there. sorry.
<dbarth> sil2100: o/ hiya, i have line 27 ready if you have silos available
<sil2100> dbarth: hey!
<Saviq> sil2100, ogra_, are you any closer to knowing what happened? it looks like something that landed causes havoc in unity8 https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/1112/?
<Saviq> we get 100% crash rate in ap tests on device
<Saviq> oh noes, my ssh!
<sil2100> uh
<sil2100> We didn't know it's so serious
 * Saviq tries to retrace
<ogra_> http://paste.ubuntu.com/7593682/
<t1mp> Saviq: I don't know if it is related, but I also got 100% failure in autolanding with a simple change: https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/1106/?#showFailuresLink
<ogra_> -legacy UAL renaming
<t1mp> ^the MR is this https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1326072-create_fake_xauthority/+merge/221953
<Saviq> t1mp, sounds related indeed
<Saviq> t1mp, so we got broken Qt it seems
<Saviq> unless it's the gsettings thing again
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/65.changes
<ogra_> thats the changeset
<jibel> sil2100, where on the wiki do you document procedures of the CI team ? I want to document the escalation process for unstable tests we discussed during the sprint.
<ogra_> doesnt look like there was much Qt in it
<Saviq> (process:3579): GLib-GIO-ERROR **: No GSettings schemas are installed on the system
<ogra_> right
<Saviq> ogra_, yeah, I take that back
<Saviq> it's this fucker
<ogra_> ++
<sil2100> jibel: there is no documentation for that existing, the only procedures have been written in an annoucement e-mail on the phone ML
<Saviq> so gsettings-desktop-schemas?
<jibel> sil2100, ok
<ogra_> Saviq, yeah, i wonder where that came from
<sil2100> hmmm
<ogra_> ah, greeter
<brendand> sil2100, how did you plan to escalate AP failures to QA?
<ogra_> err
<ogra_> no, that was touch-schemas
<Saviq> ogra_, no we have that for long
<Saviq> https://launchpad.net/ubuntu/+source/gsettings-desktop-schemas/3.12.0-1ubuntu1
<ogra_> well, it got updated
<Saviq> looks like a debian sync?
<ogra_> hrmpf
<sil2100> brendand: as per the e-mail, we proceed as discussed during the sprint - we assess the test if it's reproducible manually and then either forward it to QA or to the developers in the bug
 * Saviq flashes 64 and upgrades one by one
<ogra_> seb128, do you know anything about https://launchpad.net/ubuntu/+source/gsettings-desktop-schemas/3.12.0-1ubuntu1 ? smells like we are missing somthing ...
<ogra_> (process:3579): GLib-GIO-ERROR **: No GSettings schemas are installed on the system
<ogra_> or Laney ^^
<sil2100> It doesn't seem to be anything landed throught the citrain:
<sil2100> http://people.canonical.com/~lzemczak/landing-team/65.commitlog
<Laney> erm
<Laney> how do you do that?
<seb128> ogra_, seems like the schemas compiler didn't run?
<brendand> sil2100, yes but how?
<brendand> sil2100, by email, bug tag?
<sil2100> brendand: it will be marked in the bug and in the landing e-mail, and generally inform QA people available so that it can be passed down further
<sil2100> brendand: if there are any propositions, I'm all ears
<ogra_> seb128, when should that run ? postinst ?
<Laney> it's a trigger
<seb128> ogra_, trigger
 * ogra_ checks the image build logs 
<seb128> ogra_, ls /usr/share/glib-2.0/schemas
<ogra_> seb128, hard to do, thats in the lab :)
<ogra_> Saviq, do you have the error locally ?
<seb128> do you have a gschemas.compiled
<Saviq> ogra_, just flashing
<cjwatson> Saviq: Merge rather than sync (our terminology is that syncs are verbatim copies)
<Laney> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/utopic/ubuntu-touch/latest/livecd-armhf.out
<Saviq> cjwatson, ok, that
<ogra_> hmm, i dont see any specific errors
<sil2100> ogra_: I looked throught the diff you made and I think I see a problem
<ogra_> sil2100, tell me
<sil2100> ogra_: +    def launch_ubuntu_application(self <- this shouldn't be renamed
<sil2100> ogra_: as per the merge for the python3 rename:
<sil2100> ogra_: https://code.launchpad.net/~ted/autopilot/ubuntu-app-launch/+merge/220909
<sil2100> ogra_: you can see that it was left as launch_upstart_application, just that the underlying bones got modified
<ogra_> i wonder if that was an oversight though ... i thought tedg wanted to remove all mentioning of upstart ... but yeah
<sil2100> ogra_: as you can see, he basically did a s/Upstart/Ubuntu , case-sensitive
<ogra_> sigh, but yeah, seems like it is a lot more than just a search/replace
<sil2100> Since any other methods that were generally lowercase didn't get changed
<ogra_> right
<ogra_> let me redo that then
 * sil2100 just sounded like a complete non-technical person
<sil2100> ;p
* psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<jibel> sil2100, brendand FTR https://wiki.ubuntu.com/CI/UnstableTests
<Saviq> what a week, btw...
<brendand> jibel, i'm dubious about the idea that a failure that isn't reproducible should be reassigned to infrastructure
<brendand> jibel, but ok for it to be owned by qa
<Saviq> ogra_, so no, of course the tests pass fine locally :|
<jibel> brendand, it's now on the wiki, open for discussion and improvements :)
<Saviq> ogra_, oh wait actually
<Saviq> ogra_, yeah, I get it on 66
<Saviq> nitctl: No such variable: XDG_DATA_DIRS
<Saviq> soudns related
<ogra_> not really ... unless you read from Pictures/Music/Video etc etc
<ogra_> XDG_RUNTIME_DIR would be worrying :)
<Saviq> hmm ok
<brendand> jibel, how do you comment on the wiki? i never knew you could do that
<ogra_> sil2100, http://paste.ubuntu.com/7593792/ a little shorter now :)
<ogra_> Saviq, any dbus errors ?
<Saviq> ogra_, not that I saw, no
<ogra_> k
<ogra_> thats good at least
 * Saviq flashes 94 and will upgrade one by one
<ogra_> well, try to resinstall the schemas package ... see if it spills an error from the trigger
<ogra_> Saviq, hmm, i dont see a unity8-greeter landing, i thought you and mterry had changed the wrapper script again in your silo
<Saviq> ogra_, http://people.canonical.com/~ogra/touch-image-stats/65.changes
<ogra_> yay for descriptive changelogs ... sigh
<ogra_>  * Bump version so ubuntu-touch-session can reference this one
<Saviq> ogra_, yeah, sorry about that...
<ogra_> thats the changelog entry ... i see the changes looking at the diff now
<Saviq> gawedasduibidfbdsgsgasdkaw ^W
<ogra_> +1
 * sil2100 checks the diff
<ogra_> psivaa, can you check if gsettings-desktop-schemas is installed on mako-11
<ogra_> (hoping it is still in the state it was when the tests were run)
<psivaa> ogra_: ack, 1 sec
<ogra_> and also as seb128 said  ls /usr/share/glib-2.0/schemas
<ogra_> see if they are there
<ogra_> the console log at least doesnt show a removal ...
<psivaa> ogra_: gsettings-desktop-schemas: Installed: 3.12.0-1ubuntu1
<ogra_> thanks
<ogra_> hmm
<psivaa> and there are a lot of xmls listed under /usr/share/glib-2.0/schemas/
<seb128> psivaa, what about a gschemas.compiled
<psivaa> seb128: that's there. let me paste the whole list
<Laney> where do you see this error?
<ogra_> Laney, smoke testing
<Laney> direct link?
<psivaa> ogra_: seb128: http://paste.ubuntu.com/7593881/
<ogra_> Laney, https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/245/artifact/clientlogs/unity8/unity8.log/*view*/
<Laney> psivaa: does gsettings list-recursively work?
<ogra_> (as phablet i suppose)
<sil2100> ogra_: ok, looks better I see... tedg doesn't rename FakeUpstartBase classess, but I guess those are used only internally with autopilot autopilot tests
<ogra_> k
<sil2100> So it seems ok
<ogra_> so upload ?
<sil2100> Give me another minute ;)
<ogra_> heh, k
 * ogra_ meanwhile fixes the changelog accordingly
<sil2100> uh
<psivaa> Laney: http://paste.ubuntu.com/7593883/ is the output but as root
<ogra_> psivaa, try as phablet too ... the tests run as the user
<sil2100> ogra_: another thing... I think we cannot rename UpstartApplicationLauncher to UbuntuApplicationLauncher ;p
<sil2100> ogra_: since I think it's imported from the UAL
<ogra_> oh, why ?
<sil2100> As per the merge tedg made ;p
<sil2100> It's probably defined as such and hm
<psivaa> ogra_: it works too when as phablet
<ogra_> right, just making sure
<sil2100> Since I didn't see it defined locally in autopilot, so I guess it's imported somehow?
<sil2100> Still digging
<Laney> this is very suspicious
<ogra_> sil2100, in testcases.py iirc
<seb128> Laney, what? the gsettings no schemas thing?
<Laney> yes
<seb128> yeah, doesn't make sense to me
<Laney> what if you re-run those tests now on the same machine?
<sil2100> Ah!
<sil2100> Sorry, missed that, but yeah.. we cannot rename that
<sil2100> ogra_: it seems to be exported, and python3-autopilot didn't get that renamed
<sil2100> (this would require changing all application tests)
<sil2100> ogra_: so indeed, it's much more complicated than just regexing :|
<ogra_> sil2100, but -legacy uses py2
<ogra_> doesnt it ?
 * Mirv gets into the -gles fork packaging fun
<sil2100> ogra_: yeah, but python2 and python3 versions of AP need to use the same function/class names
<sil2100> ogra_: so if it stays as UpstartApplicationLauncher in python3, it has to stay the same in python2
<sil2100> ...I think
<ogra_> i dont get that ... this package ships UbuntuApplicationLauncher
<sil2100> https://code.launchpad.net/~ted/autopilot/ubuntu-app-launch/+merge/220909
<sil2100> Look at this change and grep for UpstartApplicationLauncher
<sil2100> It's still there, it's not renamed, so the python3 one stays with the UpstartApplicationLauncher name, doesn't rename it to Ubuntu
<ogra_> hmm
<cjwatson> sil2100: or  try: import foo; except ImportError: import bar  presumably
<cjwatson> (more awkward but you certainly can)
<sil2100> cjwatson: what do you mean?
<cjwatson> I mean it's entirely possible to write bilingual Python 2/3 code where the same functionality is imported under different names
<imgbot> === trainguard: IMAGE 67 DONE (finished: 20140605 10:35) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/67.changes ===
<popey> \o/
<cjwatson> just replying to your train of thought above
<sil2100> cjwatson: right, but it's best to keep both python 2 and 3 versions in sync, exporting the same names for both versions
<cjwatson> yeah, all other things being equal
<cjwatson> certainly if both 2/3 versions were there before, no reason not to do both
<cjwatson> I've run across cases in porting where the python3 version had no users previously and so it was better to improve the API there even though it had to be kept the same in python2 for compatibility
 * ogra_ thinks we really should lave it to ted ... i feel a bit uneasy not knowing exactly why some bits were renamed and why others werent at all in the code 
<Saviq> ok I can easily repro the gsettings issue when upgrading... let's try again to pinpoint the package
<ogra_> hmm, the change of 67 doesnt have MIr
<ogra_> sigh
 * ogra_ guesses we should have checked -proposed :P
 * ogra_ does so now 
<sil2100> tedg: heeeey!
<sil2100> tedg: wake up!
<Saviq> unlikely ;)
<ogra_> unity-system-compositor, unity-mir, mir and platform-api are all sitting in -proposed ... damned
<Saviq> unless he's jetlagging :D
<cjwatson> mir/arm64 build failed, which should have shown up in citrain
<ogra_> yeah, i see it on excuses
<cjwatson> and it has a couple of rdeps now
<sil2100> Let me check the PPA
<sil2100> robru was the publisher so I don't know much about this landing
<ogra_> well, not that important then ... the Mir team can care for that ... we just wasted an image build :P
<cjwatson> I think the android-properties fix just needs a bit more fixing
<ogra_> it will stay in -proposed and we have other issues
<sil2100> HOW DID HE PUBLISH THIS?
 * cjwatson tries to remember if that was my fault
<sil2100> I mean, sorry for the caps, but how could it gotten published with failures in amd64?
<robru> hey guys, I'm up due to jetlag
<cjwatson> the failure that is, not the publishing
<cjwatson> sil2100: arm64, not amd64 :)
<robru> sil2100, it was arm64, not amd64
<cjwatson> I *think* it must have been forced
<sil2100> Right, typo, those are close
<sil2100> Anyway, it was a valid arch for mir
<sil2100> robru: did you get some archive admin ACKing on releasing without this arch?
<robru> sil2100, cjwatson: so, this one was quite strange. I saw the build had failed in the silo, but the citrain build job was acting really funny. it was claiming that the build was ongoing, it couldn't see that the build had failed. so I tried rebuilding a couple times, no luck. camako had indicated that the silo was highly tested, and I tested it myself, it looked good on device so I was hoping that publishing it would "unstick" the
<robru> failing arm64 build somehow
<cjwatson> Afraid not
<cjwatson> I'm working on fixing it now
<robru> sil2100, no, no ACK for releasing without that arch, I was hoping that arch would rebuild in -proposed, as I've seen that happen when publishing in the past.
<sil2100> robru: ah... right, whenever a build job is stuck it might mean that there's a dep-wait somewhere
<sil2100> And the build is failing
<cjwatson> Right, the build failure's definitely real; looks like a two-liner to fix but I'll test-build it
<cjwatson> well, marginally more than two, http://paste.ubuntu.com/7593994/
<robru> sil2100, look at the PPA though, there's lots of depwaits on the Often Ignored arches, citrain didn't block on those. it just blocked only on the single arm64 "ongoing build". quite a strange build log if you review it
<cjwatson> in case of doubt the best way to check is to run "rmadison -s utopic -S <source package name>" and check what architectures it's built for there; those are the architectures that proposed-migration is going to require
<sil2100> robru: yeah, but that's happening every time and it's not normal - whenever a build is stuck on building something it means one of the arches that are required didn't build
<sil2100> cjwatson: right, useful command
<robru> cjwatson, thanks
<cjwatson> reductions are sometimes possible but require manual removal of the no-longer-supportable binaries and I'd usually only do that if the reverse-dependency chain is tiny/absent
<sil2100> cjwatson: I usually did the long way, like... LP
<cjwatson> i.e. minimum fallout
<robru> sil2100, yeah, I know it didn't build, but I didn't understand why. I was hoping it would just rebuild itself in -proposed
<sil2100> robru: it's usually much better to poke upstreams in this case
<infinity> robru: If it won't build in the PPA, it won't magically work in -proposed.
<cjwatson> ... usually
<infinity> robru: So, copying out in that case is definitely not the answer.
<sil2100> robru: right, as our PPAs have -proposed enabled and the same builders
<cjwatson> There are weird edge cases sometimes :)
<infinity> cjwatson: Well, unless timing means some rdep is fixed between A and B. :P
<sil2100> So it's like -proposed, just safer ;p
<robru> infinity, cjwatson: yes, I saw weird edge cases some months ago that made me think this
<cjwatson> Anyway, should be easy to sort out as soon as am1 finishes branching this.
<sil2100> cjwatson: thanks!
<popey> sil2100: ogra_ seems 67 doesn't have new unity/mir?
<sil2100> popey: no ;)
<cjwatson> popey: See the conversation immediately above.
<popey> \o/
<popey> oh, â»
<popey> Summarise it for me in one word.
<sil2100> popey: as discussed ^ heh, we had a premature ejacu...image build
<Saviq> ogra_, confirmed, it's url-dispatcher that causes the gsettings dying
<sil2100> No one of us actually checked if it moved out of -proposed ;p (bummer)
<robru> popey, "no"
<robru> ;-)
<popey> expected â»
<sil2100> Saviq: oh?
<ogra_> Saviq, lovely
<sil2100> Saviq: ok, I probably missed out some of the discussion, but how is that so?
<sil2100> Was that the url-dispatcher landing from tedg yesterday?
<sil2100> I'm saying we revert that
<Saviq> my apt history.log: http://pastebin.ubuntu.com/7594050/
<Saviq> no idea where the --reinstalls come from ;)
<Saviq> looks like from rootfs
<Saviq> but I upgraded gsettings-desktop-schemas and url-dispatcher + ubuntu-app-launch
<Saviq> and that's it, gsettings dead
<Saviq> well, the weird thing it's actually only happening under autopilot... the phone booted fine...
<sil2100> Saviq: so, those two in combination cause it, or simply the upgrade of url-dispatcher is enough?
<ogra_> Saviq, did you try *only* updating gsettings-desktop-schemas
<Saviq> sil2100, can't upgrade url-dispatcher alone, it deps on the ohter
<ogra_> ?
<Saviq> ogra_, yes
<ogra_> and thats behaving fine ?
<Saviq> yup
<ogra_> ok, yeah, then i agree
<Saviq> see the start-date difference? that was me rebooting and testing
<ogra_> ah, right
<Saviq> let me flash again and upgrade the minimal amount of pkgs (like only ubuntu-app-launch)
 * sil2100 needs to jump out to the shop
<cjwatson> sil2100,robru: https://code.launchpad.net/~cjwatson/mir/fix-android-properties-check/+merge/222163 (still building here and I have to go out shortly, but it's certainly getting a heck of a lot further).  Will presumably need review from somebody like kdub
<robru> cjwatson, want me to silo that?
<ogra_> cjwatson, we're not in a hurry with that one
<cjwatson> robru: Happy to wait for a mir reviewer - e.g. with their processes I'm not sure if it needs to be merged into lp:mir/devel before going into a silo
<ogra_> fixing sll the UAL rename fallout has priority anyway
<cjwatson> ogra_: Yup, just whack-a-moling tech debt
<ogra_> it is actually good that mir is stuck there so we dont taint fixing work
<robru> cjwatson, fair enough, thanks for the branch
<sil2100> ogra_: I'll try to do the autopilot rename in the meantime
<ogra_> brave
<sil2100> That's my third name
<ogra_> haha
<ogra_> whats your second ?
<sil2100> It's a secret -_^
<Chipaca> ogra_: do you know where bugs (a kernel crash) in ubuntu-emulator should be reported?
<Saviq> sil2100, ogra_, confirmed http://pastebin.ubuntu.com/7594147/
<Saviq> sil2100, ogra_, that's enough to get gsettings in a bad state
<ogra_> why does it remove upstart-app-launch ?
<ogra_> (why does it have to ... why is it installed)
<Saviq> ogra_, probably unity8-autopilot before that
<ogra_> i dont see it in the list there
<Saviq> hmm indeed
<Saviq> ogra_, I started from image 64, btw
<ogra_> oh, ok
<ogra_> that would explsin it
<ogra_> *explain
<Saviq> ogra_, thought so
<Saviq> that was my whole idea, 64 (working) and work from there
<sil2100> I think I've got something here
<sil2100> With the autopilot thingy
<Saviq> *no* idea how that affects it, since none of those packages actually touch gsettings or schemas...
<Saviq> so it must be some interaction... but dunno how to test without installing unity8-autopilot... that's what /me is interested in :P
<ogra_> Saviq, well, there is a dependency chain in unity8-autopilot ...
<sil2100> ogra_: http://paste.ubuntu.com/7594185/
<Saviq> ogra_, yeah, but installing *just* that is fine
<sil2100> ogra_: this should do it
<ogra_> unity8-autopilot -> ubuntu-ui-toolkit-autopilot -> python-autopilot -> gir1.2-upstart-app-launch-2
<Saviq> ogra_, I mean after installing that I can run unity8's ap tests fine
<Saviq> ogra_, only after upgrading UAL does it break
<ogra_> Saviq, lets see what happens after we landed sil2100's fix above
<Saviq> k
<ogra_> that gir1.2-upstart-app-launch-2 causes havoc
<sil2100> ogra_, Saviq: I don't guarantee it will work, but I worked with tedg's merge + common sense and grep magic, should be safe
<ogra_> sil2100, well, more broken than broken cant happen anyway :P
<ogra_> lets upload this and let tedg deal with the fallout
<ogra_> (merging back fixing subsequent issues) ....
<ogra_> so we dont lose more time
<ogra_> the debdiff looks ok to me but i must admit i dont know much about that code ... comparing it to the non -legacy merge it looks good though
<sil2100> ;D
<sil2100> ogra_: is this enough or you want the src package as well?
<sil2100> If we're cool then I jump out to that store for a moment, we're missing lunch essentials
<ogra_> thats enough i have the source pkg here i can apply the patch
<sil2100> ogra_: thanks :)
<ogra_> uploaded
 * ogra_ finally finds the time to upgrade his flo to 67
<ogra_> ricmm, doesnt looks good for papi v2 ...
<ogra_> *look
<kgunn> sil2100: choo-choo told me mir0.2.0 was migrating, but looks like its waiting on u-s-c in migration pocket...can you check if its stuck ?? PES guys are wanting it to land
<ogra_> the UAL rename causes more and more afllout :(
<ogra_> kgunn, it failed to build on arm64 ... there was a lot of discussion in the scrollback
<ogra_> (about 1h ago)
<ogra_> WOAH !
<ogra_> we have outlook in the store !!
<ogra_> lol
<popey> ogra_: â»
<robru> kgunn, cjwatson kindly put together a fix for mir on arm64, if you can review it and incorporate it into the silo, then that can progress: https://code.launchpad.net/~cjwatson/mir/fix-android-properties-check/+merge/222163
<ogra_> popey, the click installled fine here btw
<ogra_> on 67
<ogra_> (this was an OTA though, not a fresh install)
<mardy> fginther: hi! Any progress on adding the online-accounts stuff to http://162.213.34.64:8080/gaps/project/ ?
* psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<popey> ogra_: can you uninstall?
<ogra_> popey, aha, no, i cant
<ogra_> damned ... i'm doomed to have outlook installed forever now !
<ogra_> :)
<popey> bug 1326694
<ubot5> bug 1326694 in unity-scope-click (Ubuntu) "Can't un-install clicks #65 mako - missing uninstall button" [Undecided,New] https://launchpad.net/bugs/1326694
 * ogra_ confirms
<ogra_> popey, i cant confirm your ram issue on flo though
<ogra_> it didnt pile up any additional ram over night
 * sil2100 is preparing lunch
<ogra_> hmm
<sil2100> I see autopilot in -proposed :)
<ogra_> looks like copy pasting from paste.u.c messed up UTF-8 completely
 * tedg scans backlog, decides that dream was better
<ogra_> sorry for mangling your name
<sil2100> Saviq: thostr_1: ^ bug 1326694
<ubot5> bug 1326694 in unity-scope-click (Ubuntu) "Can't un-install clicks #65 mako - missing uninstall button" [Undecided,Confirmed] https://launchpad.net/bugs/1326694
<ogra_> tedg, looks like you forgot to port autopilot-legacy
<tedg> sil2100, Can you give me an update of what's current?
<sil2100> tedg: yeah, so it seems you updated the py3 autopilot, but py2 was left unchanged ;)
<thostr_1> sil2100: will take care of it
<tedg> Oh, I didn't realize there were two.
<ogra_> there seems to be another issue with gstettings schemas with the new url-dispatcher
<sil2100> tedg: so, I tried to do the same changes and we released it to the archive
<tedg> sil2100, Great, thanks!
<ogra_> which we dont know yet if it is related to -legacy or not
<sil2100> tedg: yeah... right now the py2 bindings are part of the autopilot-legacy source ;)
<sil2100> tedg: could you take a look at the debdiff and check if I did it good ;p?
<tedg> Sure
<sil2100> I tried using your merge for py3 in this process
<popey> ogra_: ok
<sil2100> tedg: http://paste.ubuntu.com/7594185/
<tedg> Heh, stole it from LP :-)
<sil2100> ;)
<tedg> Just to be curious, I thought all the tests were py3 already? no?
<ogra_> tedg, i think that legacy part iis sorted now ... would be good if you could help Saviq to look into why gsettings break with the new url-dispatcher
<ogra_> (which in turn breaks half of the unity8 tests)
<tedg> Hmm, okay. Saviq what are you looking into?
<ogra_> tedg, it *might* be related to -legacy pulling in upstart-app-launch stuff it shouldnt ... but we are not sure
<tedg> The change there was tiny, I'd be surprised it was the root cause.
<tedg> In URL dispatcher
<ogra_> Saviq, could pretty well nail it down to installing that package and the world fell apart
<ogra_> but that indeed doesnt necessarily mean it is url-dispatcher itself
<Saviq> tedg, yeah, I took image 64, installed unity8-autopilot, stuff's fine
<ogra_> the gsettings schmas got merged newly from debian for example
<Saviq> tedg, then, installed ubuntu-app-launch, and boom, gsettings in autopilot die :|
<tedg> Is there an error printed anywhere?
<tedg> So are we talking UAL name change? or URL Dispatcher?
<ogra_> https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/245/artifact/clientlogs/unity8/unity8.log/*view*/
<ogra_> (process:10716): GLib-GIO-ERROR **: No GSettings schemas are installed on the system
<ogra_> thats the error
<tedg> I'm getting that with the clock app on my flash from last night.
<tedg> Should be able to backtrace that
<ogra_> and i guess we are talking u-a-l since unity8 already failed before the last url-dispatcher upload
<fginther> mardy, I'll follow up with alesage, there was an MP to get most of this done, but it got stuck in review. We'll unwedge it.
<tedg> ogra_, Those errors are all coming from different processes, is that because we're restarting unity8?
<ogra_> yeah, i think we do
<tedg> Wonder if there's an env var we're getting wrong.
<tedg> I guess also, have there been any SDK changes?
<ogra_> well, did you change any env vars with the UAL change ?
<tedg> Not on purpose.
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/65.changes is where it started
<brendand> ogra_, are you guys looking at the music app not starting?
<ogra_> (teh sdk-libs in there is just an unrelated metapackage rebuid)
<ogra_> brendand, nope
<tedg> brendand, I think that's fixed in silo2
<ogra_> brendand, does it not start ?
<tedg> brendand, If you'd like to double check that silo, that'd be awesome.
<brendand> tedg, doing
<mardy> fginther: thanks! :-)
<ricmm> robru: hi
<ricmm> robru: I see platform-api 2.0.0 in -proposed
<robru> ricmm, hey
<ricmm> robru: what is it doing there? silo 007 hasnt been published
<ogra_> sil2100, seems that Mir landing was quite a bit prematures
<ricmm> do you know what silo that came from?
<ogra_> -s
<sil2100> robru: SLEEP!
<robru> sil2100, can't
<robru> ricmm, it came from silo 8
<sil2100> ricmm: there was some Mir landing last night, robru knows more
<ogra_> sil2100, platform-api 2.0 should not be used before ricmm's silo landed ... seems the Mir landing pulled from trunk or so ... given the package version number
<robru> ricmm, don't worry, it's blocked in proposed, it's not about to land, it's blocked by mir build failure on arm64, cjwatson has a fix, kgunn is reviewing
<robru> ogra_, oh, awesome
<sil2100> geh, yesterday I didn't even see the Mir landing
<ricmm> I dont get it
<ricmm> I dont see 2.0.0 in the chanelog of silo 8's MRs
<ricmm> ogra_: got a link to the source upload?
<ricmm> I want to see the diff
<ogra_> https://launchpad.net/ubuntu/utopic/+source/platform-api/2.0.0+14.10.20140603.3-0ubuntu1
<robru> ricmm, good point
<ogra_> https://launchpad.net/ubuntu/+source/platform-api/2.0.0+14.10.20140603.3-0ubuntu1
<ogra_> there are the diffs ...
<sil2100> I actually thought we'll just land ricmm's platform-api v2 today in the morning
<ogra_> looks like only packaging changes
<ogra_> but why is it called 2.0.0 then ?
<robru> that is really curious
<ogra_> the upstream tarball is 2.0 too
<brendand> tedg, looks good to me
<tedg> brendand, Great, thanks for testing it.
<ricmm> ogra_: looks like jenkins decided to update version to 2.0.0
<ricmm> but thats the only change, the rest I dont care
<ricmm> but seriously, I want to ask something
<camako> robru, I incorporated cjwatson's fix, do we need to start a rebuild?
<ogra_> phew
<ricmm> why are we even landing stuff like Mir when everything is broken?
<ogra_> ricmm, it wasnt
<robru> ricmm, because I thought everything got fixed? we're not in TRAINCON-0
<ricmm> but its clearly not fixed
<robru> camako, yes, did you merge cjwatson's diff into an existing MP? or just add the MP to the silo?
<camako> robru, the former
<robru> camako, cool, then a rebuild will handle ti
<ogra_> ricmm, http://ci.ubuntu.com/smokeng/utopic/touch/mako/64:20140604:20140530/8385/ ... it landed after we got these test results
<sil2100> ricmm: TRAINCON-0 was dropped, we had good test results and good image state when that was announced, but then some other migrations happened and caused todays problems
<tedg> robru, sil2100, can we publish silo 2, I'm not sure it fixes the Unity8 issue, but it should fix a couple of the apps tests.
<tedg> Be nice to get in the next image
<ogra_> ricmm, the prob is that it landed together with UAL changes too ... which shouldnt have happened
<robru> tedg, it's up to sil2100 now, i'm not supposed to be awake currently
<sil2100> tedg: ok, so... it's also a potential fix for the things we're encountering?
<ogra_> ricmm, and the UAL changes broke the world again ... (fix pending in proposed)
<ogra_> sil2100, seems like the music app should be better at least
<ogra_> if i understand the discussion right
<tedg> sil2100, It doesn't fix any gsettings stuff (not sure on that one yet) but it does get click apps running as click apps, which gives them a consistent environment.
<sil2100> Ok, then let's risk it
<ogra_> ++
<robru> camako, ugh, I see your build failure, hang on
* josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<ricmm> I'm still not sure why 2.0.0 got picked by jenkis as the right version to play
<ricmm> is it possible there is a bug in the CI train scripts?
<robru> ricmm, yeah that's a mystery to me
<ricmm> platform-api 2.0.0 was in silo 008 before
<ricmm> then it was flushed and move to 7
<ricmm> perhaps jenkins is seeing the PPA history
<robru> ricmm, oh yeah, that's exactly it.
<ricmm> and actually doing last+1 even if it was deleted?
<sil2100> ricmm: I checked lp:platform-api/devel and I don't see 2.0.0 there, so it's hm
<robru> ricmm, didn't know about that history
<ricmm> thats pretty awful
<sil2100> Let me check the code
<robru> ricmm, technically this is a bug in launchpad, not citrain
<robru> cjwatson, we hit this once before I think, just remembering now ^^
<ricmm> I rather put my money on ci train bug, I'm sure you can filter results on !deleted
<sil2100> But we remove all packages from the PPA, not leaving any trace
<robru> sil2100, not true, there's a trace ;-)
<ricmm> sil2100: package history always remain, the real issue is when pulling the last known version
<ricmm> to construct the changelog
<ricmm> theres probably a missing check for ==deleted :)
<ricmm> which just caused me to change every single one of my (14?) branches to update the build deps
<robru> ricmm, sorry to hear that
<robru> sil2100, https://launchpad.net/~ci-train-ppa-service/+archive/landing-008/+builds?build_text=&build_state=all here's the build history, clearly shows deleted packages
<sil2100> Then it's a serious issue, it shouldn't be like that, deleted packages shouldn't be considered in such a thing by default
<sil2100> Looking at citrain now
<robru> sil2100, I have vague memories of raising this with didier some months ago, hit some snag where I'd accidentally bumped a version I didn't want to, then tried to delete the package and lower the version, couldn't do it, jenkins kept finding the higher version number, so I had to just roll with the higher version.
<robru> camako, https://ci-train.ubuntu.com/job/landing-008-1-build/98/console ok this looks like it's on it's way now, will require re-testing of course.
<sil2100> Yeah...
<sil2100> ricmm, robru: so, I see Didier was simply fetching the list of sources, while LP API has a property declaring the state of the package
<camako> robru, thanks... sure will retest
<robru> camako, you're welcome
<sil2100> ricmm, robru: so I'll try fixing that for the future, but we'll have to do something with the Mir landing in the PPA
<ricmm> well its already in proposed
<ricmm> either you delete that and make it see its 1.2.0 again, or I dont know
<ricmm> one way is to flush it to a silo other than 008/007
<sil2100> ricmm: we can drop it if it's very bad
<ricmm> I dont know how bad it might be, it just needs a round of checking my silo 007 branches for build-dep discrepancies
<ricmm> as I dont want things linking to the incorrect platform-api
<sil2100> Mir is blocked in -proposed anyway, so I guess we could drop papi and push a new one
<ricmm> because now ther will be a papi 2.0 that actually ships 1.2 sonames
<sil2100> Right...
<ricmm> so, that in itself is broken, even if it doesnt cause world breakage
<ricmm> if dropping platform-api from proposed and manually uploading 1.2.0 from their branch is doable, I'd say do that
<sil2100> Let's see what we can do
<robru> ricmm, not sure if that's possible... I think the genie might be out of the bottle on this one, version '2.0.0' is just ruined.
<robru> would need an archive admin to give a definitive answer on the feasability of that
<ricmm> name one
<ricmm> I dont know them
<ricmm> maybe we can ask right away :)
<robru> ricmm, well cjwatson or infinity
<ricmm> cjwatson: what do you think colin?
<sil2100> robru: no worries
<sil2100> I'm sure we can find a way
<sil2100> I hope
<sil2100> cjwatson: if you're around, if we drop a platform-api 2.0.0 from -proposed, will we still be able to upload a version lower than that?
<cjwatson> robru: sorry, on a call, can I have a one-line summary?  (is your question the same as sil2100's?)
<robru> cjwatson, yes
<cjwatson> robru,sil2100: if you do that, you can never reuse the identical version, but you can go backwards
<sil2100> \o/ ok, so there's still hope
<sil2100> cjwatson: thanks!
<sil2100> ricmm: ^
<cjwatson> it's *possible* that it only works via copies rather than direct uploads, I don't quite remember
<cjwatson> try it, worst case use a different silo, and it can be handled in -proposed
<cjwatson> robru: regarding the citrain part, I'm pretty sure I fixed it to skip deleted packages immediately after that incident
<ricmm> cjwatson: after this incident? or a previous one
<cjwatson> previous
<ricmm> it totally went through this time
<jhodapp> sil2100, can you publish line 31 for me, silo 18?
<cjwatson> "that" incident
<ricmm> darn
<cjwatson> means not this one
<ricmm> well it could mean "that" one up there ;)
<robru> ricmm, yeah, "that one up there", that I referenced happening some months ago :-P
<ricmm> well even worse then, if it has already happened
<ricmm> sil2100: do you have a plan then?
<robru> yeah, not sure how this happened again
<sil2100> ricmm: so, let's play it safe and do this:
 * ogra_ goes for a walk to calm down again 
<sil2100> ricmm: let's ask cjwatson to drop papi from -proposed, then I'll assign the preprod silo 000 for the platform-api merge from that Mir landing
<sil2100> ricmm: we'll build it there, it should be correct version
<ricmm> sil2100: alright, I trust you to do the right thing
<sil2100> ricmm: then we publish that silo (it will make a copy, so we *should* be safe)
<ricmm> lemme know how it goes, if all fails I'll fix it in my branches
<ricmm> 1-2 days *after* UAL is fixed/Mir lands/ etc
<ricmm> win 18
<sil2100> cjwatson: once you're after meetings, can you drop the platform-api 2.0.0+14.10.20140603.3-0ubuntu1 from -proposed? :)
<sil2100> Damn, I'll have to copy all the mir packages to the preprod silo as well...
<sil2100> Oh, wait, no
<sil2100> I don't have to, phew
<jhodapp> or robru, it's a simple fix for QMediaPlaylist support that helps fix the dialer that Bill's team really needs
<sil2100> Since all prereqs are in -propsoed now
<robru> jhodapp, oh sorry
<robru> sil2100, but dont' forget that mir is rebuilding, the one in -proposed is broken
<jhodapp> robru, np
<sil2100> Crap...
<robru> jhodapp, silo 18 isn't marked as testing: pass
<robru> sil2100, so you'll need to republish silo 8 again. might be easier to just turf that whole silo and then reassign it in a different one
<sil2100> robru: right, if a rebuild is needed then it's even easier now
<robru> sil2100, well, it's already rebuilding.
<cjwatson> sil2100: could you give me a reason string that I can copy and paste? :)
<jhodapp> robru, it needs to be marked as testing or something else?
<sil2100> cjwatson: let me think ;) "Removing platform-api 2.0.0 as the version number is incorrect: the package in reality is still 1.2.0, but has been bumped by CI Train to 2.0.0 due to an error. Reupload with correct version number needed."
<sil2100> cjwatson: would that be ok?
<cjwatson> OK, the previous fix I got applied to citrain was actually for something slightly different
<robru> jhodapp, you know the spreadsheet right? if you tested the silo, please mark 'yes' in the "testing pass?" field on the silo page
<sil2100> kgunn: hi!
<jhodapp> robru, oh right, I always forget about that sub-tab
<robru> jhodapp, yeah, heh
<cjwatson> The problem then was that even after deleting a package you couldn't go back; so I made it take the most recently created upload, not just the one with the highest version
<sil2100> kgunn: are you handling the rebuild of the mir landing right now?
<robru> sil2100, also inform camako about this since he's working on this  mir landing quite closely.
<cjwatson> But it didn't occur to me that people might delete and then not upload a new thing
<sil2100> cjwatson: ah, ok ;) THanks
<cjwatson> robru,ricmm: ^-
<ricmm> sil2100: I think its a bit early for kgunn
<sil2100> camako: hi!
<robru> cjwatson, ahhhh that makes more sense
<sil2100> camako: so... I would need to stop the Mir rebuild that's happening and re-do it from scratch
<ricmm> cjwatson: right, so in this case silo 007 was busted (the vm, or whatever was misbehaving)
<ricmm> cjwatson: so the landing was migrated to 008
<jhodapp> robru, ok ready
<ricmm> so that stale deleted 2.0.0 was left in the PPA itself
<sil2100> camako: we actually need to assign a different silo for it... is that ok? We can do the build there
<ricmm> cjwatson: so do you think we can actually drop safely from -proposed and re-push platform-api with 1.2.0 ?
<cjwatson> ricmm: mm, so probably an artifact of the general way that silos are an awful hack then
<cjwatson> ricmm: yes
<cjwatson> ricmm: it's *possible* that you won't be able to use the same silo to prepare it
<ricmm> cjwatson: yup, sparks off of the larger silohack
<sil2100> ricmm: yes, cjwatson said it's possible - but we must make sure we won't reuse the invalid name again in the future
<ricmm> ok
<cjwatson> sil2100: yeah, you won't anyway due to the embedded date
<ricmm> I think thats why lukasz is offering to use 000 for the platform-api Mir landing
<ricmm> instead of the busted silo
<sil2100> Right, true
<cjwatson> right, you could copy source+binaries over from the existing one if that's useful
<sil2100> camako: are you around?
<robru> sil2100, he was earlier, not sure
<cjwatson> but I know that this works as far as the primary archive is concerned because <small>we might have had to do it before because I screwed up</small>
<robru> cjwatson, what was that? I can't read it
<cjwatson> good :)
<robru> ;-)
<sil2100> camako, kgunn: anyway, I stop the build of silo 008
<sil2100> ;)
<tedg> Saviq, I'm confused with this GSettings thing, does gsettings only get used with autopilot?
<cjwatson> so I've queued that removal, it'll happen with the next publisher run
<robru> sil2100, ok so hey, amongst all this crazy papi stuff, do you think it's ok if I publish this tiny bugfix from jhodapp? I'm afraid to publish anything right now, seems the last 2 or 3 times I hit publish something unexpected goes wrong...
<cjwatson> https://launchpad.net/ubuntu/+source/platform-api/+publishinghistory
<robru> cjwatson, thanks
<sil2100> cjwatson: thank you :)
<cjwatson> yeah, thinking about it, the wind-versions-backwards hack of course only works with copies
<sil2100> I'll assign 19 for that since I see it's clean
<sil2100> So we'll use a silo for this
<Saviq> tedg, no, that's the thing...
<Saviq> tedg, but *something* causes the environment to get screwed up probably
<cjwatson> oh, except getSourceAncestry only looks for PUBLISHED/PENDING - oh I'm so confused, anyway this approach will work
<Saviq> tedg, like I can see XDG_DATA_DIRS: no such variable in the console
<tedg> Saviq, So you think that someone messes up the global environment, and then when unity8 gets restarted it doesn't have the variable.
<tedg> ?
<cjwatson> I think indeed citrain should be filtering to only Published/Pending publications in most places it calls getPublishedSources, although it has to be careful since unfortunately it isn't possible to pass a list of acceptable statuses, you have to filter the result
<sil2100> robru: anyway, let's wait a moment with landing stuff
<sil2100> cjwatson: right, I'll do the modification, since now getPublishedSources is used directly, without any filtering
<robru> sil2100, figured, that's why I asked ;-)
<robru> sil2100, so seeing as kgunn and camako aren't around, we should probably just kick the new build for them, so it's ready to test when they get back. should I do it or are you on it?
<kgunn> robru: i'm around
<robru> oh cool
<sil2100> robru: I'm on it
<kgunn> what do you need ?
<robru> also cool
<sil2100> I was waiting for the spreadsheet to update
<sil2100> kgunn: we're cool for now, just know that we flush silo 008 in a moment ;)
<kgunn> i know there's some mess up with papi2.0 but hadn't quite been abckle to figure from scroll ba
<robru> kgunn, well we moved your landing into silo 19, so you can kick a build, but don't worry, sil is doing it
 * ogra_ notes AP-legacy is done with autopkg testing 
<kgunn> sil2100: ack
<sil2100> Your silo is in 18 now
<sil2100> 19
<cjwatson> sil2100: there are a few places which pass status="Published", which are probably fine - presumably they're intending to exclude pending publications
<sil2100> ogra_: \o/
<ogra_> 20?
<kgunn> ok
<kgunn> 21
<robru> sil2100, if you use my backend page, you can kick the build before the spreadsheet updates (no pointless waiting)
<ogra_> :)
<kgunn> sil2100: do i need to do a full build? or watch build ?
<sil2100> kgunn: I did a full build
<kgunn> ack...
<sil2100> kgunn: ok, quick update:
<kgunn> sil2100: bottom line, do we need to retest ?
<sil2100> kgunn: so... the mir landing published yesterday was broken, as it was FTBFS for arm64
<robru> kgunn, yeah, it will require a retest (needs to retext cjwatson's fix anyway)
<sil2100> kgunn: so it got stuck in -proposed
<cjwatson> I can confirm my fix actually builds on arm64
<kgunn> camako: ^ supposing you already knew
<robru> cjwatson, excellent
<cjwatson> shouldn't expect it would take much testing, just smoke I guess
<kgunn> ack
<sil2100> kgunn: it was already rebuilding with a fix, but then ricmm noticed that due to a bug in citrain the platform-api built in your PPA and released fetched the 2.0.0 version number
<kgunn> we beat the hell out of it
<sil2100> kgunn: while it's not correct
<kgunn> we'll focus on n4
<cjwatson> since build system only
<sil2100> Right
<kgunn> yeah...we're still confident
<robru> sil2100, build in 19 failed due to versions in -proposed already, had to FORCE_BUILD it
<sil2100> robru: no need for the two of us doing the same thing, just wanted to press the button when I saw you doing it ;)
<sil2100> We're stepping on our toes!
<robru> sil2100, ah sorry, noticed it a while ago and thought you hadn't noticed ;-)
<robru> sil2100, can I flush 8 and merge 2? ;-)
<sil2100> 2 is merging, you can flush 8 ;)
<robru> ok
 * sil2100 is still waiting for autopilot-legacy
<sil2100> ogra_: it seems to be migrated!
<sil2100> ogra_: python-autopilot | 1.4.1+14.10.20140430-0ubuntu4   | utopic/universe  | all
<sil2100> ogra_: should we kick a new image, or are we waiting for some other fix?
<sil2100> robru: why you can't sleep? ;)
<robru> sil2100, massive jetlag. I passed out at around 9PM last night... woke up at 3AM... dunno
<tedg> ogra_, I'm not seeing XDG_DATA_DIRS in my upstart global environment, is that not set as part of session init?
 * tedg reboots to be sure
<alesage> fginther, hiya
<fginther> alesage, can we work on getting https://code.launchpad.net/~allanlesage/cupstream2distro-config/enable-webcred-coverage/+merge/219606 merged today? There were just a few comments
<alesage> fginther, yep I'm there, will refresh
<tedg> sil2100, I think we might have a fix for the unity8 stuff. If you haven't done a build, let's wait.
<sil2100> tedg: ogra_ is not around anyway, so yeah - just give us a ping :)
<tedg> sil2100, Saviq is preparing a patch.
<tedg> It seems to be related to XDG_DATA_DIRS not being set for the session.
<ogra_> sil2100, that means another 3h or so ?
<sil2100> ogra_: oh, you're back!
<ogra_> yep
<sil2100> In this case we can build an image now, otherwise we won't get any test results indeed... since unity8 builds and migrates long
<ogra_> /etc/X11/Xsession.d/60x11-common_xdg_path
<ogra_> thats what sets XDG_DATA_DIRS
<ogra_> sil2100, right
 * ogra_ triggers one 
<sil2100> tedg: so let's target the next image for your fix, thanks for working on it!
<ogra_> triggered  ...
<ogra_> sil2100, fyi there are ned langpacks building (soon or already) they will show up in the diff
<tedg> ogra_, it's not showing up in initctl list-env --global
<tedg> Not sure why that is
<ogra_> tedg, hmm, confirmed ...
<ogra_> tedg, does /usr/share/upstart/sessions/xdg-dirs.conf exist ?
<ogra_> seems thats not run then
<Saviq> ogra_, truth be told that's what mterry (Xsessions.d parsing) disabled, right?
<ogra_> Saviq, no
<Saviq> hmm
<ogra_> Saviq, only lanuching of dbus from there
<ogra_> (at least he should)
<mterry> ogra_, no, we don't run that dir anymore I don't believe
<tedg> ogra_, Yes it does exist.
<Saviq> ogra_, nooo
<Saviq> ogra_, https://code.launchpad.net/~mterry/unity8/dbus-x11/+merge/221894
<Saviq> but really, my testing would need to have been so broken
<mterry> Saviq, that wasn't the one
<mterry> ogra_, https://code.launchpad.net/~mterry/ubuntu-touch-session/no-lightdm-session/+merge/221891
<ogra_> Saviq, right, that shoulld only disable launching dbus from Xsession ... we still rely on lightdm to process the other scripts from there
<Saviq> ah right sorry
<ogra_> and we likely still need some of them
<Saviq> aand we're back on that train
<mterry> We do?
<Saviq> mterry, sounds like xdg dirs would be one that we do
<ogra_> mterry, not sure ... but i would guess we havent gotten rid of everything from there yet
<Saviq> mterry, and yeah, there's more there that sound useful
<ogra_> i dont see anything beyond the xdg stuff in my install though
<mterry> I thought we set XDG_*_DIRS from an unusually verbose /etc/environment but I see it's missing there, yeah
<ogra_> ssh gaent is surely not used atm
<mterry> Yeah, I just looked too, and xdg dirs and ssh agent are only two that aren't X-specific or session-setup specific but upstart does that for us
<ogra_> right
<Saviq> mterry, at least XDG_DATA_DIRS isn't set up by upstart
<mterry> Right, I was saying xdg dirs and ssh agent are the two scripts still useful
<Saviq> mterry, http://paste.ubuntu.com/7595031/ diff between working and broken unity8 env
<ogra_> well, it cretaes a file .config/user-dirs.dirs
<ogra_> /usr/share/upstart/sessions/xdg-dirs.conf
<ogra_> but that file doesnt seem to get processed anymore
<ogra_> (note that even though my name sticks in that upstart job, the code comes from cwayne, not sure what is supposed to process that file and export the vars)
<mterry> ogra_, well that file isn't for DATA_DIRS
<ogra_> oh, right, thats USER_DIRS
<robru> sil2100, hey, mumble hangout time if you're not too busy
<ogra_> Saviq, why do yu think that has any effect on the test though ?
<Saviq> ogra_, because the test *does* prepend a dir there
<Saviq> ogra_, but since it's not in env... it prepends to NULL
<mterry> OK.  So what's the best way to set XDG_DATA_DIRS for the new world order?
<sil2100> Oh
<ogra_> sounds like something ubuntu-touch-session should do perhaps
<ogra_> or do you need to use it in the greeter too ?
<mterry> Ah, that's not a bad spot
<sil2100> robru: coming soon
<ogra_> then the greeter wrapper
<mterry> ogra_, greeter uses ubuntu-touch-session too, but I don't think we need XDG_DATA_DIRS there anywhere
<ogra_> so on desktop i have: XDG_DATA_DIRS=/usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/
<mterry> We probably don't need gnome there
<ogra_> which means we could effectively just point to /usr/local/share/:/usr/share/ ?
<ogra_> neither ubuntu i guess
<mterry> Why not ubuntu?
<mterry> And maybe we want ubuntu-touch in there, to simulate what gnome was doing there (using the xsession identifier)
<Saviq> mterry, ogra_, we *can* default to it in the unity8 suite
<ogra_> ah, i didnt notice it is actually existing on the phone
<ogra_> i thought it comes from the ubuntu-session
<Saviq> tedg, so, in any case, seems I completely misblamed you for the situation
<mterry> ogra_, so /usr/local/share/:/usr/share/ would just be the default value anyway
<Saviq> tedg, and sorry for that, I really don't understand how... I rebooted, worked, upgraded your stuff, died
<ogra_> right, i 'm not sure if we need to use anything thats in /usr/share/ubuntu/settings/system/
<mterry> ogra_, Saviq: so which thing is breaking due to the var not being defined?
<Laney> that file also sets XDG_CONFIG_DIRS
<ogra_> probably the settings app does
<Saviq> mterry, unity8 ap dies
<mterry> ogra_, but I don't think it gets there via XDG_DATA_DIRS
<Saviq> mterry, and anything else that wants to append to XDG_DATA_DIRS
<Laney> It might be easiest to just copy its logic to ease future migration pain
<Saviq> mterry, 'cause it defaults to /usr/share or so, but not if you actually set it in env
<Saviq> mterry, in which case only the ones in that var are used
<mterry> Saviq, hrm.  Because they are appending poorly, but I suppose we could help them out by defining the var to its default for them
<Saviq> without /usr/share fallback
<Saviq> mterry, well, sure, appending to NULL
<mterry> Saviq, but they should be providing the default when appending
<Saviq> mterry, should (could) default to /usr/share:/usr/local/share
<mterry> But no one does, because it's a pain
<tedg> Saviq, No problem, there's a lot of change mixing in the pot right now. Hard to separate it out.
<Saviq> mterry, sure
<Saviq> tedg, indeed
<mterry> OK, so something like this in ubuntu-touch-session:
<mterry> if [ -z "$XDG_DATA_DIRS" ]; then
<mterry>     export XDG_DATA_DIRS=/usr/share/ubuntu:/usr/local/share:/usr/share
<mterry> fi
<mterry> ?
<ogra_> ++
<ogra_> well, Laney mentioned XDG_CONFIG_DIRS
<ogra_> XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/usr/share/upstart/xdg:/etc/xdg
<ogra_> thats what i have here
<Laney> why don't you make it variable like it is currently?
<tedg> ogra_, I'm worried about the upgrade testing not seeing autopilot-legacy. I guess that's what we get fixed with CI Airline doing images instead of PPAs though.
<ogra_> tedg, yeah ... thats the plan
<ogra_> tedg, in fact we want to have the emulator run the full test suite for every landing and give the uploader/commiter the resulting report
 * tedg hopes we don't get a CI TSA along with that plan
<ogra_> on such an image
<tedg> That'd be awesome.
<tedg> I imagine that's phase n+1 though
<ogra_> yeah
<alesage> fginther, that MP is ready for your review again, thanks
<alesage> fginther, https://code.launchpad.net/~allanlesage/cupstream2distro-config/enable-webcred-coverage/+merge/219606
<fginther> alesage, approved
<alesage> fginther, 10Q
<oSoMoN> sil2100, hey, Iâd need landing request on line 33 to take precedence over the one on line 19, which is currently assigned silo 10 (itâs ok to reassign the silo)
<sil2100> oSoMoN: hey! Let me look at that after the meeting
<oSoMoN> thanks!
<mterry> Sorry, got pulled into a hangout
<mterry> Back on XDG_*_DIRS
<mterry> Saviq, ogra_, Laney: https://code.launchpad.net/~mterry/ubuntu-touch-session/xdg-dirs/+merge/222213
<Laney> mterry: how come the special treatment of 'ubuntu'?
<mterry> Laney, my desktop session has it...  I don't think anything is put there though
<mterry> Laney, I know you system-settings folk put files in that dir.  Do you need the dir in DATA_DIRS at all?
<Laney> mterry: That's just a coincidence, it's not meant to be a data dir there
<ogra_> Laney, mterry, there is stuff in it on the phone too
<Laney> your desktop has it because of $DESKTOP_SESSION
<ogra_> (not sure it is used at all though)
<Laney> it's been a wishlist/low priority item for me to rename that directory to /usr/share/ubuntu-system-settings/
<ogra_> /usr/share/ubuntu/settings/system/ has a lot of stuff
<mterry> Laney, oh I was confused by the gnome presense in my XDG_DATA_DIRS, thought that was the DESKTOP_SESSION
<mterry> Laney, but I guess that's from gnome-session?  which we still must use
<mterry> Laney, ok, will drop from branch
<Laney> right
<Laney> we probably do want /usr/share/gnome on a gnome session
<mterry> But gnome-session will do that itself
<mterry> branch updated
<Laney> fair enough
<jhodapp> sil2100, any idea when you'll be able to land simple things like silo 18 again?
<tedg> I'm a bit confused. This still lists autopilot: $ apt-cache rdepends gir1.2-upstart-app-launch-2
<sil2100> jhodapp: hi! I'll land those in a moment :)
<sil2100> jhodapp: we're just having a meeting right now
<jhodapp> sil2100, excellent, that's great news
<sil2100> We kicked a new image so we should be landable now
<jhodapp> nice
<robru> retoaded, hey, I'm getting some SMS messages... not sure what's up, my vanguard shift shouldn't start for 3.5 more hours, also I don't understand these messages at all
<mterry> Saviq, so this was causing autopilot failures for unity8 or for everything?
<ogra_> robru, it wants to make friends with you
<robru> ogra_, yeah something about manta-01 being down. gosh I hope that comes back...
<ogra_> (and probably didnt want its master to know)
<ogra_> mterry, top approved
<ogra_> (and thanks for the descriptive commit message :) )
<mterry> ogra_, heh, I would normally just do the first sentence and leave the second just in the merge description.  I was swayed by your words
<mterry> ogra_, so I guess we need a silo for this guy?
<ogra_> yeah
<ogra_> sil2100, ^^^
<sil2100> o/
<sil2100> Is there a landing prepared?
<sil2100> ogra_, mterry: so, the ubuntu-touch-session change will fix our unity8 test failures?
<ogra_> if i can belive Saviq it will :)
<mterry> Yeah I think so
<sil2100> Awesome
<sil2100> mterry: you want to prepare a landing line for that?
<mterry> working on it
<Saviq> ogra_, I expect a few failures that crept in in the mean time
<ogra_> Saviq, as long as its not all red we'Re fine i think
<sil2100> oSoMoN: looking into your request now
<Saviq> ogra_, +1
<sil2100> oSoMoN: ok, so I flush silo 10 and assign a new one for 33 then
<sil2100> oSoMoN: is that ok with you?
<Saviq> ogra_, fyi bug #1325984 is what I expect to still kick us
<ubot5> bug 1325984 in unity8 (Ubuntu) "unity-mir rejects apps with .desktop files with custom names" [Undecided,New] https://launchpad.net/bugs/1325984
<mterry> sil2100, ready
<sil2100> mterry: o/
<mterry> Saviq, sil2100, ogra_: sorry about that.  My fault for not running the tests, but I didn't expect that change to affect them
<Saviq> hum hum
<ogra_> Saviq, qmlscene behaves very oddly if QT_SELECT (or however that is called) has the wrong value ...
<Saviq> mterry, ogra_, wait for it, my phone just rebooted on start after applying that patch...
<mterry> rebooted?
<Saviq> mterry, yeah, failed to start
<mterry> Ah
<mterry> Huh
<sil2100> ricmm: so... we have an urgent fix for our breakages in ubuntu-touch-session, so be sure to rebuild that one once you are finally free in landing papi
<mterry> I'm not sure how we could screw up boot with this patc
<ogra_> hmm, quoting issue ?
<ogra_> but even then it shouldnt reboot
<ogra_> the session/greeter should just not start
<Saviq> mterry, ogra_, is fine now
<ogra_> k
<ogra_> heisenbug then
<mterry> Building silo
<Saviq> yeah, Schroedinger's cat
<oSoMoN> sil2100, perfect
<oSoMoN> sil2100, you can reuse silo 10 for the request on line 33 if thatâs easier for you
<sil2100> oSoMoN: I already freed up 10 and assigned a different silo - 008
<oSoMoN> that works too, thanks!
<imgbot> === trainguard: IMAGE 68 DONE (finished: 20140605 15:55) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/68.changes ===
<robru> oSoMoN, silo 8, so work, much build! wow
<sil2100> ;)
<Chipaca> sil2100: silo 14 ready for landing \o/
<sil2100> Chipaca: phew, you made it right before the e-mail where I announce TRAINCON-0 ;)
<Chipaca> :(
<brendand> messaging-app is taking a really long time to start
<brendand> i installed silo 2 earlier
<sil2100> Chipaca: ok, so this needs a packaging ACK from ogra_, but I already see he probably won't +1 it because of the changelog :(
<Chipaca> is there a tool to build debian-style changelogs from bzr commits?
<Chipaca> like git-debian-changelog but for bzr
<robru> Chipaca, just import the bzr branch into git ;-)
<robru> Chipaca, kidding, i'm sure that tool exists, but I don't know where to find it, sorry
<Chipaca> bzr merge-upstream looks like it wants to do that but fails
<Chipaca> maybe because i need to use that always for it to work
<Chipaca> not sure
<sil2100> Chipaca: ok, so as long as you remember to keep your changelogs/commit messages informative then I guess we can publish :)
<sil2100> Let me just give it to ogra_
<sil2100> ogra_: https://ci-train.ubuntu.com/job/landing-014-2-publish/25/artifact/packaging_changes_ubuntu-push_0.3+14.10.20140605-0ubuntu1.diff
<sil2100> That's the packaging change, cmake for the win!
<ogra_> Chipaca, thats the last time i'll let a "new upstream release" changelog through from you ...
<ogra_> sil2100, ACK
<sil2100> ogra_: thanks!
* josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<Chipaca> ogra_: ack. Thanks.
<ogra_> sil2100, gallery-app exploded on 68
<sil2100> How?
<ogra_> dunno ... 15 failures
<ogra_> Photo with image name /home/phablet/Pictures/sample04.jpg could not be found
<sil2100> Well, let's fill in a bug and escalate! ;)
 * sil2100 doesn't feel like digging into that instead of upstreams anymore today
<ogra_> there are four that are not related to the missing photo
<ogra_> the rest is though
<ogra_> right
<sil2100> I wonder if it's related to content-hub
<sil2100> We had a landing with that today
<ogra_> 68 isnt looking so great though
<sil2100> kenvandine: ^
<ogra_> smells like it will be worse than the former ones
<pmcgowan> http://people.canonical.com/~ogra/touch-image-stats/68.changes doesnt show much
<pmcgowan> applaunch stuff
 * sil2100 generates commit logs
<ogra_> pmcgowan, nope, there were autopilot-legacy fixes related to the upstart-app-launch renaming
<ogra_> that were hoped to fix a bunch of issues
<kenvandine> sil2100, ?
<ogra_> and unity8 is still waiting for a landing
<pmcgowan> but nothing to break gallery itself, and no content hub landed
<sil2100> Actually, kenvandine's landing landed after 68
<sil2100> tedg: could your click-app-confinement break anything?
<sil2100> tedg: just trying to find anything that could have caused it
<kenvandine> it was broken with that fix :)
<ogra_> pmcgowan, the whole test suite is still untested against the new UAL renaming
<pmcgowan> got it
<kenvandine> whoops
<sil2100> http://people.canonical.com/~lzemczak/landing-team/68.commitlog
<kenvandine> s/with/without
<ogra_> its all quite a mess
<tedg> sil2100, Uhm, it would be confined instead of unconfined. But the gallery confinement should let it see Pictures.
<ogra_> sadly we dont get proper logs until the whole test suite has run
<tedg> sil2100, So the old version could have let a bug through, but I don't think it's changed.
<sil2100> tedg: could you and kenvandine maybe look into that? Since with 68 only this basically landed, so I would suspect this to be a problem, or some other already existing issue
<sil2100> Just want to make sure it's being investigated by people with experience :)
<tedg> sil2100, Sure, let me flash 68
<sil2100> Thanks!
 * ogra_ would like to see some info about AP-legacy ... 
<om26er> Dear people we are here for helping you get through these tough times of TRAINCON-0 - yours QA team. ;-)
<ogra_> but without console log ...
 * ogra_ hugs om26er 
 * om26er hugs ogra_ back
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<sil2100> o/
<sil2100> om26er: thanks :)
<ogra_> sil2100, oh, if you are away, who will do silos tomorrow ?
<sil2100> ogra_: Mirv  :)
 * ogra_ has no clue how to assign them etc ...
<ogra_> PHEW !
<ogra_> thanks :)
<sil2100> ogra_: I already asked him and he said he'll be around for silo management in our timezone
<sil2100> And he's a veteran
<ogra_> sil2100, calendar looks pretty bad too btw
 * tedg needs photos to test with, everyone smile!
<sil2100> Again all failed...
<ogra_> i guess this will be much worse than 67
<sil2100> ogra_: so it seems it wasn't autopilot py2's fault it seems?
<ogra_> probably not
<sil2100> Or wait
<sil2100> hm
<sil2100> Why do I see the same message again?
<ogra_> 16:36:31.206 INFO _launcher:116 - Attempting to launch application 'com.ubuntu.calendar_calendar_0.4.296' with URIs '' via upstart-app-launch
<ogra_> 16:36:44.219 ERROR proxies:410 - Introspect error on :1.55:/com/canonical/Autopilot/Introspection: dbus.exceptions.DBusException:
<ogra_> org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)
<sil2100> Ah, ok, I didn't rename the text
<sil2100> Maybe my branch was invalid
<sil2100> tedg: did you see anything wrong with the debdiff I sent you?
<tedg> sil2100, I didn't notice anything, do you have a branch that I can grep?
<sil2100> tedg: sadly, since I didn't know which branch to use as I saw many direct-uploads in the archive
<sil2100> So I wasn't sure if those got synced
<sil2100> (so I used the sources from LP)
<tedg> Okay, let me see if I can find this gallery issue.
<tedg> Seems it can get the image, but not the thumbnail.
<sil2100> oh
* ogra_ changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: TRAINCON-0
<ogra_> :)
<slangasek> sil2100: why was autopilot-legacy an issue for the landings?  Aren't all of the phone tests migrated to python3 already?
<sil2100> slangasek: yeah, so...
<sil2100> slangasek: from what we saw, some tests still used the old python2 autopilot, that's first
<slangasek> sil2100: which tests are doing that?
<sil2100> slangasek: the other problem was that unity8-autopilot depends on both python-autopilot and python3-autopilot, so by fetching the python2 AP dependency it was pulling in the old upstart-app-launch bits
<sil2100> slangasek: let me look, one moment
<slangasek> ah; is that unity8-autopilot for the desktop?
<sil2100> No
<sil2100> It's the touch unity8 autopilot package
<slangasek> hmm, ok
<sil2100> For instance, from the logs we saw that even ubuntuuitoolkit used the old AP
<sil2100> slangasek: same for messaging-app I saw
<sil2100> Not sure if that's wanted behavior or what... really didn't have time to do that investigation
<ogra_> slangasek, unity8 pulls it in ... its not clear if they are used at all
<ogra_> slangasek, the issue was the dependency that caused parts of the UAL renamed packages ot be reverted on the test image
<ogra_> (i know that some are said to still use legacy ... but what mainly bit us was that AP-legacy brought uupstart-app-launch back)
<slangasek> sil2100: right; this is reflected on https://blueprints.launchpad.net/ubuntu/+spec/core-1311-python3-roadmap as "debs needing porting to python3 but not blocking python2 removal from the image"
<oSoMoN> om26er, hey, Iâd need a QA signoff for landing request on line 33, since weâre in traincon0
<slangasek> sil2100: (sorry, I should have remembered this)
<oSoMoN> om26er, is that something you could do for me?
<om26er> oSoMoN, yes, let me look
<oSoMoN> awesome, thanks!
<om26er> oSoMoN, does it require opening youtube.com on the device ?
<om26er> asking since its blocked here
 * sil2100 needs to finish off a script before going EOD
<oSoMoN> om26er, to verify the fix, it does, IÂ tested it myself here if itâs of any help
<oSoMoN> (I suppose thatâs not how a QA signoff works though)
<om26er> ToyKeeper, do you think you can help in this case ?
<ToyKeeper> oSoMoN: Can you add the relevant tests to the test plan?  It has no tests for the changes in the silo.
<ToyKeeper> oSoMoN: It needs either a manual or automatic test to verify the correct behavior.
<mterry> sil2100, do I need to do anything else for silo 002?
<ogra_> so at least music anf filemanager got better
<robru> mterry, QA signoff I guess
<mterry> Oh right, traincon
<robru> mterry, yep ;-)
<mterry> :(
 * mterry feels bad for contributing to traincon
<oSoMoN> ToyKeeper, will do in a moment, thanks
<robru> mterry, nah, the alternative is that your work would just bitrot forever in a silo
<ToyKeeper> oSoMoN: It looks like only one of the four MPs has any tests, so the other three need them.
 * mterry will offer sacrifices to the St. Christopher, patron saint of travelers (closest I could get to a train)
<cjwatson> ToyKeeper: I need to land https://code.launchpad.net/~click-hackers/click/devel/+merge/222243 (getting our team's lander to do it for me), which I guess will need QA signoff.  Fixes a critical bug; checking that uninstall works is in click's test plan (https://wiki.ubuntu.com/Process/Merges/TestPlan/click).
<ToyKeeper> om26er_: Can you help?
<ToyKeeper> cjwatson: Is the change already in a silo somewhere?
<cjwatson> Not yet, I've asked my team's lander to get it into the process
<cjwatson> Need to go for dinner now, just thought it might save time to ask in advance
<om26er_> ToyKeeper, cjwatson I can help with that
<cjwatson> stgraber: ^-
<oSoMoN> ToyKeeper, added test plan to the landing request
<ToyKeeper> oSoMoN: Could you get it into the actual test plan?  It doesn't really matter unless it's documented for future testing (and preferably automated).
<oSoMoN> ok, will do
<oSoMoN> ToyKeeper, ok, IÂ updated the test plan at https://wiki.ubuntu.com/Process/Merges/TestPlan/webbrowser-app
<ToyKeeper> oSoMoN: Could someone use a site which doesn't require an account, instead of twitter?
<ToyKeeper> Maybe tinypic or imgur or something?
<ogra_> QA: could you guys treat silo 002 with priority ? that is supposed to get the image less red http://ci.ubuntu.com/smokeng/utopic/touch/mako/68:20140605.2:20140530/8424/ ...
<ogra_> (for details talk to mterry but by feedback from tedg that seems ot be the roed out of traincon-0 )
<ogra_> *to be the road
 * ogra_ cant type anymore 
<sil2100> Hey
<sil2100> Shouldn't 002 go without a queue?
<sil2100> It's an isolated fix right?
<sil2100> ogra_, robru: remember that isolated bug-fix-only landings can go without QA sign-off
<robru> oh, well in that case
<robru> mterry, silo 2 published
<mterry> yay
<oSoMoN> ToyKeeper, yes, probably
<robru> stgraber, you got silo 10, please build
<ToyKeeper> ogra_: Yes, if it's related to fixing a blocker and it's an isolated change, it can bypass sign-off.
<ogra_> mterry, ^^
<oSoMoN> ToyKeeper, neither tinypic nor imgur will do, as they donât seem to restrict the accepted mimetypesâ¦
<ToyKeeper> Traincon 0 only holds back the other changes, features, large branches, anything not related to fixing blockers.
<ogra_> we need traincon training to be more trained ;)
<oSoMoN> ToyKeeper, so unless you can suggest another login-free site, weâll have to keep twitter on the test plan
<ToyKeeper> oSoMoN: Okay, was just hoping for something which doesn't require an account, since that's a lot easier for random people and scripts to test.
<ogra_> how is twitter login free ?
<oSoMoN> ToyKeeper, agreed, if you come across such a site let me know so I can update the test plan
<oSoMoN> ogra_, itâs not
<ogra_> yeah
<robru> oSoMoN, what kind of site? you can upload photos to imgur without logging in
<oSoMoN> robru, yes, but they donât seem to restrict the accepted mimetypes, which is what weâre interested in testing
<robru> ah
<robru> ok, well I'm off for lunch, happy to publish anything when i get back
<ToyKeeper> I suppose I'll need to finally make a twitter account.
<oSoMoN> ToyKeeper, found one: http://www.wufoo.com/html5/attributes/07-accept.html
<oSoMoN> ToyKeeper, having a test twitter account around wouldnât hurt though (I donât use twitter myself but I have a test account for this sort of things)
<oSoMoN> Iâll update the test plan
<oSoMoN> done
<ToyKeeper> ... testing
<stgraber> cjwatson: things are building at https://launchpad.net/~ci-train-ppa-service/+archive/landing-010/+packages
<fginther> mardy, alesage, the changes to collect coverage have been deployed. Future builds should now work.
<alesage> fginther, thanks
<alesage> fginther, when's your next vanguard btw? have to get a traunch of these ready for review
<fginther> alesage, Tuesdays and Wednesday now
<alesage> fginther, supah, will ask about next Tues.
<ToyKeeper> Well.  Found a new bug in the browser...  not sure yet how wide the impact is.
<ToyKeeper> Anyone know if this is a known issue in oxide?  http://toykeeper.net/tmp/browser-rendering-errors-while-scrolling.2.png
<ogra_> never seen that
<ToyKeeper> So far, I only see it in the uReadIt app.
<ogra_> i have seen other funny things like the screen gettng squeezed for a split second etc
<ogra_> nothing i can really put a hand on
<ogra_> but font rendering was always very nice hhere
<ToyKeeper> It's not just fonts.  Images behaved the same.
<ToyKeeper> http://toykeeper.net/tmp/browser-rendering-errors-while-scrolling.png
<sil2100> o/
<ogra_> wow
<ogra_> definitely never happened to me ... though i only use promoted images on the phone ...
<ogra_> (i use my flo for the unstable stuff)
<ToyKeeper> This is image 68, unmodified.  Was checking baseline behavior before testing a silo.
<ogra_> i have 67 on my flo and the G+ app behaves just fine
 * ogra_ upgrades to 68
<ToyKeeper> I see this in uReadIt, and I don't see it in the xkcd webapp.  Haven't tried others yet.
<ogra_> i'll try ureadit then ... probably an app bug though
<ogra_> note that we have two browser frameworks installed ... could well be that ureadit still uses webkit
<ogra_> mhall119, does ureadit use oxide or webkit ?
<ToyKeeper> The slashdot app has no issues either.
<ogra_> ureadit behaves fine on flo so far ...
<ogra_> ToyKeeper, ha ! got it now as well on flo
<mhall119> ogra_: oxide, but it's not great
<ToyKeeper> mhall119: It's doing this: http://toykeeper.net/tmp/browser-rendering-errors-while-scrolling.2.png
<ogra_> yeah, it seems to have issues i see in no other webapp
<mhall119> ToyKeeper: all the time, yeah, it's really annoying
<ToyKeeper> I was trying to figure out where the bug should go...  what component is responsible.
<mhall119> ogra_: it's not a webapp, it's a QML app with an UbuntuWebView component inside a Page on a PageStack
<ToyKeeper> mhall119: Known bug then?  Got a link?
<mhall119> UbuntuWebView is responsible, I think it's part of the webbrowser-app project still, oSoMoN ^^
<mhall119> ToyKeeper: I haven't filed it yet, no
<mhall119> glad to know somebody besides me is still using uReadIt though :)
<ToyKeeper> mhall119: It's in the webbrowser-app test plan: https://wiki.ubuntu.com/Process/Merges/TestPlan/webbrowser-app
<oSoMoN> mhall119, ToyKeeper: the rendering issues would be an oxide bug, can you please file it there: https://bugs.launchpad.net/oxide/+filebug
<ToyKeeper> oSoMoN: Yes, and that's where I was about to file it before I heard it might be webkit or something else.  :)
<robru> cjohnston, hey vanguard buddy, is it time for my vanguard shift now?
<mhall119> thanks ToyKeeper
<oSoMoN> whether itâs webkit or oxide doing the rendering depends on whether version 0.1 or version 0.2 of Ubuntu.Components.Extras.Browser is being imported
<mhall119> it's 0.2 now
<oSoMoN> in the case of ureadit, itâs version 0.2, hence oxide
<cjohnston> robru: yessir
* robru changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: robru | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: robru. oh, and TRAINCON-0
<robru> cjohnston, so, uh, hey, wanna give me a crash course in vanguarding? this is my first one
<cjohnston> robru: do you know where the docs are and do you have pager duty setup?
<tedg> K, so a reflash of 68 + the touch-session fix make clock/gallery/etc work for me in casual testing.
<robru> cjohnston, I have pager duty set up sort of, it texted me a couple things at 8am this morning, I didn't understand them. also I don't have the doc handy
<cjohnston> robru: so to understand the notifications you really need to go into PD..
<ToyKeeper> mhall119, oSoMoN: https://bugs.launchpad.net/oxide/+bug/1326924
<ubot5> Ubuntu bug 1326924 in Oxide "rendering issues while scrolling within UbuntuWebView" [Undecided,New]
<robru> cjohnston, yeah I was looking at those
<cjohnston> if you look over the doc, that's probably a really good start...
<robru> cjohnston, great, it's big ;-)
<cjohnston> There are too many things that could happen to really give a 'crash course'... the doc is probably the best bet.. and then as you see stuff, investigate, read the doc, ask questions of others... etc... and please, since you are a fresh set of eyes, if you run into something that is missing from the docs, add it in
<robru> cjohnston, oh, good call. ok will do
<cjohnston> Someone could spend an hour telling you things, and then the way things work out you never see those issues.. heh
<oSoMoN> ToyKeeper, thanks for the bug, howâs the testing going?
<tedg> With silo 10 I can uninstall apps.
<tedg> alecu, We should probably put quotes around the app name. I got "Uninstall YES or NO?" and then the buttons were Cancel/Uninstall. But "YES or NO" is the name of the app :-)
<robru> tedg, brb, making an app called "Your mom"
<robru> then another one called "the Internet"
<ogra_> robru, FYI starting an image build so we get results for the ubuntu-touch-session change ...
<robru> ogra_, excellent
<tedg> Heh, good, good.
<tedg> robru, Fill our app store with value! :-)
<robru> tedg, I live to give! ;-)
<ogra_> robru, err, or not ... it vanished
<robru> ogra_, https://launchpad.net/ubuntu/+source/ubuntu-touch-session/0.108+14.10.20140605-0ubuntu1 what vanished?
<ogra_> robru, weird ... rmadison didnt have it for a while
<robru> ogra_, glitch in the matrix... looks fine to me even in rmadison. builds away!
<ogra_> yeah, looks fine now
<Saviq> ogra_, "<CI-SNCF> mterry, , saviq (landing-002): Migration: All packages are in destination. You can Merge and Clean now. (https://ci-train.ubuntu.com/job/check-publication-migration/19455/console)"
<Saviq> oof
<Saviq> ogra_, you scared me there!
<ogra_> Saviq, yeah, i guess it uses rmadison
 * Saviq has no idea who rmadison is, but feels for him/her
<ogra_> Saviq, http://paste.ubuntu.com/7596770/
<robru> ogra_, what does? nothing in citrain does (citrain polls lp for the package status, which has known limitations regarding when packages actually hit the archive)
<ogra_> robru, how/where does it poll the package status ?
<ogra_> rmadison is the only reliable source
<ogra_> the LP UI is currently not in sync with the publisher ...
<ogra_> not sure about lplib ... but i guess it uses the same DB
<robru> ogra_, you're right, rmadison is the only reliable source, and citrain is emphatically not using that. it's caused us many problems.
<ogra_> well, colin mentioned plans to improve the LP side
<robru> that would be nice
<ogra_> so we should hopefully see that becoming better soon
<ogra_> image building btw ...
<ogra_> bot should announce it soon
<imgbot> === trainguard: IMAGE 69 building (started: 20140605 19:30) ===
<ogra_> on that note ...
 * ogra_ &
<robru> OGRA AND.... OGRA AND... what?!?!
<ToyKeeper> He daemonized.  He's daemonic now.
<ToyKeeper> He's hiding in the background, lurking in the shadows.
<robru> hide yo kids, hide yo wife
<cjwatson> stgraber: thanks
<om26er> cjwatson, regarding the click silo its status still says its not tested
<om26er> it first needs to be tested by the dev team and then we (QA) test it
<cjwatson> om26er: yeah I know, but I'm about to go out for the evening
<cjwatson> om26er: so it'll be a few hours
<tedg> om26er, cjwatson, not sure that I count for that approval, but it does work for me.
* robru changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: TRAINCON-0
<om26er> tedg, if you have tested you can formally change the status of 'Testing Done' in landing-010 tab ;)
<tedg> om26er, I think it makes sense to wait for cjwatson at this point considering it won't get into an image anyway.
<tedg> I really want to see how 69 turns out, hoping it'll focus our efforts.
<tedg> Cool, music-app fixed in 68. http://ci.ubuntu.com/smokeng/utopic/touch/mako/68:20140605.2:20140530/8424/music_app/
<tedg> Looks like the biggest regression in 68 was the clock app, which should be fixed in 69.
<om26er> cjwatson, I gotta sleep now, in my absence ToyKeeper is your QA help
 * om26er outy
<imgbot> === trainguard: IMAGE 69 DONE (finished: 20140605 21:15) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/69.changes ===
<tedg> Thanks imgbot!
<robru> can't wait for the smokeng on this one
 * tedg can't wait, downloads ;-)
 * popey updates devices
<ToyKeeper> Hmm, now my device isn't responding to screen input.  (image 68 still)
<ToyKeeper> Well, not entirely true.  If the screen starts to dim from inactivity and I touch it, it'll go bright again.
<ToyKeeper> Otherwise, no response to screen inpt.
<ToyKeeper> input even.
<tedg> 69 seems to behave well. Hoping the automated tests show the same.
<robru> tedg, results are still coming in, but so far mediaplayer-app is showing improvements in the smokeng
<tedg> robru, Nothing has failed yet, it's perfect!
<tedg> :-)
<robru> quick, RTM!
<tedg> It does seem to be running warmer than I remember.
<tedg> Not sure if it's just summer in Texas, or really an issue.
<t1mp> robru: :)
<fginther> balloons, the utopic tests have been re-enabled for the coreapps jenkins
<balloons> fginther, all sorted then?
<fginther> balloons, yep, I had to rebuild the test host, but it all appears to be working again
<balloons> fginther, awesome thanks
<ToyKeeper> Shouldn't we be at least a little bit worried about /sbin/init crashing before the user even has a chance to log in?
<ToyKeeper> That has been happening for a while...
<tedg> ToyKeeper, Not seeing any crash files for that, do you have one?
<tedg> Oh, wait, I have one now.
<ToyKeeper> Every time I flash, I get a /sbin/init crash before the device even gets to a welcome screen.
<ToyKeeper> I also get a mediascanner crash soon afterward, but I think that's because I push a bunch of files to the device for testing after flashing.
<ToyKeeper> (a bug, but one triggered by my own actions)
<tedg> Uploading mine to daisy
<tedg> Make sure the Upstart folks can get a retrace.
<tedg> ToyKeeper, Seems to be this error: https://errors.ubuntu.com/problem/1b58afecf2814f03d3953923cfe361887edf91c0
<tedg> ToyKeeper, So looks like we need an Upstart release to fix it, as it's already in trunk.
<ToyKeeper> tedg: I can't view that page.
<tedg> ToyKeeper, Hmm, that's odd. Anyway, the LP bug is bug 1222705.
<ubot5> bug 1222705 in upstart (Ubuntu) "init assert failure: alloc.c:633: Assertion failed in nih_unref: ref != NULL" [Medium,Confirmed] https://launchpad.net/bugs/1222705
<veebers> tedg: you still around perchance?
<veebers> tedg: nvm sorry, my issue has sorted itself out ;-)
<cjwatson> ToyKeeper,tedg: Right, tested silo 10 in my device and it works fine for me, definitely fixes the uninstall issue; if QA signoff is necessary then could QA have a look?
<cjwatson> That's bug 1326694
<ubot5> bug 1326694 in click (Ubuntu) "Can't un-install clicks #65 mako - missing uninstall button" [Critical,In progress] https://launchpad.net/bugs/1326694
<cjwatson> I don't think I have the ability to mark it as tested, or if I do then I don't know how.
<ToyKeeper> cjwatson: Ah, it's built and in a silo now?  Sweet.
<cjwatson> Yep
<cjwatson> My testing is a bit hampered by the fact that the only way I have internet right now is via 3G tethering which I only know how to do via Android, so I can't simultaneously test and have internet on my laptop
<cjwatson> A good part of https://wiki.ubuntu.com/Process/Merges/TestPlan/click from "Suggested Tests" down wasn't written by me and I can't vouch for how well it's likely to work; I'm not very convinced that creating more users is a good idea on a phone
<cjwatson> Nor that it's interesting to try; that's what unit tests are for IMO
<cjwatson> But meh, your call I guess
<cjwatson> In fact I think a good chunk of the "Suggested Tests" are just can-never-work right now.  I'd suggest considering them a work in progress (which should go into automatic integration tests anyway) and skipping them for the moment
<cjwatson> Dropped a note in the wiki explaining why
<ToyKeeper> cjwatson: Thanks.  Part of what happens in traincon 0 is actual review of test plans by people who didn't write them, so I tend to complain a lot at people for that sort of thing.
<ToyKeeper> I'm a bit slow today though, due to massive jet lag and being on call during the hours I should be asleep.
<cjwatson> ToyKeeper: Right.  I'm off to bed shortly, because after midnight.  Hopefully it's not so bad that it can't be published; if you decide it's OK to sign off despite problems then I'd appreciate it if you could let a lander know so that they can publish it before I'm up again.
<ToyKeeper> cjwatson: It'll probably be fine.
<cjwatson> My only a priori concern was whether the broken desktop files would be automatically regenerated on session restart with the fixed code, but it turns out that (for me) they are.
<cjwatson> I hadn't been going to go to special efforts to smooth the upgrade given that it's only in devel-proposed, but that saves me a mail to ubuntu-phone@ at last.
<cjwatson> *least
<robru> cjwatson, i gave you edit access to the spreadsheet in case you already didn't. you can mark testing: yes here: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc&rm=full&pli=1#gid=28
<cjwatson> robru: Ah, thanks a lot, done
<robru> great
#ubuntu-ci-eng 2014-06-06
<imgbot> === trainguard: IMAGE 70 building (started: 20140606 02:10) ===
<robru> well image 69 looks pretty damn good
<plars> robru: it does indeed, what was the fix?
<plars> I'm glad to see things starting to get back to normal
<plars> btw, all of our mantas are down at the moment, I have an RT in to get that fixed
<robru> plars, this one contains the further UAL fixes I think
<robru> plars, http://people.canonical.com/~ogra/touch-image-stats/69.changes no, it's mterry's touch session fixes
<ToyKeeper> Testing Click stuff, I randomly selected tipster as an app to install.
<ToyKeeper> It took so long that the network shut itself off and the download failed.
<robru> ToyKeeper, awesome
<ToyKeeper> On a later attempt, I made sure to keep the screen on, and I investigated afterward why the app was so big.
<ToyKeeper> It consists of 10 KB of qml, 80 bytes of json, 161 bytes for a .desktop file, and the other 99.8% of the package consists of its launcher icon.
<ToyKeeper> (including multiple different copies of the icon's original svn file, and the resulting rendered PNG)
<ToyKeeper> I have to wonder what goes through people's heads sometimes.
<plars>    * Don't run lightdm-session if using a Mir session.
<plars> I guess that?
<robru> ToyKeeper, seems pretty clear that the person did not check the file sizes. obviously nobody thought "yes, my app needs to be 99% launcher icon"
<plars> if I'm looking at the right changes file
<ToyKeeper> robru: Well, yeah.  :)
<ToyKeeper> Just a general lack of sanity checking before hitting 'publish'.
<robru> ToyKeeper, make sure to rate it 1 star and say "Hey jerk, pngcrush your launcher icon" or something.
<ToyKeeper> More like "Hey, don't put unnecessary build files in your package!"
<robru> ToyKeeper, to be fair, it's retardedly easy to just have one directory with all the files, and then 'click build .' and upload that to the store. It takes extra work to have a subdirectory that contains only what the app needs to run, and then have supporting files in a separate directory from that
<robru> ToyKeeper, but I agree, app authors should stop sucking ;-)
<ToyKeeper> I hope we have plans to increase bandwidth for the click app servers before any hardware launches.  I consistently get 20 KB/s or less for app downloads.
<robru> mandel, bregma: i got you guys silos and kicked builds for you. 2 and 8 respectively.
<robru> and with that, I'm gonna go pass out. this jetlag is just killing me
<robru> goodnight everybody!
<imgbot> === trainguard: IMAGE 70 DONE (finished: 20140606 03:45) ===
<ToyKeeper> Oops, I guess I flashed a little too soon.
<ToyKeeper> Just a few minutes too soon.
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/70.changes ===
<Mirv> two awesomes in the row it seems, for images
<ToyKeeper> So, I tested and approved some silos...  but only one actually landed.
<ToyKeeper> The others pretty much all got stuck at "One package at least is not available in the destination...  foo is in the proposed pocket."
<ToyKeeper> And one silo got reassigned before that could be resolved.
<ToyKeeper> (silo 008, I think...  and I've been so sleepy today I don't remember which change was in it earlier)
<ToyKeeper> IIRC, several of our failures over the past week were due to things getting stuck in proposed.  Wondering what we can do about it.
<om26er> morning
<ToyKeeper> om26er: Hi.  I'm not sure what's up with the silos I tested and approved today.  Just FYI.
<ToyKeeper> Only one actually landed.
<ToyKeeper> The others pretty much all got stuck at "One package at least is not available in the destination...  foo is in the proposed pocket."
<ToyKeeper> And one silo (008) got reassigned before that could be resolved.
<om26er> ToyKeeper, yeah I was noticing that as well. Is there any silo remaining that needs testing ?
<ToyKeeper> Not that I'm aware of, but it's possible I missed something.  I worked straight through the hours my body thinks are sleep time, and was a bit of a zombie.
<om26er> ToyKeeper, i came to the rescue early, its a new record start time for me
<om26er> you may sign out if you want
<ToyKeeper> I think I'll take you up on that; I'm exhausted and have been working for 15 hours.
<om26er> robru, do you whats up with the landings ?
<ToyKeeper> robru went to sleep a few hours ago, I think.
<Mirv> om26er: which landing in particular?
<om26er> Mirv, 31 for example
<Mirv> om26er: ok, click is in already, that info is old. currently the backend jenkins is out of disk space (I've reported it to webops), so it's probable that the spreadsheet also doesn't update itself anymore.
<ToyKeeper> Yup, line 31 (silo 010) is one that should have landed but got stuck.
<ToyKeeper> Oh, cool.
<Mirv> yep, not stuck: https://launchpad.net/ubuntu/+source/click/0.4.25 -> release pocket
<ToyKeeper> In that case, I have no idea if any silos are waiting on QA.
<Mirv> I guess not, since the Mir one was mentioned in sil2100's e-mail to be postponed until we're out of TRAINCON-0 anyway
<ToyKeeper> Uh...  yeah.  Seems like a really bad idea to land a major high-risk change to a foundational bit of architecture right in the middle of traincon 0, which was caused by several other similar landings happening too quickly.
<Mirv> I found out that the upstart^Wubuntu-app-launch joy is also found in the SDK now https://bugs.launchpad.net/qtcreator-plugin-ubuntu/+bug/1327066
<ubot5> Ubuntu bug 1327066 in qtcreator-plugin-ubuntu "upstart-app-launch was renamed to ubuntu-app-launch, launching apps from SDK broken" [Undecided,New]
<ogra_> Mirv, how about an image to pick up the click fix ?
<Mirv> ogra_: sure, why not
<Mirv> we can't land anything new anyhow before webops fix the jenkins
<ogra_> well, i think the click issue was the last promotion blocker
<ogra_> and the tests look good
<ogra_> so if dogfooding brings good results 70 might be the way out of traincon-0
<ogra_> ERR
<ogra_> "Daily rebuild quota reached for product."
<ogra_> aha ?!?
<Mirv> eh
 * ogra_ goes to build direct ....
<Mirv> yep 69 + 70 look very good on the dashboard, finally
<ogra_> build started
<mandel> robru, thx
<mandel> ogra_, just to double check, is the commit good enough => https://code.launchpad.net/~mandel/dbus-cpp/provide-macros/+merge/221840 (not being sarcastic I want to help :) )
<ogra_> mandel, perfect "
<ogra_> !
<mandel> ogra_, ok, will keep them like that then
<ogra_> thanks ! :)
<imgbot> === trainguard: IMAGE 71 building (started: 20140606 07:50) ===
<mardy> alesage: hi! Do you have a few minutes to help me to solve this? https://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-online-accounts-utopic-amd64-ci/17/console
<mardy> alesage: the coverage targets are only available if the CONFIG+=coverage is passed at configure time
<mardy> alesage: but I don't want to add that all the time; is it possible to activate it only for jenkins? is there some debian variable which is set during jenkins build which I could use in debian/rules to enable this flag?
<popey> will 71 include the click removal fix?
<popey> looks like click 0.4.25 as it
<popey> *has
<Mirv> popey: yes
<popey> ok, good
<Mirv> and webops just arrived, so hopefully jenkins will come back alive soon
<popey> oh, jenkins is dead?
<Mirv> out of disk space again :(
<popey> bah
<popey> I have a 32GB USB key they can plug in and use ã
<Mirv> :)
<popey> #69 looked good from a dogfooding pov
<popey> just not happy promoting it with the click regression
<ogra_> popey, yeah
<ogra_> we wouldnt, dont worry :)
<popey> is #71 expected to be more awesomer?
<ogra_> i think 71 is the one :)
<ogra_> nothing else landed i think
<popey> good good.
<popey> thats the only thing about #69 that would block IMO
<ogra_> well, there is that webbrowser fix that makes youtouboe work ... but who wants *that*
<ogra_> :P
<popey> pfffffft
<popey> oh. cat videos you say?
 * popey wakes 
<ogra_> on m.youtube.com ...
<brendand> popey, i preferred it back in the 50s
<ogra_> without ending up just reloading the page if you press play
<mardy> alesage: nevermind, I think I fixed it with this :-) http://bazaar.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/master/revision/125
<Mirv> ok jenkins restored
<Mirv> ogra_: popey meeting?
<Mirv> right on time
<popey> â»
<Saviq> oh yay! http://ci.ubuntu.com/smokeng/utopic/touch/mako/70:20140606:20140530/8429/
<Saviq> we're back in business
<Mirv> yeah
<ogra_> on out way to at least :)
<Mirv> so the spreadsheet got broken with the jenkins breakage, and it does not seem it would be automatically recovering now that jenkins is back up.
<Mirv> all ideas / information bits welcome on what sil/didier used to do to restart things on the spreadsheet :)
<Mirv> I only know about manually running the refresh function, but that fails
<Mirv> not that we immediately need much of the spreadsheet
<Mirv> well, http://people.canonical.com/~rbpark/citrain/ to the rescue too
 * Mirv updated info on the top of the sheet
<ogra_> is didier off today too ? he probably could help
<Mirv> true, no he's not
<imgbot> === trainguard: IMAGE 71 DONE (finished: 20140606 09:25) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/71.changes ===
<popey> \o/
<Mirv> spreadsheet is back to life again too
<popey> ogra_: i was right, mirscreencast broke.
<popey> $ adb shell mirscreencast -n 1
<popey> Failed to connect to server. Error was :connect: No such file or directory
<popey> adb shell mirscreencast -m /var/run/mir_socket -n 1
<popey> that works
<popey> getting a lot of lp timeouts
<popey> bug 1327139
<ubot5> bug 1327139 in mir (Ubuntu) "mirscreencast broke (moved socket) in #71" [Undecided,New] https://launchpad.net/bugs/1327139
<popey> OMGOMGOMGOMG!
<popey> Not only youtube video work, video works in BBC News webapp too
<popey> This changes *everything*!
<ahayzen> omg what!
<ogra_> popey, it didnt before ?
<ogra_> popey, for me all embedded videos worked in my news apps
<ogra_> just the direct youtube ones didnt
<popey> the bbc ones didnt
<ogra_> wow, bad
<popey> they do now, so i dont care. image #70 and before are dead to me
<ogra_> haha
<popey> now we just need to get someone to agree to allow webapps to keep screen on and not suspend phone
<popey> and play in background
<popey> haing grooveshark stop playing music when you swipe away makes the webapp useless
<ogra_> it will do that once it starts using media-hub
<ogra_> (and videos will be HW accelerated then ... not eating battery )
<popey> ok
<ogra_> its just very complex to inject that into the browser sandbox
<ahayzen> when did youtube start working as well?
<popey> in this image I believe
<popey> #71
<ahayzen> \o/
<ogra_> wow, surprising ... the boot time didnt degrade at all with split greeter
<ogra_> http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-utopic-71.png
<ogra_> still around 30sec
 * popey wonders why image 69 fell into the trusty testing bucket http://ci.ubuntu.com/smokeng/trusty/touch/
<popey> (flo only)
<ogra_> heh
<ogra_> psivaa, ^^^
<psivaa> popey: ogra_: let me take a look
<psivaa> ogra_: popey: somehow jenkins thinks the content of http://system-image.ubuntu.com/ubuntu-touch/trusty-proposed/flo/index.json changed when new images were built
<psivaa> for the last couple of days that is
<ogra_> funny jenkins ...
<psivaa> not just once, but the trusty job for flo has run twice.
<popey> ogra_: still can't uninstall on #71 â¹
<ogra_> crap
<ogra_> i cant either (OTA here)
<ogra_> and tedg wont be around for a few more hours :(((
<om26er> popey, ogra_ it was working fine with that version of click I tested deeply
 * popey updates bug 1326694
<ubot5> bug 1326694 in click (Ubuntu) "Can't un-install clicks #65 mako - missing uninstall button" [Critical,Fix released] https://launchpad.net/bugs/1326694
<popey> do i need to re-run the apport hooks thing perhaps?
 * popey tries that
<popey> s/apport/apparmor/
<cjwatson> popey: no stop
 * popey stops
<cjwatson> popey: nothing to do with apparmor :)
<cjwatson> popey: can you pick an affected application and see if it has X-Ubuntu-Application-ID in its .desktop file in ~/.local/share/applications/ ?
<popey> cjwatson: it does not http://paste.ubuntu.com/7601190/
<cjwatson> popey: right, so please remove everything in ~/.local/share/applications/ and reboot
<popey> ok
<cjwatson> popey: they should get regenerated with proper contents
<popey> sweet
<ogra_> hmm
<ogra_> semi sweet
<cjwatson> popey,ogra_: it occurred to me that this might happen, but it didn't happen in my case; it only affects people who upgraded through the broken -proposed images
<cjwatson> so I don't think it's worth going to special measures to handle
<ogra_> right, but it is something we need to mention in the landing mail i suppose
<cjwatson> Yes
<popey> X-Ubuntu-Application-ID=com.popey.youtube_youtube_0.1
<cjwatson> I'd send a mail myself now but I have internet problems
<popey> it has one now
<cjwatson> popey: cool, and uninstall works?
<cjwatson> stuck in the library, no access to mail
<popey> er, different app, but yeah.
<ogra_> dont worry, thats what we have the daily landing mails for
<ogra_> i'll make sure robru adds it
<popey> cjwatson: yes, i see an uninstall button now. and it works
<ogra_> bzoltan, i know i have seen a fix for this smoketest error in UITK the last days ... http://ci.ubuntu.com/smokeng/utopic/touch/mako/71:20140606.1:20140530/8440/ubuntuuitoolkit/1226263/ but i cant seem to find a branch for it ...
<cjwatson> Great
<popey> ok, commented on bug report, thanks cjwatson
 * ogra_ wonders if that fix was from the AP guys and not from the UITK guys 
<t1mp> ogra_: https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1326072-create_fake_xauthority/+merge/221953
<ogra_> \o/
<ogra_> t1mp, you rock ...
<t1mp> ogra_: it is in UITK staging, so should go in the next landing beginning of next week (I think zoltan is off today)
<ogra_> ah, k ... great next week is fine
<popey> ogra_: mako finished testing
<ogra_> and we have one failure less than 70 even
<popey> yeah, bonzer!
<popey> Been dogfooding all morning. It's looking solid.
<ogra_> ah, calendar-app
<ogra_> seems flaky ...
<ogra_> popey, hmm, so we should probably promote something ;)
<popey> Do it.
 * ogra_ does it ... i want the new shiny on my phone *now* !
<popey> Don't spend all afternoon playing youtube videos â»
<ogra_> === IMAGE #71 Promoted ===
<ogra_> yay
<asac> promoted?
<ogra_> Mirv, do we want to drop TRAINCON-0 now or should we better wait til the meeting
<ogra_> asac, yeah :D
<asac> i guess wait if people scream
<asac> for a bit
<ogra_> haha
<asac> if noone complains, lift TRAINNCON-0
<asac> like give end of day lift it so we can still react on rick going ballistic
<asac> or me :)
<ogra_> right, so the evening meeting then
 * asac upgrades
<asac> lol
 * ogra_ upgrades too 
<asac> me has to find a usb cabkle
<asac> because i still cant upgrade without ubuntu one account
<asac> seb128: ^
<asac> didnt you say that was landing?
<ogra_> planning on playing youtube vidos all afternoon
<ogra_> :P
<asac> yeah
<asac> thats awesome indeed
<asac> now i would need tor or nice proxy app
<asac> so i can really watch intersting you tube content
<seb128> asac, check with gatox
<ogra_> lol
<asac> gatox: hey :)
<gatox> asac, hi
<asac> gatox: where are we with fixing that i cant upgrade system image if i dont have ubuntu one account set up
<asac> would like to start enabling ubuntu one so i can install apps, but wanted to be sure its not forgotten before doing that :)
<gatox> asac, are you using the last image? that should already be fixed
<asac> gatox: ok i am on previous devel, so after this upgrade it shoudl be gone. will confirm! thanks!
 * asac upgrades to 71
<popey> thanks ogra_
<ogra_> well, thanks for dogfooding :)
<popey> can we call it catfooding?
<ogra_> ++
<asac> lets also think about vegetarians
<Mirv> ++
<gatox> asac, seb128 this was the branch that fixed that: https://code.launchpad.net/~diegosarmentero/ubuntu-system-settings/duplicate-and-credentials/+merge/218414
<asac> so horse/cowfeeding :)
<asac> lol
<asac> or something sweet that doesnt eat meat
<ogra_> guineapiggin ;)
<asac> lol
<asac> plantfeeding :)
<ogra_> :)
 * asac wonders what will show on screen aftrer install/restart
<ogra_> same sh*t as always
<ogra_> UI wise nothing changed yet
<asac> are the scope images now cached?
<ogra_> the boot animation is there but not enabled
<asac> feels super instantaneously how the display
<ogra_> i dont think so
<asac> oh
<asac> the UI is pretty much transalted
<asac> in gertman
<asac> thats surealy new
<ogra_> yeah
<asac> even the sim unlock dialog was good
<popey> ogra_: are you sending the mail?
<Mirv> elopio: any updated on bug #1275012 ? I'm trying to have some sort of manually run results again before the meeting but obviously that's not the same thing
<ubot5> bug 1275012 in Ubuntu CI Services "Add a job to run all the image tests with new qt versions" [Undecided,New] https://launchpad.net/bugs/1275012
<popey> or are we doing that later?
<ogra_> popey, thats robru's job today ... after the evening meeting
<ogra_> sigh ... first boot after flash always takes ages
<elopio> Mirv: robotfuel had that task. I'm not sure if he had already talked with ci.
<elopio> he should start working soon, I'll check with him.
<Mirv> ok, thanks!
<elopio> Mirv: do you have any idea what's this task about?
<elopio> UITK Unit tests to be fixed (Leo)
<elopio> I'm not sure why I'm assigned to the unit tests.
<Mirv> elopio: maybe you're assigned to keeping in touch with the SDK team? all the unit test bugs for UITK are there at https://bugs.launchpad.net/bugs/+bugs?field.tag=qt5.3 and they have assignee too. I just also filed the two AP failures they have (= 247 AP tests pass fine), those are not assigned yet.
<elopio> wow, so many already.
<elopio> Mirv: ok, I can keep track of them and ask for triaging.
<Mirv> elopio: if we could get the camera + multimedia working, it'd so far look very functional at the moment
<ogra_> EEEK !
 * ogra_ found a regression 
<ogra_> asac, what does the clock on the greeter show for you ?
<asac> ogra_: greeter == lock screen?
<asac> the time i see there is correct
<asac> 13:58
<ogra_> yes
<asac> Freitag, 6. Juni 2014
<ogra_> i see 1:58 PM
<ogra_> in the indicator too
<asac> i am sure you set your locale settings long ago
<ogra_> as soon as i swipe the greeter away i see 13:58 in the panel clock
<asac> i set them recently, maybe there is another field for date/time that wasnt migrated and is out of sync for you?
<ogra_> i surely did
<asac> right
<asac> try setting to US
<asac> then set it back
<asac> that will mean people didnt bother about the upgrade path
<asac> charles: you said the shell work needed for alarm working is in or wil land right after next promotion?
<asac> indicator/shell work that
<ogra_> asac, i think ricmm's platform-api 2.0 contains that
<asac> hmm
<Mirv> ogra_: ahum, I missed your highlights. but yep evening meeting is probably a good point, and a huge yay for promotion! let's land Qt 5.3 :)
<asac> ogra_: its frontend work that is missinga faik
<asac> and that charles was landing or is about to land
<ogra_> ah, k
<asac> according to folks our backend work is complete and in
<asac> folks == chicken and rsalveti iirc
<ogra_> asac, FYI clock is right after switching to US and back ... (and three reboots to make it pick it up)
<asac> ogra_: ack. guess file a bug against system settings and forget
<asac> e.g. no migration done
<ogra_> well, not sure ... thats not a user setting ...
<ogra_> greeter is system
<asac> i dont know, thjey can deal with redirecting it
 * ogra_ will wait for mterry 
<asac> they provide the UI
<asac> that sets the setting that didnt get properly migrated
<asac> if you find a better place thats great of course :)
<ogra_> my user setting was properly migrated
<ogra_> the greeter is "before login"
<asac> seems not really :)
<asac> the coupling to the sysstem didnt migrate
<asac> for me its all one thing
<ogra_> it is a different session running as the lightdm user
<asac> whoever does the change to settings approach, must ensure it happenes everywhere
<asac> sure, still someone pushed for change
<asac> and didnt ensure that all that needed changed :)
<ogra_> right, its a split greeter issue
<asac> whoever did that push shyould get the bug so he remembers next time to think about everything :)
<ogra_> mterry bug :)
<asac> cool
<popey> ogra_: with new split greeter, my .profile seems ignored. I have export PERFORMANCE_OVERLAY=1, but it no longer works.. does it work for you?
<ogra_> there are a bunch ...
<ogra_> like no avatar pic when recieving a call and the screen iis locked
<ogra_> popey, using phablet-shell ?
<popey> eh?
<popey> phablet-shell to do what?
<ogra_> did you use phablet-shell ?
<popey> no, i dont know what phablet-shell is â»
<ogra_> it had a bug that copied the desktop/laptop .profile file over the one on the phone
<ogra_> popey, what ?!?
<popey> ah, no, my .profile is intact
<popey> i copied that line from it
<popey> but it seems ignored.
<ogra_> upgrade to latest phablet-tools ;)
<popey> phablet-shell is nice!
<ogra_> run phablet-shell ;)
<popey> thanks! :D
<ogra_> it so is !!
<ogra_> flowers go to robru
<ogra_> popey, hmm, could be that with split greeter it doesnt process .profile anymore
<ogra_> file a bug i guess
<popey> in what?
<popey> env shows it's set
<popey> unity8 seems the right place?
<ogra_> hmm, ubuntu-touch-session i guess then
<om26er> so I am trying to test unity8 silo, seems add-apt-repository is broken
<om26er> http://paste.ubuntu.com/7601417/
* josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: TRAINCON-0
<Chipaca> who do I know and is a MOTU?
 * Chipaca wonders
<ogra_> have you tried #ubuntu-motu ?
 * Mirv would like to be MOTU one day
<Chipaca> ogra_: I hadn't, but found it on the wiki just before you asked :)
<Chipaca> ogra_: thanks
<Chipaca> (not getting any love there, but hey)
<Chipaca> actually, looking at the logs, i found it a while after you asked, but didn't see the xchat notification. strange.
<Mirv> popey: davmor2: can you come to the Qt 5.3 meeting?
<popey> its in 30 mins?
<popey> oh, it moved!
<plars> ogra_: any chance we'll ever do a trusty image again? I'd like to kill those jobs at some point. They don't run since there's no new image, but some how the json file for trusty on flo got touched and it thought there was a new one
<ogra_> plars, i think thats a management decision ... asac ^^^
<tedg> What gets us out of traincon-0 ? It seems like 69 fixed the critical issue, is it all the way to promotion?
<tedg> I've got some people asking for me to put through some non-critical branches, but I was planning on letting things get out of traincon-0 first.
<popey> Mirv: which ppa should i use for 5.3 testing?
<ogra_> tedg, after tonights landing meeting we'll lift it
<ogra_> (in 2.5h or so)
<tedg> ogra_, Ah, okay.
<tedg> When is the new platform API going in?
<ogra_> its the next big thing on the list
<ogra_> i guess on monday
 * tedg wants to avoid big things :-)
<ogra_> heh
<Mirv> popey: let's put it this way: open any related doc / PPA page you know is related to Qt 5.3, and report if some of them don't point you to the correct direction (I try to update everything with interlinks or such..)
<Mirv> popey: so the default answer is that read instructions that are written on page https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2 (which is slightly confusing of course, but I don't want to edit landing PPA's description) -> you get to ppa:ci-train-ppa-service/landing-005
<tedg> ogra_, So I think the reason that the AP-legacy thing didn't get caught is because the libraries were parallel installable (and worked that way).
<tedg> ogra_, So because I upgrade/removed and then installed the autopilot tests it just reinstalled the lib from the archive.
<ogra_> right, except for the testing infra :)
<tedg> I think the lesson here is to install the AP tests, and then remove the old library.
<asac> plars: its good that we noticed that that file was touched. when was that? check with stgraber why it was touched
<tedg> Not sure that we could really automate that, or should because it's a rare case though.
<asac> plars: i assume the timestamp got updated?
<ogra_> well, the lesson is that the remaining python2 tests finally need to be migrated i guess :)
<tedg> Heh, that too.
<plars> asac: I'm not sure timestamp is enough, it's just a jenkins url watcher that iirc compares a checksum of the file from what it last knew
<plars> asac: there was no new image though
<asac> plars: right, check with stgraber what happened
<ogra_> i think he cleaned up some old cruft
<ogra_> that likely re-gernerated the index
<asac> imo we shouldnt just say "the proble is that the trusty jobs are there", but "did we see odd behaviour on system image files"
<plars> and it was just flo, which is sorta weird: http://system-image.ubuntu.com/ubuntu-touch/trusty-proposed/flo/index.json is the file it was watching
<asac> yeah
<plars> stgraber: any ideas why that got bumped? ^
<asac> i feel its index, but double check with stgraber etc.
 * stgraber reads backscroll
<plars> asac: The downside in a case like this is that it could potentially delay running utopic jobs if we get a false update, and if it's on a release that's unlikely to see an update again, disabling the job would be the safest course of action
<ogra_> plars, asac bug 1286542
<ubot5> bug 1286542 in Ubuntu system image "keyring DuplicateDestinationError when updating from custom s-i server" [High,Fix committed] https://launchpad.net/bugs/1286542
<ogra_> stgraber, ^^^ i think it was your fixing of that one
<stgraber> plars: ok, so what exactly is the problem? you saw trusty-proposed/flo/index.json change recently? when exactly?
<asac> stgraber: seems we say a trusty job in CI scheduled, which only happens if some file change on the server
<asac> so i just wanted to check if that was a wanted change etc.
<stgraber> cdimage@nusakan:/srv/system-image.ubuntu.com/www/full/ubuntu-touch/trusty-proposed/flo$ ls -lh index.json
<plars> stgraber: twice actually... once on June 5, and once on June 6
<stgraber> -rw-rw-r-- 2 cdimage cdimage 139K Apr 22 11:09 index.json
<stgraber> the file hasn't changed on disk since the 22nd of April
<stgraber> which matches the timestamp of image 303
<stgraber> so I suspect something went wrong with whatever you guys use to monitor it...
<plars> at 21:11 and 02:01 respectively
<asac> stgraber: maybe the timestamp was force kept old while the checksum changed? or maybe that file was temporarily not there and jenkins just saw it reappearing?
<asac> but gguess jun 5 and 6 you should remember if anything happened on the server
<asac> not too long ago :P
<popey> Mirv: haha, nice
<stgraber> asac: all changes to index files are atomic and I don't have code to hardcode the timestamp, so I'm pretty sure things didn't change on my side.
<asac> right
<asac> so mayube server was down temporarily
<asac> or jenkins is just buggy (never heard of that)
<plars> asac: absence of the file wouldn't trigger it
<stgraber> yeah, that could be, I have no control over the frontend servers
<asac> temporary absence?
<asac> :)
<plars> pffft no... jenkins has NO bugs
<plars> :)
<asac> you never know
<asac> plars: ok guess disable the trusty trigger
<asac> should be fine
<plars> anyway, it's an anomaly related to flo only at the moment
<stgraber> plars: does Jenkins monitor over https or http?
<plars> asac: but it raised the question of whether we can just mark the trusty jobs as disabled for now
<asac> plars: so we should really have jobs: devel-proposed, devel, stable
<asac> and not trusty etc.
<plars> stgraber: http
<asac> i think we discussed that we have stable-proposed (aka beta) at some point
<asac> not sure if we will use beta or stable-proposed for that
<stgraber> plars: can you do it over https instead? that should at least make things slightly more robust to network glitches
<asac> cjwatson: ^
<asac> cjwatson: last 2 lines only :)
<cjwatson> I think stable-proposed was my suggestion
<cjwatson> I prefer the obvious correspondence with devel-proposed
<plars> asac: we can't use the name "devel" because it's not available at the beginning, and I think it also might pull the series from that - so unless you want to miss the first image, and have a long running set of tests for "devel" rather than separating them like trusty, utopic, vigorous, etc...
<stgraber> plars: it may also be worth spending the extra time to make the checker a bit more clever, either by checking that the file is valid (simple json check) or better yet, grab both the .json and .json.asc and make sure the signature is valid (which will do integrity checking for you)
<asac> cjwatson: i agree. lets do that
<asac> plars: what does it mean its not available at the beginning?
<asac> plars: it is available :)
<asac> plars: for the very first promotion we didnt have a devel image, but since then there is an image in devel
<plars> asac: no, not until there's an image - the devel-proposed channel is an alias that has to be created iirc. stgraber could probably explain the details better
<asac> i dont understand
<asac> isnt there devel image before and after release?
<asac> i think all phones got auto updated to next devel
<asac> so should be fine
<stgraber> there are, they just may end up being the wrong release as we don't do the switch to the new release immediately
<asac> i think once we have stable and stable-proposed thats what we should do though for devel-rpoposed
<asac> e.g. last promotion to devel happens from utopic before release
<asac> and next promotion will be coming from utopic+1
<stgraber> devel-proposed pointed to trusty-proposed until a week or so after release (we were waiting for the name), then we created utopic-proposed, checked that things worked and then changed the alias to point to it
<asac> yeah, thats because we didnt have a stable/stable-proposed solution
<asac> guess that will be solved next time
<asac> anyway,not really important i guess, just would feel cleaner if CI would track channel names
<asac> and not releases
<plars> asac: if we move over to using the devel-proposed channel instead of the ${series}-proposed, I'll need to work with the dashboard guys and figure out what the fallout will be. I suspect it will mean we now see another set of results for series "devel" since it doesn't know the series name then, which will probably mean needing to rework parts of the dashboard to cope with the fact that we no longer have touch results linked to the se
<plars> ries
<stgraber> asac, plars: btw, just did a quick check with a backup from the 12nd of May, index.json for trusty-proposed/flo matches perfectly between the two (same sha256sum), so the file didn't change and didn't get corrupted on my end. It may have been a problem with the frontend server IS runs or somewhere on the network.
<asac> plars: yeah, not urgent. maybe put this into the backlog, and dont even start doing it until aligning with foundations what to do
<plars> stgraber: very possible, I wonder if it downloaded a 404 page or something in the middle there
 * ogra_ remembers a mail about VPN issues to the lab in the beginning of the week
<plars> ogra_: that's unrelated I think
<plars> ogra_: that affected my ability to get to our lab machines and actually do anything on them, not the ability of the lab machines to get out to other systems like the s-i server
<plars> could be though, who knows
<plars> but it seems to be working now
<plars> and happened yesterday/today, not at the beginning of the week when we had those problems
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | CI Train support - US: robru, rsalveti - EU: sil2100, Mirv | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: ci.ubuntu.com is down due to DDoS mitigation testing
<om26er> Mirv, Hi!
<om26er> Mirv, it seems line 33 have wrong status ?
<om26er> Mirv, its not approved by QA but says can be published
<fginther> om26er, renato, in 1149, phablet-test-run used python-autopilot 1.4 instead of python3-autopilot 1.5 which was used on a prior run
<om26er> fginther, you can fix it ?
<Mirv> om26er: hey. I'm off already (yeah right), discuss it with robru when he's around - in general, it's expected that the landing meeting will decide to put away TRAINCON-0 in a little over an hour since an image was promoted, and I guess at that point QA sign off wouldn't be needed
<om26er> Mirv, woho, that's good to hear :)
<renato> fginther, om26er, is this a problem in my package?
<mardy> alesage: yes, it's fine
<fginther> renato, om26er, I have no idea yet what triggered the change
<mardy> alesage: though, I wonder why are we using these hooks and not the DEB_BUILD_OPTIONS variable? we could set DEB_BUILD_OPTIONS="coverage", and then let each project's debian/rules do the right thing, without using hooks
<alesage> mardy, intriguing
<mardy> alesage: so you wouldn't have to worry about what build system a project is using
<alesage> mardy, I'll have to learn a little about, thanks for that :)
<fginther> renato, I see that in your MP, revision 179 merged with staging and brought in a bunch of autopilot test file changes, perhaps something in there is forcing the fallback to python 1.4... phable-test-run does a couple of tricks to determine whether to use 1.4 or 1.5, one of them is to attempt to import the test dir under 1.5 and if it fails, it falls back to 1.4
<renato> elopio, do you know if your changes is related with that ^
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | CI Train Status: TRAINCON-0 | CI Train Support: US: robru, rsalveti - EU: sil2100, Mirv | Known issues: -
<renato> fginther, how I can try to fix that?
<fginther> renato, I'm just going through the code in phablet-test-run and trying to figure out if indeed it's hitting an import error
<fginther> renato, I've got my mako setup to test this but need to get you packages in place first
<renato> fginther, elop did the changes on the autopilot
<renato> and jenkins approved it
<elopio> renato: checking.
* josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train Status: TRAINCON-0 | CI Train Support: US: robru, rsalveti - EU: sil2100, Mirv | Known issues: -
<elopio> renato: which is the branch that's failing for you?
<renato> elopio, https://code.launchpad.net/~renatofilho/address-book-app/fix-click-mode
<fginther> elopio, renato, here's the error that gets reported when trying to import address_book_app with python3: "The ubuntuuitoolkit.emulators module is deprecated. Import the autopilot helpers from the top-level ubuntuuitoolkit module."
<elopio> fginther: that's a warning.
<fginther> elopio, right, but that's enought to trip up the login in phablet-test-run :-(
<fginther> s/login/logic/
<elopio> fginther: really? but that's pretty old.
<elopio> we have been throwing that warning for a month.
<elopio> and it happens on all the apps, as no one has been migrated to the new namespace.
<fginther> hmm, was this change released to the archive a month ago?
<fginther> elopio, nope, looks like tests were passing before with the same version of uitk
<elopio> fginther: yes, https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/reorg_autopilot_helpers
<elopio> merged at the end of april.
<elopio> we have had many toolkit versions since then.
<fginther> elopio, I've learned a couple of things...
<fginther> elopio, 1) there is a bug in generic-deb-autopilot-runner-mako that will cause it install an -autopilot package on top of the MP packages if a newer one exists in the archive.
<fginther> elopio, 2) the deprecation import error for address-book appears to be triggered by the recent addition of 'import ubuntuuitoolkit'.
<fginther> elopio, 3) bug 1) appears to have masked 2) until today when the address-book mainline was merged into the staging branch
<ubot5> bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
<fginther> no, not that bug
<fginther> elopio, the first bug I mentioned needs to be fixed on our end asap. working with the deprecation error on import may need a little coordination
<elopio> :)
<elopio> fginther: great, so many things you have found.
<elopio> I can probably workaround the deprecation. But it's not even an error, is just a message logged on the warning level.
<fginther> elopio, it's questionable if phablet-test-run should even be making that check still. Have all the autopilot tests moved to python3?
<elopio> fginther: no, not all.
<elopio> I was looking at the calendar yesterday and it's py2.
<fginther> elopio, rats
<ogra_> popey, want to join the meeting ?
<elopio> fginther: can we change phablet-test-run to check for the exit status of the import, instead of the size of the output?
<ogra_> Saviq, robru, i suppose someone can delete row 20 from the spreadsheet now ;)
<robru> ogra_, on it ;-)
<elopio> agh, there's a command saying that adb shell always returns 0 :/
<elopio> fginther: I suck at bash, but would something like this be better? http://paste.ubuntu.com/7602724/
<ogra_> robru, spreadsheet still says traincon-0 at the top ... FYI
<robru> ogra_, ah yeah, thanks
<camako> robru, standing by for mir landing in case you need anything from me... Just to reiterate that it's been tested comprehensively by the team and it's good to go...
<robru> camako, excellent thank you, I'm just writing an email then I'll look at that
<robru> camako, alright, I hit publish. it looks ok on my end but i'm not sure, it might get caught up on this whole 1.2.0 / 2.0.0 issue with platform-api, we'll have to keep an eye on at
<robru> that
<camako> robru, excellent.. sure I'll keep a watchful eye...  thanks.
<robru> camako, https://launchpad.net/ubuntu/+source/platform-api this would be a good place to watch, shortly there'll be two versions listed under utopic, (one in release and one in proposed)
<camako> robru, ack
<robru> camako, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html also this page can tell us if there's any problems. it won't be in there just yet, but if platform-api hits a snag it'll get listed in there eventually
<robru> thanks
<robru> camako, (I also have my eye on those, but if you happen to notice something odd feel free to ping me)
<camako> robru, sure.. will do
<camako> robru, do you have a feel for how long publish would take?
<robru> Saviq, hey, I see your unity8 landing in silo 14, i'll publish it today but I'd rather not land unity8 and mir in the same image, so I gotta wait for this mir landing, then kick an image build, then land your silo
<robru> camako, usually it gets into proposed within ~20 minutes or so, and then how long it stays in proposed depends on how many tests have to get run... for mir I think it takes a couple hours
<fginther> elopio, sorry I was fooding. Looking at your suggestion
<elopio> fginther: that one doesn't work, because adb shell is affecting the $? somehow
<elopio> http://paste.ubuntu.com/7602888/
<elopio> I'm not sure how to test this.
<fginther> elopio, maybe we can do a grep on "ImportError", the deprecation message doesn't emit that
<elopio> fginther: yes, that's what I was aiming at.
<fginther> elopio, just curious, how would we fix the deprecation warning in the address-book tests?
<fginther> elopio, a fix to phablet tools would have to make it through the citrain
<elopio> fginther: I haven't been able to work it around on the address book. I think we would have to remove the deprecation warning on the toolkit, and it will also have to go through the train.
<elopio> mmm, wait, maybe if I set the warning log.
<elopio> fginther: http://paste.ubuntu.com/7602962/
<elopio> the it will not go to std
<fginther> elopio, that appears to do it
<fginther> elopio, I still think the fix is to update phablet tools to either do a better import check or to skip it, but it helps to have a short term fix as well
<elopio> fginther: renato: I'll propose the workaround to the address book
<elopio> fginther: will you propose the fix to phablet tools?
<renato> elopio, thanks
<elopio> also, some other applications might start being affected by this, so it would be nice if we get it into ci-train quickly.
<fginther> elopio, yes, I'll do that
<elopio> thanks fginther
<elopio> and finally, I think I have a bug on the toolkit, because the deprecation message will appear even if we are not importing anything from the old namespace :/
<elopio> fginther: I reported the bug to link it on the workaround
<elopio> https://bugs.launchpad.net/ubuntu/+source/phablet-tools/+bug/1327325
<ubot5> Ubuntu bug 1327325 in phablet-tools (Ubuntu) "phablet-test-run will fail if the python3 import prints something to std" [High,Confirmed]
<fginther> elopio, much thanks
<fginther> elopio, I just pushed a fix for the generic-deb-autopilot-runner-mako bug I mentioned earlier
<elopio> fginther: nice, thanks.
<fginther> elopio, will keep an eye on it to make sure it continues to work after address-book-app has a new release
<elopio> fginther: I didn't understand all the details of that one, but I have seen a couple more times where we test the wrong version because of various reasons.
<elopio> It would be nice to make sure that the smoke runs with the right versions.
<elopio> maybe we can somehow set manually the version we expect on the phone, and add tests that verify it.
<fginther> elopio, indeed, that is *VERY* important
<elopio> it could be tedious, but I would feel safer.
<elopio> renato: please give this a try: https://code.launchpad.net/~elopio/address-book-app/workaround1327325-warning_to_file/+merge/222377
<elopio> well, actually, your failure was on the jenkins-mako. I think we just need to wait.
<elopio> oh, wait, you have staging.
<elopio> https://code.launchpad.net/~elopio/address-book-app/workaround1327325-warning_to_file/+merge/222378
<renato> elopio, could you change the MR target to staging branch, please?
<elopio> renato: I've just updated it ^
<renato> thanks
<robru> camako, ok, we had a hiccup, but platform-api is now in -proposed ;-)
<fginther> elopio, https://code.launchpad.net/~fginther/phablet-tools/fix-ptr-python3-import-check/+merge/222391
<fginther> xnox, could you lend a review to this as well? https://code.launchpad.net/~fginther/phablet-tools/fix-ptr-python3-import-check/+merge/222391
<xnox> fginther: hm, that looks weird, that's not the code i used to have there. let me look at the history.
<fginther> xnox, thanks for reviewing
<xnox> fginther: yeah, the check is definately bogus, now that you point it out
<fginther> xnox, I had hoped to remove it completely, but alas I found 1 project that is still falling back to python 2
<xnox> fginther: haha, there is more than one, deb based ones, no?!
<fginther> xnox, the one I found was mediaplayer-app, still deb based
<xnox> fginther: all good. Approve.
<fginther> xnox, thanks!
<robru> ricmm, looks like we're on the verge of having success with this platform-api landing (1.2.0 is in -proposed and is just about to hit the release pocket). so in silo 7 you'll soon need to rebuild platform-api and unity-mir. let me know if you need any help with it
<robru> I'm off for lunch but I'll be back!
* cprov changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cprov | CI Train Status: TRAINCON-0 | CI Train Support: US: robru, rsalveti - EU: sil2100, Mirv | Known issues: -
<Saviq> robru, if around, could you please publish silo 014? it's been ACKed for a few hours now
<robru> Saviq, yeah, i'll do it today, just waiting on an image build
<robru> which reminds me
<robru> slangasek, can you kick an image build please? thx ;-)
<Saviq> robru, ah ok thanks
<robru> ogra_, cyphermox, rsalveti: anybody around? I need an image build kicked
<robru> Saviq, you're welcome!
<cyphermox> sure
<cyphermox> robru: done
<robru> sweeeeeet
<robru> thx
<imgbot> === trainguard: IMAGE 72 building (started: 20140606 20:35) ===
* cprov changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train Status: TRAINCON-0 | CI Train Support: US: robru, rsalveti - EU: sil2100, Mirv | Known issues: -
<cyphermox> robru: we still traincon-0?
<robru> cyphermox, somebody isn't reading the landing mails ;-)
<cyphermox> actually, I'm just reading the topic right now ;)
<robru> bah, ten million places to change the status
<cyphermox> yeah
<cyphermox> cprov: could you remove traincon-0 and just write normal landings?
* robru changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train Status: #71 promoted | CI Train Support: US: robru, rsalveti - EU: sil2100, Mirv | Known issues: -
<robru> i got it
<cyphermox> ah ok
<cyphermox> I'm always expecting this to be chanserv's domain
<cyphermox> going hiking tomorrow, I can't wait
<robru> sweet, big hike? i'm going for a short one on sunday
<cyphermox> not that big
<cyphermox> just mucking around at Montmorency Park near Quebec
<cyphermox> http://en.wikipedia.org/wiki/Montmorency_Falls
<cyphermox> maybe I can convince my gf to walk on the suspension bridge above the falls ;D
<robru> sweeet!
<robru> i love suspension bridges
<cyphermox> I love the fact it means I can go gear shopping tonight :)
<robru> haha, awesome. i got some new hiking poles recently, some outdoorsy store closed down and cleared out their inventory
<cyphermox> lucky
<robru> not lucky for them!
<cyphermox> I know Catou would like some, but it's too expensive... 100$+ for poles :(
<robru> cyphermox, oh dude, what are you buying them, NASA? the ones I bought were regular $40 but on sale for $15
<cyphermox> I didn't see any where I usually go
<cyphermox> I'll just pick up some suitably-straight dead branches on the way
<cprov> cyphermox: sorry, missed your msg
<cyphermox> cprov: no worries, robru took care of it
<cyphermox> thanks!
<cprov> cyphermox: anytime. Have a nice weekend!
<cyphermox> you too
<cprov> thx
<imgbot> === trainguard: IMAGE 72 DONE (finished: 20140606 21:55) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/72.changes ===
<robru> woop woop!
<popey> ooh
 * popey stabs "check for updates"
<ricmm> robru: theres more to it than a rebuild, I'll work on it monday
<ricmm> im glad that silo 7 got unblocked tho
<ricmm> thank you
<bregma> robru, it looks like the choo choo is being moody again
<robru> ricmm, you're welcome
<robru> bregma, how so?
<robru> oh, the bot you mean?
#ubuntu-ci-eng 2014-06-07
<imgbot> === trainguard: IMAGE 73 building (started: 20140607 02:10) ===
#ubuntu-ci-eng 2014-06-08
<imgbot> === trainguard: IMAGE 74 building (started: 20140608 02:10) ===
<imgbot> === trainguard: IMAGE 74 DONE (finished: 20140608 03:30) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/74.changes ===
#ubuntu-ci-eng 2015-06-01
<abeato> trainguards ^^ :)
<pstolowski> cihelp hi, i need help with the failure in silo 40. seems like it's not happy about symbols changes, but only on powerpc; it passes elsewhere. e.g. http://pastebin.ubuntu.com/11491341/
<sil2100> mandel: ping, any news on the location silo?
<seb128> hey sil2100
<sil2100> seb128: hey
<seb128> sil2100, location is known to be not slow/not accurate on vivid images?
<seb128> I updated my bq on friday and I've been having issues with that this w.e
<sil2100> seb128: yeah, there are issues with location on vivid images right now, not sure how bad it is on krillin but on arale it doesn't work at all even
<sil2100> But mandel is on it
<seb128> it's not good on vivid
<seb128> it took me more than a day to get a position, and I was outside with working 3g
<seb128> and today I've a position (being inside on wifi) but the it's within a 10km circle
<abeato> sil2100, could I have a silo for line 61?
<sil2100> abeato: on it, looking
<sil2100> abeato: do you have separate trunks for vivid and wily? Or do you land the same thing for both distros always?
<abeato> sil2100, that's the plan, however there is currently a bug in the golang toolchain in wily (for powerPC), so I won't ask for a wily silo for the moment
<sil2100> hmm, so it won't build on wily?
<abeato> sil2100, in fact there is a pending silo in wily for a previous nuntium landing (line 39)
<abeato> sil2100, right, see bug #1454183
<ubot5> bug 1454183 in gcc-5 (Ubuntu) "gccgo crash on powerpc" [High,Confirmed] https://launchpad.net/bugs/1454183
<sil2100> Ok then
<sil2100> Makes sense, ok, assigning silo
<abeato> great, thanks
<sil2100> Just wanted to make sure a dual-landing isn't a better choice here
<abeato> sure, in fact it would be if we did not have that issue :)
<sil2100> abeato: silo 19 for you :)
<abeato> :)
<sil2100> jibel: re your e-mail - agreed, no need to waste time waiting for a decision/fix for the location bits
<sil2100> jibel: I poked mandel already but I guess he's not up yet
<mandel> sil2100, I am!!!
<mandel> jibel, sil2100 building a deb to test and update the ppa
<mandel> jibel, sil2100 did the fix over the weekend but did not test it
<sil2100> mandel: is it in a silo?
<mandel> sil2100, pushing the changes to silo 05
<sil2100> jibel: is the trello bot working? Since I don't see it creating cards for the new click/tarballs I approved today
<sil2100> jibel: ah, wait
<sil2100> jibel: nvm that
<mandel> jibel, silo 5 is rebuilding for you to take it for another sping
<mandel> spin*
<sil2100> jibel, davmor2_hols, ogra_: meeting!
<ogra_> if google would let me :P
<sil2100> Uh oh
<Mirv> sil2100: I'm in london, maybe I'll check your faces but can't attend :)
<sil2100> Mirv: ah! Sprinting :)
<popey> tumbleweed meeting
<sil2100> No cats...
 * ogra_ sighs ...
<Mirv> sorry :(
<popey> ok
<sil2100> No worries ;)
<popey> sil2100: so what did you want to discuss about Clock / Calendar / Calculator / Cweather *   (* Delete as applicable)
<sil2100> jibel: so, I was wondering, popey had a request for a new clock-app, do you guys know if this could land for this milestone?
<sil2100> popey: I hope it doesn't have any new icons though?
<jibel> sil2100, it is a question for Pat
<popey> yes, there is a new icon sil2100
<popey> (which seems reasonable, given I note other apps are landing theirs)
<popey> (system settings new icon is already in the image)
<popey> (on krillin)
<sil2100> huh
<sil2100> Ok, we really need Pat for this one ;)
<popey> sure, i can wait
<popey> I mean, once it's tested, we can land in the store when we please
<popey> the key thing is the testing bit ã
 * mandel reboots
<jibel> popey, understood, we have 1 sick and 2 on holidays today, so priority is on critical fixes and if we have room, we'll review the apps
<popey> sure sure :)
<popey> no pressure from me:)
<jibel> thanks :)
<seb128> sil2100, on my bq/vivid, the messaging indicator envelop doesn't turn blue anymore on received msg, do you know if that's a known issue/what component to blame? telephony-service?
<sil2100> seb128: not sure if it's not intentional, I mean, I remember someone saying that the icons (besides the power icon) will be monochrome only from now on
<sil2100> But I might be misunderstanding
<seb128> sil2100, so you don't have any indication you received a message now?
<sil2100> I think it should look different then - jibel do you know what was the deal with monochrome indicator icons?
<jibel> seb128, on vivid it turns white (or lighter grey) when you receive a notification
<jibel> it's dark grey otherwise
<jibel> and it is intentional
<seb128> jibel, it's so subtle that I didn't notice the change of color
<seb128> jibel, do you know if there is a bug report about the design change/if there was discussions/feedback on how well the monochrome is working
<jibel> seb128, I don't remember any bug report or discussion on a ML
<seb128> jibel, thanks, maybe I'm going to start one ;-)
<sil2100> +1 ;)
<oSoMoN> trainguards: what can I do to solve the build error in silo 1 ? would it make sense to re-target the landing to wily only? given that the gates are closed for vivid-overlay, I guess this makes sense
<seb128> sil2100, jibel, that's reported as https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1450894
<ubot5> Launchpad bug 1450894 in Ubuntu UX "[Indicators] Messaging indicator does not indicate that there is a new message" [Medium,Triaged]
<sil2100> oSoMoN: let me take a look
<ogra_> mandel, your change wont prevent the job from running on every boot
<jibel> mandel, ogra_ is right, the file event is trigger on every boot even if the file already exists
<jibel> mandel, also you start ubuntu-location-provider-here-slpgwd twice, second call will exit 1 and location-service will never start
<sil2100> oSoMoN: hm
<sil2100> oSoMoN: no retargeting is needed, we can simply only publish the wily parts of the landing in this case
<sil2100> oSoMoN: but still, you'd either need to re-include the missing version or force-build the silo
<mandel> jibel, did I, shit, sorry
<mandel> ogra_, hmm.. that was from loic, let me change that
<ogra_> mandel, just drop all the nonsense from the "start on" line ... only keep the file creation check
<mandel> ogra_, true, since the create event is just fired in a create no if it is present, right?
<mandel> jibel, sorry for the double start, I missed that
<mandel> ogra_, jibel looks better => https://code.launchpad.net/~mandel/ubuntu-location-provider-here/move-to-vivid/+merge/257910
<oSoMoN> sil2100, right, but if later on I want to land further changes, Iâll still have a vivid silo hanging around, so re-targetting and landing only in wily for now is probably better
<oSoMoN> given that we donât really know when the vivid-overlay freeze will be overâ¦
<oSoMoN> sil2100, can you do the re-targetting for me, please?
<jibel> mandel, I tried that and the file event was emitted on every boot
<mandel> jibel, really, that should not happen => http://upstart.ubuntu.com/cookbook/#upstart-file-bridge
<jibel> mandel, I know but double-check on a device.
<mandel> jibel, fun fun... I'll do a double check in the device, if that is the case.. fu** to upstart
<jibel> mandel, I tried on rc-proposed/meizu.en/arale 9
<jibel> mandel, and there is no reason that adding extra 'and' clauses would make it start on every boot if it doesn't with only the file event.
<mandel> jibel, true, the anyway those starts where not needed
<mandel> s/the/but
<sil2100> oSoMoN: let me check how the reconfigure will work, since normally changing series is not possible without wiping and re-assigning the silo
<oSoMoN> sil2100, ok, if itâs not possible then I guess we can ahead with the dual silo and then once it lands in wily we just free it
<mandel> jibel, you are right, that file call is execute everyboot time, either the docs lie or the file is create in each boot (something I hope that does not happen)
<ogra_> mandel, did you get my last lines before the reconnect ?
<mandel> ogra_, no, I did not
<ogra_> <ogra_> mandel, just drop all the nonsense from the "start on" line ... only keep the file creation check
<ogra_> <ogra_> also, make it a task (by adding the "task" keyword) dand drop the "stop on"
<ogra_> <ogra_> s/dand/and
<ogra_> <ogra_> and then just keep the old script but shield the "start ubuntu-location-provider-here-slpgwd" with "|| true"
<mandel> ogra_, what do you mean with "shield" the script?
<ogra_> apped || true to that line
<ogra_> so it doesnt stop execution of the job if it returns non-zero
<ogra_> (probably add a sleep if you want to give it some time to start)
<mandel> ogra_, ok
<sil2100> oSoMoN: I didn't want to reconfigure as dual-landing silos are basically wily silos already
<sil2100> oSoMoN: for instance, if you don't want to land for vivid, all you need to do is ask a trainguard to remove the vivid binary packages
<sil2100> From the silo
<sil2100> oSoMoN: so I would say - just force-build the silo (or include the missing changelog entries) and give me a sign to remove the vivid package
<oSoMoN> sil2100, ok, will do
<Laney> how come oxide-qt has a "passed" boottest?
<Laney> https://jenkins.qa.ubuntu.com/job/wily-boottest-oxide-qt/ http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#oxide-qt
<joc_> could anyone give me a hint as to how to get the citrain tool working to install silos on a vivid+overlay device?
<sil2100> joc_: what series are you running on your local PC?
<joc_> currently running something like "citrain device-upgrade 019 XXXX ubuntu" results in the PPA being added but nothing uprgraded
<joc_> sil2100: vivid
<joc_> the phablet-tools-citrain package is whatever is in universe I think
<sil2100> joc_: yeah, it needs a newer version of the tools, as we're using Pin Priorities now
<sil2100> I see Mirv's phablet-tools didn't yet land in the overlay...
<sil2100> Anyway
<sil2100> joc_: use the phablet-tools from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-028
<joc_> sil2100: ah thanks, i didnt know about that ppa
<sil2100> joc_: well, it's an unofficial place but the final idea is to have the right phablet-tools in the overlay-PPA
<Mirv> sil2100: oh... thanks for reminding :) there was that "let's wait if ji_bel has something to say"
<sil2100> But it didn't land yet
<Mirv> but actually it was alright
<sil2100> Mirv: aaah
<sil2100> Right, I'm pretty sure jibel won't have anything against it
<sil2100> :)
 * Mirv landing
<sil2100> jibel: right?
<sil2100> Mirv: thanks!
<joc_> sil2100: so i should have the overlay ppa enabled on my host pc?
<Mirv> sil2100: mm, what now? https://ci-train.ubuntu.com/job/ubuntu-landing-028-2-publish/36/console
<sil2100> o_O
<Mirv> sil2100: wow, it even landed (binary copy just happened)..
<Mirv> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?batch=75&memo=75&start=75 - the first one
<Mirv> O_o
<sil2100> joc_: yeah, I think it should be safe to have that enabled, it mostly has phone-stuff anyway - or at least installing phablet-tools from that and then disabling it
<jibel> sil2100, why to the overlay ppa rather than a standard SRU? it's an host package and the fix sounds reasonable for SRU, while it's unlikely that people will have the overlay unable on their desktop
<jibel> s/unable/enabled/
<sil2100> Yeah, it might be SRUed indeed
<pstolowski> anyone from cihelp there?
<jibel> sil2100, IMO stable-phone-overlay should contain only phone specific packages that cannot and don't want to be SRUed
<sil2100> jibel: the idea of the stable-phone-overlay is also to include those things that we want to SRU but are urgent enough that we don't want to wait through the whole SRU process
<ogra_> we should remove the phablet-tools package from universe
<sil2100> But I agree, it's best if we don't include non-touch packages there
<ogra_> there is no way to keep it up to date across all release3s without a ton of paperwork
<ogra_> people *need* to use the pahblet-tools PPA anyway
<ogra_> there is no way around that ... so having the package in universe is moot
<sil2100> ...or that, well, I don't follow phablet-tools development closely
 * ogra_ neither anymore :)
<Mirv> there's no such thing as phablet-tools development, just random commits when someone needs something
<Mirv> I mean, no-one owns it
<popey> so with that few commits, putting it in the archive should not be that much overhead
<popey> just needs someone to manage the release
<popey> "just"
<brendand_> Mirv, which is crazy
<sil2100> ;p
<sil2100> brb, lunch
 * ogra_ curses
<fginther> pstolowski, hello, what's the problem?
<pstolowski> fginther, hi! silo 40 is failing on powerpc only indicating problems with symbols. e.g. http://pastebin.ubuntu.com/11491341/
<fginther> pstolowski, oh, as this is a silo related issue, I'll direct this to trainguards
<pstolowski> fginther, which is weird, since it passes on other architectures. it seems to be expecting -0ubuntu1 now (which we have in the changelog), but why only powerpc. and it was fine before?
<pstolowski> fginther, ah, fair enough, thanks
<pstolowski> trainguards ^ ideas?
<sil2100> pmcgowan: hey
<sil2100> pstolowski: let me take a look in a minute
<sil2100> pstolowski: hmmm
<pstolowski> sil2100, sure, thanks
<sil2100> pstolowski: damn, this might be a bit troublesome
<pstolowski> sil2100, anything changed recently? why only powerpc?
<sil2100> It's indeed interesting why it only happens on powerpc, let me dig deeper
<sil2100> pstolowski: actually this might be a red herring
<sil2100> pstolowski: I think the actual problem might be the newly added symbols that are visible above, for instance as seen in this willy build
<sil2100> https://launchpadlibrarian.net/207774287/buildlog_ubuntu-wily-powerpc.unity-scopes-shell_0.5.4%2B15.10.20150529.2-0ubuntu1_BUILDING.txt.gz
<sil2100> Somehow those are now visible on powerpc
<pstolowski> sil2100, weird. i've just checked the 1st symbol, it should be covered by this: http://pastebin.ubuntu.com/11497617/
<pstolowski> sil2100, yeah, these symbols are not new
<sil2100> Interesting stuff, hm, looking a bit more
<pstolowski> sil2100, they are covered by  (c++|arch=!amd64 !arm64 !ppc64el) rule
<pmcgowan> sil2100, hey
<sil2100> pmcgowan: I heard from popey that people already started landing the new icons while we still didn't finish arale
<sil2100> Something about system settings having the new one already
<sil2100> Is that coordinated?
<pmcgowan> nothing landed to vivid afaik, but could be going to the store for core apps
<sil2100> Maybe it slipped in with one of the fixes or something?
<popey> pmcgowan: http://people.canonical.com/~alan/screenshots/device-2015-06-01-150711.png
<popey> thats my krillin
<sil2100> Looks like the new icon to me
<sil2100> popey: you're running vivid, right?
<popey> ah, my krillin is ubuntu-touch/devel-proposed/ubuntu 227 - is that wily?
<ubot5> Ubuntu bug 227 in Baz (deprecated) "baz branch doesn't rollback on bad gpg signature" [Medium,Invalid] https://launchpad.net/bugs/227
<sil2100> popey: yeah, that's wily
<popey> Codename:       wily
<popey> yeah
<popey> ignore me then
<sil2100> pmcgowan: ...ok, ignore that question ;)
<pmcgowan> wily
<pmcgowan> yeah
<ogra_> popey, dont run wily ... it will likely break in interesting ways :)
<pmcgowan> popey, btw i like the old one better
<popey> pmcgowan: me too
<popey> ogra_: what channel should I be on, on krillin?
<pmcgowan> jibel, so whats the deal with silo 5, just busted?
<ogra_> popey, one of the rc ones ...
<jibel> pmcgowan, in it's current state, yes.
<jibel> mandel|lunch, ^ what's the status on 5?
<sil2100> jibel: for the krillin OTA-4 we'll also need the new device tarball from john-mcaleely, rvr is on it?
<jibel> sil2100, it's done
<sil2100> \o/
<jibel> sil2100, almost, 2 MMS tests left
<jibel> sil2100, actually MMS tests fail
<jibel> rvr, does it work without the device tarball?
<rvr> Well, but MMS didn't work for me in the past, so...
<john-mcaleely> ha. mms is not news :-)
<ogra_> send postcards ... cheaper anyway
<rvr> lol
<john-mcaleely> email. always been a better choice
<popey> ogra_: ubuntu-touch/rc/ubuntu-developer ?
<popey> ogra_: is there one that has the here stuff?
<ogra_> popey, http://system-image.ubuntu.com/ubuntu-touch/rc-proposed/bq-aquaris.en/
* ogra_ changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train supthats the latest vivid+overlayport? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: The world (librarian) is burning. Run!
<ogra_> err
* ogra_ changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: The world (librarian) is burning. Run!
<popey> hah
<ogra_> thats the latest vivid+overly
<ogra_> and http://system-image.ubuntu.com/ubuntu-touch/rc-proposed/meizu.en/ is the same thing for arale
<popey> ta
<sil2100> https://developer.ubuntu.com/en/start/ubuntu-for-devices/image-channels/ has stuff explained
<sil2100> Might need to include additional info inside
<jibel> sil2100, john-mcaleely device_krillin-20150529-8e13c5f is ok. MMS can be sent but not received. It is not related to the tarball.
<sil2100> john-mcaleely: you're free to publish :)
<jibel> om26er, you tested the custom tarball for krillin last Friday right?
<john-mcaleely> sil2100, will do so shortly (otp)
<rvr> bfiller: https://bugs.launchpad.net/ubuntu/+source/messaging-app/+bug/1460664
<ubot5> Launchpad bug 1460664 in messaging-app (Ubuntu) "Delete wizard is not translated" [Undecided,New]
<rvr> Hmm
<rvr> The strings are in es.po indeed
<om26er> jibel, yes, I did.
<om26er> (IRC was disconnected and I didn't know)
* cjwatson changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues:
<cjwatson> (librarian is working)
<sil2100> cjwatson: thanks, yeah, we missed changing that on Friday
<boiko> trainguards: I got an exception on silo 16, will a rebuild fix it or does it need anything else to work?
<sil2100> boiko: hey!
<alex-abreu> trainguards can you reconfigure silo 2?
<sil2100> boiko: no, it won't be that easy... it seems you released address-book-app for wily already from the selected trunk
<sil2100> boiko: so this trunk should be either only used for dual-landings or only for wily landings
<sil2100> boiko: you should either release to wily and sync back to vivid, or use dual-landings or create a separate trunk for vivid
<sil2100> alex-abreu: on it
<boiko> sil2100: ok, let me check with bfiller what to do now
<sil2100> pstolowski: ok, I'll be back to trying to figure out what happened in a moment, got distracted
<boiko> sil2100: thanks!
<sil2100> boiko: yw! It's just that the selected trunk needs to always be used only to release for a selected focus, so either you target stable or you target devel :)
<sil2100> Since otherwise there wouldn't be any useful history in bzr
<sil2100> alex-abreu: done
<alex-abreu> sil2100, thx
<bfiller> sil2100: can we dual land now? that is what we want but vivid overlay frozen, correct>?
<sil2100> bfiller: yeah, it's still frozen... so we propose just releasing to wily for now and then syncing it back
<bfiller> sil2100: ack, boiko lets do that ^^
<boiko> bfiller: that might be the best thing to do
<sil2100> bfiller: dual-landings can also be used for only landing to wily, but it's best to just get a wily silo as it's less manual work for everyone
<boiko> sil2100: should I change the spreadsheet, or can you configure it internally?
<sil2100> boiko: I'll have to re-assign the silo in this case
<boiko> sil2100: that's fine
<sil2100> boiko: ok, on it :)
<boiko> sil2100: thanks!
<sil2100> boiko: done, silo 016 again, just remember there's a wily silo with dialer-app already in 004 (shell rotation)
<boiko> sil2100: ok
<sil2100> pstolowski: hah!
<sil2100> I think I found it
<sil2100> pstolowski: you still around?
<sil2100> Let's go pm on  this
<pstolowski> sil2100, yes
<john-mcaleely> sil2100, still a good time to publish the approved vivid tarballs?
<sil2100> john-mcaleely: yes :)
<john-mcaleely> ok, let me do that then
<john-mcaleely> sil2100, done. krillin & vegetahd pushed
<john-mcaleely> thank you
<sil2100> \o/
<sil2100> Thanks :)
<jibel> rvr, om26er did you sign off silo 5?
<sil2100> Doesn't it need some more tweaking?
<jibel> sil2100, no one from QA signed it off AFAIK
<sil2100> I wonder why it's marked as such then
<om26er> rvr, I didn't. rvr though it was not needed anymore ?
<sil2100> om26er, jibel, rvr: I switched it back to untested
<om26er> s/not needed/no a blocker.
<sil2100> om26er: it's still a blocker, but the silo was b0rken
<jibel> sil2100, pmcgowan silo 5 is still bad
<rvr> jibel: I didn't test any silo today
<pmcgowan> jibel, silo 5 worked for me - installed the debs, reboot, turn on wizard, reboot, run through wizard, open Here app and got a fix
<pmcgowan> om26er, ^^
<pmcgowan> if thats the correct method
<ogra_> pmcgowan, you need to remove /home/phablet/.config/ubuntu-system-settings/wizard-has-run before rebooting (note the wizard will come up as soon as the file is gone, but reboot anyway)
<ogra_> if you leave the file in place you dont actually test the issue
<pmcgowan> ogra_, I used phablet-config which I thought did that
<popey> balloons: any more news on the migration to vivid in jenkins?
<balloons> popey, nope..
<bfiller> robru: can you publish silo 21 please?
<robru> bfiller: sure, but need merges approved first: https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/61/console
<bfiller> robru: let me do that
#ubuntu-ci-eng 2015-06-02
<slangasek> robru: can you tell me why the changelog of https://launchpadlibrarian.net/207198066/autopilot_1.5.1%2B15.04.20150522-0ubuntu1_source.changes is such a mess? (https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-018/+packages)
<robru> slangasek: checking
<robru> slangasek: oh yeah, that's because qa team pre-merges their MPs into one big MP and then doesn't make their own changelog.
<robru> slangasek: changelog genertaion has always been "find all commit authors, then make entries based on MP commit message"
<slangasek> robru: and every commit on that branch had the exact same commit message?
<robru> slangasek: so with QA there's just one commit message (just one MP) but many many authors
<robru> slangasek: no it uses the commit message defined by the MP, not every single commit message of every single commit.
<slangasek> robru: ok so in that case I think the train needs to be more sensible and either consolidate or omit the author list
<robru> slangasek: but it grabs the authors of every single commit in order to give everybody attribution
<robru> slangasek: this has come up before and I told qa to make their own changelogs in this case because the train is geared towards handling multiple MPs, it's not really geared for mega-MPs like this
<slangasek> robru: perhaps that would be better, but as the train is not enforcing such a policy, it should still generate reasonable changelogs for a merge that it's allowing
<slangasek> robru: https://bugs.launchpad.net/cupstream2distro/ the right place to file?
<robru> slangasek:
<robru> slangasek: yeah
<robru> slangasek: you can specifically reference update_changelog in packagemanager.py
<robru> slangasek: it literally just has a for loop and calls dch once for each author
<slangasek> robru: bug #1460861
<ubot5> bug 1460861 in CI Train [cu2d] "changelog entry for MP with multiple authors should summarize as [ author1, author2 [, ...] ], not repeat changelog for each author" [Undecided,New] https://launchpad.net/bugs/1460861
<robru> slangasek: ok thanks
<slangasek> robru: now if I manually fix this changelog and reupload, will the train be unhappy later?
<slangasek> (reupload to the archive)
<robru> slangasek: is the silo published already
<robru> ?
<robru> slangasek: oh it's in unapproved
<slangasek> correct
<robru> slangasek: not sure what you're proposing.
<robru> slangasek: no matter what you do it'll screw the train one way or another.
<slangasek> robru: I'm rejecting this upload, fixing the changelog to be reasonable for an SRU, reupload, and accept
<slangasek> why?
<robru> slangasek: the train won't be able to track the migration if the version doesn't match
<robru> slangasek: or can you keep the version the same?
<slangasek> robru: the version would be the same, it's only the changelog text that needs fixing
<robru> slangasek: when the silo migrates, what will be merged to trunk week be the current version
<robru> slangasek: if you send me your version of the changelog file, i can commit it in the train though, with some manual wrangling.
<sil2100> Phew...
<jibel> sil2100, starting a day with 'phew' is rarely a good sign :)
<seb128> hey sil2100
<sil2100> Yeah, great way to start the day
<sil2100> seb128: hey!
<jibel> sil2100, can you kick a build of vivid arale and krillin? we need the last location fix
<jibel> and verify that it works on the image
<sil2100> Sure, it landed yesterday?
<jibel> sil2100, yes, finally
<sil2100> On it now
<sil2100> Should be building now
<jibel> thanks
<alf_> cihelp: Hi! Could you please add a new test ('mir_privileged_tests') to the test runs by the mir-mediumtests-runner-mako job (in job parameter 'test_suite')?
<sil2100> imgbot, where are youuuu
<ogra_> sil2100, a little sick ... let me find his medicine ...
<ogra_> imgbot, stunt
 * imgbot rolls on its back and purrs
 * ogra_ cuddles imgbot 
<tvoss> imgbot, help
<imgbot> I am the firendly system-image watchbot !
<imgbot> I know the following commands:
<imgbot> help, stop, status, map, stunt
<imgbot> for questions please mail ogra@ubuntu.com
<tvoss> imgbot, status
<brendand> ogra_, don't you have a dog or something?
<ogra_> brendand, i used to, nowadays only cats
<john-mcaleely> can you tell people who get pinged by imgbot?
<brendand> ogra_, and imgbots :)
<ogra_> tvoss, you need an image number
<tvoss> ogra_, aha :)
<ogra_> tvoss, but since the channel switch thats not much useful anymore (numbers changed) ... and i havent finished the bot rewrite yet
<tvoss> ogra_, ah okay
<tvoss> ogra_, got link to source?
<ogra_> tvoss, nope, it uses a lot of my VPN and ssh keys to access the different machines (and is awful code too)  ... the rewrite will not need all this
<tvoss> ogra_, okay
<ogra_> (and will be public)
<mzanetti> sil2100, hey, can we change silo 4 to be a dual silo and start building it, so we can land it when vivid+overlay opens again?
<sil2100> mzanetti: let me take a look
<mzanetti> I just changed it in the spreadsheet
<sil2100> mzanetti: we could, but it would need to be reassigned... will you be ok with rebuilding the silo?
<mzanetti> sil2100, yes, needs rebuilding anyways
<sil2100> mzanetti: ok, let me reassign
<popey> cihelp: Why did jenkins not pick up this merge? https://code.launchpad.net/~vthompson/music-app/decode-before-ms2-lookup/+merge/260790
<popey> cihelp: Also, what progress of moving core apps builds from utopic to vivid please?
<sil2100> grrr
<sil2100> jibel: there'll be a spam of a few lost changes e-mails from yesterday... the mail sending service was not working since I messed up the cronjob
<sil2100> jibel: it will be working normally now
<jibel> sil2100, how long does it take to build an image when a rootfs is ready?
<ogra_> jibel, ~20-30min
<ogra_> we have more arches now though ... might be 1h nowadays
<sil2100> The importer needs to pick it up, usually 15-30 minutes
<ogra_> each new arch adds up
<sil2100> hm, never saw that to take 1h, but maybe indeed now it can be a bit longer
<ogra_> when we started it took max 10min
<ogra_> then snappy came around and it doubled up
<ogra_> now with more arches to import it will be longer again
<ogra_> snappy will fix that :)
<ogra_> (before it gets un-handleable)
 * popey adds "Snappy will fix that" to "shit canonical people say"
<sil2100> ;)
 * Mirv googled http://irclogs.ubuntu.com/2013/10/16/%23ubuntu-touch.html#t08:11
<sil2100> popey: you should make a list of 'shit canonical people say' that we can actually browse ;)
<popey> haha
<ogra_> jibel, do we have a bug open for nearby ? it seems to always have some weird location right after boot until i refresh
<jibel> ogra_, none that I know of
<ogra_> do you see that too ?
<ogra_> or is my house just shielding me better from location detection :)
<jibel> ogra_, yes, it shows Paris then my real location (400km away from Paris)
<ogra_> yeah, same here
<ogra_> (well, not paris indeed)
<ogra_> tvoss, couldnt we store the last location on reboot ?
<ogra_> and keep it until we have the proper fix
<tvoss> ogra_, the scopes infrastructure could do that. Right now, they likely hand out a geoip estimate until the first real location from the service arrives
<ogra_> yeah ...
<tvoss> ogra_, I'm not a fan of centrally caching that stuff as requirements differ significantly with applications
<ogra_> would be better than having the scopes wait with startup til it is there
<tvoss> ogra_, probably best to file a bug against scopes then
<jibel> ogra_, doesn't it keep some kind of cache already, because when you travel it remembers your previous place?
<ogra_> does it ?
<thostr_> sil2100: is there any estimate yet when dual landings will be possible again?
<sil2100> thostr_: if all goes well we should be good around Thursday
<thostr_> sil2100: can we 'freely' land then or are restricted soon again by ota?
<sil2100> I suppose the next OTA would be in approx a month
<thostr_> sil2100: ack
<sil2100> The original plan would be to do an RC promotion in 2 weeks, but not sure if we have te resources to keep doing that still
<thostr_> sil2100: right. thing is it gets more and more difficult to find landing times
<thostr_> as we usually be also very picky about changes shortly before ota's, even before officially closing those
<sil2100> Yeah, this time it was even worse as we closed early and keep the gates closed for long
<sil2100> But this is a special case
<sil2100> For known reasons
<thostr_> hopefully...
<thostr_> it felt like we closed for almost three weeks then altogether
<jibel> it will be 2 weeks next Friday
<pmcgowan> seb128, did this land in vivid https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1439122
<ubot5> Launchpad bug 1439122 in Canonical System Image "battery graph seems not properly initialized" [Medium,In progress]
<seb128> pmcgowan, no, I was looking at that this morning
<seb128> pmcgowan, so many bugfixes that are not landing because things are frozen :-/
<pmcgowan> seb128, ah ok
<seb128> pmcgowan, we can resume bugfixes landing after ota4 right?
<pmcgowan> yes
<pmcgowan> which should be tomorrow
<sil2100> Fingers crossed on that
<ogra_> huh ?
<ogra_> where does that update come from
<ogra_> oh, custom tarball
<sil2100> Which update?
<ogra_> the one my arale just offered me
<ogra_> r11
<cwayne> ogra_, CTR fix
<ogra_> cwayne, yeah
<ogra_> noticed that after asking :)
<cwayne> sil2100, ^ jibel gave me the go ahead to push it :)
<sil2100> cwayne: ok ;) Give me a sign beforehand :)
<cwayne> sil2100, sorry! literally just happened
<cwayne> like, 4 minutes ago, but point taken :)
<ogra_> the importer was really fast :)
<sil2100> :)
<boiko> sil2100: when you get some time, I need a silo for row 63, OTA4 targetted bugfix
<sil2100> boiko: on it
<boiko> sil2100: thanks! :)
<sil2100> boiko: thanks for the fix! :)
<sil2100> Last from the known list
<boiko> sil2100: took a while for me and salem_ to figure out what it was, but in the end salem_ fixed it
<pmcgowan> jibel, do you want to close the gates or take a fix or two?
<pmcgowan> boiko, sil2100 need QA to ack that one landing, not sure if we are out of time
<sil2100> pmcgowan: I think QA is anticipating this fix, yesterday the plan was to not do any telephony tests before this lands
<boiko> pmcgowan: well ,the fix is not yet reviewed/tested, and we are in the sprint planning meeting right now, so it will take at least a couple hours before it is ready for QA to test
<sil2100> Or at least move those tests to later
<boiko> pmcgowan: if it is really urgent I can talk to bfiller to skip part of the meeting to test this
<pmcgowan> boiko, if we intend to land it we need it sooner than later
<sil2100> pmcgowan, boiko: since this fix is important for OTA-4, maybe QA can help out with testing the fix?
<boiko> pmcgowan: ok, I will work on it
<boiko> sil2100: that'd be good
<sil2100> jibel: I don't want to waste your time, but maybe you guys could check out silo 17 and help out with testing it once it builds?
<sil2100> It's the dual-sim fix
<fginther> popey, jenkins skipped https://code.launchpad.net/~vthompson/music-app/decode-before-ms2-lookup/+merge/260790 because it has no preview-diff, which is weird. I've manually kicked it off for now.
<popey> fginther: thanks
<fginther> popey, Also looking into moving things to vivid, first making sure the vivid environment is working. Last time we tried this, we ran into multiple build failures
<popey> fginther: it's blocking two core apps now.
<fginther> well at least one error that was hitting a few different projects
<fginther> popey, which ones?
<popey> clock and music
<popey> (which are default on device)
<fginther> popey, ack
<sil2100> pmcgowan: it would be nice to get LP: #1425172 fixed one day too...
<ubot5> Launchpad bug 1425172 in network-manager (Ubuntu RTM) "Network indicator lists the non-exist AP (timeout for the AP to be removed is too big, ~6min)" [High,Confirmed] https://launchpad.net/bugs/1425172
<pmcgowan> sil2100, we dont have a fix there yet
<pstolowski> trainguards hi, can somebody take a look at this failure https://launchpadlibrarian.net/208083338/buildlog_ubuntu-vivid-amd64.unity8_8.02%2B15.04.20150602.1-0ubuntu1_BUILDING.txt.gz ? according to mzanetti this issue has recently been fixed and another unity8 silo builds fine; perhaps some builders have old packages?
<Mirv> pstolowski: that shouldn't be possible.. but which silo? the fact that the version number is mentioned means vivid overlay is enabled there alright.
<pstolowski> Mirv, silo 40
<Mirv> pstolowski: err, silo 5 you mean?
<Mirv> the silo is configured correctly, proposed + stable phone overlay
<Mirv> and yes there was a unity8 landing after the indicator-network upload
<Mirv> Wellark: can you too check https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-005/+packages ? both vivid-overlay + wily claim libconnectivity-qt1-dev : Depends: libconnectivity-qt1 (= 0.5.1+15.10.20150519-0ubuntu1) but it is not going to be installed
<pstolowski> Mirv, ah, sorry, yes 40
<Mirv> pstolowski: still not 40 ;)
<pstolowski> Mirv, eeek, 5 :)
<pstolowski> Mirv, ack, thanks, rebuilding
<Mirv> pstolowski: there was a problem related to indicator-network landing (merging connectivity-api into it) that Wellark knows about
<Mirv> but at least in case of vivid overlay it was supposed to be fixed and indeed there was a successful landing of unity8 already, so I don't know what's really going on
<jhodapp> Mirv or sil2100: can one of you publish silo 23 for me please?
<Mirv> jhodapp: sure
<jhodapp> Mirv, thanks
<Mirv> (wily, if anyone is alarmed ;)
<sil2100> Mirv: thanks! I'm in a meetong ;)
<john-mcaleely> plars, who looks after the krillins in ci testing these days?
<boiko> sil2100: pmcgowan: all my tests are OK on the silo, I am just rebuilding for one last fix I asked salem_ to include, and then I will approve the MP
 * boiko gets lunch while it builds
<pmcgowan> boiko, thanks
<pmcgowan> boiko, looks like we will land it tomorrow for krillin testing
<plars> john-mcaleely: ci team does
<john-mcaleely> plars, who's a good person to ping. I have a bug which they should be screaming about
<john-mcaleely> (but aren't)
<josepht> john-mcaleely: what's the bug?
<john-mcaleely> josepht, can you see: https://bugs.launchpad.net/barajas/+bug/1456225
<ubot5> Error: launchpad bug 1456225 not found
<john-mcaleely> all automated testing shoudl be failing on krillin
<john-mcaleely> is it?
<josepht> john-mcaleely: yes I can see it, I'll check on the krillin tests
<jhodapp> Mirv or sil2100, can I get a silo for line #66 please?
<plars> john-mcaleely: in general, ping cihelp if it's urgent or send to the ci mailing list, but I'm certainly interested
<plars> john-mcaleely: we don't actively monitor the test results themselves - the landing team does that though for image promotion decision
<Mirv> jhodapp: sure (I'm in London this week so thus here later than usual)
<jhodapp> Mirv, cool thanks
<john-mcaleely> plars, ack. It's just been a while since I knew who to talk to
<john-mcaleely> thanks
<jhodapp> slangasek, can you take a quick look at this MR since it fixes the bug you filed? https://code.launchpad.net/~phablet-team/qtubuntu-media/fix-1452340/+merge/260850
 * sil2100 drives back home, be back soonish
<jhodapp> thanks Mirv
<john-mcaleely> josepht, any news?
<josepht> john-mcaleely: I'm not seeing adb failures
<john-mcaleely> cool. where's the dashboard these days?
<boiko> pmcgowan: ok, so I can spend some more time testing it
<pstolowski> Mirv, the issue I experienced with unity8 build is a dependency cycle of indicator-network (a packaging error); can a fix for that land in vivid-overlay despite "freeze"?
<pstolowski> Mirv, nb, pete-woods has the fix
<Mirv> pstolowski: ok
<Mirv> pstolowski: if that nb was a "nevermind" with a typo, that is :)
<pstolowski> Mirv, no, it was nota bene ;)
<Mirv> pstolowski: ejsyrbrt!
<Mirv> right, google helps :)
<Mirv> pstolowski: sooo, I don't think it'd land before OTA4, but that might mean tomorrow/Thursday is ok
<Mirv> pstolowski: just because it's very critical hour at the moment so wasting time shouldn't be risked (in case something happens to go wrong)
<pstolowski> Mirv, fair enough, ack
<pstolowski> Mirv, ejsyrbrt? :D
<Mirv> pstolowski: typoing "whatever" by having hands typing one button too right. it happens to me sometimes, even though this time it was on purpose :)
<pstolowski> lol
<Mirv> jhodapp: the spreadsheet was a bit broken, magic field contents missing so it didn't show your silo until now (dashboard ok)
<Mirv> oh, you built the package already so it wasn't an issue
<jhodapp> Mirv, yeah, saw that the silo was ready in here...thanks
<Mirv> dbarth: could you check spreadsheet lines 13, 17, 33 and clarify status/needs of those
<pstolowski> trainguards may i ask for reconfig of silo 5 (new project added)?
<Mirv> pstolowski: doing
<Mirv> end-of-bluefin in 20 mins, after that sil2100 might be back or robru up
<robru> i'm here
<Mirv> \o/
<robru> Mirv: how's it going?
<slangasek> jhodapp: followed up on the MP, further change required
<jhodapp> slangasek, ok thanks
<Mirv> robru: tired, but good - the usual sprint things, too long evenings, very long days...
<Mirv> quite productive anyway
<Mirv> my 19th qtbase 5.5.0 beta build succeeded running tests on armhf (I started two weeks ago)
<Mirv> qt creator git is building
<Mirv> qt 5.4.1 compiler options juggling going slowwly forward
<Mirv> it's good
<jhodapp> slangasek, pushed an update to the MR per your comment
<balloons> ping cihelp
<fginther> balloons, are you asking about the core-apps to vivid request?
<balloons> fginther, I am. It's starting to get painful :-)
<fginther> balloons, This is in progress, it's slowed by the fact that there is no working vivid test environment at the moment, getting that running is a bit more work than usual.
<balloons> fginther, ack.. I just wanted to make sure someone was working it as I know vivid got shutoff due to difficulties, so I imagined it might not be easy to bring it back
<balloons> popey, ^^
<popey> :(
<balloons> popey, I know nik90 and ahayzen both are being a little impacted by this. But for anyone else, can you make sure they know :-)
<popey> ya
<popey> i mentioned this to fginther earlier today.
<jhodapp> slangasek, once you approve, I'll get that landed right away
<slangasek> jhodapp: I approved it in my latest comment; are you looking for me to top-approve it?  It's not my project so I assumed that wasn't appropriate
<jhodapp> slangasek, you can top approve it, that's fine
<jhodapp> slangasek, better than me top approving ;)
<slangasek> jhodapp: ok done!
<jhodapp> slangasek, thanks!
<jhodapp> robru, you around?
<jhodapp> robru, silo 20 is ready to publish
<robru> jhodapp: on it
<jhodapp> thanks
<robru> jhodapp: you're welcome
<oSoMoN> trainguards: can the vivid packages be deleted from silo 1? I want to land only in wily for now, will sync later when vivid-overlay re-opens
<robru> oSoMoN: sure thing
<robru> oSoMoN: ok deleted, you ready to publish too?
<dobey> trainguards: it looks like rows 26 and 32 in the spreadsheet are duplicates? i guess someone should delete row 26?
<oSoMoN> robru, in a minute
<robru> dobey: indeed, thanks for pointing that out
<oSoMoN> robru, alright, silo 1 can be published now
<dobey> robru: i think row 15 can be deleted too. those branches have landed in w already
<robru> dobey: thanks for checking
<dobey> robru: np, easier for me to find things when there aren't duplicates and outdated things listed :)
<boiko> pmcgowan: I have just finished testing silo 17 (with the default sim fix), ready for QA to pick it for testing
<jibel> om26er, ^ can you verify silo 17?
<om26er> jibel, seems blocked on the board
<jibel> om26er, it is not the same 17
<jibel> probably an obsolete card
<om26er> jibel, hmm, so its telepathy-ofono ?
<jibel> om26er, yes
<jibel> om26er, the card will be created on next run of the job
<jibel> om26er, I moved it to under testing
<jibel> ready for testing*
<om26er> jibel, great, thanks
<jibel> om26er, thanks
<jibel> om26er, what are the bug # for the 2 upgrade bugs you found?
<om26er> jibel, bug 1461138 bug 1461152
<ubot5> bug 1461138 in ubuntu-app-launch (Ubuntu) "Some click icons are appearing twice after upgrade to RC" [Undecided,New] https://launchpad.net/bugs/1461138
<ubot5> bug 1461152 in pulseaudio (Ubuntu) "Pulseaudio crashed on boot after upgrading to RC (OTA4)" [Undecided,New] https://launchpad.net/bugs/1461152
<oSoMoN> cihelp: it looks like webbrowser-appâs boottest results are still affected by the unity8 greeter bug (https://jenkins.qa.ubuntu.com/job/wily-boottest-webbrowser-app/lastBuild/console), is that known? and can the test be re-run please?
<josepht> oSoMoN_: it is indeed known, unfortunately.  I'll retrigger the build.
<oSoMoN_> josepht, thanks
<jhodapp> robru, media-hub seems to be stuck in the proposed pocket for silo 23
<robru> jhodapp: cihelp: another boottest failure, can somebody investigate and retry: https://jenkins.qa.ubuntu.com/job/wily-boottest-media-hub/9/console ? thanks
<jhodapp> thanks robru
<robru> jhodapp: you're welcome
<josepht> robru, jhodapp: looking now
<robru> josepht: thanks
<jhodapp> awesome
<jhodapp> robru, silo 35 is ready to publish
<robru> jhodapp: just need this top approved: https://code.launchpad.net/~phablet-team/qtubuntu-media/fix-1457972/+merge/260520
<jhodapp> robru, alright, good
<josepht> jhodapp, robru: the rebuild was successful for media-hub
<robru> josepht: thanks!
<jhodapp> josepht, so it should be out of the pocket shortly then?
<josepht> jhodapp: afaik, yes
<jhodapp> josepht, ok great thanks, I'll keep my eye on it to make sure it does
<dobey> trainguards: can i get a silo for row 57 please?
<robru> dobey: ok you got silo 1, note the conflict with silo 22.
<dobey> robru: yeah, it's fine to land this first though :)
<robru> dobey: no worries, as long as you're aware
<jhodapp> josepht, awesome, it landed thanks
<josepht> jhodapp: great!
#ubuntu-ci-eng 2015-06-03
<robru> oops, IRC issues, I'm back now, if anybody needs anything please ping me
<sil2100> jibel: hey! Are you guys looking at krillin now? Is all testing finished for arale already?
<sil2100> jibel: would be nice if we also had someone picking up silo 17, since Omer wasn't able to test it properly
<Laney> is any cihelp person here? I'd like it if you could investigate why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#adwaita-icon-theme says boottest is red when it is green on https://jenkins.qa.ubuntu.com/job/wily-boottest-adwaita-icon-theme/lastBuild/
<jibel> rvr, Hey, can you take silo 17, omer was unable to test it, his device has a broken slot
<rvr> jibel: Ok
<Mirv> (repeating from late yesterday evening) dbarth: could you check spreadsheet lines 13, 15, 30 and clarify status/needs of those
<Mirv> lines changed a bit since yesterday
<Mirv> dbarth_: ^ (in case highlight needs that "_" in there)
 * sil2100 off to prepare lunch
<dbarth_> Mirv: ah ok
<fginther> Laney, hello. In trying to fix the source package issues, we've accidentally broken the creation of the results file that is sent to britney. It shouldn't be too hard to fix, but it might take an hour or two
<Laney> fginther: oh right, is that what I pinged about?
<fginther> Laney, you pinged on https://jenkins.qa.ubuntu.com/job/wily-boottest-adwaita-icon-theme/lastBuild/ :-)
<Laney> yus
<Laney> probably is
<Laney> fginther: anyway, cool, thanks for working on this issue!
<cjwatson> kgunn: https://code.launchpad.net/~cjwatson/launchpad/bmp-show-diffstat/+merge/260921 - FYI since that was one of your stakeholder requests
<rvr> jibel: ping
<jibel> rvr, pong
<rvr> jibel: Test case requires first boot, I reset the phone instead. Not sure if that's enough warranty of the clean setup.
<rvr> Hmmmm... but I can try to reproduce the problem without the silo and with reset.
<jibel> rvr, it's the closest environment you can get without too much effort, otherwise, flash the device, go to fastboot, flash the recovery with adb enabled, go to recovery, install the package from recovery and reboot. But it is not worth it
<jibel> rvr, you need help with this silo or it is all good?
<jibel> this = 17
<rvr> jibel: Then the silo looks good
<rvr> boiko is not available
<pmcgowan> jibel, sil2100 how we doin
<sil2100> pmcgowan: rvr is testing silo 17 now, since Omer didn't have a device that would be good for testing it
<sil2100> I suppose krillin regression tests are in progress in overall
<pmcgowan> great so no arale blockers yet either sil2100
<sil2100> Yeah, the only blockers were the cut-the-rope thing that we already agreed on and location, which has been signed off - so it seems arale testing is done
<sil2100> I poked jibel and he said it's done
<pmcgowan> sil2100, jibel I want to get this cosmetic/usability fix in today as well https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1450894
<ubot5> Launchpad bug 1450894 in Canonical System Image "[Indicators] Messaging indicator does not indicate that there is a new message" [High,Confirmed]
<sil2100> Ah, the one that seb128 mentioned?
<sil2100> pmcgowan: ok, you want this for the krillin release though, right? Not arale?
<pmcgowan> yeah, got consensus with design
<pmcgowan> krillin only
<pmcgowan> well ota4+
<jibel> pmcgowan, works for me.
<bregma> trainguards, could I get a reconfigure run for line 48 (silo ubuntu/landing-021) please?
<sil2100> bregma: on it
<bregma> ta
<sil2100> bregma: reconfigured, yw
<dobey> cihelp: it seems https://jenkins.qa.ubuntu.com/job/wily-boottest-unity-scope-click/lastBuild/ finished about 14h ago, but http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says it is still in progress, so the package is still being held in proposed :-/
<Ursinha> dobey: hi :) we're working on the boottest issues this week, let me see if that has to do with the changes we've been making
<dobey> hmm, the private jenkins seems to be timing out or something though
<Ursinha> dobey: weird, I just accessed it
<Ursinha> dobey: are you connected to the vpn?
<dobey> i was, yes
<Ursinha> odd
<Ursinha> dobey: it might be related to "<fginther> In trying to fix the source package issues, we've accidentally broken the creation of the results file that is sent to britney. It shouldn't be too hard to fix, but it might take an hour or two"
<plars> Ursinha: dobey: I can get to it fine
<dobey> ah ok
<Ursinha> dobey: "test in progress" some times means britney (proposed-migration "brain") didn't understand the test was completed, so what fginther said there sounds related
<dobey> Ursinha: right
<dobey> hopefully it's that then, and will be fixed in a couple hours :)
<Ursinha> dobey: yeah :) fginther and plars are working on boottesting this week to make it smarter and results more readable, it should improve greatly
<plars> yeah, looking into this now
<fginther> dobey, plars, I can unwedge individual package while this problem gets sorted out. dobey working on unity-scope-click now
<dobey> fginther: ok, thanks
<rvr> sil2100: Can I approve silo 17 directly?
<sil2100> rvr: hey! What do you mean?
<rvr> sil2100: Whether I will break something if I sign off in the spreadsheet :)
<sil2100> Nooo, the spreadsheet seems to be working right now, so feel free to do it normally
<rvr> Ok, approving silo 17
<rvr> boiko: ^
<sil2100> Excellent
<sil2100> \o/
<sil2100> rvr: thanks
<boiko> rvr: thanks a lot \o/
<sil2100> Ok, we need an archive admin to +1 it
<dbarth_> Mirv: replied for 13, 15 and 31; basically there is just 1 request remaining
<Mirv> dbarth_: excellent! it's line 14 now and it has a dual landing silo 001
<dbarth_> Mirv: thanks!
<boiko> sil2100: the packagaging changes are only in wily, right? we landed some critical fixes that were not landed on wily, and now they will land there
<dobey> fginther: i see it made it through now. thanks :)
<sil2100> boiko: yeah, and since it's a dual landing we can't land just one of them
<sil2100> I mean, we can, but we wouldn't want that
<sil2100> We don't seem to have an archive admin around though
<rvr> Today I hit this bug. Nothing critical, but looks ugly https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1454882
<ubot5> Launchpad bug 1454882 in unity8 (Ubuntu) "when swiping the launcher on the tutorial, it leaves the edge" [Medium,In progress]
<cyphermox> cihelp: could someone please take another look at wily-desktop-amd64-smoke-default ? It's been failing for a long while, seems to have gotten better recently but I can't seem to find a reason for it to fail -- the install using wily pending images works.
<dobey> cihelp: hrmm, "chroot problem" on fisher03 (ppc64el) or do lp people need to be pinged for that? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-022/+build/7502354
<ChrisTownsend> trainguards: May I have a silo, pretty please?
<sil2100> ChrisTownsend: on it :)
<ChrisTownsend> sil2100: Thanks:)
<sil2100> yw!
<plars> dobey: I think that's for trainguards, not ci
<sil2100> dobey: looking
<sil2100> Uh, let's rebuild
<plars> cyphermox: sorry for the delay, my irc didn't highlight for some reason, I'll take a look
<cyphermox> plars: no worries
<cjwatson> dobey,plars,sil2100: chroot problems are LP issues (or lower-level), please don't just retry without giving us a chance to investigate
<cjwatson> unfortunately we've lost the evidence now, and other recent builds on that builder seem to be OK
<sil2100> cjwatson: apologies for that, that was usually what we were told to do in the past (not by the LP team though)
<cjwatson> sil2100: there was a point where chroot problems were relatively common and due to apt-related races, but we dealt with that in launchpad-buildd and now they're anomalous situations.  do you happen to remember what the build log indicated?
<dobey> cjwatson: that's why i asked if i should just ping lp instead :)
<sil2100> cjwatson: I'll try to fetch that
<cjwatson> dobey: indeed, and you got the wrong answer :)
<dobey> indeed
<cjwatson> sil2100: the build log is gone now, retrying loses it
<cjwatson> sil2100: which is why I asked if you remembered it :)
<sil2100> I still have it in my memory ;)
<sil2100> I mean, I have the log in my browser memory, let me pastebinit
<cjwatson> ah, cool
<sil2100> That's what I meant fetching it
<sil2100> cjwatson: http://paste.ubuntu.com/11545012/
<dobey> cjwatson: https://launchpadlibrarian.net/208179642/buildlog_ubuntu-wily-ppc64el.ubuntuone-credentials_15.10%2B15.10.20150603_BUILDING.txt.gz
<cjwatson> gosh, that's exciting
<cjwatson> sil2100: ok, the retry was fine in this case, I'll see if I can track down what happened though
<sil2100> Thanks :)
<rvr> jibel: sil2100: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1461593
<ubot5> Launchpad bug 1461593 in network-manager (Ubuntu) "No data connection switching from 2G only to 3G" [Undecided,New]
<sil2100> huh
<sil2100> rvr: is that part of the standard test plan? i.e. did this work last time the regression suite was run?
<rvr> sil2100: Hmm... Let me check if I can see a similar test. I was running a test case for "2G data only" which only has the first steps in the bug report.
<sil2100> Ok, anyway, looks a bit bad, but I leave it up to you guys to decide if it's a blocker
<rvr> sil2100: This works fine in stable
<pmcgowan> rvr, did you check if it comes back after time, I recall a realted bug on a delay
<rvr> pmcgowan: Hmm... let me recheck, it may be the case
<rvr> pmcgowan: Over five minutes and still waiting
<pmcgowan> rvr, ok aybe not then
<rvr> pmcgowan: 7 minutes, and connection was back
<pmcgowan> oh
<pmcgowan> rvr, it sounds like https://bugs.launchpad.net/canonical-devices-system-image/+bug/1418077 which should be fixed
<ubot5> Launchpad bug 1418077 in network-manager (Ubuntu) "After connection drops, mobile-data takes ~5m to re-connect" [Critical,Fix released]
<pmcgowan> awe, ^^
<rvr> pmcgowan: awe: Interesting, because when switching from 3G to 2G, data connection is up very quickly. The bug report implies that both changes would trigger the problem.
<awe> rvr, can you please include which operators you used in the bug?
<rvr> awe: Sure
<plars> cyphermox: something has /var/cache/debconf/config.dat locked when a latecommand is running in the preseed to install some additional packages. I don't know why this change came into wily or where it came from though. Any ideas?
<awe> also, if the image you're testing the OTA4 image?
<awe> rvr, ^^
<rvr> awe: Yup, that's already reported. #23 in ubuntu-touch/rc-proposed/bq-aquaris.en
<awe> just confirming
<awe> hmmm
<awe> can you reproduce the problem again and attach the output of 'list-modems', 'list-contexts' ( both in /usr/share/ofono/scripts ) and /var/log/syslog
<awe> rvr, certainly sounds similar to the bug pmcgowan posted above, but that was fixed awhile back...
<rvr> awe: Of course, on it
<awe> rvr, unfortunately I can't reproduce with krillin due to the fact that it only does 2g here in the US
<awe> but I'll try on arale
<rvr> awe: Output of 'list-modems' and 'list-contexts': http://paste.ubuntu.com/11545969/
<awe> thanks rvr
<awe> I'll review this afternoon; I'm headed to grab some lunch now. be back in a bit...
<cyphermox> plars: no. nothing should keep it locked; is there any way you could add a check for that lock as the very first step of the late command, so we know whether it's something in the latecommand that triggers it or if it's from the install?
<plars> cyphermox: that's what I'm trying to do, but not with much luck to see what's happening so far
<pmcgowan> renatu, charles did you get a silo yet? need that tested today
<pmcgowan> sil2100, for a dual landing how can you tell if it published to the overlay? are vivid and wily in parallel?
<sil2100> pmcgowan: it's automatically published to the overlay PPA
<sil2100> It publishes them in parallel, but the overlay part is just a PPA copy so it's almost instant
<pmcgowan> sil2100, looking at https://bugs.launchpad.net/dialer-app/+bug/1460111
<ubot5> Launchpad bug 1460111 in dialer-app (Ubuntu RTM) "dual sim handset cannot select default sim" [Critical,In progress]
<pmcgowan> its not closed out, maybe just takes a while
<pmcgowan> oh
<sil2100> Yeah, because the fix wasn't in dialer-app ;/
<pmcgowan> righto
<sil2100> The fix was in telepathy-ofono and it wasn't marked for Ubuntu-RTM
<sil2100> So it wasn't auto-closed
<pmcgowan> right
<pmcgowan> I will fix the bug up then
<charles> pmcgowan, wrt the led silo, I'm sorry, I thought you and renatu were on it
<charles> pmcgowan, I don't see it in the spreadsheet, adding it now
<pmcgowan> charles, thanks, I don't ever do silos myself
<charles> pmcgowan: ack :-)
<rvr> sil2100: Are you creating a new image with silo 17?
<pmcgowan> that would be asking for trouble
<charles> renatu, are you around?
<sil2100> rvr: on it now, I was out shopping
<rvr> sil2100: Ok
<charles> renatu, looks like https://code.launchpad.net/~renatofilho/unity8/blue-led/+merge/224899 is failing jenkins
<charles> but it passed earlier a few revisions up, so this may be a hiccup
<charles> I'll resubmit it
<charles> ah! renatu, disregard previous comment for the obvious reason
<sil2100> hmm
<sil2100> imgbot didn't notice the build apparently
<charles> trainguards, +1
<robru> charles: on it
<robru> charles: ok, silo 46, note the conflict in silo 4.
<charles> hurmmm, yeah
<charles> I think it should be okay, renatu's patch in silo 46 only touches qml/Panel/Indicators/IndicatorsLight.qml ... but checking the unity8 shellrotation diff to confirm
<robru> charles: it's fine if they conflict, you just have to manage rebuilding whichever one publishes second.
<charles> robru, I need to reconfigure line 57 to add tiheum's branch as well; when I run Landing Tools > Reconfigure > Click here I get "Problem accessing /job/-0-reconfigure/parambuild. Reason: Not Found"
<fginther> Laney, I found something I don't understand. On wily, "grep-aptavail -X -n -S -sPackage gcc-5" does not list libgcc1, but "apt-cache show libgcc1" shows that libgcc1's Source package is gcc-5.
<fginther> Laney, this is related to that MP you proposed a few days ago for boottest. Thought you might know what's going on here.
<robru> charles: try now
<charles> robru, works now, thanks :)
<robru> charles: you're welcome
<boiko> robru: do you by chance know why telepathy-ofono is listed as Not considered in the update excuses? (this is related to silo 17)
<robru> boiko: the three previous lines say "unsatisfiable depends"
<boiko> robru: ouch! duh, should have seen it :)
<boiko> salem_: ^
<robru> boiko: yeah not sure the details but you'll have to poke at those depends.
<robru> boiko: salem_ https://ci-train.ubuntu.com/job/ubuntu-landing-017-1-build/190/artifact/telepathy-ofono_packaging_changes.diff/*view*/ looks like "libmission-control-plugins-dev (>= 1:5.14.0)" is new, check that's available in wily.
<robru> boiko: salem_: nm, it's libhybris-utils, duh
<robru> looking at wrong spot
<boiko> robru: we had that package in vivid overlay already, but it seems hybris is not available on those arches, so we might need to make the package building conditional
<salem_> boiko, what archs?
<boiko> salem_: arm64, powerpc and ppc64el
<robru> salem_: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#telepathy-ofono
<boiko> robru: if we fix the build/packaging in the MP that's currently on the silo and rebuild it, can you re-publish it afterwards?
<robru> boiko: so I guess technically this counts as an arch regression; make it conditional on those arches if possible, otherwise you might be able to get an archive admin to wave this through
<robru> boiko: yep
<salem_> robru, boiko thanks
<robru> salem_: you're welcome
<charles> robru, I was wrong, the reconfigure of line 57 to add tiheum's branch didn't take. Re-attempting a reconfigure gives me the same "Problem accessing /job/-0-reconfigure/parambuild. Reason: Not Found" error as before
<robru> charles: oh you're adding a new package. I thought you were adding a new MP within the same package.
<robru> charles: yeah I have to reconf that.
<charles> robru, ack
<robru> charles: ok should be good now
<charles> robru, thanks again :)
<robru> charles: you're welcome!
<ChrisTownsend> trainguards: Could you please publish landing-035?
<robru> ChrisTownsend: done! good luck with SRUing!
<ChrisTownsend> robru: Thanks!  I think this one will get through pretty fast.
<robru> sweet
<pmcgowan> hey sil2100 I am still hoping on silo 46 and we seem to have an app icon issue to attend to
 * robru --> lunch
<boiko> robru: package rebuilding on silo 17
<boiko> robru: when you are back, it seems that the package already landed on vivid overlay(?) and now a rebuild fails
<robru> boiko: checking
<sil2100> pmcgowan: sure thing, yeah, I just meant that the blocker bugs are out of the way, but we can land some additional things on the way as well
<sil2100> As you proposed on the meeting yesterday
<robru> boiko: oh, no, that's just because 602.2 is sitting in propose. just FORCE_REBUILD it and it'll work.
<boiko> robru: nice! let me do that then
<robru> boiko: I think that's technically a train bug, I should fix that to check only dest archive, and ignore proposed. I've seen this pop up before.
<boiko> robru: ack. want me to report that? if so, where?
<robru> boiko: it's ok, I'm filing it
<boiko> robru: ok
<robru> boiko: https://bugs.launchpad.net/cupstream2distro/+bug/1461661
<ubot5> Launchpad bug 1461661 in CI Train [cu2d] "changelog version checking mistakenly picks up versions in proposed." [Undecided,Triaged]
<boiko> robru: nice
<jgdx> trainguards, hey, seems I have two identical spreadsheet lines creating two silos. Only need one. :) Line: 14, 41 and Silos: 30, 33
<jgdx> actually, if I want to build, what do I choose? In the dash only the status differ.
<jgdx> kenvandine, what did I do? ^ :P
<jdstrand> pmcgowan: fyi, https://bugs.launchpad.net/ubuntu/+source/content-hub/+bug/1456628/comments/6
<ubot5> Launchpad bug 1456628 in Canonical System Image "DBUS API doesn't prevent confined apps from passing paths to files without access" [Critical,Confirmed]
<robru> jgdx: looks like mirv assigned you one extra by mistake. I'll free 30 since it's empty anyway
<pmcgowan> jdstrand, very good
<robru> jgdx: so build 33 if you need a rebuild.
<jgdx> robru, cheers
<robru> jgdx: you're welcome
<boiko> robru: silo 17 rebuild finished
<robru> boiko: ok, published. it's in vivid overlay already, will show up in wily-proposed soon
<boiko> robru: thanks!
<robru> boiko: you're welcome
<boiko> robru: even though the update excuses says it is testing the package, there are some "old binaries left on <arch>" and the Not considered message
<robru> boiko: ah, you'll need to get somebody from #ubuntu-release to clear those out
<boiko> robru: /me joins and asks
<jibel> renatu, what is the change with the theme in silo 46? Should the app icons be different?
<renatu> jibel, I am not sure what is the changes on the icons
<jibel> pmcgowan, ^ do you know?
<pmcgowan> oh crap
<pmcgowan> did you bring the entire theme in?
<pmcgowan> charles, ^^
<pmcgowan> thats what we wanted to land later
<charles> pmcgowan, oog. The individual icon wasn't in a separate MP...
<charles> yes, we'll want to split that up then.
<pmcgowan> we want it soon but not today
<pmcgowan> gotta run
<charles> ack
<charles> jibel, so as per ^ we'll want to shelve https://trello.com/c/JXxJRGIt/1753-ubuntu-landing-046-unity8-ubuntu-themes-renatu-charles
<charles> I'll unmark it in the spreadsheet until we get a revised MP for unity-themes
<plars> cyphermox: so it seems something along the way is running debconf-communicate, and that's locking that config.dat. It's got to be something in the install process though, which is causing some package installs in late_command setup to fail
<cyphermox> well, I just tried debconf-communicate
<cyphermox> gonna try again to be sure
<tedg> trainguards, could I please get a vivid silo for line 57 please?
<robru> tedg: silo 30
<tedg> Thanks robru
<robru> tedg: you're welcome
<jibel> charles, tedg when silos 46 and 30 are ready for testing, can you ping ToyKeeper to do the verification. I've to leave now.
<tedg> Sure
<charles> jibel, ack
<boiko> robru: should I be worried about the Regression status on the update_excuses page?
<robru> boiko: generally yeah
<robru> boiko: that's a boottest, it's known to be flaky. Ask cihelp to investigate/retry
<robru> (Also i saw that passed last time)
<plars> boiko: which job?
<robru> plars: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#telepathy-ofono
<fginther> plars, *sigh* looks like it still failed with a ssh command failure
<plars> fginther: yeah, just saw the 255
<plars> fginther: but we got an exit code 12, which is different :/
<cyphermox> plars: as far as I can tell, debconf-communicate does work after the install
<plars> fginther: that should be erronious package according to adt-run, but the 255 tells me it was more likely ssh
<plars> cyphermox: debconf-communicate is the thing locking that file and preventing progress though
<plars> so I guess, yes it's working :)
<cyphermox> plars: I just ran  echo "GET keyboard-configuration/layoutcode | sudo debconf-communicate" from a sudo chroot /target, in another VT on the CD (because I forgot to start the installer in a live session)
<cyphermox> that should have failed as much as whatever it is taht you guys are running in latecommands
<plars> cyphermox: nothing in the preseed that gets added for the test setup uses debconf-communicate
<fginther> plars, yeah, it kinda looks like adt-run interpretted that as an erroneous failure based on it trying to do a specific thing.
<cyphermox> anything using debconf...
<cyphermox> apt-get some such, or dpkg, or whatever
<fginther> plars, wft, I'll fix the permissions on boottest.sh, it somehow got flipped in a recent MP
<cyphermox> I'm happy to try installing packages now, if you tell me what it is that runs in the latecommand
<fginther> plars, I'll take care of this as you look busy
<robru> kenvandine: around for a packaging ack? https://ci-train.ubuntu.com/job/ubuntu-landing-016-2-publish/
<fginther> boiko, plars, trying wily-boottest-telepathy-ofono again
<boiko> fginther: thanks
#ubuntu-ci-eng 2015-06-04
<plars> cyphermox: I have found at least part of the problem, and I got a run of amd64 to pass. It doesn't seem to work everytime so it's still a little flaky but it's better. I'll try to do some more debugging on it tomorrow or pass it off to the next vanguard
<cyphermox> plars: ack
<cyphermox> what seems to be the problem?
<plars> cyphermox: well, at first I was thinking it was the command used to restart rsyslog - it was using 'restart' rather than 'systemctl restart' as is likely needed by systemd now. But that didn't seem to fix it. I have it trying both now though, and not failing for that alone since we need to support older isos also
<plars> cyphermox: part of the problem seems to still be permissions around /dev/ttyS0 though. That was changed a while back and it broke us. So we're adding syslog to the dialout group, setting permissions, etc. It still seems to persistently want to fail in some cases though. I'm not convinced there isn't some other error lurking there either, but I seem to be
<plars> able to work around it for now
<plars> cyphermox: to be fair, I'm not really convinced of the usefulness of these tests, they are just doing installs with different combinations, and preseed ones at that. There are autopilot tests out there for driving ubiquity through most of these same install scenarios.
<plars> that seems like a much better test for the desktop install process to me
<infinity> plars: If you want to support both upstart and systemd, what you're looking for is "service $service restart"
<abeato> Mirv, any idea why is that ^^ (nuntium not found in archive)
<abeato> it is a wily silo, that I was not able to publish before due to a bug in the gccgo powerPC compiler (now apparently fixed)
<Mirv> abeato: err
<Mirv> abeato: it's a sync silo trying to sync from silo 27, but that is already gone
<Mirv> abeato: so it should probably be a sync silo from overlay PPA instead
<abeato> Mirv, ah, I see... but there is a package in the PPA
<Mirv> abeato: yes, but you're trying to rebuild which would mean trying to sync again
<abeato> Mirv, anyway, which is the syntax I should use then?
<Mirv> abeato: well I just put it in, reconfiguring now
<abeato> ah, just seen, thanks
<Laney> fginther: the things you don't know ...
<Laney> fginther: Looks like Source can be Source: <source package> (version)
<Mirv> the spreadsheet is giving a bit of trouble though again
<Mirv> ok, now it orks
<Laney> fginther: so do grep-aptavail -e ... "^${SRC}( \(.*\))?$" or something
<Laney> fginther: and get rid of -X
<Laney> I think that should do it...
<Mirv> abeato: reconfigured + started https://ci-train.ubuntu.com/job/ubuntu-landing-011-1-build/166/console
<abeato> Mirv, awesome, thx
<Mirv> ogra_: I'm not sure if it went unnoticed, but see http://people.canonical.com/~ogra/touch-image-stats/20150521.changes - GTK2 dropped! :)
<seb128> Mirv, do you know what changed to drop it? qt?
<Mirv> seb128: "me" :)
<Mirv> seb128: I mean, the gtk2 theme support was split into separate package
<Mirv> after Debian settled on the way to do it
<seb128> Mirv, oh, great :-)
<Mirv> that was the easier thing (than dropping gtk3) but also needed to be done
<ogra_> Mirv, heh, it actually went unnoticed because when i looked at it i was focused on libgo (which droped about 30MB from the image too)
<seb128> right
<Laney> how do I delete a package from a landing?
<Laney> edit spreadsheet, delete from ppa, watch only build?
<Laney> ah "reconfigure"
<jibel> tedg, Hey, how can we test the fix in silo 30?
<jibel> since it happens on upgrade
<popey> fginther: are you mid way through fiddling with jenkins? Is that why this is failing https://code.launchpad.net/~carlos-mazieri/ubuntu-filemanager-app/samba-browsing-11/+merge/252982 ?
<fginther> popey, that branch is failing due to bzr conflicts
<popey> fginther: hmm
<abeato> trainguards, I have changed the target distribution for line 45 (silo 19), how can I reconfigure the silo?
<Mirv> abeato: it needs to be freed up and reassigned. if that's ok (you lose the current builds), I can do that.
<abeato> Mirv, that's fine, please do
<Mirv> pete-woods: needs top approval https://code.launchpad.net/~pete-woods/indicator-network/15.10-fix-unity8-cycle/+merge/260849
<Mirv> abeato: ^ 011 the dual silo
<abeato> Mirv, awesome, thx
<pete-woods> Mirv: fixed them both
<pete-woods> sorry about that
<Mirv> pete-woods: np
<jibel> charles, is silo 46 ready?
<tedg> jibel, Honestly, I'm not sure.
<tedg> jibel, In theory just upgrading the package and rebooting should be the same.
<tedg> jibel, Then installing a new version of an app
<jibel> tedg, installing the silo on an upgraded device that shows duplicate icons would work?
<tedg> jibel, No, you'd have to install or remove an application as well in that case.
<jibel> ok
<tedg> jibel, My concern with this bug is that it was vivid for two months and no one saw anything. I think we've fixed a bug, but I'm not sure it's *the* bug. I'm not sure there's much we can do with the silo, but I do think that on the next image we need to really flag this to watch out for.
<pmcgowan> jibel, silo 46 wfm, mind giving it a go
<pmcgowan> tedg, any leads on that dupe/missing icon thing
<jibel> pmcgowan, works for me too, I was waiting for charles to confirm that it's ready to land
<pmcgowan> great
<tedg> pmcgowan, silo 30
<pmcgowan> nice
<pmcgowan> tedg, how to test it?
<jibel> pmcgowan, om26er_ is verifying silo 30 but it is not clear how to test it without building an image
<tedg> pmcgowan, You basically need to install the silo and upgrade/remove an app. Butâ¦ yeah, what jibel said.
<pmcgowan> ok will wait for omer then
<tedg> pmcgowan, My big concern is that no one saw this in vivid for two months. So it makes me a bit worried about it.
<tedg> I don't think everyone running vivid is wiping or something like that.
<pmcgowan> yeah we install and update
<pmcgowan> tedg, I only saw it by reinstalling rtm then vivid afterword
<jibel> pmcgowan, bug 1461952 looks serious too
<ubot5> bug 1461952 in telepathy-ofono "SMS to multiple reciepients failed" [Undecided,New] https://launchpad.net/bugs/1461952
<pmcgowan> jibel, yeah let me get them looking at that
<pmcgowan> bfiller, ^^
<jibel> tedg, what is the risk of regression with silo 30?
<tedg> jibel, Software always gets better! ;-)  I think it's pretty low. We're only changing the filters to look at more files. Worst case we delete a user defined desktop file, which is not a "normal user" by any means.
<pmcgowan> jibel, for me it doesnt send the group message at all, just says failed
<jibel> tedg, so an option would be to confirm that the silo works on OTA4 and doesn't regress anything even if we cannot confirm that it fixes the original upgrade issue, land it, build an image and redo the upgrade test.
<tedg> jibel, +1
<pmcgowan> iahmad, for that sms bug, does it send to one of the recipients or just Failed?
<jibel> for me it doesn't send the SMS either, just 'failed' (untranslated btw) after a several seconds.
<charles> jibel, could I get a second pair of eyes on silo 46? It looks strange to me:
<charles> jibel, from the dashboard, the MPs look correct. The issue yesterday was a new MP was needed to only pull in the one new icon instead of tiheum's whole suru v2 branch
<charles> jibel, but if you look at the diff file in 46's PPA it looks like that build still pulled in all of suru v2
<charles> my guess is that this is a CI issue and wouldn't affect the actual landing, but would like a second opinion...
<iahmad> pmcgowan, just failed
<pmcgowan> ack
<jibel> Mirv, ^^ any idea about charles question, why the diff in the PPA is not the same than the diff in the MP and in jenkins?
<dobey> sounds like that silo needs reconfigured
<dobey> and then rebuilt
<om26er_> tedg, so I downgraded to last promoted image, upgraded through system-image-cli to proposed and then install the silo packages and rebooted.
<om26er_> I no longer see duplicate packages. tedg is that expected ?
<tedg> om26er_, It's possible. It would happen anytime the click hook is run. Installing a package is how you could guarantee that, but there are other reasons they'd run.
<tedg> om26er_, So that's why I suggest installing an app, just to be sure they were run.
<om26er_> tedg, I was not able to find the changelog. How "dangerous" is this silo ?
<tedg> om26er_, pansy. Sure one could kill you but it'd have to be frozen and thrown at high speed.
<om26er_> "this" :)
<Mirv> jibel: diff in the PPA may be diff to the previous version that happened to be in the PPA, not the actual diff. that's why we have the jenkins generating the diff in the first place, since PPA/LP can't be trusted on providing a correct diff.
<Mirv> charles: jibel: not opening that 13MB diff but maybe the diff is from the previous build that included the wrong things, so the diff shows how it's reverted again? the jenkins diff shows the actual diff from archive version.
<Mirv> so the jenkins generated https://ci-train.ubuntu.com/job/ubuntu-landing-046-1-build/5/artifact/ubuntu-themes_content.diff is the real diff
<jibel> charles, the actual debdiff with the version in the PPA and the version on the phone is http://paste.ubuntu.com/11566558/
<jibel> charles, there is a change for gtk-3.0 and the rest if the green icon
<jibel> no sure why it is slightly different from jenkins though
<balloons> fginther, confirming for myself and perhaps popey . We'll be shutting off the AP tests for now on core apps, yes?
<fginther> balloons, yes
<balloons> ty.
<renatu> balloons, I got approval from rsalveti on silo 16. Can we land it?
<charles> jibel, excellent, thanks for looking at that
<charles> Mirv, thanks :-)
<charles> jibel, pmcgowan, then IMO silo 46 is ready for QA signoff wrt card https://trello.com/c/JXxJRGIt/1753-ubuntu-landing-046-unity8-ubuntu-themes-renatu-charles
<pmcgowan> charles, sorry it was so much trouble
<charles> pmcgowan, sorry it didn't land yesterday as it should have; I should have started off with a cherrypicked suru MP
<rvr> awe: I attached the syslog
<om26er_> tedg, so what else should I be testing? Can you help ?
<awe> rvr, thanks much!
<tedg> om26er_, There's not a lot more, really all it does is change the hook that creates the desktop files.
<tedg> om26er_, If you look at ~/.local/share/applications things should look "right"
<tedg> om26er_, i.e. no duplicate apps or apps missing.
<jibel> om26er_, maybe additionally install and remove an app to check if icons are added/removed and there is not much else we can do
<jibel> charles, can you update column K on the spreadsheet for line 56?
<om26er_> jibel, hmm, let me try that as well
<om26er_> I was about to approve it
<balloons> renatu, perhaps you meant boiko earlier?
<jibel> om26er_, unless you find anything else useful to try from https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-app-launch it's fine to approve
<renatu> balloons, boiko is off for the rest of the week
<fginther> Laney, thanks for the help. That should help get gtk-3.0 unwedged
<pmcgowan> jibel, can you get the content of .cache/upstart/nuntium.log
<jibel> pmcgowan, http://paste.ubuntu.com/11567396/
<pmcgowan> jibel, yeah same as here
<pmcgowan> wait yours is diff
<jibel> pmcgowan, are group sms sent as mms?
<pmcgowan> jibel, yes, seems no mms is working on krillin
<jibel> pmcgowan, ah it might fail because wifi is on
<pmcgowan> oh
<pmcgowan> still fails
<pmcgowan> kenvandine, see his paste
<jibel> pmcgowan, I can send with wifi off
<jibel> it's confusing
<pmcgowan> really
<kenvandine> oh... there was a fix for sending with wifi on just recently
<kenvandine> abeato, ^^
<jibel> bug 1417976
<ubot5> bug 1417976 in nuntium (Ubuntu) "Cannot send MMS with Free Mobile when on Wifi" [High,Confirmed] https://launchpad.net/bugs/1417976
<abeato> jibel, which is the output of "ip route" ? which image are you using?
<jibel> abeato, with wifi on or off?
<abeato> on
<charles> jibel, sorry was in meeting, yes will update column K on spreadsheet line 56
<jibel> abeato, I'm using rc-proosed/bq-aquaris.en #24 aka OTA4
<abeato> jibel, also, which is your operator?
<jibel> abeato, http://paste.ubuntu.com/11567572/
<jibel> abeato, Free Mobile
<abeato> jibel, cout you paste "cat /etc/NetworkManager/dispatcher.d/03mmsproxy" ?
<abeato> jibel, and output of execution of /usr/share/ofono/scripts/list-contexts
<nerochiaro> elopio: hello, i am having different results running a test in autopilot3-sandbox-run and normally. do you know of any known bugs in sandbox-run that might cause this ? the tests have something to do with keyboard shortcuts
<nerochiaro> elopio: on webbrowser
<jibel> abeato, http://paste.ubuntu.com/11567770/ + http://paste.ubuntu.com/11567824/
<abeato> cyphermox, awe I remember to have read in some comment in some bug a problem when creating routes in case the proxy was empty in 03mmsproxy
<abeato> might be related to jibel 's issue?
<abeato> jibel, thanks
<jibel> yw
<awe> abeato, I don't recall seeing that...
<abeato> jibel, one more thing :)... what do you get when doing "grep mmsproxy /var/log/syslog" ?
<awe> abeato, did you verify he has the updated mmsproxy dispatcher script?
<awe> brb
<abeato> awe,yes that's fine, it is not a combined context, but proxy is empty for him
<awe> what do you mean by proxy is empty?  No MessageProxy defined in the context?
<abeato> awe, right, see http://paste.ubuntu.com/11567824/
 * awe looks
<awe> abeato, is the messagecenter hostname resolvable & reachable over the WiFi network?
<jibel> abeato, http://paste.ubuntu.com/11567902/
<abeato> jibel, thanks, it is this issue with the proxy, free does not define it and causes trouble with the routes
<abeato> awe ^^
<awe> indeed, I bet the mmsproxy script doesn't explicitly check for no proxy?
<abeato> yes
<awe> anyways, we need to determine (a) is the hostname resolvable over the WiFi network
<awe> and (b) is the resulting IP address reachable over the same
<awe> it could be that we need addtional routing logic added if there's no MMS proxy defined
<abeato> probably it is the case
<awe> jibel, can you see if you can resolve the messagecenter hostname when connected to WiFi
<awe> ?
<awe> and then see if the resulting IP address is reachable?
<awe> also, is there a bug for this?
<awe> abeato, ^^
<abeato> https://bugs.launchpad.net/ubuntu/+source/nuntium/+bug/1417976
<ubot5> Launchpad bug 1417976 in nuntium (Ubuntu) "Cannot send MMS with Free Mobile when on Wifi" [High,Confirmed]
<awe> right
<awe> thanks
<awe> abeato, can assign to you?
<abeato> indeed
<pmcgowan> I think I disconnected, so
<pmcgowan> <pmcgowan> abeato, awe mms is not working for me on AT&T on either arale or krillin
<pmcgowan> <pmcgowan> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1461952
<ubot5> Launchpad bug 1461952 in Canonical System Image "SMS to multiple recipients failed" [Critical,Confirmed]
<awe> pmcgowan, ;(
<awe> with ota4?
<awe> do you have an active data plan?  maybe they cut you off too!
<pmcgowan> awe, heh
<pmcgowan> yes ota4
<pmcgowan> awe, I get internet
<abeato> pmcgowan, please paste ~/.cache/upstart/nuntium.log
<pmcgowan> abeato, this is arale http://pastebin.ubuntu.com/11567998/
<pmcgowan> abeato, this is krillin http://paste.ubuntu.com/11567348/
<pmcgowan> same sim
<awe> pmcgowan, my data plan is empty; I'm going to check with AT&T, but I can't reproduce while just on mobile data
<awe> pmcgowan, in this case, when I try to send the MMS, the messaging-app just continues to show the spinner for the message
<awe> I never see it stop and indicate failed
<charles> jibel, line 56 marked as tested
<awe> also, network-indicator isn't showing me connected to WiFi when I am
<awe> ;(-
<awe> pmcgowan, do you see the same endless spinner in the messaging-app?
<awe> bfiller, do you remember seeing that at the sprint in austin?
 * awe my camera seem super-unstable on arale
<rvr> Can someone confirm this with image 24? https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1461999
<ubot5> Launchpad bug 1461999 in network-manager (Ubuntu) "Crash changing SIM slot technologies" [Undecided,New]
<jibel> tedg, can you mark column k of line 57 as tested (if it's tested of course) so the silo can publish
<tedg> alecu, ^ did you test that silo?
<abeato> pmcgowan, you do not have cellular data activated for krillin
<abeato> pmcgowan, for the moment we need tht
<pmcgowan> abeato, I don't? I can try again in a min
<abeato> pmcgowan, the contexts listed in the nuntium log are all inactive
<pmcgowan> weird
<awe> pmcgowan, can you also dump the output of /usr/share/ofono/scripts/list-contexts?
<awe> it appears that the apn db update introduced a new APN ( nextgenphone ) for AT&T
<awe> you should now see ATT Phone, ATT WAP, and ATT Nextgenphone
<awe> the latter fails for me if WiFi is enabled
<pmcgowan> abeato, ok basic mms does work there now, so I am confused
<pmcgowan> cell data was off as you said
<pmcgowan> but group mms still fails
<awe> pmcgowan, abeato and I discussed this yesterday; the messaging-app should display an error if mobile-data is off
<abeato> pmcgowan, for arale, in your pastebin I see:
<abeato> 2015/06/04 15:26:02 m-send.conf ResponseStatus for 6f58b19377ad081d8c67309452ee53c9 is 226
<abeato> Error-permanent-message-format-corrupt = <Octet 226>
<abeato> pmcgowan, was that when sending a group message?
<awe> at least for the short term.  abeato has a proposed auto-enable for MMS, but we need to focus on short-term message stability first and foremost
<awe> abeato, does group SMS use MMS under the covers
<abeato> yes afaik
<awe> I had no input in it's design or impl
<pmcgowan> awe, yes group chat needs mms
<pmcgowan> abeato, give me a min, on a call
<abeato> ok
<pmcgowan> abeato, http://pastebin.ubuntu.com/11568609/
<pmcgowan> thats a group send on krillin at&t
<abeato> pmcgowan, taking into account that non-group MMS is working, and being error 226 a bad format error, we must be sending something in the payload that att does not like
<abeato> pmcgowan, I think the data is prepared by messaging-app
<abeato> pmcgowan, nuntium wraps it and sends
<jibel> tedg, if alecu is not online can you do it, we really need this fix then rebuild an image
<om26er> jibel, tedg approved
<jibel> om26er, tedg ah thanks I missed it
<jibel> om26er, no it is not
<jibel> om26er, line 57
<om26er> jibel, yes, says Granted
<om26er> jibel, refresh your sheet :p
<jibel> om26er, right for QA, but column K is not set to tested
<om26er> oh
<awe> pmcgowan, I just restored my AT&T SIM, billing error on their end.  I'll retry MMS after lunch
<fginther> popey, balloons, music-app and ubuntu-clock-app should now be un-blocked
 * popey hugs fginther 
<tedg> jibel, I'd really prefer alecu to do it, I think he's probably back soon (and I'm about to head out). He had an upgraded OTA 3.5 device he was going to test it on.
<jibel> tedg, ok
<tedg> jibel, But if he's gone for longer I can test it after I get this other silo done.
<tedg> Not in a clean state right now.
<alecu> tedg: I'm back from lunch, I'll give it a try now
<alecu> tedg: but it's silo 030 that I should test, right? not 008 as suggested above
<renatu> balloons, are you a trainguards? could you release the silo 16?
<renatu> I got the ubuntu core dev approval
<balloons> renatu, I'm not a trainguard
<balloons> trainguards ^^
<renatu> balloons, ok sorry :D
<balloons> no worries, sorry if I misled you :-)
<Mirv> renatu: it needs an archive admin ack for the new binary package and I haven't gotten one on #ubuntu-release. robru can continue to monitor it (and robru MOTU ack on other packaging changes..)
<Mirv> (= I ack the other changes)
<robru> Mirv: actually with the new dual landing support, it's now possible to change the target series without freeing and reassigning
<alecu> tedg: installed silo 030 on my ota-3.5. Then upgraded to ota-4 (with the steps outlined by om26er): I get duplicated icons
<alecu> tedg: I suspect this has to do with the ota-4 overwritting stuff from the silo
<om26er> alecu, is there a new image ?
<alecu> tedg: any hints on how to test this properly?
<alecu> om26er: I think there's not. So, the current ota-4 image steps on whatever I installed from the silo
<alecu> I'll try installing the silo on top of ota-4, but I still have no clue on how to test it properly.
<jibel> alecu, from earlier discussion, I think there is no good way to test it without an image and the best we can do is to ensure the silo doesn't regress anything.
<jibel> alecu, 3.5 to 4 is a full image upgrade and the silo will be overwritten
<alecu> jibel: right. Then I'm not sure I'm the right person to test this silo; I offered ted help testing this issue, but I've never tested this whole package.
<alecu> jibel: I can give it a go if nobody else is around
<alecu> jibel, om26er: btw, good news are that installing the silo with the citrain script on top of ota-4 (and rebooting), shows only one copy of each of the icons
<om26er> alecu, yeah, thats what I noticed as well
<pmcgowan> jibel, so in the end I actually have group chat working on my krillin
<jibel> pmcgowan, good, me too with wifi disabled. I suppose the original reporter's issue is also related to MMS configuration.
<pmcgowan> jibel, could be, will downgrade severity
<jibel> alecu, if you and om26er tested it and didn't find any obvious breakage, it's good to land. what do you think?
<jibel> trainguards, can you publish silo 46?
<jibel> robru, ^
<robru> jibel: done. so that'll be in overlay immediately and wily-proposed shortly
<jibel> robru, thanks
<robru> jibel: you're welcome
<alecu> jibel: sounds good to me. I'm finishing with the test plan for that silo, looking good so far
<jibel> alecu, perfect, thanks.
<alecu> jibel: the tests from ubuntu-app-launch/security-app-launch are taking forever. The rest is +1
<alecu> jibel: and just now they are finished. I'm +1 the silo in the spreadsheet
<alecu> jibel: om26er, tedg: ^
<alecu> yay!
<tedg> Great, thanks alecu!
<alecu> tedg: thanks to you, sir
<robru> lol, every time
<robru> alexabreu: silo 28
<alexabreu> robru, thx !
<robru> alexabreu: you're welcome!
#ubuntu-ci-eng 2015-06-05
<jibel> ogra_, can you build an image for OTA4? we need latest fixes for the message indicator and ubuntu-app-launch that landed yesterday
<ogra_> jibel, running
<jibel> ogra_, thanks
<brendand> imgbot, help
<imgbot> I am the firendly system-image watchbot !
<imgbot> I know the following commands:
<imgbot> help, stop, status, map, stunt
<imgbot> for questions please mail ogra@ubuntu.com
<brendand> imgbot status 405
<ogra_> 405 ?
<brendand> ogra_, well i want to know if the next image for krillin is in the pipeline
<ogra_> brendand, for which channel
<brendand> ogra_, ubuntu-touch/rc-proposed/bq-aquaris.en-proposed
<ogra_> (status only ever showed the status after build and with the channel switches and resetting of the build numbers it cant monitor builds atm)
<ogra_> brendand, thats the test channel for custom/device tarballs
<ogra_> and image is building for ubuntu-touch/rc-proposed/bq-aquaris.en
<brendand> ogra_, thanks
<brendand> ogra_, would be great to be able to tell it a channel and see what's going on with that channel (last build, build(s) in progress)
<ogra_> brendand, yes, it would .,.. but it is quite some effort to switch to the new model and i dont have much time for phone stuff recently
<ogra_> (and to make the code public i have to remove all ssh keys and stuff, i'm working on a re-write that doesnt need this but it takes its time)
<ogra_> oh, do we have a meeting ?
 * ogra_ notes that sil isnt around 
<jibel> ogra_, canceled
<ogra_> good
<ogra_> (my calendar didnt notice :P
<ogra_> )
<jibel> yeah, any canceled meeting is a good meeting ;)
<Mirv> ok :)
<ogra_> well, it would be nice if my phone would agree :P
<Mirv> last bluefin day
<jibel> ogra_, Mirv we didn't have much to discuss anyway. Verify that next krillin build is still good, nothing on our list of critical bugs for OTA4, actions in progress: sanity testing of mako and emulator, next steps reopen the landing gates.
<Mirv> jibel: if anyone asks for ETA for vivid reopening (for OTA5), what would I answer?
<sil2100> ;p
<Mirv> sil2100: go away! :D
<sil2100> jibel: should I announce the landing gates being open?
<sil2100> Or do you want to confirm the image first?
<jibel> sil2100, not before we verified next build
<jibel> nobody knows what can happen
<ogra_> sil2100, delegate ... Mirv just volunteered ;)
<sil2100> Is the image ready or do you guys  want one kicked?
<ogra_> building
<sil2100> Ossum
<sil2100> ;) Mirv will be busy with closing meetings and airport transit
<jibel> sil2100, what do you think about landing silo 4 (shell rotation) and build an image with only this fix?
<jibel> s/fix/feature/
<jibel> (after it has been verified of course)
<Mirv> sil2100: jibel: oh yes that will be a problem since it's already an afternoon flight and it's a bit hard to to training from the tubes. but! heathrow does have 4h free wifi so I should be able to do minimal trainguarding until around 3.30pm british time
<sil2100> jibel: I'm +1 on that but for post-OTA-4
<brendand> Mirv, you can't do training on a train! that's surprising...
<jibel> sil2100, yeah, not right now :)
<Mirv> sil2100: jibel: I just not need to be picked up by guards when they see there's a guy with full bright white laptop display, a phone attached with usb cable with something like tiny desktop on the phone screen
<Mirv> on the positive news, the XPS 13 is now waiting for me at home
<jibel> ogra_, sil2100 what is the difference between generic and generic_x86? generic is armhf?
<ogra_> yep
<jibel> ogra_, there is no build for x86 emulator on bq-aquaris.en?
<ogra_> jibel, seems slangasek didnt set one up
<sil2100> Not sure what's up with that, since slangasek didn't like that we were promoting generic_x86 instead of generic
<sil2100> I don't use the emulator so I wouldn't know what's up
<sil2100> I just know we always used generic_x86
<sil2100> Ok, I go away do some stuff now, I'll be scanning the shell every now and then to deal with train stuff
<mzanetti> sil2100, hey, do you know what's going on here? https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/190/console
<mzanetti> seems dialer app has troubles in vivid or something
<seb128> mzanetti, see build logs
<seb128> mzanetti, "E: Couldn't find any package by regex 'qtdeclarative5-ubuntu-addressbook0.1'"
<seb128> mzanetti, seems like that code version depends on the binary split from https://launchpad.net/ubuntu/+source/address-book-app/0.2+15.10.20150601.2-0ubuntu1 but that's in wily only
<seb128> not vivid
<alf_> cihelp: Hi! Could you please add a new test ('mir_privileged_tests') to the test runs by the mir-mediumtests-runner-mako job (in job parameter 'test_suite')?
<alf_> Ursinha: Hi! I have been trying to contact 'cihelp' for a small change in one of our CI jobs, but to no avail. We want to add a new test ('mir_privileged_tests') to the test runs by the mir-mediumtests-runner-mako job (in job parameter 'test_suite'). Could you do it, or, if not, advise us on who to contact to change this?
<ogra_> jibel, your image is done
<ogra_> brendand, ^^^
<brendand> ogra_, thanks
<jibel> ogra_, thanks
<sil2100> imgbot didn't register it? :)
<ogra_> sil2100, no, it cant
 * sil2100 pats poor imgbot 
<ogra_> as i said beofre, it cant get along with the reset of image numbers when the channel was renamed
<ogra_> the next version wont be using image numbers anymore, only cdimage build id's
<jibel> rvr, ^ image 25 is ready, can you redo the upgrade test and verify there is not duplicate apps
<rvr> jibel: I'm on it
<jibel> rvr, thanks, I verifying that mako didn't explode on OTA4.
<jibel> +'m
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/vivid/20150605.changes quite a bunch of changes, are all of them expected ?
<jibel> ogra_, gtk was not expected
<ogra_> well, i guess thats an SRU
<ogra_> (and it is not like we actually use it :) )
<jibel> unity8 and themes is the green indicator, ofono was a no changes rebuild, and app-launch is the 'duplicate icons' fix
<ogra_> does anyone look into making the led on arale work btw ?
<ogra_> (beyond: we still dont use the right initrd for arale)
<jibel> Pat discussed it on another channel 2 days ago but I didn't follow the discussion
<ogra_> the led or the initrd ?
<jibel> the LED
<ogra_> ah, k
<jibel> https://launchpad.net/ubuntu/+source/gtk+3.0/3.14.13-0ubuntu1 is the GTK-3.0 SRU, nothing for the phone
<ogra_> well, the initrd is more important imho ...
<ogra_> yeah,m i thought so
<popey> jibel: do we have an ETA for OTA-4?
<jibel> popey, when it is ready?
<jibel> popey, we are still validating the latest fixes
<popey> ok
<sil2100> popey: we anticipate mid next week
<popey> sil2100: ok
<jibel> rvr, any news on the upgrade test?
<rvr> jibel: Finishing the checks, but looks good so far
<jibel> rvr, which color is the LED when you receive a notification?
<rvr> jibel: Let me check that
<rvr> jibel: Green
<jibel> rvr, \o/
<rvr> jibel: Using the OTA tests in the spreadsheet, everything is ok.
<rvr> jibel: Logs, contacts, settings, images, apps, scopes...
<jibel> rvr, do you see duplicate icons or missing icons?
<rvr> No duplicate icons
<jibel> tedg, ^ you fix worked :)
<tedg> Woot!
<tedg> rvr, jibel, thanks for testing that in the upgrade testing!
<plars> alf_: Ursinha: not sure what happened with the mir test you requested, I'll check into it today
<plars> alf_: sorry for the delay, we have very limited capacity and there's not full 24 hour coverage of someone to watch for pings on irc
<alf_> plars: no worries, thanks
<kenvandine> cihelp: can i get CI setup for some 15.04 branches?  lp:content-hub/15.04 and lp:ubuntu-system-settings/15.04
<plars> kenvandine: I'll take a look in just a bit
<kenvandine> plars, thx
<kgunn> sil2100: so is vivid+ open?
 * Mirv back for a moment
<popey> http://ci.ubuntu.com/  is that actually used by anyone anymore?
<popey> cihelp: is it possible to get hold of /var/lib/jenkins/slaves/mako-15/workspace/vivid-touch_stable-mako-smoke-daily/touch/scripts/provision.sh
<popey> cihelp I'd like to learn how the devices are setup in the lab so I can test here the same way
<plars> popey: yep, take a look at http://ubuntu-test-cases-touch.readthedocs.org/en/latest/
<popey> oooh!
<popey> thanks plars
<plars> popey: the provision.sh script doesn't really have any magic. It's just ubuntu-device-flash, phablet-config, phablet-click-test-setup wrappered to try to be more resiliant against problems like random adb failures and dead hardware
<popey> plars: that's exactly what I needed, thank you.
<plars> popey: anytime, happy to help
 * Mirv approaches boarding time
<ogra_> safe flight
<Mirv> ok plane leavimg can't check html5-theme
<kgunn> trainguards ok, i need to changed silo4 from dual landing to wily (due to dialer app divergence)....can someone reconfig for me ??
<kgunn> line 22 in the sheet
<pmcgowan> ogra_, will you be around to kick an image build for us in a couple hours
<ogra_> couple = 2 ?
 * ogra_ cant guarantee much beyond 2-3h
<jibel> ogra_, it should be fine, we are waiting for silo 20 to land
<jibel> alesage, joc_ how much time do you need to verify it?
<alesage> jibel, having some DNS issues, just finishing a flash now, an hourish?
<alesage> jibel does that sound right for the test plan?
<joc_> jibel: i've just tried sil0 20 and looks a lot better switching between apps
<alesage> jibel, or less :)
<jibel> alesage, looking at the test plan it should be less :)
<alesage> jibel in process :)
<slangasek> ogra_, sil2100: get me a custom tarball that matches bq-aquaris.en that we can use on i386, and I'm happy to set up a generic_x86 channel; otherwise it's not meaningful to have it on that channel
<ogra_> slangasek, yeah, i thought so ... (and i doubt the apps and scopes in there achtually have x86 builds)
<slangasek> jibel: ^^
<sil2100> kgunn: I can do it but am on a train now
<ogra_> sil2100, is it a ci train ?
<sil2100> Worse
<sil2100> A PL Train
<sil2100> ;)
<ogra_> they dont crash at least :)
<sil2100> kgunn: can this wait approx 30 minutes?
<kgunn> sil2100: yeah, don't see why not
<sil2100> Thanks, not sure if my mobile 100 MB data plan would survive a train reconfigure
<plars> kenvandine: quick question, should the trunk branches lp:content-hub and lp:ubuntu-system-settings be built for wily now, and the 15.04 branches you specified for vivid?
<plars> kenvandine: or do you just care about the vivid ones?
<plars> alf_: hey, your test is now merged for cupstream2distro, let us know if you have any issues with it
<plars> alf_: it should just work now though
<alf_> plars: great, thank you
<cwayne> fginther: hi, how can I update the click chroot for node exp-worker-01?
<fginther> cwayne, it can't be done remotely. do you know what it's missing?
<cwayne> fginther: i think intltool
<fginther> cwayne, k, I'll try to get it added
<cwayne> fginther: also do we have a 15.04 chroot on there as well?
<fginther> cwayne, nope
<cwayne> can we :)
<fginther> cwayne, I'll add it to the list
<cwayne> fginther: thank you!
<dbarth> hey, sorry if it's a faq, but how do you guys deal with citrain device upgrade being overriden by the overlay ppa ?
<plars> alf_: actually, I forgot one bit, give me just a moment
<plars> alf_: ok, should be good now
<sil2100> kgunn: ok, the PL Train arrived, let me reconf
<kgunn> sil2100: soooo many trains :)
<pmcgowan> dbarth, there is a new version of the tool
<sil2100> kgunn: you sure you want that to be wily-only?
<sil2100> Is dialer so much differing?
<kgunn> sil2100: well, everytime i "wait for..." i lose....so yeah
<kgunn> sil2100: dialer is dep waiting ....cause contacts changed
<sil2100> Ah, ok, that one
<kgunn> so after i land, i'm gonna create a massive sync silo with my stuff and bill's together
<kgunn> for the moment of unthaw
<kgunn> or thaw rather
<kgunn> once vivid+ thaws...we'll sync it all
<sil2100> Reconfing
<kgunn> ta
<sil2100> :)
<sil2100> kgunn: should be done
<dbarth> pmcgowan: ok, i upgraded and will test once my device is flashed; thanks
<fginther> sil2100, slangasek, Can you provide guidance on the appropriate touch images to use for the proposed-migration boottest? ubuntu-touch/rc-proposed/bq-aquaris.en for vivid and ubuntu-touch/devel-proposed/krillin.en for wily?
<alesage> jibel, AlbertA, kgunn, passed silo 20 FWIW
<sil2100> fginther: hey! I think those two would be best - are boottests done on krillins?
<fginther> sil2100, yes, krillin only
<fginther> sil2100, if some other device needed to be added, the images would be updated then
<sil2100> fginther: yeah, in that case those two channels are good
<fginther> sil2100, thanks for confirming
<AlbertA> alesage: ack, thanks
<kenvandine> plars, yes
<kenvandine> plars trunk for wily and 15.04 branches for vivid please
<plars> kenvandine: ack
<kenvandine> plars, thx
<kenvandine> jgdx, ^^ FYI, those settings CI builds for trunk are running on vivid still, not wily
<kenvandine> forgot about that
<kenvandine> probably not why we're seeing issues, but just in case
<jibel> trainguards can you publish silo 20?
<jibel> robru, ^
<robru> jibel: looks like there was a manual upload to distro unfortunately
<robru> AlbertA: I'm going to need you to take this diff and add it as a new commit on one of your mir MPs, then rebuild: http://launchpadlibrarian.net/208231494/mir_0.13.1%2B15.10.20150520-0ubuntu1_0.13.1%2B15.10.20150520.1-0ubuntu1.diff.gz
<robru> AlbertA: or better yet, just push that commit direct to trunk and then rebuild
<robru> AlbertA: nm, I'll do it
<pmcgowan> robru, those versions are the same, what does it mean it changed
<robru> pmcgowan: not the same, the new version is +.1, and the diff shows everything infinity changed.
<pmcgowan> of I see it now
<cjwatson> robru: hopefully not exactly that diff, since it adds binary files that need to be extracted
<robru> cjwatson: what's wrong with the diff? I'm just going to take infinity's upload and sync it to trunk so the train is happy.
<cjwatson> Binary files /tmp/qA5g_PglyQ/mir-0.13.1+15.10.20150520/tests/unit-tests/test_data/libpowerpc.so and /tmp/5Hrx9J0eTt/mir-0.13.1+15.10.20150520.1/tests/unit-tests/test_data/libpowerpc.so differ
<cjwatson> Binary files /tmp/qA5g_PglyQ/mir-0.13.1+15.10.20150520/tests/unit-tests/test_data/libppc64el.so and /tmp/5Hrx9J0eTt/mir-0.13.1+15.10.20150520.1/tests/unit-tests/test_data/libppc64el.so differ
<cjwatson> you can't just run that through patch and expect it to synthesise the binary files, is all
<robru> oh
<robru> sooo
<robru> cjwatson: if I download the latest orig.tar and unpack it over trunk will it do the right thing?
<cjwatson> err maybe?  if it were me, I would just grab the source package from distro, unpack in temporary directory, copy those two files from it to trunk, bzr add, and apply rest of patch
<cjwatson> either way, diff against the uploaded source to make sure it actually matches at the end
<robru> cjwatson: yeah this looks really wrong. ok i'll try that
<AlbertA> robru: ok, so should I do anything?
<robru> AlbertA: not yet, thanks
<robru> AlbertA: will need you to do a basic smoketest after the rebuild happens
<AlbertA> robru: ok
<jgdx> kenvandine, gah
<jgdx> kenvandine, will that change?
<kenvandine> jgdx, yes, plars is taking care of that
<jgdx> kenvandine, sweet. Thanks
<kenvandine> np
<robru> jibel: pmcgowan: AlbertA: ok sorry for the delay, distro is merged back to lp:mir/0.13 (MP dest) and rebuild started: https://ci-train.ubuntu.com/job/ubuntu-landing-020-1-build/149/console
<robru> fingers crossed that there's no merge conflicts ;-)
<AlbertA> robru: thanks!
<robru> AlbertA: you're welcome
<robru> ok, merge looks good. time for breakfast!
<plars> kenvandine: jgdx: it's in the process of getting approved and merged. I'll ping you as soon as it's landed
<kenvandine> plars, cool, thanks
<plars> kenvandine: jgdx: the u-s-s and content-hub job changes are finished now
<kenvandine> plars, thx
<tedg> trainguards, Can I please get wily silos for lines 47 and 50?
<AlbertA> robru: silo 20 looks good. smoke tested on vegetahd vivid+overlay and wily
<robru> AlbertA: great, thanks
<robru> jibel: pmcgowan: published rebuilt silo 20
<robru> tedg: 8 and 16
<tedg> Great, thanks robru!
<robru> tedg: you're welcome
<kenvandine> cihelp: I'm seeing a bzr error in the CI jobs for lp:content-hub/15.04 that plars just setup https://jenkins.qa.ubuntu.com/job/content-hub-15.04-vivid-amd64-ci/1/console
<robru> kgunn: looks like your qtmir-gles packaging is off. ppa has 605, -gles is looking for 602 and failing to find it.
<kgunn> robru: yep....just now fixing that
<robru> kgunn: heh, k. I'm not sure why the error message is "build failed: 1", I should fix that
<kgunn> robru: hey, so i've got swap out MP's to do so (since mzanetti used his acct, instead of mir-team)....so i need to reconfig....but i can _just_ build the gles pkgs right ?
<kgunn> e.g. i don't have to rebuild all after a reconfig i hope
<robru> kgunn: yep you can just build one after a reconfig.
<kgunn> yeeehaw
<robru> brb, lunch
<kenvandine> cihelp: disregard, i kicked a rebuild and it worked fine, so not a configuration issue :)
<fginther> kenvandine, ah, yes. Looks like a transient launchpad oops (sorry, I thought plars was having a look, but it appears he's lost IRC).
<kenvandine> fginther, yeah, i had just thought it might have been a configuration issue since it was the first job since it was setup
<fginther> kenvandine, yep, it happens
#ubuntu-ci-eng 2015-06-06
<kgunn> trainguards can you reconfigure silo 4 ? changing back to dual landing....again
#ubuntu-ci-eng 2015-06-07
 * ogra_ sighs ... 10min boot after switching channels on my krillin from RTM to rc-proposed :(
#ubuntu-ci-eng 2016-06-06
<rvr> mardy: Hey. I checked that owncloud plugin works fine, but I can't see VK listed in System Settings > Accounts. I installed the package.
<mardy> rvr: do you see the "VK.com account tester" in your applications list?
<rvr> mardy: Ah, nope, I didn't install that
<rvr> That's why
<rvr> Ok
<mardy> rvr: yes, accounts are visible only if there's an app which can use them
<kdub> rvr, got approvals on the MPs in https://trello.com/c/TgBCQi3L
<kdub> also noted the bug that the silo failed on last time in the trello card (if you remember 2 mondays ago, the silo failed)
<rvr> kdub: Ack
<jgdx> robru, neat new building interface. Kinda miss having to press build twice though, maybe add it as opt-in/easter egg?
<Saviq> robru, hey, think you could include field diffs in the audit logs?
<robru> jgdx: lol
<robru> Saviq: yeah there's some issues with errors not being reported, I'm working on that
<robru> slangasek: sil2100: we meeting today? sil's email mentioned laptop problems
<slangasek> robru: I assume not unless sil2100 says otherwise or you have something that you need to cover today
<robru> slangasek: nah I think I'm good. I'm just doing a couple days of bugfixing before I start the next big chunk of parallelization
<oSoMoN> trainguards: why is silo 3 marked failed for automated signoff? Iâm not seeing any autopkgtest failure in the reports
<robru> oSoMoN: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-003/excuses.html see the ALERT
<robru> oSoMoN: so the version in your silo is lower than the version in xenial overlay.
<robru> oSoMoN: I guess you need to bump the version & reupload, or if those are the same package, just copy the xenial-overlay one into the silo, that'll satisfy britney
<oSoMoN> robru, re silo 3, thatâs not right, the version in xenial-overlay (1.14.7-0ubuntu2~xenial1) is lower than the version in the silo
<oSoMoN> robru, from what I understand britney is complaining because of the version in xenial-updates (1.15.7-0ubuntu0.16.04.1), but I donât understand why it would do that
<dobey> oSoMoN: because it's newer than your version
<robru> oSoMoN: apparently it's in xenial-security https://launchpad.net/ubuntu/+source/oxide-qt/1.15.7-0ubuntu0.16.04.1
<oSoMoN> but touch images give a higher priority to the overlay PPA, donât they?
<dobey> not simply
<robru> oSoMoN: yeah, in touch images. not when britney is evaluating silos, that's different.
<oSoMoN> whatâs the point of doing that, if that doesnât match a real-world scenario?
<dobey> needs to change, or we need to be better about ensuring security updates that go to released ubuntus end up in the overlay
<robru> oSoMoN: the point of running britney on silos is that it matches how britney is run on -proposed, so it would catch issues that would happen when the silo is published
<robru> oSoMoN: in this case the package wouldn't be published to xenial-proposed so this wouldn't come up
<dobey> robru: well, it should come up, because the security update should have been copied to the overlay PPA
<robru> dobey: but I mean when this silo is published, the overlay package will be copied to overlay without going through xenial-proposed, so the main xenial britney would never look at this scenario
<robru> oSoMoN: you can ask QA to ignore the failure and test the silo anyway.
<dobey> robru: right, but that doesn't change the fact that we're apparently missing a security update in the overlay
<oSoMoN> robru, I understand that, but as dobey points out, packages in silos go to -proposed only for yakkety, so complaining about xenial doesnât seem correct
<robru> dobey: the versioning of the silo package gives me the impression that it's the same package?
<robru> oSoMoN: running britney for non-yakkety was a design goal, since it was viewed as a bug that publishing to overlay sneaks around britney.
<oSoMoN> robru, dobey: yes, theyâre the same packages, weâre putting them in the silo precisely because security updates are not copied to the overaly
<oSoMoN> overlay
<oSoMoN> robru, I donât mean that we shouldnât be running britney, but somehow this kind of error shouldnât be considered a blocker
<dobey> oSoMoN: i guess you shouldn't have added the ~overlay1 here
<oSoMoN> robru, Iâll ask jibel to override that error tomorrow to proceed with QA validation anyway, thanks for the tip
<robru> oSoMoN: yeah if you'd just copied the identical package without changing the version then britney would have said it was fine since it's no-change same package.
<robru> oSoMoN: which it's not too late to do
<dobey> oSoMoN: it seems it should have just been a binary copy
<dobey> not sure where they were copied from though
<robru> oSoMoN: in fact I can do that for you now if you want
<oSoMoN> but we had been doing that (with the ~overlay1 suffix) when xenial was the devel series, and it never was a problem, in fact itâs the first time Iâm seeing this kind of error
<oSoMoN> robru, wait
<robru> oSoMoN: I've seen this before but I can't remember which packages it was
<robru> oSoMoN: munging the version number to ~overlay1 only makes sense if you specifically need to rebuild against overlay PPA contents which might differ from stock xenial. not sure if that's the case here
<oSoMoN> no, please donât do that, itâs not a binary copy because the version in the silo is built against the overlay PPA, which might have e.g. updated media-hub packages
<robru> ok
<dobey> it's just too bad there still isn't arm64 builds :-/
<oSoMoN> itâs coming
<dobey> eww
#ubuntu-ci-eng 2016-06-07
<oSoMoN> jibel, hey, can silo 3 be marked ready for QA validation? the automated tests signoff is marked failed because of https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-003/excuses.html , but thatâs harmless and a false warning really, given that the version of oxide-qt in xenial-security hasnât been copied over to the overlay PPA
<dbarth> sil2100: one thing i worry though is that enabling arm64 builds in a ppa will not be specific to a release
<dbarth> ie, we will have build failures when we upload releases for vivid and below
<jibel> oSoMoN, done
<oSoMoN> jibel, thanks!
<bzoltan> sil2100:  would you be able to merge that silo under the  https://requests.ci-train.ubuntu.com/#/ticket/1485 ?
<sil2100> bzoltan: let me take a look
<sil2100> bzoltan: do you know why that one autopkgtest is failing?
<sil2100> bzoltan: is that some temporary failure? Maybe a retry will help? Or is it a known regression somewhere else?
<bzoltan> sil2100: I do not see any regressing autopkg test.
<bzoltan> sil2100:  do I miss something?
<sil2100> http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#ubuntu-ui-toolkit
<sil2100> Regression in ubuntuone-credentials
<sil2100> I could re-run that if you suspect it's a transient issue
<bzoltan> sil2100:  must be a flaky test because here it did pass - https://requests.ci-train.ubuntu.com/static/britney/yakkety/landing-047/excuses.html
<bzoltan> sil2100:  a restart would be nice, yes, please
<bzoltan> sil2100: you are doing what Timo used to do for me :)
<sil2100> bzoltan: ok, let's wait and see if it passes, if it does it should migrate and auto-merge in a bit
<sil2100> If not we can dive in and then manually merge it
<sil2100> bzoltan: autopkgtest passed now, let's see if it migrates soon :)
<bzoltan> sil2100: \o/
<ChrisTownsend> trainguards: Hey, I set https://requests.ci-train.ubuntu.com/#/ticket/1506 to Lander Approved over 30 minutes ago and it's not running (yet).  How can I check to see if its queued to run?
<robru> ChrisTownsend: https://requests.ci-train.ubuntu.com/#/tickets?active_only&lander_signoff=Approved
<robru> ChrisTownsend: britney is quite slow, usually an hour iterate over all silos, so usually an hour before it notices a new one
<ChrisTownsend> robru: Ok, but can I tell if it's actually queued for britney to run or what the status of that job is from there?
<ChrisTownsend> robru: Ok, so another case of me being impatient again:)
<robru> ChrisTownsend: http://bazaar.launchpad.net/+branch/bileto/view/head:/britney/iterate.py#L39 here's the actual api endpoint uses to iterate over so as long as your ticket matches that, it'll go
<ChrisTownsend> robru: Ok, thanks
<robru> ChrisTownsend: you're welcome
<oSoMoN> plars, hey, the arale-02 slave of the system-apps jenkins instance is down (has been for quite a few days apparently), is it known?
<plars> oSoMoN: looking
<plars> oSoMoN: looks like it was continually trying to connect and failing for a while there, so it gives up after too many retries. Possibly IS had brought it down for an upgrade or something?
<plars> oSoMoN: should be up now
<oSoMoN> plars, awesome, thanks!
<dobey> robru: maybe change the UI so that it says "Queueing" or something, when there's no other status yet. or ideally changing the lander signoff would immediately trigger a britney run on that silo.
<robru> dobey: no can do. When i implemented the britney support initially goal was to run it in parallel but it OOMs with just a couple running, so it has to be limited just one run at a time
<robru> dobey: marking it Approved IS queueing it so I'm not sure why that needs extra status
<dobey> robru: because the autopkgtests status being totally blank for an hour or more is obviously confusing
<dobey> robru: which is why everyone always comes in here and asks what the status is, and you have to reply with the same answer over and over again :)
<robru> dobey: people just need to learn
<robru> dobey: fine I'll make it say queued.
<dobey> robru: i'll remember that the next time design tells me to change some UI :)
<robru> dobey: hey can you access the train? looks to me like train (prod + staging) and canonical irc have gone offlien
<dobey> robru: irc went down for me too
<robru> dobey: I can ssh into wendigo but I can't juju status
<dobey> and train seems down as well
<robru> dobey: should we ping somebody about this or just assume they've noticed...?
<dobey> robru: not sure, but i would presume IS might notice that everyone disconnected from IRC, assuming they are still connected
<robru> dobey: this is because I rolled out that 'queued' feature you wanted, took down the whole network! I blame you!
<dobey> but given the hour, i'd expect the people on this side of the pond to have noticed it died :)
<dobey> robru: hah. i was only suggesting the change, to help you spend less time answering the same requestion repeatedly :)
<dobey> although maybe now it will just be "why is my silo 'queued' for an hour?!"
<robru> dobey: yup, looking forward to that one
<ChrisTownsend> robru: Why is my silo queued for over an hour now?;-)
 * robru tears hair out
<robru> #is-outage: 09:59:54 <deej> Rolling out CUD r7435, once more with feeling
<robru> 10:14:16 Connection closed unexpectedly
<robru> heh
<ChrisTownsend> robru: But I think having some sort of feedback in that line is better than nothing, so I appreciate the change.
<dobey> ChrisTownsend: https://www.youtube.com/watch?v=Day3oxR9Efk
<ChrisTownsend> dobey: lol
<robru> heh
* robru changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? Use JenkaaS: http://bit.ly/jenkins-docs | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known issues: train offline due to catastrophic network failure
<pmcgowan> dobey, is xenial using qt 5.6
<dobey> probably
<dobey> pmcgowan: 5.5.1 still it seems
<pmcgowan> hmm
<pmcgowan> thanks dobey
* robru changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? Use JenkaaS: http://bit.ly/jenkins-docs | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known issues: -
<robru> Ugh, no queuebot
<ChrisTownsend> trainguards: I think the xenial i386 britney run is not really running or queued: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html
<robru> ChrisTownsend: indeed
<robru> ChrisTownsend: pitti is the only person i know that can fixit
<ChrisTownsend> robru: Ugh, and he's not around.
<robru> ChrisTownsend: yeah sorry.
<ChrisTownsend> robru: Not your fault.  Thanks.
<robru> ChrisTownsend: you're welcome
<ChrisTownsend> Wow, no silos are available: https://ci-train.ubuntu.com/job/prepare-silo/793/console
<tvoss> robru, o/
<robru> tvoss: ahoy
<robru> ChrisTownsend: fun times, I'll try to free a couple up
<ChrisTownsend> robru: Ok, thanks
<tvoss> robru, hey, could copy the packages from https://launchpad.net/~turbo-private/+archive/ubuntu/ppa to silo 41?
<robru> tvoss: sure
<tvoss> robru, thx
<robru> tvoss: that URL 404s tho
<tvoss> robru, try again
<robru> tvoss: I don't seem to have permission to copy packages from there
<tvoss> robru, just gave you access, please try again
<robru> tvoss: https://launchpad.net/~turbo-private/+archive/ubuntu/ppa/+packages "not allowed here"
<robru> tvoss: considering that I'm about to copy the packages into a public PPA, maybe just make the PPA public temporarily?
<robru> ChrisTownsend: ok I freed one try assigning now
<ChrisTownsend> robru: Ok, that worked.  Thanks!
<robru> ChrisTownsend: you're welcome
<dobey> robru: converting a PPA from private to public (or reverse) is not trivial i think.
<dobey> seems like people who are asking to copy packages from a private ppa though, should first just copy said packages to a public PPA somewhere, and then ask to copy from the public PPA. or something
<robru> dobey: meh, that would trigger an unnecessary rebuild
<dobey> robru: why? binary copy is binary copy
<robru> dobey: true.
<robru> ChrisTownsend: turns out you can get somebody from #ubuntu-release to retry those autopkgtests for you, just link them to the relevant excuses page.
<ChrisTownsend> robru: Ah, that's good to know.  I'm glad not just one person holds the keys to that:)
<robru> ChrisTownsend: yeah for a while now I thought it was just pitti, so I learned something today ;-)
<ChrisTownsend> robru: I sent a general message in there, so hopefully someone is around.  Thanks for pointing that out.
<robru> ChrisTownsend: you're welcome
<dobey> robru: what the heck. trying to rebuild a silo, and when i click the big build button it just shows me the log of the previous build, and doesn't actually do anything :-/
<robru> dobey: try reloading?
<dobey> i did
<robru> dobey: what ticket?
<dobey> robru: 1461
<robru> dobey: hmm one sec
<robru> dobey: ok I pushed a fix, try again in 5 minutes.
<dobey> ok
<robru> dobey: any luck?
<dobey> robru: seems to be doing stuff now
<dobey> robru: thanks
<robru> dobey: yay, sorry about that
#ubuntu-ci-eng 2016-06-08
<bzoltan> sil2100: robru: may i get a kick on this https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-014/excuses.html
<sil2100> bzoltan: looking
<sil2100> Oh, that one again
<sil2100> Kicked
<sil2100> dbarth: hey! This silo needs to be switched to a triple landing and re-built for yakkety: https://requests.ci-train.ubuntu.com/#/ticket/1344
<sil2100> dbarth, jibel: ^ I suppose such action shouldn't require any re-testing?
<oSoMoN> ubuntu-qa: hi guys, any chance silo 3 will be validated today?
<rvr> oSoMoN: Yes
<oSoMoN> great!
<pstolowski> uh, no silos available..
<pstolowski> robru, hey, it would be nice to display a 'no silos avail' message in the Status of the silo, it stays at 'New' if Assign fails
<sil2100> dbarth: ping
<bzoltan> sil2100:  may I ask for an other kick - https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-014/excuses.html
<sil2100> Done o/
<bzoltan> sil2100:  thank you, this time the unity8 was acting up :)
<dbarth> sil2100: pong
<sil2100> dbarth: did you see my message above about the silo?
<dbarth> sil2100: hmm, nope, just automated queuebot messages; what's up ?
<sil2100> dbarth: so https://requests.ci-train.ubuntu.com/#/ticket/1344 this would need to be converted to a triple-landing silo
<sil2100> SInce I can't release it as it is now
<sil2100> So changed to a trio-landing and the yakkety packages built (with a re-build)
<sil2100> This *shouldn't* require a QA re-test I would expect
<dbarth> sil2100: ah ok, i will do the change and rebuild
<sil2100> dbarth: thanks
<ChrisTownsend> sil2100: Are you able to kick stuck britney jobs?  The i386 job for https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html has already been re-tried once, so I'm not sure what is going on.
<ChrisTownsend> sil2100: Also, when it comes time to land that silo, we will need coordinate deprecating the ubuntu-pocket-desktop metapackage and the -pd channel in general.  We will need to see python3-libertine-chroot in the ubuntu image at that time.  But that landing will remove the libertine-demo package.
<ChrisTownsend> /s/see/seed
<sil2100> ChrisTownsend: ok, I have powers to re-try, not sure if I can do anything else
<ChrisTownsend> sil2100: ok, thanks
<ChrisTownsend> sil2100: Also, about -pd, ubuntu-app-launch already pulls in xmir, so that is already in the main ubuntu channel.
<sil2100> ChrisTownsend: as for PD - ok, in case I miss the silo landing, could you poke me as well once everything is ready for the ubuntu-pd channel deprecation?
<ChrisTownsend> sil2100: Absolutely!
<sil2100> Yeah, saw that last time I checked
<sil2100> THanks :)
<ChrisTownsend> sil2100: k, cool
<ChrisTownsend> sil2100: thank you too!
<ChrisTownsend> sil2100: Sorry to bother you again, but have you tried to kick https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html ?  I ask because I have to see it show up in http://autopkgtest.ubuntu.com/running.shtml.
<sil2100> ChrisTownsend: I couldn't deal with it myself, didn't manage to find a way of doing that, but pitti re-scheduled it just now
<ChrisTownsend> sil2100: Ok, thank you
<bzoltan> sil2100:  I am not sure if the previous attempt has finished already or it is a new flakiness -> https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-014/excuses.html
<sil2100> bzoltan: *sigh* I would expect it to be a new thing already
<sil2100> Let me retry once more
<rvr> oSoMoN: ping
<oSoMoN> rvr, hey, I just saw your comment on silo 3, testing again, Iâm pretty sure it was working for me when I tested with a bt keyboard
<rvr> oSoMoN: I also tried with an USB keyboard with the same result
<oSoMoN> rvr, just tested on arale with a bt keyboard, and Ctrl+- and Ctrl+0 work, Ctrl++ doesnât because the + is on the second level of the key (shift), but I suspect thatâs a bug somewhere else in the stack
<rvr> oSoMoN: With my USB keyboard, none work: +, - and 0
<oSoMoN> rvr, and with your bt keyboard?
<rvr> oSoMoN: Neither
<oSoMoN> rvr, mmmâ¦ it would be interesting to see if those shortcuts work in a simple QML scene
<oSoMoN> rvr, if I send you a simple test app, can you test in on your device?
<rvr> oSoMoN: of course
<oSoMoN> rvr, okay, give me a moment, Iâll create that for you
<oSoMoN> rvr, itâs taking me longer to create that test app than IÂ expected, but Iâm on it
<rvr> oSoMoN: Ack
* robru changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? Use JenkaaS: http://bit.ly/jenkins-docs | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known issues: low on silos, please ping trainguards if your ticket fails to assign
<awe> ping trainguards, need some assistance with https://requests.ci-train.ubuntu.com/#/ticket/1462
<robru> awe:  hi
<awe> hey...  it's me again
<awe> ;D
<robru> awe: what's up?
<awe> I seem to be in a rock in a hard place, whenever it comes to landing NM
<awe> so, the silo is marked for triple landing
<awe> however I've only uploaded vivid and xenial versions to the silo
<awe> for reasons previously described, I can't triple land the same code in all three places
<robru> awe: ok
<awe> ( and note, this will need to be discussed in the context of our PPA becoming a "generic" stable overlay PPA
<awe> but that's another conversation I'll pickup on the UES ml
<robru> awe: what?
<robru> awe: I'm not sure what you're needing help with but as far as I can see on the ticket, you need to get britney & qa approval, then I can copy those packages into the overlay ppa.
<awe> so just trying to figure out how to get britney approval
<awe> davmor2 is waiting to test
<awe> robru, I wasn't sure whether or not the lack of a y package, would cause the britney approval to stall; also this is one part of the landing process that I don't fully grok
<robru> awe: yeah I'm not sure how a missing yakkety package will affect britney. I think it'll just look at yakkety, see there's nothing there, and approve it because it's a no-op.
<robru> awe: so the thing about britney is that it iterates over each ticket in series, which is quite slow. last run took an 72 minutes. but that finished 20 minute ago, which means the new run should have picked up your ticket.
<awe> davmor2 ^^
<robru> awe: davmor2: so at some point in the next 50 minutes it should pop up with a result
<awe> ty
<davmor2> awesome news
<robru> awe: davmor2: however if there are autopkgtests, that means it'll only just have *started* the autopkgtests.
<awe> davmor2, guess I should've approved it last night!  That said, I wanted to ensure I had the Y mp submitted first.  hindsight...
<robru> awe: davmor2: https://requests.ci-train.ubuntu.com/static/britney/log_20160608_161001.txt here's the log if you want to watch it live, eventually you should see -077 in there.
<awe> cool
<davmor2> awe: hindsight is always 20/20 vision :)
<awe> indeed
<bzoltan> sil2100:  I know it is annoying... flaky tests are horrible. Would it be possible to kick only the vivid and yakketi tests?
<bzoltan> https://requests.ci-train.ubuntu.com/static/britney/yakkety/landing-014/excuses.html
<bzoltan> https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-014/excuses.html
<bzoltan> xenial is now clean... and now the other two are acting up
<dobey> robru: hrmm, seems like the new build stuff only takes the first line of commit messages now?
<robru> dobey: yes, wasn't it always like that?
<dobey> i don't think so
<robru> dobey: there was a build time option for "TAKE_WHOLE_COMMIT_MESSAGE" but the default thing was to truncate. I guess it truncated at the first blank line rather than just the first line.
<robru> dobey: anyway that value gets passed in to dch which forcibly re-wraps it, so passing in multiple lines probably isn't what you want.
<robru> or rather, probably won't do what you want
<dobey> well what i want/expect is for each line to be a new "* foo" line in the changelog.
<robru> dobey: hmmm
<dobey> well, non-blank line starting after each newline or something
<dobey> not sure how feasilble that is, given the tooling
<robru> dobey: well I mean I could iterate over the lines of that field rather than just truncating to the first line, I'm just wondering if your expectations match everybody else's though, that behavior might be quite a surprise to everybody else.
<robru> dobey: oh, no, that won't work, because it scans the source branch for linked bugs, and it would have no way to know which linked bug goes with which line of the commit message field. so you'd get "* foo (LP: #1)\n* bar (LP: #1)\n* grill (LP: #1)" in your changelog
<dobey> robru: well, it could only add it to the first line or something
<robru> dobey: if you're wanting tighter control of how your changelog comes out, you're better off just writing it yourself and leaving the commit message field blank. then it'll use debcommit so the bzr commit message matches what you wrote in the changelog
<dobey> robru: on the other hand, there's another issue where if the commit message has (LP: #foo) in it already, train still adds it to the end :)
<robru> yeah, so stop writing (LP: #foo) in your commit message field :-P
<dobey> well, i didn't
<dobey> i just noticed that, when someone else did
<dobey> i have long been an advocate of not duplicating that data in the commit message, since bzr has meatadata for storing it in the history
<robru> yeah
<dobey> oh well
<robru> awe: yeah, so autopkgtests are running now https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-077/excuses.html
<robru> awe: the blank yakkety result shouldn't interfere with the overall outcome.
<awe> thanks robru; been keeping an eye on it too
<robru> awe: you're welcome.
<robru> awe: sorry if I didn't explain it well before, when I said "you should see a result within 50 minutes", that includes "autopkgtests have started running" as "a result"
<robru> awe: not that it would be *completed* within those 50 minutes
<robru> heh
<jhodapp> robru, koza could use a hand in figuring this issue out with his silo: https://requests.ci-train.ubuntu.com/#/ticket/1376
<robru> jhodapp: you mean destination version missing?
<robru> jhodapp: or the britney failure?
<jhodapp> britney failure
<jhodapp> I just gave it a quick glance, so maybe it's something simple
<jhodapp> he's newer to the landing process though
<robru> jhodapp: so what it's saying there is that the destination version is newer than the silo version.
<robru> jhodapp: so this upload was published from a different silo but hasn't merged yet: https://launchpad.net/ubuntu/+source/ubuntu-system-settings/0.4+16.10.20160606-0ubuntu1
<robru> jhodapp: you'll need to wait for that to merge and then rebuild
<jhodapp> robru, cool thanks, I'll pass along the info
<robru> jhodapp: once it merges the silo status will say "needs rebuild due to new commits"
<jhodapp> yeah makes sense
<jhodapp> thanks robru
<robru> jhodapp: you're welcome. yeah here's the ticket that was just published: https://requests.ci-train.ubuntu.com/#/ticket/1507
<jhodapp> thanks
#ubuntu-ci-eng 2016-06-09
<robru> jhodapp: ^^ time to rebuild in case you missed that
<robru> jhodapp: also maybe ask koza to join this chat room so he can see the notices
<jhodapp> robru, yeah indeed, thanks
<robru> jhodapp: you're welcome
<bzoltan> robru: would you plese restart these flaky unity8 tests -> https://requests.ci-train.ubuntu.com/static/britney/ticket-1511/yakkety/excuses.htmlhttps://requests.ci-train.ubuntu.com/static/britney/ticket-1511/vivid/excuses.html
<robru> bzoltan: sorry, you need somebody from #ubuntu-release
<bzoltan> Saviq: these tests are more flaky then before. On xenial they are OK and they can be OK on Viviv and Yakketi too.
<robru> bzoltan: or any core dev. I can't do it
<bzoltan> robru: I see, thanks
<bzoltan> jibel: I would like the QA team to take the silo14 in the queue - https://requests.ci-train.ubuntu.com/#/ticket/1511 The tests ar all fine. I think it is not a good idea to block the silos with the autopkg tests as 99% of the failures are caused bz flaky tests.
<robru> bzoltan: britney tests other things than just autopkgtests so it's an important check to do, but fine to override on a case by case basis. saves QA a lot of time having to validate something that goes on to get stuck in -proposed.
<bzoltan> robru: The same tests passed on the same silo a day before ... the same tests pass on amd64 and fail on i386... the same tests pass fail 1 out of 3 runs on xenial and 4 time sout 5 on vivid .. but totally inconsistently.
<bzoltan> robru:  bad quality tests are waste of time to all.. to QA and to us too. These autopkg tests are known to be super flaky ... I would propose to make them a blocker for passing QA and not _ENTERING_ the QA queue.
<bzoltan> robru:  Once a silo enters QA queue it usually spends two days before somebody picks up... that two days would be perfectly enough to click retry like five times and get a full green britney result
<bzoltan> jibel: ^
<bzoltan> We are loosing valuable time with this problem :(
<jibel> bzoltan, flaky tests in unity8 were supposed to be fixed
<jibel> Saviq, ^ https://requests.ci-train.ubuntu.com/static/britney/ticket-1511/vivid/excuses.html
<jibel> bzoltan, someone from the unity8 team has to have a look first and understand why it's failing before forcing anything
<bzoltan> jibel: what I propose is that we change the process and instead of waiting and waiting and waiting ... we start doing the QA validation and in the meantime we investigate the flakiness. It is flakiness for sure... a stable test does not randomly fail and pass
<bzoltan> jibel: and i have been strugling with these britney flakinesses for long time.. it simple wastes time, lots of it. So I am not happy to be blocked by it.
<jibel> bzoltan, and then waste time of manual testers if it's a real problem.
<bzoltan> jibel: it is not a real problem... look at the excuses page. How it could be a real problem?
<bzoltan> jibel:  look. Xenial - https://requests.ci-train.ubuntu.com/static/britney/ticket-1511/xenial/excuses.html
<bzoltan> jibel:  full OK
<jibel> bzoltan, I agree flaky tests are a problem and are usually caused by bad tests, code or infrastructure but in any case they must be analyzed and fixed.
<bzoltan> jibel:  Yakketi - amd64 passes, i386 fails - https://requests.ci-train.ubuntu.com/static/britney/ticket-1511/yakkety/excuses.html
<bzoltan> jibel: Yakketi gels!!! amd64 fails and i386 passes :D That does not make sense at all
<jibel> I don't know if it makes sense or not, then environments are different
<bzoltan> jibel:  on Vivid - amd64  passes, gles amd64 passes, gles i386 fails ... taddaa i386 fails - https://requests.ci-train.ubuntu.com/static/britney/ticket-1511/vivid/excuses.html
<bzoltan> jibel:  I tell you, it does not make sense...
<jibel> bzoltan, tell it to the unity8 team
<bzoltan> jibel:  I do not suggest not to analyze and fix tem... I suggest not to block the UITK by this.
<jibel> bzoltan, if they explain why it's failing and why it's a false positive, then I'm fine to force the silo and start testing
<bzoltan> jibel: I have wasted a full day with asking people to restart those flaky tests.. sil2100 was kind and helping me out. Time is flowing ...
<bzoltan> jibel:  I do wish to spin off one more UITK release before the freeze, but if I am blocked by flaky britney then it will not happen... so less fixes and improvements fo to OTA12. That is why I am proposing that  when it is  clearly a flaky test then do not block the silo from QA, block it from releasing. So we do check the flakiness... but do parallel work, so we do not waste time.
<bzoltan> jibel:  the Unity8 team has a sprint in Montreal :( so they will not respond very soon and i doubt that their priority there is to fix flaky tests... also Mirv is out, so i do not even have anybody who could restart those tests.. except poor sil2100 who clearly not happy for strugling with flaky tests.
<alf> trainguards: Hi! https://requests.ci-train.ubuntu.com/#/ticket/1487 failed "Automated signoff" but it's not clear to me why and if it is a real problem that needs to be solved on my side.
<alf> trainguards: Will failing "Automated signoff" block it from being checked by QA?
<alf> trainguards: ah, it now changed to "Approved"
<Saviq> jibel, bzoltan, it's a bit of a constant effort, looking through http://autopkgtest.ubuntu.com/packages/u/unity8/ it does indeed look like we're doing well on that front, so we should look into the failure
<jibel> Saviq, thanks, I know the effort you team's doing to keep them green to not just flag failures as flaky and discard the results.
<mardy> trainguards: any idea why this is not landing? It was approved by QA about a week ago: https://requests.ci-train.ubuntu.com/#/ticket/1389
<sil2100> mardy: uh
<sil2100> mardy: looks like the autopkgtests are hanged or something
<sil2100> mardy: we only see silos as publishable when they're tested both by QA nad britney
<sil2100> Well, if QA approved it, I guess it's safe to land
<mardy> sil2100: yeah, I went to see the excuses and began to suspect that it was hanging
<sil2100> mardy: publishing now
<dbarth> sil2100, mardy: thanks
<dbarth> rvr too
<rvr> dbarth: You're welcome :)
<mardy> sil2100: thanks! And about the silo that we reconfigured for triple landing (https://requests.ci-train.ubuntu.com/#/ticket/1344) will landing be automatic or do we have to push some button?
<sil2100> In the middle of button pressing now ;)
<sil2100> seb128: hello! Sorry to bother you once again, but one landing adds 2 new binary packages (new account plugins for touch) - would need a binNEW sign-off: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-1344/2016-06-09_09:18:09/yakkety_account-plugins_packaging_changes.diff
<seb128> sil2100, hey
<seb128> sil2100, the binaries descriptions suck
<seb128> sil2100, the long description is even inconsistent between the new binaries
<seb128> it could also at least explain to what service it integrates to
<seb128> sil2100, the -vk says it's for GNOME control center ... is that true?
<seb128> that should at minimal be Unity Control Center
<seb128> I doubt it integrates with goa
<sil2100> hm
<sil2100> Strange descriptions indeed
<sil2100> dbarth, mardy: ^
<mardy> sil2100, seb128: can I fix them in a new branch? these have been waiting for a month already...
<sil2100> Have those been copy-pasted from somewhere or something?
<seb128> mardy, yes, but get the branch up for review and the debs are good to go
<mardy> sil2100: yes, I think all other plugins descriptions need changing
<mardy> seb128: you didn't file a bug already, did you?
<seb128> mardy, no
<mardy> seb128: OK, I'll file one then
<seb128> thanks
<mardy> seb128: bug 1590786, branch coming soon
<ubot5> bug 1590786 in account-plugins (Ubuntu) "Package descriptions need updating" [High,In progress] https://launchpad.net/bugs/1590786
<seb128> mardy, great
<sil2100> Ok, publishing in that case, if there are no other issues for the binNEW :(
<sil2100> *:)
<seb128> sil2100, mardy, yeah, let's publish, doesn't make much sense to block on that but let's assure the descriptions get fixed in the next landing
<sil2100> Publishing in progress
<sil2100> seb128: thanks!
<seb128> yw!
<mardy> \o/
<bzoltan> Saviq:  would you please retstart the failing tests  as start?
<Saviq> bzoltan, I can't, mterry, can you please recycle https://requests.ci-train.ubuntu.com/#/ticket/1511 - I'm looking into the failures there
<bzoltan> Saviq: mterry: thanks
<bzoltan> jibel:  would you please take that silo on the QA queue? As you see there are very few core-devs with upload rights around in our timezine, so the retry cycle is really slow... i am not kidding, it is blocking the UITK big time.
<mterry> bzoltan, Saviq: yakkety recycled.  xenity had no failures.  vivid says "You submitted an invalid request: Unknown release vivid"
<Saviq> wha
<Saviq> trainguards, know anything about â when trying to restart britney runs?
<sil2100> huh, I don't know much about these parts sadly, hope it's not related to the recent britney changes
<Saviq> jibel, bzoltan, mterry bug #1590810 - that's one
<ubot5> bug 1590810 in unity8 (Ubuntu) "Tutorial::test_tutorial{Left,Right}Finish flaky" [High,Triaged] https://launchpad.net/bugs/1590810
<Saviq> checking the second
<mterry> Saviq, thanks
<robru> Saviq: mterry: no idea re:"unknown release vivid", that's a question for pitti
<Saviq> yeah, pung him too
<robru> Great
<robru> sil2100: what recent britney changes do you mean? The thing i announced about not running britney on already-approved silos wouldn't have any impact on the retrier script, that's unrelated.
<sil2100> I thought so, don't know the code so don't know how things play with eachother
<Saviq> jibel, bzoltan, I wasn't able to reproduce the other failure, with or without the UITK silo, will keep a look out
<Saviq> both are restarted now in any case
<rvr> marcustomlinson: ping
<mzanetti> jibel, we've investigated why the unity8 tests are flaky in adt for silo 14. seems just raciness and we are working on fixes for it. it's not the uitk's fault. IMO you don't need to block silo 14 on that.
<mzanetti> bzoltan, ^
<jibel> mzanetti, thanks
<mterry> bzoltan, Saviq: I just tried to restart the vivid unity8 failure again, on the off chance, and it worked this time
<marcustomlinson> rvr: pong, sorry
<rvr> marcustomlinson: Hi
<rvr> marcustomlinson: I have to leave now, but I found some problems in silo 65
<rvr> marcustomlinson: With arale, NearBy scope reboots the phone on first boot and location prompt
<rvr> marcustomlinson: And also, the prompt doesn't show until I move to another scope
<rvr> marcustomlinson: I don't get that in turbo
<rvr> marcustomlinson: And I'm trying to confirm on krillin
<marcustomlinson> rvr: oh damn. Ok, eod for me too. Thanks man, will look into this tomorrow
<rvr> Ok
<marcustomlinson> rvr: pretty sure you won't see it on krillin. Pawel and I tested thoroughly on krillin
<Saviq> mterry, yeah, pitti fixed it
<mterry> nice
#ubuntu-ci-eng 2016-06-10
<rvr> bzoltan: Hi. In silo 14 there is merge proposal to disable unit tests for yakketti?? https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/ifeq_is_better_than_ifneq/+merge/296391
<bzoltan> rvr:  yes
<bzoltan> rvr:  actually it is enabling to all others ... the yakketi disabling landed last time
<rvr> bzoltan: Why is that? Unit tests must run everywhere.
<bzoltan> rvr: and no, we donot want to stop landing OTA UITK because the Yakketi tests are failing
<rvr> bzoltan: Why are Yakketi tests failing?
<bzoltan> rvr:  i do not remember ... not because we are doing shity code :) the tests pass on Vivid and Xenial
<rvr> bzoltan: Please, enable them and fix them.
<bzoltan> rvr: We will, but not now. If you want you can block the OTA12 because of that... but i would not do that. yakketi is not a priority target.. it is not released yet, so no app developer should target yakketi with UITK apps.
<bzoltan> zsombi:  I got to run now... would you help rvr please
<zsombi> rvr: we know that Yakketi tests are failing, but we have no time/resources to focus on that target yet. All we managed to do is to make the toolkit to be built, but afaik Yakketi is not a top requirement just yet. So we had not spent time with it as long as OTA bugs are more important to fix than Yakketi ones
<rvr> zsombi: Which problems did you find and how much time would it take to solve it?
<zsombi> rvr: QtQuick internals on binding handling was changed. We saw some GLES stuff being also changed. Fixing those would require us 2-4 weeks. The Qt we have in Vivid is 5.4, Yakkety has yet 5.6.
<rvr> zsombi: So, why are you targetting yakketi at all?
<zsombi> rvr: because Mirv wanted to see how the tripple landing works, to be able to track the Qt validation on UITK too
<zsombi> rvr: Mirv suggested to patch out the tests until we can fix them all
<rvr> zsombi: How can the Qt validation be tracked if tests are disabled? If you already know how triple landing works, enable the tests and do not target yakketi until you can work on it. Disabling the tests is a bad practice.
<bzoltan> rvr: securing that uitk builds is the first step. Qt is newer in Yakketi, that explains the test failure.
<zsombi> rvr: well, Qt validation is not only about the tests. First we need to see modules building. Next come the tests. There were other modules around which were not building either, and first round is to get the built. Next comes the testing. Yes, we will get them working. We've been doing this earlier, when we swictedh to Qt 5.2, to 5.4, and we will do in the future as well.
<zsombi> rvr: we never left a test disabled because we were not been able to run them. We re-enabled them as soon as we got driven to the new version, then we spent weeks to fix them, and we did it, re-enabled them, and ran them in full flavor.
<zsombi> rvr: so this would be a temporary solution
<rvr> zsombi: You can do that in a separate silo
<rvr> for yakketi
<rvr> Check that it builds, fix the tests, etc
<zsombi> rvr: bzoltan^
<zsombi> rvr: all I know is Mirv wanted us to do it like this
<rvr> And meanwhile, we land things that are known to pass tests
<bzoltan> rvr: please check with Mirv when he is back why he decided to land uitk like this.
<rvr> bzoltan: Ok
<bzoltan> rvr: not havint unit tests Ã¶n Yakketi does not represent any risk. We do know the reason of the failure.
<rvr> bzoltan: As Donald Rumsfeld said once: we know the things that we know, and we know there are some things we do not know. And tests do exist for those.
<rvr> If you begin to merge code that is not tested, then you do not know which problems you will find, and it is not assured that it will work. That usually ends with a big mess. We have seen this in the past.
<bzoltan> rvr: I guess you know that we never merge untested code. We do test for Trusty, Vivid and Xenial. All series what are official targets.
<jdstrand> pmcgowan: hi! I heard about a nm regression in ota11 and my phone seems affected. is there a silo for the fix? have you heard if it is safe? is it queued somewhere? (I'd like to install it)
<pmcgowan> jdstrand, whats your symptom, and let me find the silo
<pmcgowan> jdstrand, silo 77 has an NM update and fixes
<jdstrand> pmcgowan: that the network isn't always there
<jdstrand> I'm not sure how else to describe it
<pmcgowan> ok not sure whats exactly fixed there but thats the one
<jdstrand> ok, thanks! I'll read the changelog and see if that is what I'm seeing
<jdstrand> pmcgowan: I think it is 1579098
<jdstrand> and/or 1565717
 * ChrisTownsend *grumble* no more silos *grumble*
<dobey> mterry, kenvandine: can one of you publish https://requests.ci-train.ubuntu.com/#/ticket/1461 and ack the packaging changes please?
<mterry> looking
<dobey> thanks mterry
<robru> ChrisTownsend: try now.
<ChrisTownsend> robru: Got one now.  Thanks!
<robru> ChrisTownsend: you're welcome!
<mardy> trainguards: can you please have a look why this is still in the proposed pocket? https://requests.ci-train.ubuntu.com/#/ticket/1344
<robru> mardy: did you look? http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#account-plugins
<mardy> here it seems it's waiting for a dependency on ubuntu-system-settings-online-accounts, but that dep should be already there
<mardy> robru: ^
<mardy> robru: u-s-s-o-a is already in yakkety (it's been in Ubuntu for ages now)
<robru> mardy: I dunno then, you should ask with #ubuntu-release
<mardy> robru: OK, thanks, let's try...
<oSoMoN> robru, just saw your comment on https://code.launchpad.net/~timo-jyrinki/ubuntu-keyboard/stop_depending_on_transitional_packages/+merge/295045/comments/763387 , out of curiosity how will that work for git-based merge requests? afaik there is currently no way to link a bug report to a git branch
<robru> oSoMoN: well we'll cross that bridge when we come to it... if lp doesn't support linking bugs to git branches then you'll just have to type it into the commit message by hand.
<robru> oSoMoN: or send a patch to lp ;-)
<oSoMoN> okay
<robru> oSoMoN: in the context of that comment, "Commit Message" means "the MP web interface field called 'Commit Message', not the bzr commit message"
<robru> kenvandine: I'm eagerly awaiting content-hub's sister project: malcontent-hub. When is that going live?
<kenvandine> :)
<robru> kenvandine: to this day I see people talk about "foo and friends" and think they're talking about Friends
<kenvandine> lol
<cjwatson> robru,oSoMoN: It's not supported yet, but it's one of the things on our list for moving LP itself to git.
<cjwatson> robru,oSoMoN: The plan is actually to support linking bugs to merge proposals rather than to git branches directly (since they're much more lightweight than bzr branches, and it would get pretty unmanageable to link bugs to git repositories).
<robru> cjwatson: oh, nice. you got an ETA? git support in the train is still ~months away
<cjwatson> robru: No very precise ETA but it's probably the next thing I intend to pick up when I get a chance to take a tech-debt card
<cjwatson> Will hopefully beat you to it.
<cjwatson> Hmm.
<cjwatson> I don't think the plan to link MPs to bugs will work for what you're doing, though.
<cjwatson> Oh, maybe it will.
<robru> cjwatson: well we use lp api to query linked bugs from branches, should be easy to query MPs instead.
<cjwatson> I guess each changelog entry is typically a different MP.
<robru> cjwatson: yep, sometimes people write their own but if not, yeah, each bulet point is one mp
<cjwatson> Right, that should be fine then.
<robru> cool cool cool
<kdub> trainguards, failure to assign silo: https://requests.ci-train.ubuntu.com/#/ticket/1528
<kdub> any ideas? says its low on silos from the logs
<robru> kdub: yeah one sec I'll boot somebody else out
<kdub> thanks robru
<robru> kdub: ok, try now
<oSoMoN> cjwatson, cool, looking forward to that feature
<kdub> robru, same message
<kdub> robru, ah, 2nd time worked
<kdub> robru, thanks for the help
<robru> kdub: you're welcome
<robru> grumble empty error messages grumble
<dobey> grumble autopkgtests grumble
<robru> hmmm I wonder why britney would approve momentarily and then switch back to running...
<robru> oh, vivid always-failed, so it would approve based on vivid, then start other series and block on those
<robru> I should really fix that to not report anything until all series have run
<dobey> robru: eh, wish we could just make it faster
<robru> dobey: did you miss the memo I sent out explaining how I reduced the run times from 80 minutes to 20 minutes
<dobey> robru: that's great, but i meant more generally. like my silo was published 5 hours ago, and still stuck in proposed on y
<robru> dobey: oh, publishing is different. my speedup only affects the lead time from when you lander-approve to when britney first notices and runs on your silo
<robru> dobey: "stuck in proposed" can be a lot of different things, could be slow autopkgtests, could be tangled in some other complicated migration, etc.
<dobey> robru: well it's autopkgtests, which is why i'm complaining about it. :)
<robru> dobey: you should performance profile your autopkgtests then, that's not britney's fault :-P
<dobey> robru: but yeah, since merges to trunk are blocked on the packages going to archives, it adds slowness
<dobey> robru: it is when someone uploads php7 at the same time, and DoSes the hardware :)
<robru> dobey: yeah, that was a design decision so people wouldn't just fire-and-forget garbage into -proposed.
<robru> (blocking merges to trunk, not uploading php7)
<dobey> robru: well, since we have britney running autopkgtests for silos now, maybe we could relax that so that when stuff is in -proposed it'll merge to trunk?
<dobey> or do we have plenty of cases of people just dumping stuff into proposed and having it stuck there?
<dobey> OverLimit: Quota exceeded for cores,ram: Requested 1, but already used 30 of 30 cores (HTTP 413) (Request-ID: req-9f63af4f-984f-4eb1-990a-e7f6e6f6fa65)
<dobey> whee, that's lovely
<dobey> maybe i should just force merge this
<dobey> oh i don't have the job/build permission on jenkins it seems
<dobey> whatever that means
<dobey> :(
<robru> dobey: what?
<robru> dobey: oh yeah, you can't force merge, only core dev & I can do that
<dobey> robru: can you force merge https://requests.ci-train.ubuntu.com/#/ticket/1461 please?
<robru> dobey: explain why you want that
<dobey> robru: so i can rebuild my other silo, and because autopkgtests builders are apparently on overload and it's been waiting like 6 hours
<robru> dobey: ok so  you have another silo that'll be ready to publish soon-ish?
<dobey> robru: no, but i need to rebuild it to test it, and since this silo has already 'landed' in overlay, i don't want to get things in a weird state
<robru> dobey: ok but having something stuck in yakkety-proposed while trunk leaves it behind will be a weird state for yakkety.
<dobey> robru: how so? it's already in yakkety. it's just in -proposed rather than release.
<robru> dobey: exactly. once i merge, trunk will have things that are not in release.
<robru> dobey: anyway, it is done, but this is really a special case, not something you should do every time.
<dobey> robru: it won't have anything which hasn't been uploaded to ubuntu.
<dobey> which goes back to...
<dobey> 14:04 < dobey> robru: well, since we have britney running autopkgtests for silos now, maybe we could relax that so that when stuff is in -proposed it'll merge  to trunk?
<dobey> 14:04 < dobey> or do we have plenty of cases of people just dumping stuff into proposed and having it stuck there?
<robru> dobey: by force merging, you're essentially saying "I don't care that yakkety-proposed is broken, I'm ignoring that so I can work on something else"
<dobey> robru: but at that point, the way to fix it is with a new upload with a new changelog entry, ie, a new silo; not to overwrite the existing upload with something completely different and lose the changelog, since that would be against ubuntu/debian policy
<robru> dobey: no, we won't be relaxing it so that it can merge after it uploads to yakkety-proposed. the whole point of waiting for it to migrate is so that landers are made aware of when their uploads break devel series. If we allowed people to just fire-and-forget their devel uploads then devel would be chaos.
<robru> dobey: if yo resolve all the britney issues in-silo then you should have no trouble getting through yakkety-proposed.
<dobey> assuming the infrastructure hasn't exploded
<robru> dobey: that's what force-merge is for then, when you're sure the issue is the infrastructure and not your package.
<robru> dobey: not something we want to be the default case.
#ubuntu-ci-eng 2017-06-05
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2783 Failed to understand "https://code.launchpad.net/~mir-team/mir/0.26/+merge/324846". Is it a merge?
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2736 Preparing packages
-queuebot:#ubuntu-ci-eng- Saviq alan_g, https://bileto.ubuntu.com/#/ticket/2791 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g Saviq, https://bileto.ubuntu.com/#/ticket/2783 Failed to build
-queuebot:#ubuntu-ci-eng- Saviq alan_g, https://bileto.ubuntu.com/#/ticket/2791 Successfully built
-queuebot:#ubuntu-ci-eng- alan_g Saviq, https://bileto.ubuntu.com/#/ticket/2736 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2792 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2792 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2792 Diff missing
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2793 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2793 Successfully built
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2779 Failed to build
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2793 Publishing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2793 Publish failed: Bad merges
-queuebot:#ubuntu-ci-eng- alan_g Saviq, https://bileto.ubuntu.com/#/ticket/2783 Successfully built
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2793 Publishing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2793 Proposed pocket
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2793 Release pocket
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2794 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2794 Successfully built
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2794 Publishing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2796 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2794 Proposed pocket
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2794 Release pocket
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2796 Successfully built
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2755 Publishing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2755 Publish failed: Bad merges
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2755 Successfully built
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2796 Publishing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2796 Proposed pocket
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2796 Release pocket
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2797 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2792 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2792 Successfully built
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Publishing packages
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Publish failed: Bad merges
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Successfully built
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2797 Preparing packages
#ubuntu-ci-eng 2017-06-06
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2797 Cancelled build (artful/indicator-datetime). Ready to build (artful/signon-ui). Successfully built (artful/indicator-bluetooth, artful/indicator-power, artful/indicator-sound)
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2797 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2797 Failed to build (artful/indicator-datetime). Successfully built (artful/indicator-bluetooth, artful/indicator-power, artful/indicator-sound, artful/signon-ui)
<chatter29> hey guys
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2755 Publishing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2755 Proposed pocket
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2616 Pending binary packages
-queuebot:#ubuntu-ci-eng- alan_g Saviq, https://bileto.ubuntu.com/#/ticket/2736 Publishing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2755 Proposed pocket (artful/ubuntu-settings, artful/unity, artful/webapps-applications). Release pocket (artful/unity-asset-pool)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2616 Successfully built
-queuebot:#ubuntu-ci-eng- alan_g Saviq, https://bileto.ubuntu.com/#/ticket/2783 Publishing packages
-queuebot:#ubuntu-ci-eng- Saviq alan_g, https://bileto.ubuntu.com/#/ticket/2791 Publishing packages
-queuebot:#ubuntu-ci-eng- alan_g Saviq, https://bileto.ubuntu.com/#/ticket/2736 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- alan_g Saviq, https://bileto.ubuntu.com/#/ticket/2783 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- Saviq alan_g, https://bileto.ubuntu.com/#/ticket/2791 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2755 Release pocket
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2797 Publishing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2797 Publish failed: Failed to build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2792 Publishing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2792 Proposed pocket
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2797 Successfully built
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2797 Publishing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2792 Release pocket
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2797 Proposed pocket
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2797 Proposed pocket (artful/indicator-sound, artful/signon-ui). Release pocket (artful/indicator-bluetooth, artful/indicator-datetime, artful/indicator-power)
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2797 Proposed pocket (artful/signon-ui). Release pocket (artful/indicator-bluetooth, artful/indicator-datetime, artful/indicator-power, artful/indicator-sound)
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2797 Release pocket
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Publishing packages
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2680 Needs rebuild due to higher version at destination (xenial/indicator-session, xenial/unity8). Needs rebuild due to new commits (zesty/indicator-bluetooth, zesty/indicator-datetime, zesty/indicator-power, zesty/indicator-session, zesty/indicator-sound, zesty/unity8, zesty/unity8-desktop-session). Successfully built (xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-power, xen
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Proposed pocket
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2798 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2798 Pending binary packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2798 Successfully built
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2798 Publishing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2798 Proposed pocket
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2798 Release pocket
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Needs rebuild due to new commits
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Preparing packages
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Pending binary packages
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Successfully built
#ubuntu-ci-eng 2017-06-07
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Needs rebuild due to new commits
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Preparing packages
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Successfully built
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Publishing packages
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Proposed pocket
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2799 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- alan_g Saviq, https://bileto.ubuntu.com/#/ticket/2736 Proposed pocket
-queuebot:#ubuntu-ci-eng- alan_g Saviq, https://bileto.ubuntu.com/#/ticket/2783 Proposed pocket
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2800 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2800 Failed to build
-queuebot:#ubuntu-ci-eng- Saviq alan_g, https://bileto.ubuntu.com/#/ticket/2791 Proposed pocket
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2799 Diff missing (xenial/aodh, xenial/ceilometer, xenial/designate, xenial/heat, xenial/keystone, xenial/neutron). Pending binary packages (xenial/nova). Ready to build (zesty/aodh, zesty/ceilometer, zesty/designate, zesty/heat, zesty/keystone, zesty/neutron, zesty/nova)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2800 Dependency wait
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2799 Diff missing (xenial/aodh, xenial/ceilometer, xenial/designate, xenial/heat, xenial/keystone, xenial/neutron, xenial/nova). Ready to build (zesty/aodh, zesty/ceilometer, zesty/designate, zesty/heat, zesty/keystone, zesty/neutron, zesty/nova)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2800 DONE queue (xenial/debhelper). Dependency wait (xenial/glusterfs)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2801 Pending binary packages
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2802 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2800 DONE queue (xenial/debhelper). Failed to build (xenial/glusterfs)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2800 DONE queue (xenial/debhelper). Diff missing (xenial/dh-autoreconf). Failed to build (xenial/glusterfs)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2802 Diff missing
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Preparing packages
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Successfully built
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2802 Abandoning ticket
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2803 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2800 DONE queue (xenial/debhelper). Diff missing (xenial/dh-autoreconf). Pending binary packages (xenial/glusterfs)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2800 DONE queue (xenial/debhelper). Diff missing (xenial/dh-autoreconf, xenial/glusterfs)
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Publishing packages
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Proposed pocket
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2803 Diff missing (zesty/cinder, zesty/heat, zesty/horizon, zesty/keystone, zesty/neutron, zesty/neutron-fwaas, zesty/nova, zesty/swift). Pending binary packages (zesty/nova-lxd)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2800 DONE queue (xenial/debhelper). Diff missing (xenial/dh-autoreconf). Pending binary packages (xenial/glusterfs)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2803 Diff missing
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2800 DONE queue (xenial/debhelper). Diff missing (xenial/dh-autoreconf, xenial/glusterfs)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2766 Needs rebuild due to higher version at destination (zesty/nagios3). Proposed pocket (yakkety/nagios3). Updates pocket (xenial/nagios3)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2765 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2766 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2804 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2804 Abandoning ticket
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Preparing packages
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Successfully built
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2779 Failed to build
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Publishing packages
-queuebot:#ubuntu-ci-eng- sergiusens, https://bileto.ubuntu.com/#/ticket/2790 Proposed pocket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2805 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2805 Pending binary packages (xenial/sssd). Ready to build (zesty/sssd)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2805 Diff missing (xenial/sssd). Ready to build (zesty/sssd)
#ubuntu-ci-eng 2017-06-08
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2806 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2806 Currently building (artful/miral). Failed to build (artful/mir)
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2806 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2806 Failed to build (artful/mir). Successfully built (artful/miral)
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2806 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2806 Successfully built
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2806 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2806 Failed to build (artful/miral). Successfully built (artful/mir)
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2806 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2806 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2807 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2807 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2807 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2773 Needs rebuild due to higher version at destination (artful/dpdk). Successfully built (artful/openvswitch)
#ubuntu-ci-eng 2017-06-09
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2808 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2808 Ready to build
-queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/2809 Preparing packages
-queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/2809 Successfully built
-queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/2809 Publishing packages
-queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/2809 Proposed pocket
-queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/2809 Release pocket
#ubuntu-ci-eng 2018-06-04
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3281 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3281 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3281 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3281 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3280 Failed to build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3280 Failed to build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3280 Failed to build
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3282 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3282 Failed to build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3280 Currently building (cosmic/dpdk). Failed to build (cosmic/openvswitch)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3282 Failed to build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3280 Failed to build (cosmic/openvswitch). Pending binary packages (cosmic/dpdk)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3280 Diff missing (cosmic/dpdk). Failed to build (cosmic/openvswitch)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3280 Failed to build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3280 Currently building (cosmic/dpdk). Failed to build (cosmic/openvswitch)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3280 Diff missing (cosmic/dpdk). Failed to build (cosmic/openvswitch)
#ubuntu-ci-eng 2018-06-05
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3273 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3281 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3272 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3278 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3282 Failed to build
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3282 Failed to build
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3267 Publishing packages
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3267 Publish failed: Diff missing
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3267 Generating diffs
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3267 REJECTED queue (bionic/gst-plugins-bad1.0, bionic/gst-plugins-base1.0, bionic/gst-plugins-good1.0). Successfully built (bionic/gst-libav1.0, bionic/gst-plugins-ugly1.0, bionic/gst-python1.0, bionic/gst-rtsp-server1.0, bionic/gstreamer-editing-services1.0, bionic/gstreamer-vaapi, bionic/gstreamer1.0)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3267 Publishing packages
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3267 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3282 Failed to build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3280 Failed to build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3280 Currently building (cosmic/dpdk). Failed to build (cosmic/openvswitch)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3280 Failed to build (cosmic/openvswitch). Pending binary packages (cosmic/dpdk)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3280 Diff missing (cosmic/dpdk). Failed to build (cosmic/openvswitch)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3280 Diff missing (cosmic/dpdk). Failed to build (cosmic/openvswitch)
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/3283 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/3283 Pending binary packages
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3282 Failed to build
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/3283 Preparing packages
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/3283 Successfully built
#ubuntu-ci-eng 2018-06-06
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3282 Failed to build
-queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/3283 Abandoning ticket
#ubuntu-ci-eng 2018-06-07
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3044 Needs rebuild due to higher version at destination
#ubuntu-ci-eng 2018-06-08
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3267 Proposed pocket
#ubuntu-ci-eng 2020-06-01
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/4002 Diff missing (focal/bluez-firmware, focal/flash-kernel, focal/livecd-rootfs, focal/raspberrypi-wireless-firmware, focal/shim, focal/shim-signed, focal/snapd, focal/ubuntu-core-initramfs). Needs rebuild due to higher version at destination (focal/linux-raspi). Ready to build (focal/awscli, focal/python-botocore, focal/python-funcsigs, focal/python-jujuclient)
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/4002 Diff missing (focal/bluez-firmware, focal/flash-kernel, focal/livecd-rootfs, focal/raspberrypi-wireless-firmware, focal/shim, focal/shim-signed, focal/snapd, focal/ubuntu-core-initramfs). Needs rebuild due to higher version at destination (focal/linux-raspi). Pending binary packages (focal/unittest2). Ready to build (focal/awscli, focal/python-botocore, focal/python-funcsigs, focal/python-jujucl
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/4002 Diff missing (focal/bluez-firmware, focal/flash-kernel, focal/livecd-rootfs, focal/raspberrypi-wireless-firmware, focal/shim, focal/shim-signed, focal/snapd, focal/ubuntu-core-initramfs, focal/unittest2). Needs rebuild due to higher version at destination (focal/linux-raspi). Ready to build (focal/awscli, focal/python-botocore, focal/python-funcsigs, focal/python-jujuclient)
#ubuntu-ci-eng 2020-06-02
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4078 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4077 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4081 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4080 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/4053 Needs rebuild due to higher version at destination (groovy/openldap). Ready to build (groovy/sssd)
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4082 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4082 Failed to build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4081 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4081 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4081 Diff missing
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4082 Diff missing
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4082 Publish failed: Diff missing
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4082 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4082 Successfully built
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4082 Proposed pocket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4068 Needs rebuild due to higher version at destination (focal/qemu). Successfully built (focal/libvirt)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4081 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4082 Release pocket
#ubuntu-ci-eng 2020-06-03
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3997 Diff missing (focal/krita). Ready to build (focal/qt-gstreamer)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4055 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4083 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4083 Ready to build
#ubuntu-ci-eng 2020-06-04
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Preparing packages
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Pending binary packages
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Diff missing
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Dependency wait (groovy/liblxqt, groovy/lxqt-qtplugin). Diff missing (groovy/lxqt-build-tools). Pending binary packages (groovy/compton-conf, groovy/libqtxdg, groovy/libsysstat, groovy/lxqt-themes)
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Dependency wait (groovy/lximage-qt, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-config, groovy/lxqt-qtplugin). Diff missing (groovy/compton-conf, groovy/libfm-qt, groovy/liblxqt, groovy/libqtxdg, groovy/libsysstat, groovy/lxqt-build-tools, groovy/lxqt-themes). Pending binary packages (groovy/pavucontrol-qt, groovy/qtermwidget)
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Dependency wait (groovy/lxqt-qtplugin). Diff missing (groovy/compton-conf, groovy/libfm-qt, groovy/liblxqt, groovy/libqtxdg, groovy/libsysstat, groovy/lximage-qt, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-build-tools, groovy/lxqt-config, groovy/lxqt-themes, groovy/pavucontrol-qt, groovy/qtermwidget)
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Dependency wait (groovy/lxqt-qtplugin). Diff missing (groovy/compton-conf, groovy/liblxqt, groovy/libqtxdg, groovy/libsysstat, groovy/lximage-qt, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-build-tools, groovy/lxqt-config, groovy/lxqt-themes, groovy/pavucontrol-qt, groovy/qtermwidget). Pending binary packages (groovy/libfm-qt)
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Dependency wait (groovy/lxqt-qtplugin). Diff missing (groovy/compton-conf, groovy/libfm-qt, groovy/liblxqt, groovy/libqtxdg, groovy/libsysstat, groovy/lximage-qt, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-build-tools, groovy/lxqt-config, groovy/lxqt-themes, groovy/pavucontrol-qt, groovy/qtermwidget)
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Dependency wait (groovy/lxqt-qtplugin). Diff missing (groovy/compton-conf, groovy/liblxqt, groovy/libqtxdg, groovy/libsysstat, groovy/lximage-qt, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-build-tools, groovy/lxqt-config, groovy/lxqt-themes, groovy/pavucontrol-qt, groovy/qtermwidget). Needs building (groovy/libfm-qt)
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3997 Diff missing (focal/krita). Ready to build (focal/kitemmodels, focal/qt-gstreamer)
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Dependency wait (groovy/lxqt-qtplugin). Diff missing (groovy/compton-conf, groovy/liblxqt, groovy/libqtxdg, groovy/libsysstat, groovy/lximage-qt, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-build-tools, groovy/lxqt-config, groovy/lxqt-themes, groovy/pavucontrol-qt, groovy/qtermwidget). Uploading build (groovy/libfm-qt)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2264 Failed to build (xenial/ubuntu-app-launch). Needs rebuild due to new commits (zesty/ubuntu-app-launch). Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:libertine/trunk, xenial/lp:ubuntu-app-launch, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:libertine/trunk, zesty/lp:ubuntu-app-launch, zesty/to, zesty/update). Successfully built (xe
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Dependency wait (groovy/lxqt-qtplugin). Diff missing (groovy/compton-conf, groovy/liblxqt, groovy/libqtxdg, groovy/libsysstat, groovy/lximage-qt, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-build-tools, groovy/lxqt-config, groovy/lxqt-themes, groovy/pavucontrol-qt, groovy/qtermwidget). Pending binary packages (groovy/libfm-qt)
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Dependency wait (groovy/lxqt-qtplugin). Diff missing (groovy/compton-conf, groovy/libfm-qt, groovy/liblxqt, groovy/libqtxdg, groovy/libsysstat, groovy/lximage-qt, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-build-tools, groovy/lxqt-config, groovy/lxqt-themes, groovy/pavucontrol-qt, groovy/qtermwidget)
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Dependency wait (groovy/lxqt-qtplugin). Diff missing (groovy/compton-conf, groovy/liblxqt, groovy/libqtxdg, groovy/libsysstat, groovy/lximage-qt, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-build-tools, groovy/lxqt-config, groovy/lxqt-themes, groovy/pavucontrol-qt, groovy/qtermwidget). Pending binary packages (groovy/libfm-qt)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4085 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Dependency wait (groovy/lxqt-qtplugin). Diff missing (groovy/compton-conf, groovy/libfm-qt, groovy/liblxqt, groovy/libqtxdg, groovy/libsysstat, groovy/lximage-qt, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-build-tools, groovy/lxqt-config, groovy/lxqt-themes, groovy/pavucontrol-qt, groovy/qtermwidget)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4085 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4085 Diff missing
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Diff missing (groovy/compton-conf, groovy/libfm-qt, groovy/liblxqt, groovy/libqtxdg, groovy/libsysstat, groovy/lximage-qt, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-build-tools, groovy/lxqt-config, groovy/lxqt-themes, groovy/pavucontrol-qt, groovy/qtermwidget). Needs building (groovy/lxqt-qtplugin)
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/4053 Abandoning ticket
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/4087 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Diff missing (groovy/compton-conf, groovy/libfm-qt, groovy/liblxqt, groovy/libqtxdg, groovy/libsysstat, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-build-tools, groovy/lxqt-config, groovy/lxqt-themes, groovy/pavucontrol-qt, groovy/qtermwidget). Pending binary packages (groovy/lximage-qt, groovy/lxqt-qtplugin)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4085 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Diff missing
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/4087 Diff missing
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/4087 Diff missing (groovy/python-maxminddb). Pending binary packages (groovy/bind9)
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3997 Ready to build
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/4087 Generating diffs
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/4087 Pending binary packages (groovy/bind9). Successfully built (groovy/python-maxminddb)
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/4087 Successfully built
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/4087 Generating diffs
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/4087 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4088 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4088 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4088 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4088 Ready to build
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Dependency wait (groovy/lxqt-panel, groovy/lxqt-runner). Diff missing (groovy/compton-conf, groovy/libfm-qt, groovy/liblxqt, groovy/libqtxdg, groovy/libsysstat, groovy/lximage-qt, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-build-tools, groovy/lxqt-config, groovy/lxqt-qtplugin, groovy/lxqt-themes, groovy/pavucontrol-qt, groovy/qtermwidget). Pending binary packages (groovy/lxq
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Dependency wait (groovy/lxqt-panel, groovy/lxqt-runner). Diff missing (groovy/compton-conf, groovy/libfm-qt, groovy/liblxqt, groovy/libqtxdg, groovy/libsysstat, groovy/lximage-qt, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-build-tools, groovy/lxqt-config, groovy/lxqt-powermanagement, groovy/lxqt-qtplugin, groovy/lxqt-themes, groovy/pavucontrol-qt, groovy/qtermwidget). Pendin
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Currently building (groovy/lxqt-panel). Diff missing (groovy/compton-conf, groovy/libfm-qt, groovy/liblxqt, groovy/libqtxdg, groovy/libsysstat, groovy/lximage-qt, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-build-tools, groovy/lxqt-config, groovy/lxqt-globalkeys, groovy/lxqt-notificationd, groovy/lxqt-openssh-askpass, groovy/lxqt-policykit, groovy/lxqt-powermanagement, groovy
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Diff missing (groovy/compton-conf, groovy/libfm-qt, groovy/liblxqt, groovy/libqtxdg, groovy/libsysstat, groovy/lximage-qt, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-build-tools, groovy/lxqt-config, groovy/lxqt-globalkeys, groovy/lxqt-notificationd, groovy/lxqt-openssh-askpass, groovy/lxqt-policykit, groovy/lxqt-powermanagement, groovy/lxqt-qtplugin, groovy/lxqt-session, gro
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Diff missing
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Diff missing (groovy/compton-conf, groovy/libfm-qt, groovy/liblxqt, groovy/libqtxdg, groovy/libsysstat, groovy/lximage-qt, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-build-tools, groovy/lxqt-config, groovy/lxqt-globalkeys, groovy/lxqt-notificationd, groovy/lxqt-openssh-askpass, groovy/lxqt-policykit, groovy/lxqt-powermanagement, groovy/lxqt-qtplugin, groovy/lxqt-runner, groo
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Diff missing
#ubuntu-ci-eng 2020-06-05
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Generating diffs
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Publishing packages
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Proposed pocket
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Proposed pocket (groovy/compton-conf, groovy/libfm-qt, groovy/libqtxdg, groovy/libsysstat, groovy/lximage-qt, groovy/lxqt-about, groovy/lxqt-admin, groovy/lxqt-build-tools, groovy/lxqt-notificationd, groovy/lxqt-openssh-askpass, groovy/lxqt-policykit, groovy/lxqt-qtplugin, groovy/lxqt-runner, groovy/lxqt-session, groovy/obconf-qt, groovy/pavucontrol-qt, groovy/pcmanfm-qt, groovy/qp
-queuebot:#ubuntu-ci-eng- tsimonq2, wxl, kc2bez, https://bileto.ubuntu.com/#/ticket/4084 Release pocket
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4088 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4083 Diff missing (groovy/adwaita-icon-theme, groovy/mutter). Ready to build (groovy/gtk+3.0)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4083 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4083 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4088 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4088 Publishing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4088 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4090 Pending binary packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/4090 Diff missing
#ubuntu-ci-eng 2020-06-06
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4091 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
#ubuntu-ci-eng 2020-06-07
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4091 Dependency wait (groovy/breeze, groovy/breeze-gtk, groovy/kde-cli-tools, groovy/khotkeys, groovy/kmenuedit, groovy/kscreen, groovy/ksysguard, groovy/kwayland-server, groovy/kwin, groovy/oxygen, groovy/plasma-desktop, groovy/plasma-integration, groovy/plasma-vault, groovy/plasma-workspace, groovy/powerdevil, groovy/systemsettings). Diff missing (groovy/plasma-nm, groovy/plasma-workspace-wallpape
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4091 Dependency wait (groovy/breeze-gtk, groovy/kde-cli-tools, groovy/khotkeys, groovy/kmenuedit, groovy/kwin, groovy/plasma-desktop, groovy/plasma-integration, groovy/plasma-workspace, groovy/powerdevil, groovy/systemsettings). Diff missing (groovy/bluedevil, groovy/breeze, groovy/breeze-grub, groovy/breeze-plymouth, groovy/drkonqi, groovy/kactivitymanagerd, groovy/kde-gtk-config, groovy/kdecoratio
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4091 Dependency wait (groovy/kde-cli-tools, groovy/khotkeys, groovy/kmenuedit, groovy/plasma-desktop, groovy/plasma-workspace, groovy/powerdevil, groovy/systemsettings). Diff missing (groovy/bluedevil, groovy/breeze, groovy/breeze-grub, groovy/breeze-gtk, groovy/breeze-plymouth, groovy/drkonqi, groovy/kactivitymanagerd, groovy/kde-gtk-config, groovy/kdecoration, groovy/kdeplasma-addons, groovy/kgamm
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4091 Dependency wait (groovy/kde-cli-tools, groovy/khotkeys, groovy/kmenuedit, groovy/plasma-desktop, groovy/powerdevil, groovy/systemsettings). Diff missing (groovy/bluedevil, groovy/breeze, groovy/breeze-grub, groovy/breeze-gtk, groovy/breeze-plymouth, groovy/drkonqi, groovy/kactivitymanagerd, groovy/kde-gtk-config, groovy/kdecoration, groovy/kdeplasma-addons, groovy/kgamma5, groovy/kinfocenter, g
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4091 Dependency wait (groovy/kde-cli-tools, groovy/khotkeys, groovy/kmenuedit, groovy/plasma-desktop, groovy/powerdevil, groovy/systemsettings). Diff missing (groovy/bluedevil, groovy/breeze, groovy/breeze-grub, groovy/breeze-gtk, groovy/breeze-plymouth, groovy/drkonqi, groovy/kactivitymanagerd, groovy/kde-gtk-config, groovy/kdecoration, groovy/kdeplasma-addons, groovy/kgamma5, groovy/kinfocenter, g
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4091 Diff missing (groovy/bluedevil, groovy/breeze, groovy/breeze-grub, groovy/breeze-gtk, groovy/breeze-plymouth, groovy/drkonqi, groovy/kactivitymanagerd, groovy/kde-cli-tools, groovy/kde-gtk-config, groovy/kdecoration, groovy/kdeplasma-addons, groovy/kgamma5, groovy/khotkeys, groovy/kinfocenter, groovy/kmenuedit, groovy/kscreen, groovy/kscreenlocker, groovy/ksshaskpass, groovy/ksysguard, groovy/k
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4091 Diff missing
