#ubuntu-ci-eng 2013-10-21
<jibel> cjwatson, I declared trusty but I need a cloud image of trusty to build the base testing environment. I'll ping smoser
<jibel> hm, and also update distro-data on all the testing nodes in the lab so they know what is the devel release.
<jibel> ev, vila ^ could you check that servers in the lab are up to date?
<jibel> vila, you'll need to upgrade the machines used for destkop testing to trusty and probably the ones running raring to saucy for SRUs or split in 2 pools for raring/saucy otherwise SRUs on raring will have to be done manually
<jibel> vila, RT65382
<vila> jibel: ack, will raise the ticket during the standup and talk with fginther, doanac and plars
<ogra_> http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20131021.1/
<ogra_> welcome to trusty !
<didrocks> ogra_: \o/
<ogra_> and here is the system image :) http://system-image.ubuntu.com/trusty-proposed/mako/
<didrocks> ogra_: how will http://people.canonical.com/~ogra/touch-image-stats/ behave btw?
<didrocks> if we have a saucy and trusty image rebuild the same day?
<ogra_> will be crowded with the next build and fine agaiun with the one after
<ogra_> i have to do a special setup for saucy later today
<didrocks> the version of the ubuntu chroot are different?
<didrocks> ok
<ogra_> the paths all changed with the release
<ogra_> you mean for building ?
<didrocks> no, I think we need to be clear which version is shown
<ogra_> yeah it is always the release we build for which we use fro the chroot
<didrocks> ok, and we'll have a saucy/ dir?
<ogra_> we already do
<ogra_> http://system-image.ubuntu.com/
 * didrocks sees current/
<didrocks> ogra_: I'm speaking of http://people.canonical.com/~ogra/touch-image-stats/
<ogra_> we have saucy and trusty channels
<ogra_> yeah, that will get a saucy dir
<didrocks> great :)
<cjwatson> jibel: Huh, why can't you bootstrap it off the saucy image?
<jibel> cjwatson, that's what I did
<cjwatson> jibel: OK, I still see nothing at https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/ though
<jibel> cjwatson, autopkgtest for trusty is open, jobs that were queued are running. I'll create the views and file a ticket to do the same on the public instance
<cjwatson> jibel: OK, I have a feeling proposed-migration lost its records of them so I'm inclined to remove its state and let it all retrigger
<cjwatson> jibel: There should be a lot more than just mod-gearman listed in excuses and I don't see any records of it collecting any PASSes
 * cjwatson nukes the state dir
<jibel> cjwatson, you should see visp as FAIL and glib2.0 as PASS
<cjwatson> I do not, but sadly adt-britney loses results sometimes as previously explained
<jibel> that's the 2 I used for testing
<cjwatson> I don't trust it :(
<jibel> cjwatson, :( I'll spend some time on it again this week.
<cjwatson> Let's see if it does a better job this time round
<cjwatson> jibel: Do you think you could edit https://wiki.ubuntu.com/NewReleaseCycleProcess to explain what we need to do (or notify somebody to do) when setting up new series?
<cjwatson> This has become fairly critical infra so we should make sure it's up early
<jibel> cjwatson, sure, I'll update it. I added a specific document to the prject auto-package-testing too.
<cjwatson> Thanks
<cjwatson> Should be a batch of trusty jobs re-running now
<cjwatson> I'll keep an eye on p-m to try to ensure it doesn't lose them
<jibel> vila, retoaded I'm creating Trusty All and Autopkgtest views on jiufeng, I'll leave others to you.
<vila> jibel: please update the ticket you created so we can keep track of what is left to be done (and document the process)
<jibel> vila, that's different, I'll file another
<didrocks> vila: joining us?
<didrocks> ev: ?
<vila> didrocks: omw
<vila> didrocks: ev is at the cloud sprint
<jibel> vila, RT65387
<jibel> retoaded, ^
<asac> didrocks: vila: so in general i believe nothing should need to be done when we continue staying on devel-proposed ... except creating new jobs to track the OLDRELEASED-proposed
<asac> that should be our goal... maybe its already like that and we are just struck by lack of phones
<didrocks> asac: agreed with that goal
<vila> +1
<didrocks> we are far from it, but let's focus on it :)
<psivaa> didrocks: asac: ogra_: as per the build this morning. the jobs have not run yet. they are only triggered with changes to http://system-image.ubuntu.com/devel-proposed/mako/index.json
<psivaa> which has not changed yet today
<asac> psivaa: right. so if we had the channel moved on top ofd trusty-proposed it would have automatically happened
<ogra_> psivaa, as i said, thats still saucy
<asac> psivaa: however, why wasnt build 101 from devel-proposed picked up
<asac> i assume thats because we have all phones down?
<ogra_> because the phones are down ?
<asac> right. so in theory nothing is wrong :
<ogra_> would be my only explanation
<ogra_> phablet-flash ubuntu-system --channel trusty-proposed --no-backup -d maguro
 * ogra_ twiddles thumbs
<ogra_> yay, my first four apps are in the appstore !
<psivaa> ogra_: asac: phones are not down there, the jobs have not been triggered yet
<asac> psivaa: because 101 is too new?
<asac> psivaa: its 2-3 days old: http://system-image.ubuntu.com/devel-proposed/maguro/
<ogra_> 101 is from friday night iirc
<didrocks> asac: the jenkins job failed as told
<psivaa> ohh 101 is from friday? sorry looking at it now
<ogra_> the cdimage build ends up in a new dir ...
<ogra_> do you use anything from cdimage for the trigger ?
<ogra_> http://cdimage.ubuntu.com/ubuntu-touch/saucy/daily-preinstalled/
<ogra_> (note the saucy subdir)
<asac> afaik they use the index.json to trigger
<asac> (from system image channels)
<cjwatson> jibel: I wonder if the causes get lost on FAIL or something
<cjwatson> jibel: for instance the very most recent run has:
<cjwatson> lintian 2.5.19ubuntu1 FAIL lintian 2.5.19ubuntu1
<cjwatson> jibel: but I don't see lintian mentioned anywhere in excuses, not even as something triggered by another package
<cjwatson> jibel: (unfortunately I didn't catch this in time to stop p-m so you could investigate in place, but perhaps that's a hint)
<cjwatson> Though lintian actually first failed in the run starting at 08:37:03
<cjwatson> I mean p-m first recorded it as failing then
<jibel> cjwatson, yes, I noticed that on saucy but couldn't find the cause. I also noticed results on excuses changing from PASS to FAIL without obvious reason. but I didn't find how to recreate the case locally.
<jibel> cjwatson, I updated https://wiki.ubuntu.com/NewReleaseCycleProcess and added a link to the detailed documentation.
<cjwatson> Thanks
<cjwatson> ogra_: Any luck with image 1?
<psivaa> asac: ogra_: the reason for the smoke tests failing to run 101 is due to regressions in the way we now flash the devices.
<psivaa> there was a merge to not use utah for this and this is causing the issue
<ogra_> cjwatson, havent checked phonecalls yet ... and popey needs to test on mako
<ogra_> cjwatson, installs and runs though :)
<ogra_> popey, mind testing the trusty-proposed channel on your mako ?
<psivaa> doanac: ^ would you be able to take a look at this the issue is only in install-and-boot
<popey> ogra_: ooh, there's a new image?
<ogra_> popey, two :) onte trusty and one saucy
<popey> which one do you want testing?
<cjwatson> please do the trusty one first as this is blocking opening
<ogra_> popey, trusty-proposed please
<popey> kk
<ogra_> just a quick smoketest should do
<popey> the delay wont be my testing, it will be my current 3g connection
<popey> phablet-flash: error: argument : invalid choice: 'trusty-proposed' (choose from 'cdimage-touch', 'cdimage-legacy', 'ubuntu-system', 'community')
<popey> oh, typo
<popey>  2% [>                                      ] 8,183,808    368KB/s  eta 8m 13s
<popey> not bad on the M6
<ogra_> cjwatson, popey, asac, didrocks, trusty is good on maguro
<asac> ogra_: can you run unity8 ap?
<asac> :)
<didrocks> ogra_: sweet!
<asac> lol
<asac> ogra_: guess thats still not good on maguro
<asac> oh we have 101 http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/
<asac> install-and-boot isnt happy though
<asac> http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/101:20131018:20131015/4775/
 * asac assumes psivaa and vila are on that
<vila> asac: I'm on cu2d for trusty withe didrocks
<vila> psivaa: ^ you're on it ?
<psivaa> asac: as i posted above, there was a regression in the way we provision the devices. i will have to revert the changes that doanac made in order to make the jobs proceed
 * ogra_ notes that the maguro is really to slow for zombie apocalypse
<popey> i handed my 100 phone out at a conference over the weekend. took less than 5 mins for someone to crash it
<ogra_> yeah, we need to do more long term dogfooding
<ogra_> i wrote 11 webapps on the weekend ...
<ogra_> running like 5 of them at the same time makes everything go cracy
<ogra_> the backgrounded apps never save their state
<ogra_> and at times unity seems to get all confused and puts the wrong labels onto the wrong thumbnals etc
<ogra_> i had two crashes over the weekend where unity just restarted
<psivaa> asac: vila: running the jobs now for 101 saucy.. i'll let you  know the outcome
<popey> ogra_: trusty 1 looks good here on mako
<ogra_> great
<ogra_> cjwatson, go for it then
<asac> ogra_: successfully ran camera_app on #1
<asac> doing webbrowser_app now as well
<asac> didrocks: ^^
<asac> (on maguro)
<didrocks> great!
<asac> unity is unfortunately unhappy still, right?
<didrocks> asac: we'll need an iso though to plug trusty tests on desktpo
<asac> at least on maguro i would think so
<didrocks> desktop*
<asac> didrocks: did the last day regression fix make it in for unity AP?
<didrocks> cjwatson: I think that will take a while? (trying to find a backup solution)
<didrocks> asac: they did
<didrocks> ah
<didrocks> unity8
<didrocks> not 7
<didrocks> no, it's not in
<didrocks> as we didn't do any SRU-related work
<asac> right. thinking about trusty. assume would come in once we start landing stuff, right?
<didrocks> asac: there are 3 things to do/ensure:
<didrocks> - daily-build ppa can build trusty
<didrocks> - config changed by Mirv
<didrocks> - otto being able to run tests on trusty (or I need to find a backup solution) -> meaning, an iso available
<vila> - views updated ob jnekins (may be minor may be scripted already)
<vila> *on jenkins
<cjwatson> didrocks: we can probably do you a desktop build
<asac> didrocks: so we depend on a desktop iso? or server?
<didrocks> cjwatson: oh, that would be excellent :)
<didrocks> asac: desktop
<didrocks> cjwatson: and ppas can build trusty already?
<cjwatson> didrocks: running
<didrocks> thanks cjwatson :)
<cjwatson> didrocks: er I'd have to check
<didrocks> ok
<cjwatson> didrocks: you could try it :)
<didrocks> yeah, let's mess with it :)
<didrocks> will keep you posted
 * cjwatson goes to open trusty
<cjohnston> asac: are the automated tests already running or are your results from manual testing?
<cjwatson> (getting coffee first so this is your last opportunity to object)
<asac> cjohnston: mine are from manual, because the automatic ones seem to not run
<cjohnston> asac: they don't look to be setup.. let me see if I can figure that out
<asac> cjohnston: check with psivaa and vila and didrocks if there was something started to fix this already
<didrocks> cjohnston: enjoy :)
<asac> cjohnston: so from what i uinderstand touch_mir should be pulling devel-proposed channel
<asac> cjohnston: that channel wasnt moved over, so we need to wait till stgraber gets up, then our touch_mir jobs should pick the right thing up
<didrocks> [PPA ubuntu-unity-daily-build] [ubuntu/trusty] bamf 0.5.1+13.10.20131011-0ubuntu1trusty1 (Accepted) -> sounds good :)
<cjohnston> ok
<asac> cjohnston: build the build number will go back to 1, so maybe check what happens on dashboard then
<cjwatson> didrocks: good
<didrocks> cjwatson: enjoy your coffee :)
<psivaa> cjohnston: fyi, saucy tests on touch devices are running but we have not set anything up for trusty yet
<cjohnston> psivaa: cool.. looks like there are still MPs that need to land for trusty tests to work
<psivaa> cjohnston: yea they are still in the review stage
<ogra_> asac, Saviq , unity8 still fails for me, http://paste.ubuntu.com/6276025/ is what i se printed in the unity8 log if the tests try to start
<Saviq> ogra_, stale socket
<ogra_> yeah
<ogra_> i thought we had fixed that
<Saviq> ogra_, no, we amended it
<ogra_> the test properly shuts down the shell
<Saviq> ogra_, but if unity8 crashes - mir never removes the socket
<Saviq> ogra_, it should only ever happen on unity8 crash now
<ogra_> well, thats after a proper shutdown i think
 * ogra_ reboots again to watch if there is a crash happening 
<Saviq> ogra_, hmm, can you rm /run/user/32011/mir_socket and clear /var/crash - and see if indeed you get the stale socket without unity8 crashing?
<Saviq> or that
<Saviq> ogra_, we should probably clear the socket in pre-start unity8
<ogra_> root@ubuntu-phablet:/# ls /var/crash/
<ogra_> _usr_bin_unity8.32011.crash
<ogra_> wow
<ogra_> it isnt even on the screen
<ogra_> and i cleared the dir when shutting down (without unity running at all)
 * ogra_ tries that again
<Saviq> ogra_, how big is the crash file?
<Saviq> ogra_, bug #1240866 probably
<ubot5> bug 1240866 in Unity 8 "unity8 crashed with SIGSEGV in getenv()" [High,Triaged] https://launchpad.net/bugs/1240866
<ogra_> root@ubuntu-phablet:/# ls -l /var/crash/
<ogra_> total 384
<ogra_> ---------- 1 phablet whoopsie 390128 Oct 21 12:53 _usr_bin_unity8.32011.crash
<asac> cjohnston: do you know why we see those bogus entries on http://reports.qa.ubuntu.com/smokeng/saucy/
<asac> cjohnston: e.g. the ones with just one date rather than normal veresion?
<cjohnston> means the install failed
<ogra_> no crash this time
<ogra_> Saviq, so firing up the test definitely creates the crash file
<ogra_> seemingly on shutdown of the shell
<psivaa> cjohnston: asac: i dash_ignore 'd them but since they were from the weekend we need to wait till 1330 UTC to get them removed
<Saviq> ogra_, yeah, we still have a crash on shutdown indeed
<asac> cjohnston: looks buggy to me at least :)
<Saviq> ogra_, or do we... thought we had that fixed
<asac> psivaa: right. still think the visualization could be at least improved
<Saviq> ogra_, can you give me your steps?
<cjohnston> asac: we don't really have a way to guess what the build number should be if we can't get it
<asac> cjohnston: so those cases we cant download?
<asac> cjohnston: cant get the index.json?
<cjohnston> AFAIK that part was fine
<ogra_> Saviq, i flash. makes the image writable and run "phablet-test-run -n -p unity8-autopilot unity8" ... once the old shell stops i see the crash file apprear (before it prints that it starts the tests in the other terminal)
<asac> cjohnston: my understanding is that we are looking at http://system-image.ubuntu.com/trusty-proposed/mako/index.json
<asac> cjohnston: that one has the version info included
<cjohnston> I thought we were getting the info from the device
<Saviq> ogra_, /me does
<asac> cjohnston: right. maybe we should use that info as well and then even compare those two infos :)
<asac> as another meta test
<Saviq> ogra_, did you keep the display lit?
<cjohnston> ack
<ogra_> Saviq, i tried to ...
<ogra_> Saviq, it turns off when the shell goes away
<Saviq> ogra_, you can always go "powerd-cli display on bright"
<Saviq> ogra_, aah
<ogra_> i cant trigger a crash when just stopping and starting unity8
<ogra_> must be the start of the test that causes it
<Saviq> ogra_, bug #1240801
<ubot5> bug 1240801 in unity8 (Ubuntu) "autopilot unity8 fails with "No GSettings schemas are installed on the system"" [Low,New] https://launchpad.net/bugs/1240801
<Saviq> ogra_, that's fixed in unity8 trunk (and only affects testing)
<cjwatson> ok, trusty is open
<cjwatson> will be starting autosyncs shortly
<ogra_> aha
<cjwatson> and removing the proposed block shortly as well
<Saviq> cjwatson, \o/
<Saviq> ogra_, export XDG_DATA_DIRS before "autopilot run unity8"
<Saviq> ogra_, and it will be fine
<ogra_> Saviq, oh
<Saviq> ogra_, XDG_DATA_DIRS=/usr/share autopilot run unity8
<ogra_> phablet@ubuntu-phablet:~$ initctl stop unity8
<ogra_> unity8 stop/waiting
<ogra_> phablet@ubuntu-phablet:~$ XDG_DATA_DIRS=/usr/share autopilot run unity8
<ogra_> Loading tests from: /usr/lib/python2.7/dist-packages
<ogra_> Tests running...
<ogra_> and it doesnt lie :D
 * ogra_ sees the unity tests on screen
<cjwatson> autosyncs starting
<cjohnston> asac, psivaa they have been removed from the dash
<didrocks> cjwatson: excellent!
<ogra_> asac, Saviq, http://paste.ubuntu.com/6276146/
<ogra_> so unity8 looks pretty good
<Saviq> ogra_, yeah, just one crash on startup - the getenv one
<Saviq> ogra_, that test will run if you start it again
<ogra_> k
<asac> ogra_: webbrowser is OK too (37 tests run)
<asac> zero failure :)
<asac> ogra_: so where is the udev fix :)?
<asac> i want systemsettle to stop complaining
 * ogra_ re-runs to prove the failure goes away
<ogra_> asac, its in 101
<asac> ogra_: so should be in 1 too?
 * asac checks top
<Saviq> Ubuntu Touch 101 ;D
<ogra_> was in trusty-proposed, i dont think it was in trusty when we built the image
<asac> ogra_: hmm. 97.8 idle only
<asac> pulse is going wildish
<ogra_> asac, i think it was held
<asac> oh wait :)
<asac> lol
<asac> that was my x220
<ogra_> heh
<asac> ogra_: we still see systemsettle issues on 101 though: http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/maguro/101:20131018:20131015/4776/gallery-app-autopilot/
<asac> ogra_: all are still orange because of that: http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/maguro/101:20131018:20131015/4776/
<asac> pretty busy
<asac> here is the before run of gallery http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/maguro/101:20131018:20131015/4776/gallery-app-autopilot/493965/
<asac> doesnt hit 97% average
<asac> ogra_: sure its in 101? build 1 feels quiet
<ogra_> asac, right, but no udevd issue it seems
<ogra_> looks like top is the biggest consumer in the logs
<asac> ogra_: ueventd is still there though
<ogra_> yes, thats fine
<asac> ogra_: the first sample always has top
<ogra_> ueventd  != udevd
<asac> ogra_: but why would top be so slow all of sudden?
<asac> we never had this problem before
<ogra_> and it is always under 0.5% as i see it
<ogra_> dunno, but top consumes >3%
<asac> right. thats new
<ogra_> that keeps us below 97% idle
<ogra_> no idea why
<asac> cjohnston: did you guys ever touch the systemsettle code :)?
 * asac tries to find it
<asac> cjohnston: or the parameters?
 * ogra_ doubts that 
<asac> ogra_: well, we see settle consistently failing after boot
<asac> ogra_: either we have loads more processes
<asac> or something slows it down
<ogra_> do we have crash files ?
<ogra_> hmm, no
<ogra_> doesnt look liek we do
<asac> zero crashes so far on 101
<ogra_> right
<ogra_> heh, spoke to soon :P
<ogra_> mako has one
<ogra_> maliit in andressbook-app
<ogra_> asac, aha https://jenkins.qa.ubuntu.com/job/saucy-touch_mir-maguro-smoke-friends-app-autopilot/22/artifact/clientlogs/top_before.log/*view*/
<asac> ogra_: i think the most interesting part is likely starting from TOP DUMP (after settle run: 1)
<asac> or even https://jenkins.qa.ubuntu.com/job/saucy-touch_mir-maguro-smoke-friends-app-autopilot/22/artifact/clientlogs/top_before.log/*view*/
<asac> err
<asac> TOP DUMP (after settle run: 3)
<ogra_> heh
<asac> thats a few minutes into the boot
<asac> so everything should be started by then
<asac> TOP DUMP (after settle run: 9)
<asac> thats the last run. whatever makes it fail there is the problem
<ogra_> phablet@ubuntu-phablet:~$ XDG_DATA_DIRS=/usr/share autopilot run unity8
<ogra_> Loading tests from: /usr/lib/python2.7/dist-packages
<ogra_> Tests running...
<ogra_> Ran 22 tests in 549.162s
<ogra_> OK
<asac> unity8 ueventd, adbd
<ogra_> yay
<asac> nice one
<ogra_> only on second run though
<asac> so our current settle limit was 97.5
<asac> we now hit like 69.5 reliably
<asac> on maguro
<asac> err
<asac> 96.5
<asac> so we only need to explain a 1% boost
<asac> that could easily be unity8 because of MIR, but i somewhat feel something else is also fishy
<asac> why is adbd for instance there with 1%?
<asac> ogra_: seems on SF its also pretty tight
<asac> http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/maguro/100:20131017:20131015/4768/calendar-app-autopilot/492569/
<asac> it like succeeeding during the last attempt
<asac> but that is before the udev fix
<ogra_> http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/maguro/100:20131017:20131015/4768/calendar-app-autopilot/
<ogra_> but it succeeded
<asac> ogra_: yeah, but still very tight/late
<ogra_> and SF doesnt trigger udevd to go wiltd
<ogra_> thats a Mir issue
<asac> so anything changing can make us go red
 * asac doesnt like that we only getting up to 97.5 anyway
<asac> ogra_: maybe it is because we use powerd-cli screen-on ?
<ogra_> well, top always eats some
<ogra_> why would have influence the load ?
<ogra_> s/have/that/
<asac> ogra_: thats it. i turned the screen on and i suddenly see unity8 coming to the forefront of top
<ogra_> sure
<asac> ogra_: and ueventd
<ogra_> has always been like that
<asac> so thats the reason. if folks turn off the screen before settle,then we are green :)
<ogra_> ueventd might be other fallout of the Mir bug
<asac> cjohnston: doanac: plars: ^^
<ogra_> tvos hass a fix for that afaik
<ogra_> *tvoss
<asac> ogra_: so the fact that unity8 starts consuming cycles when you turn screen on is considered a bug?
<ogra_> no
<ogra_> it has to refresh
<ogra_> the bug is that the driver under Mir spams uevents
<ogra_> that keeps traffic up in varioud places
<asac> i right
<asac> ack
<ogra_> not all of them can be seen
<ogra_> udevd was only one fallout
<asac> ogra_: so you say there is still some noice now in ueventd that we fixed udev?
<asac> ogra_: can we maybe also filter there smartly?
<asac> noise
<ogra_> thimas has a possible fix that only makes the uevent spam apper when there is actual interaction
<ogra_> *thomas
<ogra_> instead of having a constant stream of 60 events per sec
<asac> ok, but we can't minimize the impact on the ueventd process during a spam/attac,k on top of that?
<asac> rigt
<asac> i understand i think.
<ogra_> we need to kill the spam like SF does
<asac> oki
<ogra_> then it should work as fast as SF and your processes shouldnt misbeahve anymore
<asac> well, that would mean that its a bug and we might want to continue keeping it visible on dashboard
<asac> until we have fixed maguro
<ogra_> i uploaded some HTML5 games to the shop over the weekend, zombie attach is a highly demanding game that makes a good performan.ce test
<ogra_> *zombie apocalypse
 * asac installs it
 * asac always has to setup ubuntu one account
<asac> odd
<ogra_> once for shop access
 * ogra_ never has to do it more than once
<ogra_> that game runs on the edge on mako ... (runs super smooth on android btw) ... on mako it is just close to be unusable
<ogra_> on maguro i get all actions with a long delay
<ogra_> i.e. non usable at all
<asac> ogra_: does it work well on android maguro?
<asac> i tried it now on maguro and yes its not usable )
<ogra_> no idea, it works well on my S4
<asac> :P
<ogra_> i have never run android on a maguro :P
<ogra_> it definitely shows we need to improve the browser performance for such stuff
<ogra_> having something like this game run smooth by trusty release might be a nice goal :)
<ogra_> (on maguro)
<cjohnston> asac: I honestly have no idea about any changes to systemsettle
<asac> cjohnston: all good. i think we found it
<asac> plars: doanac: cjohnston: we need to not enable the screen while running it
<asac> (systemsettle)
<asac> plars: doanac: cjohnston: or rather use powerd-cli to have it off i guess
<asac> systemsettle test itself should do the right thing there
<plars> asac: iirc, before we added the powerd-cli display on, more things were failing
<plars> asac: so just turning the display on is causing unity8 to eat cpu?
<sergiusens> @ci share-app hasn't been part of the product for a while, it's tests should probably be disabled since it's installing things that can skew the test results for other components by installing abandoned/obsolete deps
<asac> plars: its only about systemsettle
<cjohnston> sergiusens: in the daily image testing?
<asac> plars: that testcase itself should ensure that screen is turned off
<asac> plars: every other testcase should senusre that screen is turned on and unlocked
<sergiusens> cjohnston, yup
<asac> e.g. its a testcase thing and systemsettle shoudl ensure we do the right thing for it
<cjohnston> plars: ^
<plars> asac: the problem is, doanac found that if we don't turn the display on at the beginning, before system settle comes on, then it might not come on and tests had issues later
<asac> plars: lets talk to doanac
<asac> plars: turn it off
<asac> turn it on after
<asac> i dont think that should cause harm, but lets see
<plars> sergiusens, cjohnston: ack, I'll disable share-app. It's not coming back later or anything is it?
<sergiusens> plars, it's an ubuntu ui toolkit component since beginning of september
<plars> sergiusens: that's what I thought, ok I'll remove it completely then
<fginther> morning
<Mirv> didrocks: ok, now ~everything is split to /saucy branches with updated Bzr-Vcs url:s for those, see doc
<Mirv> I'll prepare a quick cu2d change proposal, but I'll leave it to you (for today) otherwise
<didrocks> Mirv: great! the cu2d config is ready as well?
<didrocks> Mirv: maybe you'll need to get in sync with fginther
<fginther> didrocks, Mirv morning
<didrocks> hey fginther ;)
<Mirv> morning fginther
<Mirv> fginther: didrocks: https://code.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/saucy_transition_misc_unity/+merge/191989 - that's a start at least, you can also modify the commit since it's under common LP username
<Mirv> it covers those projects I created a /saucy for today, but not sil2100's ones that are still missing (I haven't gone through those)
<didrocks> Mirv: ok great, maybe fginther, as having worked with sil2100 the other day has the othe part
<cjwatson> didrocks: there are desktop images in pending, btw
<didrocks> cjwatson: excellent, thanks for the head's up. I'll start trying to fetch it as soon as I can
<cjwatson> didrocks: they're stuck in pending because the Windows executables on there are broken, but I expect you don't care
<cjwatson> (well, s/broken/missing/)
<cjwatson> didrocks: it's possible they may not work in other ways, though, as we haven't updated the installer for saucy yet
<didrocks> cjwatson: I hope/try to fetch it from otto, at least, we have a base :)
<cjwatson> otto?
<asac> doanac: didrocks: don't wait for me. let's chat a few minutes after the meeting, i will reset the whole thing now and maybe come in after
<didrocks> lp:otto, the tool we use to do desktop tests
<didrocks> saucy sounds like quality for asac :p
<ogra_> runs fine on my phone
<ogra_> :P
<didrocks> ahah
<asac> doanac: i think NM/wpa sometimes act up and dont connect to the strongest AP here... not sure if its a threshold thing or not
<asac> didrocks: ^^
<asac> (sorry, typo)
<jibel> retoaded, could you add trusty to the default view too on https://jenkins.qa.ubuntu.com/ ?
<retoaded> jibel, sure
<didrocks> asac: oh, that would be something for cyphermox I guess
<retoaded> jibel, done
<jibel> retoaded, and you can remove oneiric
<retoaded> jibel, ack
<jibel> retoaded, thanks
<retoaded> jibel, hmmmm, that seems to have broken the view
<jibel> retoaded, java.lang.StackOverflowError awesome.
<jibel> :(
<retoaded> jibel, and I don't even have the option to delete it so I can recreate it
<retoaded> hmmm, and I can re-create Oneiric since jenkins thinks it already exists (but doesn't show)
<jibel> from the error I'd say it tries to access a view that it thinks exists but actually doesn't and falls in a infinite loop
<retoaded> jibel, ack. got it straightened out.
<jibel> retoaded, good, thanks.
<retoaded> jibel, changed the default view to something else, went back into Releases, removed Oneiric (again) and it worked this time. Reset default view back to Releases.
<jibel> add a note for next time you have to remove a release from that list
<cyphermox> asac: do you mean on initial connection?
<didrocks> retoaded: http://10.97.0.1/iso/trusty/ is grabbing pending apparently, right?
<retoaded> didrocks, yes
<didrocks> excellent, thanks for confirming!
<asac> cyphermox: no its after a few days and suspend/resumes
<asac> cyphermox: i have a repeater very close and my main router far away, but you can still see my main router here
<asac> cyphermox: seems that after a few of those suspend/resumes, NM or wpa prefers the "main router" and my inet etc. goes flaki
<cyphermox> we,, it's possible you can see it, but have you compared the BSSIDs to make sure which one was conected to?
<cyphermox> ok
<asac> yeah
<asac> i see that i am connected against the wrong one
<cyphermox> there's a patch I'll upload soon that changes the threshold, perhaps that will help
<asac> cyphermox: so i tried using NM UI to force the BSSID close by, but seems that doesnt prevent NM to still roa mto the other
<asac> feels very weird how you as a user can "force" (gues its not a real force" for BSSID
<asac> cyphermox: oh there is a threshold? let me know when its there, i am happy to test
<asac> hehe
<cyphermox> no, it's meant to be that way -- if you specify it, it will not roam and use the BSSID you provided
<cyphermox> in some cases it's quite useful
<alan_g> fginther: remember setting up CI for the mir/development-branch? I just noticed that it doesn't build for armhf like lp:mir does. Was that intentional?
<fginther> alan_g, no that was not intentional, If I remember right, the armhf build was added to lp:mir after the development branch job was setup. We just didn't remember to modify both branch configurations.
<fginther> alan_g, that should be fixed now
<alan_g> fginther: thanks. (I thought armhf had been around a lot longer. But fixed is fixed)
<cjwatson> armhf in general predates mir but PPAs don't build for armhf by default and I think the mir PPA initially didn't
 * alan_g meant the mir armhf build
<didrocks> http://10.97.0.1:8080/job/autopilot-trusty-setup_otto/label=qa-intel-4000/1/console
<didrocks> vila: fginther ^
<didrocks> 2013-10-21 14:19:27,634 ERROR An error during creation occurred, trying to cleanup the container: The container didn't stop successfully
<fginther> kgunn, are you familiar with the mir branch changes that duflu is proposing? I have some questions about it
<kgunn> fginther: i read thru it about an hour ago....shoot
 * kgunn grabbing coffee & a fleece back in a moment
<fginther> kgunn, will any future changes be directly proposed to lp:mir, or will all the changes go into the development branch and that is merged into lp:mir when it's ready?
<kgunn> fginther: and i understand it..i think the idea is to stage everything on the development-branch...and then using a pull
<kgunn> fginther: rather than a merge to get the history
<fginther> kgunn, right. I'm trying to scope the amount of work needed here as a pull is not something that our tools currently support.
<kgunn> fginther: its kind of interesting....i think if we every go to a truly feature development type dev environ
<fginther> kgunn, It would help if I knew if we need to support other branches merging into lp:mir, or if we can lock this down to just the development branch
<kgunn> that's actually what would be needed
<kgunn> fginther: i'm totally ok with locking it down
<kgunn> fginther: mmmm....let me backpeddal one mire
<kgunn> minute rather
<fginther> kgunn, I'm also not familar with all that pull is doing, so need to do a little research on my own
<kgunn> fginther: i could foresee the potential need for speed, that someone might want to push to both
<kgunn> fginther: altho...that would be a merge
<fginther> kgunn, so other groups have proposed the trunk + feature branch development environment, but this is the first time pull has come up rather then merge
<kgunn> fginther: right....i think this is all about the history of the branch being merged....
<kgunn> fginther: and i don't understand it myself....but i think this is the problem with not having downstream able to pull from something other than "trunk"
<asac> didrocks: doanac: cjohnston: so what was the outcome of bringing up trusty on dashboard etc.?
<doanac> asac: we are trying to get them going today.
<doanac> i have 3 MPs out that the team is reviewing
<asac> doanac: ok cool. sounds goodie. would love to declare "happy development" to the UE team after seeing results
<didrocks> asac: ogra_: plars: robru: psivaa: cyphermox: I guess there is no need for this afternoon landing team syncing up. Let's do it tomorrow morning, we're almost there!
<ogra_> didrocks, ++
<plars> doanac: ack
<psivaa> didrocks: ack
<asac> didrocks: oki ... was just wondering while i was on there :)
<didrocks> asac: ahah, sorry ;)
<lool> Hey folks
<lool> I see there's a new trusty-proposed channel
<lool> with an image
<lool> but it's not in devel-proposed
<lool> is that intentional?
<lool> after chatting with stgraber, he intends to update both devel-proposed and devel once the first trusty-proposed image is promoted to trusty
<ogra_> lool, yes, thats what we discussed a while ago
<didrocks> ok, time for my daily run before it's night
 * didrocks waves good evening
<ogra_> ciao
<plars> doanac: I just witnessed something that could cause us trouble
<doanac> plars: i'm killing the jobs now. its too much to follow
<doanac> and i found a small bug in free the devices
<plars> ogra_: I was running the latest devel-proposed which I just installed locall, and connected to it with adb. Then mtp connected and as soon as the window popped up for it, adb disconnected.
<plars> doanac: ^
<doanac> ah - that's bad. I think josepht has seen something like that also
<plars> ogra_: I was able to reconnect just fine, but losing that connection at some points in the install/setup process could produce inconsistent results
<ogra_> plars, yes, known
<ogra_> (and we discussed it plenty of times already i think)
<plars> ogra_: is there something we can do on our side to prevent that from happening?
<ogra_> the gadget device gets reset if its options change
<ogra_> yes, rework the whole sh*t
<ogra_> :)
<plars> ogra_: heh
<doanac> can we disable MTP on our host so it doesn't happen?
<ogra_> plars, sergiusens was looking into setting persistent properties, once we can do that we should be able to not touch the settings of the device during boot
<doanac> ah - i guess not
<ogra_> doanac, no, once you change the settings of the gadget device on the phone it reconnects
<ogra_> not related ot the host side
<doanac> it weird its suddenly gotten worse. but I maybe we've just been lucky up till now
<ogra_> so instead of changing the props dunamically every boot, we should use a persistent setting that onlt changes on demand (and keeps this setting over reboots)
<doanac> plars: i've got to step away for a bit. I fixed a small bug in the master job.
<doanac> and i'm letting the touch_sf4p run on maguro
<doanac> http://10.97.0.1:8080/job/trusty-touch_sf4p-maguro-smoke-master/1/
<plars> ok
<doanac> plars: there's a bug in the unity8 tests. running "autopilot list unity8" shows a problem with unity8-autopilot/shell/tests/test_notifications.py", line 29, in <module>'
<plars> doanac: that's happened several times before - something the unity8 team will have to fix
<doanac> looks like we need to add python's "gi" repository
<doanac> for now
<plars> doanac: oh
<plars> doanac: actually
<plars> doanac: I looked at something with that late last week
<plars> doanac: it looked like the latest phablet-tools installs gi in the autopilot dir from bzr when you run phablet-click-test-setup
<plars> doanac: but the version it installs causes issues
<plars> sergiusens: have you seen anything up with that? ^
<doanac> plars: that's it. i just deleted the copy phablet-click-setup created and it works
<plars> doanac: iirc one of the tests is already installing the python-gi package
<doanac> hmm - i had to install just now, not sure
<plars> doanac: it's easy enough for us to force it to install, but if it's required then it seems odd that just the tests would require it
<plars> doanac: just the unity8 tests I mean
<doanac> plars:  i don't think thats enough. the "gi" library under /home/phablet/autopilot/gi will take precedence
<doanac> so we have to fix this in phablet-tools
<plars> doanac: I know
<doanac> sorry mis-read
<plars> doanac: I'm just wondering if it's a package that should be there in the image
<doanac> true.
<doanac> a weird dep for just the test to need
<doanac> the version phablet-tools grabs says its the same as i just installed. maybe the .deb extraction is messing something up
<sergiusens> doanac, let me check; in any case I added that for veebers
<doanac> sergiusens: here's the backtrace i just got:
<doanac> Traceback (most recent call last):
<doanac>   File "<stdin>", line 1, in <module>
<doanac>   File "gi/__init__.py", line 27, in <module>
<doanac>     from ._gi import _API
<doanac> ImportError: could not import gobject (error was: 'cannot import name _gobject')
<doanac> i just did a python shell with: from gi.repository import Notify
<sergiusens> doanac, let me wrap up this bug fix and I'll get to it
<plars> doanac: sergiusens: could it be that phablet-click-test-setup misses the .so files in python-gi?
<sergiusens> plars, most likely; which tests use python-gi now?
<plars> sergiusens: unity8 for sure, possibly others
<doanac> that's what it is
<doanac> i just verified
<plars> doanac: ack
<sergiusens> doanac, if it's just unity8, let's just remove it from there
<doanac> sergiusens: remove python-gi from phablet-click-setup?
<sergiusens> doanac, yes
<doanac> sergiusens: ack - i'll submit an MP.
<doanac> plars: you want to merge python-gi into our new apconfig.py file for unity8?
<plars> doanac: sure
<plars> doanac: we'll just need to make sure we update phablet-tools, it won't work until we have that fix in there also
<plars> doanac: we could hand-patch on phoenix for now I suppose
<doanac> plars: while you are in there: 'python-mock', 'python-dateutil' are already in phablet-click-setup so we don't need those anymore
<plars> doanac: ack
<doanac> plars: i think we probably need to change our touch test to take an option phablet-tools branch
<doanac> i think we are too reliant on it now assume what's in the distro will handle everything
<sergiusens> doanac, I've been wanting it to be sort of hand copied into a ppa you control
<doanac> plars, sergiusens: actually since we use a PPA for precise. the changes land there pretty fast :)
<plars> doanac: sergiusens: we could make a recipe for it and just request a build for our ppa whenever we want
<fginther> rsalveti, ping
<doanac> sergiusens, plars: https://code.launchpad.net/~doanac/phablet-tools/click-python-gi/+merge/192031
<rsalveti> fginther: pong
<fginther> rsalveti, we have a job hanging around for the qt51 build experiment. Is any of that still needed?
<fginther> rsalveti, http://10.97.0.26:8080/job/ubuntu-touch-image-saucy-qt51/
<plars> doanac: and https://code.launchpad.net/~pwlars/ubuntu-test-cases/pkg-changes/+merge/192033
<rsalveti> fginther: no, that's saucy specific, so let's just disable it for now
<rsalveti> and we'll probably try to migrate to 5.2 in a few weeks instead
<fginther> rsalveti, somehow it created a massive file: "140737486266368 Oct 21 18:15 kcore"
<doanac> plars: +1 thanks
<plars> doanac: looks good to me, but I can't topapprove it
<sergiusens> plars, doanac done
<doanac> plars: oops - we also need to update the utah test entry for unity8
<plars> doanac: oh, right
<plars> doanac: one sec
<plars> doanac: I update phoenix also
<plars> doanac: phablet-click-test-setup on phoenix that is
<doanac> plars: just the "/usr/bin/phablet-click-test-setup"?
<plars> doanac: yes
<doanac> k. i've updated phablet-config on phoenix :)
<doanac> we need to keep track of this - or use a proper branch.
<doanac> i'll get an MP for that soon
<plars> doanac: wait, what needs updating in the utah test? it installs unity8-autopilot which should already depend on python-gi right?
<doanac> it doesn't
<doanac> well - let me check.
<doanac> n/m
<doanac> plars: ^^^ - we are good to go
<rsalveti> fginther: hahah, wtf
<plars> fginther: impressive!
<sergiusens> fginther, do we have devices for core apps?
<fginther> sergiusens, nope
<sergiusens> fginther, would be good to run the click tests instead of deb package ones
<fginther> sergiusens, agreed, I need to inquire about running these on our internal jenkins. Not sure if the split is still required
<sergiusens> fginther, that would be awesome; well at least we can start looking into building them
<plars> sergiusens: I'm uploading a recipe for phablet-tools to build off trunk and just use {debversion}-bzr+{revno}. Any preference what I call the recipe?
<plars> sergiusens: that way we can just build in a ppa for us to pull, but would probably be useful to others as well for testing new phablet-tools etc
<sergiusens> plars, call it what you wish; only thing is that the tests don't run on precise
<sergiusens> plars, also, why not just rely on the daily release stuff?
<plars> sergiusens: because it takes a while to get through that - especially if it's in manual mode as with the problem we had a while back
<sergiusens> plars, manual mode, still?
<plars> sergiusens: you don't think that would ever happen again?
<plars> sergiusens: we were just talking about this a bit ago, having a ppa for ci to use for things like this, which we could control when we build for it and what we put there
<sergiusens> plars, the concept of daily release came up (I've been told) because the recipe system wasn't enough
<sergiusens> plars, if people start using recipe builds it sort of beats the purpose; I feel we are just circumventing a problem here
<plars> sergiusens: this is not for official builds, this is just so that image smoke testing can update phablet-tools quickly as needed for things that need to be fixed quickly to keep ci from slowing down
<sergiusens> plars, ack, feel free to create it
<plars> asac: is there really any difference between what's in the saucy build vs the trusty build?
<plars> right now that is?
<jdstrand> lool: hey, are we supposed to be asking for permission to upload now? if so, may I upload this simple update: http://paste.ubuntu.com/6279220/
<cjwatson> jdstrand: lool is on vacation
<fginther> plars, we have a way to automatically dput new phablet-tools packages to a ppa on each commit to trunk
<fginther> plars, the advantage is that the dput occurs as soon as the commit to trunk is made instead of waiting for the recipe to daily build
<jdstrand> cjwatson: thanks
<jdstrand> asac: ^
<jdstrand> lool: nm
 * lool whistles
<lool> jdstrand: truth is I'm not sure what you need right now  :-)
<lool> but I guess safe uploads to trusty with heads up to landing team would be ok
<jdstrand> yeah, it isn't clear yet. I'll wait for asac
<jdstrand> lool: thanks! and you should be vacationing now :)
 * lool &
<jdstrand> :)
* ev changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: - Type: "cihelp" for help | Britney is set to block all uploads, use lp:~ubuntu-touch-release/britney/hints-ubuntu-touch to override |  Known issues: -
<plars> ev: :)
<ev> :-P
<plars> ev: stupid irc clients
<ev> I'm not a fan of the entire protocol.
<ev> that reminds me, I need to sign up for an irccloud account to make it someone else's problem
<asac> doanac: cjohnston: how is the trusty bring up going?
<asac> ev: ?
<doanac> asac: we have jobs configured but they are buggy. i think i just fixed the issue.
<doanac> i'm running a local test right now
<doanac> moving the powerd-cli call around was causing an adb-shell call to hang
<sergiusens> doanac, hey
<sergiusens> doanac, was just testing the edge intro thing; you can probbaly remove the reboot completely as it's not needed at all
<sergiusens> doanac, as soon as you change the config, it gets out of your way
<doanac> sergiusens: ah - that's even better!
<doanac> i'll update the MP
<sergiusens> doanac, ah, thought you might of left; I copy/pasted to the mp
<doanac> sergiusens: cool. i'm about to eat, but will address tonight.
<doanac> thanks
<sergiusens> doanac, yeah, just enabled/disabled a couple of times without reboot, saw it come and go
<sergiusens> so it's good to avoid the reboot :-)
<doanac> yep. that increases our odds of having a good test run :)
<asac> doanac: moving powercli around -> for systemsettle?
<asac> doanac: i think only screen on we dont want
<asac> the rest isnt really hurting us (not sure what else you run)
<doanac> asac: if you don't call powerd-cli the screen won't come on (even if you call unlock_screen) and the tests fail
<asac> doanac: right. thats for the AP tests
<doanac> so we moved it to just before the test
<asac> doanac: for systemsettle we dont want it on
<asac> right
<doanac> note: system-settle still looks bad
<asac> doanac: is the screen off?
<asac> sure?
<doanac> the screen is in the process of getting there. we call system-settle shortly after booting. so its timing dependent what state the screen is in
<asac> doanac: how long would the screen stay on before automatically going off?
<doanac> asac: not sure. i think its a powerd setting
<asac> doanac: are we still use powerd-cli active ?
<asac> doanac: thats what we surely shoud call right after boot
<asac> then each test calls either on or off etc.
<asac> depending on what it needs
<doanac> asac: I'm trying a fix that calls active and display-on right before we run unlock_screen
<doanac> i'm seeing it doesn't need to happen right after boot
<doanac> and then that keeps system-settle from being altered
<asac> doanac: ok ... i wont hold you back. i believe getting a trusty build is more important than solving systemsettle though - in case that helps somewhat
<doanac> helps a bit. I'm hoping for the best of both worlds with my patch though.
<doanac> its looking good at home so far
<asac> cool
 * asac crosses fingers
<doanac> asac: if plars is on later tonight, we have a good shot at merging the fix and being ready to test tomorrows image
#ubuntu-ci-eng 2013-10-22
<asac> doanac: plars: ok pleas shoot me and dirocks etc. a mail what happened. 'night
<veebers> Is there anyone around that is able to tell me/find out why I can't see a CI job for this approved MR? https://code.launchpad.net/~veebers/unity8/adding_unlock_emulator/+merge/191328
<cjohnston> veebers: what do you mean can't see a CI job?
<veebers> cjohnston: hmm, actually I might be wrong, I was expecting there to be an autolanding job, but was looking at the wrong one (i.e. -ci) and the autolanding is disabled currently
<cjohnston> ok
<veebers> cjohnston: so  a different, better, way to ask my question is: What do I need to do to take that MR from Approved to Merged?
<cjohnston> veebers: what is causing all the things to be unstable?
<cjohnston> I'd guess that needs to be fixed
<veebers> cjohnston: ack, cheers
<ogra_> asac, doanac, i think it would be clever to wait until the session is completely up before running systemsettle ... after all we want to test the user experience
<ogra_> (i.e. make it check if unity8 is there before firing)
<didrocks> ogra_: do you mind refreshing me on what is systemsettle already?
<ogra_> didrocks, it takes ten samples from top and waits if the system goes >97% idle
<ogra_> apparently we run it directly at boot
<didrocks> ah ok ;)
<ogra_> running after the session is up seems like a better usecase to me
<didrocks> yeah, makes sense to have multiple tests, one to know how long we take to have everything started
<didrocks> and another, to know the idle when the session if fully loaded
<ogra_> well i want to introduce bootcharts into the tests
<ogra_> so that part should become more fine grained anyway ... if you want to see the load on boot and how much something takes
<didrocks> right
 * ogra_ grins seeing lool's comment on the bonita thread 
<didrocks> ogra_: well, for all java/jboss webapps, I don't expect less time even on a server to start TBH :p
<ogra_> i meant the "luckily we didnt disable swap" :)
<didrocks> ahah
<ogra_> we had so many discussions about that before release ...
<didrocks> yeah
<didrocks> also, we didn't disable adb
<didrocks> told you! ;)
<ogra_> there is a usecase ... for the crazy ones
<ogra_> didrocks, well, thats just because i ran out of time
<ogra_> it was actually planned to habe it off by default so you need to enable it from the terminal first
<ogra_> *have
<didrocks> ogra_: I know, I just told you we won't have time :)
<ogra_> true
<didrocks> ogra_: terminal or system settings?
<ogra_> i'Ãm to optimistic at times
<ogra_> terminal
<ogra_> there was no UI planned for dev mode
<didrocks> interesting, we should maybe
<ogra_> (we should do that for 14.10 in any case=
<ogra_> )
<ogra_> err
<ogra_> 14.04
<didrocks> ;)
<didrocks> so you always live in the future
<didrocks> and ev always lives in the past (he keeps telling 12.10 :p)
<ogra_> bah so i uploaded an internet radio app and now my BT speaker inst found :(
<didrocks> for some games as well it seems?
<ogra_> and some news sites
<didrocks> yep
<ogra_> and a TV program planner :)
<didrocks> ahah :)
<didrocks> and we have 2 xkcd apps
<ogra_> we might end up havfing 10 ... :)
<didrocks> right ;) still 0 direction/driving apps
<didrocks> but 2 xkcd apps ;)
 * ogra_ expects the same chaos as googlew play has over time 
<ogra_> well we have OSM ...
<ogra_> not with firections though
<ogra_> *directions
<didrocks> yep
<ogra_> and google maps works as well
<ogra_> (with directions)
<ogra_> webapps are just so easy (creating the click package takes less than 10min if you have a template app ... (of which 9min are used to find a proper icon)
<didrocks> google maps?
<didrocks> we do have a wrapper for it?
<didrocks> or not yet?
<ogra_> sure, go to maps.google.com
<didrocks> ah ok
<didrocks> I'll try to exercise that as a click app as well
<didrocks> today
<ogra_> it has some user agent issues so the page flips to desktop at times
<didrocks> better that we learn our technology :)
<ogra_> http://daker.me/2013/10/package-your-webapp-for-ubuntu-touch.html
<ogra_> thats an intresting hack to force the user agent for a page
<ogra_> (though thats far more effort than i had to do for my apps)
<didrocks> ogra_: excellent! will try that :)
 * didrocks finishes first the morning tasks
<asac> ogra_: didrocks: what time do we want to build the image?
<asac> :)
<asac> now or later?
<didrocks> asac: as we are unsure that the dashboard is going to pick the right image (and to not confuse result, I would prefer to have the change before we have the image built), I would like to wait for doanac "go" on the dashboard fix
<ogra_> asac, evening i'D say
<ogra_> (independently from the dashboard, the more syncs we can get in the better so we have them cross tested)
<asac> didrocks: hmm. its not about the dashboard fx, but making a reasonable soon snapshot to make the set of changes more managable
<didrocks> asac: well, without have dashboard results, we don't know of the real quality of the AP tests results
<asac> i dont understand why we wouldnt build a new image now and then whenever we feel we need more as well, but *shrug*
<asac> didrocks: we dont. so we produce the snapshots now and then get the results later
<didrocks> so we can just say "well, it boots"
<asac> didrocks: right. its for post-testeing
<didrocks> asac: I mean, it will run the tests against 101
<asac> so we have bi-sect points in history in case that stuff is broken
<asac> didrocks: ah... well, we can surealy ensure that we test the right stuff
<asac> after
<didrocks> and I'm unsure we have a way to reflash/relaunch a whole set of tests again
<asac> just produce the images now and we can test them once the dashboard is fixed
<asac> didrocks: we have
<didrocks> if you are sure we can, yeah, +1 for now
<asac> yes i am sure that we even did that in the past
<didrocks> asac: but I'm sure we are going to screw old results with new ones
<didrocks> but let's seeâ¦
<didrocks> asac: we relaunched some tests
<asac> what is tricky is testing and image that is not the latest, but that is also possible
<didrocks> in the past
<didrocks> not changed the image :)
<didrocks> ogra_: ok, so let's kick an image, we'll seeâ¦
<asac> didrocks: i hope the infra has matured a bit
 * ogra_ goes and kicks 
<nik90> @ci, with the 13.10 freeze over, would it be possible to get the patches https://code.launchpad.net/~renatofilho/qtorganizer5-eds/fix-match-all/+merge/191080 and https://code.launchpad.net/~charlesk/indicator-datetime/lp-1233176/+merge/190009 in the phone image?
<nik90> I need those two patches to verify the working of alarm
<ogra_> asac, didrocks, build #2 running
<ogra_> lets see if it even survives :P
<didrocks> nik90: I think we'll need a landing ask (if not already) for that one
<nik90> didrocks: I dont think I have the permission to do so..I will ask popey to add a landing task for it.
<didrocks> nik90: and we'll start resuming landing tomorrow morning (finishing up transitionning today to trusty)
<didrocks> thanks nik90!
<nik90> didrocks: okay :)
<popey> nik90: didrocks i dont have access either
 * didrocks gives popey power
<popey> noooooooooooooooooooooooo
<popey> â»
<didrocks> popey: powered up! :)
<ogra_> asac, what about sending a call for MIRing stuff to the MLs. i think we should have people start getting their stuff into main so we dont have to care about that at the end of the cycle
<ogra_> (and the MIR team can process the requests over the cycle instead of getting them all at the last minute)
<didrocks> ogra_: MIR team == mterry though
<ogra_> yes :)
<ogra_> thats what i mean ;)
<didrocks> kalikiana: hey, answered on landing ask #185, can you give us more details?
<didrocks> kalikiana: I wonder why it worked for you, there is surely a way you tested it differently from us and I want that we fix that gap :)
<kalikiana> didrocks: not sure what more detail you're thinking of. you got a bug number and expected fixes
<didrocks> kalikiana: I mean, you filed a first landing ask
<didrocks> kalikiana: so I intended it was working for you
<didrocks> how was it working? did you disable apparmor?
<kalikiana> I didn't disable it that I can tell
<didrocks> kalikiana: so, you were getting sensors feedback? the toolkit/apparmor regressed you?
<didrocks> we try to identify what you differently than us to get sensors feedback working when you requested the landing ask, so that we can write better guidelines on testing
<kalikiana> my assumption was apparmor changed, though jdstrand told me it didn't have a policy for the vibration before - the next thought would be android layer changesâ¦ but I don't know much about it
<kalikiana> is it possible that the container stuff changed permissions?
<didrocks> kalikiana: well, can you check with jdstrand? because we tested in the same image than you did I guess (it was the day you added the landing ask) and didn't get it working
<didrocks> so maybe it's an application test diff, some confined, some not confined, but would be great that we identify it
<kalikiana> didrocks: I repeat I wasn't able to test with that particular image to begin with
<kalikiana> I had an older one when I tested before the ask
<kalikiana> I ran into tooling problems preventing me from testing anything useful but finding unrelated bugs
<didrocks> kalikiana: hum, so, before filing the landing ask, maybe you can check with us if this reproduce?
<didrocks> as we were able to test, we can give advice maybe :)
<xnox> didrocks and/or other CI people: Why indicators linked to bug #1241539 haven't been released into trusty yet? =)
<ubot5> bug 1241539 in indicator-sound (Ubuntu) "ubiquity-dm is missing keyboard, input, sound, system indicators" [High,Triaged] https://launchpad.net/bugs/1241539
<kalikiana> well Mirv was testing also
<kalikiana> I guess you would have prefered not to add it to the sheet before either of us confirms it with the latest image
<didrocks> kalikiana: right, it's the deal to have a fast landing flow
<didrocks> xnox: well, we are deploying the switch to T. See the emails by asac, we'll get first landing tomorrow
<xnox> didrocks: on which mailing list?
<xnox> ubuntu-devel?
<didrocks> asac: do you remember where you did send that? ^
<didrocks> hum, seems only ue-leads, that would explainâ¦
<asac> xnox: ue-leads
<asac> didrocks: ^^
<xnox> didrocks: i see one to ubuntu-phone just now.
<asac> you can forward
<asac> xnox: thats one without timeline.
<asac> xnox: forwarded you the initial mail
 * asac will stop using ue-leads for high level allignment as managers seem to not forward such info to their teams :)
<Laney> It'd be better to use a public list, really
<Laney> where possible etc
<xnox> asac: i think ubuntu-engineering@l.c.c is a good one and/or ubuntu-phone@ even better.
<xnox> cause everyone is subscribed to ubuntu-engineering@
<Laney> Everyone in UE at Canonical
<psivaa> asac: didrocks: the smoke is now running trusty image now. the results are starting appear in the dashboard
<asac> psivaa: really? wowo!!
<psivaa> with image 1
<didrocks> psivaa: excellent!
<asac> ncie one
<asac> http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/1:20131021.1:20131015/4783/
<asac> psivaa: will maguro also go ahead?
<psivaa> asac: i'll look at that
<asac> plars: doanac: so if i run top -b -d 3 i constantly get better than 97.5
<asac> plars: doanac: so if i run top -b -d 5 i constantly get better than 98.5 even
<asac> plars: doanac: so maybe we should revisit our parameters used
<asac> plars: doanac: e.g. closer to the ones i initially proopsed than the very quick/fast we have now
<didrocks> sil2100: Mirv: so, we can build all trusty now?
<sil2100> Mirv: did you redeploy everything? (I did qa)
<sil2100> Let's keep our fingers crossed that we didn't miss anything ;)
<ogra_>  load average: 2.19, 1.01, 0.39
<ogra_> hmpf
<ogra_> i'd really like to know why our load is so high all the time
<didrocks> sil2100: ok, autorun launched
<sil2100> Mirv: damn, my qa merge didn't get in (but all is redeployed)
<ogra_> (there is no obvious process in top consuming anything)
<Mirv> didrocks: sil2100: yes, and let's see how it goes now
<sil2100> Mirv: huh, I can't redeploy the SDK stack for saucy it seems - ERROR Can't set the target branch ~ubuntu-sdk-team/qtcreator-plugin-ubuntu/trunk-2.7 for lp:qtcreator-plugin-ubuntu/2.7
<sil2100> Mirv: I'm not a member
<sil2100> I guess we need to ask them to add all of us, the ubuntu-unity team as members
<Mirv> sil2100: yeah sdk team was made more strict lately because the trunk was messed up. I'll add individuals.
<didrocks> ogra_: hum, I click install my own package and don't see it in the installed app
<didrocks> is there any trick? (I already tried rebooting)
<didrocks> ah, click register surely
<didrocks> hum, not apparearing after that, let's reboot
<didrocks> ah, a reboot did it :)
<asac> webbrowser app test failing? is that a known flaki one?
<asac> http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/101:20131018:20131015/4782/ vs.
<asac> http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/1:20131021.1:20131015/4783/
<asac> didrocks: unity8 also as results not meeting what we expect, right?
<asac> http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/1:20131021.1:20131015/4783/unity8-autopilot/
<didrocks> asac: no, we didn't release any other ones
<didrocks> asac: see my answer to doanac :)
<didrocks> so it's known to be screwed until we release one
<asac> didrocks: release == new unity8 fix?
<didrocks> yep
<asac> ok. so webbrowser?
<didrocks> those are supposed to be good
<cjwatson> didrocks: please don't use click install (unless you're very careful with its arguments), use pkcon install-local
<cjwatson> didrocks: the click manual page has advice
<didrocks> cjwatson: ah, ok will do then :)
<asac> didrocks: yeah. http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/1:20131021.1:20131015/4783/webbrowser-app-autopilot/
<cjwatson> didrocks: (I'd point to manpages.ubuntu.com but it doesn't have 13.10 yet ...)
<cjwatson> But   "This is a low-level tool; to install a package as an ordinary user you should generally use pkcon install-local PACKAGE-FILE or some higher-level user interface instead, which take care to use the correct set of options.  (Do not use sudo when invoking pkcon, as it needs to know the calling user.)"
<didrocks> cjwatson: I guess that we should have the tutorial as well pointing to us (I only used --help TBH)
<didrocks> to pkgcon*
<cjwatson> didrocks: the help output does point to pkcon
<cjwatson> didrocks: http://paste.ubuntu.com/6282270/
<didrocks> cjwatson: I just click --help
<didrocks> and figured out the parameters then
<cjwatson> didrocks: which points to "click install --help" for more on that specific command, which points to pkcon
<didrocks> cjwatson: right, but I didn't think that care was needed, so I just click --help and then click install <package>
<cjwatson> sigh
<cjwatson> OK, I'll add a note to the top level as well
<didrocks> cjwatson: well, maybe I'm just stupid thinking that click install <click_file> was safe and didn't need to read something else than click --help
<cjwatson> didrocks: +  * Adjust top-level "click help" entry for "install" to point to pkcon.
<didrocks> cjwatson: thanks ;)
<asac> didrocks: maliit is crashing :)
<asac> still;
<didrocks> asac: yeah, not news, we knew it, this a crash somewhere in the stack, the keyboard guys were pinged about it
<asac> ok so no regression... kk
<psivaa> ogra_: i think maguro flashing is taking longer than usual with trusty image 2. looks like more than 25 mins. i'll run once more to find out the exact time
<ogra_> ok
<ogra_> well, it is usually between 20 and 30 for me
<didrocks> ogra_: you are counting download time for you, right?
<ogra_> didrocks, no plain flash times
<asac> ogra_: can you see if the unity8 upstream merger a) run their AP and b) if it passes currently?
<didrocks> ogra_: waowâ¦
<asac> err
<asac> didrocks: ^^
<asac> ogra_: sorry
<didrocks> asac: upstream merger? we are not upstream for maliit
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/20131022.changes
<asac> didrocks: talking about unity8  itself ... sorry :)
<ogra_> diff between 1 and 2
<ogra_> (FYI)
<asac> didrocks: was back on the "unity8 is failing, but fix is in trunk - most likely" topic
<asac> didrocks: i figured that if its fixed, the upstream merger should give green on those
<asac> but now i dont know if folks have again turned the AP off :)
<didrocks> Saviq: https://code.launchpad.net/~unity-team/unity8/trunk
<didrocks> Saviq: I don't see your fix btw, you told me on Thursday you merged it, right?
<Saviq> didrocks, fix for? the autopilot tests?
<didrocks> Saviq: yep
<Saviq> didrocks, http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/473
<Saviq> didrocks, asac
<didrocks> oh, it was at Christopher's name
<Saviq> but we need unity-mir released first
<Saviq> and then drop unity8-setcap.conf from lxc-android-config
<Saviq> or well, not for image testing
<didrocks> Saviq: ? yeah, we are only talking about the tests
<asac> Saviq: what does  UNSTABLE: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/2564 mean?
<asac> test failed?
<asac> why do you merge anyway? :)
<didrocks> Saviq: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-touch/3025/console
<didrocks> unmet dependency on the one I picked
<Saviq> didrocks, look up
<asac> i cant really parse this ... https://code.launchpad.net/~veebers/unity8/ap_env_fix_1240801/+merge/191567/comments/440420
<Saviq> asac, we're not
<didrocks> let's look at a MP older then
<asac> so we have some SUCCESS: ... on armhf ->  SUCCESS: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-saucy-armhf/3023
<Saviq> didrocks, we never got mediumtests-touch to a working state with mir yet
<asac> ah thats building
<didrocks> asac: saucy is desktop AFAIK
<didrocks> Saviq: it was on the image, apart from 1 failure, right?
<Saviq> didrocks, yes
<asac> Saviq: well, the idea is that after your merge
<asac> it works
<Saviq> didrocks, the failure was a random crash, too
<asac> so you shouldnt merge it if it doesnt :)
<didrocks> 8 is more though
<Saviq> asac, really, please stop
<asac> ah
<asac> ok
<Saviq> asac, I'm telling you what's the prerequisite for unity8 even *starting*
<Saviq> and that is unity-mir release
<didrocks> Saviq: juts to understand on that one: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/2575/?
<didrocks> it's your fix
<Saviq> didrocks, asac please stop
<didrocks> I guess it was ran without this unity-mir dep
<Saviq> and listen
<asac> yeah lets listen
<asac> sorry Saviq. go ahead
<Saviq> we need to release unity-mir, so that we can drop unity8-setcap.conf from lxc-android-config
<Mirv> sil2100: unity-ubuntu now part of the sdk team (the 11 team members were ones that I would have added individually as well)
<Saviq> that will let us install unity8 in mediumtests-touch
<Saviq> and only then we can start looking into actually fixing those runs
<Mirv> I trust ~ubuntu-unity members not to push --overwrite to ui-toolkit repo :)
<asac> ok sounds good
<asac> Saviq: do we have all pieces ... in theory?
<Saviq> and looking into them if they didn't pass
<didrocks> Saviq: I still don't undestand why having just the code executed in https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/2575/? (so your fix), I was able to have all tests (but 1) passing on the image
<Saviq> asac, yes, unity-mir just needs a release
<asac> and lxc-android-config?
<didrocks> without any unity-mir/dropping unity8-setcap.conf
<Saviq> didrocks, those failures were intermittent - now fixed in trunk
<didrocks> Saviq: the 8 of them?
<Saviq> didrocks, yes
<didrocks> we just got really unlucky?
<didrocks> ok
<Saviq> didrocks, intermittent as in we fixed them
<didrocks> ok
<asac> didrocks: guess we should make an ask for this and do this as one of our first things. seems a few components are involved that require coordination :)
<didrocks> asac: indeed, I would be interesting if such ask was made to make it a priority
<asac> lxc-android, unity8, unity-mir
<didrocks> knowing that will dep on a mir ABI bump which is already in the ppa
<asac> well, we didnt tell folks if they shyould continue doing asks
<didrocks> so we'll need mir as well
<asac> now the mail is out
<asac> so... :)
<didrocks> as it's built against it
<didrocks> and so platform-api for this mir abi bump
<didrocks> as well as u-s-c
<asac> didrocks: lets create this one for saviq
<didrocks> asac: ?
<didrocks> I disagree
<asac> well, your call :)
<didrocks> otherwise, there is no value, we just add more paperwork to our own soul
<didrocks> for the sake of it
<didrocks> and we aren't sure to have all pieces listed
<didrocks> nor the impact
<asac> Saviq: can you add an ask about fixing unity8 APs and give details about all the bits and pieces so we can coordinate getting all in?
<asac> thanks
<psivaa> didrocks: ogra_ i am seeing some issues with flashing with trusty image 2.
<psivaa> i get 'ERROR:phablet-flash:Installation is taking too long or an error occured along the way.'
<psivaa> the installation on my local maguro is hung on boot screen - Google and Padlock
<ogra_> psivaa, doing an OTA upgrade here atm ... lets see how that behaves
<didrocks> psivaa: interesting (and worrying)
<didrocks> ogra_: there was no hybris change right?
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/20131022.changes
<didrocks> so can't be an android/ubuntu mismatch?
<Saviq> are we planning to stop this landind-asks business at some point please?
<ogra_> i dont see one
<didrocks> Saviq: see asac's email
<sil2100> Mirv: thanks!
<ogra_> didrocks, lightdm and libpam are new ...
<ogra_> as well as lxc
<Saviq> didrocks, yeah, didn't find an answer to that question (other than "we'll discuss in OAK")
<ogra_> they look like the most possible candidates for the session not starting
<didrocks> Saviq: if there was a decision before the discussion, that wouldn't be a discussion
<asac> well said
<cjwatson> effective diff to pam is pretty small
<ogra_> cjwatson, yeah, let me test first to see whats up here
<cjwatson> lightdm or lxc seem more probable
<cjwatson> (neither was an autosync)
<ogra_> both just are obviously involved in session startup
<didrocks> knowing that lxc dropped a fix we still needed yesterday for otto
<didrocks> not sure if this one was useful for touch
 * ogra_ twiddles thumbs watching the android with rotating guts 
<didrocks>     - 0006-add-pstore-to-container-fstab.patch
<ogra_> we really should switch these animations to something ubuntuish :)
<didrocks> ogra_: we needed still that one for otto yesterday ^
<didrocks> not sure if it's relevant to you :)
<ogra_> didrocks, i thought that was upstreamed
<didrocks> ogra_: oh possible (we ship our own fstab for otto, that's why we noticed)
 * didrocks looks at the diff
<didrocks> yep, in -Index: lxc-1.0.0~alpha1/templates/lxc-ubuntu.in
<ogra_> ok,, seems the container is up fine
<ogra_> psivaa, confirmed btw
<didrocks> ok, so not lxc :)
<ogra_> right
 * ogra_ tries a manual start lightdm 
<psivaa> ogra_: thx
<cjwatson> I'd stop autosyncs but they aren't going to run for 4.5 hours anyway.  Let me know if it's needed
<ogra_> [+0.34s] DEBUG: Seat: Session authenticated, running command
<ogra_> [+0.34s] DEBUG: Registering session with bus path /org/freedesktop/DisplayManager/Session0
<ogra_> [+0.35s] DEBUG: Session pid=884: Running command /usr/sbin/lightdm-session ubuntu-touch-session
<ogra_> [+0.36s] DEBUG: Session pid=884: Logging to .xsession-errors
<ogra_> the lightdm log looks fine as well
<ogra_> root@ubuntu-phablet:/# ps ax|grep 884
<ogra_>   884 ?        Sl     0:00 lightdm --session-child 10 13
<ogra_> and lightdm runs
 * ogra_ digs into session logs
<Saviq> asac, didrocks, ask added
<ogra_> phablet@ubuntu-phablet:~$ start unity8
<ogra_> start: Job lÃ¤uft bereits: unity8
<asac> thanks!
<ogra_> oh wow
<didrocks> thanks Saviq
<ogra_> phablet@ubuntu-phablet:~$ ps ax|grep unity
<ogra_>  1565 pts/3    S+     0:00 grep --color=auto unity
<xnox> ogra_: FYI, your job is running away to unity 8 =)
<ogra_> lies !
 * xnox somehow finds technical translations to other languages amusing =)
<xnox> ogra_: status unity8?
<ogra_> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
<ogra_>   what():  Could not open hardware module
<ogra_> all xnox' fault !!!
<xnox> ogra_: right, let me check if unity/mir was rebuild with new boost. I thought I did.
<ogra_> xnox, well probably you did but it wasnt let out of CI
<ogra_> didrocks, ^^^
<didrocks> ogra_: I guess xnox is talking about directly uploads
<xnox> didrocks: ogra_: well mir was rebuilt, but not unity-system-compositor.
<didrocks> u-s-c isn't used on touch
<ogra_> didrocks, no idea i thought mir and unity were not direct
<xnox> ah, then no idea.
<ogra_> xnox, there is unity-mir though
<ogra_> which might need a respin too (not sure ask an expert)
<xnox> could be...
<didrocks> if a boost objects is leaked through mir, can be, xnox -> #ubuntu-mir?
<ogra_> ricmm, already up ? ^^^
<xnox> didrocks: templates do leak ABI/API mismatches, via transitive dependencies.
<xnox> didrocks: but that's "standard C++" feature.
<didrocks> xnox: yeah, it's more than possible that they use templates for their public class
<xnox> didrocks: I don't know the code, and only was rebuilding stuff which does link against boost libs.
<didrocks> (I asked there)
<didrocks> meanwhile, ogra_, can you try a rebuild of unity-mir on your phone?
<didrocks> should be quick enough to build
<ogra_> hmm
<ogra_> have to do that on maguro ... that wont be fast
<ogra_> but yeah, i can try
<cjwatson> xnox: I think you forgot to quote "feature" there too
 * didrocks smells some C++ love from cjwatson :)
<cjwatson> You might say I'm not a fan
<didrocks> heh :)
<cjwatson> didrocks: (http://gerald-duck.livejournal.com/591852.html is a good example - slides from *Bjarne Stroustrup* containing errors)
<cjwatson> top tip, if your language is so hard that its creator can't get it right in presentations, choose a new language
<didrocks> cjwatson: from Stroustrup? interesting :)
<didrocks> cjwatson: will read it for sure :)
<cjwatson> well, that's an article commenting on said slides, but yes
<didrocks> cjwatson: last time I really wrote a lot of C++ code was 7 years ago (I don't count the unity code I wrote as serious development), and yeah, I have feelings as well :)
<asac> psivaa: did we retry webbrowser?
<psivaa> asac:  not yet, looking at that to see if the failures were the same as before
<asac> right
<asac> thanks
<psivaa> asac: rerunning it again. i got it confused with weather app tests
<asac> slangasek: cjwatson: seems we have a first case of our imports/core-dev uploads caused touch to not boot anymore
<asac> slangasek: cjwatson: we thought it was just a rebuild related to boost regression, but seems that didnt make it
<cjwatson> asac: I haven't seen an analysis of what actually broke yet
<cjwatson> Just a guess, which you're now saying didn't turn out to be the problem after all?
<asac> cjwatson: what do you need to know? the symptoms?
<cjwatson> asac: I'm just saying that we don't know the cause yet
<cjwatson> AFAIK
<didrocks> Mirv: sil2100: is it getting better? I see a lot of red in http://10.97.0.1:8080/view/cu2d/view/Head/
<cjwatson> ogra_: Any progress tracking this down?
<asac> cjwatson: right. so a) who is looking and b) what is the course of action until we know
<asac> (that you suggest)
<cjwatson> asac: ogra_ was looking last I heard, and 12:27 <cjwatson> I'd stop autosyncs but they aren't going to run for 4.5 hours anyway.  Let me know if it's needed
<ogra_> cjwatson, not really, didrocks did a test rebuild of the packages but that doesnt seem to help
<asac> cjwatson: thanks!
<ogra_> he claims in #ubuntu-mir that he doesnt get a seat
<didrocks> I don't have lightdm starting automatically
<didrocks> (need to start it manually)
<ogra_> (works for me though)
<ogra_> let me reboot and see
<didrocks> ogra_: yeah, would like a confirmation
<cjwatson> If it's lightdm, foundations takes no responsibility :)
<ogra_> root@ubuntu-phablet:/# status lightdm
<ogra_> lightdm stop/waiting
<ogra_> not starting ...
<cjwatson> Though the effective diff in lightdm is virtually zero
<ogra_> http://paste.ubuntu.com/6282720/
<ogra_> ERR !
<ogra_> where is the rest of this file
<cjwatson> What package is that file in?
<ogra_> ubuntu-touch-session
<ogra_> ugh
<cjwatson> That's the full file in the source package
<ogra_> its like that in bzr too
<cjwatson> I'd expect it to be getting its script or exec from lightdm.conf
<cjwatson> Seeing as that's just the override
<cjwatson> I wouldn't expect you'd *need* the "rest of this file"
<ogra_> right seems that worked before so likely a red herring
<ogra_> i thought override overrides and doesnt merge :)
<cjwatson> No
<ogra_> k
<cjwatson> "Files ending in .override are called override files.  If an override file is present, the stanzas it contains take precedence over those equivalently named stanzas in the corresponding configuration file contents for a particular job.  The main use for override files is to modify how a job will run without having to modify its configuration file directly.  See the section Override File Handling below for further details."
<cjwatson> init(5)
<Mirv> didrocks: I didn't realize it had tried to run already. it's complaining about missing trusty cow image http://10.97.0.1:8080/view/cu2d/view/Head/view/Apps/job/cu2d-apps-head-1.1prepare-notes-app/338/console
<ogra_> root@ubuntu-phablet:/# status lxc-android-config
<ogra_> lxc-android-config start/post-start, process 599
<ogra_> 	post-start process 601
<ogra_> aha
<ogra_> looks like thats the issue
<ogra_> root@ubuntu-phablet:/# ps ax|grep 601
<ogra_>   601 ?        Ss     0:00 /bin/sh -e /proc/self/fd/9
<ogra_> hmm
<didrocks> Mirv: https://wiki.ubuntu.com/DailyRelease/MovingNewRelease First setup on the jenkins server
<didrocks> we need to create a release+1 pbuilder. Ping jibel for it.
<didrocks> (we need root access to create it, we don't have it
<Mirv> right, there it reads.
<Mirv> jibel: could you create trusty pbuilder?
<cjwatson> ogra_: could you pastebin the whole "ps auxfww"?
<vila> Mirv, jibel: I thought fginther was working on that yesterday ?
<ogra_> http://paste.ubuntu.com/6282741/
<jibel> Mirv, sure I can but I thought fginther did it
<cjwatson> ogra_: So /proc/$containerpid/root/dev/.coldboot_done never gets created, I guess
<cjwatson> Since it seems to be in that sleep loop
<ogra_> we didnt rebuild android, i wouldnt know why
<cjwatson> So where is that file expected to be created
<ogra_> root@ubuntu-phablet:/# lxc-info -n android|grep pid
<ogra_> pid: 	658
<ogra_> root@ubuntu-phablet:/# ls /proc/658/root/dev/.coldboot_done
<ogra_> /proc/658/root/dev/.coldboot_done
<cjwatson> In android, yes?  http://162.213.35.4/search?weighted=1&q=coldboot_done shows android_20131006-1510-0ubuntu6/system/core/init/devices.c:905 which I guess is related
<ogra_> so the file is there
<ogra_> and it worked before the #2 build
<cjwatson> http://launchpadlibrarian.net/154411166/lxc_1.0.0~alpha1-0ubuntu11_1.0.0~alpha2-0ubuntu1.diff.gz:
<cjwatson> -			printf("pid:%10d\n", initpid);
<cjwatson> +			printf("pid: \t%d\n", initpid);
<ogra_> oh my
<cjwatson> while lxc-android-config has:
<cjwatson>     containerpid="$(lxc-info -n android|grep pid|sed 's/^pid:.* //')"
<ogra_> yeah, i see it
<cjwatson> so that needs to be [[:space:]] instead of the ' '
<cjwatson> lxc triggered it but this is an lxc-android-config bug IMO :)
<ogra_> yay for building on assumptions
<ogra_> yes, it is
<jibel> didrocks, vila do you want me to proceed with the creation of the chroot or wait for fginther?
<cjwatson> ogra_: Beware similar bug in ./usr/bin/android-chroot
<cjwatson> ./usr/bin/android-chroot:3:pid=$(lxc-info -n android|grep ^pid|sed 's/^pid: .* //')
<ogra_> cjwatson, yeah, android-chroot is due to be removed
<cjwatson> ogra_: yeah, but if it isn't actually gone yet it should still be fixed
<ogra_> it doesnt do what the name suggests and people confuse it
<ogra_> i'll remove it with the same upload
<vila> jibel, didrocks: I'd rather check with him to avoid double work and so on, he should be here any time now
<fginther> morning
<vila> tada !
<vila> fginther: hey, perfect timing
<ogra_> hey, unity !
<fginther> vila, chroots?
<ogra_> and it feels a lot snappier (for 2min using it at least)
<vila> fginther: ?
<vila> fginther: pbuilder ?
 * cjwatson codesearches to see if there are any similar bugs elsewhere (which would argue for an lxc reversion if so; otherwise I think we should just fix lxc-android-config to tolerate the whitespace change and be done with it)
<fginther> vila, trying to figure out what the perfect timing is for, are we discussing the daily release chroots?
<cjwatson> lxc itself does this kind of thing:
<cjwatson>         initpid=`lxc-info -P $lxc_path -p -n $container | awk -F: '{ print $2 }' | awk '{ print $1 }'`
<vila> fginther: yeah, Mirv didrocks and jibel were wondering if the trusty pbuilder have been created, I said I thought you were doing just that yesterday
<vila> pbuilderS even
<fginther> vila, Mirv, didrocks, the pbuilders are setup for the upstream merger
<didrocks> fginther: no, cu2d uses it as well
<didrocks> with cow
<vila> same hosts ?
<fginther> vila, didrocks, I have not touched the daily release systems yet
<vila> fginther: will you ?
<Mirv> fginther: ok. me and sil2100 have been updating the cu2d configurations today and now it seems that on the head side the next step missing is the pbuilder (http://10.97.0.1:8080/view/cu2d/view/Head/view/Apps/job/cu2d-apps-head-1.1prepare-notes-app/338/console)
<fginther> Mirv, vila ack, I'll start work on that
<ogra_> asac, didrocks, xnox, fix uploaded, session should start again with the new lxc-android-config
<cjwatson> ogra_: All other callers of lxc-info in the archive use forms that will tolerate this whitespace change
<Mirv> thanks fginther
<ogra_> cjwatson, lxc-android-config now too :)
<cjwatson> ogra_: Thanks
<xnox> ogra_: didrocks: so it wasn't related to boost?
<ogra_> xnox, not at all
<xnox> asac: ^
<ogra_> xnox, lxc change that triggered a mis-parsing in lxc-android-config
<didrocks> ogra_: hum, it fixes the boot exception as well?
<jibel> fginther, the chroot is building, I also updated debootstrap on magners-o so it knows about trusty
<fginther> jibel, thanks
<ogra_> didrocks, unity starts after i changed the upstart job
<didrocks> oh, interesting
<ogra_> didrocks, feel free to try yourself
<ogra_> -    containerpid="$(lxc-info -n android|grep pid|sed 's/^pid:.* //')"
<ogra_> +    containerpid="$(lxc-info -n android|grep pid|sed 's/^pid:.*[[:space:]]//')"
<ogra_> in /etc/init/lxc-android-config.conf
<didrocks> asac: so not boost transition, new lxc need another change in lxc-android-config ^
<didrocks> ogra_: doing
 * didrocks stops his unity8 build
<ogra_> not another change
<ogra_> that code was there forever
<vila> fginther: thanks
<didrocks>   * make parsing the lxc-info output work with new lxc so our session can
<didrocks>     start again
<ogra_> yeah
<ogra_> lxc changed the output format of lxc-info
<didrocks> yeah, so lxc changed :)
<ogra_> the parsing above couldnt keep up with thatz
<didrocks> (that's what I meant)
<asac> didrocks: nice. i like blame-games :)
<didrocks> not parsing " " but needing [[:space:]]
<ogra_> yeah
<didrocks> asac: do we see score going up and down?
<ogra_> well, it should be safe now
<ogra_> i'll trigger a new image as soon as thats in
<didrocks> ogra_: I still wonder why that impact unity8 that way though (the boost exception we saw)
 * didrocks reboot
<ogra_> and will meanwhile debug video playback in webapps on maguro
<ogra_> didrocks, it will at least fill your disk with log spam
<Mirv> fginther: and after that the next missing step would be https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/switch_from_next_to_daily/+merge/192139
<ogra_> so it should be fixed asap
<ogra_> but i doubt it will do actusal harm
<ogra_> on my maguro the #2 image feels actually snappier
<ogra_> might be subjective though
<didrocks> heh :)
<didrocks> ogra_: confirming unity8 starts
<didrocks> nice debugging :)
<ogra_> :)
<didrocks> however, weird side boost effect in unity8 :-)
 * cjwatson scores up lxc-android-config
<didrocks> xnox: that was close!
<fginther> Mirv, looks good to me (did not top approve)
<didrocks> jibel: thanks
<jibel> fginther, Mirv trusty chroot is ready on m-o
<Mirv> jibel: thanks, looks good now from that perspective
<dobey> Mirv, pmcgowan: i have a contribution to qt i'm trying to get pushed to gerrit and am having some problems with git. either of you have a minute to help figure it out? the commit-msg (and maybe others) hook doesn't seem to be running for me when i do commit -a
<fginther> sil2100, in the services.cfg stack, thumbnailer was enabled for daily_release under saucy, but the head version is not
<Mirv> dobey: have you copied the hooks to the local checked out .git/hooks?
<dobey> Mirv: yes, that's the only place they exist
<kgunn> didrocks: ping
<Mirv> dobey: that to make it obvious, the instructions talk about  ~/.git but actually they need to be under the checked out repository's .git/hooks. I haven't heard of problems in using the hooks, other than they missing from the correct directory (hmm, not sure if chmod +x is needed)
<Mirv> so one line there is the cp -av ~/.git/hooks/* .git/hooks/
<dobey> Mirv: yes, they are only in the checked out repository, i don't have a ~/.git/ directory at all
<dobey> and i did chmod +x them
<Mirv> dobey: I can't think of any reason they wouldn't get executed. so you don't get the Change-Id in the comment then? and it's called "post-commit" (and not the wget:d "git_post_commit_hook")?
<Mirv> dobey: in other words I can't think of anything that is not already written on the instruction page
<dobey> i had it work once, but that was with the wrong committer/author e-mail, so i had to blow away the branch because i couldn't find any way to change the existing commit and trying to use revert made the branch worse. so i had to salvage my changes in a patch file, and make a new tree to do it in. but now it's not working
<Mirv> dobey: yep, that must be annoying.
<dobey> Mirv: yes, i followed the instructions correctly. when i do "commit -a" the huge commentary about [ChangeLog][][] and such is not coming up
<Mirv> :(
<dobey> Mirv: yes, every time i've ever used git, has been nothing short of wildly frustrating for me ;(
<didrocks> kgunn: pong
<kgunn> didrocks: hey...i'm premature...sorry....i need to get one more mp approved by ricmm for platform-api mir abi bump
<kgunn> i'll bother you later
<didrocks> ok
<kgunn> didrocks: question is....can i actually merge those mp's ? prior to mir getting pulled into the daily build ?
<kgunn> i worry about the order
<asac> didrocks: do we feel we have the issue fixed? :)
<asac> with the new lxc upload?
<ogra_> asac, yes
<didrocks> asac: lxc-android-config to fix for new lxc, yeah
<didrocks> asac: tested locally as well, confirmed by 2 people
<ogra_> waiting for it to come out of proposed
<asac> ok. then lets tackle the unity test fixes next :)
<asac> once we have that we are back to release state i feel
<ogra_> asac, then i'll do a new build
<didrocks> kgunn: well, mir trunk already have an abi break, so don't worry about it for now, just merge it
<didrocks> kgunn: please add a landing ask as well for the transition
<didrocks> FYI, we'll start landing again things tomorrow
<didrocks> sil2100: is everything working better now?
<asac> kgunn: can we please have a session or just do the source merge of the componnents that share libmirserver?
<asac> (and exporting a stable libmirserver for platform-api)
<asac> (just got reminded by hearing abi break)
<kgunn> didrocks: ack on landing ask
<didrocks> thanks ;)
<kgunn> asac: me more than anyone wants it to settle, unfortunately its not so easy....its the story of begets....we (unity&mir) would like to leverage qt scengraph & refactor mir-data-model....which means some more breaking, and its going to take some time, then we'll be in position to distill api
<sil2100> fginther: ah, so it seems the head-saucy pieces were out of sync
<Mirv> didrocks: I've been looking after the head now, and yes it's looking better and builds are starting to appear https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages?field.series_filter=trusty
<sil2100> didrocks: yes, Mirv prepared a branch that we missed and redeployed
<sil2100> It will be merged in soon
<didrocks> sil2100: Mirv: sweet! all prepare jobs cleaned as well?
<jdstrand> didrocks, kalikiana: regarding sensors> kalikiana told me I needed to add a rw access for apparmor. I did not upload that until just now (apparmor-easyprof-ubuntu 1.0.41) so it isn't surprising if testing didn't work
<didrocks> jdstrand: well, apparently testing did work when he did the landing ask, (and we saw it wasn't), hence the question
<jdstrand> I was waiting on feedback from this channel yesterday, but then saw the email this morning so I uploaded it
<didrocks> we want to ensure we write good guidelines for everyone to test their changes and try to identify gaps :)
<jdstrand> didrocks: I gave instructions on how to add the access
<didrocks> oh, so he did that manually and tested at the time
<Mirv> didrocks: sil2100: certainly not for the prepare job cleanage, there has been enough work to get this first run done. now finally we'll get up-to-date statuses at the head jobs.
<jdstrand> didrocks: so he probably had that but the testing didn't
<didrocks> ok, that makes sense :)
<didrocks> so yeah, we really need to have a big landing ask "group", with everything that was needed to make it work
<jdstrand> didrocks: I'm guessing that was the case, yes. no matter, now 1.0.41 is uploaded, people can just do that. if it doesn't work, check /var/log/syslog for denials
<didrocks> jdstrand: yeah, it's just that we need to write good guidelines for landing those kinds of interdependants change :)
<didrocks> thanks for the hint jdstrand :)
<jdstrand> mp
<jdstrand> np
<ogra_> asac, didrocks, lxc-android-config is in, triggering a #3 now
<didrocks> ogra_: \o/
<ogra_> build running
<asac> great
<plars> asac, ogra_: so what's the story on the channels? My understanding is that devel-proposed doesn't point at trusty for some reason yet?
<ogra_> plars, not for some reason no :)
<ogra_> plars, channels can only exist once they have content
<plars> ogra_: but there is a trusty image now, yes?
<ogra_> plars, until we publish trusty-proposed to trusty we cant switch devel
<plars> ogra_: but shouldn't devel-proposed point to the same thing as trusty-proposed?
<ogra_> (we could switch devel-proposed but that would cause confusion)
<cjwatson> ogra_: next cycle we should just copy saucy to trusty to start with
<ogra_> cjwatson, tzhats what i said in the meeting ;)
<cjwatson> no real reason not to do that, except that you have to continue the build numbers (you may or may not consider that a downside)
<ogra_> right
<plars> ogra_: It appears to be causing confusion the way it is now, it was my understanding that continuing to use devel-proposed for trusty images was the right thing to do
<ogra_> plars, once we have devel and devel-proposed populated with images, yes
<asac> cjwatson: i want the build numbers of devel to always go up :)
<asac> yes.
<asac> thanks!
<asac> :)
<asac> maybe should be seeded in our "how to do releases" wiki - so we wont forget next time
<cjwatson> feel free to add touch-specific things to NewReleaseCycleProcess as appropriate
<ogra_> asac, build numbers are moot ... as long as the OTS upgrader does the right thing
<ogra_> *OTA
<plars> ogra_: so are you saying there will be nothing for devel-proposed until an image is green enough to be marked "good"?
<ogra_> plars, yes
<ogra_> plars, unless asac wants to override that for #1
<plars> ogra_: that is a change from last cycle then right? We didn't track saucy proposed last cycle, but devel-proposed
<ogra_> i personally dont think #1 is worse than #101
<ogra_> plars, we didnt have system-image when last cycle began
<ogra_> oh, you mean *during*
<plars> but if trusty-proposed is going to really be the tip, and devel-proposed is just the images that have been accepted from trusty-proposed as good, then we should always just be testing trusty-proposed this cycle it seems
<plars> asac: ?^
<ogra_> well, sinc ethey wree equivalent back then ...
<ogra_> *were
<ogra_> plars, trusty = devel ... as soon as we switched
<ogra_> (and equivalently -proposed)
<ogra_> plars, saucy = stable
<plars> ogra_: but today, saucy=devel still
<ogra_> yes
<ogra_> until we can create a new devel channel
<ogra_> which we cant without an image in there
<ogra_> its a catch22
<cjohnston> I thought devel-proposed was a symlink to trusty-proposed
<ogra_> devel = saucy ... until trusty has its first image
<ogra_> then your assumption is true
<plars> ogra_: ok
<ogra_> cjohnston, plars, though since asac wants to keep saucy testing around too, we should always use the release name for utah i think
<ogra_> that should make it easier to distinguish
<plars> ogra_: ok, we'll just change to trusty-proposed in ci then, and leave it at that
<ogra_> right
<ogra_> that way you can still test saucy-proposed in parallel
<ogra_> and once Uneasy Unicorn starts we can have that in paralell asd well ;)
<asac> plars: yes ignore devel* for the time being
<asac> also ignore stable* in the same way :)
<ogra_> image #3 done btw
<didrocks> let's cross fingers for the dashboard!
<slangasek> ogra_: why does lxc-android-config have this coldboot check at all?  Why should it not be sufficient that 'lxc-wait' says the container is running, and the local bridge handling any other android events that are needed?
<ogra_> slangasek, ueventd
<ogra_> slangasek, it creates that file once it is done processing
<slangasek> right - but doesn't ueventd also set an android property?
<slangasek> which would be a better IPC mechanism than rooting around in /proc/$pid/root
<ogra_> slangasek, not sure, it is definitaley a candidate for revisiting this cycle
<ogra_> it should hook into the upstart-local-bridge i think
<ogra_> thats why we have it after all :)
<ogra_> ARGH !
<ogra_> didrocks, asac  ... lxc-android-config update isnt in #3
 * ogra_ definitely checked with rmadison before starting the build 
<ogra_> damned
<ogra_> err
<ogra_> hmpf
<ogra_> why did phablet-flash #2 for me again
<ogra_> didrocks, asac ignore the ablve
 * ogra_ doesnt get why he doesnt get #3 ... it was definitely there since a while when i fired off phablet-flash
<asac> ogra_: check with stgraber i guess
<ogra_> asac, well, i'm starting over now
<ogra_> just to be sure the error isnt on my side
<ogra_> probably the telekom has a new proxy i dont know about or some weird stuff
<slangasek> rsalveti: do you know if there's an android property that's an equivalent to /dev/.coldboot_done ?
<ogra_> ok, this time i got #3
<didrocks> ogra_: ok, it looks fine here
<ogra_> still flashing here
<ogra_> and probably taking half the meeting
<ogra_> maguro is slooooow to unpack the tarball
<asac> :)
<Mirv> back for the call
<didrocks> sil2100: Mirv: asac: ogra_: plars: joining? (let's try to keep it short and focused ;))
<sil2100> \o/
<plars> didrocks: will be there in a sec
<sil2100> Mirv: https://code.launchpad.net/~sil2100/cupstream2distro-config/transition_webapps_T/+merge/192184 <- can you quickly? :)
<asac> doanac: any idea why touch_custom is showing up ont he QA homepage? http://reports.qa.ubuntu.com/
<asac> e.g. why not touch?
<didrocks> hum, no robruâ¦
<doanac> asac: not sure. josepht, cjohnston: any idea why our trusty touch results aren't showing up in the KPI?
<doanac> we have a regex gone bad because of the variant changes?
<didrocks> cyphermox: around?
<cyphermox> yes
<doanac> plars: i think when we ran setup_jenkins we failed to enable the "publish" option
<didrocks> cyphermox: coming to https://plus.google.com/hangouts/_/calendar/Y2Fub25pY2FsLmNvbV91cTRvNmQyMWJvNmJ0bm1mcW9xZWtsNTdnOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t.cg7k3h1nmqml7psc1nn68223i0?
<plars> doanac: I'm 99.9% certain I did, but let me check my history
<plars> doanac: well, we see build 3 showing up, so I have to have enabled it
<doanac> yeah. n/m
<plars> http://reports.qa.ubuntu.com/smokeng/
<doanac> plars: we were missing touch_sf4p
<doanac> trying to figure out why
<cyphermox> argh, just a moment I'm not setup for voice atm
<didrocks> cyphermox: ok, don't worry for today then, sil2100 will tell you what is needed if you have time
<cyphermox> ok.
<cyphermox> sorry i broke some things  while clearing up / resetting stuff for an upgrade to trusty and all, and my headset is elsewhere :)
<sil2100> No problem ;) I'll poke you with some stuff later probably
<sil2100> Mirv: approve branch! Please ;)
<didrocks> cyphermox: see, never clear stuff, always go forward! :)
<sil2100> Mirv: ^
<Mirv> sil2100: maybe if you ask nicely ;)
<didrocks> ahah blackmailing! that's how it should be :)
<sil2100> Mirv: pretty pleaaaseee :D
<Mirv> done
<sil2100> Oh, magic word!
<ogra_> maguro #3 is good
<ogra_> didrocks, asac ^^^
<sil2100> Mirv: thanks! :)
<didrocks> ogra_: sweet! :)
<didrocks> let's hope we are getting good dashboard result
<didrocks> and publish an excellent first image trusty image tomorrow morning
<cyphermox> didrocks: the problem with going forward (at least for me) is that cruft accumulates
<asac> ogra_: good as in green on automation?
<didrocks> cyphermox: easy, don't make cruft :-)
<didrocks> </managerspeech> :p
<ogra_> asac, goog as in manual smoketesting done
<ogra_> *good
<cyphermox> didrocks: easy, hand over your scripts and tricks :)
<ogra_> (and passed)
<didrocks> cyphermox: ahah ;)
<fginther> vila, want to take a crack at review if it's not too late for you? https://code.launchpad.net/~fginther/cupstream2distro-config/upstream-merger-trusty-updates/+merge/192190
<cjohnston> doanac: asac working on the touch stuff on the dash
<vila> fginther: no, not too late, but missed the meeting *again*
<vila> fginther: approved, does that need an additional review from Mirv/sil2100 if only as a heads-up ? Or is it strictly upstream-merger only ?
<fginther> vila, this only touches upstream merger pieces, but would definitely welcome another look by sil2100 and/or Mirv
<rsalveti> slangasek: no, but we can add that
<rsalveti> slangasek: and indeed, we were checking for that file because we didn't have the bridge running when we did that
<rsalveti> we got a bunch of clean-up related WIs and this is part of it as well
 * fginther -> food
<slangasek> rsalveti: ok
<plars> asac: something is causing powerd-cli crashes now, not in every run though. would killing powerd-cli after using it to turn the display on do that do you think?
<plars> asac: actually, nm I don't think it could be that at all
<plars> asac: it's happening even on the install test, which doesn't ever run the pieces that unlock the screen or use powerd-cli to turn the display on
<asac> plars: can you reproduce on image 3?
<asac> but not on image 1?
<plars> asac: of the tests that we had on 1 at http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/1:20131021.1:20131015/4783/ I couldn't find any that had this powerd crash
<asac> ChickenCutlass: ^^
<asac> powerd crash
<plars> asac: ricmm said he'd take a look also when I pinged on #u-touch
<plars> asac: qmlscene crashes on the filemanager app test too, but that was in 1 as well
<dobey> where's the config for the upstream merger (the tarmac.conf) live at?
<asac> dobey: check with fginther
<dobey> fginther: ^^ if you're around?
<fginther> dobey, looking
<fginther> dobey, what exactly are you looking for? upstream merger doesn't use tarmac directly
<dobey> fginther: what commits the code to projects being merged with the CI/daily-release process?
<asac> plars: is this putting our dashboard results at risk?
<asac> or just investigation needed?
<fginther> dobey, https://launchpad.net/jenkins-launchpad-plugin
<plars> asac: tests are done and seemed pretty consistent asac for pass/fail, no, but it adds to the number of crash files
<dobey> fginther: ah, it's a fork of tarmac?
<plars> asac: from what I'm seeing, the testsuites failing on maguro are the same as the ones failing on mako for image 3, modulo a few extra system-settle failures on maguro which isn't too surprising. I'll try adjusting things on systemsettle as you recommended though and have it in the next build
<plars> asac: maguro would understandably be more sensitive to systemsettle though
<fginther> dobey, it's best described as a wrapper. tarmac is used internally for a few functions
<dobey> fginther: well half-a-fork then? it doesn't use the tarmac config stuff, or any of the plug-ins?
<fginther> dobey, No. From a quick look,  tarmac is just used to provide abstractions for bzr branches
<dobey> fginther: is there any way to do validation of contributors with the jlp autolander? this is a plug-in in tarmac, and allows us to check that contributors have signed the contributor agreement (because they get put in a special launchpad team when they do)
<fginther> dobey, I think this is what you want - https://bugs.launchpad.net/jenkins-launchpad-plugin/+bug/1134428
<ubot5> Ubuntu bug 1134428 in jenkins-launchpad-plugin "Reject MRs if people don't belong to specific group" [High,New]
<fginther> dobey, if tarmac already supports this as a plugin, than that's probably something that can be re-used here instead of re-invented
<dobey> fginther: yes, it supports it. i wrote the plug-in :)
<fginther> dobey, do you mind adding a pointer to the bug report?
<dobey> fginther: i would guess a lot of the stuff could be done directly with tarmac instead of having a fork that only uses the branching abstractions. we wrote tarmac to be generally quite robust in that sense. i didn't realize you guys had gone this far away from using tarmac, though :-/
<dobey> sure
<fginther> dobey, now would be a good time to revisit the divergence this cycle. May I pick your brain regarding tarmac in a week or two?
<dobey> fginther: sure, i can answer questions any time.
<fginther> sergiusens, how does phablet-tools get into ppa:phablet-team/tools? (it needs a saucy version)
<sergiusens> fginther, with a jenkins job
<sergiusens> fginther, done, added it here: http://10.97.0.26:8080/view/click/job/ppa-sync-phablet/
<fginther> sergiusens, thanks
<plars> asac: ok, after some systemsettle tweaking, results on mako(saucy-101), mako(trusty-3), and maguro (trusty-3) match - with the exception of the powerd crashes I mentioned earlier
<veebers> fginther: ping
<fginther> veebers, pong
<veebers> fginther: hey how are things? I wanted to ask you about this: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/2662/console
<veebers> it failed not because of a test failure
<veebers> looks like a dpkg error: E: Sub-process /usr/bin/dpkg returned an error code (1)
<fginther> veebers, there is a slew of unmet dependencies. Unfortunately, apt isn't very good at telling you what exactly is missing
<fginther> veebers, it's often a dependency at another level that is causing the problem.
<fginther> veebers, I can help debug
<veebers> fginther: awesome thanks
<veebers> fginther: I was wondering (hoping?) that maybe just firing it off again might do it, as all the other runs installed and worked fine
<fginther> veebers, I've seen lots of unity8 builds fail this way
<fginther> veebers, I have no idea what the actual problem is as no-one has asked about it until now
<cjwatson> fginther: That's usually skew between builds on different architectures, more commonly observed when build queues are long
<cjwatson> fginther: Since it's in saucy, I assume that the skew is in a PPA
<cjwatson> fginther: This is relevant when there's a mix of architecture-dependent and architecture-independent packages involved, with tight dependencies that constrain each other to be of the exact same version; behaviour then depends on the relative publication dates of builds for i386 and whatever architecture you're testing on
<fginther> cjwatson, there was actually another error message that looks like the cause of the problem:"unable to make backup link of `./usr/bin/unity8' before installing new version: Invalid cross-device link"
<cjwatson> That's not the cause of the apt messages
<fginther> cjwatson, oh?
<cjwatson> Oh, wait, maybe it is
<cjwatson> Yeah, that's bizarre.  Is some kind of filesystem tetris involved here?
<cjwatson> Because dpkg will be making a link from ./usr/bin/unity8 to ./usr/bin/unity8.dpkg-<some suffix>, which is never cross-device unless somebody's bind-mounted something onto ./usr/bin/unity8
<cjwatson> Sorry, I didn't notice that.  The problem I describe has very similar symptoms at the *end* of the log ...
<fginther> cjwatson, hmm, there's nothing funky going on, just trying to install into on a touch device
<fginther> cjohnston, veebers and I investigated a little further and assumed it was a packaging bug
<cjwatson> ./etc/init/boot-hooks/setcap-unity8.conf:29:        mount --bind "$RUNDIR/unity8" /usr/bin/unity8
<cjwatson> that's the cause
<cjwatson> and I believe I saw an MP go by that gets rid of that file in trusty?
<cjwatson> https://code.launchpad.net/~saviq/ubuntu/trusty/lxc-android-config/drop-unity8-setcap/+merge/192131
<cjwatson> so if you can get rid of that in saucy too, maybe you should?
<veebers> cjwatson: So I should update this bug an mark it as invalid as it's not actually an unity8 packaging issue? https://bugs.launchpad.net/unity8/+bug/1243432
<ubot5> Ubuntu bug 1243432 in Unity 8 "Packaging issue makes unity un-installable" [Undecided,New]
<cjwatson> veebers: It's not a bug in unity8; it's a bug in lxc-android-config
<fginther> cjwatson, what's the story for saucy and touch?
<cjwatson> fginther: I don't know
<cjwatson> veebers: I'll reassign it
<fginther> cjwatson, ack. I'll follow up with Saviq
<veebers> cjwatson: ah awesome, thanks for that
<fginther> cjwatson, yes, thank you
 * fginther has to leave for dinner
#ubuntu-ci-eng 2013-10-23
<didrocks> hey Mirv, how are you?
<Mirv> didrocks: hey, fine. I've been fixing 10+ prepare jobs this morning for head/saucy, but there's still work to do
<didrocks> Mirv: sil2100 didn't finish it and didn't email you?
<Mirv> didrocks: I don't think he worked on those, I saw the same prepare jobs yellow as yesterday
<Mirv> (no e-mail)
 * didrocks wonders why fixing prepare jobs is taking so long.
<didrocks> Mirv: urgh :/
<didrocks> ok, I'll talk with him
<didrocks> I'm looking at why the jobs FTBFS
<Mirv> didrocks: oh, I started using the Stack status for trusty and filed first FTBFS bugs https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dHFtUmlPOUtCRk8zR2dtaEpIbUVhMmc#gid=3
<didrocks> Mirv: ah, excellent! looking :)
 * didrocks adds https://bugs.launchpad.net/ubuntu/+source/mediascanner/+bug/1243536
<ubot5> Ubuntu bug 1243536 in mediascanner (Ubuntu) "mediascanner FTBFS in trusty" [Undecided,New]
<didrocks> and https://bugs.launchpad.net/autopilot-gtk/+bug/1243538
<ubot5> Ubuntu bug 1243538 in autopilot-gtk "autopilot-gtk FTBFS on trusty" [Undecided,New]
<didrocks> jibel: hey!
<Mirv> didrocks: the prepare jobs are now fast to fix (I'm now at ~15/20), there was just so much to do before that. on Monday I started with the thought there's just small bits needing to be done, while actually most of the transition was not done at all.
<didrocks> Mirv: urgh, okâ¦ I hope we'll get better at next release opening
<didrocks> Mirv: there are some in saucy as well it seems
<didrocks> Mirv: I'm pocking people to get their FTBFS fixed
<Mirv> didrocks: yeah.. as I was away for a few days, and you mentioned something along the lines that it's about done but sil missed a few, I was under wrong impression. during Mon & Tue then the actual transition was done with me + sil + fginther.
<Mirv> didrocks: yeah, I've fixed around 8/14 of the saucy prepare job problems now
<didrocks> Mirv: ok, good luck :)
<didrocks> I'm more wondering why sil2100 didn't email/continue yesterday
<didrocks> because the FTBFS were not handled
<didrocks> nor the prepare jobs
<didrocks> nor the -check issue (no access to archive.ubuntu.com)
<didrocks> vila: did you get any email? this is blocking us
<didrocks> vila: from magners-orchestra, I can't ping archive.ubuntu.com
<didrocks> unfortunately, as sil2100 didn't share any info (I guess he pinged retoaded privately), we don't know where we stand
<didrocks> asac: FYI ^
<vila> didrocks: can't ping from m-o, filtered by the IS firewall, I use wget for that kind of tests, and wget archive.ubuntu.com works
<vila> didrocks: so, what's the issue ?
<didrocks> vila: http://10.97.0.1:8080/job/autopilot-trusty-daily_release/9/label=autopilot-nvidia/console for instance
<didrocks> /var/log/upstart/otto-setup.log:   Could not resolve 'archive.ubuntu.com'
<didrocks> vila: seems to work from outside the container
<cjwatson> that doesn't sound like a firewall problem - you wouldn't be getting a DNS failure in that case
<didrocks> (using wget)
<sil2100> Hi
<cjwatson> more likely busted resolv.conf or something
<sil2100> didrocks: retoaded had this to say (I though he was fixing that):
<sil2100> <retoaded> sil2100, looking through the console output in the job then looking at dx-autopilot-nvidia it appears that the LXC network bridge (lxcbr0) doesn't have an interface assigned so it doesn't have a network path outside if itself.
<sil2100> <retoaded> nor are there any iptables rules in place to route the network traffic from lcxbr0 to eth0
<sil2100> This was close to my EOD
<didrocks> sil2100: hum, weird, something changes on the machine, we got a successful snapshot (and it was the raring machines)
<sil2100> hmm
<didrocks> jibel: do you remember we are doing any bridge manual setup on the hosts for otto? ^
<didrocks> sil2100: btw, Mirv is finishing the prepare jobs, (apparently he didn't find any branches)
<vila> didrocks: urhg :-(
<jibel> didrocks, we don't do anything the bridge is handled by lxc in the upstart job lxc.conf
 * didrocks continues on libaccounts-glib FTBFS
<didrocks> maybe a regression from latest lxc?
<didrocks> vila: are you on it? ^
<vila> didrocks: not for now, I'm on upstream-merger for trusty but I can switch if needed
<jibel> lxc-net.conf actually
<vila> didrocks: which also involve otto and a container so I may run into the same issue...
<didrocks> vila: ok, so upstream-merger is blocked as well?
<vila> didrocks: for trusty yes (unless fginther did something I'm not aware of)
<Mirv> sil2100: I noticed that you had two branches, but there were 17 prepare job problems all in all - now fixed
<didrocks> Mirv: all fixed? \o/ (saucy as well?)
<vila> didrocks: as for cu2d on phones, I've seen MPs from doanac but no firm confirmation is was ready to be plugged...
<didrocks> vila: ok, keep us posted once he's online. I guess the priority is upstream-merger/otto, while we are working with upstream to fix FTBFS
<vila> didrocks: /me nods
<Mirv> didrocks: yep, saucy as well
<didrocks> Mirv: thanks a lot! seems it wasn't that long after all ;) not sure why sil2100 wasn't able to finish it
<didrocks> (the accounts-glib FTBFS is really puzzling)
<vila> didrocks: still, for my sanity/understanding, http://10.97.0.1:8080/job/autopilot-trusty-daily_release is a step (or several) further than the setup we did with you jibel for otto ?
<didrocks> vila: it's the otto job, the one running the tests
<didrocks> but it can't get to archive.ubuntu.com for any reason inside the container
<vila> didrocks: I thought we were able to create a container which includes an apt-get update right ?
<didrocks> so the tests are failing
<didrocks> vila: right, on Monday
<vila> didrocks: so that's a regression right ?
<didrocks> vila: sounds like it
<vila> didrocks: ok, thanks
 * vila restores a tiny bit of sanity
<vila> didrocks: could it be something similar to the [[:space:]] issue encountered on the phone yesterday ?
<ogra_> hmm, was the dashboard CSS updated or sis my browser just decide to use a completely different font on its own  ?
<didrocks> vila: maybe
<ogra_> s/sis/did/
<ogra_> system-image-cli -c trusty-proposed -v
<ogra_> ...
<ogra_> [systemimage] Oct 23 09:19:13 2013 (22849) Already up-to-date
<ogra_> HMPF
<ogra_> root@ubuntu-phablet:/# system-image-cli -i|grep channel
<ogra_> channel: saucy-proposed
<ogra_> that doesnt look right
<didrocks> ogra_: there are multiple files for the channels
<didrocks> ogra_: at least 2
<didrocks> so I won't be surprised there is a bug somewhere
<ogra_> didrocks, well, the above should switch me to trusty-proposed
<ogra_> according to the docs
<didrocks> ogra_: right, maybe it's just updating the wrong file :)
<ogra_> and i know it worked for pat mcgowan yesterday
<didrocks> ah, interesting
<didrocks> RO image?
<ogra_> oh, wait
<ogra_> i tested something ...
 * ogra_ checks for writable_image
<ogra_> right, its rw
 * ogra_ removes and reboots
<didrocks> ok, was worth lookingâ¦
<ogra_> doesnt change even in ro
<sil2100> Mirv: there were more branches, I pasted like 8 branches to cyphermox before going EOD
 * ogra_ phablet-flash'es .... hoping his data wont be wiped
<sil2100> didrocks: I pasted all the branches that needed merging to cyphermox, and I see 2 of those didn't merge in because of merger failures
<didrocks> sil2100: branches that you handled?
<didrocks> argh, so duplicate work because of no email/communcation :/
<sil2100> hm, could be, I thought Mathieu handled those as I pasted those to him - but let me check what's the status with that
<sil2100> Mirv: which branches did you have to fix? As I fixed all yellow prepare jobs that I saw yesterday, at least preparing merges for those from the Trusty side
<didrocks> sil2100: btw, any opinion on #ubuntu-unity?
<didrocks> vila: ok, seems 1.0.0~alpha2 is guilty
<didrocks> downgraded to alpha1 and no issue
<didrocks> (lxc)
<vila> didrocks: lxc on the host right ?
<didrocks> vila: right
<didrocks> then, there is another issue I'm debugging
<didrocks> aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/trusty
<didrocks> hum, lsb-release is fine though
<vila> good, the use case for upstream-merger is slightly different as we use saucy on the host so I may be immune, will know soon
<didrocks> vila: I'm going to hold lxc upgrade
<vila> didrocks: rings a bell, heard something I didn't followup closely about patching distro-data manually :-/
<didrocks> vila: well, ubuntu.csv contains 14.04 LTS,Trusty Tahr,trusty,2013-10-17,2014-04-17,2019-04-17
 * vila sighs
<vila> didrocks: something else then :-/ Sorry
<ogra_> sigh
<ogra_> so switching to trusty with pahbelt-flash works, but all installed apps are gone
<ogra_> thats annoying :/
<wgrant> didrocks: python-apt-common needs updating
<vila> ogra_: I got that even without switching (i.e. image 101)
<didrocks> wgrant: ah, that's the one! thanks :) I can do it
<vila> ogra_: but I had to redo the restoring part of the backup manually (adb got stucked but I copied the backup.tar.gz during phablet-flash, lucky me)
<wgrant> Amusingly there's a new one stuck in proposed because bzr-builddeb autopkgtest failed.
<didrocks> ah, indeed :)
<ogra_> vila, well, by the looks of it it didnbt even do a backup, it just didnt touch my homedir
<vila> ogra_: so it failed to restore it , didn't phablet-flash hang ?
<ogra_> nope
<ogra_> just went through
<ogra_> i also didnt get a full image ... which i thought i was supposed if i swithc channels
 * ogra_ will wait for stgraber 
<Mirv> sil2100: right, I only saw the unmerged ones. so also fix needing in trusty were libcolumbus, autopilot, mtp, compiz, and in saucy some 10+ more
<Mirv> didrocks: can you redeploy head unity8 + mir for the unity-mir move? I can't deploy the latter since I don't have rights to lightdm
<didrocks> Mirv: sure, only head, right? nothing to deploy for saucy?
<Mirv> didrocks: I didn't touch saucy for those, and mir is already disabled there
<didrocks> Mirv: reminder: when we move/removed things, you need to delete by hand the jenkins job
<Mirv> didrocks: I remember that
<didrocks> Mirv: ok, deployed
<Mirv> thanks, cleaned the unity-mir from unity8
<didrocks> thanks ;)
<sil2100> Mirv: right, saucy! I only posted the trusty merges to cyphermox it seems!
<didrocks> sil2100: can you relaunch the jobs where the prepare jobs failed?
<didrocks> just to ensure we are all good on that one at least
<sil2100> Mirv: sorry about that, we duplicated work because of that
<sil2100> didrocks: the saucy failures you mean? Sure
<Mirv> sil2100: I don't think there was any duplicates beside the autopilot + ui-toolkit, since you didn't start on the saucy, plus the trusty ones I did didn't have branches from you?
<Mirv> FYI unity-system-compositor was missing from head before didrock's redeploy. I'll now compare all stacks side-by-side head vs. saucy and clean up eg. removed jobs
<sil2100> didrocks: it seems all of those stacks were already ran and are now green for saucy \o/
<sil2100> didrocks, Mirv: what should we do with stacks that have no components in them anymore?
<sil2100> (in saucy)
<sil2100> Should we remove those altogether?
<didrocks> sil2100: and head?
<didrocks> sil2100: if you can remove them from config + jenkins, I guess that will help clarifying, yeah
<didrocks> thanks Mirv, sil2100
<sil2100> didrocks: clean as well
<didrocks> grrr, I can't reproduce the bzr-builddeb failure on saucy, even upgrading latest python-apt
<didrocks> will need a trusty chroot I guess
<sil2100> didrocks, Mirv: ok, I'll clean up the empty stacks then, as we see now that more or less things are working right now
<sil2100> didrocks: !
<sil2100> didrocks: I'm just checking my mail and I got a mail from Larry about the lxc issues, let me take a look
<sil2100> didrocks: hah, let me forward it to you
<cjwatson> didrocks: what was the lxc failure?
<Saviq> didrocks, any word on unity-mir and lxc-android-config release?
<sil2100> didrocks: it seems the issue is a bit bigger
<didrocks> cjwatson: I didn't debug it yet, just downgraded, I'm on the bzr-builddeb autopkgtests failing which is blocking otto as well
<didrocks> but hard to reproduce, can't start in the isolated env (following the doc from http://developer.ubuntu.com/packaging/html/auto-pkg-test.html#executing-the-test) but http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-disk1.img doesn't exist yet
<sil2100> didrocks: forwarded the e-mail, seems like retoaded forwarded the problem to Larry and he made an investigation
<didrocks> not sure what adt is using then
<didrocks> Saviq: we need first to be able to run the test infra
<cjwatson> IIRC adt-virt-lxc isn't actually packaged yet
<didrocks> Saviq: and trusty seems not ready for it yet, so working on it
<Saviq> didrocks, :/
<Saviq> didrocks, k thanks
<didrocks> ok, I think I have to upgrade to trusty to hope reproducing the bzr-builddeb autopkgtests issue
<didrocks> at least, the 3 errors seems to have a common ground
<didrocks> the first one seems more hectic
<didrocks> vila: getting any progress on your side on the upstream-merger one?
<Mirv> ok head is up-to-date, with the only exception being cordova-ubuntu which will need some more info before adding it - ie. is the 3.0 branch ready to be released (I think not, there are among else hard-coded reference to 2.8 in the SDK)
 * cjwatson would like to make it clear that the fact that you're blocked on python-apt in trusty is another casualty of Mark being slow to announce the name
<sil2100> didrocks: it anyway seems that the DNS issues we're encountering are some strange apparmor issues
<cjwatson> If we'd had the new name in a timely fashion then we could've had support for it in saucy
<sil2100> Mirv: yeah, I saw cordova-ubuntu trunk when I was doing the splitting and didn't see a debian/ directory then even
<sil2100> Not sure how it is now
<Mirv> sil2100: I'm sure the webapps team will let us know when they want it - they've promised that they'll also update the sdk at that time
<didrocks> cjwatson: I think it's clear to all of us TBH
<didrocks> cjwatson: I'm trying to look at what exactly broke in lxc after the meeting
<cjwatson> didrocks: Yeah, I just wanted to hammer it home :)
<didrocks> ;)
<didrocks> TBH, if we get everything running (including CI) less than a week after the release name was given, it's already an achievement TBH
<didrocks> diverging all branches, and so onâ¦
<didrocks> we are not rolling, so we can't have a "no time interruption" as if we had it. I think people should understand that
<cjwatson> I agree, but there's always pressure to be faster and I really resent having to break promises I've given because of something as simple as a name
<vila> didrocks: almost ready to do a run but I lack some context from fginther :-/
<cjwatson> And really, if we didn't have that blocker as we've had for the last three cycles, we could be open again almost immediately
<didrocks> oh 3? I was thinking it was only 2â¦
<cjwatson> Three
<cjwatson> We got raring's name about a day before quantal released, which was too late to add proper support to quantal
<cjwatson> And even the cycle before that, we only had three days' notice, which wasn't enough
<cjwatson> The cycle before that (so precise's name) we had eight days' notice, which was still less than I'd like but it was manageable
<cjwatson> The cycle before *that* we had 52 days' notice
<sil2100> Mirv: right
<cjwatson> I don't think I'll be on this morning's standup, I've had five hours' sleep due to kids invading the bed and I don't think I can manage coherent conversation in actual speech
<vila> didrocks: it failed, that's progress ;) The trusty container doesn't exist, now to find where it's create...
<vila> *created
<didrocks> cjwatson: no worry ;)
<vila> didrocks: it failed with an understandable error which is nice
<didrocks> heh
<didrocks> vila: joining?
<vila> didrocks: yup
<ogra_> popey, mind to test trusty-proposed ? we dont have call/sms tests for that yet
<popey> ogra_: sure thing
<ogra_> thx
<ogra_> i think didrocks tested the rest already
 * popey OTA's
<ogra_> from saucy ?
<popey> no, from 14.04
<ogra_> ah, k
<popey> I mean, OTA from saucy would be nice
<popey> but I suspect we're not planning to support that?
<ogra_> bug 1243573, bug 1243577
<ubot5> bug 1243573 in ubuntu-system-settings (Ubuntu) "Timezone setting is gone after upgrade to Ubuntu Touch touchy" [Undecided,New] https://launchpad.net/bugs/1243573
<ubot5> bug 1243577 in system-image (Ubuntu) "All apps are gone after upgrade to trusty" [Undecided,New] https://launchpad.net/bugs/1243577
<ogra_> thats non OTA though ...
<popey> yeah, i flashed clean trusty-proposed on monday iirc
<popey> maybe tues
<ogra_> i tried to switch the channel from cmdline using system-image-cli -c ... but that didnt work :(
<ogra_> it pulled the channel properly from what i saw with -v but told me i'm up to date
<popey> ogra_: sms and calls work fine in both directions
<ogra_> awesome, thanks
<ogra_> didrocks, asac ^^^
<didrocks> ogra_: please promote then! :)
<didrocks> popey: ^
<ogra_> will do
<ogra_> (or try to, not sure if the script behaves ... first trusty image etc)
<asac> ogra_: pay attention to what might have broken after :)
<asac> i am sure all phablet-flash will go crazy hehe
<didrocks> vila: so after a reboot, still nothing (worked on the nvidia machines, not on others FYI): http://10.97.0.1:8080/job/autopilot-trusty-setup_otto/label=qa-intel-4000/6/console
 * didrocks will classify that as "unknown other issues"
<ogra_> asac, i wont switch the devel or devel-proposed channels, thats stgraber stuff ...
 * ogra_ will just promote trusty-proposed to trusty
<popey> ogra_: lemme know when and I'll test reflashing without --no-backup
<vila> didrocks: makes sense since update_host ... update the host and the container so get the latest lxc no ?
<didrocks> vila: lxc in the container -> we don't really care
<didrocks> it's only the host one which is used
<vila> didrocks: update_host update the *host*
<ogra_> popey, didrocks, asac trusty 3/20131022.1 promoted
<didrocks> vila: yeah, but as told in the hangout, I hold lxc
<didrocks> vila: just try apt-cache policy on the machine to check
<didrocks> lxc:
<vila> didrocks: I'll start with that once done with u-m
<didrocks>   Installed: 1.0.0~alpha1-0ubuntu11
<didrocks>   Candidate: 1.0.0~alpha2-0ubuntu3
<didrocks>   Version table:
<didrocks>      1.0.0~alpha2-0ubuntu3 0
<didrocks>         500 http://us.archive.ubuntu.com/ubuntu/ trusty/main i386 Packages
<vila> didrocks: ack
<didrocks>  *** 1.0.0~alpha1-0ubuntu11 0
<didrocks>         100 /var/lib/dpkg/status
<didrocks> for instance
<didrocks> ogra_: thanks!
<popey> ogra_: thanks, will test
<vila> didrocks: for u-m update_host needs a tweak since it want to create a container for the host release (aka saucy here when I want a trusty container)
<didrocks> vila: are you using update_host to create the container? not otto directly?
<vila> didrocks: I'm using nothing for now ;) Looking at update_host for at least getting which parameters otto wants
<didrocks> asac: status email sent
<vila> didrocks: container building
<vila> didrocks: lxc_container: command get_init_pid failed to receive response harmless ?lxc-ls
<vila> grrr
<popey> ogra_: right, so flashing from saucy to trusty wipes /opt/click.ubuntu.com â¹
<asac> didrocks: thanks!
<popey> do we have a bug for that?
<ogra_> popey, yup
<ogra_> popey, bug 1243577
<ubot5> bug 1243577 in system-image (Ubuntu) "All apps are gone after upgrade to trusty" [Undecided,New] https://launchpad.net/bugs/1243577
<popey> ta
<vila> didrocks: 2013-10-23 05:36:55,304 INFO Starting container 'trusty-amd64-20131023-0529'
<vila> lxc_container: command get_init_pid failed to receive response
<vila> didrocks: rings a bell ?
<didrocks> vila: can be anything meaning that lxc-start didn't work
<vila> ack, looking into that already, thanks
<didrocks> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1181136
<ubot5> Ubuntu bug 1181136 in lxc (Ubuntu) "Empty log file when a container is started with the API" [Medium,Confirmed]
<vila> didrocks: great :) subscribed... read.... :-/
<didrocks> vila: there was another one I can't find right now about no log at all in stdout when using the python bindings
<vila> didrocks: seems to be related to the pre-start.sh indeed:
<vila> + [ -e /sys/fs/cgroup/memory/lxc/memory.use_hierarchy ]
<vila> + echo 1
<vila> lxc-start: Script exited with status 1
<didrocks> again the same issue :/
<vila> whic is weird since that's commented out
<didrocks> vila: is it really? we reverted IIRC
<vila> didrocks: let me check on dx-autopilot-intel, on ps-radeon-hd8350 otto is up to date with lp:otto
<didrocks> vila: dx-autopilot-intel is a saucy machine, right?
<vila> roght
<vila> didrocks: ~ubuntu/otto is up to date, but ~jenkins/otto is not, stooopid vila
<didrocks> vila: you ps-radeon-hd8350?
<vila> didrocks: http://10.97.0.26:8080/job/autopilot-testrunner-otto-trusty/9/console so, tests are running but seem to be failing
<didrocks> vila: some are passing, so sounds good
<didrocks> vila: what stack is it?
<vila> didrocks: suspicious messages /var/log/syslog: Oct 23 10:01:36 trusty-amd64-20131023-0529 kernel: [60980.789436] [drm:radeon_dvi_detect] *ERROR* DVI-I-2: probed a monitor but no|invalid EDID
<vila> didrocks: http://10.97.0.26:8080/job/autopilot-testrunner-otto-trusty/9/parameters/?
<vila> didrocks: so unity8 IIUC
<vila> didrocks: I used the same parameters as fginther did on the previous runs
<didrocks> vila: making sense for unity8 to fail
<vila> didrocks: I think I'll stop on that one as I've already far too many unknowns to check with fginther
<vila> will look at qa-intel-4000 instead
<didrocks> vila: ok, thanks
<vila> didrocks: clarification, when you say 'I hold lxc' you mean on the host or in the archive ? I think we were having two discussions intermixed, me talking about ps-radeon and you talking about qa-intel.
<vila> didrocks: on qa-intel the container creation is failing so my question is: can use update_host there or will that bring the latest lxc back ?
<vila> didrocks: or will I get the same absence of usable error message by running update_host manually :-/
<didrocks> vila: i hold the package on previous lxc on the 3 machines
<vila> well, lxc not updated and same messages...
<vila> didrocks: right, how do you achieve that ?
<didrocks> vila: apt-mark hold <binary_package>
<vila> didrocks: thanks
<didrocks> yw
 * vila breaks for lunch
<sil2100> didrocks, vila: how's progress with otto? Any luck?
<didrocks> sil2100: I guess it's for vila
<vila> sil2100, didrocks: I don't think it solved itself during my lunch but I'll know that soon ;)
<sil2100> ;)
<vila> right, still the same, the container creation fails... with not a single msg when done from update_host, I need to drill down
<Mirv> meanwhile another round of autobuilds is progressing nicely
<sil2100> Mirv: were you able to contact anyone from upstream for https://bugs.launchpad.net/libfriends/+bug/1243527 ?
<ubot5> Ubuntu bug 1243527 in libfriends "libfriends FTBFS on trusty" [Critical,New]
<Mirv> sil2100: didier pinged robru about it
<Mirv> sil2100: (as it says on the stack status page)
<Mirv> sil2100: robert will ping ken in the morning
<sil2100> Mirv: ah! Right, it's been such a long time since we used that, I need to get my habits back
<Mirv> didrocks: I was finally able to do a proper retrace, it seems apport has various bugs in handling non-English locale that don't even show up as such. bug #1243665 "QUbuntu: Could not create application instance" so might be even mir or such problem
<ubot5> bug 1243665 in qtdeclarative-opensource-src (Ubuntu) "qmlscene crashed with SIGABRT in raise()" [Undecided,Confirmed] https://launchpad.net/bugs/1243665
<vila> right, so apparmor DENIED on host's /var/log/syslog during lxc-create AFAICS http://paste.ubuntu.com/6288480/
<vila> didrocks: you did reboot after downgrading lxc right ?
<didrocks> vila: yeah, on 2 of the 3 machines
<didrocks> but as it's failing on 2
<vila> didrocks: I'm on qa-intel-4000 for now, pinged stgraber in #ubuntu-server
<vila> didrocks: the denied are for operation="mount" on /dev/input  /dev/dri but the weird thing is that the pid (16121) is the same for all creations but I can't find that process in 'ps fax'
<vila> damn, re-trying again, the apparmor msgs don't come back...
<vila> didrocks: no log files under /var/log/lxc for any container I tried to create, the last one if for trusty-i386-20131023-0008 but has been updated 10 minutes ago ???
<didrocks> vila: you are trying to create with otto?
<didrocks> or lxc-create directly?
<vila> otto
<vila> hoping to find some msgs somewhere and avoid issues reproducing the way otto calls lxc-create, will try to do that now
<didrocks> *sigh* I pointed to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1181136
<ubot5> Ubuntu bug 1181136 in lxc (Ubuntu) "Empty log file when a container is started with the API" [Medium,Confirmed]
<didrocks> vila: that why I pasted that bug ^
<vila> didrocks: for the lxc log itself, doesn't mean nothing can be found elsewhere
<didrocks> vila: what other non lxc logs you were expecting to get in /var/log/lxc?
<vila> didrocks: no idea, that 's why I looked and it's still weird that an old log file modification time changes, but I won't dig why as I doubt it's related
<vila> didrocks: using otto directly doesn't provide more output so I need to drill down to the lxc-create command but otto "prepares" a lot of stuff first (which are relevant is still unclear...)
<vila> didrocks: otto -d gives some hint but still fails too quickly.... that rings a bell
<vila> <container:209 - MainThread> 2013-10-23 12:32:59,910 INFO Container 'trusty-i386-20131023-1216' started
<vila> <commands:172 - MainThread> 2013-10-23 12:32:59,911 ERROR An error during creation occurred, trying to cleanup the container: The container didn't st
<vila> 910 started, 911 ERROR, that's a little too fast
<didrocks> vila: the issue is clearly in lxc creation
<didrocks> and as per bug I posted above, you won't get any info from the container in lxc
<didrocks> due to the python bindings
<didrocks> so you need to start lxc-create by hand
<vila> didrocks: which otto doesn't display nor the context it requires either as per   This method creates a new container from scratch. We don't want to use
<vila>         the create method from LXC API because the bootstrapping phase is not
<vila>         required and replaced by using an Ubuntu image directly.
<didrocks> vila: otto can't display the lxc logs as per bug :/
<didrocks> vila: it's call lxc-start
<didrocks> calling*
<vila> didrocks: but it could display which lxc-create command it want to execute or are you .... no lxc-create ??
<vila> at all ?
<didrocks> no lxc-create, lxc-start on the container
<didrocks> so a classic lxc-start -n <last_container_name_without_broken._prefix>
<didrocks> so you look at what container it created last
<didrocks> you mv broken.<container_name> <container_namer>
<didrocks> and sudo lxc-start -n <container_name>
<vila> pfew...... mv broken. good to get the context creted by otto, I see
<didrocks> vila: broken. is to not reuse the broken container
<didrocks> but not removing it
<didrocks> so that you can still debug
<didrocks> and you stay on latest good container
<vila> yeah, got that, confused because the last debug session I saw was Mirv extracting the delta, different case
<vila> didrocks: and if I haven't read lxc-create when you wrote lxc-start earlier....
<vila> didrocks: lxc-start succeeds....
<didrocks> vila: well, the second time, I wrote lxc-create TBH (because of broken mind)â¦
<vila> didrocks: nevermind, let's go ahead and fix that crap if we can without stgraber help
<vila> didrocks: hmm, the container just logged me out and terminate
<didrocks> because it finished its upgrade
<vila> didrocks: now I'm confused. If it starts properly and halt properly, what are we searching for ?
<didrocks> vila: are you sure it's doing everything properly?
<didrocks> if it didn't exit 1, yeah, there is an issue
<didrocks> if you are starting the right container
<vila> didrocks: no, not even sure I started with good one, so let me re-start that from scratch, update_host, use that one
<vila> didrocks: http://paste.ubuntu.com/6288876/
<didrocks> vila: it exits 1, right?
<vila> didrocks: lxc-start ? 255
<didrocks> vila: soâ¦ not 0, hence the command failing I guess
<vila> didrocks: but it's not the same behavioras when run from otto (,910 -> ,911 earlier) I'd say
<vila> behavior as
<didrocks> weird
<vila> not a spanish variant ;)
<vila> ISOID=ubuntu_14.04_lts_trusty_tahr_release_i386_20131021.1
<vila> didrocks: expected ? nothing fresher ?
<didrocks> vila: you can check yourself at http://cdimage.ubuntu.com/daily-live/current/ :)
<didrocks> 21-Oct-2013 13:57
<didrocks> which seems to match
<vila> didrocks: yeah, thanks, sorry, memory overflow ;)
<cjwatson> vila: we haven't re-cronned yet - that was a manual build to let didrocks get otto working
<vila> didrocks: so, for this specific lxc-start we're booting from the iso and creates rootfs no ?
<didrocks> vila: yeah, we did on Monday
<vila> cjwatson: ha, good, thanks ! Yeah heard about that, now I *see* it ;)
<vila> didrocks: ha, no, bases/<something>
<vila> didrocks: is that correct ? first lxc-start creates the root fs under <lxc-name>/bases ?
<vila> didrocks: and the others lxc-start will use a snapshot on top of that right ?
<didrocks> vila: right
<fginther> morning
<vila> didrocks: nothing weird in the logs inside the container :-/
<vila> didrocks: will create yet another and look under bases/ before starting
<vila> fginther: hey ! Let's sync about trusty for u-m in a few minutes
<fginther> vila, ack. let me catch up a moment first
<vila> fginther: perfect
<vila> didrocks: ha ! no logs (except for faillog and lastlog)
 * didrocks in meetings
<vila> so lxc-start failure is where I'll search next
<vila> didrocks: yeah, no worries, thanks for saying
<asac> bfiller: you able to come to our feedback meeting?
<bfiller> asac: yes
<asac> cool. cu there
<vila> didrocks: any objection to putting qa-intel-4000 offline for jenkins while stgraber investigates the lxc issue ? (currently in #distro)
<vila> didrocks: done, it's broken anyway, no jobs were running, they can still happily fail on the other slaves ;)
<didrocks> vila: still in meeting, but no objection of course ;)
<vila> didrocks: ack, thanks
<asac> didrocks: dont wait
<asac> have netwowkr issues
<didrocks> asac: we didn't wait if that can reconfort you :)
<asac> didrocks: good.never wait for me
<asac> :)
<didrocks> ;)
<asac> even if you will repeat :)
<cyphermox> Mirv: looking at autopilot--- are you sure that there weren't merges that needed to be forward-ported to trunk from the 13.10 branch?
<elopio> hey, are the jenkins phones going to be flashed with the trusty channel?
<vila> didrocks, asac, Mirv, sil2100: Looks like stgraber found a fix we can apply to otto in lxc.defaults/fstab http://paste.ubuntu.com/6289562/
<didrocks> vila: excellent, that should entirely the issue?
<vila> didrocks: that's my understanding, roughly the cause was: lxc now supports selinux, checks /sys/kernel/security, couldn't in the otto case, did nothing, the container was still using *host* profiles, messed them up, confusion followed
<vila> didrocks: full version in #distro without any misunderstanding added by me ;)
<sil2100> ;)
<elopio> fginther: I suppose you would know ^
<fginther> elopio, that's the plan, but if when we start supporting jobs needing multiple channels, then the image flashed just becomes part of the job configuration so that it flashes the right one
<elopio> fginther: my ultimate question is when can I start using autopilot 1.4. Right now I can run autopilot 1.4 tests on my phone because I flashed it with trusty.
<elopio> do you have an ETA for when will I be able to do it on Jenkins?
<vila> didrocks, sil2100, Mirv: So, I'm going to apply https://code.launchpad.net/~vila/otto/lxc-alpha2/+merge/192347 on qa-intel-4000 and create a new container
<sil2100> vila: excellent! Let's give it a try ;)
<fginther> elopio, should be working tomorow, I'll get back to you
<vila> sil2100: container creation already going further
<vila> sil2100: do you know who can review that otto patch ?
<elopio> fginther: tomorrow would be more awesome than what I was hoping. Thanks!
<vila> jibel is EOD I think
<vila> sil2100: container creation succeeded, rebooting
<vila> sil2100: do you have a job we can run or re-run there ?
<vila> once I put that node back online that is
<didrocks> vila: I'll be late, can you start leading the meeting?
<sil2100> vila: you mean, to check if it works?
<didrocks> asac: ogra_ sil2100 ^
<ogra_> didrocks, and i'll have to leave after a few mins
<vila> sil2100: yup
<ogra_> since my standup moved 1h later today
<cyphermox> didrocks: I'm at phonedations standup btw
<cyphermox> vila: asac: sil2100:  ^
 * ogra_ will go there now too 
<sil2100> cyphermox: ACK
<sil2100> vila: can I use the intel machine for a test build now?
<vila> sil2100: yup, it's good to go
<sil2100> vila: I mean, to run some otto testing on the machines now - can I? I want to get the list of extra-packages we need to modify, so that we're done when all machines are fixed
<sil2100> vila: thanks!
<sil2100> ;)
 * sil2100 is running some jobs that are to fail on purpose
<vila> sil2100: the missing bit it landing https://code.launchpad.net/~vila/otto/lxc-alpha2/+merge/192347 then I'll update the otto branch there to avoid people getting confused by the actual state
<vila> sil2100: that's for qa-intel-4000, the 2 others hosts need to be fixed, I'll do that asap while it's hot ;)
<sil2100> didrocks: I'm fixing the extra packages lists now if anythign
<sil2100> For all stacks
<sil2100> (head for now only)
<asac> vila: network issues kicked me out
<asac> still having issues
<asac> did didrocks manage to join yet?
<didrocks> asac: did just before you left
<vila> asac: yeah, that bug had very effects on various people ;) Or you were scared by didrocks ;)
<vila> *very weird
<asac> didrocks: will try after another reboot (resetted my whole network now now)
<didrocks> ogra_: so green light to start build #4
<ogra_> didrocks, will do after the meeting
<ogra_> didrocks, i just said (before i left and you joined i guess) that instead of enabling cronned builds again, i will just fire a build at the end of my day every day
<ogra_> so we have something to look at in the morning
<ogra_> and can still have a fine grained view on changes
<cjwatson> Why not just cron it for the end of your day every day? :)
<ogra_> cjwatson, well, i saw the crontab and didnt really want to be the only entry in there :P
<asac> ogra_: doesnt need every day. since we seem to resume CI landings, we will have images kicked on demand  all thet ime from tomrrow
<asac> so its just about today
<ogra_> ok
<cjwatson> ogra_: the rest will be turned on soon enough
<ogra_> cjwatson, right, and i thought touch can just go with that
<cjwatson> ogra_: just getting the installer working first, around everything else
<ogra_> yeah
<cjwatson> ogra_: it'll probably be tomorrow or Friday
<ogra_> k
<cjwatson> I did another chunk of it today
<ogra_> well, as soon as we do CI landings again and the new process hasnt been discussed i think we'll just stay on manual
 * ogra_ was slapped already today for blocking packages in proposed
<cjwatson> as you like, just seems odd to be playing human-cron
<cjwatson> ogra_: you were?  didn't see any block hints from you
<ogra_> well, i'm dont that since a few montjhs now :)
<ogra_> cjwatson, i had to remove them again
<ogra_> people complained
<cjwatson> oh, I'm looking in the wrong branch
<ogra_> rev 51-53
<didrocks> sil2100: robru: otto ready for all machines \o/
<didrocks> thanks vila for tracking ;)
<sil2100> \o/
<sil2100> didrocks: extra packages lists almost all updated
<sil2100> I don't have one for platform yet, as mir needs rebuilding, but we'll get to that later
<didrocks> sil2100: ok, QA seems to still need (it's the one I used for tests)
<didrocks> but you probably already updated it
<sil2100> didrocks: I didn't redeploy the stacks yet, but I have a branch pushed and soon ready for review
<didrocks> ah great!
<sil2100> didrocks, robru: https://code.launchpad.net/~ubuntu-unity/cupstream2distro-config/updating_extra_packages_for_T/+merge/192364 <- could you guys take a look? I'll redeploy in the meantime
<sil2100> Platform I only modified what I could
<didrocks> sil2100: I'll let have robru having a closer look ;)
<sil2100> I'm redeploying in the meantime :)
<robru> didrocks, is there any technical reason those lines can't wrap? if so, can we work on eliminating it this cycle?
<didrocks> robru: not sure if yaml accept wrapping? do you know?
<didrocks> robru: if you can get something understandable to yaml and the deploy stack command, I'm happy :)
<robru> didrocks, why wouldn't it? we wrap in other places. all this time i've simply assumed that cu2d itself was being brittle about the wrapping here
<didrocks> robru: so, what I do for deploying is:
<didrocks> import yaml
<didrocks> yaml.load(this file)
<didrocks> then I have a dictionary
<didrocks> if this is working with wrapping, I'm all in favor of it :)
<robru> didrocks, ok, i am going to try that locally in an interactive session and see what i find...
<didrocks> yeah ;)
<renato_> fginther, hi
<renato_> fginther, could you take a look on these MRs: https://code.launchpad.net/~renatofilho/address-book-app/dynamic-backend/+merge/192326
<renato_> and https://code.launchpad.net/~renatofilho/ubuntu-ui-toolkit/fix-1236464/+merge/190496
<renato_> jenkins is falling for some strange reason
<ogra_> === Build of image #4 running ===
<fginther> renato_, https://code.launchpad.net/~renatofilho/address-book-app/dynamic-backend/+merge/192326 failed because the armhf build node failed, it's been re-approved
<fginther> renato_, https://code.launchpad.net/~renatofilho/ubuntu-ui-toolkit/fix-1236464/+merge/190496 has a couple of failures. The maguro failure appears to be transient, possibly networking related. I've seen it a few times now since we switched to trusty, I'll try a workaround for that.
<fginther> renato_, the mako failure is more strange. It looks like the autopilot tests finish (with some failures) but the results don't get recorder. Will investigate
<renato_> fginther, thanks
<plars> thomi: did josepht or doanac ping you about autopilot not showing the new skips in the camera-app tests?
<thomi> plars: nope
<thomi> plars: maybe I missed it in the backscroll?
<josepht> thomi: you didn't, we haven't
<thomi> ok then :)
<josepht> thomi: autopilot needs to include 'skipped="N"' when testcases are skipped
<josepht> thomi: in the <testsuite> element
<thomi> josepht: in junitxml output format?
<josepht> thomi: yes
<thomi> it doesn't already!?
<josepht> thomi: no sir
<thomi> huh
<josepht> http://jenkins-dev-image-test:8080/job/trusty-touch_mir-mako/2/artifact/clientlogs/camera_app/test_results.xml
<thomi> can you file a bug please?
<josepht> thomi: sure
<thomi> it does actually skip the tests though, right?
<josepht> thomi: I'm not sure
<thomi> I'd be very surprised if it was that broken
<josepht> I'd say it is skipping them since they're not failing :)
<josepht> thomi: #1243928 filed
<thomi> cool
<thomi> that's an interesting bug, since it's not actually autopilot that formats that output...
#ubuntu-ci-eng 2013-10-24
* ev 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> cyphermox: yes I tried to stare at the commits enough starting from 1.3 common ancestor. I now checked with upstream and they agree with one exception that is WIP and not critical to releasing 1.4.
<Mirv> didrocks: hi! I think "Result directory doesn't exists, exiting!" is what keeps from getting green at the moment
<didrocks> hey Mirv!
<didrocks> Mirv: oh, where is this?
<didrocks> Mirv: I saw some more FTBFS as well
<Mirv> for example http://10.97.0.1:8080/view/cu2d/view/Head/view/Indicators/job/cu2d-indicators-head-2.2check/466/console
 * didrocks looks
<didrocks> weird, there is a head one
<didrocks> maybe it's archived under trusty
<didrocks> Mirv: can you try rerun a small check run?
<didrocks> I tried to add trusty
<Mirv> didrocks: ok, trying
<didrocks> Mirv: I guess on the FTBFS, platform-api needs to be rebuilt so that unity-mir can be rebuilt and the unity8 should be fine
<didrocks> right?
<Mirv> didrocks: right the one robru filed
<Mirv> didrocks: yay we have familiar looking problems too http://10.97.0.1:8080/job/autopilot-trusty-daily_release/label=qa-radeon-7750/48/console
<didrocks> Build was aborted
<didrocks> Aborted by Timo Jyrinki
<didrocks> ?
<didrocks> Mirv: robru filed the FTBFS? did he try to rebuild platform-api then?
<Mirv> didrocks: as you can see it was hanged for 1.5 hours with DHCP lines only
<Mirv> robru: I don't think he did, he claimed that the complain of a dependency is actually fulfilled in archives
<didrocks> Mirv: it's happening everywhere? or only on some machines?
<didrocks> Mirv: well, I doubt soyuz is lying on the dep :)
<didrocks> I guess robru didn't dig :(
<Mirv> didrocks: that seemed top be radeon only
<didrocks> it's obvious that the issue is platform-api
<didrocks> Mirv: hum, let me see the snapshot on radeon
<didrocks> ok, same time than others
<didrocks> I can remove and revert to yesterday's snapshot for now
<didrocks> (done)
<Mirv> running check on services stack now
<didrocks> Mirv: oh, in fact, moving unity-mir to the mir stack was a bad idea after all
<didrocks> because platform depends on mir
<didrocks> and unity-mir depends on platform
<didrocks> I didn't think about it
<didrocks> Saviq: we'll revert and remove to unity8 stack ^
<didrocks> I'm retrying unity-mir stack
<didrocks> ok, qtubuntu and all the sensors/hud are failing due to that
<Mirv> right..
<didrocks> Mirv: let's release today with that, and move back unity-mir then
<Mirv> meanwhile switching from services to some else
<didrocks> https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5155357
<didrocks> so, building
<didrocks> restarting as well platform for qtubuntu-sensors
<Mirv> didrocks: ok, still getting the results directory complaint: http://10.97.0.1:8080/view/cu2d/view/Head/view/QA/job/cu2d-qa-head-2.2check/313/console
<Mirv> that result should be yellow according to the subtasks
<didrocks> Mirv: ok, the subdir isn't created
<didrocks> jibel: salut! we don't create the result subdir automatically, right? (for the -check job)
<didrocks> Mirv: let me fix that manually
<didrocks> hum, that's not the issue
 * didrocks looks at the code
<jibel> didrocks, sorry I miss context, which result subdirectory, where?
<didrocks> jibel: http://10.97.0.1:8080/view/cu2d/view/Head/view/QA/job/cu2d-qa-head-2.2check/313/console
<didrocks> hum SEARCHPATH=${BASEDIR}/${JOBNAME}/configurations/axis-label/${NODENAME}/builds/
<didrocks> that's what doesn't exist
<jibel> uh, it is jenkins territory and it should have created it.
<jibel> didrocks, I'll check in 5 min
<didrocks> yeah, no configurations/
<didrocks> jibel: thanks!
<didrocks> (in /var/lib/jenkins/jobs/cu2d-qa-head-2.2check/)
<didrocks> Mirv: let's monitor the FTBFS meanwhile :)
<didrocks> I guess I don't read the right parameter, no configurations/ in /var/lib/jenkins/jobs/cu2d-qa-saucy-2.2check/ either
<jibel> didrocks, machines that were testing raring have been reassigned to head and the name of the AP nodes changed
<jibel> didrocks, you must change     apmachines: autopilot-intel qa-nvidia-gtx660
<jibel> to the name of the new nodes
<jibel> didrocks, in cupstream2distro-config/stacks/head/*cfg that is
<didrocks> jibel: stupid meâ¦
<didrocks> (well, I didn't do that change, but yeah)
<didrocks> jibel: /var/lib/jenkins/jobs/cu2d-qa-saucy-2.2check/ doesn't have this configurations?
<didrocks> do I read the shell badly? :)
<didrocks> Mirv: changing the config
<jibel> didrocks, in http://10.97.0.1:8080/view/cu2d/view/Head/view/QA/job/cu2d-qa-head-2.2check/configure
<jibel> execution step 3
<jibel> line 10: for machine in autopilot-intel qa-nvidia-gtx660; do
<didrocks> jibel: oh, it's a REST request
<didrocks> jibel: ok, I was on the FHS
<didrocks> jibel: thanks, and sorry for the stupid issue :/
<jibel> didrocks, np
<didrocks> Mirv: ok, all redeployed
<didrocks> Mirv: so, current -check job should still fail because of that, but next one should be fine
<didrocks> Mirv: I'm relaunching qa just to test
<jibel> didrocks, I added a note to MovingNewRelease
<didrocks> jibel: thanks :)
<Mirv> didrocks: I guess it kind of worked now, ie. to that problem
<Mirv> the radeon just failed almost all the tests
<didrocks> Mirv: yeah, I'm seeing that
<didrocks> vila: mind helping there?
<didrocks> Mirv: there are still 2 tests failing on autopilot, can you have a look with upstream?
<vila> didrocks: shoot
<didrocks> vila: seems radeon is failing all the tests
<vila> didrocks: ouchy,  for machine in autopilot-intel qa-nvidia-gtx660; do that's bad :-/
<didrocks> vila: we have 98 failures on it
<didrocks> vila: and 2 failures on the other machines
<vila> didrocks: url ?
<Mirv> now we start to actually see how's the autopilot 1.4 branch like
<didrocks> vila: http://10.97.0.1:8080/job/autopilot-trusty-daily_release/54/
<didrocks> Mirv: right!
<didrocks> Mirv: btw, it seems packaging list still needs to be updated for some stacks
<didrocks> sdk and hud?
<didrocks> Mirv: http://10.97.0.1:8080/job/autopilot-trusty-daily_release/
<didrocks> Mirv: mind doing it? feel free to push/relaunch :)
<Mirv> didrocks: I will, in a bit
<vila> didrocks: 2 on qa-intel, 4 on -nvidia, 98 on radeon, pretty messy
<didrocks> vila: isn't it? :/
<didrocks> vila: same on previous run: http://10.97.0.1:8080/job/autopilot-trusty-daily_release/53/
<vila> and the durations are... really different
<didrocks> vila: however, the machine is fine: http://10.97.0.1:8080/job/autopilot-trusty-daily_release/57/
<vila> at least - readeon fails fast ;)
<didrocks> for indicators
<vila> this is for autopilot itself right ?
<vila> sounds like an isolation issue to me, one test fails to cleanup properly and the following ones break
<didrocks> vila: that's more than probable
<vila> urgh, may be a bit more involved than that, I see successes intermixed with failures but many 'Cannot connect to X server :0' and ' BAMF: DBusException('Connection is closed',)'
<didrocks> sil2100: hey! how are you?
<didrocks> vila: an unity crash file?
<sil2100> didrocks: morning!
<didrocks> vila: oh, thinking about it
<Mirv> rerunning hud tests
<vila> still reading the console
<sil2100> Autopilot problems?
<didrocks> vila: do we have the proprietary driver install on it?
<didrocks> jibel: do you remember which driver we were using on ati? ^
<didrocks> sil2100: yeah, some just for one machine, Mirv is redeploying the latest package updates needed
<vila> didrocks: meh, no idea
<jibel> didrocks, nouveau, fglrx didn't compile earlier in the realease and we never move to the proprietary driver
<didrocks> sil2100: Mirv: but I think still one of you should start working on the real first results we have and ping upstream to get back to 0 tests failing
<didrocks> like QA ;)
<vila> didrocks: yup, sounds like the most sensible thing to do
<Mirv> didrocks: yeah starting from QA makes sense
<didrocks> jibel: ok, and so, we were fine with the free driver
<Mirv> pinging QA
<didrocks> vila: I guess it's a hint for you, look if xorg/lightdmin failed ^
<vila> didrocks, Mirv : if nothing else, if it's related to the X server, the tests should fail far earlier with better messages
<didrocks> lightdm*
<jibel> didrocks, mostly fine, the main issue was the machine hanging when it switches from Mir to Xorg
<didrocks> vila: I can list you a lot of should :)
<sil2100> didrocks: ok, is QA the one with stable results?
<didrocks> jibel: yeah, but other stacks (like, when Mir wasn't enabled), we were good running unity tests IIRC
<didrocks> and that we didn't switch back and force from it
<didrocks> sil2100: well, all the ones that are stopped should have stable results
<vila> didrocks: yeah, but that one generates a lot of noise and force unaware people to spend time deciphering, thomi welcomes that kind of input and is eager to do the related fixes
<didrocks> vila: that's why we have people first deciphering for him
<didrocks> as we have to cope with what we have
<didrocks> and fix timely first
<didrocks> to get back on productoin
<didrocks> production*
<didrocks> sil2100: so http://10.97.0.1:8080/view/cu2d/view/Head/view/All/, everywhere it's red and not running :)
<vila> didrocks: right, there is a balance to be found between fire fighting and improving, doing only the former means we'll never be able to do the later
<didrocks> vila: indeed, so then, send the email to people that we are going to improve the platform and not deliver anything meanwhile
<sil2100> \o/
<Mirv> filed bug #1244089, please update if you've anything to add to the description
<ubot5> bug 1244089 in Autopilot "Autopilot 1.4 trusty AP test errors" [Critical,New] https://launchpad.net/bugs/1244089
<Mirv> good news! indicators stack tested itself fine :)
<vila> didrocks: infinite shades of grey between white and black ;) In that specific case I think autopilot has enough data to act so *we* can focus on other things but hey, that's only MHO ;)
<sil2100> Mirv: I'm looking at hud now though
<vila> didrocks: still looking on qa-radeon- itself for additional evidence
<didrocks> vila: would be interesting to know if there was a crash
<didrocks> you have those infos
<Mirv> sil2100: I'm already there, I added a few packages already
<sil2100> Mirv: extra-packages needed for hud, ok
<vila> didrocks: /var/crash is empty
<didrocks> vila: ok :(
<Mirv> sil2100: relaunching hud now after redeploy
<sil2100> ACK
<vila> didrocks: why the sad face ?  I'd rather have autopilot fixed than one more fix in the ci infra :0)
<didrocks> vila: well, I doubt the issue is in AP
<didrocks> vila: why is it failing only on radeon? AP isn't hw specific
<Mirv> anyway. we have the first autopilot-running stack ready to publish, which is definitely progress. others running so let's see.
<didrocks> so either something changed in the way it access the hw and we don't have the setup on that machine
<vila> didrocks: it could a timing issue
<Saviq> didrocks, k
<didrocks> vila: can be, yeah, and if the cleanup isn't goodâ¦
<vila> ha crap looking at the wrong place
<Mirv> hmm the green indicators tests indicate failing tests in the log, though http://10.97.0.1:8080/job/autopilot-trusty-daily_release/57/label=qa-intel-4000/console (at the end)
<Mirv> unity.tests.test_panel.PanelHoverTests.test_hovering_indicators_open_menus: FAIL etc
<sil2100> Interesting
<sil2100> Many FAIL but SUCCESS
<vila> didrocks: http://10.97.0.1:8080/job/autopilot-trusty-daily_release/54/label=qa-radeon-7750/artifact/results/logs/gnome-session.log ?
<vila> didrocks: not sure I know how to read that
<didrocks> WARN  2013-10-24 07:18:25 unity.gdk <unknown>:0 compiz: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
<didrocks> not sure that's good
<sil2100> On webapps it seems ERROR __init__:64 - Unity doesn't appear to be running, exiting.
<Mirv> ok hud is now back in the league of "properly" failing
<Mirv> sil2100: same in hud
<vila> didrocks: what happened with the containers there ?
<sil2100> Mirv: I wonder if that's a problem with autopilot introspecting unity or just really unity doesn't start
<didrocks> vila: there?
<vila> qa-radeon-7750
<didrocks> vila: can you rephrase this? I can't parse you
<vila> what happened with the containers on qa-radeon-7750 ?
<vila> the job you asked me to look at seems to have run against an old container when there are older jobs against newer containers (including autopilot upgrades) with less failures
<vila> http://10.97.0.1:8080/job/autopilot-trusty-daily_release/label=qa-radeon-7750/62/
<vila> urgh, no they were against the current one, gee, that's confusing
<vila> there is a hanging.trusty-i386-20131024-0008 container, where is that coming from and why aren't we using it ?
<didrocks> vila: yeah, it was hanging this morning (no ui started), so I needed to mv it first thing
<sil2100> didrocks, Mirv: argh, today I might be late for the morning meeting, so just assign a lot of stuff to me if anything
<didrocks> vila: I was planning to check for it once we have at least the first pass running
<sil2100> Mirv: I'll be looking at the webapps part
<didrocks> vila: as we know that yesterday's container was working
<didrocks> sil2100: ok
<didrocks> sil2100: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=0 is assigned to you
<didrocks> Saviq: dude, really ask to packagers when you add a packaging changeâ¦
<didrocks> Saviq: https://code.launchpad.net/~elopio/unity8/autopilot-1.3/+merge/192440 isn't going to work
<didrocks> Saviq: it will block unity8 to proposed until you the dep is fixed
<Saviq> didrocks, and it won't be?
<Saviq> didrocks, ah, it won't of course..
<Saviq> didrocks, sorry, I just woke up...
<didrocks> Saviq: really, all packaging changes should involves a core dev ;)
<didrocks> involve
<vila> didrocks: right, but something is not working now, I'd rather investigate that in case reverting to a previous container introduced some skew, which job was hanging ?
<didrocks> Mirv: do you have the link for vila? ^
<Saviq> didrocks, is there a process other than us finding one? maybe a team we could assign reviews to?
<didrocks> Saviq: on another note, I can't (again) :/ refind the fix for AP tests on unity8â¦
<didrocks> Saviq: good point, I would say pinging there until the oakland sprint
<didrocks> Saviq: then, we can discuss about team assignement and so on
 * sil2100 prepares to upgrade his device
<Saviq> didrocks, which fix? lxc-android-config / unity-mir? still not released
<didrocks> Saviq: no, the one in AP unity8 tests themselves
<didrocks> the one we did on Thursday
<Saviq> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1240801
<ubot5> Ubuntu bug 1240801 in unity8 (Ubuntu) "autopilot unity8 fails with "No GSettings schemas are installed on the system"" [Low,Fix committed]
<Mirv> didrocks: just a second
<didrocks> Saviq: thanks!
<Saviq> didrocks, how's it going, btw - when do we expect trusty to be good enough to start releasing into it?
<didrocks> Saviq: we hope today, but issues on some components FTBFS and AP 1.4 having some tests failing
<Mirv> sil2100: any idea how the unity problem could be debugged?
<Saviq> didrocks, mhm
<didrocks> Mirv: sil2100: so, what I see is: someone doing the mir transition, the other one debugging the AP issues + FTBFS
<didrocks> Mirv: sil2100: we can exchange if you prefer
<didrocks> Mirv doing the mir transition
<didrocks> and sil2100 the debugging
<didrocks> what do you both prefer?
<Mirv> fine, sil2100 might know more about the lxc debugging
<didrocks> ok, so exchanging
<Mirv> vila: before switching to the older container I got this hang: http://10.97.0.1:8080/job/autopilot-trusty-daily_release/48/label=qa-radeon-7750/console
<sil2100> Oh!
<sil2100> Ok
<didrocks> sil2100: Mirv: done :)
<Mirv> didrocks: so, libmirserver8 now?
<didrocks> Mirv: indeed! 8 is a good number :-)
<didrocks> but can't wait for 9 :p
<Mirv> is it then stable?! :)
<sil2100> ...;p
<didrocks> heh, let's hope so! ;)
 * sil2100 doubts that
<Mirv> I mean ABI stable, that is
<sil2100> :<
<didrocks> Mirv: you're dreaminggggg ;)
<didrocks> Mirv: so, I guess apart from u-s-c (didn't check), everything else should be ready
<didrocks> as per my relaunch this morning
<Mirv> updating package lists for platform and unity8
<ogra_> popey, mind testing #4 ? (its good on maguro)
<popey> already done
<popey> looks good
<ogra_> awesome
<didrocks> asac: you froze!
<elopio> didrocks, Saviq: Why can't we have autopilot 1.3 and 1.4 while we update the tests?
<elopio> Autopilot 1.4 has a big API change that throws an exception where it previously returned None, and that will make some tests fail, probably on all the projects. Thomi said that the right thing to do is make sure we are currently using 1.3 on all suites, and then propose branches with the bump to 1.4 once we have update the tests.
<Saviq> elopio, because they're not installable in parallel
<elopio> *updated.
<Saviq> elopio, you can't install both autopilot-1.3 and autopilot-1.4 on the same machine - because they're different versions of the same package
<elopio> hum, that's going to be a problem.
<Saviq> elopio, yeah, we'd need autopilot 1.4 to be autopilot14
<elopio> Saviq: so, what's the strategy, bump autopilot and have all the tests failing for a while, or change the package to be autopilot14?
<Saviq> elopio, *I* think it's fine to just bump and adapt
<elopio> as long as we don't need to land the fixes on all the projects at once, that doesn't sound bad for me.
<elopio> however blocking the project with '<< 1.4 can't be satisfied' until the tests are updated sounds a litte more correct from the tests point of view.
<elopio> but I'm going to bed now. I'll ask tomorrow to see how can I help updating the tests.
<didrocks> sil2100: psivaa: please pair together ;)
<sil2100> o>
<psivaa> didrocks: ok
<didrocks> thanks! good luck guys
<Mirv> didrocks: hmmh, I launched unity-system-compositor build to update the dependencies but it FTBFS:s https://launchpadlibrarian.net/154869368/buildlog_ubuntu-trusty-amd64.unity-system-compositor_0.0.1%2B14.04.20131024-0ubuntu1_FAILEDTOBUILD.txt.gz
<didrocks> Mirv: I'm working on the radeon failure with vila, do you need me on that one or you investigate?
<didrocks> (you can parallelize the phone test at least)
<Mirv> didrocks: no need, seems upstream problem so solving with them while trying to get phone tests
<didrocks> ok, great!
<ogra_> didrocks, asac, popey image 4/20131023 promoted
<popey> super
<didrocks> ogra_: \o/
 * popey mails
<ogra_> popey, hmm, 1023.changes would have been the right one ... 22 and 22.1 were image 2 and 3
<popey> damnit
<didrocks> psivaa: Mirv: sil2100: FYI, radeon deprovisionned.
<sil2100> ACK
<asac> i have a question... are we still producing saucy-updates images?
<asac> didrocks: did you finish seb feedback?
<ogra_> asac, not atm
<ogra_> (we can if you want one)
<ogra_> asac, though i guess we should first make a decidion about #101 before building new ones
<didrocks> asac: seb is in Canada, not online yet
<didrocks> asac: I'll grab him later on
<Mirv> ack
<ogra_> *decision
<asac> didrocks: i want to be there :)
<didrocks> asac: ok, will get you in, let's try to catch
<didrocks> him*
<ogra_> asac, what do you want in canada ...
<ogra_> its full of canadians !
<asac> hehe
<vila> didrocks: the kvm was a good hint, tests lead to session crashes, lightdm is displayed, if I connect manually, the current test catches up  things are moving ;) Until it crashes again
<didrocks> vila: ok, it's a start :)
<vila> didrocks: right, I will hand it to ... dang, didn't copy from the hangout, paste the nick again ?)
<vila> didrocks: this should be reproducible locally with the same or similar card by that guy right ?
<asac> ogra_: you mean test 101? or promote it?
<asac> so the reason we do saucy-updates is to pipeclean our infrastructure and process
<ogra_> asac, 101 is fine (iirc there was only the udevd change for maguro)
<asac> we should do a few builds there
<asac> and then promote
<asac> and then move on to T
<ogra_> right
<asac> and promote T images to stable channel :)
<ogra_> 101 was the first one in there
<ogra_> huh ?
<asac> right. so that ones is in the bank
<ogra_> T images to stable channel ?
<ogra_> stable is saucy
<ogra_> T is in development
<asac> thats what people might believe :)
<ogra_> well, thats what we have
<ogra_> you cant call an in-development thing "stable"
<ogra_> especially since you break the rolling model then
<xnox> ogra_: the plan was at one point migrate stable to T series. Thus to exercise "channel upgrade"
<ogra_> stable should be a snapshot of the final release of a series
<xnox> ogra_: something 1-2 months into the T cycle, or when ready.
<ogra_> not a milestone image in the middle of a dev release
<asac> ogra_: thats ONE way to see it, yes. anyway, lets not talk about that now. let me first talk with folks
<didrocks> vila: probably yeah
<asac> abiout our saucy updates etc.
<ogra_> if you really want to change that i'm highly opposed
<ogra_> that adds massive confusion
<ogra_> saucy updates need to go to the stable channel
<ogra_> built from saucy-updates :)
<vila> didrocks: You missed one of my messages ;) I didn't copy the nick name before closing the hangout, can you paste it here please ?
<didrocks> vila: mlankhorst
<vila> didrocks: thanks ;)
<vila> http://10.97.0.1:8080/job/otto-test-radeon/label=qa-radeon-7750/ if I keep relogin some tests succeed
<Mirv> yay, error: aptitude: undefined symbol: _ZNK7tagcoll4coll4FastISsSsE13getTagsOfItemERKSs
<Mirv> breaks my pbuilder usage
<Mirv> http://bugs.debian.org/727540
<ubot5> Debian bug 727540 in libept1.4.12 "aptitude: symbol lookup error: aptitude: undefined symbol: _ZNK7tagcoll4coll4FastISsSsE13getTagsOfItemERKSs" [Grave,Open]
<vila> didrocks: what's the trick to start the container without it shutting down after a few seconds ? (i.e. I need to use the kvm to access the graphical env which seems to require lxc-start which quit before I can achieve anything ;)
<didrocks> vila: for that, you need to stay on latest run
<didrocks> vila: cd /var/lib/lxc/trusty-i386-20131024-0008/run
<didrocks> edit target-override/usr/local/bin/run-autopilot.sh
<sil2100> Yes
<sil2100> Add -S to the end of the command
<sil2100> ;)
<didrocks> SHUTDOWN=1 -> change to 0
<didrocks> sil2100: oh, -S?
<sil2100> We had the same problem during our debugging, jibel proposed this and it works
<sil2100> didrocks: in the xdg/autostart file
<didrocks>     -S|--noshutdown)
<didrocks>         SHUTDOWN=0
<didrocks>         shift;;
<didrocks> ahah ;)
<sil2100> ;)
<didrocks> so, let's use the option rather
<didrocks> edit target-override/etc/xdg/autostart/autopilot.desktop
<didrocks> and add the -S at the exec line
<didrocks> then sudo lxc-start -n <container>
<vila> didrocks, sil2100 : thanks
<asac> jibel: looking at http://people.canonical.com/~j-lallement/touch/changes/20131022.html there seem to be a bunch of changelog items not availabe
<asac> do you know?
<Mirv> didrocks: do you think I can merge https://code.launchpad.net/~mterry/unity-system-compositor/mir-fixes/+merge/192042 manually? I've tested it builds with the daily-build PPA
<didrocks> Mirv: sure, feel free :)
<Mirv> thanks
<vila> Do you guys know how to find which kind of graphic driver is installed on qa-radeon-7750 ?
<Mirv> check if dpkg -l | grep fglrx shows something installed
<Mirv> if not, it's using open drivers
<Mirv> or simply /var/log/Xorg.0.log
 * didrocks goes for a run
<cjwatson> Mirv: Do you have trusty-proposed enabled?
<cjwatson> I guess you might reasonably have it *inside* the chroot
<Mirv> cjwatson: no, but right I could enable it
<cjwatson> Mirv: No, don't
<cjwatson> Mirv: You mean it's broken in trusty?
<cjwatson> (non-proposed)
<Mirv> cjwatson: I got it via pbuilder-dist trusty create done today + adding daily-build PPA + trying to build
<cjwatson> Mirv: So you have libept1.4.12 1.0.9?
<Mirv> let me log in there
<cjwatson> There's a 1.0.10 in trusty-proposed, but it's blocked on build failures on two architectures
<Mirv> cjwatson: aha, it seems pbuilder-dist (or my old configuration of it somewhere) enables -proposed, so that's why I have 1.0.10
<cjwatson> That's actually sensible *inside* a pbuilder
<vila> Mirv: darn didn't notice your message until now. no fglrx, no mesa
<vila> Mirv: what should I search for in X.org.0.log ?
<Mirv> vila: mm maybe "X.Org Video Driver" and then before that what's the module name
<vila> Mirv: there are a bunch of messages starting with (II) RADEON(0)
<cjwatson> I mean, in general we build packages against -proposed and so test builds should do likewise
<vila> ha, hold on
<Mirv> vila: ok, radeon tells already that's it's the default (open) driver, not fglrx
<Mirv> and not vesa either, so the correct driver gets loaded
<vila> Mirv: which are the corresponding packages ?
 * cjwatson blocks libept in -proposed until we figure this out
<cjwatson> It might just need an aptitude rebuild
<Mirv> vila: xserver-xorg-video-radeon/ati, the 3D part comes from mesa packages
<vila> X.org Video Driver: 14.1... "glx" will be loaded by default "xmir" not laded "dri2", glamoregl...
<cjwatson> But that will be messy while libept has failed builds in -proposed
<vila> Mirv: xserver-xorg-video-radeon/ati neither are installed
<Mirv> vila: oh, sorry, can you find "Loading /usr/lib/xorg/modules/drivers/" in there somewhere?
<cjwatson> Mirv: I can probably work on this, but I need to finish clearing out the insanely complex perl transition from -proposed first so that I can see what I'm doing
<cjwatson> Mirv: Is it blocking you or can it wait a day or so?
<Mirv> cjwatson: sure, this is not any sort of blocker for me
<cjwatson> OK
<vila> Mirv: libglx
<Mirv> vila: that should come from "extensions", not "drivers"
<Mirv> vila: actually a simple search for lower-case "drivers" in the file should do
<vila> Mirv: no copy/paste is a reaaaaaal pain
<vila> Mirv: ha ! Can access via ssh under rootfs, pfew, some sanity restored
<vila> /usr/lib/xorg/modules/drivers/ati_drv.so
<vila> /usr/lib/xorg/modules/drivers/radeon_drv.so
<vila> /usr/lib/xorg/modules/drivers/vesa_drv.so
<vila> /usr/lib/xorg/modules/drivers/modesetting_drv.so
<vila> /usr/lib/xorg/modules/drivers/fbdev_drv.so
<Mirv> vila: you're not saying you find all of those from Xorg.0.log? :)
<vila> Mirv: I do
<Mirv> vila: ok, my guesses at Xorg.0.log contents are clearly wrong.. anyhow, you're probably using open source radeon driver. what was the actual problem you were thinking about? is there any lines having "EE" in there, if you're wondering about startup problems?
<vila> http://paste.ubuntu.com/6294522/
<Mirv> vila: if you can now get the Xorg.0.log somewhere, that'd be much easier than using a human-IRC interface to grep command :)
<Mirv> vila: thanks :)
<vila> Mirv: indeed ;) Sorry, took me a minute to get from ssh access to copy/paste restored ;)
<Mirv> vila: ok, so it's the open driver, seems to work, no (real) errors. glamoregl working, DRI2, vdpau etc point to 3D working too.
<Mirv> vila: so no visible problems starting the X there
<vila> Mirv: pfew, learning is always painful :) First time diagnosing an X issue on a remote host with a KVM, every step hurts ;)
<vila> Mirv: so, summary, the config seems correct and uses the open driver.
<vila> Mirv: now to find how to tell otto to collect Xorg.0.log[.old]
<vila> Mirv: will that be in otto sources and its associated config (where is that ?) ?
<Mirv> vila: I'm not familiar with otto so far either
<vila> Mirv: ack, thanks, negative feedback is so much better than none ;) (#ubuntu-desktop laaags ;)
<vila> jibel: where should I look to tell otto to collect Xorg.0.log[.old] ?
<Mirv> didrocks: good news is that I got the u-s-c ftbfs fixed. bad news is that new tick brought libmirserver9 and u-s-c FTBFS:s again in a different way... meanwhile I'm rebuilding unity-mir to get something to test again on device, but I haven't so far had luck with the unity8 AP.
<jibel> vila, http://bazaar.launchpad.net/~otto-dev/otto/testsuite_autopilot-unity/view/head:/config
<jibel> vila, add them to ARTIFACTS
<vila> jibel: thanks !
<Mirv> didrocks: I've assigned the new FTBFS bug to mterry (to whom the mir team assigned the previous fix too, and there was already an existing branch), so hopefully we'd have a fix for the morning at minimum.
<vila> jibel: will do a mp later, where should I look for that locally ? Or is that something that comes from jenkins ?
<jibel> vila, the branch is pulled from LP because we wanted to prevent people from doing what you're intending to do
<vila> jibel: he he
<jibel> vila, so MP is the way to go
<vila> :-/
<Mirv> yay, libmirclient4 too
<Mirv> and relaunching unity8 build since it failed because of unity-mir transition
<vila> jibel: which means no way to test before the mp, I'm sure we can do better, but in the mean time: https://code.launchpad.net/~vila/otto/testsuite_autopilot-unity-collect-Xorg/+merge/192494
<jibel> vila, you can test, but not in production
<vila> jibel: lp-propose is weird... is lp:otto/autopilot the right target ?
<vila> jibel: qa-radeon-7740 is isolated from production right now to diagnose
<vila> jibel: and so far the issues revealed by otto *had* to be diagnosed in production
<vila> jibel: and I've already been quite vocal about how bad I think that is :)
<Mirv> didrocks: because of the libmirclient bump we'd also need xserver-xorg-xmir update?
<didrocks> Mirv: argh :/
<didrocks> Mirv: right
<didrocks> Saviq: FYI, we are delayed by this ^
<Saviq> didrocks, k
<didrocks> asac: as well ^
<didrocks> asac: new bumps (without warning) from the mir team, both client and server and xserver-xorg-xmir then needs an update
<didrocks> asac: so, work from the morning -> voided
<jibel> vila, merged. If it is for testing purpose on a deprovisionned machine you call directly set the right environment to define tests, packages, ... then call sudo -E otto-run <container> <path_to_testsuite>
<jibel> s/call/can/
<jibel> vila, or set TS_BRANCH to a test branch before calling run_otto_job from a jenkins job
<vila> jibel: thanks, already running from jenkins
<jibel> vila, or propose a patch to accept a local testsuite directory as well
<vila> didrocks: http://paste.ubuntu.com/6294696/ captured on the fly, not sure otto can capture the right ones in the general case (x is restarted only once for this specific case so we are ~ok here, but that may not always be true)
<didrocks> vila: ok, so clearly a Xorg issue
<didrocks> xorg/driver
<vila> didrocks: yes, one more case where a test run breaks the ci infra with no way to guard against :-/
<fginther> morning
<asac> didrocks: client bump?
<asac> not good
<didrocks> vila: indeed
<asac> didrocks: see with mir team if they wantt o back out
<didrocks> asac: right, so we are quite stuck now, I guess Mirv is trying to rebuild xserver-xorg-xmir, we'll see if that's enough of if they break the ABI
<didrocks> asac: they pulled, they don't want to rollback without duflu
<didrocks> (which is in AU timezone)
<didrocks> who*
<asac> not sure
<asac> cant we just revert that part?
<asac> we just want to go back to the revision before this happened
<didrocks> that would mean push --overwrite
<asac> didrocks: not realy
<didrocks> as they want to keep their branch1 in pull order with branch 2
<asac> revert commit basically
<asac> well, is it really about wishes in this case?
<didrocks> asac: they overwrote your revert because they want to have this """workflow"""
<didrocks> our*
<didrocks> I don't want to restart this war
<didrocks> (basically lp:mir was pushed with --overwrite)
<didrocks> because history was messy from their standpoint
<asac> wait
<asac> thats insant
<asac> insane
<asac> they pushed overwrite?
<asac> tahts not good
<vila> didrocks: revert/commit is different from pull --overwrite, the history clearly shows who reverted what
<ogra_> instantly insane ?
<asac> didrocks: can we move on with other parts like apps etc.
<vila> grr push --overwrite
<asac> and just decslare unity etc. blocked because of this until we have discussed and sorted?
<didrocks> asac: no, apart from emptying the ppa
<asac> didrocks: we have a bunch of things that were not build against this, no?
<didrocks> which means another 2/3 hours to rebuild everything without mir
<asac> didrocks: right. but feels with mir we wont proceed either
<didrocks> asac: everything was rebuilt and dep on platform-api
<didrocks> which pulls it
<asac> its an uncoordinated client ABI bump
<asac> we cant roll that
<asac> that would defeat any discussion we did so far
<didrocks> 14:59:07     alan_g | didrocks: ok - let me grab usc
<asac> i suggest: empy the ppa, stop unity and mire
<didrocks> asac: on #ubuntu-mir ^
<asac> then go with the rest and land those things nicely
<asac> who is usc?
<didrocks> unity-system-compositor
<asac> didrocks: ok can we proceed like above? its a delay for us, but it is just the consequence we have to endure
<didrocks> Mirv: can you backout mir from the ppa, with platform-api, unity-mir?
<didrocks> we can't release any of those until mir is coordinated
<asac> didrocks: we tell mir and unity folks that their part is stopped until we have their branches sorted, and go on with simple stuff..
<didrocks> asac: I don't see kgunn online yet
<asac> empy ppa, rebuild evrything else
<cjwatson> You know it's possible to forbid push --overwrite on a branch, right?
<asac> then do the simple landings all night and morning
<asac> didrocks: right. dont need to wait
<asac> didrocks: we can post moretem with him
<didrocks> cjwatson: with the append mode only, we did that on some projects, then flamewar started, but we can envision forcing it again right
<cjwatson> Fair enough
<didrocks> asac: yeah, just be aware that we are talking about 3h of delay until the first stack is ready to be pushed
<Mirv> didrocks: ok, so removing mir and the rebuild platform-api unity-mir against old one?
<didrocks> Mirv: in fact, we can't rebuild platform-api and unity-mir as they build-dep against latest mir
<asac> didrocks: i know
<asac> didrocks: but thats life. i will send a mail to kgunn etc. explaining that this also delays other landings by half a day
<didrocks> Mirv: ok, so please disable platform-api, unity-mir, and mir
<Mirv> didrocks: oh, right, they were bumped. or not the latest mir but the one before, still newer than in archive.
<didrocks> + remove from the ppa
<didrocks> (disable from the config)
<Mirv> ok.
<didrocks> thanks ;)
<didrocks> asac: FYI ^
<asac> didrocks: right. and then lets schedule landings at best by stack so all the leave things and indicators can go in again
<didrocks> Mirv: oh, while we are at it, please move then unity-mir back to unity8 :)
<asac> etc
<didrocks> at least, we'll win that :p
<didrocks> (speaking of stacks)
<Mirv> didrocks: ok
<Mirv> done (deployed + packages removed from PPA) - except didrocks please deploy mir because of the lightdm access problem again
<didrocks> Mirv: you didn't change anything in the branches, right? You can deploy with -US
<didrocks> Mirv: to not need access to the branches
<Mirv> didrocks: right, I've always used -U. thanks.
<Mirv> so done
<didrocks> thanks ;)
<vila> didrocks: things are getting too complicated (to diagnose we need to run x under valgrind). To get something simpler I'd like <mlankhorst> to run only the failing test directly on the host
<vila> didrocks: what's the command to do that and what are the pitfalls (set DISPLAY ? something else ?)
<vila> didrocks: install xx packages
<didrocks> vila: you can change the autopilot job in /usr/local/bin/ to start autopilot with "autopilot run <list of tests failing>"
<vila> didrocks: which /usr/local/bin  ?
<didrocks> vila: the one in the container
<vila> didrocks: I want to *avoid* the container. the  server needs to be run with valgrind --track-origins=yes --error-limit=no /usr/bin/Xorg :0
<didrocks> vila: not sure then
<vila> too many steps to get that working inside the container
 * vila sighs
<vila> ok, I give up, I don't have the knowledge nor the energy to close the gap between upstream requests and the lack of reproducibility in the test env, I'm just wasting my time
<vila> didrocks: what's the risk to not run those tests on radeon ?
<didrocks> vila: we won't know if unity7 still runs on radeon hw
<didrocks> or mir
<didrocks> which is pretty bad
<didrocks> ev: asac: do you think someone else can help vila? ^
<vila> didrocks: given that we don't even know what the cause is we're far from an ETA for the fix
<vila> and until there is a fix, you're exposed to regressions
<didrocks> vila: right, but I don't think we should cut our testing because we don't have the energyâ¦
<didrocks> right
<asac> vila: didrocks: hard to say. i dont know where we are stuck.
<vila> didrocks: it's more about waste of energy than about energy per se, there are just too many unknowns here for me to be efficient
<asac> our test machine is broken?
<didrocks> the radeon one has a xorg segfault when running the tests
<vila> asac: some tests triggers a X crash
<asac> upstream has no radeon to reproduce?
<asac> who is actually xorg maintainer?
<vila> asac: He didn't say, #ubuntu-desktop
<asac> whoever that is should help out
<ogra_> did you involve tjaalton or mlankhorst yet ?
<asac> right
<asac> go for our xorg folks.
<vila> ogra_: yes, see #ubuntu-desktop, I finally managed to get it to the lab
<seb128> they just want a valgrind log of the issue since they don't get it locally, what's wrong with that,
<seb128> ?
<vila> he's hacking there right now
<vila> but that's only half of the equation
<ogra_> ah, good then
<vila> the other half is to run autopilot outside of the container and I don't know what needs to be setup there nor which command to run
<asac> vila: whats the other half? seems like folks are investigating now
<asac> vila: isnt that part solved for intel etc. machines?
<asac> cant you spy what they do?
<vila> I do
<vila> cd /etc/X11 ; rm X ;)
<vila> sounds good
<asac> so solved? :)
<vila> what I'm asking here is what needs to be setup *outside* of the container because the container use a snapshot so you can't hack there
<vila> hacking on what is put inside the container is insane
<vila> so,
<vila> <vila> didrocks: what's the command to do that and what are the pitfalls (set DISPLAY ? something else ?)
<vila> <vila> didrocks: install xx packages
<vila> is where I stopped, I *can* go ahead and lurk and find but this is getting ridiculous, just tell ne
<vila> me
<didrocks> what is getting ridiculous?
<didrocks> vila: I told you how to get the autopilot command runs inside the container?
<didrocks> outside, I don't think you can
<didrocks> there is no X, nor lightdm installed
<didrocks> it's a server install
<didrocks> I don't see what's harder being inside the container though, I told you how to remove the timeout and how to start by hand
<didrocks> then, you have a command line inside as you would have outside
<vila> right and it took me alsmost 2 hours to get the Xorg.0.log...
<vila> didrocks: and since the machine has just been rebooted anyway...
<didrocks> vila: I don't think anyone apart from you and mlankhorst are on the machine
<vila> of course not, he did reboot, because it's easier for him to work on the host to diagnose on the host, the container is just adding useless complexity that I want to get rid of
<vila> isolation is about involving less pieces
<didrocks> vila: as long as you reinstall the machine afterwards
<vila> didrocks: already mentioned in #ubuntu-desktop
<didrocks> great then :)
<vila> and now he's blocked on how to run the tests and I still have no answer
<vila> not to mention I'm late for the ci standup
<didrocks> vila: is it all my fault? Can we depassionate this discussion?
<didrocks> and be professional, thanks
<didrocks> vila: so, we always run autopilot within inside the session
<vila> didrocks: never said it was your fault, I'm asking questions which don't get answered, anybody with knowledge that I lack can answer
<didrocks> I told and showed you how to do it in an autostarted way in the container
<didrocks> AFAIK, apart from using basic Linux knowledge
<didrocks> meaning looking at gnome-session env var
<vila> and I said I wanted to avoid that to simplify the diagnosis
<didrocks> exporting those
<didrocks> and running "autopilot run <list of tests>
<didrocks> I don't think, we have an automagic job doing that
<vila> will get back to it after the standup
<didrocks> vila: and yes, I figured that our myself, nobody answered me, so I can be wrong
<didrocks> just trying to assess what the others are doing
<didrocks> and apply to this new case
<didrocks> ogra_: do you think you have bandwith to work on the emulator support right now? (an old landing ask)
<ogra_> which one
<didrocks> ogra_: can we land that without the hud branch in comment?
<didrocks> landing ask, line 143
<ogra_> hmm, not sure thats still needed
<ogra_> xnox, ^^^
<ogra_> hrm
<ogra_> that merge is clearly the wrong one
<xnox> didrocks: ogra_: if anything w.r.t. emulator is from saucy, it's all obsolete and should be dropped.
<ogra_> right, thought so
<xnox> ogra_: i had a recent branch proposal for lxc-container-config (re-prepose)
<didrocks> ok, dropping then
<xnox> ogra_: which i think i will be just uploading.
<ogra_> xnox, gimme and i'll approve :)
<ogra_> xnox, or that ... but keep the spreadsheet updated
<xnox> ogra_: https://code.launchpad.net/~xnox/ubuntu/trusty/lxc-android-config/add-generic-rules/+merge/192331
<ogra_> ah, i have seen that one before :)
 * ogra_ will update line 143
<ogra_> hmm
<ogra_> or not ... since it is gone
<xnox> well, didrocks just dropped it =)
<xnox> ogra_: imho i need to upload stuff for the emulator. (a) it's not affecting other images (b) we need it urgently
<didrocks> xnox: yeah, just file a new one
<ogra_> xnox, yes, please go ahead with that one
<didrocks> when you are read :)
<didrocks> xnox: and yeah, sounds good
<ogra_> i'll care for the spreadsheet
<didrocks> ogra_: just write it for tracking
<didrocks> ogra_: I postponed most of the landing to image 6
<didrocks> so that we kick image 5 first
<ogra_> yep
<ogra_> would be hard to kick image 6 before 5 anyway :P
 * didrocks trust ogra_ to make magic!
<didrocks> :)
<renato_> fginther, all tests passing: https://code.launchpad.net/~renatofilho/ubuntu-ui-toolkit/fix-1236464/+merge/190496
<renato_> now the only missing problem is jenkins :D
<fginther> renato_, there are some failing desktop (otto) tests. is that expected?
<renato_> fginther, please could you merge it before any other merge get merged on SDK and cause more conflicts and failures
<renato_> :(
<renato_> I did not see that, is not related with my mr but I need to ask the SDK guys to look
<fginther> renato_, Ack, This branch now builds/tests with trusty, perhaps that introduced a regression...
<fginther> renato_, just throwing an idea out there
<elopio> renato_: fginther: the otto failures are because otto is in autopilot 1.4
<elopio> the rest jobs are using autopilot 1.3.
<elopio> didrocks: do you have some minutes to talk about that ^ ?
<didrocks> elopio: so, if we take trunk for the others components, all will be fine with autopilot 1.4?
<elopio> didrocks: no, all will be failing :)
<didrocks> ah, so autopilot 1.4 was pushed to trunk without tests being updated by the QA team?
<elopio> yup.
<didrocks> ok, so I think we're going to remove autopilot 1.4 from the ppa
<didrocks> blacklist it for now
<didrocks> and have all projects running with 1.3
<elopio> didrocks: yes. So what about this:
<didrocks> elopio: they did break backward compatibility? were you informed?
<didrocks> asac: FYI ^
 * sergiusens thought those days were past us now
<elopio> didrocks: yes, it's not backwards compatible, and on QA we all knew.
<didrocks> elopio: can I say "sigh" ;)
<sergiusens> elopio, ack, so you are aware that all the tests need to be migrated in parallel?
<didrocks> there are also community core apps
<sergiusens> I don't think devs are going to be happy doing that when backwards compatibility was requested the last time this was needed
<elopio> it's a change to throw an exception instead of returning None in case the element we are looking for is not present.
<didrocks> tests done people not at canonical, and not being backward compatible isn't nice
<elopio> didrocks: but we are currently working on updating all of them.
<didrocks> elopio: right, but don't push to trunk before it's ready please
<didrocks> elopio: can you revert your trunk to last version in ubuntu
<didrocks> or last version compatible?
<elopio> didrocks: autopilot's trunk?
<didrocks> elopio: yeah
<elopio> I don't have access to that, that's thomi. But can't you take autopilot 1.3's branch?
<sergiusens> elopio, can you make ap 1.3 coinstallable with 1.4?
<elopio> sergiusens: we could. I'm not sure that's going to be needed. So last night I was too asleep to explain what thomi proposed and I was doing.
<didrocks> elopio: we want trunk to be in a good state and not changing our configuration for upstream
<elopio> let me tell you to see if you agree, or we should change the course of action.
<didrocks> ok
<sergiusens> elopio, ack, we do coinstalls for most transitions btw
<sergiusens> sf->mir as an example
<elopio> so, the first step we were doing was to make the apps -autopilot deb package depend on << 1.3
<elopio> then, we wanted to ask you to install 1.4 on all the runners.
<elopio> that would block all landings until the tests are updated.
<elopio> so, we update the tests, set the dependency to >= 1.4, and everything would be green again.
<didrocks> elopio: on getting all -autopilot dep dep on << 1.3 won't work, if they are not cooinstallable, we still can't ship 1.4 until the transition is done
<elopio> I didn't expect otto to be already on 1.4, so the first step was terrible :)
<didrocks> elopio: well, we take trunk
<didrocks> if trunk ships to something not ready, it's upstream to ensure that it's not merged
<elopio> yes, I didn't know about that, I suppose thomi didn't either.
<didrocks> it's the case for more than a year :)
<elopio> I guess it would not have problems changing trunk to be 1.3
<didrocks> elopio: yeah, please do that for now
<didrocks> lp:autopilot pointing to 1.3
<didrocks> elopio: then, it's the autopilot package breaking -autopilot debs
<elopio> didrocks: I'll tell him as soon as he starts.
<didrocks> so that one needs to express a Breaks: unity8-autopilot (<< version with the fix>
<didrocks> and so on
<didrocks> elopio: I can do it if needed
<didrocks> elopio: so changing from ~autopilot/autopilot/trunk to ~autopilot/autopilot/1.3?
<elopio> didrocks: well, that's what you suggested. Sounds good for me, I don't know if thomi will have something against that.
<elopio> I suppose not. And we can always go back if things go wrong, right?
<didrocks> elopio: right
<didrocks> elopio: done, can you sync with him? :)
<didrocks> elopio: then, same, please don't merge anything for 1.4 compatibility on projects
<didrocks> just be ready to flip the switch on the same day
<didrocks> getting us aware
<didrocks> and we do the transition in one shot
<didrocks> (even if I think autopilot should really understands they have to be backward compatible now)
<didrocks> sil2100: I've switch lp:autopilot back to 1.3, can you please rekick an autopilot build for the ppa?
<elopio> didrocks: yes, I will discuss with him. But now it's not clear for me how to move forward.
<elopio> do you want all the projects to have a branch 1.4 ready at the same time?
<didrocks> elopio: yeah, and we flip the switch for the transition the same day
<didrocks> having a landing ask for it
<elopio> didrocks: ok, this is blocking me so I think I will spend today updating everywhere.
<elopio> balloons: ^^
<didrocks> elopio: thanks :)
<elopio> didrocks: now, why would I need to add a Breaks section on the control file? Wouldn't it be enough to tell that we depend on libautopilot-qt ( >= 1.4 ) ?
<balloons> ok so autopilot stays 1.3 until everything is ready for 1.4, then we'll transition at once, n'est pas?
<didrocks> balloons: exactement!
<didrocks> elopio: that's fine as well
<didrocks> elopio: but you need to tell you breaks (<< 1.3)
<elopio> didrocks: ok, I didn't get it :) I'll start with the toolkit and ask for your review, that's going to be easier.
<didrocks> elopio: sure!
<renato_> elopio, fginther since the problem is nor related with the code could you merge my MR?
<renato_> *not
<elopio> renato_: the tests should pass after sil2100 rebuilds the ppa.
<fginther> elopio, ack. ping me when that's ready and I'll rebuild the job
<didrocks> sil2100: kenvandine: robru: joining?
<didrocks> plars: ^
<plars> didrocks: ack, brt
<mlankhorst> hey
<elopio> didrocks, sil2100: do you know where can I get libautopilot-1.4 from?
<ogra_> == Build #5 running ===
<didrocks> elopio: we just removed it from the ppa, so I think there is an autopilot ppa
<didrocks> ogra_: \o/
<vila> bug #1244324
<ubot5> bug 1244324 in glamor-egl (Ubuntu) "glamor-egl crashes when running autopilot tests" [High,Triaged] https://launchpad.net/bugs/1244324
<ogra_> == Build #5 done ===
<popey> \o/
<nik90> @ci, I heard before that the core apps which are currently present as click packages on the phone will continously be updated via the app store just like any other app. However what happens to the dependencies that these click packages depend on? Will they also be updated?
<nik90> @ci, an example in my case is the clock app which depends on the EDS. Will EDS be updated for those running the builds 101 saucy?
<nik90> @ci or should I be asking those users to upgrade to trusty build 5 for that?
<cjohnston> nik90: that doesn't sound like a CI related question
<nik90> cjohnston: but it is related to app updates landing in the platform?
<cjohnston> That still sounds like a development related question
<josepht> nik90: fwiw, please use 'cihelp' rather than '@ci'.  The latter was causing us some issues.
<josepht> cjwatson: do you have any thoughts on nik90's question? ^
<fginther> nik90, that's a question better suited for #ubuntu-touch
<fginther> popey, do you know the answer to nik90's ? ^
<sil2100> elopio: ok, it seems the QA stack got stuck because of autopilot-gtk/-qt
<nik90> fginther: okay. I will also ask on ubuntu-touch
<nik90> josepht: okay, didnt see the updated channel header. P
<elopio> sil2100: not sure what that means. Do you need us to help with something?
<cjwatson> josepht: not really, it's not up to me
<cjwatson> click packages only depend on "the system" and that gets updated by system image updates
<sil2100> elopio: no, but hm, I noticed that Didier retargetted lp:autopilot to lp:autopilot/1.3
<sil2100> elopio: are you guys aware of that?
<sil2100> I need to do the same for -gtk and -qt then
<cjwatson> sergiusens: click-sync seems unhappy
<sil2100> Anyway, I'll e-mail you guys about that anyway later on
<elopio> sil2100: we are. We are updating the tests to autopilot 1.4 so we can release 1.4 without breaking anything.
<sergiusens> cjwatson, yes, I logged on to ask you about that
<sil2100> elopio: awesome - so I did the same for autopilot-qt and autopilot-gtk, so now trunk series is the same as 1.3
<sergiusens> cjwatson, do you know of any changes going on in the infra? It's a proxy error that I see; wasn't aware of the proxy
<elopio> sil2100: thank you.
<sil2100> elopio: once 1.4 is ready, we just need to retarget trunk series again
<cjwatson> sergiusens: not that I've heard of
<sergiusens> elopio, since you are here; I was looking at the history for base.py, not sure why the call to dpkg-architecture was added from the comments
<cjwatson> sergiusens: but I have no involvement in the store side
<sergiusens> cjwatson, I'll talk to beuno; that said it's safe to disable for now
<elopio> sergiusens: it was there originally when I refactored the code. I didn't see a reason for it so I removed it.
<sergiusens> elopio, oh, would be interesting to know why it was there at all, we never needed it for the app tests that did not use the ui toolkit
<elopio> then it started failing on the phones and Mirv pointed out the reason I put on the comment.
<cjwatson> sergiusens: I'm about to vanish again and don't really mind the cron mail for now :)
<sergiusens> cjwatson, ok, if you don't mind; I'm ok with it
<cjwatson> would prefer to leave it enabled so that you can fix by pushing to its branch if necessary ...
<sergiusens> cjwatson, ack; but to confirm, there's no transparent or real proxy required now, right?
<elopio> sergiusens: Mirv replied to the email thread.
<cjwatson> sergiusens: I don't know
<sergiusens> elopio, yeah, but I was just talking to steve before; QT_SELECT is set
<cjwatson> honestly don't know enough about the setup to answer that
<sergiusens> elopio, did it fail when calling from the sdk? or did you always use phablet-test-run; that's the bits I'm missing
<sergiusens> cjwatson, I'll talk to the backend guys
<elopio> sergiusens: I don't know about that either. I wasn't working on the toolkit when it started failing, and Mirv took care of adding it back. Then I just cleaned it a little making a separate function so it would be easier to change again.
<elopio> but I can make a quick branch to throw to jenkins and see if it's working now.
<sergiusens> elopio, great, please do; I really think it's not needed
<sergiusens> cjwatson, if you are still there; can you see if there are any proxy envvars on snakefruit?
<sergiusens> shouldn't be picked up by the cron though...
<elopio> sergiusens: https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/launch_qmlscene/+merge/192576
<sergiusens> elopio, this runs the test out of the box?
<sergiusens> elopio, if it passes, don't forget to remove the dep on dpkg-dev
<elopio> sergiusens: it will eventually run all the tests in jenkins in all the devices. So if it works, I would say it's safe to remove the dep.
<sergiusens> elopio, if it fails next step is to look at how that runner is setup on jenkins
<elopio> but I would confirm with Mirv before.
<elopio> sergiusens: ack. I'll keep you guys posted on the email thread.
<cjwatson> sergiusens: neither in ubuntu-archive's default environment nor in its crontab
<sergiusens> cjwatson, yeah, just trying to figure out why the resp comes from a squid on localhost:3128
<sergiusens> when downloading the actual package
<thomi> sil2100: ping?
<sil2100> thomi: pong!
<thomi> sil2100: hey man - just wondering if you know why the autopilot trunk series was changes to point to the 1.3 branch?
<sil2100> thomi: that's a valid question! I wasn't around when this happened, but it seems this is the way in which Didier decided to force 'trusty' to use 1.3 instead of trunk
<sil2100> thomi: no idea why he didn't just modify cu2d-config instead
<thomi> sil2100: OK. I realise it's not your fault, but it would have been nice if someone told me
<sil2100> thomi: since when I appeared it was already like that, I decided to do the same temporarily for -qt and -gtk as well...
<thomi> I'm changing it back now, because it makes it impossible for people to easily get the 1.4 source code
<thomi> :(
<thomi> ok, I'm changing them all back then :)
<sil2100> hmmm, oh, ok, so maybe I'll prepare a cu2d-config switch then
<thomi> if you guys want 1.3 in trusty, I think you ought to change the cu2d config
<thomi> thanks
<sil2100> thomi: switch back autopilot-qt and -gtk if you have a moment ;)
<thomi> sil2100: I will :)
<sil2100> thomi: sorry about that, elopio was aware of that it seems (probably didrocks told him)
<thomi> thanks man
<thomi> that's OK, I found out in the end.
<sil2100> I didn't know what was the rationale so I decided to keep it until Didier pops up ;D
<thomi> I'm changing the project maintainer to be the Qa team, so this can't happen again
<josepht> thomi: the bug I mentioned yesterday turned out to be in pyjunitxml not autopilot.  Patch submitted.
<thomi> josepht: awesome :)
<xnox> Is platform-api going to be rebuild into trusty soon?
<xnox> (as in the Ubuntu Archive)
#ubuntu-ci-eng 2013-10-25
<thomi> Could someome please take a look at the failures happening here when they get a chance? https://jenkins.qa.ubuntu.com/job/autopilot-trusty-amd64-ci/2/console
 * Mirv the critical bug filer
<didrocks> :)
<didrocks> Mirv: karma!
<Mirv> that indeed
<Mirv> ok the stack status / critical bugs start now to be up-to-date reflecting the real situation of stacks. I'm still running apps tests, and waiting for info if it's known that some unity8 tests fail on desktop.
<Mirv> some config updates, two new critical bugs this morning for test failures
<Mirv> oh, three bugs, that is
<Mirv> forgot about indicators
<didrocks> nice to get that cleaned, thanks for tracking Mirv :)
<Mirv> yw, now unity8 bugged too, and apps sharing the sdk bug
<vila> didrocks, Mirv : Let me start by some clarification: thanks a lot for your help yesterday, I couldn't have reached the point where bug #1244324 were filed without you.
<ubot5> bug 1244324 in glamor-egl (Ubuntu) "glamor-egl crashes when running autopilot tests" [High,Triaged] https://launchpad.net/bugs/1244324
<didrocks> glamor-egl? I'm not even aware about that one
<Mirv> interesting, it's now the default on some radeons?
<didrocks>  Glamor is a library for accelerating 2D graphics using GL functions.
<Mirv> I thought it was mainly only the newest ones like Radeon 7000
<didrocks> humâ¦
<vila> didrocks, Mirv: My fresh understanding is that it's the only option mlankhorst needed to reproduce locally even on a different hardware
<Mirv> since AMD hasn't worked on normal 2d acceleration support anymore on those newest ones
<didrocks> vila: do you know if all ATI hw are using it or we just got "lucky" :)
<didrocks> Mirv: so, it's a layer on top of gles?
<vila> didrocks: no and mlankhorst is EOW
<Mirv> didrocks: it bypasses the need to code EXA acceleration when new cards come in
<vila> Mirv: but yeah, I *think* that's to provide 3D
<didrocks> interesting
<Mirv> vila: no, it's to provide 2D acceleration with cards that don't have it otherwise
<Mirv> vila: which Radeon the machine was running with again?
<didrocks> Mirv: so, it should be for underperforming cards, right?
<vila> 7750 (as in qa-radeon-7750 ;)
<Mirv> "GLAMOR provides 2D acceleration on the Radeon HD 7000 "Southern Islands" GPUs and newer Radeon GPUs"
<Mirv> vila: oh, right, it's one of the newest ones, right
<vila> Mirv: where do you get that ?
<Mirv> vila: http://www.phoronix.com/scan.php?page=news_item&px=MTQ2MzA
<vila> Mirv: here we go ! *Now* the knowledge spreads :)
<Mirv> didrocks: no, for new cards that AMD/community doesn't have resources (or otherwise deems better) to build a separate 2D accel support
<didrocks> Mirv: ah, ok, starting to make sense :)
<Mirv> so it turns out that glamor is not yet bug free
<didrocks> unsurprinsingly ;)
<vila> Mirv: and you googled (^Wduckduckgo'ed) that page with which keywords ? ;)
<Mirv> vila: glamor default
<vila> Mirv: thanks, will put that in the incident report when I get there \o/
<vila> Mirv: indeed ranked 4 in https://duckduckgo.com/?q=glamor%20default&kl=us-en&kp=-1 well done !
<sil2100> didrocks: hi! Did you have a discussion about the AP switch to 1.3 with thomi in the end? Since when he started his day he was unaware of anything
<sil2100> Like, with the possibility of switching back lp:autopilot to /1.3
<didrocks> sil2100: it was on IRC, he was pinged for it
<didrocks> sil2100: hey! btw ;)
<didrocks> sil2100: so I thought he got the info
<didrocks> sil2100: did you saw my email?
<sil2100> didrocks: yes yes, that's also why I'm asking - since we might want to chat with thomi about the possibility of doing that switch again
<sil2100> With all the proper explaination to him 'why' ;)
<didrocks> sil2100: I'm clearly not happy that thomi turned lp:autopilot to point to 1.4 with having a backward compatbility issue (that's not sustainable) and that they did that without converting the app AP tests
<didrocks> sil2100: that's what we explained on IRC, if people stay on IRC to get pings but don't scrollbackâ¦
<sil2100> My understanding in the past was that it was being worked on
<sil2100> But it seemed that it didn't...
<didrocks> sil2100: yeah, but not turning lp:autopilot to the incompatible version *beforehand*
<didrocks> I wonder if management won't force autopilot to be backward compatible anyway
<didrocks> like the sdk, we shipped a version to the community
<didrocks> it's time to ensure our API is stable
<didrocks> or at least having good practices, like a deprecation period
<sil2100> didrocks: true, I guess with crucial components like this I think we need to provide a more-or-less stable API even between versions
<sil2100> Right
<didrocks> seems we have neither of them :(
<didrocks> sil2100: anyway, otherwise, how went your "hunt for getting all stack yellow"?
<ogra_> hrm
<didrocks> I think AP 1.4 was part of it?
 * ogra_ sees no landing sheet entry for mterry's seed change 
<didrocks> sil2100: btw, you were pinged on this 1.3 switch yesterday as well, but it seems you were not there for 2 hours (and during the meeting)
<ogra_> nor do i see it being discussed in any backlog
<didrocks> ogra_: ah, I was wondering if he did that directly with you
<ogra_> nope
<sil2100> didrocks: yes, along with psivaa we were trying to find the problems of the AP tests and this was the main culprit of most issues we were encountering back then
<didrocks> sil2100: so, all should be yellow now?
<ogra_> and it sounds a little harmful to drop qtaudioengine
<didrocks> ogra_: yeah, I thought you were involved, so knew about it ;)
<ogra_> no, not at all
<sil2100> didrocks: sorry about that, been AFK after a late lunch and missed the time :/
<didrocks> ogra_: it's from sdk-libs, so it's still installed by the touch meta package?
<ogra_> yep
<sil2100> didrocks: we have normal AP issues now mostly
<didrocks> sil2100: ok, so you are tracking that with upstream to get those fixed?
<didrocks> ogra_: so not *that* urgent, we can have a discussion with mterry if you want
<ogra_> didrocks, yeah, i just dont feel like rolling an image before we did that
<didrocks> ogra_: sorry, I probably didn't get it then. sdk-libs is just when you want to install the sdk to develop, right?
<sil2100> didrocks: yes, we're basically waiting for the right people to pop up
<didrocks> or ubuntu-touch -> deps on sdk-libs -> which deps on the audio stuff?
<didrocks> sil2100: ok, do you see landings we can proceed meanwhile? (from the landing ask)
<didrocks> sil2100: feel free to add them (just not target an image yet, we'll discuss that in the meeting)
<ogra_> didrocks, no, thats sdk-libs-dev
<didrocks> oh ok
<ogra_> sdk-libs actually carries our API
<didrocks> ok, so we can't really redo without knowing the impact
<didrocks> nothing in the seed?
 * didrocks bzr checkout lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.trusty
<didrocks>   Drop QtAudioEngine plugin from sdk-libs, it is currently unused and will pull a lot of stuff into main
<didrocks> - * qtdeclarative5-qtaudioengine-plugin
<didrocks> Mirv: any opinion? ^
<didrocks> do we use another audio system for qml?
<didrocks> like maybe   * qtdeclarative5-qtmultimedia-plugin
<ogra_> we use pulse
<ogra_> but not sure through which channel
<ogra_> for Ot apps this might still be needed to talk to pulse
 * didrocks smells we use it through qtmultimedia for qml apps
<Mirv> didrocks: yes so zoltan + me approved removing it for now, there is other support but game makers may want positional audio so it should be a goal to add it back (+ openal & co. to main) at some point
<didrocks> Mirv: ok, but droping for now is fine, nothing is using it?
<didrocks> ogra_: ^
<ogra_> Mirv, and this has been tested with apps from the store on the phones ?
<ogra_> (not sure how many we ship by default that would make use of this)
<Mirv> didrocks: ogra_: a few weeks ago it was checked that no packages were found that would declare a dependency on it (I grepped the whole file system), but I did not have and every store app installed
<ogra_> Mirv, all apps using the sdk should just depend on sdk-libs ... which in turn will hide the dep
<didrocks> the issue is that on saucy we dep on it
<ogra_> my concern is that we are changing the API
<Mirv> ogra_: yeah, that's why I used some grep of the whole filesystem to find mentions of it
<ogra_> without *any* tests or even discussion
<didrocks> so we are potentially telling people "please use it"
<didrocks> and now we are dropping the functionality from v2 of the sdk
<ogra_> Mirv, wasnt the agreement that we just drop the harmful pieces from qtdeclarative5-qtmultimedia-plugin ?
<Mirv> actually the root of this was to get cordova to main for saucy, which is why the temporary drop was wanted. they're still driving it, though.
<Mirv> ogra_: this is it? dropping the audioengine package from qtmultimedia
<sil2100> thomi: ping
<Mirv> if I could decide I'd keep it and get the dependencies to main for trusty.
<ogra_> Mirv, as i understood the audioengine plugin weas still wanted just without the harmful lib as dep
<Mirv> ogra_: ok, well openal is a strict dependency to the audioengine, just not to the normal audio/multimedia support
<Mirv> it's not like "the" Qt audio engine, it's a 3d positional audio engine
<ogra_> Mirv, so what was the patch that i saw that just removed openal from this package in saucy ?
<ogra_> without completely removing it
 * ogra_ tries to find the bug again ... i know there was a finer grained change than bluntly removing the whole plugin
<ogra_> (wasnt that even written by you  ?!?)
<Mirv> ogra_: I haven't seen such. it doesn't build the qtaudioengine if you drop the dependency.
<ogra_> ah
<ogra_> https://code.launchpad.net/~timo-jyrinki/ubuntu/trusty/qtmultimedia-opensource-src/drop_qtaudioengine
<ogra_> that was the one i remembered
<Mirv> bug #1206268 is the main bug
<ubot5> bug 1206268 in qtmultimedia-opensource-src (Ubuntu) "[MIR] unity-webapps-qml" [Undecided,In progress] https://launchpad.net/bugs/1206268
<ogra_> and indeed you are right, no code changes
<ogra_> but again, we have a hard defined ABI that lives in sdk-libs
<ogra_> and this API was just changed without discussion or warning
<ogra_> i agree that it is unlikely that someone uses positional audio in touch games
<ogra_> nontheless we guarantee API stability and such changes need a broad discussion imho
<Mirv> it wasn't really changed, of course, because it has been blocked. I've just stated that from my part it's ok.
<ogra_> right
<Mirv> I think the real issue here is that there has been no-one driving that MIR really
<Mirv> I've helped when I've been asked to
<ogra_> well
<Mirv> like, no "one" driving
<ogra_> i saw someone driving it ... and messing it up several times now
<ogra_> which makes me cautious about changes caused by it
<ogra_> lets keep that for the meeting, i dont really know what to do here
<ogra_> while it is technically right to drop it, the way it was dropped was definitely as wroing as it could be in the light that we promote API stability
<Mirv> I believe a MIR like that should be primarily driven by the team behind it, ie webapps team? but then in practice they've asked robru to do it.
 * ogra_ gets coffee before the meeting, brb
<Mirv> and then there have been zoltan, mterry, me, xnox striking at it too
<didrocks> sil2100: Mirv: ogra_: coming?
<Mirv> yep
<sil2100> Coming
<asac> omg my noternet starts again
<asac> cyphermox: i really need this threshold fix
<asac> cyphermox: wpa is on a 35/70 quality AP while i have one with 70 right next to it
<vila> asac: you broke
<ogra_> asac, youre not moving anymore OMG !
<asac> will be back in 5 minutes
<ogra_> double vision !
<asac> i should be bak
<ogra_> yep
<sil2100> Mirv: can you take a look here? https://code.launchpad.net/~sil2100/cupstream2distro-config/trusty_fixes_projects/+merge/192602
<sil2100> :)
<sil2100> Mirv: since we decided to use this for now
<Mirv> sil2100: I had already disabled u-s-c a few hours ago
<Mirv> approved otherwise
<sil2100> Mirv: yes, I fixed that ;) Thanks
<sil2100> I need to get my phone updated to trusty I guess
<sil2100> ogra_: how can I get trusty on my phone?
<sil2100> AH, ok, channel trusty
<xnox> Mirv: your patches look fine =) but web-browser app has been attempted to be seeded too early (before qtmultimedia was done).
<didrocks> sil2100: trusty-proposed please :)
<sil2100> Using that actually ;)
<didrocks> you want the latest of latest!
<didrocks> the best of the best!
<didrocks> :)
<ogra_> sil2100, adb shell system-image-cli -c trusty -b 0
<didrocks> ogra_: that do work now?
<ogra_> or even trusty-proposed :)
<didrocks> did you get why it wasn't working for you yesterday?
<ogra_> didrocks, -b 0 ...
 * didrocks uses man
<xnox> Mirv: ogra_: re: api/abi stability our 13.10 sdk is unchanged ;-)
<ogra_> it only does the upÃ¼date if i tell it it is on revision 0 of the new channel
<ogra_> xnox, how do you mean ?
<didrocks> ogra_: oh ok
<didrocks> so we still expect to have a higher version
<xnox> ogra_: well we are not going retrospecivily drop qtaudioengine in 13.10, it's a change in 14.04 sdk and up. And well we can easily scan current clicks in the store about it, and add review warning if somebody does use it.
<ogra_> didrocks, it automatically uses the latest image in the new channel
<ogra_> xnox, we are also not dropping anything from the touch seeds (and the API) that wasnt even publically discussed
<ogra_> and had no entry on the landing plan ... and had not a single AP test etc
<ogra_> xnox, i'm in the middle of reverting it now and will send a mail to -devel and -phone
<didrocks> ogra_: why do we need -b0 then, it's not because we have image 100 on the other channel and 5 < 100?
<ogra_> didrocks, yeah, i think thats the reason, barry would know more
<didrocks> ok :)
<vila> didrocks: waiting for your ping ;)
<didrocks> vila: yeah, in 3 minutes :)
 * ogra_ wonders why msm is in the next meeting
 * ogra_ gets more coffee
<vila> ogra_: she organized it may be ;)
<ogra_> ah
<vila> didrocks: cool !
<ogra_> well, she is listed as participant :)
<didrocks> ogra_: no coffee for you! you have 8 minutes to promote the image :p
<didrocks> omg I pinged ogra_ too late
<didrocks> he has already left for coffee
<didrocks> we're screwed :)
<Mirv> noooooo
<didrocks> heh
<Mirv> didrocks: two packaging acks, to get trusty landings started. those also consist of the whole diff of what's in the changes. http://10.97.0.1:8080/view/cu2d/view/Head/view/WebCreds/job/cu2d-webcred-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_signon-ui_0.15+14.04.20131024.2-0ubuntu1.diff
<Mirv> + http://10.97.0.1:8080/view/cu2d/view/Head/view/Friends/job/cu2d-friends-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_libfriends_0.1.2+14.04.20131024.2-0ubuntu1.diff
<didrocks> waow, my 2 first packaging ack for this cycle, we should celebrate :)
<Mirv> yep :)
<didrocks> Mirv: btw, I think it's time for you to move on the upload access side
<didrocks> let me check that the packaging fixes are fine first :)
<didrocks> Mirv: -IT_PROG_INTLTOOL([0.40])
<didrocks> +IT_PROG_INTLTOOL(0.50.0)
<Mirv> didrocks: yeah I already started btw https://wiki.ubuntu.com/TimoJyrinki/DeveloperApplication-PPU as well during saucy but I've been too exhausted to hunt for approvals
<didrocks> it could have bumped the build-dep in debian/control on intltool
<didrocks> Mirv: ah, great! let's discuss that next week
<xnox> ogra_: reverting what? nothing was uploaded as far as I can tell, or changed.
<Mirv> well I asked seb and he promised but never did ;)
<alan_g> does anyone know what causes this? https://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/2/console (it doesn't seem to have anything to do with the code changes)
<didrocks> Mirv: can you remind me about this?
<didrocks> Mirv: not a blocker for intltool, but nice if you can then merge a fix for it
<didrocks> Mirv: oh, signon builds on all archs? nice. +1 then :)
<vila> Mirv: Can I haz a button after: '/!\ Remember that this diff only represents packaging changes and build tools diff, not the whole content diff!' :-p
<Mirv> didrocks: remind next week? yes.
<didrocks> please publish both
<Mirv> didrocks: the libfriends only specified intltool in general as a dependency, but I can add a version
<didrocks> Mirv: would be nice!
<xnox> ogra_: and well *crap* happens, and we do probably want webrowser-app on the desktop / converged story. It is unfortunate that it pulled in crap in-advertadly, it would have been spotted earlier if our sdk was fully in main.
<Mirv> ok
<Mirv> didrocks: I don't think the signon-ui really builds on all archs (needs qtdeclarative), but the policy has been to remove those tri-arch defines. also I guess with Qt 5.2 and removal of V8 JavaScript engine they might start to work as well.
<didrocks> Mirv: if you are sure it will move from PROPOSED, I'm fine :)
<Mirv> didrocks: it should, there has been now powerpc/arm64 releases in trusty, and the powerpc one in saucy was removed in August
<didrocks> Mirv: ok, let's go then!
<vila> cjwatson: how should I ask to get https://cloud-images.ubuntu.com/query/trusty/server/daily-dl.current.txt non 404'ing ?
<vila> meh s/how/who./
<vila> cjwatson: alternatively, ~same question to have trusty in http://cdimage.ubuntu.com/ubuntu-server/daily/current/ ?
<cjwatson> vila: me and I'll be working on it today
<cjwatson> vila: only for the latter though, can't do the cloud images
<vila> cjwatson: great ! thanks !
<cjwatson> try smoser or utlemming for those
<vila> cjwatson: right, US tzs for both so will have to wait
<vila> cjwatson: perfect answer, thanks
<cjwatson> didrocks: we're getting back to the point where if things don't migrate I might actually notice ...
 * vila &
<cjwatson> ubuntu-keyboard needs to be rebuilt against libpinyin4
<didrocks> cjwatson: yeah, I don't want you to have to suffer from us though
<cjwatson> I won't
<didrocks> cjwatson: we have an ubuntu-keyboard in progress, so that can maybe catch it
<cjwatson> touch's contribution to stuff stuck in -proposed is a drop in the ocean
<didrocks> yeah, I imagine :) just don't want to add *more* to you ;)
<ogra_> heh
<didrocks> sil2100: ubuntu-keyboard going fine? (see ^)
<ogra_> didrocks, asac, popey, calls and sms tested on maguro for image #5, looks fine, but we need someone to mail avengers while popey is out
<didrocks> ogra_: can you do it? Do you know what's popey's procedure?
<ogra_> didrocks, no
<ogra_> thats why i mentioned it :)
<didrocks> maybe asac will know :)
<ogra_> avengers is a members only ML
 * ogra_ is afk for a bit
<asac> didrocks: why dont you become part of the list and do the announces?
<didrocks> asac: I'm all in for that, but I even don't know what the avengers team is
<didrocks> https://launchpad.net/~avengers doesn't seem to be that one
<didrocks> neither https://launchpad.net/~avenger
<asac> didrocks: https://launchpad.net/~ubuntu-avengers
<asac> :-P
 * asac has a good awesome bar :)
<didrocks> asac: it's an invite only list, I need then Jono or Julien to add me
<didrocks> asac: so, meanwhile, can you send that email so that we can promote the image?
 * didrocks hopes sil2100 published before the rerun of all stacks ubuntu-keyboard
<didrocks> sil2100: did you get an early lunch this time? :)
<asac> didrocks: ok sending
<asac> didrocks: was the image tested on mako at all?
<asac> (with popey being gone)
<didrocks> asac: yeah, popey did the testing this morning early
<didrocks> (mentionned during the meeting)
<didrocks> ogra_: please promote!
<didrocks> Mirv: dialer-app -> fine for publishing?
<didrocks> (same question for content-hub)
<asac> didrocks: done
<didrocks> thanks asac ;)
<asac> do we have a 2 factor app for ubuntu phone in store?
<asac> factor auth app
<asac> 2
<didrocks> yeah, u<something>
<asac> really?
<asac> cool
<asac> heh. seems the click scope again is gone (Guess crashed)
 * asac reboots phone
<didrocks> asac: http://notyetthere.org/?p=351
<asac> cool
 * asac tries system update
<asac> first
<Mirv> didrocks: so ken tested them? for dialer-app, there was a desktop test failure for which I filed a bug in the morning. content-hub, which is also marked as ready to land, is fine from cu2d perspective and I could releaseit.
<didrocks> Mirv: yes, please release it :)
<didrocks> for dialer-app 6> ok
<didrocks> Mirv: can you anotate dialer-app test failure on the landing ask?
<didrocks> Mirv: did you ping upstream as well?
<didrocks> (in case they are not on top of their bugs?)
<Mirv> didrocks: ok, ok, and no ping yet, I suggested on the call that sil2100 would ping about the AP failures
<didrocks> sil2100: have you? ^
<ogra_> asac, "Autthenticator" is the 2fa app
<Mirv> didrocks: http://10.97.0.1:8080/view/cu2d/view/Head/view/Services/job/cu2d-services-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_content-hub_0.0+14.04.20131024.2-0ubuntu1.diff - seems ok to me, indeed adds the QML plugin docs to the doc package
<didrocks> Mirv: +1 ;)
<asac> ogra_: wow... even qrcode works :)
<vila> asac, didrocks : 2fa on touch is called Authenticator, darn ogra_ beated me to it ;)
 * asac super impressed
<ogra_> asac, mzanetti's work :)
<vila> asac: be aware that it seems you can't configure both the g one and authenticator on sso
<asac> vila: sure?
<vila> or rather, I did add authenticator but sso seems to recognize the codes from that g one
<ogra_> asac, didrocks, popey, so i released 5/20131024 ... http://people.canonical.com/~ogra/touch-image-stats/20131024.changes is the matching changelog
<asac> well. it has now both devices
<vila> asac: only light tests, no time to dig at the time
 * asac hopes
<asac> will find out soon enough... at least yubi and android worked well
<asac> together
<ogra_> yeah, shouldnt cause issues
<didrocks> ogra_: niceness!
<ogra_> didrocks, well, someone needs to mail :)
<didrocks> ogra_: asac did
<sil2100> Early ;p
<ogra_> bah, i just had the launcher crash
 * ogra_ has never seen that 
<ogra_> all swipe gestures work, just not the left to right one that brings you back to the shell (or reveals the launcher)
 * didrocks really goes for a run
<vila> ogra_: not at all or only not enough to revel the shell ?
<vila> *reveal
<ogra_> not at all
<ogra_> i have seen the "snap back" thing before that you seem to refer to
<vila> never seen then
<vila> right, any workaround for that ? (I generally just reboot)
<ogra_> well, i rebooted already ...
<ogra_> apart from filing a bug and nagging Mir and unity people ?
<ogra_> no :)
<didrocks> in fact, I can't go for a run, no music :/
<ogra_> oh ?
 * didrocks plugs it and put that on the "later on" plate (so after the meeting)
<didrocks> ogra_: sucky battery, I charged it for 30 minutes and it went off in 10â¦
<ogra_> ah, just wanted to say, music playback works fine here :)
<didrocks> ahah, no, I don't use my nexus4 while running :p
<ogra_> why not ?
<didrocks> too heavy
<ogra_> ah
<didrocks> (and risky)
<didrocks> if I feel down as I already didâ¦ ;)
 * vila hands his unused ipod to didrocks  ;)
<didrocks> or a car strikes me while riding a bikeâ¦
<didrocks> no more didrocks, but at least, the company has the neus 4
<didrocks> nexus 4
<didrocks> so didn't loose everything :p
<mzanetti> vila: first release of authenticator had a bug which made it fail to store the counter. Should be fixed now and it should be fine with having Google authenticator and Ubuntu authenticator registered at the same time
<cjwatson> heh
<cjwatson> I use my Nexus 4 while cycling quite happily
<cjwatson> (for navigation)
<vila> mzanetti: omg, that would be awesome !
<asac> mzanetti: its awesome! thanks for this app
<didrocks> cjwatson: do you have something to hang it? (or you just cycle with one hand?)
<cjwatson> didrocks: upper jacket pocket
<cjwatson> I do want to get a handlebar mount for it at some point; in the meantime as long as it's close enough I can hear voice directions
<didrocks> ah ok, so you don't use the screen, just the voice directions
<cjwatson> I'm not suicidal, I use both hands :)
<didrocks> heh :)
 * ogra_ uses it that way in the car actually
<mzanetti> asac: you're welcome
<ogra_> voice directions via earphone
<ogra_> no distracting screen
<didrocks> well, even with both hands, in Lyon, just doing the 5 kms that separate me from the park is a little bit suicidal sometimesâ¦
<cjwatson> yeah, occasionally I have to stop and look at the screen, but on a bike that's not a big deal
<ogra_> haha, move to a safe place then :)
<cjwatson> would be more troublesome if I drove
<didrocks> ogra_: well, I like to not needing owning a car TBH
<didrocks> and just rent one when needed :)
<vila> mzanetti: urgh, weird case here, at some point auth wsa removed from the phone, I just re-installed it BUT it remembers the previous settings, how can I reset that ?
<asac> psivaa: plars: can we give http://reports.qa.ubuntu.com/smokeng/trusty/touch_custom/ some love too?
<mzanetti> vila: you can just swipe the account away to delete it
<asac> psivaa: plars: like retrying and complaining in meetings if stuff is bad there?
<asac> thanks
<vila> mzanetti: a.w.e.s.o.m.e ;)
<mzanetti> :)
<ogra_> which reminds me to invest another hour to package more webapps today :)
<mzanetti> ogra_: yeah! I already finished the blocks game
<ogra_> oh my !
<mzanetti> ;D
<vila> mzanetti: woohoo it works !
<ogra_> the site thats from has a bunch more, no worries :)
<mzanetti> :D
<vila> now I can get rid of my SIM-less android phone \o/
<mzanetti> that was my intention ^^
 * ogra_ just discovered the mobile mode of dict.cc yesterday evening :)
<vila> ogra_: and thanks for imdb !
<ogra_> just need to find an icon
<vila> ogra_: when will I be able to watch the trailers ? ;-D
<ogra_> which is usually the part taking the most time when packaging a webapp
<ogra_> vila, ask jhodapp
<ogra_> he is working on fixing the web streaming mode
<ogra_> you can watch them in trusty btw
<ogra_> like the first 100 frames or so ... then it becomes a slideshow ...
<ogra_> ... and then turns into a podcast :P
<vila> ogra_: you mean with image #5 or on the des... haa,  :)
<mzanetti> lol
<ogra_> from image #4 on it should work
<ogra_> just the rendering backend isnt finished yet
<didrocks> ogra_: "progressive degradation"
<ogra_> nah its all improving :P
<ogra_> saves your bandwith ... doesnt do that wasteful video stuff once you gotr an impression iof the pics
<ogra_> and falls back to the true info via audio ...
<ogra_> we should just call it a feature :P
<sil2100> didrocks, Mirv: yes, I was pinging people ragarding the issues - I guess the dialer-app and the 'apps' AP issues are being worked on right now, let me check the status
<Mirv> sil2100: so osomon? I'd have pinged him too in the morning but he was not up yet. but I assigned the bug to him.
<Mirv> sil2100: the dialer-app is still assigned to bfiller, did you find someone to look at that during European day?
<sil2100> Mirv: yes, I poked oSoMoN about that - dialer-app I posted to renato_, who forwarded it to tiagosh
<sil2100> Who is said to be working on that
<sil2100> Mirv: osomon is at lunch now, but he confirmed that he's looking at the issue
<Mirv> sil2100: cool, I didn't know about tiagosh
<psivaa> asac: sure, will take a look
<sil2100> ogra_: do you have a moment? Could you take a look at http://10.97.0.1:8080/view/cu2d/view/Head/view/Services/job/cu2d-services-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-keyboard_0.99.trunk.phablet2+14.04.20131025-0ubuntu1.diff ?
<sil2100> I'm a bit wondering about the (<< 1.4) part
<ogra_> well, if it would load i could look at it :P
<sil2100> !
<cjwatson> sil2100: the Depends change is safe
<sil2100> One moment ;)
<sil2100> https://jenkins.qa.ubuntu.com/view/cu2d/view/Head/view/Services/job/cu2d-services-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-keyboard_0.99.trunk.phablet2+14.04.20131025-0ubuntu1.diff
<ogra_> ah, a lot better
<cjwatson> it's a bit pointless, but it's safe
<ogra_> yeah, wont break a thing
<sil2100> cjwatson: that's what I was wondering, why we even need that right now
<sil2100> But ok, then I publish, thanks guys
<cjwatson> the package is going to have to be updated later anyway; but it's not too unreasonable to document the current restriction in the metadata
<ogra_> is there any .install file that might need to be adjusted to the removals ?
<ogra_> if there isnt, i'd say its fine
<fginther> morning
 * ogra_ scratches head ... i have a webapp click package that seems to not work, even though nothing seems to be wrong ... 
 * ogra_ wonders if that could be caused by rolling it as root inside a chroot 
<didrocks> ogra_: any issue on the perms? as apparmor just kill the appâ¦
<ogra_> didrocks, thats what i'm wondewring, is it forbidden to build click packages (or their contents) as root
<ogra_> oh !
<ogra_> WOW !
<ogra_> root@ubuntu-phablet:/# grep DEN /var/log/kern.log |wc -l
<ogra_> 80
<ogra_> thats a lot denials
<didrocks> here you go :)
<ogra_> didrocks, no, my webapp isnt in there
<didrocks> interesting, so we have that many other pieces denied by apparmor? we should definitively make a list and work on it
<ogra_> seems many webapps would like to access /run/shm
<didrocks> hum, weirdâ¦
<didrocks> I would think it would be more the container acting wrongly, wouldn't it?
<ogra_> and xnox' G+ app seems to like to fiddle with the pulse config in all places you can imagine
<mzanetti> ogra_: ah, btw. what I wanted to ask. for those games, are you just running webbrowser-app with the given url or are you creating a qml file with the UbuntuWebView?
<ogra_> mzanetti, just the former
<ogra_> they are all plain HTML5 games that you can as well just play in the browser
<mzanetti> ogra_: mhm... because I noticed they can be flicked up/down which is not nice during the gameplay.
<mzanetti> ogra_: the UbuntuWebView would give you the possiblity to disable that
<ogra_> mzanetti, i tried that but that seems to not work unless i actually use the SDK
<ogra_> it seems ot be missing bits and pieces if i just try to put a qml wrapper in place and build a click package
<xnox> ogra_: honestly, not by intend =) "with pulse config" ?! what did I do wrong? =))))
<ogra_> mzanetti, http://daker.me/2013/10/package-your-webapp-for-ubuntu-touch.html
<ogra_> mzanetti, thats what i tried to follow
<mzanetti> yeah... not working?
<ogra_> xnox, i'm pretty sure thats more a jdstrand thing
<ogra_> mzanetti, nope
<jdstrand> ogra_: can you paste those denials?
<mzanetti> hmm... can you tell me more? maybe I'm able to help you
<ogra_> jdstrand, http://paste.ubuntu.com/6300513/
<ogra_> mzanetti, i'll have to dig up the click for my slashdot app again ... will take a bit since i poked around a lot in there (and borke it)
<mzanetti> ogra_: ok sure. just drop me a mail with details when ready and I'll have a look
<ogra_> mzanetti, oh, looking at these denials it seems the slashdot test app is in the list too
<jdstrand> ogra_: you need the audio policy group
<xnox> ogra_: right if the webapps policy is too restrictive, than jdstrand should add stuff to it.
<jdstrand> ogra_: for webapps, I recommend audio, networking, video and location
<ogra_> jdstrand, well, xnox does :)
<jdstrand> xnox: ^
<jdstrand> xnox: fyi, https://wiki.ubuntu.com/SecurityTeam/Specifications/WebAppsConfinement
<ogra_> jdstrand, i usually only use video where appropriate ... but have usually audio and networking
<xnox> jdstrand: i think i only use webapps policy from the easy wrapper, or shall I declare those additional ones?
<jdstrand> xnox: what easy wrapper?
<ogra_> mzanetti, Oct 24 12:21:18 ubuntu-phablet kernel: [14309.845991] type=1400 audit(1382610078.837:199): apparmor="DENIED" operation="exec" parent=1977 profile="com.ubuntu.developer.ogra.slashdot_slashdot_0.1" name="/usr/bin/qtchooser" pid=17494 comm="exec-line-exec" requested_mask="x" denied_mask="x" fsuid=32011 ouid=0
<ogra_> so thats not the code but some missing policy when using the qml wrapper
<xnox> jdstrand: let me look.
<mzanetti> ogra_: mhm... right. at that point it's like a native app to the policy I guess
<jdstrand> fyi, qtchooser exec is allowed in the ubuntu-sdk and ubuntu-webapp templates
<ogra_> root@anubis:/root/apps/slashdot-app/package# cat slashdot.json
<ogra_> {
<ogra_> "template": "ubuntu-webapp",
<ogra_> "policy_groups": [
<ogra_> "networking"
<ogra_> ],
<ogra_> "policy_version": 1.0
<ogra_> }
<ogra_> well ...
<ogra_> that would mean it shoudl work :=
<ogra_> :)
<xnox> jdstrand: right, so I have template "ubuntu-webapp", but indeed only networking in the policy_groups. I guess I should add more.
<xnox> jdstrand: i thought template "ubuntu-webapps" would do that for me.
<ogra_> xnox, video and audio at least
<xnox> ogra_: can you file a bug against https://launchpad.net/click-webapps ?
<xnox> ogra_: that's where the source code is for my webapps & bug tracking.
<xnox> ogra_: such that I don't forget. And the one to do URLPatterns.
<jdstrand> xnox: no-- the template just allows the browser to run. arguably, networking should be included in it by default, but, meh. the others aren't necessarily needed for all webapps, so those definitely make sense to not be included
<jdstrand> xnox: but, I think sane defaults are all of them
<xnox> jdstrand: ack. Now I understand.
<jdstrand> xnox: so feel free to update your template
<ogra_> bug 1244654 and bug 1244656
<ubot5> bug 1244654 in click-webapps "G+ webapp needs audio and video in the policy setup" [Undecided,New] https://launchpad.net/bugs/1244654
<ubot5> bug 1244656 in click-webapps "G+ webapp should use --enable-back-forward --webappUrlPatterns=" [Undecided,New] https://launchpad.net/bugs/1244656
<ogra_> jdstrand, so that qtchooser denial ... could that be caused by files inside the click being root owned ? http://paste.ubuntu.com/6300585/
<jdstrand> shouldn't matter
 * ogra_ notes that this is probably the totally wrong channel to discuss this 
<jdstrand> ogra_: can you paste the apparmor profile for that app? cat /var/lib/apparmor/profiles/click_com.ubuntu.developer.ogra.slashdot_slashdot_0.1
<ogra_> http://paste.ubuntu.com/6300606/
<ogra_> oh, wow
<plars> asac: yes, I'm talking to sfeole about it
<ogra_> so my new webapps seem to cause entrieas in ~/.cache/upstart/application.log
<ogra_> start: Auftrag konnte nicht gestartet werden
<plars> asac: regarding the custom job stuff
<plars> psivaa: ^
<ogra_> (which means "cant run request" or some such)
<ogra_> smells like an upstart regression
<vila> jibel: hi
<vila> jibel: I need to re-install qa-radeon-7750 as a jenkins/otto node, didrocks said you may have a document describing that, can I haz ? ;)
<psivaa> plars: ack, was looking at why the diff in cutom unity8 tests. but if you are already dealing with that i'll leave it to you
<psivaa> s/cutom/custom
<vila> jibel: otherwise, Ill just go with a basic jenkins-slave and lp:otto in~jenkins + symlink for ~/bin and see what is missing
<plars> psivaa: unity8 tests are pretty broken for now at least, I'm more interested in the custom test failure, but I'll check unity8 too... it didn't seem to run right
<plars> psivaa: also there was a difference in webbrowser with the latest image. I can handle though
<psivaa> plars: the unity8 tests in custom jobs are not even starting to run
<jibel> vila, http://bazaar.launchpad.net/~otto-dev/otto/trunk/view/head:/doc/README
<jibel> vila, if you don't know how to do a server install with cobbler, retoaded can help you.
<vila> jibel: how did I miss that...
<vila> jibel: yeah, already done (no trusty image so he did saucy + upgrade), waiting for a server image to pop up, cjwatson said he will try to get it done today
<vila> jibel: thanks
<jibel> vila, meanwhile you can install saucy and upgrade to trusty
<vila> jibel: yup, already done, see above (already done yesterday evening)
<jibel> I mean you don't really need a server image of trusty for that because this machine is not supposed to be reinstalled often
<vila> jibel: ack, but the sooner this is automated the better
<alan_g> fginther: do you know what caused this? https://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/2/console (it doesn't seem to have anything to do with the code changes)
<fginther> alan_g, ack, looks like a missing piece of transition. I'll get that fixed
<alan_g> fginther: thanks
<elopio> ping sil2100: you talked with thomi about making autopilot trunk 1.4 again, right?
<sil2100> elopio: hi!
<elopio> hello :)
<sil2100> elopio: well, thomi did it by himself already yesterday, since it seems he wasn't informed about the decisions that happened earlier (he missed the pings about it)
<sil2100> elopio: so trunk is trunk now, but next week we'll be deciding on how to resolve it completely in the end
<elopio> sil2100: yes, I see that. But otto is now taking again autopilot 1.4. I think you discussed about changing the config to take 1.3. Who can do that?
<sil2100> elopio: otto should take 1.3 I guess
<sil2100> elopio: yesterday I already redeployed it to point to 1.3, now it points to 1.3-trusty, which is nothing more than an alias to 1.3
<elopio> sil2100: ah, nice! let me dig more on the failures then, becuase I thought it was just autopilot 1.4 again.
<fginther> alan_g, the mir-android-trusty-i386-build job is working now, would you like the failed jobs to be restarted?
<alan_g> fginther: thanks, no (I merged by hand to get it done)
<cjwatson> Is Qt going to be bumped to 5.1 any time soon?  There are a bunch of modules waiting for it in -proposed
<ogra_> cjwatson, well, 5.2 was just released (or is in the process to)
<ogra_> might be that we skip 5.1 ...
<ogra_> (topic for the sprint iirc)
<cjwatson> well, whatever
<cjwatson> but 5.1 is in Debian at the moment so it'd be a merge; I thought you guys liked to work stepwise
<ogra_> rsalveti is our Qt decider i think
<rsalveti> cjwatson: we can give it another try and see, but we got quite a few regressions in touch with 5.1
<rsalveti> something might be fixed already as it's in debian, will take a look
<ogra_> rsalveti, so we wont skip directly to 5.2 ?
<rsalveti> ogra_: if we can get 5.1 to work without much effort, I'd prefer to move in smaller steps, otherwise we can just migrate to 5.2 directly
<didrocks> jdstrand: joining the landing process feedback call?
<ogra_> k
<rsalveti> ogra_: just easier to find regression if we can move in smaller steps
<ogra_> yup, agreed
<jdstrand> didrocks: ok
<fginther> vila, cjohnston, either of you interested in reviewing: https://code.launchpad.net/~fginther/cupstream2distro-config/core-apps-trusty/+merge/192600
<cyphermox> asac, you on trusty? trusty already has the fix
<cyphermox> asac: so you could take the pacakge from there too, if you want
<cjohnston> fginther: done
<asac> cyphermox: just a single wpa supp deb?
<cyphermox> asac: no, that's a NM fix
<ogra_> didrocks, phablet-tools should be ready for going in
<cyphermox> libnm-glib4, libnm-util2, network-manager, gir1.2-networkmanager-1.0
<vila> fginther: oops, done a while ago, forgot to say :-/
<fginther> vila, cjohnston, I'm trying to get more exposure on these MPs, so please feel free to ask why thing are the way they are
<fginther> vila, cjohnston and thanks
<vila> fginther: in my case it was more about why it was needed, what triggered it and so on, context ;) But that may just be me being ignorant ;)
<cjohnston> vila: I couldn't figure out why he was adding trusty support :-)
<sil2100> grrr
<vila> cjohnston: ha, so, every 6 months we... ;)
<cjohnston> take a vacation?
<didrocks> ogra_: \o/ sil2100 can you release it?
<sil2100> didrocks: aye!
<ogra_> thanks !
<sil2100> Done
<sil2100> hm, nice that robru wrapped and sorted the packages: long lines, but actually it's harder copy and pasting those now
<ogra_> you mean the deps lines ?
<sil2100> ogra_: no, I mean in cu2d-config
<ogra_> ah
<ogra_> i thought the debian/control lines
<ogra_> (which i find one of the worst behaviors)
<didrocks> ogra_: sorting deps?
<ogra_> didrocks, making them unpasteable
<ogra_> by adding linebreaks after each comma
<didrocks> ah, I like linebreaks after each comma
<didrocks> makes diff easier to read
<ogra_> i hate it with passion
<didrocks> I'm just not on the trends of alphabetical order :)
<didrocks> I think logical order (and following the build system order) is better
<ogra_> makes it nearly impossible to quickly copy/paste to install i.e. build deps
<Laney> you can't do that anyway
<Laney> use mk-build-deps or something
<ogra_> apt-get install $(echo "my paste here" | sed 's/,/ /')
<Laney> mk-build-deps -i -r
<ogra_> yeah yeah ... nifty tools :P
<Laney> :)
<cjwatson> the paste strategy fails as soon as there are versions anyway, so why cling to it ...
<ogra_> dunno, because old habits die hard i guess :)
<plars> can someone please enable saucy builds in the phablet-team/tools ppa?
<sil2100> fginther: hi! How can I check if the merge job is working for a given merge already?
<sil2100> fginther: since I have been wondering why https://code.launchpad.net/~tiagosh/dialer-app/fix-autopilot-dependency/+merge/192688 wasn't yet merged
<sil2100> fginther: I once asked, but it popped out of my head already
<sil2100> didrocks: when we're installing packages from the testpackages: list, we install automatically all the dependencies of those packages, right?
<fginther> sil2100, go to the autolanding job for the branch - http://10.97.0.26:8080/job/dialer-app-autolanding/
<didrocks> sil2100: right!
<didrocks> no filter, nothing
<fginther> sil2100, and check the parameters for the running (or queued jobs)
<fginther> sil2100, in this case your MP is running
<sil2100> Running mediumtests I see
<sil2100> fginther: thanks!
<fginther> sil2100, there was a backup due to all of the maguro's failing overnight
<sil2100> fginther: are there tools to make it skip mediumtests actually? Since I don't think there's need for running those for this small merge, I tested on the daily build job that it works
<fginther> sil2100, no there is no way to change the configuration of a running job
<sil2100> Too bad, thanks!
<fginther> sil2100, based on the speed of flashing phones and running tests, it should be done within an hour
<sil2100> fginther: good to know!
<tedg> ev, So after release, we run whoopsie but not apport... does that mean we don't get files in bug reports apport would normally attach?
<sil2100> tedg: hi! Do you know who could look into https://bugs.launchpad.net/hud/+bug/1244704 ?
<ubot5> Ubuntu bug 1244704 in Unity HUD "Some test_hud tests fail on trusty desktop" [Critical,New]
<tedg> sil2100, Looks like an autopilot issue?  I see the HUD appear and disappear in that video: http://10.97.0.1:8080/job/autopilot-trusty-daily_release/104/label=autopilot-nvidia/artifact/results/autopilot/videos/unity.tests.test_hud.HudBehaviorTests.test_no_initial_values.ogv
<didrocks> ogra_: sil2100: cyphermox: robru: kenvandine: if everyone is here, do you want to listen to the qbr call? we can proceed the meeting in advance if you prefer
<sil2100> didrocks: not sure personally
<didrocks> ok, can wait for 8 minutes then
<sil2100> Ah, actually I can't join the call right now, I don't really have a normal phone while mobile phones have problems with connecting to the conference call line
 * sil2100 didn't bother with a normal phone since we're using hangouts normaly anyway
<tedg> sil2100, There's an icecast stream
<didrocks> sil2100: can you write your summary then?
<didrocks> sil2100: like, you are taking care of dialer-app?
<didrocks> I saw you tracked that
<sil2100> didrocks: dialer-app is taken care of already - just waiting for the merge to finally get merged, trying to poke people with other test failure
<didrocks> ah, can't join the call
<didrocks> not the hangout :)
<didrocks> ok, making sense
<sil2100> Right ;)
<didrocks> don't tease me then!
<sil2100> ;D
<didrocks> keep that for the big meeting revelation ;)
<sil2100> tedg: thanks for the info
<sil2100> tedg: as for the failures, those might be AP-only related, but actually there was no change in AP 1.3, so the issue might be somewhere else as well that we suddenly ahve those failures
<sil2100> tedg: maybe I'll poke bregma about those failures, as those are from the unity source?
<tedg> sil2100, Yeah, it does seem odd.  The focus change one is odd as well.   But we did change that code recently-ish (two weeks ago)
<ogra_> i'll be late for the meeting (need to catch the cat for susie, so she can get her to the vet)
<didrocks> ogra_: Â°1
<didrocks> cyphermox: 1. mir, 2. platform-api, xserver-xorg-xmir (second one is a no-change rebuild), unity-system-compositor, 3. libunity-mir
<cyphermox> kgunn: you'll let me know when this stuff is ready?
<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> any objections or shall I go ahead?
<cjwatson> not especially major changes
<cjwatson> http://paste.ubuntu.com/6301459/
<sil2100> tedg: one more thing, did you see bug #1244522 ?
<ubot5> bug 1244522 in Network Menu "indicator-network FTBFS in trusty (new vala?)" [Critical,New] https://launchpad.net/bugs/1244522
<didrocks> plars: if you have any ringing bell -> email is fine as well :)
<didrocks> plars: but as we'll be in the same timezone, that will be easier ;)
<didrocks> on*
<didrocks> well on the ***samish*** timezone :p
<plars> didrocks: you mean next week I guess? since you'll be traveling
<sil2100> tedg: this is also one of the blockers, I think Timo already poked someone about that but it's still better if you would check that too ;)
<didrocks> plars: right
<plars> didrocks: of course :)
<sil2100> Damn, dialer-app merge takes FOREVER
<didrocks> plars: I don't think we'll do the meeting over HO, that's why ;)
<plars> didrocks: should make things easier for a bit :)
<didrocks> hehe, indeed ;)
<plars> didrocks: ah, right
<plars> didrocks: I won't be there, but just ping on irc if there's anything urgent to make me aware of from the in-person meetings
<didrocks> plars: will do!
<didrocks> thanks
 * cyphermox does to get lunch, bbl
<sil2100> didrocks: ok, oSoMoN prepared a fix for notes-app, one for gallery-app is coming right up
<didrocks> \o/
<ogra_> great
<ev> tedg: I don't quite understand what yo're asking
<ev> you're*
<ev> so for the desktop, when we switch off apport we still get crash reports to daisy.ubuntu.com
<ogra_> (wasnt the first one proper texan slang ?)
<ev> it just doesn't do the Launchpad bits
<ev> ha!
<ev> allow me to rephrase
<ev> howdy partner
<ogra_> lol
<ev> Ubuntu Touch is another story, I reckon
<ev> We didn't quite flip the switch for whoopsie being enabled by default on that, last I heard
<tedg> ev, I was worried more about the log files, like hud.log, which doesn't seem to be on recent traces.
<cyphermox> tedg: you looking at the indicator-network FTBFS?
<cyphermox> kgunn: news for the mir stuff?
<tedg> cyphermox, Yes, I passed it along to kenvandine
<cyphermox> oh
<cyphermox> heh.. I told sil I could look into it too
<cyphermox>  ;)
<kenvandine> cyphermox, feel free too :)
<cyphermox> kenvandine: you already on it?
<cyphermox> ah, alright :)
<kenvandine> just started
<kenvandine> either way :)
<cyphermox> probably just the vala version no?
<kenvandine> i am piloting... maybe this counts :)
<kenvandine> i think it's just missing a patch
<cyphermox> ok
<kenvandine> i got it
<cyphermox> ok
<kenvandine> speaking of piloting... i forgot to check in :)
<cyphermox> hehe
<kenvandine> tedg, i think it is actually indicator-network that needs fixing, i pushed a branch that fixes the build
<kenvandine> tedg, but the tests fail
<kenvandine> vala-0.22 does have the fixes from that patch in it, but the hashtable has different types
<dobey> fginther: hey. so i've been looking through the jlp autolander code a bit, and there's very little i see there that tarmac doesn't already do (and in some cases does it better). i think we can probably write a little bit of python to make plug-ins for the bits it doesn't do, maybe refactor a couple pieces in tarmac to work better for our needs, and switch over to using tarmac for all the autolander stuff
<cjohnston> +1
<cjohnston> 0000
<fginther> dobey, very cool! the hard part is prioritizing the time to work on it :-(. Do you have a suggestion on how to proceed
<fginther> dobey, I know vila would like to have some tests identified for our use cases first :)
<cjohnston> fginther: the dashboard uses tarmac for autolanding...
<dobey> fginther: not at the moment. i know i have to get a couple of the u1 projects moved over to daily releases, and the autolander isn't currently doing some of the stuff we do with tarmac, and which we need. at least, the contributor validation bit.
<dobey> fginther: i know tarmac is very well tested. we manage hundreds of branches with it in u1 :)
<fginther> dobey, I don't doubt that tarmac is reliable, the problem is that jenkins-launchpad-plugin is tightly integrated into our whole upstream merger CI process. It's going to take a bit of work to move and make sure our existing use cases are covered
<cjohnston> fginther: I think it may be something to look at with that 2.0 BP
<fginther> so we need to identify migration process
<fginther> cjohnston, agreed
<fginther> that would be a chance to build up smaller bits at a time
<dobey> fginther: is there any log/documentation about why tarmac + custom plug-ins wasn't used in the first place? i know didrocks proposed some major changes to tarmac in the past that we rejected because they were too specific to the needs of just unity at the time, but i remember those being a bit different than what i'm sing in the jlp source tree now
<fginther> dobey, I suspect that has something to do with it. A lot of process was borrow from work didrocks did. I don't have the history, but I'll poke around on a few people that are still around
<dobey> fginther: right; just looking for something to isolate the caes that tarmac doesn't handle already :)
<fginther> cjohnston, josepht, can you review https://code.launchpad.net/~fginther/cupstream2distro-config/mir-dev-trusty/+merge/192736? I provided a little bit of the 'why' this time.
<cjohnston> -1 I don't think we need to support trusty :-P
<tedg> kenvandine, Oh, good.
<kenvandine> tedg, can you take it from here?
<kenvandine> i got it building, but didn't look into the test failures
<tedg> kenvandine, I wasn't really planning on upgrading to trusty...
<tedg> Not before travelling.
<kenvandine> pbuilder is your friend :)
<kenvandine> tedg, want a log from the test failures?
<tedg> kenvandine, Sure, can I say no?  :-)
<kenvandine> http://paste.ubuntu.com/6302333/
<kenvandine> tedg, you could, but i wouldn't listen :)
<tedg> Hmm, those aren't vala related
<kenvandine> nope
<tedg> That's the non-vala code.
<kenvandine> well, couldn't they be failing because something else changed types?
<tedg> Eh, seems unlikely.
<tedg> Guessing race?
<tedg> It's not getting the notification signal
<tedg> kenvandine, Do you have it set up?
<kenvandine> same 5 tests fail, ran it 3 times now
<tedg> kenvandine, Can you try moving the creation of the spy to be before teh "GetSecrets" call?
<kenvandine> same thing
<tedg> Hmp
<tedg> Hmph
<tedg> That's probably a different bug though.
<tedg> At that point it'll probably have to be a pete-woods thing
<kenvandine> tedg, ok, i added a link to that log in the bug and assigned it to pete-woods
<tedg> kenvandine, Cool, thanks!
<kenvandine> tedg, np
<cyphermox> kgunn: mir stuff ready now? :)
<cyphermox> kgunn: I can keep pinging every two hours or so or if you want you can let me know if there's an ETA so I don't keep bugging you for no reason
<kgunn> cyphermox: no problem pinging
<kgunn> we're in #ubuntu-mir
<kgunn> mterry saw a ci failure...but i think its a flakey test, a couple of us have tested locally with no repro
<cyphermox> ok
<cyphermox> please let me know
<ev> tedg: whoopsie doesn't send custom apport files to daisy.ubuntu.com, if that's what you mean
<ev> fields*
<tedg> ev, So it's the apport tools that attach those to the crash file?
<ev> tedg: so if you have a HudLog field in your apport report, that wont get sent to daisy. That's added by an apport hook, which whoopsie ignores the data from: http://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/whoopsie.c#L93
<ev> the plan here was always to have daisy.ubuntu.com ask for additional data to be collected when it was actually needed
<ev> rather than everyone sending up massive log files
<ev> much like how we handle core files
<ev> this was called server-side hooks and I never quite got to it
<tedg> ev, Hmm, okay.  I guess I just want the log files :-)
<ev> I hear your pain, but whoopsie can't do that just yet :)
<tedg> ev, Would you be against adding the upstart logs to the white list in the mean time?
<ev> tedg: alas, it wouldn't be that simple. Cassandra isn't good at blob storage. If these log files are quite big, we're not in a good place yet for their storage
<tedg> ev, then they're very small
<tedg> :-)
<ev> there's a few things we could do here. Enabling compression in cassandra is one, but the move to 1.2 (where that feature is reliable) is a couple of months off by my estimate
<ev> ha!
<tedg> It seems to vary, I have a bunch that are 20-30K but the gnome-session one is 20M
<ev> our code is supposed to split large values across multiple columns, but I more generally worry about the performance impact on cassandra
<ev> and this is on the recoverable reports that we're getting lots and lots of?
<tedg> Yeah, we could also probably just gzip them.  Couldn't search, but I dont' think that's a needed feature.
<tedg> No, it was on crashes that it came up.
<tedg> We've apparently got 1500 cases of dbus disappearing before HUD.  Which should theoretically be impossible.
<tedg> I was curious if we're getting the sigterm before the crash and we're just not responding quick enough or if there was something else in the log.
<ev> tedg: talking to IS about it right now
<tedg> ev, Cool, thanks!
<ev> tedg: could you wait two weeks? They feel we could handle the load now, but we're in the middle of a repair on the 'newcassandra' ring
<ev> if you really need it now, then propose a merge to whoopsie to accept the field
<ev> repair> http://wiki.apache.org/cassandra/Operations#Repairing_missing_or_inconsistent_data
<tedg> ev, I don't think it's critical, we're removing the crash, so mostly hiding the error.  I was more surprised when I started digging.
<tedg> ev, More for "next time" type of thing.
 * ev nods
#ubuntu-ci-eng 2013-10-26
<ogra_> === FYI image #6 was built last night, but there seem to be issues with the system-image generation, stgraber is inspecting it ===
<vila> fginther, dobey: converging to tarmac sounds like.... an obvious long term goal. Can we discuss this on a mailing list to keep track of the discussion, tests, statsd metrics, bugs, fixes and  migration steps ? I think the effort/benefits is high enough to turn that into a medium (or who knows, short ?) term goal.
<vila> meh, the effort/benefits is *low* enough of course !
<vila> third time is the charm (sp ?): the benefits/efforts is high enough
<vila> go home vila, you're drunk !
#ubuntu-ci-eng 2014-10-20
<imgbot> === trainguards: IMAGE 293 building (started: 20141020 02:05) ===
<imgbot> === trainguards: RTM IMAGE 118 building (started: 20141020 03:05) ===
<imgbot> === trainguards: IMAGE 293 DONE (finished: 20141020 03:55) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/293.changes ===
<imgbot> === trainguards: RTM IMAGE 118 DONE (finished: 20141020 04:20) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/118.changes ===
<ricmm> bzoltan: so only 107+ ? 106 and 105 clean?
<ricmm> bzoltan: basically just want to know if 105 is broken, and if 107 is broken for you then try to roll back to qtdeclarative5-qtmir-plugin to 0.4.3+14.10.20141013-0ubuntu1
<bzoltan> ricmm:  yes, up until 106 it was OK and from 107 the UITK AP tests are broken
<ricmm> ok
<ricmm> in that case its the desktop file reader changes
<bzoltan> ricmm:  I have not yet tried to roll back
<bzoltan> ricmm: do you know who yo talk for the fix?
<ricmm> bzoltan: dandrader, gerry, kgunn
<ricmm> but first do confirm with a rollback of qtmir
<ricmm> just to make sure the pinpointed version is correct
<bzoltan> ricmm: OK, so it is 0.4.3
<bzoltan> ricmm:  is it a trival downgrade?
<ricmm> bzoltan: apt-get install qtdeclarative5-qtmir-plugin=0.4.3+14.10.20141013-0ubuntu1
<bzoltan> ricmm: cool, thank you ... doing it right now
<Saviq> davmor2, bug #1383277
<ubot5> bug 1383277 in unity8 (Ubuntu) "Power dialog sometimes shown on resume" [Undecided,New] https://launchpad.net/bugs/1383277
<popey> ooh, i have been seeing that too
<Mirv> bfiller: I published the rtm-002 now.
<bfiller> Mirv: thanks, would be great if we could respin a mako image with that
<Mirv> bfiller: I'll ping og_ra when it has migrated to release pocket
<Mirv> bfiller: I wonder if we should try to get it to utopic too? I'm not sure if those ubuntu-phone thread repliers are using rtm or utopic
<bfiller> Mirv: we should probably get it to ubuntu as well, I think the people were using rtm but we should to be safe
<popey> Saviq: davmor2 bug 1383279
<ubot5> bug 1383279 in unity8 (Ubuntu) "power button events queued, should probably be dropped" [Undecided,New] https://launchpad.net/bugs/1383279
<Saviq> popey, a
<Saviq> h
<Saviq> popey, reassigned to u-s-c
<Mirv> bfiller: ^ that 001 will have it, kicked build button.
<bfiller> Mirv: thanks
<bfiller> Mirv: could you create silos for line 56 and 57 when you have a chance?
<Mirv> ogra_: bill requested ^ above at least mako rtm image build, could you arrange it? the sim unlock problem seen on the mailing list would be now fixed.
<ogra_> i cant do a Mako only build
<ogra_> but i can indeed trigger an RTM image build
<Mirv> ogra_: yeah, that's what I thought. I guess that's important enough bug that it'd be nice to have a new image sooner.
<Mirv> hmm, I guess sil2100 is still stuck somewhere in Frankfurt or so :(
<ogra_> right, no issue with that
<ogra_> yup, i just saw his mail ... i think his new filght is in 2-3h
<ogra_> ... "I'm stuck here until the flight at 17:00 UTC+2" ...
<ogra_> even more
<Mirv> he didn't mail me, but I heard yesterday evening
<Mirv> that's terrible
 * ogra_ is on the right MLs :) 
<Mirv> ogra_: argh, not again... "aren't you on the xyz mailing list"
<ogra_> obviously LH screwed up his re-booking
<Mirv> I wonder if I should be on some more lists..
<ogra_> Mirv, thats the internal foundations list ... i was on that team and didnt unsubscribe when i changed :)
<Mirv> hehe, right
<Saviq> jdstrand, hey, could we get your feedback on bug #1383086 please (also, is there a project we could add a task for to request security feedback?)
<ubot5> bug 1383086 in unity8 (Ubuntu) "rebooting defeats the screen lock timeout" [Undecided,New] https://launchpad.net/bugs/1383086
<kenvandine> does anyone know why some autopkgtests aren't running?
<kenvandine> i have ubuntu-system-settings in proposed and excuses says there is a test running
<kenvandine> but it isn't... last run was a week ago
<pete-woods> trainguards: if I want to change my mind about the target of my landing (I want to do utopic, rather than rtm), what's the right way to do this?
<Mirv> pete-woods: you tell the line number and we'll change it :)
<Mirv> or I will, robru being at his home timezone and sil2100 stuck on Frankfurt airport...
<Mirv> pete-woods: so, I'd free up the rtm silo and assign utopic one instead
<kenvandine> Mirv, do you know why we have a bunch of packages stuck in proposed?
<kenvandine> Mirv, excuses says "test running"
<kenvandine> but they aren't running :)
<Mirv> kenvandine: in rtm or utopic?
<kenvandine> utopic
<Mirv> oh..
<kenvandine> we have packages stuck migrating since friday
<Mirv> the answer to your question is "no" (do I know). we should probably ping pitti or someone else.
<cjwatson> ask on #ubuntu-release about such things.
<pete-woods> Mirv: yes, that would be awesome :)
<popey> [D/query balloons
<popey> oops
<Saviq> Mirv, could we please have a silo for line 42 then, cleaned the utopic-targeted silo â
<brendand> marcustomlinson, hey
<marcustomlinson> brendand: hey
<brendand> marcustomlinson, can we sit for a few minutes and look at your silo?
<marcustomlinson> brendand: yeah ok
<brendand> marcustomlinson, dallas right?
<marcustomlinson> brendand: yep
<Saviq> Mirv, http://www.markshuttleworth.com/archives/1425
<AlbertA> trainguards: line 28 (rtm landing-001) is ready for QA but it's not showing up in the trello queue any ideas?
<Mirv> pete-woods: the line number, please? :)
<Mirv> Saviq: on time, great!!
<Mirv> cjwatson: is vivid open yet? ;)
<pete-woods> Mirv: line 62
<Mirv> pete-woods: oh right it didn't even have an assigned silo. ok then, 016.
<pete-woods> Mirv: sorry, that's a new line. the original one is 49
<Mirv> pete-woods: thanks, freed the silo
<Mirv> (the line 49)
<bzoltan> ogra_: sir, where are you?
<Mirv> Saviq: rtm-015
<ogra_> bzoltan, hmm, i thinnk its is called ballromm B
<cjwatson> Mirv: no :)
<popey> davmor2: bug 1383343
<ubot5> bug 1383343 in unity8 (Ubuntu) "Application icons take a long time to load on slow network" [Undecided,New] https://launchpad.net/bugs/1383343
<popey> dunno if we have one already filed for that, seems we should
<davmor2> popey: confirmed
<popey> davmor2: ta
<brendand> bzoltan, silo 13 isn't going to land this week you know
<robru> Mirv: are you at the sprint?
<robru> I'm around for any landing needs anybody might have
<rsalveti> davmor2: I got a silo that's ready for qa to sign it off, but it seems the spreadsheet is not showing that
<rsalveti> rtm silo 14
<rsalveti> Saviq: hey, we want to land https://code.launchpad.net/~mfrey/unity8/lock-fix/+merge/238918
<rsalveti> Saviq: don't think we're landing more stuff into utopic anymore, so how to proceed with that landing?
<Saviq> rsalveti, I'm releasing trunk into rtm
<Saviq> rsalveti, I've a silo already, will take that in
<rsalveti> Saviq: awesome
<robru> rsalveti: fixed spreadsheet status of row 48
<rsalveti> robru: thanks!
<robru> there it is ;-) you're welcome!
<brendand> AlbertA, which bug is silo 17 meant to fix?
<brendand> AlbertA, i don't see one mentioned in the changelog
<AlbertA> brendand: https://bugs.launchpad.net/media-hub/+bug/1378311
<ubot5> Ubuntu bug 1378311 in qtubuntu-media "EndOfStream event not received when QML Video component is destroyed" [Critical,New]
<brendand> AlbertA, that's not going to land this week though
<AlbertA> brendand: I believe it was indirectly associated with a bug that was tagged 10-23
<AlbertA> brendand: but let me check...
<Mirv> robru: yes!
<robru> Mirv: mmmm, how was the flight? /me is super jealous i didn't get to go
<Mirv> robru: yes, it's nice to have you around, since I'm walking around so much that my response time can vary.
<Mirv> robru: 1h late (+1.5h US customs queueing), but not too bad especially given how Lukasz is doing.
<Mirv> I was here at 10pm, which was ok.
<robru> yeah I saw lukasz' email, that's just brutal
<ogra_> something he cal tell his kids about :)
<ogra_> *can
<brendand> bzoltan, ping
<brendand> ogra_, what happened?
<ogra_> brendand,
<ogra_> oops
<ogra_> brendand, his original flight was overbooked and they screwed up the new booking
<ogra_> he should be in the air now (finally)
<robru> ogra_: landings are open, right? I can publish that? ^
<ogra_> robru, i donkt think landings are open, no
<robru> hm, rsalveti published himself ;-)
<ogra_> but thats the sim lock fix, that has been discussed before ...
<rsalveti> yeah
<ogra_> (talking about rtm-008 and rtm-006)
<ogra_> not sure about the mess rsalveti made with rtm-002
<ogra_> :P
<ogra_> :)
<rsalveti> it is ricmm's fault
<ogra_> as usual !!
<ogra_> robru, we actually planned to build an image once the 006 and 008 packages landed commpletely
<robru> ogra_: 6 and 8 aren't even started to publish yet, are they being reviewed still?
<ogra_> hmm, dunno, i thought Mirv had handled them this morning already
<ogra_> though i'm not sure if anything is allowed to land without QA signing off ... brendand ^^ ?
<robru> ogra_: unless they landed already and there's already two new landings in those silos? ;-)
<ogra_> magically with the same packages ? :)
<Mirv> ogra_: didn't sil write on Friday "This also means we will be unblocking landings through the CI Train now."?
<brendand> ogra_, no
<Mirv> ogra_: yes I published the mako sim unlock silo
<ogra_> Mirv, well, i think olli still only wanted landings for the critical bugfixes
<robru> yeah I read something about how landings were unblocked but since it's final freeze it's basically only critical fixes anyway
<ogra_> Mirv, and i think every landing needs QA signoff at this point in the release
<olli> Mirv, ogra_ is right
<olli> i.e. if on the list, good to land
<Mirv> ogra_: yes, only rtm14 critical of course
<olli> if not, then escalation to product team
<ogra_> olli, modulo QA signoff indeed :)
<olli> for exception
<ogra_> sine we want to keep brendand and davmor2 busy ;)
<Mirv> both today's fixes so far were for 2014-10-23 critical ones
<ogra_> *since
<Mirv> ogra_: right, so QA signoff simply to every landing..
<ogra_> yeah
<Mirv> ricmm: that means I'm changing your "turn off backlight" silo to also requiring signoff
<ogra_> Qa might decide the landing is trivial enough to just let it through, but we should get their comment at least
<Mirv> and ken's system-settings and pete-woods's silo
<ogra_> Mirv, a bit late :P
<Mirv> oh...
<ogra_> (given it is already migrating)
<ricmm> :)
<Mirv> right :)
<olli> Mirv, checking the tags only is not sufficient
<olli> as anyone can set the tags and sometimes they get set by accident
<Mirv> and Saviq's unity8 landing
<olli> the list from my mail is the authoritive source
<ogra_> well, only landing team should set them ... (though indeed everyone can set them, the landing team simply needs to check twice)
<Mirv> olli: right.. so the 10/16 email. check.
<olli> Mirv, 10/23 ;)
<Mirv> olli: yes, 10/23 email sent on 10/16 :)
<olli> hah
<olli> I can see now how this gets confusing
<Mirv> Saviq: so, I can immediately see your unity8 landing has bugs listed not on the List, so they should be escalated if wanted in
<rsalveti> but we're not just accepting MRs for the bugs from that email
<rsalveti> afaik we're back in the game and landing criticals
<rsalveti> even if not for this deadline
<davmor2> ogra_: I'm so going to slap you into the middle of next month
<Mirv> rsalveti: reading olli above it sounds like only bugs from the e-mail, or would need contacting the product team
<rsalveti> doesn't make sense, we had that for one week only, for the purpose of that milestone
<rsalveti> olli: isn't that the case?
<ogra_> rsalveti, as i understood we only land what has been approved by olli, pmcgowan or vicotr ... and then only after QA signed it off
<rsalveti> as we're fixing the other critical bugs, and we want to land them
<rsalveti> ogra_: I thought that was only for the previous milestone
<olli> rsalveti, only what's on the list for 10/23
<ogra_> (heh, vicotr ... victors evil russian brother)
<rsalveti> olli: why that?
<rsalveti> why did we decide to push the same requirements for 23?
<olli> rsalveti, ideally, we shouldn't fix bugs that aren't on the list, unless the list is wrong or there is a good opportunity
<rsalveti> olli: well, we have people enough to fix some other criticals
<rsalveti> same that happened last week
<ogra_> rsalveti, the bugs simply need to be sent to either of these three and be added to the list
<Mirv> yes, that's what Saviq said too, they have more people than bugs on the list
<rsalveti> we're just flushing them now
<rsalveti> ogra_: right, I don't understand why we need that
<Mirv> it does make sense to fix later critical bugs earlier
<rsalveti> we have the rtm14 bug list
<rsalveti> exactly
<olli> rsalveti, the intention is to reduce churn & regression risk
<rsalveti> if it's on the rtm14 critical list, let's land it
<ogra_> rsalveti, because they want to asses the risk for their product
<rsalveti> olli: but them we'll never fix every bug
<rsalveti> it's just a waste of time
<rsalveti> we should land every critical we have now
<rsalveti> as before
<rsalveti> anytime
<nik90> olli: is the rtm14 critical list public? Since I need to check if some alarm bugs are on that list which would affect user experience.
<rsalveti> we can't land on utopic, can't land criticals out of that list
 * ogra_ doesnt care either way, i just know what was requested
<rsalveti> will just take vacations
<ogra_> in any case everything going into RTM needs QA signoff ... regardless of the list
<Mirv> nik90: https://bugs.launchpad.net/bugs/+bugs?field.tag=rtm14
<olli> rsalveti, let's chat in the break
<rsalveti> olli: sure
<olli> rsalveti, vacation or improve test coverage or ...
<rsalveti> but I'm in favor of always landing critical fixes, sooner the better
<ogra_> olli, there are a good bunch of bugs that wont affect krillin but mako ... which we definitely want tto have fixed
<olli> rsalveti, I'd be with you if the overall number of bugs would go down
<nik90> Mirv: and If I need to request a bug to be on that list, do I ask olli and victorp?
<rsalveti> olli: but that's because we still have bugs
<rsalveti> ignoring that is just ignoring the reality that we have more bugs
<Mirv> nik90: so basically any bug that both has the tag "rtm14" and is Critical. then we have an these "touch-2014-10-23" milestones additionally, and this List we're talking about is about those subsets of the whole list
<rsalveti> the bug number will still increase for a while
<rsalveti> until it's stable
<rsalveti> we now have way more people using the product
<rsalveti> expect more bugs
<nik90> Mirv: ok
<Mirv> ogra_: what was the policy on adding 'rtm14' tag itself?
<ogra_> uh, i forgot
<bzoltan> brendand: pong
<Mirv> yeah, me too :P
<ogra_> heh
<ogra_> sil might know
<rsalveti> I just think we'll never ship if we keep this process as is
<rsalveti> but anyway, will complain in the corridor
<olli> :)
<Mirv> nik90: well, for now contact me or sil2100 when you've a bug that is critical (that part you can set yourself in your own projects) and that would also like to have the 'rtm14' tag.
<bzoltan> brendand:  Is it because of the UITK or is there a generic freeze?
<nik90> Mirv: ack
<olli> Mirv, rtm14 is for you to express that this is relevant for the product
<rsalveti> we're only landing ones that already has a deadline, just not for 23
<Mirv> nik90: ^ ok there you go, you can add rtm14 for your own project when you think it should be in the radar as a critical bug
<Mirv> olli: thanks.
<bzoltan> elopio:  the AP failures are same with the   qtdeclarative5-qtmir-plugin:armhf                    0.4.4+14.10.20141013-0ubuntu1
<rsalveti> postponing something that was originally for 30 just because we can't include it for 23 makes no sense
<rsalveti> made sense last week because of the reason of the deadline
<pmcgowan> rsalveti, you can, if its rtm and crit
<rsalveti> pmcgowan: olli said I can only land stuff on the 23 list
<pmcgowan> ok go yell at him then :)
<elopio> bzoltan: do you mean, the same +70 errors?
<Mirv> I think that was the plan :)
<rsalveti> pmcgowan: that's what I'm doing here
<rsalveti> :-)
<olli> pmcgowan, hey...
<brendand> bzoltan, the landings are restricted to ollis list
<bzoltan> elopio:  yes
<pmcgowan> heh olli's list
<bzoltan> elopio:  I have flashed the 118 image and downgraded that package.
<bzoltan> brendand:  Well, obviously  I am not happy for it. But can not do much I guess. I hope that the V queue will soon open and I can start landing there.
<ogra_> Mirv, so what about the SIM lock stuff ? i cant see it on the dashbaodr
<ogra_> wow, what a typo
<ogra_> Mirv, i would actually like to trigger an image build ( rsalveti wants one too) ... but i cant seem to find the SIM lock issue landing anywhere
<ogra_> ah, found it ... line 39 ... and it actually landed
 * ogra_ triggers a build 
<ogra_> imgbot, stunt
 * imgbot rolls on its back and purrs
<ogra_> good :)
<olli> lol
<cjwatson> bzoltan1: Friday, hopefully
<bzoltan1> cjwatson:  Friday is good, thanks
<cjwatson> not promising but we've managed to be up and running within a day of release before ...
<bzoltan1> sure, I totally understand
<imgbot> === trainguards: RTM IMAGE 119 building (started: 20141020 19:30) ===
<Mirv> ogra_: yes, thanks!
<Saviq> Mirv, there actually *is* a DO_NOT_ADD_RTM option ;)
<Mirv> Saviq: oh, right, it is there!
<ogra_> WHY_DO_ALL_OPTIONS_SCREAM ?
<Saviq> ogra_, BECAUSE_THEYRE_IMPORTANT
<ogra_> AH_THAT_MAKES_SENSE_THEN
<robru> bzoltan: row 70 is missing something
<Mirv> robru: oops :) I added it
<Mirv> we're rapidly trying to get the MR in there. sorry for setting it as "Ready"
<Mirv> the battle for working wifi
<robru> Mirv: heh, no worries.
<bzoltan> robru: Mirv: ready :)
<robru> bzoltan: Mirv utopic 14
<Mirv> bzoltan: building https://ci-train.ubuntu.com/job/ubuntu-landing-014-1-build/81/console
<Mirv> zbenjamin: conflicts
<imgbot> === trainguards: RTM IMAGE 119 DONE (finished: 20141020 20:40) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/119.changes ===
<ogra_> wow
<robru> pete-woods: ^ I'm afraid to publish anything as I've been out for 2 weeks. what's up with silo 16?
<ogra_> that was really fast !
<robru> hm
<davmor2> ogra_: that just means it didn't work and we now all have broken images right?
<ogra_> davmor2, well, blame rsalveti :P
<davmor2> rsalveti: it's all you fault!!!!
<kenvandine> davmor2, why can't it ever be your fault? :-p
<robru> wtfqueuebot
<davmor2> kenvandine: it is but most that I let stuff through that was broken by the devs :P
<Mirv> oh, not again, the 1min repeat queuebot thing
<ogra_> it *relly* wants to publish that :)
<ogra_> *really
<kenvandine> really
<robru> but but!
<robru> I remember the cause of that issue and the spreadsheet doesn't look like it has that problem right now!
<Mirv> it became fun when it was repeating three different landings every minute
<pete-woods> robru: I think it's ready (I mean I've tested it). but I don't know the rules about publishing..
<robru> pete-woods: is it a critical bugfix? utopic is in final freeze ;-)
<pete-woods> robru: it is, yes
<robru> pete-woods: ok
<ricmm> :)
<ricmm> s'il vous plait
<robru> ricmm: rtm 2
<ricmm> robru: thanks
<robru> ricmm: you're welcome
<davmor2> ogra_, rsalveti: why is this image never seeming to finish flashing?
<davmor2> ogra_, rsalveti: nevermind it just finished but my god that took a while :)
<rsalveti> davmor2: hahah
<rsalveti> I might be able to flash it tomorrow, will take a while to download it
<rsalveti> really slow
<cwayne> davmor2, got time for a custom tarball test tomorrow?  only critical bug fixes I swear :)
<robru> somebody who knows stuff let me know if it's actually ok to publish silo rtm 14
<davmor2> cwayne: Where's my fitbit damn you ?  possibly depends when
<robru> or not
<Mirv> robru: yes, I just published it. so it is on the 10/23 List (on the mailing list), ie ok.
<robru> ah ok, thanks Mirv
<Mirv> "10/23 iteration planning"
<cwayne> davmor2, its in my room
<cwayne> i dont have a charger for it though :/ but i do have the dongle to sync it
<balloons> ogra_, https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-meta/+bug/1383479
<ubot5> Ubuntu bug 1383479 in ubuntu-touch-meta (Ubuntu) "Remove autopilot from touch images" [Undecided,New]
<ogra_> olli, pmcgowan ^^^ we need to talk about this one
<olli> ogra_, ack, not sure I fully grasp the implications
<pmcgowan> ogra_, yeah, this week or next?
<pmcgowan> balloons, ^^?
<pmcgowan> ogra_, balloons although if it has a small footprint I suppose there is not so much urgency?
<ogra_> pmcgowan, it has a giant dependency chain
<ogra_> (it will remove quite a bit of python packages)
<pmcgowan> that sounds good
<pmcgowan> so we should do next two weeks
<ogra_> pmcgowan, but there is some risk in it, if people dont use out tools for testing but directly call autopilot for example
<ogra_> so we should do it early to asess possible fallout
<pmcgowan> ogra_, who might do that?
<pmcgowan> ok
<ogra_> pmcgowan, well, i know that the unity8 team calls AP directly during developemnt
<ogra_> (eaiser than always calling pahblet-test-run if you develop )
<pmcgowan> ogra_, so maybe an email to the list to prep folks
<balloons> pmcgowan, thanks for commenting on it. Sorry, I was offline and missed the discussion
<balloons> ogra_, pmcgowan, the potential issues also arise from people depending on autopilot or a dependency without declaring it. It's unlikely but possible
#ubuntu-ci-eng 2014-10-21
<imgbot> === trainguards: IMAGE 294 building (started: 20141021 02:05) ===
<imgbot> === trainguards: RTM IMAGE 120 building (started: 20141021 03:05) ===
<imgbot> === trainguards: IMAGE 294 DONE (finished: 20141021 03:45) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/294.changes ===
<imgbot> === trainguards: RTM IMAGE 120 DONE (finished: 20141021 04:15) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/120.changes ===
<sil2100> o/
<ogra_> sil2100, rtm 002 says it is publixhed on the dashboard
<ogra_> seems the bot disagrees
<sil2100> ogra_: it says it couldn't publish
<ogra_> sil2100, why did the bot not say that
<ricmm> lol
<sil2100> ogra_: that the merges are unapproved :)
<ogra_> bah
<ogra_> :P
<sil2100> It's SLOW!
 * sil2100 slaps queuebot 
<ogra_> snailbot !!!!
<sil2100> Anyway, ricmm you usually land things ubuntu-rtm specific things, right?
<rsalveti> silo 2 finally landed (rtm)
<sil2100> ricmm: did you approve the merge?
<sil2100> Ah, thank!
<sil2100> *thanks
 * sil2100 not used to using this keyboard
<ricmm> sil2100: bought a new laptop? what'd u get
<sil2100> ricmm: no no, the old one still, but I use an external keyboard all the time at home
<ricmm> alright
<sil2100> ricmm: so, I prepared a sync silo for this to utopic so that we don't lose track of what needs to land in utopic/vivid
<ricmm> sil2100: great, not sure how that works on the distro transitions, so I'll leave it up to you ;)
<sil2100> ricmm: we're still working on that, slangasek is also on it ;)
<pete-woods> would appreciate someone filling in the right sync: bit for me :)
<sil2100> pete-woods: sure :)
<pete-woods> thanks!
<pete-woods> sil2100: thanks!
<sil2100> ogra_: yay, saving space with autopilot \o/ Not much though I guess?
<sil2100> davmor2: do you have the list of issues that you guys found regarding the welcome wizard and edges intro?
<sil2100> e.g. the first impression buglist we talked about yesterday?
<ogra_> sil2100, i think it will be a lot thanks to also dropping a lot of python deps ...
<sil2100> ogra_: let's see when that happens then - not expecting much, but if it's more then I prefer being positively surprised
<ogra_> but i need to make sure the apport stuff still works, so it might get delayed a little ... i need to test that first
<ogra_> err
<ogra_> s/apport/apparmor/
<sil2100> hm?
<sil2100> Ah, didn't even notice that
<sil2100> ;)
<ogra_> (to many things starting with app nowadays :P )
<kenvandine> and apt
<ogra_> heh
<ogra_> appt
<kenvandine> and ap for autopilot... :-D
<slangasek> appologies for the namespace
<sil2100> APPologies ;p
<kenvandine> haha
<ogra_> lol
<sil2100> pete-woods: ok, looking into the silo, just need to double-check if QA won't like to sign it off
<sil2100> (as you know, we're playing safeish recently)
<pete-woods> sil2100: no problem!
<sil2100> brendand, davmor2, elopio: hey, anyone of you guys looking on IRC?
<pete-woods> sil2100: we did already have it checked by a QA guy (can't remember the name), but that was on utopic, I think
<sil2100> pete-woods: since basically it *should* be taken as an isolated bugfix, but bigger changes for components that are being used by multiple components I prefer to double-confirm
<pete-woods> that's cool. I really don't want to break such a visible thing!
<brendand> pete-woods, i already talked to AlbertA yesterday and i didn't get a clarification on the justification for landing it
<AlbertA> kgunn: ^
<pete-woods> brendand: it makes unity8 freeze for up to 60 seconds sometimes. that's pretty bad!
<bdmurray> I'd like to upoad apport to ubuntu-rtm/14.00 so that bug 1381658 will be fixed in it.
<ubot5> bug 1381658 in apport (Ubuntu RTM) "Top Crasher: /usr/share/apport/recoverable_problem:AttributeError:add_proc_info:main:add_proc_info:/usr/share/apport/recoverable_problem@75:main" [High,Confirmed] https://launchpad.net/bugs/1381658
<brendand> pete-woods, not doubting that. can you talk to olli and get it tagged? https://bugs.launchpad.net/media-hub/+bug/1378311
<ubot5> Ubuntu bug 1378311 in qtubuntu-media "EndOfStream event not received when QML Video component is destroyed" [Critical,New]
<brendand> pete-woods, ask him to ping me when it's done
<kgunn> brendand: am i good enough to tag ?
<kgunn> ;0
<kgunn> oops :)
<brendand> kgunn, i still need to hear from olli
<pete-woods> brendand: er. that seems like a totally different bug? (have I put the wrong bug # in?)
<brendand> pete-woods, ?? what silo are we talking about?
<brendand> pete-woods, i only have 17 here with your name
<brendand> pete-woods, or is it 7?
<pete-woods> brendand: silo 14 rtm
<brendand> pete-woods, okay - i'm really sorry. that isn't in our queue yet
<pete-woods> brendand: no worries!
<pete-woods> I hadn't marked is as requiring QA. but that was being questioned, I think
<pete-woods> I'm obviously happy to have it tested by you guys. but it's been tested by a few other people in addition to me already
<brendand> pete-woods, please do
 * pete-woods marking
<pete-woods> done
<bdmurray> sil2100: what shall I do about apport and bug 1381658?
<ubot5> bug 1381658 in apport (Ubuntu RTM) "Top Crasher: /usr/share/apport/recoverable_problem:AttributeError:add_proc_info:main:add_proc_info:/usr/share/apport/recoverable_problem@75:main" [High,Confirmed] https://launchpad.net/bugs/1381658
<sil2100> bdmurray: hey! So, I still need to get a confirmation from the product team, since this bug by itself is not noted as critical and didn't end up on olli_'s list
<bdmurray> sil2100: okay, thanks for the update
<ogra_> sil2100, so dbus-property-service and ubuntu-touch-meta were just uploaded into utopic to remove AP ... once rmadison is happy i'll build a utopic image to see how well it still copes
<sil2100> ogra_: hah, utopic playground \o/
<ogra_> yeah :)
<ogra_> plars, ^^^FYI
<ogra_> i think we should wait for seeing at least a few tests running on that image (once it exists) to see that smoke tests still work as expected)
<plars> ogra_: what's that for?
<ogra_> plars, i dropped autopilot (all traces of it) from the rootfs
<ogra_> like we discussed yesterday
<bdmurray> asac / sil2100: I've updated the bug.
<sil2100> bdmurray: thanks!
<plars> ogra_: awesome
<ogra_> sil2100, do you do a meeting ? (if so, where)
<sil2100> ogra_: no, I don't have any
<ogra_> i mean the one that just made my phone play harps ;)
<ogra_> (landing)
<robru> sil2100: ogra_ : landing meetings are off this week, right?
<ogra_> robru, sil2100 wanted to keep the "evening" one for briefing you
<robru> oh, well is it happening now? should I join a hangout?
<kenvandine> brendand, note when testing ubuntu-rtm/landing-019, setting it to "Not at all" maybe trigger indicator-location to crash, which is unrelated to this landing, bug 1382449
<ubot5> bug 1382449 in Indicator Location "indicator location is hidden when toggling location detection with gps disabled" [Undecided,New] https://launchpad.net/bugs/1382449
<sil2100> robru, ogra_: so we're schedule a new meeting for this week
<sil2100> robru, ogra_: this will probably be later on in our TZ here
<robru> sil2100: it better not be any earlier than the other one ;-)
<sil2100> robru: ;)
<sil2100> robru: anyway, we'll inform you and everyone through the calendar
<sil2100> For now, lunch time
<sil2100> robru: when do you usually go off for lunch?
<imgbot> === trainguards: IMAGE 295 building (started: 20141021 17:45) ===
<ogra_> ^^^build without autopilot ^^
<sil2100> \o/
 * sil2100 can't wait to see the size difference
<robru> sil2100: Oh, I don't have a usual lunch time, just whenever it's convenient
<sil2100> robru: ok, since I'm trying to find the perfect timing
<robru> Was thinking about it now
<sil2100> I was thinking of doing it at 17:30 of our time, just need to nicely convert it to your TZ
<robru> sil2100: it's 11am now, will take lunch a bit early today I think
<sil2100> We'll start off tomorrow I guess
<robru> sil2100: tomorrow's good. Today that conflicts at that time
<sil2100> robru: what was your TZ again? ;)
<robru> Brb
<robru> sil2100: pacific /Vancouver
<sil2100> kgunn: ping
<kgunn> sil2100: yo
<sil2100> kgunn: so, ricmm was looking for you it seems
<kgunn> ricmm: what's up?
<sil2100> kgunn: he mentioned that only the DesktopFileReader is the problem here I think
<sil2100> But I guess he wanted to meet up with you personally to discuss
<kgunn> sil2100: prolly best if ricmm speaks with dandrander about it, i was going off his updates
<ogra_> kgunn, hmm, so you pinged me about rtm 017 before .... that doesnt look like it is related to the bug you pointed at
<ogra_> (sim unlock dialog iirc)
<ricmm> kgunn: just trying to understand the bug, daniel is saying on thing in the bug but the email thread says another
<ricmm> pretty sure its related solely to the desktop file changes, but would like to confirm
<tedg> trainguards, Can I get a silo for line 80 please?
<Mirv> sure ted
<tedg> Thanks Mirv!
<kgunn> ricmm: you talking about my email thread wrt unapproved MP ? ...those are 2 seperate issues...1 ) potential issue is it's related the bug...2) email thread was more about the mystery of how it got merged
<kgunn> ricmm: i'm perfectly happy if it's unrelated to the bug...
<kgunn> but even then, there'd be a mystery of how it landed...but seems that's somewhat understood
<ricmm> I'm not sure how it landed, at the time the process seemed ok
<ricmm> but it landed during the 0.8.0 retries mess
<ricmm> so, theres a chance that some things got out of sync
<ricmm> and some got dropped
<ricmm> kgunn: I mean it went through testing, aprpoving, and the whole story, afaik
<kgunn> ricmm: right, actually unrelated to mir0.8 mess...
<kgunn> theory is it's related to branching qtmir/rtm
<ricmm> right
<sil2100> tedg, Mirv: ok confirmed as good to go
<sil2100> Mirv: you assigning that? :)
<kgunn> ricmm: right...seems related to having qtmir(trunk) in there...but at the same time we created qtmir/rtm
<ricmm> kgunn: however that landing did happen during the 0.8.0 stuff, same went for the qtmir/rtm branch
<ricmm> kgunn: I do remember that Mirv had to manually sync some branches
<kgunn> ricmm: now at the " bug" itself...i'm saying, if it is related, we should not revert your change, but rather uitk AP should be updated
<Mirv> sil2100: yes, as soon as googledocs co-operates with me
<Mirv> (now it did) tedg: rtm-025
<ricmm> kgunn: sure, just want to understand, talking with daniel about it but not sure if he has clear info
<ricmm> so maybe will just go repro
<balloons> davmor2, ping
<davmor2> balloons: slap
<balloons> davmor2, has your wifi ever refused to connect after changing the keyboard language?
<davmor2> balloons: what did you change it to and would it of effected any of the characters in the password?
<davmor2> balloons: other than that no but I tend to mostly change to French
<balloons> davmor2, spanish and it was already set. going to try and reproduce.. thanks ;-)
<sil2100> kgunn, ricmm: so in the end it seems only the desktopFileReader was at fault here
<sil2100> So only the confusion of the landing remains
<ogra_> sil2100, FYI http://people.canonical.com/~ogra/touch-image-stats/20141021.1.changes
<ogra_> sadly the size changes arent visible much because the langpacks grew so much
<sil2100> More then I expected
<robru> ogra_: what is the actual size change?
<ogra_> robru, it grew due to the langpack updates
<sil2100> ;p
<ogra_> robru, i dont think it will be visible in utopic ... but rtm will show it
<robru> stupid langpacks! everybody should just learn english!
<ogra_> lol
<ogra_> tell the spaniards
<ogra_> plars, can you tell ricmm how long UITK tests usually take ?
<ogra_> (over the thumb)
<sil2100> robru: I just made a direct commit to cu2d, HORRIBLE ME!
<robru> sil2100: you're fired
<sil2100> robru: :<
<sil2100> robru: anyway, a no-brainer that I didn't want to push through CI without any reason - just added vivid to the series list
<robru> sil2100: yeah, so the thing is, we hard-code series names in too many places. like eg in the sync code it hardcodes utopic<->14.09. We need to stop doing that.
<ogra_> sil2100, we'll make davmor2 blame you all evening if it breaks
<sil2100> robru: well, I didn't change that for now and didn't want to, as we do not switch to it by default for now
<sil2100> I just added it to the list, nothing more
<sil2100> There are too many questions unanswered to switch to vivid... plus, we can't release anything to vivid right now anyway
<robru> sil2100: yeah I know, that's fine in that spot, but generally we should stop hard-coding series names
<sil2100> It's still closed
<plars> ogra_: ricmm: maybe 30 minutes when it works? it's had problems lately though
<ogra_> thats what he is looking at ;)
<sil2100> robru: true, but ubuntu-rtm is a big hack in overall, and it was supposed to only work with utopic - if the plans change, then well ;)
<robru> sil2100: when vivid really opens, then we should rip out all rtm sync code ;-)
<sil2100> We'll change the approach to a more rolling one, where it would just somehow hook up to the currently active series
<sil2100> robru: hah, we could do that for sure - assuming that ubuntu-rtm would stay then as only something that we cherry-pick stable fixes to of course
<sil2100> The direction of ubuntu-rtm now is also under questioning I think
<ricmm> elopio: hi, trying to understand something about AP tests
<ricmm> elopio: we launch with UAL, but tear down with a simple SIGKILL ?
 * brendand used ubuntu-app-stop
<ricmm> brendand: you? or autopilot
<ricmm> I see things like 19:10:30.108 INFO _launcher:567 - Killing process 10917
<ricmm> ahh yes
<ricmm> os.killpg(pid, sig)
<ricmm> useless
<brendand> ricmm, talk to veebers
<veebers> ricmm: applications using UAL should be using UpstartApplicationLauncher or ClickApplicationLauncher which use UbuntuAppLaunch.stop_application(app_id)
<veebers> ricmm: where are you seeing these logs?
<ricmm> UITK tests that seem to be using application/_launch.py
<veebers> ricmm: how are the tests launching the application? Where are the tests that you're looking at>
<ricmm> ubuntu-ui-toolkit-autopilot
<ricmm> I guess they are actually launching them manually?
<ricmm> instead of UAL
<veebers> ricmm: perhaps? I'm not sure how they are launched, taking a quick look noe
<veebers> now*
<ricmm> yea looks like it
<veebers> ricmm: which test id are you looking at (to make it easy to check)
<ricmm> sounds broken to me considering all the implications of the very coupled dance of QtMir / UAL
<ricmm> uh lemme check
<ricmm> ubuntuuitoolkit.tests.test_fixture_setup.LaunchFakeApplicationTestCase.test_launch_fake_application_with_qmlscene
<ricmm> all of them seem to do the same, so thats just a random one
<veebers> ricmm: thanks, taking a look now to see what it's doing
<veebers> ack
<sil2100> robru: will you have time tomorrow at 5:00 pm of our time?
<veebers> ricmm: yeah looks like it using launch_test_application not launch_click_package or launch_upstart_application
<ricmm> ChickenCutlass: http://www.wunderground.com/wundermap/?lat=38.90856934&lon=-77.01797485&zoom=8&pin=Washington%2c%20DC&rad=1&wxsn=0&svr=0&cams=0&sat=0&riv=0&mm=0&hur=0
<ricmm> veebers: ok, yea some seem to be launching with upstart, others manually
<ricmm> I'll take it up with the team to better understand / fix
<veebers> ricmm: aye, that's what it looks like to me
<ricmm> veebers: thanks for the help
<veebers> ricmm: nw, let me know if there is anything else I can help with
<robru> sil2100: yeah 5PM should work
<sil2100> Crap, there's a different meeting on that time
<sergiusens> plars: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=goget-ubuntu-touch
<ToyKeeper> kenvandine: About silo rtm-019 (ubuntu-system-settings, accepting HERE after setup), it doesn't work until after a reboot.
<sergiusens> plars: just dpkg-deb -x the ubuntu-device-flash.*.deb
<ToyKeeper> kenvandine: So, it's still an improvement...  but shouldn't this take effect immediately?
<sil2100> robru: what about 30 minutes prior to that?
<ogra_> ricmm, http://dashboard.ubuntu-ci:8080/smokeng/utopic/touch_stable/krillin/95:20141010:20141008-8ea26ef/549/
<robru> sil2100: that should be fine too. can you use the google calendar to confirm the schedule? it'll show what I'm doing at that time. I have a thing at 1PM my time but I think it's before that anyway
<sil2100> robru: sure, we just need msm to do that though, as she needs to assign a room for us
<robru> ah
<imgbot> === trainguards: IMAGE 295 DONE (finished: 20141021 19:30) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/295.changes ===
<sil2100> robru: once that's done you'll be added to the invite
<robru> sil2100: alright
<ricmm> plars: are you around?
<ricmm> plars: got an idea you can help me with :)
<plars> ricmm: kinda, talking to pitti right now, what are you looking for?
<ricmm> plars: could you fire off a run of smoke tests for krillin *skipping* the hanging reminders test?
<ricmm> and applying this before hand to the ubuntu-ui-toolkit autopilot https://launchpadlibrarian.net/187841873/fix_ubuntuuitoolkit_desktop_file.diff
<ricmm> I'm really only interested in the autopilot run, to be fair
<kenvandine> ToyKeeper, shouldn't matter, i didn't need a reboot
<kenvandine> ToyKeeper, unless maybe your indicator had crashed before starting settings?
<kenvandine> or location service
<plars> ricmm: unlikely today, and it would have to be done locally
<plars> ricmm: it's just the ubuntuuitoolkit tests you want though?
<ricmm> plars: nevermind
<ricmm> just wanted some parallel check, I can deal with it
<plars> ricmm: sorry, just in the middle of some other stuff right now
<ToyKeeper> kenvandine: Nope, don't think so...  I tried twice (flash+silo+test) and it failed the same way both time.  GPS doesn't work inside this building so HERE is the only method to get location, and I couldn't get location to work until after a reboot.
<kenvandine> well, that is different :)
<kenvandine> for this silo you just need to test that the app shows up in the list there
<ToyKeeper> kenvandine: I approved it regardless, but it's something to watch out for later.  Accepting HERE post-wizard doesn't take effect until after restarting something.
<kenvandine> and that the list item showing HERE as an option should be there on krillin/rtm
<kenvandine> ToyKeeper, thanks!
<ToyKeeper> s/time/times/  oops
<ToyKeeper> kenvandine: I didn't try restarting services individually to identify which one needed to be kicked,  Might be good to add a SIGUSR or SIGHUP something to the location daemon(s) to make it reload config.
<ogra_> sil2100, looks like 295 isnt coming out worse than former images with AP dropped from the image (bit early to properly judge, but i see the app tests run (and fail the same ways they did in former images) ...
<sil2100> My biggest concern was UITK, which will be probably hard to judge
<ogra_> hmm, in fact i see even reminders not go into the usual hang/loop
<sil2100> I think it was finally fixed in reminders
<sil2100> I mean, failing properly
<ogra_> sil2100, hmm http://ci.ubuntu.com/smokeng/utopic/touch/mako/293:20141020:20141017.2/11059/ubuntuuitoolkit/
<ogra_> thats from two images ago
<sil2100> ogra_: yeah, so a new reminders landed in 112 so it shouldn't loop infinitely anymore
<ogra_> i doubt we'll actually get any results that are usable on utopic for UITK
<sil2100> Ugh
<sil2100> Yeah
<sil2100> Well, on ubuntu-rtm it will be hard to judge as well, as currently those are failing as well
<sil2100> Because of the change of the DesktopFileReader
<Mirv> ogra_: wow, locally we just tested UITK and they were "fine" (the qtmir caused ~70 failures)
<ogra_> sil2100, well, ricmm sits next to me and has them fully passing all the time :)
<ogra_> (with his tiny fix)
<ogra_> someone should land that asap
<Mirv> that was using qt 5.3.2, which seems quite fine so far
<sil2100> Yeah ;) But that's a fix to UITK, right?
<sil2100> The desktop file change?
<ogra_> sil2100, yup
<ogra_> sil2100, actually the uitk-autopilot package
<sil2100> ogra_: I only hope it would be possible to release just that, as we have an UITK landing in the queue all the time
<sil2100> Just it cannot be let through because it has many non-critical-rtm14 fixes
<ogra_> sigh
<ogra_> we really need to revise the policy ...
<sil2100> And we'll probably have to wait for Thu to get this on the list...
<ogra_> releasing with known bugs just because they are not on some artifically made up spreadsheet is a bad idea
<sil2100> Since according to the new rules, we only land what is on the list, and if it's not on the list then we wait for it to be evaluated on Thu's
<ogra_> yeah
<sil2100> This is the revised policy, so I wouldn't expect anything newer ;)
<ogra_> right
<popey> davmor2: seen this.. http://imgur.com/qJt9YGP ?
<popey> network indicator seems to sometimes go a bit funny
<ToyKeeper> olli: I'm trying to figure out if silos rtm-005 and rtm-009 can land or if they need to be delayed.  One has 4 bug fixes (1 on the blessed list, 3 not but marked rtm14 high with a milestone of last week, this week, or ota-1)...  the other has two bug fixes not on the list but marked high with this week's milestone.
<ToyKeeper> olli: The trello cards have the bug links and details.  https://trello.com/c/lLrGPdMw/     https://trello.com/c/dgnqv5Sa/
<ToyKeeper> olli: Any hints on whether to test/approve or delay them?
<olli> ToyKeeper, I can tell you tomorrow
<ToyKeeper> Okay, thanks.
<davmor2> popey: yes network indicator crashes I refer you to cyphermox and awe :)
<popey> k
<cyphermox> moo?
<Mirv> moo powers
<ogra_> plars, hmm, so looking at the test results it seems that all click tests are fine on utopic 295, but non-click apps dont look so happy
<sil2100> ogra_: on which step are those failing and complaining?
<sil2100> During the autopilot tests?
<sil2100> Maybe we're missing some deps in the -autopilot packages
<ogra_> sil2100, yeah, i think so
<ogra_> sil2100, i'm already in istanbul for the meeting, will talk to paul
<sil2100> Which meeting?
<dobey> what part of the machinery is responsible for the debian/changelog commit message entries with bug numbers? cupstream2distro?
<ogra_> sil2100, the one you set up ?
<ogra_> sil2100, nobody showed up so we are going again ... i'll find you
<sil2100> ogra_: I didn't set it up
<sil2100> ogra_: my calendar is empty
<ogra_> sil2100, check mail
<sil2100> ogra_: it's Michelle setting up meetings, so for now we only reserved one for tomorrow
<sil2100> Wait
<sil2100> Then there's a mistake
<ogra_> yeah, obviously
<ogra_> sil2100, she just moved it
<sil2100> ogra_: wait, but I have nothing in my calendar
<sil2100> Yeah...
 * ogra_ is off, drooping stuff 
<sil2100> o/
#ubuntu-ci-eng 2014-10-22
<imgbot> === trainguards: IMAGE 296 building (started: 20141022 02:05) ===
<imgbot> === trainguards: RTM IMAGE 121 building (started: 20141022 03:05) ===
<imgbot> === trainguards: IMAGE 296 DONE (finished: 20141022 03:30) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/296.changes ===
<imgbot> === trainguards: RTM IMAGE 121 DONE (finished: 20141022 04:25) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/121.changes ===
<tedg> trainguards, could I please get a silo for line 82?
<Mirv> tedg: just a second
<tedg> Mirv, Cool, thanks!
<Mirv> tedg: rtm-002
<tedg> Mirv, Great, thanks!
<davmor2> cwayne, ogra_, sil2100: custom tarball is good to go :)
<ogra_> whee !
<cwayne> davmor2, thanks for testing :)
<cwayne> sil2100, let me know when I'm allowed to push the magic button :)
<davmor2> cwayne: sorry I didn't finish it last night but with everything going on I ran out of day :)
<cwayne> davmor2, no worries at all man
<sil2100> cwayne: hey!
<sil2100> Sorry, I'm in meetings now ;)
<sil2100> ogra_: any reasons not to push the custom tarball right now?
 * sil2100 is disconnected from the world
<ogra_> sil2100, i think it should be fine ... we are still trying to solve the issues the dropping of AP caused
<ogra_> (seems there si some dependency mess we might need to have solved via plars )
<mterry> elopio, did I see you say that the latest unlock-device race fixes didn't fix all of the issues we see in CI?
<plars> ogra_: sorry I missed the conversation, I was pinging him on irc when you were talking to him, but I'm in another session right now
<mterry> plars, or was it you?  ^
<plars> ogra_: what's the issue? was he able to spot it?
<elopio> mterry: wasn't me. I think plars.
<plars> mterry: we have a lot of other issues too right now, let's fix those then we'll see
<ogra_> plars, dropping AP-touch means a bunch of deps are now missing ...
<mterry> plars, ok
<plars> mterry: did that land everywhere? I thought it couldn't land yet
<ogra_> sil2100, line 84 and 85 should help us
<mterry> plars, oh goodness you're right, it hasn't landed yet
<plars> ogra_: why are those not installed by phablet-test-run though? I thought it was installing ap-touch?
<sil2100> cwayne: ok, please push the button for now
<mterry> plars, sorry man, early morning for me
<sil2100> ogra_: looking
<veebers> olli: ping, I have 2 lines in the spreadsheet that I need to clarify perhaps. It is a packaging fix for removing autopilot from the image (sitting here with ogra_ attempting to sort it out)
<ogra_> plars, and i thought you said installuing unity8-ap would pull in all necessary bits ;)
<mterry> plars, if you want it to land sooner, advocate for higher priority on bug 1370644  :)
<ubot5> bug 1370644 in unity8 (Ubuntu) "unity8-autopilot device unlock seems racy" [Undecided,In progress] https://launchpad.net/bugs/1370644
<plars> ogra_: no, wasn't me
<ogra_> plars, well, someone claimed it in the meeting
<plars> ogra_: someone claimed that phablet-test-run installs everything, but I don't see where
<ogra_> plars, could we try to re-run some broken tests after pulling ap from one of the silos into the infra ?
<ogra_> phablet-test-run doesnt install anything on its own :)
<ogra_> unless you hand it to the -p option
<plars> ogra_: I'm confused how anything is working at all then :)
<ogra_> plars, well it worked because we shipped half the wolrd of available tests and tools before :)
<plars> ogra_: no, I mean how any of the tests work now
<ogra_> now we dont anymore
<plars> ogra_: but some don't
<ogra_> plars, seems all click tests work fine
<ogra_> and everything else doesnt
<plars> so like on webbrowser, we get like 15 tests instead of 50, but some actually pass?
<ogra_> (on a first glance)
<ogra_> yeah
<cwayne> sil2100, pushed :)
<ogra_> plars, http://people.canonical.com/~ogra/touch-image-stats/20141021.1.changes ... qttestability-autopilot ... i guess thats the issue
<ogra_> ap-touch used to pull some extra deps in
<plars> ogra_: veebers: so is there a single package to install that would fix it? autopilot-touch?
<plars> python3-autopilot?
<veebers> plars: yeah autopilot-touch should do it
<ogra_> plars, veebers just requested a silo ... i had to move one file from ap-touch into dbus-property-service
<sil2100> ogra_: ok, I'll assign silos for those
<ogra_> plars, so ap-touch is uninstallable til that silo lands (which drops the file from ap-touch)
<veebers> plars: it is already pulling in python3-autopilot, autopilot-touch pulls in qttestability-autopilot
<plars> ogra_: ok, what's the ppa? I can test something
<ogra_> plars, if sil2100 stops slacking
<ogra_> ;)
<pete-woods> trainguards: hi guys. is there anything I can do to get a silo assigned for line 50 of the CI sheet? (fixes a bug that makes location-dependent scopes blank at startup)
<sil2100> ogra_: I'm not slacking! I'm being active on a meeting!
<ogra_> plars, no ppa yet ... we're waiting ...
<plars> heh, ok
<ogra_> sil2100, yeah yeah ... i claim that too all the time :P
<sil2100> ogra_: but yeah, I wonder - we'll do it for RTM
<ogra_> (we should have pinged robru though ... and let you do your meeting ;) )
<sil2100> ogra_: I think robru is still sleeping ;)
<ogra_> sil2100, first we need it for utopic wheer we can then test ... by plars installing the silo package
<ogra_> sil2100, how dare he !!!
<sil2100> ogra_: hm, since basically we cannot release it for utopic right now, but ok - let me do the utopic silo first, sync to the rtm one and then only release RTM, waiting for utopic (or vivid) later on
<ogra_> sil2100, right, thats why we need plars, he can pull from the PPA and manually trigger a test
<ogra_> sil2100, once we see that brings things back to normal we then can do all the same steps for rtm (and actually land there properly) ... i'll take care to have olli approve it and have a bug etc etc
<ogra_> for utopic it will simply stay stuck in utopic-proposed (archive wise)
<sil2100> ogra_: silos assigned
<sil2100> ogra_, veebers: the RTM silo is a sync silo, so build the utopic one first
<veebers> sil2100: cool thanks, I'll click build now
<ogra_> awesome
<veebers> ogra_: 2 things to confirm :-) , apparmor/click.rules willstill be installed (via dbus-servie-properties right?) secondly I didn't actually remove the file in that MP so I'm doing that now (then will build)
<Mirv> pete-woods: sure, assigning, it's even on the List so no problem. we just need pinging atm.
<pete-woods> Mirv: okay, just pinged a few times and got nothing, so thought there must be a reason :)
<pete-woods> thanks for the assign!
<veebers> sil2100: ugh, failed build: https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/80/console
<Mirv> pete-woods: oh, but you probably don't want to land to utopic anymore since the release is tomorrow and I think they asked to move to SRU mode nowish already.
<Mirv> pete-woods-afk: so I'll change that to rtm if not a problem.
<Mirv> pete-woods-afk: just the sprint hecticness and weariness I assume
<thomi> ruh roh
<veebers> ugh I know why
<Mirv> and then the next release to vivid when it opens possibly on Friday
<sil2100> veebers: looking, but hm, maybe there was something released but not merged in?
<veebers> thomi, sil2100 : I made those changes to trunk not 1.5. I'll redo this in 1.5 (as there are things in trunk not released yet)
<thomi> veebers: ahh, of course.
<sil2100> veebers: ah, ok - just modify the MRs and let's reconfigure the silo
<sil2100> And rebuild
<thomi> veebers: we're still on track for the things in trunk to release this week tho, right?
<thomi> sil2100: either way we need the changes in both trunk & 1.5 of course
<veebers> thomi: trying to, currently blocked with getting this CI test passing still
<veebers> thomi: I should remove debian/autopilot-touch.dirs as well as .install right?
<ogra_> veebers, only in utopic yet
<veebers> ogra_: sorry I don't understand that comment
<ogra_> veebers, dbus-property-service (and the removal of AP from the image) only happened in utopic yet
<ogra_> veebers, for rtm we should add dbus-property-service to your silo and also make sure to pull the ubuntu-touch-meta changes that remove AP in at the same time ... so for now, focus on utopic only
<veebers> ogra_: ack, thanks
<ogra_> until we verified it all works there
<veebers> thomi, ogra_: if you could approve this MP I'll update the spreadsheet etc. https://code.launchpad.net/~veebers/autopilot/1.5-fixing-packaging-image-removal/+merge/239192
<thomi> veebers: done
<veebers> thanks thomi
<sil2100> veebers: can I reconfigure now?
<veebers> sil2100: is it cool if I just swap out the MRs in the spreadsheet that I've already filled in?
<sil2100> Yeah
<sil2100> :)
<veebers> sil2100: heh, yep I've just updated the MR links now
<ToyKeeper> tedg, charles: Any chance of an update on the silent-mode silo?  It has a couple issues: https://trello.com/c/1SD2iXGn/260-ubuntu-rtm-landing-025-indicator-sound-tedg
<charles> ToyKeeper, /me looks
<ToyKeeper> charles: Nothing appears to be an actual regression though, so we could probably land it if the test plan is updated to cover all the relevant behavior and expectations, then fix the three issues later.
<veebers> trainguards, re: the exception error I see in my silo build, should I just try a re-build? (https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/81/console)
<brendand> charles, if they have appropriate bugs raised already
<charles> ToyKeeper, completely agree with you wrt the lack of manual tests, I commented on that in my merge review as well
<charles> ToyKeeper, what I'm looking at now is trying to see what the state of the systems-settings <--> indicator sync bug is
<sil2100> veebers: hm, yeah, I think this was some connection error
<sil2100> Check if a re-run will help
<charles> ToyKeeper, I believe this is yet another manifestation of https://bugs.launchpad.net/indicator-location/+bug/1336715
<ubot5> Ubuntu bug 1336715 in unity8 (Ubuntu) "switch-items in indicators sometimes get out of sync with system-settings" [Critical,Fix released]
<veebers> sil2100: ack, thanks
<charles> ToyKeeper, which has been marked as fixed
<charles> ToyKeeper, so I'm going to re-run https://code.launchpad.net/~nick-dedekind/unity8/lp1336715-checkable-bindings/+merge/234503/comments/582588 to see if that sync test works now
<ToyKeeper> charles: If the sync issue requires other packages (system-settings) to fix, that can be landed later.  We should make sure there's a bug for it and that it's on olli's list somewhere.
<ToyKeeper> charles: I'm filing the keyboard/dialpad silencing bug now.  Probably won't be fixed by rtm.
<charles> yes, I know this is on dednick's and kgunn's TODO list. I don't see it tracked elsewhere so I'm going to re-open bug #1336715 for tracking
<bdmurray> sil2100: What need to happen next with apport?
<ubot5> bug 1336715 in unity8 (Ubuntu) "switch-items in indicators sometimes get out of sync with system-settings" [Critical,Fix released] https://launchpad.net/bugs/1336715
<sil2100> bdmurray: ah, sorry, so many things going on
<sil2100> bdmurray: so, you have a krillin ubuntu-rtm by any chance?
<sil2100> bdmurray: if yes, then if you could just test install the package from the silo PPA and check if all is ok
<charles> dednick, ToyKeeper, kgunn: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1336715/comments/14
<ubot5> Ubuntu bug 1336715 in unity8 (Ubuntu) "switch-items in indicators sometimes get out of sync with system-settings" [Critical,Confirmed]
<ToyKeeper> charles: https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1384274  (needs triage)
<ubot5> Ubuntu bug 1384274 in ubuntu-system-settings (Ubuntu) "silent mode doesn't silence keyboard or dialpad" [Undecided,New]
<ToyKeeper> charles: Thanks.  Could you update the indicator-sound test plan?  I think that's the last item remaining before it can land.
<charles> ToyKeeper, I think ted is the better person to do that, but I will track him down and pester him to do that
<charles> ToyKeeper, ...and he just walked in the door! Consider him nagged :)
<ToyKeeper> tedg, charles: It just needs to verify the indicator's functions, expected behavior, and current bugs which interfere with anything it's supposed to do.
<pete-woods-afk> Mirv: thanks, yes, that was a mistake
<plars> sergiusens: that u-d-f is not backwards compatible at all
<plars> sergiusens: I just tried it locally
<ogra_> plars, what does that mean ?
<ogra_> all official channnels should be installable with it
<plars> ogra_: right, but it requires command line change, so we have no backwards compatibility with a deprecation plan - it just has to change all at once. This is what we talked about not wanting to do
<plars> ogra_: it appears that we just need to specify the subcommand 'touch' now, but if you don't then it doesn't work
<sergiusens> plars: weird, what command are you running?
<plars> so it breaks us unless we simultaneously change the provisioning script
<plars> ubuntu-device-flash --password ubuntuci --bootstrap --developer-mode --channel ubuntu-touch/devel-proposed
<plars> unknown flag `password'
<Saviq> trainguards, can I have a reconfigure on rtm silo 15 please
<sergiusens> plars: ack, I'll fix; was something I missed
<plars> sergiusens: thanks :)
<dednick> charles: https://bugs.launchpad.net/indicator-network/+bug/1336715/comments/15
<ubot5> Ubuntu bug 1336715 in unity8 (Ubuntu) "switch-items in indicators sometimes get out of sync with system-settings" [Critical,Confirmed]
<sergiusens> plars: so I see what's going on; mandel asked me to split the review and I messed up when splitting :-/
<plars> sergiusens: no problem, I'm just trying it locally for now and I'll work on getting a regular job against this soon, so it will just test as part of the MP in the future
<veebers> trainguards: What's the expected time taken to build a silo? Perhaps I'm being impatient. (https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/82/console)
<sil2100> veebers: so, all packages are built now but are pending publication in the PPA still
<veebers> sil2100: ah I see, thanks
<sil2100> So it should be any minute now :)
<veebers> sweet
<sil2100> veebers: if, of course, the release guys didn't do something that just makes the publishers really busy
<sil2100> Or something
<veebers> sil2100: heh, understood
<plars> veebers: concerning https://code.launchpad.net/~veebers/autopilot/1.5-fixing-packaging-image-removal/+merge/239192 - I notice it removes the click.rules
<plars> veebers: does something else put those in place? iirc we need to use those during the testing process for autopilot to work properly
<plars> maybe it's not needed anymore, but tradtionally we've had to call 'sudo aa-clickhook -f --include=/usr/share/autopilot-touch/apparmor/click.rules' to get things working properly
<veebers> plars: right, this makes autopilot-touch a meta package that installs the dependencies. ogra_ has confirmed that that file is in a diffrent package now that is in the image
<veebers> plars: ah ok, so  perhaps the path might change? ogra_ can you confirm?
<ogra_> plars, dbus-property-service actually uses the file for the apparmor setup ... so it should ship it
<ogra_> the path should still be the same
<plars> ogra_: ack - that's good, as long as it comes from somewhere :)
<ogra_> plars, right, and you shouldnt call aa-clickhook yourself
<ogra_> phablet-config does that for you
<plars> ogra_: so it looks like unity8-autopilot only recommends autopilot-touch, so we'll still need to force installation somewhere
<ogra_> (whould be good to use it that way in smoke testing too, soo we see it in case  there is something wrong with it once)
<ogra_> hmm, right
<ogra_> plars, can we do that somewhere in utah ?
<ToyKeeper> pete-woods: Not sure if you saw yesterday, but the thumbnailer silo (rtm-003) failed testing.  It doesn't appear to fix video rotation at all.
<plars> ogra_: I can do it somewhere, but as we start to move to adt, I'm hopeful that it will get easier... iirc pitti said that just works in adt
<ogra_> plars, right, we just need an interim solution for now
<ogra_> and making ap-touch a hard dep of unity8-ap will likely break other stuff
<cjwatson> sil2100: there was an accidental firewall downage earlier apparently
<cjwatson> so that might have delayed stuff
<cjwatson> veebers: ^-
<sil2100> cjwatson: oh, ok, then something did happen to make it slower
<balloons> woot, ogra_ I see ap dropped on the new image :-)
<sil2100> cjwatson: thanks for the info, we're still waiting for the binaries to publish
<ogra_> balloons, yeah, causing a lot of havoc in smoke testing :)
<ogra_> it all comes at a price ;)
<balloons> ogra_, right I saw the commentary. My expectation is some tests don't list autopilot as a proper dependency
<ogra_> right
<ogra_> well, in fact autopilot-touch
<ogra_> (which pulls in the other bits as deps)
<balloons> so why the concern listing ap-touch as a depends will break something?
<ogra_> balloons, because it might break unity8 tests on desktop
<ogra_> there must be a reason it was made only a recommends and not a depends
<ogra_> (if there isnt it should indeed be bumped up to a hard dep)
<ogra_> for now we first need to get test going again though ... we can then look into the rest
<ogra_> *testing
<veebers> cjwatson: ah I see, thanks
<ogra_> veebers, i added proper paperwork to bug 1383479 ... so olli knows where your landing belongs to
<ubot5> bug 1383479 in ubuntu-touch-meta (Ubuntu RTM) "Remove autopilot from touch images" [Critical,Confirmed] https://launchpad.net/bugs/1383479
<veebers> ogra_: excellent, thanks for doing that
<sil2100> cjwatson: btw. do you know if the firewall issue got fixed?
<sil2100> cjwatson: since I see that the autopilot packages still didn't get published
<cjwatson> sil2100: where should those be?
<sil2100> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004/+packages
<sil2100> We're waiting for the publisher to pick them up since over 40 minutes
<cjwatson> ok that does seem rather bad
<cjwatson> let me look
<pete-woods> ToyKeeper: thanks. just pinging the tester (satoris) about it
<ToyKeeper> pete-woods: I'm actually retesting it now with rtm-016 added, to see if the changes are more visible together.
<cjwatson> sil2100: working on it with IS, was stuck due to firewall outage earlier
<sil2100> cjwatson: ah, ok, thanks a lot :)
<cjwatson> sil2100: unwedged; you should see things moving soon
<pete-woods> ToyKeeper: according to Satoris, you definitely need both for it to be fixed
<satoris> ToyKeeper: so the reason they were proposed separately was that at the time there was no clear timeline when the gstreamer changes would land and having the fix in thumbnailer would make it immediately obvious to jhodapp whether he is doing the right thing.
<satoris> Should have explained this better in the silo request. Sorry about that.
<veebers> plars, ogra_ sweet, looks like the ppa now has the packages from the silo build
<jdstrand> can I have a silo for line 86?
<ToyKeeper> pete-woods, satoris: Test results for rtm-003 + rtm-016 look good.  I hear that 16 has a bug and may need some changes, but it seems fine for 3 to land by itself.
<Mirv> what's wrong with jenkins hmm..
<Mirv> ToyKeeper: excellent! I'll publish 003 then
<ToyKeeper> pete-woods, satoris: For similar changes in the future though, please include a note that it depends on another silo in order to function.  :)
<veebers> plars, ogra_: That's all we need to run a test right?
<pete-woods> ToyKeeper: noted!
<brendand> ToyKeeper, i think they should land together
<ToyKeeper> brendand: rtm-003 doesn't break anything, it just allows later changes to work.
<ToyKeeper> brendand: It'd be ideal to land everything as one logical change, but in this case it seems there no harm in landing thumbnailer first by itself.
<satoris> brendand: silo 3 is basically "if someone has set the orientation tag, use it". So if there are videos that already have that then they will work.
<satoris> Silo 16 is then about setting the tag inside gstreamer for files created by the phone.
<alecu> ToyKeeper: thanks for finding out that our silo contains branches for bugs that we are not supposed to land yet. We are reconfiguring it and we will follow the testplan on it as soon as the trains rebuilds. Sorry for the annoyance; we'll ask you to re-review it later today.
<brendand> ToyKeeper, satoris - true i guess. and 16 should land soon hopefully
<Mirv> Saviq: reconfig done. the automatic function was somehow broken, needed to type in stuff manually.
<Mirv> sil2100: ^ for some reason the reconfig (prepare-silo) just gave me an empty page no matter what I did, after clicking the Proceed button
<ToyKeeper> alecu: Ah, I actually was hoping to land all of that since it all seemed important.  For today's bug review meeting, I recommended landing the whole silo...  but I haven't heard yet what was decided.
<alecu> ToyKeeper: ah, that sounds great. We'll have to re-rebuild the silo anyway...
<ToyKeeper> alecu: Not my call though; waiting on olli to confirm what's landable.
<plars> ogra_: doesn't look like it worked :( http://paste.ubuntu.com/8629765/
<plars>  *** 1.5.0+14.10.20141022-0ubuntu1 0
<plars>         500 http://ppa.launchpad.net/ci-train-ppa-service/landing-004/ubuntu/ utopic/main armhf Packages
<plars> ogra_: here's the other relevant portion from when it installed autopilot-touch: http://paste.ubuntu.com/8629802/
<plars> see if I can grab thomi later and ask him since veebers is offline now
<veebers> plars: hey touching base re: the autopilot removal from image testing. (was offline for a bit). Any luck with that?
<sil2100> brendand, davmor2, elopio: just making sure that's known - silo 24 got an approval from product team that it can land
<sil2100> ToyKeeper: ^
<sil2100> So if you have a moment, please move it to the 'Needs testing' in your trello-board
<brendand> sil2100, ok
<plars> veebers: no, it didn't seem to work: see http://paste.ubuntu.com/8629765/ and http://paste.ubuntu.com/8629802/
<ogra_> plars, autopilot-qt4 ??
<ogra_> how does that get there ?
<veebers> ogra_, plars: yeah not sure where autopilot-qt4 comes from, autopilot-touch depends on autopilot-qt5 & qttestability-autopilot
<plars> veebers: ogra_: no idea -maybe unity8-autopilot?
<ogra_> i dont see it in the Depends line
<plars> yes, looks like
<veebers> plars: I don't see autopilot-touch in that pastebin at all
<plars> ogra_: but that's when it's getting installed, when it asks for unity8-autopilot
<plars> veebers: it's in the first one
<ogra_> yes, i see the log
<veebers> plars: ah I see oops
<ogra_> i just dont get why .... there are no Qt4 deps anywhere
<ogra_> Depends: gir1.2-glib-2.0, libautopilot-qt (>= 1.4), libqt5test5, libqt5widgets5, python-autopilot, python-evdev, python-fixtures, python-gi, python-mock, python3-autopilot, python3-evdev, python3-fixtures, python3-gi, ubuntu-ui-toolkit-autopilot, unity8 (= 8.00+14.10.20141013.2-0ubuntu1), unity8-fake-env (= 8.00+14.10.20141013.2-0ubuntu1), url-dispatcher-tools, python3:any (>= 3.3.2-2~), python (>= 2.7), python (<< 2.8)
<plars> ogra_: according to rdepends - libautopilot-qt
<plars> which I think is required for unity8-autopilot
<plars> veebers: so is autopilot-qt4 what's messing it up?
<ogra_> ogra@styx:~/Devel$ apt-cache show libautopilot-qt|grep Depends
<ogra_> Depends: autopilot-qt4, autopilot-qt5, qttestability-autopilot
<ogra_> why is that not an | dependency
<veebers> ogra_: I think the lack of libautopilot-qt5 is causing the error
<veebers> due to the testability library not being loaded
<veebers> (see line 449 in that first pastebin)
<ogra_> veebers, well, but unity8-ap seemingly has a hard dep on libautopilot-qt ... which in turn will always pull in the qt4 stuff .... which sounds like at least a waste if it doesnt do harm
<plars> veebers: ogra_: I can easily try installing libautopilot-qt5 and see if it works with that
<veebers> ogra_: right, it does sound like a wast
<ogra_> plars, ++
<veebers> plars: sounds good
<plars> oh
<plars> E: Unable to locate package libautopilot-qt5
<plars> ?!
<ogra_> wow
<ogra_> try without "lib" perhaps
<plars> ogra_: autopilot-qt5 is already installed
<ogra_> (that at least exists )
<balloons> the toolkit brings in qt4 stuff
<balloons> if i remember correctly
<ogra_> hmm
<balloons> specifically the ubuntu-ui-toolkit-autopilot, due to legacy stufff
<ogra_> the second paste looks quite okay ... what is that from ?
<veebers> ogra_, plars: rats, I think that was a wild goose chase, now that I look closer I see "Testability driver loaded. Wire protocol version is "1.4"." (which indicates that it's loaded fine)
<jdstrand> mandel: hi! it turns out we are missing an apparmor rule for apps to successfully use download manager: bug #1384349
<ubot5> bug 1384349 in apparmor-easyprof-ubuntu (Ubuntu) "apparmor denies app-specific download dorectpry" [Undecided,New] https://launchpad.net/bugs/1384349
<ogra_> are we sure webbrowser actually worked in recent images ?
<sil2100> ToyKeeper: yea, so 24 doesn't have a general test plan as it's a very low level component that usually lands straight into the archive
<veebers> plars: I see this "pull: /var/crash/_usr_bin_autopilot3.32011.crash" is there anything of interest in that?
<veebers> ogra_: that is a good question too
<ToyKeeper> sil2100: I'm looking into more details now; might be able to find a way to test it.
<mandel> jdstrand, ok, will look at it asap
<jdstrand> mandel: I wanted to confirm that ~/.local/share/ubuntu-download-manager/<click pkgname> is intended
<sil2100> ToyKeeper: normally it would land without QA sign-off even, but elopio wanted to make double sure it's not breaking anything
 * ogra_ twiddles thumbs ... slow dashboard is slow 
<jdstrand> mandel: nah, it is for me to fix
<sil2100> ToyKeeper: the bug should have all the details for the bug itself I guess
<jdstrand> mandel: I just wanted to double check with you before adding it
<cjwatson> sil2100: everything all well now from the point of view of PPA publishing?
<sil2100> cjwatson: thanks, all seems to go smoothly now :)
<ogra_> plars, http://ci.ubuntu.com/smokeng/utopic/touch/mako/293:20141020:20141017.2/11059/webbrowser_app/ looks like it failed since a while already ... (thats 293) ... i guess we should pick another package
<cjwatson> sil2100: cool
<plars> ogra_: ah, good catch. I'll try unity8 instead
<ogra_> yeah
<jdstrand> mandel: so, I was thinking these would be the rules I would apply:
<jdstrand> owner @{HOME}/.local/share/ubuntu-download-manager/@{APP_PKGNAME}/   r,
<jdstrand> owner @{HOME}/.local/share/ubuntu-download-manager/@{APP_PKGNAME}/** rk,
<veebers> ogra_: good catch
<jdstrand> mandel: ie, read-only access. this is what we do with content hub for example. does this sound reasonable?
<robru>  fginther / cihelp:  any known issues with jenkins? https://code.launchpad.net/~robru/cupstream2distro/obliterate-preprod-bs/+merge/239143 is waiting on CI for nearly 1.5 hours
<ogra_> traffic jam ?
<ogra_> :)
<robru> ogra_: http://s-jenkins.ubuntu-ci:8080/job/cu2d-choo-choo-ci/ ci job hasn't ran in 12 hours
<ev> robru: please don't ping people directly - that's why we have the vanguard
<plars> ogra_: hmm, I just noticed that unity8 probably won't tell us much - that one was working
<plars> even in 296
<robru> ev: i pinged the vanguard ;-)
<ev> robru: and Francis :)
<ogra_> plars, system-settings ?
<ogra_> or address_bok
<ogra_> *book
<plars> ogra_: ok, this is the one where we see the infinite loop of:
<plars> 18:19:50.277 DEBUG _uinput:541 - Dragging from 270,481 to 270,325
<plars> ogra_: I'm reproducing it locally even with the new autopilot, so no improvement there, but this could be a test case issue
<plars> ogra_: I can confirm the screen is unlocked though, so this has nothing to do with the screen unlock status
<plars> ogra_: sil2100: I'm starting to think we just have a whole lot of test issues that need to be tracked down
<plars> sil2100: ogra_: fwiw, in the ubuntu-system-settings case, it seems to be sitting on the "Cellular" screen in u-s-s, waiting for something that never happens
<plars> ubuntu_system_settings.tests.test_cellular.DualSimCellularTestCase.test_changing_sim1_name is the test
<psivaa_> robru: i'll take a look at that
<plars> the screen I'm looking at doesn't seem to be a slider though, it's a checkmark next to sim1 or sim2, so I'm not sure why it's trying to drag?
<plars> I think this is just a test that needs fixing
<sil2100> Yeah, our tests have gone bad
<robru> psivaa_: thanks
<barry> mandel: hiya
<jdstrand> mandel: so, the rules I pasted work for beru. can you confirm they are ok and what you expect?
<mandel> jdstrand, give me a few second
<boiko> trainguards: can I get a silo for row 87? not urgent if low on silos (no critical bugs, just regular rtm/ota bugfixes)
<plars> ogra_: veebers: it's worth noting that ubuntuuitoolkit seems to get that same error as webbrowser app on krillin, so it doesn't seem isolated to one test
<ogra_> plars, hmpf
<veebers> plars: :-\ hmm do you have pastebin of the output?
<plars> veebers: http://paste.ubuntu.com/8629765/
<veebers> thanks
<ogra_> plars, again ... it has that on 293 too
<ogra_> (uitk)
<plars> ogra_: I know, but we're seeing a lot of failures, are we really sure that there was a regression with this autopilot removal?
<veebers> plars: that looks like webbrowser tests not uuitk (unless I missed something)
<ogra_> plars, not at all :P
<ogra_> veebers, https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/1062/consoleFull thats the console log from 293 (before dropping AP)  ... it has the UITK pfailure there
<ogra_> plars, we have two probs now .... utopic is closed ... and i'm scared to make the same change in rtm without knowing we actually didnt cause a regression
<ogra_> plars, but i fear thats the only way to go now
<ogra_> plars, UITK has a fix from ricmm in some silo i think
<cjwatson> you can still land things in utopic provided that they absolutely do not touch the other images
<cjwatson> at least to some extent
<ogra_> oh, wait, but thats something different
<veebers> ogra_, plars: So I'm seeing passing tests in that link, so things aren't completly broken (i.e _something_ works)
<plars> ogra_: we should talk to sil2100, but from my perspective, we have plenty of issues to deal with even without the removal of autopilot, and while nice to have, I don't think there's any critical need to remove it immediately
<plars> ogra_: sil2100: I think we should get people huting down these ap test regressions asap though
<ogra_> cjwatson, right, but we're not sure if anything will help and i dont want to break it even more and then be trapped by hard freeze
<plars> veebers: yes, it seems a few will pass, then a traceback
<cjwatson> ogra_: Yeah
<ogra_> plars, yeah ... but i'm a bit unhappy to have the distros out of sync now ...
<ogra_> and AP dropping will give us pleanty of space
<ogra_> *plenty
<ogra_> krillin 122 looks actually pretty good
<ogra_> plars, did you have to manually intervene there ?
<veebers> plars: hmm, I'm looking through to see if there are passing tests that use taps and/or drags etc. in case the input stuff is broken somehow
<bdmurray> Does the fix for bug 1339916 need to be added to the wishlist spreadsheet?
<ubot5> bug 1339916 in whoopsie (Ubuntu RTM) "SystemIdentifier can change between reboots" [Undecided,New] https://launchpad.net/bugs/1339916
<sil2100> plars, ogra_: yeah, so we should do that, but not sure if we'll get those down this week
<ogra_> bdmurray, yes, talk to olli or pmcgowan to get it added ... you need to mark it critical and tag it wwith rtm14
<ogra_> sil2100, plars are you guys at the same place atm ?
<plars> ogra_: nope, I didn't touch the 122 run
<ogra_> plars, wow
<ogra_> thats pretty good news then
<sil2100> ogra_: I'm on the 'Click packaging and CI' meeting
<plars> ogra_: no, but I just saw the time, I think I'm missing a session
<ogra_> k
<bdmurray> ogra_: talk to them and change the bug?
<ogra_> bdmurray, right
<ogra_> sil2100, plars, i think we should discuss that in person once we have a min to sit down
<sil2100> ogra_: we have a landing meeting today, we can have a quick chat during that
<psivaa_> robru: please check those two mp's. it could be that both the proposed branch and the pre-requisite branch being updated being the reason for the jenkins not triggering
<ogra_> sil2100, ok
<robru> psivaa_: it seems they've both run now, thanks for looking
<ogra_> psivaa_, i assume you didnt touch rtm krillin 122 either ?
<ogra_> (just to make sure)
<pmcgowan> bdmurray, dont tag it just put it in the spreadsheet in the email
<jdstrand> trainguards: may I have a silo for line 86?
<robru> boiko: oopps, i tried to assign yours but there were conflicts: https://ci-train.ubuntu.com/job/prepare-silo/2886/console
<boiko> robru: let me check what is in other silos
<boiko> robru: in any case, this is not landing anytime soon, so conflicts are fine
<robru> boiko: ok
<robru> jdstrand: rtm 3
<plars> ogra_: ah, I know one reason things did better on that run - it looks like dropping letters is gone from that image now too - so no infinite loop
<ogra_> plars, thats weird, i wonder who removed it without telling anyone
<plars> ogra_: which means the test didn't take hours before getting the job killed and taking out the tests after it
<boiko> robru: on a different topic, I have a silo that was targetting utopic, would it be possible to change it to target rtm?
<plars> ogra_: at least from the dropping letters result, it looks like it's not there
<robru> boiko: well we'd have to toss the silo and reassign. which one?
<ogra_> plars, given that we can still add/remove stuff in rtm i would really like to do the change there though ... since there we definitely have the option to roll back
<boiko> robru: row 40 (utopic silo 001)
<robru> boiko: ok line 87 got rtm 26
<boiko> robru: nice! thanks!
<ogra_> plars, especially now that we have a complete run and can judge it based on this
<ogra_> (which we had not in weeks for utopic)
<robru> boiko: so row 40 is just a sync? row 39 implies the same stuff already landed in rtm
<boiko> robru: oh, wait, hmm
<robru> boiko: heh, I already freed it. sorry
<boiko> robru: sorry for the confusion, I was not checking the spreadsheet, I was using the dashboard :/
<robru> boiko: but still there was some reason you wanted to give up landing in utopic? can it wait for vivid perhaps?
<boiko> robru: not really, it is just that I didn't realize it was already landed in rtm and I was going to land it there first :)
<robru> boiko: ok so you want me to reassign the sync then?
<boiko> robru: I think so, if that's not much trouble for you
<robru> boiko: no worries
<robru> boiko: you'll just have to resync
<robru> (rebuild)
<robru> boiko: sorry, 'sync:2' syntax was stale, started syncing somebody else's silo. assigning real sync silo now
<robru> boiko: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-016 ok you're in 16 now, please hit build to trigger a binary copy from rtm to utopic
<boiko> robru: thanks!
<robru> boiko: you're welcome~!
 * robru -> lunch
<psivaa_> ogra_: nope, i dint touch rtm krillin 122 :)
<ogra_> \o/
<ogra_> thats awesome :)
<mandel> jdstrand, the download manager should be downloading files to the following dir for confined apps => QStandardPaths::DataLocation/APP_ID/Downloads
<mandel> jdstrand, the path ~/.local/share/ubuntu-download-manager/Downloads is for unonfined apps
<jdstrand> oh
<jdstrand> huh
 * jdstrand scratches head
<mandel> jdstrand, let me check the bug
<jdstrand> cause the denial is for ~/.local/share/ubuntu-download-manager/@{APP_PKGNAME}/
<jdstrand> mandel: ^
<jdstrand> and said app is clearly confined (you can tell by profile name in the bug's denial
<jdstrand> mandel: note: I chopped off Downloads/ from the path, but it is there in the denial
<mandel> jdstrand, yes, sorry QStandardPaths::DataLocation defaults to /home/phablet/.local/share/ubuntu-download-manager/ so you are correct
<jdstrand> ah, ok
<mandel> jdstrand, should be /home/phablet/.local/share/ubuntu-download-manager/ + APP_ID
<jdstrand> mandel: and read-only is ok by you?
<jdstrand> mandel: (readonly worked for beru)
<mandel> jdstrand, well, we have an issue if it is readonly, if it is readonly the app will not be able to delete the files and the user will have to do manually
<jdstrand> that makes sense
<jdstrand> ok, thanks
<veebers> ogra_: so looking at the link of yours (before ap removal) and the results of the run plars did, I'm not sure the removal of ap from the image introduced any regressions, the are so many failures etc. in the run before hand it's hard to tell
<jdstrand> it's app-specific, so that's cool
<mandel> jdstrand, read-write sounds goods since the path is only for the application and that way they can delete the downloads that are not longer needed, right?
<om26er> bzoltan, ^
<jdstrand> mandel: ok, thanks! I'm on it
<mandel> jdstrand, awesome!
<jdstrand> mandel: yes, it's fine security wise, just different from content-hub so wanted to double check if write was needed
<ogra_> veebers, right, this is why i would like to do it in rtm ... with the successfull test run of image 122 we have a good datapoint to look at tomorrow then ... and decide to roll back or keep the change
<ogra_> veebers, but i want sil2100 and plars to agree to that plan :)
<plars> veebers: do you know if this timeout option in autopilot ever landed, so that tests won't run forever?
<veebers> ogra_: ah I see, sorry I'm caught up now :-)
<sil2100> Which plan? I'm a bit all around the place today
<veebers> plars: I'm wanting to land that this week (somewhere) but it hasn't landed yet sorry
<mandel> jdstrand, no idea on the file management by the content-hub, I just want to make sure that we don't have phones that are full of downloads and the user has to manually deal with them
<ogra_> sil2100, *the* plaaan !
<plars> ogra_: I'd prefer to see more of a trend - I think we got lucky in 122 because of the mysterious dropping_letters removal
<veebers> plars: but that code exists in an approved MP, just not release yet
<ogra_> plars, i'll try to find oout how it got removed
<plars> ogra_: and I'd really prefer to get some autopilot test experts on figuring out what can be done about these failing tests - we've built up a bit of a backlog of those
<plars> veebers: I've heard that phablet-test-run will need to pass it some new parameters when that lands?
<ogra_> plars, you mean on utopic ? we cant really do much anymore ... in less than 24h utopic will close down
<ogra_> plars, we will have to look at rtm only for now
<plars> ogra_: on everything
<veebers> plars: yes. It adds the command line option "--test-timeout=<seconds>" inwhich it attempts to kill and fail the test after <seconds>.
<bzoltan> om26er: Thank you. kalikiana will explain what the system settings should do in order to fix that dialog.
<ogra_> plars, the thing is, if we dont do the AP removal here where we are all on the same TZ, i fear we wont be able to easily do it at all ... and it only costs us a roll-back if it isnt successful
<plars> ogra_: I could probably reduce the noise a bit by adjusting systemsettle if we really got approval on that - I don't think I ever heard confirmation
<ogra_> i dont think it was ever properly discussed with the mgmt
<plars> ogra_: is that less of a pain if we are all traveling vs doing it remotely though?
<ogra_> (i know you said you brought it up somewhere but we never heard back)
<plars> ogra_: no, sil2100 said it was ok'd but I don't recall details of someone saying this
<ogra_> plars, it is less of a pain when doing it today, see if the results differ from 122 and roll back tomorrow
<ogra_> i wouldnt do it on friday indeed :)
<plars> ogra_: indeed, I'm fine with that if sil2100 is
<sil2100> Wait, is this about the threasholds, or about something else?
<plars> sil2100: both
<ogra_> sil2100, this is about AP removal ...
<ogra_> sil2100, and the threshold
<sil2100> ogra_: so, about the thresholds asac said a +1 on adjusting them some time ago
<sil2100> The AP removal seems to work nicely on utopic now, right?
<ogra_> sil2100, the rob with the AP removal in utopic is that we cant really tell anything ... which makes me think i would really like to do them in rtm
<sil2100> Due to tests being broken?
<ogra_> sil2100, no idea, we havent had any older results to actually make a judgement on
<ogra_> right
<ogra_> utopic was to broken for to long to actually pinpoint if the AP removal had any actual effect on tests
<sil2100> ogra_: do we need to land any autopilot changes when doing that, or just removing the AP-packages is enough by itself?
<ogra_> sil2100, OTOH rtm has the first complete test run since days today
<sil2100> (as per the earlier AP change proposed, but I think that wasn't required?)
<ogra_> which gives us a nice datapoint to compare with
<ogra_> sil2100, AP, dbus-property-service and an ubuntu-touch- meta change
<ogra_> sil2100, when we do it today while we are all here it will be way easier to coordinate the roll back if needed
<sil2100> Ok then, let's make the final decision on the landing meeting, but so far I think we can take the risk, since I see that those should be easily revertable
<ogra_> right
<sil2100> ANd we don't have any image required to build for propotion anyway
<sil2100> *promotion
<ogra_> right
<sil2100> Ok, I need to find slangasek now
<sil2100> brb
<jhodapp> sil2100, rtm silo 16 is ready for landing (brendand gave QA approval)
<jhodapp> or robru ^
<jdstrand> mandel: re full uploads> yep, ack. on it
<Mirv> jhodapp: so it seems according to trello, spreadsheet is slightly broken again with its status update feature
<Mirv> jhodapp: ^ https://code.launchpad.net/~jhodapp/qtubuntu-media/orientation/+merge/238357 is not top-approved
<jhodapp> Mirv, ok, let me get someone to approve
<jhodapp> Mirv, ok, it's approved now
<Mirv> jhodapp: ^ done
<jhodapp> Mirv, thanks!
<Mirv> brendand: om26er: rtm-007 claims to be QA Sign-off:d, but I don't find that to be the case on trello?
<Mirv> better just to not mark it Granted, , as it's in the Blocked column
<brendand> Mirv, might have been a mistake on my part
<brendand> Mirv, maybe i got the wrong row
<Mirv> it's line 32
<veebers> plars, ogra_: I went offline during the discussion re: removal of ap from image. Where do we currently stand, are we waiting for tomorrow for a test run?
<ogra_> veebers, verdict was that it should be discussed at the landing team meeting (in ~30min)
<ogra_> but we seem to be all in favour of doing it now rather than later
<veebers> ogra_: ah ok, please let me know the result :-)
<ogra_> veebers, indeed :) (if you have time you could even attend ... )
<ogra_> sil2100, plars , so i asked asac about the systemsettle adjustment and he suggested we should let it sign off by QA
<plars> ogra_: ok, davmor2?
<ogra_> hehe
<plars> :)
<davmor2> plars: not one for me, you'll want jibel for that
<ogra_> lol
<ogra_> pass the bucket :)
<sil2100> )
<sil2100> ;)
<veebers> ogra_: sorry just in the middle of something
<brendand> Mirv, 25 signed off?
<ogra_> yeah, was just an offer :)
<brendand> ah yeah
<Mirv> brendand: apparently by ToyKeeper, yes
<brendand> Mirv, yeah that's ok
<Mirv> nice
<brendand> Mirv, i missed it on our board
<mandel> sil2100, can you please get me asilo for line 88 asap, is quite important for the location service
<Mirv> mandel: may I? :) ping trainguards in general
<sil2100> Sure ^ I'm in a meeting now
<mandel> Mirv, sure, sorry, I'm used "bully" him hehe
<mandel> sil2100, sorry!
<Mirv> mandel: heh. rtm-024.
<mandel> Mirv, argh, autocomplete
<brendand> alecu, there's a problem with silo 5
<ToyKeeper> brendand, Mirv: Yes, rtm-025 just needed some test plan updates.  There are bugs, but no regressions, and they can be fixed later.
<ToyKeeper> brendand: Last I heard, alecu is building silo 5 with the original packages it had yesterday, so they can all land.  What is the problem with it?
 * alecu listens intently
<brendand> and now the problem is gone
<brendand> weird
<alecu> awesome! I love the kind of problems that go away by themselves
<alecu> brendand: I just rebuilt the package with the four branches from yesterday, perhaps it was finishing the build and that made things weird on the spreadsheet or on the dashboard
<brendand>  alecu , maybe
<brendand> alecu, it seems ok now
<alecu> great
<sil2100> robru: you around for the meeting in 3 minutes?
<robru> yep
<robru> sil2100: hm, the event doesn't have a video thing
<sil2100> robru: we'll use one of the old HO and send you a link, want everyone to gather first
<sil2100> (maybe someone will have a charger)
<robru> sil2100: ah, i added a video thing... if that doesn't work then send me a link i guess
<Mirv> robru: https://plus.google.com/hangouts/_/canonical.com/landing-task?authuser=1
<brendand> alecu, are you confident your test plan is up-to-date with tests for the bug fixes?
<sil2100> ogra_: istambul!
<brendand> alecu, it hasn't been updated in a couple of weeks
<ogra_> sil2100, yeah, next to las vegas
<ogra_> (americans and geography ... )
<kenvandine> robru, what's the current rule for landings in utopic?  can we still publish silos for fixes that are on the allowed list?
<robru> kenvandine: not sure, ask cjwatson? IIRC you can land stuff as long as it doesn't touch the desktop image or any *buntu images)
<kenvandine> just making sure it's ok to land in utopic then sync to rtm
<kenvandine> not in the desktop image
<ToyKeeper> alecu: silo 5 might take a bit longer to start testing; most of the testers are about to be in a big and possibly long meeting.
 * ToyKeeper biab
<slangasek> ogra_: http://people.canonical.com/~lzemczak/landing-team/ubuntu/289.commitlog
<bzoltan> elopio: Mirv: That desktop file fix is good
<veebers> wait, I don't remember adding that line to the spreadsheet.
 * veebers looks at ogra_ 
<robru> veebers: oh yeah I'm shuffling that around a bit at the request of ogra
<cjwatson> robru: that's correct yeah
<ogra_> veebers, to land it we need the new meta and dbus-property service land in parallel
<cjwatson> though there will be a practical cutoff pretty soon
<ogra_> veebers, meta gets pushed to rtm-proposed directly via copy-package from utopic once the silo lands
<robru> ogra_: Mirv: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-014-1-build/35/console mp building in rtm & sync should happen after that builds
<ogra_> robru, cool
<veebers> ogra_, robru: It looks like there was a decision about removing autopilot from the image? (as per ubuntu/landing-004 (veebers) Gave up this landing)
<ogra_> cjwatson, do we go on pushing into utopic-proposed to then sync into vivid from that ? (that is how i imagine the process after release at least)
<robru> veebers: well the decision was to land it just in rtm without utopic
<cjwatson> err no, should be pushing to vivid
<ogra_> cjwatson, oh, is it open already ?
<cjwatson> there'll be a day or two where everything will be held in queues, as short as we can make it
 * ogra_ wasnt aware
<ogra_> ah, k
<cjwatson> I thought you meant after release
<ogra_> no, i meant thhis week :)
<cjwatson> from now until vivid opens you should go on pushing to utopic-proposed, but no guarantees of acceptance
<ogra_> k
<cjwatson> but you did say "that is how i imagine the process after release at least"
<cjwatson> after this release we open the next release ASAP
<ogra_> heh, well, after tomorrow til vivid opens
<ogra_> sorry, i wasnt clear
<cjwatson> normally we just don't accept anything in that window
<ogra_> k
<cjwatson> but we will see, better to push to utopic than nowhere I guess ... might confuse us
<ogra_> (fine with me ... and less work for th elanding team)
<cjwatson> apparently there are rather few if any relevant toolchain changes pending
<cjwatson> so my guess is that opening will be pretty quick this time round
<sil2100> cjwatson: ping :)
<cjwatson> sil2100: hi
<cjwatson> oh /msg
 * sil2100 likes whispering
<Mirv> secrets!
<ogra_> sil2100, hmm, the click_image_tests broke a wwhile ago it seems ... i assume thats related to slangasek and cjwatson moving the clicks around ?
<sil2100> ogra_: might be? How is it failing?
<ogra_> sil2100, no idea, i only checked the tests for the last few images
<ogra_> (results i mean)
<ogra_> sil2100, click_image_tests seem to have been successfull in 106 last
<sil2100> hmm
<ogra_> oh, wait, i'm wrong
<sil2100> Later? Or earlier?
<ogra_> 108 last
<ogra_> failed in 109 for the first time and constantly since
<sil2100> ogra_: do you know if we list whenever we remove click packages from the rootfs?
<sil2100> Since I've been trying to find out when the click-strip-off happened, since I guess it was around those images
<ogra_> nope, only upgrades of them
<ogra_> no, it was later
<ogra_> iirc it was the night before we promoted the candidate
<ogra_> 110 to 114 somewhere
<ogra_> sil2100, but there is a bzr tree somewhere where you need to commit the change when removing a package
<ogra_> (i use it so rarely that i forgot again where)
<alecu> ToyKeeper: just finished my run of the testplan for silo rtm-5
<alecu> dobey: ^
<sergiusens> ogra_: sil2100 lp:click-sync
<ogra_> ah, right
<Saviq> asac, can't parse your comment in https://bugs.launchpad.net/ubuntu-rtm/+source/unity8/+bug/1348557/comments/19
<ogra_> sil2100, that should have all commits for added/removed packages
<ubot5> Ubuntu bug 1348557 in unity8 (Ubuntu RTM) "Make scrolling speed resolution independent" [High,In progress]
 * ogra_ cant even parse the title :P 
<cjwatson> sil2100: it's actually in lp:livecd-rootfs
<cjwatson> that has code for moving specific packages from rootfs to custom - click-sync isn't involved here
<ogra_> sil2100, to match the moving of the click packages you would have to match livecd-rootfs to an image number
<ogra_> i see that was on the 14th
<ogra_> (from utopic-changes)
<ogra_> which puts it around image 104
<ogra_> or 105
<ogra_> (there were two other uploads that will match 105)
<ogra_> so not related most likely
<cjwatson> win
 * cjwatson dodges bullets
<ogra_> :)
<ogra_> brendand-nexus5, moo
<brendand-nexus5> ogra_ - baa?
<ogra_> brendand-nexus5, soo ... there is silo rtm 14 ... that has the AP removal stuff ... we want to land this, build an image, see the smoke tests and if needed roll it back ...
<ogra_> brendand-nexus5, (as discussed before)
<dobey> brendand-nexus5: btw, it seems there are 2 cards for landing-005 in the trello now, as you added a second one
<ogra_> brendand-nexus5, to land the silo i would like to get QA nod-off indeed (since i want to be a good citizen) :)
<ogra_> brendand-nexus5, i dont think there is anything to sign off or test actually since the test is actually the next smoke test run (and we are prepared to completely undo the change)
<ogra_> brendand-nexus5, and to have enough time to revert all this tomorrow if needed i would like to land it now so it makes the next image
<brendand-nexus5> ogra_ - sure
<ogra_> cool, thanks !
<jhodapp> Mirv, utopic silo 24 doesn't seemed to be synced right from my previous rtm silo 16
<ogra_> argh !
<ogra_> veebers, ^^^^
<ogra_> please get the MP top approved asap
<veebers> ogra_: argh, wait this it the dbus-property-service? Who would be best to top approve it?
<ogra_> no, this is your MP
<ogra_> dbus-property-service was a source pakcgae sync
<Mirv> jhodapp: utopic 24 has been last build two weeks ago
<jhodapp> Mirv, yeah, ogra_ informed me about the situation...I'll just wait until v opens up
<ogra_> veebers, do you have thomi somewhere around so he could quickly do that ?
<Mirv> jhodapp: right, that's what I was going to say next :)
<jhodapp> Mirv, thanks :)
<veebers> ogra_: thomis not beside me :-\ Who has perms to approve that MP?
<ogra_> veebers, seems "autopilot hackers" owns that branch
<veebers> ogra_: oh wait, is it just the autopilot MP? I get confused as it says dbus-propery-
<veebers> ogra_: this one right? https://code.launchpad.net/~veebers/autopilot/1.5-fixing-packaging-image-removal/+merge/239192
<ogra_> yep
<ogra_> just needs top approval
<veebers> ogra_: sorry about that :-P Yeah it's top approved now
<ogra_> thanks
<veebers> I thought that it was a branch against dbus-property-service
<ogra_> nah
<ogra_> that package just ships the removed file now so it needs to go in alongside
<veebers> Ahhhh I understand now
<veebers> ogra_: do I need to do anything else for this before I go offline for dinner?
<ogra_> no, just go, i'm working on it
<veebers> ogra_: awesome, thank you for that
<ogra_> phew ... done
<ogra_> aaand ubuntu-touch-meta copied too
<ogra_> and on that note ...
 * ogra_ goes to find dinner
<ogra_> sil2100, ^^^
<sil2100> \o/
<sil2100> Those are still migrating, right?
<ogra_> 123 will have the changes so we can look tomorrow (its only 3h til the cron build starts anyway)
<sil2100> ogra_: will you kick a new image once those do? (after dinner ;) )
<sil2100> Ah
<sil2100> Right, different TZ
<ogra_> :)
<sil2100> I keep forgetting that..
<ogra_> haha, me too
<ogra_> anyway, all in ... cross your fingers
<ogra_> off to the bar :)
 * ogra_ waves
<robru> nooo
<robru> we gave that one up
#ubuntu-ci-eng 2014-10-23
<imgbot> === trainguards: IMAGE 297 building (started: 20141023 02:05) ===
<imgbot> === trainguards: RTM IMAGE 123 building (started: 20141023 03:05) ===
<imgbot> === trainguards: IMAGE 297 DONE (finished: 20141023 03:25) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/297.changes ===
<imgbot> === trainguards: RTM IMAGE 123 DONE (finished: 20141023 04:15) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/123.changes ===
<ogra_> YIPPPIE !!!
<ogra_> the dashboard for 123 looks just AWESOME !
 * ogra_ dances
<ogra_> and we shoved off 30MB from the rootfs tarball
<veebers> ogra_: sounds like the autopilot removal went well
<ogra_> yeah, there are a few more failures ...
<ogra_> but not significantly more
<veebers> ogra_: Right, that sounds like test issues themselves not deps etc.
<ogra_> yep
<sil2100> ogra_:
<sil2100> ogra_: \o/
<sil2100> ogra_: and the test results don't look so bad
<sil2100> There was a new toolkit in this image so that can also be the cause of some
<ogra_> sil2100, yeah
<ogra_> mvo, http://dashboard.ubuntu-ci:8080/smokeng/utopic/touch_stable/krillin/123:20141023:20141015-32e0f27/618/click_image_tests/ ...
<ogra_> (click on "testcase_test" to see some details or on consoleLog for a full log
<pete-woods> trainguards: hi guys! could I get RTM silo 019 reconfigured? it has an extra project in it now (and a bunch more bugs associated)
<dobey> ToyKeeper: hi. are you testing landing-005 unity-scope-click? i see it's still "under testing" on the board
<ToyKeeper> dobey: It wasn't really supposed to be in that lane overnight, but yes, I'm about to start on it again.
<Mirv> pete-woods: sure
<dobey> ToyKeeper: ok, thanks
<pete-woods> Mirv: thanks :_
<pete-woods> :)
<brendand> ogra_, moo
<ToyKeeper> kenvandine: I see two silos from you for the same package.  Does one include the changes from the other?  Are they divergent branches?  Can one be removed?
<kenvandine> ToyKeeper, 14 includes 13
<lool> mandel: ^ hey, I've requested an utopic silo for ubuntu-download-manager even if I dont fully understand where the utopic landing go (I guess bzr only? or -proposed for -updates?); I've never landed ubuntu-download-manager though, would one have to run the full test plan I've linked to?
<lool> the test plan is big, I wonder whether we should group landing of d-m
<jdstrand> olli: hey, we've identified 3 security updates that should go to rtm. my thinking is this: we file 3 bugs (one for each), mark then critical with rtm tag. I then request 3 rtm silos (again, one for each) and then we upload to them, test and publish. does this sound reasonable?
<jdstrand> olli: also, should I be pinging you for all of this all of the time? :)
<jdstrand> I always seem to feel like I have exceptional cases...
<ogra_> brendand, baaa
<brendand> ogra_, the ap silo doesn't need our sign-off, that's ok
<ogra_> lol
<ogra_> brendand, that landed long ago, but thanks :P
<ToyKeeper> kenvandine: Thanks, it looks like we can just land 14 and ignore 13 (unless something specific to 14 fails).
<kenvandine> ToyKeeper, cool, thanks
<kenvandine> 13 was super low risk, 14 should be fine too but not trivial like 13
<olli> jdstrand, yes re 3 sep bugs/silos
<olli> jdstrand, I think it makes sense to escalate security updates, not to impose control but to assure they don't get blocked
<sil2100> ogra_: so I had a chat with the music-app devs just a few moments ago
<sil2100> ogra_: they have been informed and will try to reproduce and fix, but they knew that there was something bad happening
<sil2100> plars: hey! :)
<ogra_> sil2100, awesome !
<plars> sil2100: hi
<sil2100> plars: do you know why we don't have full test results for mako on ubuntu-rtm? Is it that badly broken?
<ahayzen> sil2100, we've just reproduced so we can see what 'bad things' are happening :)
<jdstrand> olli: ok, in process of doing the bugs/siloing. how does the escalation process work, what I just did?
<ahayzen> sil2100, i'll update you if we make any progress
<sil2100> ahayzen: awesome :)
<plars> sil2100: let me look
<plars> sil2100: strange, it was split between 3 jobs running in parallel, one got as far as the usual looping test case on dropping letters:
<plars> 13:21:21.430 DEBUG dbus:352 - Selecting objects of type QQuickRectangle with attributes: {'objectName': 'gametilebox'}
<plars> sil2100: but the other 2 failed to even come up in bootloader mode, so they didn't get installed. I'm retrying them now and will watch them carefully
<sil2100> Ouch
<sil2100> plars: thanks!
<pete-woods> trainguards: hi folks. could I get another reconfigure of silo 019? (added another MR to it, but no new projects this time)
<pete-woods> (that's RTM)
<sil2100> pete-woods: sure, doing
<pete-woods> :)
<olli> jdstrand, sort of, got the 3 bug ids?
<pete-woods> woo!
<abeato> brendand, hey, I already tested silo 16, which solves https://bugs.launchpad.net/barajas/+bug/1356330
<ubot5> Error: ubuntu bug 1356330 not found
<abeato> brendand, I need now QA signoff
<brendand> abeato, just waiting for it to arrive in our queue
<abeato> brendand, ack
<brendand> abeato, it should get picked up soon, i'll let you know
<abeato> brendand, great, thanks
<jdstrand> olli: yes. nss - 1384718, apt - 1384720, bash - 1384721
<jdstrand> bug 1384718, bug 1384720, bug 1384721
<ubot5> bug 1384718 in nss (Ubuntu RTM) "Update to 3.17.1 to fix security issues and update certs" [Undecided,New] https://launchpad.net/bugs/1384718
<ubot5> bug 1384720 in apt (Ubuntu RTM) "Update apt to 1.0.9.2ubuntu2 to fix security issues" [Undecided,New] https://launchpad.net/bugs/1384720
<ubot5> bug 1384721 in bash (Ubuntu RTM) "Update bash to 4.3-11ubuntu1 to fix shellshock" [Undecided,New] https://launchpad.net/bugs/1384721
<ToyKeeper> kenvandine: I got a chance to look at the details for silos 13+14, and the bugs fixed in 13 aren't on olli's landing whitelist.
<kenvandine> ToyKeeper, pat said he OK'd them
<ToyKeeper> kenvandine: This means you'll either need to build 14 minus the changes in 13, or get special approval.
<ToyKeeper> kenvandine: patmcgowan approved it?
<kenvandine> yes
<kenvandine> ToyKeeper, i have an email from him to confirm it
<jdstrand> olli: also, I have an approved silo, but I didn't actually get an answer from the PM team on bug 1384349. did it show up on your list yesterday? if not, what should I be doing differently so I stop bothering you?
<ubot5> bug 1384349 in apparmor-easyprof-ubuntu (Ubuntu RTM) "apparmor denies app-specific download directory" [Critical,New] https://launchpad.net/bugs/1384349
<ToyKeeper> kenvandine: I think we can probably move ahead with it, just had to check.
<kenvandine> ToyKeeper, thanks
<olli> ToyKeeper, kenvandine which bug is that
<kenvandine> olli, 1376286 1382416 1377929 and 1383836
<kenvandine> all trivial and no risk fixes that were nice to get in
<ToyKeeper> kenvandine: Wait, four of them?  I thought there were only two plus a crit.
<kenvandine> pmcgowan, good timing :)
<kenvandine> ToyKeeper, well it's 4 bug fixes, one was just a translators comment
<kenvandine> and another one got rid of a gvariant warning
<kenvandine> nothing to test there
<kenvandine> i thought all the bug numbers were on there though
<pmcgowan> kenvandine, yes we blessed those 4 for landing
<ToyKeeper> pmcgowan: Thanks, wasn't sure since they weren't on the last whitelist I received for today's milestone.
<pmcgowan> ToyKeeper, they should be there, and if they have rtm14 with a touch-date tag they are good
<rsalveti> robru: sil2100: line 32 is not reflecting the proper status
<Chipaca> can i pester somebody for a silo for line 93?
<Chipaca> yes, please :)
 * Chipaca should learn manners from the bot
<sil2100> rsalveti: looking
<sil2100> rsalveti: yeah, google (or someone) ate teh formula for it
<sil2100> Restored
<rsalveti> sil2100: cool, thanks
<sil2100> Actually, it even ate 2 formulas
<rsalveti> cjwatson: hey, I'm getting file:///usr/share/unity8/Shell.qml:21:1: plugin cannot be loaded for module "Unity.Application": Cannot load library /usr/lib/i386-linux-gnu/qt5/qml/Unity/Application/libunityapplicationplugin.so: (dlopen: cannot load any more object with static TLS)
<rsalveti> on RTM
<rsalveti> cjwatson: do you remember what was the fix you had for utopic?
<rsalveti> we might need to mirror that into RTM
<cjwatson> rsalveti: yeah, you probably will.  copy https://launchpad.net/ubuntu/+source/glibc/2.19-10ubuntu2 in with binaries
<cjwatson> (no point rebuilding it, it's not as if there's a userspace ABI below glibc that it might be incompatible with)
<rsalveti> cjwatson: great
<olli> ToyKeeper, sil2100 I updated https://docs.google.com/a/canonical.com/spreadsheets/d/1vtSSJZTIVEki9WsxTH_UxbE_PhdsEJl3Z0mn-UyDat0/edit#gid=0
<Chipaca> trainguards?
<Mirv> Chipaca?
<Chipaca> Mirv: hi!
<Chipaca> Mirv: i asked for a silo a few minutes back, am i being too impatient? :-/
<Mirv> Chipaca: no, no, feel free to ping, most of our irc clients do not notice the queuebot's pings anyway, and I don't see a queuebot reacting to your new line anyway
<Chipaca> Mirv: -queuebot/#ubuntu-ci-eng- trainguards, please assign line 93 for Chipaca
<Mirv> Chipaca: oh, right, there it is.
<Mirv> Chipaca: rtm-012
<Chipaca> Mirv: thanks
<sil2100> When sprinting it's hard to keep track of IRC when you're moving or in meetings ;)
<sil2100> So please feel free to ping when you see you're not getting the proper service
<Mirv> yes, less time spent looking at the scrollback
<mandel> davmor2, hi! can uou please take a look at the silo 24 for rtm? is a fix for location service to deal with a race condition in the license acceptance
<mandel> davmor2, it does not fix all the bugs that we have but it does remove that issue
<brendand> abeato, your card didn't appear yet did you mark it as testing passed?
<abeato> brendand, yes
<abeato> brendand, line 32 in the spreadsheet
<abeato> brendand, ah, not marked as QA sign-off required
<abeato> brendand, we had a problem with the silo and moved the changes, so that messed things a bit
<abeato> marked as QA aign-off required
<rsalveti> sil2100: ogra_: I need to sync latest glibc from utopic into RTM in order to get emulator working again for RTM, and the change is minimal: https://launchpadlibrarian.net/186134877/glibc_2.19-10ubuntu1_2.19-10ubuntu2.diff.gz
<rsalveti> sil2100: what is the process to follow in this case?
<rsalveti> sil2100: get a silo, ask sign off and etc, or just copy them over?
<ogra_> rsalveti, lol, thats quite some comment for such a small change
<sil2100> rsalveti: let's make product management and QA aware of this
<cjwatson> this is a bit of a facepalm for me, I remember pondering at the time whether we should preemptively sync it into RTM
<rsalveti> ogra_: because it's a workaround
 * ogra_ would just sync after asking QA for approval 
<cjwatson> because there wasn't a single obvious change that triggered the problem, we just tripped over a limit
<sil2100> rsalveti: normally I would just upload it directly, but I know QA doesn't like when that's happening for components that are used by so many other things
<sil2100> rsalveti: so I would opt for the silo way
<sil2100> davmor2, brendand, elopio, ToyKeeper: ^
<rsalveti> right, we all think and know it's safe enough, but I don't want to get managers calling me names later on :-)
<sil2100> rsalveti: exactly ;p
<ToyKeeper> olli: Thanks, I'll use that spreadsheet to check bugs against.
<sil2100> rsalveti: anyway, if you can then prepare a landing for this and we can get it assigned
<rsalveti> sil2100: done, silo 25
<sil2100> olli: do we get permission to sync latest glibc to ubuntu-rtm?
<sil2100> olli: it's to fix the emulator, which IMO is pretty critical
<olli> asac, ^
<ToyKeeper> glibc?  ... if that's going to need testing, I'd be happy to volunteer someone *else* to test it.  ;P
<brendand> rsalveti, cjwatson - can you confirm whether the affected component is even used on devices?
<brendand> rsalveti, cjwatson - it reads to me like it's not, but i'm not 100% sure
<cjwatson> brendand: glibc?  hahahahaha
<rsalveti> brendand: it's used everywhere (libc), but the change is minimal and just a bump into the TLS slots
<cjwatson> brendand: glibc is the system's fundamental C library
<rsalveti> but if you want to test what it affects, that's basically everything
<rsalveti> :-)
<asac> sil2100: how can we assess the impact?
<asac> rsalveti: ?
<brendand> rsalveti, what testing have you done?
<ogra_> asac, well ... if the system still runs it is good :)
<asac> ogra_: sil2100: can it be backed out?
 * ogra_ doubts you can really assess it
<ogra_> indeed, we could roll back worst case
<asac> in case it goes havoc?
<asac> easily?
<rsalveti> https://launchpadlibrarian.net/186134877/glibc_2.19-10ubuntu1_2.19-10ubuntu2.diff.gz
<ogra_> iits just a number in a variable
<rsalveti> see the diff, it's just bumping the amount of TLS slots
<ogra_> tiny enough to back out if needed
<bfiller> sil2100: could you reconfigure rtm silo 11 please? I added a new package
<rsalveti> brendand: tested with the emulator and with the device
<ToyKeeper> Whenever I see "glibc update", I suddenly feel like calling in sick.  ;P
<rsalveti> opened apps, used the system, no issues
<asac> rsalveti: with this, will emulator work flawlessly?
<rsalveti> asac: it'll boot
<asac> e.g. whats the gain we get from it?>
<rsalveti> asac: emulator is completely broken on RTM
<ogra_> asac, a working emulator
<asac> rsalveti: what broke it?
<rsalveti> asac: we started having more processes using TLS slots
<rsalveti> then we got into glibc's limit
<rsalveti> probably caused by our graphic stack
<asac> rsalveti: do we leak threads?
<rsalveti> asac: it's not leak
<rsalveti> asac: read the diff
<rsalveti> asac: https://launchpadlibrarian.net/186134877/glibc_2.19-10ubuntu1_2.19-10ubuntu2.diff.gz
<brendand> rsalveti, which part of the graphics stack?
<ogra_> brendand, qtmir
<rsalveti> brendand: mir and qt
<asac> rsalveti: well i understand waht the patch does
<asac> rsalveti: i wonder why we hit that bound in our stack suddenly
<brendand> rsalveti, the diff calls out X11 and Mesa
<asac> rsalveti: which component consumes so many TLS slots
<asac> and if we checked that thats the expected behaviour of that component
<rsalveti> not sure which component started doing that, could be caused by base changes on other packages, mir, qtmir, qt
<rsalveti> hard to know
<asac> rsalveti: isnt this a per process limit?
<asac> if so we should see which process isnt getting enough slots
<cjwatson> asac: I tried to track down the precise cause at the time and failed, but I'm nevertheless confident that it's the proper fix
<cjwatson> I believe it is a system-wide limit
<cjwatson> so it's extremely difficult to track down, but the landing of this glibc change in utopic was a non-event
<rsalveti> asac: this happens when loading all the libraries, and in this case, this was the one that gave the error (when starting unity8):
<rsalveti> file:///usr/share/unity8/Shell.qml:21:1: plugin cannot be loaded for module "Unity.Application": Cannot load library /usr/lib/i386-linux-gnu/qt5/qml/Unity/Application/libunityapplicationplugin.so: (dlopen: cannot load any more object with static TLS)
<ogra_> brendand, also python ... they are just examples ... in fact everything using TLS could be added there
<asac> ok. for the record i think its fine. just thought maybe we see a bug here that we might want to also nail while we see it (like mir leaking threads that consume more and more slots)
<cjwatson> and yes, we can trivially back this out if it fails
<cjwatson> absolutely trivially
<cjwatson> copy the old version back in
<ogra_> yeah
<cjwatson> it would be the responsible thing to do to try it out in a silo of course
<cjwatson> but it will be fine
<cjwatson> well, in a silo or by just installing the packages directly from utopic, whatever
<asac> cjwatson: does infinity know if this is per-process or system wide? if it system wide i am fully +1; otherwise would be nice to talk to the compnent owner that does it
<ogra_> we can build an image to have it isolated to test
<asac> but still +1
<asac> olli: ^
<ogra_> if that makes feel people better
<asac> yeah, so i am sure brendand will test the silo
<cjwatson> asac: my understanding from the Fedora bug was that it is system-wide, but I'm checking
<rsalveti> it's static TLS when loading the libs, you can track down by each lib
<rsalveti> and see who actually is using more now
<brendand> asac, we can give the silo a quick test
<rsalveti> but hard to track as it could be a change in cpp related components
<rsalveti> and not sure how worthy is it
<asac> rsalveti: do we know when this started?
<rsalveti> asac: I think it started with a new qtmir upload, but I didn't track that down in details
<asac> rsalveti: when was that? who did that upload?
<rsalveti> asac: it's not necessarily something that started and used by qtmir itself
<asac> i guess lets land and file a bug for qtmir to give us a story what is going on
<rsalveti> not sure if boost could affect that or whatever
<asac> hmm
<cjwatson> I don't think it's reasonable to try to pin this down to a specific process
<cjwatson> working around it will be worse than just bumping the limit in glibc
<cjwatson> in this case
<rsalveti> yeah
<rsalveti> it might be a quite complicated fix
<cjwatson> https://sourceware.org/ml/libc-alpha/2014-10/msg00134.html has more technical details, and it is too complicated for me
<ubot5> sourceware.org bug 2014 in translator "cannot use backslash for escape sequences" [Normal,Resolved: fixed]
<Chipaca> davmor2: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-012/+packages
<cjwatson> thank you ubot5 go away
<asac> ok, well. as i said I am +1 on landing this in all cases
<asac> just wonder if its worth spinning a foloow up effort to get us a good explain
<cjwatson> we *think* it is a per-process limit but it's hard to tell for sure
<cjwatson> I'm not sure we have company-internal expertise on this ...
<cjwatson> I acknowledged at the time that I was cargo-culting from Fedora :)
<rsalveti> :-)
<rsalveti> anyway, silo is ready to be tested
<rsalveti> sil2100: ^^
<rsalveti> silo 25
<cjwatson> the upstream glibc discussion goes into suggestions of better fixes involving TLS Descriptors
<cjwatson> again I'm afraid it quickly gets into territory I'm not familiar with though
<asac> cjwatson: rsalveti: is there a bug that we should approve to follow process?
<asac> talking to olli
<brendand> abeato, https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1378397 did not get approval for landing this week
<ubot5> Ubuntu bug 1378397 in gst-plugins-base1.0 (Ubuntu) " video thumbnails are not generated for some divx files " [High,Confirmed]
<cjwatson> asac: originally was bug 1375555
<asac> rsalveti: who owns qtmir?
<ubot5> bug 1375555 in glibc (Ubuntu) "global static TLS slot limit breaks the x86 emulator" [Critical,Fix released] https://launchpad.net/bugs/1375555
<rsalveti> asac: yes, we can have a bugtask for RTM
<abeato> brendand, it was on the list
<asac> ok thats fine
<rsalveti> asac: kgunn
<abeato> the one in the email
<asac> kgunn: around?
<abeato> brendand, 10/23 planning
<rsalveti> olli: asac: there's a bug task for RTM in there (bug 1375555)
<ubot5> bug 1375555 in glibc (Ubuntu RTM) "global static TLS slot limit breaks the x86 emulator" [Critical,Confirmed] https://launchpad.net/bugs/1375555
<abeato> brendand, it is actually https://bugs.launchpad.net/ubuntu/+source/mediaplayer-app/+bug/1355095
<ubot5> Ubuntu bug 1355095 in Media Hub "mediaplayer hangs on fast-forward" [Critical,Triaged]
<asac> rsalveti: brendand: please start testing silo; we want to brief victor on this before hitting publish
<asac> but think there wont be an issue
<rsalveti> yup
<asac> rsalveti: and yes, please add an RTM task
<brendand> abeato, well you can help speed things up by mentioning the right bug *somewhere* in the silo (description, changelog, anywhere)
<brendand> abeato, thanks for clarifying though
<abeato> brendand, sorry, it is a bit messy because there are replicated bugs in barajas
<kgunn> asac: rsalveti qtmir, yep...what's needed?
<rsalveti> kgunn: read bug 1375555
<ubot5> bug 1375555 in glibc (Ubuntu RTM) "global static TLS slot limit breaks the x86 emulator" [Critical,Confirmed] https://launchpad.net/bugs/1375555
<rsalveti> kgunn: one qtmir update started to use more tls static slots
<rsalveti> might be caused by an update on some other components, optimizations, or cpp/boost related
<rsalveti> static slots for graphic is used everywhere for optimizations
<asac> kgunn: check the last comment in bug https://launchpad.net/bugs/1375555
<ubot5> Ubuntu bug 1375555 in glibc (Ubuntu RTM) "global static TLS slot limit breaks the x86 emulator" [Critical,Confirmed]
<asac> kgunn: scared that we see symptoms of something that we can't explain vs. can explain
<asac> cant explain might mean we have a bug like a threads leaking etc.
<rsalveti> this is not threads leaking
<asac> ok :)
<asac> but not sure :)... really just trying to see if there is something really in it that we are now covering with the libc patch
<asac> kgunn: guess rsalveti is better to tell you what this is about
<cjwatson> it's not threads leaking, I think it's more like more things using dlopen
<cjwatson> as far as I remember from looking at this last, this could be triggered by an object of the right kind (handwave) having an extra dlopen call
<rsalveti> cjwatson: iirc the static slots are allocated when loading the library
<cjwatson> or rather, loading an extra library with dlopen
<kgunn> josharenson: ^
<cjwatson> I'm guessing a bit, just saying I really don't think it's anything of the nature of a leak
<asac> kgunn: josharenson: bug was reported end of september ... not sure what happened then
<rsalveti> yeah
<cjwatson> it's more analogous to the structure of the object code
<cjwatson> asac: at the time I checked RTM and the problem wasn't present there
<cjwatson> presumably something that propagated in since then
<rsalveti> probably with qtmir as well
<cjwatson> the Fedora bug is more useful reading here
<cjwatson> though read it all the way through if you're going to read any of it since it goes through a fair bit of diagnosis
<ChickenCutlass> there are many things that could  cause the use of more TLS slots.  Even something using more boost code.
<cjwatson> https://bugzilla.redhat.com/show_bug.cgi?id=1124987
<asac> yeah; i think IF this is really a qtmir caused symptom then qtmir folks are best to know what happened since then
<asac> and can make sense out of it
<asac> kgunn: josharenson: ^
<kgunn> asac: right, to me it's simply a double check of is this what we expected
<kgunn> give us some time
<asac> kgunn: yeah for me this is just a post-process thingy... won't block the landing because of that investigation
<asac> kgunn: as long as it happens its fine
<asac> think we are aligned
<Mirv> mdeslaur: ^
<jdstrand> I wonder why mdeslaur is listed as the lander for bash
<jdstrand> isn't*
<mdeslaur> thanks
<robru> jdstrand: because cell b93 is left blank
<brendand> abeato, my krillin is totally stuck
<abeato> brendand, :/
<brendand> abeato, and unity 8 just rebooted
<olli> asac, cjwatson, so victor is a bit concerned about that change
<abeato> brendand, ah... it actually took a lot of time for me to get unity 8 after flashing this morning
<abeato> no idea way
<olli> asking whether we have something similar to a device tarball for the emulator
<jdstrand> robru: weird, I see it as filled in hear
<olli> rsalveti, ^
<jdstrand> here
<jdstrand> weird typo
 * jdstrand updates the cell
<rsalveti> olli: yes we have, but that can contain any change related with glibc
<robru> jdstrand: must be some sync glitch in the spreadsheet then
<jdstrand> robru: well, or network. the spreadsheet was stuck on 'Working' for quite a while
<robru> Yeah
<rsalveti> because this is a core part of the rootfs
<jdstrand> robru: I removed a letter then added it back and pressed 'Enter'. hopefully it is there now
<olli> rsalveti, "can't contain" then
<olli> makes sense
<rsalveti> olli: ask him to read the bug and patch
<ToyKeeper> kenvandine_: Silo rtm-014 appears to fix all four low-priority bugs, but does *not* seem to fix the launcher reset bug.  It still has the "needs a reboot" text and doesn't update until after a reboot.
<kenvandine_> ToyKeeper, that's what is expected now
<robru> jdstrand: doesn't look like it worked, but i put the name in and reconfigured for you, try reloading the page i guess
<kenvandine_> ToyKeeper, it's only part of the bug fix
<kenvandine_> without it, it doesn't reset the launcher at all now
<ToyKeeper> kenvandine_: Is there any change in behavior at all yet?
<jdstrand> weird
<jdstrand> robru: thanks
<kenvandine_> ToyKeeper, there is a unity8 landing that fixes the other
<robru> jdstrand: you're welcome!
<kenvandine_> ToyKeeper, nope... just fixes resetting the launcher
<ToyKeeper> kenvandine_: Okay.  So, it *does* reset the launcher after a reboot with rtm-014 installed, and it doesn't appear to break anything.
<kenvandine_> ToyKeeper, once the unity8 fix lands, we can land another branch that removes the reboot text
<kenvandine_> ToyKeeper, great... it's broken without it :)
<ToyKeeper> kenvandine_: Okay, that wasn't clear, I thought this included the complete fix for bug 1376707.
<ubot5> bug 1376707 in unity8 (Ubuntu RTM) "Launcher needs to dynamically respond to reset" [Critical,In progress] https://launchpad.net/bugs/1376707
<kenvandine_> ToyKeeper, sorry about that, it still matched the test plan
<kenvandine_> i'll update the test plan when we are landing the reboot text change
<brendand> abeato, second try to launch the video - mediaplayer hanging again
<brendand> abeato, pegging the cpu
<abeato> brendand, which video are you trying?
<brendand> abeato, the one in the bug
<brendand> abeato, now it plays but that was twice it failed badly
<robru> kenvandine_: ^ I assume you're publishing 14 but i can if you're busy/not around
<kenvandine_> robru, i got it
<robru> cool
<bfiller> robru: could you please rconfigure silo 11 for rtm (line 19) as we added a new package
<robru> sure
<abeato> brendand, when doing fast forward?
<brendand> abeato, no just when loading the video
<brendand> abeato, the first time unity8 rebooted
<brendand> abeato, the second time the video never started to play
<robru> bfiller: done
<brendand> abeato, i'll see how reproducible it is
<kgunn> trainguards: can i get a silo for row 95
<abeato> brendand, ok, I'm trying too
<Mirv> kgunn: sure
<brendand> abeato, and now the video stopped playing
<brendand> and media hub is pegging the cpu
<Mirv> kgunn: although, no MP:s in tehre or anything
<bfiller> robru: thanks
<robru> bfiller: you're welcome
<robru> Mirv: heh I just noticed that too ;-)
<Mirv> robru: morning! :)
<Mirv> it's lunch time here
<robru> Mirv: hello!
<brendand> abeato, i don't think this is okay
<mdeslaur> I just got this trying to upload to a silo: Rejected: Signer has no upload rights to this PPA.
<brendand> abeato, i haven't succesfully played the video for more than 5 minutes yet
<jdstrand> fyi, I've been the primary lander for the security team, but am training mdeslaur now
<cjwatson> mdeslaur: asac or slangasek will need to add you to ~ci-train-ppa-service
<jdstrand> mdeslaur should be on the team so he can (also) provide security updates via the citrain mechanism
<slangasek> cjwatson, jdstrand, mdeslaur, asac: done
<mdeslaur> slangasek: thanks
<sil2100> olli, rsalveti: so what's the final decision on the glibc change?
<sil2100> Is it good to land in the end?
<rsalveti> waiting managers to give a +1
<ogra_> they really need to stop slacking
<sil2100> So I proceed to grab some lunch then
<ogra_> ... managers...
<olli> sil2100, still discussing
<ogra_> :)
<olli> ogra_, ;)
<olli> I think the big q atm is... what happens if we don't fix it... and what do we gain from fixing in OTA-1
<ogra_> olli, if we dont fix it we dont have an emulator
<ogra_> the current emulator images do not boot
<olli> ogra_, is there any risk deploying the patch via OTA vs in the image
<kgunn> trainguards: ok, how about a some mp's to go in that silo i was asking for .... row 95
<ogra_> olli, OTA *is* "in the image"
<ogra_> you cant see them distinct
<olli> ogra_, I was trying to distinguish between shipping a glibc via air/update vs an image that goes to the factory
<olli> not sure there is a difference
<ogra_> olli, if you mean deplying it *later* ... well, that would mean having the emulator broken longer
<olli> ogra_, OTA-1 is kind of a 0-day SRU
<olli> i.e. the intention is to have OTA-1 live when the first customer opens the phone
<ogra_> right, but OTA is also and image we build ... it is just a later one
<olli> sure
<olli> just making sure
<olli> ogra_, so, it's "just" the emulator
<ogra_> depends how long we want to block app developers that do not have devices
<olli> the phone itself is not affected as far as we know today
<ogra_> (like the maintainer of our only ebook reader in the store)
<ogra_> olli, the change is tiny enough to immediately roll it back (it is just bumping a value of a variable to a higher threshold) ... and it would also not be a problem to build a separate image with only the change in it to asess the imapct
<jgdx> haaalp
<jgdx> are mako jenkins runs unstable? http://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-ci/1684/ e.g.
<plars> ogra_: for image 104 on mako, it appears all 3 runs are stuck - ubuntuuitoolkit, reminders, and dropping letters (all things we've seen it get stuck on before though)
<ogra_> plars, well, dropping letters isnt even there
<ogra_> so we should just throw the test out
<plars> ogra_: apparently it is on mako?
<ogra_> thats weird
<plars> oh no
<plars> maybe not
<plars> that could be another one it's stuck on
<ogra_> yeah, trow oout the test
<ogra_> *throw
<ogra_> not sure what to do about uitk, i think ricmm's fix will help with that though
<plars> strange, it is dropping letters but somehow it tries to run the test anyway? That makes no sense
<popey> plars: just updated that flo from #96 to #98 and now it boots to black screen... expected?
<popey> plars: binder_2 at 100%cpu
<plars> popey: I didn't do anything with the image on it
<robru> rsalveti: hey, what happened with media-hub in silo 8? ursinha fixed that bug, do you want to publish that silo? or did you manually copy it or something? lemme know so I can free that silo up
<plars> popey: all I did was power it on and off a few times to test how long the buttons needed to be held
<rsalveti> robru: manually landed it (I think I added a comment in there)
<plars> popey: we have an instrumented flo in the lab now, and I just needed timings for forcing it to power off and enter fastboot
<robru> rsalveti: so there's no branch to merge? i can just free that?
<rsalveti> robru: merged by hand
<cjwatson> FYI there'll probably be one more utopic publisher run after the current one and then we're done
<ogra_> \o/
<plars> popey: in ci, 98 seemed to get through quite a lot of the tests though, I'd suspect your battery which seemed to be consistently dead
<cjwatson> so not trying to publish anything would be good to prevent us getting hideously confused
<cjwatson> I'll stop proposed-migration
<robru> rsalveti: cool thanks (and sorry)
<cjwatson> Well, after one more run
<cjwatson> (to make sure it's zero)
<ogra_> olli, bug 1384841
<ubot5> bug 1384841 in tzdata (Ubuntu RTM) "Need to sync tzdata into RTM before final image goes out" [Critical,Triaged] https://launchpad.net/bugs/1384841
<ogra_> olli, already added it to the whishlist (line 56)
<olli> ogra_, thx
<Mirv> tvoss: rtm-013
<Mirv> for line 99
<tvoss> Mirv, thanks
<nik90> Mirv, sil2100: Can we please get the follow bugs marked as critical for RTM please? -> https://code.launchpad.net/~charlesk/indicator-datetime/lp-1317861-handle-trigger-valarms-in-ical
<nik90> Mirv, sil2100: In particular this bug https://bugs.launchpad.net/indicator-datetime/+bug/1362341 is very important for the clock app
<ubot5> Ubuntu bug 1362341 in Indicator Date and Time "OneTime alarms are not automatically dismissed or delete after they are triggered" [High,In progress]
<ToyKeeper> olli: Still waiting on a decision about the glibc update.  Sounds like it's fairly low risk but also may require a full image test.
<popey> plars: nah, it's booted, i can adb shell in
<olli> ToyKeeper, I was told by victor that he was convinced by ogra_ & others to do it
<olli> ogra_, is that your understanding
<sil2100> \o/
 * popey re-flashes
<Mirv> nik90: hey! the 1317861 seems already handled - the same branch fixes eg. https://bugs.launchpad.net/indicator-datetime/+bug/1362341 which is already targeted
<ubot5> Ubuntu bug 1362341 in Indicator Date and Time "OneTime alarms are not automatically dismissed or delete after they are triggered" [High,In progress]
<Mirv> nik90: oh, hey, that was that latter bug of yours :D so, yes, they are already targeted AFAIK
<Mirv> or hmm
<nik90> Mirv: are you sure it is approved since charles just informed that it needs to be marked critical before it can land in the rtm images
<nik90> Mirv: either way that branch is super critical to the alarm feature and as such definitely needs to land.
<Mirv> nik90: just a moment
<Mirv> nik90: so yes, let me add to the wishlist spreadsheet we have.
<nik90> Mirv: awesome thnx
<Mirv> it has the tags, but it needs product team to comment on one of the bugs the branch fixes
<Mirv> since the tags were added by charles
<nik90> exactly
<nik90> we need the approval for those bugs
<charles> Mirv, ty for putting it on the wishlist
<sil2100> That's why I preferred the LP project approach
<sil2100> Then it would be instantly clear if an issue is accepted or not
<Mirv> charles: nik90: I referred to 1361702 primarily and mentioned 1320880 + 1362341 being fixed by the same branch.
<Mirv> so I'd expect some sort of comment eventually at 1361702
<alecu> trainguards: hi! may I ask for silo for row 73?
<robru> alecu: looking
<nik90> Mirv: ack. I will keep an eye on it
<bfiller> fginther, Ursinha : here is an MR that shows an example: https://code.launchpad.net/~osomon/webbrowser-app/hsbc-br-ua-override/+merge/238270
<robru> alecu: so it's a bit late to release anything for utopic ;-) I guess you need to wait for vivid
<bfiller> fginther: each run of jenkins shows different results without code changing
<robru> alecu: happy to assign an rtm silo however if you need anything there
<alecu> robru: good point :P It's a sync from rtm, so, should I keep landing stuff directly to rtm and then ask for a sync once vivid opens?
<popey> plars: re-flashed flo and its okay now
<robru> alecu: yeah that sounds like a plan.
<ogra_> olli, yes
<alecu> awesome, thanks.
<ogra_> (sorry, was afk)
<plars> popey: strange
<ogra_> ToyKeeper, preferably we should build one image now, stop landings temporary, sync glibc and build an image just for this, then you can test just with this change ... if it shows any issues we can revert and the nighly build will have the reversion
<ogra_> olli, ^^^
<ogra_> sil2100, ^^^
<robru> mdeslaur: oh sorry i didn't realize you had publish rights in the train. looks like we both his publish at the same time
<mdeslaur> robru: ah! I see...whoops, I just hit it again also :P
<robru> mdeslaur: disregard the error message, it's publishing
<mdeslaur> cool, thanks robru
<robru> mdeslaur: you're welcome!
<robru> mdeslaur: but I'll let you publish the other three when you're ready ;-)
<rvr_> ogra_, sil2100: I tested a glibc silo recently, directly with the ppa. It was a small smoke test + glibc test suite. How do you want to test this silo?
<ogra_> rvr_, well, we want to be sure to catch any regressions in apps or image behavior with it
<rvr_> ogra_: https://wiki.ubuntu.com/Process/Merges/TestPlan/glib2.0
<ogra_> rvr_, we are talking about glibc
<ogra_> ;)
<ogra_> a *slight* bit different :)
<rvr_> Oh, right, different beast
<ogra_> (since it affects everything)
<rvr_> Forget about what I told you above :P
<cjwatson> although the points made by the test plan aren't actually dreadful
<cjwatson> just expand the list of dependent packages to everything :)
<sil2100> rvr_: ;)
<sil2100> cjwatson: hah ;)
<ogra_> lol
<sil2100> Utopic released
<sil2100> \o/
<ogra_> yeah !
<ogra_> :D
<rvr_> Wee
<davmor2> WooHoo!
<cjwatson> soon we might even close the archive
 * ogra_ notices the lock and chain behind cjwatson's back 
<sil2100> robru: so, I didn't schedule an official meeting today for the sync up, but let's do it at the same hour today as well
<sil2100> robru: I'll set up a manual calendar meeting for it
<sil2100> We don't need a specific room for that, we can meet up somewhere on the couches here and just fetch you to the call
<sil2100> ogra_: ^ what do you think?
<brendand> abeato, so that video seems to be a problem
<brendand> abeato, the one mentioned in the bug
<brendand> abeato, another video i have seems to be ok
<brendand> abeato, not sure is it a regression though
<Mirv> utopic \o/
<abeato> brendand, well, it is not a regression because previously divx directly did not work at all
<abeato> in krillin
<abeato> and this change makes fast forward work for mako
<abeato> it is unfortunate that that video fails after playing for a couple of minutes :/
<abeato> I tested with the videos pointed out in https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1378397
<ubot5> Ubuntu bug 1378397 in gst-plugins-base1.0 (Ubuntu) " video thumbnails are not generated for some divx files " [High,Confirmed]
<abeato> brendand, ...but no with that Amos one
<abeato> brendand, so not really sure what to do
<abeato> I'll investigate what is happening, but this change is better than nothing
<brendand> abeato, so that video would not have worked on krillin at all?
<abeato> right
<abeato> well, actually I did test the Amos one, but did not left it playing for long
<brendand> abeato, well if it didn't play at all and there are no problems with other videos then it should be ok
<abeato> brendand, ack
<abeato> it is just a matter of opening another bug to track this
<Ursinha> sil2100: I think we need to talk anytime this week about further citrain changes :) as the spreadsheet is going away, the changes you would make would have to happen also on the engine side
<lool> sil2100: hey
<lool> sil2100: the build job to copy from ubuntu landing ppa 6 to ubuntu-rtm landing ppp 4 didn't work  :-(
<lool> sil2100: I did pass location-service as package name, but it seemed to think it was already up-to-date
<lool> sil2100: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-004-1-build/53/console
<sil2100> lool: hm, let me take a look what's up
<sil2100> Ursinha: which changes :) ?
<Ursinha> sil2100: any :)
<sil2100> lool: ah, the silo needs to be reconfigured
<sil2100> lool: it's still trying to fetch from the archive now
<sil2100> lool: let me reconfigure
<kenvandine> ogra_, the removal of autopilot from the images also removed gir1.2-ubuntu-app-launch-2, which is needed by the sdk to launch on the device
<sil2100> lool: reconfigured, try to re-run now
<ogra_> kenvandine, can you file a bug so i can re-add it then ?
<kenvandine> bug 1384877
<ubot5> bug 1384877 in Ubuntu UI Toolkit "Can't run on device since rtm image 123" [Undecided,New] https://launchpad.net/bugs/1384877
<kenvandine> bzoltan,  ^^
<lool> sil2100: thanks
<kenvandine> bzoltan, ogra_ will hook you up :)
<bzoltan> kenvandine:  it feels i bit itchy to see it assigned to the UITK ;)
<ogra_> heh
<kenvandine> bzoltan, well that's where we feel the pain :)
<ogra_> let me assign it properly and put it on "olli's list"
<bzoltan> kenvandine:  it is more at the qtcreator-plugin ubuntu not the uitk
<kenvandine> bzoltan, feel free to reassign
<bzoltan> ogra_:  thanks
<kenvandine> thanks guys
<sil2100> Ursinha: ok, for now I'm busy with formalities and commitlogish stuff, but will inform you of any changes we plan on doing ;)
<lool> sil2100: seems to have worked; thanks
<sil2100> Cheers o/
<kenvandine> ogra_, can we fix that for utopic too?
<ogra_> kenvandine, nope
<kenvandine> bummer... :/
<ogra_> well, we could try to get an SRU in
<ogra_> but that will take at least two weeks i recon
<kenvandine> i'll add a utopic task
<ogra_> i wonder why this was never explicitly seeded
<ogra_> sil2100, i'm in meetings from 16:00 to 18:00
<sil2100> Crap
<sil2100> ogra_: so I'll have a chat with you beforehand, and then just connect with robru at 16:30
<ogra_> sil2100, also we really need too make a decision how to get that glibc change in (preferably today so we can still roll back)
<sil2100> ogra_: it's in a silo, right?
<ogra_> not sure
 * ogra_ checks
<sil2100> ogra_: QA is looking into testing it from what I see
<sil2100> As per #systems on the other IRC
<ogra_> sil2100, ah, so they test from the silo then, fine
<ogra_> yeah, i see it in 025
<robru> sil2100: yes the meeting is in 1hr correct? it works for me
<Chipaca> Mirv: hiya. Could you reconfigure rtm-012 please? bundling another branch in there
<brendand> abeato, the divx video does play but it still has the same issue as before the silo
<abeato> brendand, before the silo?
<abeato> brendand, before the silo it played just a few frames
<abeato> and those frames were played because of a change in the system image that I already introduced some weeks ago
<abeato> otherwise it would simply not start playing
<brendand> abeato, it seemed to play well for me
<abeato> brendand, could you try the "Micayala Gatto" video from http://www.divx.com/en/devices/profiles/video ?
<Chipaca> robru: hiya. Could you reconfigure rtm-012 please? bundling another branch in there
<robru> Chipaca: sure but fyi if there's no new package you can reconfigure yourself with the link in the spreadsheet.
<Chipaca> robru: clicked it, and it gave me an error message so i assumed i couldn't :)
<Chipaca> there is no new package though
 * Chipaca pokes at it
<robru> Chipaca: what error message?
<robru> http400?
<Chipaca> robru: You must use POST method to trigger builds.
<robru> Chipaca: yeah that's not an error, just click post
 * Chipaca clicks
<Chipaca> robru: thanks :)
<robru> Chipaca: i never did figure out how to make that damn google spreadsheet submit POST requests. hopefully we'll be able to fix that in the new thing that replaces the spreadsheet soon
<robru> Chipaca: you're welcome!
<ToyKeeper> AlbertA: It looks like silo rtm-017 (media-hub) is on the bug whitelist now, and cleared for testing.  Do you think you might be able to create a test case for it, either in autopilot or the media-hub test plan?
<ogra_> kenvandine, olli alloed me to fast-path the re-addition of gir1.2-ubuntu-app-launch-2 ... so the SDK team can do work tomorrow ;)
<ogra_> *allowed
<kenvandine> ogra_, woot... thanks!
<Chipaca> robru: could you give me a hand with understanding that build failure?
<robru> Chipaca: looks infrastructural, I'll retry
<Chipaca> robru: http://i.imgur.com/eTic1wS.jpg
<robru> lol
<robru> cjwatson: https://launchpadlibrarian.net/188028125/buildlog_ubuntu-rtm-14.09-amd64.ubuntu-push_0.64.1%2B14.10.20141023.1~rtm-0ubuntu1_CHROOTWAIT.txt.gz any idea what's going on here?
<robru> Chipaca: retry failed with the same error. no idea
<cjwatson> robru: infinity's fixing the chroots nowish, thanks for the report
<robru> cjwatson: ah ok thx
<robru> Chipaca: ^^ just wait a bit
<cjwatson> we moved the bootstrap archive aside 'cos we don't need it for utopic any more but rather for vivid, but forgot about the reference from the 14.09 chroots
<Chipaca> robru: waiting a bit is within my competences
<robru> ugh, line 100
<robru> I remember when line 30 was a lot
<cyphermox> yeah, me too
<Ursinha> robru: why that many?
<cyphermox> cleanup badly needed of landed stuff, I think
<robru> Ursinha: partly because rtm caused a combinatorial explosion in landing requests.
<cyphermox> not that it would reduce it that much though
<robru> the thing is there are only 60 silos. so if there's 100 requests...
<cyphermox> yes
<robru> hold on to your butts, I'm gonna clear the landed requests.
<cyphermox> stuff that got dropped and/or is fully landed is still in the spreadsheet
<cyphermox> robru: perhaps we want to wait a bit to do that though...
<cyphermox> since things are working properly atm wrt the spreadsheet.
<robru> cyphermox: heh, well I'm here to clean up the fallout
<cyphermox> alright then, you decide ;)
<robru> wow, 66, that's almost reasonable. I mean it's still crazy, but that number minus the number of total silos is a small number ;-)
<AlbertA> ToyKeeper: ok I have to rebuild though....it looks like some other media-hub landings occurred and the current silo is invalid
<ogra_> cjwatson, i just did a meta upload to rtm that failed with the above issue too, do i need to manually trigger the re-build if the chroots are fixed or will it just re-try automatically ?
<ToyKeeper> AlbertA: Yes, I just noticed the same thing...  it currently won't boot with the silo installed.
<ToyKeeper> AlbertA: I think the bug only got "blessed" this morning, so it was stalled until very recently.
<AlbertA> ToyKeeper: right
<cyphermox> yay!
<cjwatson> ogra_: I'll do a mass retry
<ogra_> thx
<sil2100> robru: you ARCHIVED THE LANDINGS?! How DARE you ;)
<robru> sil2100: yes, i BANISHED them to the ABYSS!
<ogra_> cjwatson, also, you did mark the seed mature ... do we need an ubuntu-rtm seed for the next weeks ?
<ogra_> or do we just go on using this one but in mature state
<ogra_> (i doubt there will be many seed changes)
<cjwatson> ogra_: I marked utopic mature, not 14.09
<cjwatson> or rather my script did
<ogra_> hmm
<cjwatson> but you can use it in mature state, sure
<cjwatson> that's probably easier
<ogra_> we have a 14.09 seed ?
<cjwatson> no
 * ogra_ wasnt even aware
<ogra_> ah
<cjwatson> probably simplest to just continue to use utopic for the moment
<ogra_> yeah
<cjwatson> Chipaca: why the rebuild of 012?
<cjwatson> changelog looks identical
<ogra_> because there was a button to press :)
<Chipaca> cjwatson: ogra_: because the previous build failed
<cjwatson> Chipaca: ok, please stop that
<ogra_> see backlog
<cjwatson> rebuild in citrain == new source upload
<cjwatson> which is pointless, we can just retry once the LP issue is fixed
<cjwatson> new source upload wastes resources
<Chipaca> i was told to wait a bit, i waited a bit :(
<cjwatson> wait forever please
<sil2100> ;)
<cjwatson> I'll mass-retry, then we can do watch-only builds
<cjwatson> it's easier if people aren't hitting buttons in the meantime
<Chipaca> ok
<sil2100> robru: hmm, so what's the story with the cu2d jenkins bot? It didn't do CI on it yet, does the merger work?
<sil2100> (it == my new branch)
<davmor2> Chipaca: I got the ppa now but there are no packages why you break the packages ;)
<robru> sil2100: i had a branch yesterday that took 1.5 hours to run. seems it's just slow
<sil2100> Holy shit
<robru> sil2100: I mean 1.5 hours before it even started
<slangasek> mm?
<ogra_> slangasek, do you highlight on "holy shit" ?
<slangasek> no, I just have good timing
<ogra_> hah
<slangasek> so this bot is running where?
<robru> slangasek: CI runs on lp:cupstream2distro branches have been slow this week. normally they run in 15 minutes, lately it can be 1.5 hours
<robru> slangasek: s-jenkins
<Chipaca> davmor2: do you have the link?
<davmor2> Chipaca: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-012/+packages
<robru> psivaa_: when you looked at the ci job for lp:cupstream2distro the other day, did you trigger a build manually? or did it just run after a while by itself?
<cjwatson> davmor2: see scrollback, being fixed
<Chipaca> davmor2: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-012/+build/6483823
<cjwatson> davmor2: not Chipaca's fault
<Chipaca> cjwatson: *everything* is Chipaca's fault
<davmor2> cjwatson: but I enjoy blaming Chipaca ;)
<psivaa_> robru: i did it manually
<cjwatson> well yes but aside from that
<Chipaca> davmor2: find packages at this link
<robru> psivaa_: oh hrrmm... i wonder why it isn't running then? looks like sil has a branch now that it isn't running on. and no screwy prerequisite branch issue here
<Ursinha> sil2100: how busy you are tomorrow? we can try to schedule some time in the afternoon to talk :)
 * sil2100 likes vanilla merges
<psivaa_> robru: ok, let me check, could i get sil2100's branch pls?
<Chipaca> davmor2: oh, wait, you want armhf ones
<robru> psivaa_: https://code.launchpad.net/~sil2100/cupstream2distro/remove_dual_landing/+merge/239452 thanks
<Chipaca> davmor2: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-012/+build/6483822
<davmor2> Chipaca: ta
<sil2100> Ursinha: let me check the calendar
<cjwatson> sil2100,robru: I've retried all the affected builds in LP; please run watch-only builds in citrain if it should be necessary
<cjwatson> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-014/+build/6484432 seems to be doing OK so far e.g.
<robru> cjwatson: thanks
<robru> sil2100: meeting now? send me hangout link
<sil2100> Ursinha: maybe we could catch up around 2 pm tomorrow? 30 minutes should be enough
<sil2100> robru: ok, let me move to a different location
<Ursinha> sil2100: 2-2h30 is good then :) I'll add to the calendar
<sil2100> robru: https://plus.google.com/hangouts/_/canonical.com/landing-meeting
<Ursinha> sil2100, we can call robru tomorrow and have a hangout so we discuss it together
<Ursinha> robru: sil2100, ok, you are invited :)
<brendand> abeato, that Amos video definitely works without the silo. i'm trying Micalaya (first try downloading it failed)
<robru> Ursinha: thanks
<abeato> brendand, interesting
<abeato> especially taking into account that both video come from the same place
<brendand> abeato, and in fact i can't reproduce the bug jibel reported
<abeato> brendand, right, but as said that was partially solved when I did some changes on the system image
<abeato> this gstreamer changed solved additional issues with divx
<brendand> abeato, although there does appear to be some tearing
<sil2100> Ursinha: sure :) Thanks!
<Chipaca> davmor2: arm (and intel) ppa built btw
<Chipaca> davmor2: also: https://twitter.com/liamosaur/status/506975850596536320/
<kgunn> trainguards: can i get a silo reconfig on ubuntu-landing-001
<bfiller> robru: can you reconfigure line 39 please? (rtm silo 6)
<robru> kgunn: on it
<robru> bfiller: one sec
<ogra_> bzoltan, are you in any meeting atm ? or could you drop by in beverley (we are planning the developer mode for next cycle)
<ogra_> bzoltan, or send someone from your team if you cant
<bzoltan> ogra_: in a minute
<robru> kgunn: bfiller: ok you're both ready to go
<bfiller> robru: thanks
<robru> bfiller: you're welcome!
<AlbertA> trainguards: can I have rtm silo landing-017 reconfigured (sync media-hub from utopic)?
<cyphermox> not sure if I'd need QA signoff for rtm silo 14?
<cyphermox> ^^
<robru> AlbertA: done
<AlbertA> robru: great thanks!
<robru> no wait, i failed
<robru> AlbertA: ok now it's done. you're welcome ;-)
<robru> cyphermox: I think everything in rtm requires qa signoff?
<cyphermox> robru: I thought so too, but somehow the scripts decided to ignore the fact that the field isn't filled in
<cyphermox> robru: it's also just so you know not to necessarily just publish it without checking :/
<robru> cyphermox: "not filled in" isn't a valid state, it should be one of N/A, Required, or Granted
<cyphermox> ah
<cyphermox> then let me fix this
<robru> cyphermox: I set it to required.
<cyphermox> good
 * cyphermox waits for a landing
<robru> cyphermox: not worth fixing the spreadsheet to consider a blank field as equivalent to 'Required' because the spreadsheet is going away so deliciously soon!
<cyphermox> robru: ok
<cyphermox> robru: please don't land silo 14 even if it gets tested, there's still https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1384776 that needs to be appropriately blessed
<ubot5> Ubuntu bug 1384776 in network-manager (Ubuntu) "Occasional hang in unity 8 dash on the phone" [High,In progress]
<cyphermox> sil2100: Mirv: ^
<robru> cyphermox: k, please say so in the comment field so everybody knows
<cyphermox> yup, just about to do it
<sil2100> cyphermox: thanks for the heads up
<AlbertA> trainguards: question.... in archive tab, line 1929, that fix landed on utopic and merged into media-hub trunk
<AlbertA> trainguards: but I don't see it on the archive
<robru> AlbertA: weird, I don't see it in the archive either, even though the branch is merged and trunk has the release commit. no matter now, the newer release includes the older release.
<tvoss> robru, could you reconfigure silo rtm 13 please?
<lool> ubuntu-qa, mind unblocking rtm silo 4 to put it back into needs qa?
<lool> we've tested it on krillin now; it's ready for its second landing attempt
<ToyKeeper> lool: It looks like the spreadsheet/dashboard aren't updated yet.
<ToyKeeper> lool: Set the "Testing pass?" field there, and it'll unblock QA.
<ToyKeeper> lool: It looks unlikely to get tested today though, since EOD is in 18 minutes.
<lool> hmm thanks
<robru> tvoss: ah sil2100  beat me to it
<tvoss> robru, yup :)
<lool> ToyKeeper: done
<AlbertA> robru: the problem is I'm trying to sync from utopic to rtm... how do I do that now? because the packages don't have the right thing...
<robru> AlbertA: not sure what you mean. the package versioned 20141020 will contain whatever was in 20141016
<AlbertA> robru: I mean the package in utopic does not match what's in media-hub trunk
<AlbertA> robru: and rtm is missing the last commit (i.e. the fix I'm trying to land in rtm)
<AlbertA> robru: and the sync just uses the package source right?
<robru> AlbertA: the sync would just grab from distro at this point, right
<AlbertA> robru: so how do I solve this?
<AlbertA> robru: a no change branch?
<robru> AlbertA: trunk and distro look fine to me. looks like you had a case of two silos happening simultaneously and the train got a bit confused, but it looks fine now
<AlbertA> robru: well the rtm silo landing-017 just built/synced does not match trunk
<robru> AlbertA: this is the latest diff to go into utopic: https://launchpadlibrarian.net/187757982/media-hub_2.0.0%2B14.10.20141015.1-0ubuntu1_2.0.0%2B14.10.20141020-0ubuntu1.diff.gz and this is the latest commit on your trunk: http://bazaar.launchpad.net/+branch/media-hub/revision/82 looks the same to me. what's missing?
<robru> AlbertA: looks totally fine to me.
<AlbertA> robru: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-017/+files/media-hub_2.0.0%2B14.10.20141020.orig.tar.gz
<AlbertA> robru: this does not match trunk...I don't know why...
<robru> AlbertA: 20141020 is the latest in trunk and in utopic. what part of it doesn't match?
<robru> AlbertA: the orig.tar doesn't really mean anything to me because I'm not familiar with the project. Can you produce a diff between what you expected to see and what you actually see? as far as I'm able to tell, the latest release to utopic matches the most recent commit in trunk
<AlbertA> robru: yeah let me produce the diff I'm seeing
<AlbertA> robru: http://pastebin.ubuntu.com/8646204/
<AlbertA> robru: shouldn't the package generated in landing-017 match trunk? there should be no diff in src/
<robru> AlbertA: it should only match trunk insofar as distro matches trunk, because it's copying from distro, not from trunk.
<robru> AlbertA: anyway, if you want to do a trunk release rather than a sync from utopic, prepare an empty MP against trunk and the train can use that to trigger a fresh build from trunk
<AlbertA> robru: ok
#ubuntu-ci-eng 2014-10-24
<imgbot> === trainguards: IMAGE 298 building (started: 20141024 02:05) ===
<imgbot> === trainguards: RTM IMAGE 124 building (started: 20141024 03:05) ===
<imgbot> === trainguards: IMAGE 298 DONE (finished: 20141024 03:25) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/298.changes ===
<imgbot> === trainguards: RTM IMAGE 124 DONE (finished: 20141024 04:15) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/124.changes ===
<cjwatson> BTW vivid is open, auto-syncs in progress, as of last night
<Mirv> morning
<Mirv> cjwatson: \o/
<ogra_> sil2100, moop ...
 * Mirv uploads first vivid PPA package
<davmor2> Mirv: if it's a new QT I'm hunting you down to hurt you ;)
 * Mirv hides, quickly
<Mirv> sil2100: stop playing with the queuebot!
<Mirv> tvoss: is the landing-006/utopic location-service going to be utopic SRU or can the silo be freed for now until a vivid silo can be assigned?
<Mirv> I just realized I need a separate vivid Qt silo since I can't reuse the version numbers I've for the utopic builds
<tvoss> Mirv, let me check with lool, will get back to you
<Mirv> tvoss: thanks
<Mirv> and currently "suitable for Qt" silos include 005, 006 and 015 which have been sufficiently bumped to 20+GB in size :)
<AlbertA> trainguards: can I have rtm landing-017 reconfigured? setup in line 43
<Mirv> AlbertA: done
<rsalveti> Mirv: silo 16 is good to go
<rsalveti> abeato: ^
<rsalveti> Mirv: not sure if we can publish it now or wait for a bit more
<ogra_> brendand, davmor2, where do we stand with glibc ?
<Mirv> I'm not aware of any reasons not to publish
<brendand> ogra_, about to sign it off
<ogra_> \o/
<ogra_> i wanted to build an image for the new -meta ... but then i'll wait
<Mirv> rsalveti: I don't see bug #1378397 in any of the lists, though. but I assume it's the single fix that fixes the 1355095 that just happens to fix also that other bug?
<ubot5> bug 1378397 in gst-plugins-base1.0 (Ubuntu) " video thumbnails are not generated for some divx files " [High,Confirmed] https://launchpad.net/bugs/1378397
<Mirv> thumbnails sounds indeed like seeking/fastforward activity to me
<rsalveti> Mirv: indeed
<rsalveti> Mirv: need to raise this with the management
<rsalveti> abeato: ^
<abeato> Mirv, so the bug mentioned in the mail is LP #1355095, but I asked in that mail about whether that was actually LP #1356330, olli ack'ed
<ubot5> Launchpad bug 1355095 in Media Hub "mediaplayer hangs on fast-forward" [Critical,Triaged] https://launchpad.net/bugs/1355095
<ubot5> Error: Launchpad bug 1356330 could not be found
<Mirv> abeato: aha, right, this the mailing list special case. indeed, 1356330 is "duplicate" of the 1378397 and was acked. thanks.
<abeato> Mirv, np
<Mirv> published
<abeato> Mirv, awesome, thanks
<olli> abeato, was there a q for me?
<abeato> olli, not really, I was just quoting you :)
<davmor2> Chipaca: where you at dude, need to ask what is happening with silo 12 now?
<Mirv> ogra_: so should we need to trigger a new image now, then land ^ 025, then another new image?
<ogra_> Mirv, hmm, i guess we could as well just let 25 in before the next image
 * ogra_ trusts QA
<ogra_> sil2100, ^^^^ opinion ?
 * Mirv waits for opinion
<sil2100> 25 was the glibc?
<ogra_> yep
<ogra_> i thik it is safe to take it in the batch
<sil2100> I wouldn't build a specific image for just that, let's land it and kick a new image then
<Mirv> ok
<Chipaca> davmor2: am here
<sil2100> IMO it's super safe
<Chipaca> davmor2: i'll go find you
<ogra_> ++
 * sil2100 in meetings since the very morning
<ogra_> brendand, there is a non-silo change for bug 1384920 ... how would you guys like to go about testing that ? i assume someone would have to manually create a trello board card ?
<ubot5> bug 1384920 in ubuntu-touch-meta (Ubuntu RTM) "Remove hud from the image" [High,Confirmed] https://launchpad.net/bugs/1384920
<ogra_> (essentially it is just "apt-get purge hud" on a working image and check that this doesnt regress anything)
<ogra_> i'd like to land that before end of the day
<sil2100> This needs to be signed-off for sure, since we were worried this might break something that was invalidly expecting hud still
<Chipaca> Mirv: do branches that are already in the pipeline need to be retargeted to comply with the land-in-vivid-then-rtm rule now?
<ogra_> sil2100, right ... just wonderign how to get it onto the trello board :)
<sil2100> We can artificially do it through the spreadsheet, but yeah, brendand should be able to do that by himself ;p
<Chipaca> sil2100: ogra_: ^?
<sil2100> Chipaca: depends on how they're in the pipeline right now
<Chipaca> sil2100: ppa built, doing autopilot tests
<sil2100> Chipaca: what are they targetting right now and what are they targeting right now?
<sil2100> ARGH
<ogra_> targets !
<sil2100> I mean, what branch they target and what series they target
<sil2100> ._.
<Chipaca> the target trunk; i don't think they target a series
<AlbertA> ToyKeeper: rtm landing-017 is ready for QA now
<ToyKeeper> AlbertA: It's now in the 'ready' lane.  :)
<sil2100> Chipaca: but the silo is for ubuntu-rtm or utopic right now?
<Chipaca> sil2100: rtm
<sil2100> So, in this case I think we still can land that before landing it back to vivid
<Chipaca> sil2100: ok. but any new branches need to go vivid -> rtm?
<sil2100> Chipaca: yes, best if they do
<ogra_> triggering an image now ...
<Chipaca> sigh
<Chipaca> ok
<Chipaca> creating new target branch ...
<ToyKeeper> AlbertA: Might be a bit...  meetings.
<AlbertA> ToyKeeper: np
<imgbot> === trainguards: RTM IMAGE 125 building (started: 20141024 14:10) ===
<cyphermox> ToyKeeper: I thought silos were added automatically in the QA trello board, but I can't seem to see my silo 14 in
<cyphermox> ToyKeeper: do you have any idea why that might be?
<Chipaca> sil2100: there isn't a vivid option in spreadsheet
<sil2100> Chipaca: not yet, still in meetings
<ToyKeeper> cyphermox: Silos get added automatically by a bot after it gets both "signoff required" and "testing pass: yes".
<cyphermox> ToyKeeper: yeah, but it is ;)
<ToyKeeper> cyphermox: ... and hopefully the kanban card will be linked directly from the dashboard soon, after CI adds a couple small features.
<sil2100> Chipaca: preparing the vivid chroot now, CI Train should be able in ~5-10 mins
<ToyKeeper> cyphermox: I'm not sure why, but queuebot doesn't seem to have noticed it either.
<Chipaca> sil2100: thanks
<ToyKeeper> cyphermox: I see the correct state in the spreadsheet, but neither queuebot not the qa bot seem to have noticed.
<sil2100> Sorry for that, it's hard to do work during meetings while staying active ;)
<cyphermox> ToyKeeper: it was set yesterday even, I just re-toggled it in case.
<ToyKeeper> cyphermox: Nevermind about queuebot; I found its notification about 1.5 hours ago.
<cyphermox> ah, that's special
<cyphermox> it should have happened either > 12 hours ago, or < 1 hour ago :)
<ToyKeeper> 2014-10-24 06:59:46 -queuebot!~queuebot@ubuntu/bot/queuebot-	trainguards, ubuntu-rtm/landing-014: Packages built. Testing pass. QA needs to sign off.   (in this time zone, it's currently 08:26)
<cyphermox> bah, as long as it notified..
<ToyKeeper> cyphermox: brendand should be looking into it as soon as he's done with a meeting...  otherwise, if it's not fixed when I finish my current silo, I'll add it manually.
<cyphermox> ToyKeeper: brendand: thanks
<ToyKeeper> cyphermox: FWIW, the direct link from the dashboard to the kanban card should also pretty much eliminate bot errors like this, since it'll have a reliable and unique ID to use for each silo+card combo.  I suspect it may have not noticed because rtm-014 was passed, published, reallocated, and submitted for QA all within a short time.
<ToyKeeper> (it might think the current silo is actually the old one)
<cjwatson> ogra_: so we need aliases for ubuntu-touch/ubuntu-rtm/14.09.es and ubuntu-touch/ubuntu-rtm/14.09.es-proposed I guess?
<cjwatson> Was that what you were saying?
<ogra_> cjwatson, for the ones we dont have anything yet... important is that we give the right channel name to the cusomer and that the pre-flashed devices have an unversioned channel name
<ogra_> else it gets hairy
<ogra_> cjwatson, the preinstalled devices should always use the alias, not the versioned channel name so we can shuffle them if needed
<ogra_> (which we currently dont do)
<ToyKeeper> AlbertA: Some issues I noticed...  If I let a video finish playing (in gallery), then hit 'play' again without returning to the list view, the second showing has only sound, no visuals.
<ToyKeeper> AlbertA: Also, after playing the same video three times in gallery, I tried closing and re-opening gallery and playing the same video again, and media-hub-server crashed.
<ToyKeeper> AlbertA: Are either of these known or expected?
<ToyKeeper> AlbertA: http://toykeeper.net/tmp/phablet/2014-10-24/_usr_bin_media-hub-server.32011.crash.bz2
<AlbertA> ToyKeeper: yeah there's some media-hub crashes that have not been addressed yet
<ogra_> sil2100, so i created a line on the spredsheet (71) ... not sure how we want to move on here
<sil2100> brendand, davmor2, ToyKeeper: anyone of you around?
<Mirv> lool: did tvoss check with you whether utopic landing 006 could be freed (location-service) and you'd land it later to a vivid silo?
<Mirv> I'll just ask for another size bump of a PPA
<Mirv> sil2100: vivid assignment seems to have gone fine https://ci-train.ubuntu.com/job/prepare-silo/2928/console
<sil2100> Mirv: phew
<ToyKeeper> sil2100: Sorry, impromptu meetings.  What's up?
<sil2100> ToyKeeper: we have a +1'ed by management change that needs QA sign-off, but it's a seed change so it's impossible to do in a silo
<sil2100> ToyKeeper: can you help out signing it out and adding to the trello board somehow?
<sil2100> ToyKeeper: ogra_ prepared a landing line, but I can't really assign it anywhere - row 72 in the spreadsheet
<Mirv> charles: nik90: "resubmit after filing MR (aka rejected for now)"
<ToyKeeper> sil2100: Added.
<ToyKeeper> sil2100: It seems we have more of a queue than we thought though, the QA bot didn't pick up a couple silos and the silo testers have mostly been stuck in meetings all day.
<davmor2> sil2100: yes thanks
<Mirv> ogra_: I was asked if there's an ETA for vivid image?
<ogra_> Mirv, nobody has talked to me about that yet ... but i guess as soon as cjwatson enables vivid desktop builds we also want phone ones
<Mirv> ogra_: ok.
<Chipaca> sil2100: i haven't set the "qa signoff needed" cell in the spreadsheet, does that break anything?
<Mirv> Chipaca: it breaks that your landing doesn't go forward. so please just set it to Required so it goes to QA's radar.
<davmor2> Mirv: we don't know how is it in a separate tab or something
<Mirv> davmor2: column I?
<Mirv> drop-down menu
<davmor2> Mirv: Yay
<davmor2> done it
<Chipaca> Mirv: i've set it. davmor2, please let me know if it still doesn't show up in wherever it is you look :)
<davmor2> Chipaca: it's there now
<Chipaca> and queuebot says to get a move on
<Chipaca> :-p
<charles> Mirv, ack, no problem
<cjwatson> ogra_: I might do it today if I can ever manage to escape meetings for an hour :)
<ogra_> heh
<ogra_> cjwatson, i suspect we need a vivid channel too on system-image
<ogra_> and move the devel and devel-proposed aliases over to that
<cjwatson> Sure
<ToyKeeper> AlbertA: Not that these are your responsibility, but these are two new bugs discovered while testing your silo:
<ToyKeeper> https://bugs.launchpad.net/gallery-app/+bug/1385370
<ubot5> Ubuntu bug 1385370 in gallery-app "second video playback has sound but no visuals" [Undecided,New]
<ToyKeeper> https://bugs.launchpad.net/mediascanner/+bug/1385358
<ubot5> Ubuntu bug 1385358 in mediascanner "crash while pushing videos to device" [Undecided,New]
<AlbertA> ToyKeeper: ack
<cking_> hey, how do I install updates from a silo?
<AlbertA> trainguards: can I get rtm landing-017 published?
<robru> cking_: "apt-get install phablet-tools-citrain" then run "citrain" for help (on your host)
<cking_> robru, thanks!
<robru> cking_: you're welcome!
<robru> ogra_: what's the deal with publishings? are you in the middle of doing a seed change? can i publish something unrelated?
<ogra_> robru-aka-ribru, what do you want to publish ?
<Mirv> ribru :D
<ogra_> (i have a seed change in the pipe but want QA signoff for it first)
<Mirv> note that I can't find AlbertA's bug #1378311 from any list
<ubot5> bug 1378311 in qtubuntu-media "EndOfStream event not received when QML Video component is destroyed" [Critical,New] https://launchpad.net/bugs/1378311
<robru-aka-ribru> ogra_: yeah, alberta asked if we could publish silo 17
<robru-aka-ribru> it has qa signoff even
<ogra_> robru-aka-ribru, sure, if it has QA signoff and approval on ollis list you can just publish
<robru-aka-ribru> ogra_: which list is the relevant one now?
<ogra_> cjwatson, infinity, whats going on with the image builders ? i started an rtm build several hours (3) ago but they seem to not start
<ogra_> 4h estimated for x86 1h for armhf according to https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu-rtm/14.09/ubuntu-touch/
<ogra_> robru-aka-ribru, always the last one he mailed to the ML
<robru-aka-ribru> ogra_: hm it doesn't seem to be there. darn
<ogra_> robru-aka-ribru, phablet@
<ogra_> https://docs.google.com/a/canonical.com/spreadsheets/d/1vtSSJZTIVEki9WsxTH_UxbE_PhdsEJl3Z0mn-UyDat0/edit#gid=0
<Mirv> ogra_: robru-aka-ribru the thing was I didn't find the bug either on the email or the wishlist
<Chipaca> davmor2: any news for me?
<davmor2> Chipaca: first run failed so trying again with download turned off
<robru-aka-ribru> Mirv: which bug even? the silo looks like a trunk release, not clear to me even which bug he was trying to fix
<Mirv> robru-aka-ribru: the landing line claims it fixes that I quoted ^ 11 mins ago
<ogra_> robru-aka-ribru, Mirv, then get it on there ...
<Mirv> robru-aka-ribru: ok I've Alberto here, he says that rsalveti (?) said yesterday it was whitelisted
<robru-aka-ribru> Mirv: so what now? ping olli?
<Mirv> robru-aka-ribru: maybe rsalveti could comment, and yes next olli but it'd be nice to hear what route this supposed whitelisting happened.
<ogra_> https://bugs.launchpad.net/barajas/+bug/1367745
<ubot5> Error: ubuntu bug 1367745 not found
<rsalveti> Mirv: which silo?
<ogra_> robru-aka-ribru, that bug has duplicates ... i guess they might be on the list
<Mirv> rsalveti: 017 media-hub
<Mirv> robru-aka-ribru: you're also correct it's a trunk release that incorporates two updates
<rsalveti> Mirv: I think that one already  landed last week
<Mirv> oh, but it should be really just a rebuild, that latter one
<rsalveti> but yeah, if not, I added a comment that it needs a rebuild
<robru-aka-ribru> Mirv: rsalveti: this landing was confusing for me because AlbertA claimed there was a diff between the utopic package and the trunk contents, but I wasn't able to see any such diff (latest diff in utopic release matched latest commit on trunk). so originally this was a utopic sync but AlbertA switched it to a trunk release.
<ogra_> robru-aka-ribru, found the bug https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1384776
<ubot5> Ubuntu bug 1384776 in network-manager (Ubuntu) "Occasional hang in unity 8 dash on the phone" [High,In progress]
<ogra_> thats on the list
<Mirv> robru-aka-ribru: rsalveti: yeah right so it'd seem likely it was a fix that already went in, but then there was criss-cross landing utopic <-> rtm and it needs this rebuild to get back in
<AlbertA> robru-aka-ribru: basically the orientation change is not in utopic
<rsalveti> Mirv: right
<rsalveti> but because utopic is done
<rsalveti> :-)
<ogra_> robru-aka-ribru, (for rtm silo 14 ... so just go ahead)
<robru-aka-ribru> ogra_: we're talking about 17
<robru-aka-ribru> ogra_: 14 need qa still
<ogra_> hmm, where did i read 14
<ogra_> :P
<Mirv> rsalveti: robru-aka-ribru: so this manual diff http://pastebin.ubuntu.com/8658892/ proves it only contains the fix it is supposed to have, but that really doesn't help the fact that the bug #1378311 does not seem whitelisted?
<ubot5> bug 1378311 in qtubuntu-media "EndOfStream event not received when QML Video component is destroyed" [Critical,New] https://launchpad.net/bugs/1378311
<Mirv> robru-aka-ribru: the diff on the PPA page is wrong
<ogra_> as usual
<robru-aka-ribru> why are the ppa diffs wrong?
<ogra_> because they are against the wrong base version
<ogra_> (against the last build that was done in this PPA, not against the archive)
<AlbertA> ToyKeeper: where did you see  bug #1378311 whitelisted?
<ubot5> bug 1378311 in qtubuntu-media "EndOfStream event not received when QML Video component is destroyed" [Critical,New] https://launchpad.net/bugs/1378311
<Mirv> oh, right, ToyKeeper might also have knowledge of the whitelisting which is now the missing part. diff confirmed, QA sign-off:d, we just need to find it's approved or get it approved.
 * Chipaca wonders whether he should embed https://www.youtube.com/watch?v=Qyf8oRF6Trg in the spreadsheet
<Chipaca> davmor2: failed == you gave up waiting? or ... ?
<lool> Mirv: I thought utopic silos would become vivid silos?
<lool> Mirv: I've actually tested that against utopic, can we just publish it to vivid?
<robru-aka-ribru> lool: Mirv: wondering about that myself. do we need to toss & reassign all utopic silos as vivid silos?
<Mirv> lool: it needs at least a rebuild, and the silo configured to vivid
<Mirv> I guess we'll go through all current utopic silos at some point and consider converting them to rebuilt vivid silos
<robru-aka-ribru> Mirv: I don't think silos can be "converted" or "reconfigured" to vivid. I think to change the series you need to free the silo and start over.
<Mirv> robru-aka-ribru: oh, right, so freeing up would be the way to go then, but just keeping the lines intact
<sil2100> ribru: so, we'll probably have to poke upstreams about that and just reassign
 * sil2100 likes the 'ribru' nickname
<robru-aka-ribru> hehe
<sil2100> brb
<robru-aka-ribru> sil2100: we have a meeting shortly...
<Mirv> ribru: be sure to have proper highlight settings
<robru-aka-ribru> Mirv: fixed
<Mirv> ribru: awesome!
<ribru> Mirv: I worried about changing the second letter of my nick, will trip people up if they type 'ro<tab>' and try to autocomplete
<ribru> sil2100: Ursinha: I am in the hangout
<ribru> nooooooo
<lool> Mirv: why does it need a rebuild?
<lool> Mirv: it's like a binary built in utopic from utopic times?
<Mirv> lool: well yeah you're probably correct that a binary with 'utopic' in debian/changelog could be published into vivid and it'd simply work. reading the sil2100's landing e-mail about vivid it sounds like though that rebuilds with vivid's toolchain (even though it doesn't have much changes) would be normally done.
<Mirv> lool: but ribru also said a silo can't be reconfigured to vivid, so it'd need to be emptied and reassigned
<lool> Mirv: I think sil2100's point was the other way around: that you can't copy binaries from vivid into rtm
<lool> Mirv: let me copy the binaries by hand then, and let's flush the silo
<Mirv> lool: ok.
<lool> Mirv: copy done; would you mark this as landed and/or flush the silo?
<lool> ftr ./copy-package -b --to=ubuntu -s utopic --from=~ci-train-ppa-service/ubuntu/landing-006 --to-suite=vivid-proposed location-service
<Chipaca> Mirv: sil2100: rtm-14 ready to go
<brendand> Chipaca, no it's not
<lool> Mirv: hmm what do we do with the ubuntu-download-manager utopic landing? vivid silo?
<lool> Mirv: it seems to have been removed, not sure
<brendand> Mirv, 14 was not signed off by QA
<brendand> Mirv, someone else changed the status
<Mirv> brendand: right, I always check trello anyhow
<Chipaca> brendand: um. it was signed off by qa.
<Chipaca> brendand: where are you looking?
<Chipaca> if it's the same spreadsheet, i changed that to granted when davmor2 told me he'd passed it
<brendand> Chipaca, afaik davmor2 tested silo 12 - ubuntu-push
<Chipaca> yes
<Chipaca> brendand: augh
<Chipaca> sorry for the confusion
<Chipaca> brendand: so, yeah, rtm-12, not rtm-14
<brendand> Chipaca, always let us do that to avoid confusion
<cjwatson> ogra_: they'll be queued behind auto-syncs.  I would score them up but they seem to have started now.
<Chipaca> brendand: noted, and thanks and sorry again
<Chipaca> brendand: should i poke davmor2 for him to flip that bit on the spreadsheet then?
<davmor2> Chipaca: sorry flipped 59 instead of 60 D'oh
<Chipaca> davmor2: and i flipped rtm-14 just to keep things interesting
<Chipaca> and i'm missing out on the snappy thing
<davmor2> Chipaca: well go to it damn it
<Chipaca> so. um. Mirv, sil2100, could rtm-12 get blessed with holy penguin pee?
<Mirv> davmor2: where was bug #1378908 approved? (rtm-12's 2nd bug)
<ubot5> Error: Launchpad bug 1378908 could not be found
<Mirv> even I can't even access the bug
<Mirv> the bug is only mentioned in CI Train spreadsheet, the Add ClearCookie change doesn't have an attached bug nr in the changelog
<ToyKeeper> AlbertA: https://docs.google.com/a/canonical.com/spreadsheets/d/1tcOf-Za9RQNgY0QQIjgIKIgk0_nx_99UsaHSm9LDbvA/edit#gid=2115197992
<davmor2> Mirv: where you at
<AlbertA> Mirv: ^
<Mirv> Chipaca: so, that bug ^ can't be found in approved bugs list or wishlist with my skills
<ralsina> mirv I can add you to that bug
<ralsina> are you also mirv on launchpad?
<Mirv> ralsina: no, timo-jyrinki
<ToyKeeper> Mirv: ^^^
<Mirv> davmor2: sdk / display server room
<ralsina> Mirv: there you go
<ToyKeeper> I checked the "RTM blocker bugs" tab in that spreadsheet, and it's on the list.
 * Mirv finds a new tab
<Mirv> AlbertA: published!
<Mirv> ralsina: thanks! I don't however find that bug nr on the a) e-mail, b) ToyKeeper's link ^ c) wishlist. so unless there's yet another tab I'm missing, it should be escalated to product team.
<ralsina> Chipaca: ^
<ToyKeeper> Mirv: Row 29 on the spreadsheet link/tab I sent.
<Mirv> ralsina: Chipaca: davmor2 is on it now, searching for approval
<Mirv> ToyKeeper: yes, I published that silo this is about 012 now
<ToyKeeper> Mirv: Oh...  sorry, I missed that context.
<ToyKeeper> Mirv: The rules, IIRC, are basically that the bug must be on a whitelist or have the right tags/status added by or confirmed by one of the core UE managers.  Some might not be on a list.
<ToyKeeper> Mirv: If in doubt, find one of those managers and ask.  Or bug the QA person who signed it.
 * ToyKeeper looks at davmor2
<Mirv> ToyKeeper: I think everything needs explicit whitelist, but any rtm14 critical bug (as decided by the team) can be put for the wishlist for approval. also, if a not-on-lists bug has explicit comment from product team that it's approved, then it's approved, but not otherwie.
<Mirv> ToyKeeper: yes, I just bugged davmor2 personally. or the other way around.
<imgbot> === trainguards: RTM IMAGE 125 DONE (finished: 20141024 19:00) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/125.changes ===
<davmor2> Mirv: where you at now?
<Mirv> davmor2: upstairs don't turn towards the foyer but continue towards istanbul.
<Chipaca> Mirv: davmor2: sorry, was in the snappy meeting. What's up with the other bug?
<davmor2> Chipaca: nothing now
<Chipaca> davmor2: do i ned to do more?
<Mirv> Chipaca: ralsina: we've finally found the approval, it was for the duplicate bug. but now https://code.launchpad.net/~verterok/ubuntu-push/fix-1378908/+merge/239456 is not top-approved so can't publish. this should be easier to solve than finding the approval :)
<Chipaca> top-approval on its weg
<Chipaca> Mirv: done
<ToyKeeper> ogra_: The hud removal looks fine, I couldn't find anything wrong with it, aside from a possibility that a bunch of other stuff might need to be rebuilt without deps for libhud*.
<ogra_> ToyKeeper, awesome, libhud deps should be reflected via package dependencies indeed, so there shouldnt be issues (i have been running my phone without hud all day today too and havent seen any issues)
#ubuntu-ci-eng 2014-10-25
<imgbot> === trainguards: IMAGE 299 building (started: 20141025 02:05) ===
<imgbot> === trainguards: RTM IMAGE 126 building (started: 20141025 03:05) ===
<imgbot> === trainguards: IMAGE 299 DONE (finished: 20141025 05:35) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/299.changes ===
<imgbot> === trainguards: RTM IMAGE 126 DONE (finished: 20141025 05:35) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/126.changes ===
<imgbot> === trainguards: RTM IMAGE 127 building (started: 20141025 11:55) ===
<slangasek> ogra_, sil2100: around?  bug #1385656 - I think we want a revert, but that needs figuring out what went in the image and since the commit logs aren't generated as part of the image build...
<ubot5> bug 1385656 in Ubuntu "Installation of application from the click store appears not to work" [Critical,New] https://launchpad.net/bugs/1385656
<ogra_> slangasek, there isnt really anything in there that could affect packagekit http://people.canonical.com/~ogra/touch-image-stats/rtm/126.changes
<ogra_> slangasek, http://people.canonical.com/~ogra/touch-image-stats/rtm/125.changes has apt changes, i wonder if that is somehow related
<slangasek> john-mcaleely: was bug #1385656 definitely not reproducible on 125?
<ubot5> bug 1385656 in Ubuntu "Installation of application from the click store appears not to work" [Critical,New] https://launchpad.net/bugs/1385656
<rsalveti> ogra_: quite a few packages got removed though, not sure if that could be causing any bad side effect
<rsalveti> bug guess that's easy to know, just install them by hand
<ogra_> rsalveti, thats all only hud, i doubt it can affect packagekit
<rsalveti> hm, libdbusmenu-qt5 got removed
<rsalveti> not sure if that would cause anything though
<ogra_> but with the builder situation atm re-rolling an image will also be hard without some admin driving them ...
<rsalveti> ogra_: what is the issue?
<slangasek> what's the builder situation?
<ogra_> they put image builds on awfully low score and are busy
<ogra_> (see #ubuntu-release, i pinged about that a while ago)
<slangasek> ok
<ogra_> (Lese Datenbank ... 38661 Dateien und Verzeichnisse sind derzeit installiert.)
<ogra_> Vorbereitung zum Entpacken von .../libdbusmenu-qt5_0.9.3+14.10.20140619-0ubuntu1_armhf.deb ...
<ogra_> Entpacken von libdbusmenu-qt5:armhf (0.9.3+14.10.20140619-0ubuntu1) ...
<ogra_> Error: Timeout was reached
<ogra_> phablet@ubuntu-phablet:~$
<ogra_> (sorry for the german)
<ogra_> smells like we have some bigger problem here
<ogra_> (not sure where thaat message comes from though)
<ogra_> seems it installed the package fine though
<ogra_> so i see that packagekit message in syslog when unity8 tries to refresh the view after installing ...
<ogra_> then it goes to 100% CPU
<ogra_> hmm
<ogra_> in fact it is constantly at 100% cpu even after reboot
<ogra_> crap
 * ogra_ installs unity-voice-service ... (and starts packing) 
<ogra_> bah
<ogra_> now apport hardlocked my phone ... doesnt take input anymore
<ogra_> with a load of 13 in top
<rsalveti> Oct 25 09:41:27 ubuntu-phablet PackageKit: daemon start
<rsalveti> Oct 25 09:41:27 ubuntu-phablet PackageKit: daemon quit
<rsalveti> Oct 25 09:41:52 ubuntu-phablet dbus[750]: [system] Failed to activate service 'org.freedesktop.PackageKit': timed out
<rsalveti> yeah
<rsalveti> that's what I'm getting
<ogra_> right, like i logged in the bug
<ogra_> i have all dropped packages re-installed apart from the hub
<ogra_> i see a fresh ubuntu-app-launch file in /var/crash
<ogra_> hmm, now it behaves better after a reboot
<slangasek> reproducible on previous build? reproducible on mako?
 * ogra_ installs hud too ... then i will have all dropped packages back
<rsalveti> weird, even after reinstalling hud and every dropped package, it is still failing for me
<ogra_> yeah
<rsalveti> was 125 fine?
<ogra_> i doubt it is actually the dropping of packages
<ogra_> no idea and i dont have the time to test that
<ogra_> rsalveti, 125 has the libc change though
<rsalveti> will take ages for me to download it
<ogra_> well, same network here :)
<rsalveti> yeah, quite a few changes on 125 as well, apt, bash, gstreamer, libc
<ogra_> right
<slangasek> the libc change was a targeted change to raise the limit on TLS usage; there's no reason to think that's the cause
<slangasek> that is, there's no reason to single it out as a possible cause
<ogra_> http://fanf42.blogspot.com/2014/08/upgrading-to-ubuntu-1404-error-timeout.html
<ogra_> there
<ogra_> i get the timeout error here all the time ... seems that refers to the apt change
<rsalveti> I did get ' Error: Timeout was reached' as well
<ogra_> right
<ogra_> i dont get apt segfaults like he describes though
<ogra_> (and indeed it is a totally different problem, but a good pointer i think)
<ogra_> rsalveti, try downgarding apt
<rsalveti> what were the apt changes that we got on 125?
<ogra_> security fixes
<ogra_> security team synced bash and apt from utopic
<slangasek> apt shouldn't be involved in the installation of a click package, however
<rsalveti> right
<ogra_> indeed
<rsalveti> this timeout we got was when installing deb packages with apt
<ogra_> well
<ogra_> does  packagekit use libapt anywhere ?
<ogra_> i assume it is perhaps linked against it
<rsalveti> ogra_: slangasek: downgrading apt fixes it
<rsalveti> Oct 25 10:02:43 ubuntu-phablet dbus[751]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper)
<rsalveti> Oct 25 10:02:43 ubuntu-phablet PackageKit: daemon start
<rsalveti> Oct 25 10:02:43 ubuntu-phablet dbus[751]: [system] Successfully activated service 'org.freedesktop.PackageKit'
<ogra_> https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-October/000763.html
<rsalveti> wow, diff is huge, major version bump
<ogra_> does not really sound like related in any way ... i suspect we were multiple versions behind
<rsalveti> yes
<rsalveti> https://launchpadlibrarian.net/187988966/apt_1.0.4ubuntu6_1.0.9.2ubuntu2.diff.gz
<ogra_> and PPAs dont take -v into account for dpkg-genchanges
<ogra_> (which annoys me since we use them)
<rsalveti> flashing 126 again and will only downgrade apt to see if that is indeed what caused the issue
<rsalveti> then we should probably revert if for now, and retry the landing with the extra needed fix next week
<ogra_> ++
<ogra_> i need to check out soon though, someone else will have to drive the builds
<rsalveti> will try to get the revert on a ppa
 * ogra_ goes downstairs for a smoke before finishing the packing here 
<imgbot> === trainguards: RTM IMAGE 127 DONE (finished: 20141025 14:25) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/127.changes ===
<popey> \o/
<popey> clean installed 127 and it's device offline ...
<ogra_> you mean in adb ?
<popey> yes
<popey> sat at the logo now
<popey> JW011705	offline
<popey> i had OTA updated to the broken image earlier, then used udf to flash it when i just saw the bot announce 127 was done
<popey> hah, now it's booted
<ogra_> sounds like apparmor re-generating
<popey> yeah, i guess so
<popey> 127 is still busted
<popey> can't run pkcon
<rsalveti> ogra_: popey: mind testing https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-012 ?
<popey> phablet@ubuntu-phablet:~$ pkcon
<popey> Failed to contact PackageKit: Error calling StartServiceByName for org.freedesktop.PackageKit: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.PackageKit timed out
<popey> ok
<rsalveti> for https://launchpad.net/bugs/1385656
<ubot5> Ubuntu bug 1385656 in Ubuntu "Installation of application from the click store appears not to work" [Critical,New]
<popey> is there some magic for testing? I mean, some special way to add the ppa (I haven't used ppas for a while on rtm)
<rsalveti> same as before, with apt-add-repository
<popey> or is add-apt-repository ppa:ci-train-ppa-service/landing-012  sufficient?
<rsalveti> just add a team/distro/ppa
<ogra_> popey, citrain
<rsalveti> in this case it would be ppa:ci-train-ppa-service/ubuntu-rtm/landing-012
<popey> ok
<rsalveti> ogra_: what is new in 127?
<rsalveti> device tarball updates?
<ogra_> rsalveti, nothing apparently, i thought the network-manager change was not landed
<rsalveti> oh, alright
<ogra_> which is why i triggered this build
<ogra_> rebooting ...
<ogra_> installing lastpass
<ogra_> done
<ogra_> rsalveti, works fine for me
 * ogra_ removes lastpass again 
 * popey reboots
<ogra_> rsalveti, seems to be fine
<ogra_> unrelatedly i thik unity8 is eating wayy to much resources though ... but thats for next week
<popey> pkcon is still broken
<ogra_> i didnt check from cmdline ... the store worked for me
<popey> hmm, should I have upgraded more than just apt from that ppa?
<ogra_> yes
<popey> ok
<rsalveti> ogra_: what should we do, publish and image rebuild?
<ogra_> rsalveti, yeah
<ogra_> popey, all packages you have iinstalled indeed ...
<popey> ok, yes, that fixed it, and pkcon
<rsalveti> pkcon working fine here
<popey> rsalveti: ^
<rsalveti> great, will publish
<ogra_> phablet@ubuntu-phablet:~$ ls apt/
<ogra_> apt_1.0.9.2ubuntu2.is.1.0.4ubuntu7_armhf.deb                  libapt-inst1.5_1.0.9.2ubuntu2.is.1.0.4ubuntu7_armhf.deb
<ogra_> apt-transport-https_1.0.9.2ubuntu2.is.1.0.4ubuntu7_armhf.deb  libapt-pkg4.12_1.0.9.2ubuntu2.is.1.0.4ubuntu7_armhf.deb
<ogra_> apt-utils_1.0.9.2ubuntu2.is.1.0.4ubuntu7_armhf.deb
<ogra_> (i usually wget them and "dpkg -i *" for silo testing ... thats slightly cleaner
<ogra_> )
<ogra_> rsalveti, write a mail about that ... since we worked past QA here
<rsalveti> ogra_: sure
<ogra_> so people are aware what we did
<popey> nice one, thanks chaps!
<ogra_> popey, well ... we dont have an image yet ...
 * popey restarts doing the original thing he was doing, installing a click to test it
<popey> well, I'm alright ã
<ogra_> heh
<rsalveti> ogra_: are you going to be able to trigger a new image once it migrates to rtm release?
<rsalveti> need to pack my stuff here
<ogra_> if it does that before 12
 * popey flew back on an A380 which was very nice and new
<popey> sat in the highest seat number I have ever sat in... 83A
<ogra_> wow
 * ogra_ twiddles thimbs til rmadison agrees with the bot 
<ogra_> *thumbs too
<ogra_> sigh ... slow publisher ..
<rsalveti> ogra_: should be in release in a few more
<rsalveti> lp thinks it's already in release
<ogra_> well, i have to leave the room before 12 ...
<ogra_> (and rmadison still disagrees)
<ogra_> also with the builders being busy i'm not sure we will get an image soon unless we have someone bumping its build score
<rsalveti> still not in rmadison...
<ogra_> i'm moving to the lobby ... hoping the wlan code will stay valind long enough
<popey> ogra_: the bar has free wifi with no code needed
<ogra_> ok, build triggered
<imgbot> === trainguards: RTM IMAGE 128 building (started: 20141025 16:05) ===
<cjwatson> ogra_: the correct fix FWIW was a new packagekit
<cjwatson> ogra_: https://launchpad.net/ubuntu/+source/packagekit/0.8.17-4ubuntu3
<cjwatson> yet another thing we're wasting time on by having an out-of-date ubuntu-rtm/14.09 missing many bug fixes
<cjwatson> (sorry I wasn't around earlier to let you know, since that would have been a much quicker fix)
<john-mcaleely> slangasek, unknown when bug #1385656 appeared from my point of view - victor reported it over telegram this morning
<ubot5> bug 1385656 in Ubuntu "Installation of application from the click store appears not to work" [Critical,New] https://launchpad.net/bugs/1385656
<john-mcaleely> rsalveti, ogra_ so following on from email, is 128 going to have the wifi power fix as well as the back out to adress bug #1385656
<ubot5> bug 1385656 in Ubuntu "Installation of application from the click store appears not to work" [Critical,New] https://launchpad.net/bugs/1385656
<cjwatson> it's a thing I fixed last month in Ubuntu, but because Ubuntu RTM didn't have the new apt, the effort involved in persuading people that it should preemptively have the fixed packagekit was too much
<ogra_> john-mcaleely, yes
<john-mcaleely> ogra_, excellent
<ogra_> cjwatson, right, we can do that next week
<cjwatson> I would strongly recommend taking the new packagekit and un-reverting apt once you have a moment, to restore the security fix
<ogra_> we just didnt want to leave the images broken til then
<cjwatson> it shouldn't be necessary to reupload - we can just copy the security-fixed apt back in
<cjwatson> (with some archive admin help)
<john-mcaleely> sounds good
<ogra_> cjwatson, well we kind of broke all processes with that revert ... if you feel like doing that while we're all in the air, please do
 * ogra_ will be offline very soon 
<ogra_> (and ricardo already left)
<cjwatson> Hm, I could fiddle with the ubuntu-rtm archive then get on a plane, that sounds good
<cjwatson> I might do a bit later :)
<ogra_> heh
 * ogra_ crosses fingers 
<cjwatson> Though I can't really test anything
<ogra_> i guess popey could help you out
<cjwatson> And yeah, it's kind of entertaining that apt is tangentially involved in installing click packages; the work to give click its own dbus service will fix that
<ogra_> well, packagekit is still linked against apt on the lib level, no ?
<cjwatson> The aptcc backend is, yes
<ogra_> eve with a click dbus service
<ogra_> *even
<cjwatson> But we wouldn't be using packagekit any more
<ogra_> ah
<cjwatson> It was always just an expedient thing to use to shorten the path to first implementation
<cjwatson> And now that packagekit upstream is dropping plugin support in 1.0, we have to find an alternative anyway
<ogra_> ah, i didnt know they would do that
<ogra_> ok ... off to the airport
 * ogra_ waves
<cjwatson> have a safe trip
<ogra_> you too
<popey> cjwatson: happy to help... wassup?
<cjwatson> popey: later maybe
<cjwatson> no rush right now
<popey> cjwatson: ok
<imgbot> === trainguards: RTM IMAGE 128 DONE (finished: 20141025 17:20) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/128.changes ===
<ahayzen> clicks are installing again thanks folks :)
#ubuntu-ci-eng 2014-10-26
<imgbot> === trainguards: RTM IMAGE 129 building (started: 20141026 03:05) ===
#ubuntu-ci-eng 2015-10-19
<Mirv> robru: ok
<abeato> Mirv, good morning, I need some help to upload http://people.canonical.com/~abeato/qtmultimedia-opensource-src/ in silo 16
<Mirv> abeato: ok, looking!
<abeato> Mirv, thanks, should be the same you did for silo 55 (jhodapp told me you handled that), this is the wily sync
<Mirv> abeato: right, this adds the backported playlist support also to wily.
<abeato> yep
<Mirv> abeato: ok it has soon built for all archs but it'll take up to 20 mins still before it's fully published in the PPA for other packages to use
<abeato> Mirv, thanks
<abeato> Mirv, was not also needed a -qtmultimedia-opensource-src-gles package?
<Mirv> abeato: yes, I'll upload it soon too
<abeato> Mirv, great
<sil2100> jibel, davmor2, Mirv, ogra_: cancelled our morning meeting since I need to drive to the car mechanic in a moment
<sil2100> And probably wouldn't be able to make it on time
<jibel> sil2100, okay
<Mirv> sil2100: aha, ok then
<dholbach> cihelp: how can we get help-app landings moved to vivid (https://code.launchpad.net/~torsten.franz/help-app/help-app/+merge/274746)?
<psivaa> dholbach: you basically want to get rid of the utopic runs, right?
<dholbach> psivaa, yep - just use whatever is current :)
<psivaa> dholbach: ok, some projects are built on wily as well as vivid. but for now, i'll just disable utopic.
<dholbach> ok cool
<dholbach> psivaa, what will I need to do once it's all done? just re-approve the branch?
<psivaa> dholbach: no, just rebuid the failued jenkins job would be enough
<dholbach> hum... I don't quite know which buttons to press - can you help me? :)
<dholbach> thanks
<psivaa> dholbach: that requires, re-approve :)
<dholbach> yep, just saw it - thanks :)
<Saviq> elopio, ping
<Saviq> or anyone else who could help me with an autopilot issue â :|
<Saviq> jibel, hey, can you recommend someone to help debug an autopilot issue?
<brendand> Saviq, ask ubuntu-qa in general, but i can help you right now
<Saviq> brendand, gimme 5min please
<Saviq> brendand, ok back
<Saviq> brendand, we've silo 22 that somehow completely broke autopilot tests, they just bail out almost straight away
<Saviq> brendand, the only suspect log line is AP trying to start the X11 input method instead of UInput
<Saviq> but I'm not sure the difference is actually meaningful
<Saviq> brendand, here's an example -vvv log from a working and broken test run http://pastebin.ubuntu.com/12860476/
<brendand> Saviq, that reads like a problem with unity8 to me
<brendand> it is initctl start unity8 that's failing (although maybe only because of testability being on)..
<Saviq> brendand, I'm just getting a clearer log, this one was a result of previous failures
<Saviq> brendand, I think I'm starting to get what's going on http://pastebin.ubuntu.com/12860568/
<Saviq> that log is much more clear
<Saviq> brendand, we changed the internal structure of unity8 to support external monitors, so this check is wrong now
<Saviq> brendand, sorry for the noise, back to the drawing board
<brendand> Saviq, no problem, i just served as your duck :)
<Saviq> :)
<Saviq> trainguards, hey, are silo branches available somewhere before they are published?
<oSoMoN> ubuntu-qa: any chance silo 10 can be validated soon-ish?
<sil2100> Saviq: they're pushed to a special remote place only after publish (and before m&c)
<sil2100> Saviq: after building those are only available on jenkins
<sil2100> (before publish happens)
<Saviq> sil2100, FWIW, could sometimes use them for testing
<sil2100> Yeah, I guess that would be a valid feature request, sometimes I also want to see how it looks from the inside
<abeato> Laney, we need somebody with super-powers to publish silo 16, which contains the qtubuntu-media changes we talked about... mind landing it?
<rvr> sil2100: It's in the queue
<rvr> Oops
<rvr> oSoMoN: It's in the queue
<sil2100> rvr: good good good... what's in the queue? ;)
<rvr> sil2100: Lots of silos :D
<rvr> Sorry, I was answering to oSoMoN
<rvr> oSoMoN: Usually the Ready to QA lane in trello is sorted by priority
<davmor2> sil2100: you are in the queue
<oSoMoN> rvr, thanks, IÂ do monitor that board, but I was wondering whether there was some sort of ETA ? is it just you currently validating silos, or are there more people on it?
<rvr> oSoMoN: I'm alone during the mornings, so maybe alesage will pick it
<rvr> If not, probably tomorrow
<oSoMoN> okay, thanks
<davmor2> rvr: only for the next 2 weeks ;)
<rvr> davmor2: Quitter!
<Laney> abeato: I queued it... but what are the indicator-sound changes? :-/
 * Laney is scared of changing things on the desktop in release week
<abeato> Laney, support for mpris controls I think... xavigarcia knows more
<jhodapp> Laney, yes just MPRIS controls for phone only
<jhodapp> it should be a very isolated change
<abeato> xavigarcia, Laney is worried about breaking something in desktop if indicator-sound lands
<abeato> xavigarcia, are the changes dangerous?
<xavigarcia> abeato: you mean in silos 55 and 16?
<abeato> xavigarcia, 16 (wily)
<xavigarcia> abeato: I don't think there's anything dangerous...
<xavigarcia> abeato: I tested it on the desktop before testing it on the phone
<xavigarcia> abeato: But to be 100% we could maybe move to QA
<Mirv> sil2100: can you maybe review this https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.wily_add_qt5-image-formats-plugins/+merge/274882 ? (so that QA can process the silo)
<Laney> xavigarcia: It's release on Thursday so I am worried about breaking anything with no time to fix it
<Laney> is it crucial or could it wait for X?
<xavigarcia> Laney: I see... I don't think it is crucial for the desktop, TBH
<sil2100> Mirv: how much do the deps + the actual package weight?
<xavigarcia> Laney: Although the indicator disables the actions for the next and previous buttons when it's told by MPRIS the UI does not show anything different
<xavigarcia> Laney: so the difference it's not really notable. It's different on the phone, though
<Laney> xavigarcia: I think we run out of time really, trying to produce final candidate images right now
<Mirv> sil2100: as per the bug report, 960kB. the package itself is ~70kB
<Mirv> s/960kB/869kB/
<xavigarcia> Laney: ok, let's hold it then.... As I said, the user won't notice any difference on the desktop.
<Mirv> so messaging app and telegram will need it for sticker support
<sil2100> Mirv: hm, webp you say? I guess ~1MB more should be fineish...
<Mirv> sil2100: webp, yes
<sil2100> Mirv: hm, I think this would need a framework bump then
<xavigarcia> Laney: until the UI changes the icons when the action are not defined the user won't see any difference
<Mirv> sil2100: I'm not sure, the Qt part is just plugins and existing API is used
<pmcgowan> sil2100, yeah no fw bump I think
<rvr> bzoltan_: Hi
<bzoltan_> rvr: hello
<rvr> bzoltan_: I see lots of failures in this log http://people.canonical.com/~bzoltan/ap-2015_10_18-VIVID-SILO55-KRILLIN/MAIN-ap-2015_10_18-vivid-055
<rvr> bzoltan_: Much more than in the previous run http://people.canonical.com/~bzoltan/ap-2015_10_02-VIVID-SILO31-KRILLIN/MAIN-ap-2015_10_03-vivid-031
<bzoltan_> rvr: yes, but UITK has nothing to do with them
<bzoltan_> rvr: as you see those are not introduced by the silo055
<rvr> bzoltan_: There are some failures in messaging and sudoku, those are not new
<rvr> bzoltan_: But there are many failures for ubuntuuitoolkit.tests
<bzoltan_> rvr: if the logs say that "Same on archive" then it means that the failures are not new
<rvr> bzoltan_: ahh, I see
<bzoltan_> rvr: flakiness
<bzoltan_> rvr:  not fun
<rvr> bzoltan_: So, what's up with these?
<rvr> Ah
<rvr> Hmm
<rvr> But if "same on archive" means they can be reproduced
<bzoltan_> rvr: If rhe archive tests fail without  the silo then I do not care
<bzoltan_> rvr: NO, the "same on archiv" means that the same test has failed on the stock image... so it is not a regression. Regression is when a test is OK on the stock image but fails with the silo
<rvr> bzoltan_: But there is a chance that a regression was introduced in the archive
<bzoltan_> rvr:  and the possible regressions are marked as real regressions if they fail twice with the silo
<bzoltan_> rvr:  if the regression was introduced in the archive then it is a problem of whoever it introduced
<bzoltan_> rvr: people should do the same testing as I do ..
<rvr> bzoltan_: I'm talking about ubuntuuitoolkit.tests :-/
<bzoltan_> rvr: But I can not do much about regressions introduced between two UITK landings
<rvr> bzoltan_: There are 32 failures... it worrying
<rvr> it is
<bzoltan_> rvr: there is nothing new about those failures...
<bzoltan_> rvr:  see the previous landing -> http://people.canonical.com/~bzoltan/ap-2015_10_08-VIVID-SILO23-KRILLIN/MAIN-ap-2015_10_09-vivid-023
<rvr> bzoltan_: I see
<rvr> Someone should take a look and fix them, if they are consistent failures
<bzoltan_> rvr:  before that  the UITK AP tests were broken, but the logs are here http://people.canonical.com/~bzoltan/ap-2015_10_02-VIVID-SILO31-KRILLIN/uitk_test.logs - rev1658
<bzoltan_> rvr: I do not mean that those 32 failures are not problem... but for sure they  are not new problems.
<rvr> bzoltan_: Agreed on that
<bzoltan_> rvr: those are failures since longtime... we are working on to make them pass, but they are broken tests and not broken functionality
<bzoltan_> rvr: with the UITK test plan I look for regression
<rvr> bzoltan_: By the way, I found something weird this morning on Today scope in rc-proposed
<bzoltan_> rvr:  tell me
<rvr> bzoltan_: The ">" sign becomes big when scrolling
<bzoltan_> rvr:  wow
<bzoltan_> rvr: is that intentional
<rvr> bzoltan_: When it is near the title bar
<rvr> I don't know
<rvr> Hmm
<rvr> Cannot see it now in latest rc-proposed
<rvr> Well, then nevermind, I will open a bug if I can reproduce it
<bzoltan_> rvr: OK
<bzoltan_> rvr:  and about those 32 failures... i am pushing to fix them buy the next landing
<rvr> bzoltan_: Ok, thanks
<davmor2> bzoltan_: you have money to burn buying the next release
<rvr> Proceeding to test silo 55
<abeato> Laney, could not it land in the ppa overlay, for wily?
<Laney> abeato: does that exist?
<Laney> I don't know, that's not my decision :)
<abeato> Laney, the stable phone overlay has a wily pocket: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay
<abeato> Laney, I guess the packages there will be copied over when X starts
<bzoltan_> davmor2: :D do you have something interesting there what you are waiting for?
<rvr> dbarth: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1507667
<ubot5> Launchpad bug 1507667 in webbrowser-app (Ubuntu) "HERE conditions cannot be loaded" [Undecided,New]
<ogra_> lol
<ogra_> thats fallout of disabling the file:// protocol
<ogra_> rvr, can you check if the url actually starts with file:// ?
<ogra_> oh, it says so in the error page, heh
<ogra_> jdstrand, ^^^ can we add an exception to the browser apparmor profile for /custom/vendor/here/location-rpovider/ to make file:// work for the pages in there ?
<ogra_> quite an oversight :)
<rvr> Yup
<jdstrand> ogra_: sure. ask oSoMoN to add it
<rvr> bzoltan_: Silo 55 approved
<sil2100> jibel, davmor2, ogra_: I'm semi-off today, so no meeting in case you guys are on it
<ogra_> jdstrand, ah, i thought it is in apparmor-easyprof
<bzoltan_> rvr: \o/
<ogra_> sil2100, yeah
<davmor2> sil2100: cancellor
<jdstrand> ogra_: the webbrowser app ships a profile based on easyprof, but it is a deb so ships its own policy
<ogra_> ah
<dbarth> rvr: ack
<jhodapp> sil2100, any issues with landing https://code.launchpad.net/~phablet-team/qtubuntu-media/mediascanner-dependency-removal/+merge/274914 for wily right now?
<popey> jibel: I realise you are all super busy, created https://requests.ci-train.ubuntu.com/#/ticket/534 for clock app. contains a DST fix which we'd love to land in the store before the weekend (when DST happens in Europe)
 * popey sends hugs and kisses and cake and beer
<jibel> popey, okay
<jhodapp> jibel, do you know if there's any issues if I land https://code.launchpad.net/~phablet-team/qtubuntu-media/mediascanner-dependency-removal/+merge/274914 in wily right now?
<jhodapp> jibel, the mediascanner team needs this to get mediascanner from being stuck in proposed
<jibel> jhodapp, it is in universe, I don't think there is a problem to upload it to wily.
<jhodapp> ok great thanks
<robru> sil2100: slangasek: we doing the meeting today?
<jhodapp> robru, can you publish silo 18 please?
<robru> jhodapp: I can't if you can't
<jhodapp> oh ok
<robru> jhodapp: need a core dev nowadays
<jhodapp> kenvandine, I know you can, care to publish silo 18 for me please?
<jhodapp> robru, here I thought you had special access ;)
<robru> jhodapp: I used to but not any longer :-(
<jhodapp> bummer
<jhodapp> cyphermox, ping
<cyphermox> jhodapp: hello
<jhodapp> cyphermox, hey man, you still have core dev status, right?
<cyphermox> yes
<jhodapp> cyphermox, perfect, would you mind publishing silo 18 for me please then
<cyphermox> lemme look
<cyphermox> this is marked as landing to wily, is it absolutely critical?
<cyphermox> because I can publish but it doesn't mean it will be allowed through (not my call)
<jhodapp> cyphermox, it is, it will unblock mediascanner which is stuck in proposed
<robru> jhodapp: the thing is that wily is being released on thursday so people are hesitant to land stuff this close to the end if it's not some super-critical bugfix.
<jhodapp> robru, yeah this is super critical
<robru> jhodapp: is mediascanner used in the desktop in any way?
<jhodapp> it is
<robru> jhodapp: oh ok well if it's an important bugfix that affects the desktop then it should probably go in
<robru> cyphermox: ^
<jhodapp> robru, it's a low risk change anyway, just removes a dependency on a specific mediascanner version from qtubuntu-media
<robru> diff looks legit I guess
<robru> jhodapp: you should ask nicely in #ubuntu-release I guess, even if cyphermox does publish it's up to them whether it actually gets accepted or not
<jhodapp> robru, anyone to ping specifically?
<robru> jhodapp: I wouldn't ping anybody in there ;-) whoevers around tends to watch the IRC fairly closely.
<jhodapp> ok
<jhodapp> robru, if release doesn't accept it, where does that package live then?
<jhodapp> robru, some overlay?
<robru> jhodapp: yeah we can copy it to the stable overlay PPA where it'll be held until wily+1 opens and it'll get copied there
<jhodapp> robru, ok great
<jhodapp> cyphermox, let's at least do that now, publish so that it lands in the overlay PPA for wily
<robru> cyphermox: you have to edit the dest PPA in the request in order to do that
<robru> or I could just do it, heh
<robru> jhodapp: cyphermox ok I copied it to overlay ppa
<jhodapp> robru, ok so that's not automatic for wily, good to know
<robru> jhodapp: it's automatic for dual silos, but this isn't a dual silo.
<jhodapp> right
<jhodapp> robru, hope to fix that soon too by syncing gstreamer versions across vivid and wily
<robru> jhodapp: yeah the more we can do with dual silos the easier it is to manage everything
<jhodapp> robru, exactly
<jhodapp> robru, normally we don't have any code that relies on a specific version of gstreamer, but in this case that's not true
<robru> jhodapp: oh you wanna backport wily's gstreamer into vivid?
<jhodapp> robru, yep
<robru> that sounds like a big job ;-)
<jhodapp> held off on that for a bit because it was a dev version
<jhodapp> but now it's a new 1.6.x stable series in wily
<jhodapp> robru, shouldn't be too bad
<robru> cool
<Saviq> robru, thanks :)
<robru> Saviq: you're welcome!
<dobey> trainguards: can somoene please retry these builds? thanks. https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+build/8133720 https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+build/8133724
<robru> dobey: one sec
<dobey> robru: thanks
<robru> dobey: you're welcome
<alesage> robru, I've just passed 19 but noticed something fishy upon further examination--can I un-approve?
<robru> alesage: yeah
<alesage> robru ok, I'll edit the card/silo
<cyphermox> robru: jhodapp: I got from Laney that the fix for mediascanner got uploaded by Laney earlier, so the ci train upload wasn't necessary
<cyphermox> the change should get merged though
<cyphermox> (I have not verified any of this yet)
<robru> cyphermox: oh indeed, there's an upload from 4hrs ago and it's no longer in proposed
<robru> cyphermox: ok I'll merge
<Laney> I just removed the package dependency as the stuff wasn't built anyway, can land this more complete removal in X
<robru> Laney: sure thing, the silo is now merged to trunk so it'll be included in whatever the next release is, when X opens
<Laney> nod
<jhodapp> cyphermox, Laney, robru cool thanks guys
<robru> jhodapp: you're welcome
#ubuntu-ci-eng 2015-10-20
<robru> Sure is quiet
<robru> heh
<Mirv> jibel: I'm sad to say we're here again - sync-monitor has two commits from renato that were never built
<Mirv> sil2100: ^
<Mirv> if I see it correctly, those are removal of two debug message outputting and a whitespace fix
<Mirv> jibel: so if http://bazaar.launchpad.net/~renatofilho/sync-monitor/sync-by-acount/revision/59 seems safe, I could rebuilt it manually and publish without additional QA being involved since nothing functional changes
<Mirv> heh, I can't publish UITK because of a change I submitted
<robru> Mirv: yeah that code that checks those unbuilt revisions is something I poked at a bit recently, but I double checked and indeed some commits are legitimately not built
<sil2100> Maybe the upstreams can revert those commits?
<sil2100> If they're not important
<Mirv> sil2100: or that, that's why I was asking jibel which we he wants it
<Mirv> we can also do the revert
<Mirv> s/we/way/
<oSoMoN> rvr, good morning, are you going to take over https://trello.com/c/yanKnskV/2388-529-ubuntu-landing-010-webbrowser-app-osomon ?
<jibel> Mirv, if the 2 lines in the diff are the only changes, don't revert and push the change
<Mirv> jibel: ok, I'll rebuild it then and push it in (unless something else pops up)
<Mirv> and double-check the actual diff is as shown there
<popey> sil2100: I got OTA-7 on my retail krillin. it says "Install and reboot" but actually did "Install and shutdown". I had to power it back on myself. Seen that?
<Mirv> diff looks good http://paste.ubuntu.com/12875462/
<Mirv> popey: my retail krillin did reboot at least this morning
<popey> hm
<davmor2> popey: mine did reboot
<popey> not a ig deal. just odd
<popey> thought maybe the battery died, but it's ~60%
<oSoMoN> ubuntu-qa: is anyone looking at silo 10, or do I have to wait for alesage to get online?
<davmor2> oSoMoN: Alan will pick it back up I believe
<rvr> oSoMoN: If someone is looking at silo 10, you would see a face in its card
<oSoMoN> can I stick a âº on the card ? ;)
<popey> sil2100: seeing complaints that some people haven't had OTA-7 yet, is phasing complete?
<sil2100> popey: let me triple check, but it should have ended at night
<sil2100> popey: maybe those people  already upgraded yesterday?
<sil2100> I mean, last week
<sil2100> popey: confirmed that both arale and krillin are 100% phased percentage, so everyone should see the update
<popey> ok, odd.
<jibel> sil2100, did you reenable daily builds for rc-proposed?
<jibel> sil2100, last build on arale is Oct 16th
<sil2100> jibel: hm, I thought I did, let me confirm
<sil2100> jibel: ok, it got reverted, re-enabled again
<sil2100> And kicked a manual build
<oSoMoN> sil2100, on a (probably) related note, see my e-mail to ubuntu-phone, did you re-enable it for krillin as well?
<jibel> oSoMoN, there is no new build for krillin either
<sil2100> oSoMoN: now it should be properly re-enabled - and the delta you mention is normal as we had an OTA-6-based image kicked in rc-proposed
<jibel> since 16th
<sil2100> oSoMoN: your image no 149 is a bit old, #151 was 'going back in time' to OTA-6
<sil2100> Then 152 was back to future
<oSoMoN> sil2100, okay, so updating now will get me a recent image, not an old one, right?
<jibel> oSoMoN, when did you receive the notification that 152 was available?
<sil2100> oSoMoN: yeah, recent one, although I'm building an even more recent image now
<oSoMoN> jibel, a few days ago, but I held off updating because it seemed like a big update, so I was waiting for the dust to settle
<jibel> ah okay
<oSoMoN> Iâll wait for 153 thatâs currently building then, Iâm not in a hurry
<rvr> boiko: I need read permissions in the click packages of  silo 11
<boiko> rvr: oups, sorry, let me fix that
<rvr> sil2100: popey: I haven't got any notification update for OTA7 yet in my personal krillin
<boiko> rvr: hmm, all packages are set with read permissions for everybody already
<rvr> Oh, chinstrap
<sil2100> rvr: huh?
<sil2100> rvr: what image are you on?
<rvr> sil2100: 25
<sil2100> rvr: what if you poll manually in system-settings?
<rvr> sil2100: Only file manager available
<sil2100> hm, not good, I wonder if it's something wrong with the client and percentage handling
<sil2100> We need barry to help out here
<sil2100> rvr: I suspect the problem might also be in people receiving the notification last week already
<sil2100> rvr: could you reboot your phone, want to check if that helps
<rvr> Rebooting
<rvr> boiko: I used wget instead the browser to download the click packages, everything's fine
<boiko> rvr: ah yeah, you need to authenticate
<rvr> sil2100: Downloading
<rvr> sil2100: I didn't get notification, but new image is available in Update settings page
<sil2100> rvr: you would probably get the notification after it's downloaded
<sil2100> Eh, we'll have to inform people to reboot their phones to get the update ;/
<rvr> Let me reboot again and wait a little bit more without installing the update
<sil2100> pmcgowan: hey, I have a theory that krillin users that got the last-weeks OTA-7 update notification but didn't manage to update might not get the notification without rebooting their phones
<pmcgowan> sil2100, does the phone home happen only on reboot or also when network comes up
<sil2100> pmcgowan: not sure, but I suppose that system-settings remembers that it got an invalid notification for image #26 and doesn't recognize the proper image #26 as appearing - rvr said that a reboot fixed it
<rvr> I have network
<pmcgowan> sil2100, it would be the system image code if anything
<renatu> sil2100, jibel, hi, I noticed that silo 19 was merged thanks. Do you know if it will be part of next dev image?
<pmcgowan> I could see how it would retain the state util a reboot
<rvr> but the notification doesn't appear ... still waiting, maybe eventually
<sil2100> rvr: did it download the image already?
<rvr> sil2100: I stopped it
<sil2100> rvr: you won't get a notification before it's downloaded
<rvr> sil2100: But at least appears in the Updates page
<rvr> sil2100: ??
<sil2100> rvr: IIRC the update notification only appears when the image is fully downloaded
<pmcgowan> rvr, sil2100 depends on the auto download setting
<pmcgowan> if auto is off you will get it before downloading
<rvr> Automatic download... using wifi
<rvr> I'm in wifi
<pmcgowan> rvr, I think it wont reload it now that you stopped it
<pmcgowan> sil2100, your theory sounds plausible, we can confirm with barry
<sil2100> rvr: in that case it's as pmcgowan said, you won't get a notification if it doesn't download completely
<pmcgowan> sil2100, but manually checking I would expect to work
<sil2100> But anyway, seems like reboot helped
<sil2100> pmcgowan: rvr said it didn't help ;/
<Mirv> renatu: sure it will part of the next image that will be build in roughly 12h
<sil2100> Seems like indeed something not handled too well in either system-settings or the system-image client itself
<renatu> Mirv, ok thanks. I will send a e-mail to the ML
<pmcgowan> sil2100, admitedly though this case shouldnt happen
<sil2100> pmcgowan: true, again sorry for that
<sil2100> Won't happen next time
<sil2100> But I'm thinking if we should maybe send out an announcement somewhere about rebooting
<pmcgowan> sil2100, you could say if someone hasnt seen a notification by now they should manually check or reboot
<pmcgowan> or maybe just reboot if manual doesnt work
<sil2100> Yeah, I might send out a quick one about that somewhere
<jibel> rvr, when you didn't get a notification, is there anything interesting in system-settings' logs?
<jibel> sil2100, did you trigger a new build.
<jibel> ?
<sil2100> jibel: yes
<jibel> sil2100, should it be on https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/ ?
<sil2100> hmmm
<sil2100> I have no idea what's happening
<rvr> jibel: I didn't check the logs
<sil2100> Maybe it's blocked due to the wily images being built?
<sil2100> Looks like cdimage just ignored building the image
<sil2100> I need to check the logs
<sil2100> jibel, rvr: let me poke cdimage again, I don't see anything in the logs
<Mirv> kenvandine: could you publish UITK https://ci-train.ubuntu.com/job/ubuntu-landing-055-2-publish/10/ , one new build dep just added?
<kenvandine> Mirv, sure
<Mirv> kenvandine: thanks!
<kenvandine> Mirv, np
<sil2100> jibel: ok, looks like it's building this time
<jibel> sil2100, good, thanks
<balloons> fginther, josepht I've had some trouble getting the tarmac examples to work on my instance. Can someone set aside a little time to help me out today?
<josepht> balloons: we should be able to make a bit of time for you.  We have a cluster of meetings in the late morning and early afternoon (EDT)
<rvr> boiko: ping
<boiko> rvr: pong
<rvr> boiko: I have found two problems in silo 11 so far
<rvr> boiko: First one, timestamps
<boiko> salem_: ^
<rvr> boiko: On the messaging-app main screen, old timestamp appears after changing the timezone and restarting the app
<rvr> boiko: Second one, history-daemon is started on boot
<boiko> rvr: the starting on boot thing is expected, forgot to update the testplan, now it generates some cached content on boot
<boiko> rvr: sorry for that
<rvr> boiko: Ok
<salem_> rvr, hm, the timestamp issue is tricky. I will have a look. thanks.
<boiko> rvr: ok, can you just put the testing on hold while we check the timestamp issue you found?
<rvr> boiko: Yup
<boiko> rvr: meanwhile I will update history-service's testplan
<rvr> boiko: Thanks
<abeato> sil2100, I cannot publish silo 16 to stable-phone-overlay, I'm not authorized for qtmultimedia-opensource-src
<sil2100> abeato: I think we'll either need a core-dev or Mirv ;)
<sil2100> Mirv: ^
<abeato> sil2100, yep, looks like that :)
<oSoMoN> alesage, when you get online, please ping me re- silo 10, thanks!
<jgdx> dbarth__, hey, I thought we decided I would land mardy's facebook removal. :)
<Mirv> abeato: sil2100: publishing
<jgdx> rvr, could you maybe put a block on [435] ubuntu/landing-024 - account-polld for now? Silo 21 has this change, as well as some other goodies. /cc dbarth__
<Mirv> kenvandine: can you btw also perhaps top approve https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.wily_add_qt5-image-formats-plugins/+merge/274882 (needs core dev) so that QA can check the silo? it's not actually going to land to wily archive as such, the silo has wily + vivid for the overlay.
<rvr> jgdx: Do you want it to block or to remove it?
<jgdx> rvr, block until we hear from dbarth__?
<rvr> jgdx: Ack
<jgdx> rvr, thanks :)
<rvr> And done ;)
<kenvandine> Mirv, done
<Mirv> kenvandine: thanks again
<dbarth__> jgdx: yes, is there still a silo conflict?
<jgdx> dbarth__, silo 24 vs 21
<dbarth__> jgdx: ah ok
<dbarth__> jgdx: silo 24 abandonned
<jgdx> dbarth__, thanks
<abeato> Mirv, thanks!
<boiko> rvr: just verified here, the timestamp thing is just a behavior change because history-daemon is being started on boot now
<boiko> rvr: so for testing, instead of rebooting and then changing the timestamp, you can change the timestamp and then reboot
<boiko> rvr: in any case, I reported #1508074 to improve this behavior in the long run
<boiko> rvr: so, if those were the only things you found wrong in the silo, it is good to go
<rvr> boiko: Nope, I stopped testing there
<rvr> boiko: The problem can be considered a regression, since the current expectation is that no reboot is needed
<rvr> boiko: So, either the problem is fixed or a dialog is presented to force a reboot
<Trevinho> trainguards, why indicator-session and unity in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-042/+packages doesn't get the proper changelog lines or bugs
<Trevinho> MPs are
<Trevinho> https://code.launchpad.net/~unity-team/unity/trusty-sru-7.2.6/+merge/274599 and https://code.launchpad.net/~azzar1/indicator-session/lp-1460626-trusty/+merge/261087
<rvr> robru: Hi
<rvr> robru: rhuddie needs QA powers in  bileto
<rvr> robru: How can add him to the team?
<rvr> sil2100: ^
<jibel> rvr, sil2100 I signed it off on behalf of rhuddie
<jibel> popey, ^ clock approved
 * popey runs up to jibel and gives him a bit wet sloppy kiss
<popey> Thanks!
<rvr> jibel: Ok
<rhuddie> jibel, thanks
<davmor2> popey: it's rhuddie that should get the big sloppy kiss he did the work ;)
<popey> I'll let jibel pass it on
<jibel> dbarth__, jgdx there are 2 account-polld silos 21 and 24, would it be possible to merge them so we don't do the verification twice?
<jgdx> jibel, silo 24 is abandoned and I asked for a block on the associated card.
<jgdx> jibel, it can probably be deleted by now
<jibel> jgdx, even better :) thanks
<dobey> trainguards: could i get someone to take the branch in https://code.launchpad.net/~dobey/whoopsie-preferences/no-get-ui/+merge/275056 and tweak the version to "0.19~15.04.1" or something, to upload to landing-026 silo?
<dobey> for the vivid series
<boiko_> rvr: well, nowadays a reboot is already required, if you follow the testplan, you reboot and then change the locale
<boiko_> rvr: if you had opened messaging-app already and try to change the locale, closing messaging-app and reopening won't help
<rvr> boiko: The locale, no the time zone
<boiko_> rvr: sorry, I meant the timezone
<rvr> boiko: I tested this morning in OTA6, and didn't require a reboot
<boiko_> rvr: try on a stock image: open messaging-app, close it, change timezone and reopen it
<rvr> Restarting messaging app worked
<boiko_> rvr: really? it shouldn't, but let me give it a try
<boiko> rvr: nevermind, you were right, history-daemon was getting the new timezone correctly (I thought it wouldn't, but it does)
<boiko> rvr: we will fix this regression
<rvr> boiko: Ok, I am moving the silo to failed
<boiko> rvr: thanks
<balloons> josepht, what time are you thinking this afternoon?
<josepht> balloons: how does 2:30 work for you?  fginther: you too
<josepht> balloons, fginther: that's EDT, btw
<fginther> josepht, works for me
<rvr> jgdx: ping
<balloons> josepht, i might not be back on time.. Might need to be 1500.. But i'll try and ping if so
<jgdx> rvr, pong
<jgdx> rvr, could you give me the whole .log?
<jgdx> that wakelock value is a bit random, I should've left it blank or <true/false>
<jgdx> (not random, but for the sake of that particular test, it doesn't matter)
<josepht> balloons: ack.
<josepht> fginther: how about 3:00?
<fginther> josepht, that works
<josepht> balloons, fginther: updated invite sent for 3:00
<Mirv> cihelp: can you enable auto-merger for  lp:ubuntu-sdk-ide for zbenjamin / bzoltan_ ?
<bzoltan_> Mirv: thanks
<jgdx> rvr, I've changed the test. We don't want to test wakelock in Test 3, but rather in a new test. I've added a TODO.
<rvr> jgdx: I see
<rvr> jgdx: But it's also wakeupReq
<rvr> jgdx: https://pastebin.canonical.com/142204/
<jgdx> rvr, yeah, that too.
<jgdx> rvr, what we changed is how informed push-client's âpollerâ is of the connectivity state. So the important thing is that FM, no wifi and good wifi works as expected (no poll, no poll, poll).
<jgdx> I wish we could have a test case for when NetworkManager says "you're connected to the Internet", but you carrier says "to Internet-insert coin"
<rvr> lol
<rvr> jgdx: Then it's good
<jgdx> sweet
<rvr> jgdx: Silo approved
<robru> Trevinho: it's because you used "trusty" instead of "UNRELEASED" in your changelog
<Trevinho> ouch
<Trevinho> that was the one we had, I'll fix them
<Trevinho> robru: oh, actually unity changelog has UNRELEASED... You meant the other way around?
<robru> Trevinho: no it needs to be UNRELEASED. I don't see the problem with the unity changelog but the other one is clearly wrong with "no change rebuild"
<robru> dobey: im not sure why your asking for that. Why can't you just put that mp in the silo and build it?
<Trevinho> robru: https://code.launchpad.net/~unity-team/unity/trusty-sru-7.2.6/+merge/274599 has UNRELEASED, but still the changelog is missing some bug links
<Trevinho> and I'd love to avoid to do one branch for each bug packported
<Trevinho> err, fix backported :P
<dobey> robru: because it's a native manually uploaded package in the archive and not managed by the train
<dobey> robru: so the build job will just fail and complain about the version being wrong in the changelog
<dobey> robru: anyway, i just made lp:~dobey/whoopsie-preferences/no-get-ui-15.04 which has the changes to debian/changelog necessary to build it in vivid as a backport, if you could just bzr bd -S that one and then  upload it to landing-026 PPA, that'd be awesome
<Trevinho> or well, I could fill the changelog manually...
<robru> Trevinho: I'm not sure what's wrong with your changelog. It should be that if you touch the changelog by hand it preserves everything so I'm not sure why the one in the silo diverse from your mp at all. You'll have to fill out whatever you think is missing by hand
<Trevinho> ok, thanks
<robru> dobey: well why not onboard it for train usage now? It'll be easier than doing manual sources every time
<dobey> robru: i am not the maintainer, so i don't want to step on their toes to do that, and turn myself into sisyphus perpetually pushing boulders up hills by trying to do it
<robru> dobey: OK one sec I just need coffee
<dobey> robru: sure. thanks
<robru> dobey: ok it's uploaded, you can run the build job
<dobey> robru: ok, thanks much
<robru> dobey: you're welcome
<balloons> josepht, thanks. And in the end, I made it on time :p
<balloons> if you'd rather go early, can do
<josepht> balloons: we'll wait until 3:00 if that's okay.  Our meetings went long
<balloons> yep
<robru> cihelp: https://jenkins.qa.ubuntu.com/job/cu2d-choo-choo-autolanding/310/console s-jenkins is in a bad way
<alecu> hi trainguards! Are packages with debugging symbols created for packages landed in the overlay? Is there somewhere to find them?
<robru> alecu: I believe they are, yes.
<robru> alecu: what package?
<alecu> robru: I'm looking for these two: libmediascanner-2.0-3-dbgsym mediascanner2.0-dbgsym
<robru> alecu: I see libmediascanner-2.0-4-dbgsym in there
<fginther> robru, can you top-approve that MP again? The node that job ran on went bye-bye
<robru> alecu: oh libmediascanner-2.0-3-dbgsym is there for vivid. -4 is in wily
<alecu> robru: ah, I just needed to click on "View package details"....
<robru> fginther: sorry I was in a rush to get that in in time for the cron job that pulls trunk into production, thanks for looking at it though
<robru> fginther: will let you know if the next branch still has issues
<alecu> robru: so, the right way is to download those packages, and manually install them, right? there's no way to add the ppa, or something, right?
<robru> alecu: what are you trying to do exactly? the overlay PPA should be enabled by default in silos (and if not, the citrain script enables it)
<robru> alecu: I mean the overlay PPA should be enabled by default in phone images.
<alecu> robru: right: I've got a clean phone, just installed with OTA-7, no silos. And I'm trying to install the debug symbols for a package I want to debug
<alecu> robru: so I enable rw, do an apt-get update, and then try to install the -dbgsym packages, but they are not found.
<robru> alecu: ok, if you're not working on a silo then you'll want to make the root image readable, make sure overlay PPA is enabled, then you can install that package you want.
<robru> alecu: I'm not sure why it wouldn't be found...
<robru> alecu: I guess you'll have to download the deb manually, I don't know much about this dbgsym stuff
<robru> alecu: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+files/libmediascanner-2.0-3-dbgsym_0.107%2B15.04.20150922.1-0ubuntu1_armhf.ddeb
<alecu> robru: no worries, I can do that manually. Thanks anyway for helping me find it!
<robru> alecu: you're welcome
<Trevinho> robru: about the new landing feature, does it detect --overwrites? I mean, does it use the commit id or the commit number as reference?
<robru> Trevinho: it uses the commit id ;-)
<oSoMoN> alesage, still around?
<alesage> oSoMoN, yes here
<oSoMoN> alesage, so the issue thatâs affecting your testing of silo 10 (webbrowser-app) on desktop has been identified, itâs https://bugs.launchpad.net/oxide/+bug/1508054
<ubot5> Launchpad bug 1508054 in webbrowser-app (Ubuntu) "[desktop] Crashes on startup with wily+overlay" [Critical,Confirmed]
<alesage> oSoMoN, yep, seeing that
<oSoMoN> alesage, a fix is in the works, can IÂ suggest we donât block on this to validate the silo. if your testing is satisfactory on a touch device, that should be good enough IÂ think
<alesage> oSoMoN, IIRC the features I'd be testing were layout features destined for the desktop proper
<oSoMoN> alesage, they can also be tested on a nexus 7 in landscape orientation, if you have one handy
<alesage> oSoMoN, am I unlucky in being affected by the crash bug?  or would another QE maybe miss it?
<oSoMoN> alesage, no, IÂ think the bug should affect everyone regardless, itâs puzzling that we havenât hit it earlier
#ubuntu-ci-eng 2015-10-21
<ToyKeeper> robru: If you're around, could you mark silo 41 / ticket 500 as qa-passed?  It's not letting me save changes at the moment...
<robru> ToyKeeper: are you getting an error?
<ToyKeeper> robru: Yes, I just need to check my team memberships and login session.  SSO didn't send the required team marker.
<robru> ToyKeeper: oh OK. Should work if you log out and log back in. I can set it for now though
<ToyKeeper> I should be able to get it working eventually.  :)
<ToyKeeper> (am pretty familiar with SSO's internals and protocols)
<robru> ToyKeeper: has it been a while since you used it? I think I did shuffle around which team memberships were needed a few weeks ago or something.
<robru> done ^
<ToyKeeper> robru: Yes, I've been on other projects.  Now filling in for Dave for a week or so.
<robru> ToyKeeper: yeah could be then. when you log back in just make sure all the teams are checked (they should be checked by default, too)
<ToyKeeper> sil2100: If you're around, could you add me to lp:~ci-train-users ?
<sil2100> ToyKeeper: sure, one moment
<sil2100> ToyKeeper: done :)
<ToyKeeper> Thanks!
<sil2100> yw!
<robru> ToyKeeper: yep, being in the right team would help, sorry i forgot to check that
<tvoss> trainguards, I would like to land silo 19 to wily overlay, jibel sent me here
<robru> tvoss: edit the request to set the overlay as the destination then click publish
<Mirv> tvoss: dbus-cpp? you say it's Ready for QA which means it's already in the QA queue so actually jibel's team will probably pick it up unless there's a problem with it
<Mirv> tvoss: ah, wily...
<tvoss> Mirv, yup
<Mirv> tvoss: then the correct setting is "Publish without QA" instead. ok, I can set the overlay for you.
<tvoss> Mirv, ack
<jibel> Mirv, yeah wily, it's either an SRU at this point or wily+1 if the fix is not needed in wily
<tvoss> jibel, not a fix, just a sync
<jibel> s/fix/sync/ sorry :)
<tvoss> Mirv, do you take care of the changes then? Or do I need to do something?
<Mirv> jibel: can you unblock 014 btw on trello, MP both approved and top-approved now (even though will not actually be merged to the wily branch, it will go to overlay via PPA's manual uploads at this point)
<Mirv> tvoss: I changed everything already, nothing needed anymore
<tvoss> Mirv, thx
<Mirv> tvoss: for publishing, we need a core-dev unfortunately so it'll take some time. otherwise ready for publishing.
<jibel> done
<Mirv> thanks
<dbarth__> hi trainguards, there is a new oxide release for upload to silo 6; please take 1.10.3 from the ubuntu-mozilla-security ppa
<sil2100> dbarth__: hey! A source rebuild is needed as always?
<sil2100> dbarth__: both wily and vivid?
<dbarth__> sil2100: yes correct, source copy please
<dbarth__> yes, both please
<sil2100> dbarth__: downloading and re-packaging
<popey> jibel: another click for you at https://requests.ci-train.ubuntu.com/#/ticket/544 :)
<popey> jibel: this one doesn't have a priority at all.
<jibel> popey, what are the cahnges?
<jibel> changes*
<popey> jibel: complete redesign
<popey> UI wise
<popey> jibel: i know davmor2 reviewed it recently and asked us to fix a couple of things (which we did)
<popey> but I guess he/you guys are all super busy, so it's fine to be bottom of the list
<davmor2> popey: jibel: I can probably hit it friday once the desktop is released
<popey> Good to finally get this done and get rid of the old app :)
<popey> Thankfully I can say the design of the old app sucked because the people who designed it no longer work for us ;)
<jibel> davmor2, it also means updating our regression test plan
<jibel> popey, are there results of automated tests for the new weather app somewhere?
<sil2100> dbarth__: the packages take a while to upload with my current connection, but I'm on it
<dbarth__> sil2100: ty
<popey> jibel: the latest merge passed in jenkins... http://91.189.93.70:8080/job/ubuntu-weather-app-reboot-ci/282/console
<popey> jibel: I can re-run locally if you want?
<jibel> popey, it would help to have the results of automated tests even re-run locally on latest image
<popey> jibel: okay, I'll do that and update the ticket
<jibel> thanks
<popey> np
<jgdx> popey, I wanted to try the weather click. It doesn't start. Anything I need to do?
<popey> jgdx: pull down refresh click scope and try again?
<popey> I tested it here before uploading it
<jgdx> popey, there we go
<jgdx> beautiful
<jgdx> can't find the amount of precipitation, though :p
<jgdx> an important metric in western Norway
<popey> jgdx: tap the massive number where it says the temp
<popey> it will expand and show "chance of rain"
<popey> we're somewhat limited in that we can only show what the 3rd party api gives us
 * popey just saw 0% chance of rain and thought "Yay" then realised I was looking at the weather for Cairo :)
<popey> 20%.. UK that's more like it
<ogra_> at least you have weather at all :P
<ogra_> (my scopes only seem to show it randomly based on cosmic rays ... )
<jgdx> popey, wait, is that the row with the drop-like icon?
<jgdx> that's translated to âfuktighetâ in Norwegian, which usually means air moisture. hmm
<mterry> sil2100, you mentioned a possibly more official channel for mako devices than bq-aquaris.en?
<mterry> (in an email)
<ogra_> well, the official channel is /ubuntu
<ogra_> but that doesnt contain the HERE providers
<sil2100> Yes
<sil2100> I'll be creating one and the tarball, as I have the infra for that now
<sil2100> But that a bit later
<mterry> ogra_, right, so no one uses it  :)
<mterry> I think there was an ubuntu-customized at one point?
<mterry> Maybe it's still there, but I don't know how updatd
<mterry> sil2100, cool.  I have a mako and am debating if I just update to rc-proposed or wait  :)
<rvr> jgdx: Is this right? http://paste.ubuntu.com/12885639/
<jgdx> rvr, need some context.. what test?
<rvr> jgdx: Silo 21, account-polld
<jgdx> rvr, did you change pwd for acc 3?
<rvr> jgdx: Yes
<jgdx> rvr, it looks good. You can also trigger polls by using gdbus call --session -d com.ubuntu.AccountPolld -o /com/ubuntu/AccountPolld -m com.ubuntu.AccountPolld.Poll
<jgdx> rvr, anyway, before this fix, the output would be flooded with messages of token expiry and new data from acc 3.
<rvr> jgdx: So looks good?
<jgdx> yep
<rvr> jgdx: 2015/10/21 13:32:55 3 auth failures in a row for account 3 -> skipping it for the next 10 poll cycles
<jgdx> rvr, perfect
<rvr> jgdx: Silo approved
<jgdx> rvr, thanks!
<Mirv> kenvandine: tvoss will appreciate if you look at publishing his dbus-cpp https://requests.ci-train.ubuntu.com/#/ticket/536
<kenvandine> Mirv, i'll look at it
<kenvandine> Mirv, a no change rebuild that adds the symbols files?
<tvoss> kenvandine, yup
<tvoss> kenvandine, cleaning up branches that did not get landed properly after the gcc 5 transition for wily
<kenvandine> tvoss, so that's intentional?  i'll publish it then
<kenvandine> cool
<kenvandine> tvoss, the branch hasn't been reviewed yet
<tvoss> kenvandine, let me see
<kenvandine> https://code.launchpad.net/~thomas-voss/dbus-cpp/fix-1452322/+merge/265627
<oSoMoN> alesage, I commented on https://trello.com/c/yanKnskV/2388-529-ubuntu-landing-010-webbrowser-app-osomon with a way to temporarily disable the apparmor confinement of webbrowser-app so that you can proceed with validation of the silo, until bug #1508054 gets fixed
<ubot5> bug 1508054 in apparmor-easyprof-ubuntu (Ubuntu) "[desktop] Crashes on startup" [Critical,In progress] https://launchpad.net/bugs/1508054
<tvoss> kenvandine, yup, you are unfortunately right, sorry.
<kenvandine> np
<jdstrand> oSoMoN: we can't fix that in apparmor easyprof
<jdstrand> oSoMoN: not in a stable update. it will regenerate all apparmor policy for webapps
<jdstrand> oSoMoN: which is a time consuming operation
<oSoMoN> jdstrand, how can we proceed then? other apps embedding a webview are going to hit the same issue, Iâd think
<jdstrand> oSoMoN: it can be fixed in the 16.04 policy
<jdstrand> oSoMoN: the phone is fine
<oSoMoN> yes, the issue is desktop-specific
<jdstrand> oSoMoN: what other apps are you talking about?
<jdstrand> oSoMoN: personal will use the 16.04 policy, which can be fixed
<oSoMoN> jdstrand, I donât have any specific example, I guess any app with a webview that runs confined, on desktop, will get the denials
<jdstrand> so, I think the path forward is fix webbrowser-app today (use write_path) and then have the 16.04 policy fix this
<jdstrand> oSoMoN: yes, but those things don't run on the desktop today
<jdstrand> they will in personal
<jdstrand> but personal isn't until 16.04 or later
<oSoMoN> jdstrand, ok, Iâll do that then, thanks for the feedback
<jdstrand> np
<jdstrand> oSoMoN: I took the liberty of retriaging the bug
<oSoMoN> jdstrand, you did well
<kenvandine> Mirv, i approved it and published
<Mirv> kenvandine: thanks, so it looked but as a main package required a core-dev
<Saviq> robru, hey, not necessarily sure if (or where) it's a bug, but found an issue with how citrain tool leaves the device (most likely priorities) - after installing silo 22 I could not install unity8-autopilot without also passing libdpkg-perl or so (will confirm in a sec)
<Saviq> robru, actually, unping, this seems to have a been a temporary problem
<Saviq> robru, owait, reping - it's a wily issue inded
<Saviq> grrr is there a UITK in progress of being released?
<alesage> oSoMoN, ack, able to test shortly
<Saviq> robru, http://pastebin.ubuntu.com/12886091/
<oSoMoN> alesage, excellent, and note that I have just submitted a fix for bug #1508054, so it will go in the next webbrowser-app silo
<ubot5> bug 1508054 in webbrowser-app (Ubuntu) "[desktop] Crashes on startup" [Critical,In progress] https://launchpad.net/bugs/1508054
<dobey> trainguards: can someone delete a manually uploaded package from a silo ppa please?
<dobey> Mirv: are you still around?
<seb128> dobey, I can do that I guess?
<dobey> seb128: maybe
<dobey> seb128: can you delete whoopsie-preferences from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+packages please?
<seb128> dobey, done
<dobey> seb128: great, thanks!
<seb128> yw!
<seb128> what was wron with it?
<dobey> seb128: it's not a necessary change, and doesn't work like i thought it would. it's been a long time since i've had to deal with policykit and i didn't understand what it was doing
<seb128> dobey, ok, I was just curious since the bug/mp don't have updates about the change being incorrect
<dobey> seb128: i changed the mp too
<seb128> thanks
<rvr> dbarth: In silo 2, Â«Also, craft a webapp with a new .account file and check that the hooks are still executed to produce the .application/.service files in ~/.local/share/accounts/Â». Can you explain that?
<oSoMoN> alesage, have you been able to test silo 10 on desktop with the workaround I suggested?
<alesage> oSoMoN, just beginning :) , more news in a bit
<oSoMoN> thx
<boiko> rvr: silo 11's regression is fixed and ready for a new round of testing
<rvr> boiko: Ack
<robru|sick> Saviq: are you trying to install something from the archive after installing a silo? That would be expected as the curtain tool uses apt pinning to disable the archive. Delete /etc/apt/preferences.d/* if you want to go back to normal apt behavior
<Saviq> robru|sick, actually no, install from silo + dependencies from overlay/archive
<Saviq> so thought that should Just Workâ¢
<Saviq> robru|sick, not a big deal, feel better
<robru|sick> Saviq: yeah that's weird, if the package is in the silo it should work
<robru|sick> Thanks
#ubuntu-ci-eng 2015-10-22
<tvoss> trainguards, I would like to have https://requests.ci-train.ubuntu.com/#/ticket/548 landed to wily overlay
<robru|sick> tvoss: if you set the destination ppa to the overlay you can click publish on it
<robru|sick> tvoss: there's a dropdown menu you can select the overlay from, just double click in the field
<tvoss> robru|sick, ah, so wily + overlay ppa
<tvoss> cool, let me try to hit publish :)
<robru|sick> tvoss: looks good
<tvoss> ah, I'm not authorized to upload :)
<robru|sick> Ooooh
<robru|sick> tvoss: you need a core dev then, I'm afraid i can't help you there
<tvoss> robru|sick, ack and thx
<robru|sick> tvoss: you're welcome
<tvoss> robru|sick, and get well soon :)
<robru|sick> tvoss: thanks, will sleep it off tonight
<Saviq> sil2100, re: translations, I don't think there's really any other way, translators should use rc (if we start using it as actual rc), we need a string freeze @ which point we release to rc, give translators a few days to do translations and start testing then
<sil2100> Saviq: yeah, but I don't want to force translators to have to use rc even at best... since even though it's safer than rc-proposed, the first images we build in rc will be untested, so they could have some issues on their main phones
<Saviq> sil2100, how else are they supposed to see new, untranslated, or changed, strings
<Saviq> sil2100, otherwise you release untranslated images to users
<jibel> sil2100, I agree with Saviq there is no other way than using a pre-release image
<Saviq> sil2100, if we treat translation changes as "safer", you could update just the langpacks post-testing
<seb128> we could also publish a list of new strings in the coming ota
<seb128> but it would mean keeping track of string changes
<Saviq> seb128, well, should be easy to get .po diffs
<Saviq> seb128, but, it's not just about the strings
<sil2100> seb128: we already do something like that, since LP has the new strings earlier - the problem is that they do not know the context of some of the strings
<Saviq> exactly, or how much space they have
<jibel> seb128, right but without context and the layout on the phones it's hard to figure out what the translation should be. The physical space on the screen is a hard constraint
<seb128> there is not one phone and screen size though
<seb128> so that's not really an argument
<Saviq> well, 40GU is our smallest target
<seb128> right, so now you change from "test on your device" to "test on a 40GU"
<seb128> ideally the emulator would make that easy
<Saviq> if it wasn't as slow as it is... but sure, I treat the emulator == device
<Saviq> but I'm probably slightly different than community folk just trying to help, not brick their phones
<rvr> mardy: ping
<mardy> rvr: pong
<rvr> mardy: Hey
<rvr> mardy: Silo 2
<rvr> mardy: Â«I have created a Google account. I have granted access in System Settings > Accounts to both YouTube and Contacts. Two issues: YouTube scope doesn't hide the "Log in YouTube" buttonÂ»
<rvr> mardy: Â«Clicking in "Import contacts from Google" opens the Google login dialog to introduce the credentials.Â»
<mardy> rvr: brb, got to reboot
<mardy> rvr: ok; the second one seems normal
<mardy> rvr: what happens when you tap on the Log in Youtube button?
<rvr> mardy: Even though the account has been created and permission granted?
<mardy> rvr: wait, does it asks you to authorize a service, or to enter your credentials?
<rvr> mardy: Yes
<rvr> mardy: The button doesn't do anything, apparently
<rvr> It reloads the page, but doesn't go away
<mardy> rvr: can you please try without the silo?
<Saviq> brendand, kudos on picking up the behemoth silo ;), let me know please if you have any questions
<brendand> Saviq, np i'm currently filling my armory
<brendand> let's see, assault rifle, check. grenades, check. 8 inch hunting knife, check
<brendand> body armour, check
<Saviq> :)
<Saviq> trainguards, https://requests.ci-train.ubuntu.com/#/ticket/445 somehow got SILO DIRTY for unity8, even though I rebuilt it yesterday and no one released unity8 in the mean time
<Saviq> oh ok, duflu merged trunk... bad timing
<Saviq> is this going to be a problem for publishing?
<sil2100> Saviq: silos now can also be marked as dirty if someone pushes a new commit to any of the branches - anyway, so did anyone release unity8 in the end, or is it that case right now?
<Saviq> sil2100, one of the branches got a trunk merge after it was built in the silo, so there's no change really
<Saviq> sil2100, we can safely ignore that commit
<Saviq> sil2100, just not sure what the result's gonna be when publishing (should I WATCH_ONLY?)
<sil2100> Saviq: hmm, good question, might cause some problems
<sil2100> Saviq: try watch-only, but with all the recent changes that Robert made I'm not sure if watch-only does what it was doing in the past anymore
<rvr> mardy: Same without the silo
<mardy> rvr: that's kind of good news :-)
<Saviq> sil2100, it'll likely just go back to dirty the next time it does the checks... but let's try
<mardy> rvr: rc-proposed?
<rvr> mardy: Good news for the silo, but it's not working as expected
<rvr> mardy: Yes
<rvr> If I granted permissions to Contacts, why does it ask again? And YouTube scope seems broken.
<mardy> rvr: since it's already landed, can you please file a couple of bugs?
<mardy> rvr: one is the local permission to use the account, the other one is Google request to authorize the app -- but I'll check
<Saviq> sil2100, actually, watch_only didn't clear the flag, let's see what happens
<rvr> mardy: In Contacts, the dialog to fill the Google account credentials is displayed
<mardy> rvr: mmm... I tried just now: deleted the account, re-created, enabled contacts from system settings:
<mardy> rvr: the transfers indicator showed an error, with "tap to retry" suggestion
<mardy> rvr: I tapped, it retried, and it worked, with no question asked
<mardy> rvr: can you tell me exactly your steps?
<rvr> mardy: 1. System Settings > Accounts > Create Google Account.
<rvr> mardy: 2. Edit account to grant permissions to Contacts and YouTube
<rvr> mardy: 3. Open Contacts, click on Import contacts from Google
<rvr> mardy: At this point, the Google login page appears
<mardy> rvr: don't you get the transfer icon in the indicators, as soon as you enable Contacts in the account?
<rvr> mardy: Yes
<rvr> mardy: But no error
 * Mirv freeing up 10GB of PPA space :)
<mardy> rvr: that's weird, so there is a working sync after creating the account, but it doesn't work from the calendar app...
<mardy> rvr: did you install the first version of buteo landing, which was later reverted?
<rvr> mardy: I'm latest using rc-proposed
<rvr> I'm using latest rc-proposed
<mardy> rvr: yes, but I mean, if you once installed that (broken) silo, the accounts.db file might still contain wrong infos
<mardy> rvr: unless you wiped the device
<rvr> mardy: The device is wiped for each silo
<mardy> rvr: ok, then please can you try again while running this: OAU_LOGGING_LEVEL=2 OAU_DAEMON_TIMEOUT=9999 online-accounts-service
<rvr> mardy: http://paste.ubuntu.com/12893637/
<rvr> mardy: That's without the silo
<rvr> https://bugs.launchpad.net/ubuntu-system-settings-online-accounts/+bug/1508903
<ubot5> Launchpad bug 1508903 in Online Accounts setup for Ubuntu Touch "[Contacts] Permission dialog shows in already granted account" [Undecided,New]
<mardy> rvr: you know what? it's not using the same account, it's actually creating another account
<rvr> mardy: I suppose it's not recognizing the existing one
<mardy> rvr: can you also paste the output of "account-console show <google-account-id>", where the google account id is returned by account-console list?
<rvr> mardy: https://pastebin.canonical.com/142430/
<mardy> rvr: thanks; looks like this is a regression in calendar, I'll comment on the bug
<rvr> mardy: In calendar?
<mardy> rvr: contacts, calendar, same thing ;-)
<rvr> mardy: Ah, ok
<rvr> mardy: The account tester app is failing. "Error 4"
<rvr> mardy: signon-apparmor-extension is installed
<mardy> rvr: are you testing the silo 2 now, or still on vanilla rc-proposed?
<mardy> rvr: in any case, could you please try again with OAU_LOGGING_LEVEL=2 OAU_DAEMON_TIMEOUT=9999 online-accounts-service ?
<rvr> mardy: Silo :)
<rvr> mardy: Forget it, it was an expected error
<brendand> are these issues known about? http://paste.ubuntu.com/12893982/
<sil2100> brendand: hm, no, I don't think so
<sil2100> brendand: is that with proper PPA pinning?
<rvr> mardy: Approving silo 2
<rvr> mardy: I filled another bug https://bugs.launchpad.net/ubuntu-system-settings-online-accounts/+bug/1508935
<ubot5> Launchpad bug 1508935 in Online Accounts setup for Ubuntu Touch "[Account tester] Test case password-query fails" [Undecided,New]
<rvr> renatu: ping
<renatu> rvr, pong
<rvr> renatu: om26er has been trying to install silo 55 in OTA7 without luck
<rvr> renatu: https://trello.com/c/Sof1bEKA/2397-540-ubuntu-landing-055-address-book-service-bfiller
<rvr> renatu: Should be installed in rc-proposed instead?
<rvr> OTA7 lacks dependencies
<renatu> rvr, did we update evolution-data-server libraries?
<rvr> renatu: I don't know
<renatu> Version of libstdc++6:armhf on system is 4.9.2-10ubuntu13.
<renatu> it is complaning about evolution-data-server libraries and stdc++ versions
<renatu> rvr, I do not have controls over these libraries, I can try push a new build on the silo to check if it will fix the problems
<rvr> renatu: I could install it in rc-proposed
<rvr> renatu: But om26er was trying to do it in OTA7, as explained in the merge proposal
<renatu> rvr, do I need to change something in the silo to create packages for OTA7?
<Mirv> jibel: hey. I don't see cachio here but request 531 / silo 014 was marked as Passed but the ticket was not updated.
<renatu> rvr, I do not know why the silo is creating packages incompatible with the libraries on OTA7
<rvr> renatu: Hmm
<rvr> renatu: I'm going to take look to it. Why is OTA7 a requirement?
<rvr> Mirv: I see
<renatu> rvr, OTA7 is not a requirement
<rvr> Mirv: Maybe he has no bileto powers
<rvr> Mirv: Approving
<renatu> rvr, it will be land on OTA8
<Mirv> rvr: thank you! possibly so.
<renatu> rvr, ok I see the test plan ask to install OTA6. I will update that.
<rvr> renatu: Ok
<renatu> rvr, done
<rvr> robru|sick: Can you add cachio to bileto (qa-team)?
<sil2100> rvr: I can do that if needed :)
<rvr> sil2100: Yes, please :)
<rvr> renatu: I'm reading the steps here https://code.launchpad.net/~renatofilho/address-book-service/fix-facebook-account-import/+merge/275076
<rvr> renatu: * Install OTA7 or older image on phone
<rvr> renatu: Step '''Install the last version of the package "buteo-sync-plugins-contacts-google" and "address-book-updater"''' ... is this equivalent to install the silo packages?
<renatu>  rvr, I added a extra step: Flash proposed image;
<renatu> :D
<rvr> renatu: Same URL?
<renatu> yes
<rvr> Still see the same steps
<renatu> rvr, for me it is showing:
<renatu> Open system settings and create one account (Account D):
<renatu> Make sure that contact sync is disabled for this account
<renatu> Flash proposed image;
<renatu> Install the last version of the package "buteo-sync-plugins-contacts-google" and "address-book-updater"
<renatu> reboot the phone
<rvr> renatu: Flash without wiping?
<renatu> yes
<renatu> let me update that
<rvr> Weird, in https://code.launchpad.net/~renatofilho/address-book-service/fix-facebook-account-import/+merge/275076 I still see the old steps
<rvr> om26er: You? ^
<om26er> rvr, yeah they are the same as they were previously
<rvr> om26er: renatu has updated the steps, see above
<renatu> rvr, ok sorry I have been updating the test plan page: https://wiki.ubuntu.com/Process/Merges/TestPlan/buteo-sync
<renatu> rvr, I will update the MR description
<om26er> ;)
<rvr> renatu: Aaaaaahhhhhh
<om26er> renatu, is buteo-sync-plugins-contacts-google not installed by default ?
<renatu> om26er, yes they are on proposed
<rvr> barry: ping
<om26er> renatu, hmm, so I don't need to install it then ? or do I have to downgrade to the previous version of this package ?
<renatu> om26er, you need to install the packages on silo
<om26er> renatu, the silo does not contain buteo-sync-plugins-contacts-google it only contains address-book-service
<om26er> renatu, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-055
<renatu> yes in this case just install the silo
<renatu> I will update the description
<davmor2> popey: oh I like it
<popey> wat?
<davmor2> popey: I thought well that bug number one not fixed and then I tapped the today and up it scrolled very swish
<popey> \o/
<davmor2> and the bottom one pops it's details up rather than down that's 2 out of 2 woohoo! now to find some new issues ;)
<Saviq> brendand, how's your armour, holding? need a med-pack?
<davmor2> popey: found a bug
<davmor2> popey: 19 kph is not 19 mph for wind
<davmor2> popey: 19kmh is about 12 mph
<davmor2> kph even
<ahayzen> davmor2, not more issues! ;-)
<davmor2> ahayzen: flick between mph and kmh surely the numbers should change ;)
<ahayzen> they do for me..
<davmor2> kph even
<ahayzen> which provider and is that the day delegate or the today info ?
<ahayzen> davmor2, oh you mean the numbers would change good point!
<davmor2> ahayzen: both providers on the default location page for any day including today
<davmor2> ahayzen: indeed 19 kph != 19mph more like 12mph
<ahayzen> davmor2, haha who wrote this!
 * ahayzen hides
<davmor2> ahayzen: ermmmmmm I forget his name
<ahayzen> bzr blame will tell us ;-)
<davmor2> ahayzen: I just blame popey â¢ any way
<ahayzen> davmor2, right investigating, you can report a bug and assign to me if you want :-)
<ahayzen> davmor2, haha, so if you change the temperature from C to F i bet the wind value will change ;-)
<Saviq> davmor2, have you seen brendand? I'm worried silo 22 kiled him...
<davmor2> Saviq: bath is a long way from wolverhampton dude ;)
<davmor2> ahayzen: what muppet wrote that ;)
<ahayzen> :-)
<Saviq> davmor2, not sure what it has to do with the fact you don't take regular baths
<Saviq> I work from  home, too
<davmor2> Saviq: yes an I can't see you either :P
 * Saviq wipes the camera lens
<davmor2> Saviq: oh dude seriously put some clothes on no one needs to see that.  /me buys some more mind bleach
<sil2100> slangasek: hey! I see the xenial series is up on LP, feel free to do the wily-overlay batch copy once you see the time is right and give us a sign to re-target the CI Train
<om26er> sil2100, Hi!
<slangasek> sil2100: ah, we should probably do that asap
<om26er> sil2100, I need to bless https://requests.ci-train.ubuntu.com/#/ticket/540
<om26er> sil2100, I would probably need permissions to do that, can you give me permissions ?
<sil2100> om26er: sure!
<davmor2> Saviq: there you go resurrected brendand for you
<davmor2> Saviq: don't be killing him again I only have the one potion available till I complete the next quest
<sil2100> om26er: added!
<sil2100> rvr: oh and I almost forgot about your request, added that person now - sorry for the delay!
<rvr> sil2100: Thanks
<sil2100> jibel, robru|sick, rvr, davmor2: anything to discuss besides celebrating wily release?
<jibel> sil2100, nothing from me
<popey> davmor2: http://people.canonical.com/~alan/weather/com.ubuntu.weather_3.0.150_all.click for you - fixes your bug
<jibel> rvr, why is 23 still blocked?
<rvr> jibel: barry haven't pinged back
<jibel> barry, ^
<rvr> hasn't
<jibel> barry, there is a comment on this card https://trello.com/c/lGitnxvO/2373-514-ubuntu-landing-023-system-image-barry
<davmor2> ahayzen: https://bugs.launchpad.net/ubuntu-weather-app/+bug/1508998
<ubot5> Launchpad bug 1508998 in Ubuntu Weather App "Numbers are not recalculated on unit change for wind speed" [Undecided,New]
<davmor2> popey: oh nice
<ahayzen> davmor2, already fixed :-P
<popey> davmor2: added link to the citrain task
<davmor2> popey: thanks
<popey> davmor2: give us a ping if you find any more :)
<barry> jibel: i apparently can't log into trello any more.  getting a pw reset
<davmor2> popey: will do
<barry> rvr: do you have a few minutes to talk about the test b failure?
<rvr> barry: Sure
<barry> rvr: what does it mean "s-i-cli doesn't unset auto downloads?"
<rvr> barry: system-image-cli is self-consistent, it gets and sets its autodownload status correctly
<rvr> barry: but is not consistent with System Settings
<rvr> barry: When I unset autodownloading with system-image-cli, System Settings says otherwise
<barry> rvr: i guess that's a bug in system-settings?
<davmor2> ahayzen, popey: that's better :)
<ahayzen> davmor2, :-)
<barry> rvr: who owns system-settings these days?
<rvr> barry: Ask kenvandine
<davmor2> ahayzen: how can tell if the refresh has happened?
<ahayzen> davmor2, when the spinner stops spinning? or the bouncing stops bouncing ?
<ahayzen> or if the data changes
<ahayzen> davmor2, you could load you cache folder with the data from the autopilot tests
<ahayzen> then you would see it all change
<davmor2> ahayzen: I mean for the refresh interval to test it is actually refreshing
<ahayzen> ah hmm
<ahayzen> change the time on your clock ?
<barry> rvr: okay, while waiting for kenvandine to respond, let me ask about the other problem i think you reported.  you're not seeing updates because of another system-settings issue, or is that a system-image problem?
<davmor2> ahayzen: is there a timestamp on the data?
<ahayzen> davmor2, not sure think that was hijacked from the old app, let me check
<rvr> barry: Well, I don't know whether the problem is in System Settings or in system-image, but I did "Wait for it to say there is an update available" and in the main screen, I couldn't see the new image notification
<barry> rvr: did you explicitly check for updates?
<rvr> barry: I followed the test plan
<ahayzen> davmor2, hmm i'm not sure if that auto-refreshes or if when you restart the app it then uses that to determine if its loading from the cache or if it needs to go to the web
<rvr> barry: https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-system-image#Test_B_--_Good_Path_Automatic_Download_Current_Packages
<rvr> barry: As I didn't get the notification, I stopped to ask whether that was expected or not
<davmor2> ahayzen: okay I'll have a look at the data see if it has a timestamp and play a bit
<barry> rvr: note that for s-i 3 you only follow the first Test A and B.  i suppose i should relabel those so it's not confusing
<barry> rvr: but i will also double check on my phone
<ahayzen> davmor2, this is the bit of code it hits if its any use http://bazaar.launchpad.net/~ubuntu-weather-dev/ubuntu-weather-app/reboot/view/head:/app/data/WeatherApi.js#L771
<rvr> barry: Oh, right, don't worry I was using test plan for system-image 3
<rvr> It's clear
<barry> rvr: cool
<davmor2> ahayzen: thanks I'll have a look after
<barry> rvr: i'm on ubuntu-touch/rc-proposed/bq-aquaris.en r149
<barry> rvr: let me install si 3.0.2 from the silo and test it
<rvr> barry: Ok
<davmor2> ahayzen: yeap looks like it updates on close and reopen  if it passes the time selected by the look of it but I'll have a confirmation in 8 minutes
<ahayzen> davmor2, sweet :-)
<kenvandine> barry, rvr: hey, mostly jgdx and myself
<barry> rvr: hmm. i see "Auto download Never" now
<barry> after i install s-i 3.0.2, and reboot
<rvr> barry: Hmmm
<jgdx> barry, reminds me, we need to stop using Info if you backport s-i 3 to vivid+overlay, right?
<barry> jgdx: right.  use .Information()
<jgdx> barry, I have an MP for that
<barry> jgdx: cool.  rvr, jgdx, kenvandine one thing i am seeing though: if i set auto_download=0 via system-image-cli, system-settings doesn't see the change
<barry> i'm guessing it caches it and doesn't recheck
<barry> however, if i swipe up the s-s panel and relaunch, it sees the change
<jgdx> barry, while page open, or do you back->re-enter?
<barry> jgdx: back->re-enter
<jgdx> kenvandine, shouldn't be any caching between panel âsessionsâ should there?
<kenvandine> it might not get the property changes
<kenvandine> so won't see the value changed until it restarts
<jgdx> barry, that sends a dbus signal?
<kenvandine> unless it was changed in settings
<barry> jgdx: yes, it should send a SettingChanged signal with the key and new value
<jgdx> okay, maybe it's not hooked yp
<kenvandine> my guess is we don't handle that signal
<barry> jgdx, kenvandine swipe-up->relaunch does work
<barry> jgdx, kenvandine, rvr so the other thing i see is that on manual download, while i do get an offer for r155 (i'm on r149), i don't see any progress during the download.  might want to check that you're handling UpdateProgress signals correctly too
 * barry will update the trello
<kenvandine> barry, mind filing a bug?
<barry> kenvandine: on both signal issues, or just UP?
<kenvandine> both please
<kenvandine> one bug for both is fine
<barry> kenvandine: ack
<kenvandine> thx
<davmor2> ahayzen, popey, pmcgowan ^
<pmcgowan> nice
<davmor2> popey: now just publish the right one ;)
<popey> brilliant news, thanks davmor2
<barry> rvr, jgdx, kenvandine at least the --set issue isn't a bug in system-settings i think.  i think the signal doesn't get set when system-image-cli is used
<barry> *sent
<barry> i'm still going to file the bug, but i'll add a bugtask to system-image for that, though 1) i'm not sure if i can make that work; 2) it's an odd corner case anyway since "normal people" don't use the cli
<rvr> barry: I see
<rvr> barry: Hmm
<rvr> barry: I'm re-running test B to check the rest of it
<barry> rvr: okay.  jgdx, kenvandine LP: #1509022
<ubot5> Launchpad bug 1509022 in ubuntu-system-settings (Ubuntu) "system-settings may not be responding to system-image D-Bus signals" [Undecided,New] https://launchpad.net/bugs/1509022
<rvr> barry: Great, thanks
<barry> rvr: thanks!
<kenvandine> barry, thx
<rvr> barry: Test B
<rvr> barry: Open System Settings panel
<rvr> barry: I go to Updates
<rvr> barry: And, although I set system-image-cli --set auto_download=0, Updates says it downloads when wifi available
<rvr> barry: Anyway, I installed that update
<rvr> barry: After the phone is rebooted, I rm -f /etc/system-image/config.d/02_testing.ini
<rvr> barry: Test plan says "Open System Settings panel, then Updates. It should report that your Software is up to date"
<rvr> barry: But it downloads the image again
<rvr> barry: cat: /etc/system-image/config.d/02_testing.ini: No such file or directory
<jhodapp> sil2100, ping
<jhodapp> cyphermox, hey can you do me a quick favor and push qtmultimedia-opensource-src from ppa:jhodapp/ubuntu/ppa to silo 15 please?
<jhodapp> cyphermox, source package only
<cyphermox> sure
<barry> rvr: i think i left off a step.  after printf'ing to 02_testing.ini, system-image-dbus needs to be restarted.  let me verify and update the wiki
<jhodapp> thanks
<popey> davmor2: ahayzen published :) (the right one)
<barry> rvr: or you can wait for it to timeout, but that's no fun
<rvr> barry: I see
<cyphermox> jhodapp: stuff is building, do you still need the copy?
<jhodapp> cyphermox, yeah, if the build is in the way feel free to cancel it
<jhodapp> cyphermox, thanks for doing that, going to grab lunch quickly...bbiab
<dobey> rvr: hey. sorry, forgot to approve the one branch in our iap silo. it's approved now :)
<cyphermox> jhodapp: copied; it's building now
<rvr> dobey: Great!
<jhodapp> thanks!
<robru> sil2100: I'm here to enable xenial if you want to EOD
<sil2100> robru: hey! You feeling good enough?
<robru> sil2100: oh yeah, just slept a bit late, feeling fresh now
<sil2100> robru: ok, didn't start the switch yet, I'm deep in Qt debugging now
<rvr> barry: Ok, killing system-image-dbus does the trick
<robru> sil2100: alright
<sil2100> I suppose you would do it much faster than me anyway
<rvr> barry: System up-to-date
<rvr> robru: Welcome back
<robru> rvr: thanks
<barry> rvr: cool.  wiki page updated
<robru> sil2100: slangasek: ok bileto trunk is updated for xenial, just waiting on #webops to do a rollout (vanguard is on lunch)
<sil2100> robru: excellent, thanks! Now just the train needs to be switched back to not to land to the overlay for x
<robru> sil2100: oh right, heh, on it ;-)
<slangasek> robru: why did you leave wily+vivid as a target and remove trusty+precise?
<slangasek> robru: and where is the logic that tells it to land xenial to the main archive instead of the overlay ppa?  I couldn't figure this out looking at the code
<rvr> barry: Silo approved
<robru> slangasek: left wily+vivid for transitional purposes. weird results happen if we do a hard/instantateous cutover, eg, silos mid-publish won't be able to find the packages during the migration check. removed trusty+precise because that was more of just an example that I don't think anybody was actually using.
<slangasek> ok
<slangasek> tvoss: hi, just replied to your comment on LP: #1278780
<ubot5> Launchpad bug 1278780 in apport (Ubuntu) "apport takes too long to write crash report, appears to lock up phone" [High,Triaged] https://launchpad.net/bugs/1278780
<tvoss> slangasek, cool
<slangasek> tvoss: summary: I like the sendfile idea, but want to discuss further why you classify unmapping of graphics buffers as "quite dangerous" :)
<tvoss> slangasek, yup, just read through your comment. So the problem is: it is not as simple as unmapping a buffer, and we have no idea what an underlying driver might do if we call "free graphics buffer"
<tvoss> if it was an munmap, fine with me
<slangasek> tvoss: ok; why is it not that simple? :)
<slangasek> we've segfaulted.  You don't get to do any other cleanup in this case
<slangasek> is it because you don't have enough info to call munmap()?
<tvoss> slangasek, we use gralloc, with a binaryblob providing us with the actual implementation
<tvoss> slangasek, we don't call munmap, but would call into a binary blob we don't own and have no idea what it is doing :)
<tvoss> slangasek, so "mapped graphics buffers" does not mean mmap'd in the general case
<slangasek> hmm
<alexabreu> robru, ping
<slangasek> tvoss: de facto, if it's been mapped into the process's memory space, it should be possible to unmap it
<robru> alexabreu: pong
<slangasek> using munmap()
<robru> sil2100: slangasek: ok, xenial+vivid is live in bileto production
<slangasek> robru: did you see my second question, about where the logic lives to tell it that xenial is landing to the main archive and not the overlay?
<robru> slangasek: yep, that's fixed in cu2d and also in production already
<robru> slangasek: or sorry, you wanted to know *where* the logic is?
<slangasek> robru: ok, so I was just looking at the wrong repo - thanks
<robru> slangasek: yeah check the latest commit at lp:cupstream2distro
<tvoss> slangasek, sure, although I would like to make sure we at least have an idea of how things might go wrong. also: ashmem and pmem ftw, you never know what a driver uses
<slangasek> robru: I wanted to know why I couldn't find it, and I also wanted to know it was done ;)
<robru> slangasek: heh, looking at the scrollback, yeah I somehow missed your entire second message there
<tvoss> slangasek, don't get me wrong: minimizing the memory footprint is a great idea, but it needs further thought to minimize the risk of corrupting graphics driver state
<alexabreu> robru, have a mns to check something w/ me?
<robru> alexabreu: sure, what's up?
<alexabreu> robru, https://jenkins.qa.ubuntu.com/job/unity-js-scopes-wily-armhf-ci/23/console check at the bottom, ... the copyright errors, ... & the associated branch seems to be fine in terms of deb copy http://bazaar.launchpad.net/~abreu-alexandre/unity-js-scopes/doc/view/head:/debian/copyright
<sil2100> robru: the train code is in lp:cupstream2distro if anything ;)
<slangasek> tvoss: ok.  I am confident that if it's in the process's address space, munmap() DTRT in this context, but I agree we should make sure
<sil2100> I mean, slangasek
<sil2100> But I see robru already mentioned that
 * sil2100 gets back to his code as he clearly missed some backlog
<sil2100> ;)
<davmor2> popey, ahayzen: yay new app on stable phone \o/
<popey> \o/
<robru> alexabreu: I'm not really familiar with whatever tool is doing the copyright scan, but the first thing I'd check is the headers of those files themselves. Perhaps it wants a copyright header directly in every file? I'm not sure it cares about debian/copyright
<alexabreu> robru, yes but that's the thing, those are files that are generated everytime there is a doc update, ... & the headers are from upstream, this would be a bummer if I had to script those headers to be tweaked (which seems is what I'll have to do)  ... I was wondering if there was something else obvious
<robru> hmmm, I wonder how badly the opening of xenial will exacerbate our disk space issues in the train...
<robru> alexabreu: yeah, not sure, sorry. I've never seen a project enforce copyright checks at build time, or at least I've never seen it fail.
<alexabreu> ok thx, I'll add those headers :/
<davmor2> ahayzen, popey: so I guess the next app update to land is likely to be music app right?
<robru> brb
<Saviq> brendand, hey, any update on silo 22 testing, you're awfully quiet about it, not sure if a good sign or bad :)
<slangasek> robru: and if we're saying that wily+vivid won't land anymore as-is but will become xenial+vivid, is there any reason to continue supporting that as an option right now, as opposed to forcing the transition?
<slangasek> (not that I think we need to push a bileto deployment just for this, necessarily)
<robru> slangasek: well my concern was that if there were any wily+vivid silos that were currently migrating the train wouldn't be able to track them any longer, but of course none are migrating because the copy to overlay PPA is instant.
<robru> slangasek: I'll drop the option from trunk but won't roll it out until later
<kenvandine> robru, ^^ what do we need to do for that?
<kenvandine> robru, ah, that's what you guys have been talking about :)
<robru> kenvandine: check my email on phone ml
<robru> kenvandine: need to bin-copy wily packages to xenial within the ppa, then delete wily packages, then set request to xenial+vivid, then publish
<kenvandine> yeah, this silo has already been through qa
<robru> kenvandine: that's fine, it's a bin copy
 * kenvandine copies
<robru> kenvandine: the thing is there won't be any more copies from wily overlay to xenial so if we let you publish to wily overlay then xenial would get left behind
<kenvandine> yeah
<kenvandine> robru, do i need to wait for the copied binaries to be published for xenial before publishing again?  or is it fine if they are pending still?
<robru> kenvandine: i would wait... I'm not sure how that would work if you didn't
<kenvandine> ok
<kenvandine> bfiller, ^^ i've fixed the silo and copied the binaries, but need to wait for the copied binary to be published in the silo ppa before trying to publish again
<robru> kenvandine: well, yeah, because snakefruit needs to call copyPackage do if it's still pending that'll fail i think
<kenvandine> yeah, i figured
<robru> Heh, need to wait for it to publish before you can publish, awesome overload between train & archive terminology
<kenvandine> indeed
<brendand> kgunn, about silo 22, i had a whole heap of unrelated trouble with my device earlier today. just starting on it now
<brendand> kgunn, it seems to be gleefully removing most of the packages in the system :/
<kgunn> brendand: do you have the latest citrain ?
<kgunn> if you use the latest version from
<kgunn> ppa:ubuntu-sdk-team
<kgunn> it shouldn't gleefully remove packages anymore
<kgunn> brendand: and when i say "citrain" i mean citrain tool...to do device-upgrade
<robru> brendand: what's the output of 'apt-cache policy phablet-tools-citrain' ?
<kenvandine> bfiller, i think we have to rebuild silo 55 :/
<robru> kenvandine: wait
<kenvandine> robru, got a solution?
<robru> kenvandine: I'm thinking.
<kenvandine> ignore dest?
<robru> kenvandine: maybe
<kenvandine> yeah... that's exactly the right thing :)
<robru> kenvandine: this would be the result of different package versions in wily vs in xenial
<kenvandine> it'll make xenial newer
<kenvandine> which is fine
<robru> kenvandine: that option would override this check, yes, I'm just trying to reason through if that's actually the right thing to do or if that'll cause unintended problems
<kenvandine> fine right?
<robru> kenvandine: I don't understand why address-book-service appears in that error message twice with two different version numbers.
<robru> kenvandine: 0212 is the vivid version
<robru> 1015 is the xenial (from wily overlay version)
<kenvandine> oh...
<kenvandine> what about the vivid overlay?
<robru> kenvandine: this is really weird, hang on
<kenvandine> ok... i need to run out for a bit
<kenvandine> i'll check back in a bit later
<robru> ok
<kenvandine> thx
<robru> kenvandine: you didn't delete the wily version, that might be related
<robru> kenvandine: ok it looks legit. the 1015 version being complained about is in the changelog of the one being published, so I guess it's ok
<robru> kenvandine: feel free to publish when you get back
<robru> ooooooo
<robru> first train publication to xenial is progressing ^
<brendand> kgunn, robru - the ppa changed then i guess - any particular reason for that?
<robru> brendand: what ppa were you using? Generally I publish to phablet-team/tools and then Mirv copies it to sdk ppa
<brendand> robru, right, that would have been the one - phablet-team/tools
<robru> brendand: yeah phablet-team/tools has the latest version.
<brendand> although it looks like i don't have that enabled... strange
<brendand> kgunn, got it installed now will give feedback by tomorrow
<kgunn> brendand: thanks man!
<kgunn> sorry you had trouble
#ubuntu-ci-eng 2015-10-23
<michi__> robru: ping
<robru> michi__: hey what's up?
<michi__> robru: Thanks for your reply, all sorted out. (Sorry, didn't see your message earlier).
<michi> robru: I really like the change in color scheme when a silo is dirty. Thanks for that, nice touch!
<robru> michi: you're welcome
<abeato> robru, hi, would it be possible to clean the wily packages in silo 13?
<robru> abeato: sure one sec
<abeato> robru, ok, thanks
<robru> abeato: done! you're welcome
<abeato> great
<Saviq> robru, hey, can I reset the dirty flag somehow https://requests.ci-train.ubuntu.com/#/ticket/445 ? we've reverted the commit that caused it to go dirty (was a trunk merge anyway)
<Saviq> robru, otherwise, will this cause us trouble on publish?
<robru> Saviq: hmmm
<robru> Saviq: the file that tracks commit IDs would indeed match again if you reverted the commit, but the dirty flag can officially only be removed by doing an actual rebuild. however I can go in and surgically remove the flag from the silo
<Saviq> robru, no need if it will allow us to publish
<robru> Saviq: I cleared the flag manually and I'm doing a WATCH_ONLY build to make sure that the commits all match expectations
<Saviq> robru, tried a watch_only yesterday and it didn't work, it was, though, before the revert
<robru> Saviq: yes, but I waved my magic wand prior to running WATCH_ONLY though.
<Saviq> robru, ah ;)
<Saviq> robru, I think it'd make sense for watch_only to re-check the commit ids
<robru> Saviq: yeah this needs a bit of work. the problem is that dirtiness can be created either by new commits or by other silos being published and it's not currently possible to tell which is which.
<Saviq> robru, ack
<robru> Saviq: I'll file a bug for now
 * Saviq waiting for brendand to rise from the dead and give some feedback on silo 22,  shame it won't merge/clean until migration for xenial is on anyway...
<Mirv> sil2100: ok, we were here :)
<robru> Saviq: here you go https://bugs.launchpad.net/cupstream2distro/+bug/1509250
<ubot5> Launchpad bug 1509250 in CI Train [cu2d] "Allow people to uncommit new commits." [Medium,Triaged]
<Saviq> brendand, morning! any news on silo 22, you've been awfully quiet :)
<brendand> Saviq, i spoke to kgunn yesterday. i had some unrelated issues, then found out i had the wrong citrain version
<brendand> Saviq, testing it now
<Saviq> ack
<Saviq> brendand, no pressure at this point, as we're blocked by lack of proposed migration for xenial
<Saviq> +anyway
<oSoMoN> ubuntu-qa: is silo 16 on someoneâs plate? ToyKeeper wasnât able to confirm the desktop fixes
<oSoMoN> rvr, thanks for the comment. One of the fixes in silo 16 is desktop-specific (fixes a crash). Of course I verified it myself, is that enough? If so can you/someone please approve the silo?
<oSoMoN> the fix in question is for bug #1508054
<ubot5> bug 1508054 in webbrowser-app (Ubuntu) "[desktop] Crashes on startup" [Critical,In progress] https://launchpad.net/bugs/1508054
<rvr> oSoMoN: Yes, I think so
<rvr> oSoMoN_: Silo 16 approved
<jgdx> trainguards: when building against xenius+vivid, i get that pep8 isn't installed: https://launchpadlibrarian.net/222250573/buildlog_ubuntu-xenial-amd64.ubuntu-system-settings_0.3%2B16.04.20151023-0ubuntu1_BUILDING.txt.gz
<oSoMoN_> rvr, thanks
<jgdx> trainguards: sorry, it's not installable, rather.
<Mirv> coincidentally I was just upgrading my chroot:s and lxc:s to xenial
<Mirv> jgdx: it says to me that pep8 depends on python3-pep that is no longer available, so it errors out
<jgdx> can I land using vivid+wily?
<robru> Mirv: jgdx looks like there's already a fix in xenial-proposed, not sure when that'll land
<Mirv> jgdx: well, it's fixed actually in this https://launchpad.net/ubuntu/+source/pep8/1.6.2-0.1ubuntu1 that is in xenial-proposed, and our PPA:s should be using prpoposed
<Mirv> jgdx: no, wily is no more, other than SRU:s
<Mirv> robru: shouldn't our PPA:s build with proposed anyway?
<jgdx> (weird way of adding plural to these things, Mirv :P)
<Mirv> but it might be xenial is not completely "running" yet
<robru> Mirv: hmm, I think so...
<jgdx> Mirv, is there a way to know for sure if that's fix is in?
<jgdx> Maybe let me know/enable me to know so I can start another build?
<Mirv> robru: hey Mr. 4am, haven't we talked about this?
<robru> jgdx: what silo?
<robru> Mirv: shush you
<sil2100> The builders are probably not using -proposed
<robru> ;-)
<sil2100> I mean, the builder build-envs, as it seems to die out on very early stages of the build
<jgdx> robru, the silo's under your pillow! Go get it ;P
<jgdx> robru, 39
<Mirv> 039 it'd seem
<Mirv> it has proposed enabled
<sil2100> We might need to wait for it to migrate
<robru> Hmm I don't have my lp login on this tablet...
<robru> OK I'll let you guys figure it out ;-)
<robru> Goodnight
<sil2100> Goodnight
<sil2100> I didn't create a xenial chroot yet as I know it's a bit early yet
<brendand> Saviq, can you clarify how to test this ? https://bugs.launchpad.net/ubuntu-translations/+bug/1372061
<ubot5> Launchpad bug 1372061 in unity8 (Ubuntu) "SMS notification: time format not translatable" [High,In progress]
<brendand> Saviq, the notifications indicator no longer seems to use date stamps
<brendand> Saviq, it just says x minutes/hours ago
<Saviq> brendand, yeah, we've just deleted a bunch of code and reverted to what SDK now provides
<Saviq> brendand, so if it looks right... it's right
<Saviq> dednick, unless you have an idea to test ââ
<dednick> Saviq: no, it should just be the same
<Saviq> brendand, basically, the fix comprised of implementing The Right Thingâ¢ in the UITK, now we've switched to using it - if it's in the UITK, it has to be good, right? :)
<Saviq> and the translation comes from there as well
<brendand> Saviq, yeah it seems good
<brendand> Saviq, i had to adjust the clock manually to make it show a date
<Saviq> ack
<oSoMoN> kenvandine, hey, would you mind acking the packaging changes in silo 16? https://ci-train.ubuntu.com/job/ubuntu-landing-016-2-publish/121/artifact/webbrowser-app_packaging_changes.diff
<kenvandine> sure
<kenvandine> +1 from me
<kenvandine> oSoMoN, want me to publish it?
<oSoMoN> kenvandine, if you donât mind
<kenvandine> oSoMoN, published
<oSoMoN> thanks!
<kenvandine> np
<jgdx> Mirv, how we doing wrt the pep8 package?
<Mirv> jgdx: please join #ubuntu-devel , there might be related discussion soon
<bfiller> kenvandine, renatu : re: silo 19, does this need to be dual landing? I wasn't sure whether buteo was in wily or not and it's status in x
<kenvandine> bfiller, i think it's in xenial now
<kenvandine> so dual landing would be xenial+vivid
<kenvandine> so should be fine
<bfiller> kenvandine: ok thanks
<kenvandine> np
<Mirv> jgdx: I just figured something when I was about to ask there... just a moment
<Mirv> sil2100: FYI bug #1509356
<ubot5> bug 1509356 in pep8 (Ubuntu) "pep8 depends on python3-pep, not python3-pep8" [Undecided,New] https://launchpad.net/bugs/1509356
<Mirv> I figured out when I stared at the diff again.. the builders _are_ using proposed correctly, and that's the problem
<rvr> dbarth: Approving silo 56
<oSoMoN> trainguards: is it expected that packages for the X series are landing in the overlay PPA, not in the distro?
<Mirv> oSoMoN: that's an error in ticket configuration if that happens
<Mirv> the target PPA field should be empty
<oSoMoN> Mirv, well IÂ had silo 16 that was awaiting QA validation before robru enabled X in bileto, so IÂ asked him to manually binary-copy the wily packages to retarget xenial in the silo, and I was expecting they would land in the correct place
<oSoMoN> Mirv, it was a dual silo, initially targetting vivid and wily, then modified to target vivid and xenial
<Mirv> oSoMoN: the binary-copy is needed, but so is ensuring the PPA field is empty so it does the normal dual thing ie vivid to PPA, devel to archive
<Mirv> oSoMoN: so yes https://requests.ci-train.ubuntu.com/#/ticket/547 had the field
<Mirv> oSoMoN: we'd need a core-dev to copy it from the overlay to archive and then we can delete the overlay version
<oSoMoN> ah, IÂ didnât know that, IÂ thought the field was needed for the vivid packages to go to the PPA
<oSoMoN> kenvandine, could you do that for us? ^^
<Mirv> oSoMoN: no, the behavior is "known" but I agree not obvious.
<Mirv> ah, right it's the time when Ken is around :)
<kenvandine> oSoMoN, which silo?
<oSoMoN> kenvandine, the one you published an hour agoÂ :) I didnât know but it was targetted at the overlay PPA for the X series, so we need to copy it from the silo to the distro proper, and delete the X packages in the overlay PPA
<Mirv> kenvandine: so copy-package webbrowser-app from overlay xenial to archive xenial
<Mirv> s/archive xenial/archive xenial-proposed/
<kenvandine> ah
<dbarth> rvr: \o/ thanks
<kenvandine> oSoMoN, Mirv: done
<kenvandine> Mirv, should i delete the xenial build from the ppa?
<oSoMoN> kenvandine, thanks!
<Mirv> kenvandine: thanks! and thanks for also deleting it from the ppa.
<kenvandine> np
<Mirv> see you in a week, everyone
<Mirv> robru: sil2100: the 024 xenial is still in abyss, not sure what happened, rsync seems correct
<sil2100> Mirv: have a nice holiday!
<Mirv> sil2100: thanks!
<brendand> Saviq, all clear
<Saviq> brendand, \o/
<Saviq> kgunn, greyback â
<Saviq> trainguards, we'll need to transition silo 22 to xenial, please
<kgunn> greatness
 * kgunn sheds a tear and whispers "good bye" silo0
<Saviq> right :D
<Saviq> it took us under a year to go from silo0 to release :D
<sil2100> hmmmm
<sil2100> Saviq: ok, performing the binary package copy
<greyback> Saviq: kgunn woooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
<greyback> oh if only I didn't have to drive now
<greyback> Saviq: has it really been a year?
<kgunn> greyback: almost...10 mo for sure
<kgunn> almost like a baby
<Saviq> greyback, MWC last year
<Saviq> erm *this* year
<greyback> blimey
<jibel> bfiller, Kaleo ^ camera app approved you can publish. It won't break on devices running stable?
<bfiller> jibel: it shouldn't but we'll test, there is problems with that silo though won't build on xenial
<Kaleo> bfiller, stable has 1.3 right?
<bfiller> Kaleo: yes it does
<Kaleo> cool
<jibel> bfiller, I'm sanity testing on stable
<jibel> Kaleo, it does, it shouldn't be a problem, but I just want ot make sure
<bfiller> Kaleo, jibel: we need to get that silo built correctly first then we can publish the deb and click
<bfiller> Kaleo filed a bug on it already https://bugs.launchpad.net/ubuntu/+source/python-flake8/+bug/1509396
<ubot5> Launchpad bug 1509396 in python-flake8 (Ubuntu) "Missing dependency on python-setuptools" [High,New]
<jibel> Kaleo, bfiller it's fine on stable too
<dobey> trainguards: is it possible to land in xenial via train yet?
<sil2100> dobey: yes
<dobey> awesome
<jgdx> barry, hey, what's the plan for ota versioning from s-i's end?
<barry> jgdx: from client's end, nothing once 3.0.2 lands.  everything needed is already supported there.  sil2100 was working on server support iirc
<sil2100> Yes, it's in the works now
<jgdx> barry, what are the eta for the former?
<jgdx> is
<sil2100> I would say I should be done by feature freeze
<jgdx> sil2100, really. Okay
<sil2100> Monday I hope to give barry something to review
<barry> awesome
<jgdx> could we share a silo?
<barry> i think it's waiting for qa sign-off.  rvr was doing qa
<jgdx> okay, great
<jgdx> I'll make one now then
<rvr> barry: I approved silo 23 yesterday
<barry> rvr: rock on!  i was just going to ask since i didn't see it on requests
<barry> rvr: is there anything more you need from me for that?
<rvr> QA Signoff Status	QA Granted
<rvr> Status	Landed
<rvr> barry: Seems done
<barry> \o/
<barry> thanks
<sil2100> Yeah, saw it in the vivid-overlay changes
<jgdx> sil2100, do you know anything re: the pep8 situation? Any change?
<sil2100> jgdx: packages still in -proposed
<sil2100> jgdx: I saw some autopkgtest regressions, but those should be resolved soon with a new upload of pyflakes
<sil2100> jgdx: all caused by some package renames
<jgdx> sil2100, okay, will it be resolved before tuesday?
<sil2100> I'm sure it would, if not we'll consider giving a bit more time for landers that were blocked because of that
<bfiller> jgdx: silo 39 has built now
<jgdx> bfiller, great
<bfiller> jgdx: that issue was resolved apparently
<jgdx> huh okay
<bfiller> seb128 told me doko fixed it
<bfiller> rvr: how's silo 11 testing coming?
<rvr> bfiller: Hope to finish soon
<jgdx> sil2100, could you given an example of what the tag key would contain as value?
<jgdx> sil2100, re: ota
<sil2100> jgdx: it will append something like this to the version_detail - "tag=OTA-6", so e.g. "version_detail": "ubuntu=20151015,device=20150911,custom=mako-1.1,version=26,tag=OTA-6"
<jgdx> sil2100, +1
<sil2100> jgdx: I can't guarantee the ordering though, so don't take that for granted of course
<jgdx> sil2100, sure thing.
<boiko_> rvr: how is silo 11 going?
<rvr> boiko: I'm checking an issue with the messages scope
<rvr> I've received some messages and the scope is blank
<boiko> rvr: ah yes, those are not really landing together with the silo, so, bugs in there should not block the landing really, I still have to fix a couple issues bfiller found in the new scopes implementation
<rvr> boiko: I see
<rvr> boiko: bfiller: Approving silo 11
<boiko> rvr: great! thanks!
<bfiller> rvr: ty
<bfiller> kenvandine: mind publishing silo 11?
<kenvandine> sure
<kenvandine> bfiller, that's alot of branches :)
<kenvandine> bfiller, so that's set to "dual"
<kenvandine> and built for wily and vivid
<bfiller> kenvandine: crap
<bfiller> so what does that mean?
<kenvandine> already qa granted
<kenvandine> i can do the same thing i did last night
<bfiller> kenvandine: sorry
<bfiller> kenvandine: silo has been around for a long time :)
<rvr> kenvandine: Silo 39 is targeted for xenial+vivid
<kenvandine> rvr, i'm doing 11
<kenvandine> what's wrong with 39?
<rvr> kenvandine: Shouldn't it land directly, or it is incorrectly targeted?
<rvr> kenvandine: https://requests.ci-train.ubuntu.com/#/ticket/546
<kenvandine> it should be xenial+vivid
<rvr> kenvandine: Does it mean dual land?
<kenvandine> yes
<rvr> Ah, I see, thanks
<kenvandine> we don't land for wily anymore
<kenvandine> np
<jgdx> barry, 3.0.2 is deprecating or removing Info altogether?
<barry> jgdx: silently deprecated :)
<jgdx> barry, :))) very good
<alexabreu> robru, ping
<robru> alexabreu: pong
<alexabreu> robru, sorry again on that copyright issue w/ jenkins, this is insane, ... I added the headers but ... https://jenkins.qa.ubuntu.com/job/unity-js-scopes-wily-amd64-ci/37/console
<alexabreu> robru, I am at a loss
<alexabreu> robru, the copyright seems fine http://bazaar.launchpad.net/~abreu-alexandre/unity-js-scopes/doc/view/head:/debian/copyright
<alexabreu> robru, & the targetted files have headers e.g. http://bazaar.launchpad.net/~abreu-alexandre/unity-js-scopes/doc/view/head:/doc/docbuild/api.js
<alexabreu> I must be missing something
<robru> alexabreu: that's a different error though isn't it?
<robru> alexabreu: didn't it say before it couldn't find the license? seems like now it says the license is not an acceptable license.
<alexabreu> robru, yes, I progressed
<alexabreu> from unknown to this
<alexabreu> so it picks it up
<robru> alexabreu: as I said I'm not familiar with this copyright checker you're using here. I'm not sure who would know more about this.
<alexabreu> ok
<robru> alexabreu: maybe ask slangasek
<ChrisTownsend> trainguards: May I have a silo assigned for https://requests.ci-train.ubuntu.com/#/ticket/561 please?
<robru> ChrisTownsend: you have the ability to assign your own these days
<ChrisTownsend> robru: Oh wow, I did not know that (obviously):)
<ChrisTownsend> robru: Thanks
<robru> ChrisTownsend: you're welcome. feel free to ask for help if something goes wrong but it should be pretty smooth
<ChrisTownsend> robru: Thanks again
<robru> you're welcome again
<ChrisTownsend> robru: I assume we do not have the ability to publish though, right?
<alexabreu> alexabreu, any idea (see my comments above) ^
<robru> ChrisTownsend: you can publish as long as there's no changes under debian/ and all your packages are prepared by merges (you can't publish manual sources)
<ChrisTownsend> robru: Ok.  If there are changes in debian/ do we ping a trainguard or is it queued up for review?
<robru> ChrisTownsend: you'd have to ping either a core dev or a MOTU depending on if your package is in main or universe.
<ChrisTownsend> robru: Ok, thanks for the lessons:)
<robru> ChrisTownsend: you're welcome
<slangasek> robru, alexabreu: sorry, I don't know anything about this license checker either.  But it appears to be getting called as part of pbuilder itself?
<slangasek> /var/cache/pbuilder/build//24503/tmp/hooks/A10checklicenseheaders doesn't look like a package build directory
<robru> slangasek: yes it does? build/nnnn
<slangasek> really?  that's a strange convention
<robru> slangasek: i think that's a cowbuilderism
<slangasek> I rest my case
<robru> slangasek: alexabreu no wait, that log is from s-jenkins, not train Jenkins
<robru> I officially have no idea what's going on there
<robru> alexabreu: you should really poke cihelp for this
<fginther> alexabreu, looking
<robru> fginther: thanks
<robru> slangasek: actually though I thought you might be more knowledgable about policy, eg, is there some reason that "BSD 3 clause" wouldn't be acceptable in ubuntu or something.
<slangasek> robru: no, that's perfectly acceptable in Ubuntu, but it's possible this is a license checker that tries to verify that debian/copyright matches the source
<robru> slangasek: k, I dunno then. the headers and the debian/copyright appear to match to me
<robru> thanks
 * robru --> lunch
<fginther> robru, this is just a case of using an overly restrictive license check. There's nothing really wrong with the files
<fginther> robru, in case you were curious
<fginther> alexabreu, should be fixed now, and your MP is being re-run.
<robru> fginther: haha, thanks. where's the documentation on that license checker?
#ubuntu-ci-eng 2015-10-24
<alexabreu> fginther, thx !
<fginther> robru, there is no documentation for those license checkers other then the code itself - http://bazaar.launchpad.net/~jenkaas-hackers/pbuilderjenkins/trunk/files/head:/hooks/
<robru> fginther: ok, thanks
<robru> Mein gott
<alexabreu> fginther, so did you disabled the license checkers for the issue above, or disabled some of them?
#ubuntu-ci-eng 2016-10-24
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2087 Failed to build (vivid/webbrowser-app, zesty/webbrowser-app). Successfully built (xenial/webbrowser-app)
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Preparing packages
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Successfully built
<oSoMoN> trainguards:Â could you please kick off a rebuild of https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2087/+build/11067136 ?
<oSoMoN> trainguards: and Iâm seeing build failures on zesty because of unmet dependencies on apparmor and apparmor-easyprof-ubuntu, is that a known issue? The following packages have unmet dependencies:
<oSoMoN>  sbuild-build-depends-webbrowser-app-dummy : Depends: apparmor but it is not going to be installed
<oSoMoN>                                              Depends: apparmor-easyprof-ubuntu (>= 1.3.13) but it is not going to be installed
<oSoMoN> e.g. https://launchpadlibrarian.net/290606682/buildlog_ubuntu-zesty-amd64.webbrowser-app_0.23+17.04.20161024-0ubuntu1_BUILDING.txt.gz
<oSoMoN> maybe a temporary failure that would go away if retried now?
<oSoMoN> jibel, sil2100:Â we discussed last week about overriding the automated signoff status for https://bileto.ubuntu.com/#/ticket/1919 , can we go ahead?
<oSoMoN> itâs pretty quiet today, is everyone down with ubuflu?
<popey> maybe some took swap days
<mzanetti> oSoMoN, for our team, one down with ubuflu, one still stuck in AMS as all the flights got cancelled
<mzanetti> and yeah, 4 with swap days
<oSoMoN> wow, what happened in AMS?
<mzanetti> sorry, that stays in AMS :P
<oSoMoN> :)
<mzanetti> nah, weather conditions
<oSoMoN> man, Iâm glad we flew back on Friday evening
<mzanetti> yep :)
<popey> yeah, that didn't go smooth for us :)
<mzanetti> sil2100, hey, can you help with that? ERROR This ticket must be migrated to zesty+xenial+vivid before it can be built.
<mzanetti> or do I need to create a new one?
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 QA Signoff: Required
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 This ticket must be migrated to zesty+xenial+vivid before it can be built
<mzanetti> ignore that...
<mzanetti> realized I could just change the checkbox
<mzanetti> erm, combobox
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Needs rebuild due to new commits (zesty/ubuntu-settings-components). Successfully built (vivid/ubuntu-settings-components, vivid/unity8, xenial/ubuntu-settings-components, xenial/unity8, zesty/unity8)
<dobey> trainguards: can someone please delete unity-scope-snappy from overlay ppa?
<sil2100> dobey: on it
<sil2100> mzanetti: which ticket?
<mzanetti> sil2100, nvm... it was about 2022 but I saw I could just change the config and that works
<mzanetti> sil2100, you might want to drop yakkety packages from the ppa though?
<sil2100> oSoMoN: I guess it's up to QA to do, I'm +1 on that since we only want to sign-off the vivid part there - but jibel is off today, so you might want to poke davmor2 instead
<oSoMoN> sil2100, ok, thanks
<sil2100> mzanetti: wait, wasn't that silo ready for QA?
<mzanetti> sil2100, yes, but davmor2 found an issue, I fixed and rebuilt
<sil2100> Are you rebuilding it now?
<sil2100> Oh, ok
<oSoMoN> davmor2, if youâre around, can we move silo 1919 to ready for QA ?
<sil2100> Let me remove the yakkety packages then - you rebuilt all of them?
<mzanetti> sil2100, yes
<mzanetti> sil2100, zeisty still building, but the others built
<davmor2> oSoMoN: just reading the backlog is this the one with the issue on apparmor?
<davmor2> oSoMoN: give me a few and then I'll have a proper look at it if it is as described I'll move it into the queue
-queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/2071 Preparing packages
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2089 xenial/ubuntu-themes: Failed to commit https://code.launchpad.net/~malaperle/ubuntu-themes/ubuntu-themes. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Successfully built
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2089 Ready to build
-queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/2071 Dependency wait
<dobey> sil2100: hmm, i wonder why it's still saying depwait in bileto :-/
<oSoMoN> davmor2, no, thatâs just https://bileto.ubuntu.com/#/ticket/1919 thatâs ready for QA review, but autopkgtests failed because weâre only targetting vivid+overlay and xenial+overlay, there are no yakkety/zesty packages in the ppa (thatâs ok because that version is already in yakkety and zesty)
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/1919 QA Signoff: Ready
<davmor2> oSoMoN: that's done should show in the queue shortly
<oSoMoN> davmor2, cheers mate
<sil2100> dobey: which ticket is it?
<dobey> sil2100: 2071
<sil2100> dobey: hm, interesting, maybe because it's not available in any of the series in the archives
<sil2100> dobey: so it treats all failures as real failures
<sil2100> dobey: since it assumes you should have it building for all architectures - the only snappy scope in the archives is for wily
<dobey> sil2100: oh, right; forgot about that
<sil2100> And Bileto only checks the binaries for the given source
<sil2100> We can just maybe try ignoring it somehow, not sure if Bileto will let us ;)
<dobey> yeah i think it will
<davmor2> oSoMoN: hmmm won't this need a rebuild if we land https://bileto.ubuntu.com/#/ticket/1885
<dobey> well i'll set it to lander approved and see what happens :)
<oSoMoN> davmor2, w00t? no this shouldnât land, 1919 is superseding 1885
<oSoMoN> davmor2, can you remove 1885 from the QA queue?
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2088 Pending binary packages
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2087 Preparing packages
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2090 Successfully built
<davmor2> oSoMoN: on it
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2087 Failed to build (xenial/webbrowser-app). Pending binary packages (vivid/webbrowser-app, zesty/webbrowser-app)
<oSoMoN> trainguards: can https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2087/+build/11071070 be retried, please?
<tedg> oSoMoN: Retried
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2088 Successfully built
<oSoMoN> thanks tedg
-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- oSoMoN, https://bileto.ubuntu.com/#/ticket/2087 Pending binary packages (xenial/webbrowser-app). Successfully built (vivid/webbrowser-app, zesty/webbrowser-app)
 * dobey wonders how long britney takes right now
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2087 Successfully built
<dobey> sil2100: hmm, i guess bileto is just skipping because of the depwait?
<dobey> err, s/bileto/britney/
<dobey> meh
<dobey> maybe i should chagne debian/control to only build on those then
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2068 Abandoning ticket
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2067 Abandoning ticket
<robru> dobey: looks like britney currently runs in 15 minute intervals
<robru> dobey: and yeah it only considers tickets with "success" in the status
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2090 Publishing packages
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2089 Preparing packages
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2088 Publishing packages
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2089 xenial/ubuntu-themes: Failed to add changelog message
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2091 Successfully built
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2088 Proposed pocket
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2089 Ready to build
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2090 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2089 Preparing packages
-queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/2071 Preparing packages
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2089 Pending binary packages
-queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/2071 Pending binary packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/1675 Abandoning ticket
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 QA Signoff: Approved
<dobey> robru: wow, 15min is a miracle!
<robru> dobey: yeah, looks like it's only processing one ticket
-queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/2071 Successfully built
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2089 Successfully built
<dobey> robru: can i get this xenial-overlay-only silo set to N/A for QA? it's an initial landing to get stuff moving and some initial testing, but is really not ready for QA level of scrutiny yet, and will only ever land in xenial overlay for a few months
<robru> dobey: which one?
<dobey> robru: 2071
<robru> dobey: ok done
<dobey> robru: ok, thanks!
-queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/2071 QA Signoff: N/A
<robru> dobey: you're welcome
<dobey> now i just have to find a coredev who isn't away today to do the packaging ack i guess
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2087 QA Signoff: Ready
<davmor2> sil2100: you about still?
<dobey> err, britney is complaining about ppc64el for some reason
<dobey> robru: do i need to just abandon and rebuild to clear things up?
<robru> dobey: wait
<robru> dobey: I deleted the old packages, should sort itself out on next run.
<dobey> ok
<dobey> robru: hmm, next next run? seems it didn't with this one
<robru> dobey: maybe one more run? it's possible I deleted it too late in the run for it to notice
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 xenial/dialer-app: debdiff failed: see log for details
<tedg> Hmm, any core-devs around today that could hit publish on this? https://bileto.ubuntu.com/#/ticket/1710
<tedg> kenvandine: are you around? ^
<dobey> mterry is on vacation
 * kenvandine looks
<dobey> oh ken is around, yay
<kenvandine> Ready to build (zesty/libindicator).
<kenvandine> ??
<tedg> kenvandine: Landed with u7 earlier in zesty, needs to be backported to vivid and xenial
<dobey> well the binaries could have been copied in
<tedg> I believe that's what pitti did... not sure, but they have his UID on them.
<dobey> he only uploaded for xenial/vivid
<dobey> copying zesty binaries in too would make the message go away
<dobey> tedg: if you copy the zesty binaries from ubuntu archive into that silo PPA, the "ready to build" will go away
<tedg> Sure, but the message doesn't do anything...
<dobey> i guess
<robru> tedg: dobey: kenvandine: publication will block on that, you should copy the package in
<dobey> or that ^^
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telepathy-ofono, zesty/telepathy-ofono, zesty/telephony-service). Pending binary packages (vivid/dialer-app, xenial/dialer-app, zesty/dialer-app). Successfully built (vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telephony-service, xenial/history-service, xenial/messaging-app, xenial/telephony-service, zesty/history-service, zes
<kenvandine> tedg, so i should copy libindicator 16.10.0+16.10.20160913-0ubuntu1 from zesty into the ppa?
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Publishing packages
<dobey> someone who has permissions should apparently, yes
<kenvandine> robru, dobey, tedg: i copied the package
<dobey> kenvandine: after next bileto run then, things should clear up
<kenvandine> bileto says it's publishing already
<dobey> kenvandine: can you publish https://bileto.ubuntu.com/#/ticket/2071 too please?
<tedg> kenvandine: Thanks!
<kenvandine> but i didn't hit publish
<robru> pitti hit publish
<kenvandine> dobey, has an archive admin reviewed it?
<dobey> kenvandine: it's only going into the overlay ppa
<kenvandine> ah, indeed
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Publish failed: Ready to build
<dobey> heh
-queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/2071 Publishing packages
<tedg> Hmm, don't see any errors. robru, do you see anything here? https://bileto.ubuntu.com/log/1710/publish/1/
-queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/2071 Publish failed: Bad merges
<dobey> sigh
<dobey> tedg: it's because pitti hit publish before the zesty binaries were copied in
<robru> tedg: "Publish failed: Ready to build" as I predicted. the package needs to be copied in (and wait for binaries to finish publishing)
<kenvandine> dobey, your branch wasn't approved!
<dobey> oh
<dobey> and nobody on my team is around today but tedg
<dobey> tedg: care to rubber stamp https://code.launchpad.net/~unity-api-team/unity-scope-snappy/+git/unity-scope-snappy/+merge/308383 please? :)
<tedg> dobey: Done
<dobey> kenvandine: can you publish again please? it's approved now :)
-queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/2071 Publishing packages
<dobey> hah, too fast
<tedg> kenvandine: Okay, the zesty binaries are published in the PPA, can you re-publish mine too :-)
<kenvandine> dobey, done
<kenvandine> tedg, publishing
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telepathy-ofono, zesty/telepathy-ofono, zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telephony-service, xenial/dialer-app, xenial/history-service, xenial/messaging-app, xenial/telephony-service, zesty/dialer-app, zesty/history-service, zesty/messaging-app)
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Publishing packages
<tedg> kenvandine: Thanks!
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Publish failed: Diff missing
<dobey> yeah thanks kenvandine
<robru> kenvandine: diff then publish again
<dobey> hmm, it's too bad i can't copy and paste from my x11 host machine into terminal under unity8 in kvm
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Generating diffs
-queuebot:#ubuntu-ci-eng- marcustomlinson dobey, https://bileto.ubuntu.com/#/ticket/2071 Release pocket
<dobey> oh sweet, i can ssh though. so some win
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 /: Failed to upload diffs. Please try regenerating diffs
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 QA Signoff: Required
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Needs rebuild due to new commits (zesty/qmenumodel). Successfully built (vivid/qmenumodel, vivid/unity8, xenial/qmenumodel, xenial/unity8, zesty/unity8)
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Generating diffs
<sil2100> davmor2: just got back recently
<sil2100> davmor2: what's up?
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Release pocket (zesty/libindicator). Successfully built (vivid/indicator-application, vivid/indicator-bluetooth, vivid/indicator-datetime, vivid/indicator-display, vivid/indicator-keyboard, vivid/indicator-location, vivid/indicator-messages, vivid/indicator-network, vivid/indicator-power, vivid/indicator-session, vivid/indicator-sound, vivid/indicator-transfer, vivid/libi
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 /: Failed to upload diffs. Please try regenerating diffs
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Generating diffs
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 /: Failed to upload diffs. Please try regenerating diffs
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Release pocket (zesty/libindicator). Successfully built (vivid/indicator-application, vivid/indicator-bluetooth, vivid/indicator-datetime, vivid/indicator-display, vivid/indicator-keyboard, vivid/indicator-location, vivid/indicator-messages, vivid/indicator-network, vivid/indicator-power, vivid/indicator-session, vivid/indicator-sound, vivid/indicator-transfer, vivid/libi
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2092 Proposed pocket
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Publishing packages
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Publish failed: Diff missing (zesty/libindicator). Packaging diff requires ACK (vivid/indicator-application, vivid/indicator-bluetooth, vivid/indicator-datetime, vivid/indicator-display, vivid/indicator-keyboard, vivid/indicator-location, vivid/indicator-messages, vivid/indicator-network, vivid/indicator-power, vivid/indicator-session, vivid/indicator-sound, vivid/indicat
<tedg> robru: It seems like publish doesn't like the null diff?
<robru> tedg: no the diff is *missing*. For some reason the three attempts at diffing all failed to upload to swift. I have no idea why
<tedg> robru: Is there any way we can ignore it?
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 QA Signoff: Ready
<robru> tedg: no it's hardcoded in that it can't publish without a diff, even if it's an empty diff it needs to exist
<pitti> o/
<pitti> robru: hello
<robru> pitti: ok welcome. So the ticket is missing the diff for zesty, there have been three attempts to generate diffs but they all fail to upload to swift
<pitti> robru: well, there *is* no zesty/libindicator diff
<pitti> the current zesty versino was backported to x and v to the silo
<robru> pitti: yes, and that should be represented by an empty file in swift
<robru> pitti: bileto looks in swift and finds no such file, so it says "a ha! You can't publish this if you don't know what the diff looks like! Generate diffs doofus!"
<pitti> rihgt, the previous attempt failed, so I tried again as status asked me to
<robru> pitti: yes i also attempted to diff and it failed to upload, i don't know what's wrong with swift
<pitti> do zero-byte files work in general?
<robru> pitti: yes
<robru> pitti: hmmm actually it checks the cached list of filenames from the bileto ticket itself, it doesn't query swift for that info
<pitti> seems too much of a coincidence that it would randomly fail several times on that special caes
<pitti> robru: would it help to copy the zesty dsc to the silo PPA, so that the diff would not actually fail, but work and produce a zero-byte diff?
<robru> pitti: yes I've escalated to webop
<robru> s
<pitti> publishing would still not work as it would not be a new version
<robru> pitti: no, it succeeds in generating the diffs, what fails is uploading the diffs to swift
<pitti> or I upload a Standards-Version bump to the pPA
<pitti> ok, if you are sure about that
<robru> pitti: no. once the diff exists in swift it will harmlessly detect the version matches and not publish the version. it's just getting caught up because it doesn't know that the diff is null, it's blocking because it's worried that there might be some huge, unknown diff
<robru> pitti: https://bileto.ubuntu.com/log/1710/diff/latest/ read the error message, it is completely clear. "2016-10-24 20:06:31,355 INFO Diffed zesty/libindicator." with no errors. then later the error is in uploading.
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2092 Failed to build (zesty/dbusada). Proposed pocket (zesty/dbus)
<pitti> ok
<pitti> robru: oh, so it actually failed on vivid_indicator-sound_packaging_changes.diff
<robru> pitti: yes, in uploading. the diff is generated correctly
<robru> pitti: checking the three different logs it fails in different places so I guess it's some transient infra issues in uploading
<robru> pitti: tedg: kenvandine: I'll try diffing again I guess, hopefully it works.
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Generating diffs
 * pitti keeps hands off
<robru> if it fails again I will use curl to manually hack the ticket to make it go, which in this case is ok because we know the diff is empty, but generally this check is correct as we would never want to publish an unknown package...
<pitti> I think it did fail again
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 /: Failed to upload diffs. Please try regenerating diffs
<robru> blah
<robru> ok hold on, I'll poke it
<pitti> robru: thanks; calling it a day now, I'll check again tomorrow
<robru> pitti: ok, I'll get ken to publish shortly
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Release pocket (zesty/libindicator). Successfully built (vivid/indicator-application, vivid/indicator-bluetooth, vivid/indicator-datetime, vivid/indicator-display, vivid/indicator-keyboard, vivid/indicator-location, vivid/indicator-messages, vivid/indicator-network, vivid/indicator-power, vivid/indicator-session, vivid/indicator-sound, vivid/indicator-transfer, vivid/libi
<robru> awwwww
<robru> missed ken by 4 minutes.
<robru> pitti: if you're still around by chance could you please publish?
 * sil2100 is still around
<sil2100> Should I ACK and publish something?
<sil2100> Ah, the old silo I suppose?
<robru> sil2100: yeah, 1710 please
 * sil2100 blindly ACKs publishes
<sil2100> Oh, got an error 'this ticket is busy'
<robru> sil2100: it's ok, already acked by pitti
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Generating diffs
<robru> sil2100: ah I was trying diffs again, I cancelled it, please publish now
<sil2100> Ok, it's working now it seems
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Publishing packages
<sil2100> I go EOD now, see you tomorrow
<sil2100> o/
<robru> sil2100: no
<sil2100> ...or maybe not
<robru> sil2100: can you run it again? it asploded
<sil2100> Oh, hah
<sil2100> Wow, first time I see that nuclear sign next to a run
<sil2100> Re-running
<robru> sil2100: yeah nuclear means unhandled exception. it used to be a black X but I changed it recently
<sil2100> I'll stick around for a bit, just in case
<robru> sil2100: thanks
<robru> sil2100: fortunately it should skip all the ones it already published, but there's still more it can explode over. I should really make it handle that more gracefully...
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Release pocket (vivid/indicator-application, vivid/indicator-bluetooth, vivid/indicator-datetime, vivid/indicator-display, vivid/indicator-keyboard, vivid/indicator-location, vivid/indicator-messages, vivid/indicator-network, vivid/indicator-power, vivid/indicator-session, vivid/indicator-sound, vivid/indicator-transfer, vivid/libindicator, xenial/indicator-application, x
<sil2100> So far so good I guess?
<sil2100> Ok, I see 'Succeeded'
<robru> sil2100: ok looks good, thanks!
<robru> here's hoping for a quick migration so that PPA can be deleted ;-)
<robru> brb
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Destination version missing from changelog (zesty/indicator-power). Failed to build (xenial/unity8, 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, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Proposed pocket (zesty/indicator-application, zesty/indicator-bluetooth, zesty/indicator-datetime, zesty/indicator-display, zesty/indicator-keyboard, zesty/indicator-location, zesty/indicator-messages, zesty/indicator-network, zesty/indicator-power, zesty/indicator-session, zesty/indicator-sound, zesty/indicator-transfer). Release pocket (vivid/indicator-application, vivi
<sil2100> Oh, indeed, 'the final silo' ;)
<sil2100> o/
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Proposed pocket (zesty/indicator-network, zesty/indicator-session). Release pocket (vivid/indicator-application, vivid/indicator-bluetooth, vivid/indicator-datetime, vivid/indicator-display, vivid/indicator-keyboard, vivid/indicator-location, vivid/indicator-messages, vivid/indicator-network, vivid/indicator-power, vivid/indicator-session, vivid/indicator-sound, vivid/ind
#ubuntu-ci-eng 2016-10-25
<pitti> robru: yay, thanks for fixing tihs
<robru> pitti: you're welcome! Still not sure what happened to the swift uploads but i hacked around it
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 QA Signoff: Required
<davmor2> mzanetti: where's the silo dude I've been waiting on rebuilds for fixes for 24 hours man ;)  Thinks that's fair after your lightning talk :P
<mzanetti> davmor2, yeah... britney took ages, and then it failed
<mzanetti> davmor2, some timeout
<mzanetti> I kicked it again
<davmor2> mzanetti: \o/
<mzanetti> fingers crossed
<davmor2> mzanetti: no worries dude :)
-queuebot:#ubuntu-ci-eng- seb128, https://bileto.ubuntu.com/#/ticket/2093 Pending binary packages
-queuebot:#ubuntu-ci-eng- seb128, https://bileto.ubuntu.com/#/ticket/2093 Successfully built
-queuebot:#ubuntu-ci-eng- sil2100 alf, https://bileto.ubuntu.com/#/ticket/2065 QA Signoff: Approved
<mzanetti> davmor2, sorry, again a timeout... kicked it again :/
<davmor2> sil2100: ^ fixedededed it please
<sil2100> \o/
<sil2100> Yeah, let me manually publish this silo
<sil2100> davmor2: thanks!
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/1679 Destination version missing from changelog (zesty/ubuntu-touch-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, zesty/gsettings-ubuntu-touch-schemas, zesty/lightdm
-queuebot:#ubuntu-ci-eng- sil2100 alf, https://bileto.ubuntu.com/#/ticket/2065 Release pocket (vivid/ubuntu-touch-session, xenial/ubuntu-touch-session). Successfully built (yakkety/ubuntu-touch-session)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2066 /: Failed to update local lp:ubuntu-system-settings cache
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2086 /: Failed to update local lp:libertine cache
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2089 Publishing packages
 * sil2100 goes to lunch
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2091 Publishing packages
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2086 Needs rebuild due to new commits (zesty/libertine). Successfully built (vivid/libertine, xenial/libertine)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2066 Successfully built
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2089 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2091 Proposed pocket
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Release pocket
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Failed to build (xenial/unity8, zesty/unity8). Needs rebuild due to new commits (zesty/indicator-power). 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/qtmir, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 zesty/indicator-power: Failed to branch lp:~ci-train-bot/indicator-power/indicator-power-ubuntu-zesty-1710
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2094 /: Failed to upload diffs. Please try regenerating diffs
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Ready to build
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 QA Signoff: Required
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Needs rebuild due to new commits (yakkety/indicator-network). Successfully built (vivid/indicator-network, xenial/indicator-network)
<tedg> sil2100: Could you look at this silo? I think everything merged, but it had an error on one and now has gone back to ready to build. https://bileto.ubuntu.com/#/ticket/1710
<tedg> I *think* we can just abandon it now, but I'm not sure.
<sil2100> tedg: looking, I'll check if all merges went in
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Too many merge targets: lp:messaging-app, lp:messaging-app/staging
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2094 Diff missing
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Too many merge targets: lp:telephony-service, lp:telephony-service/staging
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2094 Generating diffs
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2091 Release pocket
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2094 Diff missing
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2094 Successfully built
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2094 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Too many merge targets: lp:messaging-app, lp:messaging-app/staging
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 /: Failed to upload diffs. Please try regenerating diffs
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Merging branches
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 zesty/indicator-location: Failed to branch lp:~ci-train-bot/indicator-location/indicator-location-ubuntu-zesty-1710
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Ready to build
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Too many merge targets: lp:telephony-service, lp:telephony-service/staging
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Pending binary packages (vivid/unity8, xenial/unity8, zesty/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- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2094 Successfully built
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Successfully built
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Too many merge targets: lp:messaging-app, lp:messaging-app/staging
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Too many merge targets: lp:telephony-service, lp:telephony-service/staging
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Successfully built
<boiko> jibel: hi, we have silo 2085 which basically adds snap .yaml files to dialer and messaging, can we skip QA validation for that one ? It doesn't  change any of the existing deb or source code
<sil2100> boiko: jibel is off, you'd best poke davmor2 - but I guess that should be ok for now
<boiko> davmor2: any opinion on that? ^
<boiko> sil2100: thanks
<sil2100> I suppose it should get a fast-track tag and just letting it through
<davmor2> boiko: I think it's safer to push it through on fast-track and just ensure that it opens runs etc and the yaml affect the system.
<boiko> sil2100: how do I get it on fast-track? never did that before :-S
<davmor2> boiko: we add it it's fine
<sil2100> Yeah, it's a QA thing ;)
<boiko> davmor2: ah ok, cool! thanks!
<davmor2> sil2100, oSoMoN: 1919 I'm just testing it on arm32 arm64 passes when I approve this sil2100 there is some work you need to do according to the ticket
<davmor2> sil2100: I at least assume it is something you have to do :)
<oSoMoN> davmor2, youâre correct, after publishing silo 1919 a trainguard will need to delete the oxide-qt-arm64 package from the stable phone overlay PPA
<davmor2> oSoMoN: yeah just giving sil2100 a heads up to keep an eye out for it
<sil2100> Yeah
<sil2100> Will keep an eye out on that one, thanks!
<davmor2> sil2100, oSoMoN: so this is good on arm32 too just hit the approve button
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/1919 QA Signoff: Approved
<sil2100> \o/
<sil2100> On to publishing then
<sil2100> Thanks
<oSoMoN> davmor2, sil2100: thanks!
-queuebot:#ubuntu-ci-eng- sil2100 alf, https://bileto.ubuntu.com/#/ticket/2065 Merging branches
<sil2100> oSoMoN: oh, also, I discussed with dbarth during the sprint already but just wanted to make double sure - we don't really need to publish the xenial one to the overlay, right? Since the xenial-updates one should be good enough?
<oSoMoN> sil2100, yup, thatâs not needed
<sil2100> Or do you prefer to be on the safe side and get the xenial-overlay one there?
<sil2100> ACK
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Too many merge targets: lp:messaging-app, lp:messaging-app/staging
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/1919 Release pocket
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/1679 Needs rebuild due to new commits (zesty/ubuntu-touch-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, zesty/gsettings-ubuntu-touch-schemas, zesty/lightdm, zesty/un
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2094 QA Signoff: Ready
<mardy> rvr: ^ that's a quick and easy one :-)
<sil2100> It's never easy
<sil2100> Never...
<sil2100> ;)
<rvr> LOL
<rvr> davmor2 is taking care of silos this week
<davmor2> sil2100: +1 you also missed some ever's
<davmor2> mardy: it'll happen when it happens :)
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Too many merge targets: lp:telephony-service, lp:telephony-service/staging
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 QA Signoff: Ready
<mardy> davmor2: no bribes accepted?
<davmor2> mardy: not right now too many balls in the air.  It won't be too long be it probably won't be today
<mzanetti> sil2100, davmor2: https://bileto.ubuntu.com/#/ticket/2022#audit_log
<mzanetti> hell yeah!
<mardy> davmor2: oh, sure, I'm not in such a hurry, it can wait a few days
<sil2100> Woo!
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Too many merge targets: lp:messaging-app, lp:messaging-app/staging
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2088 Release pocket
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 Merging branches
-queuebot:#ubuntu-ci-eng- tedg seb128 pitti laney charles, https://bileto.ubuntu.com/#/ticket/1710 zesty/indicator-application: Failed to branch lp:~ci-train-bot/indicator-application/indicator-application-ubuntu-zesty-1710
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2090 Needs rebuild due to new commits
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Generating diffs
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Currently building (zesty/telephony-service). Failed to build (xenial/telepathy-ofono, zesty/telepathy-ofono). Pending binary packages (xenial/telephony-service). Successfully built (vivid/dialer-app, vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telephony-service, xenial/dialer-app, xenial/history-service, xenial/messaging-app, zesty/dialer-app, zesty
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 /: Failed to upload diffs. Please try regenerating diffs
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Generating diffs
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 /: Failed to upload diffs. Please try regenerating diffs
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telepathy-ofono, zesty/telepathy-ofono). Needs rebuild due to new commits (zesty/messaging-app). Successfully built (vivid/dialer-app, vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telephony-service, xenial/dialer-app, xenial/history-service, xenial/messaging-app, xenial/telephony-service, zesty/dialer-app, zesty/history-service
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Successfully built
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Generating diffs
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 /: Failed to upload diffs. Please try regenerating diffs
<robru> holy hell
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2095 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Successfully built
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2095 Successfully built
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2096 Preparing packages
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2086 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Needs rebuild due to new commits (zesty/qmenumodel). Successfully built (vivid/qmenumodel, vivid/unity8, xenial/qmenumodel, xenial/unity8, zesty/unity8)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2096 /: Failed to upload diffs. Please try regenerating diffs
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2096 Generating diffs
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2096 Diff missing
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2086 Successfully built
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2096 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Needs rebuild due to new commits (zesty/qmenumodel, zesty/unity8). Successfully built (vivid/qmenumodel, vivid/unity8, xenial/qmenumodel, xenial/unity8)
<dobey> kenvandine: hey. care to ack/publish another silo for me? :) https://bileto.ubuntu.com/#/ticket/2095
<kenvandine> dobey, so this will actually remove paid apps support?
<dobey> kenvandine: we already don't have paid apps support in z/y/x+overlay, as we don't ship the store there. this doesn't affect vivid
<dobey> removed this to help clean up the unity8 snap a bit
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2095 Publishing packages
<dobey> thanks
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2096 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2095 Proposed pocket (zesty/unity-scope-click). Release pocket (xenial/unity-scope-click)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2096 Pending binary packages
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2096 Abandoning ticket
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Generating diffs
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2096 Pending binary packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Successfully built
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/1679 Needs rebuild due to new commits (zesty/lightdm, zesty/ubuntu-touch-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, zesty/gsettings-ubuntu-touch-schemas, zesty/un
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2096 Successfully built
<dobey> huh. why are unity-scope-click and unity8 autopkgtests marked as always failing on all archs on zesty? and why does my silo not have an excuses file for xenial?
<dobey> weird
<robru> dobey: which one?
<robru> dobey: the always failed is probably due to zesty autopkgtest results being wrong since it's newly opened
<dobey> robru: 2095
<robru> oh wow there's officially zero tickets in britney
<dobey> huh
<robru> dobey: not sure why you never got a xenial run there, but since the ticket is published it will be ignored by bileto britney and hopefully soon appear in p-m britney
<dobey> robru: well the tests were run (one unity8 test is still running)
<dobey> it's just that there is no excuses file and for some reason it was set to approved because of the zesty situation it seems
<robru> dobey: yeah but britney stops caring about your ticket once the status stops containing 'Successfully built', so britney won't update it to find the autopkgtest results now
<dobey> robru: sure, but that doesn't explain why it lied about the status in the first place
<robru> dobey: yeah that's quite strange
<robru> dobey: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2095-excuses/2016-10-25_18:15:01/2095_xenial_excuses.html looks like xenial ran once
<dobey> right, but didn't link that into the ticket page for some reason, and didn't block on those tests getting finished
<dobey> hmm
<robru> dobey: well that xenial one isn't linked on the ticket page because there was a subsequent run that only considered zesty
<robru> dobey: discoverble if you click on "list of past excuses"
<dobey> robru: ok, but why did it only consider zesty? :)
<robru> dobey: https://bileto.ubuntu.com/static/britney/log_2016-10-25_18:25:01.txt the 404 explains your always-failed, the 502 contacting swift probably explains why xenial didn't update there
<dobey> hmm
<dobey> so a bug in britney not handling all HTTP errors properly i guess?
<robru> dobey: oops, missed your message. seems britney correctly errored out but bileto ignored the error and reported the status anyway.
<robru> I'll file a bug
<robru> dobey: https://bugs.launchpad.net/bileto/+bug/1636643
<ubot5`> Ubuntu bug 1636643 in Bileto "Bileto ignores britney problems" [Undecided,New]
#ubuntu-ci-eng 2016-10-26
<robru> Hmmm
-queuebot:#ubuntu-ci-eng- robru, https://bileto.ubuntu.com/#/ticket/2097 Abandoning ticket
<robru> Oh...
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2096 Generating diffs
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2096 Successfully built
<robru> Man i thought queuebot was busted for a while there
<oSoMoN> davmor2, good morning! how is testing of silo 2087 looking so far?
<davmor2> oSoMoN: need to test it on xenial for the sound issue and a couple of other tests but ran out of time last night so far so good
<oSoMoN> cool, let me know if you find any issues with it
<davmor2> oSoMoN: however it is Andrews first official set of patches so I will go out of my way to break it cause you know evil and everything ;)
<oSoMoN> heh :)
<davmor2> oSoMoN: hmm browser on xenial m10 is crashing
<oSoMoN> davmor2, reliably?
<davmor2> oSoMoN: only everytime I open it ;)
<oSoMoN> davmor2, and was it launching fine without the silo? IÂ must admit IÂ havenât flashed xenial on my M10 to test it
<davmor2> oSoMoN: let me try a fresh flash first
<oSoMoN> thanks
<davmor2> oSoMoN: meh looks like it is dying on xenial so I blame sil2100 it's all bound to be his fault ;)
<davmor2> oSoMoN: let me check on versions
<oSoMoN> davmor2, thanks. Iâm interested in app logs and crash files, too (can you maybe file a bug with those?)
<davmor2> oSoMoN: sure let me make sure that the newer oxide landed first cause it was opening fine with that, it might be that I'm flashing the wrong version or something
<oSoMoN> ack
<davmor2> oSoMoN, sil2100: hah I wonder if that is the issue, I tested the silo 1919 on vivid and xenial with the xenial bit in, that got removed for release right and now in the image it isn't working \o/
<davmor2> oSoMoN, sil2100: also the version in xenial seems to be 1.17.9 and the version in the silo was 1.17.6 so now I'm confused
<oSoMoN> davmor2, it was 1.17.9 in the silo too, but the description said "1.17.6"
<oSoMoN> (it was originally 1.17.6 and the version had been updated in the silo, but the description wasnât)
<davmor2> oSoMoN: ah phew
<davmor2> oSoMoN: so now I'm wondering if the xenial bit should of been included on the xenial image or not :)
<davmor2> sil2100: ^
<oSoMoN> davmor2, it could very well be indeed
<davmor2> let me trigger a bug report and add the info you need to it
<oSoMoN> sil2100, you discarded the xenial build of oxide 1.17.9 from silo 1919 before publishing, right? Iâm thinking that it might have been needed too, because it had been built against packages in the overlay (including private Qt headersâ¦)
<davmor2> oSoMoN: https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1636760  meh so it looks like the crash file is no more for some reason but here are the logs from browser any others that would be useful?
<ubot5`> Ubuntu bug 1636760 in webbrowser-app (Ubuntu) "Crash on Xenial" [Undecided,New]
<oSoMoN> davmor2, thanks. unfortunately thereâs nothing of interest in the log file. could you maybe try to get a crash file again?
<davmor2> oSoMoN: will do
<oSoMoN> davmor2, if not IÂ can try to do that this afternoon, I donât have my M10 with me atm
<davmor2> oSoMoN: no worries I'll try and kill it here and if I do I'll add the crash file I might be able to see the url for the one it uploaded give me a few
<oSoMoN> ok, thanks
<davmor2> oSoMoN: damn it ofcourse it opens that in the browser right D'oh
<oSoMoN> heh :)
<sil2100> oSoMoN: yeah, that's why I asked you and dbarth if that was needed
<sil2100> hmmm
<sil2100> Worst thing is that now that PPAs are ephemeral, we can't get the binaries back
<oSoMoN> sil2100, well we can still do a rebuild in a new PPA targetting xenial+overlay only, itâs not a big deal as our official images are still vivid-based
<sil2100> oSoMoN: yeah, I just dread on the thought of prepping a source package of oxide ;)
<oSoMoN> sil2100, we already have the source package in xenial-updates
-queuebot:#ubuntu-ci-eng- abeato, https://bileto.ubuntu.com/#/ticket/2098 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
<sil2100> oSoMoN: yes, but you need to modify the changelog version to do the rebuild
<sil2100> And that requires extracting the source and re-building the source for upload, which always is sooo slow on my PC ;)
<davmor2> oSoMoN: okay this is weird I get this appear _usr_bin_webbrowser-app.32011.crash but it only stays for a second and then disappears :(
<oSoMoN> davmor2, itâs gonna take a while to land an updated oxide 1.17.9 in xenial+overlay, can we unblock 2087 in the meantime?
<davmor2> oSoMoN: not really cause I need to test on xenial for the sound fix only obviously can't because I can't open a page :)  there were a couple of others that were both xenial and vivid two I think, the vivid part is done it's the xenial bit I need to test :)
<oSoMoN> davmor2, the sound fix can be tested on desktop (thatâs where it was reported actually)
<davmor2> oSoMoN: should only take 20-30 minutes once I have the oxide with fixes
<oSoMoN> davmor2, the issue is even reproducible (and fixed with the silo) in a virtual machine
<oSoMoN> sil2100, so, can we do a silo with oxide 1.17.9 targetting xenial+overlay only? it doesnât need to be right now, itâs fine if you kick the rebuild of the source package when your computer is idle
<davmor2> oSoMoN: okay let me get the 2 I'm working on out of the way then and I'll take it a look of it on desktop then
<oSoMoN> davmor2, thanks!
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato, https://bileto.ubuntu.com/#/ticket/2085 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 QA Signoff: Approved
<davmor2> mzanetti: Wait for it
 * mzanetti runs
<mzanetti> oh
<davmor2> mzanetti: much happier now that is fixed :)
<mzanetti> approved!
<mzanetti> niiice!
<mzanetti> thanks dave!
<mzanetti> good catch on that indicator menu
<davmor2> mzanetti: that's what we're here for :)
-queuebot:#ubuntu-ci-eng- pitti seb128, https://bileto.ubuntu.com/#/ticket/2099 Preparing packages
<Saviq> sil2100, can you land https://bileto.ubuntu.com/#/ticket/2022 please?
<sil2100> o/
<Saviq> I promise I won't give you any more Chef's salty chocolate balls
<sil2100> Phew
<sil2100> Ok, packaging changes look good, publishing
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Publishing packages
-queuebot:#ubuntu-ci-eng- pitti seb128, https://bileto.ubuntu.com/#/ticket/2099 Pending binary packages
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/1679 Destination version missing from changelog (zesty/unity8). Needs rebuild due to new commits (zesty/lightdm, zesty/ubuntu-touch-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-desk
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/1721 Destination version missing from changelog (zesty/ubuntu-settings-components). Failed to build (vivid/ubuntu-system-settings). Successfully built (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components, xenial/ubuntu-system-settings, zesty/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Destination version missing from changelog (zesty/qtmir, 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-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Proposed pocket (zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-settings-components, zesty/unity-notifications, zesty/unity8). Release pocket (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenia
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Preparing packages
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Needs rebuild due to burned version number (vivid/unity8, xenial/unity8). Needs rebuild due to new commits (zesty/unity8)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Destination version missing from changelog (zesty/unity8). Needs rebuild due to new commits (zesty/ubuntu-settings-components). Successfully built (vivid/ubuntu-settings-components, vivid/unity8, xenial/ubuntu-settings-components, xenial/unity8)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2095 Release pocket
-queuebot:#ubuntu-ci-eng- pitti seb128, https://bileto.ubuntu.com/#/ticket/2099 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Currently building (vivid/unity8, xenial/unity8). Dependency wait (zesty/unity8). Failed to build (vivid/qmenumodel, zesty/qmenumodel). Needs building (xenial/qmenumodel)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Dependency wait (zesty/unity8). Failed to build (vivid/qmenumodel, zesty/qmenumodel). Successfully built (vivid/unity8, xenial/qmenumodel, xenial/unity8)
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato, https://bileto.ubuntu.com/#/ticket/2085 Publishing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, 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- boiko, https://bileto.ubuntu.com/#/ticket/1897 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Currently building (vivid/history-service, vivid/telepathy-ofono, vivid/telephony-service, xenial/history-service, xenial/telephony-service, zesty/history-service, zesty/telephony-service). Failed to build (xenial/telepathy-ofono, zesty/telepathy-ofono). Needs building (vivid/dialer-app, vivid/messaging-app, xenial/dialer-app, xenial/messaging-app, zesty/messaging-app). Successf
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato, https://bileto.ubuntu.com/#/ticket/2085 Proposed pocket (zesty/dialer-app, zesty/messaging-app). Release pocket (vivid/dialer-app, vivid/messaging-app, xenial/dialer-app, xenial/messaging-app)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2086 Needs rebuild due to new commits (zesty/libertine). Successfully built (vivid/libertine, xenial/libertine)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2086 Abandoning ticket
-queuebot:#ubuntu-ci-eng- boiko, https://bileto.ubuntu.com/#/ticket/1897 Failed to build (xenial/history-service, xenial/telephony-service, zesty/history-service). Needs building (vivid/history-service, vivid/telephony-service, zesty/telephony-service). Ready to build (vivid/telepathy-qt, xenial/telepathy-qt, zesty/telepathy-qt)
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon, https://bileto.ubuntu.com/#/ticket/1319 Currently building (vivid/telephony-service). Failed to build (xenial/telepathy-ofono, zesty/telepathy-ofono). Needs building (vivid/dialer-app, vivid/history-service, vivid/messaging-app, xenial/dialer-app, xenial/messaging-app, zesty/history-service, zesty/messaging-app, zesty/telephony-service). Successfully built (vivid/telepathy-ofono, xenial/history-service, xenial/telepho
-queuebot:#ubuntu-ci-eng- pitti seb128, https://bileto.ubuntu.com/#/ticket/2099 Publishing packages
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 This ticket must be migrated to zesty+xenial+vivid before it can be built
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2100 Preparing packages
-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- pitti seb128, https://bileto.ubuntu.com/#/ticket/2099 Proposed pocket
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2100 Dependency wait (xenial/unity-scope-snappy). Successfully built (xenial/go-unityscopes)
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Currently building (vivid/messaging-app, xenial/messaging-app). Failed to build (xenial/telepathy-ofono, zesty/telepathy-ofono). Needs building (zesty/history-service). Successfully built (vivid/dialer-app, vivid/history-service, vivid/telepathy-ofono, vivid/telephony-service, xenial/dialer-app, xenial/history-service, xenial/telephony-service, zesty/dialer-app, zesty/me
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Preparing packages
-queuebot:#ubuntu-ci-eng- boiko, https://bileto.ubuntu.com/#/ticket/1897 Failed to build (xenial/history-service, xenial/telephony-service, zesty/history-service). Needs building (vivid/history-service). Pending binary packages (zesty/telephony-service). Ready to build (vivid/telepathy-qt, xenial/telepathy-qt, zesty/telepathy-qt). Successfully built (vivid/telephony-service)
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1993 Abandoning ticket
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 zesty/indicator-printers: Failed to commit https://code.launchpad.net/~ted/indicator-printers/systemd-unit. 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/2081 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2100 Successfully built (xenial/go-unityscopes). Uploading build (xenial/unity-scope-snappy)
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telepathy-ofono, zesty/telepathy-ofono). Successfully built (vivid/dialer-app, vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telephony-service, xenial/dialer-app, xenial/history-service, xenial/messaging-app, xenial/telephony-service, zesty/dialer-app, zesty/history-service, zesty/messaging-app, zesty/telephony-service)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 /: Failed to upload diffs. Please try regenerating diffs
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Preparing packages
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato, https://bileto.ubuntu.com/#/ticket/2085 Release pocket
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Failed to build
-queuebot:#ubuntu-ci-eng- boiko, https://bileto.ubuntu.com/#/ticket/1897 Failed to build (xenial/history-service, xenial/telephony-service, zesty/history-service). Ready to build (vivid/telepathy-qt, xenial/telepathy-qt, zesty/telepathy-qt). Successfully built (vivid/history-service, vivid/telephony-service, zesty/telephony-service)
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telepathy-ofono, zesty/telepathy-ofono). Needs rebuild due to new commits (zesty/dialer-app, zesty/messaging-app). Successfully built (vivid/dialer-app, vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telephony-service, xenial/dialer-app, xenial/history-service, xenial/messaging-app, xenial/telephony-service, zesty/history
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2100 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Destination version missing from changelog (zesty/unity8). Failed to build (vivid/qmenumodel). Successfully built (vivid/unity8, xenial/unity8, zesty/qmenumodel). Uploading build (xenial/qmenumodel)
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Failed to build (zesty/unity). Needs building (zesty/indicator-printers)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Proposed pocket (zesty/qtmir, zesty/qtmir-gles, zesty/ubuntu-settings-components, zesty/unity-notifications, zesty/unity8). Release pocket (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Destination version missing from changelog (zesty/unity8). Failed to build (vivid/qmenumodel). Successfully built (vivid/unity8, xenial/qmenumodel, xenial/unity8, zesty/qmenumodel)
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Failed to build (zesty/unity). Successfully built (zesty/indicator-printers)
<robru> morphis: hey, what's the deal with https://bileto.ubuntu.com/#/ticket/1632 ? Are you still working on that?
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Preparing packages
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 zesty/compiz: Failed to commit https://code.launchpad.net/~pitti/compiz/standards-version. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- pitti seb128, https://bileto.ubuntu.com/#/ticket/2099 Release pocket
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Failed to build (zesty/unity). Ready to build (zesty/compiz). Successfully built (zesty/indicator-printers)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Generating diffs
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Destination version missing from changelog (zesty/unity8). Failed to build (vivid/qmenumodel). Successfully built (vivid/unity8, xenial/qmenumodel, xenial/unity8, zesty/qmenumodel)
<oSoMoN> trainguards: can someone please publish silo 2087 for me?
<sil2100> oSoMoN: let me give it a try
<sil2100> hm, I don't see it approved by QA?
<oSoMoN> sil2100, well it is: https://trello.com/c/YSHgTSds/3705-2087-ubuntu-2087-webbrowser-app-osomon , I guess the status hasnât propagated to bileto yet?
 * oSoMoN â doctor, bbiab
<robru> Oh god i need to roll trello into bileto so badly
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Currently building (zesty/compiz). Failed to build (zesty/unity). Successfully built (zesty/indicator-printers)
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2087 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2087 Publishing packages
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Failed to build (zesty/unity). Successfully built (zesty/compiz, zesty/indicator-printers)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2066 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2066 This ticket must be migrated to zesty+xenial+vivid before it can be built
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2087 Proposed pocket (zesty/webbrowser-app). Release pocket (vivid/webbrowser-app, xenial/webbrowser-app)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/1994 Abandoning ticket
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Preparing packages
<robru> kenvandine: huh that's odd...
<robru> kenvandine: just copy 2066 manually I guess
<robru> kenvandine: like, copy the yakkety packages to zesty I mean
<kenvandine> :/
<kenvandine> no time to deal with that atm... busy
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/1994 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Currently building (vivid/unity8, xenial/unity8, zesty/unity8). Failed to build (vivid/qmenumodel). Successfully built (xenial/qmenumodel, zesty/qmenumodel)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Proposed pocket (zesty/qtmir, zesty/qtmir-gles, zesty/ubuntu-settings-components, zesty/unity-notifications). Release pocket (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifica
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2066 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Failed to build (vivid/qmenumodel). Pending binary packages (vivid/unity8, xenial/unity8, zesty/unity8). Successfully built (xenial/qmenumodel, zesty/qmenumodel)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Proposed pocket (zesty/ubuntu-settings-components). Release pocket (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-notifications, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-notifications, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Preparing packages
-queuebot:#ubuntu-ci-eng- andreas-pokorny, https://bileto.ubuntu.com/#/ticket/2084 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Destination version missing from changelog (zesty/unity8). Successfully built (vivid/qmenumodel, vivid/unity8, xenial/qmenumodel, xenial/unity8, zesty/qmenumodel)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2102 Successfully built
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2102 Publishing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2100 Needs rebuild due to burned version number (xenial/go-unityscopes). Successfully built (xenial/unity-scope-snappy)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2102 Proposed pocket (zesty/go-unityscopes). Release pocket (xenial/go-unityscopes)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Needs building
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2100 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/1994 Needs building (xenial/content-hub). Successfully built (vivid/content-hub, zesty/content-hub)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2100 Needs rebuild due to burned version number (xenial/go-unityscopes). Successfully built (xenial/unity-scope-snappy)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Destination version missing from changelog (zesty/unity8). Successfully built (vivid/qmenumodel, vivid/unity8, xenial/qmenumodel, xenial/unity8, zesty/qmenumodel)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Destination version missing from changelog (zesty/ubuntu-settings-components). Ready to build (vivid/unity8, xenial/unity8, zesty/unity8). Successfully built (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/1994 Successfully built
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2102 Release pocket
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2104 Destination version missing from changelog (zesty/ubuntu-settings-components). Ready to build (vivid/unity8, xenial/unity8, zesty/unity8). Successfully built (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Preparing packages
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 zesty/unity: Failed to commit https://code.launchpad.net/~pitti/unity/gdk-api. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2087 Release pocket
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Preparing packages
<tedg> robru: bileto stack trace: https://bileto.ubuntu.com/log/2105/build/1/
<robru> tedg: that's a transient issue connecting to launchpad, just run it again
<tedg> robru: K, restarting
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Failed to build
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Failed to build (zesty/ubuntu-app-launch). Pending binary packages (vivid/ubuntu-app-launch). Uploading build (xenial/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Successfully built
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Failed to build (zesty/ubuntu-app-launch). Successfully built (vivid/ubuntu-app-launch, xenial/ubuntu-app-launch)
#ubuntu-ci-eng 2016-10-27
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Preparing packages
-queuebot:#ubuntu-ci-eng- robru, https://bileto.ubuntu.com/#/ticket/2097 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Destination version missing from changelog (zesty/qtmir). 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-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Failed to build (zesty/ubuntu-app-launch). Pending binary packages (vivid/ubuntu-app-launch, xenial/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Failed to build (vivid/ubuntu-app-launch). Successfully built (xenial/ubuntu-app-launch, zesty/ubuntu-app-launch)
<oSoMoN> davmor2, how do you flash xenial onto an M10?
<oSoMoN> "ubuntu-device-flash query --device=frieza --list-channels" only lists staging, stable, rc and rc-proposed, no devel or devel-proposed
<davmor2> ubuntu-device-flash touch --channel ubuntu-touch/staging/ubuntu --device frieza_arm64 --bootstrap --recovery-image recovery-images/recovery-frieza.img
<davmor2> oSoMoN: ^
<oSoMoN> davmor2, aha, so itâs the arm64 image, afaik oxide was never actually tested on arm64
<davmor2> hmmmm so why did it work with the patches but didn't without :(
<oSoMoN> davmor2, I donât know, Iâll try to find out
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Preparing packages
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Preparing packages
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Dependency wait (zesty/unity8). Destination version missing from changelog (zesty/qtubuntu). Pending binary packages (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/qtub
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Dependency wait (zesty/unity8). Destination version missing from changelog (zesty/qtubuntu). 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
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Successfully built
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Publishing packages
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Publish failed: Bad merges
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Publishing packages
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Proposed pocket
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2066 This ticket must be migrated to zesty+xenial+vivid before it can be built
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2066 QA Signoff: Required
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2066 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Needs rebuild due to new commits (zesty/ubuntu-settings-components). Ready to build (vivid/unity8, xenial/unity8, zesty/unity8). Successfully built (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2066 Pending binary packages (xenial/ubuntu-system-settings). Successfully built (vivid/ubuntu-system-settings). Uploading build (zesty/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 zesty/ubuntu-settings-components: Failed to merge https://code.launchpad.net/~3v1n0/ubuntu-settings-components/radio-menuitem
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2107 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
<oSoMoN> sil2100, I created https://bileto.ubuntu.com/#/ticket/2107 to have a silo to push oxide 1.17.9 (xenial) to. If I prepare the source package with updated version number in my personal PPA, could you then copy it over to the silo?
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Proposed pocket (zesty/unity). Release pocket (zesty/compiz, zesty/indicator-printers)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2104 Needs rebuild due to new commits (zesty/ubuntu-settings-components). Ready to build (vivid/unity8, xenial/unity8, zesty/unity8). Successfully built (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2022 Release pocket
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2066 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 zesty/ubuntu-settings-components: Failed to merge https://code.launchpad.net/~3v1n0/ubuntu-settings-components/touch+pointer-styles
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 zesty/ubuntu-settings-components: Failed to merge https://code.launchpad.net/~3v1n0/ubuntu-settings-components/new-calendar-design
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2077 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, yakkety/qtmir). Successfully built (xenial/miral)
-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- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Needs rebuild due to new commits (zesty/unity8). Successfully built (vivid/qmenumodel, vivid/unity8, xenial/qmenumodel, xenial/unity8, zesty/qmenumodel)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Needs rebuild due to new commits (zesty/qtmir, 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-gles, zesty/unity-api)
-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). Successfully built (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components, xenial/ubuntu-system-settings, zesty/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Needs rebuild due to new commits (zesty/ubuntu-settings-components). Ready to build (vivid/unity8, xenial/unity8, zesty/unity8). Successfully built (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- dednick, https://bileto.ubuntu.com/#/ticket/2026 Needs rebuild due to new commits (zesty/qtubuntu, zesty/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, 
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Dependency wait (vivid/unity8, xenial/unity8). Needs rebuild due to new commits (zesty/ubuntu-settings-components, zesty/unity8). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/qmenumodel)
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2032 Needs rebuild due to new commits (yakkety/qtmir, yakkety/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/unity8, yakkety/qtmir-gles)
-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)
<mardy> sil2100: hi! looks like I don't have permissions to publish siloes anymore, could you please press the button for me on https://bileto.ubuntu.com/#/ticket/1971 ?
<sil2100> mardy: hey! You do have the permissions, but whenever there are packaging changes only core-devs can do the publishing
<sil2100> Let me take a look
<sil2100> (it's an archive requirement)
<sil2100> Oh, yakkety still in there
<sil2100> Will have to manually do the publish...
<mardy> sil2100: yes, indeed it's not a SRU, it can go to zesty indeed
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Preparing packages
-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/2106 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2104 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 zesty/unity8: Failed to merge https://code.launchpad.net/~3v1n0/unity8/calendar-days
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 zesty/unity8: Failed to merge https://code.launchpad.net/~3v1n0/unity8/radio-button-menus
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 zesty/unity8: Failed to merge https://code.launchpad.net/~3v1n0/unity8/calendar-day-selection
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2104 zesty/unity8: Failed to merge https://code.launchpad.net/~3v1n0/unity8/radio-button-menus
<boiko> trainguards: can someone please remove the s390x binaries from silo 1319? also, is the trick of build depending on upstart still work for avoiding building on that arch?
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Needs rebuild due to new commits (zesty/unity8). Successfully built (vivid/qmenumodel, vivid/unity8, xenial/qmenumodel, xenial/unity8, zesty/qmenumodel)
<sil2100> boiko: hey! I guess it should still work... I don't have the power to remove just selected arch binaries
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Needs rebuild due to new commits (zesty/ubuntu-settings-components). Ready to build (vivid/unity8, xenial/unity8, zesty/unity8). Successfully built (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components)
<sil2100> mardy: hm, looking through the changes - I see you disabled tests for arm64 there, but can't really see why?
<sil2100> mardy: the bug it's pointing to is the arm64 QML segfault one, but this one has been resolved on the builders
<sil2100> mardy: so is there any other reason for disabling the tests there?
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2104 Needs rebuild due to new commits (zesty/ubuntu-settings-components). Ready to build (vivid/unity8, xenial/unity8, zesty/unity8). Successfully built (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components)
<boiko> sil2100: is there anyone who could? or maybe we should just remove all & rebuild?
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2104 Preparing packages
<boiko> sil2100: it would be dialer-app, messaging-app and telephony-service
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 zesty/unity8: Failed to merge https://code.launchpad.net/~3v1n0/unity8/calendar-day-selection
<mardy> sil2100: ouch
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Preparing packages
<mardy> sil2100: can we land it anyway, and I file a bug to re-enable arm64 tests?
<mardy> sil2100: mmm... wait, I don't see that change in the MPs...
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 zesty/unity8: Failed to merge https://code.launchpad.net/~3v1n0/unity8/calendar-days
<mardy> marcustomlinson: maybe the diff is old?
<mardy> sil2100: ops ^
<mardy> marcustomlinson: sorry for the noise :-)
<sil2100> hm
<marcustomlinson> ;)
<sil2100> mardy: can't see it in the MPs as well, but the source package in the silo has that change
<sil2100> So maybe it was removed from the silo but not rebuilt?
<sil2100> This would complicate stuff
<sil2100> Looks like after updating the MPs only one project was rebuilt
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Needs rebuild due to new commits (zesty/dialer-app, zesty/messaging-app). Successfully built (vivid/dialer-app, vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telephony-service, xenial/dialer-app, xenial/history-service, xenial/messaging-app, xenial/telepathy-ofono, xenial/telephony-service, zesty/history-service, zesty/telepathy-ofono, zesty/te
<mardy> sil2100: ah, that might be...
<mardy> sil2100: so I guess I should rebuild it?
<sil2100> Let me think about it
<Trevinho> robru: hey, is there a way to use a custom debian/changelog but at the same time to make bileto to use the lp Commit Message for bzr committing?
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Dependency wait (vivid/unity8, xenial/unity8). Needs rebuild due to new commits (zesty/ubuntu-settings-components, zesty/unity8). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, xenial/qmenumodel, xenial/ubuntu-settings-components, zesty/qmenumodel)
<sil2100> mardy: let's re-add this missing MP to the MP list, publish this and instantly follow up with a silo that reverts this change
<sil2100> Without any rebuilding
<mardy> sil2100: oh, good idea
<sil2100> mardy: I'll do that now
<mardy> sil2100: ok! it's this one: https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/tests-arm64/+merge/307801
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Preparing packages
<boiko> sil2100: so, can you remove the existing telephony-service, dialer-app and messaging-app packages from silo 1319? I will have to rebuild them anyway
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Pending binary packages (vivid/unity8, xenial/unity8, zesty/unity8). Successfully built (vivid/qmenumodel, xenial/qmenumodel, zesty/qmenumodel)
<sil2100> boiko: ok, on it
<sil2100> boiko: that's for zesty, right?
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Preparing packages
<sil2100> boiko: hm, why do you need those removed btw? I guess the only problem should be rebuilds of dialer and messaging for the new commits
<sil2100> But everything else looks ok
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 zesty/unity8: Failed to merge https://code.launchpad.net/~3v1n0/unity8/radio-button-menus
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/1971 Release pocket (vivid/online-accounts-api, vivid/signon-apparmor-extension, vivid/ubuntu-system-settings-online-accounts, xenial/online-accounts-api, xenial/signon-apparmor-extension, xenial/ubuntu-system-settings-online-accounts). Successfully built (yakkety/online-accounts-api, yakkety/signon-apparmor-extension, yakkety/ubuntu-system-settings-online-accounts)
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2094 QA Signoff: Required
-queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2094 Destination version missing from changelog (zesty/ubuntu-system-settings-online-accounts). Successfully built (vivid/ubuntu-system-settings-online-accounts, xenial/ubuntu-system-settings-online-accounts)
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2033 Preparing packages
<dobey> trainguards: can someone please delete go-unityscopes from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2100/+packages ? it's already landed in another silo
<sil2100> dobey: ok, on it
<sil2100> dobey: done
<dobey> sil2100: thanks
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2100 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Preparing packages
<mardy> sil2100: is the "Destination version missing from changelog" an innocuous warning, or should I worry? :-)
<boiko> sil2100: so can I just ignore the s390x showing up on the ppa package details page?
<sil2100> boiko: I would say yes, it's a dep-wait on upstart already so looks good from the glimpse of it
<sil2100> mardy: in which silo?
<boiko> sil2100: great! so, sorry about the noise, all good then :)
<dobey> mardy: destination version missing means a version is in the destination archive, but not in trunk, in debian/changelog. it might just mean the previous silo hasn't fully landed yet (ie, is still in zesty-proposed)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2100 Successfully built
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Dependency wait (vivid/unity8, xenial/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- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Currently building (vivid/gmenuharness, xenial/gmenuharness). Failed to build (vivid/indicator-network, xenial/indicator-network, zesty/gmenuharness, zesty/indicator-network)
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2033 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Preparing packages
<mardy> sil2100: 16:15 -queuebot:#ubuntu-ci-eng- mardy, https://bileto.ubuntu.com/#/ticket/2094 Destination version missing from changelog
<mardy> sil2100: ah, silly me
<mardy> sil2100: I didn't even look at the silo number, it's another silo, so this is all expected -- sorry for the noise :-)
<sil2100> ;)
<sil2100> No worries, I'm tracking that silo to manually merge it once it's good
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Failed to build (vivid/indicator-network, xenial/indicator-network, zesty/gmenuharness, zesty/indicator-network). Successfully built (vivid/gmenuharness, xenial/gmenuharness)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Successfully built
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2089 Proposed pocket
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Preparing packages
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Pending binary packages (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components). Successfully built (vivid/qmenumodel, vivid/unity8, xenial/qmenumodel, xenial/unity8, zesty/qmenumodel, zesty/ubuntu-settings-components, zesty/unity8)
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Failed to build (vivid/indicator-network, xenial/indicator-network, zesty/gmenuharness, zesty/indicator-network). Successfully built (vivid/gmenuharness, xenial/gmenuharness)
<robru> Trevinho: nope, it's one or the other
<Trevinho> robru: what about adding a tag to ignore a debchange for committing?
<robru> Trevinho: why?
<Trevinho> So that you can use debian changelog lines without adding them to the bzr commit msg
<Trevinho> robru: for example, now I bumped some versions in the control, and I want the debian/changelog to show them. However I don't want that line to be used as the commit msg in bzr... for the whole branch
<Trevinho> robru: so, I'd like to be able to append bzr commit msg to that debian file, but not to use it as the bzr changelog (still preferring the Commit Message of the MP)
<robru> Trevinho: I'd really rather not complicate the changelog code any more than it already is, I don't see any reason you'd want things in your changelog and not in your commit message. just put everything you want in your changelog
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Pending binary packages (vivid/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, xenial/unity8, zesty/indicator-power, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api, zesty/unity8)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Successfully built
<robru> jibel: did you see my qakit merge? Can you update your silo card bot to use that latest code?
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Preparing packages
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 zesty/indicator-network: Failed to download DSC file https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2073/+files/indicator-network_0.8.0+17.04.20161026-0ubuntu1.dsc
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 vivid/telepathy-ofono: Failed to download DSC file https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/1319/+files/telepathy-ofono_0.2+15.04.20161027-0ubuntu1.dsc
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/1994 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Currently building (vivid/gmenuharness, xenial/gmenuharness, zesty/gmenuharness). Failed to build (vivid/indicator-network, xenial/indicator-network, zesty/indicator-network)
<oSoMoN> trainguards: can someone please do a source copy of https://launchpad.net/~osomon/+archive/ubuntu/oxide/+sourcepub/7064981/+listing-archive-extra to https://launchpad.net/~ci-train-ppa-service/+archive/2107/ ?
<robru> oSoMoN: on it
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Successfully built
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2107 Generating diffs
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Failed to build (vivid/indicator-network, xenial/indicator-network). Needs building (vivid/gmenuharness, xenial/gmenuharness, zesty/gmenuharness). Needs rebuild due to new commits (zesty/indicator-network)
<oSoMoN> robru, thanks!
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2107 xenial/oxide-qt: debdiff failed: see log for details
<oSoMoN> robru, can you confirm that 2107 is building against the stable phone overlay ppa ? Iâm not seeing that info anywhere on the PPA page
<robru> oSoMoN: yes: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2107/+edit-dependencies
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Currently building (xenial/history-service). Failed to build (vivid/telephony-service, xenial/telephony-service, zesty/history-service, zesty/telephony-service). Needs building (xenial/dialer-app, zesty/dialer-app). Pending binary packages (vivid/dialer-app, vivid/history-service, vivid/messaging-app, xenial/messaging-app, zesty/messaging-app). Successfully built (vivid/
<oSoMoN> robru, I canât view that page: "Not allowed here", but Iâll take your word for it, thanks :)
<oSoMoN> robru, https://bileto.ubuntu.com/log/2107/diff/1/ failed, apparently because curl failed to fetch oxide-qt 1.15.7.orig.tar.xz
<oSoMoN> not sure if that is a transient failure, or a real problem
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Currently building (vivid/gmenuharness). Failed to build (vivid/indicator-network, xenial/indicator-network). Needs rebuild due to new commits (zesty/indicator-network). Successfully built (xenial/gmenuharness, zesty/gmenuharness)
<robru> oSoMoN: hopefully transient
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2107 Generating diffs
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/1994 Publishing packages
<robru> oSoMoN: I made a change recently that had the unintended side effect of making the statuses not update unless there are diffs on the ticket, I'll probably revisit that soon but for today you won't get the notified about build failures unless you diff.
<oSoMoN> ack
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2066 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/telephony-service, xenial/telephony-service, zesty/history-service, zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, xenial/dialer-app, xenial/history-service, xenial/messaging-app, xenial/telepathy-ofono, zesty/dialer-app, zesty/messaging-app, zesty/telepathy-ofono)
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2108 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Failed to build (vivid/indicator-network, xenial/indicator-network). Needs rebuild due to new commits (zesty/indicator-network). Successfully built (vivid/gmenuharness, xenial/gmenuharness, zesty/gmenuharness)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/1994 Proposed pocket (zesty/content-hub). Release pocket (vivid/content-hub, xenial/content-hub)
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2076 Proposed pocket
<ahayzen> jibel, o/ hey, my latest request (2108) seems to have created loads (5) cards on the QA trello board under needs qa sign off?
<davmor2> ahayzen: what did you do
<davmor2> ahayzen: and another
<jibel> ahayzen, I'll have a look
<jibel> ahayzen, it happens when the bot crashes
<robru> jibel: is the crash related to my recent changes? hope not!
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2008 This ticket must be migrated to zesty+xenial+vivid before it can be built
<robru> slangasek: sil2100: sigh, need to reboot, will be slightly late
<sil2100> k
<jibel> robru, without looking it's probably your fault indeed ;)
<jibel> I'll disable the bot for the moment
<jibel> robru, did you already switch from request_id to id?
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2008 Failed to build (vivid/address-book-app, xenial/address-book-app). Successfully built (yakkety/address-book-app)
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2008 Preparing packages
<robru> jibel: id field is present but there is still a request_id field provided for compatibility, so if you're running without my changes it should work
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/telephony-service, xenial/telephony-service, zesty/history-service, zesty/telephony-service). Needs rebuild due to new commits (zesty/messaging-app). Successfully built (vivid/dialer-app, vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, xenial/dialer-app, xenial/history-service, xenial/messaging-app, xenial/telepathy-ofono, zesty/
<robru> jibel: if there's a traceback please share it so I can fix it, I'd like to drop request_id today or tomorrow
<jibel> robru, http://paste.ubuntu.com/23389369/ looks like request_id is no more
<jibel> robru, anyway I'll update the bot tomorrow. I turned it off for the night
<robru> jibel: https://bileto.ubuntu.com/v1/ticket/2008 request_id is still there but there is a short (20minutes max but usually less) race condition during which a newly created ticket only has id and not request_id. is the bot making trello cards when tickets are created instead of when tickets are set to qa ready?
<robru> I was hoping to avoid service interruption but if the bot is offline anyway then I'll just drop the field now I guess...
<jibel> robru, indeed, lets move forward. I'll do the change tomorrow, request_id is used in too many places to do it safely now
<oSoMoN> davmor2, how do you make your frieza writable to install a silo? I used "phablet-config writable-image", and IÂ verified that /userdata/.writable_image exists on the device, but the filesystem is still read-only
<davmor2> oSoMoN: use bileto to install the silo, failing that adb shell sudo mount -o remount, rw /
<davmor2> oSoMoN: so sudo apt install phablet-tools-bileto then bileto device-upgrade <silo-number> <device-pin>
<robru> oSoMoN: davmor2: make sure you have ppa:phablet-team/tools enabled for the latest version
<davmor2> meh robru beat me to it ;)
<davmor2> oSoMoN: does that help :)
<oSoMoN> davmor2, yes, thanks!
<oSoMoN> I wonder why the writable-image trick doesnât work though
<davmor2> oSoMoN: because it hates you? Hate it back it works for me ;)
<oSoMoN> so many things to hate out there, I only have a limited amount of hatred :)
<davmor2> oSoMoN: hahaha
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2008 Successfully built
-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-app, zesty/messaging-app). Failed to build (vivid/messaging-app, vivid/telephony-service, xenial/telephony-service, zesty/history-service, zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/history-service, vivid/telepathy-ofono, xenial/dialer-app, xenial/history-service, xenial/telepathy-ofono, zesty/dialer-app, ze
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2008 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-app, vivid/telephony-service, xenial/telephony-service, zesty/history-service, zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/history-service, vivid/telepathy-ofono, xenial/dialer-app, xenial/history-service, xenial/messaging-app, xenial/telepathy-ofono, zesty/dialer-app, zesty/messaging-app, zesty/telepathy-ofono)
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2108 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Preparing packages
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Failed to build (vivid/indicator-network, xenial/indicator-network, zesty/indicator-network). Successfully built (vivid/gmenuharness, xenial/gmenuharness, zesty/gmenuharness)
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2107 Ready to build (zesty/oxide-qt). Successfully built (xenial/oxide-qt)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Needs rebuild due to new commits (zesty/ubuntu-settings-components). Successfully built (vivid/qmenumodel, vivid/ubuntu-settings-components, vivid/unity8, xenial/qmenumodel, xenial/ubuntu-settings-components, xenial/unity8, zesty/qmenumodel, zesty/unity8)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 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/2106 Pending binary packages (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components). Successfully built (vivid/qmenumodel, vivid/unity8, xenial/qmenumodel, xenial/unity8, zesty/qmenumodel, zesty/ubuntu-settings-components, zesty/unity8)
#ubuntu-ci-eng 2016-10-28
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Successfully built
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2109 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2109 zesty/indicator-application: Failed to commit https://code.launchpad.net/~jbicha/indicator-application/dont-show-in-startup-applications. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2109 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2109 Pending binary packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2081 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2109 Successfully built
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2109 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2109 Publishing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2109 Publish failed: Bad merges
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2109 Successfully built
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2100
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/1679
-queuebot:#ubuntu-ci-eng- alex-abreu, https://bileto.ubuntu.com/#/ticket/1640
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080
<robru> Heh
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2100 Successfully built
-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- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-app, vivid/telephony-service, xenial/telephony-service, zesty/history-service, zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/history-service, vivid/telepathy-ofono, xenial/dialer-app, xenial/history-service, xenial/messaging-app, xenial/telepathy-ofono, zesty/dialer-app, zesty/messaging-app, zesty/telepathy-ofono)
-queuebot:#ubuntu-ci-eng- alex-abreu, https://bileto.ubuntu.com/#/ticket/1640 Cancelled build (xenial/content-hub, yakkety/content-hub). Successfully built (vivid/content-hub)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2080 Successfully built
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 zesty/unity-scopes-shell: Failed to branch https://code.launchpad.net/~mterry/unity-scopes-shell/snap-root
<marcustomlinson> trainguards: help ^ "zesty/unity-scopes-shell: Failed to branch https://code.launchpad.net/~mterry/unity-scopes-shell/snap-root"
<robru> marcustomlinson: did you read the log?
<marcustomlinson> robru: yeah, reading it again
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Ready to build
<robru> marcustomlinson: actually hmm. The log says it's not a branch, but it loads in the browser...
<marcustomlinson> robru: yeah
<robru> marcustomlinson: i dunno, try it again
<marcustomlinson> k :)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Preparing packages
<marcustomlinson> robru: ok seems to be working now
<robru> marcustomlinson: race condition maybe? Is the branch super new?
<marcustomlinson> robru: no
<robru> marcustomlinson: weird, i dunno. I guess transient lp issue
<marcustomlinson> robru: yeah np, thanks :)
<robru> marcustomlinson: you're welcome!
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Currently building (vivid/unity-scopes-api, vivid/unity-scopes-shell, xenial/unity-scopes-shell, zesty/unity-scopes-api, zesty/unity-scopes-shell). Failed to build (xenial/unity-scopes-api)
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Failed to build (xenial/unity-scopes-api, zesty/unity-scopes-api). Pending binary packages (vivid/unity-scopes-shell, xenial/unity-scopes-shell, zesty/unity-scopes-shell). Uploading build (vivid/unity-scopes-api)
<oSoMoN> sil2100, jibel, good morning! can the status of https://bileto.ubuntu.com/#/ticket/2107 be overridden so that it gets into QAâs queue? itâs fixing the landing of silo 1919 where the xenial+overlay packages were dropped
<sil2100> oSoMoN: switched the silo to xenial-only
<sil2100> Since zesty is not needed there
<sil2100> oSoMoN: I guess we can just publish this
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2107 QA Signoff: Required
<oSoMoN> sil2100, wouldnât that make it a candidate for SRU, instead of targetting the stable overlay PPA?
<sil2100> No, you can then switch the target to the overlay
<sil2100> Single landings have a target field, you can decide whether to SRU or go to the overlay
<sil2100> I guess this was already tested for xenial when davmor2 was signing off the original silo
<sil2100> Publishing
<oSoMoN> sil2100, thanks
<oSoMoN> IÂ hadnât noticed the "Destination" field, itâs quite handy
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2107 Publishing packages
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Failed to build (xenial/unity-scopes-api, zesty/unity-scopes-api). Pending binary packages (vivid/unity-scopes-api, vivid/unity-scopes-shell, xenial/unity-scopes-shell, zesty/unity-scopes-shell)
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2107 Release pocket
-queuebot:#ubuntu-ci-eng- marcustomlinson, https://bileto.ubuntu.com/#/ticket/2110 Failed to build (xenial/unity-scopes-api, zesty/unity-scopes-api). Successfully built (vivid/unity-scopes-api, vivid/unity-scopes-shell, xenial/unity-scopes-shell, zesty/unity-scopes-shell)
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2111 Preparing packages
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2111 Pending binary packages
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2111 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2109 Publishing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2109 Publish failed: Bad merges
<jbicha> good morning, could I get a review of https://code.launchpad.net/~jbicha/indicator-application/dont-show-in-startup-applications/+merge/309526
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Successfully built
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2109 Successfully built
<davmor2> sil2100: have you not added zesty to the phablet-tools ppa yet?
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2066 Publishing packages
-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- jgdx, https://bileto.ubuntu.com/#/ticket/2066 Proposed pocket (zesty/ubuntu-system-settings). Release pocket (vivid/ubuntu-system-settings, xenial/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- kenvandine jgdx, https://bileto.ubuntu.com/#/ticket/2078 Destination version missing from changelog (zesty/ubuntu-system-settings). Successfully built (vivid/ubuntu-system-settings, xenial/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/1721 Destination version missing from changelog (zesty/ubuntu-system-settings). Failed to build (vivid/ubuntu-system-settings). Needs rebuild due to new commits (zesty/ubuntu-settings-components). Successfully built (vivid/ubuntu-settings-components, xenial/ubuntu-settings-components, xenial/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- kenvandine jgdx, https://bileto.ubuntu.com/#/ticket/2078 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/2106 Successfully built
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-app, vivid/telephony-service, xenial/telephony-service, zesty/history-service, zesty/telephony-service). Needs rebuild due to new commits (zesty/telepathy-ofono). Successfully built (vivid/dialer-app, vivid/history-service, vivid/telepathy-ofono, xenial/dialer-app, xenial/history-service, xenial/messaging-app, xenial/telepathy-ofono, zest
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2050 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine jgdx, https://bileto.ubuntu.com/#/ticket/2078 Destination version missing from changelog (zesty/ubuntu-system-settings). Successfully built (vivid/ubuntu-system-settings, xenial/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2103 Successfully built
<Elleo> trainguards: are there any known issues with autopkg tests on xenial? the url-dispatcher tests timed out on 3 architectures on xenial for this silo: https://bileto.ubuntu.com/#/ticket/2033
<sil2100> Elleo: I don't know anything about the machines having some issues per se, but britney is under heavy load since yesterday basically as far as the number of running tests is concernet
<sil2100> *concerned
<sil2100> But not sure if that could cause such timeout issues
-queuebot:#ubuntu-ci-eng- andreas-pokorny, https://bileto.ubuntu.com/#/ticket/2084 Publishing packages
<Elleo> sil2100: ah, I guess that might be it; nothing in the branch being tested should have an effect on the url dispatcher tests, and they pass on other architectures/distributions
<Elleo> sil2100: plus they took a really long time to finish, they started running last night :/
<Elleo> sil2100: is it worth kicking those tests off again now?
<sil2100> I can retry them, but not sure when they get to be finished actually
<sil2100> I pushed a new package to -proposed yesterday and still didn't get all tests run
<Elleo> perhaps we need some sort of queue system for autopkg tests, so the system load remains reasonable when there's a lot of tests ready to run, instead of running them all concurrently
-queuebot:#ubuntu-ci-eng- andreas-pokorny, https://bileto.ubuntu.com/#/ticket/2084 Release pocket
<dobey> Elleo: there is a queue
<Elleo> oh, maybe it needs tweaking then if its getting into a situation with such heavy load?
<dobey> i don't know what the host hardware is like, but afaik the tests are run in virtualization. i guess on some archs that can end up with resource conflicts, but unless the host is getting destroyed, things should be fine
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
<dobey> but yes, the infrastructure has always had issues meeting demand
<dobey> you'd need to talk to pitti i guess
<kenvandine> rvr, silo 2066 which was published a little bit ago has been switched back to ready for QA in bileto
<kenvandine> rvr, i suspect maybe because of britney?
<rvr> kenvandine: Let me check
<dobey> i guess if url-dispatcher tests are timing out there are some serious issues, possibly in the tests themselves though
<kenvandine> rvr, it must have been qa approved and still had tests running
<rvr> Yeah, it was approved 2016-10-26 17:43:40 +0100 (davmor2) qa_signoff: Approved
<rvr> davmor2: Can you set https://bileto.ubuntu.com/#/ticket/2066 again as approved?
-queuebot:#ubuntu-ci-eng- pitti Trevinho, https://bileto.ubuntu.com/#/ticket/2101 Release pocket
<davmor2> done
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2066 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2106 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/1951 Needs rebuild due to new commits
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-app, vivid/telephony-service, xenial/telepathy-ofono, xenial/telephony-service, zesty/history-service, zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/history-service, vivid/telepathy-ofono, xenial/dialer-app, xenial/history-service, xenial/messaging-app, zesty/dialer-app, zesty/messaging-app, zesty/telepathy-ofono)
-queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/2112 Dependency wait (vivid/unity8, xenial/unity8, zesty/unity8). Successfully built (vivid/unity-api, xenial/unity-api, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2069 QA Signoff: Approved
<AlbertA_> cjwatson: I'm getting this failure trying to build a snap: https://launchpadlibrarian.net/291187751/buildlog_snap_ubuntu_yakkety_arm64_mir-kiosk_BUILDING.txt.gz
-queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/2112 Successfully built
<AlbertA_> sil2100: Would you know who can fix such issues like above ^
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2113 Successfully built
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Preparing packages
-queuebot:#ubuntu-ci-eng- alan-griffiths, https://bileto.ubuntu.com/#/ticket/2114 Preparing packages
-queuebot:#ubuntu-ci-eng- alan-griffiths, https://bileto.ubuntu.com/#/ticket/2114 zesty/miral: Failed to commit https://code.launchpad.net/~alan-griffiths/miral/0.3. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- alan-griffiths, https://bileto.ubuntu.com/#/ticket/2114 Preparing packages
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Failed to build (xenial/indicator-network, zesty/indicator-network). Pending binary packages (vivid/indicator-network). Successfully built (vivid/gmenuharness, xenial/gmenuharness, zesty/gmenuharness)
-queuebot:#ubuntu-ci-eng- alan-griffiths, https://bileto.ubuntu.com/#/ticket/2114 Failed to build
-queuebot:#ubuntu-ci-eng- alan-griffiths, https://bileto.ubuntu.com/#/ticket/2114 Preparing packages
-queuebot:#ubuntu-ci-eng- alan-griffiths, https://bileto.ubuntu.com/#/ticket/2115 Preparing packages
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Failed to build (xenial/indicator-network, zesty/indicator-network). Successfully built (vivid/gmenuharness, vivid/indicator-network, xenial/gmenuharness, zesty/gmenuharness)
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2115 Pending binary packages
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Preparing packages
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 xenial/gmenuharness: debdiff failed: see log for details
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Failed to build (xenial/indicator-network, zesty/indicator-network). Pending binary packages (vivid/gmenuharness, zesty/gmenuharness). Successfully built (vivid/indicator-network). Uploading build (xenial/gmenuharness)
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2115 Successfully built
<jbicha> trainguards: could I get a review of https://code.launchpad.net/~jbicha/indicator-application/dont-show-in-startup-applications/+merge/309526
<robru> jbicha: Hmmmmmmm? I don't know anything about indicators. Surely you want an indicator developer?
<jbicha> robru: who do you recommend I ping then?
<dobey> hmm i don't know if we land that via ci train anyway
<jbicha> also, I'd like to get this fix into yakkety and xenial for regular Desktop users; what's the procedure for that?
<dobey> tedg: ^^ how do indicator-application things get merged?
<robru> jbicha: https://launchpad.net/~indicator-applet-developers/+members#active I'd look for one of the admins, indeed tedg should be around
<jbicha> ok, he was pinged twice so I'll wait :)
<robru> jbicha: if you want a yakkety and xenial sru you need a separate ticket for each, the current machinery for targeting multiple series hard-codes the overlay ppa
<dobey> he might be gone already. he said he had to leave early today, so i think he's taking a half day
<jbicha> robru: ok I see now, thanks
<dobey> jbicha, robru: well, that's not entirely true
<jbicha> except I'm confused about how xenial works
<robru> dobey: jbicha: indicator-application was released with bileto just once before https://code.launchpad.net/~ted/indicator-application/systemd-unit/+merge/300336
<dobey> a couple times, yeah
<dobey> yakkety is the odd man out now, since we don't have any way to do z+y+x in ci train in a single ticket
<robru> jbicha: as far as bileto is concerned all you need is to have a different target "trunk" for each series. Your MPs can't all target same series because the generated changelogs will conflict
<robru> dobey: ci train? What's that? :-P
<dobey> robru: it's missing a car
<jbicha> hmm, I think we'd need someone on the indicator team to create those branches then
<robru> I could add z+y+x if you felt it would be useful but it would be hardcoded as zesty with yakkety overlay and xenial overlay, it wouldn't do srus
<dobey> robru: well, the binaries can be copied from overlays to y-proposed and x-proposed for the updates
<jbicha> I'm concerned about version numbering, it wouldn't be right for yakkety to have a later/higher version number than zestyâ¦
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Failed to build (xenial/indicator-network, zesty/indicator-network). Pending binary packages (vivid/gmenuharness, xenial/gmenuharness, zesty/gmenuharness). Successfully built (vivid/indicator-network)
<dobey> because even when not landing to ovleray the PPA still gets built against it anyway no?
<robru> dobey: no i fixed that with ephemerals, it only adds overlay when the target is overlay
<dobey> well, when /any/ target is overlay
<dobey> since that can't be speified per series
<robru> dobey: right but building with "zesty overlay"is harmless because there's nothing in there
<dobey> robru: right, but ideally the list of targets would be checkboxes, and i could specify overlay or not for each target
<dobey> but alas :)
<robru> dobey: but yeah you wouldn't want to build a xenial SRU with the overlay
<robru> dobey: yeah it's on my list to make that more flexible.
<dobey> and all the non-trunk branches for i-application are not up to date with reality in archive/overlay anyway, so this would be a fair bit more work than just making new MPs for the other branch targets
<robru> dobey: snap support is the latest craze though
<dobey> i really don't like how ted has been creating all these branches at the beginning of cycles for this stuff
<robru> dobey: well it's trivial to copy the main trunk to a new name, just a question of who has permission to create those branches
<dobey> especially when they never get cleaned up
<dobey> it's a difficult mess
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Failed to build (xenial/indicator-network, zesty/indicator-network). Successfully built (vivid/gmenuharness, vivid/indicator-network, xenial/gmenuharness, zesty/gmenuharness)
<sil2100> bzoltan, zsombi: hey, why did you start skipping arm64 tests in the UITK?
<sil2100> bzoltan, zsombi: I see no mention of why in the changelog, no bug or anything
<bzoltan> sil2100:  It was a temporary thing because there were some tools crashing on arm64
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Preparing packages
<bzoltan> sil2100:  it could be turned on with the next releas
 * tedg was at lunch
<tedg> jbicha: Why do we need that? Why shouldn't one be able to see it in startup applications?
<jbicha> tedg: it's long-standing practice to hide "system" services from Startup Applications
<jbicha> because we don't want users to accidentally disable things they shouldn't
<tedg> jbicha: Eh, okay. Seems an odd practice.
<jbicha> it looks like we started it for precise
<jbicha> the Startup Applications app is from gnome-session and GNOME dropped it there but we patch it back in
<jbicha> https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-startup-applications
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Failed to build (zesty/indicator-network). Pending binary packages (vivid/indicator-network, xenial/indicator-network). Successfully built (vivid/gmenuharness, xenial/gmenuharness, zesty/gmenuharness)
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-app, vivid/telephony-service, xenial/telepathy-ofono, xenial/telephony-service, zesty/history-service, zesty/telephony-service). Needs rebuild due to new commits (zesty/messaging-app). Successfully built (vivid/dialer-app, vivid/history-service, vivid/telepathy-ofono, xenial/dialer-app, xenial/history-service, xenial/messaging-app, zesty/
<dobey> tedg: does it really matter since it's started by systemd anyway?
<dobey> the .desktop file in xdg autostart seems a bit superfluous no?
<tedg> dobey: Yes, but legacy reasons... we have an xdg autostart, with an overide in the Upstart directory. Which has an override. Which has a systemd service.
<tedg> dobey: We support ALL the init systems.
<dobey> that is awful
<tedg> I think once we get to systemd everywhere we can just start cleaving the other solutions.
<dobey> so now :)
<tedg> Not yet, U8 still isn't there.
<dobey> eh, indicator-application doesn't work under u8 anyway does it?
<tedg> Eh, no, but I'd be for dropping them all at once.
<tedg> (all the indicators)
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2073 Failed to build (zesty/indicator-network). Successfully built (vivid/gmenuharness, vivid/indicator-network, xenial/gmenuharness, xenial/indicator-network, zesty/gmenuharness)
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-app, vivid/telephony-service, xenial/telepathy-ofono, xenial/telephony-service, zesty/telephony-service). Needs rebuild due to new commits (zesty/history-service, zesty/messaging-app). Successfully built (vivid/dialer-app, vivid/history-service, vivid/telepathy-ofono, xenial/dialer-app, xenial/history-service, xenial/messaging-app, zesty/
<dobey> robru: btw, should bileto do a rebase and squash commits to use the commit message from the MP when merging git requests?
<robru> dobey: Hmmmmmmm, why do you think that? Isn't it better to preserve the input commits?
<dobey> robru: because git doesn't merge them as sub-commits like bzr does
<dobey> so the commits get a bit messy if the branch in the MP wasn't already squashed :-/
<robru> dobey: technically both git and bzr treat them exactly the same, it's just that bzr hides them by default and git shows them by default. If you just don't want to see them, do "git log --first-parent" or something like that
<robru> dobey: file a bug
<dobey> robru: that doesn't fix the display in launchpad. and no they aren't exactly the same. in bzr when you merge another branch in, you then have to commit it, which creates a new parent commit. in git the commits are just copied in on merge
<dobey> as i understand it anyway
<robru> dobey: in bileto git we explicitly skip the auto merge then make a manual merge with the custom commit message, so treating it a lot like bzr.
<dobey> huh
<dobey> weird
<dobey> oh but you're not squashing the commits. so they show up when looking on code browser
<robru> dobey: https://git.launchpad.net/bileto/tree/scripts/vcs.sh#n441 right
<dobey> and it's using whomever proposed the MP as the author for that commit?
<dobey> or i guess git doesn't like passing multiple authors to commit?
<robru> dobey: no, it inspects the committers of the unmerged commits to use as the author of the merge commit
<robru> dobey: yeah git seems to only let you specity --author once so I just shoehorn them all into one
<dobey> even then it seems it might only use the first one
<dobey> https://git.launchpad.net/unity-scope-snappy/commit/?id=5c48965f4132a5340e38ab886097e979f971ed67
<dobey> at least that's how this commit appears
<robru> dobey: not clear to me if the git web ui is just truncating the display or if the real commit only takes the first one. you can see right there in the code that it lists all committers, comma separates them, and then shoves the whole value into --author="$authors"
<dobey> yeah i see the script does that
<dobey> git log only shows the one
<dobey> so i guess it truncated on the commit
<robru> damn
<robru> dobey: anyway I already raised your concern with steve when I was writing the code and he requested it behave this way for feature parity with bzr. if enough people vote for squashing behavior I could change it but you'll have to appeal to steve. I know I personally prefer squashing in my projects ;-)
<dobey> steve as in slangasek ?
<dobey> robru: well, maybe launchpad just needs to be fixed to show --first-parent or whatever instead of everything, like it does for bzr
<dobey> (or really, git needs to be changed to do that by default, but *sigh*)
<robru> dobey: I suppose that's also possible, file a bug against launchpad ;-)
<dobey> not sure what to do about the author thing
<robru> dobey: well instead of using a comma I could make it say "Name and Name and Name and Name" and then git couldn't possibly truncate it ;-)
<dobey> that would be incredibly awful
<robru> Â¯\_(ã)_/Â¯
<dobey> some weird thing inside the long commit would be better. but meh. it's at least a little less annoying than the history thing
<robru> hmm
<dobey> hmm, now i need to figure out how best to get snapd-glib in xenial overlay
<robru> dobey: what's the issue? trying to decide between dual landing or having separate branches per series?
<dobey> no, it's not my project, and it's not landed via ci train
<dobey> the issue is it's not in xenial and i need to use it to do my work :)
<dobey> and rober ancell is not back until monday i guess
<dobey> well, saturday for him now anyway, but still
<dobey> i guess i could copy the yakkety version and append ~16.04.1 onto it or something, and shove that in a silo
<dobey> robru: can you copy snapd-glib source from https://launchpad.net/~unity-api-team/+archive/ubuntu/dev-build-4/+packages into silo 2116 please?
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2116 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
<robru> dobey: sure
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2116 Preparing packages
<dobey> i guess nobody is around to publish though
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2116 Successfully built
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2116 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2117 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2118 Successfully built
#ubuntu-ci-eng 2016-10-29
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2117 Publishing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2118 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2117 Publish failed: Bad merges
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2118 Publishing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2118 Publish failed: Bad merges
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2117 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2118 Successfully built
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-app, vivid/telephony-service, xenial/telepathy-ofono, xenial/telephony-service). Needs rebuild due to new commits (zesty/history-service, zesty/messaging-app, zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/history-service, vivid/telepathy-ofono, xenial/dialer-app, xenial/history-service, xenial/messaging-app, zesty/
-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 (vivid/history-service, vivid/telepathy-ofono, xenial/dialer-app, xenial/telepathy-ofono, xenial/telephony-service, zesty/telepathy-ofono). Failed to build (vivid/messaging-app, xenial/history-service, zesty/history-service, zesty/telephony-service). Pending binary packages (vivid/dialer-app, vivid/telephony-service, xenial/messaging-app, zesty/messagi
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (vivid/messaging-app, xenial/history-service, zesty/history-service, 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/telephony-service, zesty/dialer-app, zesty/messaging-app, zesty/telepathy-ofono)
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2109 Publishing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2109 Proposed pocket (zesty/indicator-application). Release pocket (vivid/indicator-application, xenial/indicator-application)
#ubuntu-ci-eng 2016-10-30
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2109 Release pocket
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Preparing packages
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 zesty/indicator-network: Failed to commit https://code.launchpad.net/~unity-api-team/indicator-network/data_usage_indication. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Preparing packages
-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
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2120 vivid/indicator-network: Failed to add changelog message
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2120 Preparing packages
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2120 Failed to build (xenial/indicator-network). Successfully built (vivid/indicator-network, zesty/indicator-network)
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Needs rebuild due to new commits (zesty/indicator-network). Successfully built (xenial/indicator-network)
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2120 Failed to build (xenial/indicator-network). Needs rebuild due to new commits (zesty/indicator-network). Successfully built (vivid/indicator-network)
-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- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Failed to build
-queuebot:#ubuntu-ci-eng- Wellark, https://bileto.ubuntu.com/#/ticket/2119 Preparing packages
#ubuntu-ci-eng 2017-10-23
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3001 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3003 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/3003 Diff missing (xenial/dnsmasq, zesty/dnsmasq). Ready to build (yakkety/dnsmasq)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3002 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3004 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/3002 Pending binary packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3002 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3004 Diff missing
#ubuntu-ci-eng 2017-10-24
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3005 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3005 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/3005 Currently building (xenial/percona-xtradb-cluster-5.6). Failed to build (zesty/percona-xtradb-cluster-5.6). Ready to build (yakkety/percona-xtradb-cluster-5.6)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3005 Currently building (xenial/percona-xtradb-cluster-5.6). Failed to build (zesty/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)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3005 Failed to build (zesty/percona-xtradb-cluster-5.6). Pending binary packages (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)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3005 Diff missing (xenial/percona-xtradb-cluster-5.6). Failed to build (zesty/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)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3006 Ready to build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3007 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3007 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/3007 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3007 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3008 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3007 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3008 Pending binary packages
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3006 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3008 Diff missing
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3006 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3008 Needs rebuild due to higher version at destination
#ubuntu-ci-eng 2017-10-25
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3010 Diff missing (xenial/pacemaker). Ready to build (zesty/pacemaker)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3010 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3011 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/3011 Diff missing
#ubuntu-ci-eng 2017-10-26
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3012 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/3012 Ready to build
-queuebot:#ubuntu-ci-eng- Saviq, https://bileto.ubuntu.com/#/ticket/2986 Abandoning ticket
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2983 Abandoning ticket
-queuebot:#ubuntu-ci-eng- Saviq, https://bileto.ubuntu.com/#/ticket/2986 Pending binary packages
-queuebot:#ubuntu-ci-eng- Saviq, https://bileto.ubuntu.com/#/ticket/2986 Successfully built
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3000 Diff missing (artful/ocaml). Ready to build (artful/boost1.65.1)
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3000 Diff missing (artful/ocaml). Ready to build (artful/boost-defaults, artful/boost1.65.1)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3005 Diff missing (xenial/percona-xtradb-cluster-5.6). Pending binary packages (zesty/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)
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/3013 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3005 Diff missing (xenial/percona-xtradb-cluster-5.6, zesty/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)
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/3013 Failed to build
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3014 Preparing packages
-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 Failed to build
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/2970 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2992 Ready to build (xenial/qemu). Updates pocket (zesty/qemu)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2858 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2999 Diff missing (artful/strongswan). Failed to build (artful/memcached). Needs rebuild due to higher version at destination (artful/libmemcached, artful/tgt)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2995 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2992 Needs rebuild due to higher version at destination (zesty/qemu). Ready to build (xenial/qemu)
#ubuntu-ci-eng 2017-10-27
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3005 Diff missing (zesty/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). UNAPPROVED queue (xenial/percona-xtradb-cluster-5.6)
-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 Failed to build
-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
-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
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2680 Needs rebuild due to higher version at destination (xenial/indicator-session, xenial/unity8). Needs rebuild due to new commits (zesty/indicator-bluetooth, zesty/indicator-datetime, zesty/indicator-power, zesty/unity8-desktop-session). Successfully built (xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-power, xenial/indicator-sound, xenial/libindicator, xenial/policykit-uni
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2680 Needs rebuild due to higher version at destination (xenial/indicator-session, xenial/unity8). Needs rebuild due to new commits (zesty/indicator-bluetooth, zesty/indicator-datetime, zesty/indicator-power, zesty/indicator-session, zesty/indicator-sound, zesty/unity8, zesty/unity8-desktop-session). Successfully built (xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-power, xen
#ubuntu-ci-eng 2017-10-28
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/3016 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/3016 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/3016 Pending binary packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/3016 Diff missing
#ubuntu-ci-eng 2017-10-29
<uofm49426> can someone mannually type the chatroom for #xubuntu having problems with 17.10 and nm-applet
<uofm49426> using pidgin and dont know how to get to there
