#ubuntu-ci-eng 2013-10-28
 * ogra_ will not make this mornings landing team meeting (got to get a sick cat to the vet), but i will do smoke testign for image #6 on maguro right after i return 
<popey> ogra_: #6 seems good to me.
 * ogra_ just returned from the vet ... will test soon
<ogra_> the dashboard doesnt look so good though
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<sil2100> hmm, I wonder what's up on the mir front exactly
<sil2100> Since I see a u-s-c mir dependency bump failed autolanding, I see u-s-c disabled from cu2d-config - along with platform-api
<sil2100> Not sure if I should re-enable u-s-c and platform-api already
<sil2100> Didn't get a solid 'go for it' from Kevin
<ogra_> sil2100, did you guys have the meeting this morning (i couldnt come as i mentioned above )
<ogra_> (oh, i just notice you only joined after i pinged the channel)
<sil2100> ogra_: I probably missed it, since I thought we were having meetings at 10:30 of my time, this one was probably one hour before that - wasn't informed of it
<ogra_> well, i was ignoring the broken gcal and assuming we'd have it at 10:30 (but couldnt come due to a vet appontment)
<ogra_> DST and gcal are ususally a big fail anyway
<sil2100> Ah, time changes...
<sil2100> Well anyway, I wasn't on any meeting today sadly - not sure who was on it in the end
<ogra_> i doubt anyone was then
 * ogra_ thought lool would return today 
<sil2100> ogra_: do you know if the merger uses the daily-build PPA right now in any way?
 * sil2100 would need fginther
<ogra_> no idea, sorry
<ogra_> yeah, i was about to mention him :)
<fginther> morning
<fginther> sil2100, morning
<sil2100> fginther: morrrning!
<sil2100> fginther: my question to the usage of daily-build is related to this merge: https://code.launchpad.net/~mterry/unity-system-compositor/bump-mir-0.1.0/+merge/192701
<sil2100> fginther: the merge seems to be failing because of missing dependencies, while lp:mir and daily-build have mir 0.1.0 already
<fginther> sil2100, looking
<fginther> sil2100, the mir stack is configured not to use the daily-build ppa. Tryng to figure out why...
<sil2100> fginther: maybe in the past it was causing some problems, Didier would probably know more
<fginther> sil2100, the commit comment indicates a launchpad connection issue. But I can't recall the details... I'll renable it
<sil2100> fginther: thanks! I guess this would help us with getting this in and pushing on the transition
<fginther> sil2100, merged now
<sil2100> fginther: thanks again!
<plars> ogra_, asac: Not sure who else would be interested - webbrowser on mako seems to inconsistent at times still, passed on maguro, but failed all on mako. I reran and down to one failure on mako though
<plars> this is for image 6
<ogra_> plars, great, thanks
<plars> ogra_: I'll probably give it a few more retries
<plars> ogra_: we aren't having the landing meeting today right?
<ogra_> yeah, even though the test should be fixed (or the app or whatever the cause is here)
<ogra_> plars, not sure, if there was one this morning, i couldnt attend it due to a personal emergency
<ogra_> and i dont know if we need one this evening ...
<plars> asac, ogra_: I'll try to just watch the pipeline spreadsheet extra  close, but if we could have some extra communication about builds as they are decided on, it might be helpful this week
<ogra_> yep
<plars> I don't see anything marked for 7 at the moment, so I'm guessing we won't see one until much later today at the earliest
<ogra_> well, i might be traveling from wed. on
<ogra_> (depends if the cat recovers, else i'll stay at home)
<plars> ok
<lool> ogra_: I'm in Oakland
<lool> ogra_: so TZ wise, 2 hours ago was a bit early  :-)
<lool> it's 7amish here
<ogra_> pfft, just live your jetlag
<ogra_> :)
<ogra_> lool, i didnt knwo you are in oakland though :)
<popey> Everyone should stay on UTC, no matter where they are. Simple.
<ogra_> yeah
<ogra_> oh, awesome ... reloading http://reports.qa.ubuntu.com/smokeng/trusty/touch/ i can re-generate OOPS-IDs
<ogra_> :P
<ogra_> cjohnston, ^^^ is there a server down ?
<cjohnston> ogra_: looking
<plars> yeah, webbrowser completely passes now
<ogra_> yay
<plars> ogra_: I should have the .crash stuff working better and uploading properly by the next image
<ogra_> wow, cool
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: dashboard is down
<ogra_> cjohnston, seems to be back
<cjohnston> thanks ogra_
<ogra_> plars, what do you think about filemanager on maguro ... would that be worth retrying ?
<ogra_> (seems to have two more fails than #5)
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team: http://goo.gl/PNMH8c | Vanguard: cjohnston | Known issues: - | Landing instructions: Landing instructions: http://goo.gl/8H1Du3 | Please use #ubuntu-ci-eng for anything that isn't private information | Bugs to http://goo.gl/a7ndbb
* fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team: http://goo.gl/PNMH8c | Vanguard: fginther | Known issues: - | Landing instructions: Landing instructions: http://goo.gl/8H1Du3 | Please use #ubuntu-ci-eng for anything that isn't private information | Bugs to http://goo.gl/a7ndbb
<fginther> cjohnston, are you still working any cihelp issues?
<cjohnston> no sir.. just filling out an incident log
<plars> ogra_: ping
<ogra_> plars, just ask :)
<plars> ogra_: weren't we supposed to get a phablet-tools fix around build 6 also?
<plars> ogra_: I know it's not really part of the image
<ogra_> i think that landed already
<plars> ogra_: but we were waiting on it so we could land some other things
<plars> ogra_: I don't think so, I don't see an update in the ppa at least since 1022
<doanac> its also not update in-archive on saucy
 * ogra_ knows he approved at least two commits for the last package 
<doanac> ogra_: a commit went through: http://bazaar.launchpad.net/~phablet-team/phablet-tools/trunk/revision/213#debian/changelog
<ogra_> doanac, yeah, thats the one i mean
<doanac> but my saucy still has a version from 20131016
<ogra_> and i see it on trusty-changes ftom friday
<plars> ogra_: oh, and on filemanager (sorry was in a meeting earlier) I can retry it, but it's *very* inconsistent. If you look at the graph of previous builds, it's all over the place. psivaa already reran it once to get it down to that
<ogra_> doanac, oh, you probably want to ask someone to enable saucy builds for the PPA then
<ogra_> seems that was missed after release
<doanac> ogra_: note the precise PPA hasn't built either
<plars> I mentioned that on friday, not sure who would do that
<ogra_> hmm
<plars> doanac: you could use the citeam ppa if you want newer also. Maybe we should just use that for phoenix?
 * ogra_ has no idea how that level of builds works 
<doanac> ogra_: no worries. I'll bother fginther now
<ogra_> doanac, i think sergiuens might know some thing more
<doanac> sergiuens, fginther: seems like phablet-tools PPA isn't updating for precise
<doanac> (or any other releases)
<ogra_> i know he initially set that stuff up (or at least aksed the right people to do it for him)
<fginther> doanac, looking
<doanac> plars: agree, but also want to make sure we get this sorted out in the real PPA since it has an important bug fix
<plars> ogra_: I know one thing on the filemanager tests psivaa was looking at earlier was a path issue and due to other tests dropping files around, and we're hoping that the modification in phablet-tools might help with that also
<plars> doanac: yes
<ogra_> plars, well. its in the archive since friday
<ogra_> plars, or are you using saucy over there ?
<plars> ogra_: on the ci server, no it's precise
<ogra_> oh
<fginther> plars, doanac, 1.0+14.04.20131025-0ubuntu1 is now being published to the ppa
<plars> fginther: cool
<cyphermox> Mirv: https://code.launchpad.net/~mathieu-tl/platform-api/changelog-fix/+merge/192899
<sil2100> cyphermox: thanks! Just noticed this one ;)
<cyphermox> aye
<cyphermox> I only just tried to rebuild it
<Mirv> cyphermox: approved
<sil2100> cyphermox: approved
<cyphermox> hold on, sil2100, I'll have a merge for you too ;)
<Mirv> sil2100: too late :)
<sil2100> Mirv: 5 second difference between our approvals :D
<ogra_> oh, hmm
 * ogra_ notices that he has two conflicting meetings now 
<sil2100> cyphermox: can I respin the platform stack?
<sil2100> cyphermox: (changelog merge is in)
<cyphermox> please don't
<cyphermox> I'll take care of it shortly
<cyphermox> sil2100: https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/mir-abi-bump-testing/+merge/192901
<sil2100> cyphermox: cool
<sil2100> cyphermox: approved, thanks
<sil2100> cyphermox: anyway, desktop with xmir looks good here as well
<sil2100> So I guess a +1 from my side as well
<sil2100> Ah, we don't have the meeting today it seems ;)
<ogra_> yeah
<ogra_> i dont see anyone els e
 * ogra_ goes to the other meeting then 
<ogra_> plars, uh, what happened ? the maguro tests went for 38 failures to 52
<ogra_> wow, filemanager testing seems to be really bad :/
<plars> ogra_: yeah, I'm rerunning it again
<plars> ogra_: told you it was bad :)
<ogra_> heh, yeah i should have listened
<plars> balloons: file manager is really all over the place
<plars> balloons: http://10.97.0.1:8080/job/trusty-touch-maguro-smoke-ubuntu-filemanager-app-autopilot/
<plars> psivaa: ^
<balloons> plars, I intended to get back to looking at these this week
<balloons> there are other things in the world I have to look at sometimes ;-p
<plars> balloons: I know :)
<balloons> anyways I'll look at file manager now, for psivaa's sake :-)
<psivaa> why is that for my sake :)
* fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team: http://goo.gl/PNMH8c | Vanguard: - | Known issues: - | Landing instructions: Landing instructions: http://goo.gl/8H1Du3 | Please use #ubuntu-ci-eng for anything that isn't private information | Bugs to http://goo.gl/a7ndbb
 * fginther will be out for about 1 hour
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: - Type: "cihelp" for help | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<cyphermox> Mirv: sil2100: robru: https://code.launchpad.net/~mathieu-tl/cupstream2distro-config/unity-system-compo-reenable/+merge/192922
<psivaa> plars: the filemanger test are back to 3 failures now, i had to delete 'Renamed File' as well before running
<sil2100> cyphermox: right, I redeployed with that re-enabled, but if you did any redeploys recently then it got reverted
<psivaa> plars: balloons: this 'Renamed File' is supposed to be deleted in the tests but that's being left unclean as well.
<cyphermox> sil2100: I just did redeploy with it enabled again, so no worries
<balloons> psivaa, duely noted
<psivaa> plars: so what's happening when more entries are present in /home/phablet/ is that any new files or folders that the tests create are created at the bottom of the list
<psivaa> and that they are not visible for any folder operations like 'press and hold' to bring up the pop over toolbar.
<psivaa> plars: this is making all those uncertain failures
<sergiusens> fginther, are you writing retries for https://jenkins.qa.ubuntu.com/job/phablet-tools-trusty-i386-autolanding/7/console too?
 * ogra_ hugs plars 
<ogra_> you rock !!!
<ogra_> 35 fails for image 6 on both devices
<fginther> sergiusens, ugh
<fginther> sergiusens, yes, that bzr code is wrapped in a retry loop, but it looks like it either needs to retry/wait longer or something else is borked
<plars> ogra_: psivaa deserves much of that credit, he got the filemanager stuff working a bit better :)
* fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: fginther Type: "cihelp" for help | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<cyphermox> Mirv: robru: how did your results look for unity8 autopilot tests?
<Mirv> (mako 22/22 pass, maguro 20/22 pass)
<cyphermox> robru: http://www.youtube.com/watch?v=BYBw_o_2nG0
<cyphermox> s/banana/cookies/g
<Mirv> cjwatson: hi, we're missing unity8 in some limbo. it was published from cu2d around 20mins ago and now checked by didier as well and tried to be republished 5mins ago (without errors), still we're not seeing it in anywhere.
<Mirv> cjwatson: the unity-mir that was published at the same time is there and several packages after that
<cjwatson> Mirv: what version number?
<Mirv> cjwatson: 7.83+14.04.20131028-0ubuntu1
<cjwatson> <PlainPackageCopyJob to copy package unity8 from ubuntu/daily-build, RELEASE pocket, in ubuntu trusty to ubuntu/primary, PROPOSED pocket, in ubuntu trusty, including binaries>
<cjwatson> raised CannotCopy:
<cjwatson> unity8 7.83+14.04.20131028-0ubuntu1 in trusty (source has no binaries to be copied)
<cjwatson> that suggests somebody tried to copy it before it was built?
<cjwatson> Indeed it failed to build everywhere
<cjwatson> https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages?field.name_filter=unity8&field.status_filter=published&field.series_filter=
<cjwatson> No idea why this passed cu2d but it shouldn't have done :-)
<Mirv> cjwatson: sudden sense of revelation in this table
<cjwatson> :-)
<cjwatson> Looks like maybe just retrying those builds would work - maybe it was tried before unity-mir was built/published
<Mirv> cjwatson: sorry for the noise, and thanks. maybe that log some day could be parsed/outputted somewhere?
<cjwatson> Yeah, it's fiddly but possible
<cjwatson> It does get mailed but it'd go to the archive robot which is a mailbox I never read
<cjwatson> For inter-PPA copies it gets shown in the web UI but not for copies to primary
<cyphermox> pretty sure that's the exact reason
<cyphermox> Mirv: it's most likely because I told you to go ahead and kill off the follow-up jobs to check that things were built and published, so that you could go ahead with starting the unity8 build
<Mirv> right
<thomi> fginther: any way you can seed the ppa:autopilot/experimental PPA with a full compliment of trusty packages please?
<cyphermox> since we were doing manual testing, it was fine for *that*, kind of
<cyphermox> but tbh I didn't have unity8 in my list, I'll add it
<fginther> thomi, sure, I can't get to it right now, but can have it done by tomorrow
<thomi> thanks man
* fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: - Type: "cihelp" for help | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<Mirv> hopefully of course all this manual testing is a thing of the past soon enough
<popey> lol
<cjwatson> if anyone's watching this time, I made a request on Friday
<cjwatson> 17:13 <cjwatson> I've got a new packagekit upstream I'd like to upload, merged from Debian; I've tested it on grouper and click handling still seems to work as I'd expect
<cjwatson> 17:13 <cjwatson> any objections or shall I go ahead?
<cjwatson> 17:13 <cjwatson> not especially major changes
<cjwatson> 17:13 <cjwatson> http://paste.ubuntu.com/6301459/
<popey> â»
#ubuntu-ci-eng 2013-10-29
<xnox> Why has the https://bugs.launchpad.net/ubuntu/+source/indicator-bluetooth/+bug/1241539 not been released to trusty yet?
<ubot5> Ubuntu bug 1241539 in indicator-sound (Ubuntu) "ubiquity-dm is missing keyboard, input, sound, system indicators" [High,Triaged]
<xnox> (all linked branches)
<xnox> I need those fixes in the distro for the desktop installer (touch unrelated), shall I cherry-pick indicator-profile configs and upload into the archive?
<Mirv> xnox: I believe we're still in manual mode, ie. you need to add to the Landing Asks page
<Mirv> plus a lot of stuff was blocked by Mir transition which has now been just released (in proposed)
<xnox> ogra_: didrocks: please release indicators, including changes introduced by merge proposals linked on the bug 1241539.
<ubot5> bug 1241539 in indicator-sound (Ubuntu) "ubiquity-dm is missing keyboard, input, sound, system indicators" [High,Triaged] https://launchpad.net/bugs/1241539
<xnox> Mirv: I see, thanks for the head's up.
<xnox> ogra_: didrocks: and / or schedule it on the landing as appropriate. I care about my changes =) which in that bug are non-touch.
<didrocks> xnox: it's getting landing starting tomorrow
<didrocks> xnox: we needed to unscrew mir
<didrocks> which is the case now
<Mirv> didrocks: should we suggest landing indicators to sil2100 now that mir is resolved?
<didrocks> Mirv: right, now that discussion is over, I'm trying to put that on the landing ask
<Mirv> mir "INARCHIVE" \o/
<xnox> cihelp
<cjohnston> xnox: ?
<xnox> cjohnston: i thought some magic will happen and a bot will talk to me. Apperantely there is indicators-sound landing ask required to be filed (to land my change) and i'm not sure where/how to do that.
<cjohnston> xnox: there was an email sent about it
<xnox> cjohnston: the very old one - talk to your techlead and/or manager? both of them are sprinting in 7h timezone difference.
<xnox> " 3. CI/trunk components:
<xnox>      - continue to use Landing Asks sheet for the time being"
<Mirv> xnox: the page to add to is https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=1
<cjohnston> AIUI they are still the only ones with commit access
<cjohnston> s/commit/edit
<cjohnston> xnox: but a large portion of the landing team is in Oakland right now too
<cjohnston> or atleast a decent
<xnox> cjohnston: i am a core dev working on ubiquity in my spare time (non-company time) and there is a savere regression in saucy installer of not showing any indicators, which is now fixed.
<xnox> cjohnston: when the rest of indicators are landing from https://launchpad.net/bugs/1241539 they should land with changes across the board from that bug (all are tested & merged into trunk)
<ubot5> Ubuntu bug 1241539 in indicator-sound (Ubuntu) "ubiquity-dm is missing keyboard, input, sound, system indicators" [High,Triaged]
<xnox> Affects	Status	Importance	Assigned to	Milestone
<xnox> â	 indicator-bluetooth (Ubuntu) Remove	
<xnox> Triaged
<xnox> High
<xnox> â Dmitrijs Ledkovs  Edit
<xnox> Target to milestone
<xnox> â	 indicator-keyboard (Ubuntu) Remove	
<xnox> Triaged
<xnox> High
<xnox> â Dmitrijs Ledkovs  Edit
<xnox> Target to milestone
<xnox> â	 indicator-session (Ubuntu) Remove	
<xnox> Triaged
<xnox> High
<xnox> â Dmitrijs Ledkovs  Edit
<xnox> Target to milestone
<xnox> â	 indicator-sound (Ubuntu) Remove
<xnox> cjohnston: is there an email queue for landing ask at all?
<cjohnston> xnox: not to my knowledge
<xnox> note that i'm not the team/"owner" of the said components i need to get released to unbreak installer. *sigh*
 * xnox will go and upload something into debian.
<cjohnston> xnox: sorry I don't have anything better to tell you. I'm not very familiar with the process to know if there is anything else you could do
<xnox> cjohnston: ok. thanks alot. I've requested it via my tech lead. And added reminder to check upon it in couple of weeks.
<cjohnston> thanks xnox
<cjwatson> xnox's request is landing ask #216 now
* psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa (Type: "cihelp" for help) | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
* psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa (Type: "cihelp" for help) | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<ogra_> sil2100, where do we stand with unity8, mir and friends ? should i trigger a new image ?
<sil2100> ogra_: hi! You didn't get any message from Didier?
<sil2100> ogra_: from what he e-mailed me, it seems that mir + unity8 is tested and works, I have some landing asks TODO but these already use the new mir and unity8
 * ogra_ didnt see any message
<ogra_> so you mean i should wait til your stuff has landed ?
<sil2100> ogra_: no no, I guess we can spin a new image with the new mir + unity8 I guess
<ogra_> awesome, going to then ...
<sil2100> ogra_: btw. what image are we on now?
<sil2100> Since my stuff is targetted for image 7
<ogra_> proposed is on 6, trusty is on 5
<ogra_> ah, the next build would be 7 ... so re-target to 8
<sil2100> ACK ;)
<ogra_> === Image #7 building ===
<vila> ogra_: I used the 'adb shell system-image-cli -c trusty -b 0 -b' to switch channels. I had to resest clock from epoch to make it work but it's good now.
<ogra_> why the second -b ?
<vila> ogra_: it's my french accent, read it as -v ;)
<ogra_> haha
<vila> ogra_: yet, I want #6 or even #7, should I redo that with s/trusty/trusty-proposed/' ? (yeah, yeah, s/-b$/-v/ too ;)
<ogra_> if you want to be on proposed, yes, do that
<vila> ogra_: ok, I'll stick to OTA from there
<vila> ogra_: and thanks !
<ogra_> np :)
 * psivaa is seeing 'ERROR:phablet-flash:Installation is taking too long or an error occured along the way.' when flashing with image 7
<psivaa> ogra_: ^
<psivaa> installing one locally to confirm
<ogra_> psivaa, check if there are any crash files ... if apport kicks in on first boot it might time out before it finished
<psivaa> ogra_: i can't connect to the devices that failed in this way.. probably a consequence of the bad flash
<ogra_> hmm, yeah
<ogra_> what device is that ?
<ogra_> mko or maguro
<ogra_> *mako
<psivaa> both
<ogra_> oh
<psivaa> yea, there are 5 devices now i could not connect in the lab
<psivaa> all had attempted to install image 7
<psivaa> mixture of mako and maguro
<ogra_> well, image 7 isnt existent yet
<ogra_> hmm, unless my terminal lies
<ogra_> (teh build command didnt return yet in the terminal i started it in)
<ogra_> bah
<ogra_> you are right, 7 is there
 * ogra_ tries an OTA upgrade on maguro
<ogra_> there was an adbd update from xnox, but i think plars tested that
<ogra_> ok, UI is up here ... no adb
<ogra_> xnox, !!
<ogra_> no mtp either
<ogra_> hmm
 * ogra_ wonders if this is a subjective feeling or if maguro really got faster 
<ogra_> bah and now unity crashed
<ogra_> and this time maliit ... hard to get any logs in the terminal-app if everything crashes all the time
<ogra_> sigh
<ogra_> so adbd doesnt start and maliit crashes after thre chars in the terminal-app
<sil2100> popey: hi!
<sil2100> popey: are you around?
<sil2100> ogra_: do you have a moment for a packaging diff ACK?
<sil2100> ogra_: https://jenkins.qa.ubuntu.com/view/cu2d/view/Head/view/Indicators/job/cu2d-indicators-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_indicator-sound_12.10.2+14.04.20131029.1-0ubuntu1.diff
<xnox> sil2100: looks good to me.
<sil2100> xnox: awesomage, thanks!
<ogra_> what xnox said
<ogra_> xnox, so image 7 doesnt start adb ... nor does it start mtp ...
<xnox> ogra_: i'm upgrading grouper to image 7 at the moment.
<ogra_> k
 * ogra_ tries to grab logs via recovery
<ogra_> android-tools-adbd stop/pre-start, process 2027
<ogra_> thats what i see in the upstart log
<ogra_> so it seems to hang in pre-start
 * ogra_ wishes it would be easier to access the ro image from recovery :(
<ogra_> xnox, !
<ogra_> typo
<ogra_> pre-start script
<ogra_> 	if [ -d /sys/class/android_usb ]
<ogra_> 	then
<ogra_> missing semicolon
<ogra_> hmm, definitely not enough
<xnox> hm? is /sys/class/android_usb present ?
<ogra_> no idea
<ogra_> i have no chance to get in at all
<ogra_> cant start ssh because the kbd dies
<xnox> ogra_: right so from terminal.app "sudo adbd" does get me adbd
<ogra_> i cant type that
<ogra_> dies after three chars for me
<ogra_> but it looks like you completely reversed the logic for the pre-start script
<xnox> ogra_: true and the qemu grep is killing it.
<ogra_> why did that work during testing ?
<xnox> grep qemu /proc/cmdline is killing it.
<xnox> let me reboot and make the image writable
<ogra_> phew, i'm in via ssh
<sil2100> Ok guys, I go for lunch and changing locations, be back in ~2h
<xnox> ogra_: testing http://paste.ubuntu.com/6323631/
<ogra_> root@ubuntu-phablet:~# grep -q qemu /proc/cmdline || echo foo
<ogra_> foo
<ogra_> ah, yeah, that might work
<ogra_> xnox, works
<ogra_> though i wonder why you also broke mtp
<ogra_> seems that died alongside
 * ogra_ reboots with the change added
<ogra_> lest see
<ogra_> probably just a coincidence
<ogra_> xnox, what i dont get is why it worked for the testers yesterday
<ogra_> hmm, adb still works, mtp still broken after reboot
<ogra_> ah
<ogra_> i spoke to soon
<ogra_> works :)
<xnox> ogra_: i did $ watch -d adb devices
<xnox> ogra_: on the host & rebooted, grouper briefly appears and disappears
<ogra_> yeah
<ogra_> the fix is fine, please upload
<ogra_> i'll roll a new image
<xnox> ogra_: which is very odd, since in the past once up, it stayed up.
<ogra_> under ubuntu ?
<ogra_> we dont use persistent properties yet
<ogra_> so that theoretically cant work
<ogra_> (it used to work before we flipped the conatiner though, but teh flip broke that part )
<ogra_> xnox, dont forget the semicolon btw :)
<xnox> ogra_: where a semicolon, and why.
<ogra_> (or does the linewrap suffice there ?)
<ogra_> xnox, after the if condition, before then
<xnox> it should be needed. I've tested the patch as it is here http://paste.ubuntu.com/6323631/
<ogra_> ok
<ogra_> mine had the semicolon added after ]
<ogra_> but if the linewrap is sufficient then i'm fine
<xnox> ogra_: how does mtp suppose to work? and why is it sometimes flacky?
<ogra_> xnox, it works through the same gadget device
* josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht (Type: "cihelp" for help) | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<ogra_> xnox, by setting additional properties for the device
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<sergiusens> cjohnston, hey having a license problem with renato_ on a build here
<cjohnston> sergiusens: I'll need more info please
<sergiusens> cjohnston, this is the result http://paste.ubuntu.com/6323802/ if I add Collabora to the allowedlicenses in http://bazaar.launchpad.net/~private-ps-quality-team/pbuilderjenkins/trunk/view/head:/hooks/A10checklicenseheaders.in
<sergiusens> cjohnston, but I'm not sure what the proper solution would be for the other bits
<sergiusens> the allowedlicenses thing seems weird though; I'd imagine a list of GPL, LPGL, ...
<sergiusens> cjohnston, this is the job btw https://code.launchpad.net/~renatofilho/address-book-service/fork-dummy/+merge/192964
<cjohnston> sergiusens: looking
<cjohnston> sergiusens: we are investigating and will get back to you hopefully shortly
<sergiusens> cjohnston, get back to renato__ directly if you want; he just pinged me as I used to do this for him ;-)
<cjohnston> ok
<ogra_> hmm, so rmadison thinks android-tools is in ...
 * ogra_ gives it another 10min to be 100% sure ... 
<ogra_> hmm, no sil2100 ...
<ogra_> i'll mess up his image planning with my build :/
<renato__> ogra_, hi, I would like to know if you have plans to update  folks and EDS packages  on "Trusty"
<ogra_> me ?
 * ogra_ has no plans regarding this ...arent we getting that via sync from debian ?
<renato__> ogra_, yes bill told me to ping you :D
<ogra_> s/sync/autosync/
<ogra_> renato__, traditionally seb128 (or his team) maintained eds
<ogra_> he should be online soon (at the sprint)
<renato__> ok thanks
<plars> ogra_, xnox: hi... so was the adbd that went into 7 different somehow from the one I tried yesterday?
<ogra_> plars, well, not sure
<ogra_> i havent looked inside the deb yesterday
<ogra_> but appraently it was different. yes
* josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht (Type: "cihelp" for help) | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<xnox> ogra_: android-tools is in release pocket.
<ogra_> xnox, i know
<ogra_> it is since a while
<ogra_> xnox, prob is that sil2100 is gone
<xnox> ok =) sorry.
<xnox> ogra_: ah, fair enough.
<ogra_> and he has pending stuff according to the spreadsheet
<ogra_> waiting for him to return from lunch
<cjwatson> You don't need to wait once rmadison says it's in
<cjwatson> It's definitely fine for image building then
<ogra_> looking at the sheet it seems only the hud fixes didnt get in yet
<ogra_> cjwatson, k
 * ogra_ thinks we can afford one more build later this evening and just kicks off image #8 now 
<ogra_> popey, do you know if we will revisit the app categories  at some point ? the options the store offers are really odd imho
<popey> i hope so, but that's more bueno's dept
<xnox> popey: ogra_: it feels like at the moment it's offering categories as as for .debs / from debian policy. (so copy&paste from the non-click app store)
 * xnox ... maybe not policy, but wherever debian lists all possible categories.
<ogra_> yeah
<dobey> fginther: https://bugs.launchpad.net/jenkins-launchpad-plugin/+bug/1214970 <- this is "fix released" now right?
<ubot5> Ubuntu bug 1214970 in jenkins-launchpad-plugin "test result URLs posted on MRs are linking to s-jenkins instead of public location" [Undecided,New]
<fginther> dobey, yes, that's been fixed
<fginther> was a configuration issue, not an actually code change
<dobey> right
<dobey> i'm doing some work to get tarmac back up to par, for where we need it to be
<ogra_> === Image #8 is done ===
<ogra_> psivaa, plars ^^^ that one should work again
<plars> ogra_: you rock!
<plars> rfowler_: are the devices back up?
 * ogra_ upgrades
<ogra_> ogra@chromebook:~$ adb shell
<ogra_> root@ubuntu-phablet:/#
<ogra_> looks good
<ogra_> xnox, ^^^
 * popey updates to 8
<didrocks> hey sil2100, how are you?
<didrocks> hey ogra_!
<ogra_> sil2100, we had an issue with image 7 ... we fixed it and rolled #8 a bit earlier
<didrocks> ogra_: ah nice, you kicked an image!
<didrocks> (that was my question)
<ogra_> sil2100, i updated the spreadsheet for your stuff
<didrocks> what was wrong with image 7?
<ogra_> didrocks, adbd didnt start
<didrocks> ah, not nice!
<ogra_> issue with the upstart job
<didrocks> mir was in image 7 as well?
<ogra_> it was tested by two people ...
<ogra_> yeah
<didrocks> okâ¦
<ogra_> new mir and unity8
<didrocks> excellent!
<ogra_> not sure how the tests did succeed though
<didrocks> thanks ogra_, /me won 10 minutes :)
<didrocks> ogra_: tests succeed?
<ogra_> (for the broken adbd)
<didrocks> I see no result on the dashboard
<didrocks> ah
<didrocks> yeah, this was landing ask #?
<ogra_> yeah, #7 didnt start ... no adb :)
<ogra_> and #8 is there since 20min only
<sil2100> Hello!
<didrocks> ogra_: I mean, I don't see the adb upload
<didrocks> hey sil2100 ;)
<sil2100> ogra_: ok, thanks :)
<didrocks> ogra_: in the landing plan
<ogra_> didrocks, oh, that was xnox , i think we might have missed adding it
<ogra_> but he asked popey and plars for testing ... sorry, i should have taken care of the spreadsheet
<fginther> plars, rfowler_, any issues getting our devices restarted to flash to image 8?
<ogra_> (but it was late last evening and i forgot)
<plars> fginther: it looks like they are still not up, for image testing at least
<ogra_> hmm
<didrocks> ogra_: no worry, thanks for tracking that to the end
<ogra_> so Mir on maguro is *a lt* snappier after reboot
<didrocks> sil2100: how is the landing going? Seems well from what I see
<didrocks> ogra_: yeah, there is still some mem leaks
<ogra_> but gets really awful after starting a few apps
<didrocks> (visible on mako as well)
<ogra_> like, worse than before imho
<didrocks> oh really?
<didrocks> possible, quite a bunch of code entered
<ogra_> its lots and lots better after a fresh boot
<popey> yeah, feels quite sluggish
<sil2100> didrocks: rather well, I also tested indicator-datetime, no regressions with AP unity8 but I'm not sure how the fix is supposed to work
<ogra_> nearly as smooth as mako
<popey>  3386 phablet   20   0  284180  53304  37700 S  99.3  2.8   0:37.20 camera-app
<sil2100> didrocks: I set up an alarm and didn't see any indication of it alarming
<ogra_> but as soon as i have a few apps open it crawls
<didrocks> sil2100: argh, checkig with upstream as well?
<ogra_> didrocks, since youre at it, can you add robru's seed change to the plan too ?
<didrocks> sil2100: basically, instead of having the day, you should have a generic message
<ogra_> so we finally get that off the plate
<didrocks> ogra_: well, I want that backward compatibility to be discussed properly here before we take a decision
<didrocks> ogra_: I try to have that happens, it's hard for them to see that blocking us :p
<ogra_> at the sprint you mean ?
<didrocks> yep
<ogra_> yeah, we need a defined process how to change the API
<ogra_> but that one is actually safe
<ogra_> 3D directional audio is definitely not used by any app yet :)
<didrocks> right, but imagine someone start developping today
<didrocks> basing on our sdk 1
<xnox> sil2100: i open indicator, and it says "... Battery, Sound, Tuesday, Network, ..." which is plain odd =)
<plars> fginther: haven't heard back yet, but it looks like the devices on the image testing side are up now at least. Just started the tests
<xnox> (that's with old image)
<didrocks> they will have a surprise :)
<plars> ogra_: ^
<plars> fginther: can you check yours?
<ogra_> plars, great
<popey> ogra_: didrocks #8 seems to have broken the music app?
<popey> I get a white screen on mako
<ogra_> popey, oh ?
<sil2100> xnox: ah, this is ok
<sil2100> didrocks:  ^
<ogra_> popey, works on my maguro
<popey> hmm
<ogra_> (well, i have no music on it ... )
<sil2100> didrocks: I mean, the Tuesday -> now it's Upcoming
<fginther> plars, all are still off-line. I'll follow up with rfowler_ in case he's not aware they need attention
<sil2100> didrocks: but there was also a mention about the alerts being fixed
<ogra_> popey, "please import music and restart the app" ... on mako as well
<popey> ogra_: for me it started the first time after a reboot, showed some music and then fell over
<popey> ah, add some music
<sil2100> didrocks: I'm waiting for upstream to comment
<didrocks> sil2100: oh that one, yeah
<ogra_> so its more the scanning than the app
<didrocks> sil2100: sounds good, put it in red
<popey> dunno
<sil2100> didrocks: in the meantime, I check the hud maybe
<popey> scanning is separate
<popey> it could be something inside the app reading from mediascanner
<ogra_> yeah, that shouldnt cause a white sceeen
 * popey reboots and tries again
<popey> #5 is fine
<didrocks> sil2100: yeah, sounds good!
<ogra_> popey, musci app is native C++ right ?
<popey> nope
<popey> qml + plugin
<ogra_> k
<ogra_> popey, coudl you check #6 ?
<popey> /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene: unrecognized option '--file='
<popey> /usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene: invalid option -- 'I'
<popey> QUbuntu: Could not create application instance
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/20131025.changes
<popey> http://paste.ubuntu.com/6324436/
<ogra_> i see mediascanner was updated in #6
<popey> yeah
<popey> ok, will test #6
<popey> phablet-flash ubuntu-system -d mako --revision 6
<popey> ?
<ogra_> -b  6
<ogra_> oh
<ogra_> phablet-flash
<ogra_> yeah
<popey> ah, needed channel too
 * ogra_ is so focused on system-image-cli nowadays 
<popey> INFO:phablet-flash:Flashing revision 6 from channel trusty-proposed
<popey> yay
<popey> i like that it tells me now
<ogra_> :)
<popey> shame it whizzes past so fast
<ogra_> WOAh
<ogra_> system-settings just crashed in my face
<ogra_> and doesnt start anymore now
<ogra_> and again
<popey> ogra_: music app works in #6
<ogra_> popey, can you try if system-settings behaves for you ?
<popey> on #6?
<ogra_> it just vanishes for me after clicking around in it a bit
<ogra_> on 8
 * ogra_ wonders if anyone actually checked the impact of the boots transition for out toolkit
<ogra_> *boost
<ogra_> *our
<popey> i have visited every pane in system settings on #6
<popey> no problems
<ogra_> hmm, doesnt for me anymore either
<ogra_> but i'm at the tenth try or so
<ogra_> oh
<ogra_> and now the G+ app crashed
<ogra_> wow
<ogra_> apps are super crashy on #8
<ogra_> didrocks, do you know if anyone from the SDK team asessed the impact of the boost transition on our stuff ?
<ogra_> haha
<sergiusens> ogra_, how does the whole landing ask work for the android tree?
 * ogra_ just tried to start the ubuntu desktop tour on the ubuntu website in the browser
<cjwatson> Didn't the boost transition predate the previous good image?
<sergiusens> ogra_, can I just push stuff to the repo?
<cjwatson> Please could you find out whether it's actually related before implicating it
<ogra_> cjwatson, oh, right, it was all boost updates, not the transition itself
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/20131029.1.changes
<cjwatson> There's a boost change in this image, but it's not the transition, indeed
<ogra_> ah, no
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/20131029.changes
<ogra_> its also bumping from 1.53 to 1.54
<cjwatson> Wasn't #7 good?
<ogra_> (image 7 was broken)
<ogra_> no, adb was messed up
<ogra_> so the tests couldnt run
<cjwatson> Oh.  Well, please still find out whether it's related before we go trying to unwind a complxe transition
<cjwatson> *complex
<ogra_> cjwatson, i only wanted to know if someone from the SDK team actually checked the potential sisk for us
<ogra_> *risk
 * ogra_ didnt mean to point fingers or anything 
<cjwatson> That looks like only a small part of the boost transition - most of it was already done
<cjwatson> I think that was just lucene++?
<thomi> sil2100: hey man, I wonder if you could comment on this please? https://bugs.launchpad.net/autopilot/+bug/1244089
<ubot5> Ubuntu bug 1244089 in Autopilot "Autopilot 1.4 trusty AP test errors" [Critical,New]
<ogra_> cjwatson, yeah, my path of thought wa more going towards if we potentially need to rebuild any native apps
<ogra_> or if thats covered on the Qt level for us
<cjwatson> There's more in http://people.canonical.com/~j-lallement/touch/changes/20131025.html, but there's also quite a lot else
<cjwatson> (that was #6 - looks like the last promoted image was #5?)
<ogra_> 25 was image 6
<ogra_> i ran that fro a few days without issues
<cjwatson> OK
<ogra_> the breakage came between 6 and 8
<sergiusens> xnox, do you know what the process is for committing/pushing to the android repo these days?
 * ogra_ thought that process was called rsalveti 
<sergiusens> ogra_, I have push rights; just want to know how it plays with the landing asks and all that
<rsalveti> sergiusens: you need to push, wait for the tarball to be out, and upload
<rsalveti> sergiusens: the tarball is done at every hour
<ogra_> sergiusens, ah
<rsalveti> but you need to sync with the landing team
<sergiusens> rsalveti, ok, I just want to push the revert for mtp
<rsalveti> sergiusens: or just ask either me or xnox to sponsor it
<cjwatson> ogra_: FWIW I just unpacked everything from http://people.canonical.com/~ubuntu-archive/click_packages/click_list and none of those have any direct linkage to boost
<rsalveti> sergiusens: which patches?
<ogra_> sergiusens, you need to mount / rw and replace the android img file i think ... to test it
<cjwatson> ogra_: I would have expected direct linkage to boost from apps to be strictly forbidden - the SDK team doesn't like that kind of thing :)
<ogra_> inside the ubuntu-system.imd
<sergiusens> rsalveti, http://people.canonical.com/~sergiusens/mtp/0001-Revert-Disabling-mtp-for-manta.patch
<sergiusens> rsalveti, remember :-)
<ogra_> cjwatson, well, system-settings is native iirc
<ogra_> cjwatson, as well as the browser
<rsalveti> sergiusens: yeah, I can check it now :-)
<rsalveti> got the new laptop in place
<sergiusens> ogra_, I know how to test; I have my changes locally
<ogra_> cjwatson, i meant less the click packages ...
<rsalveti> sergiusens: will review your other mrs today as well
<cjwatson> ogra_: It neither directly build-depends nor depends on boost
<sergiusens> ogra_, I just need to know what the bureaucratic part is
<ogra_> cjwatson, k
<cjwatson> ogra_: Likewise webbrowser-app
<ogra_> sergiusens, landing ask ... have someone from the team move it to landing plan ...
<cjwatson> ogra_: So I suppose it's *possible* something obscure there is going on but it doesn't seem like the highest-probability cause ...
<ogra_> cjwatson, yeah ... Mir and unity depend on it, if there is breakage its more likely in them, thanks for checking the apps !
<ogra_> hmm
<ogra_> gallery-app looks really bad on the dashboard
<ogra_> 50% fail rate
<xnox> cjwatson: can you grep for dlopen? =)
<ogra_> funny, locally it is actually rock solid
<cjwatson> xnox: no matches
<sil2100> thomi: sure, give me a moment ;)
* doanac changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: doanac | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<plars> ogra_: yeah, on mako and maguro too
<ogra_> right
<sergiusens> ogra_, are you not on canonical irc for a reason?
<ogra_> sergiusens, erm, no reason except not noticing that i dropped
<thomi> sil2100: I assigned you to the bug, and marked it as incomplete. Feel free to change the status once that information is added. Thanks!
<sil2100> thomi: sure! Thanks, will test the branch whenever it's possible
<thomi> ok, I figured there was an automated system for that
<thomi> thanks for your help
<sil2100> Mirv: tested HUD, publishing if all is ok in cu2d
<Mirv> sil2100: cool, and morning!
<Mirv> cyphermox: could you pre-ack packaging change http://10.97.0.1:8080/view/cu2d/view/Head/view/Phone/job/cu2d-phone-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_dialer-app_0.1+14.04.20131029.1-0ubuntu1.diff ?
<Mirv> sil2100: so you got unity8 AP also working?
<cyphermox> hrm, sure...
<sil2100> Mirv: yes \o/
<sil2100> Mirv: some tests are failing, but re-runs help
<ogra_> plars, given the crashyness of apps, i dont think it is worth to give back anything on image 8
<sil2100> Mirv: those seem like problems with introspecting unity8 in overall sometimes
<plars> ogra_: agree, tests are still running so if there's anything you're curious about we can do retries in a bit, but I don't think it looks good
<Mirv> sil2100: yeah being able to run unity8 tests now with the new Mir with just one command is great
<sil2100> Mirv: btw. we have a lot of failures for one machine for HUD - you think it's still ok to publish? Other platform is better, below threshold
<ogra_> plars, yeah, its not woth it, we need a fix for Mir first
<Mirv> sil2100: I don't know, better do some validating of those?
<cyphermox> Mirv: all good for dialer-app
<cyphermox> I'd be a bit wary of running that on a "live" phone though :)
<Mirv> sil2100: have you looked that there are _1400_ autopilot errors in unity stack?
<cyphermox> Mirv: the autopilot tests themselves scare me ;)
<Mirv> yeah I wouldn't suggest running the autopilot tests with SIM card..
<slangasek> ci help
<thomi> slangasek: :)
<cjohnston> doanac: ^
<cjohnston> slangasek: no space between the two... but if there is a vanguard, they are even better :-)
<slangasek> oh
<slangasek> cihelp?
<doanac> slangasek: works. what's up?
<cjohnston> slangasek: that's the one
<slangasek> doanac: hi :)  Just testing the system that ev is briefing us all on :-)
<Mirv> ticket resolved :)
<doanac> slangasek: also a tip: the channel topic includes some information about who's vanguard and what critical issues are known
<sil2100> Mirv: I vaildated that those are not regressions if anything, still wondering why those fail
<sil2100> Mirv: oh, didn't look at unity stack ;p
<sil2100> 1400?!
<sil2100> :O
<Mirv> sil2100: maybe related to the unity stack problem...
<cjohnston> slangasek: tell ev to explain to ping the vanguard if there is one instead of cihe*lp please :-)
<sil2100> Mirv: :O
<slangasek> doanac: ack - but ev didn't tell us to look at the topic, he just said to type 'ci help' ;)
<doanac> slangasek: makes sense. we should update our alert patterns to catch that also
<slangasek> too late, the moment has passed, we'll have to clarify this by email later ;)
<doanac> :)
<Mirv> sil2100: yeah, slight problems, looks like dbus also with autopilot 1.3? (you e-mailed about autopilot 1.4)
<Mirv> doanac: maybe support also "ci help", "CI Help!" and so on :)
<cjohnston> Mirv: there is a reason it's what it is. :-)
<cjohnston> not all clients support things like spaces
<Mirv> right
<sil2100> didrocks: ACK please! http://10.97.0.1:8080/view/cu2d/view/Head/view/HUD/job/cu2d-hud-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_hud_13.10.1+14.04.20131029.1-0ubuntu1.diff
<didrocks> sil2100: +1 of course
<sil2100> \o/
<didrocks> thanks dude!
<ogra_> didrocks, bug 1245958
<ubot5> bug 1245958 in unity-mir "Apps crash with image 8" [Undecided,New] https://launchpad.net/bugs/1245958
<ogra_> FYI
<ogra_> didrocks, no way to promote that one
<didrocks> ogra_: argh, Mirv can you handle that? ^
<ogra_> didrocks, kdub and alan_g discuss it in -touch atm
<ogra_> but i wont be around late today so wont be able to drive that
<Mirv> didrocks: ok, I'll at least poll on them to get the news on a fix
<didrocks> ogra_: ah nice!
<didrocks> thanks :)
<Mirv> I do have some crash files in /var/crash for apps too, although from user perspective one doesn't see that much it seems
<didrocks> ok
<Mirv> marked the bug as critical as it prevents image promoting
<ogra_> sergiusens, added landing #288 to the landing plan for you
<sergiusens> ogra_, thanks
<popey> oooh Mirv https://codereview.qt-project.org/#change,69368 via https://bugreports.qt-project.org/browse/QTBUG-32225
<kenvandine> Mirv, sil2100: i've added a reference to the bug report for Mir causing lots of app crashes in image 8 to the old unity team work spreadsheet, so we prevent to much duplicate work
<Mirv> popey: \o/ for progress
<Mirv> kenvandine: thanks
<Mirv> vila: can you glance at http://10.97.0.1:8080/job/autopilot-trusty-daily_release/216/ - all AP tests failing because of a dbus problem?
<vila> Mirv: EOD, doanac ? ^
<doanac> looking
<doanac> seems limited to unity8?
<vila> doanac: thanks
<Mirv> doanac: unity7, not unity8
<doanac> Mirv: sorry those keys are too close together
<Mirv> doanac: I noticed upgrading to that trunk unity install xpathselect 1.4, maybe it's related?
<Mirv> doanac: I also saw an e-mail from Chris Lee related to problemws with Autopilot 1.4 (but we use 1.3 in the PPA) about that Unity7 "hasn't been updated to use thenewer 1.4 DBus wire protocol (Unity7 a unique beast in that the functionality that isusually provided by libautopilot-qt/gtk is part of the Unity7 source tree.)" - it says dbus but does that mean xpathselect instead?
<doanac> Mirv: possibly. i was worried some of those DBUS errors seemed unrelated. but that seems feasible.
<Mirv> ah right
<Mirv> https://code.launchpad.net/~3v1n0/unity/xpathselect-1.4 - so maybe this?
<Mirv> I filed bug #1245988 now, updates welcome
<ubot5> bug 1245988 in Unity "All AP tests fail with unity - xpathselect 1.4?" [Critical,New] https://launchpad.net/bugs/1245988
<doanac> Mirv: both 1.3 and 1.4 are getting installed for xpath
<Mirv> doanac: the new unity-autopilot only depends on libxpathselect1.4
<fginther> doanac, Mirv, i think that's the culprit. unity is speaking 1.4, autopilot is listening to 1.3
<thomi> hi guys
<fginther> thomi, o/
<thomi> so, Marco and I were looking at those branches yesterday - I didn't think he'd merged them yet though
 * thomi pulls unity
<Mirv> it seems https://code.launchpad.net/~townsend/unity/fix-lp1243529/+merge/192381 got merged
<fginther> thomi, it's been merged
<thomi> oh
<thomi> well
<thomi> this is the problem we face - landing autopilot 1.4 and *all* the test suites at the same time takes som serious coordination :)
<Mirv> so is this a chicken and egg problem with moving to autopilot 1.4?
<thomi> right - either we land AP 1.4 and fix the tests later, or we try and do everything at the same time
<thomi> We were trying to do everything at once, but I guess I should have been clearer with Marco
<thomi> so I guess the options are either to revert the unity7 change, or go ahead and land AP. I know which one I'd rather do, but I'll leave that to you guys :)
<fginther> I vote for reverting the unity7 change
<thomi> à² _à² 
<doanac> i'm pretty sure asac would prefer to revert
<fginther> of course now I see the bug that was addressed: https://bugs.launchpad.net/unity/+bug/1243529
<ubot5> Ubuntu bug 1243529 in unity (Ubuntu) "unity FTBFS on trusty" [Critical,Fix committed]
<fginther> appears that unity7 fails to build with xpathselect 1.3?
<thomi> fginther: should build fine once marcos branch is reverted
<thomi> I mean, it used to build against 1.3, marco merged code to build it against 1.4
<fginther> thomi, ok, I see that 1.4 isn't in trusty anymore
<fginther> hang on
<doanac> so are there 2 changes that would need reverting:  https://code.launchpad.net/~townsend/unity/fix-lp1243529/+merge/192381 and http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3581 ?
<fginther> thomi, ah. libxpathselect 1.4 is still in the daily-build ppa
<fginther> that's causing unity7 not to build (https://launchpadlibrarian.net/154760401/buildlog_ubuntu-trusty-amd64.unity_7.1.2%2B14.04.20131023-0ubuntu1_FAILEDTOBUILD.txt.gz), hence the bump
<thomi> fginther: I see.
<thomi> fginther: I'm not really sure what makes it land in the PPA
<thomi> I guess it's some cu2d config?
 * thomi shrugs
<fginther> thomi, yes. whoever added the autopilot 1.3-trusty branches probably didn't realize that xpathselect was a dependency
<thomi> :(
<thomi> We never expected 1.3 to land in trusty. I guess the config was written assuming 1.4 would get released there
<fginther> thomi, most likely
<fginther> doanac, mirv, wokring on a suggestion, one moment
<balloons> psivaa, plars just an update on filemanager.. 4 errors are bugs, the rest I think I've fixed
<plars> balloons: awesome, is it more consistent now too? or are the 4 bugs things that don't happen every time?
<balloons> plars, the 4 remaining failures have to do with seemingly the clipboard not working
<Mirv> fginther: ok. indeed xpathselect was probably not in radar when reverting to AP 1.3 for trusty.
<psivaa> balloons: are the fixes in already with image 8?
<fginther> doanac, Mirv, thomi, so we have two options: 1) add xpathselect 1.3 to trusty and revert the unity7 MP or 2) Land autopilot 1.4 in trusty and update the remaining autopilot tests
<balloons> psivaa, no, i'm working on a branch
<psivaa> balloons: ack, thank you :)
<balloons> trying to get everything working :-)
<fginther> either way 2) needs to happen eventually
<doanac> 2 is probably less total work also.
<fginther> with 2 there will be test failures for the image and for upstream merger, but this might put more pressure on getting them resolved
<doanac> fginther: who makes the decision? asac?
<fginther> doanac, this might be didrock's team. they did the original change to get 1.3 into trusty
<fginther> doanac, this is probably a landing pipeline descision
<doanac> yeah
<doanac> fginther: given they are probably in meetings, should I send off an email to summarize?
<fginther> doanac, good idea
<slangasek> didrocks: clearly, that subtitle should have been written 'quickly improve'
<Mirv> fginther: it should be a revert - as discussed before all AP 1.4 changes should land at once, otherwise we block various stacks for undetermined amount of time
<Mirv> ogra_: are you about? the qtmultimedia/audioengine seed changes are finally greenlighted now
<fginther> Mirv, I can start on the cu2d-config changes. Once that's done, can you remove the xpathselect 1.4 packages from the daily ppa?
<Mirv> fginther: yes, I can remove it then
<fginther> Mirv, doanac, can you review: https://code.launchpad.net/~fginther/cupstream2distro-config/xpathselect-trusty-1.3/+merge/193133
<doanac> fginther: looks good
<Mirv> +1, deleting the PPA build of xpathselect 1.4
<fginther> Mirv, doanac, now to revert the unity7 bump of xpathselect: https://code.launchpad.net/~fginther/unity/revert-libxpathselect1.4/+merge/193137
<doanac> fginther: reading
<Mirv> thanks for that, hopefully we'll get desktop AP results after that. as an example, because of the problem I had to dedicate my laptop to running unity7 AP:s manually so that it would be possible to validate an libunity release, instead of getting the desktop results from jenkins.
<fginther> Mirv, you remember to pack a spare laptop just for this purpose, right? :-)
<Mirv> yeah, my draggable trusty 5y old Dell is so fun to travel with :)
<thomi> doanac: ping?
<thomi> doanac: can you please explain to me what the three touch images are? There's "touch_sf4p", "touch", and "touch_custom". Why are there several images, and what do they mean?
<thomi> cihelp
<thomi> ^^
<cjohnston> thomi: one sec
<thomi> thanks :)
<cjohnston> touch == mir
<cjohnston> custom is a custom variant
<cjohnston> sf4p iirc is mir disabled
<cjohnston> thomi: ^
<thomi> cjohnston: any idea what's different on the custom image?
<cjohnston> thomi: tis a question for achiang
<thomi> ok
<thomi> thanks charles
<thomi> oops
<thomi> thanks cjohnston
<cjohnston> ya, him too
<cjohnston> lol
<charles> thomi: no problem at all
<charles> thomi: anytime
* doanac changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
#ubuntu-ci-eng 2013-10-30
<jibel> vila, the link /etc/apparmor.d/disable/usr.bin.rsyslogd is part a the default setup of the system not specific to our setup or anything required by otto.
<jibel> s/a/of
<vila> jibel: wow.... ok thanks
<jibel> vila, also, I think I'll drop swap control from the default config file and add it dynamically only if swapaccount is enabled.
<jibel> vila, unless you beat me to it and send me a patch of course:)
<vila> jibel: hehe, ack, probably not, I'm still un-piling  a bunch of other stuff ;)
<vila> jibel: out of curisosity, what should have I done to track where /etc/apparmor.d/disable/usr.bin.rsyslogd was coming from, 'dpkg -S' doesn't help there
<vila> jibel: in the mean time, removed from the doc and pushed
<jibel> vila, it must be created by rsyslog itself, check dpkg *inst scripts of rsyslog.
<vila> jibel: ack
<jibel> vila, â« grep apparmor.d/disable /var/lib/dpkg/info/rsyslog.*inst
<jibel> /var/lib/dpkg/info/rsyslog.preinst:    APP_DISABLE="/etc/apparmor.d/disable/usr.sbin.rsyslogd"
<vila> jibel: excellent, thanks !
<jibel> anyhow it is irrelevant to the configuration of otto.
<vila> jibel: yup, fixed in the mp
<vila> rhaaaa, damn it vila, you updated that doc to capture knowledge and failed to add the knowledge acquired during the review !
<vila> jibel: sorry about that https://code.launchpad.net/~vila/otto/update-setup-instructions/+merge/193201
<popey> ogra_: we spinning another build today?
<ogra_> popey, waiting for bug 1245958 to be fixed i fear
<ubot5> bug 1245958 in unity-mir "Apps crash with image 8" [Critical,New] https://launchpad.net/bugs/1245958
<popey> ok
<popey> nobody assigned
<ogra_> i havent herad from the Mir team, i think alan_g and kdub wanted to look into it though
 * ogra_ hopes that gets fixed asap ... we couldnt release an image since friday
<ogra_> and i fear rolling back the whole stack is as much work as fixing it :(
<alan_g> ogra_: I *guess* that what is needed is https://code.launchpad.net/~afrantzis/mir/remove-client-rpc-timeout/+merge/193094 - but I'm still setting up phone to test.
<popey> balloons / fginther any idea what's going wrong here? http://91.189.93.70:8080/job/generic-mediumtests/1247/? (from https://code.launchpad.net/~vthompson/music-app/fixes-1234990/+merge/192771 )
<ogra_> alan_g, awesome, good to know someone looks into it, thans a lot !
<ogra_> +k
<fginther> popey, morning
<fginther> popey, the last run for that MP passed (30 minutes ago)
<popey> thanks fginther, can we prepare a click package soon for music app sergiusens ? I'd like to do some tesing before we upload to the store
<sergiusens> popey, sure, the app should be autogenerated still
<sergiusens> popey, fginther now, the problem with all click apps is that they need to be tested on stable AND on devel-proposed
<popey> i can do that
<popey> i have two devices setup exactly like that
<popey> (manual, not automated testing that is)
<fginther> sergiusens, hmm
<sergiusens> fginther, that's before publishing to the store
<fginther> sergiusens, stable == saucy right?
<sergiusens> fginther, would be good to start hooking up the apps in http://10.97.0.26:8080/view/click/? to some sort of automated testing and do auto pushes; it would be a daily release extension I guess
<sergiusens> fginther, today, yes
<sergiusens> fginther, I'm not sure how you are going to deal with the non backwards compatible autopilot 1.4/1.3 though
<fginther> sergiusens, then we have a problem... autopilot tests...
<fginther> beat me to it
<sergiusens> fginther, I'll leave that issue to QA; tbh I thought api breakages were a thing of the past
<fginther> sergiusens, does this also apply to internal apps?
<fginther> notes, webbrowser, etc
<sergiusens> fginther, yes
<sergiusens> fginther, since click apps are exposed to devices by the framework they support
<fginther> sergiusens, https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1246299
<ubot5> Ubuntu bug 1246299 in Ubuntu CI Services "Need to test apps as click packages on touch devices" [Critical,Triaged]
<sergiusens> fginther, webbrowser I'm particularly not sure of it's path, but notes, camera and gallery for sure
<sergiusens> fginther, subscribed, thanks
<t1mp> are there new known issues with jenkins? Since yesterday or so CI is failing our MRs again
<t1mp> for example, this one https://code.launchpad.net/~kalikiana/ubuntu-ui-toolkit/aviator/+merge/193219
<cjohnston> t1mp: not that I know of
<fginther> t1mp, there is a unity8 and qmlscene crash on that mako run
<t1mp> fginther: what does that mean, that unity8 is broken and we need to wait for a fix?
<fginther> t1mp, unity8 crash is probably there from the failed unlock attempt. It eventually succeeded and the first few tests passed...
<fginther> t1mp, but I've never seen a qmlscene crash. looking for something in the logs that might indicate anything
<ogra_> Mir is crashy in trusty atm ... (or rather apps are due to Mir)
<ogra_> see bug 1245958
<ubot5> bug 1245958 in unity-mir "Apps crash with image 8" [Critical,Confirmed] https://launchpad.net/bugs/1245958
<t1mp> kalikiana: ^ fyi
<ogra_> not sure how much impact this can have on MP tests
<sergiusens> ogra_, a lot if the MR test runner installs trusty-proposed
<ogra_> yeah, i was suspecting that
<sergiusens> ogra_, fginther would temprarily switching to surfaceflinger unblock people?
<fginther> sergiusens, ogra_, t1mp, MPs are tested with trusty-proposed
<ogra_> not so sure ... the behavior will be different (i.e. you might have other issues)
<ogra_> but probably worth a try
<sergiusens> fginther, ogra_ either that or set the phablet-flash to flash -r -2
<sergiusens> or -r 6 (7 and 8 being the broken ones)
<kalikiana> why wasn't it noticed before?
<kalikiana> how did it pass despite you sounding as if it's obviously crashy as known?
<ogra_> kalikiana, it doesnt happen immediately ... so if you are lucky all manual AP tests pass ... and even testing it manually works if you dont test for more than 10min
<fginther> sergiusens, here's a better question, should apps even be tested with -proposed?
<ogra_> (testing it manually as in "using it" )
<kalikiana> hmm another memory issue? there was the one about not releasing closed apps that took n test runs to break
<ogra_> there is a proposed fix on the bug
<fginther> sergiusens, just use -proposed for unity8, uitk and other plumbing components?
<ogra_> kalikiana, this one is rather "you use the app and watch it disapper underneath your fingers while using it"
<sergiusens> fginther, well apps should work everywhere given they have no dependencies
<sergiusens> fginther, it's a tough question
<sergiusens> fginther, utah already tests them on proposed; maybe would be good to test the apps on non proposed
<fginther> sergiusens, my thought is to give the apps a more stable environment, keep the plumbing in -proposed. We could also add some apps to the uitk and unity8 tests to make sure they continue to work
<fginther> sergiusens, adding more test suites to uitk and unity8 has been the plan for a while, we just have to solve the (lack of) resource issue
<kalikiana> first we need ci to be reliable otherwise it's hard to get better coverage in
<kalikiana> a number of planned things never made it
<fginther> kalikiana, right, if the tests aren't stable then adding more will just cause more issues
<kalikiana> fginther: basically improvements in the uitk are being discussed all the time among the team - but we struggle to get anything in at all :-(
<t1mp> so, if a new version of unity is proposed for a merge (or in the image), can it be tested with UITK trunk (should be known stable, right?) autopilot tests before merging?
<t1mp> like that our MRs would be tested with an image that should be stable
<kalikiana> +1000
<dobey> do any ci-eng people have time to help with reviewing branches for tarmac?
<dobey> fginther: ^^ would you maybe?
<cjohnston> dobey: I could take a look
<fginther> dobey, I would like to look as well
<dobey> cjohnston, fginther: thanks. added both of you to ~tarmac-devs team.
<dobey> https://code.launchpad.net/~dobey/tarmac/simple-setup/+merge/193147
<dobey> and https://code.launchpad.net/~dobey/tarmac/bzr-export/+merge/193130
<dobey> those could use a couple reviews right now
<fginther> t1mp, that is something that can be added, but we have to build this up gradually. The last time we added additional test suites, we overtaxed our resources and created a huge wait queue
<t1mp> fginther: on the other hand, we now have a large amount of MRs approved for UITK, but we know that they will fail CI/autolanding. So actually it is a waste of resources to execute the tests for those right now
<t1mp> s/large amount of MRs/some MRs
<fginther> t1mp, we can disable the autolanding job until we have a new image
<t1mp> fginther: yes, okay.
<fginther> t1mp, since there is other test feedback provided by the other non-touch jobs I would recommend keeping ci going
<t1mp> kalikiana: ^ that's what happened to your MR. autolanding failed.
<t1mp> executing all the tests first with the last-known stable image, and then with the proposed one, may be helpful in the future
<t1mp> but I don't know if it is feasible considering the resources, and maybe a smarter solution can be thought of
<fginther> t1mp, it would take more resourced, but for a few projects, it might be a better solution.
<fginther> t1mp, If an MP passed stable, but failed proposed, that most likely indicates an issue in the image itself, what's the action for the MP owner?
<fginther> if any
<t1mp> fginther: find someone to fix it in the image ;)
<t1mp> fginther: now we test with proposed, right?
<fginther> t1mp, yes
<t1mp> fginther: a lot of times, a bunch of tests "suddenly" start to fail for us, and then we spend quite an effort to track down what we did wrong
<t1mp> ..until we figure out the bug is in the image.
<t1mp> that can be avoided by testing with a stable image firs
<t1mp> *first
<fginther> t1mp, I can see that as a result we would be beating harder on the proposed image...
<t1mp> and then, depending on the developer, we can decide whether we debug more and help with solving the issue, or simply wait for a good image to come again
<t1mp> fginther: I don't understand your sentence
<fginther> t1mp, if we test an MP on both stable and proposed, that would provide more test coverage of the proposed image
<fginther> vs the stable one to expose issues
<t1mp> yeah
<fginther> mostly just thinking out loud
<t1mp> me too
<t1mp> it is difficult to find a way to have everything well-tested because there are so many large and small things coming together in an image
<fginther> agreed
<kalikiana> fginther: wouldn't a passing test on stable indicate it can land? given stable is a moving target that updates all the time and gets the latest from -proposed anyway
<kalikiana> maybe that's too obvious to be an option?
<cjwatson> For apps yes, for stuff that actually goes through trusty-proposed in the archive that could create deadlock
<cjwatson> (Since the contents of trusty-proposed may be blocked waiting for what you're trying to land ...)
<cjwatson> Though I guess if you mean the trusty-proposed *image* that's not relevant
<kalikiana> I see deadlock right now with always testing proposed and mir/ unity keeps introducing new bugs resulting in a race with low chance of winning
<kalikiana> oh yes
<kalikiana> image is what I meant, sorry
<fginther> kalikiana, the issue that comes to mind is that the MP being tested is not released on top of stable, it's released as the next -proposed. you don't want to get too far away from that target. Apps should be image agnostic (although a change to the image can break them as well)
<kalikiana> fginther: apps fail the same way as the toolkit when the underlying system changes
<kalikiana> I'm not convinced making a difference there is a genuine win
<fginther> kalikiana, I need to think about it more...
<kalikiana> fginther: is there any way for jenkins to compare test results for equality? for example to say "apparently 20 mrs fail lexactly ike this, please ask a qa engineer about it"
<kalikiana> reducing the effort of investigating would at least alleviate some pain
<t1mp> kalikiana: wow. how did you move the l of like to lexactly?
<fginther> kalikiana, jenkins can't do this by itself.  but there are ways to pull the info out of jenkins to create a running report of test failurs
<fginther> It's been on my wishlist for a while, but fires keep coming up
<kalikiana> t1mp: I don't use the same finger to type an e, probably rested on the l for longer and accidentally touched it
<t1mp> ah; lazy finger.
<kalikiana> fginther: *nod* I would even say a brief message w/o any details could be helpful; doesn't have to replace anything but reduce time spent on the wrong end of the problem
<kalikiana> though it might be equally non-trivial to implement I guess
<fginther> kalikiana, https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1246380
<ubot5> Ubuntu bug 1246380 in Ubuntu CI Services "Provide running reports for upstream merger test failures" [Wishlist,Triaged]
* retoaded changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: retoaded | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<didrocks> ogra_: hey!
<ogra_> didrocks, yo
<didrocks> how are you?
<ogra_> why did you revert the seed change again ?
<ogra_> fine, thanks
<didrocks> ogra_: yeah, missing stuff on the Mirâ¦
<didrocks> MIR*
<didrocks> should be finally resolved today
<ogra_> well, we can drop the package from the seed anyway
<didrocks> do you know why image 8 didn't run the unity8 AP tests on mako?
<ogra_> independently of the MIR i think
<didrocks> ogra_: yeah, we want to do everything in a shot (late yesterday, so prefered to not do it)
<ogra_> didrocks, because Mir crashes ?
<didrocks> ok, it's confirmed it's the cause?
<ogra_> no idea, its definitely one cause
<didrocks> do you think it worth rekicking an image now?
<ogra_> the tests are all shaky with that bug
<ogra_> no, it isnt
<ogra_> we need the Mir team to fix the crasher
<ogra_> didrocks, still bug 1245958 ...
<ubot5> bug 1245958 in unity-mir "Apps crash with image 8" [Critical,In progress] https://launchpad.net/bugs/1245958
<ogra_> i wouldnt consider any test reliable until thats gone
<ogra_> (and apparently it broke other stuff like CI too)
<didrocks> ogra_: ok, we have a branch apparently
<ogra_> right, no package though
<ogra_> i know davmor2 is eager to test it
<didrocks> ken is testing as well
<didrocks> and we'll deliver ASAP
<ogra_> yay
<ogra_> no idea if there are other subsequent issues, i fear this one shields other issues that we will only see after the fix
<davmor2> if I have a deb I can just not got the time to learn to cross-compile from source
<ogra_> especially something with complex deps
* retoaded changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: fginther | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<thomi> Hello CI team... Pretty soon we're going to be porting the autopilot test suites to python 3.
<thomi> However, we'd like to be able to port them one by one
<thomi> but, that means that some test suites will need to be run with the python3-package, and others with the older python-autopilot package
<thomi> I'd like a way so we can do this without that being a massive PITA for you guys
<thomi> like, maybe we can somehow specify which suites should be run with python3 somehow so you gusy don't need to update your configuration every time we port another test suite
<thomi> ...or something like that.
<thomi> Who should I be talking to to make something like that happen?
<cjohnston> I'd guess fginther
<thomi> As far as timeline is concerned, we're probably looking at a couple of weeks away...
<thomi> maybe 3 weeks, actually
<cking> plars, i see a i386 power test has completed, can you kick off an amd64 power test and then another i386 and amd64 test so I can sanity check the results?
<plars> cking: will do - did they results look like they were ok with your new changes?
<cking> plars, they look OK to me
<plars> cking: great
<cking> plars, just like to see some results of more runs now to ensure I've not introduced too much variability
<plars> cking: understand
<alan_g> ogra_: we've confirmed and top approved the fix for bug 1245958
<ubot5> bug 1245958 in unity-mir "Apps crash with image 8" [Critical,In progress] https://launchpad.net/bugs/1245958
 * ogra_ hugs alan_g 
<fginther> thomi, yes, lets talk
<fginther> thomi, is there going to be a new python3-autopilot package?
<thomi> fginther: already exists
<thomi> :)
<thomi> what doen't exist is python 3 versions of the meta-packages
<thomi> i.e.- autopilot-touch and autopilot-desktop. but since those are meta-packages we can create them easily enough, if they'd help
<fginther> thomi, the apps themselves will need to depend on the right python3-autopilot or python-autopilot, right. Does that not solve the problem?
<thomi> fginther: is that what you guys do? just install that package?
<thomi> if so, then yeah, that's easy :)
<cjwatson> thomi: can't you just make it depend on both?  python-* and python3-* should be coinstallable
<fginther> thomi, that might not be how it works now.
<thomi> cjwatson: no, they both install /ust/bin/autopilot
<cjwatson> that's a bug :)
<cjwatson> should be in a common package
<thomi> cjwatson: patches welcome :)
<thomi> fginther: maybe we should do a single porting and see what happens
 * cjwatson runs away to the warm friendly coreutils build
<fginther> thomi, but if just don't pre-install any autopilot, then the deps should get us the right version
<fginther> thomi, I'm all for a test case, I'm sure it will expose some issues
<fginther> thomi, I can see it being a problem for image testing.
<thomi> fginther: yeah, ok.
<fginther> and testing as a click package
<thomi> indeed
<fginther> thomi, so yeah, lots of issue to fix first
<thomi> well, I'm not doing this till 1.4 is out anyway
<fginther> thomi, https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1246425
<ubot5> Ubuntu bug 1246425 in Ubuntu CI Services "Need to support simultaneous testing of python-autopilot and python3-autopilot test suites" [High,Triaged]
<thomi> fginther: sweet, thanks
<davmor2> ogra_: so when does image 9 land :)
<ogra_> davmor2, once the bug is fixed
<ogra_> (once there is a package with the fix in the archive)
 * davmor2 curses lp for not being instant at creating packages, why do you have to take minutes damn you :D
<ogra_> davmor2, minutes ?!?
<ogra_> LOL
<ogra_> lets talk again in a few hours
<davmor2> ogra_: shhhh
 * ogra_ is grumpy 
<ogra_> all google SMS services dont work for me :(
<fginther> Mirv, can you dput qtcreator for trusty into ppa:ubuntu-sdk-team/ppa?
<Mirv> fginther: sure, bzoltan was working on getting it sponsored to archives but it has not yet happened
 * Mirv pushes
<fginther> Mirv, bzoltan just pinged me in another channel, he may already be working on updating the ppa
<Mirv> fginther: I see the discussion
<fginther> Mirv, do we also need a trusty qtdeclarative-opensource-src? I can't find any packages
<Mirv> fginther: we sure have qtdeclarative on top of which all apps run https://launchpad.net/ubuntu/+source/qtdeclarative-opensource-src
<fginther> ... I can't find any packages using http://packages.ubuntu.com
<Mirv> fginther: what we do need is qtcreator-plugin-ubuntu, after the qtcreator. so the cu2d-config rule should be extended to trusty
<fginther> Mirv, I'm not sure what you mean
<Mirv> fginther: qtcreator-plugin-ubuntu has autolanding to SDK PPA for precise,quantal,raring,saucy in head/sdk.cfg, trusty should be added. it needs the qtcreator-dev
<fginther> Mirv, ah, yes, you're correct
<fginther> Mirv, argh! they were all updated except for qtcreator-plugin-ubuntu
<Mirv> fginther: well without this manual upload of qtcreator it wouldn't have compiled anyhow
<Mirv> since the trunk doesn't work against QtC 2.7
<fginther> Mirv, I'll get if fixed before the next MP lands
<Mirv> fginther: thanks
<sil2100> Mirv: hi! Remember guys that if you have some stuff that needs to be done, just assign it to me in the Landing Plan or the Ubuntu Unity Team Work, ok? ;)
<sil2100> Mirv: in the meantime I'll deal with misc issues and the appmenu Qt5 for 5.2
<sil2100> Mirv: have a nice work-day guys \o/ ;)
<fginther> Mirv, thomi, not sure who to contact. They're might be a regression in autopilot in the daily-build ppa, but based on a very small sample size...
<fginther> I have a notes-app MP that fails on desktop when using the daily build PPA, but passes when the PPA is removed
<fginther> there are only a few differences in the dpkg log, one of them being autopilot 1.3.1+13.10.20131003.1-0ubuntu1 -> 1.3.1+14.04.20131030.2-0ubuntu1
<fginther> but there have been any autopilot changes since 2013-10-14
 * fginther realizes he was looking at the wrong branch
<fginther> still, no changes on autopilot/1.3 since  2013-10-15
<thomi> fginther: hey, sorry - was at lunch
<thomi> fginther: so, autopilot hasn't changed in that period?
<thomi> so we're off the hook?
<fginther> thomi, I honestly don't know. I'm still trying to make sense of the logs
<thomi> OK. I don't think we've merged much into 1.3
<fginther> thomi, AFAIK notes-app is the only thing that's failing and it hasn't passed yet with trusty
 * fginther updates laptop to trusty
<thomi> Hi guys - I realise this is probably going to be a massive PITA, but I wonder if we could somehow run the Ap tests for the branches listed here: http://pad.ubuntu.com/autopilot-1-4 with autopilot 1.4?
<thomi> We're porting these to be compatible with 1.4, but the CI runs use 1.3, so our tests fail in CI.
<thomi> it'd be nice to know that the CI system passes the tests as wel
<thomi> l
<thomi> outside of developer machines
<thomi> but if it's too hard to achieve, then I guess we'll do withotu
<thomi> *wihtout
<thomi> dammit
<fginther> thomi, let me see what I can do
<fginther> thomi, do you have a PPA with 1.4?
<thomi> fginther: ppa:autopilot/experimental
<fginther> thomi, thx
<didrocks> fginther: hey!
<fginther> didrocks, greetings!
<didrocks> fginther: so, I have feelings, but I would prefer numbers on the upstream merger :)
<ogra_> didrocks, mir is stuck in proposed
<didrocks> ogra_: ken should look at that
<ogra_> (and i'm really to tired to fix this tonight)
<didrocks> ogra_: I'll have a look, don't worry
<didrocks> fginther: with our "silos" for stack, how often do we have failures because of something else moved outside of the local repo?
<didrocks> cyphermox: can you either grab ken or look at why Mir is stuck in proposed?
<cyphermox> sure
<fginther> didrocks, very rarely
<cyphermox> I'll look now
<ogra_> didrocks, it depends on ust ... which in turn depends on ltt-bin, lttng-tools, python-autopilot-trace ... one of them is stuck as i understand
<didrocks> fginther: ok, thanks for your feedback :)
<didrocks> cyphermox: thanks!
<cyphermox> correct, that's the reason
<cyphermox> ust is blocking it
<ogra_> yep
<didrocks> cyphermox: blocking because tests are running?
<infinity> didrocks: No, SONAME transition.
* fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<infinity> didrocks: autopilot and ltt-contol need transitioning to the new ltt-whatever2.
<infinity> (In progress)
<didrocks> infinity: ok, thanks! (quite ironic Mir being block on another SONAME transition)
<didrocks> blocked*
<ogra_> didrocks, if i'm still around, i'll trigger a build, else tomorrow morning
<ogra_> (or if infinity likes to ...)
<didrocks> ogra_: don't worry, go homeâ¦ well, go to bed :)
<ogra_> heh, cant be more home :P
<ogra_> i'm still up for a while and will take a look before going to bed later ... if its ready i'll trigger a build
<didrocks> ogra_: ok, just ping me if it's the case (as there is no way for me to know if a build was kicked)
<ogra_> yeah, i'll ping here
<thomi> cihelp can someone help me figure out why this is failing? https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-maguro/2839/console
<thomi> it ends with "top write error", which sounds to me like a CI problem
<fginther> thomi, did you mean this one? https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-maguro/2838/consoleFull
<fginther> thomi, the failure is caused by ppa:phablet-team/ppa not having any packages, /me wonders if this job even needs it
<fginther> errr, any 'trusty' packages
<xnox> fginther: yeap, i've pinged #qa team to upload _anything_ for trusty such that a pocket for trusty is published, but they didn't do that yeat.
<xnox> fginther: wait phablet-team? i might have access. let me check.
<thomi> fginther: hmmm
<thomi> fginther: a better question to ask would be: why is this MP failing to land? https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1244518-composer_sheet_object_names/+merge/192641
<xnox> nah i'm not.
<thomi> I can't see anything obvious in any of the failing jenkins jobs
<fginther> thomi, there is one test failure: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-maguro/2839/testReport/
<thomi> fginther: oh.. thanks. Not sure how I missed that
<fginther> thomi, xnox, I have to drop off for family time. I'll be back in 3 hours or so if I can help further
<thomi> thanks fginther
<ev> cihelp, can someone tell me how many machines and what spec are being used to do build on commit in our infrastructure, and are we generally keeping up with the queue (are we over/under provisioned)?
<ev> retoaded: ^ ?
<doanac> ev: probably more for fginther ^
 * ev nods
<ev> also, can someone tell me how many builds we're doing, and the total build time on average?
<cjohnston> ev: sounds like an email question and allow ~a day to respond. I realize your probably in a meeting and that came up, but its after 5 for I think everyone on the team
<ev> cjohnston: I didn't ask for a quick response
<ev> fginther: just so you have the context, elmo is trying to get some idea of the load if we moved to a PPA-build-per-commit setup in the London DC
<ev> so whatever numbers you can provide when you're back online would be much appreciated
#ubuntu-ci-eng 2013-10-31
<sergiusens> ev, not sure of the actual load these days, but the calxeda's that came in sure made it a lot less dramatic for the ex-PS stuff; I do want to say that we use to have a dput per merge into PPAs (binary version of trunk) and were told to stop doing that because we were overloading the system; again this is prior to calxeda
<sergiusens> if resource wise is ok, all that would need to be devised is a way to pull out the test results; not that it would be difficult
<Mirv> infinity: rmadison reports new mir is in, didrocks suggested to ask you to kick off a new image build?
<Mirv> cyphermox: FYI ^
<didrocks> ogra_: we can kick an new image (in case infinity can't get it before you are online). The Mir fix is in
<Laney> ogra_: infinity: is there any more to that than running the line from crontab?
<Laney> (I could do it)
<infinity> Laney: Should be just that.  Sorry, was in transit between hotels.
<Laney> mmkay
<infinity> Laney: You already doing it, or should I?
<didrocks> infinity: ok, Laney volonteered :)
<Laney> voluntold
<plars> ev: We could look at the images on system-image and cdimage for better numbers, but it's generall 1-2 builds/day. We didn't have one today though
<plars> in case anyone was waiting around for it, image showed up and tests have started on it - the image ci shouldn't truncate .crash files anymore too
<plars> asac, ogra_, rsalveti: gallery passes again \o/
<rsalveti> plars: :D
<ogra_> plars, yay
<jibel> cyphermox, your latest upload of autopilot 1.3 breaks system upgrade if python-autopilot-strace is installed bug 1246620
<ubot5> bug 1246620 in ust (Ubuntu) "upgrade failed: trying to overwrite '/usr/lib/x86_64-linux-gnu/liblttng-ust-tracepoint.so.0.0.0', which is also in package liblttng-ust0:amd64 2.1.1-6" [High,Triaged] https://launchpad.net/bugs/1246620
<sil2100> jibel: got the same issue yesterday when upgrading my desktop
<sil2100> cyphermox: ^
<sil2100> fginther: hello, poke me back when you're around :)
* psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<plars> psivaa, ogra_: did you see that ubuntu-ui-toolkit tests are all failing now?
<psivaa> plars: uitoolkit passed in image 9 iirc
<ogra_> no, i noticed that maguro had not run gallery when i looked last
<ogra_> (but thats a while ago)
<psivaa> i re-ran gallery and it passed
<ogra_> great
<plars> psivaa, ogra_: *sigh* sorry, nevermind me... I've been up since 3am de-flooding my house
 * psivaa checks the time in texas 
<plars> psivaa: it's 5am now
<ogra_> plars, urgh !
<plars> psivaa: I saw you restarted unity8 on mako, thanks - it looks promising from what I saw on maguro
<psivaa> plars: yea, just reran a few jobs. the passrates are actually good with 9
<t1mp> would it be a good idea not to accept a new image if it doesn't pass UITK (trunk) autopilot tests?
<plars> psivaa: I saw, awesome
<plars> ogra_: psivaa reran that one already on maguro
<plars> ogra_: it was good
<t1mp> and with "accept a new image" I mean make it the new default image for CI
<psivaa> plars: btw good luck with de-flooding and  having a bit of sleep :)
<plars> ok, I'm going to go at least lay down for a bit, I think sleep is out of the question at this point
<ogra_> oh man
<ogra_> good luck
<ogra_> psivaa, do we know why unit8 fails on mako ? smells like not unlocked or some such
<psivaa> ogra_: not really, we have a better passrate on maguro. unfortunately i dont have a mako to locally test
<psivaa> looking through the logs to see anything obvious
<psivaa> ogra_: we have unity8 crash there
<ogra_> we do on maguro as well though
<ogra_> two even
<psivaa> yea, lauch_unity is failing, tried looking at the network camera and can't see any movements. that may be pointing that the screen is locked
<ogra_> yup
<popey> ogra_: no new build yet?
<ogra_> hmm ? we have #9
<ogra_> was built at 3am UTC
<ogra_> (and still didnt pass the unity8 test on mako)
<psivaa> untiy8 on mako was tried again after re-flashing, still dint pass.
<ogra_> :(
<popey> oh, sorry, i thought #9 was the old broken one, not the new broken one ã
<davmor2> popey: No 8 was the old broken one :)
<davmor2> popey: at least apps stay open long enough to do things now :)
<ogra_> right, 9 looks pretty good ... except that unity8 thing :/
<popey> ogra_: would you recommend upgrading my test phone to #9 or is it unusable?
<ogra_> popey, looks fine on maguro is all i can say
<ogra_> i wont upgrade my mako now that it replaces my android phone :)
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
 * popey updates
<popey> ogra_: next time you use update manager and see new apps, before you install them can you please see if you can reproduce bug 1245890
<ubot5> bug 1245890 in Unity 8 "Pinning to launcher followed by upgrade, breaks pinned app link" [Undecided,New] https://launchpad.net/bugs/1245890
<ogra_> popey, cant confirm, this works for me
 * ogra_ usually adds his new apps in the stroe to the launcher ... they all still work fine
<popey> hm
<sergiusens> popey, that's a dup
 * ogra_ shakes his fist at google 
<sil2100> fginther: hello! Re-ping ;)
<sil2100> fginther: did you see my annoying PM?
<fginther> sil2100, sorry, just saw it
<fginther> sil2100, one moment
<sil2100> Thanks!
<boiko> hi guys, I need a new release of lp:history-service, how should I proceed?
<cjohnston> boiko: http://paste.ubuntu.com/6292280/
<sil2100> boiko: hi!
<boiko> cjohnston: hi, so, I have seen those instructions, but there is no link to the Landing Asks sheet
<boiko> sil2100: hi!
<sil2100> boiko: as it's history-service we're talking about, I would proceed by adding it to the Landing Asks
<sil2100> boiko: let me give it to you, but you should actually ask your manager to do that
<ogra_> yeah, unlikely you can edit it
<sil2100> boiko: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=1
<cjohnston> what sil2100 said
<ogra_> after all it is still the same process we use since twoo months though
<sil2100> boiko: we can then follow up and get it released in the nearest time - since didrocks is on a sprint I guess it might take till next week to get it released? Depends if the guys in Oakland pick it up or not
<boiko> sil2100: oh right, thanks, I am just asking directly cause everybody is at the sprint
<ogra_> popey, did you try #9 on mako yet ?
<sil2100> boiko: I would try releasing it myself, but I would first need management permission, and they're at the sprint as well...
 * ogra_ wonders if unity8 is fine in real life ... compared to the failing tests 
<sil2100> boiko: what issues does it fix?
<sil2100> ogra_: I can upgrade my device if needed
<ogra_> sil2100, why do you need management approval ? if the AP tests pass and you cant see a regression in a manual smoke test it shouldnt be blocked on this
<boiko> sil2100: well, the one bit I need released is the pkgconfig support, but there has been other changes there as well (things that were pending from the last cycle)
<sil2100> ogra_: I didn't know if that's ok right now - but if you say that, then I guess!
<ogra_> well, we shouldnt block on them not being here ... as long as the landing appears safe
 * sergiusens thinks that when managers go on sprint they should get some peer+1 assigned
<ogra_> (test twice if you feel thats safer :) )
<sil2100> ;)
<sil2100> In my case even testing thrice won't help
<sil2100> :D
<sil2100> Anyway, thanks, then I'll look into it and try getting it released
<ogra_> well, if it doesnt pass, indeed, keep it til next week
<ogra_> but things that pass safely shouldnt be blocked by missing managers
<boiko> sil2100: I can ask my manager if that makes you more comfortable, that's fine, the landing is not urgent
<popey> ogra_: yeah, it's been fine here
<ogra_> thought so
<ev> plars: excellent news on no longer truncating crash files
<ev> on the frequency of builds, I was referring more to how often we're running dpkg-buildpackage within the CI infrastructure
<cyphermox> jibel: well, it's not a breakage in autopilot.
<cyphermox> jibel: that said, it's on my list, I'll fix it shortly
<cyphermox> sil2100: ^
<sil2100> cyphermox: thanks!
* doanac changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: doanac | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<ogra_> doanac, hey ...
<doanac> ogra_: what's up?
<ogra_> doanac, it looks like we have issues with unlocking the screen on mako with the unity8 tests ...
<ogra_> psivaa ran them multiple times on image #9 ... he checked with the webcam and apparently the screen doesnt show anything ... popey tested #9 manually and unity8 behaves fine
<doanac> ogra_: i don't think we run unlock_screen for unity8. we just kill the shell before running.
<doanac> checking now
<ogra_> hmm
<psivaa> doanac: the issue is only on mako, we are though not 100% but fairly well in maguro
<ogra_> well, there seems to not be anything unusual in the logs apparently
<psivaa> doanac: lauch_unity is failing
<doanac> let me test locally and see what happens
<Mirv> sil2100: are the cu2d problems because of autopilot or what's all the red about?
<Mirv> sil2100: there seem to have been also multiple manual uploads I guess (yellow)
<doanac> ogra_: i'm running the test at home and its failing the same way
<ogra_> wow
<ogra_> i wonder what makes mako special then
<sil2100> Mirv: autopilot was reddish today as well, so I would say it's fifty-fifty - I was mostly dealing with other things today so I didn't administer cu2d in detail
<Mirv> sil2100: it's not autopilot tests, the check job looks problematic in general somehow http://10.97.0.1:8080/job/autopilot-trusty-daily_release/281/label=autopilot-nvidia/console
<Mirv> lxc problem?
<sil2100> Mirv: I was using the autopilot jobs directly today, without cu2d, and just saw that there was a loong stroke of red jobs, but didn't have a moment to look into that
<sil2100> Let me also look at that now
<sil2100> Mirv: ah, this one - this one I saw happening once, but then next time the machine ran fine
<Mirv> sil2100: it seems it's nvidia specific
<sil2100> Yes, let me find my job, one moment
<Mirv> then under qa there is also a missing package when looking at the intel side
<sil2100> Aaah
<sil2100> Mirv: ok, my mistake, it was happening all the time on nvidia, so it seems to be b0rken
<Mirv> sil2100: can you look at that still, you have much more skillz in the lxc area? :)
<Mirv> I'm fixing at least qa package list now
<sil2100> Ok, let me take a look then
<Mirv> my main problem is that if it complains about a missing container, I wouldn't know immediately where I should see the containers etc.
<sil2100> hmm, I might see one of the problems
<sil2100> The permissions to the containers directory got changed, not sure if jenkins user can access them this way - so it cannot find them
<sil2100> Let me try fixing that
<doanac> fginther: the permissions thing ^^^ - weren't you seeing something similar the other day?
<sil2100> Mirv: let's run some test now maybe?
<Mirv> cyphermox: synced your autopilot manual upload to the branch to make the prepare job work again
<Mirv> sil2100: aha.. ok, I'll try
<Mirv> sil2100: QA running
<Mirv> sil2100: actually there's another check ongoing, nvidia seems to be running
<Mirv> let's wait
<sil2100> Mirv: keeping my fingers crossed!
 * sil2100 wonders if that's the issue
<sil2100> We'll see soon enough
<cyphermox> thanks
<jibel> sil2100, Mirv this is a change in lxc 1.0.0~alpha2-0ubuntu5, you can revert that change by chmod'ing /var/lib/lxc to make it readable by any user.
<jibel> sil2100, Mirv next upgrade won't touch it
<cyphermox> jibel: so I looked at NM again, hard, and I can't figure anythign wrong with dnsmasq... would it be possible to have the autopkgtest run again so I could see what goes on?
<sil2100> jibel: did that
<jibel> cyphermox, sure, but it ran again this morning and I had to kill it again. Didn't pitti found the reason?
<sil2100> jibel: that's what I'm trying to test now :)
<Mirv> jibel: cool, thans
<cyphermox> jibel: oh, you did
<sil2100> But good, then I diagnosed it correctly, thanks
<jibel> sil2100, at least that what is written in the changelog :)
<cyphermox> jibel: alright then
<cyphermox> jibel: I haven't heard back from piiti about it..
<cyphermox> jibel: was the environment build from a server image or from minimal?
<fginther> doanac, where? Yes we saw an issue with the workspace dir getting set to 600 causing jenkins to complain of mkdir failures
<jibel> cyphermox, it's based on a server cloud-image http://developer.ubuntu.com/packaging/html/auto-pkg-test.html#executing-the-test is you want to test locally
<cyphermox> weee
<cyphermox> awesome, that's what I expected.
<cyphermox> I'll definitely give it a good look, I think I know what the issue is
<sil2100> Mirv: did it help?
<sil2100> I need to disconnect now, but I'll be back in like 3-4 hours
<sil2100> Mirv: drop me an e-mail if anything ;)
<Mirv> sil2100: yes it helped
<Mirv> at least initially it looks so
<sil2100> \o/
<Mirv> ok soon many of the stacks should be greener/yellower, as I'm rerunning check jobs for a bunch of them
<alan_g> fginther: I've seen some Mir jobs today with "E: Unable to locate package liblttng-ust0" e.g. https://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/73/console - can you help?
<Mirv> build failures in some too, though
<cyphermox> Mirv: https://code.launchpad.net/~mathieu-tl/indicator-datetime/13.10.0+13.10.20131023.2-0ubuntu1/+merge/193460
<Mirv> +1
<cyphermox> jibel: what hoops do I need to go through if I want to delete that offending test?
<cyphermox> it's just too broken, not bringing much usefulness
<cyphermox> (it's running fine on my machine with the auto testing scripts)
<cjwatson> alan_g: mir should've been rebuilt against liblttng-ust2 recently, I thought
<cjwatson> alan_g: looks that way in trusty anyway.  maybe transient?
<cyphermox> cjwatson: what was the issue?
<cjwatson> cyphermox: 17:10 <alan_g> fginther: I've seen some Mir jobs today with "E: Unable to locate package liblttng-ust0" e.g. https://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/73/console - can you help?
<fginther> cjwatson, thanks for the reping
<alan_g> cjwatson: Hmm... I guess the https://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/73/console runs the tools/setup-partial-armhf-chroot.sh script?
<cyphermox> ah, yeah
<alan_g> and that script needs to pull liblttng-ust2?
<cyphermox> that should just be happening automatically, python-autopilot-trace depends on it
<cjwatson> alan_g: That's beyond my knowledge, but I would've hoped it'd be following mir's dependencies rather than hardcoding a library name
<cjwatson> cyphermox: Downloading mir dependency: liblttng-ust0
<cyphermox> oh, mir
<cjwatson> I think it's probably worth retrying to confirm it's gone
<cjwatson> Which it should be ...
<alan_g> cjwatson: that's an embarrassing script, but no-one has spent the time to fix it properly
<cyphermox> ah
<cyphermox> yeah, that's hard-coded there
* plars changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: plars | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<cjwatson> hardcoded> yikes!
<fginther> :q
<fginther> alan_g, cjohnston, cyphermox, so problem solved? setup-partial-armhf-chroot.sh needs to be updated?
<cyphermox> yeah. updated with rm if possible ;)
<cyphermox> fginther: otherwise I'd like to fix it to get the right stuff from debian/control
<fginther> cyphermox, I'll leave that to the mir team
<alan_g> fginther: yeah - I'm at EOD. I've passed the problem to kdub ;)
<cyphermox> I'll propose a merge to repair this... I don't know what they use the script for really, but if it can't be dropped then..
<renato_> fginther, could yo help me with this MR: https://code.launchpad.net/~om26er/mediaplayer-app/imrove_autopilot_tests/+merge/184584
<cjohnston> renato_: you should probably try the vanguard first
<cjohnston> renato_: it looks like there is a test failure
<fginther> renato_, the armhf node died during the build too
<renato_> fginther, cjohnston I have approved again
<plars> fginther, renato_: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-maguro/2813/console looks like unlock failed also
<fginther> plars, the unlock worked on the second attempt
<plars> fginther: ah, ok I see
<plars> fginther: why is there no rebuild link on this one? do we just need to retry and post results manually if it passes?
<Mirv> plars: fginther: are you look at this one we'd need to launch a new image build? https://code.launchpad.net/~saviq/unity8/move-setenv/+merge/193426 (the e-mail thread "Unity 8 AP tests on #9")
<fginther> plars, it was triggered by an approved MP, so to rebuild, you need to re-approve the mP
<plars> fginther: I have no rights to do that
<plars> fginther: do you?
<fginther> renato_, there are a number of test failures, it may fail again
<fginther> plars, yes, renato_ already re-approved
<renato_> fginther, where did you see that
<fginther> UNSTABLE: http://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/185
<fginther> renato_, something bad happened here too: FAILURE: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-maguro/2813/console
<renato_> fginther, let me see if something change in the code since this mr was created because the first build works nice
<fginther> renato_, the maguro failure looks like a possible crash
<fginther> renato_, ahh, this was on build 8. that had some known issues
<fginther> renato_, let me see if I can find the bug
<plars> Mirv: it seems to have restarted
<plars> Mirv: it's running now
<fginther> renato_, https://bugs.launchpad.net/mir/+bug/1245958
<ubot5> Ubuntu bug 1245958 in Mir "Apps crash with image 8" [Critical,Fix committed]
<renato_> fginther, do you think this will work now?
<renato_> bfiller, ^ ^
<fginther> renato_, the mako/maguro tests should be more stable
<bfiller> fginther: looks like the otto test failure is because correct codec not installed? https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/185/testReport/junit/mediaplayer_app.tests.test_player_with_video/TestPlayerWithVideo/test_show_controls_at_end_with_mouse_/
<fginther> bfiller, renato_, if that's the cause, then we should be able to resolve it by adding a dependency to the -autopilot package
<renato_> rsalveti, told me to no do that
<bfiller> fginther, renato_ : I'll check with rsalveti  - seems we need this, at least for otto
<fginther> ack
<Mirv> plars: yeah, I just didn't do something so I'm wondering if you'd understand more of the problems it's seeing.
<Mirv> plars: I'm not holding my breath that it'd now succeed automatically
<plars> Mirv: it's not a failure I've personally seen before, did anything change? looks like it passed at one point in the mp
<bfiller> renato_: rsalveti said we shouldn't be testing mp4, and you should convert that to ogg or other free format
<renato_> bfiller, ok I will try that
<bfiller> renato_: mp4 works on the device because it's using hardware decoding and doesn't need gstreamer-ugly, but on desktop that won't work without that pacakge. And you are right we don't want to install the -ugly
<renato_> I am afraid that, the ogg does not work well on device (In the last time that I tried)
<renato_> this was before the the new gst plugin
<rsalveti> renato_: we might indeed have issues with a different format, but we need to use an open format
<rsalveti> renato_: can you convert and post the video somewhere so we can test?
<rsalveti> renato_: other we might indeed, temporarily, add the av/ffmpeg dependency for the test itself
<rsalveti> *otherwise
<renato_> rsalveti, give me a minute I will transcode the video
<renato_> rsalveti, https://chinstrap.canonical.com/~renatofilho/videos/
<plars> Mirv: well, it looks like it was mediumtests-trusty and qmluitests that failed last time, and they are passing now
<renato_> could you try
<plars> Mirv: it's not 100% complete yet, but so far so good
<plars> Mirv: looks like it passed this time https://code.launchpad.net/~saviq/unity8/move-setenv/+merge/193426
<plars> Saviq: ^
<Mirv> plars: \o/ launching build
<Mirv> great
<renato_> fginther, what is this error: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-maguro/2877/console
<fginther> renato_, looks like the device lost adb connection during the test. It's also at the same point in the test as https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-maguro/2813/console
<fginther> renato_, is it possible the test itself is causing the device to reset?
<renato_> fginther, I do not know, do you want me to try again:
<fginther> I'll try another build of just the maguro job
 * Mirv testing unity8 with the setenv fix
<ogra_> Mirv, plars, any reason why we dont just set that in the upstart job ?
<plars> ogra_: maybe a question for Saviq
<Mirv> yep, Saviq ^
<ogra_> seems more appropriate for hacks ... also makes them more visible and saves you from changing the binary if you need to change or drop it
<ogra_> (not that this is overly important, just noticing it)
 * Mirv published unity8
<Mirv> ogra_: #10 after that, or do you know what's the plan?
<Saviq> ogra_, well, wherever they are - they shouldn't even be needed
<Mirv> unity8 now in release pocket
* plars changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: - | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<ogra_> Mirv, i'll trigger a build in the morning
 * ogra_ is off for the night
<didrocks> Laney: infinity: can one of you kick a touch image build?
<Laney> ok
<didrocks> there is an unity8 fix that we are interested in :)
<didrocks> thanks!
<Laney> did the one I did yesterday work?
<didrocks> we should finally get a better pass rate
<didrocks> Laney: yeah, perfect! (but unity8 was crashing in the tests :p)
<didrocks> Laney: I won't blame you though ;)
<Laney> ok, just wondering, you get no feedback
<Laney> going
<didrocks> thanks!
<popey> how long does it usually take for the build?
<didrocks> popey: more than an hour
<didrocks> actually ~40 minutes for the ubuntu part
<popey> k
<popey> will have a play in the morning hten
<didrocks> then, I heard some 20 minutes for assembling the android one
<didrocks> popey: yep ;)
<didrocks> popey: still awake? getting late, isn't it?
<popey> yeah, watching politicians argue on telly before bed â»
<greyback> some people count sheep
#ubuntu-ci-eng 2013-11-01
<ogra_> Laney, http://reports.qa.ubuntu.com/smokeng/trusty/touch/ has the feedback ;)
<ogra_> (your #9 build was the best one we had in a long time)
<ogra_> psivaa, looks like gallery didnt run again on maguro
<ogra_> (and unity8 fails still the same way on mako)
<psivaa> ogra_: i'll take a look at them
<ogra_> thanks
<popey> ogra_: #10 seems good here
<ogra_> popey, havent done calls/sms yet,. but from what i see atm here too ...
<ogra_> to sad the fix didnt work though
<ogra_> (which apprently was the only change vs #9)
<popey> calls/sms work fine here
<popey> â¹
<ogra_> yup, looks fine here too
<ogra_> if we could get the dashboard a bit greener i would actually propose to promote this
<psivaa> ogra_: re: unity8 failures on mako, there was a new upload to unity (7.83+14.04.20131031-0ubuntu1) but it dint fix the issue apparently
<psivaa> Mirv: ^
<ogra_> psivaa, yeah, see whay i wrote above :)
<ogra_> *what
<psivaa> ok, known then :)
<ogra_> well, probably not by Mirv yet :)
* josepht changed the topic of #ubuntu-ci-eng to:  Ubuntu CI Engineering Team | Vanguard: josepht | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<fginther> morning
<plars> balloons: a couple of things you might be interested in: 1. I got clock to finally pass today on maguro after a rerun, it's been failing for a while, includeding the first time it ran on image 10
<plars> 2. weather is failing some extra tests on mako - even after rerunning, I'll try again but that's kinda strange
<ogra_> plars, psivaa, did anyone try to re-run munity8 on mako yet ?
<ogra_> the image looks so good, would be a shame to not promote it ...
<ogra_> but i dont want to with these unity test results
<plars> ogra_: I can, did we expect it to be fixed now?
<ogra_> plars, yes, apparently it didnt suffice though
<plars> ogra_: I'm restarting it now
<ogra_> Mirv was pinged about it above
<plars> ogra_: but it looked the same on the custom image with mako also
<plars> ogra_: so I suspect it's still broken
<ogra_> (probably we should also poke Saviq )
<ogra_> yeah
<ogra_> me too
<plars> ogra_: failures are still the same
<plars> ogra_: after the rerun
<ogra_> *sniff*
<ogra_> plars, how is the house btw ?
<ogra_> all dry again ?
<plars> ogra_: mostly, we came out ok. Some people not far from us were stuck in trees, on rooftops, etc
<plars> we are up high enough that it wasn't so bad
<ogra_> ugh
<plars> ogra_: also we are a bit farther away that they are from the creek that got to 19 feet above flood level
<ogra_> wow
<plars> (about 5.7 meters for the metric folks)
<ogra_> yep, my brain turned into ~5m :)
<ogra_> we have that in the east of germany regulary every year since a few years ...
<ogra_> and it seems to be higher with the years
<ogra_> (and didnt occur at all 20years ago)
<plars> ogra_: yeah, it comes in cycles. Nearest similar flooding in my immediate area was in 1925 or somthing like that
<ogra_> yep
<ogra_> well, i guess the water from the melting ice caps has to go somewhere ... and if it isnt the sea it is the atmosphere
<sergiusens> heh, we get a bit of rain here from time to time and some areas with very little go up to 3m (it never rains here)
<fginther> josepht, want to help review? https://code.launchpad.net/~fginther/cupstream2distro-config/core-apps-trusty/+merge/193612
<josepht> fginther: sure
<doanac> plars: i just noticed our unity8 touch  test still installs the unity8-autopilot package. is that really needed?
<plars> doanac: iirc we needed that to bring in some dependencies right?
<doanac> sergiusens: you remember? ^^^
<plars> doanac: but in reality, it's going to run the tests out of the click-test-setup installed bits since they are in the python path
<doanac> plars: that's true, so it might just be to pull in some other dep
<doanac> someone should thank thomi_ for making autopilot add ./ to the python path. its probably saved a lot of tech support questions over the years :)
<thomi_> doanac: :)
<doanac> thomi_: its quite hard to work around my ignorance - it knows no bounds!
<thomi_> heh
<Saviq> plars, ogra_ the known issue is fixed indeed - not sure yet what's the new thing (it only started happening yesterday or so that all the test started failing)
<Saviq> obviously non-reproducible locally :/
<plars> Saviq: it seems to only happen on mako and not maguro though
<ogra_> Saviq, and restricted to mako
<Saviq> ogra_, yeah
<Saviq> it's aborting somewhere in Mir, nothing obvious, though :/
<ogra_> maguro is probably just to slow to notice any breakage :P
* retoaded changed the topic of #ubuntu-ci-eng to:  Ubuntu CI Engineering Team | Vanguard: leworks | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<plars> ogra_, Saviq: I think I have the tests working locally on mako... no idea why it was a problem on mako and not maguro, but it appears related to the screen not being on properly
<ogra_> yeah, i said that yesterday
<plars> we used to turn it on earlier, but were asked to quit doing that because there was some suspicion that it was causing some sort of powerd problem iirc
<plars> ogra_: ok, I missed that conversation I guess, sorry
<thomi_> fginther: Anny ideas what happened here? http://10.97.0.26:8080/job/autopilot-testrunner-otto-trusty/279/console
<ogra_> plars, yeah, that was easy to miss ... and totally out of your TZ anyway (in my morning)
<fginther> thomi_, sorry, I can't take a look now. please see if cihelp can
<thomi_> fginther: no worries.
<plars> ogra_: do you have any ideas on how to really make sure the screen gets turned on? doanac had previously made a change to do this sooner after the boot, and I think that was pretty effective but iirc asac wanted us to turn that off.  It seems like somtimes using powerd-cli to turn the display on after it's timed out already doesn't work
<ogra_> no, i dont really know anything else but powerd-cli
<ogra_> and i dont know why that was ripped out instead of fixing the apparent race
<thomi_> cihelp: can someone help me figure out how CI runs the Ap tests for the ubuntu-clock app?
<ogra_> since it clearly breaks us now
<thomi_> cihelp: The specific problem is that ubuntu-clock-app isn't in the archive it seems
<plars> ogra_: I think even if the timeout is configurable somehow, that would do the trick
<plars> thomi_: hmm, isn't that one that we run as click now?
<ogra_> yes, but thats a feature thats still missing
<thomi_> plars: could be. If so, how do I configure that in http://10.97.0.26:8080/job/autopilot-trusty-master ?
<thomi_> or maybe I can't?
<plars> thomi_: ah, I thought you meant the image tests, sorry
<thomi_> no worries
<plars> ogra_: so running everything locally on my mako all passes, even if I run it the same way we run it in smoke testing, provided I make sure the screen is on
<ogra_> right
<plars> ogra_: do you know if anyone is working on a configurable screen timeout?
<ogra_> so we should probably add the code that does this back ... even if we have to rip it out next week again
<ogra_> it is a supposed feature of the shell
<doanac> thomi_: probably should ask fginther, but it almost looks like in that test it shouldn't matter if its click or not
<ogra_> so i would expect someone to work on this, yes
<thomi_> doanac: but it fails because it can't install ubuntu-clock-app package
<thomi_> doanac: http://10.97.0.26:8080/job/autopilot-testrunner-otto-trusty/279/console
<doanac> thomi_: isn't it in the archive that gets copied over: http://10.97.0.26:8080//view/mediumtests/job/generic-mediumtests-builder-trusty-amd64/296/artifact/*zip*/archive.zip
<thomi_> doanac: so I don't have to specify it?
<thomi_> I was just copying the deps from debian/control
<doanac> thomi_: not sure. i'm surprised it failed. if you look at the ubuntuuitoolkit job that ran before that (job 278) it did something similar and worked
<thomi_> doanac: yeah, but the sdk *is* in the archive :)
<thomi_> doanac: it's OK, I'll mess around with it some more
<elopio> hey ci team, all tests failed in mako here:
<elopio> https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/2947/consoleFull
<elopio> any idea why?
<elopio> oh, nevermind. Tests are running again. I'll let you know if it fails again.
<cjohnston> elopio: looks like a test failed to me
<elopio> cjohnston: all tests failed. when that happens, just in one of the environments, it's more likely an environment issue.
<om26er> this machines is running low on disk space, can anyone look into that ?
<om26er> http://10.97.0.26:8080/computer/ps-generic-precise-amd64/?
<om26er> ci ^ (incase anyone have that for a highlight)
<cjohnston> om26er: ping the vanguard
<om26er> cjohnston, he is not online it seems
<om26er> actually
<cjohnston> retoaded: you should probably use your nick as 'vanguard'
<om26er> retoaded, ^
<om26er> Saviq, ^
* retoaded changed the topic of #ubuntu-ci-eng to:  Ubuntu CI Engineering Team | Vanguard: retoaded | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<retoaded> cjohnston, thought I had. apparently something else was in mouse memory
<retoaded> om23er ps-generic-precise-amd64 is a vm but I will take a look
<Saviq> retoaded, whatever's happening, jobs for that machine are blocked http://10.97.0.26:8080/job/generic-land/
<Saviq> retoaded, there's a job running for 2 days now, too
<retoaded> Saviq, ack
<Saviq> http://10.97.0.26:8080/job/generic-covlpsync/1394/console
<Saviq> retoaded, thanks
<retoaded> Saviq, 70% of the disk space on that VM is sitting in /tmp; do the jobs not clean behind themselves?
<retoaded> Saviq, used disk space that is
<Saviq> retoaded, no idea
<retoaded> Saviq, space is freed up and the node is processing jobs again
<elopio> ci team, what does this failure mean? https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-maguro/2902/console
<elopio> remote object '/.setup_complete' does not exist
<elopio> SETUP FAILED - CAN'T CONTINUE
<cjohnston> elopio: there was a an issue installing packages so it needs to be rerun
<retoaded> elopio, looks like it failed to resolve ports.ubuntu.com
<elopio> so, just rerun, ack.
<elopio> thanks cjohnston, retoaded.
<cjohnston> elopio: /11
<cjohnston> elopio: sorry. nvm
<elopio> np/
<plars> ogra_, Saviq: ok, I'm pushing a change to move the display-on stuff again right now, and I'll rerun those unity8 tests
<ogra_> awesome
<plars> ogra_: the world just got a little greener: http://reports.qa.ubuntu.com/smokeng/trusty/touch/
<plars> ogra_: we see this hud-service crash there now though
<plars> but that's known I think
<Saviq> plars, awesome, thanks
* retoaded changed the topic of #ubuntu-ci-eng to:  Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
<thomi_> cihelp - I seem to be seeing some otto errors, and I don't understand the errors: http://10.97.0.26:8080/job/autopilot-testrunner-otto-trusty/295/console
<cjohnston> thomi_: E: Unable to locate package ubuntu-clock-app
<thomi_> cjohnston: doh! I just saw the otto message
<thomi_> ugh, thanks
#ubuntu-ci-eng 2014-10-27
<imgbot> === trainguards: RTM IMAGE 130 building (started: 20141027 03:05) ===
<imgbot> === trainguards: RTM IMAGE 130 DONE (finished: 20141027 04:15) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/130.changes ===
<davmor2> Morning all
<davmor2> brendand: is there no landing meeting this morning?
<Mirv> morning
<Mirv> davmor2: lukasz is away at least, I promised to keep an eye on landings
<brendand> davmor2, not sure if ogra_ is around
<brendand> davmor2, i'm not up for a landing meeting anyway :/
<ogra_> i am kind of around, but technically not supposed to do anything else than the scrum sprint
<Mirv> I'd say skip it, then
<davmor2> I only came on this early for the meeting if it isn't on I'll catch you all at 11:00 and I'll go do some shopping instead :)
<davmor2> skip it
<Mirv> ok :)
<Mirv> there are two landings I haven't landed since the bugs are not on whitelists
<popey> \o/
<popey> shopping
 * popey is not here
<brendand> Mirv, which are those?
<brendand> Mirv, the rules have changed so much i wouldn't be surprised if you were confused by now
<Mirv> brendand: they've change so many times by now that I'm definitely confused :)
<Mirv> brendand: rtm-004 and rtm-023
<Mirv> the last rules I understood were that anything that is rtm14+critical can be added to the wishlist, but still the bug would need to be approved on that wishlist or other rtm bug spreadsheets/e-mails before landing
<brendand> Mirv, if they are tagged with rtm14 and a date, then they can be landed
<Mirv> brendand: I understood the tags need to have been verified by PM team? otherwise anyone could add those tags
<Mirv> for example bug #1374397 has the tag but no PM comment
<ubot5> bug 1374397 in trust-store (Ubuntu) "Camera app takes 1 minute to load" [Critical,Fix released] https://launchpad.net/bugs/1374397
<brendand> Mirv, yeah
<Mirv> I think rtm-004 is clear, though, since the only bug referred has touch tag added by PM member
<Mirv> but 023 has that 1374397
<brendand> Mirv, https://bugs.launchpad.net/camera-app/+bug/1374397/comments/11
<ubot5> Ubuntu bug 1374397 in trust-store (Ubuntu) "Camera app takes 1 minute to load" [Critical,Fix released]
<Mirv> brendand: Joe is not on the product team? I understood it should be anyone from the trio olli, pat, victor
<Mirv> ah, damn, olli _has_ modified the tag in there actually, between comments 15 and 16
<Mirv> brendand: so, yeah, 023 is also clear. I stared too much at the lists and not the bug comments/tag operations
<ogra_> Mirv, did you check the original list (004 was on there for example)
<Mirv> ogra_: 004's 1382501 was not on the original 10/23 planning e-mail or wishlists
<ogra_> no, it was on the list we had before
<ogra_> on the initial list, before the mails started
<Mirv> I've now 3 lists I'm checking, but I've probably forgotten about the "original original" list. I though the 10/23 mail had everything known so far.
<Mirv> anyway, these resolved now
<ogra_> k
<ogra_> Mirv, "Fwd: bug assignments for the 10/16 image" on phablet@ (forwarded from ue-leads) has the list
<ogra_> iirc there was another one like 004 that didnt make the milestone
 * ogra_ forgot which or if it landed yet 
 * brendand wonder if there is a blanket allowance for changes to test/ code
<Mirv> ogra_: ah, right, I had that starred too but it looked so similar to the e-mail three days later that I had forgotten about it being different
<ogra_> if we would just be able to use launchpad searches like we always did it would be so much easier
<ogra_> spreadsheet vs spreadsheet vs html-list-in-an-old-email really doesnt help
 * ogra_ poders about the luxury to have an image for each landing now that we are down to a slow pace
<ogra_> i think i'll triger a build ;)
<ogra_> +g
<ogra_> done
<imgbot> === trainguards: RTM IMAGE 131 building (started: 20141027 10:50) ===
<brendand> ogra_, have the latest ci failures been triaged?
<ogra_> brendand, how would they without landing meeting?
<brendand> ogra_, true, but has nobody been looking at them at all?
<brendand> ogra_, my point being that i can if no-one else has
<ogra_> well, i dont think anyone has tried to find out why system-settings dont finish anymore since 127
<ogra_> no idea why rollin back apt would/could do that though
<ogra_> for UITK we should have a landing ... not sure about music app
<ogra_> i poked Saviq last week about the unity8 failures, not sure where they got with that, i know he had an idea
<ogra_> weather and the list of crashers could need a closer look i guess
<ogra_> and mvo__ should take a look at the failing click tests ... i poked him during the week but we havent talked much more about it yet
<brendand> ogra_, says dropping letters is not found
<ogra_> oh, thats in the click test ?
<ogra_> interesting
<brendand> ogra_, makes sense - because it's not there
<brendand> ogra_, is it supposed to be?
<ogra_> http://people.canonical.com/~ubuntu-archive/click_packages/click_list has it ... but i think that migh be overridden by the custom tarball on krillin rtm
<brendand> i heard something about removing it i'm sure
<ogra_> not sure about utopic, iirc there is should be still installed
<ogra_> hmm, i guess the test uses click_list as a base on both distros ... which is wrong
<oSoMoN> trainguards: hey, if anyone is alive and around, can I have a silo for line 74?
 * oSoMoN is faster than queuebot
<imgbot> === trainguards: RTM IMAGE 131 DONE (finished: 20141027 12:00) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/131.changes ===
<Mirv> oSoMoN: o/
 * ogra_ does his first wipe flash of his krillin since re-partitioning ... 
<ogra_> to much testing during the sprint ... my system is really messed up :(
<ogra_> i wonder how i would back up the call history
<davmor2> ogra_: you can't muhahahahahah
<davmor2> ogra_: I'm assuming it is a db somewhere
<ogra_> well, it must be stored somewhere
<davmor2> ogra_: there is no list, it's like spoons in the matrix ;)
<oSoMoN> ogra_, IÂ believe itâs ~/.local/share/history-service/history.sqlite
<ogra_> thanks !
<oSoMoN> boiko would be able to confirm
<ogra_> well, we will see in about 45min when the flashing is done and i have put the file back in place :)
<brendand> ogra_, it seems python3-autopilot doesn't depend on python3-evdev
<ogra_> brendand, causing what issue ?
<ogra_> (we should have seen that since mid last week)
<ogra_> (image 123)
<brendand> ogra_, well it might not cause an issue in ci if another package is pulling that in
<brendand> ogra_, but trying to run tests stand-alone it seems to be the case
<ogra_> well, i see there are a few more failures between 122 and 123
<ogra_> so it might actually affet some tests ... but only a few it seems
<ogra_> we should add the dependency if it really affects stuff though
<ogra_> i remember we moved that direct dep back and forth in the past ... and ended with seeding it instead of a dep ... i cant remembery why anymore though (but my brain is in degraded post-travel mode today) ... iirc xnox was involved in the decidion
<ogra_> cwayne, yo !
<cwayne> ogra_: hey man
<ogra_> cwayne, could you somehow work out a way to get the click_image_test smoketest fixed with mvo__ ? i guess he needs to modify it a little to not use the default click_list but to get the preinstalled list from you somehow
<ogra_> currently the test uses http://people.canonical.com/~ubuntu-archive/click_packages/click_list as master ... but that doesnt work when apps get removed via custom tarballs
<ogra_> (i.e. dropping_letters, filemanager or terminal)
<oSoMoN> woot, the CI train doesnât seem to know of vivid
<oSoMoN> Mirv, any idea whatâs going on there? ^^
<cwayne> ogra_: sure thing
<cwayne> davmor2: new custom tarball is ready for testing. the entire change log is updating about 80% of the scopes with translations
<cwayne> if helpful, i can get you teh exact clicks that have been updated for translation
<davmor2> cwayne: no that's okay
<Mirv> oSoMoN: sounds like we're not yet ready for vivid silos then :(
<Mirv> oSoMoN: we checked assigning a silo worked, apparently there's a problem with build
<Mirv> and I've built vivid packages, but without running the 'build' job since I'm uploading manual Qt packages
<Mirv> sil2100 will be back tomorrow
<oSoMoN> :(
<Mirv> there's no absolutely simple place where 'vivid' could be just added in the code, it might need some jenkins updating too
<Mirv> we may possibly not have vivid cowbuilder chroot:s yet. not that I'd know how to check that.
<Mirv> did what I could find https://code.launchpad.net/~timo-jyrinki/cupstream2distro/more_vivid/+merge/239721 , but would need review from ribru at least when he wakes up
<Mirv> I won't deploy it before it's reviewed by someone who knows what's ok to change and what's not
<brendand> ogra_, the messaging app tests seem to be making unity8 crash (or whatever you want to call it ;) )
<brendand> ogra_, i can't get through a whole run without being met by the u-s-c screen
<ogra_> Saviq, ^^^ seems we really need to exclude the dash from lifecycle mgmt (i saw it restarting plenty during traveling home too)
<brendand> ogra_, it's odd though. this is a fresh flash and i'm not doing anything with the dash. just running messaging AP tests
<ogra_> which might eat your ram
<brendand> ogra_, and actually there is a unity8 crash present
<ogra_> oh, then it might not even be the dash
<brendand> Mirv, should i be concerned about these failed copies? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-008/+packages
<dobey> Mirv: hrmm, looking at that branch, i think you need to add vivid stuff, as well as keeping the current utopic stuff
<dobey> Mirv: utopic isn't gone, and people may still need to land something there to get an SRU done, at least for the next 9 months
<Mirv> brendand: no. sounds like related to previous landing, and LP just keeps them eternally until they are dismissed.
<brendand> pete-woods, do you want https://launchpad.net/bugs/1380586 to land for RTM?
<ubot5> Ubuntu bug 1380586 in Unity Media Scanner Scope "Need to click-package local media scopes" [Undecided,In progress]
<pete-woods> brendand: I think that's what is wanted, yes
<brendand> pete-woods, i can't find it in any list though, can you check with olli
<olli> trainguards, brendand, ogra_, sil2000 et all
<pete-woods> brendand: I think I'd have to ask thostr, but he's not back til tomorrow
<olli> we have reviewed the wishlist with changes since 10/24
<olli> will send mail in a sec
<ogra_> olli, take your time, landing team works in degraded mode today anyway ...
<ogra_> (while our bodies arrived home our brains are mostly still traveling)
<dobey> s/landing team/\*/g
<ogra_> haha
<Mirv> dobey: re: branch, vivid was already added in one place, and that branch adds it into second place plus assumes dual landings will be vivid/rtm (if any). tests could probably have more than one series being tested. anyway, ribru can check the branch.
<dobey> lots of people had extended stays in DC or took today off
<davmor2> dobey: speak for yourself I'm on tippedy top form today honest gov'nor I'm not tired at all
<Mirv> olli: thanks
<davmor2> dobey: luckily I had these matchsticks to hold my eyes open :D
<dobey> davmor2: you're just high on all the extra sweeteners we put in stuff over here :P
<Mirv> I'm quite thankful for 2 nights at home bed instead of that awful hotel one
<Mirv> something around 2*12h of sleep
<davmor2> dobey: hahaha
<Mirv> that corn syrup coca-cola tasted so fake :D
<dobey> heh
<olli> ogra_, :)
<davmor2> Mirv: it did I had to buy one at the airport so I had change for the bus back in the uk, it tasted so much nicer
<brendand> ogra_, does messaging-app open sideways when the phone is flat on the table?
<ogra_> brendand, sometimes (and how would the phone be able to guess what the rotation state is in that state)
<davmor2> ogra_: I have apps open upside down too
<ogra_> davmor2, fix your table :P
<ogra_> get a water balance and make sure it is straight
<davmor2> ogra_: open gallery with the phone flat on the table
<ogra_> (and even then, what i said above still applies ... how is the phone supposed to guess rotation if it lies flat on the table)
<davmor2> ogra_: same for system settings the odd thing is though for system settings the loading screen it the right way up
<ogra_> happens on androidd all the time too
<ogra_> the splash is hardcoded
<ogra_> using the shell rotation (which doesnt ever rotate)
<davmor2> haha
<ogra_> if the shell would rotate too it would be consistent based on a guess the rotation sensor does in HW
<ogra_> i think the bug here is that the shell doesnt rotate ... causing that inconsitent behavior
<ogra_> there is no way to manipulate the sensor HW to make better guesses
<ogra_> android does the exact same thing, but there you see the shell being rotated so you dotn expect apps to come up in a different rotation
<asac> did the wifi battery fix land yet?
 * asac overslept after lunch because phone ran out of battery :P
 * asac sees a new si
<ogra_> asac, yes, landed on sat.
<ogra_> (and battery life got awesome long here for me )
<asac> ok lets see if that image brings cure
<ogra_> 126 had the fixes
<ogra_> 128 had the rollback for the apt desaster we had
<ogra_> (and 131 new location and trust-store fixes ... thats about all that landed since friday)
<ogra_> mdeslaur, jdstrand ^^^i assume you noticed by now that we rolled back apt ?
 * popey observed that the clocks changed correctly on his ubuntu phone and alarms went off at the right time today
<asac> ogra_: 131 krillin rtm?
<asac> good
<asac> i think got them all
<ogra_> asac, yup, latest one
 * asac happy dog again
<asac> lets see
<davmor2> asac: and more import did you get a notification for the new image?
<asac> davmor2: yes i got a green notification thingy message center
<mdeslaur> ogra_: yeah, saw that
<davmor2> asac: \o/ Chipaca your fix worked on more than my phone :D
<mdeslaur> ogra_: my mind is still blown that the apt package has anything to do with installing clicks :P
<ogra_> mdeslaur, it broke with the packagekit version we have in rtm ... i would propose you prepare another apt landing that also includes packagekit
<mdeslaur> ogra_: sure, I'll get around to it eventually
<ogra_> mdeslaur, yes, packagekit is liked against libapt-pgk or some such
<mdeslaur> ogra_: I'll probably just backport the security fix
<asac> hehe
<asac> nice
<asac> so 131 seems to crash unity shell
<asac> when i hit messaging app icon
<asac> i think the indicator was empty before
 * asac thinks its all still indicators crashing
<davmor2> asac: seems very crashy currently no idea why though
<ogra_> asac, it doesnt crash :P
<ogra_> asac, it is "lifecycle managed"
<asac> davmor2: ack. if you can identify a test case, bisecting might help
<asac> ogra_: that i dont believe until i get a proof
<asac> i didnt have a single app open
<ogra_> something hogs your ram
<asac> it was a fresh boot
<asac> just settings
<asac> nothing else
<asac> indicators got empty, then i started app and unity restarte
<ogra_> something hogs your ram and that makes lifecycle mgmt kick in ... since there is nothing else to kill it kills the dash
<ogra_> (which IMHO should not be managed at all, but i lost that argument :P )
<asac> ogra_: so even if liefcycle has this effoect, i am sure we shouldnt rule out any other cause
<ogra_> asac, oh, unity restarting is indeed something else
<davmor2> ogra_: no it is things lock unlock pin on sim and the phone is locked that is even before unity8, phone call went yesterday and crash unity8/mir ie ubuntu icon spinning
<ogra_> i understood your dash restarted
<davmor2> s/lock/like
<ogra_> davmor2, thats unity8 itself then ... or u-s-c or lightdm
<ogra_> can be any of the three if you see the spinner
<ogra_> check /var/crash
<davmor2> ogra_: this is what is say the whole system seems less stable as a whole
<ogra_> davmor2, yeah, i had that with my OTAed image at the airport if you remember
<davmor2> ogra_: it's been wiped 6 times since then ;)  OTA testing today
<ogra_> i was assuming it was because i had so many test packages installed manually though ...
<ogra_> and i must say after a fresh bootstrap today it all seems far more stable to me
<ogra_> (havent seen anything cashing in the last 4h)
<ogra_> *crashing too :P
<ogra_> davmor2, wiped or bootstrapped ?
<davmor2> ogra_: yeah with the latest it seems more stable but I'm going to do some heavy testing on it after the ota and custom tarball testing is finished
<davmor2> ogra_: wiped
<ogra_> wow, the filemanager is pretty useless trying to see anything in /var/crash
 * ogra_ sees a bunch of "_usr...rash" 
<ogra_> there seems to be no kinf of list view
<davmor2> ogra_: rotate your phone
<ogra_> doesnt rotate
<ogra_> (the app that is ... others do fine)
<ogra_> oh, blind me
 * ogra_ found list view now 
<ogra_> seems i got mediascanner crashes since the new flashing
<davmor2> ogra_: I blame you trying to use an app to do something it was designed for
<ogra_> :P
<ogra_> hah
<ogra_> clicking a file in that dir gets me a filemanager crash
 * ogra_ goes to the terminal ...
<ogra_> hmm, so i have mediscanner, filemanager, u-a-l and scoperunner crashes ...
<ogra_> from the last 4h
<ogra_> u-a-l is still the fitbit thing crashing it
<ogra_> cwayne, ^^ do we have a fix for that already somewhere ?
<cwayne> ogra_: what fitbit crash?
<ogra_> cwayne, http://dev-jenkins.ubuntu-ci:8080/job/utopic-touch_stable-krillin-smoke-daily/398/artifact/clientlogs/security/_usr_lib_arm-linux-gnueabihf_ubuntu-app-launch_desktop-hook.32011.crash/*view*/
<ogra_> has an example
<ogra_> "icon-path-unhandled"
<ogra_> krillin only indeed
<cwayne> uhm, ill take a look
<cwayne> not sure that should really count as a crash and trigger apport though...
<ogra_> its a recoverable error
<ogra_> but produces a crash file indeed
<cwayne> ill take a look, i believe that desktop file is automagically created by the scopes api, but will double check
<ogra_> whom do i poke about the dashboard ?
<cwayne> me :)
<ogra_> it seems to never use the proper location data (looks actually like geoip, it is about 150km off at the next node of my provider)
<davmor2> ogra_: if it isn't on mako it's cwaynes fault
<cwayne> ogra_: it uses whatever unity-scopes-api gives us, and iirc the only think it uses location data for is sunrise/sunset
<ogra_> the rest of the system seems to use location just fine ... on the spot on my house
<ogra_> cwayne, well, and weather
<cwayne> ah right
<cwayne> so weather isn't one of ours, it's a remote scope
<ogra_> tapping weeather gives me the 150km away location from geoip
<cwayne> so I'm not sure how accurate it's location data is
<cwayne> so that's not me actually, that's lucio :)
<davmor2> cwayne: no it's you, you can blame lucio after but everything is your fault :P
<cwayne> ha
<davmor2> cwayne: if the scope is passing the geoip rather than the actual location then that won't help
<dbarth> hey guys, are vivid landings possible this week?
<dbarth> for all those silos that are not meant for rtm
<cwayne> davmor2: dashbord isn't doing anything, weather only does geoip AIUI
<cwayne> it's not allowed your lat/lng since its remote
<ogra_> bad weather then
<davmor2> cwayne: it's still your fault though don't think you are getting off that light ;)
<cwayne> yeah, perhaps that's one that should be re-written to be local
<cwayne> i'll poke some people
<davmor2> cwayne: hahahaha :)
<cwayne> davmor2: u wot m8
<davmor2> cwayne: see that sounds less Cockney than when you say it :P
<cwayne> lol
<ribru> Mirv: hey, just up. will check branch asap
<brendand> dbarth, what do you want to do with silo 009 for RTM?
<ribru> Mirv: https://ci-train.ubuntu.com/job/upgrade-chroot/106/console looks good so far! I don't think I was involved in the opening of utopic so I had no idea how this would go but congrats ;-)
<ribru> Mirv: it says SUCCESS but we should look into that libeatmydata thing...
<ribru> oSoMoN: Mirv: ok looks like it's working (well, at least that one traceback is fixed, we'll see if anything else pops up) https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/85/console
<dbarth> brendand: hi; i'd like to re-target that for a non-rtm landing
<oSoMoN> ribru, cool, thanks
<dbarth> ribru: ribru?! the new robru
<brendand> dbarth, ok
<dbarth> brendand: is vivid opening soon?
<ribru> dbarth: ;-)
<ribru> oSoMoN: you're welcome!
<ribru> infinity: cjwatson: any thoughts on this libeatmydata spew? https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/85/console can it harm builds? can we fix it?
<brendand> dbarth, last i heard it's not ready for landings yet
<dbarth> brendand: ok; i'll continue asking tomorrow then ;)
<dbarth> brendand: otherwise, i will re-add silo 20 back on the whishlist to get this one going
<ribru> dbarth: we're doing the very first vivid landing right now, do you want to be number 2?
<ribru> also, is it european dst right now or something? why did all my meetings jump forward an hour?
<dbarth> ribru: oh, nice; i would gladly be
<ribru> dbarth: k, which spreadsheet row?
<dbarth> ribru: we flipped DST this week-end, yes
<ribru> thanks
<dbarth> lemme check
<dbarth> ribru: line 19 and 20; so remove the line 19 landing request, and reconfig 20 for vivid please
<ribru> dbarth: ok sure
<ribru> dbarth: oh, so you don't want to land this in rtm then?
<dbarth> ribru: nope, not now; the bugs are not critical enough
<dbarth> ribru: can i also turn silo 020 to vivid maybe?
<dbarth> ie, is the landing policy back to: devel 1st and stable next?
<ribru> dbarth: yes vivid is wide open for all feature development
<dbarth> cool!
<ribru> Mirv: do you plan to free utopic/15?
<ribru> dbarth: ok for starters you have silo vivid/8 http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-008 still looking at the other one
<ribru> dbarth: hm, are you sure silo rtm-20 isn't a critical fix needed for rtm? "password prompt broken" sounds pretty serious.
<dbarth> ribru: it's still a question mark; the severity is limited to cases where users /change/ their passwords
<dbarth> ribru: but yeah, a potential rtm fix
<ribru> dbarth: ok well I won't free that silo then, but we can make a sync silo to also sync it to vivid
<ribru> dbarth: https://ci-train.ubuntu.com/job/ubuntu-landing-009-1-build/87/console ok building for vivid
<ribru> uh
<ribru> well shit
<davmor2> ribru: say what now?
<ribru> davmor2:  ^^ check the uncaught exception. it says the file doesn't exist, but the build log clearly shows that file existing. i'm stumped.
<ribru> dbarth: I guess hold off on doing that passowrd one in vivid for today
<ribru> dbarth: but webbrowser app should be ready to test soon
<ribru> davmor2: https://ci-train.ubuntu.com/job/ubuntu-landing-009-1-build/87/consoleFull
<dbarth> ribru: np; i'll let you check the file issue
<dbarth> ribru: for ref. i think i had seen that one before during an rtm build attempt
<ribru> dbarth: yeah there was an issue where the code just called '*.dsc' and it would break if there were two dsc files, but we fixed that some time back, so I have no idea what this issue is
<davmor2> ribru: that's a lot of errors for something that is meant to of built
<ribru> davmor2: ignore the libeatmydata stuff. i have no idea what that is, and stuff seems to be working in spite of that (it's coming up in all vivid logs). just check the traceback at the very end
<davmor2> ribru: is citrain supporting vivid?  I thought Mirv said it wasn't this morning
<ribru> davmor2: yeah mirv had a branch taht fixed it and I landed it so it's "working" now
<davmor2> ribru: I blame Mirv then ;)
<ribru> davmor2: dunno, the file pretty clearly exists: https://ci-train.ubuntu.com/job/cyphermox-test/309/console
<ribru> dbarth: oh, i just noticed the package was actually uploaded, so WATCH_ONLY build seems to be working anyway: https://ci-train.ubuntu.com/job/ubuntu-landing-009-1-build/88/console
<brendand> ogra_, what is going on that so many things are crashing unity8?
<brendand> ogra_, what could we have landed?
<davmor2> brendand: only seems to of been from Saturday I wonder if it is the low power wifi stuff
<davmor2> brendand: and possibly dbus-cpp by the sound of it ;)
<ogra_> brendand, nothing really
<dobey> ribru: so given the vivid issue above, is it possible to sync something from rtm to vivid?
<ribru> dobey: yes it seems to be possible, there is a strange traceback but it doesn't happen until after the PPA upload completes, so the packages should be building in the ppa without issue.
<dobey> ribru: ok cool. can we get a silo for line 45 in the spreadsheet then?
<mandel> cihelp, how can I find the -dbgsyms for a silo?
<ogra_> davmor2, the wifi changes cant crash unity8 (well, not directly at least)
<ribru> dobey: ok, vivid 14
<davmor2> ogra_: if they take out dbus I bet they could ;)
<ogra_> brendand, davmor2, we dropped the hud ... but there were no dependencies declared on it by unity ....
<ribru> mandel: IIRC those don't exist.
<mandel> ribru, oh.. what a pita
<ribru> mandel:  yep ;-)
<ogra_> they doi exist for the rtm archive though
<ogra_> so you should be able to use them after landing
<ribru> mandel: there was a big discussion about that some weeks ago. IIRC the dbgsym packages are created at publish time, not at silo build time
<ogra_> (now dont ask me where ... thats a pitti question)
<davmor2> mandel: have a look at the silo ppa some include .debug in which case you can just grab the package and install it right?
<ribru> dbarth: approve merges please -) https://ci-train.ubuntu.com/job/ubuntu-landing-008-2-publish/43/console
<mandel> ribru, is a little annoying to have them at publish time when a silo under tests crashes
<mandel> davmor2, I have a work around and created the debug for myself, I was asking to see if that was an ugly work around
<ribru> mandel: yeah I totally hear you, sorry I can't remember more details, slangasek or infinity would know more, but it has something to do with launchpad, it's not something we can control from the ci train side.
<davmor2> mandel: there is no such thing as an ugly work around if it works ;)
<mandel> ribru, ack, is just unfortunate :)
<mandel> davmor2, well... as it is right now is not reusable :P
<dobey> ribru, mandel: i thought it just needs to have ddebs enabled on the PPAs?
 * mandel mandel|lunch
<dobey> ribru: yeah, we just need to get an admin to enable ddebs for all the landing PPAs
<dobey> are there vivid builds on the system-image server yet? or should i just test the silo on utopic on my mako?
<infinity> ribru: The ddeb availability issue isn't LP's fault, but rather that we're not using LP for them (yet) because we can't.  That's going to be solved VEry Soon, it looks like.
<infinity> ribru: As for the eatmydata thing, that's entirely out of my hands as a distro guy, it looks like your infra tries to LD_PRELOAD it, but your chroots don't have it installed.
<infinity> ribru: Harmless, but noisy (and not getting you the speed boost you're hoping for).
<ribru> infinity: Hmmmmmmm thanks for the tip
<ribru> Not sure why it wouldn't be installed
<ribru> (I didn't make the chroots)
<ribru> Will poke at it in a bit. Brb, lunch
<davmor2> ogra_, ribru, cwayne: custom tarball is good :)
<ogra_> land it then :)
<mandel|lunch> cihelp, I'd like to block the landing of silo 13 for rtm, eventhough the branches have been approved I'm able to reproduce the bug that it in theory fixes
<mandel> cihelp, should I just change the value in the spreadsheet?
<dobey> mandel: if it fails tests, change the "testing pass?" column to "no" for that line in the spreadsheet
<mandel> dobey, just that? is there a way to comment or should I just add a comment in the bug?
<dobey> mandel: there's a comments column too. add comments there :)
<mandel> dobey, ugh, the formatting is going to suck :-/
<mandel> dobey, is a cpp bt from gdb
<mandel> in a spreadsheet
<dobey> well, put that in the bug then
<dobey> and in the spreadsheet comments field put "testing failed, see bug #xxxxxxx" or something
<dobey> obviously don't put stack traces in spreadsheet fields :P
<ribru> mandel: yeah what dobey said.
<ribru> mandel: also for silo / spreadsheet questions you should ping trainguards, not cihelp.
<ogra_> you could paste the bt into the MP column .... just to test ribru's code ;)
<dobey> watch it explode
<ogra_> if the dashboard shows burning flames you broke it :)
<dobey> (because that spreadsheet is already incredibly slow already, a 30K line stack trace probably is not going to be fun)
<ogra_> might be fun to have queuebot patse it into IRC though ... one line per char
<dobey> heh
<ribru> ogra_: queuebot already has message-length restrictions. watch the migration messages from silos containing more than a handful of packages and you'll see it's often clipped.
<ogra_> bah, spoiling all the fun ... these bot devs
 * dobey puts +++ath in the spreadsheet
<dobey> ogra_: any idea when vivid images will be available to flash?
<cwayne> ogra_: sorry, had been at dr's, so i'm good to publish custom?
<davmor2> cwayne: likely story ;)
<cwayne> davmor2: ha, so should I press the magic button, or do i need to wait for ribru or someone on ye olde landing team
<davmor2> cwayne: yes it's good as far as I can tell
<cwayne> ok, hitting the magic button then
<cwayne> aaand built
<cwayne> WOO TRANSLATED SCOPES NOW IN IMAGE WOO
<ribru> cwayne: er, what button did you hit?
<cwayne> ribru: running a jenkins job to move the custom tarball past the qa gate
<ribru> cwayne: uh, what jenkins is that? that's not part of the train as far as I knwo
<cwayne> it's not part of the train, it's usually just getting a +1 from QA
<cwayne> it's on s-jenkins
<ribru> cwayne: ah ok, nm then. you said 'pressing the button' then queuebot didn't say anything so I thought maybe whatever you pressed didn't work. but if it's not part of the train then no worries
<davmor2> ribru: were you hungry when you got up?
<ribru> davmor2: yes, just like every day...
<davmor2> ribru: that explains your nick then, I think we know what you might have a craving for ;)
<ribru> davmor2: haven't read the channel topic in a couple weeks i guess?
<davmor2> ribru: yeah just seemed funnier than the actual truth of the matter :)
<ribru> davmor2: I'm craving my ribs to reconnect to themselves in a healthy way so i can get out of bed... ;-)
<davmor2> I think you are safer where you are if you go around breaking ribs for the fun of it ;)
<mandel> davmor2, can you help me understand how can I request a silo for line 55 in rtm and vivid?
<mandel> davmor2, it looks like it was request for utopic but we should land in vivid and do an SRU, correct?
<ribru> mandel: yes, vivid-first landings I think are best. I heard a rumour that we don't need the full rigamarole of an SRU though, there's going to be a sort of SRU-lite where we just land things in a special blessed PPA for utopic-based phone images going forward.
<mandel> ribru, so I updated the spreadsheet, is there anything else we need to do
<mandel> ??
<mandel> that we == I
<ribru> mandel: which row?
<mandel> ribru, 55
<ribru> mandel: looks good, I'll assign it
<ribru> fginther: around?
<mandel> ribru, superb, thx, do I have to request one for rtm too?
<ribru> mandel: yeah rtm will require a second spreadsheet row with a second silo. is your landing one of the approved critical rtm fixes?
<mandel> ribru, that is a very good question, I'll have to check that and ping people to get it there is not present
<ribru> mandel: ok ping olli or asac about that I guess. once they approve it we can go for qa and get it into rtm
<mandel> ribru, ack
<olli> mandel, which one?
<mandel> olli, bug 1341685
<ubot5> bug 1341685 in ubuntu-download-manager (Ubuntu RTM) "When unconstrained, udm sometimes downloads files to wrong location" [Critical,In progress] https://launchpad.net/bugs/1341685
<mandel> olli, is a fix that affects system image at the unit/integration tests level which is making barry s life horrible when trying to land system image
<barry> mandel, olli note that that could also be considered a security bug.  it's asking on the wrong bus for whether the connection is constrained or unconstrained, though it's probably making the wrong answer in the safer direction.
<olli> mandel, I added it to the wishlist and we'll check in tomorrow
<olli> barry, that's one way to look at it ;)
<mandel> olli, ok, it is quite critical from our point of view a barry mentioned
<mandel> olli, lets say we really really strongly wish for it ;)
<barry> cool.  olli let me know too about the phased update bug for si.  that's been communicated to me as critical for rtm too ;).  (i'm getting ready to put it in a silo for testing)
<mandel> barry, we have a silo for vivid, would be nice if we test it there already
<mandel> barry, at least we can have it there asap
<barry> mandel: i'm not going to land my branch in vivid, though i will merge it into my si 3.0 branch for vivid.  rtm will only have si 2.5.1 and i don't plan to sru it into utopic (mostly because nobody cares)
<barry> so si 2.5.1 is rtm only
<mandel> barry, ok, well, I'll be aming for vivid and later in rtm (I'll be creating a utopic branch in the project to be able to sru stuff)
<barry> mandel: cool
<olli> barry, id on the phased one?
<olli> I thought that was already +1'd
<olli> but... I see way too many bugs atm
<barry> olli: it's on "the" spreadsheet, but it's also LP: 1383539
<ubot5> Launchpad bug 1383539 in Ubuntu system image "phased update support does not give idempotent answer for each (machine,update)" [Critical,In progress] https://launchpad.net/bugs/1383539
<ribru> infinity: https://ci-train.ubuntu.com/job/upgrade-chroot/113/console eatmydata is definitely installed in the chroot, reinstalling it doesn't seem to help. any ideas on how to fix that? I'm totally unfamiliar with eatmydata, i guess it's just configured wrongly.
<ribru> or broken in vivid
<barry> ribru: are you seeing eatmydata problems on a vivid chroot?
<olli> barry, comment #4
<olli> is there anything else you think is holding you back>
<olli> ?
<barry> ribru: comment #4 on which bug?
<olli> https://launchpad.net/bugs/1383539
<ubot5> Ubuntu bug 1383539 in Ubuntu system image "phased update support does not give idempotent answer for each (machine,update)" [Critical,In progress]
<barry> olli: oops, yes, thanks
<olli> :)
<olli> np, sorry, this is a mess, I understand
<barry> olli != ribru :)
<olli> no insult taken
<barry> olli: i hope your ribs are in better shape ;)
<ribru> barry: oh yes, i just set up the vivid chroots today and while they seem to be "working", there's eatmydata spew everywhere.
<ribru> barry: just for starters: https://ci-train.ubuntu.com/job/upgrade-chroot/113/console but the build jobs are even worse
<barry> ribru: i saw that too when i set up my vivids yesterday.  haven't spent any time investigating
<ribru> barry: I've been poking at it. infinity suggested it was because eatmydata was missing but I confirmed it's not missing. not sure what else to even check. not my specialty
<barry> ribru: yeah, i did a naive apt-get reinstall of eatmydata in my vivid chroot and that didn't help.
<ribru> barry: heh same. https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/85/console fun
<barry> gorp
<ribru> barry: ok well if it's bit you too then I'll just chalk it up to "vivid is broken" and move on to the next thing in my to-do list. lemme know if you make any progress on that one, thanks ;-)
<barry> ribru: same back atcha :)
<ribru> barry: I have no idea what eatmydata even does. I'd just as well disable it as fix it.
<barry> ribru: it speeds things up by disabling fsync and friends.  of course, that means you can lose data, but who cares in a chroot?
<ribru> ah
<ribru> barry: so it's not something anybody would ever use outside of a chroot?
<slangasek> ribru, mandel: the process for landing on RTM hasn't changed, anything to be landed there still has to have a full landing - and since vivid and 14.09 will now have toolchain skew, these need to be separate sources / separate builds
<barry> ribru: not if they didn't want their data eaten.  it's aptly named :)
<ribru> slangasek: https://code.launchpad.net/~robru/cupstream2distro/force-rtm-versions/+merge/239775 ok here's the branch that forces ~rtm version tagging unconditionally, and defaults to source syncs. We'll let sil review it tomorrow
<slangasek> ribru: sounds good
<ribru> AlbertA: around? I'm just investigating what happened in your silo 17 ^^
<AlbertA> ribru: tvoss will take a look, I think what happened is an update was made to vivid but the branch was not merged to the project trunk
<ribru> AlbertA: so it looks like location-service is also in silo 6, which claims to be in a state 'you can publish' but somehow is already in distro now. not sure how that came to be. anyway it looks like if we merge & clean that one then your build will be fine
<ribru> AlbertA: yeah that sounds about right
<ribru> AlbertA: want me to merge the other silo or should I coordinate with tvoss first?
<AlbertA> ribru: go ahead and merge
<ribru> AlbertA: sweet
<AlbertA> ribru: thanks!
<ribru> AlbertA: you're welcome
<ribru> awesome
<ribru> AlbertA: https://ci-train.ubuntu.com/job/ubuntu-landing-017-1-build/76/console ok looks like it's building now
<AlbertA> ribru: awesome thanks!
<ribru> AlbertA: you're welcome!
<tvoss> robru, mind undoing the merging? I think the branches got messed up
<tvoss> ribru, I thought the rtm referred to line 36 of the spreadsheet?
<ribru> tvoss: not sure what you mean. 36 was definitely set for utopic.
<ribru> tvoss: not sure what happened to that landing though. silo claimed it was ready to publish, but the package was in utopic. not sure how it got there without publishing. i guess somebody manually uploaded that
<ribru> tvoss: I can revert the trunk commit I did, do you want the package also reverted in utopic? that's a bit harder
<ribru> but possible
<ribru> err, maybe not so possible in utopic, but we can rever it for vivid I mean ;-)
<ribru> AlbertA: tvoss: https://launchpadlibrarian.net/188458283/buildlog_ubuntu-vivid-amd64.location-service_2.1%2B15.04.20141027.1-0ubuntu1_FAILEDTOBUILD.txt.gz also this is a weird build failure. missing dependencies somehow?
<tvoss> ribru, nope, one of the tests times out
<tvoss> ribru, okay, I will try to untangle it tomorrow
<tvoss> ribru, what about rtm silo 6?
<tvoss> ribru, sorry, hang on
<ribru> tvoss: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=landing-006 rtm 6 is unrelated ;-)
<ribru> tvoss: utopic 6 was somehow in utopic but not merged to trunk, which is why I pushed to trunk, to try and sync those up
<ribru> tvoss: so utopic 6 silo is free now
<tvoss> ribru, okay, looking here, the wrong mp got merged: https://launchpad.net/ubuntu-rtm/+source/location-service
<tvoss> or better: released
<tvoss> ribru, seems like an autosync happened
<tvoss> ribru, can we revert that release in rtm at least?
<ribru> tvoss: looks like the rtm release matches the utopic release
<tvoss> ribru, sure, but that's still not correct :)
<ribru> tvoss: there was a translation update if that's what you mean. those auto-sync into trunk and then get included with whatever other releases happen
<ribru> tvoss: we can revert it, I'm just not sure how it got into utopic/rtm in the first place.
<ribru> tvoss: like it would have had to have gone past qa to get into rtm. if we revert it that presumably also needs to get past qa
<tvoss> ribru, yup, same here. But I would like to avoid having such an artifact in rtm
<tvoss> ribru, okay, I can lookinto it further tomorrow my afternoon, not before
<ribru> tvoss: ok sorry, do you want me to prep a revert now? or wait?
<tvoss> ribru, if you feel comfortable reverting, do so. If not, I can see to it tomorrow
<ribru> tvoss: ok, I'll leave it then, as I'm not very familiar with the revert tooling. I'll write an email to sil and ogra since I think they know more about that
<tvoss> ribru, thanks
<ribru> tvoss: you're welcome
#ubuntu-ci-eng 2014-10-28
<ribru> bfiller: messaging-app conflicts with rtm26
<bfiller> ribru: rtm26 safe to ignore for now as that won't land in 10/30 image
<ribru> bfiller: ok cool
<ribru> bfiller: you got rtm 4
<bfiller> ribru: thanks
<ribru> bfiller: you're welcome
<ribru> bfiller: rtm 9 ;-)
<bfiller> ribru: awesome
<infinity> ribru: Curious.  So, I have literally zero insight into how it's being used in the CI infrastructure.
<infinity> ribru: I can tell you that it's harmless for it to fail to load, but no idea without access to all the moving parts to tell you how it's broken or how to fix it.
<ribru> infinity: well I can't speak for all of CI, but within ci train / lp:cupstream2distro, this is the only file that references it: http://bazaar.launchpad.net/+branch/cupstream2distro/view/head:/chroot-tools/.pbuilderrc
<ribru> infinity: barry mentioned he was also bit by this eatmydata issue, so it seems like eatmydata is just broken for all of vivid as far as I can tell. that config works fine as-is for trusty and utopic. and I confirmed the package is installed and file present in vivid. so there's something else going on causing it to fail to load
<infinity> ribru: Well, there has been a pretty massive version bump (26 to 82) between utopic and vivid, so it's possible calling conventions changed or something.
<ribru> hrm
<infinity> http://bazaar.launchpad.net/+branch/cupstream2distro/view/head:/chroot-tools/.pbuilderrc
<infinity> Or that.
<infinity> Err.
<infinity>     + debian/rules: move shared library to /usr/lib/<triplet>/libeatmydata.
<infinity> That.
<ribru> hrm
<ribru> infinity: https://wiki.ubuntu.com/PbuilderHowto#eatmydata not sure why I didn't think to google this earlier ;-)
<ribru> barry:  ^^ ;-)
<infinity> So you probably want something like export LD_PRELOAD="${LD_PRELOAD:+$LD_PRELOAD:}/usr/lib/$(dpkg-architecture -a$ARCH -qDEB_HOST_MULTIARCH)/libeatmydata/libeatmydata.so"
<infinity> But only for vivid+
<ribru> infinity: -a$ARCH?
<infinity> Also, oh god, why do we still have pbuilder in our infrastructure, it burns, make it stop.
<infinity> ribru: It seems that script has $ARCH as the target dpkg arch.
<ribru> infinity: lol. too many other fires to put out before that one. but all of ci train / jenkins /etc is going away Real Soon Now, so let's cross our fingers that the new uci-engine isn't using it
<ribru> ah
<ribru> infinity: what's the easiest way to conditionalize "if vivid: foo; else: bar" in this case
<ribru> or query the version of eatmydata installed..
<infinity> ribru: You have $DIST, you can test.  Simlper to test for older dists, though with all this having a short life (in theory), it makes little difference.
<ribru> infinity: slippery slope though, don't want to be sloppy just in case it sticks around too much longer ;-)
<infinity> ribru: But I'd use a case.
<ribru> infinity: is pbuilderrc just a shell script? it seems to be calling mkdir but other than that I'm not sure if it has full shell support to do whatever
<infinity> ribru: Looks like shell to me.
<infinity> ribru: case $DIST in\n  precise|trusty|utopic) do_old_way;;\n  *) do_new_way;;\nesac
<ribru> infinity: there's no easy way to do version number matching with apt-cache or something right?
<infinity> ribru: You're not in the chroot at that point, so no.
<ribru> crap
<ribru> no wait
<infinity> ribru: And, if the chroots are tarballs (which it looks like), you can't even look in them yet.
<ribru> infinity: but it just calls lsb_release to populate $DIST, that must mean it's inside the chroot, doesn't it?
<ribru> otherwise $DIST would just be the $DIST of the host system
<infinity> ribru: No, it's not actually using that.
<infinity> ribru: Those lines populate the variables to the host system's setup if you don't feed it better defaults, which you obviously do.
<ribru> hmmmm
<ribru> ok
<ribru> infinity: can I trouble you for a quick review? https://code.launchpad.net/~robru/cupstream2distro/fix-eatmydata/+merge/239782
<ribru> bfiller: rtm 12 ;-)
<bfiller> ribru: nice
<ribru> infinity: https://ci-train.ubuntu.com/job/upgrade-chroot/114/console well I pushed that branch into production and it seems to be not working. Hrm
<ribru> no qa?
<ribru> that's better
<infinity> ribru: Got it all sorted out?
<ribru> infinity: sure didn't!
<ribru> infinity: tried it your way and the wiki way (which suggests relative instead of absolute path), both are still spewing like crazy in vivid
<infinity> ribru: So just make the vivid path not use the LD_PRELOAD at all, and we can revisit it later if speed is a huge issue.
<ribru> infinity: seems reasonable.
<infinity> ribru: Certainly not something I want to debug blind at 8pm on a day off. ;)
<ribru> infinity: just gonna play with a bit in a local chroot since tinkering with jenkins remotely is fiddly.
<ribru> infinity: haha, didn't realize it's a day off for you. regular day for me. Ok I'll try a couple things and if it fails I'll just disable it. thanks for the input
<imgbot> === trainguards: RTM IMAGE 133 building (started: 20141028 03:05) ===
<imgbot> === trainguards: RTM IMAGE 133 DONE (finished: 20141028 04:20) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/133.changes ===
<Mirv> ribru: thanks!
<Mirv> ribru: I'll free up 15 soonish, but I'll make a copy of it for utopic desktop users somewhere as some like using it
<Mirv> ribru: the eatmydata seems familiar and is harmless. we should just get it properly installed so that it could do its job (speed up i/o)
<ribru> Mirv: you're welcome. My latest branch disables eatmydata for vivid until a solution can be found. If you have any insight, branches welcome ;-)
<ribru> Mirv: the pbuilder howto wiki mentions a change to eatmydata in vivid and suggests and alternate configuration but i wasn't able to get it working. Preprod is useless here but feel free to tinker with it in production. lp:cupstream2distro /chroot-tools/.pbuilderrc
<ribru> Mirv: check the commits on my latest merge to see what didn't work....
<Mirv> ribru: thanks, I'll check them. I'm sure eatmydata was not a crucial part of our performance anyway, it's more of a desperate measure in case of slow hard drives etc
<ribru> Mirv: i don't have any hard metrics on the performance with out without it. Maybe we should put some timers on the build job and try building the same packages in utopic and vivid ;-)
<ribru> Mirv: you know, a million times, and average the results, like python's mtimeit ;-)
<Mirv> it could help a bit in the packages unpacking part which is quite i/o bound
 * Mirv converts utopic silos to vivid
 * ogra_ tries to decypher ribru's mail ... 
<sil2100> hmmm
<ogra_> i guess we want tvoss around before touching anything
<Mirv> hmmmm
<ogra_> though looking at https://launchpadlibrarian.net/188458283/buildlog_ubuntu-vivid-amd64.location-service_2.1%2B15.04.20141027.1-0ubuntu1_FAILEDTOBUILD.txt.gz this is a clear test failure, not sure how it wouold related to mis-merging
<ogra_> *would relate
<Mirv> sil2100: so, after robru accepted my yesterday's cu2d branch and did some additional fixes, I've changed most utopic silos to be now vivid
<Mirv> also, first vivid publish done
<ogra_> sigh
<ogra_> apport right after OTA to 133 ... my UI hangs
<ogra_> and kills the session
 * ogra_ sees a fresh unity8 crash file 
<sil2100> ogra_: yeah, anyway I would indeed wait for tvoss, not sure if he'll be around today though
<sil2100> Mirv: \o/
<dbarth> good morning, is vivid available for mako currently?
<dbarth> --channel=ubuntu-touch/vivid gives me an error like
<dbarth> Failed to locate latest image information
<ogra_> dbarth, that would mean we have promoted something :)
<ogra_> you would want vivid-proposed ... (but you should simply not use versioned channels, so devel-proposed) ...
<sil2100> Would be nice to find some cycles to promote a devel channel image anyway, at least sometimes in the nearest future
<ogra_> there were no successful image builds yet
<dbarth> ogra_: ok, makes sense; i should have known better... ;)
<dbarth> hmm, but vivid-proposed says the same
<sil2100> Not sure if we build vivid images yet
<sil2100> ogra_: right?
<dbarth> ah
<ogra_> sil2100, i saw one failed attempt
<dbarth> so i can still stack my brand new vivid silo on top of my utopic image?
<ogra_> havent checked deeper yet, i was waiting til desktop images build
<pstolowski> trainguards, Mirv I've fixed the URL in line #57
<Mirv> dbarth: essentially yes, but you need to add the silo url manually since apt-add-repository would add it as "utopic" to sources.list
<dbarth> ah ok np
<dbarth> we're really on the edge with vivid today ;)
<popey> \o/ browser locked up
<sil2100> psivaa_: hey!
<pstolowski> trainguards hey, can i get a silo for line #57?
<Mirv> pstolowski: sure, we just have a meeting ongoing
<popey> davmor2: quick, make a webapp from that!
<sil2100> Wompwompwomp
<davmor2> popey: not a bad idea I'll look into it after
<Mirv> with not one but two Qt silos it looks like I'm breaking up the usability of http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q= a bit :( so much scroll, no fun.
<Mirv> I'll free up the utopic once I've vivid up to speed and have made backup of the utopic to somewhere
<sil2100> Much scroll? Very big
<sil2100> Wow wow
<sil2100> ;)
<Mirv> exactly!
<ogra_> W: Failure trying to run: chroot /build/chroot mount -t proc proc /proc
<ogra_> W: See /build/chroot/debootstrap/debootstrap.log for details
<ogra_> P: Begin unmounting filesystems...
<ogra_> sil2100, ^^^^ thats the armhf image build failure
<ogra_> fails very early on ... when greating the first chroot
<ogra_> *creating
<sil2100> hm, doesn't make much sense, why is that failing?
<sil2100> We need someone from the elders to check that out
<ogra_> thats just fallout, most likely some packages couldnt be unpacked, sadly you cant see that bit
<sil2100> (a reference to the presentation from Alexander last week)
<ogra_> debootstrap isnt very verbose
<ogra_> yeah
<ogra_> i pinged adam about it
<ogra_> i'll try a deboostrap myself here
<sil2100> debootstrap for vivid worked fine on i386 (or amd64?) on the citrain jenkins though
<ogra_> yeah, it does
<ogra_> it does also for thex86 images
<ogra_> (for touch)
<ogra_> ubuntu-core fails the same way
<ogra_> https://launchpadlibrarian.net/188476083/buildlog_ubuntu_vivid_armhf_ubuntu-core_FAILEDTOBUILD.txt.gz
<ogra_> for all arm builds https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core/
<ogra_> so i guess infinity is aware already
<sil2100> btw. I really hate car mechanics, gave them my car before flying off to Washington and they had a week to finish some maintenance
<sil2100> They were even saying it might be done earlier
 * ogra_ did the same with his coffee machie 
<ogra_> got it back yesterday :)
<sil2100> But it seems that they will only be done on Thu, so I'm stuck without a car for 2 more days :o
<sil2100> heh ;)
<ogra_> well, at least you will be able to get to work ...
<brendand> sil2100, coffee is way more important than driving though
<ogra_> ++
 * brendand will try rolling back the image to see if messaging_app AP tests stop crashing
<sil2100> ogra_: btw. poked on #ubuntu-unity regarding hud, but best indeed if we wait for Saviq to be back
<ogra_> right, or mzanetti
<brendand> ogra_, what image had the hud removal?
<sil2100> cihelp: hey! We would need someone from CI to help us out with smoketesting dashboard results - is anyone available for that today?
<ogra_> brendand, 126
<brendand> ogra_, oh that long ago. hmm
<ogra_> yeah
<ogra_> brendand, well, that was friday
<ogra_> (or rather even sat. ... it was dropped on fri. image built on sat.)
<popey> Mirv: could you please upload calendar to store http://s-jenkins.ubuntu-ci:8080/job/calendar-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.calendar_0.4.531_all.click
<Mirv> sil2100: I hate car mechanics too, that's why I drive 50+km and travel back with public transport when my car requires service, just because I've finally found one place that actually treats customers well
<Mirv> or if it's a one day job, I work from a nearby cafe and simply drive back at eod
<sil2100> Mirv: lucky! I mean, I would be willing to do that as well, but the car mechanics that are just like 100m from my apartment were normally timely
<ogra_> sil2100, oh ... can we actually turn line 61 into "landed" state somehow ?
<sil2100> ogra_: looking
<ogra_> (hud removal ... )
<sil2100> Sure, doing
<sil2100> Done
<ogra_> thx
<brendand> ogra_, i flashed 128. i guess if the messaging tests do well here then we can rule out the hud removal. let's see
<ogra_> hmm
<ogra_> i actually wonder if the framework itself specifies the hud somewhere
<brendand> although it looks like it's already crashed
<brendand> :/
<brendand> before i even got to run them
<ogra_> or unity-voice-service
<ogra_> (without haveing a dependency)
<brendand> ogra_, it takes a really long time to restart unity8 too
<ogra_> sometimes, yeah
 * ogra_ has seen that here too
<Mirv> popey: calendar uploaded
<popey> thanks
<brendand> ogra_, we should probably all be collecting stack traces when we have these crashes
<ogra_> brendand, well, mine seem to all be uploaded to e.u.c
<ogra_> https://errors.ubuntu.com/?package=unity8&period=day
<ogra_> hmm
<brendand> ogra_, shit - look at thursday/friday
<brendand> ogra_, although perhaps that's just the effect of the release
<ogra_> hmm, so this is better https://errors.ubuntu.com/?package=unity8&period=week&pkg_arch=armhf
<brendand> ogra_, 128 seems to be a lot more stable and that was after the hud removal
 * ogra_ wonders where ubuntu-rtm errors actually go 
<ogra_> there is no way to look them up on errors.u.c it seems
<brendand> ogra_, yeah they all seem to be from utopic
<ogra_> right, which doesnt have the most recent unity8
<ogra_> ev, do we have errors.u.c for ubuntu-rtm somewhere ?
<ogra_> now that we land in vivid the utopic data doesnt help much anymore (as the vivid data wont since everything moved on)
<asac> unity is again spinning the spinner and doedsnt come back
<ogra_> asac, see above ... thats what we are researching
<asac> ok cool any info?
<ogra_> sadly all our info sources dont really help much ... pointing to utopic or vivid
<ogra_> utopic is to old, vivid has moved on beyond whats in 14.09
<asac> and?
<asac> i dont see how that prevents us from figurinng this
<ogra_> that measn we cant get proper info from errors.u.c
<ogra_> beyond that brendand is going back through the images atm
<asac> i thought that we fixed that
<ogra_> if we did i wouldnt know how to get that info summary
<asac> e.g. we have the right symbols on retracers for derived distro
<ogra_> do you ?
<asac> yes
 * asac asks pitti in -touch
<popey> Mirv: also, please upload sudoku. http://s-jenkins.ubuntu-ci:8080/job/sudoku-app-click/lastSuccessfulBuild/artifact/generic-click-builder-utopic-armhf/output/com.ubuntu.sudoku_1.1.312_all.click
<asac> ogra_: sil2100: https://errors.ubuntu.com/bucket/?id=/usr/bin/unity8%3A6%3A__assert_fail_base%3A__GI___assert_fail%3A__GI___pthread_mutex_lock%3A__gthread_mutex_lock%3Astd%3A%3Amutex%3A%3Alock
<asac> tahts the unity crash ogra is seeing
<asac> brendand: ^
<asac> if thats our crash, thats the starting point
<asac> started on oct 10 on RTM
<asac> what landed on oct 9/10 ?
<asac> :)
<satoris> Mirv: any idea why line 41 has been given up on and if there is something we need to do to get it back on track?
<ogra_> asac, depends :) image 94,95 and 96 were built in that timeframe http://people.canonical.com/~ogra/touch-image-stats/rtm/
<ogra_> 94 had an ubuntu-app-launch
<brendand> asac, but that would have been in the bq image then
<brendand> asac, there's no way we wouldn't have noticed when qa-ing it
<ogra_> 95 a new UITK
<asac> pulse
<asac> :)
<asac> we have a playback crash here
<ogra_> and 96 a new unity8
<asac> ogra_: so maybe its indeed OOM because you have soooo many albums?
 * ogra_ wonders if thats a red herring 
<brendand> ogra_, i feel like it is
<asac> good
<asac> i got a new unity one
<ogra_> the "feelable" crashyness only started end of last week
<asac> that really tears down everything here
<ogra_> yeah
<ogra_> i have that on nearly every reboot
<asac> https://errors.ubuntu.com/oops/47162672-5e98-11e4-a34f-fa163e22e467
<asac> thats mine
<asac> from just now
<brendand> ogra_, only 10 crashes since two weeks doesn't stack up if that's the one crash
<ogra_> brendand, did you try something pre 126 yet ?
<ogra_> right
<asac> ig guess thhat might have to get processed first
<brendand> ogra_, no. 128 seemed more stable though. but still not totally stable
<ogra_> right
<ogra_> i remember at the airport 128 was rather stable for me while it constantly crashed for davmor2
<brendand> ogra_, i'll try pre 126 next
<brendand> ogra_, yeah but davmor2 is special :)
<ogra_> true
<ogra_> i know that i manually rolled back the hud stuff though ... when searching for the apt issue
<ogra_> that might have gotten me this tiny bit better stability
<brendand> ogra_, yeah the hud i think is the top culprit right now
<ogra_> well, i guess rather unity-voice-service than the hud actually
<ogra_> missing dep or so
<davmor2> ogra_: please do a very careful review of sadtrombone.webapp on your phone ;)
<ogra_> davmor2, you mean i should press the button very gentile ?
<ogra_> whoops ...
<ogra_> s/gentile/gentle/
 * ogra_ has french day today 
<ogra_> :P
<davmor2> ogra_: haha
<asac> brendand: can we have a bug for the crashes? see -touch
<asac> unity8
<davmor2> ogra_: I wonder if it is webapp containers that is making the phone unstable?  we both seemed to get lock ups on or around the g+ app right?
<davmor2> brendand: ^
<davmor2> just a guess, I'm trying to find some common ground
<Mirv> satoris: it was to utopic, where you don't land anymore. I'll assign a vivid silo for i tnow.
<sil2100> Anyway, it seems we're a bit low on manpower from the CI team today
<brendand> asac, yeah will do
<brendand> can i point to the ci crashes in a public bug?
<sil2100> asac: if you could subscribe landing-team-trackers to then - awesome
<satoris> Mirv: ok, thanks.
<asac> brendand: sure; those are public anywya, no?
<brendand> asac, for RTM on krillin?
<asac> brendand: hmm. i think posting the link should be fine given that the link is protected?
<asac> brendand: is this only on krillin?
<asac> brendand: are the links for downloading protected?
<brendand> asac, yes
<asac> brendand: then its fine i guess...
<brendand> asac, only on krillin? hmm, we have no evidence to the contrary since not many people are using mako
<ogra_> sil2100, you said at the airport there was a silo for ricmm's fix for the ~70 UITK test failures ... i dont seem to see it anywhere (nor do i see a spreadsheet entry for it)
<sil2100> ogra_: there's a branch for it prepared, but I didn't know anything about a silo - bzoltan_ just mentioned that they have it and are planning on releasing it with the next UITK (whatever that meant)
<sil2100> bzoltan_: ^ any news on landing the AP test failure fixes?
<Mirv> sil2100: not yet landed https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/bug-lp1382414/+merge/239290
<Mirv> ETA is most probably this week, since it was discussed last week
<sil2100> We would really need this in before the cut-off
<fginther> sil2100, morning
<fginther> sil2100, did you get a response on your dashboard query from a couple hours ago?
<ogra_> fginther, i dont think we did
<Mirv> bregma: ^ unity 14.04 SRU made it in, running merge&clean
 * bregma does a happy dance
<fginther> ogra_, sil2100, I've restarted the portion of the smoketesting that failed due to an unrecoverable device. Looking for other issues...
<sil2100> fginther: no, didn't get any :)
<sil2100> fginther: thanks! Do you know if plars will be around today as well?
<fginther> sil2100, other then the lack of results, any other known issues?
<sil2100> Oh!
<sil2100> fginther: what about psivaa_? Do you know if he's also away?
<barry> ribru, infinity i saw the eatmydata errors when i was updating my vivid chroots.  now i don't see them.  go bother someone else you gremlins
<sil2100> hah
<sil2100> ;)
<brendand> ogra_, 125 is definitely much more stable
<brendand> ogra_, anecdotally at least
<brendand> ogra_, did you or sil2100 get to file that bug?
<sil2100> brendand: not me, but 125 is the image before the hud removal
<sil2100> http://people.canonical.com/~lzemczak/landing-team/ubuntu-rtm/126.commitlog
<sil2100> So this should be the image that worsened things
<brendand> bfiller, hey - you've got a lot of silos queued up :)
<bfiller> brendand: indeed
<bfiller> brendand: let me know if you have any questions about testing
<brendand> bfiller, hopefully most of them should get looked at today - do you have any preference for the order they are done in?
<sil2100> davmor2, brendand: so currently there are only 4 silos in the sign-off queue, right?
<cwayne> jdstrand: we should figure out when to land apparmor-easyprof-ubuntu :)
<bfiller> brendand: one sec, on standup
<bfiller> brendand: silo 6 would be great to get in first
<brendand> bfiller, both those bugs are approved?
<bfiller> brendand: yes
<tvoss> sil2100, ping
<ogra_> tvoss, !
<sil2100> ogra_: hey, did you get any info from -release regarding those chroots?
<sil2100> tvoss: !
<ogra_> tvoss, everything ok ?
<sil2100> ogra_: the armhf ones during debootstrap for armhf
<ogra_> sil2100, seems infinity isnt up yet
<tvoss> ogra_, sil2100 mostly, everyone back home
<ogra_> cool
<sil2100> tvoss: \o/ really glad to hear that
<ogra_> hop its wasnt anything bad
<ogra_> *hope
<ogra_> tvoss, so we tried to decypher ribru's mail but kind of failed
<tvoss> ogra_, rota virus, kinda dangerous for little ones as they dehydrate fast and easily
<ogra_> uh, yeah
<tvoss> ogra_, the issue is that https://code.launchpad.net/~thomas-voss/location-service/fix-gps/+merge/239411 was meant to land, and I put that MP into the silo (see spreadsheet, although the line says "given up")
<ogra_> tvoss, especially since the build failure he refers to seems to not be related to merging but seems to be some self test where the build does not find ofono on the dbus
<tvoss> ogra_, nope, one of the tests times out, the ofono not there messages are perfectly fine and handled gracefully
<ogra_> ah ,k
<tvoss> ogra_, sil2100 the MP that landed is https://code.launchpad.net/~thomas-voss/location-service/fix-gps-integration-and-allow-for-decorating-provider-names
<tvoss> ogra_, sil2100 at least in the binary packages. I think someone published a silo other than rtm 6
<ogra_> tvoss, rtm 004
<ogra_> that was long pending
<ogra_> and landed yesterday
<ogra_> (that was the one that missed the milestone due to QA failing a few times)
<tvoss> ogra_, sil2100 so, at any rate, I would like that landing to be reverted and instead https://code.launchpad.net/~thomas-voss/location-service/fix-gps if possible at all
<tvoss> ogra_, sil2100 but your call, I can just fix the test hang for AlbertA and we keep on movin
<tvoss> g
<ogra_> tvoss, but that means reverting a critical fix from milestone 1016
<tvoss> ogra_, ack, so I will fix the test hang for AlbertA
<AlbertA> tvoss: cool thanks!
<ogra_> tvoss, well, it is your trunk :)
<tvoss> ogra_, true, still unsure what happened as the respective branch wasn't merged automatically
<ogra_> tvoss, hmm, it should have been when the silo landed indeed
<ogra_> but thats a sil2100 question
<sil2100> Trying to get my head around this as well
<tvoss> ogra_, yeah, so something went wrong ... not sure what, though
 * ogra_ has only seen cu2d from far far away
<ogra_> sil2100, the silo had lxc-android--config in it too ... i wonder if the merging choked on that (unlikely though)
<sil2100> ogra_, tvoss: the thing is... silo 004 had a sync request of location-service
<ogra_> yes, plus lxc-android-config
<sil2100> ogra_, tvoss: so there was no merge related to location-service in the landing, so no wonder nothing got merged
<ogra_> oh
<ogra_> right
<sil2100> Not sure how this got into utopic though then
<tvoss> sil2100, ah, interesting, but where did the binary packages come from?
<ogra_> dput to the PPA ?
<sil2100> tvoss: trying to figure that out, sadly it's all working on scraps of information
<ogra_> lool, ^^^ do you knwo ?
<sil2100> ogra_, tvoss: I would suppose it was a sync from utopic
<ogra_> i doubt that
<ogra_> since what landed in utopic was broken ...
<ogra_> the issues were found on milestone day when the rtm silo was tested
<sil2100> hm, I see 23 in vivid
<ogra_> not before iirc
<sil2100> So a sync from vivid that was maybe?
* fginther changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: fginther | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: robru broke 3 ribs
<sil2100> hmmm
<ogra_> so it landed in utopic ... then failde QA later in rtm ... and then was stuck for a week
<sil2100> Actually that's really strange, since CI Train logs say:
<sil2100> 2014-10-23 19:19:41,929 INFO Looking at location-service as per sync request
<sil2100> 2014-10-23 19:19:44,505 INFO Grab code for location-service (2.1+14.10.20141023-0ubuntu1) from utopic to the 'build' directory
<sil2100> So I think it got synced from some silo PPA :|
<lool> sil2100, ogra_: lxc-android-config bzr is way out of sync; that's why everybody uploads changes, either to archive ot to PPA
<lool> which is what I did here
<ogra_> lool, thats fine
<sil2100> lool: do you remember where you synced location-service from?
<ogra_> lool, the location-service side is what broke
<lool> sil2100: from an ubuntu PPA
<ogra_> lxc-android-config isnt the issue
<lool> I mean a regular anding PPA
<lool> so it didn't land?
<ogra_> well, i assue something happened to fix it between 10/16 and yesterday
<sil2100> lool: seems it didn't
<ogra_> where did that fix come from
<sil2100> I mean, wait
<lool> so
<sil2100> I guess it's landed in both distros now anyway
<lool> a) lxc-android-config package uploaded + location-service branch merged into ubuntu silo => this landed
<ogra_> right, the question is if that is what we wanted :)
<sil2100> So I suppose there only was the problem of the branch not being merged properly
<lool> b) separate rtm lxc-android upload + copy of location-service into ubuntu-rtm PPA => this partially landed?
<ogra_> lool, right ... on 10/16 the rtm equivalent failed QA
<lool> it ended up passing QA
<ogra_> i.e. your b) scenario
<ogra_> lool, how ?
<lool> it failed before the sprint
<ogra_> there must have been a change inbetween
<lool> wow, electricity went down here
<ogra_> was that in a device or custom tarball ?
<lool> but back up
 * lool checks equipments brb
<ogra_> dont lick your finger and touch power cables ! use a voltmeter instead !!
<ogra_> :)
<lool> ok, UPS took most of the hit, rest took it fine
<ogra_> lool, so to make it pass QA something must have been fixed
<lool> impressed by the microwave which has no battery but kept the time and the disher that just kept on going
<ogra_> what/where was that
<ogra_> device ? custom ? code change ?
<lool> so the first time this failed, it was mostly me copying the lxc-android-config from ubutnu erroenously
<lool> then I'm not sure whether we did a code update or not, I think not
<lool> vruiz tested the version which landed last week
<ogra_> you mean yesterday
<lool> no, that was like thursday last week
<lool> where's the archive of passed qa?
<sil2100> lool: I think the trello board has that
<ogra_> lool, http://people.canonical.com/~ogra/touch-image-stats/rtm/131.changes
<ogra_> thats was yesterday
<ogra_> not sure if it sat idle over the weekend though
<lool> well the rtm build from yesterday shows the package being picked up
<lool> I guess they only got published in rtm recently
<ogra_> i remember you fixing lxc-android-config on 10/16 so QA could test
<ogra_> but then it faild that test
<lool> 27
<lool> ogra_: yes, this is what I mention above
<ogra_> then something must have happened that now makes QA pass
<lool> but that's when we were trying to hit the 17th
<lool> or 16th rather
<ogra_> right
<lool> and we had a fix on the 17th
<lool> but that only started being QA-ed like wed last week
<lool> on 22th
<ogra_> and that landed in utopic
<lool> QA passed 23
<lool> no, I'm speaking of rtm
<ogra_> well, utopic and rtm now have the same location-service
<ogra_> so i assume you landed the fix in utopic on the 17th
<lool> location-service landed on 23rd in utopic and yesterday in rtm
<lool> sorry, I dont even know what problem we're trying to solve here
<lool> ah no, it's *not* in utopic
<lool> it's in vivid
<ogra_> lool, just trying to do forensics to know the right thing landed where it should
<lool> cause utopic was closing at the time
<sil2100> Yeah
<lool> i see the fixes in rtm and in vivid; do we need them in utopic?
<ogra_> yeah, might sit in unapproved ... if at all
<ogra_> lool, no, we just want to be sure the right thing is in rtm
<lool> I dont think we even tried landing in utopic
<lool> yeah, I think we're good on that one
<lool> missing the startup fix now
<ogra_> (and why the landing didnt get merged into trunk ... but i think we understood that already)
<ogra_> (i.e. silo sync fro something that didnt land in utopic)
<lool> right
<ogra_> phew, so we're all fine
<ogra_> lool, tvoss, btw, did you ever test location in a car ?
<tvoss> ogra_, not me personally, but it's part of a larger test plan for the Here stuff
<ogra_> works fine for about 5km :) then i have to restart the app to have it move along with me
<ogra_> else the dot just gets stuck
<ogra_> things seem to time out or so
<lool> ogra_: I did in the past
<lool> ogra_: actually what I've spotted last week is that whenever the screen turns off, updates stop; you have to start some location using app to have them resume
<ogra_> i did it on a freshly bootstrapper install yesterday
<lool> even walking
<lool> ogra_: seems coherence with your experience
<ogra_> i disabled screen blanking completely and had the phone on charger
<ogra_> attached to the windshield
<ogra_> it gets the fix within 1-2sec ... really nice ... just that it stops then
<tvoss> ogra_, could you check that the gps provider was actually running?
<tvoss> ogra_, I assume that you had a 3G data connection enabled?
<ogra_> tvoss, hard to do while driving :)
<ogra_> yep
<ogra_> and the maps were properly updating when moving
<ogra_> juust the dot wasnt anymore after some time
<ogra_> (i could zoom and move the map with a finger and it downloaded fine, so the network was good)
<ogra_> it looked like either trust-store timing out the permission or the provider itself timing out
<tvoss> ogra_, the map was moving?
<tvoss> ogra_, then you certainly had location updates
<ogra_> i could move it
<ogra_> it was moving while the dot moved
<pmcgowan> I am curious, what is the real solution to keeping the screen on when navigating? Should we have a manual toggle?
<ogra_> and when the dot stopped moving i could swipe it around and got map updates for the missing tiles
<tvoss> ogra_, so if you could check prior to the drive that the location service command line actually has --provider gps::Provider, that would help me
<ogra_> tvoss, http://paste.ubuntu.com/8720282/ ... that should be the respective logfile (as you will notice i switched to googlemaps at some point to see if it behaves any better)
<ogra_> smells like the dbus backend vanishes somehow
<tvoss> ogra_, hmmm, that's interesting. Did you reopen the page?
<tvoss> ogra_, at any rate: mind filing a bug against location-service and trust-store?
<barry> ogra_, sil2100 quick sanity check on s-i 2.5.1 for rtm.  upstream tarball is ready to go so i'm prepping a source package for ubuntu-rtm only.  i don't plan on sru'ing 2.5.1 into utopic and vivid will get s-i 3.0 when that's ready.  so i want to version number the rtm package properly.  i'm thinking 2.5.1-0ubuntu1~rtm1.  that will sort higher than the last utopic/rtm of 2.5-0ubuntu1, lower than any vivid 3.0 release, but also lower than
<barry> any 2.5.1 we might (for unforeseen reasons) want to release into vivid.  does that sound right?  also, i'm leaving it UNRELEASED in the assumption that the citrain will fill that in correctly.
<barry> ogra_, sil2100 once the source package is tested locally, i'll then create an rtm silo only and use a source package upload to the ppa instead of a merge proposal, right?
<ogra_> tvoss, yes, as i said above, every time the dot stopped moving i needed to restart the app to have it move again ... it works for about 3-5km then sits there
<lool> trainguards, could we land rtm silo 24 now?
<brendand> thostr_, do you have any feedback on silos 19 and 7? they appear to have changes that didn't make the list. i asked pete-woods yesterday, he said he needed to check with you
<ogra_> barry, hmm, why dont you just want to push to vivid and rtm in parallel ?
<thostr_> brendand: i was out yesterday and he today... will try to clarify... should have it by tomorrow at latest
<ogra_> pmcgowan, i dont think there is any solution yet ... as per definition an app cant request the screen to be on constantly
<ogra_> (i had some discussion with tvoss about that before ... seems extending the timeout is possible at some point, but not permanent-on state)
<ogra_> (in my case for ebook reader stuff though)
<barry> ogra_: i probably could, although i only wanted to land 3.0 in vivid and it'll be a little more work on my end to reconfigure my branches to do that.  if it would make the train run more smoothly, i'd be willing to do that (or at least try to)
<asac> sil2100: when do you think will we have first vivid image popping out?
<ogra_> barry, well, it will make switching rtm to vivid easier (which will happen in a far far future ... ) so you would have at least the last working code in vivid even if you couldnt land 3.0 yet
<ogra_> asac, once debootsrap is able to produce armhf chroots
<ogra_> asac, i pinged adam this morning but he seems to be out (and colin is on vac ... )
<ogra_> the build falls over when debootstrapping
<sil2100> asac: so, still waiting for some answers to why armhf chroots fail with debootstrap
<sil2100> ogra_: maybe slangasek can help out?
<sil2100> ogra_: btw. we have a bug number for the issues already?
<ogra_> sil2100, i think adam is around now
<barry> ogra_: so, just to be clear.  you're saying, land 2.5.1 onto the ubuntu train, which will land in vivid, then sync it over to rtm, and everything will work properly, right?  iow, just use the "normal" pre-vivid process
 * ogra_ goes to #ubuntu-release
<sil2100> barry: so, you want to upload s-i as a source package upload, right? Since it's not released by merges in the train, right?
<ogra_> barry, i think thats a sil2100 question but thats how i would imagine it ... kind of ...
<barry> sil2100: that's what i'm trying to figure out ;).  if i were to land it in vivid, then sync to rtm, i'd do a merge proposal like usual
<sil2100> barry: oh, so normally you release it with merges in the train?
<sil2100> Since the version number seems different than what the train uses - you have a flag that disables the version rewrite there?
<barry> sil2100: yep
<barry> X-Auto-Uploader: no-rewrite-version
<barry>  
<jdstrand> cwayne: yes-- it is actually apparmor, click-apparmor and apparmor-easyprof-ubuntu. an additional fix was identified as needed over the weekend for the apparmor change to make any effect
<sil2100> Ok, excellent
<jdstrand> cwayne: so that is built in the silo and I just have to test. however, there is another bug about the date on the device being set to 2014-01-01 that you and I need to discuss, but I am heading into a meeting atm
<jdstrand> cwayne: let's talk in a little bit
<barry> sil2100, ogra_ okay, i'll try to board the train with the usual ticket and ping you if i have problems
<sil2100> barry: so, let me think about that, since it's not as easy-peasy as it is in other cases
<barry> sil2100: okay.  ping me.  in the meantime, i'll continue to test things locally
<sil2100> barry: anyway I would try to do it like this - try to land it for vivid for now (i.e. 2.5.1) and let's then try syncing that up to ubuntu-rtm
<barry> sil2100: ok
<sil2100> We might do a source sync for that, but I'm afraid that CI Train would wrongly interpret the version
<barry> thx
<sil2100> But I'll think of something ;)
<barry> :)
<sil2100> barry: since when doing a CI Train source sync, it will probably try changing the version to: 2.5.1~rtm-0ubuntu1
<sil2100> barry: not sure if that's acceptable?
<barry> sil2100: i don't care too much as long as it lands in rtm, but i don't think it's ever done that before and i've definitely done syncs from utopic->rtm
<sil2100> barry: yeah, but when you were doing utopic->rtm syncs those were usually binary syncs
<barry> sil2100: that is true
<sil2100> barry: it *should* work as a binary sync right now too I guess, but more risky
<sil2100> (since we no longer can be sure of that as in the past)
<sil2100> Well, anyway, for now vivid, then we care about rtm ;)
<barry> sil2100: ok.  and i still have a bit of local testing to do first before i'm ready for a silo, so if something hits you let me know.  rtm is of course the one we really care about :)
<barry> right now
<Mirv> lool: done. there was some sort of dashboard issue, but all seems fine when I checked manually.
<brendand> Mirv, are you going to be testing silo 22?
<Mirv> brendand: it's WIP still, lorn keeps on churning upstream fixes
<Mirv> brendand: for testing, I'll probably refer to mr. zanetti and others who have reproduced the problem (although I nowadays think I know how I see that too)
<john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20141028-3ca60be.changes
<john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-testresults-20141028-3ca60be.ods
<john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20141028-3ca60be.tar.xz
<john-mcaleely> sil2100, ogra_ davmor2 brendand ^ new device tarball
 * ogra_ checks what you broke again 
<john-mcaleely> can I request a qa pass at your earliest convenience
<john-mcaleely> :-_
<john-mcaleely> :-) eve
<john-mcaleely> n
<davmor2> john-mcaleely: lalalalala not listening lalalalalala
<ogra_> wheee dropping log noooooise \o/
<john-mcaleely> davmor2, tsk
<ogra_> get that in !!!
<john-mcaleely> so it's fixes for alarms not always working, and cleanup performed during power management investigation
<john-mcaleely> which we should get in so future investigations (!) have an easier life
<john-mcaleely> both bugs are 'on the list', I believe
<davmor2> john-mcaleely: I'll have a look after I finish this silo I'm testing
<john-mcaleely> davmor2, yay. sounds good
<john-mcaleely> davmor2, notably absent are the new modem binaries I mentioned last week. They've caused regressions, and are being re-worked
<sil2100> davmor2, john-mcaleely: if Dave has time for it, then go for it
 * ogra_ just wants the logging noise gone 
<ogra_> screw the modems, land it already :)
<john-mcaleely> ha. never have so many been pleased by printf changes
<ogra_> heh
<sil2100> fginther: can you check what's up with #133 krilling test results that it's not moving forward?
<ogra_> i thought he did above
<fginther> sil2100, sure, it failed again (for a different reason) and I restarted it again. but I do suspect some other results to be there
<ogra_> well, reminders is known to be wonky due to using OAuth 1.0
<ogra_> you likely want to skip that
<ogra_> click_image_tests are also known to fail (but cwayne and mvo_ should be working on that )
<ogra_> though the latter should make anything stuck
<mvo_> ogra_: *cough* right - what was the url again?
<sil2100> fginther: what was the reason for the failure this time?
<fginther> wasn't reminders fixed to not hang the tests?
<ogra_> mvo_, so i looked a bit deeper ... krillin doesnt use the click_list anymore for the test
<fginther> sil2100, unity8-autopilot could not be installed: 'Err http://derived.archive.canonical.com/ubuntu-rtm/ 14.09/main python3-junitxml all 0.6-1.1build1
<fginther>   Could not resolve 'derived.archive.canonical.com'"
<ogra_> mvo_, seems the test calls "click list" on the device and compares it to http://people.canonical.com/~ubuntu-archive/click_packages/click_list ... which used to be our master list ... but due to the fact that we now have a custom tarball on krillin that removes clicks there and adds its own they wont match anymore
<fginther> it couldn't hit "derived.archive.canonical.com" at all
<ogra_> mvo_, so i think cwayne needs to provide you a different "krillin_click_list" to match against and the test needs to use that
<mvo_> ogra_: oh, I see. what is the url again for hte test failure?
<ogra_> mvo_, http://dashboard.ubuntu-ci:8080/smokeng/utopic/touch_stable/krillin/132:20141027.1:20141015-32e0f27/634/click_image_tests/220717/ is the url of the last test
<mvo_> ogra_: thanks
<cwayne> mvo_: ogra_: i'm happy to get you a list
<tvoss> fginther, around?
<bdmurray> sil2100: what needs to happen next with bug https://bugs.launchpad.net/ubuntu-rtm/+source/whoopsie/+bug/1339916? I see it was approved in the spreadsheet.
<ubot5> Ubuntu bug 1339916 in whoopsie (Ubuntu RTM) "SystemIdentifier can change between reboots" [High,Triaged]
<lool> Mirv: thanks
<fginther> tvoss, yes
<ogra_> bdmurray, add a line to the spreadsheet for it to request an rtm silo
<ogra_> oh, sorry
 * ogra_ should read sentences to the end :P 
<ogra_> oh, other spreadsheet
<ogra_> bdmurray, https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc&pli=1#gid=0
<ogra_> you want an rtm landing entry there
<ogra_> bdmurray, once you got a silo assigned, you dput the change to the silo PPA and test it ... the rest is handled by QA and the landing team then
<ogra_> bdmurray, note that the version needs to be on top of the last rtm package though ...
 * ogra_ looks that up 
<ogra_> bdmurray, https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-October/000775.html ... you want rtm5 most likely
<sil2100> bdmurray: yeah, so if it's approved, we need to get it to RTM through the train - is this change landed in vivid/utopic already?
<sil2100> bdmurray: I mean, where is it landed, to vivid or to utopic?
<ogra_> sil2100, utopic
<bdmurray> sil2100: utopic and vivid (presumably)
<sil2100> bdmurray: ok, then we can do a binary sync then
<ogra_> sil2100, and then there was an lxc change on top of it which blocked us from syncing it over
<sil2100> bdmurray: just fill in an landing entry for it an I'll fill in all the details to do a sync
<bdmurray> sil2100: it also requires a change to lxc-android-config
<sil2100> Ah
<ogra_> sil2100, new lxc version and according changes ... we cant use utopic at all as base for rtm for this package anymore
<ogra_> neither vivid i guess
<ogra_> since that has the same packag
<ogra_> e
<ogra_> (and a dep on a newer lxc version)
<sil2100> ogra_: then a sync of whoopsie and then upload a custom lxc-android-config
<ogra_> right
<ogra_> based on https://launchpad.net/ubuntu-rtm/14.09/+source/lxc-android-config/0.208rtm4
* fginther changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: robru broke 3 ribs
<brendand> sil2100, did the spreadsheet get messed up?
<sil2100> brendand: what's wrong?
<brendand> sil2100, ubuntu-rtm/landing-004 says line 65 in its description
<brendand> sil2100, but line 65 is definitely not that
<davmor2> Saviq: I've just had the phone reboot/unity8/mir/lightdm/crash it's one of them anyway on the ubuntu spinning logo I'll check the crash files after, but it was on receiving the osd for google syncing contacts
<ogra_> looks like 66 though
<ogra_> off by one
<ogra_> davmor2, reboot ?
<ogra_> thats definitely a kernel or driver issue then
 * ogra_ has never seen that 
<bdmurray> sil2100: I seem to only have view access so can't add a new landing entry
<davmor2> ogra_: ubuntu spinning logo, I'm assuming reboot is the wrong term and I know how Saviq likes specifics so I covered them all :)
<ogra_> phew ...
<sil2100> bdmurray: oh no!
<sil2100> Let me fix that :)
<ogra_> davmor2, so the known issue then
<davmor2> ogra_: yes but a fresh log/crash file for Saviq to poke hopefully :)
<kenvandine> anyone know why 4 of the 7 powerppc builders have a status of "Manual"?
<ogra_> i think asac collected one and me too
<ogra_> kenvandine, probably a question for #ubuntu-release
<kenvandine> causing long wait times for the vivid silo builds :/
<ogra_> but likely simply because they arent ready yet
 * ogra_ thinks we were a bit fast with opening this time round ... to have all bits in place in time
<kenvandine> perhaps
<kenvandine> but it would be nice if all 7 were building :)
<ogra_> (especiallly since soome arches will need some time to process all initial package builds)
<sil2100> bdmurray: done
<asac> sil2100: when do you think can we do v landings?
<asac> slangasek: ^^
<sil2100> asac: we're doing v landings already
<asac> sil2100: when do we do first image you think?
<bdmurray> sil2100: okay, I've added a landing entry
<sil2100> asac: it's just that we don't have an image yet, not sure when that will be resolved though...
<ogra_> asac, we already do them ?
<sil2100> ogra_: I think I missed in the backlog, but do we have a bug for the chroot issue?
<ogra_> sil2100, i dont think so, but infinity is digging, i assume it will be fixed soon
<ogra_> obviously it isnt reproducable locally so i guess he needs to dig into the builders themselves
<ribru> barry: are you saying you got eatmydata working without any configuration changes in vivid? wtf?
<barry> ribru: no, only that it hasn't shown up again yet.  but the day is young
<ribru> barry: oh ok. because I found some wiki documentation for pbuilder that suggested some changes to make eatmydata work in vivid, but they didn't seem to work for me, I tried several variations.... after a while I just gave up and disabled it in vivid.
<brendand> ogra_, did we try just rolling back the hud removal yet?
<ogra_> brendand, did you confirm it is actually the hud ?
<brendand> ogra_, no i still have no idea
<ogra_> (i will have to rip it out again, even if i roll back, so i want to be 100% sure)
<brendand> ogra_, well i mean did we try just installing the old version of the package - we don't actually have to revert it yet
<ogra_> how do you mean "old version" ?
<ogra_> it was ripped out completely
<ogra_> just apt-get install hud
<ogra_> that will revert the change easily ;)
<davmor2> john-mcaleely: can you make the tarball so I can access it please it makes it so much easier to flash then ;)
<john-mcaleely> davmor2, oh
<davmor2> john-mcaleely: You don't have permission to access /~jhm/barajas/device_krillin-20141028-3ca60be.tar.xz on this server.
<john-mcaleely> davmor2, please retry
<john-mcaleely> davmor2, sorry!
<davmor2> john-mcaleely: yay ta
<sil2100> fginther: o/
<sil2100> davmor2: you SLACKER!
<davmor2> sil2100: sorry I thought it was off in the afternoon, you could of pinged :P
 * ogra_ didnt get a calendar notification either 
<davmor2> sil2100: I was too busy testing silos :P
<ogra_> and ibn fact my phone calendar doesnt have the evening meeting at all anymore
 * ogra_ forces a calendar sync
<davmor2> sil2100: install sadtrombone app and you can play it :P
<sil2100> I got an e-mail reminder
<sil2100> ;p
<davmor2> sil2100: I didn't
<ogra_> yeah, it is obviously in my gcal
<sil2100> davmor2: you testing the device tarball now?
<ogra_> but not on my phone
<davmor2> sil2100: yeap just moved onto it now I finished the silo I was on
<ogra_> davmor2, what happened to failsauce ? i thought *that* was the recommended app for the task
 * john-mcaleely excitedly awaiting results
<john-mcaleely> well, awaiting, anyway
<john-mcaleely> :-)
<davmor2> ogra_: it probably is but popey said to make it so I did :)
<popey> it works
<davmor2> popey: and passed all the tests
<ogra_> heh
<sil2100> fginther: one quick question though - do you know if the http://ci.ubuntu.com/smokeng/utopic/touch/ dashboard is configured to fetch images from devel-proposed or utopic-proposed?
<ogra_> sil2100, check the console log of one of the tests
<ogra_> the u-d-f command should be in there
<ogra_> (with channel name and all)
<ogra_> + adb reboot bootloader
<ogra_> + ubuntu-device-flash --password ubuntuci --bootstrap --developer-mode --channel ubuntu-touch/devel-proposed
<ogra_> sil2100, ^^^^
<sil2100> Found it as well, thanks!
<ogra_> yay, and a calendar sync got me the meeting back
<ogra_> so i wont miss the harps tomorrow
<sil2100> Harps for the win!
<ogra_> ++
 * ogra_ finally finds a minute to subscribe to vivid-changes
<ogra_> wow ... and i already missed a ton of packages
<fginther> sil2100, it uses devel-proposed
<asac> hmm. i kinda still feel i dont get a notification for system updates
<asac> didnt see 133 krillin rtm by notification, but just through trying in system settingts
<asac> Chipaca: ^
<ogra_> asac, are you sure your networking was up and working ?
 * ogra_ always missed them when he also had wlan issues 
<ogra_> i did a --bootstrap today though ... we'll see how that goes
<asac> ogra_: yeah pretty, but well :)
<asac> next time i will monitor for new images and keep looking at state
<asac> monitor here
<ogra_> you can be sure to get an image every morning when getting up usually
<asac> ogra_: so i cant rule out that temporarily the network was down, but i would anticipate that it picks it up first time it can talk tot he server again
<asac> ok lets see what the next morning brings :)
<ogra_> if davmor2 manages to test the device tarball successfully you might even see one tonight
<asac> ok good news i guess :)
<ogra_> finally dropping all the log spamming from the kernel
<ogra_> silly hardcoded printfs in android kernels ...
 * asac hopes this will give another boost in usability :P
<ogra_> heh
 * asac will do a out-of-wifi-walk-through-town scenario tomorrow morning - scheduled :P
<asac> really hope the image is up to that so i can find more interesting bugs than "damn, this needs restarting" :)
<plars> sil2100: hi, sorry I was unresponsive to your email earlier, at a conference this week but I think fginther talked to you already about reminders still appearing to cause problems?
<ogra_> asac, use location ;)
<plars> sil2100: what's the status of the new autopilot with internal test timeout landing? iirc there needs to be a phablet-test-run change for that as well
<ogra_> plars, system-settings is also worrying ... startsd to fail out of the blue in 128
<john-mcaleely> there are multiple anecdotal reports of upgrade notifications 'not working'
<ogra_> (and constantly since)
<asac> ogra_: why?
<plars> ogra_: has anyone tried to reproduce yet?
<ogra_> plars, nope
<ogra_> asac, if i knew that i would have fixed it :P
<sil2100> plars: I think that's still not there yet
<sil2100> plars: but from what I saw, it's not only reminders causing trouble
<plars> ogra_: nothing has changed for us since 10/21, and that was just where the default wifi config is pointing at
<plars> nothing test related
<ogra_> asac, the only thing in 128 was the apt rollback which cnat really affect system-settings
<sil2100> plars: sometimes I saw the dashboard being stuck on some other test suite, like weather or system-settings
<asac> ogra_: shall i try downgrading something?
<plars> sil2100: yeah, ogra_ mentioned system-settings
<asac> unfortunately i cant even reproruce, so i could only state a gut feeling that its "maybe more stable"
<asac> ogra_: my backtrace from earlier today had media-hub in it
<asac> that thing landed in 126 i was told
<ogra_> asac, i'm not even sure it is a failing tests ... looking at the console log i see system-settings running something
<ogra_> but the dashboard disagrees
<asac> i am talkinga bout my crash locally
<asac> that thing had media-hub in it
<asac> https://errors.ubuntu.com/oops/47162672-5e98-11e4-a34f-fa163e22e467
<asac> but was a bit bogus
<ogra_> asac, kgunn is looking into that bug
<asac> so if we also see something related to media-bug/audio etc. in the automation
<ogra_> asac, bug 1386803
<asac> i am sure its the same
<ubot5> bug 1386803 in unity8 (Ubuntu) "unity8 crashing a lot since image #126" [Undecided,Confirmed] https://launchpad.net/bugs/1386803
<asac> yeah
<asac> righgt
<ogra_> we were focused on hud initially
<ogra_> but seems thats not it
<ogra_> so now the other bits get inspected
<asac> ok
<asac> let me know what ended up causing the issue
<asac> just wanted to point out that if automation has something related to audio/media-hub in trace
<asac> its probably the same i saw locally here
<asac> same with different paint
<asac> heh
<ogra_> well, for me its always scoperunner that crashes alongside
<ogra_> judging by the timestamps in /var/crash
<davmor2> john-mcaleely: so the tarball looks good, I've been tailing log files as I test it and they have been fairly quite appart from some of the apps but I'm assuming that is the app rather than random data as it shuts up again after I close it :)
<davmor2> ogra_: ^ that should make you happy
<ogra_> \o/
<ogra_> :)))))))
<ogra_> :D
<ogra_> davmor2, syslog is the only interesting one for these changes anyway
<ogra_> kernel all goes there
* fginther changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: fginther | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: robru broke 3 ribs
<davmor2> ogra_: yeah I tail syslog still am infact :)  and other that apps that trigger hardware like the camera and tagger and here maps app/location it was mostly quite odd lines thrown in but nothing major
<ogra_> awesome
<ogra_> thats what i like
 * ogra_ remembers having to do all these printf fixes for the nexus7 kernel back when we did desktop images for them ... it was pure horror
<davmor2> ogra_: hahaha
<john-mcaleely> davmor2, sounds good :-)
<john-mcaleely> ogra_, so, when's a good time to publish it?
<john-mcaleely> sil2100, ^
<ogra_> any time is fine
<john-mcaleely> I'll do it now then
<ogra_> 3am UTC wouldnnt be so fine
<ogra_> in case you planned to wait til tzhen :P
<bfiller> ribru: could you publish silo 11 on rtm please?
<john-mcaleely> ha. is that when the daily starts, or when the custom tarball lands?
<davmor2> ogra_: john-mcaleely is not you he goes to sleep ;)
<ogra_> daily
<ogra_> well, that might be true for this week actually :)
<john-mcaleely> aha :-)
<ribru> bfiller: dnoe
<ribru> done
<john-mcaleely> ogra_, davmor2 sil2100 new tarball published
<john-mcaleely> thank you!
<bfiller> ribru: thanks
<ogra_> yay, thanks
<ribru> bfiller: you're welcome
<davmor2> john-mcaleely: awesome
<pmcgowan> hi guys was there an issue with the 130 image not starting properly?
<ribru> bfiller: rtm 6 and 14
<bfiller> thanks ribru
<ribru> bfiller: you're welcome
<ogra_> asac, i just got the notification here fyi
 * ogra_ OTAs to silent logs 
<ogra_> et voila ...
<ogra_> session crashed directly after SIM PIN -> PIN
<jdstrand> fyi, rtm silo 003 but 'QA signoff needed' is marked as 'yes'. it was formerly 'no', but someone changed it I think. I was going to land it tonight (the changes are really small-- adds an apparmor rule, adds an extra option to apparmor_parser invocations in the boot script and click-apparmor, and adjusts the parser to not unconditionally regenerate the cache when providing that option)
<ogra_> jdstrand, convince olli_ ...
<jdstrand> davmor2: you said you'd test the custom tarball tomorrow, but you can't do that until the above ^
<ogra_> technically every landing in rtm needs QA signoff atm
<jdstrand> I don't really care if someone does it, there was just coordination happening
<jdstrand> I've got to step away for a while; I'll be back later
<ribru> ugh, dashboard is missing lots of spreadsheet data but the spreadsheet seems fine, not sure why it's not picking that up. great
<jdstrand> ok, updated the comments in the spreadsheets to reference all the changes
<jdstrand> spreadsheet*
<asac> ogra_: ack notification retrieved and processed
<ogra_> asac, 50% of the vivid image failures are fixed ... thanks to adam ... i'll do the other half tomorrow
<asac> ogra_: debootstrap probs?
<asac> is there a tracking bug?
 * asac thinks not
<ogra_> yeah, these are fixed
<ogra_> nope
<ogra_> they were builder related
<asac> ogra_: what other failures do we have now?
<asac> ah, image building?
<ogra_> yes
<asac> or ppas etc.?
<asac> ogra_: just touch or all images?
<asac> uknow?
<ogra_> next bit is to find a way to make livecd-rootfs find that it is on rtm and switch some configs back and forth
<ogra_> just touch armhf
<ogra_> well, all armhf actually
 * asac impatient while unity spinner is spinning on first boot after upgrade
<ogra_> well, it crashed immediately for me
<ogra_> after sim pin and pin entering
<asac> hmm. did i enter the pin?
<ogra_> asac, since we use a hardcodded /etc/passwd in touch newly added users break the build ... i need to find a way to conditionally add all the new systemd users when building o vivid
<asac> i think the fact that i cant remember that i entered the pin means that i didnt get that far
<asac> but *shrug&
<asac> -rw-r-----  1 phablet  whoopsie    11295 Oct 28 22:00 _usr_lib_arm-linux-gnueabihf_ubuntu-app-launch_desktop-hook.32011.crash
<ogra_> asac, thats "normal"
<ogra_> non issue
<ogra_> (recoverable error about a duplicated icon entry)
<asac> we won't try to fix that?
<asac> ok phone is running
<asac> i dont see a unity crash in /var/crash though
<asac> it just took ages and came up
<ogra_> lucky you
<asac> guess because of the crash file getting dumped above?
<ogra_> yeah
<asac> ogra_: you say it will happen if i reboot?
<ogra_> apport running
<ogra_> asac, for me it happens always on first boto after OTA
<ogra_> *boot
<asac> maybe it crashes without a .crash?
<ogra_> nah
<asac> i swear it took very very long to boot
<ogra_> i have plenty of crash files
<asac> ok
 * asac reboots phone and sees what happens in /var/crash
<asac> who is working on the app scope still being empty?
 * ogra_ forgot who, but someone is 
<ogra_> thostr_ perhaps ... iirc he was in the dicussion this morning
<pmcgowan> asac, it was marcus I believe
<ogra_> oh, right
<asac> ok pinged the bug
<asac> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1382039
<ubot5> Ubuntu bug 1382039 in qtmir (Ubuntu) "[TOPBLOCKER] Apps scope empty on boot" [Critical,Triaged]
<asac> seems the bug suggests its all on tedg :)
<ogra_> luckily the workaround is just a down-swipe away :)
<asac> lets see what folks say
<ogra_> you want votes ?
 * tedg perks up
<asac> doesnt give me much sleep that there is a workaround :)
<asac> ogra_: votes for what?
<asac> that this needs fixing? :P
<ogra_> <asac> lets see what folks say
<asac> yeah, what they say who needs to do what to get this fixed
<ogra_> i thought if tedg needs to fix it :)
<asac> hehe
<tedg> Oh, it's fixed in silo, we just need Saviq to land it :-)
<asac> thanks. keep the bug posted on such great progress :P
<ogra_> damn ... i was hoping i could get some bribes out of that :)
<asac> heh
 * ogra_ likes that voting idea
<asac> guess depends on how many votes you have
<asac> think we could give folks for flawless landings some virtual cash
<ogra_> i vote for not moving to systemd ... just causes my first headdache in vivid
<asac> they could use that to vote for bugs and folks :)
<sil2100> ogra_: \o/ good to hear about the debootstrap
<ogra_> sil2100, well, livecd-rootfs hacks ahead
<ogra_> its not done
<ogra_> damn
<ogra_> this gets really tricky ... stgrabers hardcoding of passwd|greoup|shadow in the images assumes that you have an md5sum of the original file ... which you only have after one successful build
<slangasek> E: config/hooks/99zz-check-uid-gid.chroot failed (exit non-zero).
<slangasek> SUCCESS!
<ogra_> lol
<ogra_> yeah, it likes to be ironic :)
<slangasek> well I'm very glad the hook did its job ;)
<ogra_> well, i guess i could just take an utopic passwd, add the lines, generate an md5  and hope for the best ...
<ogra_> which will then fail on /etc/group
<ogra_> smells time consuming
<ogra_> hmm, and we would also want it conditional ... only on vivid
<slangasek> but a local build will give you the full environment that triggered the failure, you can then extract both /etc/passwd and /etc/group from it
 * ogra_ doesnt really feel like maintaining livecd-rootfs-rtm instead 
<slangasek> only on vivid> don't we always use the version of livecd-rootfs corresponding to the target release?
<ogra_> yes
<ogra_> but we have only one trunk
<slangasek> ok, so
<ogra_> of which we roll the packages
<slangasek> you're going to have to get used to that
<ogra_> and i dont want to maintain an rtm livecd-rootfs
<slangasek> because releases from trunk to 14.09 are not going to happen
<ogra_> hmm, k
<slangasek> however, as olli_ and I were just discussing, we do expect to be able to use a single source trunk for both vivid development and a "14.10-devel" branch
<ogra_> we tried to keep it in sync in utopic vs rtm
<slangasek> so in that case, yeah, it needs to be clever
<ogra_> that mens it needs multiple md5's
<ogra_> that will become fun over time :)
<slangasek> unfortunately, yes
<slangasek> in practice though I think you only ever need two sets at a time
 * ogra_ adds sqlite to the brannch to be future proof :P 
<slangasek> one for current devel, one for previous stable
<ogra_> yeah, thats true
<ogra_> luckily we roll ... that means no point releases for old images
<slangasek> exactly
<ogra_> so i dont need to look to far back at least
<ogra_> sil2100, you should perhaps enable the ML on https://launchpad.net/~landing-team-trackers
<ogra_> saves you from long CC lists for such mails ;)
<fginther> has anyone tried 134 yet on a krillin? the smoke test jobs all failed "phablet-network"
<sil2100> ogra_: another ML you say? ;)
<ogra_> fginther, runs happily here after a first boto crash of the session
<ogra_> sil2100, well, only for announcements ... not for conversation
<popey> fginther: I'm on 134 here
<fginther> ogra_, popey, thanks
<popey> network works fine
<ogra_> fginther, if the crash happens apport kicks in ...
<fginther> I'll kick them again one at a time
<ogra_> fginther, that might cause everything to behave really slow for a bit ...
<fginther> ogra_, that makes sense
<sil2100> ogra_: so, I wanted to G+ my landing e-mail, but it didn't appear in the archive yet
<sil2100> Been waiting for like ages
<sil2100> Will G+ it later
<sil2100> o/
<ogra_> hmm
 * ogra_ noticed odd behavior of the ML archive before ... 
<kgunn> trainguards: does anyone understand the comment on line 22 wrt u-s-c in ubuntu-rtm/landing-001 ?
<kgunn> e.g. i believe it's still needed
<ribru> kgunn: sorry otp. my guess would be that there's a new sync that will take care of that sync as well. although 'line 67' seems like a stale reference, as line numbers can jump around.
<ribru> kgunn: altough I don't see any other landings that reference u-s-c, so unfortunatley no, i don't know what that comment is supposed to mean, or who wrote it
<kgunn> hmm
<ribru> kgunn: if you're confident it's still needed and there's an approved bug for it, I guess just delete that comment, sounds like a mistake.
#ubuntu-ci-eng 2014-10-29
<AlbertA> ribru: the fix is already in rtm:https://launchpad.net/ubuntu-rtm/14.09/+source/unity-system-compositor/+changelog
<AlbertA> ribru: hence why I put that comment there
<ribru> AlbertA: kgunn: ah yes, the version in rtm does seem to be higher than the one in distro. should I free silo rtm 1 then?
<AlbertA> ribru: yeah
<ribru> hm, the version in rtm is even newer than utopic/vivid, seems like a sync the other way is needed ;-)
<imgbot> === trainguards: RTM IMAGE 135 building (started: 20141029 03:05) ===
<imgbot> === trainguards: RTM IMAGE 135 DONE (finished: 20141029 04:20) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/135.changes ===
 * Mirv frees up 015 (utopic)
<ogra_> err
<Chipaca> asac: if you ever think you should've gotten a notification and didn't, get me the logs :)
<Chipaca> asac: also if you open system settings and see the update downloading, that's why you didn't get the notification -- you get it once it's downloaded
<asac> Chipaca: i got notification this morning; +1 for the feature
 * ogra_ got it too, OTAed and now his phone restarted the session already 4 times in 2h
<ogra_> with really really mild usage ... (two webapps and onyl switching between them at times)
<asac> yeah like 50Kb :)
<brendand> ogra_, sil2100 - i'm trying out silo 13 to see if it helps
<sil2100> brendand: ok, I'll check the media-hub revert in some moments
<ogra_> brendand, ++
<brendand> sil2100, i think our first blocker might be that flight mode is pretty broken
<brendand> davmor2, can you confirm?
<dbarth> good morning
<dbarth> sil2100: for bugs on the whishlist list, should we go straight for an rtm landing? or vivid + sync
<sil2100> Morning
<sil2100> dbarth: are you only targeting rtm landings for now?
<dbarth> sil2100: actually, we'll want vivid + rtm sync for line 79; so forget that, we'll do the normal process
<sil2100> dbarth: you have one trunk right now, right?
<dbarth> besides, silo 8 will stay on the side while oSoMoN lands the new silo
<brendand> davmor2, also location not working
<brendand> hmm i wonder is this silo at fault
<dbarth> sil2100: 2 for webbrowser-app, oSoMoN just created an rtm branch for it
<oSoMoN> sil2100, webbrowser-app is going to diverge between trunk and 14.09, so we now have two branches, and as a consequence, no sync anymore
<sil2100> Right, this is the recommended approach
<davmor2> brendand: right back, what do you want me to check other than flight mode
<brendand> davmor2, location
<brendand> oh wait, location worked in the end
<brendand> but not sure if assisted location is working
<davmor2> brendand: so flightmode just worked fine here what was the issue you saw?
<brendand> davmor2, i turned it off and it still shows the icon and the sim is Offline
<brendand> davmor2, but i have a tvoss silo installed
<davmor2> brendand: http://people.canonical.com/~davmor2/flight-mode.png http://people.canonical.com/~davmor2/flight-mode1.png http://people.canonical.com/~davmor2/flight-mode2.png
<brendand> Mirv, can i request that if you or lorne are planning to do manual testing on silo 22, can you ping me beforehand?
<Saviq> sil2100, ogra_, better late than never, congratz!
<ogra_> Saviq, thanks !
<davmor2> brendand: location is working here too, although it did take longer than normal
<davmor2> brendand: took about 10 seconds rather than the 5-7 it normally takes
<popey> Mirv: when you have a moment could you please upload http://s-jenkins.ubuntu-ci:8080/job/sudoku-app-click/lastSuccessfulBuild/artifact/generic-click-builder-utopic-armhf/output/com.ubuntu.sudoku_1.1.312_all.click to the store?
<brendand> davmor2, does indicator-network show all the networks you'd expect? mine just shows one
<davmor2> brendand: http://people.canonical.com/~davmor2/network-ind.png
<davmor2> brendand: pretty much what I expect to see
<Mirv> brendand: ok, adding a note to the spreadsheet too. I've done a new build in the PPA, but the code reportedly still needs more fixing so no use to test yet.
<Mirv> popey: done.
<brendand> Saviq, is silo 15 landing today/tomorrow (or hoping to at least)?
<Saviq> brendand, yeah, I'm working on that right now
<Saviq> brendand, I need to verify one thing and rebuild to be sure and will start testing
<brendand> Saviq, will you test it or someone else?
<Saviq> but bzr's crapping out on me today...
<popey> thanks Mirv
<brendand> thostr_, pete-woods - still waiting for instructions on silos 19 and 7. if they aren't going anywhere you should probably free them up
<Saviq> sil2100, hey, ~rtm in the version is now unavoidable?
<sil2100> Saviq: thanks!
<sil2100> Saviq: yeah, basically yes
<Saviq> sil2100, ok, /me retargets the silo to vivid then...
<sil2100> Saviq: so, last time we ended up with many binary packages with the same version but different contents last time
<sil2100> Saviq: which is bad
<Saviq> sil2100, different *source* content or?
<Saviq> sil2100, or different binary content as well?
<sil2100> Saviq: sometimes different source content, sometimes just different binaries (when people were doing source syncs without ~rtm or simply source copies)
<Saviq> sil2100, ok, thought it was ok to have the same source build for both
<sil2100> You need to have a different version then, as the binaries that get generated are basically different
<Saviq> sil2100, yeah understand
<Saviq> sil2100, can you please help me retarget the silo quickly then
<Saviq> sil2100, line 30
<Saviq> sil2100, I'm cleaning the rtm one
<sil2100> Ok, let's clean it then and re-assign (that's the only way right now)
<oSoMoN> sil2100, if I add/remove branches from a silo, IÂ need to reconfigure it, right?
<sil2100> oSoMoN: yes :)
<sil2100> Saviq: ok, having problems with jenkins right now
<Saviq> sil2100, cleaned
<Saviq> sil2100, ok, please let me know when ready
<sil2100> Saviq: I'm trying to re-assign, but I think SSO does some problems again
<Saviq> sil2100, right, try going to https://ci-train.ubuntu.com/job
<Saviq> sil2100, and log in there
<Saviq> sil2100, I had to do that with "reconfigure silo" whenever I was not logged in
<sil2100> I am logged in but some redirects don't seem to work
<Saviq> sil2100, oh :/
<sil2100> Mirv: can you help me out?
<sil2100> Mirv: can you try going to line 30 in the spreadsheet and trying to assign that?
<jdstrand> davmor2: hey, so I was supposed to push rtm silo 3 to rtm, so that cwayne could build the custom tarball so that you could test, but the silo is awaiting qa team signoff
<jdstrand> davmor2: I'm happy to walk through the changes with someone from qa if that would help
<davmor2> jdstrand: I'm testing it now, so far only issue I've hit is that the news scope isn't displaying anything which I would assume would get fixed in the tarball but I could be wrong looking into that now though
<jdstrand> davmor2: ok cool. are there any denials? (this should be unrelated, btw)
<davmor2> jdstrand: there are some I've been tailing syslog, but I'll paste you the log after
<jdstrand> ok
<jdstrand> we aren't really fixing any policy here-- just one for apps that use udm's qml interface
<davmor2> jdstrand: so all the apps that are in the list to test so far have been fine, I need to do the incoming out going calls, but got caught up on why the news scope was blank
 * sil2100 is retrying the silo assignment
<Mirv> sil2100: ok..
<sil2100> Still cannot do that ;/
<sil2100> It doesn't do the POST it seems, doesn't want to redirect me
<sil2100> Mirv: can you try?
<Mirv> sil2100: same here..
<sil2100> Maybe we need help from webops?
<Mirv> sil2100: I've seen similar once before two weeks or ago or so. then I just filled pepare-silo manually.
<sil2100> Will do that then
<pete-woods> trainguards: hi guys! could I get RTM silo 19 totally reconfigured? I've stripped out the non MRs that fix non-RTM bugs now
<sil2100> pete-woods: sure, looking
<boiko> sil2100: can I get row 51 of the spreadsheet changed from rtm to vivid?
<sil2100> pete-woods: reconfigured and switched to tested: no
<sil2100> Please re-build and retest ;)
<pete-woods> yep. all good fun
<pete-woods> sil2100: sorry could you help out with that?
<sil2100> pete-woods: uh, strange, it said it removed that
<sil2100> Looking
<pete-woods> thanks :)
<sil2100> pete-woods: ok, should be good now, but I think something is b0rken in CI Train then ;)
 * sil2100 goes prepare lunch o/
<abeato> sil2100, Mirv I need a silo for line 73
<abeato> gst-plugins-bad
<Mirv> abeato: ok
<abeato> Mirv, thanks
<boiko> trainguards: can I get row 51 switched from rtm to vivid? I have an rtm silo assigned already
<psivaa_> ogra_: for health-check tests to run we think psutil is needed in the image: http://dashboard.ubuntu-ci:8080/smokeng/utopic/touch_stable/krillin/135:20141029:20141028-3ca60be/640/health-check/224356/
<psivaa_> ogra_: any chance that it was removed along with autopilot
<psivaa_> ?
<ogra_> psivaa_, where did that come from before ?
<ogra_> ah, that might be
<ogra_> cant you just install it in the setup phase of health-check ?
<Mirv> boiko: it'd mean the PPA rtm-026 would be emptied? (it can't be converted on the fly)
<psivaa_> ogra_: we could if that's not needed by anything else
<psivaa_> and yes it does not look like being needed
<dbarth> trainguards: ping, can we get a silo for line 79
<seb128> bah, unity8 segfault while replying to sms using the indicator
<ogra_> i doubt it is ... we dont really support python programming for app devs ... and system bits should properly define a dependency
<ogra_> seb128, yeah, all the time currently :(
<seb128> ogra_, is anyone working on that?
<seb128> Saviq?
<ogra_> seb128, yeah, indeed :)
<Saviq> seb128, got .crash?
<seb128> Saviq, maybe, apport still busy doing its thing
<boiko> Mirv: yep
<seb128> shrug, unity8 respawned but I started the messaging app and it's spinning endlessly now
<boiko> Mirv: I will land this stuff only on vivid, and check with bfiller what is worth adding to rtm's wishlist
<ogra_> seb128, yes
<Saviq> seb128, that might be because the app was left around
<ogra_> seb128, apps are not killed along with the session
<Saviq> seb128, close and launch again
<ogra_> seb128, kill it once and it will work again
<Mirv> dbarth: done
<Mirv> boiko: ok!
<dbarth> thanks
<boiko> Mirv: thanks!
<seb128> ogra_, Saviq: thanks
<seb128> oh, another fallout/fail
<seb128> unity respawned, I opened the indicator and the message was still there, and I replied inline
<seb128> which acted like that worked
<seb128> but apparently it didn't, the message is not in the log nor counted on the lock screen stats
<ogra_> and didnt because the messaging app was stuck in bg
<Saviq> sil2100, getting the redirect issue when trying to reconfigure, do you have a solution?
<seb128> well, isn't that done by a service?
<ogra_> that service is called unity8
<ogra_> (managing apps)
<seb128> no, sending sms
<seb128> I though telephony-service was doing that
<ogra_> oh, yeah
<seb128> e.g that the feature was not relying on the app to run
<ogra_> but if the messaging app held that hostage ...
<seb128> k
<seb128> oh, another fail
<ogra_> lol
<seb128> replying from the messaging menu, it asks me what sim to use
<ogra_> stop that !
<seb128> SIM2 SIM1
<seb128> or I only have one sim in that phone
<ogra_> iirc i heard about a bbug for that one
<seb128> whose issue is that?
<dbarth> Mirv: of note, oxide is still building in the phablet ppa, but i'll need a binary copy later in the day to silo 15 btw
<ogra_> bfiller, ^^^wasnt there a bug for the SIM1/2 selection popup if you only have one SIM ?
<seb128> Saviq, no dump no :-/
<Saviq> :/
<seb128> why the heck is apport failing to collect those?
<seb128> SegvAnalysis: Skipped: missing required field "Disassembly"
<seb128> bah
<ogra_> funny, i definitely have a bunch of .crash files for unity8
<seb128> I do
<ogra_> and it gets properly updated all the time
<seb128> they just are 100k and without gdb dump
<seb128> so they are useless
<ogra_> errors.u.c should do the processing on a retracer, no ?
<seb128> no, they don't have the dump
<ogra_> weird
<seb128> nothing that can be used for retracing
<ogra_> https://errors.ubuntu.com/bucket/?id=/usr/bin/unity8%3A6%3A__assert_fail_base%3A__GI___assert_fail%3A__GI___pthread_mutex_lock%3A__gthread_mutex_lock%3Astd%3A%3Amutex%3A%3Alock
<ogra_> thats definitely one of mine
<seb128> not that weird, apport doesn't collect those if the dump is larger than some % of the free memory
<seb128> so it depends of your free memory
<ogra_> ah
<dbarth> trainguards, i have line 80 also ready for a silo
<dbarth> eh, as the queuebot said
<dbarth> i'll prep rtm landing requests targetting backport branches real soon
<seb128> shrug, medi-hub eating 100% cpu now
<seb128> I think I should properly reboot
<seb128> things are weird after unity8 goes down
<ogra_> yep
<ogra_> i always do a reboot then
<Saviq> oh my
<seb128> oh, telephony-service segfaulted 10 minutes ago
<seb128> could be one of the issues with the replying from menu weirdness
<Saviq> I think I exceeded available size of the silo POST header for reconfigure
<Saviq> sil2100, â
<Saviq> sil2100, getting 413 when trying to reconf silo 5
<Saviq> which suggests to me the amount of data I'm trying to pass through is too much?
<jdstrand> cwayne: davmor2 tells me the silo passed. shall I push now?
<cwayne> jdstrand: please
<cwayne> ogra_: once apparmor-easyprof-ubuntu gets into the archive can we kick a build? we need it to land a new custom tar
<ogra_> Saviq, exceeded the 512 branches limit for a single landing ? :)
<Saviq> ogra_, that's what I'm worried indeed
<jdstrand> ogra_ (and cwayne): it is apparmor, click-apparmor and apparmor-easyprof-ubuntu
<ogra_> cwayne, if sil2100 doesnt object
<jdstrand> sil2100: ^
<jdstrand> all three :)
 * ogra_ doesnt mind doing as many builds as the builders can bear 
<ogra_> iw would prefer to do them back to back in a constant flow ...
<ogra_> sadly smoketesting wouldnt cope with that
 * jdstrand doesn't care how it goes-- I just want to make sure cwayne has all three when he does his custom tarball
 * Saviq managed to reconfigure... had to copy the data manuall
<Saviq> y
<Mirv> dbarth: ok, to both oxide binary copy and line 80
<Mirv> landing-029 (vivid) for line 80
<jdstrand> can we not reconfigure our silos any more?
<jdstrand> I need rtm 003 reconfigured since the apparmor in there is not the version the silo was configured with (we should not rebuild anything though-- it is all tested. this is just to get past the build step)
<jdstrand> err
<jdstrand> the publish step
<jdstrand> "Can't publish: Some packages in the ppa are not at the latest version
<jdstrand> Please rerun the prepare job, eventually only with that project."
<jdstrand> istr I used to be able to do that ^
<jdstrand> ah, it is in the spreadsheet
<dbarth> trainguards: i think you can also unload silo rtm 020, which won't be accepted for landing this week
<dbarth> trainguards: also, vivid silo 008, the status is really: in testing, not stuck in publishing state
<Mirv> jdstrand: publishing worked now . I think build with watch_only alone would have been enough.
<jdstrand> cwayne: ok, pushed to proposed. they are finding their way now
<jdstrand> Mirv: oh rather than the reconfigure? good to know
<bfiller> brendand: I rebuilt the click for camera-app and updated the link in the spreadsheet (also emailed to you)
<cyphermox> Wellark: poke, you responsible for rtm landing 013?
<dbarth> trainguards: i have verified silo 009, but it seems the spreadsheet is out of sync: i can't mark it tested there, can you help
<asac> sil2100: did we get to the bottom of the unity instability yet?
<dbarth> it should correspond to line 28, for landing in vivid
<dbarth> it is also silo rtm 20 which is verified, but should *not* land on rtm
<cwayne> jdstrand: what version of click-apparmor should be in 14.09?
<Wellark> cyphermox: dunno
<Wellark> cyphermox: lemme check
<cyphermox> Wellark: if you're not touching it then all is fine
<Wellark> cyphermox: tvoss is
<Wellark> but apparently he got ebola or something
<cyphermox> I just want to make sure it doesn't clash with the vivid landing for other dbus-cpp fixes..
<Wellark> cyphermox: other dbus-cpp fixes?
<Wellark> cyphermox: I don't even know how that should relate to them
<cyphermox> http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=dbus
<Wellark> cyphermox: that branch fixes two top blockers
<Wellark> *silo
<Wellark> so we need them in
<cyphermox> you can't build dbus-cpp separately and land one without telling someone about the other
<cyphermox> ie. the second to land needs to get rebuilt
<Wellark> cyphermox: I'm not landing anything
<asac> ChickenCutlass: do you know that folks think that unity crashing might be media-hub related?
<cyphermox> Wellark: that's all I wanted to know, thanks
<Wellark> cyphermox, thostr_: please figure out what to do with rtm-013 silo
<ChickenCutlass> asac: I asked kgunn yesterday and that was not the case
<ChickenCutlass> asac: and if it is.  That is a real problem â how could that happen
<cyphermox> thostr_: how ready are you changes to land? also, have they landed in vivid yet?
<asac> ChickenCutlass: i think its a different thread if media-hb can bring down unity, but still doesnt make it less important
<kgunn> ChickenCutlass: yeah, so theory is notifications are effectively audio clients, so create/kill...causes "left overs" to hang around on dbus
<thostr_> Wellark: cyphermox: this is tvoss... anyhow, I just started to rebuild as it had a strange build error...
<kgunn> at least the signature matches
<jdstrand> cwayne: click-apparmor 0.2.11.2, apparmor-easyprof-ubuntu 1.2.38 and apparmor 2.8.96~2652-0ubuntu5.3
<kgunn> for a fix that is comming from tvoss
<ChickenCutlass> kgunn: asac  so that is not media-hub.  That is prob the sbud client
<ChickenCutlass> right
<ChickenCutlass> ok
<cyphermox> thostr_: so you're not driving the landing right now, just rebuilding out of interest?
<kgunn> ChickenCutlass: yeah...the bug currently reflects this theory/thinking
<jdstrand> cwayne: your custom tarball will include the 'touch -t' change on /var/lib/apparmor/profiles/click_*?
<ChickenCutlass> kgunn: ok thanks
<kgunn> ChickenCutlass: people just aren't reading :)
<ChickenCutlass> lol
<thostr_> cyphermox: well, this might be the root cause also for the unity crashes we're seeing... so just trying to help while tvoss is away
<cyphermox> alright
<cyphermox> I think we should possibly look into landing this in vivid first...
<cwayne> jdstrand: yep, it will
<jdstrand> nice
<cwayne> sil2100:  ogra_: so all the bits for apparmor are ready, could we kick a build?
<cyphermox> thostr_: can I ask you what crashes? there's other changes which might help too..
<ogra_> sure ... sil2100 ?
<sil2100> Yeah, sorry guys, had lunch and then UE Live
<sil2100> ogra_, cwayne: looking at the backlog, but I think it's +1
<ogra_> i just want a "yes" :)
<thostr_> cyphermox: it's still the issue of not having a dash
<cyphermox> hum, what bug is that?
<ogra_> sil2100, apparmor needed in image before custom tarball can land
<cyphermox> is there a stack trace on it?
<ogra_> thats what this build is for
<thostr_> cyphermox: https://bugs.launchpad.net/ubuntu/+source/unity-scope-scopes/+bug/1386653
<sil2100> ogra_: yeah, as I thought
<ubot5> Ubuntu bug 1386653 in unity8 (Ubuntu) "Scopes fail to launch when the network stack is not up" [Undecided,Confirmed]
<cyphermox> ah, thanks
<sil2100> dbarth: still having problems setting the silo to tested yes?
<dbarth> sil2100: yeah, i guess so
<dbarth> sil2100: i was trying to clean up the various silos i have around
<dbarth> sil2100: so if we take 020(rtm) and 009(utopic/vivid)
<ogra_> cwayne, sil2100 build triggered
<dbarth> sil2100: i'd like to delete 020(rtm) and land 009
<cwayne> ogra_: thanks
<cwayne> davmor2: so once the build is done, would you still have time for custom test?
<cwayne> there were a few more changes that leaked in, but most are quite trivial
<oSoMoN> dbarth, sil2100: do you remember if a binary copy from the phablet-team PPA (for oxide-qt) is enough, or if a source copy is needed?
<sil2100> dbarth: ok, so delete 20 you say - let me free that up then
<sil2100> And check sil0 009
<oSoMoN> trainguards: can I haz a silo for line 81, please?
<sil2100> oSoMoN: where do you want to land it?
<dbarth> sil2100: yup
<oSoMoN> sil2100, rtm
<dbarth> incidentally, oxide is now finished building in https://launchpad.net/~phablet-team/+archive/ubuntu/ppa/+packages
<davmor2> cwayne: in theory yes, as we are looking to use it to check for issues in the image but it depends how long
<sil2100> oSoMoN: if the phablet-team PPA oxide-qt has been built for utopic then a binary copy to the ubuntu-rtm silo should be enough
<oSoMoN> dbarth, which is why IÂ was asking :)
<dbarth> it was for utopic indeed
<dbarth> nice, more silos ready
<oSoMoN> excellent, a binary copy will save us time (5+ hours to be precise)
<sil2100> dbarth: can you try changing the tested field now?
<dbarth> ok
<dbarth> marked tested, let's see what the bot says
<imgbot> === trainguards: RTM IMAGE 136 building (started: 20141029 15:30) ===
<bdmurray> sil2100: what needs to happen next for fixing bug 1339916 in ubuntu-rtm?
<ubot5> bug 1339916 in whoopsie (Ubuntu RTM) "SystemIdentifier can change between reboots" [High,Triaged] https://launchpad.net/bugs/1339916
<ogra_> bdmurray, do you have a silo already with lxc-android-config in it ?
<sil2100> bdmurray: oh! Ok, let me help out with that landing, I think we forgot you didn't do any landings before :) So, that's a whoopsie upload + something else, right?
<bdmurray> sil2100: yes, a whoopsie sync from utopic and an upload of lxc-android-config
<sil2100> Excellent
<sil2100> Preparing
<sil2100> bdmurray: now we need to upload lxc-android-config
<sil2100> bdmurray: can you check if you can upload to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-009 ?
<bdmurray> sil2100: I don't see the "You can upload packages to this PPA using" message from Launchpad
<sil2100> hmmm... ok, then the easiest way would be for you to provide me a source package for lxc-android-config
<sil2100> And I'll upload
<sil2100> (since I have no power to grant upload powers)
<ogra_> make sure you use the lxc-android-config from rtm as base actually
<ogra_> rtm and utopic diverged
<bdmurray> ogra_: right, you'd pointed me at rtm4 previously
<ogra_> :)
<oSoMoN> sil2100, ribru: can I have a rtm silo for line 81, pretty please?
<Mirv> oSoMoN: ok
<oSoMoN> trainguards: can you please publish silo 4 (vivid) ?
<Mirv> bfiller: can you arrange that the same camera-app being published from rtm-018 is uploaded as .click to the store? (I can also upload, if just given .click url)
<Mirv> oSoMoN: MP not approved
<Mirv> oh, it's "Merged". that should be pretty approved...
<Saviq> ogra_, are there no vivid images yet? ;|
<Saviq> how am I supposed to test anything...
<Mirv> ogra_: hey ogra, were there any vivid images yet? how about questions about whether there are vivid images? ;)
<Mirv> Saviq: he has had around 40 requests in 24h about the topic :)
<Saviq> ogra_, are there no vivid images yet?
<Saviq> 41
<oSoMoN> Mirv, dâoh, IÂ was pretty sure IÂ had removed the MR from the list this morning, sorry about that
<Saviq> ogra_, are there no vivid images yet?
<Saviq> 42
<Saviq> now that's a good number
<oSoMoN> Mirv, can we force the publication, or do IÂ need to manually revert the state of the MR to "approved"Â ?
<Mirv> oSoMoN: we can force, no problem
<oSoMoN> Mirv, excellent, thanks
<oSoMoN> sil2100, Mirv, ribru: can one of you please do the binary copy of oxide-qt from https://launchpad.net/~phablet-team/+archive/ubuntu/ppa/+packages to ubuntu-rtm/landing-015 ?
 * ogra_ throws little paperballs at Saviq and Mirv 
<ogra_> i'm working on it ...
<ogra_> (should be ready later tonight ... no promise that they boot though ... there is a good bunch of systemd services now)
<Mirv> oSoMoN: done. required command line usage.
<oSoMoN> Mirv, thanks!
<ogra_> Saviq, there were build machine issues til late last night ... and today i already spent all day fixing up the build scripts ... but it will still take a while, each iteration of changes takes hours
<ogra_> asac, bug 1387231
<ogra_> :)
<ubot5> bug 1387231 in Ubuntu Clock App "[clock] alarm still rings once it's been deleted" [Undecided,Incomplete] https://launchpad.net/bugs/1387231
<cyphermox> Mirv: hey, I top-approved the merge that wasn't approved yet in ubuntu silo 12
<cjwatson> Not build machine issues as such, I just didn't write the livefs copying script quite right (this was the first cycle we had to do this, since livefs-in-LP was new last cycle) and so the livefs objects had the wrong require_virtualized setting
<brendand> plars, why are terminal and dropping letters still on the krillin dashboard?
<ogra_> cjwatson, yeah, i tried to simplify :)
<cjwatson> I've since fixed the script so that this won't be a problem next time
<ogra_> issues with building on the wrong machine :)
<cjwatson> Yeah
<Mirv> cyphermox: there's the other branch still https://code.launchpad.net/~thomas-voss/dbus-cpp/fix-1361642/+merge/236820
<cyphermox> AGH, people changed it
<cyphermox> this is ridiculous
<ogra_> slap the people
<ogra_> :)
<cyphermox> I'll just scrap that branch and make a new one
<asac> ogra_: thx. commented on it; i dont think it is mine though
<asac> mine is about disabling, not deleting
<asac> deleting helped/worked in the end
<ogra_> cyphermox, see line 55 on eth spreadsheet (and silo 13)
<cyphermox> that was added
<cyphermox> I'm getting tired of this
<cyphermox> Mirv: you can scrap lines 74 and 75
<brendand> kgunn, there is a problem with silo 13 - it seems i can't get out of flight mode once i enable it
<brendand> kgunn, on the bright side it makes the crashes go away!
<kgunn> brendand: sort of good news :)
<ogra_> there is a million of things in that silo
<Mirv> cyphermox: maybe just reuse the silos for the new branches?
<kgunn> a million ?
<ogra_> its like it is its own distro :)
<cyphermox> Mirv: no
<kgunn> ogra_: you talkin' bout silo 13v?
<Mirv> cyphermox: ok. so, freeing up silos landing-012 and rtm-009
<cyphermox> thanks
<ogra_> kgunn, indicators, media-hub, location-service dbus-cpp
<ogra_> kgunn, no, rtm 13
<Mirv> cyphermox: rtm-011, that is...
<kgunn> right
<cyphermox> correct
<ogra_> kgunn, who cares about v silos ... cant test them anyway
<kgunn> ogra_: it was acutally a typo....my thumb spas'd
<kgunn> or is it spazzed
<ogra_> oh, heh
<kgunn> but yeah, that's not a million....but does unblock a lot of criticals
<ogra_> yeah
<dbarth> trainguards: please don't publish silo 029, it needs a rebuild now that silo 9 is landing
<dbarth> trainguards: i may also need to manual help for silo 9 landing (it should really go onto vivid, even if marked as a utopic build)
 * Mirv starts executing a late "do eod" plan
<dobey> dbarth: eh? if for silo 9 you mean row 28 in the spreadsheet, it's built on vivid, not utopic
<Mirv> bfiller: right, the branches were in that rtm landing, so now published + m&c:d plus kicked a new .click build at s-jenkins to build from the now updated trunk. just get someone to upload it to the store when it's ready.
<dbarth> dobey: ah ok, so fine; i'll just wait for it to exit the -proposed pocket
<dbarth> is there something i can do to speed that up? i have another silo to rebuild just after that
<dobey> dbarth: no, that's pretty automated at this point, but can be slow for some packages, waiting on archive builders and publishing. but it should copied to release pocket once it's published in proposed within 30 minutes at most, generally
<dbarth> ok, perfect; thanks
<dobey> at least, that's my understanding of how often the automated pocket copy works for in-development ubuntu series
<imgbot> === trainguards: RTM IMAGE 136 DONE (finished: 20141029 16:35) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/136.changes ===
<davmor2> cwayne: ^
<ogra_> hurry up
<ogra_> where is the tarball ?
<cwayne> built i like 30 mins ago
<dobey> come on debootstrap
<cwayne> should have been imported by now probably, version 1414598646
<oSoMoN> trainguards: it looks like https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-015/+packages is full, and it prevents building packages, can its size be increased?
<Saviq> brendand, can you please confirm that without rtm silo 13 flight mode works fine for you? I don't think the change there could've caused that
<brendand> Saviq, it does work fine for sure
<brendand> Saviq, i'll do another cycle of testing to make sure
<brendand> Saviq, but i've already done two
<Saviq> brendand, ok, I just have seen flight mode trouble all over the place
<brendand> Saviq, well yeah flight mode is troublesome
<brendand> Saviq, this is pretty reproducible for me though
<cwayne> davmor2: looks like import-images hasn't finished yet
<cwayne> oh nm maybe it has, just got an ota
<sil2100> oSoMoN: oh! I think we'll need IS for that...
<oSoMoN> :/
<davmor2> cwayne: no worries, just let me know I'm busy writing a test plan :)
<cwayne> davmor2: i think it's all in now
<cwayne> doing a fresh flash here to check
<oSoMoN> sil2100, can you do the request to IS?
<davmor2> cwayne: right what is the image number so I know I'm on the right one please
<cwayne> davmor2: let me verify it on a fresh flash first so I don't waste your time :)
<cwayne> will get you the image number soon as its done
<ogra_> davmor2, ust be 137
<ogra_> *must
<dbarth> trainguards: can i get a silo for line 82 please; this is an rtm silo for a bug that has now been approved for landing
<ogra_> jdstrand, hmpf ...
<davmor2> cwayne: flashing version 175 does that sound right
<sil2100> oSoMoN: sure
<jdstrand> ogra_: ?
<sil2100> dbarth: ok!
<cwayne> davmor2: yep, just verified it
<oSoMoN> sil2100, thanks!
<davmor2> ogra_: no cwayne 's channel is way ahead when it is released it is the next image on rtm
<ogra_> jdstrand, 5min boot in 137
<jdstrand> that is expected until cwayne's tarball lands
<ogra_> ah
<ogra_> then i'm fine :)
<jdstrand> as discussed here earlier
<cwayne> 13 sec bq screen on -customized :)
<cwayne> jdstrand: Modify: 2013-12-31 11:59:00.000000000 +0000
<cwayne> :)
<ogra_> that sounds better
<jdstrand> ogra_: so, that 5 minute boot time is actually down quite a bit from other times when it had to recompile all the policy, no?
<jdstrand> cwayne: nice :)
<ogra_> jdstrand, i have seen up to 13min, yeah
<jdstrand> right
<jdstrand> that was part of that upload
<sil2100> slangasek, ogra_: so, I think I have generated a list of missing landings for both distros, just need to double check still if the script does it right
<ogra_> well, not boot but only bootlogo
<jdstrand> of course, we want to avoid those even if they are faster then before, hence the coordination with cwayne
<ogra_> yeah, well, i knew it ... just didnt think of it
<sil2100> bzoltan_: any ETA for landing the AP test fix?
<sil2100> We need it in ASAP
<brendand> Saviq, i have a slightly unusual config in that i have two locked sims
<Saviq> brendand, how is that unusual? :)
<Saviq> same here, actually
<ogra_> you guys are so unusual !
<brendand> Saviq, well joc who only has one can't reproduce the same failure with silo 13
<brendand> Saviq, can you?
<Saviq> brendand, testing another silo now
<brendand> Saviq, ok
<slangasek> ogra_: I've got confirmation from asac that we're good to redirect the 'stable' channel to ubuntu-rtm/14.09 now
<ogra_> slangasek, great, i havent had any system-image training so this time stgraber will still have to do it
<slangasek> ogra_: yeah, I just got the rundown from stgraber on how to do it; I'll send an email first
<ogra_> cool
<ogra_> hopefully with the next build i should also have vivid images
<slangasek> john-mcaleely: ^^ this channel name change impacts how we should be flashing the devices going forward, I believe
<ogra_> and the build will now spit the info thats needed for new passwd and friends directly in the log
<john-mcaleely> maybe. depends which channel name... slangasek ^
<ogra_> so you dont need to do a build at how to get the md5 etc
<ogra_> slangasek, be carefule though, i dont think we had krillin in stable before, that might require extra tweaking
<ogra_> (at least adding the arch)
<slangasek> john-mcaleely: the channel name will be 'ubuntu-touch/stable' going forward
<ogra_> rather ubuntu-touch/ubuntu-rtm/stable ?
<ogra_> 'ubuntu-touch/stable' would be "vivid stable"
<cwayne> wouldnt ubuntu-touch/stable be utopic
<ogra_> cwayne, utopic is dead
<ogra_> it is composting already
<sil2100> oSoMoN: bumped :)
<cwayne> right, but wasn't the last released usually what was put in stable
<sil2100> slangasek:
<sil2100> \o/
<ogra_> well, stable should have our last stable image
<ribru> AlbertA: do you know what's happening with silo rtm 10? I can't find it in the spreadsheet.
<cwayne> i.e. stable was trusty all throughout the utopic cycle
<sil2100> slangasek: give us a sign once it's done and I'll include the info in the e-mail
<slangasek> ogra_: no, not ubuntu-rtm/stable because as discussed elsewhere we don't want that name to persist
<oSoMoN> sil2100, awesome, IÂ didnât think it would be that fast, thanks man!
<sil2100> I'll have to update the developer documentation as well though
<ogra_> utopic surely isnt at a quality to become stable
<sil2100> oSoMoN: thanks go to cjwatson, he's always so fast in doing things ;)
<slangasek> ogra_: and no, stable doesn't point to vivid because that's the devel channel that will become "stable" only around OTA-3
<ogra_> slangasek, ok, it just doesnt match the existing channel structure, curious how s-i will handle the delta for this
<slangasek> ogra_: this is a false choice; there's nothing *else* that's more stable
<ogra_> yeah, it is actually the only "stable" channel we have
<ogra_> under rtm we never created a stable one
<AlbertA> ribru; you can release that one
<brendand> Saviq, it's working better now. maybe it was rebuilt since i tried it earlier
<ogra_> slangasek, looking at http://system-image.ubuntu.com/ubuntu-touch/stable/ we should probably consider ripping out all the arches that fell behind though ... manta and  flo are most likely not at the quality level of mako or krillin (and i'm not soure there are QA resources to even test them)
<ogra_> and maguro would even only get you a trusty image ... we should consider obsoleting that imho
<ogra_> thats to far behind already
<bdmurray> which channel do I want to install from to test my rtm whoopsie changes?
<slangasek> bdmurray: ubuntu-touch/ubuntu-rtm/14.09
<ribru> AlbertA: by 'release' do you mean 'free'?
<ribru> AlbertA: as in 'not publish it' ;-)
<slangasek> bdmurray: sorry, I mean ubuntu-touch/ubuntu-rtm/14.09-proposed
<ogra_> bdmurray, rtm-proposed ... see --list-channels in ubuntu-device-flash
<AlbertA> ribru: sorry yes...:)
<bdmurray> okay, I'd chosen the former and it seemed old to me
<ribru> AlbertA: ok thanks
<cwayne> davmor2: ive got to go afk for a bit, ping/email me when testing of custom is done and I'll push the magic button when I return
<cwayne> sil2100: ^
<slangasek> ogra_: right, yes; let's definitely clean up those devices that should no longer be on the channel, but also let's worry about that after this initial switch
<ogra_> yeah
<davmor2> cwayne: will do
<john-mcaleely> um, so ubuntu-touch/stable alias' to what? slangasek
<cwayne> davmor2: thanks man
<slangasek> john-mcaleely: ubuntu-touch/stable will alias to ubuntu-touch/ubuntu-rtm/14.09 for now
<AlbertA> ribru: and rtm silo 001 can also be freed
<john-mcaleely> slangasek, that sounds good
<john-mcaleely> slangasek, let me know when I can try that?
<john-mcaleely> so will we be adding a stable-proposed alias?
<john-mcaleely> (I don't believe there is one today)
<slangasek> john-mcaleely: not planning to add one at the moment, as I assume that nobody needs to track stable-proposed as a thing right now
<john-mcaleely> hrm. I think we need it to test stuff, but I'll defer that to others
<slangasek> john-mcaleely: we need a -proposed channel for testing stuff, but it doesn't necessarily have to be /called/ stable-proposed which would just be an alias
<john-mcaleely> true enough
<ogra_> john-mcaleely, we will never build any images into stable or devel ... the only place where we build them is -proposed ... then they get copied into devel or stable ... so there is no need to have more than actually one proposed channel from which we can populate the others
<ribru> AlbertA: oh yeah. ok done
<ogra_> oooh shiny !!!
<ogra_> https://launchpadlibrarian.net/188621599/buildlog_ubuntu_vivid_armhf_ubuntu-touch_FAILEDTOBUILD.txt.gz
 * ogra_ likes that 
<ogra_> ... now it gives you exact instructions what to do to make the next build not fail at the end of the log :)
<cjwatson> s/crated/created/
<ogra_> bah !
<ogra_> will fix with the next iteration :)
<ribru> Saviq: ok you got rtm 10
<Saviq> ribru, (did you change your name to Ribert?), thanks
<ogra_> Saviq, well, matching the topic :)
<Saviq> ribru, oupsikesy
<Saviq> ribru, don't laugh (or cough... or sneeze... breathing is not really necessary either, is it?)
<ribru> Saviq: A witch turned me into a frog, now I can only say 'ribbit'
<ribru> ribbit ribbit
<sil2100> brendand: sorry, got a bit distracted, but here's the bug for the UITK: https://bugs.launchpad.net/qtmir/+bug/1382414
<ubot5> Ubuntu bug 1382414 in Ubuntu UI Toolkit "New qtmir makes UITK AP tests fail" [Critical,In progress]
 * sil2100 seems to have internet problems again
 * ogra_ sends some cans full of internet to sil2100 
<ogra_> oh ... and a can opener ... in case you dont have one
<sil2100> Yeah, please!
<john-mcaleely> ogra_, I think the time we need 'stable proposed' will be to test ota from previous stable builds to the one we want to release. There other ways we can do that though
<ogra_> john-mcaleely, where would that ota image come from ?
<ogra_> i mean, i guess you would just build it from the rtm archive after you landed some fixes
<john-mcaleely> ogra_, I think it depends on if there have been multiple private builds, and so we need to test what public handsets will see
<ogra_> which will make the image pop out in ubuntu-touch/ubuntu-rtm/devel-proposed ... where you can test
<john-mcaleely> ogra_, to be honest, I'm happy to suck it and see
<ogra_> yeah
<ogra_> we wont have "multiple private builds" of the rootfs
<john-mcaleely> what, no images testing fixes one by one?
<ogra_> you will perhaps have additional changes in custom or device tarballs
<john-mcaleely> which we roll into one build for stable handsets?
<ogra_> but these can also iterate over devel-proposed
<ogra_> and once QAed can be copied into stable
<ogra_> if you have different custom tarballs (unlikely ot ever have different devvice tarballs for the same device in one release) you can indeed have stable-custom-foo
<ogra_> but that would again come out of devel-custom-foo
<ogra_> or devel-custom-foo-proposed
<ogra_> rootfs and device tarballs will always just move forward ... custom might move sideways at tiimes though
<ogra_> grr, in my shiny livecd-rootfs change i forgot the md5 for /etc/group and gshadow :(
<AlbertA2> fginther: we are getting a CI failure for i386 builds: https://jenkins.qa.ubuntu.com/job/mir-android-utopic-i386-build/2297/console
<AlbertA2> fginther: any ideas?
<fginther> AlbertA, looking
<josharenson> fginther, were you, or anyone else, ever able to re-enable the mi-performance-test- job?
<fginther> josharenson, yes it was re-enabled on Monday. The latest runs show results (I think I sent you an email earlier today)
<josharenson> fginther, cool thanks
<fginther> AlbertA2, this is very strange. there are several failures and each appears to mention a different missing package
<sil2100> slangasek: I just got the 'Landing pipeline:' e-mail - wasn't that supposed to be sent out last week? ;)
<sil2100> slangasek: as it mentions the sprint ;)
<sil2100> slangasek: ARGH
<sil2100> slangasek: ok, scratch that
 * sil2100 needs more coffee or a kick in the butt
<slangasek> sil2100: ok - I was gonna say, I didn't send any such mail today ;)
<sil2100> slangasek: yeah, I think I'm braindead today or something
 * ribru -> lunch
<bdmurray> sil2100: so my silo looks good to me. Is there anything I need to do? update the spreadsheet?
<ogra_> bdmurray, test it on a device ... then set the spreadsheet to testing done
<slangasek> john-mcaleely: ubuntu-touch/stable now points to 14.09
<sil2100> bdmurray: if you have tested it on an 14.09 image, then please change the K column to 'Yes (#image_number device your_nick)'
<sil2100> And then it's all up to QA :)
<bdmurray> sil2100: okay, done. thanks for the help!
<sil2100> \o/
<ogra_> yay
 * ogra_ looks forward to eventually finding his error reports by lcicking the button in system-settings
<thomi> licking the button? O.0
<dobey> it's just like OS X
<sergiusens> slangasek: hah, the stable channel is finally useful!
<fginther> AlbertA2, I noticed that all the failures are coming from the same node (although it also had plenty of successful builds as well), so as a first step I've disabled that node.
<sergiusens> u-d-f's default too
<AlbertA2> fginther: ack
<fginther> AlbertA2, also, debootstrap which the mir cross compile uses does not appear to have any built-in retry mechanism. So if the apt repository (ports.ubuntu.com in this case) is ever unreliable, the entire bootstrap will fail. The cross-compile scripts should take this into account
<ogra_> sergiusens, oh, we still default to that ?
<ogra_> nice
<slangasek> ogra_: I guess you have a handle on livecd-rootfs, nothing you need help with?
<ogra_> slangasek, well, if this upload has landed and the nnext image fails i will
<cwayne> davmor2: hows custom lookin?
<ogra_> slangasek, i *belive* it is fixed with this last upload ...
<slangasek> ok
<sil2100> cwayne: it might take some time still I suppose, as davmor2 is performing some extra testing there
<AlbertA2> fginther: aah.....I'll check with the team...why are we even calling cross_compile_chroot for CI - that doesn't seem right...
<cwayne> sil2100: right, i wasnt trying to rush you guys, just wanted to check in and see if there's anything i needed to fix :)
<oSoMoN> trainguards: Iâll need your help reconfiguring ubuntu-rtm/landing-015, IÂ added a MR for webbrowser-app and the silo wonât let me reconfigure it myself
<davmor2> cwayne: tea got in the way too :)
<cwayne> davmor2: :)
<oSoMoN> trainguards, sil2100, ribru, anyone?
<sil2100> oSoMoN: hey!
<sil2100> oSoMoN: so, let me try helping you inbetween :)
<oSoMoN> sil2100, sorry if IÂ sound insistent, trying to land urgent stuffâ¦ :/
<sil2100> oSoMoN: no worries! ribru is on lunch so he would only take care of your request a bit later
<sil2100> oSoMoN: reconfiguring :)
<ribru> just back!
<ribru> sil2100: thanks
<oSoMoN> sil2100, thanks!
 * sil2100 goes off to exercise a bit
<sil2100> oSoMoN: yw!
<sil2100> Sorry it took so long ;)
<barry> sil2100: if you're still around, i *finally* have an mp for si 2.5.1-0u1.  i'm going to add it to the spreadsheet for ubuntu and we'll go from there
<barry> sil2100: i'm going to try to get this into tomorrow's image if i can get at least one other person to test it
<ribru> barry: I'm around to assign and help test, just need some testing instructions
<barry> ribru: awesome, thanks.  just got assigned silo ubuntu/landing-004.  i'll ping you for testing when the ppa build finishes
<barry> ribru: the row has a link to the test plan
<barry> ribru: Test G will be the one specifically addressing this bug (but the other tests are good to ensure no regressions)
<ribru> barry: cool
<alecu> thanks!
<barry> aw crap
<barry> yeah yeah, thanks queuebot
<ribru> barry: weird error, I guess it's a side effect of your non-standard versioning scheme ;-)
<barry> ribru: yeah ;)  i deleted the tag on the mp branch and hit rebuild
<barry> seems to be making progress now
<ribru> barry: ugh, how do I reboot into the bootloader? 'fastboot reboot-bootloader' just says 'waiting for device' (even though adb shell works), and no amount of power+volume up/down fiddling seems to want to do it for me today
<barry> ribru: gosh, i'm not sure any more
<ribru> between my vacation and broken ribs, it's been a couple weeks since I've updated one of these, wanted to start with a fresh flash ;-)
<barry> yeah, that's a good idea.  does ubuntu-device-flash not work for you?
<ribru> barry: with --wipe and --bootstrap it says 'waiting to be in bootloader'
<ribru> ...
<ribru> but when I specify --device it magically starts working
<ribru> even with wipe and bootstrap. huh
<barry> yay
<barry> wow, the silo actually built on the first try
<ribru> barry: uh, flashing didn't seem to work. seems like it just downloaded the image and stopped.
<barry> ribru: i'm trying it now with my krillin.  will let you know how it goes
<ribru> barry: seems to actually flash if I don't use wipe and bootstrap. bah
<barry> weird
<ribru> barry: oh wow, just reading test G, that sounds intense ;-)
<barry> ribru: yeah ;)  took a bit of work to get the staging server up on stgraber's domain, since we don't have an official one
<barry> ribru: i'm flashing right now w/o --wipe or --bootstrap
<ribru> argh wtf! The flash said it was pushing the image to my device, and then it rebooted to recovery to flash etc, now system settings reports I'm running an image from september. bah
<barry> ribru: are you on channel ubuntu-touch/ubuntu-rtm/14.09-proposed?
<barry> (i suppose i should update that instruction
<barry> )
<ribru> barry: apparently not, but that's the channel I tried to flash
<ogra_> \o/
<ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/
<ogra_> slangasek, so we have a vivid ...
<pmcgowan> nice
<ogra_> now i wonder if we can just bend the devel channel over to this and system-image will cope on devices
<ogra_> (obviously once s-i has imported it)
<slangasek> excellent
<ogra_> well, curious if it will boot :)
<slangasek> I guess you mean the devel-proposed channel, since you need a proper image promotion to get it onto devel :)
<ogra_> do you knwo if the systemd daemons we ship will stay no-op's ?
<ogra_> heh. indeed i meant -proposed
<slangasek> I don't know anything about the delta, which systemd daemons do you mean?
<ogra_> well, the whole breakage was caused by systemd-timedated and three other daemons we ship in minimal now adding their users to /etc/passwd
<ogra_> i wonder if they just stay on the image and dont start or if they actually interfere
<slangasek> ah; yes, those certainly aren't started via upstart
<slangasek> systemd-timedated is a dbus service anyway
<ogra_> ah
<ogra_> well, then i assume it wll just work like utopic ...
<ogra_> just with extra cruft on the fs
<ogra_> (i doubt i will stay awake long enough to actually test one of these images tonight)
<sil2100> o/
<slangasek> ogra_: systemd-timedated itself isn't new, only the user is new
<ogra_> ah
 * ogra_ mailed about image status and will fall dead now 
 * asac hugs ogra for vidid images
<ogra_> :)
<asac> sleep well!
<ogra_> oh i will !
<ogra_> i'm seriously behind on sleep :)
<barry> slangasek: ping
<asac> ogra_: go for it. wanted to ask if i shall try image, but lets just tru ...
<slangasek> barry: hi
<asac> ... together tomorrow morning!!
<asac> cu
<asac> try
<ogra_> asac, well, in ~30-45min you should see something in the channel
<barry> slangasek: hi.  interesting possible observation, re: the udm timeouts we see during ppa builds
<asac> ogra_: yeah, dont worry. just go off!!!!!
<ogra_> asac, if you feel brave ;)
 * asac sends an electric outage to ogras home
<ogra_> haha, yeah
<barry> slangasek: we just build s-i 2.5.1 in a vivid ppa.  it finished quickly, and no timeouts on first try
<barry> slangasek: then ribru source copied it to rtm silo, which is running more slowly, and i *suspect* (tho it hasn't happened yet) that it will timeout
<slangasek> mm, so
<slangasek> how does that help us? :)
<barry> slangasek: what's the difference between vivid ppas and rtm ppas?... :)
<barry> i386 vs amd64
<barry> slangasek: it doesn't immediately, but i wonder if udm is crashing on i386
<slangasek> ok
<slangasek> should be reproducible in an i386 chroot?
<barry> slangasek: it's just a thought right now.  let's see how this ppa build finished, and then i'll put this theory on the udm bug
<barry> but yeah
<barry> slangasek: i wonder how much testing udm gets on i386
<slangasek> well, if you can get upgrades working in the emulator, it'll get more
<barry> indeed
<bdmurray> slangasek: do you think I should add bug 1386752 to the RTM wishlist?
<ubot5> bug 1386752 in whoopsie (Ubuntu Utopic) "whoopsie-id is world readable" [High,In progress] https://launchpad.net/bugs/1386752
<slangasek> bdmurray: why is it a problem for the id to be world-readable?
<slangasek> bdmurray: fwiw I think this is ok to defer to post-RTM
<slangasek> even if it's not meant to be world-readable, there won't be many people reading it before OTA-1 :)
<cjwatson> this system-image source copy you mention
<bdmurray> slangasek: It was inconsistent as the dbus call to get the identifier required root.
<cjwatson> that seems to be compounding the problem we identified and discussed with sil2100 at the sprint, of binaries with the same version but different contents between ubuntu and ubuntu-rtm, which is making it difficult for us to produce a new ubuntu-rtm/14.10 branch
<cjwatson> this is going to need discussion with sil2100, I know, we probably aren't all on the same page, but would it be possible to drop 2.5.1-0ubuntu1 from the rtm PPA here and do a 2.5.1-0ubuntu1~rtm or whatever the convention is instead?
<slangasek> oh indeed
<slangasek> barry: ^^
<cjwatson> I know that doesn't really help your specific problem at hand, just noticed it on the way past
<cjwatson> (and I'm off to bed)
<ribru> slangasek: in this case s-i doesn't follow the citrain versioning conventions so barry will have to manually mangle the version himself.
<slangasek> that's fine; but he has to do it
<slangasek> and not have two separate packages floating around with the same version number but different binary contents :)
<cjwatson> the plan is to modify LP to prevent this kind of thing happening by accident, but we were only hatching this plan at the tail-end of the sprint and so haven't put it into effect yet
<barry> sil2100 and i discussed this yesterday. i actually did have an rtm version number and was going to only go to rtm-14.09 but he talked me into going vivid then sync'ing with the same version number
<ribru> barry: I guess best to manually upload to the PPA. we'll treat it like a source release (as opposed to a silo sync or an MP build)
<cjwatson> barry: a binary sync would have been fine, but not a source sync
<cjwatson> barry: maybe sil2100 meant the former?
<cjwatson> which I think would have been reasonable here given that it's python
<ribru> cjwatson: the funny thing is I specifically told citrain to do a binary sync here but for some reason the package rebuilt anyway. I blame the train itself for being stupid.
<cjwatson> we have to be a bit careful about binary syncs from vivid to ubuntu-rtm/14.09, but they're certainly possible if the dependencies aren't too complex/whatever
<barry> also, ribru thought he did do a binary sync, so neither of us are sure why it ended up doing a source sync
<cjwatson> ribru: curious
<cjwatson> well, I'm not investigating now, trying to do better about being off the clock in the evenings :)
<cjwatson> night
<ribru> barry: cjwatson: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-016-1-build/50/parameters/ here is the proof that I did a "binary copy" note that REBUILD_SOURCES_FOR_SYNC is unchecked.
<ribru> cjwatson: goodnight
<barry> cjwatson: gn
<cjwatson> yeah, was intentionally not saying "oh hai ribru you broke it" because I hadn't investigated the situation at hand at all :)
<brendand> plars, fginther - i filed this just now - https://bugs.launchpad.net/ubuntu-test-cases/+bug/1387391 it's probably a dupe i guess, but it's something i think we need to look at so i just wanted to make sure - didn't find anything similar in ubuntu-test-cases
<ubot5> Ubuntu bug 1387391 in Ubuntu Test Cases "Need a way to customise tests per device/channel" [Undecided,New]
<barry> cjwatson, slangasek btw, if it will make others lives easier, i'll change my workflow or whatever for uploading new s-i versions
<barry> but i'm really not sure what The Right Thing To Do Is, as i get somewhat conflicting recommendations
<slangasek> ribru, barry: well, for the moment the takeaway is "it was a source sync, that shouldn't have happened, dump the silo and try again"
<barry> slangasek: wfm.  ribru can you do that?
<slangasek> barry: it can be a binary sync if we know that it's safe, but we're generally telling people not to do that at all because it takes a core-dev to know that it's safe
<slangasek> and if binary syncing isn't working right, that's something else
<barry> yeah
<slangasek> barry: so you can do a sourceful upload with a ~rtm version number, or you and ribru can try to work out what went wrong with the binary sync... but the latter would need a different silo now, since you can't reuse that version number in that particular ppa :)
<barry> slangasek: for now, si in vivid will be the same as in rtm, but once rtm happens, i'm hoping to start landing new features, so they will diverge (and i have a new upstream branch just for rtm)
<slangasek> path of least resistance: source upload with manual mangling of version number
<barry> or maybe i was talking to ogra_, but anyway the same applies
<barry> slangasek: so, you're saying 2.5.1-0ubuntu1~rtm1 sourceful upload to the existing ppa?  (that'll sort lower than the current in flight package though)
<slangasek> yes
<barry> ribru: do you want to retry a binary copy for giggles?  and if it doesn't work again, then i can prep a source package
<barry> slangasek: wfm
<slangasek> can't retry a binary copy without allocating a separate silo
<barry> oh right
<fginther> brendand, Thanks for the bug description and example, I've added it to the list of things to work on
<slangasek> version numbers are launchpad's diamonds
<slangasek> (they're forever)
<barry> slangasek: that was actually my first suggested version number for rtm.  i wasn't even going to upload to vivid ;)
<barry> slangasek: yeah, i've been bitten by that too many times before
<barry> ribru: let me know your preference for proceeding
<barry> slangasek: but i guess either way, this might not make it into tomorrow's image, unless i can get ribru and maybe one other person (hint, hint) to test the new version
<ribru> barry: I guess easiest if you can bump the version number and ~rtm it for the same silo. I'm not really inclined to try the binary sync again since it's discouraged anyway (I want to just rip all that code out, I don't want to debug it)
<ribru> barry: or if you really need that version number I guess we have to toss the silo and start a fresh one either way
<ribru> barry: fwiw, test G passed perfectly for me.
<barry> ribru: the version number is really unimportant
<barry> ribru: awesome, thanks!
<barry> i think i'll just prep a new ~rtm version for the silo and do a sourceful upload
<ribru> barry: you're welcome. yeah I guess upload version as 0ubuntu2~rtm then
<barry> ribru: that'll sort higher than the vivid version.  not sure if that's a problem or not, but frankly i don't even care if 2.5.1 is published to vivid or not
<sergiusens> slangasek: barry if you ask nicely and own the ppa, webops can make versions not be the tough diamonds we thought they are... (not saying we should do that here though)
<ribru> barry: yeah but if you just do 0ubuntu1~rtm it won't be accepted as a newer package, right? so you have to do 0ubuntu2 just to get the package even accepted in the PPA.
<barry> sergiusens: for my own ppas in the past i've just blown the whole ppa away.  it *does* make for more inconvenient testing, but it's not that big of a deal
<barry> ribru: i think i can delete the -0ubuntu1 version
<ribru> barry: also are you in the team to be able to do uploads to silo PPAs? if not ask slangasek to add you
<barry> worth a try and if it fails i'll bump it
<barry> ribru: hmm, i may not be
<slangasek> ribru, barry: remove the existing package from the ppa first, upload the new version with a version number that sorts earlier
<barry> slangasek: yep.  of course: "Package deletion can take some time before the packages are actually removed. See more about deleting a package."
<ribru> ok package is deleted
<slangasek> barry: you are a member (~ci-train-ppa-service)
<ribru> barry: my experience lately is that deletion is actually pretty quick despite the warning. less than a couple minutes
<slangasek> I assume wgrant has optimized launchpad for deletion in the face of librarian pressure ;-)
<barry> slangasek, ribru: cool.  let me build the rtm srcpkg and try an upload.  will follow up soon
<ribru> ok, good time for me to make a smoothie ;-)
<barry> hang on a sec.  i won't be able to upload an UNRELEASED right?  should that be ubuntu-rtm/14.09 ?
<barry> slangasek, ribru ^^
<slangasek> barry: '14.09', then upload to the right ppa target
<barry> slangasek: ack
<barry> lalalala: bad-distribution-in-changes-file 14.09 :)
<davmor2> cwayne: so everything is looking okay on the tarball
<barry> slangasek: Unable to find distroseries: 14.09
<cwayne> davmor2: \o/
<barry> rejected
<cwayne> davmor2: so do I push it? or do I need to wait for sil?
<davmor2> ribru: are you spin up any images right now?
<slangasek> barry: rejected from where?
<barry> slangasek: soyuz
<slangasek> barry: 14.09 is definitely the right syntax; what was your upload target?
<barry> slangasek: dput ppa:ci-train-ppa-service/landing-016 system-image_2.5.1-0ubuntu1~rtm1_source.changes
<slangasek> barry: yeah, that's the wrong target :)
<slangasek> barry: you need 'ubuntu-rtm/' in the middle of that ppa name
<slangasek> otherwise it's uploading to the ubuntu ppa of the same name
<barry> oh, i guess the ppa page lies then ;)
<barry> slangasek: dput ppa:ci-train-ppa-service/ubuntu-rtm/landing-016 system-image_2.5.1-0ubuntu1~rtm1_source.changes  ...?
<slangasek> yes
<barry> cool.  i blame launchpad :)
<barry> oh ffs.  File system-image_2.5.1.orig.tar.gz already exists in Landing PPA 016 (RTM), but uploaded version has different contents.
<barry> i guess i should just dump the silo and try again
<barry> brb
<ribru> heh
<ribru> davmor2: I was just gonna let cron do it, do you need one sooner?
<davmor2> ribru, cwayne: ^ so no images till 3:00am  so hit the button I guess
<ribru> barry: oops ok I'll flush and reassign
<cwayne> davmor2: done
<cwayne> thanks for testing man
<ribru> barry: ok when you get back, pls upload to rtm 4
<barry> ribru: awesome, thanks.  will upload then continue prepping dinner
<ribru> barry: you're welcome!
<ribru> barry: hm, is it supposed to take this long to build? looks like it's still running tests
#ubuntu-ci-eng 2014-10-30
<barry> ribru: yep.  i think that's i386
<barry> ribru: we'll see if it'll succeed.  anyway, i'm going to watch a bit of the world series and check in now and then
<ribru> barry: ok cool. I'm nearing EOD but should be around later if anything comes up
<boiko> trainguards: any idea what this is about: https://ci-train.ubuntu.com/job/ubuntu-landing-026-1-build/12/console ?
* fginther changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: robru broke 3 ribs
<ribru> boiko: no, I've seen that before but haven't been able to figure it out yet. I think the package was uploaded in the PPA though, so if you just do a WATCH_ONLY it should be fine.
<ribru> barry: just noticed your build failed with a bunch of timeouts, so I retried it
<imgbot> === trainguards: RTM IMAGE 138 building (started: 20141030 03:05) ===
<popey> You know you need to go to bed when... "imgbot says..."
<barry> ribru: hey, still around?  thanks for the retry.  looks like it's now built
<Mirv> mornings
<ribru> barry: bedtime soon ;-) need something?
<Mirv> sigh for adding new Qt private header users
<Mirv> sil2100: ^ so Zoltan is on holiday, I made a branch and preparing for landing. I just don't have any history on the topic other than I remember he mentioned it during the spring and there is a "stupidly easy fix". at least it affects only tests, so maybe if UITK AP is fine it could be considered for releasing...
 * sil2100 looks at the change
<sil2100> Mirv: yeah, I think it's reasonable to only check autopilot results for UITK in this case
<Mirv> that's the comment #5 from dandrada on bug #1382414
<ubot5> bug 1382414 in Ubuntu UI Toolkit "New qtmir makes UITK AP tests fail" [Critical,In progress] https://launchpad.net/bugs/1382414
<sil2100> But I already remember a branch from ricmm I think
<Mirv> sil2100: but but, are "our" blockers approved by product team, I was wondering?
<Mirv> sil2100: there's nothing attached to the bug report though.
<Mirv> no UITK branches at https://code.launchpad.net/~ricmm/
<sil2100> Mirv: infrastructure blockers are a bit different, but I'll make sure PT is aware
<Mirv> sil2100: ok, thanks
<ogra_> hmpf ... seems we have lockfile issues on the image builder
<davmor2> Morning all
<sil2100> Morning
<sil2100> davmor2: good to hear that currently we have just that unity8 blocker :)
<sil2100> + the autopilot one I personally added
<ogra_> hmm, i just got an SMS with no sound
<ogra_> oh, volume was turned down ...
<ogra_> (turning it up again restarted my session though)
<davmor2> ogra_: haha yeah that fix really needs to land :)
<ogra_> davmor2, well, if we only could build any images now :P
<ogra_> ProtocolError: <ProtocolError for iso.qa.ubuntu.com/xmlrpc.php: 403 Forbidden
<ogra_> for all images ... yay
<davmor2> ogra_: man you developers you are set on destroying the world with your code ;)
<ogra_> lol
<ogra_> this time it is datacenter admins, not developers
<sil2100> yay for lockfiles
<davmor2> ogra_: yeah cause there is no code stored in a datacenter right.......wait a minute, you're trying to trick me ;)
<ogra_> :P
<ogra_> woah
<ogra_> my session *didnt* restart
 * ogra_ just noticed the phone is still on the spinner
 * ogra_ reboots hard
<sil2100> o_O
<brendand> ogra_, who's the best person to ask how to deal with the idle level issue?
<brendand> ogra_, assuming it's being calculated correctly
<ogra_> brendand, i guess plars has dug deepest into it from a test side ... or do you mean for deciding about raising the value ?
<brendand> ogra_, yeah - if the test is telling the truth then we either need to fix something in the system to make it better, or raise the value
<brendand> ogra_, do we even know if one component is at fault? or it could be many
<ogra_> brendand, well, i think we should invest a day and go through all topbefore/after logs and grep out the top consumers to get some heuristics
<ogra_> and on that base make a decision
<ogra_> (assuming the numbers are right)
<brendand> ogra_, http://dev-jenkins.ubuntu-ci:8080/job/utopic-touch_stable-krillin-smoke-daily/433/artifact/clientlogs/sudoku_app/topbefore.log/*view*/
<brendand> ogra_, unity8-dash - 81.8%!
<ogra_> yeah
<ogra_> the question is for how many iterations
<brendand> ogra_, nearby 64, news 34
<ogra_> remember, each top loop is only a snapshot
<ogra_> brendand, we should grep the first 5 lines out of each loop, collect the top consumers from that and take the average ...
<ogra_> if we do that for a bunch of runs we should find the bad guy
<ogra_> (thats why i said we should invest a day, i meant that literally, it will take time to collect)
<brendand> ogra_, hmm yeah. it's only that high for the last couple of iterations
<ogra_> and we should compare to mako
<ogra_> if the same process does the same there but simply stelles faster then i guess we cant do much about it (except make the app faster or some such)
<ogra_> *settles
<ogra_> in that case i would vote for adjusting the value (but also let the app owner know)
<ogra_> wget -O- -q http://dev-jenkins.ubuntu-ci:8080/job/utopic-touch_stable-krillin-smoke-daily/433/artifact/clientlogs/sudoku_app/topbefore.log/*view*/|grep PID -A3|grep -v ^PID
<ogra_> brendand, that gives us the three top consumers of each run
<brendand> ogra_, is mako ok?
<davmor2> hmmmm I guess this is a bad thing right 15138 phablet   20   0  275220  48168  25044 S  95.5  4.9  17:55.60 system-set+
<ogra_> how do you mean ok ?
<brendand> ogra_, i'm wondering is the negative value in this run being ignored? http://dashboard.ubuntu-ci:8080/smokeng/utopic/touch_stable/krillin/136:20141029.1:20141028-3ca60be/643/sudoku_app/225287/
<brendand> ogra_, by ok i mean do settle tests fail there or not?
<ogra_> it think they do but sinificantly less
<ogra_> ah, wait
<ogra_> wget -O- -q http://dev-jenkins.ubuntu-ci:8080/job/utopic-touch_stable-krillin-smoke-daily/433/artifact/clientlogs/sudoku_app/topbefore.log/*view*/|grep -v "top -c -b -d 6 -n 5"| grep PID -A3|grep -v ^PID
<ogra_> this is a better command ... filterin out top itself first
<ogra_> wget -O- -q http://dev-jenkins.ubuntu-ci:8080/job/utopic-touch_stable-krillin-smoke-daily/433/artifact/clientlogs/sudoku_app/topbefore.log/*view*/|grep -v "top -c -b -d 6 -n 5"| grep PID -A3|grep -v ^PID|cut -d' ' -f9,12
<ogra_> and that gives us a nicer formatting
 * Saviq split up the unity8 mega silo, only includes what's already in rtm now
<ogra_> (cpu percentage and processname)
<ogra_> brendand, so using that line above over a bunch of topbefore/topafter logs should give an impression what is keeping the system busy
 * ogra_ ponders ... 
<ogra_> how about we cut out everything starting with 0.
<psivaa_> brendand: https://code.launchpad.net/~psivaa/ubuntu-test-cases/skip-unity-8-for-utopic/+merge/235791 is a sample of how we skip tests for a certain channel. similar could be done but as you could see it's a little ugly
<brendand> psivaa_, well yeah it is a bit hacky, but if that's the best we can do for now with the system we have
<psivaa_> sil2100: this is what i have for the vivid test setup from plars:
<psivaa_> plars> fginther|away, josepht: so it looks like we might have vivid images in devel-proposed soon, going to try to update stuff tonight but there's no new distro-info-data package yet, so have to hack around that for now
<davmor2> ogra_: if you cut out 1's too that get rid of all the binary ;)
<psivaa_> sil2100: plars is at a conference, i'll ping him about the progress when i get hold of him later
<sil2100> psivaa_: ok, thanks :)
<ogra_> davmor2, lol
<ogra_> brendand, so looking at it with the ablve command (and ignoring the first three runs where the session still settles down) i see dbus-daemon, upowerd and indicator-power being the busy ones ... with an occasional spike of unity8
<ogra_> which makes me think if mako would look different that krillin is simply very chatty with upowerd
<ogra_> keeping the dbus noisy
<ogra_> thats just a guess thogh, we have to compare mako
<cjwatson> ribru: Binary syncs aren't discouraged in any kind of long-term way, and are often still appropriate; the probability of failure is just a bit higher than usual since vivid and 14.09 are diverging a fair bit at the moment.  I'd appreciate you not ripping out that code.
<cjwatson> A package with long build times but uncomplicated and easily-analysed dependencies is still likely to be appropriate for binary syncing.
<brendand> ogra_, i run it on my krillin and nothing seems to ever take more than 2%
<brendand> ogra_, except for unity8 on a couple of occasions
<brendand> ogra_, but it still fails
<sil2100> ogra_: any news on the image builds?
<brendand> ogra_, i think i understand what's going on now
<Saviq> sil2100, can I get silo for row 30 please
<brendand> ogra_, so basically the script wants the system to reach a certain idle level, for some reason krillin can't do that
<brendand> ogra_, spikes shouldn't affect the outcome
<sil2100> Saviq: oh no, is that a new one?
<brendand> ogra_, rather one of the things you mentioned is keeping krillin constantly above that level
 * sil2100 prepares the manual prepare_silo job
<Saviq> sil2100, it is, I needed to split the big one
<brendand> ogra_, the question is whether we can fix that or it's just something we need to accept
<Saviq> sil2100, it was too big to understand issues that we've noticed
<brendand> ogra_, i'm not that knowledgable about these things, but any chance the lower clock speed could make a difference?
<sil2100> Saviq: assigning
<sil2100> Mirv, ogra_, asac, ribru: I guess it's time to draw the line
<sil2100> NOTICE! Landings going on halt!
* sil2100 changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: CI Train on halt! No non-blocker landings accepted until image promotion!
<brendand> sil2100, awwww
<brendand> Mirv, did that camera-app landing make it in?
<Saviq> sil2100, thanks
<brendand> Mirv, it has test fixes that are wanted
<Mirv> brendand: I published it since that was a pre-requirement for newer .click to build, kicked a .click build and asked bfiller to have it uploaded when it's ready. I'm not sure if it made it in, but if not I can also upload it.
<Mirv> it's over here http://s-jenkins.ubuntu-ci:8080/job/camera-app-click/149/
<brendand> Mirv, yeah it would be nice to fix those tests - but i guess landings are frozen?
<Mirv> sil2100: are they ^
<sil2100> Mirv: see topic
<Mirv> oh, topic
<sil2100> :)
 * sil2100 prepares an announcement e-mail
<Wellark> can I have a silo for row 92 please
<Mirv> there are two bugs from the wishlist list and three bugs not there
<Mirv> correction, three bugs from previously accepted rtm critical fixes, two not
* psivaa_ changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: psivaa | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: CI Train on halt! No non-blocker landings accepted until image promotion!
<asac> sil2100: will you send mail on the halts?
<asac> thanks
<asac> or are we happy enough with /topic nowadays
<asac> (could be :))
<brendand> psivaa_, how does ci handle the lock screen?
<brendand> psivaa_, does it disable that completely?
<psivaa_> brendand: that's unlocked for every test suites
<psivaa_> reboot and unlock
<brendand> psivaa_, ah - and what kind of security is set for it? is it passphrase?
<psivaa_> brendand: i think it's u-d-f --password
<brendand> psivaa_, yeah - this is bad
<brendand> psivaa_, there is a huge bug ATM caused by that
<brendand> psivaa_, it could have an unknown impact on our smoke tests
<psivaa_> brendand:  bug caused by using password?
<brendand> psivaa_, any chance it can be changed to pin?
<brendand> psivaa_, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1373985
<ubot5> Ubuntu bug 1373985 in maliit-framework (Ubuntu) "foreground app doesn't get activated after we leave the lock screen" [Undecided,In progress]
<sil2100> asac: yes, just sent one :)
<brendand> psivaa_, it's a maliit bug so doesn't happen with pin
<sil2100> As mentioned above, it was still in the works
<sil2100> brendand, davmor2, ToyKeeper, elopio: just so you remember - no landings besides blocker landings o/
 * sil2100 is still waiting for some info from ogra_ regarding image builds
<psivaa_> brendand: i dont think changing it to pin is difficult, but altering the flashing just to overcome a bug does not seem to be right
<brendand> psivaa_, no far better to fix the bug
<psivaa_> i'm sure i'll be asked a lot of questions when i try to do this change :)
<brendand> sil2100, this bug is causing smoke testing failures too now - and lot's of functional issues - https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1373985
<ubot5> Ubuntu bug 1373985 in maliit-framework (Ubuntu) "foreground app doesn't get activated after we leave the lock screen" [Undecided,In progress]
<brendand> sil2100, would be good to have it on the email
 * sil2100 looks
<ogra_> sil2100, should work again
<ogra_> sil2100, colin removed the isotracker check for the moment
<imgbot> === trainguards: RTM IMAGE 138 DONE (finished: 20141030 11:20) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/138.changes ===
<ogra_> see :)
<popey> You don't have permission to access /~ogra/touch-image-stats/rtm/138.changes on this server.
<ogra_> because it doesnt exist :P
<ogra_> checking
<popey> heh
<mvo_> pardon my ignorance - so the train is on halt, does this also affect click on vivid? i.e. I would like to make a new release soon(ish) of click. but the train on halt means that we also stop vivid images, right?
<asac> i would hope vivid is still flowing :)
<asac> but i might be wrong
<Wellark> what is vivid?
<ogra_> hmm
 * Wellark hides
 * ogra_ doesnt see 1030 at http://cdimage.ubuntu.com/ubuntu-touch/ubuntu-rtm/14.09/daily-preinstalled/
<Wellark> trainguards: I have fix for two top blockers for RTM waiting for a silo and I see plenty of them available for rtm. *wink* *wink* :)
<ogra_> i wonder if there is more fallout from the inccident :/
<Wellark> line 92
<asac> ogra_: seems we can build images again?
<asac> well done!
<Wellark> ogra_: which incident?
<ogra_> asac, well, only partially ... seems the roootfses dont reach the cdimage server ...
<asac> kk
<ogra_> there is a lot of stuff down atm
<ogra_> (no idea how that would affect rsyncing the images from nusakan to cdimage though, it shouldnt)
<cjwatson> ogra_,sil2100: for the record I didn't remove it, I just made cdimage carry on if it can't contact the tracker at all
<ogra_> cjwatson, ah, thanks ... would perhaps be good to have a switch for the future in case you are not around
<cjwatson> ogra_: (a) you could have made the very same change, it didn't particularly require me (b) no need for a switch
<ogra_> ok
<cjwatson> Hm, I wonder if I didn't quite get it right
<ogra_> is sync-mirrors using similar checks
<ogra_> or the wrapping call ...
<cjwatson> Not sync-mirrors, but there's a stage in between I missed
<cjwatson> ogra_: fixed harder, synced mirrors
<ogra_> thanks :)
<ogra_> popey, try now
<popey> It's there!
<ogra_> :)
<cjwatson> and indeed system-image goes off the local filesystem so should have been unaffected
<ogra_> yeah, only the changelog generation uses cdimage
<ogra_> i should move that some day ...
<Mirv> Wellark: you have silo rtm-003. rtm-013 is probably not going to land.
<ogra_> (like i should move the bot)
<Wellark> Mirv: not going to land?
<Wellark> tvoss: ^
<Wellark> Mirv: thanks!
 * ogra_ points to Wellark's inbox :)
<Mirv> Wellark: word back, 013 might land too but it's anyway not yet upstream tested so if you're quick 003 might land first...
<ogra_> psivaa_, did one krillin (krillin-09) fall over in 138 smooketesting ?
<ogra_> or is that an older dashboard entry
<ogra_> oh, seems to be older
<sil2100> ogra_: so, is the 138 progressing?
<ogra_> seems like
<ogra_> i dont see all tests listed yet
<psivaa_> ogra_: yes, it did. let me kick that one again
<tvoss> Wellark, on rtm-proposed, my sim is not recognized anymore. Is that a known issue?
<ogra_> did you run out of credit ?
<Wellark> tvoss: krillin?
<tvoss> Wellark, ack
 * ogra_ has both sims here (though i'm one image behind)
<tvoss> ogra_, sim with contract
<ogra_> ah
 * ogra_ upgrades to 138
<tvoss> ogra_, my sim is pin-locked, too
<ogra_> i have one locked and one open ...
<ogra_> (open one is prepaid ... the other one is contract)
<abeato> tvoss, some people had that issue in mako, but never ran into it with krillin
<abeato> tvoss, what does indicator-network show?
<tvoss> abeato, offline for both sims
<Mirv> sil2100: it does not look like I'm getting a full UITK AP run.. I've now been running after --bootstrap flashing my mako with latest rtm release, but it simply seems to stop at some point. do you think someone else could test it? maybe krillin, if the results would be easier to obtain than on mako?
<abeato> tvoss, ok, could you paste the output of /usr/share/ofono/scripts/list-modems ?
<tvoss> abeato, Wellark http://pastebin.ubuntu.com/8745974/
<Mirv> sil2100: among symptoms I have /lib/systemd/systemd-udevd keeps respawning all the time, while when it "halts" (Unity8 still works, but tests don't proceed) there seems to be a mirscreencast process that doesn't go away (hanged?)
<Wellark> ogra_: "The Product Team will probably still consider some exceptions"
<Mirv> if I kill the mirscreencast process (needs -9), I get unity-system-compositor crash and unity8 restarts
<ogra_> sure
<Wellark> please considersilos rtm 013 and rtm 003 as exceptions
<abeato> tvoss, hm, looks like you were in flight mode
<ogra_> Wellark, we are not the product team
<abeato> tvoss, is that the case?
<ogra_> wrong channel
<Wellark> ogra_: who is?
<ogra_> dude
<ogra_> the guys that bllock your landings since two weeks :P
<Wellark> sorry, haven't seen a org chart
<Wellark> nobody has blocked anything on me
<Wellark> I only have TOP BLOCKERs ;)
<ogra_> victor, olli, pmcgowan as announced serveral times over the last two weeks
<Wellark> well stuff in 013 and 003 fix only top blockers
<Mirv> so if anyone krillin wants to test UITK, please see silo https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-011 to your sources.list , apt upgrade to it, apt install ubuntu-ui-toolkit-autopilot, and run phablet-test-run
<ogra_> they decide what goes in ... talk to one of them to get an exception
<ogra_> doesnt help to moan in here ...
 * ogra_ notes his location indicator is gone on 138
<ogra_> tvoss, smells like there still is some race
<Wellark> ogra_: they are all offline, so where else could I moan ;)
<ogra_> dis/enabling location in system-settings makes it show up
<Wellark> + they usually hang out on this channel, so..
<ogra_> Wellark, victorp usually comes online around this time ... try #phablet
<Wellark> ack.
<davmor2> ogra_: if it is disabled in system-settings and you open a location based app does it show up then?
<ogra_> davmor2, dunno, i just tied to get the indicator back ... now it is there again
<ogra_> let me reboot, perhaps i hit the same race again
<ogra_> it wasnt off or anything ... just the indicator missing
<ogra_> nope, this time it is there
 * Mirv physiotherapist, and Qt telco immediately after that
 * sil2100 goes off to prepare lunch
<tvoss> abeato, probably
<abeato> tvoss, then just unset flight mode ;)
<tvoss> abeato, flight mode isn't active in the indicator and urfkill says false for flight mode
<abeato> tvoss, using the urfkill script?
<tvoss> abeato, according to http://pastebin.ubuntu.com/8746071/
<abeato> ok
<abeato> tvoss, following in #phablet?
<tvoss> abeato, sure
<Saviq> sil2100, is vivid silo 12 configured correctly https://ci-train.ubuntu.com/job/ubuntu-landing-012-1-build/55/console ?
<ogra_> brendand, http://paste.ubuntu.com/8746386/ .... (i guess i should one day make a branch of all these tools i use)
<ogra_> brendand, very interesting: the last mako rtm build had a dropping-letters hang that has systemsettle issues ... the output is pretty informative with that: http://paste.ubuntu.com/8746387/
<bfiller> Mirv: shall I upload the camera click now?
<Mirv> bfiller: according to topic we'd be frozen for blockers only, so my understanding would be that no
<bfiller> Mirv: ok, I think I'll upload it and then we can wait to approve until deemed open. I was approved for the wishlist anyway..
<davmor2> ogra_: on 138 if you slide down the battery indicator do you see auto brightness?
<Saviq> trainguards, can you please publish vivid silo 9 for me
<ogra_> davmor2, yep
<Saviq> trainguards, and reconfigure vivid silo 5, added qtmir there
<davmor2> then how come I don't sanity test blocker number 2 :(  not looking good guys
<ogra_> davmor2, i think the autobrightness thing is old ... there was a thread about it on ubuntu-hone quite a while ago (two weeks perhaps)
<sil2100> Saviq: o/
<sil2100> ...
<sil2100> Saviq: ok, so I reconfigured the wrong silo, but well, nevermind that!
<Saviq> sil2100, should be fine after a watch_only, no?
<sil2100> Saviq: yeah, let's wait for it to finish reconfiguring, but my brain mixed up the order
<sil2100> Good thing I didn't publish the other one
<sil2100> ;)
<mvo_> hey trainguards, is there a chance that I can get a vivid silo for line 94 (click)?
<seb128> mvo_, you have access to the assign function no? ;-)
<Mirv> bfiller: ok.
<mvo_> seb128: hmmmmmmm
<mvo_> seb128: I guess I do
<sil2100> mvo_: ;)
 * mvo_ assigns himself a silo or two
* josepht changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: josepht | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: CI Train on halt! No non-blocker landings accepted until image promotion!
<pmcgowan> https://docs.google.com/a/canonical.com/document/d/14L2Be36VRMQoWvbhguQu4D_lNQlhtmb3oMwbaGsAj2M/edit#heading=h.z2457fdjyl35
<pmcgowan> zbenjamin, Mirv  ^^
<pmcgowan> Mirv, is that you? hard to hear
<Saviq> sil2100, publish 9 please
<zbenjamin> pmcgowan: android emulator based
<barry> ribru, olli so, rtm/4, what's next?
<barry> pmcgowan: ^^ perhaps
<Mirv> pmcgowan: thanks for the doc
<brendand> ogra_, so that looks like an actual bug
<brendand> ogra_, whereas the krillin thing is maybe something more fundamental
<ogra_> brendand, yeah, just wanted to demo how it looks with an actual hanger
<ogra_> brendand, if i find time on the weekend i'll probably write a parser that pulls all top logs autmatically and generates us a regular report
<ogra_> (for one image run)
<sil2100> Saviq: puiblishing!
<sil2100> Saviq: btw. spreadsheet was b0rked and your silo didn't want to get marked as ready for release
<olli> thostr_, silo 15 doesn't look related to what we discussed?
<olli> sil2100, ^
<Saviq> sil2100, b0rkiness!
<Saviq> sil2100, ah, unapproved, checing
<Saviq> sil2100, ready agan
<Saviq> +i
<thostr_> olli: why 15?
<olli> thostr_, because i can't read
<olli> I guess you said 5
<olli> oops
<olli> sil2100, ^
<thostr_> :)
<olli> thostr_, but how does #5 relate to blank scopes?
<thostr_> olli: that's the qtmir fix to not suspend dash
<olli> silo 5... I read ubuntu-push-qml
<olli> Saviq, ^ is that possibly #10
<thostr_> olli: it's vivid silo 5
<thostr_> and rtm silo 13
<thostr_> that's the kind of mess...
<Saviq> olli, thostr_, yes vivid 5 (that's in flux right now) and rtm 13
<Saviq> *no*
<Saviq> rtm 10
<Saviq> 13 is just for crashes
<olli> :)
<thostr_> so, to summarize: rtm 5 and 10 is what we need to make the image stable...hopefully
<thostr_> no
<thostr_> f..ck
<Saviq> lol
<olli> nice...
<Saviq> that's blank scopes, totally no scopes aka black scopes is something I don't know yet where's it coming from, but both rtm 10 and 13 have potential there
<olli> straightforward as it seems
<sil2100> Silo 13 is what we need for unity8 crashes
<thostr_> rtm 10 and 13 that is
<Saviq> â
<sil2100> thostr_: what does silo 10 fix?
<thostr_> sil2100: that's the qtmir things, no? saviq?
<Saviq> sil2100, yeah, that's me, it's syncing rtm with unity8 trunk
<Saviq> sil2100, and now's the time when you tell me I can't do that
<Saviq> and I go to a corner and slit my wrists
 * ogra_ brings a bucket 
<cwayne> this got real dark real fast
<ogra_> i just want to save the carpet of our chatroom
<Saviq> sil2100, I'll have to redo vivid silo 5 then to only include changes relevant for rtm blockers
<Saviq> sil2100, and do a sync silo from that
 * olli hands ogra some episodes of Dexter
<ogra_> :)
<dobey> traingaurds: what do i need to do to actually rebuild the packages in a silo ppa that have already built/published in that ppa? i can't seem to get the train to force new package uploads
<brendand> tvoss, is 13 going to be ready for sign off soon?
<Saviq> dobey, which silo?
<tvoss> brendand, yup
<dobey> Saviq: ubuntu/landing-014
<Wellark> brendand: once 13 is in, you might want to champion 3 :)
<Wellark> brendand: has a fix for this: https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1374419
<ubot5> Ubuntu bug 1374419 in indicator-network (Ubuntu RTM) "[TOPBLOCKER] Threading issue with the MenuModel Updates" [Critical,In progress]
<Wellark> but needs 13 to go in first
<brendand> Wellark, i do like 3 (and not just for the gratuitous Symbian reference)
<brendand> Wellark, but i think we want to land just the blocker fixes first
<Saviq> dobey, that's a sync silo
<Saviq> dobey, once it's built, it's there
<Saviq> dobey, you'd have to bump version to rebuild
<Saviq> dobey, why do you need to rebuild it btw?
<ogra_> brendand, so i went though all systemsettle issues on 137 with my script ... upower clearly keeps dbus busy ... sometimes there is pulse on the list ... i think we shoulld a) raise the threshold a slight bit ... *but* ... have a bug to reaserch why upower keeps the bus so busy ...
<brendand> ogra_, let's drag rsalveti in :)
<dobey> Saviq: it was built before the new u-d-m landed in vivid, and now that it's in vivid, we need to rebuild against it as it was an abi break
<ogra_> brendand, i think ondra- did some reasearch of that before
<ogra_> brendand, and here is the topafter from the unity8 test on krilllin rtm 137 ... this is really interesting http://paste.ubuntu.com/8747221/
<Saviq> dobey, then you need to ask a trainguards to bump the ubuntu$ version in there and reupload to force a rebuild
<brendand> ogra_, that's our friend unity8 crash no :)
<ogra_> yeah
<Saviq> dobey, and then you'll have to sync that bump to your trunk
<ogra_> the interesting bit is that it keeps media-hub runnint at 100%
<ogra_> *running
<dobey> that is broken :-/
<ogra_> which will most likely cause later crashers
<ogra_> brendand, but this is the only systemsettle where we really have some high consumer ... all the others are just upower dbus noise
<dobey> Saviq: why can't the jenkins build job just grab the existing builds through launchpad api, and do retry() on them?
<ogra_> so i think we are good for adjusting the test as long as we keep an eye on that bit
<ogra_> (and if we find something ... lower tthe test value again)
<Saviq> dobey, because they're not failed?
<Saviq> dobey, and you can't have two binary packages with the same version in any ubuntu archive
<ogra_> sil2100, see backlog of the last ten mins (about systemsettle)
<Saviq> dobey, there's no "overwriting" packages
<sil2100> ogra_: doing in a moment
<ogra_> take your time, not urgent :)
 * sil2100 has a meeting now so it might take a moment
<sil2100> ;)
 * Mirv back from meeting
<imgbot> === trainguards: IMAGE 299 building (started: 20141030 14:05) ===
<dobey> maybe we should just cheat here, since u-d-m cheated too
<Mirv> davmor2: brendand: do you have any krillin free time to test (UITK AP only) the rtm-011?
<Mirv> davmor2: brendand: on mako I'm not getting them to finish, even if unity8 would not crash. seems a possible Mir(screencast) issue or such.
<dobey> ogra_, sergiusens: should we just copy+rebuild unity-scope-click from rtm -> vivid directly, since ubuntu-download-manager was done that way?
<davmor2> Mirv: nope I'm testing on mine
<ogra_> uh
<ogra_> ignore the imgbot
 * ogra_ is switching it over to vivid
<Mirv> davmor2: ok
<Saviq> Mirv, can you publish vivid silo 9 for me please
<Mirv> Saviq: yes
<brendand> Mirv, maybe - just double checking a few things for davmor2
<Mirv> brendand: ok, thanks for trying. I'll experiment with UITK testing with ro image, but I guess that's not possible since we don't have autopilot on the image anymore.
<Saviq> Mirv, thanks!
<ogra_> dobey, is unity-scope-click newer inr rtm than it was in utopic ?
<dobey> ogra_: yes
<ogra_> if it doesnt have a ~rtm version string etc that should be doable then
<dobey> ogra_: and new udm breaks abi, and autopkgtest for unity-scope-click fails now
<dobey> ogra_: i think it has the ~rtm because ci train :(
<ogra_> hmm, thats bad, then i would suggest rather a vivid silo
<sil2100> Mirv: hey, since I was away at lunch - how's the UITK test fix going?
 * dobey bangs his head against a train car
<Mirv> sil2100: no update from my update to you 1.5h ago, ie I'm not able to get the tests to finish on mako, therefore asking for any krillin user ^ to try it.
<Mirv> oh, 2.5h ago, that is
<Mirv> sil2100: it's probably not related to the change in anyway, but Mir or Unity8 or such
<Mirv> so it might be it'd work on krillin
<Saviq> dobey, basically, seems like now's the time to split trunk and rtm branches
<dobey> or having things not break underneath me while trying to get stuff done, would also be nice
<dobey> trainguards: can you destroy ubuntu/landing-014 silo? this is apparenlty not going to work and now we have to do extra work to get the fix into vivid. :-/
<sil2100> Mirv: if I have a moment after the meeting I could try that on krillin
<sil2100> Mirv: any specific way of running it required?
<Saviq> ribru, think we could make 123456 strings in the train dashboard active, opening the bug in target=_blank
<Saviq> ?
<Saviq> for the description that is
<ogra_> should be simple to just point to http://pad.lv/$bugnumber
<Mirv> sil2100: not that I'm aware off. about this http://pastebin.ubuntu.com/8747718/ ie usual
<sil2100> Mirv: oh, you not using the citrain tool? :)
<Mirv> sil2100: "the citrain tool"? if you mean Zoltan's script, no I've not modified it to run UITK tests only.
<sil2100> tvoss: how's silo 13?
<sil2100> Mirv: no no, phablet-tools-citrain I mean
<tvoss> sil2100, building
<sil2100> Mirv: like, citrain device-upgrade <silo>
<Mirv> sil2100: eh.. installing
<Mirv> sil2100: I did hear people using something like that, it didn't occur to me it's in archives!
<ogra_> and dont step on the tracks :)
<sil2100> Mirv: hah ;)
<Mirv> sil2100: oh right, but it uses the apt trick from me anyway :)
<brendand> Mirv, i can try that silo now - which one was it?
<Wellark> trainguards: could I please get a reconfiguration of silo rtm-3 ?
<sil2100> Wellark: sure
<Wellark> sil2100: thanks!
<alecu> jhodapp: hi! I made a small branch for this: https://bugs.launchpad.net/mediaplayer-app/+bug/1387691
<ubot5> Ubuntu bug 1387691 in unity8 (Ubuntu) "Media Player should not be visible in the app scope and launcher" [Undecided,Incomplete]
<Wellark> sil2100: also could you check (when you have a minute) why the Status field in line 92 is not updating
<sil2100> Wellark: so, I see it has dbus-cpp - remember that we have a critical landing for dbus-cpp in the works
<jhodapp> alecu, excellent...is it ready for testing and approval?
<Wellark> sil2100: oh, you are good. now it updated
<sil2100> Yeah, just fixed it ;)
<Wellark> sil2100: yes. tvoss requested I get one of the MP's out of that pending dbus-cpp silo
<Wellark> sil2100: and in the comments the dbus-cpp silo is mentioned
<alecu> jhodapp: yes, I think it's ready to build on an rtm silo and test it
<jhodapp> alecu, alright, can you get an rtm silo requested?
<sil2100> Wellark: reconfigured o/
<jhodapp> alecu, let me know when the ppa is ready
<Wellark> sil2100: thanks!
<alecu> jhodapp: sure. I'll get it built then ask you to do the usual tests for it, and I'll test that click scope still works fine with that change.
<alecu> jhodapp: nothing's really changing in that branch, but just to be sure.
<Mirv> brendand: rtm-011
<jhodapp> alecu, indeed...last time that landed I assumed everything would be ok but there can be unexpected bugs from that
<jhodapp> alecu, with how url-dispatcher works
<alecu> right
<alecu> jhodapp: I checked that local videos can be launched from the video scope
<alecu> and that seems to be working right (unlike with the NoDisplay=True change, I tried that before and it broke)
<alecu> jhodapp: btw, what's the url for the media player test plan?
<jhodapp> alecu, don't have it offhand, just navigate to the top of all test plans on the wiki and you'll find it
<alecu> I guess it's this: https://wiki.ubuntu.com/Process/Merges/TestPlan/mediaplayer-app
<jhodapp> yes
<om26er_> oSoMoN, on krillin, twitter webapp seems to load the static version now. it was loading the dynamic version just last week.
<om26er_> do you know what changed ? see: http://i.imgur.com/5SfomgK.png
<om26er_> dbarth, ^
<dbarth> om26er_: checking
<dbarth> om26er_: it's the browser, not the webapp
<om26er_> dbarth, right, its the same there as well.
<dbarth> loads fine here
<dbarth> om26er_: which image # are you on?
<brendand> Mirv, so just run the uitk AP tests?
<Mirv> brendand: yep.
<Mirv> brendand: that's what I'm seemingly unable to get done on my mako.
<om26er_> dbarth, r138
<ribru> barry: looks like we're waiting for qa signoff on rtm4
<ribru> Saviq: yeah I'm a little behind on the dashboard to-do list sorry
<Mirv> brendand: if they pass, then we have something probably worth landing. the only change was this https://code.launchpad.net/~timo-jyrinki/ubuntu-ui-toolkit/modify_test_desktopfile_lp1382414/+merge/240079
<Saviq> ribru, just asking, if that's there on your list already, I'm game
<barry> ribru: yep
<Laney> josepht: hi, can you reconfigure jobs like https://code.launchpad.net/~laney/libaccounts-glib/libtool-and-gi/+merge/240116/comments/590222 to run on vivid instead please?
<josepht> Laney: we're in the process of adding vivid support now
<Laney> ok
* josepht changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: CI Train on halt! No non-blocker landings accepted until image promotion!
<ribru> sil2100: did you notice yet that our vivid builds are getting versioned as 14.10.YYYYMMDD? ;-)
<sil2100> ribru: didn't have time to notice that, sorry ;p
<sil2100> Why vivid isn't set to 15.04?
<sil2100> Was that a mistake I made?
<ribru> sil2100: dunno, I'll have to dig in that code today.
<sil2100> Maybe I did that by mistake when I added it
<sil2100> Like, in the big trance
<sil2100> Just typing random things on a meeting
<sil2100> ;)
<sil2100> (like now)
<ribru> sil2100: there's a weird bug where vivid builds have an unhandled exception trying to open the dsc file, but I've confirmed the dsc file exists with the exact name... but it's marked 14.10 ;-)
<Mirv> sil2100: I've failed miserably in getting the citrain tool to work, it always tries to add wrong PPA :)
<sil2100> Mirv: hah!
<Mirv> on the last attempt it did add a PPA, for rtm, but set the series to "devel" instead of "14.09"
<sil2100> Mirv: did you enter the silo name as 007?
<ogra_> i thought that was fixed with ribru's llast changes
<sil2100> Mirv: since no pending zeroes! DO not add those
<Mirv> sil2100: I did that too, getting some funky calculation of 011 becoming 009
<ribru> Mirv: what do you mean "set the series"? citrain tool doesn't change the image series
<sil2100> Mirv: just use '7' instead of 007
<ogra_> no james bond silos !
<ribru> Mirv: are you using the latest version? also wtf
<Mirv> sil2100: so I ended up then with the correct silo but with 'devel' indeed, and I don't know where it's picking that up
<Mirv> ribru: in the apt line, ended with "devel"
<sil2100> huh?
<sil2100> wtf
<Mirv> latest rtm image, citrain device-upgrade 11 0000 ubuntu-rtm
<sil2100> Mirv: did you try setting the distro manually?
<ribru> Mirv: well that's a bug in phablet-config then, which citrain tool just wraps
<sil2100> Like attaching ubuntu-rtm to the end?
<sil2100> Mirv: ah, right...
<cjwatson> "devel" is a fallback in add-apt-repository when working with a different distribution
<cjwatson> and "devel" should work just fine for ubuntu-rtm/14.09
<cjwatson> since that's the latest series in that distribution
<Mirv> I got 403 Forbidden with that
<cjwatson> that's an LP bug then
<cjwatson> deployment bug rather than code bug, I think
<cjwatson> it's meant to work
<cjwatson> been outstanding for a while, didn't realise it still was, we'll need to investigate that
<Mirv> sil2100: with and without setting the distro
<Mirv> yeah, s/devel/14.09/ works, but it's unclear to me how that tool works for anybody testing rtm silos
<cjwatson> I'll chase it up
<cjwatson> we shouldn't change add-apt-repository, we should fix ppa.lp.net :)
<davmor2> lool marked bug accordingly
<Mirv> thanks cjwatson, something worthwhile from this experimentation (I wouldn't have needed the tool but sil2100 suggested it)
<ogra_> MIrwell, it definitely worked once
<ogra_> Mirv, ^^
<Mirv> orwell, mirwell
<lool> davmor2: thanksely
 * ogra_ has seen is working 
<ogra_> *it
<ogra_> but thats a while ago
<brendand> Mirv, we're using it all the time
<Mirv> brendand: I thought so, that's why it's curious why it works for you
<Mirv> brendand: which image channel exactly you're using? I wonder if it has anything to do with that. I'm currently using --channel=ubuntu-touch/ubuntu-rtm/devel-proposed
<Mirv> since I think ogra at some point stated one should not use release names preferably
<brendand> Mirv, ooooh
<brendand> Mirv, interesting
<brendand> Mirv, try ubuntu-touch/ubuntu-rtm/14.09-proposed
<ogra_> Mirv, right, do not end up in a situation where you need to switch channels
<ogra_> once there is a new versioned one
<Mirv> ogra_: yeah, that's what I thought
 * ogra_ would very much prefer if we could make the versioned or named channels just invisible on the server 
<Mirv> brendand: I might, although I fail to see how phablet-config or anything could get the "devel" from somewhere related to that
<ogra_> and only stay with devel and devel-proposed
 * Mirv grepped "devel" at /etc/ and didn't find anything
<ogra_> Mirv, iirc from system-image-cli -i
<ogra_> if i remember roberts code snippet right
<Mirv> ogra_: true! channel: ubuntu-touch/ubuntu-rtm/devel-proposed, alias: ubuntu-touch/ubuntu-rtm/14.09-proposed
<ogra_> right
<Mirv> not sure if it has anything to do with this, but at least there's one place a tool could pick up devel instead of 14.09
<ogra_> yeah, we might want to force it using the alias if there is one ... for the moment at least
<ogra_> and not tthe actual channel name
<Saviq> Mirv, should I be worried http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8 - unity-scope-click test failed
<ribru> ogra_: er, wut? I grep the output of system-image-cli for whether or not it's ubuntu/ubuntu-rtm. nothing to do with series.
<ribru> or channel name.
<Saviq> alecu, does that ring any bell http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-unity-scope-click/lastBuild/ARCH=amd64,label=adt/console ?
<ogra_> ribru, the channel name is the only place to get that info from in system-image-cli
<ribru> sil2100: seriously the function that generates version numbers is 100 lines long and that doesn't even include the logic for determining which series to put in the version (that's passed in). this spaghetti is terrible.
<ogra_> so you do grep for the channel name if it has rtm
<ribru> ogra_: yeah but I grep it for rtm, not for what series it says
<ogra_> right
<ogra_> and we might need to add that for the moment until LP can act properly on "devel"
<brendand> sil2100, we're putting a halt on image testing until 13 lands
<sil2100> brendand: o>
<sil2100> ribru: it should just use the number that's taken from settings.py, no? Like, the one that's related to the series name
<sil2100> ribru: but hmmm, that's correct there: "'vivid': '15.04',"
<sil2100> So it should just work
<sil2100> Has to be some bug somewhere else
<imgbot> === trainguards: IMAGE 3 DONE (finished: 20141030 15:45) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/3.changes ===
<sil2100> \o/
<ogra_> yay
<ogra_> so the both knows vivid now :)
<ribru> sil2100: yes that's how I thought it worked... but indeed vivid builds are not picking that up correctly.
<sil2100> o_O
<davmor2> ogra_: is devel-proposed not meant to point at image 3 now?
<ogra_> davmor2, it should (accordign to slangasek )
<tvoss> sil2100, silo 13 built, retesting
<Mirv> Saviq: someone on some channel was taking about unity-scope-click tests failing because of xyz. does that help you? :)
<slangasek> ogra_, davmor2: maybe it's still importing?
<Saviq> Mirv, kinda, probably won't help me migrate though ;(
<Saviq> Mirv, right, because of u-d-m
<ogra_> slangasek, no, the bot checks the external http server if it announces it it is definitely there
<davmor2> slangasek: still points to utopic 299 as of my flash this morning
<ogra_> slangasek, but i dont think davmor2 meant to say it isnt
<Saviq> mandel, alecu, hey, any resolution on unity-scope-click tests vs. ubuntu-download-manager
<ogra_> davmor2, with image 3 this should have changed
<ogra_> only right now
<slangasek> ah, so the bot only sees it once it's on the channel
<ogra_> this morning it was still pointing to the old one
<davmor2> ogra_: ah right I will update and check then
<ogra_> right
<slangasek> ah, yes
<brendand> ogra_, should we rope someone into the landing meeting to give feedback on the settle/powerd issue?
<ogra_> an OTA or a fresh flash should get you vivid #3
<brendand> ogra_, not sure who's a good candidate
<sil2100> tvoss: keeping my fingers crossed! We're all anticipating silo 13 eagerly
<ribru> sil2100: https://ci-train.ubuntu.com/job/ubuntu-landing-003-1-build/63/console figures I run a build job with DEBUG and it gets the 15.04 version. damnit
<ogra_> brendand, well, i know that ondra- looked at upower and dbus stuff not to far ago ... and i knwo hhe talked about it with rsalveti ... but the latter is gone this week ...
<brendand> ogra_, yeah
<davmor2> ogra_: ota version 3
<brendand> ogra_, i guess for now we could try and ignore them
<ogra_> brendand, the core question was if we should adjust the systemsettle value ...
<brendand> ogra_, since they manifest as errors not failures it's a bit easier to filter them out
<ogra_> brendand, and i think we have the answer ... as long as we keep an eye on upower
<davmor2> slangasek: too ^
<ogra_> thats true
<ogra_> davmor2, cool !
<ogra_> so its all working then :)
<slangasek> hmm?
<brendand> ogra_, well if we adjust the value to say - 96.5 then most of the tests should pass, and if anything else apart from upower goes haywire it will make it fail anyway
<davmor2> ogra_: no idea it has to download the whole image a fresh
 * ogra_ likes that our software always works and never has bugs :) 
<brendand> ogra_, so as long as we don't think the upower thing is an issue we should probably do it
<ogra_> brendand, yeah ... 96.5 would still have catched the media-hub
<tvoss> Mirv, hey there, I'm having problems downloading packages from a ppa
<tvoss> Mirv, tells me: W: Failed to fetch http://ppa.launchpad.net/ci-train-ppa-service/landing-013/ubuntu-rtm/dists/devel/main/binary-armhf/Packages  403  Forbidden
<brendand> Mirv, i ended up with 3 failures on uitk
<ogra_> i think the upower thing is an issue that deserves a bug filed ... and fixed ... but it shouldnt make the dashboard uglier than it already is
<ondra-> ogra_ brendand lastest measurements were fine, there wasn't much traffic on dbus, more like 10s with no traffic
<Mirv> tvoss: we just discussed that. s/devel/14.09/ in /etc/apt/sources.list.d/*.  there's a bug.
<ogra_> ondra-, did you ever compare to mako ?
<ogra_> ondra-, the point is that our idle measurement before and after smoke tests never hits the same low value as mako does ... and looking at the logs it seems upower and dbus simply keep it slightly more busy
<Mirv> brendand: excellent! excellent for a) being able to finish the tests, b) having only 3 failing tests instead of ~70. 0 would have been perfect of course.
<Mirv> sil2100: ^
<Mirv> maybe there's a mako specific issue then, but krillin fine
<sil2100> Mirv: for me that's perfect, let's get that to the QA queue then
<brendand> ogra_, so i did say earlier, and maybe you didn't answer me because it was a stupid question - but given two pieces of hardware running the same code, would the one with the lower clock speed end up with less idle time?
<ondra-> ogra_ hmm, there was not much from upower since last update
<sil2100> Mirv, brendand: so, silo 11 (UITK AP fix) got a +1 from management
<ogra_> brendand, migh, yes
<ogra_> *might
<sil2100> Mirv, brendand: it's not a promotion blocker, but can land during the landing lock if we make it in time before the dbus-cpp fix
<ogra_> ondra-, no, thats there since forever
<brendand> ogra_, and krillin is slower than mako
<brendand> ogra_, i totally realise that it's a bit apples and oranges, but just worth considering
<ogra_> yes
<ogra_> its not really apples vs oranges ...
<ogra_> more like beetel vs porsche 911
<ogra_> *beetle
<ogra_> there is indeed a significant performance difference
<Mirv> sil2100: ok. well, I simply marked as brendand as having "upstream tested" it since my AP results weren't too good, even though yes I've been using it the whole day. the question is what QA sign-off would need this time, but now it's in the queue anyway.
<brendand> sil2100, are there no uitk code changes in there, just Mirv 's test fixes?
<Mirv> brendand: sil2100: this time the PPA diff is correct: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-011/+files/ubuntu-ui-toolkit_1.1.1298%2B14.10.20141016.1-0ubuntu1_1.1.1298%2B14.10.20141030%7Ertm-0ubuntu1.diff.gz - noise because of translation updates.
<brendand> sil2100, if so then i wouldn't even bother with QA sign-off
<brendand> Mirv, lol - is this the fix :)
<brendand> -Exec=Not important
<brendand> +Exec=/usr/bin/whoami
<Mirv> brendand: yes! :D
<Mirv> brendand: the new qtmir desktop parses requires a valid file
<brendand> bug : identity crisis in desktop file
<sil2100> brendand: yep
<brendand> sil2100, just land it
<sil2100> brendand: well, I would want someone to do some random exploratory tests maybe - Mirv did you have a moment to play around with it for a moment?
<sil2100> Just to make sure no new deps didn't cause it to break after rebuild
<Mirv> sil2100: I've played around with it on mako, browsing the web et cetera.
<brendand> sil2100, i could do that
<ogra_> cjwatson, since i get poked about it all the time and am not sure ... people ask me about package copies from rtm to vivid ... i tend to refuse copying anything with ~rtm in the version, is  that correct or would that be a safe thing to do ?
<brendand> sil2100, i have it installed on my krillin now
<sil2100> I'll do that as well, don't want brendand to waste his time ;)
<Mirv> some exploratory tesitng on krillin wouldn't hurt
<sil2100> I have it on krillin too
<brendand> sil2100, actually i'd prefer it if someone pored over the translation updates and make sure they look sensible
<cjwatson> ogra_: it's not unsafe, though some people might find it confusing maybe
<cjwatson> ogra_: (not unsafe as long as it's a binary copy, anyway)
<Mirv> brendand: I think translations are gotten from LP to the language packs regardless of what's in the .deb, although pitti might confirm that.
<brendand> Mirv, true
<ogra_> ah, no, i always do a source copy to -proposed to make sure possible toolchain or dep changes get picked up
<cjwatson> binary copy please!
<ogra_> i just wasnt sure about the versioning and if that might get in our way when merging the distros back later
<ogra_> ok
<cjwatson> don't rebuild packages with the same version in ubuntu vs. ubuntu-rtm
<cjwatson> if you're going to rebuild, change the version please
<cjwatson> it's not a problem to not pick up toolchain changes, after all most packages aren't rebuilt from utopic to vivid
<cjwatson> and if a dependency change is required then proposed-migration will notice that
<ogra_> ok
<tvoss> sil2100, so I couldn't get the indicator network to crash, wizard worked for me and I could enter my pin
<dobey> ogra_: so you're going to bincopy udm and unity-scope-click then?
<Mirv> brendand: I looked through them now. it doesn't look anything would be broken and I even partially know da/sv/no/en/de/fi (well I made the fi translations myself) + can evaluate indo-european languages' sanity.
<ogra_> dobey, udm again ?
<ogra_> i did that yesterday
<Mirv> additionally, my understanding is UI Toolkit translations are only used in the UI Toolkit gallery test application
<dobey> ogra_: you did a source copy to proposed
<dobey> ogra_: and i presume it's blocked due to unity-scope-click autopkgtest failing?
<ogra_> dobey, right ... but thats surely built now
<brendand> Mirv, sil2100 - it's in the QA queue now which means i get the final say :)
<brendand> Mirv, sil2100 - well that's not actually true ;) but...
<tvoss> brendand, is silo 13 in the queue, too?
<dobey> ogra_: yep, it's still sat in proposed because of the autopkgtests
<Mirv> brendand: right, are the Cancel/Confirm things used eg. somewhere in apps via UITK?
<brendand> tvoss, not yet - it will be when you mark it testing passed
<ogra_> dobey, proposed = after building
<brendand> tvoss, eagerly awaiting that
<dobey> oh, sure
<sil2100> brendand: so, I played around with the image with an UITK now and it seems to be good
<ogra_> dobey, i'll bin copy the scope then
<sil2100> brendand: you want to additionally dogfood or should I just land it?
<dobey> ogra_: ok, great. thanks
<Mirv> I dont see anything modifying existing translations of those key strings, just adding translations to new languages
<brendand> sil2100, i'm going to set it to granted now
<sil2100> \o/
<sil2100> tvoss: excellent
<sil2100> Saviq: hey, regarding bug LP: #1386653 ...
<ubot5> Launchpad bug 1386653 in unity8 (Ubuntu) "Scopes fail to launch when the network stack is not up" [Critical,Confirmed] https://launchpad.net/bugs/1386653
<sil2100> Saviq: so, could you maybe install silo 13 on you machine and take a further look into this bug? Since the instabilities should be gone after installation of that one
<tvoss> sil2100, I fail to see how 13 should fix that
<dobey> sergiusens: ^^ so if it's being bin copied to vivid now, what does that mean for the silo/spreadsheet? clean out the silo, delete the spreadsheet row, and act like nothing ever happened? :)
<ogra_> tvoss, stop trashing peoples hopes !!!
<Saviq> sil2100, not gonna happen today I'm afraid
<Saviq> sil2100, and it's silo 10 that fixes blank scopes
<sil2100> tvoss: it won't, but one of the problems with testing that bug was that unity8 was crashing and introducing noise
<tvoss> sil2100, okay
<sil2100> Saviq: ok, silo 10 is another one that product management is waiting on too
<sil2100> Saviq: any ETA for silo 10?
<sil2100> Since it's on the list of 'needing to land before promotion' from the product team
<Saviq> sil2100, well, yeah, it needs to be redone after you guys locked the doors
<sil2100> Redone?
<Saviq> sil2100, sure, but there's changes unrelated to blockers
<sil2100> Ah
<Saviq> sil2100, and in any case I'm blocked in proposed for vivid now
<Saviq> sil2100, so can't land into vivid/trunk
<sil2100> Crap, then we need to inform olli and others
<Saviq> sil2100, until vivid 14 gets published (which needs a rebuild)
<olli> wazzup
<Saviq> olli, long story short, unity8's silo not gonna land today
<ogra_> dobey, http://paste.ubuntu.com/8748693/ is that the right version ?
<sil2100> Mirv: we need https://code.launchpad.net/~timo-jyrinki/ubuntu-ui-toolkit/modify_test_desktopfile_lp1382414/+merge/240079 approved
<olli> Saviq, what is it fixing?
<sil2100> olli: silo 10
<sil2100> olli: it was supposed to help with blank scopes
<Saviq> olli, blank scopes (not sure about black ones though)
<dobey> ogra_: it is, yes
<ogra_> cjwatson, hmm, it just strikes me that when i do binary copies from rtm we will miss ppc and arm64
<olli> what about the crashes?
<Saviq> olli, that's 13, dbus-cpp
<cjwatson> ogra_: they'll build as needed
<ogra_> cool
<dobey> ogra_: unity-scope click isn't building on those anyway
 * ogra_ presses y then 
<Saviq> olli, the unity8 one had a slew of rtm fixes apart from the blocker ones
<ogra_> dobey, yeah, thats was more in general
<olli> Saviq, mind expanding the short story
<Saviq> olli, sure
<olli> Saviq, are you saying the silo has more than what's approved?
<ogra_> 13 packages successfully copied.
<Saviq> olli, not more than approved, more than blocker-fixes
<ogra_> dobey, enjoy
<dobey> ogra_: danke!
<ogra_> :)
<Saviq> olli, so according to the rules I'd need to redo that silo to only include promotion blocker fixes
<Saviq> olli, but before I can do that (or well, before I can land anything in rtm)
<Saviq> olli, I need to land in vivid
 * dobey goes to land some lunch
<Saviq> olli, and I'm blocked in proposed for vivid (ogra just uploaded something that will unblock me)
<Saviq> olli, but still I need to land another vivid silo before being able to cherry-pick from there to rtm
<tvoss> sil2100, kgunn is running the unity8 ap test suite
<tvoss> sil2100, once that is done, we set it to tested. Qa could probably start testing in parallel, though
<tvoss> brendand, ^
<Mirv> sil2100: yeah, bzoltan_ just is the only one who knows the background of the bug I think
<ogra_> Mirv, of the 70+ AP failures ?
<Mirv> ogra_: well yeah I guess everyone is aware of the problem. I'm currently trying to get t1mp to approve it :)
<ogra_> Mirv, the fix comes from ricmm
<sil2100> brendand: ^ what do you think?
<sil2100> Mirv: I approved the -gles one, but we need someone to approve the main one :)
 * sil2100 feels trigger happy today
<Mirv> ogra_: according to bug report it was dandrada originally, although not sure
<Mirv> since he made the patch attachment
<ogra_> well, i sat next to ricmm when he fixed it on monday at the sprint
<Mirv> hehe
<Mirv> sil2100: approved!
<ogra_> or researched it and found the issue ... but it might well be that he gave the actual code change and landing into other hands
<sil2100> Saviq, olli: maybe we could do an exception for this particular silo - Saviq what bug fixes are in silo 10? Maybe we can get olli and the others looking through them and giving an exception to land
<Saviq> sil2100, it's not even that
<Saviq> sil2100, I need to land into vivid first
<sil2100> To save up time, as time is what we don't have
<Saviq> sil2100, and am blocked in proposed currently
<sil2100> Ah, right...
<sil2100> Mirv: o/
<Saviq> sil2100, and have another silo to land in vivid before I have things in trunk that I want to land into rtm
<olli> Saviq, sil2100 happy to look at it this way to unblock a timely promotion, but as I understand from Saviq it seems a waiver won't help atm
<ogra_> now only fatsre infra will help
<ogra_> *faster
<Saviq> ogra_, faster people too, if I'm supposed to test it actually
<mvo_> so my click vivid is sitting in silo30, does that need some manual approving step before it gets build or is stuff just a bit on the slow side right now ?
<Saviq> sil2100, obviously I can't reproduce the "black scopes" issue in rtm with flight mode
<Saviq> sil2100, so can't even see if 10 is helping
<ogra_> mvo_, was that a dput ?
<ogra_> or an MP
<mvo_> ogra_: no, MP
<olli> Saviq, do you need me to test something
<ogra_> then just clicking the build button should do
<olli> I was able to reliably repro
<Saviq> olli, if you still can repro, you could try with rtm silo 10 to see whether it helps (we'll still need to fix the silo, but at least we'll know it helps)
<Saviq> olli, you can install silo 10 on top of rtm + silo 13 just fine
<brendand> sil2100, i totally missed the context
<Mirv> sil2100: I've clicked publish, the -gles packages needed ack_packaging for the "debian/watch" file change.
<sil2100> Mirv: ok :) Thanks!
<sil2100> brendand: so, tvoss's silo 13 is almost ready, kgunn is just running final unity8 AP tests, so tvoss asked if QA could start the sign-off in parallel
<brendand> sil2100, tvoss - set it to testing passed then
<olli> Saviq, I can do that in ~30min
<olli> Saviq, silo 10 and which build?
<olli> just latest?
<Saviq> olli, yeah
<olli> k/ me updates
<olli> Saviq, PES was asking for a new ETA to align their testing teams
<olli> sil2100,
<popey> landing call?
<Saviq> olli, my estimate before noon UTC tomorrow
<olli> john-mcaleely, ^
<sil2100> hm, problems with the hangout
<olli> Saviq, thx
<sil2100> One min, need to restart FF
<olli> yeah, google is acting up today
 * Saviq needs afk for now, back later
<sil2100> olli: anyway, we'll spin out an image with the unity8 crashed and UITK fix in case you want to have that as the promoted
<sil2100> And ask QA to do the promotion testing on that
 * ogra_ wonders if google uses drupal :P
<john-mcaleely> olli, thanks
<Mirv> sil2100: re: 013 do note https://code.launchpad.net/~thomas-voss/dbus-cpp/fix-1361642/+merge/236820 is not approved yet
<Mirv> tvoss: ^
<Mirv> the issue reported is however handled in 003
<tvoss> Mirv, I removed that MP from the silo
<tvoss> brendand, set to testing pass
<Mirv> tvoss: oh, ok
<Mirv> sil2100: unping re: 013
<tvoss> brendand, you don't need to run the entire location service test suite, just focussing on the bug reports should be fine. Feel free to run the location service stuff, though :)
<tvoss> Mirv, sil2100, brendand I'll be around in 30 minutes again
<dbarth> hey guys
<dbarth> i have a problem with line 28 of the spreadsheet
<dbarth> it says the silo was landed; but the branch was not merged afaict
<dbarth> i'm about to land another change of the same package, but if i do, i risk loosing the rest
<ribru> dbarth: so line 28 is just a sync, it doesn't have any branches to merge. line 27 has the branch and it says it was freed without landing.
<dbarth> ah, so i can land silo 29, and then i will re-attempt landing that one
<dbarth> ribru: thanks for the clarification
<Mirv> dbarth: ribru: the 029 would look like removing a fix already made https://ci-train.ubuntu.com/job/ubuntu-landing-029-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-system-settings-online-accounts_0.5+15.04.20141029.1-0ubuntu1.diff (see the 1023 changelog entries, and the fact libapparmor-dev build-dependency is being removed)
<dbarth> Mirv: hmm, i had not spotted that one
<dbarth> Mirv: we were clarifying the status of this other silo landing attempt
<ribru> Mirv: dbarth: not sure about 29, it's just a sync?
<dbarth> no it's a real landing
<dbarth> Mirv: those -- lines look like the one was half merged, or present in mardy's branch when he mp'ed it
<dbarth> Mirv: the issue is that the other branch was approved and merged on master, and that's what mardy based his other branch on
<dbarth> Mirv: so really i need to land the other password prompt first, and then the one in silo 29 :/
<dbarth> or ribru ^^
<dbarth> so that means i will need to reload a silo with the content of line 28-27, targetting vivid
<dbarth> land that, rebuild 29, test and reland
<dbarth> oh joy ;)
<ribru> dbarth: ok well it's no trouble to retarget line 27 at vivid
<ribru> dbarth: ok you got vivid 27, please build
<ribru> heh line 27 got silo 27
<dbarth> ribru: thanks
<dbarth> yeah, neat ;)
<ribru> heh
<dbarth> ribru: yeah, it's already in vivid
<dbarth> https://launchpad.net/ubuntu/vivid/+source/ubuntu-system-settings-online-accounts/+changelog
<dbarth> that very branch
<ribru> dbarth: ok merge the branch normally but make sure you also get the changelog from distro synced into trunk
<ribru> "merge manually"
<dbarth> ribru: the silo 29 one, you mean
<dbarth> we'll need to go master -> trunk i think that'll be easier
<dbarth> still not sure why master exists, but that's another story
<dbarth> i'll see with alex_abreu
<ribru> dbarth: uh no? I mean the line 27 one, I guess that sync was already landed to vivid, but because it was a sync the branch didn't get merged. so merge that branch, sync the changelog from distro to trunk, then you're back in a consistent state there
<dbarth> oh my, yes
<dbarth> ok, makes sense now
<dbarth> (or so i hope)
<lool> cjwatson, slangasek: Would you know if --channel=ubuntu-touch/devel-proposed-customized-here is meant to be updated as often as vivid-proposed?
<slangasek> lool: in principle it should be; at the moment only devel-proposed has been switched to vivid, we haven't made any changes to the customized channels because that needs to be coordinated with the custom.tgz owners
<cjwatson> lool: in theory yes; in practice it's still pointing at utopic, I think until we get a clear statement that the custom tarballs are ready for vivid
<cjwatson> snap
<slangasek> :-)
<slangasek> lool: so since you're the owner of that particular tarball, you can tell us when you want it updated
<lool> slangasek: I'm the owner? crap
<lool> slangasek: yeah, totally, it should be forward compatible with vidid
<lool> *vivid
<lool> this was tracking utopic til the end, and should now track vivid just the same
<slangasek> ok
<cjwatson> I keep typing "vidid" too ...
<dbarth> ribru: i'm done with the manual merge; so i think silo 27 can be removed, and i will then rebuild 29; ok?
<ribru> dbarth: sure
<ribru> dbarth: http://bazaar.launchpad.net/+branch/ubuntu-system-settings-online-accounts/revision/203 I think you made a copy&paste error here (launchpad's fault, I think you just copy&pasted directly from lp, which is wrong). you're missing a blank line before the '--' line, and there should be just 2 spaces, not 3, in between the > and the Thu.
<dbarth> ah yeah, i took it from lp
<ribru> dbarth: yeah lp helpfully mangles the changelog into an invalid format
<ribru> like, that will fail to build because the package builders can't parse that
<dbarth> fixing, and i'll re-rebuild next
<tvoss|food> brendand, ping
<brendand> tvoss|food, hey
<ribru> dbarth: also everything got shuffled around in the spreadsheet, line 29 we were talking about is now 22.
<olli> sil2100, ^
<dbarth> ah, to further confuse me
<dbarth> but i'll make it
<ribru> dbarth: lol, silo 29 is row 62. was row 29 ever relavent? ;-)
<sil2100> tvoss|food: give me a sign once you're back :)
<sil2100> Saviq: same for you, give me a sign once you're back
<tvoss|food> sil2100, here we go
<sil2100> tvoss|food: o/ so, I had a question: silo 13 is fixing the unity8 crashiness first thing, right? But does it also help with the network indicator stability?
<sil2100> tvoss|food: since I heard that thostr_ mentioned that some merge has been taken out of it or something
<tvoss|food> sil2100, it helps, yes. But: we migrated one fix to wellark's silo
<tvoss|food> sil2100, wellark tried the silo (with the other fix taken out) and +1ed that it fixes the crash
<Wellark> tvoss|food, sil2100: silo 13 as it's current state fixes: https://bugs.launchpad.net/ubuntu/+source/dbus-cpp/+bug/1382595
<ubot5> Ubuntu bug 1382595 in indicator-network (Ubuntu RTM) "[TOPBLOCKER] /usr/lib/arm-linux-gnueabihf/indicator-network/indicator-network-service:indicator-network-service: pthread_mutex_lock.c:80: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed." [Critical,In progress]
<Wellark> which affects i-network and location-service
<Wellark> the MP that was pulled out helps i-network on couple of cases not to do controlled restart (user sees the menu repopulate itself)
<sil2100> Ah, ok
<sil2100> But in overall the situation will be much better I suppose
<Wellark> well, at least we get both location-service and indicator-network not to report crashes (and kill the performance on phones while apport runs) on that assertion error causin a plain abort()
<Wellark> in silo 13 that is
<Wellark> so yes. it's a very important fix in there
<Wellark> silo 3 has the important fix for wifi list getting "corrupted" but that can't land before 13 is in
<sil2100> olli: ^
<olli> sil2100, I not having silo 3 is imho fine if that's all it fixes... in case that was the q/fyi
<sil2100> Yeah, just wanted clear out the situation, just need to catch thostr_ still
<Wellark> olli: ok, to be clear: silo 13 fixes: https://bugs.launchpad.net/ubuntu/+source/dbus-cpp/+bug/1382595
<ubot5> Ubuntu bug 1382595 in indicator-network (Ubuntu RTM) "[TOPBLOCKER] /usr/lib/arm-linux-gnueabihf/indicator-network/indicator-network-service:indicator-network-service: pthread_mutex_lock.c:80: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed." [Critical,In progress]
<Wellark> olli: silo 3 fixes: https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1374419
<ubot5> Ubuntu bug 1374419 in indicator-network (Ubuntu RTM) "[TOPBLOCKER] Threading issue with the MenuModel Updates" [Critical,In progress]
<olli> Wellark, how exposed is x419 ^
<olli> happening everytime?
<brendand> olli, for better or for worse we already shipped that issue in the last promoted image
<olli> exactly
<Wellark> olli: you get it by hitting "Cancel" on wifi password dialog
<Wellark> but yes. it's been in since the infamous urfkill landing
<olli> ok, brendand's rationale holds true... it was good enough for the last promotion, so let's not risk the current promotion with rushing it in
<olli> unfortunate but the safe bet
<Wellark> olli: ack. reasonable.
<Wellark> I just need silo 13 to land at some point so I can land 3 :)
<sil2100> Wellark: 13 will land tomorrow - if, of course, it indeed fixes the unity8 crashness as well
<sil2100> Scratch that
<sil2100> s/tomorrow/today
<sil2100> -_-
<brendand> sil2100, i nearly had a heart attack :P
<ribru> brb, lunch
<tvoss|food> sil2100, be careful, brendand needs to finish his testing
<Wellark> sil2100: ack. thanks!
<thostr_> sil2100: olli: Wellark: so no silo 3 then
<thostr_> sil2100: anything else you need from me?
<brendand> tvoss|food, ToyKeeper is doing the bulk of the testing now
<tvoss|food> brendand, ack
<tvoss|food> ToyKeeper, hey there :)
<ToyKeeper> Hmm?  Should I hide?
<ogra_> run !
<tvoss|food> ToyKeeper, nope, did you start testing, yet?
<sil2100> thostr_: no, just wanted to clear this out :)
<ToyKeeper> I'm testing rtm-013, if that's what you mean.
<tvoss|food> ToyKeeper, yup :)
<ToyKeeper> So far, I've managed to crash the dash, but unity8 itself kept going.
<tvoss|food> ToyKeeper, ack
<thostr_> sil2100: sure. everything should be clear now.
<ogra_> sil2100, this time we should really make sure that sommeone does at least a boot test of emulator and mako btw :)
<ogra_> (before we promote them)
<Wellark> ogra_: where would be the fun in that? ;)
<ogra_> heh
<brendand> ogra_, leave that to you :)
<ogra_> nah
<ogra_> my line is way to slow
<brendand> sil2100, where's silo 10!
<brendand> sil2100, hurry up :)
<ogra_> that needs someone with british gigabit :)
<brendand> ogra_, Ha!
<brendand> ogra_, that someone is not me
<ogra_> heh
<bfiller> ribru: can I get silos for line 75 and 76 please?
<brendand> sil2100, are we landing 10 as is? it's a bit of a beast
<sil2100> uh oh!
<sil2100> brendand: yeah, so we want to land that, product team gave it a +1
<sil2100> But Saviq is not around to clear some doubts about us waiting on vivid
<sil2100> btw. why silo 006 got signed off?
<sil2100> Oh, it was just the bot being silly it seems
<sil2100> ogra_: +1 on that
 * sil2100 repokes Saviq 
<sil2100> kgunn: hey! Do you know why Saviq mentioned that landing silo 10 is blocked on it landing for vivid? Is it just because of the formal rules?
<sil2100> Or is there something more to it?
<brendand> olli, sil2100 - it seems like we need a contingency plan for silo 10
<sil2100> brendand: could you explain?
<kgunn> sil2100: last i spoke with him, he was struggling with some AP tests on vivid
<kgunn> i know he broke up the silo
<kgunn> into ~1/2
<kgunn> to make it easier to "fix" along the way to land it all
<sil2100> kgunn: yeah, remember that too... but he mentioned that the vivid silo got published, but is blocked in -proposed
 * davmor2 lends sil2100 his big pointy prodding Saviq stick try this
<sil2100> kgunn: and that he's now waiting with setting the rtm equivalent as ready to land for the vivid one to migrate
<kgunn> sil2100: blocked on a autopkg test that isn't unity8 related afaik
<sil2100> kgunn: so I was wondering: why is the vivid one needed?
<kgunn> sil2100: also, saviq's understanding was that we can't land until we clear blockers
<sil2100> I know we have the rule: first vivid, then rtm - but in case of blockers like these this is exception-happy
<kgunn> first one being dbus / unity8 crasher
<kgunn> second being empty scope on rboot
<sil2100> Yeah, that's being fixed - but the empty scope on reboot is indeed in Saviq's silo 10
<sil2100> + other changes
<sil2100> BUt those other changes have been +1'ed by the product team
<kgunn> sil2100: he'll almost certainly be on again in a bit...
<kgunn> he can't control himself and always checks
<sil2100> So from what I see, silo 10 is good to hand-off to QA :)
<sil2100> kgunn: heh ;)
<sil2100> kgunn: he mentioned he'll be in a bit so I'm waiting
<kgunn> i'd prefer to get his info
<brendand> sil2100, looks like it's ok anyway
<sil2100> brendand: silo 10?
<brendand> sil2100, yeah
<sil2100> brendand: by ok what do you mean?
<brendand> sil2100, you said it's good to hand off right?
<ChickenCutlass> tvoss|food: what if you try strace -f -p PID
<ChickenCutlass> tvoss|food: see if that gives any info
<sil2100> brendand: I said I 'think' it's good to hand off, since there's no Saviq that would double confirm that ;p That's what I understood from him a few hours ago
<sil2100> brendand: you doing sign-off for it now?
<ChickenCutlass> wrong channel
<brendand> sil2100, no
<ogra_> heh
<brendand> sil2100, how long will we wait before deciding to go ahead with or without it?
<sil2100> I think  we'll wait until silo 13 passes sign-off - if Saviq doesn't get back by then, we'll probably just skip it...
<ribru> bfiller: rtm 11 and vivid 27, and congrats on being the 3000th silo assigned ;-)
<bfiller> ribru: yay!
<davmor2> bfiller: on a down side what you win is the opportunity to land another 3000silos
<veebers> ogra_: Can you remind me where the click rules went that we removed from the autopilot-touch package? dbus-properties or something similar?
<ogra_> veebers, dbus-property-service
<veebers> ogra_: awesome, thanks!
<balloons> ogra_, where does dbus-property-service hold it's bugs?
 * balloons notes this may or may not be related to above :p
<ogra_> balloons, bug 1385475 ?
<ubot5> bug 1385475 in dbus-property-service (Ubuntu) "error processing archive /var/cache/apt/archives/dbus-property-service_0.7_all.deb (--unpack): trying to overwrite '/usr/share/autopilot-touch/apparmor/click.rules', which is also in package autopilot-touch 1.5.0+14.10.20140812-0ubuntu1" [Critical,Confirmed] https://launchpad.net/bugs/1385475
<balloons> ogra_, no I'm trying to keep track of the click.ruled so they can be updated once https://bugs.launchpad.net/autopilot/+bug/1379488
<ubot5> Ubuntu bug 1379488 in Autopilot "apparmor denial during test runs for /home/phablet/autopilot/fakeenv/*/.cache/QML/" [Undecided,Triaged]
<ogra_> balloons, ah
<ogra_> balloons, well, but the bug should at least answer your question where to file :)
<balloons> so I stuck in on the bug, but you won't see it
<veebers> ogra_: regarding that bug (1385475), what needs to happen on the autopilot side? Are you still taking care of it or does there need to have more happen?
<ogra_> veebers, dbus-property-service misses a breaks and i didnt add the complete version ... i'll try to get to it tomorrow (for vivid at least)
<ogra_> i think AP should be fine
<veebers> ogra_: awesome, thanks :-) Just making sure I didn't miss something.
<sil2100> Ok, I go out now for a walk with my gf
<sil2100> Be back in some hour or so
<dobey> ribru: hi, can you take care of the comment on row 36 in spreadsheet please?
<ribru> dobey: oh ok sure
<dobey> thanks
<dobey> ribru: and if on another silo, i want to change the target from rtm to vivid, to i just change that column, then ask for a reconfigure, and then rebuild?
<dobey> i guess it's more than a reconfigure though, as the silo would need to be changed to ubuntu instead of ubuntu-rtm
<ribru> dobey: yeah I'll have to free it and reassign it, but yeah just change the row to say vivid and tell me which row
<dobey> ribru: ok, row 65
<ribru> dobey: erk, no silos free, but 2 are freeing, one sec before I can assign
<tvoss|food> okay, I'm off. o/
<dobey> ribru: sure, no problem. :)
<ribru> ok dobey, vivid 9
<dobey> ribru: thanks. building now
<ribru> dobey: you're welcome
<sil2100> olli: hey, so I contacted Saviq
<olli> k
<sil2100> olli: he'll be around in a some time, but he mentioned that silo 10 in overall is not entirely ready
<sil2100> That it needs some fixes still
<olli> ok
<sil2100> So I wouldn't count on landing it now
<olli> agreed
<sil2100> ToyKeeper: how's silo 13?
<olli> pointless
<sil2100> Published? :)
<sil2100> Ok, I see it's ready to be published
<sil2100> ribru: publishing silo 13
<ribru> k
<sil2100> crap, unapproved merge...
<sil2100> Ok, approving that one, it's only a packaging change
<Saviq> sil2100, olli, am around, can do a cherry-pick silo for rtm if we need
<Saviq> or land vivid 5 and sync that
<sil2100> olli, ogra_: silo 13 publishing, we just need to wait for it to migrate
<ogra_> awesome
<sil2100> Saviq: o/ how much more work would silo 10 need?
<olli> Saviq, does it make sense to do that
<sil2100> olli: how urgent is the scope bug?
<olli> not sure what vivid 5 fixes
<olli> scope blank is a promo blocker
<Saviq> olli, that it does
<olli> scope black can be argued
<Saviq> olli, so with 10 you still got black scope?
<Saviq> http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-005
<Saviq> the description should hopefully be complete enough
<Saviq> sil2100, so, I either need to rebuild/sync rtm 10 from vivid 5, or redo rtm 10 to just be cherry-pick of the promo blocker
<olli> Saviq, so I think we already have accepted the fact that it won't make it
<olli> landing vivid 5 seems rushed and increases risk
<olli> ^my view
<olli> happy to hear differently
<sil2100> olli: then maybe just cherry-picking the blank scopes fix?
<Saviq> olli, that's why I'm saying we can cherry-pick for rtm
<Saviq> olli, that could be done in... I'll venture to say Â½h, in parallel with vivid 5
<Saviq> 45mins
<Saviq> if I start right now
<alecu> Saviq: what's the branch that would be cherry picked?
<olli> pfffff
<Saviq> alecu, https://code.launchpad.net/~ted/qtmir/ual-pause/+merge/236033 and https://code.launchpad.net/~ted/unity8/dash-oom-score/+merge/238888
<olli> Saviq, that'd fix blank scopes, i.e. https://bugs.launchpad.net/bugs/1382039
<ubot5> Ubuntu bug 1382039 in qtmir (Ubuntu) "[TOPBLOCKER] Apps scope empty on boot" [Critical,Triaged]
<Saviq> olli, yes, *black* scopes I don't know of a fix for, if it's a different cause
<olli> correct
<Saviq> olli, mostly because I could not repro / things are in flux too much
<olli> if yu don't do it now for the next 45min then it won't land until noon utc tomorrow
<olli> pmcgowan, ^
<pmcgowan> olli, you are suggesting not talking all of rtm-10//vivid-5?
<olli> pmcgowan, debating
<pmcgowan> man thats a lot of good fixes
<pmcgowan> I am weak
<olli> saviq is offering to cherry pick from 5 to unblock timely promotion
<pmcgowan> right, promote then land the rest would work for me
<olli> if we go with rtm10 then that's only done earliest noon tomroorw
<olli> Saviq, let's do that
<olli> if you have the time & energy
<Saviq> olli, pmcgowan, if you guys want vivid 5/rtm 10
<Saviq> that we can do, too
<Saviq> it's just a bit more testing
<olli> but by tomorrow noon only, right?
<Saviq> olli, well, no, say, an hour+
<olli> or what was the noon utc statement referring to
<Saviq> olli, that was referring to me not coming back to work tonight, that ship has sailed ;)
<Saviq> olli, but I'd actually rather land it whole
<olli> k
<Saviq> if you guys ok with that
<Saviq> that would mean less time spent testing on mine and QA's side
<olli> well, it's going to get screwed up it's back with you anyways
<olli> k
<olli> go!
<Saviq> ok, need to wait for vivid 5 to build sources then
<Saviq> and sync 10
 * sil2100 feels responsible now for bringing poor Saviq back here
<olli> Saviq, want me to still test 10 on latest rtm?
<sil2100> :<
<Saviq> sil2100, don't be
<Saviq> sil2100, if I wasn't who I am, I wouldn't come ;)
<Saviq> sil2100, there's some leftover unity-notifications in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-005
<Saviq> sil2100, if you could drop that
<sil2100> Saviq: ah, teh bug in CI Train - yeah, let me remove that
<Saviq> sil2100, your look at https://code.launchpad.net/~mir-team/qtmir/gles-sync/+merge/240182 then, please
<sil2100> Saviq: just remember - in case of blocker fixes it's not required to land in vivid first, just so you know :)
<Saviq> sil2100, I know, but since it's a sync, I need to build the sources at least
<Saviq> sil2100, I'll test rtm first
<Saviq> assuming it does come first
<sil2100> Ok, looking good
<sil2100> Approving
<Saviq> sil2100, cheers
<sil2100> Thanks! :)
<sil2100> Saviq: to my defense I must say that I only wanted to call you to know if we can land silo 10 as it is ;)
<Saviq> sil2100, no need
<Saviq> (for defence)
<Saviq> sil2100, we're all in the same boat
<Saviq> sil2100, keep rowin'
<sil2100> hah ;)
<Saviq> sil2100, can we make it so it syncs vivid silo 5 + unity-notifications from vivid (that'd actually be a no-change rebuild, just wanted to get versions in sync... but maybe not worth it)
<sil2100> hmmm
<sil2100> It can be made, but we'd have to build in 2 steps
<sil2100> i.e. first sync:5 then change to sync:ubuntu,vivid etc.
<sil2100> Saviq: want to do it that way?
<sil2100> Versions in sync sound like a good idea
<Saviq> sil2100, yeah, let's do that then
<Saviq> sil2100, I think we can sync:5 now, let me see
<Saviq> sil2100, yeah, doing
<sil2100> Saviq: ok, once it's done let me reconf and resync
 * Saviq starts testing vivid + 5 then
<Saviq> ah, just publish already...
<sil2100> ;)
<sil2100> Ok, so it's still preparing packages, keeping an eye on that
<sil2100> Ok, I see silo 10 just uploaded sources to the PPA, should be safe to reconfigure in a moment
<Saviq> sil2100, it's ready for you
<olli> Saviq, sil2100 testing black scopes with silo 10 finally
<sil2100> Saviq: ok, so now you want unity-notifications synced from vivid, right?
<sil2100> From the archives?
<Saviq> olli, you might wanna wait 20mins
 * sil2100 double-checks
<Saviq> sil2100, yes
<sil2100> Ok, reconfiguring
<sil2100> And I'll rebuild as well
 * olli is divorced when still around in 20 min
<olli> :)
<Saviq> olli, or not, your call, contents should really be the same
 * ogra_ hugs olli 
<olli> Saviq, I can test tonight
<Saviq> olli, ok, good feedback anyway
<ogra_> olli, i really didnt mean to frustrate you !
<Saviq> from what's in silo 10 now
<Saviq> (to have)
<olli> it's not a blocker but a curiousity anyways
<olli> ogra_, you are not frustrating me per se
<olli> it's the gesamtsituation I am not happy with
<ogra_> yeah, lets fix it then ... ;)
<olli> Saviq, sil2100, didn't realize how late it is... I have to run now already
<olli> sil2100, Saviq I'll test later
<Saviq> o;
<Saviq> o/
<sil2100> olli: ok!
<sil2100> o/
<olli> call my cell (801 210 0647) if you need anything
<sil2100> Have fun :)
<sil2100> Saviq: so, syncing sources from vivid as we speak
<olli> thx guys!
<sil2100> Saviq: just remember that now this silo is configured as a sync from vivid, so any 'build' press will sync from vivid
<sil2100> olli: yw!
<Saviq> sil2100, but we'll only build unity-notifications, right?
<Saviq> sil2100, yeah, it's good
<sil2100> Saviq: yeah, we're only building unity-notifications right now :)
<Saviq> sil2100, will keep in mind
<sil2100> Since I specified it directly
<olli> sil2100, Saviq pls ping me with what silo I should test then
<sil2100> It's a bit of a hack, but at least it works ;D
<sil2100> olli: sure thing, thanks o/
<Wellark> queuebot: where dbus-cpp
<Wellark> stupid..
<sil2100> Wellark: queuebot doesn't have that functionality ;)
<sil2100> Wellark: but the dashboard should
<Wellark> sil2100: :)
<Wellark> could someone merge and clean silo 13 (rtm) please..
<Wellark> so I can kick a rebuild on silo 3
<sil2100> Wellark: oh, it landed? Let me do that
<sil2100> Yay for fast migration
<sil2100> Love ubuntu-rtm for that
<Wellark> sil2100: thanks!
<veebers> trainguards: Am I able to get a silo assigned for line 77?
<ribru> veebers: sorry, there are no free vivid silos
<veebers> ribru: ah, no worries.
<veebers> ribru: Would it be possible to get one at your EOD tomorrow? (as tomorrow is my Sat) so I can do testing on Sunday and should have it freed up on my Monday?
<ribru> veebers: sure, but let me just see if I can't free one up now
<veebers> ribru: if silos are tight it would probably be better to get it tomorrow arvo as it will take at least ~6 hours of testing to clear it out (which is past my EOD today)
<veebers> and thus don't want to clog up the silos for tomorrow etc.
<ribru> veebers: hmm ok, can you just send me an email to remind me to assign it? or ping me at my EOD (2 hours from now tomrrow)
<veebers> ribru: can do. thanks
<ribru> veebers: you're welcome
<veebers> ribru: just to clarify, silo numbers are pretty tight right? It's not that I asked at the wrong time?
<ribru> veebers: yes there are literally zero free for vivid. but I think there's some confusion going on, because there's a bunch that were assigned and then *never built* when we switched them from utopic to vivid. not sure why they're not built, trying to figure out if any are just abandoned or what
<veebers> ribru: ack
<ribru> bfiller: bzoltan_ cyphermox lool: hey you guys have vivid silos assigned to you that were never built. what's going on? can I free them? are you waiting for something?
<ribru> veebers: just found one spreadsheet row that had two silos assigned to it somehow, so that's a thing. freeing...
<sil2100> Saviq: anything else we need to do besides waiting for things to build re: silo 10? :)
<Saviq> sil2100, it's already built, I'm running ap on vivid 5, should finish within 5 mins, then 3 mins of playing around and it'll be good, then I'm jumping onto rtm10
<Saviq> some half hour later we should be able to ACK it
<sil2100> \o/
<sil2100> ToyKeeper: are you around?
<ToyKeeper> sil2100: I'm kinda waiting until the build with rtm-013 is done.
<ToyKeeper> (have a lot of things to do today, and it seems the best time to do everything else is during the build)
<Saviq> sil2100, vivid is +1
<Saviq> â
 * Saviq flashes rtm
<sil2100> Yay
<sil2100> ToyKeeper: we waiting for silo 10 to land before kicking a new image
<sil2100> ToyKeeper: so we'll actually need someone to sign off that silo...
<ToyKeeper> sil2100: Er, I thought rtm-013 was the only one going in and we were totally done with silos for now.
<ToyKeeper> sil2100: So, someone needs to test 10 first?
<brendand> sil2100, is 10 still not ready?
<sil2100> ToyKeeper: yeah, so there was a final decision here that we want 10 before an image
<sil2100> So the promotion testing might not be finished today even I suppose
<sil2100> brendand: it's built, but Saviq is testing it, as it required some changes from the previous state
<brendand> ToyKeeper, when are you planning to EOD?
<ToyKeeper> brendand: Looks like it'll be a few hours later than planned.
<sil2100> No need for staying longer - in case there's no time to finish the promotion testing, we can just leave it for the EU morning
#ubuntu-ci-eng 2014-10-31
<ToyKeeper> sil2100: So...  is someone going to set the tested flag to 'yes' so it'll show up in trello?
<sil2100> ToyKeeper: yeah, once it's ready Saviq will set it to Yes - I think he's finishing up some final tests from his side
<sil2100> Saviq: right?
<brendand> sil2100, is 10 ready to test otherwise?
<Saviq> sil2100, just starting the rtm testing, but am positive, gimme Â½h
<ToyKeeper> sil2100: Whoa...  wait.  We're going to try to land something with 19 different bug fixes in it, last-minute, right before the final build?
<sil2100> ToyKeeper: yep..!
<sil2100> ;)
<sil2100> pmcgowan wanted those nifty fixes in along with the blocker fix
<Saviq> ToyKeeper, if it makes it any easier, they are really self-contained things
<Saviq> and not huge changes either
<ToyKeeper> There sure are a lot of them though...  we've been aiming for one fix per image, especially near deadlines, not ~20 all in one bundle.  Very high-risk even if the individual changes aren't huge.
<sil2100> slangasek: hi! Would you be around here to kick off a new RTM image when silo 10 gets published and lands in the archive?
<sil2100> ribru: if you could make sure silo 10 gets published after QA then it would be awesome
<slangasek> sil2100: what's the eta on that? I can be around this evening but will be away from the computer very shortly
<sil2100> I really need to EOD now, have to pick up my car at 7 am
<sil2100> slangasek: let me think: aroung 20 minutes for Saviq to finish testing, ~30 min for ToyKeeper's sign-off, some time for migration... I guess not earler than 1.5h from now?
<slangasek> sil2100: ok, I should be back around that time
<ToyKeeper> As a general rule, to get a good estimate, form your best guess (in detail), then double the number and bump up the unit by one.  So, if the expectation is 1.5 hours, the realistic expectation would be 3 days.
<brendand> Saviq, it's meant to fix https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1381731 ?
<ubot5> Ubuntu bug 1381731 in ubuntu-system-settings (Ubuntu) "[oobe] Shutdown dialog does not appear in welcome wizard" [High,In progress]
<Saviq> brendand, it's meant to prepare for the fix in ubuntu-system-settings
<sil2100> Thanks everyone!
<sil2100> o/
<sil2100> Goodnight
<ToyKeeper> sil2100: There's no way I can verify 20 bug fixes in 30 minutes, especially since it takes ~15 minutes just to flash and install.
<brendand> ToyKeeper, let's not aim to verify them all then
<brendand> ToyKeeper, obviously not ideal, but
<ToyKeeper> ... final image candidate, big high-risk landing, ... don't verify it?  Can I retroactively call in sick today?
<cwayne> brendand: i can help if you guys want
<brendand> ToyKeeper, it's more important it doesn't cause any big regressions
<Saviq> brendand, ToyKeeper, FWIW, I *am* verifying them all
<ToyKeeper> brendand: If you want to sign off without testing, you're welcome to.  :)
<brendand> ToyKeeper, i didn't suggest that
<Saviq> have already done so for vivid, and will for rtm in a moment, after autopilot finishes
<Saviq> slangasek, if you're still around, could you please publish vivid silo 5 for me
<brendand> ToyKeeper, btw you know where to find the sanity tests right?
<ribru> Saviq: I'm around to publish things
<Saviq> ribru, ah, I got used to you being on holidays ;)
<ToyKeeper> brendand: I think so, but it doesn't hurt to send the link again.
<ToyKeeper> brendand: Oh, actually I still have it open.
<brendand> ToyKeeper, yeah i was about to say :)
<ToyKeeper> I was planning to pick up a bluetooth headset on my way back from dinner so I can do the sanity tests completely, but it looks like I might not be going at all.
<ToyKeeper> (should be leaving about now)
<brendand> ToyKeeper, you go, i'll deal with the silo and you can test the image after you get back
<ToyKeeper> brendand: You sure?
<brendand> ToyKeeper, yes
<ToyKeeper> brendand: Okay, I'll get going on the image tests right after the build finishes...
<brendand> Saviq, where's that bug olli confirmed?
<Saviq> brendand, black scopes is it?
<brendand> Saviq, i don't see it amongst the million or so fixes in that silo :P
<brendand> Saviq, yeah that one
<Saviq> brendand, yeah, because it does not fix it (or well, not confirmed that it does)
<Saviq> brendand, I couldn't reproduce, olli didn't have time yet
<brendand> Saviq, :/
<brendand> Saviq, now i'm really confused
<Saviq> brendand, the more important one was different
<brendand> Saviq, ok?
<brendand> Saviq, enlighten me
<Saviq> brendand, http://pad.lv/1382039
<ubot5> Launchpad bug 1382039 in qtmir (Ubuntu) "[TOPBLOCKER] Apps scope empty on boot" [Critical,In progress]
<brendand> Saviq, ahhh ok
<Saviq> brendand, the other one is bug #1386653
<ubot5> bug 1386653 in unity8 (Ubuntu) "[TOPBLOCKER] Scopes fail to launch when the network stack is not up" [Critical,Confirmed] https://launchpad.net/bugs/1386653
<Saviq> AP pass, /me goes for testing
<brendand> Saviq, i'll focus on those two fixes and regression testing
<brendand> Saviq, you make sure the other fixes are verified
<Saviq> brendand, doing that, + test plan
<brendand> lovely, just had a unity8 crash - with 13 and 10 installed
<cyphermox> ribru: ubuntu silo 25 can be freed, it's not up to me, it's up to tvoss doing some testing there, but we can re-do that change if necessary, it's trivial
<cyphermox> ribru: for silo 16 I'll check back with awe and abeato tomorrow, to see whether they tested it. it's a direct upload, so they very well could have.
<cyphermox> arf, maybe not, there's nothing in it
<brendand> Saviq, is it just me or has silo 10 somehow removed the autobrightness control on the battery indicator?
<cyphermox> in any case, we'll finish off that landing completely tomorrow, it's simple to test and to build the package
<Saviq> brendand, hmm just you, is here fine for me
<Saviq> brendand, care to restart indicator-power
<brendand> Saviq, hmm yeah
<brendand> Saviq, even after i rebooted it didn't come back though
<brendand> Saviq, that's a known bug though i guess?
<Saviq> brendand, first I've heard of it
<cwayne> i've got the autobrightness here with silo 10
<ribru> cyphermox: thanks, oh just noticed that one was still utopic as well, doubly should be freed ;-)
<Saviq> brendand, +1 from me
<Saviq> verified all the fixes that fix, did not find regressions
<Saviq> it's still quite crashy though, seems silo 13 did not solve everything
<brendand> Saviq, i got a dash crash
<Saviq> brendand, got a .crash file?
<brendand> Saviq, no i didn't keep it
<Saviq> brendand, yeah, so, crashes and black scopes we will start investigating tomorrow
<Saviq> brendand, as indeed I did not see stability promised by silo 13
<brendand> Saviq, anyway i'd better go to bed now. we can roll the dice with this one
<Saviq> but no more than before 10
<Saviq> brendand, I'm confident in this one, if that's of any help
<Saviq> been testing it two days now
<brendand> Saviq, take it away
<brendand> Saviq, you should probably go to bed too no :)
<Saviq> ribru, rtm 10 up for publishing please
<brendand> Saviq, let ribru handle it
<Saviq> brendand, beds are for wussies
<Saviq> ;)
<brendand> well i'm a wussie then - night
<Saviq> o/
<Saviq> brendand, thanks
<brendand> almost
<Saviq> ribru, looks like spreadsheet hates us again, did not update the status
<brendand> ribru, don't forget to kick an image as soon as 10 (and 13) have landed
<ribru> I don't think i can kick rtm images....
<ribru> Checking statuses
<ribru> Saviq: this is some new kind of evil from the spreadsheet. usually when "the status doesn't update" there's some field missing that I just fill in. in the last few days I've seen a number of cases where nothing is missing but it just doesn't show up anyway. it's totally fucking bizarre
<Saviq> ribru, good we're getting something to replace the spreadsheet then :)
<ribru> Saviq: and not a moment too soon!
<ribru> ok, publishing
<ribru> slangasek: OK landing 10 is landed, can you kick an rtm image?
<slangasek> indeed I can
<ribru> slangasek: thanks
<slangasek> thanks, just got back and was looking for its status
<slangasek> ribru: running
<ribru> slangasek: thanks!
<ribru> ToyKeeper: ^^^ looks like the image should be ready for testing on an hour or so
<ToyKeeper> ribru: So...  sometime around now?
<ToyKeeper> Let's see, did silo 10 land?
<ribru> ToyKeeper: it's definitely landed... slangasek ran the image build
<ToyKeeper> ribru: Are we expecting a notification from imgbot about the build finishing?
<ribru> ToyKeeper: i would assume so, but not sure...
<ribru> ToyKeeper: can you just try flashing to see if the image is there? My laptop isn't handy
<ToyKeeper> ribru: It should be image 139?
<ribru> ToyKeeper: sounds right i think.
<ribru> imgbot: stunt
 * imgbot rolls on its back and purrs
<ribru> Hmmm
<ToyKeeper> 139 is downloading...  not sure how long it has been there.
<olli> does 139 have silo 10 & 13?
<olli> ToyKeeper, I can't repro https://bugs.launchpad.net/ubuntu/+source/unity-scope-scopes/+bug/1386653 anymore
<ubot5> Ubuntu bug 1386653 in unity8 (Ubuntu) "[TOPBLOCKER] Scopes fail to launch when the network stack is not up" [Critical,Confirmed]
<olli> Saviq, ^
<ToyKeeper> olli: 139 should have 10 and 13 in it.
<ToyKeeper> Assuming it passes sanity testing, we'll be sending it to PES and will start on the really detailed testing.
<olli> that's the plan
<olli> ToyKeeper, do you see u8 crashing when working the indicators?
<olli> spec nw-indicator?
<ToyKeeper> olli: Not yet.
<ToyKeeper> olli: However, I tried to get u8 to crash for an hour with silo 13 installed, and wasn't able to get it to fail.  I got six other crashes, but not u8.
<ToyKeeper> olli: ... and with 13+10 installed, brendand said he got a unity8 crash.
<olli> hm, i crashed it twice in 1 session
<olli> but can't repro now :/
<ToyKeeper> That's worrisome...  I had a feeling that 10 might have un-fixed the crash fix in 13.
 * olli brings baby to bed
<ToyKeeper> In general, the size and hasty landing of silo 10 makes me nervous.
<ToyKeeper> olli: Ah, there it is.  Got unity8 to crash.  All I did was accept an incoming call.
<ToyKeeper> I get the feeling 139 is fail and we'll have to back out silo 10.
<olli> ToyKeeper, interesting
<ToyKeeper> With three of us trying to crash unity8 for at least an hour each (image 138 + silo 13), it was unshakable.  But image 139 is just as crashy as ever.
<ToyKeeper> olli: Did you see the change list in silo 10?  https://trello.com/c/enrjHgsd/
<olli> I saw it
<olli> if it hadn't landed today it would have landed tomorrow, Saviq just "happened" (sil2000 called him) to show up and fix it today instead of tomorrow
<olli> ToyKeeper,
<Mirv> mornings
<olli> hey Mirv
<Mirv> hey olli
<olli> ToyKeeper, not sure if this was only the procedure when you helped with 114... but maybe... it might be more helpful if you could file the bugs (spec. the crashes) before you EOD, rather than pile it up (liek I think we did with 114)
<ToyKeeper> olli: Yeah, I've been doing it that way ever since.
<olli> awesome!
<olli> I am brainfried, logging off, good luck ToyKeeper!
<ToyKeeper> Thanks.  I can tell you already this failed sanity testing.
<ToyKeeper> I'm just trying to measure how *much* it failed.
<Mirv> so I guess I'll locally prepare 010 revert to have something ready when Savi_q and sil2100 wake up in a couple of hours?
 * Mirv does that
<olli> Mirv, Saviq is going to cherry pick from 10 if the whole silo fails
<olli> not sure what though
<Mirv> right
<tvoss|food> good morning
<brendand> sil2100, today will be fun
<Wellark> brendand: every day is a fun day!
<brendand> Wellark, today will be really fun
<Wellark> brendand: you got some mushrooms stored away for special occasions?
 * Wellark wants whatever brendand has
<brendand> Wellark, yeah i think something special is needed ATM
<Wellark> brendand: *hug*
<brendand> Wellark, well that's special
 * brendand needed that
<sil2100> Fun fun
<sil2100> So, did silo 10 end up landing?
<sil2100> I see it did
<brendand> sil2100, yes but ToyKeeper found issues still
<sil2100> I don't see a new image with it though
<Mirv> sil2100: it did, and it's suspected it _might_ undo the fix from 13, crash wise
<sil2100> ...
<brendand> sil2100, as if 13 either didn't land properly or 10 reverted some aspect of it
<Mirv> 139 should be ready, no changelog though on ogra's site
<brendand> sil2100, i'm testing 139 now
<brendand> sil2100, so far i didn't hit any crashes
<sil2100> !
<sil2100> brendand: you know what I want to say now?
 * sil2100 whispers "shipit"
<Mirv> maybe it's also possible the 13 never fixed it completely
<brendand> Mirv, or maybe there are just other crashes around
<sil2100> brendand: you mentioned yesterday that when you were testing silo 13 that you still encountered crashes, right?
<ogra_> hmpf
 * ogra_ wonders why the bot stayed quiet
<brendand> sil2100, not after i reset the device
<sil2100> Just hope that indeed we don't have any additional instabilities
<sil2100> But I suppose that's a risk that management wanted to take
<ogra_> well, reading selenes summary it seems we got a lot worse
<brendand> ogra_, that's not levelling with my my experience here though
<brendand> i'm still testing
<brendand> it definitely hasn't gotten worse
<brendand> just not all the way better maybe
<ogra_> ah, sounded very pessimistic
<ogra_> igonre the bot ... it might spit out nonsense soon
<ogra_> (seems the watchdog on the image build server was killed somehow)
 * popey refrains from commenting on ogra_ making sense
<ogra_> heh
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/rtm/139.changes
<ogra_> in case you still need it
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/4.changes for vivid
<sil2100> \o/
<sil2100> ogra_: is there a way to distinguish .changes files for vivid from the utopic ones?
<ogra_> sil2100, via the path ?
<ogra_> (and usually the bot only announces them next to the image number and distro name)
<sil2100> Ah, you moved the old ones to 'utopic'
<ogra_> yeah
 * ogra_ needs to make a script to fix the links of the archived ones
 * ogra_ sees the smoketests and dances ... 
<ogra_> finally
<Mirv> FWIW, the new image is definitely more stable on mako than what it was yesterday
<Mirv> yesterday I was quite constantly seeing 100% unity8 CPU usage after a boot, and later a crash (or two), after it possibly stabilized. none of that today.
<ogra_> http://paste.ubuntu.com/8758270/
<ogra_> thats the results of the topafter.log in the unity8 test
<ogra_> i *think* we have a media-hub problem
<ogra_> just guessing by these 200% CPU usage
<sil2100> Oooh, one failure in UITK o/
<Mirv> sil2100: \o/
<Mirv> o/
<Mirv> \o
<ogra_> well, so it seems your smkoetest clearly exposes the unity8 crash
<sil2100> Which one? The dashboard one?
<ogra_> the unity8 smoketest
<sil2100> I still see the same crashes there indeed
<ogra_> sil2100, http://paste.ubuntu.com/8758270/ topafter
<ogra_> hmm
<ogra_> unhappy firefox
<ogra_> weird
<ogra_> after half a connect i get "server not found" in my face
<ogra_> (all other websites work fine)
<ogra_> can you gusy connect to the hangout ?
 * ogra_ curses
<tvoss> sil2100, ping
<sil2100> tvoss: pong
<tvoss> sil2100, so what's the promotion status=?
<ogra_> still crashing
<sil2100> tvoss: we're still testing
<tvoss> sil2100, ogra_ please note that 13 never was meant as the silver bullet
<tvoss> ogra_, still crashing isn't helpful. What exactly is crashing and where? What does the stack trace say?
<ogra_> tvoss, i have no idea, ask QA
<tvoss> brendand, ping
<popey> tvoss: everyone is on a call right now...
<brendand> tvoss, i have a stack trace here
<popey> you'll get longer answers in a bit
<tvoss> brendand, shoot
<brendand> tvoss, well a crash file anyway
<tvoss> popey, sure
<brendand> tvoss, i need to retrace it
<tvoss> brendand, no need to, just shoot the crash file
<Mirv> brendand: tvoss: regarding mako with today's image, I filed bug #1388019, .crash file at http://people.canonical.com/~tjyrinki/unity8_apport/20141031/_usr_bin_unity8.32011.crash
<ubot5> bug 1388019 in unity8 (Ubuntu) "unity8 crashed with SIGSEGV in core::dbus::Bus::handle_message()" [Undecided,New] https://launchpad.net/bugs/1388019
<Mirv> ogra_: so if I've id 5946f7c6-60e2-11e4-be34-fa163e75317b , how do I fetch it?
<tvoss> Mirv, is mako blocking promotion?
<brendand> Mirv, errors.ubuntu.com/oops/<id>
<davmor2> so on start up the following crashed unity8 unity8-dash app-launch and scopes scopes runner \o/
<ogra_> Mirv, what brendand said
<tvoss> Mirv, sorry, that's in media-hub client as far as I can see from the crash file
<ogra_> if the automatic retracer did its work already you should get a stack
<brendand> tvoss, http://people.canonical.com/~brendan-donegan/_usr_bin_unity8.32011.crash - careful it's 14MB
<tvoss> brendand, top of the stack trace points towards qtqml
<brendand> tvoss, yeah
<brendand> Mirv, ^ ?
<ogra_> Mirv, i have a few of the media-hub ones here too
<tvoss> Mirv, ogra_ is there any chance we can get a better stack trace?
<ogra_> tvoss, only with the m,atchin dbg packages installed
<ogra_> tvoss, ask pitti, perhaps there is a way to squeeze more info out of the retracer
<tvoss> ogra_, I will try to retrace locally
<davmor2> tvoss: http://davmor2.co.uk/~davmor2/unity8-crash/
<ogra_> davmor2, you can ignore ubuntu-app-launch ... thats only moaning about a duplicated icon
<ogra_> (fitbit)
<tvoss> davmor2, sorry, cannot access the individual files, insufficient permissions
<davmor2> tvoss: give me 5
<tvoss> davmor2, what triggered the crash?
<Mirv> tvoss: surely mako is not blocking, just in case it's useful (and I don't have krillin)
<davmor2> tvoss: typing in the simpin
<Mirv> brendand: ogra_: thanks! no backtrace yet https://errors.ubuntu.com/oops/5946f7c6-60e2-11e4-be34-fa163e75317b
<Mirv> I was trying /problem/ url
<Mirv> ogra_: so far I have only unity8 crasah
<brendand> Mirv, StackTraceTop points to media-hub though
<Mirv> brendand: true
<Mirv> and via media-hub to dbus-cpp
<ogra_> tvoss, btw, in case that helps unity8 is also crashing during smoke testing ... we have a test that loops ten times over the processlist and CPU usage ... this is how the system looks afterwards http://paste.ubuntu.com/8758270/
<davmor2> tvoss: try again
<tvoss> Mirv, sure, why does that point to dbus-cpp?
<ogra_> see StacktraceAddressSignature
<ogra_> it is the lowest in the stack
<tvoss> ogra_, that's at best a heuristic, sorry
<ogra_> (well, above libc)
<tvoss> ogra_, sure, but you want to look at the highest in the stack to assign to a project
<ogra_> media-hub then i guess
<Mirv> tvoss: StacktraceTop's first two lines are in libmedia-hub-client.so.2 and the next two lines to libdbus-cpp.so.4, then core::dbus::Bus::handle_message(std::shared_ptr<core::dbus::Message> const&) () from /usr/lib/arm-linux-gnueabihf/libdbus-cpp.so.4
<ogra_> and having it hang at 200% CPU in tests  as well as always having a media-hub and scoperunner crash file created alongside unity8 also points to one of these three
<tvoss> Mirv, sure, with that, it segfaults in media-hub obviously
<ogra_> the issues started somewhere in the 120s
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/rtm/123.changes
<ogra_> this looks like we got a *lot* of media related landings there
<ogra_> https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-October/000753.html perhaps ?
<tvoss> ogra_, probably, I will look into the stack trace as soon as retracing finished
<tvoss> davmor2, I'm on the 10th reboot entering pin, no crash for unity8 here?
<ogra_> and there was a later one in 126
<ogra_> http://launchpadlibrarian.net/188170974/media-hub_2.0.0%2B14.10.20141016-0ubuntu1_2.0.0%2B14.10.20141024~rtm-0ubuntu1.diff.gz
<davmor2> tvoss: I have 2 lock sims and it never fails to crash
<ogra_> tvoss, sometimes it only fails after a while of usage ... but i could get it pretty reliably in the past when bein fast entering SIM PIN and then quickly the unlock PIN
<ogra_> it also happens often when you get a notification for SMS
<thostr_> ogra_: can you pass us the scoperunner crash file?
<sil2100> thostr_: it's on the krillin dashboard if anything
<sil2100> On each test suite
<ogra_> thostr_, http://people.canonical.com/~ogra/ubuntu-touch/_usr_lib_arm-linux-gnueabihf_unity-scopes_scoperunner.32011.crash
<ogra_> right, what sil2100 said too
<ogra_> just click any of the test names and scroll down on http://dashboard.ubuntu-ci:8080/smokeng/utopic/touch_stable/krillin/139:20141031:20141028-3ca60be/649/
<Saviq> sil2100, Mirv, so we reverted 10 rtm did we?
<sil2100> Saviq: no, why?
<Saviq> sil2100, /me reading the backlog is all
<Mirv> Saviq: no, it's just an option
<Saviq> ah ok
<Saviq> lemme know if I can help
<sil2100> Saviq: rtm 10 is still in the image, QA is still dogfooding to make sure if it's causing issues or not
<Saviq> kk
<sil2100> Saviq: but it has been mentioned that unity8 is still crashing somewhere, but it's currently hard to get a completely objective opinion
<tvoss> Saviq, could you help retracing http://davmor2.co.uk/~davmor2/unity8-crash/_usr_bin_unity8.32011.crash with all necessary debug packages installed?
<sil2100> So we're waiting
<Saviq> tvoss, doing
<tvoss> Saviq, ack and thx
<davmor2> I'm going to clear out my /var/crash now so if I see any new ones I know they are fresh
<thostr_> ogra_: thanks
<davmor2> thostr_: there is one in http://davmor2.co.uk/~davmor2/unity8-crash/ to incase you want to compare
<brendand> davmor2, camera videos not getting thumbnailed, is that a known issue?
<davmor2> brendand: they are for me
<davmor2> brendand: let me make one
<brendand> davmor2, they appear in the video scope?
<thostr_> ogra_: the scope runner crash is actually a crash in events scope...
<davmor2> brendand: http://people.canonical.com/~davmor2/video-tn.png
<cwayne> thostr_: we're aware of that crash, the dev is spending some time today to fix
<thostr_> cwayne: are we both talking about https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1382567
<ubot5> Ubuntu bug 1382567 in The Savilerow project "Top Crasher: /usr/lib/arm-linux-gnueabihf/unity-scopes/scoperunner:*** Error in `/usr/lib/arm-linux-gnueabihf/unity-scopes/scoperunner': free(): invalid pointer: ADDR ***" [Undecided,Confirmed]
<cwayne> thostr_: yes
<sil2100> ogra_: btw. sorry for sending out G+ announces for landing e-mails with one day delay, but the lists.launchpad.net ML archive refreshes really really slow, usually I need to wait like 2 hours for the mail to appear there
<sil2100> So I usually need to share it in the morning
<thostr_> cwayne: let's update the bug and add the rtm tag to make it visible, otherwise we need to answer the same questions x times...
<cwayne> thostr_: sure, i was thinking of closing that one and putting it in hanloon, and then linking the hanloon bug from there
<thostr_> cwayne: works for me.
<thostr_> can you put me and Pete on the watcher list?
<ogra_> sil2100, np
<cwayne> thostr_: done
<thostr_> cwayne: thanks
<ogra_> brendand, i think jhodapp works on something camera/thumbnail related currently
 * sil2100 needs to AFK for ~1h
<davmor2> biab restarting server
<brendand> tvoss, did you see ToyKeeper 's crash file? https://launchpadlibrarian.net/188758251/_usr_bin_unity8.32011.crash
<tvoss> brendand, haven't looked at it in depth, yet
<tvoss> brendand, trying to prove something, gimme 15
<brendand> olli, good morning :)
<olli> that remains to be seen ;)
<ogra_> heh
<olli> a friendly hello to everyone though
<cwayne> such optimism :)
<davmor2> cwayne: what's optimism?
 * ogra_ is really scared to upgrade to 139 ... bu i guess i shoulld to collect more crashers
<cwayne> davmor2: it's that thing you have right before something goes horribly wrong
<davmor2> cwayne: nope doesn't ring a bell
<davmor2> cwayne: are telling me that you expect things to work?
<cwayne> on occasion
<ogra_> davmor2, wow
 * ogra_ just entered his sim pin on 139
<ogra_> this is gross
<davmor2> ogra_: did it crash horribly?
<ogra_> well, it didnt scream or some such ... so not sure about horribly
<ogra_> but yeah, it went directly to the spinner
<davmor2> brendand, tvoss: ^
<ogra_> and weather still gets me totally wrong data on the dashboard
<ogra_> (200km away)
<ogra_> hmm, and all events in the dashboard seem to be in some weird TZ
<ogra_> definitely not in mine
<cwayne> ogra_: that's a bug in remote scopes
<davmor2> ogra_: ditto but that known and isn't going away any time soon so ignore that ;)
<cwayne> ogra_: that bugs fixed in next custom tar release
<cwayne> (the events one)
<brendand> olli, the short version is that there appear to still be some crashers around
<ogra_> cwayne, ok
<olli> brendand, I guessed :)
<cwayne> the weather channel one is that we're not properly passing the lat/lng to remote scopes, so it's using geoip
<olli> and saw it myself, installed 139 shortly after it saw daylight
<tvoss> ogra_, how many sims do you have installed?
<brendand> olli, personally it feels way better than 138
<popey> same here
<popey> not had a single unity crash yet
<ogra_> tvoss, two ... one with PIN one without
<brendand> davmor2, i just succesfully unlocked two sims
<tvoss> ogra_, same here, I'm on the 15th reboot and no crash when entering my SIM PIN
<brendand> davmor2, you have magic sims
<ogra_> brendand, and i just succesfully chashed the session unlocking one
<ogra_> let me reboot
<olli> popey, try switching flight on/off, repeat, maybe do wifi on with flight off
<olli> boom
<davmor2> brendand: seems ogra_ has the same magic sims in Germany though
<popey> olli: nope â»
<olli> but I couldn't repro last night reliably
<brendand> ogra_, we should gather all the crashes and figure out where they're coming from and decide what the next course of action is
<popey> hmm, on welcome screen, double tapping no longer works
<brendand> olli, functionally speaking though it seems fine
<popey> so can't switch away from "No text messages sent today"
<ogra_> brendand, i thought thats what we currently try :)
<olli> nope as in won't try or nope as in doesn't crash
<popey> olli: nope as in won't try right now â»
<olli> heh
<ogra_> tvoss, reproduced sim unlock crash again
<brendand> ogra_, yeah - just re-iterating
<ogra_> seems very reliable for me
<popey> olli: yeah, i can turn wifi on with flight mode on â¨
<popey> we should probably hide the wifi switch when flight mode on. the whole UI should block
<tvoss> popey, that's meant to work actually. For when you are on a plane
<brendand> popey, err no - you need to be able to turn wifi on in flight mode
<tvoss> popey, with in-flight wifi support
<popey> oh okay.
<popey> olli: flipped flight on/off, wifi off/on.. no crash yet
<popey> playing music pauses briefly during flight mode switch
<brendand> popey, known issue
<popey> k
<brendand> davmor2, apart from sim pin unlock what other crashes are you seeing?
<ogra_> this time i could log in ... it only crashed 5sec after
<popey> i dont have SIM locks, which may be why I'm not seeing any of this.
<davmor2> brendand: still testing once I'm in the phone it is behaving better than 138+silo 13 but I wouldn't say it was perfect
<brendand> davmor2, well no - but have you had any crashes apart from the SIM unlock one?
<olli> brendand, davmor2 are all your devices on the latest partition scheme?
<davmor2> olli: mine is
<ogra_> why would that matter ?
<ogra_> it moves 500M around, thats all
<brendand> olli, yeah
<ogra_> shouldnt have any impact
<ogra_> (i'm not btw)
<olli> ogra_, that was the only difference I could think of between my device and a device thostr_ has where I could repro a bug and he couldn't
<olli> modulo country specific things such as operator
<ogra_> olli, different SIMs ...
<olli> sure
<ogra_> i think the fact that davmor2 and i can reliably crash it on sim unlock (or shortly after) kind of points there
<brendand> i could too before silo 13
<brendand> now i can't
<olli> ogra_, this was unrelated and just trying to make sure QA is on the latest official state
<olli> this = my q
<ogra_> my top SIM is without PIN and prepaid ... my bottom one is with PIN and not prepaid
<ogra_> i use data from SIM1 and everything else from SIM2
<brendand> ogra_, did anyone retrace one of those crashes and see where it is?
<tvoss> brendand, we are on that
<ogra_> brendand, yes, davmor2 gave his .crash files to tvoss
<tvoss> ogra_, I have exactly the same setup modulo the upper sim being roaming
<ogra_> davmor2, whats your SIM setup ?
<ogra_> (see above)
<tvoss> ogra_, so this is after boot, without the wizard, correct?
<ogra_> i havent seen any crashes after this so far
<ogra_> tvoss, for me it is, i think davmor2 did a fresh install
<ogra_> (i did OTA)
<davmor2> ogra_: T-mobile and orange both are EE
<ogra_> davmor2, both PIN locked ? only one ? where is your data set to, where the calls/SMS ?
<davmor2> tvoss: I get it to crash every reboot on the sim pin
<davmor2> ogra_: both sims pin locked
<ogra_> k
<tvoss> davmor2, does it crash on first or second sim? anything systematic?
<brendand> ogra_, are you reproducing that crash every time?
<davmor2> tvoss: on first boot it crashes on both, there after normally after entering the first
<ogra_> tvoss, well, given i can crash with only one PIN locked SIM i dont think that matters
<ogra_> brendand, yes
<tvoss> davmor2, how can you crash on both? ;)
<ogra_> brendand, rebooted 5 times, crashed it 5 times
<brendand> davmor2, what if you swap the sims?
<brendand> davmor2, does it crash on the first one then?
<ogra_> one time it only crashed after login
<ogra_> the other rounds immediately after entering the PIN
<brendand> davmor2, alternatively just have the second one locked
<davmor2> tvoss: it crashes restart second sim pops up to unlock and crashes again
<ogra_> oh
<ogra_> so you get two crashes for two PIN unlocks ?
<ogra_> thats a pretty good indicator
<davmor2> ogra_: only on first boot after the it is only entering the first sim pin
<ogra_> iteresting
<davmor2> brendand: right trying with 1 sim
<cjwatson> Mirv: silo 2 - please note that calibre is part of the in-progress imagemagick transition.  Hopefully we'll finish that soon, but if you try to land this before then, it will be stuck
<davmor2> brendand: so contract sim on it's own and it boots with no issues, now I'll try the payg sim on it's own
<Mirv> cjwatson: ok. there are open qtpim (renato) and UITK (sdk team) issues still with the silo before even testing it, so it's not going to land soon. interestingly there's a reproducable powerpc failure now that's not seen in the archives and was not seen with the previous calibre version: https://launchpadlibrarian.net/188776106/buildlog_ubuntu-vivid-powerpc.calibre_2.7.0%2Bdfsg-1build1_FAILEDTOBUILD.txt.gz
<cjwatson> Mirv: Yeah it was actually
<cjwatson> Mirv: It succeeded in the primary archive on a retry, so just smash it back until it works
<cjwatson> (It might only succeed on certain builders or something, I'm not quite sure)
<Mirv> cjwatson: ok, I'll do a second retry
<Mirv> good to know
<cjwatson> Mirv: So yeah, hopefully imagemagick will be out of your way before it matters, then
<Mirv> probably.
<davmor2> brendand: payg sim on it's own no crash, now I'll put the contract sim in slot 2
<davmor2> brendand: and crash
<davmor2> brendand: and back with contract in sim1 and payg in sim 2 crash
<davmor2> brendand: so it is only happening with 2 sims,  let me unlock the payg sim and see what happens in that configuration
<ogra_> well, and not always if you look at tvoss
<ogra_> might be a certain combo only
<brendand> ogra_, surely the sims themselves may be involved
<brendand> davmor2, also what length pin do you use? 4 digits in both cases?
<ogra_> can you use more on a SIM ?
<davmor2> brendand: yeap
 * ogra_ didnt know 
<davmor2> ogra_: yeah up to 8 I think on simpin
<davmor2> ogra_: and lucky me double simpin crash
<davmor2> brendand: so it crash with the payg unlocked
<brendand> we should get a bug filed for this
<brendand> davmor2, want to do that?
<brendand> davmor2, APPORT_DISABLE_DISTRO_CHECK=1 ubuntu-bug unity8 in the shell
<davmor2> brendand: on it
<davmor2> ogra_: what sim do you have and is it payg or contract
<ogra_> top one is payg ... bottom one is contract
<davmor2> ogra_: on what network/networks
<ogra_> top one is conngstart (german telecom cheapo daughter), bottom one is eplus/kpn
<davmor2> brendand, ogra_, tvoss: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1388060 have at it
<ubot5> Ubuntu bug 1388060 in unity8 (Ubuntu) "Sim pin unlock is crashing unity8" [Undecided,New]
<ogra_> perfect
<tvoss> davmor2, sent you a testing package. Mind trying?
<brendand> olli, ^ for the sim pin unlock
<brendand> oooh a test package
<ogra_> davmor2, i see another thing here, the app lifecycle mgmt doesnt seem to kick in
<ogra_> tvoss, ^^
<tvoss> ogra_, sure, one after the other
<davmor2> tvoss: installed ,rebooting
<tvoss> davmor2, ack
<davmor2> tvoss: 2 sims unlocked and logged into the system \o/ I'll try a few more times to confirm though
<davmor2> tvoss: attempt 2 pass
<Saviq> can everyone please stop filing crashers against unity8 please!? please!?
<tvoss> Saviq, +1, we need to analyze the stack traces and correctly track them down
<Saviq> we *know*, working on it ;P
<tvoss> ogra_, sent you testing package
<brendand> davmor2, the fix works?
<tvoss> ogra_, for sim pin unlock crash
<ogra_> tvoss, yeah, will test shortly
<ogra_> tvoss, where did you send it ?
<ogra_> ah
<ogra_> heh, my dekko on the phone has it ... my evo on the desktop doesnt :P
<davmor2> okay 6 restarts and I have been able to unlock both sims and login to the phone
<brendand> \o/
<brendand> tvoss, can i test it too - even though i don't have the issue?
<davmor2> I'm going to keep going till I hit 10 it's a nice round number
<cwayne> davmor2: go to 11
<tvoss> brendand, sent
<ogra_> empty dashboard ... but no crash first time
 * ogra_ reboots
<brendand> tvoss, can i see the patch?
<tvoss> brendand, https://code.launchpad.net/~thomas-voss/qtubuntu-media/disconnect-from-playback-status-changed-signal-on-destruction/+merge/240254
<ogra_> tvoss, looks good so far
 * ogra_ goes on rebooting ... 3 survived so far
<davmor2> tvoss: number 9 triggered a reboot
<tvoss> davmor2, okay, still better thanbefore I would argue
<davmor2> tvoss: indeed
<tvoss> davmor2, and that might even be a different issue altogether
<tvoss> davmor2, got crash file?
<brendand> tvoss, should that patch fix my crash, or did you not get to look at that one yet?
<tvoss> davmor2, triggered a reboot? or restart of unity8?
<Saviq> brendand, if you're able to reproduce https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1387959/comments/2 that would be interesting, it's a crash signature I didn't see before
<ubot5> Ubuntu bug 1387959 in unity8 (Ubuntu) "unity8 crash in image krillin rtm 139" [Undecided,New]
<tvoss> brendand, I'm focusing on the sim pin unlock right now
<davmor2> tvoss: restart of unity8 spinning ubuntu logo on black screen
<Saviq> I'm retracing now
<tvoss> davmor2, ack
<brendand> Saviq, nope it just happened randomly. i wasn't doing anything with the phone even (was in a HO)
<Saviq> brendand, ok, can you see if you got an OOPS for it?
<Saviq> brendand, maybe errors managed to retrace
<brendand> Saviq, i did indeed - https://errors.ubuntu.com/oops/5946f7c6-60e2-11e4-be34-fa163e75317b
<Saviq> brendand, hmm no
<Saviq> brendand, that's the known one
<Saviq> brendand, maybe it's hiding, let's see if I manage to retrace
<olli> ogra_, brendand, davmor2 can you guys see if you can reproduce https://bugs.launchpad.net/ubuntu/+source/urfkill/+bug/1388065
<ubot5> Ubuntu bug 1388065 in urfkill (Ubuntu) "urfkill seems to get stuck when stressing flight mode" [Critical,New]
<davmor2> tvoss: no new crash so I have wiped /var/crash and hopefully I can get it to appear again
<olli> if/when you have time
<tvoss> davmor2, ack
<brendand> Saviq, hmmm - i only had one
<olli> if you can reproduce, then this is another one for RTM :/
<tvoss> davmor2, ack, a .crash would really help
<brendand> Saviq, ah here we go - https://errors.ubuntu.com/oops/e8b1c5f4-60e1-11e4-9f52-fa163e525ba7
<Saviq> brendand, yup, I just uploaded it from mine as well, let's see if it retraces
<ogra_> tvoss, heh, same thing davmor2 had ... first 9 reboots were fine, 10th crashes
<ogra_> definitely good enough for a quick-fix though
<tvoss> ogra_, got crash file?
<ogra_> i'd say prepare a silo :)
<ogra_> let me check
<tvoss> ogra_, also: just preparing another package, with the cleanup being more aggressive, you might want to give that a spin, too
<Saviq> ogra_, OOPS would be useful, too
<ogra_> tvoss, no recent crash file :(
<ogra_> only the usual UAL fitbit one that you get on every boot
<ogra_> (recoverable error ... just noise)
<tvoss> ogra_, weird, then it probably didn't crash but exited?
<olli> sil2100, brendand ogra_ whom should I invite to a promotion sync in 4h at 5pm UTC?
<tvoss> brendand, got the bug for the sim pin unlockhandy?
<ogra_> olli, well, i think LT and QA were a good start (from your mail)
<ogra_> or do you mean individuals ?
<olli> individuals
<ogra_> LT partially covers QA
<brendand> tvoss, it was this one (which i think Saviq got angry at us for filing :/) https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1388060
<olli> Fri 6pm... not sure who is up for that
<ubot5> Ubuntu bug 1386803 in qtubuntu-media (Ubuntu) "duplicate for #1388060 [TOPBLOCKER] unity8 crashing a lot since image #126" [Undecided,In progress]
<ogra_> so just the whole LT would be fine
<ogra_> you should get people from both teams that are relevant
<brendand> olli, any chance we can do something when US folks come online?
<ogra_> brendand, 6pm sounds like it would fit for that
<ogra_> assuming thats UTC
<olli> brendand, 5pm UTC
<brendand> ogra_, i wasn't planning to be around at  6 :)
<olli> brendand, what time are you suggesting
<ogra_> hmm, we have a LT launchpad team now and i cant find it
<brendand> olli, i was thinking 2 UTC, but no need to shape the time around me. i'll either change my plans or do a handover to jfunk or someone
<ogra_> olli, https://launchpad.net/~landing-team-trackers
<ogra_> thats a good set of people
<tvoss> davmor2, any luck with the crash file?
 * ogra_ goes back into reboot loops ... lets see if i can get it again
<olli> brendand, I'll let sil2100 make the call
<davmor2> tvoss: still trying
<tvoss> davmor2, can I send you an updated package?
<davmor2> tvoss: sure
<ogra_> geezs these left shifted popup dialogs are so annoying to my sense of geometry
<tvoss> davmor2, ogra_ sent updated package
<ogra_> cool
<tvoss> sil2100, ogra_ where would I land the hotfix? rtm or vivid, too?
<ogra_> rtm for now and vivid later ?
<ogra_> it needs to land in both
<ogra_> and theoretically first in vivid ... but in this situation i guess you can do vivid later
<tvoss> ogra_, I'm told it is easier to land in vivid
<ogra_> tvoss, it is, but you need to have it go to rtm in any case
<ogra_> else it wont go to the image
<ogra_> and give that you need QA signoff and we need to build an image etc etc i would start with rtm and then do vivid while you wait for signoff etc
<tvoss> sil2100, line 80
<ogra_> tvoss, so how many reboots do we want ?
<tvoss> ogra_, not sure, how many do you have right now?
<ogra_> 3 with the new one
<ogra_> #10 was the crash for me last time
<ogra_> so i guess 20 should be a good number
<tvoss> ogra_, ack
<Mirv> tvoss: rtm-001 for qtubuntu-media
<tvoss> Mirv, ack
<davmor2> tvoss: installed new version, lunch has just been called though, back after that but on reboot 2 no issues so far
<tvoss> davmor2, eat and reboot faster :)
<ogra_> tvoss, 15 now ... no crash yet
<brendand> davmor2, btw can you test mms?
<brendand> davmor2, that was the only thing me and ToyKeeper couldn't
* josepht changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: josepht | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: CI Train on halt! No non-blocker landings accepted until image promotion!
<tvoss> sil2100, rtm1 building
<thostr_> sil2100: why is there no commit log for rtm image 137?
<ogra_> tvoss, ok, 20 reboots, no crsh
<ogra_> thostr_, custom or device tarballs do not generate a rootfs changelog
<ogra_> 137 was a new custom tarball
<thostr_> ah, that explains
<tvoss> ogra_, ack, rtm 1 is building. should be finished soon
<tvoss> ogra_, so I think giving it another 10 should be good
<tvoss> brendand, ^
<ogra_> ok, going on with it then
<tvoss> ogra_, hang on, you should wait for the silo pakcages :)
<brendand> tvoss, silo 1
<tvoss> brendand, yup
<ogra_> tvoss, ok, that will be a nice break at least ... loop-rebooting is boring
<tvoss> ogra_, true
<sil2100> ogra_, Mirv, tvoss, brendand: situation?
<sil2100> Hotfix needed?
<ogra_> sil2100, fix for the on-boot crasher in silo1
<ogra_> sil2100, lifecycle management doesnt happen for webapps (still need to file that but was busy with testing for tvoss )
<ogra_> and there was a third one
<sil2100> hm, so unity8 fixes needed, right?
 * ogra_ has to check back in the other channel
<ogra_> yes
<sil2100> Is Saviq aware?
<ogra_> err
<ogra_> not unity8
<ogra_> qtubuntu-media
<sil2100> Since unity8 is doing the lifecycle management, right?
<ogra_> silo1 ... as i said
<ogra_> oh, that one
<ogra_> yeah, Saviq was testing that with me
<ogra_> not clear thats unity8 though ... could be webapp-container
<ogra_> seems the renderer gets lifecycled ... but the UI part doesnt
<ogra_> so if it was killed you dont get a blurry screenshot in the preview and if you switch to it it turns completely white
<ogra_> some of them manage to keep the header
<ogra_> but have white content
<ogra_> all in all we seem to consume a lot less memory though ... so it gets hard to test ... you have to have a gazillion apps open to trigger the lifecycle at all
<ogra_> sil2100, ah, the third potential blocker was brendand's untriggered session restart we saw during the meeting this morning
<ogra_> which appreas to be unrelated to the sim unlocking
<Mirv> sil2100: silo1 has only qtubuntu-media, but of course that might not be all of it (the crash issues)
<ogra_> Saviq, https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1388089 ... not sure what the actual package should be, i thought i should start with webbrowser
<ubot5> Ubuntu bug 1388089 in webbrowser-app (Ubuntu) "[webapp-container] apps are not handled by lifecycle management properly " [Undecided,New]
<ogra_> sil2100, ^^
<sil2100> ogra_: thanks!
<sil2100> dbarth: maybe you could help with that as well ^ ?
 * ogra_ opens a task for qtmir ... i see tedg did a change wrt cgroups there 
<tedg> ogra_, I think your analysis is probably correct, we're adjusting the OOM value for the renderers now, so they could be killed.
<tedg> I never saw one die like that though.
<ogra_> tedg, we somehow need to include the UI in that ;)
<ogra_> it got really hard to actually have the lifecycle kick in at all now
<ogra_> we seem to use a *lot* less ram
<tedg> Heh, damn it! Use more RAM people!
<ogra_> i had to open nearly every installed app to have it even start to cycle the native ones
<tedg> When I was talking with ricmm he mentioned we might be able to get the low memory killer to take out the entire cgroup.
<tedg> We never finalized that conversation though.
<tedg> ricmm, Do you have a link on how to do that? ^
<ogra_> sil2100, the conversation in #phablet just remined me, olli was seeing issues with flight mode he considered critical
<ogra_> tedg, i think he is out til monday (ricmm)
<sil2100> ogra_: when
<sil2100> ?
<ogra_> sil2100, when what ?
<ogra_> when he did see it ? when the conversation in phablet was ?
<ogra_> he mentioned it when he came online
<tedg> ogra_, Hmm, okay. I'll see what Google comes up with, but usually ricmm comes up with more useful links :-)
<ogra_> heh, yeah
<davmor2> tvoss: http://davmor2.co.uk/~davmor2/new-unity8-crash/
<ogra_> sil2100, ask olli in #phablet, he talks there :)
<davmor2> took about 16 attempts that's with the new fix
<ogra_> davmor2, i couldnt get it to crash anymore
<ogra_> with 20 reboots
<olli> sil2100, I was asking if it can be reproduced by others
<ogra_> waiting for the silo now to re-test
<olli> until then it's imho not significant
<olli> it = https://launchpad.net/bugs/1388065
<ubot5> Ubuntu bug 1388065 in urfkill (Ubuntu) "urfkill seems to get stuck when stressing flight mode" [Critical,New]
<ogra_> olli, so what do i need to do ... just toggle it on/off very fast ?
<olli> ogra_, yeah
<olli> make sure sim is online
<davmor2> ogra_: yes this might be something else as it only crashed after both sims were unlocked
<ogra_> bah ... my location indicator is gone ... again
<olli> then on/off/on/off flight mode
<olli> then check what state the sim is in when flight mode is off after about 5+ iterations
<davmor2> ogra_: possibly just a race
<ogra_> olli, hmm, i might not be the best to reproduce that ... toggling it on requires me to enter the SIM PIN ... which makes fast toggling impossible
<olli> hmmmm
<olli> maybe still try to just toggle multiple times consecutively
<olli> might be a good indication for abeato
<ogra_> (i mean, i could indeed hit the toggle fast)
<ogra_> olli, hmm, so i have the flight mode on now ... but only BT is off ... both sims and WLAN are connected
<ogra_> after toggling the switch really fast
<dbarth> sil2100: sorry, missed that
<ogra_> oh, no, i'm offline but the indicator lies about the status
<ogra_> webpages actually get me a network error
<brendand> ogra_, what was the -proposed image for #5?
<ogra_> olli, so confirmed i think ... something at least :)
<olli> ogra_, yeah, that is iirc known
<brendand> ogra_, 116?
<dbarth> sil2100: ok, can do; how urgent is that?
<olli> out of sync states
<ogra_> brendand, last promoted one was 5
<tvoss> davmor2, ogra_ silo 1 built
<tvoss> davmor2, ogra_ could you guys give it a spin?
<brendand> ogra_, yes - but that was which -proposed image?
<ogra_> oh, one sec
<ogra_> brendand, krillin 114
<brendand> olli, am i reading it right that there are new blockers?
<davmor2> tvoss: did you get my earlier ping?
 * ogra_ reboots, i seem to not be able to get out of flight mode anymore now 
<ogra_> no matter what the UI shows
<tvoss> davmor2, did you get my pm?
<tvoss> :)
<sil2100> dbarth: it's a promotion blocker I think
<ogra_> sil2100, it is unlikely to be webbrowser, see my conversation with tedg above
<tedg> ogra_, I think the browser needs to handle the renders being killed though â¦
<tedg> It could happen for lots of reasons.
<dbarth> sil2100: oh, really?!
<ogra_> tedg, ah
<dbarth> ogra_: is that webapp bug suddenly a promotion blocker?
<ogra_> dbarth, well, it only happens with the latest changes to qtmir
<Mirv> I got unity8-dash crash this time on mako. https://errors.ubuntu.com/oops/c594512c-6104-11e4-b9de-fa163e373683 . now upgrading to silo 001.
<ogra_> dbarth, also ask olli, i dont make things promotion blockers, i only find and report them atm :)
 * Mirv is happy about finding whoopsie.log
<ogra_> dbarth, it surely has the potential to be a blocker though
<dbarth> but because of a change in qtmir, right?
<dbarth> i mean, from non-existant to promotion blocker in 17min, that's a bit fast...
<pmcgowan> what was the change - to OOM the renderers? what was to come with the group management
<pmcgowan> that was
<ogra_> pmcgowan, yes, but it only OOMs the renderers
<dbarth> that's wrong
<pmcgowan> yeah thats a problem
<ogra_> pmcgowan, the UI stays and gets stuck
<pmcgowan> revert it
<dbarth> oxide can deal with renderers being killed like that
<dbarth> can't
<tedg> No, it doesn't only kill the renders.
<dbarth> that's why we made changes a few month ago to kill the whole group, remember
<ogra_> i think Saviq has a nice and detailed explanation what exactly happens
<tedg> It does kill the whole group on exit.
<pmcgowan> ok good so whats the issue?
<ogra_> so why does the UI stay and the content gets white then ?
<tedg> The issue is that the OOM killer doesn't work with exit, it kills by PID.
<ogra_> also why do the apps not get llifecycle managed at all anymore then ?
<ogra_> (i.e. no blurry screenshots in app preview)
<tedg> So it can (and could) have killed renders before.
<tedg> The problem was before that we didn't adjust the renders to the background, so no one saw one being killed.
<dbarth> tedg, or whoever knows: what is the actual code change that triggered this issue?
<tedg> They could have been, they were just less likely before.
<ogra_> dbarth, last qtmi upload i guess
<ogra_> *qtmir
<tedg> dbarth, There was no code change that triggered this issue. It was noticed because we've made it more likely to happen, but it's happened forever.
<ogra_> https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-October/000800.html
<dbarth> ok
<dbarth> why don't we just revert the change for now?
<davmor2> brendand, tvoss: right flashing my phone fresh now and then I'll try silo 001 \o/
<tvoss> davmor2, ack
<pmcgowan> tedg, dbarth  and what is the fix we really need?
<ogra_> davmor2, dude, you are falling behind
 * ogra_ is at his 5th reboot already
<ogra_> pmcgowan, killing by process group
<davmor2> ogra_: lunch got in the way and then I had a meeting and then I had the crash file to upload and tell people about :P
<dbarth> pmcgowan: no idea right now
<ogra_> not only by PID
<dbarth> pmcgowan: is that for the rtm image? if so, we should just revert
<dbarth> otherwise, hop on a hangout to discuss a fix for vivid
<pmcgowan> I take it 139 is not so good sinc eit crashed immediately
<ogra_> pmcgowan, silo1 fixes that
<ogra_> we're all actively testing it already
<ogra_> tvoss, 10 reboots, no crash ... want me to go to 20 ?
<tvoss> ogra_, I guess we are good
<ogra_> great ... lets see how davmor2 does
<ogra_> he always gets crashes i dont :P
<ogra_> must be his werid language setting ... wolverhapton english ....
<ogra_> +m
<davmor2> right image up instant crash with no silo in place
<davmor2> citrain taking care of installing the silo now
<tvoss> mlankhorst, mind giving rtm 1 a spin?
<mlankhorst> sure
<mlankhorst> how do I test a silo?
<davmor2> number 8 no issues
<ogra_> i usually do: adb shell ... then sudo mount -o remount,rw / ... cd /tmp ... wget the deb from the PPA ... dpkg -i it ... sudo sync ... log out ... adb reboot
<ogra_> mlankhorst, ^^
<ogra_> thats fastest if you only have one deb to install
<ogra_> else use the citrain tool
<mlankhorst> phablet-tools-citrain should really depend on phablet-tools, seems to get an error without
<ogra_> file a bug please
 * ogra_ will try to fix next week
<ogra_> assign me
<mlankhorst> ok
<davmor2> ogra_, tvoss 12 still no issues
<mlankhorst> ogra_: done
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/phablet-tools/+bug/1388114
<ubot5> Ubuntu bug 1388114 in phablet-tools (Ubuntu) "phablet-tools-citrain needs to depend on phablet-tools" [Low,New]
<tvoss> davmor2, let's set the silo to tested
<ogra_> mlankhorst, thanks !
<ogra_> mlankhorst, btw, how long did you play music til that happened ?
<mlankhorst> not long
 * ogra_ is at the third or fourth title now ... on random play 
<mlankhorst> though I didn't try to find the exact steps yet
<ogra_> well, we have clearly a qtubuntu-media issue on 139 ... so i would expect it wouldnt be hard to repro on the plain image
<ogra_> i'll just leave it play along
<ogra_> (i got silo 1 installed here )
<tvoss> davmor2, I assume 139, krillin?
<sil2100> \o/
<sil2100> Publishing
<ogra_> yay
<ogra_> one down
<ogra_> now we need some assessment about urfkill and webaps
<sil2100> Do we block on the others?
<davmor2> tvoss: filled it in already :)
<tvoss> davmor2, thanks
<sil2100> davmor2, brendand: ?
<ogra_> sil2100, not sure if olli wants to or not
<sil2100> I know he was worried about the crasher
<ogra_> the webapps thing should be a safe rollback
<ogra_> not sure what to do about urfkill
<tvoss> ogra_, sil2100 talking about those right now
<ogra_> i can clearly get it in a bad state here too
<olli> sil2100, what tvoss says
<sil2100> ACK, just give us a sign about the decision
<ogra_> but i dont think there is a fix in the pipe for urfkill yet ... and roolback wouldnt make it better either
<davmor2> ogra_: by the sound of it it was a qt change not a webapps change do you really want to revert qt?
<ogra_> davmor2, qtmir
<sil2100> qtmir is our component
<ogra_> right
<davmor2> ogra_: yes sorry I could remember the component
<ogra_> https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-October/000800.html
<ogra_> this one
<pmcgowan> ogra_, sil2100 tedg  is preparing a tweak to ual to reduce the likelihood of the renderers being killed
<ogra_> should be safe to roll back if someone wants that
<ogra_> cool
<ogra_> thats even better
<tedg> https://code.launchpad.net/~ted/ubuntu-app-launch/no-oom-value-for-oxide/+merge/240276
<davmor2> ogra_: my point is that it isn't necessarily safe to revert it with all the other fixes in places on top of it ;)
<ogra_> davmor2, there are none on top of it as i understand
<jhodapp> sil2100, if we get QA approval of a silo that has critical bug fixes, are we allowed to land it right now?
<ogra_> tedg, hmm, and you think that helps ?
<sil2100> jhodapp: no
<jhodapp> sil2100, just blockers?
<ogra_> tedg, that sounds like webapps wont be lifecycled at all anymore then
<jhodapp> sil2100, even if it's marked for rtm?
<sil2100> jhodapp: now we *only* land blocker fixes or changes that the product team approves, but we need a promotion so it's highly unlikely now
<sil2100> jhodapp: yes, even those - it's a very strict freeze right now
<tedg> ogra_, Well the main process will, just the renders are less likely. It basically puts it back to the same place as yesterday.
<davmor2> ogra_: we'll see when you revert it ;)
<ogra_> tedg, ah, cool then
<ogra_> davmor2, well, seems we have a "fix" so no need to revert
<jhodapp> sil2100, ok thanks, there was some confusion out there (too many emails I think)
<ogra_> jhodapp, write a mail ... :) we should have a definition for this on a wiki or so where we can just point people :)
<ogra_> this question comes up every milestone
<jhodapp> ogra_, or an official web page to visit with the status of landing
<sil2100> There was an e-mail about this
<ogra_> sil2100, yes, i know
<sil2100> jhodapp: well, the /topic and the dashboard seem to have all the info
<jhodapp> ogra_, one where everyone knows to look and can see a very clear definition
<jhodapp> sil2100, yeah it's too scattered...we need one official place
<ogra_> sil2100, i think we should have a wiki section "LandingTeam/Milestones" where all the bits and pieces can be found centrally
<jhodapp> that won't change locations
<sil2100> Still working on the docs ;)
<ogra_> time schedule ...
<sil2100> Might do that indeed
<ogra_> what can land
<ogra_> etc
<jhodapp> ogra_, as helpful as a wiki is, I still find them very hard to find things...they get lost in the noise of everything else
<ogra_> sil2100, i dream that your  next email should only contain this link and the milestone date
<ogra_> ;)
<jhodapp> ogra_, and then you need to maintain external bookmarks to various wiki pages
<ogra_> jhodapp, well, we have everything else for the landing team on a wikipage
<jhodapp> ogra_, yeah, and I have no idea what that wiki page is :)
<sil2100> hah
<ogra_> and they are linked from every landing team mail sil2100 sends
<tvoss> mlankhorst, any luck with silo 1?
<sil2100> There will be a centralized place for all docs related to landings
<ogra_> tvoss, music plasy still fine for me ... 15 titles so far on random playback
<sil2100> https://wiki.ubuntu.com/LandingTeam/
<mlankhorst> got silo 1 working finally
<jhodapp> ogra_, the best would be a URL of http://landings.ubuntu.com
<tvoss> ogra_, ack
<sil2100> This is essentially it, but not yet ready
<ogra_> yeah
<jhodapp> simple
<ogra_> jhodapp, well, that wont be as easy to edit as a wiki
<ogra_> i think https://wiki.ubuntu.com/LandingTeam/isnt to hard either
<jhodapp> ogra_, well that URL could even point to the wiki URL
<ogra_> sure
<jhodapp> ogra_, it isn't, but it is when you have 50 million other wiki pages to remember
<ogra_> heh, yeah
<jhodapp> ogra_, what our wiki really suffers from is not having a fantastic search ability
<ogra_> true
<davmor2> jhodapp: light weight only 50,000,000 ;)
<jhodapp> davmor2, ha I know, I'm working up to 1 billion :)
<tedg> trainguards, could I please get silos for line 81 and 82?
<ogra_> go go go
<ogra_> :)
<tedg> jhodapp, google with "site:wiki.ubuntu.com"
 * ogra_ gets standup-meeting coffee 
<jhodapp> tedg, yeah, never remember that syntax
<jhodapp> tedg, still too complex
<mlankhorst> I'm not seeing the issue atm, so I guess things are more stable now
<Mirv> tedg: done
<tvoss> mlankhorst, ack
<mlankhorst> but if it pops up again I'll let you know
<tvoss> mlankhorst, yeah, thanks
<tedg> Mirv, Thanks!
<davmor2> jhodapp: set it as a search provider in your favourite browser :)
<brendand> ogra_, 1 didn't go through sign-off?
<ogra_> brendand, the bot said it did
<dbarth> trainguards: i have silo 29 (vivid) ready for publication
<ogra_> not sure who signed it off ... davmor2 ?
<tvoss> brendand, I guess davmor2 tested it, too
<davmor2> brendand: i tested it
<brendand> davmor2, don't short circuit the process
<brendand> ogra_, is the image building?
<ogra_> brendand, waiting for tedg *s fix
<davmor2> brendand: I didn't,  Myself and ogra needed to test as we were the only ones who could reproduce it, Ogra confirm it was all good for him after 10 reboots I confirmed it was good for me with 12 after a fresh install and silo001 added
<sil2100> I published it as it was set to 'signed-off'
<Wellark> brendand: I know you want to test silo 3 ;)
<davmor2> sil2100: yeap only it missed the trello board
<sil2100> Ah, ACK
<ogra_> all fine
<ogra_> tedg, sea a commit message please !!
<ogra_> *set
<tedg> ogra_, Yeah, doing it. Fixed the changelog and so it won't do it for me now :-/
<ogra_> hmm
<ogra_> sil2100, can you give a hand ?
<ogra_> (last blocker afaik)
<tedg> Oh, it's fixed.
<ogra_> oh, ok
<sil2100> ;)
<tedg> Just hate that "feature"
<ogra_> the the bot is just babbling :)
<brendand> sil2100, so tedg is fixing? webapps?
<ogra_> brendand, yes
<ogra_> "fixing"
<tedg> Not sure how the changelog in ubuntu-rtm got unmatched with the bazaar branch.
<tedg> brendand, Making the issue less likely to happen, yes.
<brendand> Wellark, i'm going to ignore you for now :)
<brendand> ogra_, did we get a bug for that?
<ogra_> for what ? webapps ?
<brendand> ogra_, yeah
<ogra_> brendand, bug 1388089
<ubot5> bug 1388089 in webbrowser-app (Ubuntu RTM) "[webapp-container] apps are not handled by lifecycle management properly " [Undecided,New] https://launchpad.net/bugs/1388089
<ogra_> olli, can we get that bug status proper just for the paperwork to be correct ?
<ogra_> (geez, i'm so german today)
<sil2100> olli, brendand: is that a blocker in the end?
<brendand> ogra_, olli - and we decided the flight mode issue was not a blocker?
<ogra_> brendand, still waiting for a verdict from olli on that one
<ogra_> brendand, but we dont have a fix in the pipe and rolling back would bring back old bugs
<ogra_> so it is somehow rock vs hard place anyway
<brendand> ogra_, i have a feeling it's not new either
<ogra_> imho we should roll with it
<brendand> ogra_, flight mode has never worked perfectly
<ogra_> it worked fine on my flights :)
<brendand> ogra_, yeah but if you start stressing it like in the bug, then...
<brendand> all bets are off
<ogra_> right
<ogra_> for me it actually seems to queue the actions
<brendand> Wellark, any chance 3 might fix those issues?
<ogra_> i can se BT going on/off for a few iterations after i stopped tapping the network indicator button
<Wellark> brendand: which ones?
<ogra_> wlan and SIM cards seems ot react to slow to actually pick up the changes at all
<Wellark> brendand: sorry, meeting
<ogra_> Wellark, the potential image blockers with flight mode
<Wellark> brendand: the bug numbers are stated in the landing sheet comment
<brendand> Wellark, flight mode switch getting stuck
<brendand> so probably not
<Wellark> brendand: bug number?
<brendand> wow
<brendand> this channel has so much scrollback it only goes 2 hours back :)
<brendand> so the bug has dropped off
<Wellark> I can't see flightmode listed in the top blocker list
<Wellark> nor in the landing email
<brendand> no it was filed recently
<ogra_> https://bugs.launchpad.net/ubuntu/+source/urfkill/+bug/1388065
<ubot5> Ubuntu bug 1388065 in urfkill (Ubuntu) "urfkill seems to get stuck when stressing flight mode" [Critical,New]
<ogra_> filed during image testing of the promotion candidate
<Mirv> brendand: /set scrollback_time 7day
<ogra_> heh
<popey> oooh
 * ogra_ just has xhat set to 50000 lines
<ogra_> *xchat
<popey> thaks Mirv
<Mirv> ogra_: scrollback_time overrides even if 50000 would fill up :) but I agree 50000 should also be enough alone
<Mirv> popey: np
<Wellark> ogra_, brendand: ok. no. my bugs are not fixing any of that
<Wellark> please ping cyphermox and awe
<ogra_> Mirv, the good thing is that i can grep xchatlogs on disk :)
<Mirv> when needed, I do a quick /lastlog -file foo and then grep
<mterry> plars, the race fix for unlocking on boot landed in vivid and rtm, btw
<mterry> plars, let me know if that helps
<Wellark> $ du -chs irclogs/
<Wellark> 324M    irclogs/
<plars> mterry: awesome, which images?
<mterry> plars, I don't think any images next.  Probably +1 for both channels
<ogra_> ogra@anubis:~$ du -chs .xchat2/xchatlogs/
<ogra_> 4,6G	.xchat2/xchatlogs/
<plars> mterry: or I guess that means... yeah, next image
<ogra_> Wellark, pfft
<plars> mterry: I'll keep an eye out for it
<Mirv> ogra_: can you approve "-a" at https://ci-train.ubuntu.com/job/ubuntu-landing-029-2-publish/5/artifact/packaging_changes_signon-plugin-oauth2_0.20+15.04.20141031-0ubuntu1.diff ..
<plars> mterry: there are many other strange problems to sort through too, so it's just one of several :)
<plars> mterry: thanks for doing that though, every bit helps make it more reliable
<Mirv> I know it works since I also use that with Qt
<mterry> plars, eventually it will be 100% reliable  :)
<ogra_> Mirv, ack (the debian/rules change should be mentioned in the changelog though )
<plars> mterry: that's the goal
<Mirv> ogra_: it seems to be a CI Train "cropping" of the changelog entry
<ogra_> Mirv, since i had to look up what -a does
<ogra_> ah, k
<ogra_> mlankhorst, tvoss, music still plying here ... tirelessly
<ogra_> *playing
<mlankhorst> so far no issue here either
<ogra_> sounds good
<tedg> trainguards, Could I get a silo for line 85 please?
<ogra_> (hah, pun)
<mlankhorst> but sound kept working even if it crashed, so it doesn't just have to sound good!
<ogra_> haha
<olli> ogra_, what status do you need for https://bugs.launchpad.net/ubuntu/+source/mtp/+bug/1378576
<ubot5> Ubuntu bug 1378576 in mtp (Ubuntu) "/usr/bin/mtp-server:11:boost::asio::detail::epoll_reactor::run:do_run_one:boost::asio::detail::task_io_service::run:run:core::dbus::asio::Executor::run" [Critical,Confirmed]
<ogra_> olli, dunno, ask cyphermox
<ogra_> olli, we'd like to know about bug 1388089 though
<ubot5> bug 1388089 in webbrowser-app (Ubuntu RTM) "[webapp-container] apps are not handled by lifecycle management properly " [Undecided,New] https://launchpad.net/bugs/1388089
<olli> ogra_, I pasted the wrong bug
<ogra_> olli, tedg's fix should be ready any minute and sil2100 needs to know if it should land for 140
<ogra_> olli, ah :)
<ogra_> ETOOMANYBUGS :)
<olli> yuo tell me
<olli> I am stressing the tabs in chromium
 * ogra_ looks forward to the next milestones where we only have to care for one or two bugs each time *g*
<olli> ogra_, if QA & everyone is happy with that fix then we (in a status mtg) agreed to take it
<olli> pmcgowan, ^
<ogra_> brendand, davmor2 ^^^^^
<ogra_> sil2100, ^^
<ogra_> seems its up to us
<tedg> So the fix is published, realized I need to switch to the devel rtm to be able to test it. So I'm going to have to grab a new image.
 * ogra_ tries hard to not say "its just a one line fix"
<pmcgowan> yes if it helps the issue we want it
<tedg> rtm/10 for those who want to play
<brendand> tedg, low risk of regression?
<tedg> brendand, Yes
<ogra_> brendand, its a one line fix
 * ogra_ hides from davmor2 
<pmcgowan> it fixes a regression
<ogra_> right
<tedg> ogra_, Two lines, there's a debug message! And a comment!
<ogra_> oh, right
<tedg> :-)
<ogra_> me liar !!!
 * davmor2 mocks ogra_ 
<brendand> ogra_, but it looks like a hack not a fix?
<ogra_> :)
<ogra_> brendand, ssshhh, dont let QA hear that !
<tedg> brendand, It puts things back in the same state they were in.
<ogra_> oh, wait ...
<ogra_> :P
<tedg> Channel your happiness from yesterday.
<davmor2> ogra_: brendand is qa you fool :P
<brendand> ogra_, can i get some straightforward repro steps for the issue so i can see how bad it is?
<ogra_> olli, any verdict about the urfkill thing ? we dont have a fix in the pipe, rolling back will bring back older bugs ...
<brendand> ogra_, what would we roll back?
<olli> ogra_, talking to abeato
<ogra_> brendand, install a bunch of webapps ... opena all the apps you can to force lifecycle mgmt ... see that only native apps get blurry screenshots in the app selector ... if you switch to a webapp then see the content go white instead of the app restarting
<Saviq> tvoss, will you take care of syncing qtubuntu-media from rtm to vivid?
<ogra_> brendand, its not easy to repro since our ram usage seem to have gone down significantly
<tvoss> Saviq, not sure I get to it today
<Saviq> tvoss, doesn't have to be today, just want an owner
<Saviq> tvoss, can be a delegate
<tvoss> jhodapp, can you take care of the sync for qtubuntu-media to vivid?
<brendand> ogra_, to the extent that my opinion counts i wouldn't call that a blocker...
<Saviq> tvoss, what about http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-012 btw?
<olli> ogra_, I think for now the urfkill bug is probably not a promo blocker
<ogra_> olli, agreed
<olli> need to verify with AK
<ogra_> if it is, i think it will delay significantly
<davmor2> olli, ogra_, brendand, sil2100: I just managed to get flight mode into this situation http://people.canonical.com/~davmor2/flightmode.png
<brendand> ogra_, install a bunch of webapps and start them all at once ?
<ogra_> since we dont even know how to fix yet
<brendand> ogra_, i mean really :)
<ogra_> brendand, start *all* apps you have installed
<olli> davmor2, twice the bandwidth!
<ogra_> not only all webapps
<brendand> ogra_, but i guess we prefer not to have regressions, and it does seem to be one
<ogra_> brendand, you need to get some memory pressure to trigger lifecycle mgmt
<tvoss> Saviq, that's sync to vivid, too?
<ogra_> brendand, you guys really need some lifecycle test on your test list
<Saviq> tvoss, yeah, just asking what's the status of that
<brendand> ogra_, i assume tedg 's fix is temporary
<brendand> ogra_, we sure do
<ogra_> brendand, for sure
<Saviq> tvoss, should we be testing it and land it?
<tvoss> Saviq, surely
<Saviq> tvoss, it's your silo, you need to chase for that to happen! ;)
<Saviq> biab
<tvoss> Saviq, you requested it for me :)
<tvoss> Saviq, how about putting qtubuntu-media in there, too?
<ogra_> tvoss, nothing is officially allowed to land in rtm if it isnt in vivid
<tvoss> Saviq, makes testing actually useful
<brendand> ogra_, to me it feels wrong to make a temporary change to fix an issue like that
<ogra_> tvoss, promotion is kind of an exceptional state thogh ... but yu should still land it in vivid
<brendand> ogra_, i could understand if it was really bad and hindered testing
<tvoss> ogra_, sure thin
<tvoss> g
<ogra_> brendand, it makes webapps non functional ...
<Wellark> davmor2, olli: we still have this affecting the toggle switches you see in the indicators: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1336715
<ubot5> Ubuntu bug 1336715 in unity8 (Ubuntu RTM) "[TOPBLOCKER] switch-items in indicators sometimes get out of sync with system-settings" [Critical,In progress]
<ogra_> brendand, it will affect you badly over time ... the "start all apps" is just to speed it up
<brendand> ogra_, fair enough i was just giving my opinion
 * brendand tries to reproduce said issue and become more informed
<olli> Wellark, yep, I went and just killed indicator-nw
<olli> just to be sure
<Wellark> olli: ack.
<davmor2> brendand: tell someone who doesn't use 18 webapps on his phone then your point might stand but this is ogra_ and that's all he uses ;)
<ogra_> davmor2, lkies ... i use dekko too
<ogra_> :)
<ogra_> *lies even
<davmor2> ogra_: Oh so sorry you use one qml app too ;)
<ogra_> :)
<ogra_> nowadays even two
<ogra_> i became a telegram user :)
<davmor2> ogra_: oh yeah
<sil2100> So what's the final verdict?
<sil2100> We waiting for the webapps fix?
<ogra_> sil2100, up to us ...
<ogra_> sil2100, i'd say yes
<ogra_> sil2100, nothing to wait for though, silo is ready, just needs signoff
<brendand> tedg, did you test it?
<tedg> brendand, Rebooting with it right now.
<ogra_> brendand, when you test it, G+ is very noticeable after you scrolled down for a while to have it load more messages in the stream, then swith apps, use something else for a while and go back to G+
<ogra_> i just had it die on me again and only have a handfull of apps open
<tedg> Okay the OOM values aren't getting set.
<popey> sil2100: fyi, i wont be around for the landing meeting. Email me if anything is required of me (I expect not though) â»
<sil2100> popey: sure :) Well, considering that we're in promotion mode right now, that might be true!
<popey> be back later anyway.
<tvoss> Wellark, I'm inclined to call https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1382595 fix released
<ubot5> Ubuntu bug 1382595 in indicator-network (Ubuntu RTM) "[TOPBLOCKER] /usr/lib/arm-linux-gnueabihf/indicator-network/indicator-network-service:indicator-network-service: pthread_mutex_lock.c:80: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed." [Critical,In progress]
<tvoss> Wellark, what do you think?
<ogra_> tvoss, is that the "empty indicator and showing a gear" thing ?
 * ogra_ hasnt see that in a while 
<Wellark> tvoss: ack.
<Wellark> ogra_: nope. that's in silo 3
<Wellark> waiting for qa signoff
<ogra_> heh, ok
<ogra_> yeah, most likely after promotion
<Wellark> didn't we promote already like yesterday?
<Wellark> oh, well..
<ogra_> :)
<tvoss> sil2100, in the spreadsheet, can I sync from multiple sources?
<sil2100> tvoss: sadly currently that's not easily possible - we can do that for you using specific tricks
<ogra_> magic
<sil2100> i.e. first specifying a sync from one place, then reconfigure and sync from another
<tvoss> sil2100, so line 46 should also sync what used to be qtubuntu-media in rtm 1
 * sil2100 looks
<sil2100> tvoss: ok, since silo 1 will be done soon (I hope), let me maybe configure this to be a sync from ubuntu-rtm in overall
<sil2100> As both silos it would want to sync from will be landed in ubuntu-rtm anyway
<tvoss> sil2100, ack
<bfiller> kenvandine: marked silo 24 as passed
<kenvandine> bfiller,  thanks!
<kenvandine> bfiller, published
<davmor2> sil2100, ogra_: this magic does it start with the line I sacrifice this chicken to satan and all that is evil under his reign?
<ogra_> davmor2, dunno, it is polish magic ... probably involves sausages
<davmor2> ogra_: hahahaha
<kenvandine> yum, sausages
<sil2100> olli, brendand: lost connection
<sil2100> Google works terribly for me today
<pmcgowan> tedg, any results?
<ogra_> sil2100, oh, will you give us a summary what olli decided in the LT meeting then ?
<brendand> ogra_, did you get to test silo 10?
<sil2100> Yeah
 * ogra_ feels a slight lack of information
<ogra_> brendand, not yet, i thought you would ?
 * ogra_ gest soli 10 contents
<ogra_> *gets silo
<ogra_> sigh
<brendand> ogra_, i am, but you know i still haven't reproduced the issue in the first place :) i have like 20 apps open
<ogra_> i hate my kbd
<tedg> pmcgowan, Yes, the patch doesn't set the OOM value anymore.
<tedg> pmcgowan, Marked as tested.
<pmcgowan> tedg, great thanks
<ogra_> wow
<ogra_> installing UAL is unbelivable noisy
<ogra_> complaining massively abouot fitbit and instagram
<dbarth> tedg: do you have a silo with it?
<tedg> dbarth, rtm/10
<dbarth> ok thanks
<brendand> ogra_, so i select a webapp from the switcher and it comes up as a white screen?
<ogra_> brendand, a) you dont have a blurry screenshot ... even though the app was lifecycled ... b) it comes up and when it would actually restart it doesnt but gets a white screen
<brendand> ogra_, but then i kill it and relaunch it and everything is fine again?
<ogra_> brendand, right
<ogra_> it is just the restarting
<ogra_> brendand, tested and confirmed good ... G+ just got lifecycled properly for me
<ogra_> and i see other apps having blurry screenshots
 * ogra_ tries these
<ogra_> brendand, what helps pretty well to get mem pressure are news sites with embedded video ... play it and you get many apps blurry
<ogra_> brendand, ok, had ten apps bein lifecycled properly here ... i think we can call that good
<ogra_> definmitely behaves like before
<dbarth> tedg, ogra_: +1 for me also while testing; i got several webapp-containers killed, all of which restarted properly
<ogra_> brendand, ^^^^
<dbarth> (after loading like 10-12 webapps at the same time to exhaust memory)
<ogra_> right
 * ogra_ has 34G of music on SD card ... for me it is usually enough to switch the music lens to album view to get enough mem pressure ;)
<dbarth> well, that's cheating ;)
<ogra_> heh
<sil2100> \o/
<sil2100> Published
<olli> sil2100, jfunk, I am heading off now, call me anytimeif it's urgent
<ogra_> yay
 * ogra_ will watch for it in rmadison
<sil2100> olli: sure, we just published silo10 - once it migrates we kick a new image
<olli> sil2100, I'll test later :)
<olli> curious
<ogra_> slangasek, so to not raise the confusion level for people wrt image numbers i will turn off the cronjob on the weekend (since nothing will land the images would come out identical anyway)
<ogra_> right after i built the next one
<slangasek> ogra_: that's for ubuntu-rtm only, right?
<cjwatson> is this likely to be a regular thing?  in which case we should adjust the cron job to only build on weekdays
<brendand> sil2100, start your engines!
<cjwatson> since it probably actually wants to run early on Saturday morning, right?
<brendand> ogra_, where's that webapps bug again? i'm so lost right now
<ogra_> slangasek, yup
<brendand> ogra_, got it
<ogra_> brendand, you cleary need better drugs then ;)
<brendand> ogra_, yup
<ogra_> cjwatson, not really, but the milestone we test today wont be promoted before monday
<brendand> right, i'm abandoning you all now, have fun
<ogra_> cjwatson, i just dont want to get testers confused which image # to test
<cjwatson> I don't mind it being commented out if it's a special case
<ogra_> generally we want them to build on weekends
<davmor2> right time for tea if ever there was an appropriate time :)
<dobey> davmor2: isn't the "appropriate time" when the queen says it's the appropriate time? :)
<davmor2> dobey: no :P
<dobey> davmor2: blasphemer!
<davmor2> dobey: that's God, I'd be a hieratic :P
<dobey> elopio: hey. is it plausible to run autopilot tests on the x86 emulator?
<elopio> dobey: it is.
<elopio> I have successful results on some, like calendar and calculator.
<elopio> some others will have a variaty of problems.
<dobey> elopio: i'm guessing power button is a problem?
<elopio> dobey: um, there should be a way to simulate it. It doesn't sound like a hard problem, but I don't know.
<elopio> rsalveti: ^ ?
<ogra_> yeah, there is a table somewhere on the wiki about key combos to simulate such stuff
<ogra_> ricardo is on vacation til next week
<ogra_> http://developer.android.com/tools/help/emulator.html
<dobey> key combos, as typing on a physical keyboard while using the emulator?
<dobey> hmm
<ogra_> well, you can surely use some sendkey thingie
<ogra_> power button would be F7
<ogra_> sil2100, is UAL 0.4+14.10.20141031~rtm-0ubuntu1 the version we wait for ?
<ogra_> tedg, ^^
 * ogra_ assumes so since it has a stamp of today
<ogra_> rmadison shows it is in
<ogra_> ah, it is
 * ogra_ triggers a build
<ogra_> done ...
<ribru> bfiller: ^ surely that needs QA?
<ogra_> yeah, everything rtm does ...
<bfiller> ribru: hmn, didn't touch the qa column
<ogra_> but we are fully on hold til monday anyway ... so ... meh
<ribru> ogra_: but it's marked as TOP BLOCKER and apparently approved for 10-30 ;-)
<bfiller> ribru: empty state on the spreadsheet should default to QA Required
<ogra_> ribru, doesnt really matter
<ogra_> ribru, until sil2100 lifts the lock nothing lands that we werent told to land specifically by olli or pmcgowan
<imgbot> === trainguards: RTM IMAGE 140 building (started: 20141031 17:55) ===
<ribru> bfiller: i agree, but not worth changing as the spreadsheet is going to be nuked from orbit in 1-2 weeks
<ogra_> we hope :)
<ChickenCutlass> what no more spreadsheet
<ChickenCutlass> lol
<bfiller> ribru: ack, I set it manually
<pmcgowan> ChickenCutlass, I think olli is using all the spreadsheet capacity at google
<ogra_> LOL
<ogra_> and doing a clever LP buglist would be so much easier :)
<ribru> bfiller: thanks
<ogra_> plars, did you already change the systemsettle values for krillin ? we decided we would like to give it 1% more wiggle room
<ogra_> (if thats not to hard it would be cool to have it before 140 starts testing)
<plars> ogra_: I can do that, but it's not just for krillin
<ogra_> :(
<ogra_> well, then do it for all for now
<plars> ogra_: the test doesn't distinguish between whether it's running on krillin or mako, just that it's arm
<ogra_> right, do it for all then
<ogra_> 1% wont hurt on the others
<ogra_> plars, oh, and i wrote this really helpful script http://paste.ubuntu.com/8746386/
<ogra_> producing output like http://paste.ubuntu.com/8746387/ or
<ogra_> s/or//
<plars> cool
<ogra_> plars, i wonder if we couldnt add something like this to the dashboard output somehow ... to make the top stuff easier readable
<plars> ogra_: probably, I'll see where we can slot it in
<ogra_> yeah, no hurry
<plars> ogra_: or better yet, send an email to ev and Ursinha saying that you'd like the systemsettle top offenders to be made more obvious in the dashboard, and can recommend this as a place to start
<ogra_> ok
<plars> ogra_: I wonder... how much do you think systemsettle helps as a before/after check for every single test? It seems like when there are really offenders, then it doesn't normally happen as a result of running autopilot tests
<plars> ogra_: usually it seems like these things can also be noticed if running it by itself
<ogra_> well, see the output in my second pastebin ... thats from todays unity8 test which crashes heavily
<ogra_> and it does that since quite some time ...
<ogra_> ChickenCutlass, and kgunn only discovered the same thing yesterday and are now debugging the dbus hang ...
<ogra_> but with better data from systemsettle tests we could have identified it two weeks agi
<ogra_> *ago
<ogra_> so if there is really an issue it can be very helpful ... the prob is that nobody ever takes the time to crawl through that giant logfile
<ogra_> which kind of makes it useless atm
<plars> ogra_: fair enough, just trying to see if there are opportunities to speed up the testing process
<ogra_> yeah
<plars> ogra_: but a little more time is worth it if it can produce useful data
<ogra_> we could surely limit it to half the loops
<ogra_> it would catch the big runaway processes still with that
 * ogra_ hugs pmcgowan for bug 1388189
<ubot5> bug 1388189 in indicator-messages (Ubuntu) "retain notifications that the user has not acted on" [Wishlist,New] https://launchpad.net/bugs/1388189
 * pmcgowan feels special
<ogra_> that annoys me since a while and i always forget to file it
<pmcgowan> ogra_, you watch bugs as much as I do
<ogra_> :)
<davmor2> ogra_: why is emulator on 243 for i386
<ogra_> for utopic ?
<davmor2> ogra_: hmm that's a point let me check
<ogra_> http://system-image.ubuntu.com/ubuntu-touch/ubuntu-rtm/14.09/generic_x86/
<ogra_> oh, wait thats the promoted one
<ogra_> http://system-image.ubuntu.com/ubuntu-touch/ubuntu-rtm/devel-proposed/generic_x86/
<ogra_> 111
<davmor2> ogra_: yeap so I missed the --channel out completely god knows what version I had :)
<ogra_> heh
<ogra_> rootfs of 140 is done ...
 * ogra_ disables cron
<ogra_> === Cronned Image builds disabled til promotion on monday !! ===
<davmor2> ogra_: well it doesn't list it unless you run help the right way at the right time with the wind in the right direction, me shakes his fist at sergiusens ;)
<ogra_> heh
<ogra_> poor sergiusens
<sergiusens> davmor2: try silo 19 on your desk
<sergiusens> davmor2: I don't understand the problem though
<davmor2> sergiusens: that's not gonna work is it there's no screen on my desk ;)
<sergiusens> davmor2: ;-) analogies, good or bad, stick
 * sergiusens whacks the mouse on his desk
 * ogra_ hears the *squeek*
<davmor2> sergiusens: I just ran sudo ubuntu-emulator create --arch=i386 ubutouchi386 and couldn't figure out how to set the right channel  ;)  got there in the end by reading the man page then running help on the option :)  it was a bit round about to get there though :)
<ogra_> ubutouchi ?
<ogra_> sounds like the japanese version :)
<sil2100> ogra_: \o/
<sil2100> ogra_: hah ;)
<sil2100> Indeed!
<ogra_> :)
* josepht changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: CI Train on halt! No non-blocker landings accepted until image promotion!
<davmor2> ogra_: I like the sound of this in my youth and was trying to reproduce it ;) http://www.youtube.com/watch?v=a3ir9HC9vYg
<ogra_> lol
<imgbot> === trainguards: RTM IMAGE 140 DONE (finished: 20141031 19:05) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/140.changes ===
<ogra_> \o/
<ogra_> aaaannd we got an update notification
<davmor2> ogra_: emulator 112 downloading
<ogra_> davmor2, cool ... now restart that with thew new img
<davmor2> ogra_: 112 is the latest already had 111
<ogra_> oh, right
<sil2100> ToyKeeper: ^ :)
<ogra_> does anyone else see the bouncy bar on the dashboard bottom never stop ?
<ToyKeeper> ogra_: Yes, it also never stops here.
<ogra_> its a cylon !!
<ogra_> (or knight rider ... for the older oof us)
<rvr> lol
<davmor2> ogra_: it is knightrider
<rvr> Cylons predate the Knight Rider, and it comes from the same creator
<ogra_> oh, indeed !
<ogra_> lorne greene is the only true adama !!
<davmor2> ogra_: ofcourse now I have this stuck in my head http://www.youtube.com/watch?v=GbfVmzF7N4g
<davmor2> ogra_: you Germans do love the Hoff ;)
<ogra_> i never did
<ribru> ogra_: which dashboard?
<ogra_> ribru, the new default home scope
<ribru> ah
<ribru> hadn't noticed
 * ogra_ gets linner 
<ribru> glad there's three things called the dashboard now ;-)
<cwayne1> we changed the name
<cwayne1> next image it'll be called "Today"
<ribru> sweet
<davmor2> ribru: are you trying to say that we call more than one thing dash board?
<sergiusens> ogra_: what's 140 supposed to fix?
<davmor2> sergiusens: webapps so ogra stopped whining that they were broken :)
<ogra_> sergiusens, session crash on boot
<ribru> davmor2: that's correct! There's the dashboard, the dashboard, and the dashboard!
<ogra_> broken webapp lifecycle mgmt
<ogra_> now really food ...
<pmcgowan> 140 seems good
 * davmor2 doesn't believe pmcgowan ;)
<sergiusens> ogra_: davmor2 right, the webapps one annoyed me, never saw the session crash for me though
<davmor2> sergiusens: you were lucky then
<pmcgowan> davmor2, why not?
<davmor2> pmcgowan: default mode for all things developers say, didn't want you feeling left out in the cold :)
<davmor2> pmcgowan: okay you might be right, but I'm not jinxing it this early on
<davmor2> sil2100, ogra_, olli, pmcgowan, tvoss|food: 2 sims unlocked no crash \o/ so far so good :)
<ogra_> sergiusens, happened only for ~50% of the people on SIM unlock
<ogra_> davmor2, yeah, same here
<ogra_> webapps lifecycle fine for me too
<sergiusens> davmor2: but pmcgowan is a manager (director even), not a regular dev ;)
<kenvandine> ugh... that sync of powerd from rtm wasn't good... it needs a rebuild against the vivid upower
<pmcgowan> so my opinion typically based on no data at all :)
 * ogra_ thinnks thats enough 
 * ogra_ hits the promote button based on pmcgowan's judgement 
<davmor2> pmcgowan: haha dude that's harsh, normally you guys have all the data, just no time to read it ;)
 * sergiusens updates now that his music app's playlist is done
<ogra_> pmcgowan, do you know if there are plans to not turn the battery red at 30% already
 * ogra_ thinks 15-20% would be totally sufficient
<pmcgowan> ogra_, that does seem a bit pessimistic
<pmcgowan> I have heard no discussion
<davmor2> pmcgowan: not if you are watching a video on youtube
<ogra_> nowdays 30% means like another 6-8h
<ogra_> if not being davmor2
<sil2100> davmor2: SHIPIT
<pmcgowan> ogra_, https://bugs.launchpad.net/ubuntu-ux/+bug/1388235
<ubot5> Ubuntu bug 1388235 in indicator-power (Ubuntu) "Icon turns red at 30%" [Undecided,New]
<pmcgowan> should say battery icon
<ogra_> confirmed
<kenvandine> shouldn't i be able to do a no change rebuild of powerd without a MP?
<kenvandine> ogra_, how do i do that?
<ogra_> kenvandine, thats a ribru or sil2100 question
<kenvandine> the sync of powerd from rtm made settings crash in vivid :/
<kenvandine> rebuilt against the wrong upower
<kenvandine> ribru, ^^
<ogra_> just dput it with a -build1 ?
<kenvandine> i could sure :)
<kenvandine> but i'm pretty sure we can do this with a landing :)
<kenvandine> ogra_, dput... that's a flash from the past :-p
<ogra_> haha
<ribru> kenvandine: citrain requires a null MP in order to do a no-change rebuild.
<kenvandine> ribru, ok
<pmcgowan> did we get an apparmor rebuild change with a recent image, taking forever
<ogra_> nope
<ogra_> and didnt take forever for me
<pmcgowan> ah ubuntu logo
<ogra_> 45sec at most
<pmcgowan> this is mako going from like 136 to 140
<pmcgowan> I am just impatient then
<kenvandine> can i get someone to ack https://code.launchpad.net/~ken-vandine/powerd/upower_vivid_rebuild/+merge/240326
<ogra_> done
<kenvandine> thx
<ribru> alecu: https://ci-train.ubuntu.com/job/prepare-silo/3019/console need merge proposals
<alecu> ribru: right, sorry.
<alecu> ribru: fixed
<ribru> alecu: ok rtm 1
<alecu> thx
<ribru> yw
<jhodapp> ribru, can I get a silo for line 91 please?
<ToyKeeper> ... and unity8 crashed while trying to change network settings in an indicator.
<ribru> jhodapp: rtm 2
<alecu> hmmm.... that was too quick...
 * alecu suspects something wrong
<jhodapp> ribru, thanks
<kenvandine> Setting up libupower-glib-dev (0.9.23-2ubuntu2) ...
<kenvandine> grrr
<kenvandine> doesn't the silo build against vivid-proposed?
<ToyKeeper> Woot, unity8 crash.
<ToyKeeper> Oh, I mentioned that already.
<ogra_> ToyKeeper, what ?!?
<ogra_> sigh
<ribru> kenvandine: it should
<ogra_> tvoss|food, ^^^
<alecu> ribru: rtm/landing-001 built too quickly, but there's no package. The only change in that MP is a png.
<ToyKeeper> ogra_: All I did was try to turn off wifi via the indicator...  which was the crash I thought silo 13 was supposed to fix.
<kenvandine> grrrr, the powerd silo pulled in the old libupower-glib-dev
<ribru> alecu: bloody hell
<ToyKeeper> Also, we don't recover well from unity8 crashes.  It tends to leave old apps running at 100% CPU until a reboot.
<ogra_> ToyKeeper, no, the charsh that was suppposed to be fixed was the one on boot where your session completely crashes after SIM PIN entering ... but there was hope it fixes all the other unity8 issues too
<ToyKeeper> Oh, thought the sim pin crash was fixed today in a different silo.  I meant yesterday's crash fix.
<alecu> ribru: I think this is the first time we are expecting the rtm package to be built from the rtm branch in launchpad; it used to be built from trunk usually, but now we are using that for vivid
<ogra_> ToyKeeper, thats two different things ... it keeps apps suspended (which is why you cant start them anymore without killing them once) ... they dont consume CPU ... what consumes CPU are session services that lose their connection ... media-hub for example
<alecu> dobey: any ideas? ^^^
<iahmad> ogra_, I am testing the image 140
<ribru> alecu: citrain shouldn't care what branch you're branching from
<ogra_> iahmad, great !
<ToyKeeper> ogra_: I just know what 'top' tells me.  An app I previously had open is pegging the CPU as hard as it can.
<iahmad> ogra_, on receiving call, phone freezes some time
<iahmad> ogra_, leading to unity crash
<ogra_> ugh
<alecu> ribru: does that apply to dest branches too?
<ogra_> olli, ^^^
<ogra_> i wonder why we didnt see that the whole day
<iahmad> ogra_, out of 10 attempts, It happened twice
<ogra_> yeah, still to much
<ribru> alecu: yes there's no hardcoded logic for what branches go where. you just feed MPs into the thing and it builds them then merges them
<davmor2> ogra_: have I got news for you http://people.canonical.com/~davmor2/ogra-just-for-you.png http://people.canonical.com/~davmor2/ogra-just-for-you-2.png
<dobey> hmm
<ogra_> davmor2, what is that supposed to tell me ?
<ogra_> oh
<ogra_> lol
<ribru> alecu: ok i did a force rebuild, seems to be doing something now
<ogra_> davmor2, awesome, thanks a lot !
<davmor2> ogra_: that is the emulator on 112 ;)
 * ogra_ didnt even realize it is the emulator :P
<ogra_> took my poor brain a bit
<kenvandine> ribru, any suggestions as to how i can figure out why libupower-glib-dev isn't being pulled in from vivid-proposed?
<kenvandine> ribru, silo 16
<ogra_> so that is good, i guess i can give mako a spin on the weekend so we know its good too
<davmor2> ogra_: so the terminal window and irc in the background weren't a clue ;)
<sergiusens> davmor2: heh, 2g icon should be a blocker in the emu
<sergiusens> davmor2: ... that was a joke btw ;-)
<ogra_> davmor2, that slowly soaked through :)
<kenvandine> my settings build this morning built against libupower-glib-dev from vivid-proposed, which is why it now crashes with the binary sync of powerd
<davmor2> ogra_: falshing mako now
<ribru> kenvandine: ok I set 16 to use proposed, rebuild now.
<kenvandine> thsx
<ogra_> oh,, cool
<davmor2> flashing even
<ToyKeeper> davmor2: Can you test MMS?  Even after setting my custom APN info and verifying I get working cell data, I still can't send MMS.
<ribru> kenvandine: I thought we had recently decided to always build against proposed, no idea why 16 isn't set for that.
<alecu> ribru: yes, it seems to be building ok now, thanks!
<davmor2> ogra_: ToyKeeper is in command on Sanity testing so I'm just hitting the edges
<ribru> alecu: you're welcome
<davmor2> ToyKeeper: yeap sure
<ogra_> davmor2, yep, i know ... and she is hitting things we didnt see the whole day :(
<kenvandine> ribru, ah... thanks :)
<ToyKeeper> I reported a unity8 crash on 139 too...
<ogra_> tyright, which we expected to be fixed with the emergency landing today
<ogra_> *right even
<ogra_> we all ran that silo for nearly the whole EU day ... nobody reported a crash
<ribru> kenvandine: you're welcome
<ogra_> ToyKeeper, good you catched it though :)
<iahmad> ogra_, is it a known issue that system-settings takes forever to launch sometime (after unity crash reboot at least)?
<dobey> ToyKeeper: are you on t-mo us for the mms sending?
<ToyKeeper> dobey: I have two Straight Talk SIMs, one T-Mobile and one ATT.
<ogra_> iahmad, define "unity crash reboot" ... you mean after you reboot after a unity crash ?
<iahmad> ogra_, right
<ToyKeeper> Power cycling my bluetooth headset still causes a kernel panic, too.  :(  (though this time it took like 10 tries instead of just 1 or 2)
<ogra_> iahmad, that apps you had open before a unity crash (note, *not* with a forced reboot) can not start until you kill them once is known, yes
<ogra_> iahmad, if you actually rebooted the device that is not known
<iahmad> ogra_, right, it is the first one
<ogra_> ah, thats ok
<ogra_> but you should not test in that state, if unity crashed, reboot the device
<dobey> ToyKeeper: i was able to send mms last thursday during the sprint, on utopic-proposed, but noticed the other day that i'm no longer ablee to send any on rtm-proposed. so definitely a regression there i think (or maybe something landed in utopic, but didn't make it to rtm?)
<ogra_> there are other known issues that make the phone unstable
<ToyKeeper> dobey: I've never seen MMS work on this device, but usually I don't bother manually configuring the APNs.  I can only get 2G/edge at best anyway.
<ToyKeeper> (wrong type of radio for the US)
<davmor2> ogra_: http://people.canonical.com/~davmor2/lge-nexus-4.png
<ogra_> davmor2, got a SIM you could test one call with ?
<ogra_> last time unlocking didnt work
<dobey> ToyKeeper: i'm using rtm proposed on my n5 as my main phone. i can definitely confirm mms not working, and that it's a regression (though i don't know when the regression happened)
<davmor2> ogra_: you said and I quote boot :P
<ogra_> heh, yeah, its fine :)
<davmor2> ogra_: no give me 5
<dobey> on #117 on my phone right now
<ToyKeeper> dobey: Also, hoping davmor2 can confirm mms on krillin, since I'm on the wrong continent to test that.
<davmor2> ToyKeeper: yeap will do as soon as I finish throwning things at ogra_ so he'll push the promote button Monday :)
<dobey> yeah, i don't have a krillin now. alecu has the one i had
 * sergiusens just had a deja vu on the mms test request
<ogra_> ToyKeeper, i refused to promote without at least having someone boot emuator and mako this time round :)
<davmor2> sergiusens: you sleeping and using irc again
<ToyKeeper> ogra_: Good.  :)
<sergiusens> davmor2: no, just ... just... nothing... too long to explain :P
<ogra_> lol
<pmcgowan> dobey, ToyKeeper just sent an mms from mako to krillin no probs
<davmor2> sergiusens: hahaha
<ogra_> pmcgowan, did you see above ? we still have unity8 crashes :(
<dobey> pmcgowan: :(
<pmcgowan> rtm-proposed on both
<ToyKeeper> BTW, do we care that we have the rotation indicator enabled and that it doesn't actually do anything?  (the control in system-settings works, but the indicator doesn't)
<pmcgowan> ogra_, what no
<ogra_> pmcgowan, iahmad saw one on incoming call, ToyKeeper saw one as well
<ToyKeeper> pmcgowan: At least two of us got a unity8 crash within ~30 minutes.
<pmcgowan> oh crap, I have not
 * ogra_ neither in 5h of testing
<davmor2> ogra_: might be bad news on mako just rebooting
<ogra_> i didnt have an incoming call though
<iahmad> ogra_, so it seems to be frequency is actually higher than 1 in 5
<ToyKeeper> In both cases, the phone didn't recover well...  required a reboot to function correctly again.
<ogra_> ToyKeeper, yeah, thats known ... you shouldnt tets in that state anymore ... people are working on fixes
<ogra_> just note the crash and reboot ...
<ToyKeeper> Just thought I should mention it.
<ogra_> yeah, definitely
<iahmad> ogra_, what I am doing is keep rejecting the call until it reproduces
<ogra_> pmcgowan, ^^^
<iahmad> ogra_, and on fresh reboot, it reproduces on 2nd attempt
<ogra_> oh man
<pmcgowan> just made 5 calls back and forth, but I accepted them
<ogra_> try rejecting then
<kenvandine> ogra_, i now see there was a branch from pitti that was needed for powerd... never landed
<pmcgowan> working so far, does it need to be suspended or something?
<pmcgowan> iahmad, ^^
<ogra_> kenvandine, bah
<pmcgowan> thats one funky ringtone
<davmor2> ogra_, pmcgowan: mako isn't recognising that the sim is locked,  I get unknown in the indicator, no sim pin in the boot, and no unlock option in the indicator,  I can however go into settings, security, simpin and unlock it then then it works.  I'm assuming that is bad though right?
<iahmad> pmcgowan, not really, when it happens, it happens wether device is locked or not
<kenvandine> uncaught exception... looks like the job is still building to me :)
<pmcgowan> davmor2, its not good but not as bad as if it were krillin
<ogra_> pmcgowan, i refuse to promote if mako doesnt half way work
<pmcgowan> ogra_, dunno working fine here
<sil2100> davmor2: I think we're desperate enough to not call that a blocker ;)
<ogra_> pmcgowan, davmor2 says it doesnt
<sil2100> ogra_: on the meeting you said you want to see mako booting!
<pmcgowan> ogra_, for a locked sim, I can try that but I dont lock it
<sil2100> ;)
<ogra_> pmcgowan, all european SIMs come with PIN by default (well, all contract ones)
<pmcgowan> ogra_, so does your mako not work?
<ogra_> pmcgowan, davmor2's doesnt
<kenvandine> yay... citrain figured out that it is still building :)
<ogra_> pmcgowan, boots, but SIM lock isnt recognized
<kenvandine> pmcgowan, are you talking about the sim locked thing?
<ogra_> pmcgowan, dont forget that all our app devs use either mako or emulator
<pmcgowan> yes
<kenvandine> i just noticed my vivid mako couldn't make calls because the dialer-app thought the sim is locked
<kenvandine> but it isn't
<sil2100> davmor2: is that reproducible?
<ogra_> iahmad, i rejceted about 20 calls now ...
<ogra_> no crash
<ogra_> pmcgowan, ^^^
<pmcgowan> kenvandine, thats an old issue on mako although I thought it was fixed
<pmcgowan> ogra_, I rejected 5
<ogra_> pmcgowan, the old issue was exactly the opposite :)
<ogra_> iirc you couldnt unlock
<pmcgowan> ogra_, on mako it thought it was locked when it wasnt - some race
<ogra_> oh, if it is the same issue then we're fine
<ogra_> well ... kind of :P
<pmcgowan> not sure
<kenvandine> yeah, that's what i was just seeing
<kenvandine> never saw it before
<kenvandine> the indicator didn't think it was locked
<kenvandine> but dialer-app did
<ogra_> kenvandine, last promoted rtm had it too
<kenvandine> so i couldn't call
<kenvandine> ugh
<pmcgowan> davmor2, is that what you see? sounds different
<kenvandine> so if i rebooted it might have been ok?
<pmcgowan> kenvandine, I think reboot can fix it
<kenvandine> i put my sim in the krillin for the weekend :)
<kenvandine> i really want to get settings to stop crashing before i EOW :)
<kenvandine> build faster ppa!
<pmcgowan> kenvandine, I used to roll back a deb but it seems to be working for me
<pmcgowan> might be luck
 * ogra_ gives up after rejecting 20 incoming calls 
<kenvandine> this upower transition really took me for a detour today
<davmor2> ToyKeeper: 1 mms sent and received http://people.canonical.com/~davmor2/tiger.png
<iahmad> ogra_, pmcgowan so for last 10 attempts, not able to reproduce, looks like some kind of race condition.
<ribru> kenvandine: wtf? can you find the build log that says unhandled exception? I mean queuebot didn't just make that up, it came from somewhere
<ribru> kenvandine: I'm working on a branch for exactly that type of file not found bs right now, except until now I was only aware of a problem with dsc files, never saw a failure to find the .changes file before
<kenvandine> ribru, no... i can't
<kenvandine> i never saw it in the build log
<kenvandine> it never hiccuped
<kenvandine> but showed in the dashboard and from the bot
<kenvandine> and it cleared itself up :)
<davmor2> ogra_, pmcgowan: once unlocked from system settings the sim works as expected to calls are fine
<davmor2> s/to/so
<davmor2> Just an ugly way to unlock
<pmcgowan> thats good, it could be related to the other issue
<pmcgowan> not getting a valid state
<ogra_> yeah, thats still promotable
<davmor2> pmcgowan: most likely
<ogra_> with a notice though
<davmor2> ogra_: indeed
<kenvandine> ogra_, what should be tested in a powerd landing?
<ToyKeeper> Is mtp supposed to work when the screen is locked?
<davmor2> pmcgowan: is there a bug for that?
<ogra_> kenvandine, no idea :P i never landed powerd
<kenvandine> ok, just saw you reviewed pitti's branch :)
<ogra_> kenvandine, but i bet there is some test plan on a wikipage somewhere
<pmcgowan> davmor2, good question, let me look
<kenvandine> ChickenCutlass, ^^
<davmor2> ToyKeeper: no it is meant to show the device connected but not show you the contents
<kenvandine> ogra_, doesn't appear to be
<ogra_> ToyKeeper, nope, security "feature"
<ToyKeeper> davmor2: Hmm, wasn't sure if that had changed.  MTP is totally working for me when the screen is locked.
<ogra_> it needs to work after unlock though ..
<ogra_> oh, wow
<pmcgowan> davmor2, https://bugs.launchpad.net/ubuntu/+source/telepathy-ofono/+bug/1379836
<ubot5> Ubuntu bug 1379836 in telepathy-ofono (Ubuntu) "dialer and messaging app show unlocked pin as locked" [High,In progress]
<kenvandine> oh... found it :)
<davmor2> ToyKeeper: did you have the device plugged in when you unlocked the screen?
<ogra_> ToyKeeper, thats definitely a bug, when you attempt to access it you need to unlock ... it shouldnt kick you out if it locks then though
<davmor2> ToyKeeper: then let the screen lock?
<ToyKeeper> davmor2: It has been plugged in since boot, and has been unlocked/locked several times.
<ogra_> (only on first connection attempt the screen needs to be unlocked)
<davmor2> ToyKeeper: right so lock the screen, unplug the device and plug it back in
<ToyKeeper> davmor2: Just did that.  :)
<ogra_> right, that should not let you access it
<davmor2> ToyKeeper: now does it show the device and not the contents
<ToyKeeper> Looks like it properly rejects mtp after being plugged in, until the first unlock...  and then it's accepted until it gets physically unplugged.
<ogra_> right
<ogra_> that is how it is supposed to work
<ogra_> fine then
<ToyKeeper> Okay, last I checked, it was a bit more strict.  :)
<davmor2> ToyKeeper: that is it, it's stops bad people stealing your data
<ogra_> adb will behave the same soon
<davmor2> unless they learn to keep the phone awake, lets hope no one thinks of that ;)
<ogra_> davmor2, yeah, if you give away your phone unlocked thats your own fault
<sil2100> davmor2: re: the mako pin unlock bug - does that happen all the time? When was the last time we checked this?
<ogra_> (anybody could just switch off screen blanking)
<ogra_> sil2100, we promoted with it the last time
<ogra_> because nobody had checked mako
<davmor2> sil2100: it's a long term issue
<ogra_> yeah
<davmor2> sil2100: the fact it can be unlocked and works makes us happy though so chill ;)
<ogra_> right
<sil2100> Ok, as long as QA gives it a +1 then I'm ok ;)
<ogra_> emulator boots, mako works with workatrounds
<ogra_> thats enough for now
<brendand> ToyKeeper, i think you got lucky with that headset :)
<brendand> ToyKeeper, you should add the device info to the bug, it looks like an interop issue
<ToyKeeper> brendand: I did that a couple hours ago.
<brendand> ToyKeeper, cool - cyphermox can probably help you debug it
<pmcgowan> davmor2, I am reopening that bug on rtm, your symptom is same as comment 5
<davmor2> ToyKeeper: yeah cyphermox was looking for more bluetooth bugs at the sprint :)
<brendand> sergiusens, which package do BT bugs go in? bluez right?
<davmor2> pmcgowan: that is the very definition of the issue I see :)
 * brendand doesn't have his krillin up to check if bluez is installed
<brendand> davmor2, what's the issue
<brendand> ?
<davmor2> brendand: on mako https://bugs.launchpad.net/ubuntu/+source/telepathy-ofono/+bug/1379836
<ubot5> Ubuntu bug 1379836 in telepathy-ofono (Ubuntu) "dialer and messaging app show unlocked pin as locked" [High,In progress]
<pmcgowan> brendand, yes
<pmcgowan> or settings
<brendand> davmor2, oh that old chestnut. jeez
<davmor2> brendand: see comment 5 , the work around is to open settings â security â sim pin and unlock it there then it works fine
<sergiusens> brendand: it is one target, yes
<sergiusens> brendand: and cyphermox might be able to guide the bug to the right place
<davmor2> brendand: ToyKeeper: bluetooth working fine here
<brendand> davmor2, same for me - as i said probably a device interop issue
<sergiusens> brendand: fwiw, I've listened to two albums over bt on my bose speaker
<davmor2> ToyKeeper: is there anything else you can't test before I call it a night?  MMS in and out work and BT works
<ToyKeeper> davmor2: Nope, I think that's all.
<ToyKeeper> Ooh, that's impressive.  I get a total of 5 entries for each entry on my SD card, via mtp.
<ToyKeeper> I've never seen it do more than 3 before.
<davmor2> ToyKeeper: Cool, I'll leave it with you then, good luck
<ToyKeeper> Long-standing mtp bug though, not new.
<sil2100> davmor2: o/
<brendand> ToyKeeper, i can't seem to view images on the SD card in the gallery
 * brendand wonders can anyone else confirm
<ToyKeeper> brendand: That's what I'm trying to do right now.
<ogra_> not sure thats a supported feature yet
<ogra_> music and videos are
<brendand> ogra_, ah so it never worked?
<brendand> ogra_, maybe true
<ogra_> brendand, as i said, not sure
<brendand> ogra_, tbh i never tested it
* ribru changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: CI Train on halt! No non-blocker landings accepted until image promotion! Please report all build job failures to ribru
<ogra_> i know our SD card media support was very limited for rtm
<pmcgowan> brendand, not supported no
<brendand> pmcgowan, ah right
<sergiusens> and the whole stack is being redone anyways
<pmcgowan> gallery doesnt use the scanner, it needs to
<ogra_> if we keep it :)
<sergiusens> the concept of an sdcard is going away
<brendand> probably not cool it's part of our sanity suite
<pmcgowan> uh oh
<sergiusens> it's just going to "add" to storage
<ogra_> ++
<brendand> pmcgowan, that's an oversight i guess
<pmcgowan> guess that makes sense
<sergiusens> and be encrypted and useless if removed from the device
<pmcgowan> brendand, old baggage
 * sergiusens is still waiting for the final designs
<ogra_> sergiusens, thats bad
<pmcgowan> yeah not sure about that part
<sergiusens> ogra_: not if you look at the big picture
<ToyKeeper> brendand: Actually, I see a pic from SD card in the pictures scope.
<ogra_> sergiusens, encryption should be possible but really optional
<pmcgowan> yeah the scope uses the scanner, thats right
<pmcgowan> nice
<ogra_> sergiusens, i copy data with my SDXC USB3 reader about 50x faster than with USB
<ToyKeeper> brendand: I don't see it in the gallery app though.
<sergiusens> ogra_: depends if you want to land things that aren't supposed to be taken out of there
 * sergiusens hints at drm
<pmcgowan> ToyKeeper, as expected
<ogra_> sergiusens, i wouldnt want to lose that feature for encrypting my music files
<ogra_> which is useless to do
<ToyKeeper> pmcgowan: But if I hit 'open' on that pic, gallery-app launches and doesn't load it.
<pmcgowan> ToyKeeper, aha and thats not good
<pmcgowan> let me seee if we have bug logged
<ToyKeeper> Same with videos...  the scope shows videos on SD, gallery-app doesn't.
<pmcgowan> right
<sergiusens> ogra_: so there are going to be two options; keep it as owned by the user or owned by the device
<pmcgowan> ToyKeeper, can you log a new bug on gallery?
<pmcgowan> there is this one https://bugs.launchpad.net/gallery-app/+bug/1371606
<ubot5> Ubuntu bug 1371606 in gallery-app "Port to use mediascanner rather than libmediainfo" [High,New]
<sergiusens> if owned by the user, it won't change much from what you see today
<pmcgowan> which is related
<ogra_> sergiusens, thats fine then
<brendand> pmcgowan, were videos meant to work?
<pmcgowan> no same issue
<sergiusens> ToyKeeper: pmcgowan the scope preemtively implemented that, but it was never planned for iirc
<pmcgowan> well they should launch in mediaplayer
<sergiusens> brendand: yes
<brendand> pmcgowan, but is it an issue or a missing feature - i.e. is it a regression
<pmcgowan> not a regression but efffect of the new scope
<ogra_> pmcgowan, ToyKeeper only said gallery doesnt show them, she didnt say gallery launches when opening one from the scope ;)
<ogra_> ToyKeeper, do videos launch in mediaplayer from the scope ?
<ToyKeeper> ogra_: Gallery launches when trying to open a photo from the scope...  but gallery-app can't find the pic if it's on an SD card.
<brendand> ToyKeeper, technically that test case didn't fail though
<ogra_> ToyKeeper, talking about videos
<ToyKeeper> ogra_: Videos launch from the scope just fine.  It's only gallery-app which fails.  media-player works.
<ogra_> perfect
<pmcgowan> ToyKeeper, yes lets log that first bug
<sergiusens> ToyKeeper: pmcgowan most likely because gallery doesn't have permissions; can you check DEN in syslog?
<ogra_> that is how it is excpected to be
<sergiusens> or even doesn't look in there for them at all
<ogra_> that opening photos tries to open gallery is a bug
<ogra_> (from SD)
<pmcgowan> what should it open?
<ogra_> pmcgowan, no idea
<ogra_> pmcgowan, not an app that by design cant handle the ource location at least ;)
<ToyKeeper> sergiusens: Bingo, that looks like the issue.  gallery is getting apparmor denials.
<ogra_> design needs to change or we need another app that knows SD cards
<pmcgowan> yep
<ogra_> but sounds like sergiusens decyphered the issue
<ogra_> apparmor profile bug then
<sergiusens> jdstrand: might be able to hack something up ;-)
<jdstrand> what is the denial?
<sil2100> But is that a blocking problem? The SD card thing?
<pmcgowan> not new
<ogra_> heh, i knew ... saying apparmor once summons jdstrand
<sil2100> hah, he has a highlight set for 'apparmor' it seems
<pmcgowan> that user expereince will be weird even if it works
<jdstrand> it was a double whammie-- 'apparmor' and 'jdstrand'
<ogra_> heh
<ogra_> sil2100, no worries ;)
<brendand> pmcgowan, was it definitely in the last promotion?
 * sil2100 has a highlight set for 'blocker'
<pmcgowan> brendand, I would say it was if the photo scope was there
<brendand> pmcgowan, which it was
<pmcgowan> I cant prove it but would say must have been
<pmcgowan> just no one tried that
<ogra_> plars, hmm, looks like 1% wasnt actually enough
<brendand> surprising no-one did
<ogra_> still quite a few systemsettle issues
<ogra_> oh
<ogra_> interesting ... unity now has a settle-before issue
<ogra_> that was the other way round before
<pmcgowan> brendand, you would have to have photos on sd card, go to the scope, try to open one, as ToyKeeper  did
<brendand> pmcgowan, jibel tested it and his comment was 'No content from SD Card' and the test passed
<brendand> pmcgowan, which is confusing
<pmcgowan> brendand, did he mean in gallery? yeah
<brendand> would be good if someone could volunteer to check the current behaviour in #5
<ToyKeeper> brendand: It's worth mentioning that you probably need the photo on the SD card before booting the first time.  So far I haven't successfully made it detect new photos on SD, even when sent via MTP (and even after a reboot).
 * brendand has a feeling it will be him
<sil2100> ogra_: at least it's looking a bit better though
<ogra_> sil2100, yeah ... once the logs are there i'll go over them with my script
<cwayne1> ToyKeeper: even with a pull to refresh?
<ogra_> lets see if there are actual issues
<pmcgowan> ToyKeeper, that also sounds like a bug, the scanner should see them
<pmcgowan> oh pull to refresh makes sense
<ogra_> orthe "pull down refresh" at least
<ToyKeeper> cwayne1: Even with pull-to-refresh.
<cwayne1> huh, that's odd
<cwayne1> that means mediascanner isnt getting them
<plars> ogra_: it hasn't landed yet
<brendand> cwayne1, wfm
<ogra_> plars, OOOH !!! thats very good nes then !!
<ogra_> *news too
<plars> ogra_: I was hoping to get someone to ack it, but it's a super-low risk change. I'll go ahead and push it through
<ogra_> well, the tests have nearly finished now
<ToyKeeper> It detected logs/foo/blah.jpg but not Pictures/us.jpg ...  and I added the second one later via mtp.  Not sure if that's actually the reason why it doesn't show up though.
<ogra_> and we only have half the systemsettle issues it seems
<brendand> ogra_, still half though :/
<ogra_> brendand, without adjusting the value !!
<ogra_> this is significant, we never were so low
<brendand> ogra_, ahhhh
<ogra_> cwayne1, what about the click tests, did you work with mvo on it yet ?
 * ogra_ sees they still fail
<ToyKeeper> So, sanity testing shows three issues: unity8 crashes (on incoming call ~10% of the time, on network indicator use once), gallery not being allowed to access SD contents, bluetooth kernel panics which seem isolated to my particular headset.  And a tendency for the phone to run really slow sometimes while dbus pegs the CPU (intermittent).
<ogra_> pmcgowan, olli ^^
<ogra_> i still cant repro the incoming call crash here
<ToyKeeper> None of the tests actually failed, per se.  Do any of the above block us?
<pmcgowan> good summary, although not sure about 10% crashes I will defer to you
<ogra_> at least not on rejection
<pmcgowan> I cant get any
<pmcgowan> ToyKeeper, that crash is the only one that would concern me, but there seems to be more to reproducing it
<pmcgowan> I would say +1
<ogra_> the dbus thing is really worrying ... but not a blocker atm
<pmcgowan> ideed
<ogra_> should be a super high prio bug
<pmcgowan> is that this one https://bugs.launchpad.net/ubuntu/+source/dbus-cpp/+bug/1380848
<ubot5> Ubuntu bug 1380848 in Media Hub "Apps and services use large amount of CPU after unity8 resets" [Critical,Triaged]
<ogra_> pmcgowan, well, that is connected to a unity8 crash
<ToyKeeper> After I left 139 idle overnight, the dbus thing made the phone so slow it took about 3 minutes to launch system-settings.  :(
<pmcgowan> right
<ogra_> ToyKeeper, but it most likely crashed some time inbetween
<pmcgowan> ToyKeeper, we have another bug on that let me get it
<pmcgowan> specific to battery events
<ToyKeeper> I still think we need a leave-it-idle-overnight test.  :)
<ogra_> which is a known bug ... we need to make sure that unity8 doesnt crash and we are still discussing to force a hard reboot if it still crashes anyway somehow
<pmcgowan> ToyKeeper, ogra_ https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1337200
<ubot5> Ubuntu bug 1337200 in ubuntu-system-settings (Ubuntu) "High CPU due to excessive device changed signals from upower" [High,Incomplete]
<cwayne1> ogra_: agh crap, i forgot about that.. writing it down so i don't forget this time
 * ogra_ leaves his krillin idle over night ... but onteh charger :P
<pmcgowan> maybe that needs bumping up if its more common
<ogra_> cwayne1, well, i'll nag again next week otherwise :)
<pmcgowan> thats te bug, overnight on charger, wake u and flood of events
<ogra_> i dont have issues here
<ogra_> the blinking blue light is the only annoyance i have every morning with my krillin :)
<cwayne1> ogra_: that's fine, with all the nagging I do it's only fair to have some directed at me :P
<ogra_> heh
<cwayne1> the blinky blue light is annoying, but not nearly as bad as the bright white led on my n5 if i get an email overnight
<cwayne1> which is 100% of the nights
<pmcgowan> ToyKeeper, if you can reproduce could get the info pitti asked for
<ogra_> cwayne1, hah, i would be killed by someone for that
<ToyKeeper> pmcgowan: I probably can but it'll take a while...  gotta leave it overnight.
<pmcgowan> ToyKeeper, to answer your question, I guess you submit the report and the mondya morning crew can check it and decide to promote or not, but I think its good to go
<pmcgowan> ToyKeeper, ack
<ogra_> yeah, looks really good imho
<cwayne1> ogra_: hah yeah, fiancee *hates* it :P
<ogra_> put a sock over that area on the phone ;)
<ToyKeeper> I leave a 0.1 lumen light on overnight so I won't trip over stuff.  Ceiling bounced, it's just barely enough to see where I'm going.
 * ogra_ likes it pitch black ... i have my krillin if i need light ;) 
<sergiusens> ogra_: dbus being pegging the cpu could also be the reason for 'i press the power button and the screen takes a while to turn on'
<ogra_> sergiusens, yeah, definitely
<ToyKeeper> I think it may also be the reason for a lot of general UI lag, like not responding (highly variable frame rate) when I try to type in my PIN.
<sergiusens> ToyKeeper: I leave it idle over night lately
 * sergiusens is too lazy too move cables and chargers around
<ToyKeeper> I reflash so often that 'overnight' is the only time it gets a chance to get more than a couple hours runtime.
 * ogra_ hopes the next phone has Qi support ... 
<ogra_> i have a charger on ym nightstand but cant use it wit the krillin
<pmcgowan> ToyKeeper, I did finally get a crash declining a call, but then 10 more without
 * ogra_ still didnt get a single one
<brendand> ToyKeeper, file a bug anyway with the crash report, tvoss/Saviq can look at it later
 * ogra_ goes afk for a while
<brendand> ogra_, btw re: the settle tests, looks like 96.5 is not going to be sufficient
<ogra_> brendand, ohm, are there logs now ?
 * ogra_ doesnt see them yet 
<brendand> ogra_, in the ones that fail on 140 it never gets above 96
<ogra_> oh, you look at the report, not the log
<sergiusens> ogra_: ToyKeeper pmcgowan can you try something? Play music (I was on BT), let the screen do it's power thing (turn off, lock, yada yada), receive a phone call (music pauses), after the 3 minute mark, the music started playing back again
<sergiusens> or brendand ^
<sergiusens> and I was still in the call, so I had to: press back on the phone app, unlock the screen, find the music app, pause
<sergiusens> jhodapp: might interest you too ^
<ogra_> sounds like the "swipe away music app and music still plays" bug
<ogra_> i dont think that landed yet
<sergiusens> ogra_: well I didn't swipe away anything :-P
<sergiusens> ogra_: and it indeed stopped for 3 minutes ;-)
<ogra_> yeah, probably not the same
<ogra_> just sounds similar
<ToyKeeper> sergiusens: I tried, but the music didn't restart until I ended the call (after about 5 minutes call time).
<ToyKeeper> I don't have the slightest clue where to file this intermittent dbus issue.
<sergiusens> ToyKeeper: the dbus issue is logged, ogra_ has the link to it
<ogra_> ToyKeeper, bug #1380848 ?
<ubot5> bug 1380848 in Media Hub "Apps and services use large amount of CPU after unity8 resets" [Critical,Triaged] https://launchpad.net/bugs/1380848
<ToyKeeper> ogra_: Nope, I was trying to figure out where to file a bug about dbus pegging the CPU intermittently during phone use, making everything go really slow.
<ogra_> then file a new one
<ToyKeeper> It's probably not actually dbus's fault, but I don't know what's causing it.
<ogra_> right, file it against dbus as entry point then
<ogra_> (just note in the description what you think)
<ToyKeeper> :)
<brendand> pmcgowan, what's the current opinion on the unity8 crashing?
 * brendand switches to brendand-nexus5
#ubuntu-ci-eng 2014-11-01
<imgbot> === trainguards: IMAGE 5 building (started: 20141101 02:10) ===
<imgbot> === trainguards: IMAGE 5 DONE (finished: 20141101 03:30) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/5.changes ===
<popey> can anyone reproduce bug 1388359
<ubot5> bug 1388359 in unity8 (Ubuntu) "User metrics can no longer be changed by double tap " [Undecided,New] https://launchpad.net/bugs/1388359
<dobey> popey: yes, happens for me on my n5 as well
<dobey> popey: the launcher just keeps bouncing on/off the screen instead
<dobey> launcher bounces on mako too, but i don't have any actual metrics there
<dobey> popey: so definitely a regression there
#ubuntu-ci-eng 2014-11-02
<imgbot> === trainguards: IMAGE 6 building (started: 20141102 02:10) ===
<imgbot> === trainguards: IMAGE 6 DONE (finished: 20141102 03:25) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/6.changes ===
<ogra_> hmpf, today i didnt have a unity crash, just a hard hang of the UI
<ogra_> (top didnt reveal anything, no new .crash files
<ogra_> )
#ubuntu-ci-eng 2015-10-26
<Saviq> trainguards, morning, what need I do about https://requests.ci-train.ubuntu.com/#/ticket/445 ?
<Saviq> sil mentione binNEW, but not sure why?
<pete-woods> trainguards: morning folks, I just tried to do a dual vivid+xenial landing, and I think I just ended up with both going into the overlay PPA
<pete-woods> should I have done something different for the config for the silo?
<robru> Saviq: looks like you just need a core dev to ack & publish
 * Saviq looks around
<Saviq> seb128, I can has core-dev ACK on https://requests.ci-train.ubuntu.com/#/ticket/445 please?
<robru> pete-woods: yep, you set the destination to the overlay so that's where the packages went. You'll need a core dev to copy those to xenial now
<seb128> Saviq, hey, looking, not a trivial one ;-)
<pete-woods> robru: so if I wanted the overlay PPA for vivid, but not for xenial, what should I have done?
<robru> pete-woods: leave dest ppa field blank because that only controls where the primary series goes. Vivid copies always go to overlay
<pete-woods> robru: right okay, that's good to know, thanks :)
<robru> pete-woods: you're welcome!
<pete-woods> might I ask a passing core-dev if they could copy my mistaken package from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.name_filter=cmake-extras&field.status_filter=published&field.series_filter=xenial
<seb128> Saviq, the summary is unreadable :-/
<pete-woods> into xenial?
<seb128> it's like over a full screen of red bold text
<seb128> wth
<robru> pete-woods: it may be helpful to think of it this way: in a dual silo, everything is focused on the primary series. Only the primary series gets tracked in migration, only the primary series let's you set the destination, etc etc. The vivid copies of the packages are sort of just bolted on and hard coded to always go to overlay
<Saviq> seb128, you mean the landing description?
<seb128> Saviq, yes
<seb128> https://requests.ci-train.ubuntu.com/#/ticket/445
<seb128> that page
<pete-woods> robru: yeah, that makes sense now, could have sworn this behaviour has change from the past, though
<Saviq> seb128, it's a behemoth silo, I tried my best
<seb128> is there a pointer somewhere to the diff to review?
<pete-woods> anywa, I know what to do now
<robru> seb128: second from top there's a link to the artifacts
<seb128> would be nice if there one concatenated diff
<seb128> and if the page was not only red text
<robru> pete-woods: nope, vivid copies were always hardcoded to go to overlay. The only thing that changed was that wily copies also went to overlay for a time
<Saviq> seb128, re: not trivial, the -gles reworks are robru's authorship, replacing the need to set changelog and silo in debian/rules
<Saviq> but will only work in silo (or when you get the source yourself)
<seb128> that feels hackish
<robru> seb128: it is hackish but it has reduced the effort required to maintain gles in real terms and also had slangasek 's approval
<seb128> then slangasek should publish it :-)
<robru> Saviq: OK you need to wait 8 hours for Steve to wake up
<seb128> did he state somewhere in public that he was ok with those?
<seb128> like in a irc log I can read
<robru> seb128: it was in emails but I can't remember if it was on a list or not
<Saviq> robru, I got the thread you started after that, don't think Steve weighed in in that thread though
<pete-woods> seb128: if you're feeling super generous could you push my mistaken upload to the overlay xenial series into xenial for real when you've finished reviewing Saviq's mega request? (https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.name_filter=cmake-extras&field.status_filter=published&field.series_filter=xenial)
<seb128> pete-woods, hey, ok, queuing to have a look next
<robru> seb128: Saviq ugh yes it was private irc where he approved it
<robru> seb128: anyway I have no proof of Steve's approval but just realized that this dramatically reduces the amount of maintainance effort on the gles packages as they don't need to point debian/watch at a new ppa every time they do a release.
<seb128> Saviq, robru, diff for other things is fine, I'm happy to press the publish button if you take responsability to deal with potential issues/discussions following the gles changes
<robru> seb128: OK
<Saviq> seb128, ACK
<seb128> Saviq, there you go ;-)
<Saviq> thank you
<seb128> Saviq, nice to see those changes coming btw!
<seb128> yw
<Saviq> seb128, indeed, shame it took so long to land...
<Saviq> freezes, releases, everything that could delayed it
<seb128> Saviq, failed :-/
<Saviq> huuuh
<Saviq> aah
<Saviq> robru, help â
<Saviq> robru, the previous release never migrated https://launchpad.net/ubuntu/+source/unity8
<robru> seb128: oh just hit ignore, that's a bug on silos transitioned from wily to xenial
<Saviq> but we did rebuild after that landed
<Saviq> oof
<seb128> "IGNORE_VERSIONDESTINATION"?
<robru> seb128: yeah
<seb128> let's try that
<Saviq> you can even see in https://ci-train.ubuntu.com/job/ubuntu-landing-022-2-publish/46/artifact/unity8_packaging_changes.diff that the version was there before :)
<robru> Yeah
<robru> Saviq: most likely the last release was to wily overlay. For some reason xenial-proposed is a bit backed up
<Saviq> robru, yup
<Saviq> robru, does train not push to https://code.launchpad.net/~ci-train-bot/unity8/unity8-ubuntu-wily-proposed any more?
<Saviq> only to silo branches?
<robru> Saviq: right. It's the same branch though...
<Saviq> robru, ok, I didn't get a silo branch (didn't build when you added that), but I'll manage ;)
<robru> Saviq: oh awesome
<robru> Saviq: I can push something manually hang on
<Saviq> robru, oh if you can that'd help a bit
<robru> yeah just a minute to whip something up
<robru> Saviq: ok I started a mass-push of all branches currently in the train. could take a while until silo 22 shows up: https://code.launchpad.net/~ci-train-bot
<Saviq> robru, great, thanks
<robru> Saviq: you're welcome!
<robru> oh crap, I hard-coded all the branches to be labelled 'xenial', hopefully that doesn't confuse too many people (any subsequent builds will have correct branch names anyway) Â¯\_(ã)_/Â¯
<robru> Saviq: ok 22 is there
<Saviq> robru, thankski
<robru> Saviq: you're welcome
<robru> Saviq: ah and I've just noticed that train publication is broken, let me fix that...
<Saviq> robru, check out this trick you just made possible https://requests.ci-train.ubuntu.com/#/ticket/564 ;)
<robru> Saviq: oh god what now
<Saviq> robru, while I wait for silo 22 to publish, I can use it to seed my new silo ;)
<Saviq> it == the branch
<robru> Saviq: how did you do that?
<Saviq> robru, https://code.launchpad.net/~ci-train-bot/unity8/unity8-ubuntu-xenial-landing-022/+merge/275672 ;)
<Saviq> robru, packages will be in proposed already, so it's just about the trunks
<Saviq> (or overlay for that matter)
<robru> Saviq: packages aren't in proposed yet ;-)
<Saviq> robru, yeah, note the "will" be ;P
<robru> Saviq: you can just force-merge the silo to get the same effect but you lose migration tracking that way
<Saviq> robru, I'm more interested about conflicts for now
<Saviq> robru, yeah, won't do that in case it's blocked in proposed forever
<jgdx> rvr, let me know if you have questions about that silo 39.
<rvr> jgdx: Ok
<robru> Saviq: *whew* ^^ fixed publishing
<Saviq> :)
<sil2100> jibel, davmor2, ogra_, popey: hey, if you guys are not travelling, meeting ;)
<Saviq> robru, bug in train: http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial+vivid/update_excuses.html#unity8 (note the xenial+vivid)
<seb128> pete-woods, copied
<robru> Saviq: heh, yep, just fixed that in trunk but probably won't roll it out until tomorrow
<Saviq> ack :)
<pete-woods> seb128: awesome, thanks!
<seb128> yw!
<jibel> sil2100, I was in another meeting
<sil2100> jibel: ok, no worries, we can sync on IRC if needed
<morphis> sil2100: when using citrain currently I see:
<morphis> The following packages will be REMOVED:
<morphis>   ubuntu-touch ubuntu-touch-session unity8 unity8-common
<morphis> is that expected?
<morphis> it is with silo 13 which just contains an updated ofono package
<jibel> morphis, did you install another silo with these packages previously?
<morphis> jibel: no
<morphis> it's the most recent rc-proposed image + silo 13
<morphis> jibel: http://paste.ubuntu.com/12968947/
<jibel> morphis, looking
<jibel> rvr, can you confirm that 'silent mode' switches are out of sync between the indicator and system-settings on latest rc-proposed?
<rvr> jibel: Checking
<rvr> jibel: Yes
<rvr> Silent mode active in indicator, off in System Settings
<jibel> rvr, k, I'll file a bug
<jibel> not sure when it regressed
<jibel> rvr, any idea of a silo that could have broke it?
<rvr> Hmm
<jibel> morphis, no problem *without* citrain
<jibel> morphis, trying with citrain now
<rvr> jibel: Related to indicator-sound, we had silo 55 with mpris controls, but I don't think that touched silent mode switch
<jibel> morphis, and I confirm that with citrain it removes unity8
<jibel> sil2100, ^ any idea?
<sil2100> jibel: sadly, no, I don't have any knowledge or experience of the citrain commandline tool
<jibel> morphis, as a workaround for the moment, you can install the silo manually. switch your device rw, add the corresponding entries to sources.list and pin the silo higher than the overlay
<morphis> jibel: yeah, currently looking at citrain
<morphis> jibel: http://paste.ubuntu.com/12969030/
<morphis> went through fine now
<rvr> The following packages will be REMOVED:
<rvr>   ubuntu-touch ubuntu-touch-session unity8 unity8-common
<rvr> Argh
<morphis> jibel: adb shell SUDO_ASKPASS=/tmp/askpass.sh sudo -A apt-get -o Dir::Etc::SourceList=/dev/null update is the faulty line
<morphis> rvr: edit citrain and drop -o Dir::Etc::SourceList=/dev/null from the apt-get update line
<jibel> morphis, yeah but I don't remember the purpose of this line
<morphis> jibel: looks like that is already fixed
<morphis> jibel: it only fetches updates from the silos
<morphis> not from the archive
<sil2100> ogra_: hey, you around for some package publishing? :)
<morphis> jibel: robru already fixed this with https://bazaar.launchpad.net/~phablet-team/phablet-tools/trunk/revision/345
<robru> morphis: jibel please don't edit the script just install the latest version from the ppa
<robru> rvr: ^
<rvr> robru: Ok
<robru> Ooh
<jibel> robru, I don't use citrain :)
<jibel> robru, is the patch released?
<robru> jibel: the fix is released in xenial only. If you're using anything prior to that you can get it from either phablet-team/tools or sdk ppa
<jibel> robru, I'm on xenial
<robru> jibel: the fix just landed in xenial 4 minutes ago ;-)
<jibel> robru, heh :)
<robru> jibel: i dunno why it was stuck in proposed so long, i published it last week
 * rvr is in wily
<jgdx> rvr, bblâin two hours ca.
<rvr> jgdx: Ack
<jibel> rvr, so silent mode switch in system-settings does nothing
<rvr> jgdx: ^
<rvr> jibel: I'm checking in stable
<rvr> jibel: Oops
<rvr> jibel: It's also broken in stable
<rvr> jibel: Silo 49
<rvr> jibel: sound-silent-mode-handling https://trello.com/c/y5CFR6eY/2349-452-ubuntu-landing-049-ubuntu-system-settings-kenvandine
<jibel> rvr, how did it pass testing? There is an explicit test for that
<rvr> jibel: Yes, and I marked it as  passed
<rvr> jibel: I don't know whether that's the culprit, but seems related
<jibel> rvr, it looks like the silo you're testing contains the fix https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/fix-sound-ap-regression/+merge/275038
<rvr> Oh, I didn't finish installing the ppa
<rvr> I will check it then
<rvr> No bug attached
<rvr> jibel: Silo fixes the sync between indicator and System Settings, indeed
<rvr> seb128: Do you know which silo introduced the sound regression?
<rvr> -                property variant silentMode: action("silent-mode")
<rvr> 20	                 property variant highVolume: action("high-volume")
<rvr> So it was the one that I tested
<rvr> jibel: It was my fault
<popey> is silo 22 going to land sometime soon? :) (I have a conf at the weekend, wanted to try and demo it) :D
<jgdx> jibel, don't know how it wasn't picked up in manual testing, but the automated test failed as well and noone noticed.
<jgdx> though, our suite saw many many spurious failures at that time, so it was easy to miss
 * jgdx really bbl
<jibel> jgdx, yeah, there is a test in our regression testsuite and the tester marked it as passed. It's clearly a failure on our side, I'll talk to him.
<rvr> popey: ping
<popey> rvr, hello
<rvr> popey: Do you know when if music app being updated for mpris controls?
<rvr> s/if/is/
<popey> Heh
<ahayzen> rvr, yes, we are working on it ;-)
<ahayzen> waiting for the media-hub and indicator-sound bugs to be fixed first :-)
<rvr> ahayzen: It should land for OTA7
<ahayzen> rvr, it can't too many bugs at the moment in the background-playlists implementation
<popey> it needs fixing in the platform _first_
<rvr> ahayzen: Are you waiting for ready-for-testing silos?
<ahayzen> rvr, i believe Jim has another one WIP, but i would need to check with him if any are ready
<ahayzen> silo015 looks possible, but i need to link music-app to its new commands to totally test (which i'll do when back from lectures later :-) )
<rvr> ahayzen: Ok, I will test silo 15 after I'm doing with the current one
<rvr> I'm done
<ahayzen> rvr, cool, not sure if Jim has any mini-apps to prove that the new command works or is faster
<rvr> ahayzen: popey: Can you coordinate with Jim?
<popey> rvr, we are and have been for some time
<rvr> Great
<ahayzen> yup :-)
<popey> We keep getting asked about mpris in music app as if _we_ are the blocker here.
<ahayzen> hehe
<popey> Which most certainly isn't the case.
<rvr> popey: Sorry, I understood that after the indicator sound landed, only music app update was required
<popey> Yeah, a few people assumed that :)
<ahayzen> hah
 * ahayzen has a list of issues :(
<popey> Fact is, if we gave you the in-progress branch for music app, you'd reject it from QA perspective.
<popey> I don't think mpris should have landed _at_ _all_ until music issues were fixed
<popey> but that's just me :)
<ahayzen> popey, there is work in the scopes which needed it ;-)
<rvr> popey: Yeah, I try to test it and it was a failure
<popey> Yeah, it's big and invasive.
<rvr> popey: The mpris silo had four or five failures
<popey> Glad ahayzen and jim are working on it.
<popey> erk
<popey> :)
<rvr> Ah, the scopes too
<popey> fun times :)
<ahayzen> \o/
<rvr> Hmm
<rvr> sil2100: ping
<sil2100> rvr: pong
<rvr> sil2100: Tomorrow is string freeze. Does it make sense to delay to Wednesday the language export, or to make a new one?
<sil2100> rvr: I think we can make a new one on Wednesday
<sil2100> Anyway, another auto-export will happen next week anyway
<rvr> sil2100: I still wish more frequent exports :(
<sil2100> For rc-proposed I guess we could have that, since the exports take like 5 minutes anyway
<sil2100> But for now we can poke manually
<jibel> sil2100, once a day is probably overkill but at least one on feature freeze day would be good.
<sil2100> I originally wanted the syncs to happen on Wednesdays, so after FF, but I remember pitti had some concerns
<sil2100> But those might have been related to time needed for the exports to happen
<sil2100> (which is minimal here)
<jibel> sil2100, lets freeze a day earlier ;)
<Saviq> trainguards, qtmir won't migrate in xenial (bug #1510067), I'm gonna force merge&clean in silo 22 and skip the release to xenial, unless you think I shouldn't?
<ubot5> bug 1510067 in qtmir (Ubuntu) "qtmir rebuild fails with "assertion fail ../../bfd/elf32-i386.c:5245"" [Undecided,New] https://launchpad.net/bugs/1510067
<sil2100> Saviq: hm, I think +1 on force-merging
<sil2100> As long as you'll keep track of that it's fine with me
<Saviq> yeah I will
<bfiller> sil2100: how do I change silo 48 to xenial+vivid? it was pre-existing and using wily+vivid
<sil2100> bfiller: hey! You need to reconfigure it to xenial+vivid on bileto and then I'll do a binary copy of your wily packages to xenial
<sil2100> bfiller: was it ready for release?
<bfiller> sil2100: no not yet
<bfiller> sil2100: need to rebuild it first and finish test
<sil2100> Then I think a reconf to xenial+vivid and a rebuild of all packages would suffice, I'll remove the wily binaries then
<bfiller> sil2100: thanks
<jhodapp> jibel, hey, I had emailed you a few months ago about getting some non-autopilot integration tests running for media playback...have you learned anything more about who I would need to talk to in order to get these tests automated?
<bfiller> sil2100: seems builds are failing, out of disk space: https://ci-train.ubuntu.com/job/ubuntu-landing-048-1-build/72/console
<jgdx> sil2100, +2 on that, https://ci-train.ubuntu.com/job/ubuntu-landing-047-1-build/43/console
<jgdx> âmktemp: failed to create directory via template '/tmp/debsign.XXXXXXXX': No space left on deviceâ
<sil2100> Argh, again
<sil2100> On it
<jgdx> thanks!
<sil2100> hmm, not sure if this will help, could you guys check?
<sil2100> The instance seems to have some size issues, I already see that there's not too much disk space available in overall
<jgdx> check wat
<sil2100> The disk that has all the pbuilders is like 10G, which seems really not enough
<sil2100> jgdx: check if rebuilding now works
<jgdx> ack
<jgdx> !build 47
<jgdx> :'(
<jgdx> okay, in work
<jgdx> sil2100, failed
<jgdx> new error msg but same symptom
<sil2100> hmmm
<bfiller> same with me
<sil2100> uh
<jgdx> http://i.imgur.com/ji1pen2.png
<Trevinho> trainguards, can I do a direct push to lp:unity and lp:unity/wily  just to make a release (bump version numbers, add changelog...). But I don't want to release that on distro (at least, not yet and not in wily)
<Trevinho> I mean, I want do do an Upstream only release, with new tarball and such...
<Trevinho> sil2100: maybe you know ^ ?
<sil2100> Trevinho: hey!
<Trevinho> sil2100: hey
<sil2100> hmmm... why would you want to do an upstream release without releasing it to the archive?
<sil2100> I mean, well, it poses some problems in the current model
<Trevinho> sil2100: because I don't want to do an "SRU" for wily
<sil2100> As normally everyone expects that trunk == release
<Trevinho> I just want to close the 7.3.3 gate move all the bugs waiting love there to the 7.4 milestone and release a tarball
<Trevinho> but i wanted that to be on the wily branch, not only on the xenial one
<Trevinho> And if we'll do an SRU to wily later, archive and upstream will sync again
<sil2100> hm, as said, I would personally prefer only doing releases when an actual release happens, but in the CI Train world we leave branch management to upstreams
<sil2100> So I guess you can do that, but it would confuse me personally
<Trevinho> mh, ok... All that I don't want is that to break anything
<Trevinho> sil2100: I mean, if the changelog in upstream is newer than the one downstream
<sil2100> Trevinho: you'll get a warning, nothing to worry about
<Trevinho> ok thanks
<pstolowski> hello trainguards, i've recurring problem with silo 8 - No space left on device
<sil2100> pstolowski: hey, yeah, it's a known issue, looking into that in a moment
<pstolowski> sil2100, ack, thanks
<morphis> sil2100, robru: something seems to be really flawky with the citrain builds: https://ci-train.ubuntu.com/job/ubuntu-landing-052-1-build/64/console
<morphis> tried five attempts but all failed: first because of no space, second cause of package upgrade, after that they fail with some jenkins errors
<sil2100> Yeah...
<sil2100> Poking IS/webops
<sil2100> Since this is something I can't help with, as now jenkins jobs fail running at all
* sil2100 changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? ping cihelp | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: CI Train jenkins has disk-space issues
<rvr> jgdx: Approving silo 39.
<jgdx> rvr, thanks.
<morphis> sil2100: ok
<sil2100> Webops are on it, they're trying to make more space
<sil2100> For now they freed up some but this might not be enough
<sil2100> morphis, bfiller, pstolowski: could you guys re-try your builds?
<pstolowski> ok
<sil2100> Webops moved the pbuilder stuff to persistent storage, symlinking to the original place, want to see if it didn't break anything
<morphis> sil2100: running again
<bfiller> mterry: mind publishing silo 23?
<Saviq> cihelp hey, can we please switch unity8-ci job to vivid and xenial? thanks
<mterry> bfiller, let me look
<mterry> bfiller, done ^
<bfiller> mterry: ty
<sil2100> \o/
<sil2100> mterry: can I ask you for some other publishings? :)
<mterry> sil2100, sure
<sil2100> mterry: https://requests.ci-train.ubuntu.com/#/ticket/519 :)
<mterry> sil2100, why no QA on an SRU?
 * mterry is often confused about what needs QA
<sil2100> mterry: it's a non-touch package, we only do QA sign-off for touch projects
<sil2100> (non-touch packages)
<mterry> sil2100, ok
<sil2100> SRUs get the QA in the SRU queue :)
<mterry> sil2100, fair...
<sil2100> morphis, bfiller: the train working fine for you guys?
<bfiller> sil2100: doesn't seem to be working correctly for silo 48.. not seeing anything building on the ppa
<jgdx> same for 47
<morphis> sil2100: still building :)
<bfiller> sil2100: stuck on "preparing packages"
<bfiller> sil2100: and silo 23 which mterry published seems to be stuck on status: publishing
<dobey> rvr, jibel: can we have pay-ui in the qa review queue before the pay-service silo? this way the pay-ui change can be tested against the current pay-service, and we can get it in the store so that the new pay-service silo will then get tested against the new pay-ui too
<rvr> dobey: Sure
<sil2100> bfiller: looks like it moves ;)
<dobey> rvr: great, thanks
<jgdx> sil2100, https://ci-train.ubuntu.com/job/ubuntu-landing-047-1-build/47/console
<jgdx> is that still the space issue?
<fginther> Saviq, We're still in the process of getting builds setup for xenial. I'll add unity8 to the list once it's ready.
<Saviq> fginther, ack, thanks
<sil2100> jgdx: try again now, we just recently 'fixed' the space issue
<sil2100> jgdx: I had to ask webops for help as I didn't have enough power myself
<balloons> josepht, how's the re-deploy of my jenkaas coming? I'm thinking it might be useful to test the backup and restore as well. Can we manually take a backup before doing it though so I don't hate my life in redoing things? :-)
<josepht> balloons: the MP just landed.  You will now need to request an upgrade of your jenkaas from IS.  I'd discuss with them doing a manual backup as well.  I don't think we have the means to easily backup the master from a job since we don't allow execution of jobs on the master.
<josepht> fginther, psivaa: have a missed anything? ^
<josepht> Ursinha: do you want to request the core-apps upgrade or should balloons do it?
<sil2100> bregma: ping
<balloons> josepht, ok, I'll make doubly sure I have a backup, and then I'd like to do a full redeploy if you don't mind. It needs to be tested
<fginther> josepht, balloons, Correct, we don't have means to do a manual backup ourselves (we can make a backup of all the job configurations if that helps). IS can probably do that if specifically asked
<sil2100> bregma: hey! So, I want to publish silo 55
<balloons> fginther, how would you back up the job configs? That would represent a big portion of what's needed atm anyway, as little real data is in there right now
<balloons> only about a week's worth
<fginther> balloons, this is what I use - http://bazaar.launchpad.net/~canonical-ci-engineering/uci-jenkins-utils/trunk/view/head:/jenkins-dump-config.py
<sil2100> bregma: actually, I see everything is ok, so nvm :)
<fginther> balloons, it has a dependency on 'python-jenkins' from https://launchpad.net/~jenkaas-hackers/+archive/ubuntu/tools
<ChrisTownsend> sil2100: I think if it publishes, then the last two changelog entries that are currently in the archive will be wiped out.
<fginther> balloons, I have a script somewhere to push a config.xml file to jenkins as a job configuration. I should get it added to uci-jenkins-utils
<ChrisTownsend> sil2100: A core dev updated libertine underneath this landing.
<sil2100> ChrisTownsend: no problem, those were quick-fixes, I checked that those are actually 'fixed' in the landing itself
<ChrisTownsend> sil2100: Right, I was just meaning the changelog history.
<sil2100> Yeah, that's ok
<ChrisTownsend> sil2100: Ok, then I won't worry about it:)  Thanks!
<balloons> fginther, this looks great thanks. It will at least keep the job configs. I bet python-jenkins can do other fun things with automating job creation. Have any scripts around restoring jobs, or making a set of jobs from a template
<fginther> balloons, I've relied on python-jenkins for most of my scripting in the past. It's not perfect, but it has a simpler API for most tasks (vs using curl for example). And yes, we've done some work around templating, this is basically what lp:cupstream2distro-config is for
<fginther> balloons, But I am in now way endorsing lp:cupstream2distro-config as a way to solve any current or future problem :-)
<brendand> fginther, is cu2d sticking around for the foreseeable?
<Saviq> robru, hey, does train only push to lp:~ci-train-bot/ on successful builds?
<sil2100> Saviq: not sure if that changed or not, but in the past it was pushed only on publish
<Saviq> sil2100, yeah, that changed
<Saviq> sil2100, https://code.launchpad.net/~ci-train-bot
<sil2100> ACK
<Saviq> just wondering when (i.e. I predict a build failure, but that's when I could use the branch ;))
<bfiller> sil2100, fginther: anyone know what's up with the calexda-pbuilder instances? they've all been busy for quite a while. trying to build http://s-jenkins.ubuntu-ci:8080/view/click/job/camera-app-click/ and building silo 48 taking forever waiting for builders
<fginther> bfiller, There is a large number of builds in progress right now on s-jenkins. All the builders are working right now, just appears to be an unusually high demand
<bfiller> fginther: ok
<jgdx> sil2100, okay, thanks.
<pstolowski> sil2100, no disk space problem in silo 8, but there's something wrong with dependencies
<sil2100> pstolowski: dependencies?
<pstolowski> sil2100, http://pastebin.ubuntu.com/12971383/
<pstolowski> hmm not sure if it actually breaks anything
<Trevinho> robru: FYI, here https://ci-train.ubuntu.com/job/ubuntu-landing-011-1-build/306/consoleFull I got this
<Trevinho> 2015-10-26 17:14:20,157 INFO Checking bamf for new commits...
<Trevinho> 2015-10-26 17:14:20,382 INFO bamf has no new commits, skipping.
<Trevinho> 2015-10-26 17:14:20,383 INFO Checking compiz for new commits...
<Trevinho> it was a clean build though
<rvr> jhodapp: Silo 15 approved
<jhodapp> rvr, yay!
<jhodapp> thanks
<jhodapp> robru, mind publishing silo 15 please?
<jhodapp> rvr, I feel like I asked this of you before but I forget what you said, but do you have publish permission as well?
<jhodapp> cyphermox, ping
<robru> jhodapp: if it's all MPs and no packaging changes then you can publish your own
<jhodapp> robru, unfortunately it's not, includes a qtmultimedia source package change
<robru> Saviq: it pushes the branches after a successful merge.
<jhodapp> robru, so if everything is to land in the overlay ppa, then I have permissions...is that accurate?
<robru> jhodapp: ah, you need a core dev then
<jhodapp> yep
<robru> jhodapp: nope, train treats overlay just like real archive, requires same permissions
<Saviq> robru, oh good, missed it somehow
<jhodapp> robru, then what's the general rule for which I have permission to publish?
<robru> jhodapp: if there silo contains only MPs, no manual sources, and no packaging changes
<jhodapp> robru, ok
<jhodapp> ogra_, you're a core dev, care to publish my silo 15 if you're around?
<sil2100> jhodapp: mterry might be a good choice too!
<jhodapp> sil2100, cool, mterry ^
<sil2100> He's usually nice enough to publish silos for us ;)
<jhodapp> sil2100, mterry got scared away ;)
<sil2100> hmmm
<sil2100> ;)
<sil2100> mterry: pong!
<mterry> sil2100, hihi
<sil2100> mterry: hey! Could you publish some silos for us? jhodapp has silo 15 for release :)
<jhodapp> mterry, pretty please :)
<mterry> sil2100, 15... ok
<jhodapp> thanks
<cyphermox> jhodapp: hey
 * mterry is reviewing
<jhodapp> cyphermox, yo, I got mterry to do my dirty work of publishing silo 15...so don't need your services anymore
<mterry> doh  :)
<jhodapp> thanks mterry
<mterry> jhodapp, yw!
<bfiller> popey: mind review latest camera-app in the store?
<popey> bfiller, sure thing, will do right now.
<bfiller> popey: ty
 * sil2100 hugs mterry 
 * sil2100 gets back to his system-image
<Saviq> robru, so, how about automagically adding -gles twins to silos, without an MP even?
<jhodapp> Saviq, I'm +1 to that idea
<robru> Saviq: jhodapp yeah I like that idea too just a lot on my plate unfortunately
<robru> Saviq: jhodapp can one of you guys send me a summary of how the packaging is different between gles and non-gles? Eg if I took your non-gles trunk, copied the dir, what change do I need to make there to make it build against gles instead?
<jhodapp> robru, I don't know the details to that, Mirv always handles that for me for qtmultimedia
<robru> hm
<robru> Trevinho: that's because the previous build recorded the commit id even though it failed.
<robru> Trevinho: I'll file a bug, not sure how to fix that though
<robru> Trevinho: https://bugs.launchpad.net/cupstream2distro/+bug/1510230
<ubot5> Launchpad bug 1510230 in CI Train [cu2d] "Commit id tracking suboptimal." [Undecided,Triaged]
<Saviq> robru, I don't think that's possible, the changes are significant
<Saviq> robru, basically, the -gles branch is a packaging branch almost in its own right
<robru> Saviq: you don't think it's possible to determine -gles programmatically from trunk?
<Saviq> robru, I'm afraid not
<Saviq> robru, just getting a diff for qtmir
<robru> Saviq: then I'm not sure how I could make the train handle it automatically, if you guys need to manually sync packaging changes from one to the other
<Saviq> robru, http://pastebin.ubuntu.com/12973106/
<Saviq> robru, well, you can just default to lp:qtmir/gles when you see qtmir
<Saviq> robru, and if we need to supply MPs, we will
<Saviq> robru, as you can see, it's already outdated, which is a pain, but I really don't think how we can create that diff automagically
<Saviq> biab
<robru> Saviq: yeah that's pretty crazy
<Saviq> robru, but what I think we could do, is just get -gles trunks regardless if there are MPs against it or not
<robru> Saviq: I suppose it's possible. Can you file a bug?
<Saviq> robru, yup, will do, thanks
<robru> Saviq: thanks
<robru> Saviq: how's things otherwise though? train is operating smoothly for you?
<Saviq> robru, just having issues with conflicts now, but that's rather bzr's fault than trains
<Saviq> +'
<Saviq> robru, one thing is somewhat confusing: https://requests.ci-train.ubuntu.com/#/ticket/564
<robru> Saviq: what's confusing?
<Saviq> robru, dirty flag has precedence over other states, which means I don't see the build job state here
<Saviq> robru, it's build failed, but it only says silo dirty
<robru> Saviq: right
<robru> Saviq: the problem is that the silo status is just a free form string so it's getting increasingly hard to show different info there, because eg dirty state is determined at a different time than the build failure, so one clobbers the other
<robru> Saviq: I guess that'll need to grow a bit more clever so it can have a dirty flag but still preserve the original failure message
<robru> Saviq: for now if you look at the audit log you can see the failure
<Saviq> robru, yeah, I understand, and not complaining, although the dirty flag seems also quite persistent
<Saviq> robru, like if I kicked a build, and it failed, it shouldn't go back to dirty
<Saviq> but it seems only a successful build clears it today
<robru> Saviq: yeah that's because we had a problem where maybe one package is marked dirty, if you rebuild only a different package it clears the dirty state even though the other package is still dirty. so I made it more agressive about marking silos dirty
<Saviq> robru, sure, I'm dealing with it
<robru> Saviq: also silos now become dirty just by having a new commit on your MP (it used to be just by publishing a conflicting silo)
<Saviq> robru, yeah yeah, I know, but it's not the case here
<robru> Saviq: yeah I agree it's not great, need to think about it a bit to make it work better
<Saviq> robru, it did become dirty due to commits, but now without a successful build (which I'm struggling with due to conflicts) it won't get cleared
<robru> Saviq: that's odd, it should clear the dirty flag at the beginning of the build
<robru> Saviq: oh, no, I see
<robru> Saviq: the build clears the dirty flag but when the build fails, the cron job runs and marks it dirty again
<Saviq> robru, could be, yeah
<robru> Saviq: yeah I'll need to add a new field in the db for recording dirty states, so that the main status can be preserved.
<robru> Saviq: I just rolled out a small train change (just a code cleanup, shouldn't be any noticeable behavior change), and I'm just going to step out for lunch, if anything explodes I'll be back in 30
<robru> (I tested it in the staging instance though, should be harmless, but there's always a slight risk...)
<robru> anyway brb
<Saviq> robru, ack
<michi> robru: I just sent an email, could you have a squiz please? Iâm looking for inspiration...
<robru> michi: looking
<michi> Ta!
<robru> michi: https://launchpadlibrarian.net/222338585/DpkgTerminalLog.txt this seems more instructive. I guess there's a missing dep on something or other? not sure
<popey> bfiller, something is up with the store, i thought the camera was published, but it's still showing as needing manual review
<popey> I don't know why
<bfiller_> Popey: do I need to do anything?ï¿¼
<michi> libapt-pkg.so.4.16
<michi> Never heard of it...
<popey> bfiller_, i think a store admin needs to look at it. i asked in #u1-internal
<michi> robru: So, this looks like a problem with click.
<michi> Thanks for your help!
<popey> ok, bfiller_ got it, it's approved.
<bfiller_> popey: thanks
<robru> michi: more specifically it's an import error which suggests to me that there's a dep missing, not sure what package provides that but shouldn't be too hard to dig it up.
<michi> robru: Hmmmâ¦ We have a dependency on click. But if click needs libapt-pkg, I guess thatâs a missing dependency in click.
<robru> michi: strange that that would be overlooked or that more people aren't affected
<robru> michi: also strange that one bug is from utopic and one from vivid, I thought this might be some new issue in xenial or something
<michi> So far, Iâve seen only these two reports
<michi> But xenial isnât involved, as far as I can see.
<robru> brb tho, eating
<michi> I donât think any xenial build for scopes-api exists yet.
<michi> Hey, take your time! :)
<jgdx> bfiller_, hey, silo 47 just went to QA.
<bfiller_> jgdx: cool. did 39 land?
<robru> michi: yeah it wouldn't need a xenial build specifically, i was thinking maybe the wily build that got copied to xenial could have been broken by changes in click in xenial. But it's not xenial so that's not the issue anyway ;-)
<michi> robru: Yes. Iâve added click to the bug. Letâs see what comes up. Iâm pretty sure itâs not a scopes-api problem.
<michi> Thanks again!
<robru> michi: agreed, definitely an issue in click, you're welcome
<brendand> Saviq, didn't silo 22 land in xenial?
<Saviq> brendand, almost there, there was a toolchain issue that's now solved
<brendand> Saviq, ah
<Saviq> brendand, just waiting to test & migrate
<Saviq> for some reason http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtmir-gles still says i386: Regression, even though if you click on it it's passed twice already
<brendand> Saviq, because they're all the same version?
<robru> brendand: the passes have newer timestamps though
<robru> That is weird
<brendand> agh it's in perl !
<brendand> my eyes
<robru> What is?
<brendand> robru, debci
<robru> Heh.
<brendand> Saviq, here it says pass too: http://autopkgtest.ubuntu.com/packages/q/qtmir/
<brendand> except on armhf
<brendand> Saviq,  this is what's stopping unity8 from migrating?
<brendand> oh actually it's mostly ruby
#ubuntu-ci-eng 2015-10-27
<veebers> robru: hey if you're still around. I've used "citrain device-upgrade " and now my device doesn't boot past the bq screen. Have you seen this before?
<robru> veebers: what version of phablet-tools-citrain do you have installed?
<robru> veebers: and in the log did you see citrain tool uninstalling the entire world?
<robru> veebers: I fixed a ton of bugs in citrain tool recently, make sure your installed version has an october timestamp in it. Install from phablet-team/tools or sdk ppa
<robru> veebers: or update to xenial ;-)
<veebers> robru: hah, ok will check version etc.
<veebers> robru: (in a step I should have taken earlier) looking at the output I see:
<veebers> The following packages will be REMOVED:
<veebers>   ubuntu-touch ubuntu-touch-session unity8 unity8-common
<robru> veebers: yeah that sounds like the bug I fixed.
<robru> veebers: alright I gotta run but will be back in ~2 hours if you ned any more help
<veebers> robru: ack, cheers. Will install from ppa
<cjwatson> michi__: Agreed that it's click's problem, though not a missing dependency.  Analysis in the bug.
<robru> veebers: ok I'm back, did you get everything working?
<veebers> robru: aye, using the ppa worked
<robru> veebers: great
<nerochiaro> cihelp: i see some settle_before and settle_after failures in this MR, mixed with AP test failures. should i worry about the tests or just re-run the job before having a look ? https://code.launchpad.net/~uriboni/webbrowser-app/tabs-use-haptics/+merge/275726
<psivaa> nerochiaro: it actually depends on the failures. if you'd want to rerun and see if the failures are reproducible then that's fine, but taking a look at the failures are always recommended
<nerochiaro> psivaa: the reason i ask is because i become skeptical of failures in tests when i see mixed with them failures in infrastructure
<psivaa> nerochiaro: which are the infrastructure failures?
<nerochiaro> psivaa: settle_before and settle_after, like this: https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/3886/testReport/junit/%28root%29/webbrowser_app/settle_before/
<psivaa> nerochiaro: I would not consider this to be an infrastructure failure, the system_settle failures should also be investigated as regular failures especially when there are all passes in the runs before and after this particular run.
<nerochiaro> psivaa: how do i investigate them ?
<psivaa> nerochiaro: they could be transient (or flaky) failures, but that needs to be confirmed
<psivaa> nerochiaro: re-running the job with the same parameters in this case would confirm if they are transient
<nerochiaro> psivaa: i'll request a re-run
<psivaa> nerochiaro: and i see that there are no settle_after/ settle_before logs for those failures, which would make investigating those failures impossible, but please note that there are some crash files here: https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/3886/artifact/clientlogs/webbrowser_app/
<nerochiaro> psivaa: are they from that same test run ?
<psivaa> nerochiaro: yes
<Saviq> brendand, yeah, it's all slowly migrating now
<Saviq> seems unity8 is the last to migrate, testing unity-scope-click now
<jibel> Saviq, Are you sure unity-scope-click is running? It has been in this state for a while and I don't see it on http://autopkgtest.ubuntu.com/running.html
<jibel> or maybe it is just still waiting for an executor
<Saviq> jibel, it says it's running ;)
<jibel> Saviq, yeah but it's strange that it's done on other arch and still running on i386
<jibel> and not listed on the "running" page
<Saviq> jibel, agreed
 * Saviq asks pitti
<Saviq> jibel, pitti's looking into it, known issue
<Saviq> sil2100, are you the framework master these days?
<sil2100> Saviq: hey! Master - no, 'maintainer' - yes ;)
<sil2100> What's up?
<Saviq> sil2100, where can we find what the most recent framework included?
<sil2100> Saviq: that's not so easy, you would just have to see what's up the latest OTA-7 image, as frameworks do not define any hard list of pulled in deps
<sil2100> So it's basically whatever was in the image that first had the framework defined
<Saviq> sil2100, yeah, which sounds like a problem...
<Saviq> sil2100, how are devs supposed to know what they can safely use?
<Saviq> UITK 1.3 moved a long way since then (btw, the framework first appeared on rc-proposed before OTA7, but that we can probably ignore)
<sil2100> Saviq: true, in any case UITK 1.3 is the toolkit version to target for 15.04.1, but yeah, I suppose it might be troublesome if 1.3 had additions later on
<Saviq> sil2100, yes exactly, it had
<Saviq> and important ones
<sil2100> Saviq: not sure how the framework idea got invented, but quoting lool: it's a "contract without the terms of the contract"
<Saviq> sil2100, so... working within the constraints of frameworks as we know them today, we need to publish the list of packages that are on OTA7
<Saviq> sil2100, I would plan a new framework for OTA8 already
<sil2100> If the number of additions/changes in 1.3, I would maybe later bump the UITK version and add a new framework for it
<sil2100> I mean, if the number is high
<Saviq> sil2100, we can't bump the 1.3 bit, there is minor version that's bumped with every release (that's actually a revision number from staging)
<Saviq> sil2100, 1.3 has to stay because it corresponds to "import ... 1.3" in qml
<Saviq> sil2100, basically 1.3 isn't completed yet (it's stable wrt. deprecations, but additions are happening all the time)
<Saviq> sil2100, which means "1.3" isn't precise enough
<sil2100> I think we need a common place where the UITK -> framework binding would be available
<zsombi> sil2100: nope, we will not bump the version.. as then every time new stuff is added in an OTA we will need to bump the import
<sil2100> i.e. what features of 1.3. are available in which framework
<zsombi> sil2100: and the user space on the device si limited
<Saviq> ugh, why do we still have 14.04 -dev1 frameworks on the phone, thought those go away :/
<zsombi> sil2100: beside, every time the apps would need to adapt to the imports... so it woudl be a nightmare
<zsombi> sil2100: and we would have lots of unfinished work in each framework
<zsombi> s/framework/UITK version
<Saviq> sil2100, we either need to have a seed/seeds that actually depend on the packages/versions that we say a framework includes, or some place where the map is published
<Saviq> and we need to clear the -dev frameworks from devices...
<Saviq> except for the most recent one
<Saviq> sil2100, the current situation of "oh yeah, that framework was first published with OTA7, so whatever was there"... especially if we can't easily say what's there
<Saviq> the full list of packages in OTA7 is not an indicator either, because packages can come and go, a framework can only include a subset of APIs that we commit to maintaining
<sil2100> I never really understood the principle of how this framework model was supposed to work
<sil2100> I might try getting rid of the -dev ones if needed
<sil2100> Anyway, I suppose from a developer POV it would be best if there was a place that would say: hey, 15.04.1 framework, you can use this and that from 1.3 UITK etc.
<sil2100> But right now it's all a fuzzy thing
<rvr> dobey: ping
<Saviq> sil2100, yeah, it's quite random
<Saviq> sil2100, UITK has an auto-generated .api file that lists all components and properties available, it's trivial to do with QML
<Saviq> so a set of those files could be a start
<Saviq> we should probably have per-framework docs, too, ideally with /since markers
<sil2100> +1
<sil2100> I suppose that's a valid work-item for the nearest time
 * sil2100 just needs to finish something before feature freeze
<sil2100> ;)
<Saviq> robru, you asked for a bug #1510515
<ubot5> bug 1510515 in CI Train [cu2d] "Auto-build -gles twins" [Undecided,New] https://launchpad.net/bugs/1510515
<dobey> rvr: hi
<rvr> dobey: Hi
<rvr> dobey: Check card in trello
<dobey> rvr: weird. sounds like online-accounts-ui is broken there maybe
<rvr> dobey: Let me check without the silo
<rvr> dobey: Without the silo it works
<dobey> rvr: i'm upgrading to latest image on my mako and trying again there too
<dobey> rvr: without silo 26?
<rvr> dobey: Sorry, without pay-ui click update
<dobey> rvr: that's very odd
<dobey> rvr: it's working fine here. :-/
<rvr> dobey: Which image are you using?
<dobey> channel: ubuntu-touch/rc-proposed/ubuntu
<dobey> on mako
<dobey> #273
<rvr> dobey:  arale ubuntu-touch/rc-proposed/meizu.en 148 here
<dobey> rvr: i don't have an arale or bq here, but i don't see what could possibly different between meizu.en and ubuntu images, that would cause the new pay-ui click to break (which is oddly not even pay-ui breaking at that point, but online-accounts), but not with the pay-ui that's currently in the store.
<rvr> dobey: I'm reflashing  the arale to check pre-post/pay-ui click update
<dobey> ok
<pstolowski> trainguards,  may i ask for purging of silo 4?
<rvr> dobey: It fails again
<rvr> dobey: Without the package, it works, the accounts dialog UI shows
<rvr> dobey: With the package, it opens and closes
<rvr> dobey: I install the package with pkcon --allow-untrusted
<sil2100> Back
<sil2100> pstolowski: on it
<sil2100> pstolowski: you want to abandon it completely?
<dobey> rvr: pkcon install-local --allow-untrusted right?
<rvr> dobey: Right
<pstolowski> sil2100, no, just start clean
<dobey> rvr: weird. that makes absolutely no logical sense :-/
<rvr> dobey: untrusted-helper-pay-ui .... log
<rvr> dobey: It is because the component is not trusted?
<dobey> rvr: those dbus complaints are mostly meaningless and are coming from online-accounts
<dobey> rvr: no, --allow-untrusted only has to do with signature verification on the package itself
<rvr> mardy: Can you refresh me how to set the debug mode in the online-account service?
<mardy> rvr: OAU_LOGGING_LEVEL=2 OAU_DAEMON_TIMEOUT=9999 online-accounts-service
<rvr> mardy: Thanks
<rvr> Given applicationId doesn't match profile
<rvr> request.cpp 272 fail "com.ubuntu.OnlineAccountsUi.InvalidApplication" "Invalid client application"
<dobey> rvr: is there a crash file in /var/crash for any online-accounts stuff?
<dobey> huh
<rvr> mardy: What does "invalid client application" mean?
<pstolowski> sil2100, just clean the ppa please
<sil2100> pstolowski: ACK
<sil2100> pstolowski: done
<sil2100> pstolowski: remember to change the silo to xenial+vivid
<pstolowski> sil2100, right, thanks!
<sil2100> yw!
<rvr> dobey: http://paste.ubuntu.com/12979708/
<dobey> rvr: right, i don't know what that means, or why online-accounts would be doing that, but it's an issue with online-accounts, not pay-ui. i'm surprised the pay-ui that's on the image works, but the sideload click doesn't, but beyond that, i don't know what to say
<balloons> josepht, hey, I didn't hear back yesterday on which way to go with the upgrade. Shall I ask for it or ? I still need to run the backup script, which I can do when we are ready
<josepht> balloons: I'd go ahead and run your backup script.  I'll have an answer for who should request the upgrade shortly.
<josepht> balloons: you can request the upgrade
<josepht> balloons: when/if you're ready you are also empowered to request a redeploy if you'd like to test that path.
<pete-woods> trainguards: hi folks! could someone kick the ppc64el build that failed in here? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-055/+packages
<balloons> josepht, ok will do. And yes, I'll test the redeploy after. Backups first!
<pete-woods> it looks like the builder went a bit mad
<sil2100> pete-woods: on it
<pete-woods> sil2100: thanks
<sil2100> pete-woods: rebuilding, yw!
<rvr> dobey: http://paste.ubuntu.com/12979832/
<rvr> dobey: There is an extra parameter passed in the current pay-ui, windowId. Don't know whether it makes any difference.
<dobey> rvr: i have no idea what any of that means. pay-ui is "unconfined"
<rvr> dobey: Could you work with mardy on this? Otherwise, it's not going to land.
<dobey> mardy: ^^ what is going on with rvr's device here?
 * mardy looks
<dobey> rvr: i can't recreate the issue on my mako, so i'm not sure what i can do other than to bug mardy about it and look at your debug info
<Saviq> robru, hey, something went wrong here https://ci-train.ubuntu.com/job/ubuntu-landing-021-1-build/213/consoleFull - I think the train decided it doesn't need to build u-s-c since it built it once... but it never uploaded it to the silo
<Saviq> robru, I think it might be because unity8 was failing to prepare a package, and u-s-c prepared it fine, so decided there's no need to rebuild, even if it didn't upload it due to the unity8 fail
<mardy> dobey: can I see the code where you are requesting the account creation? At a first sight, it looks like the given applicationId is incomplete: it should be "com.canonical.payui_payui"
<cjwatson> pete-woods,sil2100: I recommend leaving those alone for the moment - I'm working with IS to work out what's wrong with the cloud in question, and I'll be retrying in bulk once that's done
<sil2100> cjwatson: ok, thanks for the heads up!
<dobey> mardy: looking for it. i'm not 100% sure on the path through online-accounts there, but it's not something that's changed in an incredibly long time
<dobey> oh right
<dobey> mardy: https://bazaar.launchpad.net/~unity-api-team/pay-ui/first-branch/view/head:/app/payui.qml#L71
<dobey> but that hasn't changed in over a year
<mardy> dobey: so, what is the silo you are trying to land?
<dobey> mardy: https://jenkins.qa.ubuntu.com/job/generic-click-builder-14.09-armhf/39/artifact/output/com.canonical.payui_15.01.133_armhf.click
<mardy> dobey: do you have a diff from the previous version?
<dobey> mardy: https://code.launchpad.net/~dobey/pay-ui/iap-support/+merge/271815
<mardy> dobey: mmm... cannot see anything wrong in it...
<mardy> rvr: could it be that you have also some other silo installed?
<rvr> mardy: I didn't install any silo, just the click package
<dobey> mardy: indeed, the Setup{} hasn't changed, and i don't have this issue on my mako
<mardy> rvr: can you try reinstalling the old version of the click package?
<rvr> mardy: I did reflash the phone
<rvr> mardy: Problem gone. With the click package, fails.
<mardy> rvr: I wonder if it could be a problem with the online accounts hook; can you install the old click version, after having installed the new one?
<rvr> dobey: Where can I download the current click package?
<dobey> rvr: the store
<mardy> dobey: meanwhile, please try appending a "_payui" to that applicationId string; it should fix the issue
<dobey> popey: ^^ you had a separate repo of all the free clicks that are in the store, right?
<popey> i do.
<dobey> popey: where was it?
<popey> http://popey.mooo.com/mirror/clicks/
<dobey> rvr: http://popey.mooo.com/mirror/clicks/2015/04/2015-04-30-050001/com.canonical.payui_15.01.120_armhf.click
<rvr> Nice
<rvr> Thanks
 * popey adds one to the 'number of times that mirror has come in handy' counter
<rvr> mardy: dobey: It just works
<dobey> wtf :(
<mardy> rvr: and can you please get me the usual logs (as per command above) with the old click?
<rvr> mardy: This is with the new click http://paste.ubuntu.com/12979708/
<rvr> mardy: With the old http://paste.ubuntu.com/12979817/
<mardy> rvr: can you please do "ls ~/.local/share/accounts/applications/com.canonical.payui*" and "cat ~/.local/share/accounts/applications/com.canonical.payui*" ?
<rvr> phablet@ubuntu-phablet:~$ ls ~/.local/share/accounts/applications/com.canonical.payui*
<rvr> /home/phablet/.local/share/accounts/applications/com.canonical.payui_payui.application
<rvr> mardy: http://paste.ubuntu.com/12980127/
<mardy> rvr: ok, I think I got it
<dobey> mardy: you understand why it's breaking now?
<mardy> rvr: my feeling is that hooks are not properly executed when updating a preinstalled app
<mardy> rvr: so, even after you install the new click, the /home/phablet/.local/share/accounts/applications/com.canonical.payui_payui.application file contains the apparmor profile for the old app
<mardy> rvr: I should make the OA check ignore the version number
<barry> sil2100: you asked me a question last night during my dinner.  still need an answer?
<dobey> mardy: i think that .application file is with the old click installed though
<rvr> mardy: I installed the new click package
<dobey> rvr: can you pastebin the contents of that file after installing the new click again?
<rvr> mardy: cat ~/.local/share/accounts/applications/com.canonical.payui* gives the same results as the original click
<dobey> huh
<mardy> rvr, dobey: yep, so either the hook is not executed, or it fails somehow
<rvr> mardy: http://paste.ubuntu.com/12980179/
<sil2100> barry: I suppose, it wasn't anything super urgent but I was just wondering about the description feature ;)
<dobey> how
<sil2100> barry: since I know we're not really using that in the touch images at all
<mardy> rvr: can you manually run online-accounts-hooks and see if the file changes afterwards?
<mardy> rvr, dobey: sorry, have to run out now, will be back tomorrow morning
<dobey> rvr: you are not running pkcon install-local with sudo are you?
<rvr> mardy: online-accounts-hooks doesn't do anything
<rvr> dobey: Nope
<barry> sil2100: right.  so that was basically an early requirement that never really panned out.  we even had support for i18n descriptions but that never happened either
<dobey> rvr: can you try rebooting after installing the new click and then see if the .application file contents still point at the pre-installed app?
<rvr> dobey: I did that and nothing changed, but doing it again
<dobey> hmm
<dobey> rvr: what does "ls -lh .local/share/accounts/applications/com.canonical.payui_payui.application" say?
<bzoltan_> does anybody know who is the best (from maybe cihelp) around here I could ask about Breaks/Conflicts/Replaces?
<rvr> dobey: -rw-rw-r-- 1 phablet phablet 662 oct 27 14:22 .local/share/accounts/applications/com.canonical.payui_payui.application
<dobey> huh, ok
<dobey> bzoltan_: #ubuntu-packaging probably the best place to ask
<bzoltan_> dobey: what a descriptive channel name :D thanks
<fginther> dobey, thanks for answering, I was going to suggest a core-dev, but that sounds better
<fginther> Saviq, is there a recommended image channel for testing xenial builds of unity8 on the phone?
<dobey> are there xenial images being built yet?
<Saviq> fginther, there isn't a xenial channel yet afaict... sil2100?
<Saviq> fginther, but it would be ubuntu-touch/devel-proposed/ubuntu
<dobey> rvr: and the file is still broken after a reboot?
<sil2100> None yet, maybe it's time to finally start building those images
<rvr> dobey: Yes
<fginther> Saviq, that was my expectation. If it's not ready yet for the unity8 testing, we can hold off on adding that bit until it's ready
<dobey> rvr: what does "click list | grep payui" say?
<rvr> dobey: com.canonical.payui	15.01.133
<dobey> rvr: what version of the "click" debian package is installed?
<rvr> dobey: 0.4.40+15.04.20151006-0ubuntu1.1
<dobey> well bugger :(
<dobey> rvr: so, this looks like the bug that should have been fixed by that version of click, resurfacing somehow
<dobey> kyrofa_: ^^ any ideas?
 * kyrofa reads scrollback and wonders why his nick had an underscore
<dobey> netsplits are fun!
<dobey> anyway, i am starving and need to get lunch. bbiab
<kgunn> sil2100: hey just noticed something odd, so robert-ancell placed a new xorg package in stable-phone-overlay ppa...and on my device i did update/dist-upgrade
<kgunn> but it's still on the "old" xorg (this is for xmir)
<sil2100> kgunn: maybe he published the wily/xential version to the PPA? Or did he push the vivid package?
<sil2100> Let me check
<kgunn> sil2100: maybe it's priority pinning ?
<kgunn> https://pastebin.canonical.com/142782/
<kgunn> it's there ^ just not the installed version
<sil2100> hmmm
<kgunn> and this is obviously ubunt-pd
<sil2100> The pin priority is obviously wrong there, it's 50 instead of higher
<sil2100> kgunn: check the apt/preferences.d if everything is ok there
<rvr> dobey: However, running online-accounts-hook doesn't do anything, does it need any parameter?
<kyrofa> dobey, interesting... I'm not sure I understand what's happening here though. I don't see a click hook that generates the .local/share/accounts/applications though. Where do they come from?
<kyrofa> rvr, ^^
<rvr> kyrofa: There is a .application file in the click package, but I have no idea beyond that fact
<rvr>     "hooks": {
<rvr>         "payui": {
<rvr>             "account-application": "com.canonical.payui_payui.application",
<rvr> kyrofa: I guess is that one
<kyrofa> rvr you're right-- that one creates the online-accounts-hooks and then runs the online-accounts-hooks binary... which must generate those .application files somehow?
 * sil2100 jumps out for practice
<rvr> kyrofa: Probably
<kyrofa> I'm not familiar with online-accounts-hooks. However, dobey if you're referring to bug #1479001, I'm not sure these two things are related. The fix for that bug doesn't even happen until reboot. This sounds like an upgrade gone bad or something
<ubot5> bug 1479001 in Canonical System Image "Older version of a user installed click is not updated by custom or base pre-installed clicks with a more recent version" [Critical,Fix released] https://launchpad.net/bugs/1479001
<sil2100> The mediascanner2 silo needs a binNEW review, we'll poke someone about that in a bit
<kyrofa> rvr can you verify that the .application file in the click package was actually updated between the two versions?
<rvr> kyrofa: Well, the issue we have is that the content of the .application file is not updated with the correct click package version
<rvr> kyrofa: so online-accounts-service fails matching the application request
<kgunn> sil2100: sorry, got otp for a bit...
<kgunn> so yeah, my pref file clearly shows Pin-Priority: 50
<kgunn> which would seem wrong
<kgunn> hmm...i did run citrain tool
<kgunn> i've another device....it shows
<kgunn> Pin: release o=LP-PPA-ci-train-ppa-service-stable-phone-overlay
<kgunn> Pin-Priority: 1001
<kgunn> lemme add a ppa with citrain and see what happens
<kgunn> yeah citrain appears to be altering the pin priority incorrectly
<pstolowski> sil2100, hey, my silo is set for xenial, but build log has this: http://pastebin.ubuntu.com/12980779/ ; anything to be worried about?
<pstolowski> sil2100, uh oh i've plethora of issues with silo 4 today - all projects in the silo seem to fail on xenial - ppc64el; on vivid it fails on missing dependencies such as  libandroid-properties-dev - see https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004/+build/8197298
<pstolowski> sil2100, any idea?
<dobey> kyrofa: yeah, so, i'm referring to the hooks not being run right when a package is upgraded.
<dobey> anyway, i don't know what to do about that
<dobey> rvr: can you rm the .application file in .local/share/, then reboot, and see if the issue still happens?
<kyrofa> dobey, yeah I assume user hooks are run upon install. My only guess is that the online-accounts-hooks binary is failing somehow
<dobey> well i presume rvr is gone for the day now
<dobey> whom can i get to test pay-ui and the other silo now? alesage i guess?
<rvr> dobey: Ok, removing the file and restarting does the trick
<rvr>   <profile>com.canonical.payui_payui_15.01.133</profile>
<rvr>   <package-dir>/opt/click.ubuntu.com/.click/users/@all/com.canonical.payui</package-dir>
<rvr>   <desktop-entry>com.canonical.payui_payui_15.01.133</desktop-entry>
<dobey> ok
<rvr> com.canonical.payui	15.01.133
<rvr> dobey: And online accounts dialog appears
<dobey> ok
<dobey> let's file a bug against click/online-accounts about the hook issue and not have it block pay-ui please?
<rvr> dobey: No way
<rvr> dobey: We will be releasing this to real users. Without fixing this problem, we won't release the new pay-ui.
<pstolowski> sil2100, following doko's email about xenial, i've opened a bug for constant failures on ppc64el: https://bugs.launchpad.net/launchpad-buildd/+bug/1510637
<ubot5> Launchpad bug 1510637 in launchpad-buildd "Build fails all the time on xenial ppc64el with no log" [Undecided,New]
<dobey> so pay-ui has to fall on the sword, because you happened to hit a bug in click/online-accounts on your one device?
<rvr> dobey: We don't know whether the fix will be in time or not
<jgdx> bfiller, silo 47 is now top approved.
<pstolowski> sil2100, not sure about other architectures though, where it fails on dependencies such as libandroid-properties-dev, libhardware-dev, qtdeclarative5-ubuntu-web
<rvr> dobey: If not, this will break real phones
<rvr> because .application won't be recreated
<dobey> rvr: that's funny. it's not broken on my phone
<rvr> dobey: Have you flashed the phone with --wipe?
<dobey> so until this is fixed, all click packages will be blocked by QA then, right?
<rvr> dobey: If their test plans don't pass, yes
<dobey> ...
<cjwatson> sil2100: ppc64el> all fixed now, everything retried
<cjwatson> sil2100: you may want to do watch-only builds or whatever
<cjwatson> pstolowski: that's fixed now
<cjwatson> pstolowski: the ppc64el bit anyway
<cjwatson> pstolowski: and those dep-waits should be harmless assuming the packages failed before
<pstolowski> cjwatson, cool, thanks for update
<pstolowski> cjwatson, i'm not sure what do you mean with the dep-waits.. are you referring to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004/+build/8197301 ? do you mean it should work now when i retry?
<cjwatson> pstolowski: I mean the ones in vivid
<cjwatson> libandroid-whateveritwas
<cjwatson> pstolowski: oh, well that too - you don't need to retry that, it's not a relevant failure because unity8 never built on powerpc
<rvr> dobey: I have created a bug https://bugs.launchpad.net/canonical-devices-system-image/+bug/1510640
<ubot5> Launchpad bug 1510640 in pay-ui "PayUI unable to log in Ubuntu One" [Undecided,New]
<dobey> why is that a bug in pay-ui?
<cjwatson> pstolowski: I believe the only thing that needs to finish now is https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004/+build/8197296, which would retry by itself eventually but I'll hurry it along as soon as it's possible to do so
<pstolowski> cjwatson, ack, thanks
<dobey> moved it to click
<rvr> dobey: I was adding all the projects involved :P
<robru> kgunn: sil2100: yes citrain tool alters the pins so that it can install a silo without pulling in extra updates from overlay ppa. That is the correct behavior. If you want to dist-upgrade after installing a silo you need to clear the pin file.
<kgunn> robru: yeah that makes sense now
<robru> Saviq: yeah I tweaked that behavior a bit but it's obviously not quite right yet
<rvr> kyrofa: Do you think pay-ui's problem lies in online-accounts or in the click tool, not executing the hook?
<kyrofa> rvr I feel like there would be other symptoms if click wasn't running hooks. I'm leaning toward online-accounts
<kyrofa> Because it supplies the hook that being run
<dobey> can anyone else replicate the issue?
<mardy> dobey, rvr: so, the online-accounts-hook checks the date of the .application file specified in the hook and the date of the generated file. Maybe something goes wrong with that check?
<mardy> dobey: http://bazaar.launchpad.net/~online-accounts/ubuntu-system-settings-online-accounts/trunk/view/head:/click-hooks/main.cpp#L342
<rvr> mardy: If my deb visor is not mad, the date of the .application file inside the click package is Oct 1st
<mardy> rvr: can you please do a "ls -l ~/.local/share/online-accounts-hooks/"?
<dobey> but what is the date of the file in the image? it should be from april
<mardy> rvr: actually: ls -l ~/.local/share/online-accounts-hooks/*.application
<rvr> mardy: We recreated the file removing the old
<dobey> but apparently it was today
<dobey> 11:16 < rvr> dobey: -rw-rw-r-- 1 phablet phablet 662 oct 27 14:22 .local/share/accounts/applications/com.canonical.payui_payui.application
<dobey> i don't know if that date is the same as what's on a clean image though
<cjwatson> pstolowski|afk: ok, so perhaps you have some genuine failures now, or maybe somebody needs to take a look at that silo since the failures don't seem to correspond to something actually published in the PPA
<dobey> ubuntu=20151027 <- where does the tarball for this come from?
<dobey> ah in /pool
<dobey> which is incredibly huge list
<dobey> mardy: it checks the date of the source files, or of the currently generated file?
<mardy> dobey: both, it compares them
<dobey> mardy: well that's not nice
<dobey> i wonder how many click hooks are doing that
<mardy> dobey: isn't that reliable?
<dobey> mardy: no, because on a freshly flashed device, the timestamp of the generated file is set when it first boots up after flashing, and not to the timestamp of the source file it was generated from. so the generated file gets oct 27 2015 as the date, but the source file was mar 31 2015
<dobey> and then if it compares the generated file's date to the source file of the new package, the file that's actually older, will appear newer
<dobey> mardy: so i guess that if() block just needs removed
<cjwatson> hooks should be setting the timestamp of generated files to be equal to that of the source file, as a general rule
<mardy> dobey: wait a second... actually the source file is a symlink, created by click
<dobey> huh?
<dobey> no, the source file is the .application file in the click package
<dobey> if you're getting to that data via symlink, then you should be resolving the link so that you read the target file's info, and not the symlink's
<mardy> dobey: no, actually I do really want to get the symlink's date
<mardy> dobey: because that tells me when the click was installed
<dobey> well either way, the generated file's date is not the same as the source file's date (whether that be the actual source, or the symlink)
<cjwatson> if the generated timestamp is only >= the source timestamp rather than ==, then it's much much harder to reliably update it when the original changes - because the original might become newer, but not as new as the generated file
<dobey> but how has this literally not been a problem for us for the last 15 months, and is only appearing now?
<dobey> this can't possibly be a new bug
<cjwatson> sort of thing that happens in corner cases that it's hard to get anybody to care about until they happen
<cjwatson> I've definitely seen similar kinds of things in other hooks before
<cjwatson> or it gets papered over somehow
<dobey> yeah, i mean, we've released multiple fixes to pay-ui since july last year, so i'm just very surprised that this would be the first time this has happened. or for any other click packages that use any online accounts
<mardy> cjwatson: ok, so you recommend setting the time of the generated files to be the same as the source files, and re-generated them everytime we see that they are different?
<dobey> mardy: so i guess i should assign bug #1510640 to you?
<ubot5> bug 1510640 in ubuntu-system-settings-online-accounts (Ubuntu) "PayUI unable to log in Ubuntu One" [Critical,New] https://launchpad.net/bugs/1510640
<mardy> dobey: I think so, thanks
<mardy> dobey, rvr: but this shouldn't block the new payui from landing
<cjwatson> mardy: that's generally what I've found to be more robust.  disclaimer: haven't looked into this bug in detail
<mardy> cjwatson: makes a lot of sense anyway, I'll try that, thanks
<dobey> mardy: thanks for coming back to look at this
<mardy> dobey: yw :-)
<dobey> is rvr still around? or should we prod alesage or ToyKeeper to prod this landing back to life?
<pstolowski> cjwatson, how long does it take for packages to show up in the ppa? i've rebuild another package in silo 4, it's available for xenial for 17 minutes, but not for vivid
<cjwatson> pstolowski: details so that I can grep, please?
<pstolowski> cjwatson, unity-scopes-shell here https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004/+packages
<cjwatson> 2015-10-27 18:24:16 INFO    Upload was rejected:
<cjwatson> 2015-10-27 18:24:16 INFO        File unity-scopes-shell_0.5.5+15.04.20151027.1.orig.tar.gz already exists in Landing PPA 004, but uploaded version has different contents. See more information about this error in https://help.launchpad.net
<cjwatson> /Packaging/UploadErrors.
<cjwatson> 2015-10-27 18:24:16 INFO        File unity-scopes-shell_0.5.5+15.04.20151027.1-0ubuntu1.diff.gz already exists in Landing PPA 004, but uploaded version has different contents. See more information about this error in https://help.launchpa
<cjwatson> d.net/Packaging/UploadErrors.
<cjwatson> 2015-10-27 18:24:16 INFO        Files specified in DSC are broken or missing, skipping package unpack verification.
<cjwatson> pstolowski: ^- version clash, fix that
<cjwatson> perhaps it is confused because the package was previously there but was then removed
<cjwatson> I expect you need to get it to bump to 20151027.2 somehow (for which you'll need a trainguard, I can't help further on that)
<pstolowski> cjwatson, ok, i'll just bump the micro version in the changelog, should have done that anyway. thanks!
<pstolowski> eod
<robru> wait what? train should be generating that number...
<robru> somebody apparently manually deleted the vivid version from the ppa so the version numbering code is getting confused.
<Saviq> robru, hey, did you see my msgs before about "build" not working as expected after a failed prepare?
<Saviq> robru, train skips unchanged packages regardless if they've been uploaded to silo or not
<robru> Saviq: oh yeah I fixed that already (or at least it's fixed for future cases, for silos that are already affected by this issue you'll need to put the package name in PACKAGES_TO_REBUILD to push this along)
<Saviq> robru, ack
<robru> Saviq: at this point it doesn't write the commit id  until after the upload to the PPA, so if there's any errors merging or uploading it won't consider any of the merges to have been built
<Saviq> yup, tx
<robru> you're welcome
#ubuntu-ci-eng 2015-10-28
<ogra_> sil2100, where do i commitr system image config changes, i see the etc/ dir is a bzr branch, is it only there or is there a matching external one
<sil2100> ogra_: commit your changes and just do a bzr push
<ogra_> sil2100, so no external LP branch then, ok
<morphis> sil2100: can you drop the wily packages from silo 52 for me?
<ogra_> sil2100, eeek, there are uncommited changes
<sil2100> ogra_: yeah, temporary stuff usually is left uncommited
<morphis> sil2100: or is that anymore true that we should lands things also for wily?
<sil2100> But I suppose you can just commit that
<sil2100> morphis: on it, removing
<ogra_> sil2100, well, how do i commit my stuff then ?
<morphis> sil2100: thanks!
<ogra_> ah ok
<sil2100> xenial should be the focus now
<sil2100> ogra_: those 'temporary changes' are usually changes that have no relevence if they're reverted or not ;)
<sil2100> At least that's the overall idea
<ogra_> sil2100, well the prob is that you have no history if every now and then youor log has "committed uncommited changes that someone did"
<ogra_> i.e. you dont now what they were for
<sil2100> morphis: deleted
<sil2100> ogra_: yeah, I guess we'll have to make sure to keep the config clean next time
<sil2100> hm, I think I might have had some uncommited changes there
<ogra_> or just commit the temporaray stuff too ...then you have proper explanation ...
<sil2100> But those, as I said, were irrelevant things - will commit them next time
<sil2100> Sorry about that ;)
<ogra_> no prob
<Saviq> sil2100, is there a xenial channel yet?
<jibel> Saviq, it'll be devel-proposed once there is a build for it which sil2100 said he would work on today
<Saviq> jibel, ack, thanks
<sil2100> Yeah, actually my expectation was it would switch automatically, but seems it needs a bit manual love
<sil2100> On my plate today
<rvr> jgdx: ping
<pstolowski> trainguards, hey, what's happening to silo 24? it's been in a weird state for 2-3 days
<sil2100> Let me take a look
<sil2100> hm, looks like it got rejected
<jgdx> rvr, ponmg
<rvr> jgdx: Hey
<rvr> jgdx: Silo 47. How do I check the OTA version in ubuntu-system-settings?
<rvr> jgdx: I see no info in the About page
<jgdx> rvr, i think you have to have ota8, but I'm not sure. sil2100 ^ do you know?
<rvr> jgdx: Phone was flashed in rc-proposed channel
<jgdx> rvr, if not, let me know if you want me to create a mock for this.
<jgdx> command line that will give you an ota
<rvr> jgdx: How did you test the feature?
<jgdx> rvr, using a mock
<jgdx> sil2100, if you flash ota7 now, will you get a tag=ota7 in version_details? You know?
<rvr> version_detail: ubuntu=20151028,device=20150911,custom=20151028,version=274
<sil2100> jgdx: no, we won't be supporting tags from the past
<sil2100> jgdx: since this requires an image to be re-created (with the new tag)
<jgdx> sil2100, yup. Thanks!
<jgdx> rvr, so impossible to test w/o trickery
<sil2100> If you need it for testing, I can prepare a private system-image server
<sil2100> I mean, hm, I would need to find a public place first
<jgdx> sil2100, I was going to suggest a mocked s-i, but whatever's fine with me.
<sil2100> jgdx, rvr: let me quickly take a look if I can export my s-i somewhere, you guys could then flash from there for testing
<rvr> I tried to add the tag to the file, but no luck
<jgdx> sil2100, thanks
<pstolowski> sil2100, rejected? why?
<pstolowski> sil2100, also.. are the builders overloaded atm or something? i'm rebuild the mediascanner scope in silo 4 and it has been over 2,5 hrs already
<cjwatson> pstolowski: arm64 still has a day or so left of a test rebuild
<cjwatson> pstolowski: I've scored up your builds, though they were pretty close already
<pstolowski> cjwatson, ah i see
<pstolowski> sil2100, anything i can do about silo 24? it would be great to land it as i have another one in the pipeline :)
<sil2100> pstolowski: let me take care of it now, had a busy afternoon today ;/
<sil2100> pstolowski: ah, I think I see why it failed!
<sil2100> Let me publish it by hand
<pstolowski> uhm
<pmcgowan> mterry, Saviq silo21 still dirty :(
<mterry> pmcgowan, looks like it got some builds in last night though -- you can try it and it should have the shutdown dialog fix
<pmcgowan> mterry, I was thinking, are we doing too little in powerd and too much in unity? seems it should be simple to have two distinct events
<mterry> pmcgowan, yeah it might make more sense to have USC/powerd emit a "long power press" signal that u8 consumes
<mterry> I think there are still intentions to review that whole power signaling mess
<pmcgowan> mterry, exactly, insteaad now there are multiple button pressed and released signals
<pmcgowan> should just be short and long
<pmcgowan> then filter multiple presses that are too frequent
<dobey> rvr: ping
<rvr> dobey: pong
<dobey> rvr: so, the issue with the online-accounts is very improbable to be hit by pay-ui in real production devices, as once it lands in the store, and new images get built, the new version will already be installed, and anyway installing it as an update through system-settings will likely not have done an immediate --wipe flash of their device after the new click was built, as the click which will land in the store will be built b
<dobey> rvr: so i'm wondering if we could please move forward with the landings
<rvr> dobey: As I commented on the trello card, the plan is to land silo 1 first, then pay-ui, and then 26.
<rvr> mardy is already working on it, so seems it won't take too long
<Saviq> pmcgowan, it's dirty because there were new commits, but it's sane
<pmcgowan> Saviq, ack
<mardy> cjwatson: is it possible to score up https://ci-train.ubuntu.com/job/ubuntu-landing-056-1-build/33/console and https://ci-train.ubuntu.com/job/ubuntu-landing-001-1-build/231/console too?
<cjwatson> mardy: the first is already building; done the second
<alan_g> cihelp: we're seeing consistent problems on krillin in CI (https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-touch/) that we're having trouble reproducing locally. What image is installed on these runners?
<fginther> alan_g, one moment
<oSoMoN> trainguards: is https://requests.ci-train.ubuntu.com/#/ticket/576 correctly configured so that vivid packages will land in the overlay PPA and xenial packages in the archive?
<fginther> alan_g, ubuntu-touch/rc-proposed/ubuntu
<fginther> alan_g, which currently appears to be image 312
<alan_g> fginther: thanks.
<rvr> xavigarcia: ping
<mardy> cjwatson: thanks a lot!
<sil2100> oSoMoN: looking
<sil2100> oSoMoN: looks ok, although I'm not sure if the Destination PPA shouldn't be empty
<sil2100> oSoMoN: since dual silos anyway by default land the vivid part to the overlay
<sil2100> But I need to check the code as robru made a lot of modifications in the past few weeks ;)
<oSoMoN> yeah, thatâs what Iâm unsure about too
<xavigarcia> rvr pong
<rvr> xavigarcia: Hi
<rvr> xavigarcia: I'm taking a look at silo 46, I think it contains new strings, right?
<rvr> xavigarcia: I plugged my headphones and a notification appeared with "Headphones" as title
<xavigarcia> rvr: yeah, it has new string to show the output device
<rvr> xavigarcia: Ok. I think we are blocking it, we are in string freeze.
<xavigarcia> rvr: ok :(
<rvr> sil2100: Any news about the s-i for OTA tag?
<sil2100> rvr: I'm testing my local s-i on my krillin right now to see if it flashes/works correctly from the local server
<rvr> sil2100: Ack
<sil2100> rvr: once that's done I'll export it for you to test for a moment
<rvr> sil2100: Cool, thanks
<barry> robru: ping
<sil2100> rvr: how can I get my krillin into recovery?
<rvr> sil2100: Power + Volume Up for 20 seconds or so
<rvr> When you see a red light, release Power
<rvr> With Up select Recovery and with Volume Down enter that option
<sil2100> rvr: thanks!
<sil2100> I suspect the GPG keys might be causing problems
<sil2100> Ah, I think I see what's broken
<dbarth__> uh, sorry if that a faq, but how do i transition an old silo to xenial?
<dbarth__> https://requests.ci-train.ubuntu.com/#/ticket/446
<dbarth__> hi trainguards ^^
<sil2100> dbarth__: hey!
<dbarth__> sil2100: hi
<sil2100> dbarth__: so first of all, you need to switch the silo type to xenial+vivid
<sil2100> dbarth__: so edit the 'Target Series' field and save
<sil2100> Next, rebuild your silo
<sil2100> I'll remove the wily binaries from the PPA
<sil2100> rvr: still investigating, my phone doesn't want to properly update to any image from my local s-i instance
<rvr> sil2100: Ack
<sil2100> (unrelated to the tag= syntax, simply issues with the local server or my flashing mechanisms)
<sil2100> dbarth__: should I remove the wily binaries now? :)
<dbarth__> sil2100: ok done
<sil2100> dbarth__: packages removed
<dbarth__> sil2100: thank you
<jgdx> sil2100, any progress on the private s-i-s for rvr ?
<jgdx> anything I can do before I eod?
<pete-woods> trainguards: hi folks, we have a new project we want to get into xenial, and indeed vivid overlay (https://launchpad.net/gmenuharness), I can't remember the process to do it, though :$ (been a while)
<pete-woods> name of the right person to ping is all I'm after, really :)
<rvr> mardy: dobey: Great, pay-ui can be installed with silo 1 :))
<rvr> and it shows the Ubuntu One login screen in the Store
<dobey> rvr: good
<Saviq> robru, any reason for the silo branches having $source-name duplicated? like ~ci-train-bot/unity8/unity8-...?
<rvr> mardy: jgdx: There is a problem in the online accounts page in System Settings
<rvr> mardy: jgdx: When editing an account (Google, Facebook), there is no bar with button to go back
<rvr> jgdx: Maybe related to components 1.3 migration
<jgdx> rvr, hm, right.. mardy, was online accounts migrated to 1.3?
<rvr> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1511055
<ubot5> Launchpad bug 1511055 in Online Accounts setup for Ubuntu Touch "Cannot go back to Accounts" [Undecided,New]
<sil2100> rvr: ok, I flashed my device from my local s-i instance and confirmed that the tag= field is there
<sil2100> rvr: how long will you work today still?
<rvr> sil2100: I will finish current silo
<rvr> sil2100: Can we check it tomorrow morning?
<sil2100> rvr: sure, all is ready, I'll just open it up for you tomorrow then
<rvr> Thanks
<sil2100> rvr: but please note you'll need to flash with a script for disabling GPG verification and the adb unlocking recovery...
<rvr> sil2100: Ok
<rvr> --run-script=/home/vrruiz/bin/disable-gpg.sh
<sil2100> hah ;)
<rvr> I'm already disabling gpg
<sil2100> Prepared already I see!
<robru> barry: pong
<robru> Saviq: yes, because the first one is the project name and the second one is the source package name, they're not always the same (mostly it's so gles twins don't clobber the main trunks but there's other cases too)
<robru> sil2100: it's always been the case that vivid goes to overlay and dest ppa controls only where primary series goes (wily or xenial).
<Saviq> robru, ack
<robru> dbarth__: rebuild wasn't necessary, especially since you already had qa approval, sorry sil2100 gave bad info.
<robru> My email announcing xenial switch explained the correct steps
<robru> Too late to go back now though!
<dbarth__> robru: uh, my bad; it had the info, i just forgot
<dbarth__> note for others: read robru's email !
<robru> Yes!
<sil2100> Sometimes I copy existing wily binaries to xential, yes
<sil2100> But I usually noticed that people anyway want to rebuild since there are toolchain changes etc.
<sil2100> So sorry if you had to rebuild without any reason
<robru> sil2100: oh did the toolchain stuff land already? I didn't think it had yet.
<robru> barry: with regards to deadlocking, how likely is it for python to exit without closing it's fd's? In my (limited) testing i wasn't able to see a deadlock, it always freed the lock on process exit
<barry> robru: well, i'd have to go to my stevens to remind myself of generic process semantics, but python itself won't do anything special.  you can always set an atexit handler to explicitly close fds (or do whatever), but of course those handlers running are subject to the usual caveats, e.g. os._exit() or kill -9 won't run them
<robru> barry: Hmmmmmmm OK I'll need to test further in order to decide if it's worth switching.
<robru> barry: never heard of os._exit but sys.exit gets called in some cases. Most common signal will be 15 of user cancelled job in Jenkins
<barry> robru: sys.exit is fine; it raises an exception and if uncaught, it does a normal shutdown procedure.  same with catchable signals
<barry> robru: https://docs.python.org/3/library/os.html#os._exit
<robru> barry: OK great, the signal handler i have for signal 15 calls sys.exit
<sil2100> Xenial is now open for development, so the most important stuff is in
<rvr> mardy: Silo 1 approved
<dobey> hmm
<robru> barry: what's 'stevens'?
<barry> robru: http://tinyurl.com/ndcpys3  - it's the definitive book on unix semantics
<robru> barry: oooh
<barry> every *nix developer should own a copy (i really need to get the 3rd edition)
<barry> w. richard stevens died a long while ago, but i believe it's been updated by other pepole and is still relevant
<robru> barry: yikes, $30 even on kindle
<barry> he also has books on network programming which are really excellent too
<robru> barry: must be printed with golden electrons
<barry> yeah, but worth every penny :)
<robru> barry: maybe I'll pick it up then ;-)
<barry> looks liked 3rd ed even covers "ubuntu 12.04 (based on linux 3.2)"
<sil2100> robru: uh: https://ci-train.ubuntu.com/job/ubuntu-landing-001-2-publish/123/console <- you saw anything like this before?
<robru> sil2100: yeah, the silo is locked
<robru> sil2100: that should only happen if you try to run two jobs simultaneously.
<sil2100> The silo was ready for publish and built, maybe some lock that's left-over?
<robru> sil2100: not sure, the train has code to check that locks are stale but if you feel it's in error you can delete ~/silos/$SILONAME/lock
<sil2100> https://requests.ci-train.ubuntu.com/#/ticket/573 <- the silo looks fine here
<robru> sil2100: that is weird
<robru> sil2100: I'm working on a refactor of locking that should hopefully eliminate these issues
<sil2100> robru: ok, thanks :)
<robru> barry: I have a question about generators
<barry> robru: sure
<renatu> robru, do you know what is the problem with this silo? https://ci-train.ubuntu.com/job/ubuntu-landing-002-1-build/241/console
<robru> barry: let's say I'm iterating on a generator and it takes a long time (~5 minutes total).
<renatu> I am getting silo locked too, on silo 2
<robru> barry: if the generator instantiates an object for each iteration, what's the lifecycle of the object? is the object freed when the next iteration starts? no reference to the objects is kept as far as I know
<robru> renatu: looking
<barry> robru: the generator is a closure so if the object is referenced by a local variable in the generator, that reference will keep the object alive.  from there, it's normal python lifecycle semantics.  if you reassign or del the name binding and the object's refcount goes to zero, it gets freed.  if the object participates in a cycle, the cyclic garbage collector will eventually break the cycle, subject to those semantics (e.g. based on
<barry> the presence of __del__'s)
<robru> renatu: sil2100: oh apparently i goofed up and rolled out a half-finished merge to production, awesome.
<robru> will fix that asap
<robru> barry: so like this: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/view/head:/cupstream2distro/silomanager.py#L163 it just yeilds the object without assigning it, those'll be freed after each iteration right? or does python hang onto them until the full generation is complete?
<robru> renatu: sil2100: ok trunk is fixed, should hit production in ~20 minutes
<barry> robru: here's a good boiled down example which should explain what's going on: http://paste.ubuntu.com/12992694/
<barry> but yes, they should get freed
<barry> robru: er, try this instead: http://paste.ubuntu.com/12992722/
<robru> barry: seems to work even without the del at the end
<barry> robru: right, the del is just for printing a message when the object is collected
<barry> robru: if the del created a cycle, then you'd have problems :)
<barry> *or resurrected the object
<barry> __del__'s can be evil :)
<robru> barry: but I mean I dropped the del and it still prints 'freed' in each iteration instead of all at the nd
<barry> robru: impossible :)
<barry> well, if you replace the def with a pass
<robru> barry: what?
<barry> robru: what does "dropped the del" mean?
<barry> oh, you mean `del obj`
<barry> robru: that makes sense
<robru> barry: http://paste.ubuntu.com/12992782/
<robru> yeah
<robru> barry: that's great though, that answers my question and it's the behavior I wanted ;-)
<barry> right?  "obj" gets rebound to a new Foo instance, and rc() returns so both refcounts are dropped, and the object's refcount goes to 0 so it gets del'd.  at the end of the for loop, obj gets unbound
<barry> s/end of the for loop/script exits/
<robru> barry: right
<robru> barry: this means that the generator loop should only lock each object for 5 seconds each instead of locking them all for the full 5 minutes, so that's perfect ;-)
<barry> cool :)
<robru> sil2100: renatu: ok try again?
<robru> Saviq: oh btw, not sure if you noticed yet, but "bug NNN" and "# NNN" are both linkified now. You don't need to use pad.lv anymore if you don't want to
<Saviq> robru, oh good, thanks
<robru> Saviq: you're welcome!
#ubuntu-ci-eng 2015-10-29
<robru> wat
<mardy> jgdx: hi! Not yet, but I've a branch for that
<dbarth__> hey trainguards, seems that i can't fully publish siloe 056
<dbarth__> https://ci-train.ubuntu.com/job/ubuntu-landing-056-2-publish/9/console
<dbarth__> can you help?
<pstolowski> sil2100, hey, any news on silo 24?
<sil2100> pstolowski: checked that the new package reached the destination, force merging now
<pstolowski> sil2100, great, thanks!
<sil2100> Oh, queuebot is gone
 * sil2100 needs to jump out for a min, brb
<mardy> dbarth__: mmm... silo 56 is dirty again :-/
<rvr> mardy: Hey. Did you see this? https://bugs.launchpad.net/bugs/1511055
<ubot5> Launchpad bug 1511055 in Online Accounts setup for Ubuntu Touch "Cannot go back to Accounts" [Undecided,New]
<mardy> rvr: no, I didn't... looks interesting :-)
<dbarth__> mardy: oh is it?
<dbarth__> i m still trying to get a trainguard to help me publish
<dbarth__> let me check why
<rvr> sil2100: Can you enable the s-i?
<bzoltan_> sil2100:  how to deal with the gles packages now that we are targeting 16.04?
<bzoltan_> sil2100:  the citrain is bitching that cp: cannot stat '/var/lib/jenkins/silos/ubuntu/landing-051/ubuntu-ui-toolkit_1.3.1705+16.04.20151029.1.orig.tar.gz': No such file or directory
<cjwatson> sil2100: so, you know the way we keep a big git repository of Packages/Sources history in order that you folks can fork a factory PPA from an old version of the archive if you need to?  how far back do we need to keep that?
<cjwatson> sil2100: I ask because even with git's amazing compression an 82GB repository is killing snakefruit and I'd like to truncate it
<cjwatson> (it's not really about space, to be clear, it's that git gc kills the box daily)
<sil2100> rvr: on it in a minute
<sil2100> bzoltan_: that's hm, odd, let me check your silo in a moment
<sil2100> cjwatson: hmmmm, I need to think about that, I think we might not need it anymore - you mean archive history, right? Since now that we basically use the overlay PPA and the overlay PPA has infinite history, we can get the exact package versions used from the image manifests + binary copies
<cjwatson> sil2100: Both have infinite history, but working out the state of build-dependencies isn't something that manifests give you
<cjwatson> sil2100: (We keep index history of the overlay PPA this way too)
<cjwatson> sil2100: My question is just what the oldest point you might wish to fork from is
<cjwatson> sil2100: right now we have back to somewhere around July/August 2014
<bzoltan_> sil2100:  I ripped off the gles package .. but now it does the 15.04 versioned package only
<sil2100> hm, I think that's indeed a bit too much into the past
<sil2100> cjwatson: I think if the history would be spanned to around the 15.04 release, I suppose that would be sufficient
<cjwatson> sil2100: righto, I'll see about filtering it, thanks
<cjwatson> I'd like to keep ALL THE THINGS but it's not feasible at the moment :-/
<sil2100> rvr: what device do you want to test on?
<sil2100> rvr: krillin?
<sil2100> bzoltan_: is there some new method of doing the -gles uploads, or is it the same as in the past?
<bzoltan_> sil2100:  I do not know about any change... the last time I have landed the 1688 UITK I simple updated the changelog and added the MR, so without watch file
<sil2100> bzoltan_: so changing the watch file is no longer required? Just want to get myself up-to-date with latest changes Robert made
<bzoltan_> sil2100: Yes, that is the new thing .. no watch file
<rvr> sil2100: Yes, krillin
<jgdx> mardy, what's the target? OTA8?
<mardy> jgdx: yes!
<jgdx> mardy, wheee
<jgdx> mardy, when testing that silo, could you make sure the header is shown in System Settings -> Online Accounts?
<jgdx> if not, just let me know and we'll figure it out
<mardy> jgdx: ok I will
<boiko> sil2100: could you please remove wily packages from silos 25 and 54?
<sil2100> boiko: on it!
<sil2100> rvr: did it download?
<boiko> sil2100: thanks!
<sil2100> boiko: will you be re-building the silos? Since if they're both ready for release I can simply copy the wily packages to xenial
<rvr> sil2100: Yes, it did
<boiko> sil2100: none of them are ready for release
<boiko> sil2100: well, silo 54 maybe, but on silo 25 we are expecting rebuilts to happen
<sil2100> boiko: ok, then maybe it's safer to just remove the binaries then
<boiko> sil2100: yep, I think it is better to rebuild the silos indeed
<sil2100> boiko: done, yw!
<boiko> sil2100: great! thanks
<rvr> jgdx: http://people.canonical.com/~vrruiz/ubuntu-system-settings-ota-about.png
<jgdx> uh
<rvr> jgdx: The string is "OTA-x"
<rvr> jgdx: version_detail: device=20150821-736d127,custom=20150925-901-35-40-vivid,keyring=archive-master,tag=OTA-x,version=
<jgdx> rvr, what's the output of gdbus call -y -d com.canonical.SystemImage -o /Service -m com.canonical.SystemImage.Information
<rvr> jgdx: ({'device_name': 'krillin', 'current_build_number': '2', 'last_check_date': '', 'channel_name': 'tag-test', 'version_detail': 'device=20150821-736d127,custom=20150925-901-35-40-vivid,keyring=archive-master,tag=OTA-x,version=2', 'target_build_number': '-1', 'last_update_date': '2015-10-29 13:07:36'},)
<jgdx> rvr, so, on the previous screen, does it say OTA-x?
<rvr> jgdx: Where?
<jgdx> go back one,
<rvr> Hmm
<jgdx> rvr, how can I test this channel and image?
<rvr> Wait a moment
<rvr> The silo didn't install
<rvr> jgdx: "Unavailable" should be translated
<jgdx> rvr, yeah, that's bad.
 * sil2100 hopes he didn't break anything by adding the tag as OTA-x
<sil2100> Didn't want to put any confusion with an image with a real OTA tag
<jgdx> sil2100, let's just get it right :) Thanks for providing the image. Do you have some steps I can do to install this image?
<rvr> The following packages have been kept back:
<rvr>   libsystemsettings1
<jgdx> oh, yeah, maybe it prefers the newer stable overlay system settings?
<sil2100> jgdx: I ran it on my private s-i server locally, I don't want to keep my ports open for too long
<jgdx> rvr, you know what to do or do you want steps?
<jgdx> sil2100, okay
<jgdx> rvr, btw, I haven't changed "OS build number" to use the OTA. I can't remember the rationale for that, though.
<sil2100> If you guys need it for testing tho, I can set it up on a canonistack instance temporarily
<rvr> jgdx: sil2100 has a local server
<rvr> jgdx: But it takes ages to download
<jgdx> rvr, are you able to install the correct USS version?
<rvr> sil2100: I have a faster connection, do you want me to upload the bits somewere?
<rvr> somewhere
<rvr> jgdx: Still trying
<rvr> It refuses to do a dist-upgrade
<jgdx> rvr, apt-cache policy ubuntu-system-settings and then install by apt-get install {libsystemsettings1,ubuntu-system-settings}=$version
<jgdx> pick the version provided by the silo
<rvr> jgdx: Ahh, the version of the stable ppa is higher that the one in the silo
<jgdx> yes
<rvr> jgdx: The following packages will be REMOVED:
<rvr>   account-plugin-ubuntuone obexd-server ubuntu-system-settings
<rvr>   ubuntu-system-settings-online-accounts ubuntu-touch ubuntu-touch-session
<rvr> jgdx: http://paste.ubuntu.com/12999225/
<rvr> jgdx: Looks ugly
<rvr> jgdx: Status	SILO DIRTY: You must rebuild: ubuntu-system-settings
<jgdx> aaah, okay, let's do a rebuild
<dobey> rvr: can we get pay-ui/pay-service requests tested now? mardy's fix from yesterday is in the overlay ppa now, and these requests have been sitting here for a week now
<rvr> dobey: This morning it wasn't available in the overlay PPA, but I'm checking other silos now.
<dobey> rvr: is nobody else doing the qa sign off testing too? i see your face on a lot of cards, and not many others :-/
<rvr> dobey: Right now, yes.
<mardy> jgdx, rvr: silo 18 now fixes bug 1511055
<ubot5> bug 1511055 in webapps-sprint "Cannot go back to Accounts" [Critical,In progress] https://launchpad.net/bugs/1511055
<jgdx> mardy, thank you
<mardy> jgdx: I also merged your MP into the uitk 1.3 branch: https://code.launchpad.net/~jonas-drange/ubuntu-system-settings-online-accounts/lp1445350/+merge/271956
<robru> bzoltan_: did you get your gles problem fixed? I'm around to look at it if it's still a problem. What silo?
<rvr> mardy: Great
<jgdx> mardy, thanks
<alecu> rvr: jibel: sil2100: we screwed up, and forgot about the extra strings in the sound indicator bugfixes in silo 46. Still, I'm talking with xavigarcia and we'd like to know if it's possible to request an exception, since  there's an extra week for bugfixing this time, and that will give enough time for translators to get that done.
<alecu> it's this card: https://trello.com/c/4fh6dI4j/2417-528-ubuntu-landing-046-indicator-sound-xavi-garcia-mena
<mardy> jgdx: thanks to you :-)
<bzoltan_> robru:  not yet
<bzoltan_> robru: https://ci-train.ubuntu.com/job/ubuntu-landing-051-1-build/52/console
<alecu> rvr: xavigarcia: I've got confirmation from jibel and pmcgowan that an exception is allowed for the strings in silo 46. So: we need to give a week before the final freeze for translators to work on this, and please xavigarcia, as soon as this lands let the -translators mailing list know about the new strings.
<robru> bzoltan_: looks like the versions are out of sync, xenial build is building .1 but gles build is looking for .2 somehow. Maybe try a version bump in the upstream part of the version to force them to sync up again.
<rvr> alecu: Ack
<bzoltan_> robru:  I will try
<rvr> jgdx: Build failed
<alecu> rvr: thanks
<jgdx> rvr, looking
<jgdx> rvr, it didn't even try.. Let's do another.
<robru> bzoltan_: oh it's probably because you put .1 in the changelog, so the train tried to increment that
<robru> bzoltan_: you probably shouldn't touch the changelog manually anymore, just put your message in the mp "commit message" field, it will generate the changelog with right values.
<robru> bzoltan_: or if you really need to touch the changelog just put "upstream-0ubuntu1" don't try to predict the date part, train will add that itself
<bzoltan_> robru:  Okey, i push the gles branch again and see
<rvr> dobey: There is a problem with this test "Security Information: Paypal payment"
<rvr> dobey: When I tap cancel in the paypal login page, it shows a Ubuntu One login page
<rvr> dobey: In stable, it goes back to the the app info screen, as expected
<jgdx> rvr, okay, this uss build seems to be more successful
<rvr> jgdx: Cool
<dobey> rvr: huh.
<Saviq> robru, is it expected that a unity8, qtmir, qtmir-gles rebuild would take almost 1.5h just to prepare packages https://ci-train.ubuntu.com/job/ubuntu-landing-021-1-build/232/consoleFull ?
<Saviq> ah hmm, *2, because dual landing... still, 20mins to build a source package :/
<sil2100> jibel, rvr: hey, you guys want to have the meeting today?
<jibel> sil2100, I don't think it's necessary, there is nothing special
<dobey> rvr: i get the same behavior for both, and apparently the paypal site itself is different now.
<Saviq> sil2100, is devel-proposed xenial yet? or is there a different channel?
<sil2100> Saviq: it's devel-proposed, good thing you mentioned as I see s-i didn't import the rootfs - let me do it now
<dobey> hmm, actually the sandbox paypal site that we get via staging is different than the production site
<dobey> sigh
<robru> sil2100: I'm OK to skip
<dobey> hmm, no on production it works correctly for me with both versions of payui
<robru> Saviq: that does sound quite slow, not sure why though...
<Saviq> robru, yeah, it doesn't help it doesn't log anything after "building...source package"
<Saviq> or well, just spews in the whole log in one go
<robru> Saviq: yeah i had to buffer the output of the source package build because when it was unbuffered it would print things out of order in a totally illegible way
<Saviq> robru, :)
<dobey> rvr: so this works fine for me, and none of the changed code is related to that. i'm not sure what you did, but it's working the same in both.
<robru> Saviq: part of the problem seems to be that the chroots are old and installing a ton of updates. The job that periodically refreshes the chroots has been busted fit a while but it hasn't been a priority to fix
<Saviq> robru, /me puts priority on it
<Saviq> ;)
<Saviq> robru, even if you can just do it one-off manually, every once in a while, would be good enough
<robru> Saviq: unfortunately i can't, last time i looked at it the failure was quite mysterious. Like it was saying "file not found" or something, but the file clearly existed when i checked.
<Saviq> :/
<robru> Saviq: one thing we've been wanting to do is switch from pbuilder to sbuild, i was figuring id fix everything in the switch, unfortunately there's a lot of priorities right now
<robru> Saviq: https://ci-train.ubuntu.com/job/upgrade-chroot/489/console yeah this has always been a mystery to me
<Saviq> robru, I think that's expected, if cowcopy ever worked, steaks would've been much cheaper... and likely less greenhouse gases, too
<robru> Heh
<jgdx> rvr, built :)
<robru> Saviq: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/1185#citrain/jenkins-templates/upgrade-chroot.xml.tmpl well that was embarassingly easy to fix. let me know if your next build is any faster
<robru> Saviq: although the update to the xenial pbuilder is tiny compared to the giant list of updates I saw in your build log, not sure what that's about.
<robru> Saviq: on second look, seems like your builds just pull in a ton of deps. Did you add new deps recently?
<Saviq> robru, I think the real problem is there's no Test-Depends: in debian/control
<Saviq> robru, so our Build-Depends might indeed be excessive
<Saviq> robru, or maybe even Source-Depends, as obviously building a source package does not require all of build-depends
<robru> Saviq: is Source-Depends a thing? never heard of that one. it is a bit silly to pull in the entire world just to build a source package though
<Saviq> robru, well, yeah, that's the problem, there isn't
<robru> heh
<Saviq> robru, yeah, well, if only there was a way to declare srcpkg depends (some need some specific dh- packages, for example)
<Saviq> unity8 itself I don't think requires anything above build-essential
<robru> Saviq: yeah this is a problem I've run into in the past. not sure why debian doesn't handle this better. not much we can do I guess
<Saviq> robru, we could devise a custom addition to debian/control that the train would use
<robru> Saviq: oh god pls no
<robru> Saviq: the train-specific gles hackery is bad enough
<Saviq> robru, oh well, I only meant X-Source-Depends or so
<Saviq> robru, you'd use Build-Depends if not present, is al
<Saviq> l
<Saviq> robru, in any case, I'll have a look and see if we could clear this thing up
<Saviq> robru, maybe we reduce Build-Depends to a minimum and add a debian/control.tests with Build-Depends listing test-only dependencies
<Saviq> so that we can still use mk-build-deps on that or so
<Saviq> we already have a bit of a split between build.sh and debian/control
<Saviq> not a great situation indeed
<robru> Saviq: yeah I'm not sure what to do about that
<Saviq> robru, but I don't think X-Ubuntu-Source-Depends: would be such a bad idea, we have a bunch of custom bits for debian/control arleady
<Saviq> even for the train (like the no-rewrite thing)
<Saviq> robru, but yeah, a lot of our Build-Depends could probably be scrapped, we've been abusing it for test dependencies
<Saviq> but then we'd have to duplicate it between debian/control.test and debian/tests/control :/
<Saviq> meh meh meh
<robru> yeah
 * Saviq will talk with pitti tomorrow to see if they ever thought of that
<kenvandine> wow... citrain spam :)
<robru> kenvandine: yeah I don't know what the hell this is, I specifically coded queuebot not to spam on startup, but apparently there's some kind of network error causing it to parcially clear it's state, but not clear it enough to think it's starting fresh and suppress the startup spam.
<robru> kenvandine: like, the state gets cleared enough that it thinks it needs to notify all this stuff, but doesn't clear enough that it realizes it's got no state and doing a fresh-startup spam
<kenvandine> queuebot was hungry, need some spam to chew on :)
<Saviq> cihelp, any reason we only have two makos online http://s-jenkins.ubuntu-ci:8080/label/mako/? ?
<pmcgowan> Saviq, I have heard they are all dying
<Saviq> :(
<pmcgowan> so need to get some krillins instead
<josepht> Saviq: what pmcgowan said, unfortunately
<sil2100> cyphermox, mterry: hey! We have a few packages that would require core-devs for releasing :)
<sil2100> cyphermox, mterry: https://requests.ci-train.ubuntu.com/#/publishable
<robru> wat http://paste.ubuntu.com/13003129/
<sil2100> ;p
<mardy> sil2100: what is the problem with silo 56 and libaccounts-qt?
<mterry> sil2100, looking
<sil2100> mardy: nothing wrong so far, I'm just not powerful enough to publish that
<sil2100> mterry: thanks!
<sil2100> mardy: it needs a core-dev, I'm just a MOTU
<sil2100> mterry: I'll take unity-scopes-shell, that's an universe package
<sil2100> mterry: the mediascanner2 landing needs an archive admin btw.
<sil2100> mterry: since it renames a package
<sil2100> mterry: (just so you know)
<sil2100> :)
<mterry> sil2100, that doesn't affect publishing though right?  that's a post-publish step?
<sil2100> mterry: it's actually a pre-publish step
<mterry> sil2100, oh.  OK, will leave that one alone then
<sil2100> mterry: since the train doesn't respect new binary packages, just pushes them without them going to the NEW queue
<mterry> oh huh.  I didn't know we could shortcircuit NEW
<sil2100> mterry: for new source packages - yes, but for new binary ones we need to poke some archive admin
<sil2100> slangasek: hey! If you have a moment, there's a silo that needs an archive admin checking the binNEW -> https://ci-train.ubuntu.com/job/ubuntu-landing-031-2-publish/24/
<slangasek> sil2100: looking
<sil2100> brb
<slangasek> sil2100: isn't this package missing Conflicts/Replaces from qml-module-ubuntu-mediascanner0.1 against the old version of qtdeclarative5-ubuntu-mediascanner0.1?  It looks to me that the package will fail to upgrade, which is more important than the transitional package issue
<slangasek> sil2100: it's ok from an AA POV but not from a core-dev signoff
<mterry> sil2100, silo 56 looks fine packaging wise, but needs to incorporate the archive changes above ^
 * mterry goes afk for a few minutes
<robru> holy hell, silo 56 wasn't built since before the gcc transition??
<michi> robru: Whatâs with the flood of notifications anyway?
<robru> michi: queuebot is a braindead piece of crap
<michi> I havenât built anything since yesterday, and now Iâm being told that the build has finished
<michi> Ah, that explains it then :)
<robru> michi: I don't know why or how, but I'm told that queuebot is experiencing some sort of network error that causes it to lose all it's state (so it thinks all those statuses are new and need to be pinged), but it doesn't lose ALL of it's state, otherwise it would hit the piece of code I wrote that says "hey if there's no state, don't spam the channel"
<michi> Oh well, itâs not the end of the world. There are bugs worse than this :)
<robru> yeah
#ubuntu-ci-eng 2015-10-30
<sil2100> jibel, davmor2: I tried cancelling the meeting but not sure if I just didn't remove it for me
<sil2100> So if anything, no morning meeting anyway
<jibel> sil2100, WFM
<jgdx> rvr, hey, how's it going?
<rvr> jgdx: Hi. I'm finishing another silo.
<jgdx> rvr, okay dokay
<boiko> sil2100: could you please publish silo 22?
<sil2100> boiko: on it in a min, don't have reliable internet here
<sil2100> 10 mins and I'm good again
<boiko> sil2100: thanks
<boiko> renatu: ^
<Saviq> cihelp any idea why those xenial failures https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-xenial-mako/8/console ?
<renatu> boiko, sil2100, ok thanks
<sil2100> renatu, boiko: published, yw!
<renatu> sil2100, thanks
<dobey> rvr: i commented on the card in trello, but the pay-ui blank page on cancelling adding a card is known issue with a fix in waiting, and the other thing was you actually cancelled adding the card, so it's expected to not be added at that point. so can we move this forward?
<rvr> dobey: Known issue? It's not happening with the current version.
<rvr> At least, for me, it doesn't happen
<rvr> Only with the new
<dobey> rvr: it most certainly does happen with the current version.
<rvr> I tested with both
<rvr> With the version that comes in rc-proposed and with the click package
<rvr> only with the click package showed the blank page
<dobey> i can't imagine how it would not happen for you with the current version, and not the new pay-ui
<dobey> given the issue is with existing code, and none of that code changed in this pay-ui
<rvr> In stable, cancelling in PayPal correctly goes back to the payment screen
<rvr> Sorry, cancelling in the add credit card
<rvr> Doing that with the new pay-ui, shows a page in blank
<dobey> not here it doesn't
<psivaa> Saviq: let me take a look at that
<dobey> rvr: nessita filed the bug with the current version in the store, and it's certainly not working in the current version. if it somehow does for you, i don't know what to tell you, but it definitely doesn't work that way.
<dobey> rvr: it /is/ a regression, just not a new one in this version of pay-ui.
<rvr> dobey: https://people.canonical.com/~vrruiz/pay-ui-add-card-cancel-stable.mp4
<dobey> rvr: well that's very odd. even the working version doesn't return that fast for me, on my wifi and 500 Mbps upstream. you must be hitting some other bug that's somehow magically resulting in you getting returned to that page, because the code path does not work correctly in the current version.
<dobey> rvr: so i have no way to explain what you're seeing, other than a bug that is working in your favor.
<rvr> dobey: https://people.canonical.com/~vrruiz/pay-ui-add-card-cancel-rc-proposed.mp4 (mako)
<rvr> Above was krillin in stable
<dobey> rvr: try it in english
<rvr> dobey: https://people.canonical.com/~vrruiz/pay-ui-add-card-cancel-rc-proposed-new.mp4 (mako)
<rvr> And this is the one that fails
<rvr> Switching to English
<rvr> dobey: With the new click, same result, blank page
<dobey> yes of course, but it's an issue in the current click too
<rvr> But I can only see the issue with the new click
<rvr> And now, you too
<rvr> So, what's up?
<rvr> 2015-10-30 14:39:00,451 - DEBUG - [JS] (https://myapps.developer.ubuntu.com/click/payment-method/add/child/?currency=EUR:788) Signal: send HEARTBEAT
<rvr> 2015-10-30 14:39:00,453 - CRITICAL - [JS] (:0) Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://software-center.ubuntu.com') does not match the recipient window's origin ('https://myapps.developer.ubuntu.com').
<dobey> rvr: huh? no, i see the issue with the old click, not only the new one
<dobey> like i said, this is definitely an issue in existing code
<dobey> is there some way to record a video directly from the mir buffer?
<rvr> dobey: Logs for 15.01.120 http://paste.ubuntu.com/13009752/ and logs for 15.01.133 http://paste.ubuntu.com/13009794/
<dobey> there's nothing useful in those logs. all the [JS] messages are from oxide and a result of server side js code, and have nothing to do with any changes in the click itself
<mardy> seb128: do I understand correctly, that if I add a "Recommends: mypackage" to a package that is currently preinstalled in the phone image, "mypackage" will also be preinstalled? Or that works only with Depends?
<dobey> and nothing changed in the click related to the problem you claim you aren't seeing in the old click. the problem is there
<rvr> dobey: I don't "claim". I showed you the videos and the logs.
<dobey> there is a bug reported and a branch that fixes it, waiting  to land
<dobey> rvr: like i said, afaict, you are apparently hitting some other bug, which apparently works in your favor
<dobey> rvr: i know the code. the issue is present in current code.
<rvr> dobey: If I'm hitting another bug, find it and fix it.
<rvr> I showed you the logs and the videos. There is a problem, I don't know which.
<seb128> mardy, the phone image doesn't install recommends as far as I know
<seb128> so no that wouldn't work
<dobey> rvr: well i don't know what else to say. the issue exists in the current pay-ui. i can't explain why you are being returned to the checkout page so quickly, and magically not hitting the issue there, or why you are somehow hitting the issue in the newer pay-ui. i have a fix for the issue in line, but you're blocking the current click, so getting it through QA is blocked on getting the current stuff through QA.
<rvr> jgdx: ping
<mardy> seb128: thanks :-)
<seb128> mardy, yw
<rvr> mardy: Can you get a review for silo 18?
<pmcgowan> rvr, I cna approve it since db is away
<pmcgowan> can
<dobey> rvr: did you try the old pay-ui in en_US?
 * pmcgowan loads 18
<rvr> dobey: Nope
<rvr> pmcgowan: mardy's merge proposal needs a code review/approval
<rvr> pmcgowan: If you can do it, fine :)
<pmcgowan> rvr, dbarth approved it, and I also reviewed it, will try the silo
<pmcgowan> its just qml :)
<pmcgowan> works
<dobey> rvr: well, in en_US the issue happens for me regardless of the pay-ui click. and in spanish i get your videod behavior with the new click.
<sil2100> rvr: how's the OTA tag silo sign-off going? :) I'm in the middle of preparing a remote s-i for testing in case it's needed
<dobey> so a translation is causing some other issue or something, i don't know, but the bug exists in the current pay-ui
<rvr> sil2100: I have troubles installing the packages from the silo
<rvr> sil2100: http://paste.ubuntu.com/13010059/
<sil2100> rvr: didn't it get rebuilt yesterday?
<rvr> sil2100: Yes, it's weird
<sil2100> jgdx: ^ ?
<rvr> pmcgowan: Thanks
<jgdx> sil2100, when did you flash the phone last?
<jgdx> rvr, ^ (sil sorry)
<rvr> jgdx: I flashed it today
<rvr> I always reflash and wipe for testing
<pmcgowan> rvr, it installs for me with citrain
<jgdx> rvr, apt-cache policy system-image-dbus
<jgdx> yeah, I have 3.0.2 here, flashed yesterday
<pmcgowan> rvr, did you instal both packages
<rvr> Ahhh, wait, wait, wait
 * jgdx waits
<rvr> This is sil2100's server image
<sil2100> hm?
<jgdx> can that package be updated using apt?
<rvr> sil2100: I'm testing jgdx's silo with the image I downloaded from your local s-i
<sil2100> rvr: that's good, right?
<sil2100> rvr: ah!
<sil2100> rvr: right, it's an rc image
<rvr> sil2100: Well, I think that the updated packages are no longer in the overlay PPA
<sil2100> So it might have slightly outdated packages, you'd have to pull in more stuff from the overlay
<rvr> Let me check
<sil2100> Maybe try apt-get upgrading, it should simply pull in everything it needs from the overlay
<sil2100> Anyway, this shouldn't be a problem
<sil2100> Since if you do apt-get update with the overlay enabled, then it should just pull in all new deps when installing the silo
<rvr> Yes, it is available in the overlay PPA
<rvr>      3.0.2-0ubuntu1 0
<rvr>          50 http://ppa.launchpad.net/ci-train-ppa-service/stable-phone-overlay/ubuntu/ vivid/main armhf Packages
<rvr>  *** 2.5.1-0ubuntu1~overlay1 0
<rvr>          50 http://ppa.launchpad.net/ci-train-ppa-service/stable-snapshot/ubuntu/ vivid/main armhf Packages
<rvr> I need to pin the stable-phone-overlay higher
<rvr> sil2100: Is there any chance of breaking anything doing that?
<rvr>  system-image-dbus : Depends: system-image-common (= 3.0.2-0ubuntu1) but 2.5.1-0ubuntu1~overlay1 is to be installed
<jgdx> sudo apt-get install {system-image-common,system-image-dbus}=3.0.2-0ubuntu1
<rvr> jgdx: The following packages will be REMOVED:  system-image-cli ubuntu-touch
<jgdx> hm
<jgdx> maybe add s-i-cli to the list {-common,-dbus,-cli}=â¦
<jgdx> if an upgrade doesn't work
<sil2100> Wait, what depends on s-i 3.0.2?
<sil2100> I thought we don't switch to s-i 3.0.2 yet, or do we?
<sil2100> hm, maybe barry did release it for vivid
<sil2100> Oh, he did
<sil2100> nvm
<sil2100> Yeah, the rc images didn't have the new s-i yet
<Saviq> mako/devel-proposed doesn't boot for me, known?
 * barry waves
<jgdx> :)
<psivaa> Saviq: the failure that you pointed before could be related. i wanted to test with 336 to confirm if that is working
<jgdx> rvr, how's it going?
<Saviq> psivaa, yeah indeed
<psivaa> --revision=336 should flash OK,  but waiting for a device to be available
<rvr> jgdx: I can't get pinned the whole stable-overlay ppa
<Trevinho> "bzr missing" failed: No handlers could be found for logger "bzr" :o
<sil2100> o_O
<sil2100> Trevinho: seems to work now, right?
<Trevinho> sil2100: yeah...
<rvr> sil2100: Your customized image worked, now testing with a regular image that there are no regressions
<sil2100> \o/
<psivaa> Saviq: with image 336, http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-xenial-mako/9/console appear to go past that failed stage . this is a temporary workaround until the devel-proposed image is flashable
<Saviq> psivaa, thanks
 * Saviq flashes 336
<rvr> jgdx: sil2100: Approved silo 47
<sil2100> \o/
<sil2100> rvr: thanks!
<rvr> sil2100: Are you adding OTA tag to rc-proposed soon?
<sil2100> You mean, to the public system-image server?
<sil2100> I still need to finish writing some unit tests for it
<sil2100> But we don't intend tagging anything in the public (besides some test channel if anything) before OTA-8
<rvr> sil2100: One test that we didn't do is to upgrade from an image tagged as ota_n to ota_n+1
<renatu> robru, sil2100 , any problem with silo: .cache/upstart/sync-monitor.log, it is ok proposed pocket for a while
<renatu> sorry
<renatu> https://requests.ci-train.ubuntu.com/#/ticket/575
<rvr> mardy: Silo 18 approved
<robru> renatu: excuses page says valid candidate and that was generated just 10 minutes ago, I guess it will migrate soon?
<dobey> alesage: are you around and able to do any qa signoff testing?
<alesage> dobey I am around and I am able to do qa signoff testing
<dobey> alesage: can you test pay-ui and see if you can replicate what rvr sees?
<alesage> dobey rvr's observations are valid
<dobey> i didn't say they weren't valid.
<Saviq> trainguards, can you please restart qtmir and qtmir-gles builds in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-021/+packages - we had some dependency issues that are now solved, but don't want to go through source builds unnecessarily
<robru> Saviq: on it
<Saviq> robru, thanks
<robru> Saviq: uh but you ran a full rebuild anyway? https://ci-train.ubuntu.com/job/ubuntu-landing-021-1-build/236/consoleFull this will clobber all the qtmir rebuilds I just did
<Saviq> robru, that rebuild is the rebuilds you just pushed
<robru> Saviq: what are you talking about? "Started by user MichaÅ Sawicz"
<Saviq> robru, yeah, but 3h ago
<dobey> alesage: i'm not inquiriing about validity. i'm querying about replicability.
<Saviq> robru, and qtmir from that build job failed in PPA, that's what I asked to restart
<robru> Saviq: oh weird, when I was looking at that it didn't show the full log, it looked like it was still preparing packages
<Saviq> robru, yeah, same here
<Saviq> robru, thanks
<robru> Saviq: ok nm, rebuilds pushed, will restart the watching so it sees them
<boiko> robru: silo 22 is waiting for qtorganizer5-eds to migrate from proposed for a few hours already, any idea what could be causing the delay?
<robru> boiko: not sure
<robru> boiko: I just asked in #ubuntu-release
<boiko> renatu: ^
<robru> renatu: boiko: check #ubuntu-release, some info there
<boiko> robru: thanks
<robru> boiko: you're welcome
<boiko> renatu: can you check that the packages mentioned there are installable with the silo somehow?
<Saviq> robru, oh grr, forgot, can you please rebuild unity8, too (same problem(
<robru> Saviq: k
<renatu> boiko, robru , I have the silo installed on my device
<renatu> I will re-check
<robru> renatu: boiko: the issue is with xenial-proposed
<robru> renatu: boiko: you'll need to test with a xenial sbuild with -proposed enabled, nothing to do with device
<robru> renatu: boiko: I may have time to look at it later just a bit swamped right now
<boiko> robru: that'd be great! thanks
<renatu> robru, ok, thanks. Let me know if you need any info. I am not sure what could cause that. since the silo changes does not change any package related script
<renatu> robru, it could be related with a change-log that I push direct in the turnk, was the g++5 forced build
<robru> renatu: adam said it could be caught by unrelated changes in another package, will really take some digging
<boiko> robru: I see a new evolution-data-server in the excuses, maybe it could be it?
<robru> boiko: yeah it's possible, but like I said you have to make an sbuild and really dive into it to find out, I'll get to it after lunch
<boiko> robru: yep, ok, thanks
<robru> renatu: boiko: see? you just needed to wait for it to solve itself ^^ ;-)
#ubuntu-ci-eng 2015-10-31
<boiko> robru: :D
<robru> gosh darn it queuebot!
#ubuntu-ci-eng 2015-11-01
<robru> Gooby pls
#ubuntu-ci-eng 2016-10-31
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Failed to build
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2121 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2121 Successfully built
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Preparing packages
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Currently building (vivid/unity-scopes-shell, xenial/unity-scopes-api, xenial/unity-scopes-shell, zesty/unity-scopes-api, zesty/unity-scopes-shell). Failed to build (vivid/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Preparing packages
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2069 This ticket must be migrated to zesty+xenial+vivid before it can be built
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2069 Successfully built
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Successfully built
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Preparing packages
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Failed to build (zesty/indicator-network). Successfully built (xenial/indicator-network)
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2115 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2115 Publishing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2115 xenial/miral: Failed to update local lp:~ci-train-bot/miral/miral-ubuntu-xenial-2115 cache
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Merging branches
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Currently building (xenial/indicator-network). Failed to build (zesty/indicator-network)
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2115 Merging branches
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2094 Needs rebuild due to new commits (zesty/ubuntu-system-settings-online-accounts). Successfully built (vivid/ubuntu-system-settings-online-accounts, xenial/ubuntu-system-settings-online-accounts)
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Failed to build (zesty/indicator-network). Successfully built (xenial/indicator-network)
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Preparing packages
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2111 Publishing packages
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2111 Publish failed: Packaging diff requires ACK
<oSoMoN> trainguards: can you please publish https://bileto.ubuntu.com/#/ticket/2111 for me?
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2111 Successfully built
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Preparing packages
<sil2100> oSoMoN: on it
<sil2100> hm, why did the autopkgtests fail?
<oSoMoN> sil2100, not sure, but this is a SRU silo and it looks like it considered an upgrade path from the package in the stable overlay PPA?
<oSoMoN> i.e. 0.23+16.04.20161024.1-0ubuntu1 is not in xenial release, itâs only in the overlay
<sil2100> Ok, looks safeish, for a moment I was worried that the silo was still building against the overlay
<sil2100> But no, phew
<sil2100> Ok, let me publish that anyway
<sil2100> bzoltan: hey! Regarding the disabled arm64-tests - could you merge to your staging branch the change to re-enable the arm64 tests again?
<sil2100> bzoltan: this would enable me to publish the current packages as-is without any trouble
<bzoltan> sil2100:  I will do
<sil2100> bzoltan: thanks! If you could poke me once that's done, would be grateful :)
<bzoltan> sil2100: I will do so
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2111 Publishing packages
<bzoltan> sil2100: ohh silly me, that change exists only in the landing branch. It is not present in the staging neither in the trunk. So i can patch it out after the landing branch is merged. Or i can fix the landing branch and spin a new build.
<sil2100> bzoltan: no no, I guess let's just release this as is then, but please add to your short term TODO listo to revert this as soon as it merges in
<sil2100> I don't want to block the landing anymore
<bzoltan> sil2100: I will do it in the following 5 minutes  after the landing branch is merged to the trunk.
<sil2100> bzoltan: please note that I'll have to manually publish this silo so it might take a bit until it's merged and finalized, since this I will ahve to do manually as well
<sil2100> (since it still has yakkety binaries)
<bzoltan> sil2100: acknowledged :)
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2069 Release pocket (vivid/ubuntu-ui-toolkit, vivid/ubuntu-ui-toolkit-gles, xenial/ubuntu-ui-toolkit, xenial/ubuntu-ui-toolkit-gles). Successfully built (yakkety/ubuntu-ui-toolkit, yakkety/ubuntu-ui-toolkit-gles)
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2111 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Pending binary packages
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Successfully built
<Elleo> trainguards: could we try rerunning the timed out tests on this silo? https://bileto.ubuntu.com/#/ticket/2033 (the autopkg tests for xenial amd64, i386 and ppc64el)
<sil2100> Elleo: hey! On it
<sil2100> Elleo: done
<dobey> is the trello obsolete now?
<Elleo> sil2100: great, thanks :)
<dobey> jibel: can i get https://bileto.ubuntu.com/#/ticket/2116 marked as either Approved or N/A for QA, as it's just pulling the yakkety snapd-glib into the overlay for xenial, so i can use it?
<pmcgowan> rvr, ^^ jibel is out till thur
<dobey> oh
<rvr> pmcgowan: Let me check
<rvr> dobey: Done
<dobey> rvr: thanks
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2116 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2117 Publishing packages
<cpaelzer> sil2100: hi, thank you so much already for the work on bileto access for non core-dev
<cpaelzer> sil2100: I wanted to ask if you had any time yet to look at the extra group you mentioned to be needed for "dput based" uploads
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2118 Publishing packages
<dobey> kenvandine, mterry, sil2100: hi, can one of you ack/publish https://bileto.ubuntu.com/#/ticket/2116 please? it's only to the overlay, so i think an AA isn't needed, especially since it's already shipped in ubuntu archive
<mterry> dobey: sure on it
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2117 Proposed pocket
<dobey> thanks
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2118 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2116 Publishing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2116 Release pocket
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2117 Release pocket
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Needs rebuild due to new commits (zesty/unity8). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, vivid/unity8, xenial/qmenumodel, xenial/ubuntu-settings-components, xenial/unity8, zesty/qmenumodel, zesty/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2113 Abandoning ticket
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
<Trevinho> ubuntu-qa: hey, why https://trello.com/c/1rrsBQw2/3696-2081-ubuntu-2081-qmenumodel-unity8-trevinho is still marked as failing?
<rvr> Trevinho: There is no automatic movement
<rvr> of cards
<rvr> Trevinho: At least to get it back :)
<Trevinho> rvr: so should I put it back to needs qa?
<rvr> There is automatic failure if the card is rebuilt
<rvr> Trevinho: Moved
<Trevinho> rvr: thanks
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Pending binary packages (xenial/unity8). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, vivid/unity8, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/qmenumodel, zesty/ubuntu-settings-components, zesty/unity8)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Successfully built
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Successfully built
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2066 Merging branches
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine jgdx, https://bileto.ubuntu.com/#/ticket/2078 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/1994 Merging branches
<robru> slangasek: meeting? no sil?
-queuebot:#ubuntu-ci-eng- alex-abreu, https://bileto.ubuntu.com/#/ticket/1640 Cancelled build (xenial/content-hub). Needs rebuild due to new commits (yakkety/content-hub). Successfully built (vivid/content-hub)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/1721 Failed to build (vivid/ubuntu-system-settings). Needs rebuild due to new commits (zesty/ubuntu-settings-components, zesty/ubuntu-system-settings). Successfully built (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components, xenial/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Successfully built
<dobey> robru: -1 ERROR ?
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
<dobey> hmm, seems to have righted itself now
<robru> dobey: what were you doing when it happened?
<robru> dobey: I've seen it do 0 ERROR if you interrupt an ajax request but I've never seen -1 before, fun
<dobey> robru: did a build and then switched back to the ticket tab and clicked to open the MP in a new tab, then switched back to the ticket tab and it displayed that
<robru> huh
-queuebot:#ubuntu-ci-eng- kenvandine jgdx, https://bileto.ubuntu.com/#/ticket/2078 Successfully built
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2124 zesty/compiz: Failed to commit https://code.launchpad.net/~albertsmuktupavels/compiz/gwd-support-metacity-3-22. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2124 Preparing packages
<mardy> dobey, robru: I'd prefer if git commits didn't get squashed automatically; if one wants to, he can do that on the proposed branch
<robru> mardy: yeah that's what I was thinking, the current behavior gives you the option to squash yourself, but if bileto does the squashing then you don't have an option
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Needs rebuild due to new commits (zesty/ubuntuone-credentials). Successfully built (xenial/ubuntuone-credentials)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2124 Pending binary packages
<dobey> well i guess my complaint isn't really about the squashing, but the git UX just being utterly horrible
<dobey> and that's not necessarily bileto's fault
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Pending binary packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2124 Successfully built
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Successfully built
<slangasek> robru: no me either because Romania
<robru> ah right
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Successfully built
#ubuntu-ci-eng 2016-11-01
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2094 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2094 Successfully built
-queuebot:#ubuntu-ci-eng- dobey marcustomlinson, https://bileto.ubuntu.com/#/ticket/2100 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2100 Uploading build
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2094 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2100 Successfully built
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Preparing packages
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Successfully built
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2125 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2126 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2125 Pending binary packages (zesty/online-accounts-api). Successfully built (vivid/online-accounts-api, xenial/online-accounts-api)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2126 Abandoning ticket
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2125 Successfully built
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Needs rebuild due to new commits (zesty/unity8). Successfully built (vivid/indicator-power, vivid/qtmir, vivid/qtmir-gles, vivid/unity-api, vivid/unity8, xenial/indicator-power, xenial/qtmir, xenial/qtmir-gles, xenial/unity-api, xenial/unity8, zesty/indicator-power, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Successfully built
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Needs rebuild due to new commits (zesty/ubuntuone-credentials). Successfully built (xenial/ubuntuone-credentials)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Successfully built
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Pending binary packages (zesty/ubuntu-app-launch). Successfully built (vivid/ubuntu-app-launch, xenial/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 xenial/url-dispatcher: Failed to add changelog message
<mterry> tedg: oh you're starting on the mega silo, thanks
<mterry> I can help with that after lunch
<tedg> mterry: Yeah, not sure why that changelog failed :-/
<mterry> maybe I didn't set a changelog?
<tedg> You did :-)
<mterry> hmm
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Successfully built
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2128 Pending binary packages (vivid/ubuntu-system-settings, xenial/ubuntu-system-settings). Successfully built (zesty/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Ready to build
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 xenial/ubuntu-touch-session: Failed to add changelog message
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 xenial/ubuntu-touch-session: Failed to add changelog message
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2127 Pending binary packages (xenial/content-hub). Successfully built (vivid/content-hub, zesty/content-hub)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2128 Successfully built
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 xenial/unity-scopes-shell: Failed to add changelog message
<tedg> cjwatson: It looks like there's no webhook for a new package in a PPA. Just checking to make sure there isn't a super secret way to do it :-)
<cjwatson> tedg: Correct, we have no archive webhooks today (and nobody has yet filed a bug asking for one ...)
<tedg> cjwatson: K, my real use-case was to build a snap based on a PPA updating, but was gonna connect the two via IFTTT if there was a webhook.
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2125 QA Signoff: Ready
<cjwatson> tedg: I'm all for adding it given a real use
<cjwatson> sounds like a good idea
 * tedg files a bug
<cjwatson> thanks
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2127 Successfully built
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Ready to build
<robru> tedg: your MPs are targeting yakkety trunks but it's a xenial ticket, this is forbidden because the version number is lower than the previous one. You need to either do a z+x or fork trunks for xenial
<tedg> robru: Ah, thanks!
<robru> tedg: you're welcome
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 zesty/indicator-transfer: Failed to merge https://code.launchpad.net/~mterry/indicator-transfer/snap-root
-queuebot:#ubuntu-ci-eng- kenvandine jgdx, https://bileto.ubuntu.com/#/ticket/2078 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 zesty/indicator-network: Failed to merge https://code.launchpad.net/~mterry/indicator-network/snap-root
<mterry> tedg: you didn't like indicator-transfer?  :)
<tedg> mterry: Failure to merge ^
<mterry> oh shoot, I wasn't paying attention to those messages
<mterry> will fix both
<tedg> Cool
<tedg> mterry: Initial build of the snap here: https://launchpad.net/~ted/+snap/unity8-session-silo
<mterry> network and transfer fixed
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Bad merges (zesty/unity-scopes-api). Currently building (xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-messages, xenial/indicator-network, xenial/indicator-power, xenial/indicator-session, xenial/indicator-sound, xenial/indicator-transfer, xenial/ubuntu-app-launch, xenial/unity-scope-scopes, xenial/unity-scopes-api, xenial/unity-scopes-
<mterry> scopes-api...
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Dependency wait (zesty/unity-scopes-shell). Successfully built (vivid/unity-scopes-api, vivid/unity-scopes-shell, xenial/unity-scopes-api, xenial/unity-scopes-shell, zesty/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Currently building (xenial/indicator-bluetooth, xenial/indicator-session, xenial/ubuntu-app-launch, xenial/unity-scopes-api, xenial/unity-scopes-shell, xenial/unity8, zesty/indicator-network, zesty/unity-scope-scopes, zesty/unity-scopes-api, zesty/unity8). Failed to build (xenial/url-dispatcher, zesty/unity-scopes-shell, zesty/url-dispatcher). Needs building (xenial/indicator-sound, zesty/in
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2033 Destination version missing from changelog (zesty/ubuntu-download-manager). Successfully built (vivid/ubuntu-download-manager, xenial/ubuntu-download-manager)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2128 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Currently building (xenial/ubuntu-app-launch, zesty/unity-scopes-api). Failed to build (xenial/url-dispatcher, zesty/unity-scopes-shell, zesty/url-dispatcher). Pending binary packages (zesty/unity8). Successfully built (xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-network, xenial/in
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Successfully built
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Currently building (xenial/ubuntu-app-launch). Failed to build (xenial/url-dispatcher, zesty/unity-scopes-shell, zesty/url-dispatcher). Successfully built (xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-network, xenial/indicator-power, xenial/indicator-printers, xenial/indicator-sessi
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2096 Publishing packages
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2096 Proposed pocket (zesty/unity8-desktop-session). Release pocket (xenial/unity8-desktop-session)
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/1679 Destination version missing from changelog (zesty/unity8-desktop-session). Needs rebuild due to new commits (zesty/lightdm, zesty/ubuntu-touch-session, zesty/unity8). Successfully built (vivid/gsettings-ubuntu-touch-schemas, vivid/lightdm, vivid/ubuntu-touch-session, vivid/unity8, vivid/unity8-desktop-session, xenial/gsettings-ubuntu-touch-schemas, xenial/lightdm, xenial/ubuntu-touch-session, xen
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2128 Successfully built
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Pending binary packages (zesty/ubuntuone-credentials). Successfully built (xenial/ubuntuone-credentials)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Failed to build
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Failed to build (xenial/ubuntu-app-launch, xenial/url-dispatcher, zesty/unity-scopes-shell, zesty/url-dispatcher). Successfully built (xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-network, xenial/indicator-power, xenial/indicator-printers, xenial/indicator-session, xenial/indicator-
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2096 Release pocket (xenial/unity8-desktop-session). Successfully built (zesty/unity8-desktop-session)
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/1679 Needs rebuild due to new commits (zesty/lightdm, zesty/ubuntu-touch-session, zesty/unity8). Successfully built (vivid/gsettings-ubuntu-touch-schemas, vivid/lightdm, vivid/ubuntu-touch-session, vivid/unity8, vivid/unity8-desktop-session, xenial/gsettings-ubuntu-touch-schemas, xenial/lightdm, xenial/ubuntu-touch-session, xenial/unity8, xenial/unity8-desktop-session, zesty/gsettings-ubuntu-touch-sch
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Failed to build (zesty/ubuntuone-credentials). Pending binary packages (xenial/ubuntuone-credentials)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Needs rebuild due to new commits (zesty/qtmir, zesty/unity8). Pending binary packages (vivid/unity-api, xenial/unity-api, zesty/unity-api). Successfully built (vivid/indicator-power, vivid/qtmir, vivid/qtmir-gles, vivid/unity8, xenial/indicator-power, xenial/qtmir, xenial/qtmir-gles, xenial/unity8, zesty/indicator-power, zesty/qtmir-gles)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2127 Needs rebuild due to new commits (zesty/content-hub). Successfully built (vivid/content-hub, xenial/content-hub)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Preparing packages
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2096 Release pocket
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2127 Preparing packages
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/1679 Needs rebuild due to new commits (zesty/lightdm, zesty/ubuntu-touch-session, zesty/unity8, zesty/unity8-desktop-session). Successfully built (vivid/gsettings-ubuntu-touch-schemas, vivid/lightdm, vivid/ubuntu-touch-session, vivid/unity8, vivid/unity8-desktop-session, xenial/gsettings-ubuntu-touch-schemas, xenial/lightdm, xenial/ubuntu-touch-session, xenial/unity8, xenial/unity8-desktop-session, ze
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 /: Failed to upload diffs. Please try regenerating diffs
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Failed to build (zesty/ubuntuone-credentials). Successfully built (xenial/ubuntuone-credentials)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Bad merges (zesty/unity8). Currently building (vivid/qtmir, vivid/unity8, xenial/qtmir, zesty/qtmir). Failed to build (xenial/unity8). Pending binary packages (xenial/qtmir-gles). Successfully built (vivid/indicator-power, vivid/qtmir-gles, vivid/unity-api, xenial/indicator-power, xenial/unity-api, zesty/indicator-power, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Currently building (vivid/unity8). Failed to build (xenial/unity8). Pending binary packages (xenial/qtmir). Successfully built (vivid/indicator-power, vivid/qtmir, vivid/qtmir-gles, vivid/unity-api, xenial/indicator-power, xenial/qtmir-gles, xenial/unity-api, zesty/indicator-power, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api, zesty/unity8)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Successfully built
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Failed to build (xenial/unity8). Successfully built (vivid/indicator-power, vivid/qtmir, vivid/qtmir-gles, vivid/unity-api, vivid/unity8, xenial/indicator-power, xenial/qtmir, xenial/qtmir-gles, xenial/unity-api, zesty/indicator-power, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api, zesty/unity8)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 zesty/indicator-power: Failed to download DSC file https://launchpad.net/ubuntu/+archive/primary/+files/indicator-power_12.10.6+17.04.20161021-0ubuntu1.dsc
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Currently building (vivid/unity8, zesty/unity8). Failed to build (xenial/unity8). Successfully built (vivid/indicator-power, vivid/qtmir, vivid/qtmir-gles, vivid/unity-api, xenial/indicator-power, xenial/qtmir, xenial/qtmir-gles, xenial/unity-api, zesty/indicator-power, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Failed to build (xenial/unity8). Successfully built (vivid/indicator-power, vivid/qtmir, vivid/qtmir-gles, vivid/unity-api, vivid/unity8, xenial/indicator-power, xenial/qtmir, xenial/qtmir-gles, xenial/unity-api, zesty/indicator-power, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api, zesty/unity8)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Diff missing (vivid/qtmir, vivid/qtmir-gles, vivid/unity-api, xenial/qtmir, xenial/qtmir-gles, xenial/unity-api, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api). Failed to build (vivid/unity8, xenial/unity8, zesty/unity8). Successfully built (vivid/indicator-power, xenial/indicator-power, zesty/indicator-power)
#ubuntu-ci-eng 2016-11-02
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Abandoning ticket
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Currently building (xenial/unity-scopes-api, xenial/unity-scopes-shell, zesty/unity-scopes-api). Failed to build (zesty/unity-scopes-shell)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2131 Preparing packages
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Currently building (xenial/unity-scopes-shell). Failed to build (zesty/unity-scopes-shell). Successfully built (xenial/unity-scopes-api, zesty/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Failed to build (zesty/unity-scopes-shell). Successfully built (xenial/unity-scopes-api, xenial/unity-scopes-shell, zesty/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2131 Failed to build
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2131 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2131 Successfully built
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Abandoning ticket
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Currently building (vivid/unity8, zesty/unity8). Failed to build (xenial/unity8). Pending binary packages (vivid/indicator-power, xenial/indicator-power, zesty/indicator-power)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Failed to build (xenial/unity8). Pending binary packages (vivid/unity8, zesty/unity8). Successfully built (vivid/indicator-power, xenial/indicator-power, zesty/indicator-power)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Failed to build (xenial/unity8). Successfully built (vivid/indicator-power, vivid/unity8, xenial/indicator-power, zesty/indicator-power, zesty/unity8)
<kenvandine> ubuntu-qa:  is there an issue with the QA signoffs trello board?  Silo 2078 has been ready for QA for a while now and there still isn't a card created
<sil2100> kenvandine: I guess it might be out-of-date regarding the recent API changes, jibel would have to modify it (possibly) but he's on holidays still
<sil2100> IIRC
<kenvandine> ah
<kenvandine> yeah, bileto changes also broke the ubuntu-silo-installer too
<kenvandine> i guess we need to manually create cards for now
<kenvandine> ubuntu-qa: can someone please create a card for 2078?
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2133 zesty/content-hub: Failed to merge https://code.launchpad.net/~ken-vandine/content-hub/systemd-unit
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2134 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2127 Successfully built
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Currently building (xenial/unity-scopes-shell). Failed to build (zesty/unity-scopes-shell). Successfully built (xenial/unity-scopes-api, zesty/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2133 Preparing packages
<Mirv> sil2100: o/
<sil2100> Mirv: o/
<sil2100> Mirv: welcome back!
<Mirv> sil2100: it took me the week to recover from the sprint anyway :)
<Mirv> now on Sunday evening I managed to fall asleep without taking something to the cough that developed mostly after the sprint
<Mirv> but good resting
<oSoMoN> trainguards: can you please do a source copy of oxide-qt 1.18.3-0ubuntu0.16.04.1~overlay1 from https://launchpad.net/~osomon/+archive/ubuntu/oxide to https://launchpad.net/~ci-train-ppa-service/+archive/2134 ?
<sil2100> oSoMoN: on it
<oSoMoN> sil2100, thanks!
<sil2100> oSoMoN: source copy done, yw!
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Failed to build (zesty/unity-scopes-shell). Successfully built (xenial/unity-scopes-api, zesty/unity-scopes-api). Uploading build (xenial/unity-scopes-shell)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2133 Currently building (vivid/content-hub, zesty/content-hub). Failed to build (xenial/content-hub)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Failed to build (zesty/unity-scopes-shell). Pending binary packages (xenial/unity-scopes-shell). Successfully built (xenial/unity-scopes-api, zesty/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2133 Failed to build (xenial/content-hub, zesty/content-hub). Pending binary packages (vivid/content-hub)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Failed to build (zesty/unity-scopes-shell). Successfully built (xenial/unity-scopes-api, xenial/unity-scopes-shell, zesty/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2134 Cancelling build
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2133 Currently building (zesty/content-hub). Failed to build (xenial/content-hub). Successfully built (vivid/content-hub)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2133 Successfully built
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2135 Pending binary packages
<rvr> kenvandine: Done
<kenvandine> rvr, thx!
<renato__> ubuntu-qa, could you make sure that this silo get reviewed: https://bileto.ubuntu.com/#/ticket/2008
<rvr> renato__: Hmm
<rvr> Seems fine, but there is no new trello card for it
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2033 Preparing packages
<renato__> rvr, it is not urgent, but looks like jibel script to get the cards is broke
<rvr> renato__: Seems so, I'll ping him tomorrow
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2135 Successfully built
<renato__> rvr, thanks
<rvr> renato__: I have created the card manually
<renato__> thanks
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Preparing packages
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2033 Destination version missing from changelog (zesty/ubuntu-download-manager). Pending binary packages (vivid/ubuntu-download-manager, xenial/ubuntu-download-manager)
<pmcgowan> tedg, mterry how we doin on 2129, need any help there?
<mterry> pmcgowan: I think we've been hitting various zesty ftbfs issues
<mterry> ted was more involved yesterday, might know more
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Currently building (xenial/unity-scopes-shell). Failed to build (zesty/unity-scopes-shell). Successfully built (xenial/unity-scopes-api, zesty/unity-scopes-api)
<sil2100> mterry: hey! Where can we find the snapcraft.yaml for the big unity8 snap in-progress?
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2033 Destination version missing from changelog (zesty/ubuntu-download-manager). Successfully built (vivid/ubuntu-download-manager, xenial/ubuntu-download-manager)
<tedg> pmcgowan: I think that generally it is okay-ish. There are somethings that failed to build, but we don't care.
<tedg> pmcgowan: The only one that mattered is url-dispatcher.
<tedg> pmcgowan: I think the current snap in the edge channel has the silo
<pmcgowan> tedg, cool, and can we land directly from that silo? I see a note not to
<tedg> pmcgowan: I'm not sure that makes sense, it'll probably have too much stuff in it.
<tedg> pmcgowan: Probably makes more sense to land in pieces in other silos.
<pmcgowan> tedg, whats the diff?
<pmcgowan> is it an issue for qa?
<tedg> pmcgowan: QA could test the invidual piece and make sure nothing is broken in that area vs. "test everything"
<mterry> sil2100: lp:unity8-session-snap
<tedg> I imagine that silo is gonna end up with, at some point, all the packages in the system.
<pmcgowan> heh
<pmcgowan> tedg, just as long as things start landing soonish
<pmcgowan> tedg, do you expect the leads t make their own silos from this?
<tedg> pmcgowan: I'd expect them to pull them in with other landings. Most are pretty small.
<tedg> pmcgowan: We can of course encourage if there's nothing landing soon.
<pmcgowan> tedg, ok will send out a heads up on it to approve mrs and land
<tedg> +1, thanks!
<sil2100> mterry: woo! Thanks
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Failed to build (zesty/unity-scopes-shell). Successfully built (xenial/unity-scopes-api, xenial/unity-scopes-shell, zesty/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Currently building (vivid/unity-scopes-api, vivid/unity-scopes-shell, xenial/unity-scopes-api, xenial/unity-scopes-shell, zesty/unity-scopes-api). Failed to build (zesty/unity-scopes-shell)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Failed to build (zesty/unity-scopes-shell). Pending binary packages (vivid/unity-scopes-api, vivid/unity-scopes-shell, zesty/unity-scopes-api). Successfully built (xenial/unity-scopes-api, xenial/unity-scopes-shell)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Failed to build (zesty/unity-scopes-shell). Successfully built (vivid/unity-scopes-api, vivid/unity-scopes-shell, xenial/unity-scopes-api, xenial/unity-scopes-shell, zesty/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2033 Preparing packages
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2033 Destination version missing from changelog (zesty/ubuntu-download-manager). Pending binary packages (vivid/ubuntu-download-manager, xenial/ubuntu-download-manager)
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Needs rebuild due to new commits (zesty/unity8). Successfully built (vivid/unity8, xenial/unity8)
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2033 Destination version missing from changelog (zesty/ubuntu-download-manager). Successfully built (vivid/ubuntu-download-manager, xenial/ubuntu-download-manager)
-queuebot:#ubuntu-ci-eng- robru, https://bileto.ubuntu.com/#/ticket/2136 Preparing packages
-queuebot:#ubuntu-ci-eng- robru, https://bileto.ubuntu.com/#/ticket/2136 zesty/phablet-tools: Failed to commit https://code.launchpad.net/~robru/phablet-tools/bileto-v2. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
<robru> heh
-queuebot:#ubuntu-ci-eng- robru, https://bileto.ubuntu.com/#/ticket/2136 Preparing packages
-queuebot:#ubuntu-ci-eng- robru, https://bileto.ubuntu.com/#/ticket/2136 Successfully built
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2137 Preparing packages
-queuebot:#ubuntu-ci-eng- robru, https://bileto.ubuntu.com/#/ticket/2136 Merging branches
<oSoMoN> sil2100, it looks like we have an issue with oxide-qt in the overlay PPA: the version in xenial-updates (1.18.3-0ubuntu0.16.04.1) depends on qtbase-abi-5-5-1, and itâs not installable on a system which has the stable-phone-overlay PPA because the overlay has Qt 5.6
<oSoMoN> sil2100, rebuilding oxide-qt against the overlay PPA and publishing it as 1.18.3-0ubuntu0.16.04.1~overlay1 wouldnât solve the issue, because the version in xenial-updates would still take precedence
<oSoMoN> Iâm not sure how to solve this, other than pushing a version > 1.18.3-0ubuntu0.16.04.1 in the overlay PPA
<oSoMoN> any suggestions?
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2137 Dependency wait
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Currently building (vivid/history-service, vivid/telephony-service, xenial/messaging-app, xenial/telephony-service, zesty/telephony-service). Failed to build (vivid/messaging-app, vivid/messaging-framework, xenial/history-service, xenial/messaging-framework, zesty/history-service, zesty/messaging-framework). Pending binary packages (vivid/dialer-app, vivid/telepathy-ofon
<oSoMoN> I guess 1.18.3-0ubuntu0.16.04.1+overlay1 would work, but not sure if that acceptable as a version naming scheme
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-app, vivid/messaging-framework, xenial/history-service, xenial/messaging-framework, zesty/history-service, zesty/messaging-framework, zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/history-service, vivid/telepathy-ofono, vivid/telephony-service, xenial/dialer-app, xenial/messaging-app, xenial/telepathy-ofono, xenial
<sil2100> oSoMoN: for touch images we use PPA pinning, so the overlay version *always* takes precedence over what's in the archive
<oSoMoN> sil2100, right, but what about desktops running xenial+overlay, or launchpad builders for silos? theyâre going to get the version from xenial-updates
<dobey> oSoMoN: 1.1~overlay1
<dobey> oSoMoN: ie you need to "bump to the next build number" and append ~foo
<dobey> oSoMoN: i tend to find appending .1 rather than increasing the single number value, to be a little safer, so generally what i suggest for such situations
<oSoMoN> dobey, thanks, that sounds reasonable
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2137 Preparing packages
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2134 Diff missing
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2137 Currently building (vivid/unity8, zesty/unity8). Failed to build (xenial/unity8)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Failed to build
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2137 Currently building (vivid/unity8). Failed to build (xenial/unity8). Uploading build (zesty/unity8)
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 Currently building (xenial/indicator-application, xenial/indicator-datetime, xenial/indicator-network, xenial/indicator-transfer, zesty/indicator-bluetooth, zesty/indicator-datetime, zesty/indicator-location, zesty/indicator-sound). Failed to build (xenial/indicator-sound, zesty/indicator-messages, zesty/indicator-network, zesty/indicator-power). Pending binary packages (xenial/indica
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Successfully built
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 Failed to build (xenial/indicator-network, xenial/indicator-sound, zesty/indicator-messages, zesty/indicator-network, zesty/indicator-power). Pending binary packages (xenial/indicator-datetime, zesty/indicator-datetime). Successfully built (xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-power, xenial/ind
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 Failed to build (xenial/indicator-network, xenial/indicator-sound, zesty/indicator-messages, zesty/indicator-network, zesty/indicator-power). Successfully built (xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-power, xenial/indicator-printers, xenial/indicator-session, xenial/in
<boiko> trainguards: can someone please copy the packages from https://launchpad.net/~boiko/+archive/ubuntu/tpqt/+packages to silo 1319?
<robru> boiko: on it
<boiko> robru: thanks!
<robru> boiko: you're welcome!
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Currently building (vivid/telepathy-qt, xenial/telepathy-qt, zesty/telepathy-qt). Failed to build (vivid/messaging-app, vivid/messaging-framework, xenial/history-service, xenial/messaging-framework, zesty/history-service, zesty/messaging-framework, zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/history-service, vivid/telepathy-ofono, vivid/telephon
#ubuntu-ci-eng 2016-11-03
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Currently building (xenial/telepathy-qt). Failed to build (vivid/messaging-app, vivid/messaging-framework, xenial/history-service, xenial/messaging-framework, zesty/history-service, zesty/messaging-framework, zesty/telepathy-qt, zesty/telephony-service). Pending binary packages (vivid/telepathy-qt). Successfully built (vivid/dialer-app, vivid/history-service, vivid/telep
<boiko> robru: can you please trigger a rebuild of telepathy-qt5/amd64/zesty on silo 1319? I want to check if a failure there is transient
<robru> boiko: sure
<boiko> robru: thanks!
<robru> boiko: you're welcome!
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Currently building (zesty/telepathy-qt). Diff missing (vivid/telepathy-qt, xenial/telepathy-qt). Failed to build (vivid/messaging-app, vivid/messaging-framework, xenial/history-service, xenial/messaging-framework, zesty/history-service, zesty/messaging-framework, zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/history-service, vivid/telepathy-ofono,
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Diff missing (vivid/telepathy-qt, xenial/telepathy-qt, zesty/telepathy-qt). Failed to build (vivid/messaging-app, vivid/messaging-framework, xenial/history-service, xenial/messaging-framework, zesty/history-service, zesty/messaging-framework, zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/history-service, vivid/telepathy-ofono, vivid/telephony-serv
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Currently building (xenial/messaging-framework, zesty/messaging-framework). Failed to build (vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, xenial/history-service, xenial/telepathy-ofono, xenial/telephony-service, zesty/history-service, zesty/telepathy-ofono). Pending binary packages (vivid/messaging-framework, vivid/telephony-service, zesty/telephony
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, xenial/history-service, xenial/telepathy-ofono, xenial/telephony-service, zesty/history-service, zesty/telepathy-ofono). Successfully built (vivid/dialer-app, vivid/messaging-framework, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/messaging-app, xenial/messaging-
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-app, xenial/history-service, xenial/telephony-service). Pending binary packages (vivid/telepathy-ofono, xenial/telepathy-ofono). Successfully built (vivid/dialer-app, vivid/history-service, vivid/messaging-framework, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/messaging-app, xenial/messaging-framework, xenial/te
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-app, xenial/history-service, xenial/telephony-service). Successfully built (vivid/dialer-app, vivid/history-service, vivid/messaging-framework, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/messaging-app, xenial/messaging-framework, xenial/telepathy-ofono, xenial/telepathy-qt, zesty/dialer-a
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Preparing packages
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Preparing packages
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Currently building (vivid/unity-scopes-shell, xenial/unity-scopes-shell). Failed to build (zesty/unity-scopes-shell). Successfully built (vivid/unity-scopes-api, xenial/unity-scopes-api, zesty/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Currently building (xenial/unity-scopes-shell). Failed to build (zesty/unity-scopes-shell). Successfully built (xenial/unity-scopes-api, zesty/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Failed to build (zesty/unity-scopes-shell). Successfully built (vivid/unity-scopes-api, vivid/unity-scopes-shell, xenial/unity-scopes-api, xenial/unity-scopes-shell, zesty/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Failed to build (zesty/unity-scopes-shell). Successfully built (xenial/unity-scopes-api, xenial/unity-scopes-shell, zesty/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Preparing packages
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Preparing packages
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Dependency wait (zesty/unity-scopes-shell). Pending binary packages (xenial/unity-scopes-shell). Successfully built (xenial/unity-scopes-api, zesty/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Dependency wait (zesty/unity-scopes-shell). Successfully built (xenial/unity-scopes-api, xenial/unity-scopes-shell, zesty/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2131 Needs rebuild due to new commits (zesty/account-plugins). Successfully built (vivid/account-plugins, xenial/account-plugins)
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Preparing packages
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Currently building (vivid/unity8). Dependency wait (zesty/unity8). Failed to build (xenial/unity8). Pending binary packages (vivid/qtubuntu, vivid/qtubuntu-gles, xenial/qtubuntu-gles, zesty/qtubuntu-gles). Ready to build (zesty/qmenumodel, zesty/ubuntu-touch-meta, zesty/unity8-desktop-session). Successfully built (vivid/qmenumodel, vivid/ubuntu-touch-meta, vivid/unity8-desktop-session, xenial/qm
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2131 Preparing packages
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Dependency wait (zesty/unity8). Failed to build (xenial/unity8). Ready to build (zesty/qmenumodel, zesty/ubuntu-touch-meta, zesty/unity8-desktop-session). Successfully built (vivid/qmenumodel, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-touch-meta, vivid/unity8, vivid/unity8-desktop-session, xenial/qmenumodel, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-touch-meta, xenial/unity8-d
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Preparing packages
<mzanetti> oSoMoN, hey, had to leave yesterday. what was the outcome with the oxide issue?
<oSoMoN> mzanetti, not solved yet as the version in the silo is < the version in xenial-security, but chrisccoulson is going to upload a new version to the silo shortly
<mzanetti> ok, great, thanks
<mzanetti> ltinkl, ^
<ltinkl> cool, ty
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2131 Successfully built
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Publishing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Currently building (vivid/unity8, zesty/unity8). Failed to build (xenial/unity8). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/qmenumodel, zesty/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2120 Abandoning ticket
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Currently building (vivid/unity8, zesty/unity8). Failed to build (xenial/unity8). Successfully built (vivid/indicator-power, xenial/indicator-power, zesty/indicator-power)
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Proposed pocket (zesty/indicator-network). Release pocket (xenial/indicator-network)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Failed to build (xenial/unity8). Pending binary packages (zesty/unity8). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, vivid/unity8, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/qmenumodel, zesty/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Destination version missing from changelog (zesty/indicator-network). Failed to build (xenial/ubuntu-app-launch, xenial/url-dispatcher, zesty/unity-scopes-shell, zesty/url-dispatcher). Successfully built (xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-network, xenial/indicator-power, 
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Failed to build (xenial/unity8). Successfully built (vivid/indicator-power, vivid/unity8, xenial/indicator-power, zesty/indicator-power, zesty/unity8)
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2139 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/2106 Failed to build (xenial/unity8). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, vivid/unity8, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/qmenumodel, zesty/ubuntu-settings-components, zesty/unity8)
<jgdx> robru, do I need to save a new ticket before building?
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2140 Preparing packages
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2140 zesty/ubuntu-system-settings: Failed to commit https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/displays-mir. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
<Elleo> trainguards: how can I sort out the missing changelog error on this ticket https://bileto.ubuntu.com/#/ticket/2033? I updated the MR to include the changelog that had been manually uploaded to zesty, but it still reports it as missing
<mardy> Mirv: hi! The autopkgtest results in https://bileto.ubuntu.com/#/ticket/2135 seem due to wrong package deps (temporary glitch?), is there a way to force re-running the tests?
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2140 Ready to build
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Preparing packages
<dobey> mardy: anyone with upload rights to the package in question, or the package which triggered the autopkgtests, can click the re-run button next to the failed tests on the excuses page, to re-run a test
<mardy> dobey: eh, not me unfortunately :(
<dobey> Elleo: 2016-11-03 13:14:55,174 ERROR Commit this to TRUNK, then rebuild!
<dobey> Elleo: so i'm pretty sure you need to get that changelog entry into trunk rather than in your MP
<Mirv> mardy: I have clicked the retries for the xenial failures now
<mardy> Mirv: thanks
<Mirv> mardy: http://autopkgtest.ubuntu.com/running#pkg-ubuntu-system-settings-online-accounts
<Elleo> dobey: ah, okay; thanks
<Mirv> Elleo: as dobey said, there's disparency between what trunk says and what archive says, even though they should be identical
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2033 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-app, xenial/telephony-service). Pending binary packages (zesty/history-service). Successfully built (vivid/dialer-app, vivid/history-service, vivid/messaging-framework, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/history-service, xenial/messaging-app, xenial/messaging-framework, xenial/tel
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Currently building (vivid/unity8, zesty/unity8). Failed to build (xenial/unity8). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/qmenumodel, zesty/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2140 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Failed to build (xenial/unity8). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, vivid/unity8, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/qmenumodel, zesty/ubuntu-settings-components, zesty/unity8)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2142 Abandoning ticket
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2033 Successfully built
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Currently building (vivid/unity8, zesty/unity8). Failed to build (xenial/unity8)
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-app, xenial/telephony-service). Successfully built (vivid/dialer-app, vivid/history-service, vivid/messaging-framework, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/history-service, xenial/messaging-app, xenial/messaging-framework, xenial/telepathy-ofono, xenial/telepathy-qt, zesty/dialer-a
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Failed to build (xenial/unity8). Pending binary packages (vivid/unity8, zesty/unity8)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2140 Failed to build (vivid/ubuntu-system-settings). Successfully built (vivid/qtmir, vivid/qtmir-gles, xenial/qtmir, xenial/qtmir-gles, xenial/ubuntu-system-settings, zesty/qtmir, zesty/qtmir-gles, zesty/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1886 This ticket must be migrated to zesty+xenial+vivid before it can be built
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1886 Preparing packages
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Failed to build (xenial/unity8). Successfully built (vivid/unity8, zesty/unity8)
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2139 Ready to build
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 Destination version missing from changelog (zesty/indicator-network). Successfully built (xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-network, xenial/indicator-power, xenial/indicator-printers, xenial/indicator-session, xenial/indicator-sound, xenial/indicator-transfer, zest
-queuebot:#ubuntu-ci-eng- koza, https://bileto.ubuntu.com/#/ticket/2004 Diff missing (yakkety/bluez). Pending binary packages (vivid/bluez). Successfully built (xenial/bluez)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1886 Failed to build (vivid/url-dispatcher, zesty/url-dispatcher). Pending binary packages (xenial/url-dispatcher)
<mardy> Mirv: mmm... it failed again with the same error, so maybe it's not a temporary glitch... however, I have no idea what's wrong: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-2135/xenial/amd64/u/ubuntu-system-settings-online-accounts/20161103_135545_942fa@/log.gz
-queuebot:#ubuntu-ci-eng- koza, https://bileto.ubuntu.com/#/ticket/2004 Diff missing (yakkety/bluez). Successfully built (vivid/bluez, xenial/bluez)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1886 Failed to build (vivid/url-dispatcher, zesty/url-dispatcher). Successfully built (xenial/url-dispatcher)
<dobey> mardy: it's the oxide issue
<mardy> dobey: thanks, I was not aware of such an issue; I should just ignore it, I guess?
<dobey> mardy: does your silo link to oxide?
<dobey> mardy: you might need to rebuild after oSoMoN's silo lands i guess
<mardy> dobey: ah ok, I'll try that
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1886 Successfully built
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2089 Updates pocket
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1886 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1886 Currently building (xenial/url-dispatcher). Failed to build (vivid/url-dispatcher). Successfully built (zesty/url-dispatcher)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Currently building (vivid/unity8, zesty/unity8). Failed to build (xenial/unity8). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/qmenumodel, zesty/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2139 Abandoning ticket
<dobey> robru: i think you need to get rid of the [SAVE] button next to "Add a comment" erhaps
<dobey> perhaps
<robru> dobey: why?
<dobey> robru: it's confusing. i edited MP urls, then hit save, and then got an error about malformed request
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Needs rebuild due to new commits (zesty/ubuntuone-credentials). Ready to build (xenial/unity-scope-click, zesty/unity-scope-click). Successfully built (xenial/ubuntuone-credentials)
<dobey> robru: so what does the save button actually do?
<robru> dobey: the save button submits your comment.
<robru> which is why it's next to the comment field there
<robru> dobey: the fields on the ticket autosave when the input loses focus
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Failed to build (xenial/unity8). Pending binary packages (vivid/unity8, zesty/unity8). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/qmenumodel, zesty/ubuntu-settings-components)
<dobey> robru: maybe only make it clickable if there is a comment to save, and/or change it "save comment" (or maybe make it more like LP's CSS for editing the summary line of a bug report)
<dobey> i saw jgdx ask a similar question this morning about saving a request before building
<robru> dobey: ok, just working on something else, will get to that in a sec
<dobey> robru: np. just offering my experience :)
<robru> dobey: thanks
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Failed to build (xenial/unity8). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, vivid/unity8, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/qmenumodel, zesty/ubuntu-settings-components, zesty/unity8)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 zesty/unity-scope-click: Failed to branch https://code.launchpad.net/~dobey/unity-scope-click/u1-no-delete
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 zesty/unity-scope-click: Failed to branch https://code.launchpad.net/~dobey/unity-scope-click/u1-no-delete
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2143 QA Signoff: N/A
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2143 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Successfully built
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Successfully built
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2143 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2124 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1886 Cancelled build (xenial/url-dispatcher). Successfully built (vivid/url-dispatcher, zesty/url-dispatcher)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Needs rebuild due to new commits (zesty/libertine). Successfully built (vivid/libertine, xenial/libertine)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/1886 Successfully built
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Preparing packages
-queuebot:#ubuntu-ci-eng- robru, https://bileto.ubuntu.com/#/ticket/2144 Abandoning ticket
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2124 Pending binary packages
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Pending binary packages (vivid/libertine, xenial/libertine). Successfully built (zesty/libertine)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2124 Successfully built
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2145 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2143 Publishing packages
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2143 Publish failed: Bad merges
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Pending binary packages (xenial/ubuntuone-credentials, zesty/ubuntuone-credentials). Successfully built (xenial/unity-scope-click, zesty/unity-scope-click)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Successfully built
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2143 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Successfully built
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Needs rebuild due to new commits (zesty/libertine). Successfully built (vivid/libertine, xenial/libertine)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Preparing packages
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2145 Pending binary packages
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2111 Proposed pocket
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Successfully built
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2143 Successfully built
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2145 Successfully built
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2077 Bad merges (yakkety/qtmir). Dependency wait (vivid/qtmir, vivid/qtmir-gles). Failed to build (vivid/miral, vivid/unity-api, xenial/qtmir, xenial/qtmir-gles, xenial/unity-api, yakkety/qtmir-gles, yakkety/unity-api). Needs rebuild due to new commits (yakkety/miral). Successfully built (xenial/miral)
<larryprice> trainguards: is this the right place to ask about possibly getting a new package in overlay?
<robru> larryprice: yes
<larryprice> robru, cool
<larryprice> robru, in particular i'm looking to use gir1.2-appstream-1.0
<larryprice> currently there is a separate package for the older implementation called gir1.2-appstream (no -1.0)
<larryprice> which is available in xenial, vivid
<robru> larryprice: use it where? on a phone?
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
<larryprice> robru, any device? we'd like to integrate it as part of libertine, which runs x apps in unity 8
<robru> larryprice: ok so what's the situation? the package in overlay is older than the one in xenial/vivid? or it's not in overlay at all?
<larryprice> robru, from what i can tell the >=0.9 series of the package is called gir1.2-appstream and is available on xenial,vivid,trusty
<larryprice> robru, what we're using is the 0.10 series of the package which seems to have been renamed to gir1.2-appstream-1.0 and is only available on yakkety,zesty
<robru> larryprice: ok so you're wanting to backport zesty to xenial & vivid then is what you're saying?
<larryprice> robru, yes we'd like to use the zesty version of the package on xenial+overlay/vivid+overlay
<robru> larryprice: ok, so what you're going to want to do is create your own PPA, then do the backport there. you'll also have to backport any dependencies. then once you have that built, make a ticket and I'll copy the packages from your ppa to the ticket ppa. then we submit to qa to make sure it doesn't explode the phone.
<robru> larryprice: wait, is canonical upstream of this project?
<larryprice> robru, you mean package i want to backport?
<robru> larryprice: yeah. nm it looks like we aren't.
<larryprice> nope
<robru> larryprice: anyway yeah prep the backport in your own ppa and then ping me once you got it building for xenial and vivid
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2137 Failed to build (xenial/unity8). Ready to build (vivid/unity8-desktop-session, xenial/unity8-desktop-session, zesty/unity8-desktop-session). Successfully built (vivid/unity8, zesty/unity8)
<larryprice> robru, willdo thanks for the tips!
<robru> larryprice: you're welcome!
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2124 Publishing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2124 Publish failed: Packaging diff requires ACK
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2134 Diff missing
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2124 Successfully built
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Destination version missing from changelog (zesty/indicator-network). Failed to build (xenial/ubuntu-app-launch, xenial/url-dispatcher, zesty/unity-scopes-shell, zesty/url-dispatcher). Ready to build (xenial/unity8-desktop-session, zesty/unity8-desktop-session). Successfully built (xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-location,
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 Successfully built
#ubuntu-ci-eng 2016-11-04
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2146 QA Signoff: N/A
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2146 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2146 zesty/unity: Failed to merge https://code.launchpad.net/~azzar1/unity/properly-handle-copy-dialog
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2146 Ready to build
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Currently building (vivid/unity8, zesty/unity8). Failed to build (xenial/unity8). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/qmenumodel, zesty/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1951 Ready to build
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Failed to build (xenial/unity8). Pending binary packages (vivid/unity8, zesty/unity8). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/qmenumodel, zesty/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Failed to build (xenial/unity8). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, vivid/unity8, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/qmenumodel, zesty/ubuntu-settings-components, zesty/unity8)
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2134 Generating diffs
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2134 Diff missing
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2134 Successfully built
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2135 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2135 Pending binary packages
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2137 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2135 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2124 Publishing packages
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2137 Failed to build (xenial/unity8). Pending binary packages (vivid/unity8). Successfully built (vivid/unity8-desktop-session, xenial/unity8-desktop-session, zesty/unity8, zesty/unity8-desktop-session)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2124 Proposed pocket
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2125 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- abeato, https://bileto.ubuntu.com/#/ticket/2147 Preparing packages
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2137 Failed to build (xenial/unity8). Successfully built (vivid/unity8, vivid/unity8-desktop-session, xenial/unity8-desktop-session, zesty/unity8, zesty/unity8-desktop-session)
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2125 Publishing packages
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Currently building (vivid/unity8, zesty/unity8). Failed to build (xenial/unity8)
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2125 Proposed pocket (zesty/online-accounts-api). Release pocket (vivid/online-accounts-api, xenial/online-accounts-api)
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Failed to build (xenial/unity8). Successfully built (vivid/unity8, zesty/unity8)
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2148 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
<sil2100> Mirv, bzoltan: I'm trying to see UITK migrating from zesty-proposed, but I see some regressions in ubuntu-settings-components tests
<bzoltan> sil2100:  ohh, that is not nice. Would you please show me the logs?
<sil2100> bzoltan: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-ui-toolkit <- some calendar tests seem to be failing, not sure if it's related to UITK but I don't see this failure in other packages
<sil2100> I remember trying to re-run at least once
<sil2100> Things like "qmltestrunner::Calendar::test_minMaxDate(Min=-1) The number of months should have changed"
<bzoltan> sil2100:  the newer Qt in Z did introduce asynchronousity and that makes the DatePicker component to act flaky with tests... that beast needs a complete redesign, which will be done. But not next week :(
<sil2100> bzoltan: you think some re-runs could work, or it's rather not possible?
<bzoltan> sil2100:  the question is what to do... the present UITK in Z has that component already and yes it is fishy there
<sil2100> We might request a one-time exception (I suppose?)
<bzoltan> sil2100:  sure, re-run can turn the icons green... but it does not solve the very existing problem.
<bzoltan> sil2100: So I am not hiding that it is a regression... caused by the newer Qt
<sil2100> For now I would try getting it through with some exception
<sil2100> And then ASAP try to redesign it so it's not that flaky
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2143 Publishing packages
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2143 Publish failed: Bad merges
<sil2100> bzoltan: would you be able to do this for the next UITK landing?
<sil2100> ChrisTownsend: hey! One merge needs top-approval there
<bzoltan> sil2100: If we do not plan to land UITK for 2-3 months
<sil2100> ChrisTownsend: already requested that on #ubuntu-unity
<ChrisTownsend> sil2100: Yep, got it:)
<ChrisTownsend> sil2100: I approved
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2143 Publishing packages
<ChrisTownsend> I thought I did yesterday, but obviously not.
<sil2100> bzoltan: wow, hm, ok so this will be a serious issue then
<sil2100> bzoltan: since basically this means that any package release that runs the u-s-c tests will fail and get blocked in -proposed
<ChrisTownsend> sil2100: BTW, getting autopkgtest failures in Xenial for https://bileto.ubuntu.com/#/ticket/2123.  Looks strange to me.  Is there a known problem?
<sil2100> bzoltan: we could include a hint for it being a known regression, but this basically disables all archs from the autopkgtests
<bzoltan> sil2100:  it is a serious issue and it is the top priority task for the UITK development.
<sil2100> ChrisTownsend: hm, didn't see those before
<sil2100> ChrisTownsend: let me try re-running one, since it seemed to time out
<ChrisTownsend> sil2100: Ok, thanks
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2134 QA Signoff: Ready
<sil2100> Mirv: hey! Would like to know your opinion on how to resolve the ubuntu-settings-components test regressions with the new Qt
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2137 Destination version missing from changelog (zesty/unity8-desktop-session). Failed to build (xenial/unity8). Successfully built (vivid/unity8, vivid/unity8-desktop-session, xenial/unity8-desktop-session, zesty/unity8)
-queuebot:#ubuntu-ci-eng- michi, jamesh, https://bileto.ubuntu.com/#/ticket/2149 Preparing packages
<sil2100> Mirv: it seems that due to the new Qt some UITK DatePicker component is now flaky, causing u-s-c tests to fail
<sil2100> Mirv: it's unreliable enough that this is blocking UITK from migrating - you think we should allow these regressions? I'm worried that we won't notice real regressions if we do
<sil2100> Mirv: a temporary hint will work one-time but all other landings that will run u-s-c tests will most likely fail
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2143 Proposed pocket (zesty/unity8-desktop-session). Release pocket (xenial/unity8-desktop-session)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 zesty/unity-api: Failed to commit https://code.launchpad.net/~mzanetti/unity-api/appdrawermodelinterface. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
<Mirv> sil2100: hmm. are you talking about vivid, xenial, zesty?
<Mirv> sil2100: the DatePicker has had problems in xenial since 5.6 so anything changed is related to fixing xenial. I wonder if it then could be some regressing on vivid side?
<Mirv> kalikiana_: ^ see sil2100's comments about date picker, although I think we'd want to see some logs first
<Mirv> sil2100: ah sorry missed your earlier ping, reading. so, zesty only? not xenial?
<sil2100> Zesty
<Mirv> sil2100: xenial + zesty == identical Qt versions
<Mirv> so weird if there's some difference
<sil2100> What I would want is to get UITK migrating from zesty-proposed finally ;)
<sil2100> And this was what bzoltan said the problem was
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Preparing packages
<Mirv> sil2100: I'm just slightly wondering it shouldn't be anything new compared to September or so in yakkety
<Mirv> but at least there's nothing in UITK related to datepicker, it'd seem, in that newest non-migrated release
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2016 This ticket must be migrated to zesty+xenial+vivid before it can be built
<mardy> Mirv: hi! How do I do the migration? ^
-queuebot:#ubuntu-ci-eng- michi, jamesh, https://bileto.ubuntu.com/#/ticket/2149 Dependency wait (zesty/storage-framework). Successfully built (vivid/storage-framework, xenial/storage-framework)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Ready to build
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Currently building (xenial/unity-scopes-shell). Failed to build (zesty/unity-scopes-shell). Successfully built (xenial/unity-scopes-api, zesty/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2016 Ready to build (vivid/online-accounts-api, xenial/online-accounts-api, yakkety/online-accounts-api). Successfully built (vivid/libaccounts-glib, vivid/libaccounts-qt, xenial/libaccounts-glib, xenial/libaccounts-qt, yakkety/libaccounts-glib, yakkety/libaccounts-qt)
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2016 Abandoning ticket
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2016 Preparing packages
<dobey> mardy: edit the target series on the MP
<mardy> dobey: thanks, I found it eventually; for some reason the field was empty, so I didn't even notice it
<dobey> oh, i guess you figured it out
<abeato> Mirv, hi, I have uploded the qtmultimedia packages to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2147/+packages , but got a build error on xenial
<abeato> Mirv, quite weird because the changes are the same as zesty, which build ust fine
<abeato> Mirv, error is :   Project ERROR: /<<PKGBUILDDIR>>/examples/multimedia/spectrum/3rdparty/fftreal/fftreal.pro installs target to unexpected location.
<abeato> Mirv, any hint?
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2130 Failed to build (zesty/unity-scopes-shell). Successfully built (xenial/unity-scopes-api, xenial/unity-scopes-shell, zesty/unity-scopes-api)
<oSoMoN> ubuntu-qa: https://bileto.ubuntu.com/#/ticket/2134 is ready for QA validation, can you please add a card to your trello board to track it?
<jibel> oSoMoN, it should be created automatically
<oSoMoN> jibel, ah, I thought the script that did it was broken and you were out until next week
<oSoMoN> jibel, good to have you back :)
<oSoMoN> Iâll wait for the card to be automatically created then
<jibel> oSoMoN, I fixed it last week, but chages didn't go to production
<rvr> oSoMoN: I'm sure that jibel is the one that creates all the cards, because when he's gone, there are no cards ;)
<kenvandine> jibel, is there a known issue with autopkgtests on xenial?
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2016 Dependency wait (vivid/libaccounts-qt, xenial/libaccounts-qt, zesty/libaccounts-qt). Failed to build (vivid/online-accounts-api, xenial/online-accounts-api, zesty/online-accounts-api). Successfully built (vivid/libaccounts-glib, xenial/libaccounts-glib, zesty/libaccounts-glib)
<kenvandine> content-hub,  ubuntu-system-settings-online-accounts and unity8 tests are failing consistently on xenial but passing on vivid and zesty
<jibel> kenvandine, nothing that I am aware of
<kenvandine> the content-hub tests fail because it times out after 3 hours
<kenvandine> and unity is test dependencies
<kenvandine> so i guess not related
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2151 Preparing packages
<Mirv> mardy: change the target series (like you did)
<mardy> Mirv: yep, I just didn't see the widget initially
<Mirv> abeato: hmm, well you'll want to upload the same 5.6 to xenial, since the target is xenial overlay (which has same Qt version as zesty until zesty gets 5.7 at some point)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
<Mirv> abeato: so it tries to build qtmultimedia 5.5 against Qt 5.6 from xenial overlay, failing
<dobey> kenvandine: it's probably the oxide issue
<Mirv> abeato: call the version for example 5.6.1-2ubuntu3~~xenialoverlay1~1 (two ~ so that it's when compared << the zesty version)
<Mirv> abeato: nice work with the uploads anyway!
<abeato> Mirv, oh, I see, I did not get the packet from xenial-overlay
<abeato> Mirv, :)
<dobey> oSoMoN: err, why did you do 1+overlay1 instead of 1.1~overlay1 there?
<dobey> kenvandine: ^^ when 2134 lands, the deps issues should be resolved i think
<kenvandine> dobey, cool, thx
<kenvandine> still need to figure out what's going on with content-hub tests
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2016 Dependency wait (vivid/libaccounts-qt, xenial/libaccounts-qt, zesty/libaccounts-qt). Failed to build (vivid/online-accounts-api, xenial/online-accounts-api). Needs rebuild due to new commits (zesty/online-accounts-api). Successfully built (vivid/libaccounts-glib, xenial/libaccounts-glib, zesty/libaccounts-glib)
<kenvandine> they fail for all arches on xenial
<kenvandine> but passes on vivid and zesty :/
 * kenvandine is running the tests locally now
<dobey> kenvandine: well it doesn't sound like they fail, but are just hanging?
<kenvandine> dobey, yeah, it hangs for 3 hours
<mardy> michi: hi! just saw your bug about s390x... I never understood what's the actual problem with that architecture :-)
<kenvandine> but they do get far enough that they are running them
<michi> mardy: well, we need to work with s390x.
<dobey> kenvandine: right. i wonder if they'd pass if you do all proprosed or whatever for them
<mardy> michi: I was building my packages on s390x as well, but then they were getting deleted
<michi> And it looks like there is no package of online accounts for s390x on zesty.
<michi> So we are suck
<michi> stuck
<michi> Deleted?
<dobey> there can't be online-accounts packages on s390x
<mardy> michi: so I was told that I should add a build dependency on upstart, in order to force my projects not to build on s390x
<michi> dobey: why not?
<michi> mardy: intersting, I didnât now about that trick...
<dobey> michi: because online-accounts requires things which are not available on s390x to function
<michi> Aha.
<michi> OK. Fine with me.
<michi> So, how do we stop silo builds for s390x for storage-framework?
<michi> Use the same trick mardy is using?
<mardy> michi: I *think* that it's not needed, since you are already depending on libonline-accounts-qt-dev, which does exist on s390x, but I might be wrong
<dobey> michi: which silo is this?
<michi> dobey: sec.
<michi> dobey: Links are here: https://bugs.launchpad.net/ubuntu/+source/online-accounts-api/+bug/1639224
<ubot5`> Ubuntu bug 1639224 in online-accounts-api (Ubuntu) "Cannot release because of missing zesty s390x build" [Undecided,New]
<dobey> michi: ah, so you don't need to add anything extra to s-f itself; we need to request an AA to delete the s390x storage-framework binaries from the zesty archive
<dobey> oh no
<dobey> err, yes actually; the manual upload from xnox confused me for a minute
<michi> dobey: I have no I dea what â request an AA to delete the s390x storage-framework binaries from the zesty archiveâ means :)
<dobey> michi: Archive Admin
<michi> Whatâs an AA?
<michi> A
<michi> ah
<michi> OK, thanks, Iâll do that on Monday
<dobey> usually found in #ubuntu-release
<dobey> yeah, i think some are in romania this week anyway
<mardy> Dracula hunting
<dobey> not sure who is around now
<dobey> michi: anyway, if you wait until monday, wgrant or raof are in/near your TZ
<michi> I donât know. Itâs Friday here, just before midnight, so Iâm about to call it a day.
<dobey> yeah
<michi> dobey: Thanks, Iâll follow up Monday.
<dobey> get some rest :)
<michi> Trying :)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2151 Ready to build
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Abandoning ticket
<dobey> robru: can you make Ctrl+Enter submit changes to fields on bileto? please :)
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-app, vivid/messaging-framework, xenial/messaging-framework, xenial/telephony-service, zesty/messaging-framework). Successfully built (vivid/dialer-app, vivid/history-service, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/history-service, xenial/messaging-app, xenial/telepathy-ofono, xenial/t
<oSoMoN> dobey, I didnât, Chris did
<dobey> ok
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Successfully built
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2016 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2127 Needs rebuild due to new commits (zesty/content-hub). Successfully built (vivid/content-hub, xenial/content-hub)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2016 Dependency wait (vivid/online-accounts-api, xenial/online-accounts-api, zesty/online-accounts-api). Successfully built (vivid/libaccounts-glib, vivid/libaccounts-qt, xenial/libaccounts-glib, xenial/libaccounts-qt, zesty/libaccounts-glib, zesty/libaccounts-qt)
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2016 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-app, vivid/messaging-framework, xenial/messaging-framework, xenial/telephony-service, zesty/messaging-framework). Pending binary packages (xenial/messaging-app, zesty/messaging-app). Successfully built (vivid/dialer-app, vivid/history-service, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/hi
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Currently building (xenial/unity-api, zesty/unity-api). Failed to build (vivid/unity8, xenial/unity8, zesty/unity8). Uploading build (vivid/unity-api)
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2016 Failed to build (vivid/online-accounts-api, xenial/online-accounts-api, zesty/online-accounts-api). Successfully built (vivid/libaccounts-glib, vivid/libaccounts-qt, xenial/libaccounts-glib, xenial/libaccounts-qt, zesty/libaccounts-glib, zesty/libaccounts-qt)
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-app, vivid/messaging-framework, xenial/messaging-framework, xenial/telephony-service, zesty/messaging-framework). Successfully built (vivid/dialer-app, vivid/history-service, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/history-service, xenial/messaging-app, xenial/telepathy-ofono, xenial/t
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Failed to build (vivid/unity8, xenial/unity8, zesty/unity8). Successfully built (vivid/unity-api, xenial/unity-api, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 QA Signoff: Required
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 Preparing packages
<Saviq> jibel, any idea why https://bileto.ubuntu.com/#/ticket/2134 isn't under trello's radar? it's blocking us on x+o :/
<jibel> Saviq, no idea. I'll have a lok
<jibel> +o
<jibel> Saviq, oSoMoN it's on the board now. the bot works better when its cron job is enabled
<jibel> sorry about that
<Saviq> lol :)
<oSoMoN> :)
<oSoMoN> thanks jibel
<kenvandine> jibel, the autopkgtests run under a chroot right?
<kenvandine> jibel, anything different about how the tests are run for xenial vs vivid or zesty?
<kenvandine> jibel, i think the apparmor profiles aren't being loaded for xenial tests
<jibel> kenvandine, I have no idea, the infra evolved a lot since I last touched it. pitti is your guy
<kenvandine> ok
<kenvandine> i'll talk to pitti on monday
<sil2100> Mirv: so, continuuing on the UITK thingy, you think we should just hint it in for now?
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 Ready to build (vivid/indicator-network). Successfully built (vivid/indicator-application, vivid/indicator-bluetooth, vivid/indicator-location, vivid/indicator-messages, vivid/indicator-power, vivid/indicator-printers, vivid/indicator-session, vivid/indicator-sound, vivid/indicator-transfer, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/in
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Failed to build (vivid/unity8, xenial/unity8). Needs rebuild due to new commits (zesty/unity8). Successfully built (vivid/unity-api, xenial/unity-api, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 Ready to build (vivid/indicator-network). Successfully built (vivid/indicator-application, vivid/indicator-bluetooth, vivid/indicator-datetime, vivid/indicator-location, vivid/indicator-messages, vivid/indicator-power, vivid/indicator-printers, vivid/indicator-session, vivid/indicator-sound, vivid/indicator-transfer, xenial/indicator-application, xenial/indicator-bluetooth, xenial/ind
<dobey> kenvandine: no, the autopkgtests get run the same way on all versions of ubuntu
<dobey> kenvandine: i think they are run on a vm, not a chroot (or maybe a chroot on a vm, not 100% sure about that)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2153 Preparing packages
<kenvandine> dobey, they apparmor profiles aren't being loaded on the xenial runs
<kenvandine> still looking into why
<tyhicks> kenvandine: there have been some recent changes to how apparmor profiles are loaded inside of lxd containers on xenial
<kenvandine> tyhicks, oh...
<kenvandine> only xenial though?
<kenvandine> tyhicks, i'm only seeing the issue when running the autopkgtests for xenial
<tyhicks> kenvandine: well, xenial was recently made to act the same way as yakety
<kenvandine> vivid and zesty are fine
<dobey> kenvandine: what silo?
<kenvandine> dobey, https://bileto.ubuntu.com/#/ticket/2123
<kenvandine> it was happening the week we were in the hague too
<kenvandine> dobey, note that silo has 2 issues
<kenvandine> the first is aa-check test fails
<dobey> well there isn't much in the artifacts there
<dobey> really need syslog i guess
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2155 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2155 zesty/miral: Failed to branch https://code.launchpad.net/~alan-griffiths/miral/0.4
<robru> dobey: it submits the field when the input loses focus (clicking to close the field isn't actually necessary). You want ctrl+enter to just close the field?
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2156 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2155 Preparing packages
<dobey> robru: actually it seems i have to click the pencil again, not just click outside; but yes, i would like to be able to do it directly from the keyboard in the same way i do in all the other web sites i use
<robru> dobey: clicking the pencil only makes the field go away. The change is submitted when focus is lost. Post attention to the spinner, it appears just by clicking or tabbing out field. I wanted to make the field go away as well when focus is lost but for some reason this made the form impossible to paste into
<robru> dobey: anyway I'll look into ctrl enter, I'm not familiar with keyboard bindings in js though, no idea what that'll entail
<robru> dobey: what I'm saying is you can hit tab and it will submit your change, it just doesn't close the field
<dobey> robru: ok. so i guess it "works" but it feels like it doesn't because the editable is still there.
<robru> dobey: it's not clear to me why pasting fires a blur event on the field, that was a real kick in the teeth when i was developing it. Otherwise I'd close the field on blur and you could just tab out
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2077 Abandoning ticket
<dobey> robru: i'd avoid trying to be overly clever with the focus events; doing it more like LP and having Ctrl+Enter would be best i think
<robru> dobey: ok I'm just having breakfast, I'll get to that shortly
<dobey> robru: ie when i edit the description on a bug/MP on LP, it shows x and checkmark icons for cancel/save
<dobey> robru: no worries
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 Currently building (vivid/indicator-datetime, vivid/indicator-sound, xenial/indicator-datetime, zesty/indicator-datetime). Failed to build (zesty/indicator-sound). Pending binary packages (vivid/indicator-application, vivid/indicator-messages, vivid/indicator-power, vivid/indicator-printers, vivid/indicator-session, vivid/indicator-transfer, xenial/indicator-application, xenial/indica
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2154 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2155 Successfully built
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2156 Successfully built
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 Failed to build (zesty/indicator-sound). Ready to build (vivid/indicator-network). Successfully built (vivid/indicator-application, vivid/indicator-bluetooth, vivid/indicator-datetime, vivid/indicator-location, vivid/indicator-messages, vivid/indicator-power, vivid/indicator-printers, vivid/indicator-session, vivid/indicator-sound, vivid/indicator-transfer, xenial/indicator-applicatio
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2143 Release pocket
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2124 Release pocket
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2134 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Preparing packages
<Trevinho> trainguards if anyone can publish this... https://bileto.ubuntu.com/#/ticket/2134 it would fix many u8 build failures
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Preparing packages
<dobey> needs a coredev
<dobey> kenvandine: ^^ :)
<robru> Yeah
<Trevinho> kenvandine: and also https://bileto.ubuntu.com/#/ticket/2081 since you're there :-)
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2137 Failed to build (xenial/unity8). Needs rebuild due to new commits (zesty/unity8-desktop-session). Successfully built (vivid/unity8, vivid/unity8-desktop-session, xenial/unity8-desktop-session, zesty/unity8)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Publishing packages
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2134 Publishing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Currently building (vivid/unity8, zesty/unity8). Destination version missing from changelog (zesty/qmenumodel). Failed to build (xenial/unity8). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 Preparing packages
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2134 Release pocket
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2157 Preparing packages
-queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/2112 Destination version missing from changelog (zesty/unity8). Successfully built (vivid/unity-api, vivid/unity8, xenial/unity-api, xenial/unity8, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Currently building (vivid/unity8, zesty/unity8). Failed to build (xenial/unity8). Successfully built (vivid/indicator-power, xenial/indicator-power, zesty/indicator-power)
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Destination version missing from changelog (zesty/unity8). Failed to build (xenial/unity8). Successfully built (vivid/unity8)
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2137 Destination version missing from changelog (zesty/unity8). Failed to build (xenial/unity8). Needs rebuild due to new commits (zesty/unity8-desktop-session). Successfully built (vivid/unity8, vivid/unity8-desktop-session, xenial/unity8-desktop-session)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Proposed pocket (zesty/qmenumodel, zesty/unity8). Release pocket (vivid/qmenumodel, vivid/unity8, xenial/qmenumodel, xenial/unity8)
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 Currently building (vivid/indicator-application, vivid/indicator-bluetooth, vivid/indicator-datetime, vivid/indicator-location, vivid/indicator-power, vivid/indicator-printers, vivid/indicator-session, vivid/indicator-transfer, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-pow
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Destination version missing from changelog (zesty/qmenumodel, zesty/unity8). Failed to build (xenial/unity8). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, vivid/unity8, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Currently building (vivid/unity8, zesty/unity8). Failed to build (xenial/unity8). Needs rebuild due to new commits (zesty/qmenumodel). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2153 Pending binary packages (zesty/content-hub). Successfully built (vivid/content-hub, xenial/content-hub)
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Destination version missing from changelog (zesty/indicator-network, zesty/unity8). Failed to build (xenial/ubuntu-app-launch, xenial/url-dispatcher, zesty/unity-scopes-shell, zesty/url-dispatcher). Ready to build (xenial/unity8-desktop-session, zesty/unity8-desktop-session). Successfully built (xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indic
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Failed to build (xenial/unity8). Pending binary packages (vivid/unity8, zesty/unity8). Successfully built (vivid/indicator-power, xenial/indicator-power, zesty/indicator-power)
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2154 Diff missing (xenial/maliit-framework, xenial/presage, zesty/maliit-framework, zesty/presage). Pending binary packages (vivid/maliit-framework, vivid/presage). Successfully built (vivid/ubuntu-keyboard, xenial/ubuntu-keyboard, zesty/ubuntu-keyboard)
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 Failed to build (xenial/indicator-session, zesty/indicator-power). Pending binary packages (vivid/indicator-application, vivid/indicator-bluetooth, vivid/indicator-location, vivid/indicator-messages, vivid/indicator-power, vivid/indicator-printers, vivid/indicator-session, vivid/indicator-sound, vivid/indicator-transfer, xenial/indicator-application, xenial/indicator-datetime, xenial/
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Destination version missing from changelog (zesty/unity8). Failed to build (xenial/unity8). Needs rebuild due to new commits (zesty/qmenumodel). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, vivid/unity8, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2153 Successfully built
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Destination version missing from changelog (zesty/unity8). Failed to build (xenial/unity8). Successfully built (vivid/indicator-power, vivid/unity8, xenial/indicator-power, zesty/indicator-power)
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2154 Diff missing (vivid/maliit-framework, vivid/presage, xenial/maliit-framework, xenial/presage, zesty/maliit-framework, zesty/presage). Successfully built (vivid/ubuntu-keyboard, xenial/ubuntu-keyboard, zesty/ubuntu-keyboard)
<ChrisTownsend> #ubuntu-qa: Hi!  Would it be possible to get an exception for the failing Xenial autopkgtests for https://bileto.ubuntu.com/#/ticket/2123 ?  The content-hub's url-dispatcher test is timing out for some reason and it's unrelated to our Libertine landing.
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2140 Failed to build (vivid/ubuntu-system-settings). Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (vivid/qtmir, vivid/qtmir-gles, xenial/qtmir, xenial/qtmir-gles, xenial/ubuntu-system-settings, zesty/qtmir, zesty/qtmir-gles)
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-framework, xenial/messaging-framework, xenial/telephony-service, zesty/messaging-framework). Successfully built (vivid/dialer-app, vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/history-service, xenial/messaging-app, xenial/telepathy-ofono, xenial/t
-queuebot:#ubuntu-ci-eng- charles mterry ted, https://bileto.ubuntu.com/#/ticket/2138 Failed to build (xenial/indicator-session, zesty/indicator-power). Ready to build (vivid/indicator-network). Successfully built (vivid/indicator-application, vivid/indicator-bluetooth, vivid/indicator-datetime, vivid/indicator-location, vivid/indicator-messages, vivid/indicator-power, vivid/indicator-printers, vivid/indicator-session, vivid/indicator-sound, vivid/indicator-transfer, x
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2100 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2138 Preparing packages
<Elleo> 4/9
<Elleo> oops
<robru> dobey: ok I've updated it to save the field when you click ctrl+enter, please try it out
<dobey> yay
<dobey> neato :)
<robru> eh, I made a bug that broke ticket creation, fix for that will be rolled out in 10 mins
<dobey> hoepfully xenial autopkgtests will work now
<dobey> and hopefully i don't have to wait an hour to found out if they didn't
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2157 Pending binary packages (zesty/compiz). Successfully built (zesty/metacity)
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2138 Ready to build (vivid/indicator-network). Successfully built (vivid/indicator-application, vivid/indicator-bluetooth, vivid/indicator-datetime, vivid/indicator-location, vivid/indicator-messages, vivid/indicator-power, vivid/indicator-printers, vivid/indicator-session, vivid/indicator-sound, vivid/indicator-transfer, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-date
<dobey> bah
<dobey> why are autopkgtests still failing so hard
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Preparing packages
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2157 Successfully built
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Preparing packages
<robru> dobey: if you're in a hurry for autopkgtest results, always consult http://autopkgtest.ubuntu.com/running directly, as there is a delay polling the info into bileto
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2127 Preparing packages
<dobey> robru: yeah, except that's not helpful if what you're looking for isn't on it :)
<dobey> robru: once things are run, it's impossible to find the results until britney runs
<robru> dobey: oh really? htm
<robru> hr
<robru> hrm
<dobey> though this failure might actually be my fault
<dobey> the log was a bit confusing with the oxide stuff though
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2157 Publishing packages
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2157 Publish failed: Bad merges (zesty/compiz). Packaging diff requires ACK (zesty/metacity)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2122 Successfully built
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2157 Merging branches
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Destination version missing from changelog (zesty/unity8). Successfully built (vivid/unity8, xenial/unity8)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2153 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2148 Diff missing
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/1896 Abandoning ticket
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2128 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-framework, xenial/messaging-framework, zesty/messaging-framework). Successfully built (vivid/dialer-app, vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/history-service, xenial/messaging-app, xenial/telepathy-ofono, xenial/telepathy-qt, xenial/teleph
#ubuntu-ci-eng 2016-11-05
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
<boiko> trainguards: can someone please trigger a rebuild of telephony-service/vivid/armhf on silo 1319?
<robru> boiko: on it
<boiko> robru: thanks!
<robru> boiko: you're welcome
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Currently building (vivid/telephony-service). Failed to build (vivid/messaging-framework, xenial/messaging-framework, zesty/messaging-framework). Needs rebuild due to new commits (zesty/dialer-app, zesty/messaging-app). Pending binary packages (zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/history-service, vivid/messaging-app, vivid/telepathy-ofon
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-framework, xenial/messaging-framework, zesty/messaging-framework). Pending binary packages (vivid/dialer-app, vivid/messaging-app, vivid/telephony-service, xenial/dialer-app, xenial/messaging-app, zesty/dialer-app, zesty/messaging-app). Successfully built (vivid/history-service, vivid/telepathy-ofono, vivid/telepathy-qt, xenial/history-se
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-framework, xenial/messaging-framework, zesty/messaging-framework). Successfully built (vivid/dialer-app, vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/history-service, xenial/messaging-app, xenial/telepathy-ofono, xenial/telepathy-qt, xenial/teleph
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Release pocket
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Destination version missing from changelog (zesty/unity8). Failed to build (xenial/ubuntu-app-launch, xenial/url-dispatcher, zesty/unity-scopes-shell, zesty/url-dispatcher). Needs rebuild due to new commits (zesty/indicator-network). Ready to build (xenial/unity8-desktop-session, zesty/unity8-desktop-session). Successfully built (xenial/indicator-application, xenial/indicator-bluetooth, xeni
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Needs rebuild due to new commits (zesty/indicator-network). Successfully built (vivid/gmenuharness, vivid/indicator-network, xenial/gmenuharness, xenial/indicator-network, zesty/gmenuharness)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Preparing packages
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/1632 Abandoning ticket
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/1874 Abandoning ticket
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Currently building (vivid/unity-scopes-shell, xenial/unity-scopes-shell). Failed to build (zesty/unity-scopes-shell). Successfully built (vivid/unity-scopes-api, xenial/unity-scopes-api, zesty/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Failed to build (zesty/unity-scopes-shell). Successfully built (vivid/unity-scopes-api, vivid/unity-scopes-shell, xenial/unity-scopes-api, xenial/unity-scopes-shell, zesty/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- abeato, https://bileto.ubuntu.com/#/ticket/2147 Generating diffs
-queuebot:#ubuntu-ci-eng- abeato, https://bileto.ubuntu.com/#/ticket/2147 Diff missing (vivid/gst-plugins-bad0.10, vivid/qtmultimedia-opensource-src, xenial/qtmultimedia-opensource-src, zesty/qtmultimedia-opensource-src). Ready to build (vivid/qtmultimedia-opensource-src-gles, xenial/gst-plugins-bad0.10, xenial/qtmultimedia-opensource-src-gles, zesty/gst-plugins-bad0.10, zesty/qtmultimedia-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- abeato, https://bileto.ubuntu.com/#/ticket/2147 Ready to build (vivid/qtmultimedia-opensource-src-gles, xenial/gst-plugins-bad0.10, xenial/qtmultimedia-opensource-src-gles, zesty/gst-plugins-bad0.10, zesty/qtmultimedia-opensource-src-gles). Successfully built (vivid/gst-plugins-bad0.10, vivid/qtmultimedia-opensource-src, xenial/qtmultimedia-opensource-src, zesty/qtmultimedia-opensource-src)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Proposed pocket (zesty/unity8). Release pocket (vivid/qmenumodel, vivid/unity8, xenial/qmenumodel, xenial/unity8, zesty/qmenumodel)
#ubuntu-ci-eng 2016-11-06
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2125 Release pocket
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2016 Failed to build (vivid/online-accounts-api, xenial/online-accounts-api). Needs rebuild due to new commits (zesty/online-accounts-api). Successfully built (vivid/libaccounts-glib, vivid/libaccounts-qt, xenial/libaccounts-glib, xenial/libaccounts-qt, zesty/libaccounts-glib, zesty/libaccounts-qt)
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2148 Generating diffs
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2148 Diff missing
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2148 Successfully built
-queuebot:#ubuntu-ci-eng- michi, jamesh, https://bileto.ubuntu.com/#/ticket/2149 Preparing packages
-queuebot:#ubuntu-ci-eng- michi, jamesh, https://bileto.ubuntu.com/#/ticket/2149 Dependency wait (zesty/storage-framework). Failed to build (zesty/mcloud). Successfully built (vivid/mcloud, vivid/storage-framework, xenial/mcloud, xenial/storage-framework)
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2158 QA Signoff: N/A
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2158 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2158 Failed to build
#ubuntu-ci-eng 2017-10-30
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3017 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/3017 Ready to build
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3006 Ready to build
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3006 Pending binary packages
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3006 Diff missing (artful/openvswitch). Ready to build (artful/ceph)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2954 Updates pocket
<alan_g> Hi, is it possible to land ticket 3013?
<alan_g> xnox: is it possible to land ticket 3013 at the moment?
<xnox> alan_g, to bionic?
<alan_g> Ideally to both artful and bionic
<alan_g> But I'm not sure what's actually possible currently
<xnox> alan_g, we will not do that from the same ticket. Why do you care about both?
<xnox> alan_g, so bionic is free for all.
<alan_g> bionic would be good
<alan_g> But bileto didn't give me that option
<xnox> alan_g, artful would be an SRU, and requires the same SRU process as everything else i.e. just targetted fixes documented one by one.... or whatever special exceptional process that mir may have (if it does have sru exception)
<xnox> alan_g, i believe i can upload that into bionic for you.
<alan_g> Sure.
<xnox> alan_g, would you want to stop using bileto stuff? and just create merge prosal, that sponsors can sponsor for you? i'd rather just take your MP and upload that as 0.28.1, or as 0.28.1-1 like a regular package.
<xnox> alan_g, for example, was 0.28.1 tarball published on launchpad, and do you want to use that pristine tarball to upload package into ubuntu?
<alan_g> xnox: I'll follow any process that works. But bileto creates a nice ppa for testing.
<xnox> ack
<xnox> alan_g, i will upload that, direct to bionic, later today. No idea what bileto will think of it. And will do a merge propsal to manually sync-up / fix up lp:mir/ubuntu branch. But let me double check with bileto devs queickly
<alan_g> The latest tarball is 0.28.0 pending the 0.28.1 MP merging
<xnox> right
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/3013 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/3013 Successfully built
#ubuntu-ci-eng 2017-10-31
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/3013 Publishing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/3013 Publish failed: Packaging diff requires ACK
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/3013 Publishing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/3013 Proposed pocket
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3002 Needs rebuild due to new commits
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/3013 Release pocket
<xnox> alan_g, so i believe mir is now in.
<xnox> alan_g, anything else needs doing? finalize the ticket?
<alan_g> xnox: that's great. Thanks
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2841 Needs rebuild due to new commits (xenial/unity-control-center). Successfully built (xenial/compiz, xenial/nux, xenial/unity)
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3014 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3014 Successfully built
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3014 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3019 Preparing packages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3014 Needs rebuild due to burned version number (xenial/ubiquity). Proposed pocket (xenial/network-manager-applet)
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3019 Failed to build
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3019 Failed to build
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3006 Diff missing (artful/openvswitch). Pending binary packages (artful/ceph)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3006 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3005 Diff missing (zesty/percona-xtradb-cluster-5.6). Proposed pocket (xenial/percona-xtradb-cluster-5.6). Ready to build (xenial/percona-xtradb-cluster-5.5, yakkety/percona-xtradb-cluster-5.5, yakkety/percona-xtradb-cluster-5.6, zesty/percona-xtradb-cluster-5.5)
#ubuntu-ci-eng 2017-11-01
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3020 Preparing packages
#ubuntu-ci-eng 2017-11-02
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3022 Preparing packages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3022 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3022 Proposed pocket (bionic/camlidl, bionic/findlib, bionic/ocaml). Successfully built (bionic/hivex, bionic/plplot)
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3022 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3022 Publishing packages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3022 Proposed pocket
-queuebot:#ubuntu-ci-eng- Saviq, https://bileto.ubuntu.com/#/ticket/2986 Dependency wait (bionic/qtubuntu-gles). Failed to build (bionic/qtubuntu)
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3019 Failed to build
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3019 Successfully built
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3019 Publishing packages
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3019 Proposed pocket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3003 Diff missing (xenial/dnsmasq). Needs rebuild due to higher version at destination (zesty/dnsmasq). Ready to build (yakkety/dnsmasq)
#ubuntu-ci-eng 2017-11-03
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3023 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/3024 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/3024 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3023 Diff missing
-queuebot:#ubuntu-ci-eng- Saviq, https://bileto.ubuntu.com/#/ticket/2986 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/3016 Abandoning ticket
-queuebot:#ubuntu-ci-eng- Saviq, https://bileto.ubuntu.com/#/ticket/2986 Dependency wait (bionic/qtubuntu-gles). Pending binary packages (bionic/qtubuntu)
-queuebot:#ubuntu-ci-eng- Saviq, https://bileto.ubuntu.com/#/ticket/2986 Dependency wait (bionic/qtubuntu-gles). Successfully built (bionic/qtubuntu)
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2981 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2981 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2981 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2981 QA Signoff:
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2981 Pending binary packages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2981 Successfully built
