#ubuntu-ci-eng 2014-03-24
<imgbot> === trainguard: IMAGE 256 building (started: 20140324-03:05) ===
<imgbot> === trainguard: IMAGE 256 DONE (finished: 20140324-04:10) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/256.changes ===
<Mirv> SDK folks are reporting phablet-flash doesn't work for them
<Mirv> I upgrade just by system-settings
<bzoltan> Mirv: I have booted to the bootloader and flashed with ubuntu-device-flash --channel=devel --bootstrap successfully
<Mirv> bzoltan: phew
<bzoltan> Mirv: yes... relieved. But not a pleasant experience :)
<Mirv> bzoltan: landing-009 for QtC plugins, click build when ready
<bzoltan> Mirv:  thanks .. building right now
<didrocks> cjwatson: hey! I think you read the phone ML and some people complaining of not being able to start some apps anymore. I'm not entirely familiar with the click layout, but it seems to me from latest email of Sam's bull that the installed version is latest one for music app (1.1.359) where his local desktop file is matching 1.3.389 which isâ¦ higher? (also look at the click list crash)
<didrocks> Mirv: hi! mind doing psivaa_'s backup on the image status as he's not around this week? :)
<sil2100> ah, right, he's not around this week
<sil2100> didrocks: vila mentioned something he can fill up for psivaa_ if anything, not sure if that changed
<didrocks> sil2100: excellent! he's going to do the image status then?
<didrocks> maybe better to have 2 pairs of eyes, just in case :)
<sil2100> didrocks: that's what I remember from Friday's morning meeting, but I guess that better being safe than sorry ;)
<didrocks> heh
<Mirv> didrocks: sil2100: sure, I can keep an eye on them too in addition to vila.. of course, if we'd have image testing working in the first place
<thostr_> sil2100: could you check line 9 in ci sheet? apparently ted used the wrong ffe bug to document the ffe
<didrocks> Mirv: yeah, I count on you guys to refresh me on the image testing story today :)
<Mirv> didrocks: latest update is from Paul on ubuntu-qa mailing list
<didrocks> Mirv: do you have a direct link? that would be easier (etoomanyemails)
<Mirv> so hosts seem down. popey emailed ev and francis on the weekend and now they've kicked it a bit but getting a lot of failing.
<didrocks> yeah 185â¦
<Mirv> didrocks: direct link seems a bit problematic, search for "Upgrade of ADB hosts within the CI Lab"
<Mirv> didrocks: sil2100: on the good news side, I've ran all AP tests this morning for 256 + updated UITK, and mostly everything passes 100%
<Mirv> I've 1 gallery-app test and 1 address-book-app test that seem flaky or broken
<didrocks> Mirv: did you try rerunning them then?
<didrocks> and they pass?
<sil2100> thostr_: checking...
<didrocks> thostr_: thanks for updating the bug btw :)
<thostr_> ffe bug?
<didrocks> jibel: I've got another bug where rosa maria assigned himself
<didrocks> thostr_: yep :)
<didrocks> (this ffe bug)
<Mirv> didrocks: address-book-app test passed individually at least, but gallery_app.tests.test_photo_viewer.TestPhotoViewer.test_photo_delete_works seems to fail consistently
<didrocks> kicked him out
<didrocks> Mirv: and with downgrading the sdk?
<Mirv> and I just tested that those are not related to the UITK but are on #256 in general
<didrocks> ok
<didrocks> please not that down
<Mirv> I mean, that, gallery-app
<didrocks> Mirv: any gallery-app update recentaly?
<Mirv> yes
<didrocks> recently*
<Mirv> how to check a 'changelog' for click package, ie upload log
<sil2100> thostr_: yeah, I remember the core-dev discussions around Friday
<sil2100> thostr_: let me see how we're standing with silos
<thostr_> sil2100: thanks
<didrocks> Mirv: I think start looking at the image content diff
<Mirv> calendar is at 0.4.214, I believe that was also on #250 and passed
<didrocks> generated in ogra's directory
<Mirv> ok, looked at wrong app, sorry :)
<Mirv> but, yes #256 had click:com.ubuntu.gallery from 2.9.1.927 to 2.9.1.931
<Mirv> so that could explain it
<Mirv> filing a bug, although it'd be nice if we would have also automated test results
<sil2100> So, to make sure, sergio is currently the only one who can do a click-app landing to the store, right?
<Mirv> bug #1296573
<ubot5> bug 1296573 in gallery-app "gallery-app AP regression on image #256" [Critical,New] https://launchpad.net/bugs/1296573
<sil2100> Saviq: hi! Did you get any further with the Qt bi-secting? :)
<Saviq> sil2100, not really, qt is a bitch
<Saviq> sil2100, have pulled tsdgeos is for help
<Saviq> *in
<popey> fyi xnox ran all the ap tests for gallery #931 before it hit the store.. Ran 34 tests in 623.078s
<sil2100> Saviq: good choice, thanks! Keep us updated if anything, and good luck
<Saviq> sil2100, there's also upstream folk online today, so we'll be hitting them soon
<Saviq> sil2100, will do
<sil2100> Saviq: if you need any additional help, just ping
<Mirv> popey: aha, aha, good to know
<Mirv> I wonder why I'm hitting that, or is there something else on #256 (or before) that causes it
<Mirv> ie what base image xnox was using
<didrocks> sil2100: as it seems there is no-one from CI around, do you mind retrying the whole set of job?
<didrocks> for the tests
<didrocks> to see if that's going to fix it
<didrocks> (the master job I pointed to all of you last week)
<sil2100> didrocks: which set of jobs?
<didrocks> sil2100: ah, you didn't write it down?
<didrocks> let me refind it
<sil2100> I don't seem to have it anywhere, hmm
<didrocks> sil2100: http://q-jenkins.ubuntu-ci:8080/job/trusty-touch-mako-smoke-master/
<didrocks> Mirv: please note it down too ^
<didrocks> this is the master job to relaunch iso testing
<Mirv> nice to know, thanks, bookmarking
<sil2100> It seems it's waiting for the next available executor to start
<didrocks> hum
<didrocks> asac: so, we're stuck, no device available ^
<sil2100> It seems the only one available is running touch_custom right now?
<didrocks> yep
<ogra_> apparmor.click.AppArmorException: "Could not find '/usr/share/autopilot-touch/apparmor/click.rules'"
<ogra_> hmpf
<vila> sil2100, didrocks, Mirv : Yes, only one mako available right now. Thanks to plars and fginther` efforts during the week-end 1 > 0
<didrocks> vila: it's the same device than touch_custom and so we are blocked on those tests to finish?
<didrocks> (for the rerun)
<didrocks> vila: seems like we don't have the AP tests installed on the device on previous 256 run though, and I can't figure why we don't bzr branch the tests
<didrocks> asac: FYI ^
<asac> didrocks: probably sergio topic
<didrocks> asac: or infra?
<asac> didrocks: we could compare logs
<davmor2> ogra_: what you broken now
<didrocks> but yeah, basically all click apps didn't run tests
<vila> didrocks: yeah leave it run I'd say
<asac> ogra breaks everything
<didrocks> ok
<asac> single source of obstructions :)
<ogra_> davmor2, nothing, thats the crash we have on all failing tests
<didrocks> vila: well, I think we'll have the same issue on the rerun, don't you?
<vila> didrocks: yeah, there seems to be a single common failure related to click apps not launching
<asac> autopilot-touch from 1.4+14.04.20140319.1-0ubuntu1 to 1.4+14.04.20140319.1-0ubuntu2
<ogra_> apparmor denies execution
<asac> http://people.canonical.com/~ogra/touch-image-stats/20140323.changes
<vila> didrocks: sounds likely but it's a wild guess, it's either a click/apparmor issue or some unforeseen fallout from re-provisioning the device
<ogra_> .oO( we really need servers without BIOS in the lab )
<ogra_> my DSL reconnect seems to have moved to 10:30 ... i might be a few mins late to the meeting btw
<vila> ogra_: IIUC said server has a memory issue and the debug they attempted *locally* (i.e. physical access with a physical keyboard) didn't help
<ogra_> vila, yep, i saw the mail
<vila> ok, great
<popey> bah, google talk crash
 * popey restarts browser
<popey> \o/ freed up 10GB RAM
<ogra_> deleted your mail ?
<popey> closed chromium
<ogra_> hah
<ogra_> apparmor.click.AppArmorException: "Could not find '/usr/share/autopilot-touch/apparmor/click.rules'"
<didrocks> popey: once shutting down all those html5 gamesâ¦ :p
<popey> didrocks: I still don't have the high score in Google Docs!
<ogra_> |HELP
<ogra_> |HELP
<imgbot> I am the firendly image watchbot
<ogra_> k
<popey> !bots
<ubot5> Hi! I'm #ubuntu-ci-eng's favorite infobot, you can search my brain yourself at http://ubottu.com/factoids.cgi | Usage info: http://ubottu.com/devel/wiki/Plugins | Bot channels and general info: https://wiki.ubuntu.com/IRC/Bots
<popey> ogra_: should probably add your bot to that page
<ogra_> :)
<popey> so people know about it
<vila> ogra_: fire ndly ? Put fire on all images ? :-p
<ogra_> popey, thanks
<ogra_> vila, it only kindles a little :P
<vila> ;)
<didrocks> popey: I can implement it in the CI train spreadsheet if you wantâ¦ :p
<popey> np
<ogra_> autopilot (1.4+14.04.20140319.1-0ubuntu2) trusty; urgency=medium
<ogra_>   * Add python-gi and python3-gi dependencies which provide gi.repository
<ogra_>     modules. (since gir1.2-upstart-app-launch is accessed via
<ogra_>     gi.repository)
<sil2100> WTF
<davmor2> sil2100: hahaha
<sil2100> Now google hangouts won't start!
<sil2100> didrocks: ok, it seems both my internet and google hate me today
<sil2100> "Please wait"
<sil2100> ...
<sil2100> didrocks: as for landings, there is one content-hub landing that is ready for landing, but I need sergio around to publish the new gallery-app along with it
<davmor2> sil2100: it's okay we pushed all the work over to you
<sil2100> didrocks: no other were marked as 'testing done', but I will consult the scopes one I guess
<ogra_> popey, did you mean the movies ?
<popey> I have 12 items showing in gallery
<popey> and 12 media items in the gallery database
<didrocks> sil2100: ok, and new scopes?
<ogra_> i think it is supposed to
<didrocks> maybe mhr3 would know? ^
<popey> http://paste.ubuntu.com/7145536/
<didrocks> sil2100: yeah :)
<didrocks> (sorry was bcklogging)
<popey> I'll file a bug
<sil2100> didrocks: yeah, will poke them about that :)
<seb128> mhr3, can you maybe land/clean l23 (code cleanup in the clip scope)? it has been built and holding a silo for at least half of a week
<didrocks> popey: ok, so I guess it's a bug for the apps team? (but if you can try the upgrade stuffâ¦)
 * sil2100 has lags so sorry if answering slow
<didrocks> popey: maybe one version picked the videos that you have at some point and didn't flush it?
<didrocks> sil2100: no worry
 * popey shrugs
<didrocks> popey: the videos name makes sense at least?
<didrocks> like it's videos you had at any point on your device?
<popey> they are on my device now
<popey> those are the videos I test with
<mhr3> seb128, it didn't pass testing last time
<popey> maybe gallery is hooked up to mediascanner now, dunno, bug will reveal all
 * popey files
<seb128> mhr3, if so can you drop it and give back the silo and ask for one again once it's ready? ;-)
<mhr3> seb128, fine, drop it
<seb128> sil2100, Mirv, didrocks: it would be nice to keep some "desktop silos" with beta freeze today, so we don't block desktop changes to land because there are not silo left
<seb128> mhr3, I don't have powers for that, just ^
<mhr3> seb128, eh, sorry, i thought i'm talking to sil2100 :P
<seb128> lol
<seb128> mhr3, you need more coffee!
<seb128> mhr3, btw there is a fix up for the manpages scope issue we discussed some days ago, if you want to review/approve that
<mhr3> seb128, waiting for david to confirm
<seb128> mhr3, you always have a good reason! ;-)
<seb128> mhr3, thanks
<Mirv> seb128: sil2100: I now went one below the set minimum of 3 free silos to have at least one for desktop, landing-018, and kicked a build
<seb128> Mirv, thanks
<didrocks> seb128: I agree with you and we can use silo-000 if you need anything
<didrocks> Mirv: FYI ^
<seb128> Mirv, don't worry about the desktop ones, I'm going to drive them through
<Mirv> didrocks: seb128: aha, ok.
<seb128> e.g they should be freed in a few hours every time, no days locking
<seb128> didrocks, thanks
<Mirv> seb128: maybe start from the second one and use 000 for that, while I check freeing up the 018 again
<seb128> Mirv, your call, I don't think it's an issue to be down to 2 for an hour
<popey> davmor2: didrocks bug 1296634
<ubot5> bug 1296634 in gallery-app (Ubuntu) "gallery shows blank dates and photos" [Undecided,New] https://launchpad.net/bugs/1296634
<davmor2> popey: confirmed
<Mirv> seb128: ok, you can have it, I just had a configuration messup but now it's building, for real this time.
<Mirv> tvoss: can you see about landing the dbus-cpp ppc64el fix that has built in landing-001?
<tvoss> Mirv, sure, flashing latest image right now
<seb128> Mirv, thanks
<didrocks> popey: thanks
<davmor2> popey, didrocks: Oho  some of the apps are installing on 237
<didrocks> davmor2: wdym?
<popey> if they have the 13.10 framework, they will
<popey> not every app bumped the framework in their latest updates
<davmor2> popey, didrocks: they did for the qt5.2 rebuild I thought
<popey> no. not all
<popey> some
<davmor2> popey: ah oky
<popey> apps can still install post-qt5.2 if they have the older framework
<davmor2> just leaving myself a list of app to try,  gallery, terminal, camera, music, notes all have command error,   calculator, calendar and sudoku all installed.
<cjwatson> didrocks: Yeah, I have a data dump from sergiusens that looks like the same kind of thing - was planning to sit down and stare at it today.  I don't think it's a particularly recent regression, if it's a regression at all - it's the sort of thing that can build up as people install apps, upgrade images, etc.
<didrocks> cjwatson: yeah, I was on same assumption, can be an upgrade before updating the image, or multiple upgrades + removalâ¦
<didrocks> Saviq: hum, just read kgunn's email? Was I implying it was Mir's fault? I was just explaining the bugâ¦
<cjwatson> didrocks: there's definitely something weird, can't tell you what yet
<Saviq> didrocks, it read a little bit like it, don't worry
<Saviq> didrocks, it might still be in the end ;)
<didrocks> Saviq: argh, ok, sorry for that, I'll talk to kgunn
<Saviq> not a bug per se, but an incompatibility between how Mir and Qt handle things
<didrocks> cjwatson: yeah, I think it's worth having on the radar and see if we can get a clear reproducer
<didrocks> but yeah, not anything that will block as probably not new but a followup of people upgrading manually some apps
<cjwatson> didrocks: let's not have anyone spend effort on it right now, as I say I have a data dump
<didrocks> Saviq: yeah, we do agree, I just tried to explain
<didrocks> cjwatson: good :)
<davmor2> didrocks: So I just flashed 237, updated all the apps that would, seen the command error issue on all the others.  I've then upgraded to 256 and everything works everything opens with no issues
<didrocks> davmor2: ok, I think just concentrate on normal dogfooding until we have image test results now :)
<didrocks> sil2100: progress on the gallery-app test failure?
<davmor2> didrocks: that's my plan now i'm a work ;)
<didrocks> thanks davmor2 :)
<davmor2> Morning all
<sil2100> didrocks: had to reflash with bootstrap, as it seems I had some deb version of gallery-app and the click one did not want to work
<sil2100> didrocks: so I'll be running the real test just now
<didrocks> sil2100: ok, let's see if the test failing is flaky or notâ¦
<didrocks> hey davmor2!
<ogra_> hmm, to bad psivaa isnt around ... having a test run with rolled back AP would really be interesting
<ogra_> grr
<didrocks> ogra_: yeah, let's see with Mirv's first test result run
<ogra_> webapps really misbehave on my phone
<didrocks> with a clean bootstrap image
<didrocks> ogra_: misbehaving like?
<ogra_> didrocks, well, i always have like 5 open constantly ... flicking through them one or two always die
<ogra_> randomly
<ogra_> not sure when that started
<ogra_> (i'm on 254 btw)
 * ogra_ upgrades to 256
<didrocks> ogra_: what webapps are you trying? so that I can try on latest
<ogra_> heise, golem n-tv.de are the ones i have always open
<ogra_> and G+
<ogra_> i'll see after upgrade if it happens right from the start or only after a while ... havent rebooted since the last upgrade
<ogra_> doesnt happen after upgrade/reboot yet ... i'll watch it over the day
<ogra_> aha, now it did
<ogra_> (and is fine again after the app restarted)
<ogra_> i'll leave the phone alone for a while and re-check again later
<didrocks> ogra_: yeah, I can't reproduce it until now here
<ogra_> session restore would really be an awesome feature :)
<ogra_> so you dont have to always re-open all your apps after upgrade
<didrocks> yeah
<ogra_> lol
<ogra_> http://www.ebay.com/bhp/nexus-4-broken
<ogra_> they even have a category for that
<didrocks> waow
<ogra_> we should buy all of these and put them in the lab :)
<ogra_> (i use my broken one here for doing bootcharts ... works excellent)
<davmor2> didrocks: one broken phone per test how quick would result be in then ;)
<didrocks> heh :)
<ogra_> davmor2, thats the idea
<ogra_> parallelize all tests
<davmor2> ogra_: No don't parallelize them, it's cruel to put tests in wheelchair
<ogra_> :P
<t1mp> is this the correct channel to request to trigger a CI run on this MR? https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-002/+merge/202171
<didrocks> t1mp: it is, please ask the citeam (if no vanguard, just use cihelp) ^
<t1mp> !cihelp
<t1mp> ?
<Mirv> t1mp: you just use it in hilight and they'll get it
<Mirv> for hilight
<Mirv> that magic string ci_help without underscore
<t1mp> Mirv: ahh :)
<josepht> t1mp: looking
<t1mp> josepht: thank you.
<Mirv> FWIW so far even after bootstrap I'm not getting test failures (in click packages)
<Mirv> didrocks: ^ on #256
<sil2100> Craaap
<didrocks> Mirv: ok, so seems to be infra-side onlyâ¦ :(
<didrocks> asac: FYI ^
<Mirv> so it seems
<seb128> sil2100, Mirv: I freed my 2 silos, if you want to give me 1 pack for some other desktop line ;-) (need to keep the ball rolling with beta freeze today)
<ogra_> Mirv, no aa-click crashes ?
<seb128> 1 back*
<asac> didrocks: cant be long until they come on
<sil2100> seb128: ;) Thanks!
<sil2100> seb128: doing!
<Mirv> ogra_: where they would be visible?
<seb128> sil2100, thanks
<ogra_> Mirv, in /var/crash
<Mirv> ogra_: nope. I do have one _usr_lib_arm-linux-gnueabihf_upstart-app-launch_desktop-hook.32011.crash
<Mirv> that seems to have happened during notes AP tests (which succeeded)
<sil2100> seb128: ok, assigned - line 55 will have to wait as u-c-c is already locked by silo 11
<sil2100> From bregma's landing
<seb128> oh
<seb128> sil2100, thanks for spotting that, and that's fine ;-)
<davmor2> popey, didrocks: I just noticed that my 256 image has no oddities in the gallery app. That is on the upgrade from 237 to 256 so I wonder if it is something on the platform from 255 to 256 rather than gallery itself?
<ogra_> Mirv, yeah, doesnt look like the one we get on the infra
* josepht changed the topic of #ubuntu-ci-eng to:  Ubuntu CI Engineering Team | Vanguard: josepht | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: ADB host ashes is down
<mhr3> sil2100, you didn't free 002?
<mhr3> sil2100, pinged you last week that i'm giving it up
<mhr3> sil2100, and now i want silo for 57
<asac> didrocks: ok thats semi-good news i think
<asac> Mirv: do you use the phablet-flash command?
<asac> or ubuntu-device-flash?
<didrocks> asac: which news?
<asac> didrocks: that its infra only
<sil2100> mhr3: I freed it, I guess someone else assigned it?
<didrocks> asac: yepâ¦
<asac> didrocks: on the bad side we are blind
<asac> but maybe we are still good :P
<didrocks> indeed
<didrocks> or we are regressing
<asac> as long as we produce enough images we are probably fine
<asac> and maybe have someone once a day crunch all APs manually :(
<ogra_> yeah, now having doanac's "run all AP tests like UTAH did" script would be nice to have
<sil2100> mhr3: let me free it again then
<didrocks> asac: that's what Mirv did for a sdk landing
<sil2100> didrocks: no failures on my device on latest image for gallery... ran the whole test suite 4 times already
<didrocks> sil2100: can you just upgrade from Mirv's silo and see if you get the gallery failure he has?
<sil2100> didrocks: hmm, seems to look ok as well, 2 test runs and no failures
<didrocks> not sure what Mirv is experiencing, maybe the phone doesn't like colder temperaturesâ¦
<didrocks> or cats
<didrocks> sil2100: thanks for looking at it!
 * didrocks classes that at NOISSUETHERE for now
<Mirv> cat is a possible explanation
<sil2100> Waiting just in case for the third test suite run
<Mirv> asac: too many highlights, so I used ubuntu-device-flash this time for the newest bootstrap, and I was using phablet-flash earlier
<ogra_> i can definitely run the aa-clickhook command from the .crash manually and it properly works and finds the file
 * ogra_ has no idea wh it wouldnt work during testing
<ogra_> *why
<Mirv> ok in my latest gallery-app rerun after bootstrap flash I got one fail, but it was different from before, so no I can't trustworthily reproduce the TestPhotoViewer.test_photo_delete_works ...
<davmor2> Mirv: that might be the bug that appears on an initial install IIRC it is something to do with the icon on notes
<davmor2> didrocks: 256 is looking similar to 250 for me
<didrocks> davmor2: apart from the blank dates and photos, right?
<davmor2> didrocks: see my message earlier I don't see that on the upgrade from 237 to 256
<didrocks> davmor2: your first trial was a direct flash?
<didrocks> and you did wipe when getting back to 237?
<davmor2> didrocks: no upgrade from 255 or 254 whatever was released early on Sunday
<didrocks> ok
<didrocks> and on 237, you did wipe, imported some photos and upgrade?
<davmor2> didrocks: I did a bootstrap to get 237 on
<didrocks> and imported some photos/videos?
<didrocks> or all blank and fresh?
<davmor2> didrocks: blank and fresh I can add some images if you want and try again
<didrocks> davmor2: yeah, let's see that
<didrocks> so get 237
<didrocks> import some photos and videos
<didrocks> run the gallery-app
<didrocks> and then update
<davmor2> didrocks: will do I'll give you a ping in a bit
 * sil2100 lunch
<didrocks> great!
<ogra_> not that this would help much with all tests failing :P
<cjwatson> Sorry for the -proposed logjam, folks, having some problems with the x264 transition causing proposed-migration to take eons
<ogra_> s/all tests/all click tests/
<cjwatson> I *think* this run might sort it out
<Mirv> balloons: with the new qtdeclarative 5.2.1-3ubuntu11 there's a fix for bug #1294181 from qtdeclarative side, ie the revert-212 could be reconsidered since it shouldn't be crashing anymore
<ubot5> bug 1294181 in qtdeclarative-opensource-src (Ubuntu) "Autopilot tests crashing in switch_to_tab helper" [Undecided,In progress] https://launchpad.net/bugs/1294181
<balloons> Mirv, yes, did kunal re-propose the merge?
<balloons> it should pass and yes, we should add it bacl
<Mirv> balloons: I don't see such a branch that would revert the revert, but anyhow such could be proposed now
<balloons> Mirv, would you mind doing it? I can help approve/review
<Mirv> balloons: tried, a few problems. bzr merge -r 213..212 has conflicts in WeekView.qml and calendar.qml
<Mirv> I might be able to cope with it even with my zero calendar knowledge
<Mirv> just a minute
<popey> Mirv: when you have 10 mins, we could do with a calendar release. lots of good UI stuff landed over the weekend.
<bfiller> sil2100, didrocks: can we get silo14 released? it needs gallery app click to be released at same time
<didrocks> bfiller: gallery-app is part of the silo 14 isn't it?
<didrocks> bfiller: and please, ping all EU people, so that Mirv can help you as well if around :)
<didrocks> (see /topic)
<cyphermox> howdy
<didrocks> bfiller: who is doing the gallery-app part from the click store, is that coordinated?
<didrocks> hey cyphermox
<bfiller> didrocks: I don't know, sergio usually does it but he's not here today
<cyphermox> yo yo yo, how's everyone and everything doing?
<popey> didrocks: sil2100 pinged me earlier, and I suggested xnox if he's about
 * ogra_ is banging his head against the aa-clickhook crashers and doesnt get anywhere 
<popey> otherwise balloons is around and can upload to store too
<bfiller> didrocks: yes gallery is part of silo 14 but needs a click release at the same time of deb release
<didrocks> bfiller: please get xnox or balloons in though, so what we don't release in a broken state
<didrocks> we don't have access to click store here
<balloons> ty Mirv
<bfiller> didrocks: this is going to be a common occurance in the next few weeks where we'll need coordination
<bfiller> balloons: can you help get gallery-app click ready for release (using branch in silo-14)?
<didrocks> bfiller: yeah, I expect the landers to coordinate on that. That's part of the issue of having your app in click
<bfiller> didrocks: great
<bfiller> didrocks: wishing we hadn't done that (:
<bfiller> we really need the train to release both click and deb
<didrocks> bfiller: I warned about it (not sure it was to you :))
<bfiller> didrocks: is there a roadmap for having CI Train support both click and deb?
<didrocks> bfiller: not with the current workload
<Mirv> popey: um, should I know about publishing click apps?
<didrocks> bfiller: the airline should have it, it's on the roadmap of it
<didrocks> bfiller: not sure about the train
<popey> Mirv: it wouldn't hurt if you did, xnox does. would be good to have more .eu people able to
<Mirv> popey: sure, I'd love a guide to it
<popey> (note: I don't have the power to publish clicks, and I don't want to, I am happy keeping the approval auth only)
<popey> Mirv: if xnox isn't around, balloons may be able to help here â»
<bfiller> xnox is off today afaik
<bfiller> so is sergio
<popey> balloons: ^^ quick! Someone wanting to offload work from you! Snap it up!
<bfiller> so balloons is the only click man
<balloons> lol
 * balloons is watching the dialog
<balloons> building clicks is generally very easy if the project is setup with cmake
<balloons> for things that get hard, francis has setup jenkins jobs, so in general it's fairly straightforward to do
<bfiller> Mirv: can you get silo14 released then? and balloons can you release gallery app click? I really need to get that silo freed as it's blocking address book silo
<Mirv> bfiller: yes, if balloons says yes in case it needs coordinated
<Mirv> like it sounded like in the backlog
<balloons> Mirv, bfiller yes I can help build the click
<balloons> and push it
<bfiller> balloons: great
<bfiller> Mirv: lets do it
<Mirv> ok
<mhr3> sil2100, 002 tested, rdy to publish
<balloons> bfiller, I assume we want a build of trunk?
<bfiller> balloons: trunk + https://code.launchpad.net/~ken-vandine/gallery-app/content_hub/+merge/211091
<bfiller> (that's what's in the silo that we need released)
<cjwatson> bfiller: fwiw there'll be perhaps an extra half-hour delay to proposed-migration over the usual, in case that matters to you
<cjwatson> still working through some issues from this morning
<bfiller> cjwatson: thanks for the heads up, shouldn't be a problem
<sil2100> mhr3: hoke! Sanks
<Mirv> bfiller: publishing done
<bfiller> Mirv: great, thank you
<Mirv> balloons: https://code.launchpad.net/~timo-jyrinki/ubuntu-calendar-app/revert_213_that_reverted_212/+merge/212422
 * didrocks is out for a run
<didrocks> balloons: bfiller: FYI, you have the branch somewhere with the merge since it was published
<sil2100> mhr3: hmm
<sil2100> mhr3: so, just want to make sure - was the add() method always internal?
<mhr3> sil2100, yes
<mhr3> sil2100, you are looking at the diff, aren't you? :)
<didrocks> bfiller: balloons: http://162.213.34.102/job/landing-014-2-publish/lastSuccessfulBuild/console says lp:~ps-jenkins/gallery-app/trusty-proposed for gallery-app
 * didrocks really out now
<balloons> I find it a bit odd you would release a random branch like that, and not something like lp:gallery-app/release
<sil2100> Mirv, bfiller: remember about publishing gallery-app to the store now
<mhr3> sil2100, now i'd like silo for 34 :)
<Mirv> sil2100: happening with balloons
<sil2100> ogra_: since didrocks is out, do you have a moment?
<bfiller> balloons: I guess it will be trunk now that Mirv has published
<sil2100> Mirv: balloons has the power to publish stuff to the store as well? :D
<Mirv> sil2100: yes, apparently, newly found powers
<sil2100> \o/
<Mirv> bfiller: not yet merge & clean ran
<sil2100> ogra_: I need a core dev for a packaging ACK ;)
<sil2100> ogra_: http://162.213.34.102/job/landing-002-2-publish/60/artifact/packaging_changes_unity-scopes-api_0.4.0+14.04.20140324-0ubuntu1.diff
<ogra_> sil2100, ack
<sil2100> ogra_: thanks! :)
 * Mirv published also UI Toolkit (thanks to my today's double testing I already did before they did their own testing) and Qt Creator plugins
<sil2100> mhr3: will assign 34 once we free up some of the now publishing silos :)
<plars> sil2100: I'm going to let the one you restarted run for a bit more, but if it still has problems, I want to kill it early and try a different device
<Mirv> bfiller: I guess you as the lander will run the merge & clean for the landing-014, and only after that the changes are pushed to trunks
<bfiller> Mirv: ack
<plars> sil2100: right now, it's running webbrowser tests, which passed fine before, but in a little while it should start getting to the ap tests that had failed
<sil2100> plars: ok, sure, thanks... let's just keep an eye on it if it starts having problems again
<thostr_> sil2100: could you reassign silo15 to line item 8 of the ci sheet?
 * Mirv needs to move to do some babysitting
<sil2100> thostr_: let me see
<sil2100> thostr_: so, you want to let go of silo 15 and assign line 8 instead, right?
<Mirv> bfiller: and it needs the IGNORE_PACKAGES_NOTINDEST since they are not yet in reelase pocket, co-operate with sil2100
<Mirv> sil2100: ^ possibly that flag to be used so that click can be built from the trunk?
<Mirv> especially with proposed migration being slow today
<thostr_> sil2100: yes. in the meantime ted can fix line 9 :)
<sil2100> Mirv: hmm, I don't think we need to use any flags here?
<plars> sil2100: I'm watching it right now
<Mirv> sil2100: well, yes if wanting to run m&c before migration to release pocket?
<sil2100> thostr_: ok ;) This will take some moments though
<sil2100> Mirv: I guess so - can't we wait? :)
<cjwatson> it shouldn't take *too* much longer now
<Mirv> sil2100: that's up to bfiller + balloons, I'm not exactly sure how critical the click package copublishing is
<cjwatson> 15mins more for this publisher run, then I'll be able to set p-m back to normal
<cjwatson> (rough guess)
<cjwatson> so there's probably no need to take special measures
<sil2100> Mirv: I think that as long as we don't build a new image in the meantime, we're safe
<sil2100> cjwatson: thanks!
<bfiller> sil2100: yup, as long as we don't build a new image until the gallery-app click is released we should be fine
<Mirv> sil2100: ok, then it's less critical time wise
<Mirv> as long as balloons doesn't disappear or something
<sil2100> Let's just keep this in mind though and not forget m&c'ing
<Mirv> as we don't have sergio, x_nox etc
 * Mirv runs
<bfiller> Mirv sil2100 : I got this error doing merge and clean: http://162.213.34.102/job/landing-014-3-merge-clean/15/console
<bfiller> is that related to issue cjwatson is describing?
<sil2100> bfiller: this just means that we need to wait still for the packages to migrate from proposed to the archive
<sil2100> bfiller: I guess we need to wait up to an hour still
<bfiller> sil2100: ok thanks
<cjwatson> bfiller: yes it is
<cjwatson> Hm, maybe I underestimated the publisher runtime :-/  The domination phase is up to eight minutes now even just for one architecture
<cjwatson> I don't have great intuition for this bit
<bregma> sil2100, and when you get the chance, landing-011 is ready for a publish (desktop-only)
<sil2100> thostr_: uh, sadly, it seems some of your components from line 8 are locked in a big silo 004 from Saviq
<thostr_> sil2100: but that can be landed now, no?
<sil2100> thostr_: yes, but it's still not built and tested
<Saviq> sil2100, silo 004 is just for testing, wasn't it supposed to be disregarded for locking?
<thostr_> sil2100: Saviq: if so, then just give us the override permission and everything should be good
<cjwatson> ok, fortunately the 13 minutes that that took on amd64 didn't multiply up by the other architectures
<sil2100> Saviq: ah, sure
<sil2100> thostr_: ok, let me assign that silo then
<sil2100> cjwatson: phew
<thostr_> sil2100: thanks
<Saviq> thostr_, sil2100, yeah, override away, we'll manage
<sil2100> ogra_: another packaging ACK: http://162.213.34.102/job/landing-011-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity_7.1.2+14.04.20140321-0ubuntu1.diff <- the migration file looks ok, checked in the bzr branch
<fginther> popey, hello. the changelog version for stock-ticker-mobile-app went backwards, causing the PPA upload problems. Is this something we can change?
<popey> fginther: we can
<ogra_> sil2100, looks fine, ACK
<popey> fginther: what went backwards?
<sil2100> ogra_: thank you again!
<popey> 0.4.3 -> 1.0 -> 1.0ubuntu1 in the debian changelog fginther ?
<sil2100> thostr_: line 8 assigned
<popey> fginther: the .desktop file was fixed by balloons in rev 177.. is that it?
<plars> sil2100: I'm still getting that error on your rerun, so I'm going to kill it
<plars> sil2100: I've set up another device to try
<plars> sil2100: and while that's running, I'll poke at some things on the first device we tried to see if I can find differences in it's behavior
<fginther> popey, the debian/changelog went from '0.3.7ubuntu1' to '0.3.7'
<plars> asac: ^
<fginther> popey, http://bazaar.launchpad.net/~stock-ticker-dev/stock-ticker-mobile-app/trunk/revision/63
<asac> plars: right
<fginther> popey, you're comment makes me think I'm looking at the wrong branch :/
<popey> oh, no, I am looking at the wrong thing
<popey> i was looking at sudoku, sorry
<ogra_> plars, so there is some weird behavior with all click tests ... resulting in an aa-click crash file ... that claims /usr/share/autopilot-touch/apparmor/click.rules does not exist ...
<sil2100> plars: strange thing, thanks, keep us updated :)
<ogra_> plars, do you have a chance to check on a device if that file is there (i think it makes all click tests fall over, but i see teh file on a fresh install)
<plars> ogra_: sure, I'm just looking for /usr/share/autopilot-touch/apparmor/click.rules on the device itself?
<popey> fginther: not been touched for ages. not sure why it would break now.
<ogra_> plars, yeah
<plars> ls: cannot access /usr/share/autopilot-touch: No such file or directory
<plars> odd
<ogra_> plars, https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/175/artifact/clientlogs/ubuntu_calculator_app/_usr_bin_aa-clickhook.0.crash/*view*/ is an example crash
<ogra_> so thats why all our click tests fail
<plars> ogra_: shouldn't autopilot put that there though?
<ogra_> plars, yeah
<ogra_> and it does so on my fresh install here
<ogra_> so something must have removed it
<fginther> popey, merging a changelog bump should get everything working again
<ogra_> is my assumption
<plars> ogra_: ok, so autopilot-touch is *not* installed on that device at the moment
<asac> feels like autopilot-touch isnt installed?
<plars> asac: right
<asac> so a dependency change issue
<ogra_> plars, asac, it is seeded
<ogra_> its in the readonly image
<ogra_> how can it be missing ?
<asac> apparmore could hide it, no?
<ogra_> not from root
<asac> then i dont know
<ogra_> i think
<plars> aha!
<plars> I found it
<ogra_> wow, i spent nearly my whole day on this ... fun that the file simply doesnt exist
<plars> + adb-shell sudo apt-get autoremove --purge -y python-gi url-dispatcher-tools
<asac> ogra_: do we see anything like that in the logs?
<asac> plars: who is doing that?
<ogra_> plars, lol !
<plars> ogra_, asac: so you remember that change that was made a while back to remove the deb packages that were installed for testing before going to the next test?
<ogra_> asac, thats fine (well, was)
<plars> that's the culprit
<plars> but this isn't a new thing
<ogra_> the last autopilot upload added a python-gi dep
<asac> plars: right. we have to run apt-get install ^ubuntu-touch after i guess
<plars> it's been like this for a while, so I guess something ... yeah
<asac> otherwise might loose something
<cjwatson> ok, proposed-migration should be back to normal now
<ogra_> its AP
 * ogra_ dances
<ogra_> hooray
<popey> fginther: https://code.launchpad.net/~popey/stock-ticker-mobile-app/fix-changelog sufficient? if so, I'll merge it
<ogra_> plars, so can we drop python-gi from that line safely ? its preinstalkled on the image now
<plars> I think so, hang on
<ogra_> i even read that line today
<ogra_> but it didnt strike me that it pulls AP as well
<plars> ogra_: right, so we force python-gi for the unity8 tests,  because that was needed at one time. If it's preinstalled now then we can drop that. Of course this doesn't prevent some other package from doing this to us in the future
<ogra_> indeed
<plars> ogra_: it's a bit heavy-handed, but we could force reinstall of autopilot-touch after, if there's no better way. For now though, I'll just pull out the python-gi bit
<ogra_> right
<ogra_> i doubt it has ill sideefects
<ogra_> we'll have to sort all that anyway once AP went off the image
<fginther> popey, +1
<fginther> If you propose an MP, I'll approve
<asac> plars: cool. thx
<asac> nice one
<asac> (i assume this is really it)
<ogra_> hard one though
<ogra_> asac, it is
<plars> ogra_: thanks for spotting that! that was the needle in the haystack we needed!
 * ogra_ knows everything about that issue now ... plars only have me the missing piece of the puzzle 
<ogra_> *gave
<asac> ogra_: thanks!
<sil2100> \o/
<asac> didrocks: plars has probably found the issue and is "fixing" it as we speak :)
<asac> read above
<sil2100> dbarth, mardy: hi! I think it would be nice if we could do a landing of signon and libaccounts-qt with the two merges 'working-around' the -dev cmake file install in the packaging
<sil2100> dbarth, mardy: as the current versions in the archive are broken
<sil2100> dbarth, mardy: I would say to land for now the workarounds, with moving the installation of cmake files only to the -qt4 versions (as per the 2 merges that are available)
<dbarth> sil2100: hi
<mardy> sil2100: do you think you could directly upload them, or do we need to pass through a silo?
<popey> fginther: https://code.launchpad.net/~popey/stock-ticker-mobile-app/fix-changelog/+merge/212451
<sil2100> We would land the proper fix later
<sil2100> mardy: I would say doing it through a silo would be cleaner
<mardy> sil2100: OK
<sil2100> mardy: we won't have to do the whole testing, just a general install would be sufficient
<dbarth> sil2100: on another note, i have line 33 with that pre-oxide set of MPs
<sil2100> As we would be only landing the 2 packaging fixes
<dbarth> sil2100: i've created a new request to distinguish between changes that require oxide as a build-dep
<dbarth> and those which are fine to build / test with just fixes and optional runtime support
<dbarth> sil2100: can you activate line 33, and we'll try to land that quickly before oxide is fully ready for a build dep
<plars> asac, ogra_, didrocks: ok, that fix has been pushed in, and I expect it will work. This explains why when I tried just one of the tests by itself everything went fine, but had problems when going through the entire run. There is already a run in progress that hasn't gone far enough to hit this, so we can let it continue to run, and it will get around to the failed ones eventually
<mardy> dbarth: so, we are talking about https://code.launchpad.net/~robru/signon/trunk/+merge/210917 and https://code.launchpad.net/~sil2100/libaccounts-qt/fix_dev_conflict/+merge/211058
<mardy> dbarth: can you queue a silo for them?
<sil2100> dbarth: dbarth thanks! I'll assign it pretty soon, we're low on silos but we published a lot of them now, and soon they should be free
<asac> plars: thx
<dbarth> sil2100: ok, keep us posted
<sil2100> dbarth: so I suspect that in an hour we might have all the required bits assigned with silos
<sil2100> Thanks guys!
<dbarth> mardy: once silos become available; how much of a priority is that?
<sil2100> plars: ah, so no re-run needed?
<dbarth> if that's to unblock other packages, I guess we can have a silo more easily, but i wiuld recommend we give a final try at the webapps+oa one and free the silo one way or the other
<mardy> dbarth: that's a question for sil2100; it's a packaging change, rather harmless, I'm not sure who requested it
<plars> sil2100: I kicked one on a different device after I saw yours was hitting the same problem, and it's already started - so there *is* a rerun needed, but I don't have to kill the one in progress to do it
<sil2100> mardy, dbarth: I would like to have it released as today while upgrading my system I encountered the conflict on my system first-hand
<sil2100> So generally it's not a good thing to have brokenness in the archive ;)
<sil2100> I wouldn't say it's high prio, but since it's a quick landing I thought we can quickly land it once some silos become available
<fginther> popey, do you want to set the release to 'trusty' in that MP?
<fginther> popey, I missed that when I looked a moment ago
<popey> fginther: saucy and trusty are the only two we're said we're building for
<fginther> popey, right. I mean change it from "UNRELEASED" to "trusty"
<fginther> in the changelog entry
<dbarth> sil2100: ok, hand over the silo when one is free and we'll do some quick regression testing on it
<popey> i changed from raring to UNRELEASED
<sil2100> dbarth: thanks :)
<cjwatson> is there any hope of getting https://code.launchpad.net/~cjwatson/dee/multiarch/+merge/211463 landed soon?
<stgraber> I just added a click landing to the spreadsheet, let me know when we can have a silo
<cjwatson> (stgraber's request is also indirectly from me, and I'd rather that one come first if there's a shortage)
<cjwatson> oh, click might fail to build until the python3-defaults/dh-python stuff in trusty is sorted
<davmor2> didrocks: sorry for the delay now I get the odd dates
<davmor2> didrocks: in gallery
<didrocks> davmor2: so, existing data?
<davmor2> didrocks: I added one image and 6 videos and I get 6 dates that are blank I'm assuming representing the videos
<didrocks> cjwatson: I guess for dee, you need the lander or you can get that in a stgraber's silo
<didrocks> which you will get once one is freed
<didrocks> davmor2: mind updating the bug report, set it as critical and send that to bfiller?
<didrocks> seems like an important one to me
<didrocks> thanks plars
<seb128> sil2100, Mirv: there are a bunch of silos that can be cleaned (so you can start attributing some backs ;-)
<josepht> t1mp: the CI job has been run on the MP you mentioned.
<sil2100> seb128: as Mirv is away, I'll m&c his silo ;p
<seb128> sil2100, thanks
<bfiller> davmor2: added videos how? via mtp? sounds like a missing codec if that's the case
<seb128> bzoltan, tvoss, bfiller also have silos that are waiting to be cleaned
<davmor2> bfiller: https://bugs.launchpad.net/ubuntu/+source/gallery-app/+bug/1296634
<ubot5> Ubuntu bug 1296634 in gallery-app (Ubuntu) "gallery shows blank dates and photos" [Critical,Confirmed]
<davmor2> bfiller: I added my steps below all of popey 's work
<davmor2> bfiller: let me know if you are missing anything
<bfiller> davmor2: what types of videos are they?
<popey> mine are h264
<davmor2> bfiller: the ones I copied across are the 6 mp4 I using in testing they all work fine on the device
<popey> they all play fine in mediaplayer and have thumbnails in the dash
<didrocks> davmor2: bug #1273781, did this ever worked or it was a regression?
<ubot5> bug 1273781 in ubuntu-system-settings-online-accounts (Ubuntu) "If you open the accounts page in the settings app and close it you can't reopen it" [Undecided,Confirmed] https://launchpad.net/bugs/1273781
<bfiller> davmor2: which version of gallery click?
<sil2100> bzoltan: hi! You can merge and clean silo 009 now :)
<popey> didrocks: i dont think that ever worked
<bfiller> davmor2: hopefully this will be fixed with pending version that is about to land - it uses libthumbnailer
<popey> bfiller: i tried latest in store and previous
<bzoltan> sil2100: thanks!
<bfiller> popey: click list?
 * cjwatson vaguely wonders why merge-and-clean isn't automatic
<popey> bfiller: i have downgraded to 931
<popey> com.ubuntu.gallery	2.9.1.931
<didrocks> thanks popey
<popey> but kept the same database so unsurprising the blank thumbnails are still there
<bfiller> popey: try mv ~/.cache/thumbnails to another location and restarting
<popey> ok
<sil2100> tvoss: you can merge and clean silo 008 if anything ;)
<tvoss> sil2100, cool, thank you
<tvoss> sil2100, triggered
<popey> bfiller: same
<popey> bfiller: http://popey.com/~alan/phablet/device-2014-03-24-155534.png
<sil2100> tvoss: thanks
<bfiller> popey: any chance you could upload a few of the videos and picture?
<popey> sure
<popey> most are ripped from youtube using youtube-dl
<thostr_> didrocks: Saviq: what about landing new scopes today?
<Saviq> thostr_, just running the fixed flaky test
<didrocks> thostr_: I'm all for that :)
<didrocks> thostr_: metapackage is ready and everything
<thostr_> didrocks: cool
<Saviq> thostr_, I'm +1 on it after that is confirmed fixed
<didrocks> great!
<Saviq> didrocks, so yeah, it's time for additional eyes
<didrocks> sil2100: if you are around?
<didrocks> stgraber: including dee request in the click one?
<sil2100> \o/
<sil2100> didrocks, Saviq: the scopes transition you mean?
<cjwatson> didrocks: they're unrelated so probably shouldn't be in the same silo
<didrocks> sil2100: yep
<didrocks> cjwatson: it's just to avoid using 2 silos as we are quite low on free ones
<cjwatson> well, ok, should be safe enough I guess
<Saviq> sil2100, yup, landing-013, needs some bashing :)
<didrocks> yeah, I don't think the dee part will break your landing :)
<cjwatson> seems unlikely :)
<didrocks> cjwatson: I'm adding it to the same request and configure it for you
<didrocks> cjwatson: stgraber: assigned
<t1mp> josepht: thanks!~
* josepht changed the topic of #ubuntu-ci-eng to:  Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: ADB host ashes is down
<cjwatson> didrocks: ta
<didrocks> yw
<tvoss> sil2100, could you give silo 001 a spin, too?
<sil2100> tvoss: sure ;) Getting to it!
<stgraber> didrocks: thanks
<tvoss> sil2100, thanks.
<sil2100> didrocks: you have a moment for a packaging ACK? :) http://162.213.34.102/job/landing-001-2-publish/lastSuccessfulBuild/artifact/packaging_changes_dbus-cpp_2.0.0+14.04.20140322-0ubuntu1.diff <- seems a bit hacky, but I guess it's ok in this case
<didrocks> sil2100: so, all the stack is building with gcc 4.8 on ppc64el?
<didrocks> I think it's due to the stack protector thingy
<davmor2> cyphermox: I've marked that bug as fixed I've not had issues with adb/mpt since ogra_ did all those update a few images ago
<cyphermox> thanks, that's what I thought
<ogra_> cyphermox, we seem to still have an issue with the mtp content not refreshing when files are added/removed though
<cjwatson> didrocks: either it is, or it won't build at all there :)
<cjwatson> didrocks: ppc64el doesn't have gcc-4.7
<cyphermox> ogra_: yes I know
<sil2100> didrocks: I need to check for other components, but I guess that's a start
<didrocks> ok, so all the stack is built with 4.8 and we won't have the ABI mismatch with C++11
<didrocks> thanks cjwatson
<didrocks> sil2100: based on that +1 ^
<ogra_> cyphermox, ah, good
<asac> cyphermox: can you ping RichiH about modemmanager?
<asac> thx
<tvoss> didrocks, sil2100 for questions on the motivation for the dbus-cpp fix -> doko :)
<cjwatson> tvoss: I think I've supplied the answers :)
<davmor2> popey: https://bugs.launchpad.net/ubuntu/+source/dialer-app/+bug/1288692 can you confirm this is fixed too?
<ubot5> Ubuntu bug 1288692 in dialer-app (Ubuntu) "Loudspeaker toggle broken in #223 on mako" [Low,Incomplete]
<balloons> bfiller, popey Mirv gallery app is uploaded to store, ready for review
<tvoss> cjwatson, oh yeah, sorry :)
<popey> ack
<bfiller> balloons: thanks
<popey> balloons: [u'all'] that looks wrong
<balloons> popey, scratch that, it built as _all
<popey> haha
<balloons> why did it do that?
<balloons> :-(
<cjwatson> because the manifest didn't have an "architecture" entry that said otherwise?
<seb128> hum
<seb128> jenkins down?
 * balloons looks
<cyphermox> so it is
<mhr3> sil2100, 34 pls
<Mirv> sil2100: thanks :)
<sil2100> mhr3: suar
<sil2100> Nooooo
<asac> plars: were we able to confirmt hat the fix helped?
<cyphermox> sil2100: didrocks: I'll restart jenkins...
<sil2100> cyphermox: if you have the power, please do
<cyphermox> done
<plars> asac: I'm watching the current build, and it should hit one of the failed ones soon - when that happens I'll send out an email
<asac> plars: ok so we didnt see it helping yet? ic
<plars> asac: also, we have confirmation from IS that they got the previously dead device host back up and running
<asac> nice
<asac> so we have all the devices available again? /me thinks nothing can stop us now
<ogra_> did they add a proper BIOS then ? :)
<sil2100> mhr3: you have to wait some time, jenkins is restarting
<mhr3> sigh
<cyphermox> should be back up alredy
<cyphermox> it only takes a minute
<plars> asac: good news, notes-app was the fist one it got to that was failing before, and it's now passing :)
<davmor2> popey: do you get a nice black screen for several seconds if you close a video?  Same as you get when you close accounts.   Makes me wonder if the 2 are called in a similar fashion and the call has changed
 * ogra_ hugs plars 
<sil2100> mhr3: anyway, it's assigned ;)
<popey> davmor2: lemme test
<mhr3> sil2100, i'll call 002 my personal silo :)
<plars> ogra_, asac: Also, the original host is back up - since mako seems to be running ok, I'm going to let it continue that job where it's at, but I did go ahead and kick off flo and manta on the original adb host
<davmor2> popey: when I say close I mean hit the minimise button or whatever it is meant to be :)
<popey> davmor2: yeah, goes black here. stays black
<davmor2> popey: it goes eventually honest :)
<popey> hah, *eventually*
<popey> yes
<ogra_> plars, yeah+
 * plars watches image 256 gradually get a little more green
<davmor2> okay hands up if you deal with accounts and mediaplayer
<asac> plars: \o/
 * davmor2 sees asac put his hands up and blames him for all the black windows when closing accounts and videos
<davmor2> :D
<ogra_> twice even
<ogra_> that were two hands
<davmor2> ogra_: one for each application obviously :)
<ogra_> heh
<ogra_> didrocks, heh, funny, so now my morning notification mail has a HO link, the evening one doesnt
<ogra_> (well, it has it as text in "location" just not as link)
<sil2100> didrocks: meeting :)
<didrocks> yeah, was in a meeting
<didrocks> coming, sorry
<didrocks> cyphermox: coming?
<fginther> popey, can you take a look at my comment here: https://code.launchpad.net/~popey/stock-ticker-mobile-app/fix-changelog/+merge/212451
<ogra_> bfiller, messaging-app tests seem to fail in flames
<ogra_> http://ci.ubuntu.com/smokeng/trusty/touch/mako/256:20140324:20140304/7337/messaging_app/
<popey> fginther: fixed it to raring (like previous releases)
<tvoss> sil2100, didrocks, Mirv could someone review the packaging changes in https://code.launchpad.net/~thomas-voss/process-cpp/fix-death-observer/+merge/211996
<tvoss> I needed to bump the so name
<dbarth> sil2100 or robru: I messed up the reconfig. of silo 007; the update to https://code.launchpad.net/~mardy/webbrowser-app/add-onlineaccount-support-for-container2/+merge/211701 is not getting in
<dbarth> can you manually reconfig this one?
<fginther> popey, thanks, approvedd
<robru> dbarth, sure
<bfiller> ogra_: must be the apps fault :)
<ogra_> bfiller, dialer too it seems (that one just finished)
<ogra_> 4 failures in 9 tests
<robru> dbarth, ok, reconfigged
<dbarth> robru: thank you!
<robru> dbarth, you're welcome
<dbarth> robru: and if a silo frees up, i also have this line 33 for later today
<robru> dbarth, ok, i'll keep an eye
<robru> dbarth, yeah, your line 33 has webbrowser-app which conflicts with your existing silo 7. but the good news is that there's no restrictions on landing, so if you can test silo 7, i can publish that, and then get you a silo for line 33
<robru> mhr3, just published silo 2
<mhr3> robru, ty
<robru> mhr3, yw
<robru> seb128, you got silos 11 and 12
<mhr3> didrocks, something wrong with 013?
<didrocks> mhr3: hum, why?
<didrocks> seems "building"
<mhr3> didrocks, cause it says it's building, but the link is dead
<didrocks> interesting
<didrocks> mhr3: weird weird weird
<didrocks> seems jenkins "lost" this run
<didrocks> I just rerun with watch onlly
<robru> tvoss, you got silo 14
<mhr3> didrocks, k
* fginther changed the topic of #ubuntu-ci-eng to:  Ubuntu CI Engineering Team | Vanguard: fginther | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: ADB host ashes is down
<didrocks> mhr3: seems the right status is available now
<didrocks> mhr3: however, not sure why the test plan is content-hub
<didrocks> and not unity8 :)
<mhr3> didrocks, clearly to make it pass :P
<seb128> robru, thanks
<robru> seb128, you're welcome
<didrocks> mhr3: tsss ;)
<ogra_> hmmm, sudoku-app fails too
<ogra_> and it didnt change since 250
<ogra_> argh
<ogra_> and calculator-app looks awful as well
<ogra_> heh, or not ... the dashboard is cheating :P
<ogra_> it was cheating for sudoku too
<ogra_> bah
<asac> ogra_: arent the results still outdated on ci.ubuntu.com?
<ogra_> asac, until the tests have run ... the dashboard shows the old tests until the new ones have run ... i looked to early at sudoku and calculator
<ogra_> http://ci.ubuntu.com/smokeng/trusty/touch/mako/256:20140324:20140304/7337/
<ogra_> sadly dialer and messaging failures are real
<t1mp> for messaging they also failed on my mako (with a fresh 256 image): http://paste.ubuntu.com/7147199/
<balloons> bfiller_afk, fyi, store changes are holding back gallery app from going on. The store folks are looking into fixing the issues. ETA is today
<robru> ogra_, feel like kicking an image build? i've published a few things this morning, seems like a good time for a new image to me
<ogra_> robru, i thought we shouldnt until all new sopes are in ?
<ogra_> *scopes
<ogra_> at least thats how i understood didier in the meeting
<robru> ogra_, hmmm i published a few scopes already, let me check on that
<ogra_> (i was distracted, but i think he said something like that)
<robru> ogra_, oh yeah, I guess that's silo 13 then, with ubuntu-touch-meta
<ogra_> right
<ogra_> so lets wait until thats done
<robru> ogra_, i already landed all the other scopes, so i think just silo 13. ok
<asac> ogra_: hmm. ok. well, folks should fix it then
<robru> Saviq, how's silo 13 testing going? need help?
<t1mp> hello. I'm trying to run some AP tests for apps to test changes in ubuntu-ui-toolkit
<t1mp> I cannot test with the autopilot packages that match the versions of apps in image 250, because they are no longer available
<t1mp> I can do an apt-get update first and then get them, but then I will have mismatching versions of apps/libs
<t1mp> and image 256 has some broken apps/tests
<t1mp> so would it be useful to make sure that the -autopilot packages for the latest promoted image are still available somewhere?
<t1mp> I don't know if it is feasible to arrange that
<t1mp> at least then we can test our changes with the AP tests in the latest promoted image
<ogra_> t1mp, as cjwatson suggested, we should copy them to some PPA when the image is built or so
<t1mp> I missed that
<t1mp> but that sounds like a good solution for me
<t1mp> cjwatson: +1 :)
<tedg> robru, There are some packaging changes that need acking for the silo 15 publish: http://162.213.34.102/job/landing-015-2-publish/9/
<robru> tedg, yeah, cyphermox just acked those, will publish in a sec
<tedg> robru, Cool, thanks!
<tedg> cyphermox, Thanks!
<robru> tedg, ok, silo 15 published
 * tedg does a little dance
<ogra_> asac, http://ci.ubuntu.com/smokeng/trusty/touch/mako/256:20140324:20140304/7337/
<ogra_> looks great (apart from the known two apps)
<fginther> robru, is lp:qtcreator-plugin-cmake now in ci-train? I see revisions indicating that it is - https://code.launchpad.net/~ubuntu-sdk-team/qtcreator-plugin-cmake/trunk.  but the spreadsheet doesn't list it: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c&usp=drive_web#gid=1
<robru> fginther, everything should be in citrain. spreadsheet is probably just stale, lemme check
<fginther> robru, thanks. It's a new branch. I don't even have the ci jobs enabled in s-jenkins yet
<robru> fginther, yeah, so assigning an official lander & test plan for that seems to have been forgotten, we should do that
<robru> fginther, right, daily_release is dead, when adding new projects to ci make sure to have the three "use citrain" flags set (just like all the others)
<fginther> robru, ack
<asac> ogra_: yay. do we know whats up with those apps?
<ogra_> asac, nope, but bfiller_afk is pinged
<asac> ogra_: did we land them?
<ogra_> yes
<ogra_> in 253
<asac> ogra_: reproducible locally?
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/253.changes
<ogra_> asac, yeah, i think t1mp reproduced it, he pinged me about it even befoe we re-ran the tests on the infra
<asac> bfiller_afk: sure you tested your silo for landing with proper attention :)? or maybe because of click you missed that?
<asac> guess click can easily lead to such mistakes
<ogra_> yeah
<ogra_> though these two are unconfined ...
<ogra_> so click shouldnt make a big difference
<asac> ogra_: well, oversight
<asac> using apt-get install
<asac> but not updating the click package
<asac> its all sergios fault :P
<ogra_> yeah, might be
<ogra_> (not the latter one :P )
<robru> Saviq, i tried running unity8 AP on silo 13, got some funny errors: http://paste.ubuntu.com/7147801/ maybe a dep missing? any thoughts?
<Saviq> robru, yeah, wrong tests
<Saviq> robru, probably stale ~/autopilot or something?
<robru> Saviq, oh, that's possible. let me blast that and try again
<Saviq> robru, I'm +1 on it
<robru> Saviq, ok great. it looked really good to me just playing with it briefly, will publish soon
<Saviq> robru, awesome
<popey> fginther: can you take a look at bug 1296610 ? The build for click has the key, but the desktop build in the ppa doesn't. -> var twcKey = "";
<ubot5> bug 1296610 in Ubuntu Weather App "Desktop: TWC key is missing in the daily-ppa " [High,New] https://launchpad.net/bugs/1296610
<asac> ogra_: couldnt we revert the click things from store?
<asac> sounds like one of the easier things to do
<ogra_> dunno
<ogra_> popey, ^^^
<ogra_> iirc you did that already
<popey> ogra_: revert what exactly?
<ogra_> dialer and messaging
<popey> have they been updated in the store?
<ogra_> dunno how they get in
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/253.changes
<popey> they get manually put in and then I test and either accept or reject them usually
<ogra_> they were updated in 253
<popey> dialer and messaging aren't clicks are tey?
<popey> *they
<ogra_> oh
<ogra_> indeed they arent
<popey> ii  dialer-app     0.1+14.04.20 armhf        Dialer application for Ubuntu
<ogra_> yes
<popey> ii  messaging-app  0.1+14.04.20 armhf        messaging application for Ubuntu
<ogra_> the changelog tells us :P
<popey> :D
 * Saviq just read "dealer-app" WHA?!
 * popey wanders off again
<ogra_> asac, so not a store thing
<ogra_> Saviq, ssshhh
 * popey has a butt-clench every time I see dialer-app â»  should be dialler â»
<Saviq> :D
<bfiller> balloons: thanks
<t1mp> popey: and dealer id dealler in britain?
<asac> ogra_: ?
<asac> ogra_: cant we just remove latest version from store and done?
<asac> anyway out for now. happy that ci is back on image level
<asac> and that the ashes server is also back (soon?)
<thostr_> Saviq: robru: can you drop me a not if/when the scopes finally make it?
<Saviq> thostr_, will do
<pmcgowan> scopes landing?
<thostr_> Saviq: thanks
<pmcgowan> hoohaa
<thostr_> pmcgowan: yes
<robru> thostr_, Saviq: just getting packaging changes acked by core dev. should be good Real Soon
<thostr_> robru: ok, then I leave it in your hands... should be a piece of cake now anyway :)
<plars> bfiller: the 15 failures on messaging app appear to be reproducible on my setup at home also, have you seen these? http://ci.ubuntu.com/smokeng/trusty/touch/mako/256:20140324:20140304/7337/messaging_app/
<plars> bfiller: there are dialer_app failures also
<bfiller> plars: boiko was looking at them
<plars> bfiller: ok, thanks
<bfiller> boiko: any update on this?
<t1mp> plars: I created a bug for it https://bugs.launchpad.net/messaging-app/+bug/1296826
<ubot5> Ubuntu bug 1296826 in messaging-app "A bunch of autopilot failures when testing with image 256" [Critical,New]
<robru> Saviq, ok, just hit publish on silo 13 now ;-)
<mhr3> robru, \o/
<robru> mhr3, ohhhhhh yeah
<mhr3> robru, so 257 will have it?
<robru> mhr3, heck yeah! we (ogra_?) are gonna kick 257 as soon as unity8 makes it through proposed, maybe in an hour
<mhr3> think i'll take holiday just to celebrate that
<robru> mhr3, yeah, I was testing the silo and it looked like a massive improvement. I'm excited too!
<mhr3> oh were the old scopes that bad? i haven't been running them for too long :)
<robru> mhr3, well, unity8 home screen used to just hard-code 9 apps with no way to change it. now that's gone, and the scopes-scope makes unity8 much more dynamic, almost like a real usable OS ;-)
<mhr3> i do see the *almost* there ;P
<boiko> bfiller: I flashed my nexus 4, installed messaging-app, and ran the tests, they were OK, but tiago managed to reproduce the problem, we are still checking what is going on
<boiko> plars: did you run autopilot on the device, or did you use phablet-test-run, or even something else?
<plars> boiko: something that runs phablet-test-run - we have ci infrastructure that sets everything up and runs through all the tests, but in the end, for autopilot tests, it's just running phablet-test-run
<cjwatson> t1mp: nope, still dealer
<cjwatson> robru: oh yeah, I should see whether it still has that bug where it shows those nine apps even if some of them have been removed :-)
<robru> cjwatson, i think you'll be pleasantly surprised ;-)
<boiko> plars: ok, trying that here
<Saviq> robru, \o/
<balloons> bfiller, popey is finishing the review now for gallery -> store
<popey> balloons: running ap tests now
<bfiller> popey, balloons: thanks
<bfiller> popey: regarding that blank thumbnail, trying to track that down. Basically the gallery is now supposed to show thumbnails and allow playback of videos found in ~/Pictures or ~/Videos. Works fine on desktop. For some reason the image provider is crapping out on the device hence the blank spots where the videos shoul be
<popey> right
<pmcgowan> bfiller, any particular format?
<bfiller> popey: trying to figure out what is causing that
<bfiller> pmcgowan: I tried a bunch of different ones
<pmcgowan> bfiller, I know a number do not work, even in the scope
<pmcgowan> bfiller, do they show up in scope?
<popey> yes
<bfiller> pmcgowan: the weird thing is they all show up correctly in the scope and play in the mediaplayer
<pmcgowan> hmm
<popey> and play fine
<pmcgowan> got it
<bfiller> seeing this error in the log: Failed to get image from provider: image://thumbnailer/home/phablet/Pictures/Tears_of_Steel-Trailer.mp4
<bfiller> for all videos
<bfiller> it's got to be a codec thing, or bug with libthumbnailer on the device
<pmcgowan> but they are there for the scope, thats thumbnailer
<bfiller> maybe a permission thing
<pmcgowan> btw is that the design, to show all in /Videos?
<bfiller> as gallery is confined
<bfiller> it is now :)
<pmcgowan> I thought we just wanted to show stuff the camera recorded, but I cannot recall exactly
<pmcgowan> bfiller, you may need a new profile for apparmor
<popey> i see no apparmor DENies in dmesg
<bfiller> pmcgowan: for desktop mode we needed to make videos show up and play, so it's a carry over. We can disable I suppose for the device. The camera doesn't support video recording yet.
<pmcgowan> bfiller, may want to, I thought there was something in the gallery design
<bfiller> pmcgowan: kind of strange to only show videos recorded with the camera - we had a hack in there to only look for the file extension saved by camera recorder but that was not good
<pmcgowan> bfiller, it kinda makes sense, as camera vids are short and you really want to play the in a component, whereas movies are fullscreen in the player
<pmcgowan> not sure, need to check
<bfiller> pmcgowan: that's how it used to work, we'd need a better way to check if the vid was recorded by the camera not using file extension
<bfiller> pmcgowan: what about on desktop?
<pmcgowan> bfiller, same thing?
<pmcgowan> lets check the original docs
<bfiller> pmcgowan: maybe, I like that it shows me all of my vids
<bfiller> so I can use one app
<thomi> fginther: doanac: When you gentlemen have a moment, I wonder if you could update me with the dashboard subunit conversion  work please? Perhaps drop me an email?
<pmcgowan> bfiller, wfm
<popey> balloons: does gallery ap tests not delete the gallery database first?
<balloons> popey, I've never really played with them
<balloons> popey, I can look one sec
<popey> oooh!
<popey> running AP it just played one of my videos!
<bfiller> popey: it's kind of strange, supposed to make a backup
<popey> that's gonna fail
<bfiller> popey: but think it doesn't work right. if any tests fail I see the test vids in my gallery aftwards
<balloons> popey, yep, looking at the code bfiller is correct. It makes a backup, assuming other stuff is there
<popey> ./gallery-app: unrecognized option '--pick-mode'
<popey> saw that mid-test
<popey> gonna start again, screen went blank mid-test
<popey> haha, rogue __init__.py in my ~/Pictures directory
<bfiller> popey: fwiw, I ran all the AP tests on the gallery click that was built from same version one you are testing
<popey> ok
<bfiller> popey: it did work for me after seeing some weirdness
<bfiller> popey: I first moved my Pictures dir out of the way and then retried
<popey> its better after clearing out the database and pictures and videos
<fginther> thomi, aye.  I'll need to get the latest from doanac who is out of the office until tomorrow.
<thomi> fginther: ok, can you email me please?
<fginther> thomi, yes
<thomi> thanks!
<bfiller> plars: I think there is a serious problem with phablet-test-run
<plars> Oh?
<bfiller> plars, thomi : all the tests are failing with an Invalid application id
<bfiller> and when running it from my desktop it's accessing files in local directory
<popey> balloons: bfiller gallery 2.9.1.934 approved into store
<thomi> bfiller: which test suite?
<plars> bfiller: boiko was having trouble reproducing though
<bfiller> thomi: http://ci.ubuntu.com/smokeng/trusty/touch/mako/256:20140324:20140304/7337/messaging_app/
<bfiller> plars: well it's failing for me in the same way when using phablet-test-run
<thomi> bfiller: hey, not *all* the tests are failing :P
<bfiller> :)
<thomi> bfiller: I note that it's launching it as a normal app, rather than as a click or upstart app. Is that what it's supposed to do?
<thomi> I kind of expected all the touch apps to be click/upstart at this point?
<bfiller> thomi: they are not all clicks
<bfiller> messaging-app is not a click
<thomi> bfiller: oh ok.
<bfiller> thomi: check out this log when running phablet-test-run from my desktop http://pastebin.ubuntu.com/7148342/
<bfiller> thomi: note the files before the invalid application id message - all from my local disk -- weird
<thomi> hmm, "Neil Young songbook" - you sir, have good taste in music :)
<bfiller> plars: when running autopilot run directly on the device the screen goes black
<bfiller> while the tests are running
<thomi> bfiller: I'm not sure what the message even means TBH
<plars> bfiller: we do some things to prevent that in our scripts
<plars> bfiller: assuming you are talking about screen timeout/blanking?
<thomi> bfiller: perhaps someone from kgunn's team would be able to help out?
<bfiller> plars: right
<plars> bfiller: if you want to run it the same way we do:
<plars> bzr branch lp:ubuntu-test-cases/touch
<plars> cd touch/scripts
<plars> export NETWORK_FILE=<path/to/nm/conf>
<plars> ./run-smoke -a messaging_app
<plars> Note: this will reprovision with the latest image
<ToyKeeper> Can anyone verify bug 1292420?  It seems like it might be important...
<ubot5> bug 1292420 in dialer-app "headset mic ignored during calls" [Undecided,Confirmed] https://launchpad.net/bugs/1292420
<ToyKeeper> I'd imagine that we care about headsets being usable for calls.
<kgunn> thomi: bfiller whats the question ?
<thomi> kgunn: what does the "invalid application id" message in http://pastebin.ubuntu.com/7148342/ mean?
<thomi> kgunn: and why does it show files from bfiller's disk in the log message?
<bfiller> I'm going to go out on a limb here and guess the 15/16 failures are not problems with the messaging app. we couldn't have broken it that badly
<kgunn> i got nada
<kgunn> for the AP test run and screen timeout, gonna need to "powerd-cli display on bright" on the device (as root)
<kgunn> current problem of new qt 5.2 won't deliver signals when rendering loop is halted
<kgunn> (which we're looking into)
<bfiller> boiko, plars: the tests fail for me whether I run autopilot locally on the device or through phablet-test-run
<plars> bfiller: they fail for me too, I think boiko was having trouble recreating at one point though
<Saviq> robru, does unity8 have a problem migrating to release pocket? it's been in proposed for an hour already?
<robru> Saviq, hmmm, i was waiting for the autopkgtest to finish, although i just see now that it passed
<Saviq> robru, ah, ok, not like we have autopkgtests :)
<robru> cjwatson, poke about unity8, we seem stuck on arm64/etc again
<Saviq> uh, so that needs manual poking every time? :|
<robru> Saviq, shouldn't need it, but we're just in this somewat transitory state where there's three new arches the release team is trying to bootstrap
<Saviq> robru, mhm, understood
<boiko> plars: bfiller: found the reason for the failures, cooking a fix here
<plars> Bioko++
* fginther changed the topic of #ubuntu-ci-eng to:  Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: ADB host ashes is down
<Saviq> robru, is there any place to grab -dbgsym packages other than ddebs? apparently armhf .ddeb for the latest unity8 didn't reach ddebs yet :/
<Saviq> http://ddebs.ubuntu.com/pool/universe/u/unity8/
 * Saviq says that's weird, it's been built a good few hours ago
<robru> dunno
<cjwatson> robru: oh right, that
<cjwatson> Saviq: unity8 is a very special case here :-/
<robru> cjwatson, yay, save us ;-)
<cjwatson> done for next run
<cjwatson> Saviq: (unity8 triggers the unity-scope-click autopkgtest, fwiw)
<robru> ogra_, cyphermox, rsalveti: ok, anybody around to kick a new image build? we just landed unity8 ;-)
<rsalveti> robru: I can do it
<rsalveti> building
<robru> rsalveti, thanks!
<cjwatson> robru: you need to wait for rmadison to say it's landed
<cjwatson> robru: so this image build won't actually have the new unity8
<cjwatson> robru: when the LP UI ticks over, that means the publisher run has *started*, not finished
<cjwatson> robru: rmadison updates at the end of the publisher run
<robru> cjwatson, oh, usually the difference between lp and rmadison is only a few minutes, and also the image build takes an hour to download all the packages somehow
<cjwatson> robru: a release pocket update typically takes at least 15 minutes, and the image build updates its indices near the start
<cjwatson> robru: so you are walking on very thin ice
<robru> cjwatson, hummm, i'm always told that it's not safe to publish packages during image build, and the build takes an hour
<cjwatson> robru: I have no idea what that first thing is a mangled version of, but it's not true
<cjwatson> please wait until rmadison updates before requesting image builds
<rsalveti> hm, I thought you were checking with rmadison as well
<robru> cjwatson, rsalveti i was just looking at the spreadsheet, which gets updated from lp i guess
<cjwatson> I expect so
<imgbot> === trainguard: IMAGE 257 building (started: 20140324-22:50) ===
<cjwatson> the only leeway you have at the start of the image build is that it runs debootstrap first
<rsalveti> yup
<Saviq> cjwatson, yea, noticed that (re: u8 autopkgtest)
<cjwatson> please can we find out where this notion that it's unsafe to publish packages during an image build comes from, and exterminate it
<Saviq> cjwatson, on that note, I was planning to add actual unity8 autopkgtests (qml ui test in xvfb), do I need to do anything beyond what's written down in the manual, bearing in mind this click-scope "override"?
<cjwatson> there we go, you lost the race
<cjwatson> Get:530 http://ftpmaster.internal/ubuntu/ trusty/universe unity8 armhf 7.84+14.04.20140319.1-0ubuntu1 [3849 kB]
<cjwatson> Saviq: shouldn't, but it'd be a good idea to use adt-run (or whatever advice is in the wiki) to test things before uploading, of course :-)
<robru> cjwatson, so, at some point I asked ogra "i need to publish some packages, but i don't want them to be in the current image build, when can I do it?" and he said "when you see the image here" or whatever, and showed me the URL where the builds get uploaded to, which would be the last possible point in the build process
<Saviq> cjwatson, yeah, of course
<robru> rsalveti, ok, can you cancel the image build and restart it in 10 mins?
<cjwatson> robru: well, to start with, that's quite different from "how can I guarantee that packages I've published will be in the next build"
<cjwatson> robru: it's not cancellable
<cjwatson> you lose
<cjwatson> you just have to wait
<rsalveti> yeah, will trigger another one once this is done
<robru> can we at least disable the smoke run since we know this image is garbage?
<cjwatson> robru: in fact it's possible to publish packages rather earlier, as soon as the relevant download phase has finished; it's just hard to get that information externally (at the moment, anyway)
<rsalveti> robru: plars should know
<robru> plars, please disable the smoke run for image 257, it's gonna have an inconsistent set of packages and can't possibly be any good
<Saviq> robru, thanks for pressing "clean & merge", btw
<cjwatson> robru: the only "unsafety", though, is that the packages you've published might end up in a build; they won't be inconsistent
<robru> Saviq, you're welcome!
<cjwatson> or at least no more inconsistent than the release pocket is
<robru> cjwatson, oh but you're wrong! i published silo 13 and now image 257 has only one of the two packages from that silo. so very inconsistent state here
<cjwatson> this run is only inconsistent because dependencies weren't strict enough to ensure that everything landed in the release pocket together
<cjwatson> that is nothing to do with image build vs. package publication races or anything like that
<cjwatson> it has everything to do with lazy metadata
<robru> cjwatson, zuh? i hit the publish button on a silo and now an image is building that only has part of that silo
<cjwatson> publishing a silo does not guarantee that it all hits the release pocket together!
<cjwatson> it is vitally important that you educate yourself about how this actually works
<cjwatson> https://wiki.ubuntu.com/ProposedMigration
<cjwatson> publishing a silo puts it in the *input* to that process
<cjwatson> this has zero to do with image build atomicity with respect to the archive
<cyphermox> robru: didn't didrocks mention there was a pending change in the seeds to watch out for, specifically re: scopes for unity8?
<cjwatson> one day, maybe it might not be terrible to figure out how we can communicate constraints from the CI system to proposed-migration to ensure that silo contents are migrated atomically
<cjwatson> but that's vapourware today
<robru> cyphermox, yep, i took care of that. the seed was in silo 13 that i just published. the thing to watch out for was that all the other scope silos needed to land, which they did
<cyphermox> robru: alright
<cjwatson> the system assumes that if packagers think it's important for things to migrate together, then they bother to say so in dependencies :)
<cyphermox> robru: ping me if there are any reviews to do, but I'll be coding on personal stuff tonight
<cyphermox> cjwatson: yeah
<robru> cyphermox, i think we're pretty good here... i'm winding down on landings
<robru> cjwatson, right, it would make a lot of sense for silos to be treated atomically
<cyphermox> cjwatson: would it work for the silo publishing code to also push versioned blocks for each of the binary packages in the silo, which can then be explicitly removed?
<cjwatson> I don't think that's the right approach
<cyphermox> ok
<cjwatson> Too much busywork
<cjwatson> It needs to communicate a constraint; there's no syntax for that today
<cyphermox> no, there isn't
<cjwatson> And we would need to think about how this works if e.g. there's a subsequent manual upload to the archive which is needed to get things past p-m
<cjwatson> It's not an entirely trivial problem
<cyphermox> I'm not saying it is, just mentioning an idea in passing
<cjwatson> Right; the problem with versioned blocks would be that remembering to lift them would be error-prone
<robru> rsalveti, got you silo 7
<cyphermox> I'm quite good at bad first ideas :)
<cjwatson> And would introduce non-trivial delays
<rsalveti> robru: thanks
<robru> rsalveti, you're welcome
<cyphermox> cjwatson: ah, I was actually thinking about some automation for lifting them as well
<cjwatson> Not to mention non-atomicity, because something might go wrong between checking that they're safe to lift and the next run which processes the unblock
<cjwatson> So in fact I think that just kicks the can down the road and doesn't actually help
<cyphermox> probably yeah
<robru> rsalveti, so, cron kicks an image in ~4 hours, and I don't think I'll be landing anything before then... do you think it's safe to just let cron kick it, or should we kick another one right after 257 finishes?
<cyphermox> rsalveti: hey
<rsalveti> robru: wait for cron
<cyphermox> got a public presentation of ubuntu touch by any chance?
<robru> rsalveti, sounds good
<rsalveti> cyphermox: hm, not yet :-)
<rsalveti> cyphermox: what do you need?
<cyphermox> rsalveti: a local LUG is asking me to do a presentation soonish
<cyphermox> I'll fix up slides at some point
<rsalveti> cyphermox: right, I need to do that soon as well, will present ubuntu-touch on elc-us
<cjwatson> robru: so, sorry if I was harsh above, but I really think it's important for the landing team to understand how -proposed works and its interaction with image building, since in some sense these are more CI components.  if there's anything I can do to document/explain things better, let me know
<cjwatson> and I get unhappy when voodoo rules are passed around :-)
<rsalveti> cyphermox: only slides I got atm are those I gave you a few months ago
<robru> cjwatson, it's ok, i only know what people tell me.
<cyphermox> rsalveti: alright :)
<cyphermox> cjwatson: I guess that's my failure there, I should have better mentioned checking for rmadison output
<boiko> plars: https://code.launchpad.net/~boiko/messaging-app/fix_autopilot_tests/+merge/212526
<boiko> plars: I will be submitting a similar fix for dialer_app too
<plars> robru: how bad would it be? are these package issues that would just cause a lot of failures, or package issues that would make it to where someone needs to manually recover the device?
<plars> unless it would put the device out of commission, it would be better to just let it run
<robru> plars, uhhhh well we got a seed update in there, without the associated unity8 update that went with it. most likely any unity8 and scopes tests are gonna fail... i guess it won't be "unrecoverable" but it won't be usable
<plars> robru: let's just let it run then, I can't easily tell it "just skip the next one". I could disable the runs, but then if we got another one after that it would be disabled. I would have to know when this one is coming and I'd have a 5 minute window to stop it before it really gets going
<plars> robru: if there's another fixed one right after though, and I'm still up and you want me to stop it so we can start tests on the newer one sooner, just let me know
<robru> plars, hmmmm ok
<robru> plars, we decided to let the next fixed one just get kicked by cron, which is ~3.5 hours away now... that one should be fine
<plars> sounds good
<boiko> plars: and the one for dialer-app: https://code.launchpad.net/~boiko/dialer-app/fix_autopilot_tests/+merge/212527
<boiko> plars: I managed to reproduce the bug, but still it would be nice if you could give this one a try just in case
<robru> Saviq, oh, don't forget to rebuild unity8 in silo4 so that it includes all the new stuff we just published.
<Saviq> robru, right
#ubuntu-ci-eng 2014-03-25
<imgbot> === trainguard: IMAGE 257 DONE (finished: 20140325-00:15) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/257.changes ===
<Saviq> robru, could you please delete indicator-datetime, indicator-sound and unity-greeter-session-broadcast packages from silo 004?
<Saviq> robru, and please reconfigure when that done, I just kicked a rebuild of unity8 and removed MPs that we don't need any more
<Saviq> /sleep
<robru> Saviq, sure thing
<Mirv> testing infra shows signs of coming back to life, but not quite
<Mirv> so um we should have 258 built for the unity8, I guess by cron if no-one around?
<Mirv> wow, the silo 004 is still a bit amiss
<Mirv> trying reconfigure + build/watch again
<Mirv> doing direct magic on the silo project files
<Mirv> direct magic helped, silo 004 now looking good again (after lightdm rebuild finishes)
<didrocks> Mirv: hey! mind looking at the 2 failures (unity8 and messaging-app) on the dashboard? My guess is really a missing depâ¦
<Mirv> so, unity8 resolved leaves messaging-app and dialer-app having some weirdness still (visible also on #256 test results, but locally both passed)
<Mirv> let me check with manually updated image with the new unity8
<imgbot> === trainguard: IMAGE 258 building (started: 20140325-07:20) ===
<didrocks> Mirv: probably a missing dep, you think?
<Mirv> well, I do have messaging app failing also locally after dist-upgrade. but my Unity8 also has an ugly grey background, which is probably not what robert saw when testing it.
<ogra_> hmm, i wonder who turned off the 3am build
<vila> Mirv: so messaging app failures are reproduced locally ?
<Mirv> vila: "maybe", I'm not sure if my phone is good after dist-upgrade
<Mirv> vila: but the thing is that they're now also shown for #256 while I have logs clearly showing how they passed locally.
<vila> Mirv: ok, I'm looking at the unity8 ones for now, have ruled out python-autopilot-trace as a missing dep despite the warning as I found the same message in a passing run
<Mirv> vila: unity8 is possibly resolved by this new #258 build, see robert's message on the mailing list
<vila> ha, let me check mail
<Mirv> vila: #257 was started too early so it lost packages, so it's broken
<vila> O_o
<vila> Mirv: argh, arck, stopping #257 analysis :-/
<Mirv> I wonder if the "tested and ready for release" content-hub is causing some problems too, meaning if it's related to my grey background in unity8
<Mirv> but maybe when #258 is upgradeable to it will be seen if it continues to be so
<didrocks> vila: yeah, right now, I would say just keep an eye on the messaging-app one, I'll fetch info on the dialer-app (and ignore unity8)
<ogra_> didrocks, i thought asac wanted to have both rolled back ?
<didrocks> both?
<didrocks> I don't know
<didrocks> is it latest producing that?
<ogra_> he talked about it last night
<ogra_> dialer and messaging fail local tests too and there was no fix uploaded
<ogra_> at least i dont see anything on -changes
<didrocks> ogra_: and rollbacking make them pass?
<didrocks> this analyze was done?
<ogra_> (this went back and forth a little last night, i havent read the backlog, gimme a bit)
<ogra_> didrocks, i dont think so, no
<didrocks> ogra_: so why rollbacking? :p
<ogra_> didrocks, aha ... seems dialer and messaging are tested as click apps
<didrocks> ah, but I would expect all dialer test to fail
<didrocks> not only a few
<didrocks> right?
<didrocks> vila: can you get that fixed? ^
<ogra_> hmm, so what i grok from the backlog between plars and bfiller is that there is some issue with the testing
 * didrocks finishes his download + flashing
<didrocks> just to ensure that testing "the proper way" pass
<ogra_> last thing i see on the topic: <boiko> plars: bfiller: found the reason for the failures, cooking a fix here
<didrocks> hum
<didrocks> so not only that?
<ogra_> now he doesnt say where he fixes it :)
<didrocks> ok, upgraded to the broken image done
<didrocks> broken as in == no scope :p
<didrocks> at least, the tests are starting here
<didrocks> (messaging-app)
<Mirv> nope, my grey background problem isn't fixed by reverting the content-hub landing, so it's more likely the scopes/unity8 landing in general
<Mirv> or then just my cats again and no-one else has the problem
<didrocks> Mirv: I don't have a grey background
<sil2100> Mirv: ;)
<didrocks> Mirv: just the default background
<didrocks> and no scope
<Mirv> bah
<didrocks> which was to expect
<ogra_> you should probably borrow Mirv's cats then
<ogra_> seems to be needed to reproduce :)
<didrocks> ogra_: I have enough regressions on my own to not add more :)
<Mirv> good riddance regarding the white one, at least temporarily. he's quite demanding.
<ogra_> heh
<didrocks> Mirv: he likes camera as well, you should just do some videos
<vila> didrocks: no idea what you're talking about O_o will read backlog
<vila> ogra_: the discussion happened here ?
<ogra_> vila, yep
<ogra_> vila, 22:23 -> 23:03
<sil2100> I wonder where the problems from dialer-app and messaging-app come from, I don't remember publishing those two recently
<ogra_> (say my timestamps in xchat)
<sil2100> And they're still .deb's
<ogra_> sil2100, they changed on saturday
<sil2100> Oh, that's why I don't know about it
<sil2100> ;)
<Mirv> UDS video appearances are enough :)
<ogra_> i think robru published them
<ogra_> (he did a few silo flushes over the weekend ... which would have been fine had we had tests :P )
<Mirv> sil2100: the weird thing is that I've logs here running dialer-app+messaging-app tests successfully on #256 yesterday, but they are now visible in the #256 results too
<ogra_> (and one image build per flush)
<didrocks> ogra_: landing line 40
<didrocks> Mirv: sil2100: ^
<didrocks> but wasn't tested
<Mirv> oh, right, I assigned that silo in the morning and kicked the build
<Mirv> anyone with slightly more functional device could maybe test the silo
<didrocks> there is clearly another issue
<didrocks> all messaging-app tests are passing here
<sil2100> didrocks: without changes from this silo?
<didrocks> ouai, but running it as a deb package
<ogra_> well they clearly dont on the infra
<didrocks> yeah
<didrocks> vila: so, it seems that messaging-app is configured as a click package
<didrocks> instead of a deb
<ogra_> and i know that t1mp pointed me to it yesterday as well
<didrocks> maybe that was fixed and next image will have the configuration ok
<didrocks> meanwhile, I'm installing the silo
<ogra_> even before we had test results
<didrocks> and will test
<ogra_> didrocks, the backlog doesnt look like someone put any other effort into it
<ogra_> (from CI side)
<didrocks> vila: can you check that?
<ogra_> (would really help if you could see the backlog :P )
<didrocks> ogra_: well, I can go to irclogs.ubuntu.com
<didrocks> but I guess that we understand what we know
<sil2100> didrocks: hm, but from what I see on the testconfig.py, messaging and dialer are still configured to run as deb tests
<popey> bah
<didrocks> sil2100: do you see any recent change for that?
<popey> broken unity. updated in between robru and ogra mails â¹
<ogra_> yay timing
<popey> http://popey.com/~alan/phablet/device-2014-03-25-083743.png
<sil2100> http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/view/head:/jenkins/testconfig.py <- no, just this python-gi addition
<popey> clean aesthetic
<didrocks> popey: my build should be finished quite soon
<ogra_> popey, shiny
 * popey files a bug in case anyone else happens to update
<didrocks> hum
<ogra_> sil2100, right, python-gi is installed by default (new autopilot-touch dep since the last upload)
<didrocks> so, why do we have all failures on the infra?
<didrocks> I don't reproduce that locally
<imgbot> === trainguard: IMAGE 258 DONE (finished: 20140325-08:40) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/258.changes ===
<didrocks> popey: upgrade ^
<popey> will do
<popey> how?
<popey> system-image-cli ?
<Mirv> popey: like suggested on another channel, it's this new "clean style"
<didrocks> popey: yeah, the -cli
<popey> â»
 * didrocks does the same
 * Mirv wonders why -cli?
<popey> cant start apps
<didrocks> Mirv: well, no way to launch system settings
<ogra_> http://paste.ubuntu.com/7150216/
<didrocks> or
<popey> actually you can
<didrocks> su - phablet
<didrocks> phablet@ubuntu-phablet:~$ upstart-app-launch ubuntu-system-settings
<Mirv> oh, right, luckily I've such a good #257 in use that I can launch it (just ignore my and my device...)
<ogra_> thats the complete log from the last dislaer-app test
<popey> pull down on the indicator, battery, battery settings, back, updates â»
<didrocks> popey: my way is easier!
 * didrocks clicks now install and restart
<vila> didrocks, ogra_, Mirv, sil2100: So, from the backlog, it seems boiko worked on https://bugs.launchpad.net/messaging-app/+bug/1296826 made https://code.launchpad.net/~boiko/messaging-app/fix_autopilot_tests/+merge/212526 and https://code.launchpad.net/~boiko/dialer-app/fix_autopilot_tests/+merge/212527
<ubot5> Ubuntu bug 1296826 in messaging-app "A bunch of autopilot failures when testing with image 256" [Critical,In progress]
<didrocks> vila: yeah, we do have it in silo8
<vila> but the later haven't even landed (they are approved but not merged)
<didrocks> vila: so, you are sure that messaging-app isn't configured as a click app?
<didrocks> vila: I'm just puzzled to not reproduce the messaging-app "all failures" locally
<didrocks> so just want to ensure this is enough
<didrocks> popey: upgrade works FYI
<didrocks> I have scopes
<didrocks> and yeah, I can see the first bug you'll open
<ogra_> see the log
<ogra_>  phablet-test-run -o /var/lib/jenkins/slaves/mako-11/workspace/trusty-touch-mako-smoke-daily/clientlogs/dialer_app -a /var/crash -a /home/phablet/.cache/upstart -v dialer_app
<vila> didrocks: no I'm not, I can't connect that click/deb thing to the MPs
<popey> bug 1297141
<ogra_> that is what is run
<ubot5> bug 1297141 in unity8 (Ubuntu) "Scopes don't start on image #257 - fixed in #258" [Undecided,New] https://launchpad.net/bugs/1297141
<ogra_> 02:20:32.131 INFO _launcher:230 - Launching process: ['/usr/bin/dialer-app', '-testability', '--desktop_file_hint=/usr/share/applications/dialer-app.desktop']
<didrocks> vila: ok, ogra_'s log confirm it's not click
<sil2100> ogra_: the config says that it installs the -autopilot packages, so I would say it doesn't use it as click - but let me see the infra logs
<vila> popey: right, sounds like the way to go, but can someone explain me ... ack
<didrocks> vila: let's hope the ofono-phonesim fix is what's failing on the infra reliably
<didrocks> I don't understand why it's not here :/
<ogra_> didrocks, do you have a SIM ?
<didrocks> ogra_: not as of now, I remove it when running the AP tests on purpose
<ogra_> the lab devices have a SIM card
<didrocks> (and it's always a PITA to remove on the N4 as you know :p)
<didrocks> oh
<sil2100> oh?
<didrocks> so the fake phonesim is starting too late
<didrocks> and the hack could work?
<didrocks> (stopping the service, restartingâ¦)
<didrocks> that would explain
<ogra_> (which was causing the difference between tablet and phone tests in the past when we had ofono-phonesim issues)
<didrocks> osomon is testing the silo btw as of now
<ogra_> i think it just doesnt know which to chose
<didrocks> yeah
<didrocks> so "last wins"
<didrocks> and it can be racy
<didrocks> I guess
<ogra_> if one wins at all (by looking at the fixes)
<didrocks> yeah
<didrocks> ok, so, we should be good
 * didrocks crosses fingers
<ogra_> try reproducing with a SIM inserted :)
<didrocks> let's getting that published once tested and kicking an image
<sil2100> didrocks: should we just wait for osomon's testing, or you want us to double-test that before landing?
<didrocks> sil2100: if you have time, if you can do the double testing that ogra_ suggested
<didrocks> with a sim card in
<sil2100> ACK
<ToyKeeper> Hello, r258... my, how you've changed since r257.
<sil2100> ;)
<ToyKeeper> Looks like I picked the wrong time to start...  got most of the way through image 257's tests (despite the complete lack of any scopes), and then 258 popped out.
<didrocks> ToyKeeper: hey! always read the phone ML :)
<ToyKeeper> I often try to get things done before I deal with email, to avoid spending the whole day on unplanned tangents.  :(
<ToyKeeper> didrocks: Did you see bug 1292420?  It seems like something we should probably care about.
<ubot5> bug 1292420 in dialer-app "headset mic ignored during calls" [Undecided,Confirmed] https://launchpad.net/bugs/1292420
<sil2100> ToyKeeper: was that working before?
<ToyKeeper> I think it was working like 30+ images ago...
<ToyKeeper> ... but I'm not 100% sure.
<didrocks> ToyKeeper: too old and too many uncertainities to consider that as a blocker, just something to put high on the trusty release list
<ToyKeeper> Okay, good to know.
<ToyKeeper> Anyone else had issues with the screen getting stuck on after making/receiving calls?
<didrocks> I just had one app getting stuck
<didrocks> (webbrowser)
<didrocks> try switching to another app
<didrocks> to see if only the app is stuck or everything
<ToyKeeper> ... what.  Image 258 insists that I don't even have cell service, and refuses to make calls.
<seb128> thostr_, your indicator-sound landing from yesterday is creating issues on desktop, https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1297034
<ubot5> Ubuntu bug 1297034 in indicator-sound (Ubuntu) "Do I really need 17 click or phone related packages on a Desktop install?" [Undecided,New]
<seb128> thostr_, can you join #ubuntu-devel?
<ogra_> gah
<ToyKeeper> On the odd chance that my local cell provider is actually down, I think I'll wait until morning to continue.
 * ogra_ forgot to re-set his DSL reconnect ... i might drop off the meeting after a few (for a few) minutes
<sil2100> didrocks: be ther in a minute
<didrocks> sil2100: coming soon as well
<sil2100> GRRR
<ogra_> didrocks, indicator-sound revert just landed
<seb128> ogra_, does it matter to touch?
<seb128> ogra_, it should be a noop for you, since you don't consider recommends
<ogra_> seb128, yeah, it should, but didrocks was watching for the landing
<sil2100> ok, now suddenly google hangouts crashed, that's something new
<didrocks> sil2100: we just finished
<Mirv> sil2100: FWIW I updated to 5.2.4.0-1 of google-talkplugin which still seems to work ok
<sil2100> Mirv: maybe I need to upgrade as well, need to check on which version I am now on
<ogra_> sil2100, did you verify dialer/messaging break with a SIM ?
<ogra_> bah
<ogra_> no wallapaer on the new unity/scopes
<ogra_> seb128, is someone working on that ?
<ogra_> wow, and the UI is a lot slower when scrolling
<seb128> ogra_, no wallpaper on scopes?
<seb128> ogra_, no idea, I've nothing to do with unity8/scopes
<ogra_> seb128, yeah, we got new scopes and a new unity ...
<seb128> try asking Saviq or mhr4?
<Saviq> ogra_, that's by design
<ogra_> seb128, now there is no wallpaper anymore, i guess they look for it in a different place now
<ogra_> Saviq, you mean i cant adjust the wallapaer anymore ?
<Saviq> ogra_, no, wallpaper is only meant to bleed-through below the header
<ogra_> *wallpaper
<ogra_> well, it doesnt do that either
<Saviq> ogra_, yes, "meant to"
<Saviq> ogra_, that's not implemented yet
<Saviq> ogra_, check out https://drive.google.com/a/canonical.com/?tab=co#folders/0B-a_7E3tDxOgTTBybG1TZG9GWnM
<ogra_> and if thats by design, the wallapaer selection in system-settings needs updating
<Saviq> indeed
<ogra_> .oO( why cant i type "wallpaper" today)
<Saviq> ogra_, what's more scopes are meant to (not implemented yet either) choose a different background for themselves now, too
<ogra_> thats why i pinges seb128
<ogra_> *pinged :)
<Saviq> ogra_, it was devised that people's wallpapers are too busy for a generic background
<ogra_> sigh, who decided the back button needs to sit on the farthes reachable place on the screen ?
<ogra_> i cant use my phone one handed anymore
<Saviq> ogra_, you need bigger hands
<ogra_> a twice as long thumb
<ogra_> thats annoying
<ogra_> really takes the fun out of using it
<Saviq> ogra_, talk to Dani, he's doing the header UX
<Saviq> ogra_, FWIW, this came out of user testing
<ogra_> Saviq, well, putting it *in* the header at all is my issue
<didrocks> Saviq: ogra_: when you tell "no wallpaper", you mean, you only have the origami effect?
<didrocks> with the lines?
<ogra_> i cant reach it if i hold the phone normal
<Saviq> didrocks, yes
<Saviq> ogra_, and is coming to apps, too
<didrocks> ok, for me that was a wallpaper :p
<Saviq> didrocks, in a sense, it is!
<ogra_> didrocks, i'm using my own wallpaper (this is my main phone) since day one
<ogra_> didrocks, now i cant anymore
<didrocks> ogra_: even my desktop has the default!
<Saviq> it's even made of... paper!
<didrocks> heh
<ogra_> didrocks, i found the default phone one awful when we started :)
 * sil2100 had a nice manga wallpaper on his phone always
<ogra_> (i did even set it before we had an app for this ... excitingly seb128 workd so well that the app just picked it up since :) )
<didrocks> sil2100: btw, osomon confirmed the AP test pass
<didrocks> sil2100: same for you?
<ogra_> but that back button placement really wants me stop to use it
<ogra_> thats the most pointless place to put such an important function
<ogra_> i can only go back by using the other hand or hold the phone in a way that makes it awkward to reach the bottom parts
<sil2100> didrocks: dialer app was ok on the first run, running messaging app - I also ran the tests without the PPA on my phone and confirmed that they're failing as on the infra ;/
<Mirv> Saviq: ogra_: oh, it's (the background) by design, that explains it
<didrocks> ogra_: stop to want to go backward, go forward! </non constructive joke ;)>
<didrocks> sil2100: "grreat"! :)
<ogra_> didrocks, heh
<seb128> didrocks, ogra_, Saviq: I didn't update my device yet, I'm unsure what the wallpaper is but it's not likely something for me or settings: p
<didrocks> seb128: agreed
<ogra_> seb128, you cant set it anymore ... so the setting is pointless
<didrocks> we should just be prepared to see rant/bugs opened
<didrocks> Saviq: do we have this statement from design in a bug report?
<seb128> ogra_, oh ok, "great"
<didrocks> ogra_: it changes in the greeter, still?
<Saviq> didrocks, yes
<sil2100> No more girls as my background, OUTRAGE
<ogra_> yes
<ogra_> greeter is fine
<ogra_> wallpaper isnt
<seb128> shrug
<Mirv> it's even more confusing because the background setting in settings shows "how it'd look like" in the old style
<didrocks> Saviq: do you have it off hand so that we can direct people to it?
<seb128> Saviq, since when do you know about that?
<Saviq> didrocks, https://drive.google.com/a/canonical.com/?tab=co#folders/0B-a_7E3tDxOgTTBybG1TZG9GWnM
<sil2100> When I was buying my first phone ever as a teen my only requirement was 'being able to set a custom wallpaper' ;)
<didrocks> seb128: it was in the mwc image, but I thought personnaly they wanted to use another wallpaper by then
<Saviq> didrocks, scopes are now meant to be able to set their own backgrounds, too
<didrocks> Saviq: that a public folder?
<Saviq> didrocks, I think so
<didrocks> ok, will share on the ML if needed
 * Saviq tries
<Mirv> sil2100: when I was telling my parents what phone to purchase me as a present, the only requirement was to "be able to send SMS in addition to receiving them" (Nokia 1611 - awesomeness!) :D
<Saviq> didrocks, no, it's actually not
<didrocks> Saviq: yeah, tried an inconito mode
<sil2100> ;p
<didrocks> Saviq: can we have design stating that in a bug report?
<didrocks> Saviq: that needs to be documented publicly
<Saviq> didrocks, the images themselves are public, though
<didrocks> Saviq: well, it's not a document
<Saviq> seb128, well... since I saw the first designs...
<ogra_> oh
<ogra_> since when do we have a mediaplayer icon !
<Saviq> didrocks, no, I just meant that the folder isn't, but the images themselves are
<ogra_> lol
<ogra_> which just gets me an error message
<didrocks> Saviq: yeah, not something we can point people directly to
<Saviq> ogra_, we had it before... looks like a bug in click scope
<Saviq> ogra_, shouldn't be there
<seb128> Saviq, which is?
<ogra_> yeah, seems it cant start if it doesnt get a file handed over
<ogra_> would need a file selection dialog or so
<seb128> Saviq, it would have been nice if somebody told us earlier, rather than letting us do work that can be thrown away now
<seb128> oh well
<Saviq> seb128, well, no, not that far back
<Saviq> seb128, separate wallpapers were there in the image already when I first saw those
<seb128> Saviq, we did the new design changes like in january
<ogra_> Saviq, wehn do we get the new app switcher UI ?
<seb128> but a part of that still works for the greeter image selection I guess
<Saviq> ogra_, it's coming
 * ogra_ thought that would land alongside
<Saviq> seb128, but it's not like it's a new thing for us that we get complete redesigns every month or so
<ogra_> k
<Saviq> ogra_, no, we wanted it separate on purpose
<seb128> Saviq, it's new for me, I'm used to live in my desktop world ;-)
<ogra_> ah
<Saviq> seb128, slacker
<seb128> lol
<ogra_> the UI is really stuttery for me wiht a few apps open
<Saviq> ogra_, yeah we need to work on performance
<Saviq> ogra_, open apps don't really matter
<ogra_> flicking through the app sand going back to the home scope the UI doesnt react for a while
<ogra_> *through the apps
<Saviq> ogra_, the items got much more flexible, so complex
<Saviq> we need to do some tricks there
<ogra_> yeah, understood
<sil2100> oh, mhr3 reverted his ABI change
<sil2100> He's back to soname 3
<seb128> he got downgraded
<mhr3> sil2100, yea, introduced lots of regressions :P
<sil2100> ;)
<sil2100> didrocks: publishing the dialer and messaging silo
<didrocks> reverted even \o/
<didrocks> sil2100: sweet!
<imgbot> === trainguard: IMAGE 259 building (started: 20140325-10:45) ===
<didrocks> urgh
<didrocks> who started it?
<didrocks> ogra_: ^ ?
<sil2100> o_O
<sil2100> Why would we need a new image now?
<didrocks> we'll loose time as well on the testing side
<sil2100> Image build shtaph!
<ogra_> you cant stop them
<ogra_> and i told you that infinity had a build queued
<sil2100> didrocks: you think I can publish a thumbnailer landing?
<didrocks> ogra_: but for Touch as well?
<ogra_> which would get us one unconditional build
<ogra_> didrocks, for touch what as well ?
<didrocks> ogra_: a build queued for Touch? Not sure why infinity care about that one (or he rebuilds all flavors?)
<cjwatson> bulk rebuild for beta
<ogra_> didrocks, he turned off the cron job and had added all builds to his rebuild queue script it seems
<ogra_> i turned cron back on, but cant remove his queue stuff :)
<cjwatson> it was probably accidental but can't really be stopped now
<ogra_> right
 * sil2100 sighs
<didrocks> ok
<didrocks> I hope that this will be more fine grained in the future
<ogra_> didrocks, well, he just wanted to be nice and make sure we still get a build even with disabled cron
<didrocks> ogra_: yeah, but not sure why cron was disabled in the first place
<ogra_> (not knowing about our way to build images on demand)
<didrocks> as we are not part of beta freeze
<cjwatson> again by accident
<ogra_> didrocks, cron was generally disabled for all build
<ogra_> s
<didrocks> ok
<ogra_> by accident
<cjwatson> I'm going to move it out to a separate block so that it's more obvious
<ogra_> and the queue script obviously was already holding a build for touch
<didrocks> thanks cjwatson
<ogra_> (and i warned you in the meeting so you wouldnt be surprised) :)
<didrocks> doanac: hey, once you are around, I hear that parallel testing is mostly there, is it already the case?
<didrocks> ogra_: didn't hear that part, only heared about the cron
<ogra_> was the same setence ;)
<ogra_> (or one before/after that one)
<didrocks> that's maybe why I only got half of it :p
<didrocks> ogra_: it's not Friday!
<didrocks> :)
<ogra_> no, on fridays i dont want to smash my phone to the wall :P
<seb128> https://errors.ubuntu.com/problem/bb53c1417a42ad5963219f4244f7447f7f5b1042 suggests there is a new issue/segfault with the most recent telephony-service update
<seb128> (not sure if that's known, I'm reviewing e.u.c and noticed it so mentioned it in case)
<davmor2> Morning all
<didrocks> seb128: mind mentionning that to #ubuntu-touch? (I guess osomon)
<seb128> didrocks, did it, https://launchpad.net/ubuntu/+source/telephony-service/0.1+14.04.20140319-0ubuntu1 has mterry and boiko listed but neither of them seems to be online atm
<didrocks> seb128: yeah, that's why I looked at all, and seems the apps team is doing most of the work there, hence the suggestion
<seb128> didrocks, I'm going to ping boiko&mterry as well later
<didrocks> seb128: thx!
<seb128> yw!
<didrocks> davmor2: so, once you get a nice stacktrace, you are going to hand it over to Saviq and mhr3?
<didrocks> Saviq: mhr3: FYI, we can get some crashes in unity8 with new scopes by expanding some content (especially the big ones)
<davmor2> didrocks: once I can break it again it seems to be refusing to now
<davmor2> popey, didrocks: music preview in scope is playing up when the screen shuts down
<didrocks> davmor2: playing up as?
<davmor2> didrocks: randomly pausing just trying it from applications where it seems fine
<popey> seems fine in scope here
<didrocks> davmor2: can't that be the same infamous Qt issue?
<davmor2> popey: select a long track, play it in the scope and let the device sleep and it pauses more erratically as it goes
<popey> not here
<popey> been playing a long track for a while now
<davmor2> popey: hmmm okay
<popey> run top, whats running?
<popey> is it busy?
<davmor2> popey: yeah could be I'll try that
<davmor2> didrocks: could well be but it is more that it pauses for a second or two then carries on so I assume popey is correct and some process suddenly uses all the cpu for a second or something
<didrocks> yeah
<davmor2> popey: connect the device with music on to your computer, Open rhythmbox select nexus 4 from devices do all the tracks show up as unknown?
<popey> yes
<davmor2> okay so with top running no hang up
 * davmor2 glares at ogra_ and cyphermox 
<davmor2> trying music playback again with the lead removed
<ogra_> hmm ?
 * ogra_ only touches upstart jobs for mtp ... 
<davmor2> ogra_: I know but I still blame you ;) It's the way to get things fixed :D   I did glare a cyphermox too to be fair :)
<ogra_> :)
<davmor2> popey, didrocks: okay so the music is playing perfectly now which is what I expected so I can only assume it was some random spike in use \o/ one less issue :) Now to try and get the damn thing to crash unity8 again :)
<didrocks> yeah
<didrocks> ok, so let me append an image build now
<didrocks> done
<Saviq> davmor2, didrocks, if you have steps to repro, that'd be greate
<Saviq> -e
<didrocks> Saviq: seems that om26er got it as well
<didrocks> Saviq: basically, play with the expander on the app scope (for suggestion)
<didrocks> I got it once
<didrocks> and second time
<didrocks> Saviq: want the crash file?
 * didrocks wants for apport to finish the collect
<Saviq> didrocks, I think we need to up the kill timeout again to make apport work... at least that's what I was seeing for exit crashes, although those might be special
<didrocks> Saviq: it's collecting for more than a minute here
<didrocks> so, we should be fine
<didrocks> 40M until now
<didrocks> ah done
<didrocks> 43M!
 * didrocks adb pull
<didrocks> Saviq: a bug with the crash attached is fine? (better for you to retrace manually I guess?)
<Saviq> didrocks, well, letting apport do its thing still good
<didrocks> Saviq: let's do both :p
<Saviq> didrocks, but you can submit somewhere for me to retrace
<Saviq> didrocks, exactly :)
<didrocks> Saviq: manual bug: https://bugs.launchpad.net/unity8/+bug/1297236
<ubot5> Ubuntu bug 1297236 in Unity 8 "Unity8 with new scopes crashes randomly when expanding some big category scope" [Critical,New]
<didrocks> Saviq: now, let me report the other one
<didrocks> Saviq: bug #1297240 (let's wait for apport to retrace it)
<ubot5> Error: Launchpad bug 1297240 could not be found
<didrocks> I added you to it
<didrocks>  QQuickWindowPrivate::polishItems()
<didrocks> too much polish! :)
<Saviq> didrocks, mhr3 saw that, too
<ogra_> want more french ?
<didrocks> ogra_: I can ensure you you wouldn't have a crash in that case :p
<ogra_> lol
<ogra_> right
<didrocks> only weird characters :p
<didrocks> and typos in the UI
<didrocks> anyway, time for a run!
<ogra_> run forest run !
<didrocks> ;)
<didrocks> I'll try to avoid the chinese president
<didrocks> seems he's in town today and I can sense traffic jams :p
<ogra_> oh, you run that far ?
<didrocks> ahah
<ogra_> ah, he is in town
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<imgbot> === trainguard: IMAGE 259 DONE (finished: 20140325-12:05) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/259.changes ===
<ogra_> hmm, that was a pointelss build
<davmor2> ogra_: http://people.canonical.com/~ogra/touch-image-stats/259.changes no changes what?
<Mirv> so no new messaging/dialerapp
<ogra_> davmor2, yeah, no uploads between 258 and 259
<Mirv> "47 minutes ago" (messaging/dialer-app, published, according to LP)
<ogra_> right
<ogra_> plus publisher run ... which can be another 30min
<Mirv> yep, and anyway the image build started half an hour before even that
<ogra_> but i think didrocks said he queued a build
<ogra_> (though that will be in line with beta builds as well i think, might take a while til it gets a free slot now)
<ogra_> oh
<ogra_> ne build is already running ... why did the bot not pick it up
<Mirv> imgbot: feeling tired of all the builds?
<cjwatson> There aren't any beta builds happening at the moment
<cyphermox> davmor2: popey: I'm already aware of the tracks showing as unknown, but there were higher priorities than mtp tbh
<davmor2> cyphermox: pfff who needs to make calls and listen to them on bluetooth ;)
<davmor2> cyphermox: is there a bug for it?
<cyphermox> I think there is yeah
<cyphermox> well, there are only about 10 bugs for mtp so could you please check and file one if there isn't ?
<cyphermox> actualy, hold on, I think I have the tab open
<cyphermox> no bug for that
<cyphermox> please file one ;)
<davmor2> cyphermox: will do
<cyphermox> thanks
 * Chipaca waves
<sil2100> Hello o/
<sergiusens> didrocks, sil2100 I just added line 44 for Chipaca on the sheet, can we assign a silo?
 * sergiusens just got back, may be lacking info
<sil2100> sergiusens: sure :) hi!
<sil2100> sergiusens: you're in luck, we have some free silos
<sergiusens> sil2100, heh, it seems we may finally be able to land the phablet-tools one as well; just waiting for doanac to be here to ask him to trigger a full run for ci
<t1mp> asac: hello
<Mirv> sil2100: are you querying for packaging ack for the album art service?
<sil2100> Mirv: yeah, I'm dealing with it, just got context switched out of that one - pushing it forward now
<sil2100> didrocks: hello! Do you have a moment for a packaging ACK? 2 packages need ACKing, looking safe:
<Mirv> ok, just curious
<sil2100> http://162.213.34.102/job/landing-009-2-publish/34/artifact/packaging_changes_thumbnailer_1.1+14.04.20140324-0ubuntu1.diff
<sil2100> http://162.213.34.102/job/landing-009-2-publish/34/artifact/packaging_changes_ubuntu-ui-toolkit_0.1.46+14.04.20140324-0ubuntu1.diff
<sil2100> Mirv: thanks for reminding ;)
<t1mp> asac: I have an issue with getting *all* app autopilot tests to pass for merge requests in ubuntu-ui-toolkit.
<sil2100> ogra_: hello! Can you take a look on those 2 above ^ ? :)
<t1mp> asac: I cannot test with image 250, because I cannot apt-get install the autopilot tests for the versions of apps that are in the image (they are not in the archive anymore?)
<sil2100> ogra_: I don't like the double-changelog entry for the UITK, but otherwise well, seems ok
<t1mp> asac: if I apt-get update first, I get mismatching versions, and apt-get upgrade and/or installing a newer (not promoted) image will give me apps/tests which are failing
<t1mp> asac: how would you propose we proceed? I can top-approve MRs where all tests except known-broken ones (in the latest proposed image) pass, and leave a note that some tests were not executed successfully?
<t1mp> asac: that way we can proceed to add new features/bugfixes, but it won't give us 100% good test results so there is always a risk of breaking stuff
<asac> t1mp: feels like a bug in your test job that it can't test click apps
<asac> maybe lets get that fixed? Alternatively, you should be able to do the landing properly by doing those tests manually
<asac> (like most other landers do right now)
<t1mp> asac: do all apps have click packages?
<asac> t1mp: do you have a job that tests your silo?
<asac> t1mp: yes all but two
<asac> almost all have been moved to click
<asac> t1mp: where is your test job? and who did that job?
<t1mp> asac: no, our policy is to pass all tests before top-approving an MR. And no MR goes into a silo before it is top-approved
<asac> t1mp: oh i think you use a local script that runs them all?
<t1mp> asac: I am trying to run the tests locally
<t1mp> asac: yes
<t1mp> asac: if there is a better way, please educate me
<asac> t1mp: yeah, thats not complete then. you can run them all manually once and get kaleo to support that script?
<t1mp> asac: I am running kaleo's script to run them all locally
<asac> t1mp: well, that script was developed by kaleo for convenience
<asac> so he missed click apckages. you can run them without that script. check with sergiusens
<asac> and then have the script fixed
<asac> sergiusens: ^^
<asac> sergiusens: any doc that shows how to run click tests with phablet-test-run?
<t1mp> asac: phablet-click-test-setup should install the click tests for all apps?
<sergiusens> asac, in the wiki
<asac> t1mp: probably with some command argument
<asac> t1mp: https://wiki.ubuntu.com/Touch/Testing
<sergiusens> https://wiki.ubuntu.com/Touch/Testing#Running_Click_tests
<asac> sergiusens: how do we keep the list of commands in sync?
<asac> do we have a process or automationm in place?
<sergiusens> asac, can you rephrase that question?
<asac> sergiusens: i see a list of commands in that section
<asac> sergiusens: that gives the impression that if you run those you have run all
<sergiusens> asac, we don't change them
<sergiusens> I consider that 'backwards' compatibility to never break ci
<t1mp> asac, sergiusens thanks
<t1mp> sergiusens: is that list of click tests supposed to be complete? a bunch of apps are not in the list there
<ogra_> asac, as i mentioned yesterday, ev tasked doanac with developing a phablet-test-run-all script
<asac> sergiusens: no. that list has like 10 apps
<asac> sergiusens: how do we ensure that we add app 11
<sergiusens> t1mp, that's easy to answer
<asac> in case we add it to our image
<ogra_> to actually have a wrapper that runs everything in one go
<sergiusens> t1mp, these are all the preinstalled apps http://people.canonical.com/~ubuntu-archive/click_packages/click_list
<popey> asac: sergiusens i dont believe that page should list every app, but just list how to do it for one app and point to the list of installed apps
<asac> sergiusens: the way it is presented gives the impression that its all tests (e.g. timp and me had the same question indicates that its a bit confusing) ... I would suggeste to add a comment so that people know that this list might not be up-to-date or complete; and also explain how to find the complete list
<t1mp> sergiusens: so I still have a problem with everything that is installed as a deb in the image. If I use (for example) image 250, I need to use apt-get to install the autopilot tests for that right?
<t1mp> sergiusens: but the autopilot tests with matching versions for image 250 seem no longer in the archive
<asac> popey: right, but the list looks too complete to make that clear is my comment
<popey> asac: its a wiki, feel free to edit it
<sergiusens> asac, it's a wiki; people change it as they feel it adds clarity; just change it
<asac> think just giving one or two examples would be better
<t1mp> sergiusens: for example messenger-app, webbrowser, unity8
<sergiusens> I didn't even create that wiki
<boiko> t1mp: btw, I found the problem yesterday and proposed an MR for that, it is already merged
<asac> sergiusens: well, there was an intend by someone to do it like that :)
<t1mp> boiko: cool, thanks :) I saw it in the bug report.
<asac> so i dont want to just wipe that intend. maybe the intend was to have it always have all commands for copy/paste
<t1mp> boiko: do you know if it is in image 259?
<sergiusens> t1mp, yes; you need apt-get for the debs
<boiko> t1mp: flashing now, let's see
<sergiusens> t1mp, I dn't like the tests as deb solution fwiw, I like the click approach I did a lot better; intended for times like these ;-)
<ogra_> asac, the initial issue was that the names of the test packages varied a lot in the beginning ... some were ubuntu-$appname-app ... others had an underscore instaed of a dash others again had no ubuntu-
<sergiusens> t1mp, for the tests as debs you need to discuss with the ci and qa team
<popey> asac: sergiusens added a line to make that clear
<asac> sergiusens: we would like to have that click_list for our images
<asac> sergiusens: http://people.canonical.com/~ubuntu-archive/click_packages/click_list
<ogra_> asac, so initially a detailed list was needed
<asac> thats not versionmed
<asac> so its probably as of today :)
<t1mp> sergiusens: I'm confused who is on which team, and in which channel to find people for that
<sergiusens> ogra_, I am already working on phablet-test-run click:com.ubuntu.music and it will run all the tests the manifest sasys it can run (which isn't just autopilot)
<t1mp> so I come to this channel for all CI testing and landing questions
<ogra_> if the tests now follow a scheme it should be fine to just have the procedure once
<sergiusens> t1mp, this is obviously the wrong channel, don't know why people discuss everything here
<asac> t1mp: you are in right channel :)
<t1mp> haha ;) that explains my confusion
<sergiusens> asac, just run 'click list' on the image
<asac> t1mp: fginther, ev are your point of contact; doanac is working on an official version of kaleo's script
<sergiusens> asac, there's even a test for that that I wrote
<asac> sergiusens: why do you think that -ci-eng is not the right question to ask about anything CI and landing related?
 * asac confused :)
<asac> this is the channel for that purpose :)
<ogra_> he said that to confuse you :)
<asac> sergiusens: i know. but having that info off the image is also good
<sergiusens> asac, was a general comment; I see people discuss architecture; general image testing here as well
<ogra_> mission accomplished
<sergiusens> and not everyone is here
<sergiusens> and shouldn't be
<Mirv> t1mp/etc: FYI for the non-click AP tests (ie come from debs) what I do is http://pastebin.ubuntu.com/7151115/
<asac> ah
<asac> well, thats the normal case for IRC channel
<sergiusens> I would much rather prefer this channel to be treated as the ubuntu-release channel
<asac> you just wander off topic and then you pull in crowds to the wrong channel. thats why private channels end up talkinga bout public matters etc.
<Mirv> the first two separately and then outputting to a log file when executing a script with the rest of the lines
<asac> sergiusens: this is the channel about our CI engine and services :)
<t1mp> Mirv: I do something similar, but the problem is that for the latest proposed image, apt-get install fails saying those packages are not available (anymore). And running apt-get update first will give me mismatching packages or new packages that are broken
<asac> landing is a service by CI
<sergiusens> asac, t1mp, ok, so IMO the autopilot as debs, you need to contact either/or thomi, veebers, jfunk, fginther doanac
<sergiusens> that's the list I believe
<Mirv> t1mp: promoted, I guess? I tend to always test on latest image, promoted or not. but yes, I can see how that could happen.
<Mirv> t1mp: generally our non-promoted images are in good enough shape too that one can compare own results to those (seen at http://reports.qa.ubuntu.com/smokeng/trusty/touch/ - usually close to 100%)
<t1mp> Mirv: yes promoted (250). In newer images at least messaging-app tests were failing so I couldn't get 100% OK
<Mirv> t1mp: yeah you can't get better results than on the dashboard if it's some other component breaking the tests
<t1mp> Mirv: yes, *close* to 100%. But is "close" good enough to top-approve an MR? That's the question. It is not difficult to top-approve it, but do we want to run the risk?
* asac changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | on topic: support/discussion on everything CI approach, engine, operations/services (incl. landings and system image tests etc.) | Vanguard: cjohnston | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<Mirv> t1mp: if you see no regressions compared to dashboard results, then it should be (almost) as good as 100%. but whenever dashboard is not 100%, it makes of course trusting one's own results harder in the case of those specific packages having AP errors.
<sergiusens> asac, this package-autopilot depends on package (= $Version) means that in the image test that you run, if you don't make sure that the package is not brought in as a dependency update you aren't really testing the latest image
 * sergiusens had just thought of that
<Mirv> t1mp: at least I've kept the dashboard as the meter of "100%", ie something that needs to be equalled
<asac> sergiusens: so you say we still ship a deb to pull in test deopendencies?
<asac> i just wondered this morning how that works in click case
<asac> e.g. expressing your runtime/test requirements
<sergiusens> asac, in click it's much fancier (and in contradiction to the ci train which came later)
<sergiusens> asac, when a package lands to trunk, it's revno and branch used to build the click are annotated in the manifest
<asac> sergiusens: so how does click express what needs to be put on image for testing?
<t1mp> sergiusens, asac ok I try with the click tests and contact one of the people for the autopilot deb tests
<t1mp> thansk
<t1mp> *thanks
<sergiusens> asac, so when you want to pull the tests for any click on any image, it will grab the branch, take the tests and push it into the device
<t1mp> thostr_: how did a ubuntu-ui-toolkit MR end up in this silo? https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=27
<t1mp> thostr_: it has not even been reviewed by someone in the SDK team yet
<asac> sergiusens: right, but how do you express "i also need mock backend XYZ from archive?"
<sergiusens> asac, you don't
<didrocks> sil2100: did you ask on another core-dev for a packaging ack?
<sergiusens> asac, clicks definition is to have everything in the bundle; no apt get allowed
<thostr_> t1mp: are you saying neither james nor Satoris contacted you on this?
<sil2100> didrocks: yes, but no answer so far ;) Poked ogra_ and cyphermox, but both seem to be busy!
<sergiusens> asac, if you apt-get, you risk modifying the image enough to not be sure you are testing what you want to test
<asac> sergiusens: right. so in case of the messaging/dialer app will we ship the mock backends as part of click?
<t1mp> thostr_: no, not that I am aware of. There is no approval from an sdk-team member in the MR, and it has not been top-approved yet
<sergiusens> asac, I'll leave that to the QA team, I asked too many times for them to architecture their solutions with click in mind
<seb128> thostr_, you should avoid listing/landing non reviewed/approved mps as an usual rule (getting them in a silo for testing is fine, landing them is not)
<asac> right
<asac> we want the checklist to be used :)
<seb128> thostr_, it's not the first time your landing have some unreviewed code included
<didrocks> sil2100: +1 on thumbnailer
<asac> sergiusens: yay thats evil :P
<thostr_> seb128: yes, I know :(
<sergiusens> asac, I actually really tired of playing catch up and being ignored
<sergiusens> asac, that's why the gallery took so long to land; testing
<didrocks> sil2100: +1 on toolkit, please remind me to promote the new binary package to main
<seb128> didrocks, was it ever discussed to make CI land (in sense of upload to the archive) only if the includes mps are status approved?
<didrocks> seb128: it was, but the fundation team has a special workflow which involve to never approving mps
<didrocks> seb128: and I don't want to special case on a per project basis
<ogra_> sil2100, oh, sorry, yeah. day is full of meetings for me
<seb128> didrocks, oh, right, they do release and have 1 mp which is basically "merge the content of the release" back
<asac> sergiusens: yeah i can understand. i think the problem is really that this click topic is not really owned by anyone for real
<ogra_> didrocks, didnt you say above you had queued a new image build ?
<asac> the overall click topic
<didrocks> ogra_: I had, why?
<asac> maybe foundations should take on driving the COMPLETE story
<didrocks> seb128: right
<seb128> didrocks, thanks
<didrocks> ogra_: the request was ignored?
<ogra_> didrocks, because there wasnt any after 259
<didrocks> yw :)
<didrocks> maybe the webui is buggy?
<ogra_> might be
<thostr_> sil2100: can you hold back silo 9 from landing (stuck anyway)
<didrocks> it was clearly letting me add one and then the ui was "rebuilding)
<seb128> didrocks, what about refusing to land but having a checkbox to force? ;-)
<didrocks> seb128: enough checkbox
<didrocks> or people will always use it
<asac> sergiusens: the idea is that we only publish MPs that follow the checklist etc.
<didrocks> and will complain about the tool :p
<asac> seb128: ^^
<asac> sorry sergio, wrong
<sil2100> didrocks: thanks!
<asac> seb128: landing team is suppposed to take samples and if folks dont follow help upstreams to fix their process
<sil2100> thostr_: you want to free up the silo?
<asac> and look closer for those components the next few times
<seb128> asac, right, the theory and what happens in practice diverge though
<asac> seb128: didrocks says his team has no time to quickly look at the MPs to see if they filled out a checklist
<seb128> asac, they shouldn't
<thostr_> sil2100: no, just wait couple of minutes first... I'll ping you in couple of minutes
<asac> seb128: someone needs to control
<seb128> they are not there to watch the universe
<asac> seb128: well, they are the ones that get a ping, so they are the best to take a look
<asac> because they already have a trigger
<seb128> or you need to trust people
<asac> upstreams shouldn't fail
<asac> seb128: right, the reason we implemented it this way was that upstream managers asked for help
<seb128> well, they shouldn't get a ping either :p
<sil2100> thostr_: ok :)
<asac> seb128: they couldnt enforce MP practices
<asac> seb128: hence having the opportuntiy of an independent team quickly looking and blocking was perceived as very welcome
<seb128> well, the system can enforce those for you (or at least help to catch errors)
<seb128> right
<seb128> it's welcome for those who get the reviews
<seb128> not for those who have to review the universe for others
<asac> its not that much imo
<sergiusens> asac, the click thing is a ci thing most likely and there are bugs open
<seb128> asac, it's probably worth some hours of work a day, when your days are already packaged that's starting being much
<asac> seb128: no its a matter of 2 minutes for each landing
<asac> seb128: you open aall MPs, quickly eyeball if there is checklist pattern
<asac> otherwise bounce it back
<asac> seb128: and we dont need to do it for every landing
<asac> seb128: just take random sample
<asac> like run "should-i-look"
<seb128> right
<asac> that spits out yes for every 190th
<seb128> it's a bit orthogonal
<asac> and then if you find something you feed back and ensure that this component doesnt land :)
<seb128> it doesn't prevent us to helping people be noticed about potential errors in an automatic way
<seb128> e.g "your landing include non approved changes"
<seb128> noticed->notified
<asac> seb128: well, then lander should really look at his MPs
<asac> hence its just putting up that there might be checks
<seb128> they should
<asac> so they dont go lax
<asac> if you know there will never be alcohol checks on streets
<asac> you start not caring about that :)
<asac> but the fact that you might get busted helps - even if super unlikely
<didrocks> thostr_: so, oyu don't want us to publish 009?
<didrocks> thostr_: testing was set to yes though and it's blokcing the ui toolkit that we need for unity8
<thostr_> didrocks: no, wait until we get the MP also fully approved from sdk guys
<asac> seb128: having a convenience tool that opens all URLs in the landing silo so you can quickly skim through would be nice
<asac> but more automation we really dont need imo. its about establishing review practies
<asac> after all :)
<seb128> asac, I think it's the wrong approach here though, people should do the right thing because it's their job and they care about what they are doing, not because they want to avoid public shaming or something :p
<didrocks> thostr_: ah, so it's not a rebuild/test issue, can you ensure next time it's approved first so that we are not into that situation?
<asac> and the review is manual anyway :)
<thostr_> didrocks: if we get a quick review from sdk guys we can go forward
<didrocks> ok
<asac> seb128: its not about shaming
<asac> seb128: its about helping people to not go lax
<thostr_> didrocks: I'll... was assuming james/Satoris had it gotten reviewed by now
<asac> :)
<didrocks> thostr_: no worry, keep us posted
<asac> seb128: i assume good faith in anyway. everyone wants to do that if you ask them up front
<asac> seb128: but then during battle etc. they might just dismiss their principles
<thostr_> didrocks: can you go forward without silo9 for unity8 right now?
<asac> and thats where another instance can help by reminding, helping them to not shoot themselves etc.
<asac> and saying NO :)
<thostr_> didrocks: then we review first and get it in after unity8
<seb128> asac, well, I think some of those are honest overlook and the tool could easily ask you for confirmation when it stops an overlook
<seb128> when it spots*
<asac> seb128: i dont think its really an overlook, its a priority
<asac> and then forgetting etc.
<didrocks> thostr_: I guess we need both (with the toolkit), but I guess you have ~30 minutes as Saviq is on a crasher that I'm sure he want to sneak a fix in
<asac> if you land without having reviewed the MP you are doing something serioyusly wrong
<Saviq> didrocks, I can't even repro your crash
<asac> if we give them a tool to bless those MPs we send the wrong signal. every MP needs to be carefully reviewed by lander before adding
<Saviq> didrocks, so don't hold your breath
<didrocks> Saviq: but multiple people can, and the stacktrace doesn't give you any hint?
<Saviq> didrocks, not really, everything's in Qt
<didrocks> argh
<fginther> t1mp, sergiusens, I've read the backlog but may still be missing some context. It sounds like there is a general issue of getting the right version of autopilot packages installed for local testing?
<Saviq> didrocks, and please ask the multiple people that you know to report their steps to repro
<t1mp> fginther: yes, I think that is the problem
<t1mp> fginther: I can get the latest versions of everything, but the latest version does not mean that all tests will pass. I only know that all tests should pass for the latest promoted image
<sergiusens> fginther, yeah, it's not possible to get the tests for the latest devel image
<t1mp> fginther: I need an image with all the autopilot tests installed on my device for which I know that without changes I get 100% OK on the tests
<t1mp> fginther: with that, I can then install the debs from the MR and see if still 100% is OK
<fginther> t1mp, so it sounds like what you need is a way to start with the last promoted image, and then install just your MR debs on to it?
<t1mp> fginther: no, the promoted image does not include the autopilot tests
<t1mp> fginther: so if the last promoted image included all the autopilot tests and all the apps+tests that we need to test, then that would be enough
<didrocks> davmor2: popey: can you try to answer Saviq's request?
<didrocks> davmor2: popey: on bug #1297240
<ubot5> bug 1297240 in unity8 (Ubuntu) "unity8 crashed with SIGSEGV in QQuickWindowPrivate::polishItems()" [High,New] https://launchpad.net/bugs/1297240
<t1mp> fginther: if you meant the last promoted image including the apps+tests, then the answer is yes :)
<davmor2> didrocks: in  a call then Lunch then I can
<fginther> t1mp, doesn't phablet-click-test-setup install the tests that match the click packages in the image?
<fginther> t1mp, at least for the click apps?
<didrocks> ogra_: so repushed the buttonâ¦
<ogra_> good
<popey> didrocks: i haven't reproduced that yet
<t1mp> fginther: I have to check that, but lets assume it does. Then still I need to get the AP tests for messaging-app, unity8, system-settings, ...
<didrocks> ogra_: hum http://ci.ubuntu.com/smokeng/trusty/touch/mako/260:20140325.2:20140304/7371/
<didrocks> ogra_: I do see 260
<ogra_> weird
<didrocks> and the number matches
<ogra_> i didnt see it build
<didrocks> argh
<ogra_> heh
<fginther> t1mp, ok, so there is still anything deb based that would be missing...
<didrocks> ogra_: anyway to kill the build?
<ogra_> didrocks, nope
<t1mp> fginther: yes
<fginther> t1mp, I'm starting to see the full picture, thanks for filling in my gaps
<didrocks> ogra_: so, we are getting a void image again :p
<didrocks> I guess that's ok
<ogra_> yeah :/
<didrocks> as long as 260 is testing
<didrocks> which it is now
<didrocks> ogra_: can you poke your script?
<didrocks> ogra_: I want the image diff!
<sil2100> ;p
<t1mp> fginther: if I install image 250, I cannot get the matching AP tests for the deb-based packages that are installed. I think they are just no longer available in the archives because there are newer packages already. Is that correct?
<didrocks> t1mp: launchpad has them
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/260.changes
<ogra_> didrocks, ^^^^
<didrocks> ogra_: \o/
<ogra_> |HELP
<imgbot> I am the firendly image watchbot
<ogra_> hmm, bot is still there
<fginther> t1mp, I suppose a trivial solution would be to archive all of the debs that were installed when image 250 was tested
<ogra_> i guess it got confused with the overlapping builds
<didrocks> ogra_: if we do a revert of my revert, we will get something like 12.10.2+14.04.20140325.12.10.2+14.04.20140324.is.12.10.2+14.04.20140320-0ubuntu1 like tomorrow :p
<ogra_> haha
<t1mp> fginther: it is not trivial for me, but if you can do that, as far as I can anticipate now, it would solve the problems
<t1mp> didrocks: is there an easy (not time-consuming) way to get them from launchpad?
<fginther> t1mp, ok, I'm not saying that's to solution, but it would perhaps provide the raw materials for one
<t1mp> fginther: it would at least give us something to work with now so that we can approve MRs with confidence that at least there was a promoted image where the tests passed
<davmor2> popey, cyphermox: can I get a confirm on https://bugs.launchpad.net/ubuntu/+source/mtp/+bug/1297301
<ubot5> Ubuntu bug 1297301 in mtp (Ubuntu) "Phone shows in rhythmbox but display unknown on all tracks" [Medium,New]
<cyphermox> done
<didrocks> t1mp: you need to go to https://launchpad.net/ubuntu/trusty/+source/<packagename>, click on the version you need
<popey> davmor2: confirmed
<davmor2> popey: ta
<didrocks> t1mp: and then, find the maching in arch all "autopilot" package
<davmor2> cyphermox: ta
<didrocks> davmor2: do we know when this regression started? was this already in latest promoted image?
<t1mp> fginther: if it is possible to store the image that was used for testing (including the installed click packages and all tests) that we could re-use for testing then that would make it even easier
<t1mp> fginther: so an image that includes all the tests
<fginther> t1mp, right, a testing image snapshot
<didrocks> t1mp: it's what is planned with the airline FYI
<davmor2> didrocks: that has possibly been around for ever but is more noticeable now that mtp is more reliable
<t1mp> fginther: exactly, that would be awesome :)
<t1mp> didrocks: cool :)
<didrocks> davmor2: ah ok :)
<t1mp> didrocks: but I'm trying to find a solution for now. We have like 30 MRs pending, and manually searching all the autopilot debs for each package to test sounds like very time-consuming
<imgbot> === trainguard: IMAGE 261 building (started: 20140325-13:55) ===
<davmor2> ogra_: what happen to 260 /me shakes his fist at imgbot
<didrocks> t1mp: the manual way is the only way I know of which is achievable as of today
<ogra_> davmor2, the builds kind of overlapped
<ogra_> davmor2, 260 is there but the bot missed it
<fginther> t1mp, asac, what is the kaleo script that was mentioned?
<davmor2> ogra_: you saying that you didn't prep the imgbot for being hammer by 3 images landing at once ;)
<t1mp> fginther: https://code.launchpad.net/~fboucault/+junk/ciathome
<asac> fginther: a convenience script so that sdk folks can run all AP tests locally/easily
<asac> t1mp beat me
<asac> :)
<ogra_> davmor2, well, it watches for the build command and stores the PID ... if a buiuld runs with the same PID for some reason it doesnt notice that this is a new build ... i guess i need to review that concept
<t1mp> fginther: I am using it with these changes: http://pastebin.ubuntu.com/7151299/
<thostr_> didrocks: sil2100: invalidate silo 9 for now... obviously no quick way to get the approved from sdk guys
<sil2100> thostr_: ok, so freeing up that silo then
<fginther> t1mp, thanks
<sil2100> thostr_: give us a sign once it can be set-up again
<sil2100> thostr_: wait, silo 9?
<sil2100> Crap...
<sil2100> thostr_: the problem is, when you poked me earlier, I already published silo 9
<thostr_> sil2100: yes, that was the one I said I'll clarify the situation for a couple of minutes ago
<thostr_> sil2100: yes, but it's stuck
<sil2100> thostr_: UITK and thumbnailer are stuck, but mediascanner2 is in -proposed already
<sil2100> So hm, it would be a half landing, not sure if we can easily remove something from proposed now
<sil2100> didrocks: ^ :(
<thostr_> sil2100: half landing here is not good at all
<ogra_> asac, didrocks, do we have any plans for the final weeks of the release and how we handle landings yet ?
<ogra_> i guess that would deserve a mail with the planning to the ML
<didrocks> thostr_: well, if half landing doesn't work, your packaging is there to block mediascanner2 in proposed, right?
<ogra_> (how do we go forward while the rest of the world is frozen)
<sil2100> cjwatson: hi! So, it seems we have a package version in -proposed that we wouldn't want to enter the release archive - can it be removed somehow easily?
<thostr_> didrocks: I'd hope so... let me double check
<sergiusens> fginther, t1mp fwiw, you can get the click tests for any released image you want
<sergiusens> without going into r/w
<fginther> sergiusens, thanks, that what I thought. The missing piece appears to be anything still installed via debs (like unity8-autopilot)
<sergiusens> fginther, yeah, the thought was to have that preinstalled
<thostr_> didrocks: sil2100: partial landing doesn't screw up anything, so we're safe there
<didrocks> thostr_: ok, if we free silo, you need to push the mediascanner branch yourself
<thostr_> didrocks: wait, I thought those have fully landed now (except uitk)?
<ogra_> sergiusens, the plan was to get rid of autopilot on the image eventually :P
<didrocks> thostr_: mediascanner will, not thumbnailer and uitk
<didrocks> thostr_: they are both blocked on beta freeze
<didrocks> thostr_: so, I can kick thumbnailer and uitk out
<didrocks> so that they will never hit the proposed (nor release) pocket
<didrocks> do you want that?
<thostr_> didrocks: yes, kick those out. everything still save
<didrocks> thostr_: ok, so only mediascanner2 will reach the release pocket
<thostr_> didrocks: yes, that's ok
<sil2100> ok
<didrocks> thostr_: you need to push the new trunk manually as we are going to free the silo
<sil2100> Phew
<didrocks> thostr_: publication gives you a hint where those branches are: http://162.213.34.102/job/landing-009-2-publish/35/console
<didrocks> 2014-03-25 13:35:14,486 INFO Pushing mediascanner2 to lp:~ps-jenkins/mediascanner2/trusty-proposed
<didrocks> thostr_: so, just bzr pull/bzr push to trunk
<sil2100> thostr_: so, we'll do the m&c, you just need to manually push this branch to your trunk
<sil2100> thostr_: as we'll do a m&c without merging in the changes to bzr branches
<didrocks> and uitk/thumbnailer flushed
<sil2100> didrocks: thanks!
<sil2100> I do the m&c then
<sil2100> didrocks: even after the m&c, the trusty-proposed branches still stay, right?
<sil2100> They're not removed in the onlyfreesilo case?
<didrocks> sil2100: yep :)
<sil2100> Awesome :)
<didrocks> we keep it for that
<didrocks> and always bzr push --overwrite
<thostr_> didrocks: should be done now
<didrocks> thostr_: looks perfect!
<cjwatson> sil2100: ask on #ubuntu-release if this hasn't been resolved - I'm on vacation this afternoon
<sil2100> cjwatson: ok, thanks ;) It's all resolved already
<sil2100> Phew \o/
<ogra_> cjwatson, didnt you say that 1h ago in -installer already ? go away !
<ogra_> :)
<Chipaca> does anybody know offhand what could cause dh-exec to not get called? I'm having a package ftb because it's not getting exec'ed
<Chipaca> (that is: I have an executable .install file, with #!/usr/bin/dh-exec, with a => pattern, that fails)
<didrocks> can't wait to have dialer-app and messaging-app test result: http://ci.ubuntu.com/smokeng/trusty/touch/mako/260:20140325.2:20140304/7371/
<didrocks> Chipaca: is it executable?
<cjwatson> Chipaca: make sure it's a 3.0 format source otherwise the exec bit isn't preserved
<ogra_> didrocks, 261 will most likely step on your toes here
<Chipaca> didrocks: yes
<Chipaca> cjohnston: hm!
<didrocks> ogra_: 260 will finish first
<Chipaca> cjwatson: that's the one! :)
<cjwatson> ogra_: I wish people would stop policing.  I was just dropping in to ask a question on a non-work channel
<ogra_> now thats confidence
 * Chipaca hopes and tries
<ogra_> cjwatson, sorry
<Chipaca> what're "debian native" packages?
 * Chipaca looks it up
<Chipaca> ok
<ogra_> Chipaca, packages that contain the debian/ dir in their source
<Chipaca> ogra_: but if i have .bzr-builddeb with split=true, that means the source as far as ubuntu is concerned is non-native, yes?
<ogra_> (usually you have an orig.tar.gz with the upstream code plus everyhing thats in the debian/ dir i.e. distro patches ... native packages have that in one tarball)
<ogra_> i think thats true, yes
<sergiusens> ogra_, no, they are using bzr split deb
<sergiusens> Chipaca, you shouldn't be native
<ogra_> oh, ok
<Chipaca> so 3.0 (quilt) it is
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: wazn being rebooted
<t1mp> thostr_: does this 15:06:23 < sergiusens> fginther, t1mp fwiw, you can get the click tests for any released image you want
<t1mp> epaste
<t1mp> sergiusens: ^ thanks for the hint. In our testing scripts we are still using some debs where we can use clicks, so for that part of the tests we can solve the testing problems by using click packages instead
<t1mp> fginther: do you have an idea for a (temporary?) solution for the deb AP packages?
<fginther> t1mp, it's possible to follow the chain from https://launchpad.net/ubuntu/trusty/+source/<source_package> and and get to the deb file that corresponds to a specific version
<fginther> t1mp, so assuming you have the version installed for unity8, you can find the deb file for unity8-autopilot
<fginther> t1mp, I don't have a better solution then that at the moment
<bregma> Chipaca, if you run into grief using 3.0 (quilt) in a bzr split deb (and I expect you will), try using a .maintscript file instead of an executable .install file (see dpkg-maintscript-helper(1))
<Chipaca> bregma: so far grief has been due to my rusty packaging skillz, but I'll remember (or rather, my xchatlog will ;-) )
<bregma> been there, done that, got the commit logs to prove it
<Chipaca> sergiusens: https://code.launchpad.net/~chipaca/ubuntu-push/bring-back-the-good-old-days-of-yore/+merge/212631 plz?
<popey> davmor2: can you confirm bug 1297334
<ubot5> bug 1297334 in unity8 (Ubuntu) "Text on music is sometimes unreadable." [Undecided,New] https://launchpad.net/bugs/1297334
<popey> ?
<davmor2> popey: I'll check
<popey> ta
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<sergiusens> Chipaca, ack
<sergiusens> Chipaca, http://162.213.34.102/job/landing-012-1-build/40/console
<Chipaca> doom doom doom
<Chipaca> :)
* doanac changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: doanac | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<cjwatson> Chipaca: you could also chmod +x the .install file in debian/rules
<cjwatson> (if you aren't already sorted)
<cjwatson> that's a perfectly reasonable old-style belt-and-braces technique
<Chipaca> cjwatson: it was +x'ed, but because I'd been asked to remove source/format, it had stopped getting poked at
<cjwatson> Chipaca: I mean at build time
<Chipaca> ah!
<Chipaca> lulz
<cjwatson> e.g. right before dh_install
<cjwatson> in an override_dh_install rule or whatever
<Chipaca> cjwatson: good point. I'm overriding dh_install already, so it'd be trivial to do
<imgbot> === trainguard: IMAGE 261 DONE (finished: 20140325-15:20) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/261.changes ===
<Chipaca> now the package's gotten through the jenkins, what happens?
<didrocks> bfiller: boiko: dialer-app at 100% back \o/
<sil2100> ;)
<didrocks> bfiller: boiko: messaging-app running as we speak
<sil2100> I wouldn't expect anything else!
<bfiller> didrocks: excellent
<boiko> \o/
<t1mp> where can I find the scripts that run to generate these test results? http://ci.ubuntu.com/smokeng/trusty/touch/
<t1mp> doanac, plars ^
<plars> t1mp: you mean to run the tests right?
<t1mp> plars: yes
<doanac> t1mp: lp:ubuntu-test-cases/touch, https://code.launchpad.net/ubuntu-test-cases/touch
<plars> t1mp: ^that :)
<t1mp> plars: I think the script that we are using in the sdk team is not optimal ;)
<t1mp> doanac: thanks
<plars> t1mp: it's pretty easy to use, if you want to use the run-smoke script, it'll do it all in one go and even provision for you
<plars> t1mp: or you can run the individual pieces
<plars> t1mp: let me know if you need any help getting it up and running
<plars> t1mp: the main thing is that you'll need to set NETWORK_FILE to the path of your nm profile
<plars> t1mp: that's pretty much the only thing that needs to be customized depending on your environment
<t1mp> plars: what I want to do is run the autopilot tests for all the apps  to see if they are OK
<t1mp> plars: but after installing the deb's that jenkins created for an MR
<t1mp> plars: so basically I want to do the same as these smoke tests, except I want to do it before approving an MR
<plars> t1mp: all the apps? or just certain ones?
<t1mp> plars: all
<plars> t1mp: be aware the full run takes quite a bit of time
<plars> ok
<t1mp> plars: about 2 hours ;)
<t1mp> on my nexus4
<t1mp> I think, may be even more, I'm not using a stopwatch :)
<t1mp> plars: will the scriipt also install the latest (or promoted?) image and the click packages+autopilot tests?
<plars> t1mp: yes
<t1mp> plars: oh cool. We were using this https://code.launchpad.net/~fboucault/+junk/ciathome but that has some issues
<t1mp> and it installs a bunch of apps with apt-get, while those apps are now clickified ;)
<t1mp> kalikiana: ^ there is another script
<plars> t1mp: yeah, our stuff only installs packages for non-click autopilot packages. For the click packages it uses phablet-click-test-setup to get the appropriate branches. Also, any packages installed for testing are uninstalled before the next test is started
<t1mp> plars: what's the default location of my network manager profile?
<t1mp> plars: can the script take my system nm profile to copy to device?
<plars> t1mp: /etc/NetworkManager/system-connections is where they are located by default. Copy the one you want it to use to somewhere you can point it easily
<didrocks> bfiller: boiko: and messaging-app AP tests passing \o/ well done guys :)
<plars> t1mp: well, since this is normally intended to run on a server that's not using a wireless profile, it doesn't try to default to what you are already using
<bfiller> didrocks: sorry it was broken in the first place, was unfortunate. boiko thanks for fixing so quickly
<kalikiana> plars: is it feasible to take the script and run it locally to test a given merge request?
<t1mp> plars: so this should be good: ./provision.sh -n /home/tim/network-manager-conf
<didrocks> bfiller: well, it was tricky, with the SIM card inâ¦
<t1mp> wow we are at 261 already
<t1mp> there is a new image every hour :)
<sil2100> ;)
<t1mp> plars: is there a way to run *all* tests without passing them all individually via -a ?
<plars> t1mp: sure, just set TESTS=all APPS=all
<plars> t1mp: for the non-autopilot stuff, you'll also need to install utah on your system from ppa:utah/daily
<t1mp> plars: what is the non-autopilot stuff?
<t1mp> I thought all apps are tested with autopilot
<plars> kalikiana: not really set up to handle merge requests directly, you could possibly do something by either setting it up by hand and just running the tests rather than having it provision, or maybe build your packages in a ppa and have it use that ppa (you'll need to specify the packages to build)
<plars> kalikiana: for the mr stuff, fginther is the expert - and he has other scripts that handle those tests
<t1mp> plars: testing for an MR is exactly what I am going to try to do with it
<plars> t1mp: there are the systemsettle tests, some default smoke tests, security, sdk, and things like that - things that don't have a ui to test with ap
<t1mp> plars: when we propose an MR, jenkins runs CI and creates a zip-file with deb packages in it that has the changes of the MR
<t1mp> plars: so what I was thinking is to simply install those debs and the run all the AP tests using your script
<plars> t1mp: that's the process I mentioned a few lines up, and is different from the smoke tests that run against images
<t1mp> plars: the main goal is to verify that the changes in UITK don't break anything in the apps (or at least in the apps autopilot tests)
<fginther> t1mp, kalikiana, I'm working on changes to lp:ubuntu-test-cases/touch (or a branch) to specifically test MRs
<plars> t1mp: that should work ok, just you'll want to run it with jenkins.sh rather than run-smoke so that it doesn't provision
<plars> t1mp: you should provision with provision.sh though (see the help on it)
<t1mp> plars: I already provisioned, or waiting for it to finish after flashing the new image
<plars> t1mp: fginther has it pretty close I think, but this part was explicitly designed for image testing not mr testing. So fginther is doing some things to make it usable for both
<t1mp> fginther: that's great :) how is the progress so far?
<t1mp> fginther: tell us if you need anything from us, we are quite eager to get this working
<fginther> t1mp, it's close to being usable as a replacement for the tests we're currently running in CI for MPs. It's goals are probably slightly different then your as I wasn't specifically attempting to run all tests
<t1mp> plars, fginther one question, are you always using the latest proposed image for testing? it may have (known) failing tests
<fginther> but that may be an easy thing to add
<fginther> t1mp, yes, the MP testing currently uses the latest proposed.
<t1mp> fginther: currently when we propose an MR, I don't think jenkins runs autopilot tests, right?
<plars> t1mp: you can specify the image, for image smoke testing we are always testing latest
<t1mp> fginther: for UITK, it runs the unit tests only as far as I know
<t1mp> plars: ok
<fginther> t1mp, if you're referring to ubuntu-ui-toolkit, only the uitk ap tests are executed.
<fginther> t1mp, the infrastructure should support adding additional tests as parameters
<t1mp> fginther: ok. we need to run all app autopilot tests to be sure nothing breaks
<t1mp> fginther: but I don't know if that is feasible on jenkins, that's why we are running it at home on our own devices
<fginther> t1mp, I'll look at adding it. My initial concern is that we don't have enough hardware to run all the tests for every MP, but I'll need to collect some data to know for sure
<t1mp> ok provision.sh finished
<davmor2> didrocks: okay so I don't seem to be able to reproduce the crash so I wonder if it is something that happens only after an update and it is doing the initial data check or something?
<t1mp> fginther: true. and running all the tests will make it last at least 90m longer before we get results
<t1mp> so I have this MR: https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/optIn-newHeader/+merge/208662
<t1mp> jenkins CI was succesfull and it created deb packages here: http://jenkins.qa.ubuntu.com/job/ubuntu-ui-toolkit-trusty-armhf-ci/892/artifact/work/output/*zip*/output.zip
<t1mp> I'll download&unzip&dpkg -i those on the device
<t1mp> what do I run afterwards so that all tests are executed?
<t1mp> hmm.. provision.sh didn't install the AP tests for deb packages? for example unity8-autopilot is not there
 * t1mp gotta go, bbl
<davmor2> didrocks, kenvandine, Saviq: https://bugs.launchpad.net/ubuntu/+source/address-book-app/+bug/1297388  I've assigned it to address book app as ken is saying that content hub has done it's bit.
<ubot5> Ubuntu bug 1297388 in address-book-app (Ubuntu) "unable to add an image to a contact" [Undecided,New]
<kenvandine> bfiller, ^^
<bfiller> davmor2: this is a dupe, i;ll mark it as such. already fixed in the silo
<kgunn> cyphermox: hiya, can i get a reconfig on silo 4 ?
<davmor2> bfiller: awesome I just couldn't find a bug for it when I searched :)
<bfiller> davmor2: https://bugs.launchpad.net/address-book-app/+bug/1295725
<ubot5> Ubuntu bug 1295725 in address-book-app "contact picture disappears" [Critical,In progress]
<davmor2> bfiller: sweet thanks didrocks ^ use that bug instead :)
<kenvandine> bfiller,  my gallery-app branch never got marked as merged, but it looks like it is merged
<davmor2> kenvandine: it's just out to blag your head ;)
<cyphermox> kgunn: sure
<Saviq> cyphermox, can you please kick https://launchpad.net/~ci-train-ppa-service/+archive/landing-008/+build/5848957 for us, the dependency got built in the mean time
<sil2100> didrocks: packaging ACK needed! http://162.213.34.102/job/landing-001-2-publish/lastSuccessfulBuild/artifact/packaging_changes_libcolumbus_1.1.0+14.04.20140325-0ubuntu1.diff <- symbols file added, looking nice, using the export symbols map to get rid of symbols leaking from source
<didrocks> sil2100: in meetings, please ask another core dev
<sil2100> didrocks: ACK
<davmor2> didrocks: black screen on media player actually causes a crash https://bugs.launchpad.net/ubuntu/+source/mediaplayer-app/+bug/1297395
<ubot5> Error: ubuntu bug 1297395 not found
<Saviq> sil2100, kick the unity8 build above please ââ?
<sil2100> cyphermox: do you have another free moment for a packaging ACK?
<sil2100> Saviq: k
<Saviq> sil2100, actually it's building already :D
<sil2100> Oh, it's kicked
<Saviq> late refresh...
<davmor2> didrocks: no public so should be accessible
<cyphermox> sil2100: yeah
<davmor2> s/no/now
<sil2100> cyphermox: http://162.213.34.102/job/landing-001-2-publish/lastSuccessfulBuild/artifact/packaging_changes_libcolumbus_1.1.0+14.04.20140325-0ubuntu1.diff <- as mentioned before, symbols file added, looking nice,using the export symbols map to get rid of symbols leaking from source
<cyphermox> sil2100: NAK. It changes a previous changelog entry; see the second hunk for debian/changelog
<didrocks> bfiller: would you be available on the landing meeting to discuss those issues? ^
<didrocks> davmor2: ^
<didrocks> (sorry, in meeting, hard to track for me)
<sil2100> cyphermox: hm, right, not sure why the bot did that, we already published something that did something similar, I wonder what's up
<plars> sergiusens: ubuntu-device-flash doesn't seem to reboot to the bootloader when you specify --bootloader, which I guess probably also means it won't detect the device type. Is there any reason why?
<plars> sergiusens: or am I missing a magic flag to make it do that?
<bfiller> didrocks: on a meeting that will conflict so can't make it
<bfiller> didrocks: address book app is a regression, not critical imo as you can still set the picture - it just blanks but is actually still there
<sil2100> cyphermox: yeah, so, it happened already for unity-scopes-api and it got approved by a core-dev, probably it's not a good thing but anyway
<bfiller> didrocks: it's been fixed with line 18 on the sheet which is in testing
<bfiller> (along with other fixes)
<cyphermox> sil2100: it's very very bad
<sil2100> cyphermox: will look into the citrain code why that's happening and poke Didier on the meeting
<cyphermox> I'm hungry
<didrocks> bfiller: thanks!
<didrocks> ogra_: coming?
<didrocks> so fast :p
<ogra_> no :P
<davmor2> ogra_: http://weirdscaryandusualstuff.tumblr.com/post/884597811/finger-stretcher-for-the-aspiring-pianist-hailing
<davmor2> didrocks: I hit this too so I don't know if it is linked to yours or caused by the mediaplayer crash https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1297410
<ubot5> Error: ubuntu bug 1297410 not found
<ogra_> davmor2, well, i thought more about that "enlargement" SPAM ...
<davmor2> ogra_: no real stuff :)
<ogra_> davmor2, there are sometimes devices offered that are real stuff too :)
<popey> davmor2: Go to Scopes scope, tap grooveshark, tap a song (I chose Get Lucky by Daft Punk), click Play in Grooveshark, click "Play" button in the browser. Note the audio level is much lower than the native music app.
<davmor2> sil2100: https://bugs.launchpad.net/address-book-app/+bug/1295725 is the line you are looking for
<ubot5> Ubuntu bug 1295725 in address-book-app "contact picture disappears" [Critical,In progress]
<davmor2> popey: https://bugs.launchpad.net/ubuntu/+source/mediaplayer-app/+bug/1297395
<ubot5> Ubuntu bug 1297395 in mediaplayer-app (Ubuntu) "mediaplayer-app crashed with SIGABRT in __libc_do_syscall()" [Medium,New]
<popey> ta
<ogra_> popey, while i see you saying grooveshark, do you know who is responsible for these pieces ? in germany grooveshark is completely blocked i wonder if we shouldnt hide scopes you cant use in a country
<ogra_> based on language or location selection
<popey> good question!
<popey> Saviq: ?
<davmor2> popey: so grooveshark is working for me.
<popey> works here too
<popey> but audio level is low
<popey> lower than music app or preview in scope
<popey> bug 1297420
<ubot5> bug 1297420 in webbrowser-app (Ubuntu) "Audio playback level is lower than native apps." [Undecided,New] https://launchpad.net/bugs/1297420
<cyphermox> kgunn: what part have you changed for silo 4?
<davmor2> popey: stay on the call
<popey> kk
<thostr_> sil2100: what do I need to do on silo1?
<plars> sergiusens: if you replied I missed it, sorry. I had a power outage here
<didrocks> balloons: you're not coming to the landing team meeting anymore?
<sergiusens> plars, no, I saw you disconnect and waited,
<sergiusens> plars, that info was in the email discussion with doanac; fwiw device autodetection works from fastboot
<sergiusens> plars, I can add a --from-adb flag to the cli if you want; but wanted to avoid it being automatic for people not to mix a bootstrap from a wipe
<sergiusens> a wipe just adds format data to the ubuntu commands
<sergiusens> a bootstrap flashes more that what the system image updater would do and also cleans up much more
<balloons> didrocks, sorry, not used to the new time and been a bit distracted. But yes I still plan on being there
<plars> sergiusens: oh ok, so I could just adb reboot bootloader, wait a few seconds, and run u-d-f with --bootstrap and it should work?
<t1mp> plars:
<t1mp> tim@ideapad:~/dev/touch/scripts$ TESTS=all APPS=all ./run-autopilot-tests.sh
<t1mp> plars: ^ I think that didn't run any autopilot tests
<sergiusens> plars, no need to wait
<plars> sergiusens: does --wipe add anything useful when you are already using --bootloader?
<sergiusens> plars, ubuntu-device-flash will wait appropriately
<t1mp> plars: http://pastebin.ubuntu.com/7152306/ at least I don't see autopilot logs
<plars> t1mp: eh, yeah I think those only work if you are using run-smoke
<sergiusens> plars, --bootstrap? no; it's the other way around :-)
<t1mp> plars: test_results.xml http://paste.ubuntu.com/7152310/ or should I make the image writable manually?
<dbarth> sil2100 or robru: we finished testing silo 002 (both phone ande desktop mostly): can you publish?
<plars> sergiusens: not sure I understand, let me rephrase... so I want --bootstrap so that I get the new  bootloader (if any), but there would be nothing more done if I added --wipe on top of that right?
<robru> dbarth, it's just oxide-prep right? doesn't actually bring in oxide right now?
<plars> t1mp: if you use provision, it will do all the extra setup steps required like making it writable (if you use -w) and running phablet-click-test-setup
<davmor2> popey: http://www.w3schools.com/html/tryit.asp?filename=tryhtml_audio_5
<t1mp> plars: ok. I used provision.sh but without the -w
<t1mp> plars: and if I want the autopilot tests for the non-click apps? I need run-smoke, but if I understand it correctly that automatically runs provision so I cannot use my own packages?
<t1mp> is that correct?
<plars> t1mp: are your packages in a ppa?
<t1mp> plars: no they are the output of jenkins CI on an MR
<sergiusens> plars, wipe is incompatible with bootstrap; you only want bootstrap
<plars> t1mp: we could look at adding an option to skip provisioning from run-smoke
<plars> sergiusens: got it, thanks
<t1mp> plars: or add an option -z that downloads a zip-file with .deb's to test :)
<t1mp> plars: but yes, without provisioning would be useful
<t1mp> plars: then I can run all the tests on the device set-up the way I want it tested
<plars> t1mp: there's also a way to add hooks that happen after the device is provisioned, but I haven't played with that at all
<davmor2> popey: when you hang up on a hang out do you get what look like a mock chrome os desktop?
<popey> i dont hang up
<popey> i close the tab
<davmor2> popey: hang up next time :) I got this http://ubuntuone.com/5iFagCM9dUDOvOklPKjUKb
<popey> heh
<plars> t1mp: untested branch at lp:~pwlars/ubuntu-test-cases/touch-no-provision
<plars> t1mp: just specify run-smoke --no-provision
<sergiusens> robru, silo-012 is fine according to Chipaca; can we publish?
<sergiusens> robru, can we also make Chipaca the lander for ubuntu-push?
<robru> sergiusens, did he get lander training?
<kgunn> cyphermox: sorry, was eating lunch...
<kgunn> cyphermox: so i addded an mp for indicator-sound
<dbarth> robru: nope; oxide is in universe;and then we'll give a try to the silo on line 18 now
<dbarth> robru: so silo 002 is safeto land i tested it without oxide and it works fine; and if oxide is added to my system it works fine as well here
<robru> dbarth, yeah, but that's the problem. unity-webapps-qml is in main but is depending on oxide which is in universe. you need to MIR oxide for this
<robru> dbarth, http://162.213.34.102/job/landing-002-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-webapps-qml_0.1+14.04.20140324-0ubuntu1.diff
<dbarth> robru: there should not be a build dep
<dbarth> robru: is there one?
<robru> dbarth, there's a dep dep
<cyphermox> kgunn: you know that it conflicts with landings 5, 8 and 15 right? (just confirming again)
<dbarth> robru: ugh; we'll turn that into a suggest, cause that's not a hard depend
<sergiusens> robru, no, just ramped up by me; can we get him a training?
<dbarth> ie, it works without oxide; but we'lll need to rebuild the ppa just to verify
<robru> dbarth, ok, if you can add the change to one of the existing MPs then rebuild, then I can publish
<alex_abreu> robru, yup doing it right now
<robru> alex_abreu, great thanks
<dbarth> robru: i will re-test very quick, and then ask to publish ;)
<ogra_> mentioned seed change uploaded ...
<robru> sergiusens, I don't see why not, but it's not really my call. poke didrocks about it i guess
<sergiusens> Chipaca, ^^
<robru> dbarth, great, thanks
<Chipaca> i'll poke him in the morning
<kgunn> cyphermox: yep...testing only
<Chipaca> robru: was there an answer to sergiusens's first question (wrt publishing it) ?
<kgunn> it actually landed/but got revereted from what i understand
<robru> Chipaca, oh sorry, i still have to look at that
<Chipaca> k
<Chipaca> robru: should I wait, or should I walk the dog and get dinner? :)
<robru> Chipaca, nope, just looking at it now
<robru> Chipaca, remind me though, you had packaging fixes from didrocks right?
<ogra_> kgunn, it broke the desktop
<Chipaca> robru: from several people, yes; didrocks gave me a +1 to pre-new, if that means something to you?
<kgunn> ogra_: yep...not complaining...just letting cyphermox know
<ogra_> yeah
<robru> Chipaca, yeah, that's what I was looking for ;-)
<Chipaca> :)
<robru> Chipaca, ok, if didrocks says +1, then I can publish it
<Chipaca> cool
<alex_abreu> robru, dbarth ok done
<t1mp> plars: thanks, I'll try it tomorrow
<robru> Chipaca, ok, so i just published silo 12. what happens now is that the package gets uploaded to trusty-proposed and it'll probably get stuck there for a while (partly because it's NEW, partly because of beta freeze etc etc) but eventually it's gonna make it into the archive, and at that point you'll want to "merge & clean" the silo. i'll handle it for today because you probably don't have permission, but just be aware of the workflow
<robru> "ask for a silo -> build your stuff yourself -> test it yourself -> ask to publish it -> merge & clean yourself"
<Chipaca> robru: so merge & clean only after it's gotten into the archive?
<robru> Chipaca, yep. if you try it too soon it'll just error saying "not in archive yet". the goal is to have project trunks match what's in distro.
<Chipaca> robru: ignoring the beta freeze, if something were in -proposed I'd expect to ask people to review the package to help it get out of proposed; is that still the case?
<robru> Chipaca, only if it's stuck somehow. 90% of the time packages flow through -proposed in about an hour.
<Chipaca> ah! ok
<Chipaca> robru: so... when does the beta freeze thaw?
<robru> Chipaca, it might get stuck by depwait on certain arch or perhaps an autopkgtest failure, or maybe a manual block by a release team member.
<robru> Chipaca, hmmm, lemme check
<robru> Chipaca, looks like friday.
<robru> hmm
<robru> alex_abreu, great. did dbarth start the rebuild or should I?
<robru> alex_abreu, nm, i see the build job running ;-)
<sergiusens> Chipaca, ubuntu touch specific packages (and more so unseeded ones) don't need to necessarily wait until friday
<Chipaca> sergiusens: ah! ok. Now, how do I get seeded?
<sergiusens> Chipaca, that's easy; but needs to be in archive first
<sergiusens> Chipaca, it's an MR against ~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.trusty and get a core dev to germinate and push
<Chipaca> sergiusens: ok... tell me more about not needing to wait for the thaw
<Chipaca> sergiusens: ... :)
<robru> Chipaca, right, sorry. in theory ubuntu-push is part of the touch FFe. however I think the release team will be too swamped with freeze work to care much for a new package...
<Chipaca> robru: ah, ok. Ta.
 * Chipaca adjusts plans accordingly.
<robru> Chipaca, you might try pinging in #ubuntu-release. not sure how receptive they'll be
<Chipaca> I'll do so. Tomorrow. :)
<robru> hehe
<Chipaca> robru: thank you!
<robru> Chipaca, you're welcome!
<sergiusens> Chipaca, it's just a matter of approaching the release team nicely
<ogra_> or being not nice but bringing the right bribe with you
<ogra_> ;)
<ogra_> robru, (i'll bring that up tomorrow in the meeting too but thought it might help you today already) please done flush silos while the release team has not accepted a landing, else the packages are lost, the freeze block kicks in before the package is in -proposed (for desktop packages, touch will get auto-accepted after a few mins by a bot)
<ogra_> s/done/don't/
<ogra_> cyphermox, for you too ^^^
<robru> ogra_, what? how do the packages get lost?
<ogra_> robru, the freeze blocks them from going to proposed ...
<ogra_> so the only actual copy is in the silo ... until they get accepted
<robru> ogra_, but the merge & clean job errors if the package isn't already in archive? who is running merge & clean before packages get to -proposed? did i do this?
<ogra_> robru, thats just a warning, nobody did anything wrong
<robru> ogra_, oh ok, i thought you were saying some packages were lost, i was worried i did something wrong ;-)
<ogra_> desktop packages are generally blocked and need manual approval from the release team before even going to proposed
<ogra_> just a heads up ... only flush the silo if you are sure the packages made it into proposed
<cyphermox> ogra_: robru: it breaks the silo scripts for publishing, that's what it is
<cyphermox> the packages aren't list, they're just in the queue
<cyphermox> *lost
<ogra_> cyphermox, i was just told they are lost ... in #ubuntu-release
<cyphermox> ah?
<cyphermox> well, if they said it
<ogra_> they arent oin proposed ... and the only actual copy is in the siol
<ogra_> silo
<cyphermox> i'd expect things to just fall into the queue for trusty-proposed
<ogra_> if you flush at that point you might lose them
<cyphermox> yes
<cyphermox> oh, I think I see
<robru> ogra_, it seems an empty warning since the official policy is to not run merge & clean until after the packages are in *distro*, not before they even get to *proposed*
<cyphermox> syncs
<ogra_> no, they dont fail, they wait for approval, i dont think there is any extra queue
<cyphermox> ogra_: but since it's syncs it might be special.
<ogra_> yeah
<ogra_> ask the release team for details ... i just promised to forward the info :)
<ogra_> i think seb128 nearly ran into such an issue, thats what brought up the topic
 * ogra_ picks up GF ... brb
<seb128> cyphermox, things hit "unapproved", not trusty-proposed, because of freeze
<seb128> or unapproved doesn't have a copy of the source
<seb128> just a pointer to the ppa content
<seb128> so if the ppa is cleaned before the upload is approved, the file is not available anymore and the upload can't be accepted
<seb128> I know that "merge only when package are in distro"
<seb128> but you are going to run out of silos today if you stick to that
<seb128> since nothing goes in distro in the next days
<seb128> so you are not going to be able to claim back any silo
<seb128> (well, nothing that is on images, which is still a good part of what we land)
<seb128> talk to infinity or stgraber if that starts being an issue I guess
<seb128> imho they should just let stuff in proposed at least and britney block them
<kgunn> cyphermox: were you gonna reconfig silo4 ?
<kgunn> maybe i got lost in the churn
<cyphermox> kgunn: sorry, you did for a while but I did reconfigure silo 4 already
<cyphermox> seb128: that's what I was saying
<cyphermox> because it's a binary package copy the actual packages are only in the PPA until they really do hit proposed
<cyphermox> if all else fails we can also reclaim silos and have some people start over testing if they really aren't ready; provided they agree of course
<robru> cyphermox, seb128: clearly the correct solution is to have 5x more silos ;-)
<cyphermox> clearly
<cyphermox> let me put that to the agenda for tomorrow, since we're still on procrastination day
<robru> lol
<robru> cyphermox, ehh, i'll add it to the agenda later
<cyphermox> alright
<robru> alex_abreu, dbarth: how's silo 2? tested?
<kgunn> cyphermox: huh....ever seen where a reconfig didn't take ?
<kgunn> http://162.213.34.102/job/landing-004-1-build/78/console
<kgunn> at least, its still whining that indicator-sound isn't there
<dbarth> robru: just now; i noticed it's built now
<dbarth> robru: won't be long
<robru> dbarth, no worries, just checking. thanks
<cyphermox> kgunn: looking
<cyphermox> build should pass now I think
<cyphermox> I didn't find anything funky, I jsut reran your project reconfigure and it passed
<dbarth> robru, alex_abreu: all good here wit hthe 'suggests'; it installs fine with or without oxide; and runs fine after that
<dbarth> robru: can you publish please?
<dbarth> i'll merge and clean tomorrow morning and will get the next oxide silo ready
<robru> dbarth, sure
<dbarth> thanks
<asac> robru: where do we have the silo temp bzr branches?
 * asac remembers we had something like that
<robru> asac, which? like the branches post-publish but pre-merge?
<robru> asac, it's all here: https://code.launchpad.net/~ps-jenkins
<asac> robru: ah we only have that post-publish?
<asac> thought we had that everytime you reconfigure
<asac> e.g. you can check whts in current silo basically
<robru> asac, no, reconfigure just changes which branches it knows to pull from.
<asac> robru: hmm. so building merges the MPs? I guess thats where pushing the branches woudl be great
<robru> asac, best way to check what's in the silo is to just look at the most recent build job. grep for "trying to merge", it includes the MP link and the revision number that it pulled from there. you can open all the links and compare revision numbers to see if the silo has the latest of each MP
<asac> basically, at the very first moment we havce them, publish them
<asac> robru: well, thinking having the real tmp/merge branch would be nice
<asac> but who knows :)
<robru> asac, could be, i never had a need for it personally. didrocks is the one who controls the code, nothing I can do ;-)
<kgunn> robru: cyphermox ...or anyone, how would one determine what the version of bzr is that's being used by the silo builders ?
<cyphermox> kgunn: you'd need to ask ;)
<cyphermox> or maybe look at the ppa logs
<kgunn> mmm
<cjwatson> I don't think bzr is run in a PPA-like environment
<cjwatson> For the purpose of silo merging
<asac> kgunn: thats what i just asked above. they take your bzr trunk, and merge stuff together, but dont publish that at the build stage; think thats what I hope the train could do; similar to the branches published when you hit merge and publish: https://code.launchpad.net/~ps-jenkins/+branches?memo=100&start=100
<asac> kgunn: since we don thave that it seems, you probably have to look at the logs :/
<robru> asac, you should fild a bug against cupstream2distro and assign it to didrocks ;-)
<asac> robru: whats the jenkins URL again?
<asac> the CItrain jenkins that is
<robru> asac, you mean http://162.213.34.102/ ?
<asac> right
<asac> thats where the logs would be, right?
<robru> asac, yeah, you can get links to the right jobs from the spreadsheet, and then the logs are listed on the left side of the page
<asac> robru: hmm. where would the bzr branching/merging be done for the build prep?
<robru> asac, in the build logs. depends per silo
<robru> asac, each silo has a unique build job, so you have to know what silo you care about first, then look at it's build logs
<asac> robru: right :) ... but at what stage?
<asac> cant find anything in reconfigure and build
<asac> ... bzr bd...
<asac> does that pull the source auto?
<robru> asac, what is it that you are looking for?
<asac> robru: the bzr versions branched
<asac> and merged
<asac> those revs
<robru> asac, ok, so lets say you are wondering about silo 3. go to the silo 3 tab in the spreadsheet. click on the 'build' button. see the logs on the left, most recent build is #85. click the blue dot, and you get this: http://162.213.34.102/job/landing-003-1-build/85/console
<robru> asac, grep for 'Trying to merge' and it tells you the merge URLs with revisions pulled
<asac> ic
<asac> so the command is hidden :)
<asac> good
<robru> asac, yeah, it's not like a makefile where it echoes the commands it runs. it's a python script and it just logs certain details at certain points
<robru> although I'm starting to think that a makefile would work better considering how many commands we run... ;-)
<cyphermox> robru: is this still about the bzr version used for the silos?
<robru> cyphermox, yeah
<cyphermox> not revisions, correct?
<robru> cyphermox, I'm pretty sure they are asking which MP revisions got branches for the most recent silo build job.
<cyphermox> isn't that in the build logs?
<robru> cyphermox, yes it is, I explain it in the scrollback
<cyphermox> alright :)
<cyphermox> if you need the actual bzr utility version; then you can ssh on the jenkins box to see it
<cyphermox> it's 2.5.1-0ubuntu2
<robru> cyphermox, yeah, that's what I thought they were asking at first but I don't think that's it
<balloons> sergiusens, ping
<t1mp_> plars: I just noticed that ubuntu-test-cases is using phablet-flash. Do you know that that is deprecated and ubuntu-device-flash should be used?
<plars> t1mp: yes, we're aware. phablet-flash does still work, and the host system needed to be updated before patching this. I have an MP out to update to ubuntu-device-flash that is being reviewed and tested by another person right now. It worked in local testing, so I expect we'll probably merge it this evening
<balloons> ogra_, cyphermox sergiusens, cjwatson perhaps? Can any of you help me in fixing a click package being built by cmake? I need it to include a plugin
* doanac changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<sergiusens> balloons, which project?
<balloons> sergiusens, filemanager. https://code.launchpad.net/~nskaggs/ubuntu-filemanager-app/fix-armhf-build/+merge/211621
<sergiusens> you should just follow what reminders app does
<balloons> sergiusens, yes but the plugin is external to the project
<sergiusens> balloons, you need to include it; that's the click model
<balloons> sergiusens, qtdeclarative5-nemo-qml-plugin-folderlistmodel
<sergiusens> balloons, the plan with dpm was to include it in source
<balloons> sergiusens, can I use find_package or find_library or ?
<balloons> in the source would certainly help
<sergiusens> balloons, you can use what I use in click-ready, you should notice a plugins.json in source
<sergiusens> it's still bad though
<sergiusens> and pull-lp-bin for it
<sergiusens> or apt-get download it
<sergiusens> but you need to add the ppa to your sources.list for the latter to work
<balloons> ahh pull-lp-bin.py
<balloons> sergiusens, so there's no really good way to do this apart from having the plugin inside the project?
<sergiusens> balloons, nope; I talked to zoltan about having some 'plugin' repository and reusing that; but I guess they had no time yet to design and implement
<balloons> ugh that's ugly. ok, so I will try and hardcode some hackery to make it build against a static copy of the plugin and push to get it into the project
<balloons> ty sergiusens .. I reserve the right to ping you again, but this makes sense enough now I think
<t1mp> plars: okay, nice
<plars> bfiller: boiko: around?
<bfiller> plars: yes
<plars> bfiller: boiko: wondering if you saw the new crashes with dialer and messaging: http://ci.ubuntu.com/smokeng/trusty/touch/mako/261:20140325.3:20140304/7375/dialer_app/
<bfiller> plars: argh, no
<plars> I wondered if those might be related to the fix that recently went in
<plars> bfiller: on the plus side, all the tests pass! :)
<bfiller> robru: can I get a silo please for line 46
<robru> bfiller, on it ;-)
<robru> bfiller, ok, you got silo 9, please build
<bfiller> robru: thanks!
<robru> bfiller, you're welcome!
<Saviq> popey, ogra_, re: blocking content based on geo, that's the smart scopes server's task
#ubuntu-ci-eng 2014-03-26
<boiko> plars: bfiller_afk: tomorrow I will investigate those crashes
<plars> t1mp: I made one minor but important change to that branch, so you might want to repull it. I've proposed a merge for it, and it ought to land in trunk of lp:ubuntu-test-cases/touch tomorow
<imgbot> === trainguard: IMAGE 262 building (started: 20140326-03:05) ===
<imgbot> === trainguard: IMAGE 262 DONE (finished: 20140326-04:25) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/262.changes ===
<Mirv> good morning
<Mirv> now I realize I forgot to ask sergiusens for click credentials yesterday, after ball_oons taught me how to publish click packages. on the other hand, I'd like to go through the first time by double-checking the steps anyway.
<Mirv> (regarding the gallery-app)
<Mirv> nice to see 100% green again http://ci.ubuntu.com/smokeng/trusty/touch/mako/261:20140325.3:20140304/7375/
<Mirv> tvoss: were you planning to test+land dbus-cpp ppc64el fix before the process-cpp one? I mean, you are not having a problem of not having a silo for process-cpp yet?
<tvoss> nope
<tvoss> Mirv, coming back to you in ~30
<Mirv> I take that as a positive answer to my triple negations etc ;)
<Mirv> cool
<didrocks> Mirv: 3rd day of the week, triple negationsâ¦ Tomorrow, four? :)
<Mirv> :)
<sil2100> Morning!
<sil2100> didrocks: so, I checked the dch parameters, and found the difference between precise and now - in precise we need to use "--release-heuristic changelog", as by default it uses 'log'
<sil2100> didrocks: it works differently as the default heiristics looks for dput upload files, not the changelog contents ;/
<didrocks> sil2100: oh, I was overleading that in the directory
<didrocks> but as we moved CI Train, I guess we missed that
<didrocks> yeah
<didrocks> you're more than right
<didrocks> so the fix is easy!
<didrocks> morning sil2100 :)
<didrocks> sil2100: want to propose a branch? ;)
<sil2100> didrocks: ok ;)
<didrocks> sil2100: with some unit tests will be bonus!
<tvoss> Mirv, hey, I'm confused :) https://code.launchpad.net/~thomas-voss/dbus-cpp/fix-ppc64-el/+merge/211894
<tvoss> says that it is merged
<sil2100> Will try, guess it won't be that hard ;p
<didrocks> sil2100: shouldn't, thanks!
<Mirv> tvoss: err. let's see.. it seems to have been published by robru (somehow) https://lists.ubuntu.com/archives/trusty-changes/2014-March/013069.html
<tvoss> Mirv, it used to be in silo 001 before
<Mirv> tvoss: it looks to me that sil2100 published it on Monday http://162.213.34.102/job/landing-001-2-publish/59/ :D maybe he can explain something to this confusion
<Mirv> I'm not seeing a line in CI Train where it got published
<sil2100> hmm, I remember publishing that in CI train
<Mirv> tvoss: and yes it build for ppc64el, and we got 100% pass on CI Train too from image #261 so I guess that counts as tested.. https://launchpad.net/ubuntu/+source/dbus-cpp/2.0.0+14.04.20140322-0ubuntu1
* vila changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: vila | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<tvoss> Mirv, so you don't need me to do anything, correct? :)
<sil2100> Mirv: I guess something racy happened, let's set it to landed I guess ;)
<Mirv> tvoss: yeah no need, let's get that silo to your newest process-cpp line then :)
<Mirv> sil2100: only free silo?
<sil2100> Mirv: yes, only free silo in the m&c, and then let's set it to Landed manually :)
<Mirv> running
<sil2100> Thanks o/
<tvoss> Mirv, hang on, I need to bump build deps before we can do that
<tvoss> Mirv, give me ~15
<Mirv> tvoss: ok
<Mirv> FYI we'd have the gallery-app click package built too, if we'd just have someone to push it to the store together with publishing landing-009
<tvoss> cjwatson, for https://code.launchpad.net/~thomas-voss/process-cpp/fix-death-observer/+merge/211996 and your comment on build deps: Do I have to bump the build deps and make them versioned?
<tvoss> cjwatson, as in: requiring libprocess-cpp-dev (>= 1.0.0) in dbus-cpp for example
<Mirv> thomas has a silo now, so he can click build when the brances are double-checked to be ready
<ToyKeeper> Oi, it has been a long day.  I just realized I marked all my test results with image 261, but it was really image 262.
<didrocks> ToyKeeper: just update on the spreadsheet, thanks for the testing!
<ToyKeeper> I already did.
<tvoss> Mirv, can I just add trunk branches to the silo as well? To check that everything still works together?
<dbarth> sil2100: hi
<dbarth> sil2100: there seems to be an issue with landing silo 002
<dbarth> a message about a package in the unapproved queue
<sil2100> dbarth: let me take a look
<sil2100> dbarth: ah, might be due to the freeze
<sil2100> didrocks: btw. looking at the unit tests ;p When and where do we run those unit tests? As I already see a zillion unit tests that should fail in our case! ;)
<Mirv> tvoss: if you're not planning to publish those trunks, maybe just build the silo and then update to the silo locally and to the test builds? I mean, it becomes slightly tricky if there are "just out of interest" builds/branches in the PPA which need to be cleaned before publishing.
<didrocks> sil2100: hum, are you sure they are failing? I run them recently and they don't
<Mirv> tvoss: if you want non-x86 PPA builds, I can help by building in another PPA against the landing PPA after it has built
<didrocks> sil2100: nosetests tests/unit/
<didrocks> sil2100: Ran 190 tests in 18.055s
<sil2100> didrocks: they wouldn't fail for me here, would have to modify it to 'do the wrong thing' - but looking code wise they should just fail, as all the test_refresh_symbols_files_* compare the resulting changelog with the 'right' one, and this should fail - let me experiment ;)
<tvoss> Mirv, alternatively, I could setup MPs for the packages that have a build and runtime dep on process-cpp, bumping the build-dep to libprocess-cpp-dev (>= 1.0.0)
<tvoss> Mirv, does that make sense?
<didrocks> sil2100: I don't use a mock dch, but let me check
<dbarth> sil2100: ah, so what's the way forward?
<didrocks> sil2100: yeah, only bzr, dput and sudo are mocked
<Mirv> tvoss: do they need the rebuild and the bumping of build-dep? if so, yes it makes sense, but if there is no need other than testing that they WOULD build against the new process-cpp, again I'd use another PPA that builds against that landing PPA
<tvoss> Mirv, I think I'm a fan of versioned build-deps here, so I would prefer bumping them
<sil2100> dbarth: I think we'll have to poke the release team and try to convince them that it's something we need to get pushed through
<Mirv> tvoss: if you can get approvals for the version bump MP:s similar to the other MP:s, sure I don't object :)
<tvoss> Mirv, ack :)
<tvoss> Mirv, could you have a look at http://162.213.34.102/job/landing-014-1-build/40/console
<sil2100> didrocks: so, when running the unit tests locally by emulating what's going on on the citrain device (i.e. a precise system with heuristics default to log), then I get all the test_refresh_symbols_* tests failing
<sil2100> didrocks: so on the citrain machine it has to be failing as well!
<didrocks> sil2100: ah, so making sense!
<didrocks> sil2100: let me see if I can install nosetest on the machine
<sil2100> didrocks: anyway, I was shocked on how many tests you wrote for this :o There's like almost every case supported :o
<didrocks> sil2100: I told you it's not some small scripts :)
<sil2100> ;)
<didrocks> Ran 190 tests in 21.974s
<didrocks> FAILED (failures=7)
<didrocks> sil2100: confirmed!
<didrocks> and the diff contains this :p
<didrocks> http://paste.ubuntu.com/7155572/
<didrocks> which confirms the theory
<didrocks> sil2100: so yeah, my fault was to only run the test on my machine :p
<sil2100> didrocks: \o/ the branch for a quick-fix is here: https://code.launchpad.net/~sil2100/cupstream2distro/dch_heuristics/+merge/212788
<didrocks> not a precise one
<sil2100> didrocks: yeah, who would have guessed there would be these subtle differences ;p
<didrocks> sil2100: excellent :)
<didrocks> sil2100: well, TBH, I've seen it while putting the train in production
<didrocks> and you can see I changed that when generating the changelog
<didrocks> didn't thought about the symbols file
<didrocks> though
<Mirv> tvoss: I checked them out and it looks like lp:~marcustomlinson/unity-scopes-api/scope_process_lifetime would need another sync with the trunk to have the latest changelog entry included too before bumping the version
<didrocks> sil2100: so approved!
<Mirv> tvoss: there was a release on Monday of it
<didrocks> sil2100: we'll put that in prod at the same time than the other changes (continuing on the spreadsheet refactoring for the request id support)
<didrocks> sil2100: feel free to merge manually to cu2d
<sil2100> didrocks: ah, we don't have an auto-merger?
<didrocks> sil2100: unfortunately, not
<sil2100> Ok :)
<sil2100> Mirv: are you handling Bill's gallery-app landing, or can I pick it up and publish?
<Mirv> sil2100: it needs the simultaneous click publishing, so we need someone that can push the (already built) click package too
<Mirv> sil2100: and I can't do that even though I was taught how to, since I forgot to ask sergiusens for crendentials yesterday
<Mirv> additionally, the Python publishing thing fails to run for me for some reason (it downloads random modules from the internet so maybe that's why)
<pete-woods> seb128: morning! sorry to grab you as you arrive
<pete-woods> but what you were worried about with the HUD sync has happened
<pete-woods> seems my boss was immediate in following my instructions to clean the PPA
<pete-woods> do you have any advice about what I should do?
<seb128> hey pete-woods, I guess you need to put a new landing ask for the same vcs-es and do a new landing :/
<seb128> infinity, slangasek, ^ (silo cleaned while the copy was in trusty unapproved queue, is there any way around redoing a build/upload)?
<pete-woods> I do actually have another MR I'd have liked to add, so I can just request another silo (and not clean this time) if that would work
<pete-woods> then maybe just reject the sync?
<dbarth> sil2100: should i just go here on the channel and ask the release tema?
<seb128> pete-woods, yes, rejecting the sync is fine
<seb128> pete-woods, if you need a landing feel free to give me the merge requests urls, I can put one for you (I think thostr is off today)
<pete-woods> seb128: the silo's in a weird state now, though, the branches have been merged, but the spreadsheet doesn't know it's clean
<pete-woods> seb128: https://code.launchpad.net/~unity-api-team/hud/dbusmenu-safety-valve/+merge/212668 is the one
<pete-woods> that branch is based on top of the merged trunk, though..
<dbarth> sil2100: i'd like to flush the siloi to get started with the more important oxide branches for webbrowser-app
<seb128> pete-woods, the weird state is because thostr stopped the clean job
<seb128> pete-woods, but the ppa was already cleared
<pete-woods> seb128: ah, he must have got my "wait, don't clean the PPA" ping too late
<seb128> sil2100, Mirv, didrocks: what's the proper way to deal with that ^?
<sil2100> dbarth: yeah, sorry, let's try doing that - was busy with something
<didrocks> seb128: so, something was cleared, but the job was stopped?
<didrocks> seb128: and so unassignement didn't work?
<sil2100> pete-woods, seb128: so, branches are merged but packages still not released?
<sil2100> Or is everything in the archive and merged in properly, just the silo is still there?
<seb128> didrocks, sil2100: right, the clean job was started, it merged back and send the clean ppa order, then the job was stopped
<pete-woods> sil2100: yes, the packages ended up in the unapproved list
<seb128> so things are merged&cleaned
<didrocks> seb128: wonder why people are doing that
<didrocks> hum
<didrocks> which silo #?
<seb128> didrocks, because we overlooked that "sync to unapproved" are not copies
<seb128> 11
<pete-woods> didrocks: silo 11
<didrocks> seb128: what the link with sync to unapproved?
<seb128> didrocks, those syncs are links to the ppa, so when you clean the ppa the item in the unapproved queue becomes void/can't be accepted
<didrocks> merge and clean will have failed with that
<didrocks> telling don't merge, things are in unapproved
<seb128> didrocks, well, we didn't want to block the silo until beta freeze
<seb128> otherwise we are going to be out of silo and locked down today
<didrocks> so override?
<seb128> that's what happened
<didrocks> niceâ¦ :/
<seb128> until we realized that cleaned the ppa makes the upload unvalid
<seb128> since the queue doesn't have a copy
<seb128> just a pointer to the ppa librarian
<didrocks> everything was blocked or some components passed?
<seb128> you mean?
<pete-woods> didrocks: hud didn't make it, the other package did
<didrocks> ok
<pete-woods> (libqtdbustest)
<seb128> oh, right
<didrocks> I suggest that you bzr push --overwrite HUD trunk to the previous status
<didrocks> to reconcile with what's in the distro
<didrocks> then, we force m&c
<didrocks> and redo a landing
<pete-woods> didrocks: should I go and reopen the MRs then?
<didrocks> pete-woods: yeah, rewrite history basically! :)
<pete-woods> okay, cool, I'll do that then
<didrocks> pete-woods: seb128: if that request is set to landed, that's fine?
<seb128> didrocks, can't we just add a landing for a new mp?
<didrocks> (that's what will happen)
<seb128> that would do trunk + that new change
<didrocks> seb128: depends, is there any?
<seb128> yes
<didrocks> ok, that can work as well
<seb128> https://code.launchpad.net/~unity-api-team/hud/dbusmenu-safety-valve/+merge/212668
<didrocks> if you don't let the ball dropping and we are not in a middle-state
<didrocks> pete-woods: ^
 * didrocks runs m&c with "only free silo"
<pete-woods> didrocks: I'm happy with whichever way you guys think will work
<seb128> let put a landing ask for ^
 * seb128 does that
<didrocks> pete-woods: yeah, so just file a new request with that branch, but please mention that the rest in the decription will land as well
<pete-woods> it's just frustrating being "unapproved" for bug fixes while if I had a phone FFE I could land anything
<pete-woods> anyway, I'm not interested in moaning, I will get that landing request in
<didrocks> pete-woods: we are in beta freeze, that's why desktop updates are blocked
<seb128> I think the release team is making that more difficult that it should
<seb128> they should let stuff in proposed and britney block
<didrocks> yep
<didrocks> and then people complain about Touch process ;)
<seb128> didrocks, pete-woods, sil2100: l48
<didrocks> sil2100: letting you assigned once the current silo is freed?
<didrocks> (should be refreshed in less than a minute)
<didrocks> sil2100: done, please assign
<didrocks> pete-woods: seb128: set manually the previous status to "Landed but HUD"
<sil2100> didrocks: should I explicitly specify that silo, or just leave citrain to decide which silo to use?
<didrocks> sil2100: let CI Train deciding
<didrocks> nothing remained in the silo
<didrocks> it's really freed and gone
<sil2100> dbarth: hmmm...
<sil2100> dbarth: actually, give me some time to think about how to proceed ;/
<dbarth> sil2100: sure
<dbarth> sil2100: i just want to clear decks as much as you do i guess
<sil2100> Yeah, it's a sticky situation
<pete-woods> seb128, didrocks, sil2100: thanks for sorting me out here , guys :)
<ogra_> |HELP
<didrocks> pete-woods: yw :)
<Laney> ah interesting
<Laney> So deletion and queues don't interact very well
<didrocks> popey: coming?
<popey> sorry, yeah
<ogra_> |HELP
<imgbot> I am the firendly image watchbot
<ogra_> :)
<seb128> Laney, no they don't, pocket copies are not actual copies, they are pointers to the librarian
<seb128> Laney, so when you clean the source you loose the data and the unapproved entry becomes invalid
<Laney> firendly indeed
<davmor2> ogra_: I don't believe you
<Laney> seb128: I see
<ogra_> heh
<Laney> Not sure if that would be fixable in LP
<Laney> but you could use an intermediate PPA
<seb128> lol
<seb128> more crazyness isn't the answer :p
<seb128> just let thing in proposed and review there?
<Laney> This argument is already hitting a wall, so I'll go and do something more useful
<seb128> yeah, same here
<seb128> I guess I don't care enough
<seb128> let's hit the silos lockdown situation
<Laney> I do, but if there is no option to change anything CI is doing then it's pointless even talking about it
<seb128> but I guess that's going to come down back from management on why we lock everything then
<seb128> Laney, I guess there is the option, but why isn't release open to consider changes as well?
<Laney> Essentially I think that any process designed to work with the archive has to be able to deal with what it does, and that includes freezes sometimes
<Laney> It could just be that LP can actually be fixed to work how we want it to here, but I don't know enough to say that
 * Laney EOD :-)
 * wgrant wakes up
<Laney> o hai
<wgrant> Haven't ready all of scrollback, but is the problem that a copy sitting in the queue will fail if the source PPA has the source removed?
<wgrant> That should work if it's accepted within a week or so
<Laney> Yeah
<Laney> I assume there was an actual incident, but ...
<seb128> infinity warned that if we clean the ppa we screw the items in the queue
<seb128> we just took his words on it
<wgrant> Well
<wgrant> That was a problem back when stuff would sit in unapproved for weeks
<wgrant> But stuff is copiable until at least seven days after it was deleted from the origin.
<Laney> Would it be possible to notice the reference made by a copy record?
<wgrant> Not in the current model.
<Laney> Fair enough
<wgrant> There's a redesign in progress, but it's currently blocked on a couple of other big projects.
<Laney> Well anyway, I think 7 days should actually be alright for our purposes
<Laney> People start pinging after 7 hours, anyway. ;-)
<seb128> right
<Laney> sil2100: ^^^ you should be alright
<sil2100> didrocks: ^
<didrocks> ok, then, just m&c with "ignore package in dest"
<cjwatson> tvoss: I would tend not to unless the changes require the new APIs
<tvoss> cjwatson, yup, same here. But with that, we cannot easily add trunk for the build deps to the silo as per what Mirv said
<sil2100> dbarth: we might have a solution!
<cjwatson> tvoss: or just wait until the new process-cpp is in trusty and then it won't matter
<sil2100> dbarth: let me get back to you in a some minutes
<cjwatson> tvoss: bumping the build-deps isn't *wrong*, I wouldn't spend much time agonising about it, but it does impede situations where you might otherwise be reasonably able to backport things
<tvoss> cjohnston, ack and thanks
<dbarth> sil2100: ok
<didrocks> sil2100: Mirv: FYI, when I'll be in a little bit of a quieter place, I'll be able to finish the spreadsheet part and then switch to the new assignement silo/reconfiguration process
<didrocks> I'll keep you posted
<Mirv> ok
<didrocks> davmor2: can you give me the new bug # ref?
<didrocks> so that I can +1, set the appropriate priority as well
<sil2100> didrocks: ok ;)
<davmor2> didrocks: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1297770
<ubot5> Ubuntu bug 1297770 in unity8 (Ubuntu) "Scopes scroll down till header goes seems to lock the scope in place" [Undecided,New]
<davmor2> didrocks: I added the secondary icons visible in header as I assume the two are linked
<didrocks> davmor2: yeah, I think they are
<didrocks> sil2100: this is the bug to give to the unity8 team as well ^
<didrocks> davmor2: please mention it's a regression from latest promoted image and the image #
<sil2100> dbarth: ok, so, what we'll do - I'll merge and clean your silo (as we need to do some special handling) and then I can assign a new silo for your features
<sil2100> dbarth: it seems that we can do it now even
<tvoss> Mirv, Marcus and me are testing silo 14, would be great if you could setup a ppa for testing the process-cpp build-deps
<dbarth> sil2100: perfect
<dbarth> sil2100: need me to push some buttons?
<sil2100> dbarth: no no, all is handled from our side ;)
<sil2100> dbarth: which landing from your list is now the highest priority?
<didrocks> Mirv: so, you're going to publishin landing-002 as we discussde?
<pete-woods> seb128: hi, the HUD silo has been tested (and succeeded) now, would you be able to mark it as such for me?
<sil2100> Mirv: I'll publish the gallery-app silo in the meantime
<Mirv> tvoss: you can set one at https://launchpad.net/~thomas-voss/ or I can push builds to some PPA when you give me a list of packages to build against the landing PPA
<Mirv> sil2100: thanks
<tvoss> Mirv, ack
<pete-woods> seb128: thanks :)
<seb128> pete-woods, yw ;-) publishing as well (just not cleaning this time)
<pete-woods> :)
<Mirv> tvoss: so which way, your PPA or my PPA? :)
<dbarth> sil2100: uh sorry; it's line 18
<tvoss> Mirv, your PPA :)
<Mirv> tvoss: does this happen to be the correct set: connectivity-api dbus-cpp platform-api platform-api unity-mir unity-scopes-api ? (reverse-depends -b libprocess-cpp-dev)
<tvoss> dbus-cpp unity-mir and unity-scopes-api are sufficient
<davmor2> didrocks: so it looks like the header in it's current format will be removed so what do you want to do about it?
<didrocks> davmor2: I won't take any decision, I guess it's your/QA decision to take
<didrocks> for it being a promotion blocker or not
<didrocks> like, are we happy to have users with such bugs on their phone
<davmor2> Oh I wouldn't block on it
<Mirv> tvoss: rebuilds of those against landing-014 visible now at https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta-proper/+packages?field.name_filter=&field.status_filter=published&field.series_filter=trusty
<tvoss> Mirv, thank you
<sil2100> dbarth: oh, but line 18 is still not set to ready - is it ready?
<sergiusens> Mirv, what's up? How were you shown the process?
<sil2100> sergiusens: morning! Could you release a new gallery-app to the click store? :)
<dbarth> sil2100: ah wait, yes i was putting on hold
<dbarth> sil2100: just re-checking the branches real quick
<sergiusens> sil2100, yeah
<dbarth> sil2100: oh and they're stacked on each other, so i need to flatten that first
<sil2100> dbarth: ok, just give me a poke once it's ready and I'll assign a silo then :)
<sil2100> sergiusens: thanks
<Mirv> sergiusens: the gallery-app would need publishing as sil2100 said. balloons showed me the jenkins job(s) that can be used to build click packages, and explained lp:click-toolbelt having a tool to push those packages
<sergiusens> Mirv, yeah, can you install click-toolbelt into a vitualenv?
<Mirv> sergiusens: nope, since the install fails at some point to "TypeError: dist must be a Distribution instance"
<sergiusens> Mirv, yeah, make the virtualenv python2
<sergiusens> Mirv, we need to tell pindonga about that py3 bug
* vila changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cprov | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<Mirv> sergiusens: (first time using virtualenv) even if I use virtualenv --python=python2.7 I get the same error. installing python-stevedore from archives instead of fetching it via the easy_install resolves that problem at install time, but I still get some DistributionNotFound error when trying to execute the resulting bin/click-toolbelt
<sergiusens> hm, I don't have that error
<Mirv> some pastebin instructions on how you install lp:click-toolbelt could be enlightening
<sergiusens> Mirv, all I did from trusty was; virtualenv [path]; [path]/bin/activate; bzr branch lp:click-toolbelt; cd click-toolbelt; python setup.py install
<sergiusens> Mirv, anyways, direct uploads is broken... talking to pindonga about it and he confirmed... http://paste.ubuntu.com/7156378/
<sergiusens> manual uploads seem broken too :-/
<Mirv> sergiusens: tried http://pastebin.ubuntu.com/7156410/
<Mirv> sergiusens: right
<sergiusens> Mirv, try installing oauthlib locally
<davmor2> popey: are you getting the welcome screen locking for a while most times you wake the device?
<popey> yes
<popey> suspected it's the queuing issue
<ogra_> yeah
<ogra_> it seems to take longer the longer it was suspended
<ogra_> which kind of points to the queue issue
<Mirv> sergiusens: both python-oauthlib and python3-oauthlib seem already installed, or do you mean locally as in force its installation to the virtual env too? can try.
<ogra_> takes nearly 30sec in the morning for me
<davmor2> that's the answer I was hoping for atleast :)
<Mirv> sergiusens: thanks for the e-mail anyway, in case I'm required to do some publishing at some point
<ogra_> i guess there is a lot of sensor events and such that pile up
 * davmor2 must remember to try ringing his phone after it has been off for a while, now where did I put that pad
<ogra_> heh, did anyone try the new scopes on flo already ?
<ogra_> the font in my Apps header is slightly moved to the center after boot
<ogra_> only moves to the left once i switched back and forth between scopes
<sergiusens> Mirv, sure, just copy that into~/.config/click-toolbelt/click_toolbelt.cfg
<sergiusens> Mirv, ok, with python3 (and yes this feels broken), just do python setup.py install in a loop until it works (just tried myself)
<Mirv> sergiusens: ...
<Mirv> sergiusens: works :S
<sil2100> ;)
<sergiusens> Mirv, ugly; but the dev told me to do this; it's one of the reasons I asked for proper packaging on the list...
<Mirv> this fits well in my (granted, very limited) experience of "easy" install, ruby gems and so on
<Mirv> sergiusens: ok, I'm set up then, in case the uploads start working at some point and something in addition to the currently pending gallery app is needed during EU timezones
 * davmor2 has poached popey 's excellent idea of a pad for quick notes/bugs you need to file :)
<davmor2> unfortunately it's now filling up :)
<ogra_> geez, just dont add stuff then !
<sergiusens> Mirv, sil2100 so I can't upload the new gallery until the store gets fixed
<davmor2> popey: erm what.  On the desktop pull down the system inidcator what is lock now called :)
<sil2100> sergiusens: ok... any ETA on that?
<seb128> davmor2, not sure what you describe, the indicator-session items didn't change
<sergiusens> sil2100, I don't have one
<tvoss> Mirv, I would like to the unity-scopes-api branch out of the silo
<didrocks> sergiusens: Mirv: ok, the spreadsheet is readyâ¦ I'm going for a run now. However, we'll see depending on ping crazyness if I deploy it today or tomorrow
<tvoss> Mirv, take it out
<didrocks> tvoss: you can do that yourself
<didrocks> tvoss: just reconfigure with the list of MP and remove the unity-scopes-api from it
<didrocks> (but we need to remove the package if there is no more MP associated to it)
<tvoss> didrocks, in the silo tab?
<didrocks> tvoss: yeah, if unity-scopes-api has been built from a MP
<Mirv> tvoss: if you do that ^ I can remove the package fro the PPA
<tvoss> didrocks, Mirv when I try to alter in the silo tab, I only get a formula
 * tvoss is scared
<didrocks> tvoss: hum, see the "reconfigure" button?
<davmor2> seb128: in the live session it's called start screensaver I'm assuming because there is no password for lock.  I was just double checking that it was lock on a real desktop rather than rebooting
<seb128> davmor2, real desktop is fine
<davmor2> seb128: okay cool
<tvoss> didrocks, Mirv I reconfigured here: http://162.213.34.102/job/landing-014-0-reconfigure/9/
<didrocks> great :)
<Mirv> tvoss: looks good :) I removed the unity-scopes-api from the PPA now
<tvoss> Mirv, thanks
<sergiusens> sil2100, seems the bug is soon to be solved; given it's backened it might take a bit to propagate
<sil2100> sergiusens: excellent!
<t1mp> didrocks: hello, we are discussing adding a staging branch for the ubuntu-ui-toolkit
<t1mp> didrocks: I have a proposal here https://docs.google.com/a/canonical.com/document/d/1rgXqqCeGg9JjHEHmDHOfhBJOGTgk7luBuBbpzNTMMLk/edit#
<t1mp> didrocks: it would be good to get your feedback/approval on that :)
 * sil2100 goes for a longer lunch
<tvoss> Mirv, okay, with silo 14 reconfigured, and the rebuild packages from your ppa, things still work. Could you give it a quick spin, too?
<Chipaca> didrocks: hello there. How can I become a lander for ubuntu-push? :)
<Mirv> tvoss: ok I updated my phone with those two PPA:s and even removed the libprocess-cpp0, indeed I don't notice anything different
<tvoss> Mirv, okay, that's good in this case, so I will set the silo to tested
<tvoss> Mirv, thanks for the help :)
<tvoss> Mirv, done
<Chipaca> is there an easy way to point at a /usr/lib/{multiarch}/yadda/yadda from an upstart script?
<Mirv> tvoss: ok. I'm going to run "watch only" build job now first since it seems the spreadsheet doesn't update correctly.
<Mirv> oh, right there's an eternal build job running already
<Mirv> so, let's see if watch only correctly notices just the process-cpp
<Mirv> tvoss: darn, you've a small ppc64el problem that would prevent the package from migrating to release pocket since it built there before: https://launchpadlibrarian.net/170746201/buildlog_ubuntu-trusty-ppc64el.process-cpp_1.0.0%2B14.04.20140326.1-0ubuntu1_FAILEDTOBUILD.txt.gz
<Mirv> why that is only on ppc64el I don't know
<Mirv> tvoss: and the build problem wasn't visible on the dashboard since there was a stalled build job running for the silo that waited eternally for unity-scopes-api
<cjwatson> should be trivial to change anyway
<tvoss> Mirv, cjwatson updated the symbols file
<Mirv> sergiusens: are you able to find time to drive (test) your landings in silos 010 (phablet-tools) and 005 (usensord, platform-api) soon? just wondering since they've been built for quite some time now.
<tvoss> still weird ...
<Mirv> tvoss: ok! kick a rebuild then. now it shouldn't stall on unity-scopes-api anymore.
<bfiller> sil2100: silo-13 ready to be released
<sergiusens> Mirv, I thought usensord and platform api were unassigned already two weeks ago+
<sergiusens> Mirv, for silo 10; I can deal with that today if doanac has a minute to spare
<tvoss> Mirv, kicked
<sergiusens> doanac, can you rerun a full ci with the phablet-tools from silo 10?
<Mirv> sergiusens: ok. does that mean the usensord/platform-api silo should be cancelled?
<Mirv> sergiusens: I think the silo was temporarily freed, but the line was not removed so it got a new silo since it still looked like it would be wanted to be landed
<sergiusens> Mirv, needs some fixing from ricmm; I'll talk to him today
<Mirv> sergiusens: ok, I'll let the silo then be still there but add a comment with that info
<ogra_> davmor2, popey, hey you english speakers ... is there a bug open for all translations missing for the new scopes ? :)
<ogra_> dpm, ^^^^do you know if anything is in the works here ?
<dpm> ogra_, no, I don't know, I've just realized this myself
<dpm> I think the new scopes don't support translations
<ogra_> lol ?
<popey> oof
<dpm> but perhaps Saviq knows more on whether the translations for the new scopes are still provided by the shell or by the scopes themselves ^
<Saviq> dpm, scopes
<Saviq> dpm always backends, we in unity8 can't even dream to be able to hold all the translations for all the possible scopes etc.
<dpm> in that case, they need to add i18n support
<dpm> thanks Saviq
<Saviq> yup
<doanac> sergiusens: sure thing
<dpm> is unity-scopes-api the best place to file the bug?
<Saviq> dpm, basically each scope in question needs to enable i18n for its own strings, -api might facilitate a bit, but there's also smart scope server that we need to make sure gets the locale from the device and communicated to the scopes
<Saviq> dpm, so probably a bug with real many tasks - unity-scopes-api, unity-scope-click, unity-scope-scopes, unity-scope-mediascanner2, $smart-scope-server
<dpm> oh dear
<ogra_> dpm, given that went completely unnoticed ansd we want to be regression free in the future, i wonder if it makes sense to have translateability as a landing criteria ... i.e. if something lands that was possible to translate before it has to fulfill that requirement too before being allowed to land
<dpm> ogra_, that sounds sensible (and great!) to me, but I'm easy to convince when it comes to internationalization :)
<ogra_> heh
<ogra_> i think it isnt necessary to require translations, but at least the code need to keep the ability to be translated in a new iteration when it lands
<dpm> +1
<davmor2> ogra_: no idea
<sergiusens> doanac, if that works we are going to finally be able to get some traction :-)
<ogra_> didrocks, asac ^^^^ i wonder how to put that down as a "policy"
<doanac> sergiusens: http://q-jenkins:8080/job/andy-smoke-daily-test/4/console
* cprov changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: retoaded | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<infinity> seb128: Why are you taking my name in vain?  I'm not the one who warned against silos and freezes. :P
<seb128> infinity, do I get to take a penalty card? and a few more for lying? :p
<infinity> seb128: Have a whole deck.
<seb128> :-(
<seb128> but yeah, checking logs, it was stgraber who said that
<didrocks> ogra_: dpm: I have list of projects not loading translations
<seb128> infinity, my apologies
<ogra_> didrocks, right, i think we should make it a policy that formerly translated code still needs to be translateable, even after a major rewrite before it lands
<didrocks> Chipaca: ask to asac, he's giving the landers card (but I think your team already have 2 ;))
<Chipaca> didrocks: from your POV, who is my team?
<didrocks> t1mp: well, I can give a look. Won't approve as discussed at UDS as you're shooting in your own feet IMHO
<didrocks> t1mp: I just want that if one day there is a regression, I don't want to have to pull whole trunk to have a fix. So the more work to get the fix will be on you
<didrocks> Chipaca: I didn't followed last tractation, but I thought you were moved to phonfundation
<didrocks> ogra_: agreed
<ogra_> (this is why i pinged asac too, not sure where we should put down such things )
<Chipaca> didrocks: at that granularity, I was teamless for a while; now I'm in "dash-server"
<t1mp> didrocks: how are we shooting in our own foot? Because we add an extra layer between the initial MP and landing in the image?
<t1mp> didrocks: I mean, you think we can have problems there that will cost us more time to fix?
<didrocks> t1mp: yeah, and no focus on getting things fixed, no automated feedback on the AP tests and so on
<didrocks> t1mp: and yeah, on the cost to fix
<t1mp> didrocks: what do you mean with automated feedback on AP tests? is that something we have now?
<didrocks> t1mp: you have in your trunk, with manual testing
<t1mp> didrocks: the standards still stay high. Before landing we run all the AP tests just like now
<didrocks> t1mp: I don't think you will afford the same testing on every commit in your trunk
<didrocks> all AP tests on all your dependencies?
<t1mp> didrocks: commit to trunk comes from the landing. You mean that we do less testing on each MP before it is approved to be merged in staging?
<didrocks> Chipaca: I'm fine with it, however, you would need some pre-training, do you think ralsina or anyone you feel close to being a lander can help there?
<ralsina> didrocks, Chipaca: haappy to help, I did a bunch of landings before
<didrocks> t1mp: right, I don't think you will be able to run manually all AP tests on all your rdependencies on every single MP + the test suite of manual tests
<ralsina> some of them even succesful! ;-)
<didrocks> ralsina: heh :)
<t1mp> didrocks: that is exactly what we are doing now for each MP
<didrocks> t1mp: you run like dialer-app AP tests for each MP?
<didrocks> t1mp: and all click apps?
<t1mp> didrocks: yes
<Chipaca> ralsina: you're a lander?
<t1mp> didrocks: we discussed that as a requirement in the SDK team, but it does not seem feasible now that's why we are discussing an alternative
<ralsina> Chipaca: I think I still am, yes
<Chipaca> :)
<didrocks> t1mp: on the device? waow, I'm unsure why we got this complain when you needed to do that at each landing then
<t1mp> didrocks: yes we do it on the device
<didrocks> t1mp: great then, I have no objection, you just do manually what the airline will do automatically
<t1mp> didrocks: maybe we are putting the standards for the MPs too high?
<t1mp> didrocks: it sounds great, but it is a big burden, especially since we decided not to top-approve an MP if not all tests pass
<didrocks> t1mp: I guess it's costly, but I prefer that the contrary :)
<t1mp> didrocks: and some times tests/apps are broken, so we are slowed down a lot in top-approving MPs
<dpm> Saviq, ogra_ bug 1297889 (I still need to find out the project for the remote scopes, though)
<ubot5> bug 1297889 in unity-scope-scopes (Ubuntu) "Add i18n support to scopes" [Undecided,New] https://launchpad.net/bugs/1297889
<ogra_> ++
<asac> ogra_: hmm. not sure if and how we should really try gating translatability. we might want to include it in the upstream checklists so the reviewers know about this.
<t1mp> didrocks: so the problem is, like this we get a backlog of MPs
<didrocks> Chipaca: gave you the rights. Please check with ralsina on the process and test plan requirements :)
<t1mp> didrocks: the idea is to relax the requirements a bit for MPs to merge into staging, so we proceed with staging, and then before landing it in image and the trunk we keep the same requirements of 100% passrate
 * Chipaca sets everything on fire
<didrocks> t1mp: what is preventing you to land all the approve one?
<Saviq> dpm, thanks
<ogra_> asac, i think its a regression if formerly translated apps come without i18n support after an update
<ogra_> asac,  so code that had it before needs to also have it after upgrade ...
<t1mp> didrocks: nothing, but because we require 100% OK before approving, we don't have approved ones now
<t1mp> didrocks: just a lot of MPs that are basically approved, but need to pass all the tests before top-approving
<didrocks> t1mp: so you lower your standards to be faster?
<ogra_> (doesnt mean there need to be translations immediately, but the gettext support, the .pot file etc should be there)
<t1mp> didrocks: for staging, we will no longer require 100% OK for all app tests if we don't have an image at that moment for which we know that all tests are OK
<t1mp> didrocks: and then when we get 100% OK for all apps in staging, we do a landing
<didrocks> t1mp: how will we not come back in a situation where you don't land anything for 2 months and half?
<t1mp> bzoltan / zsombi / kalikiana ^ please correct me if I am saying something that you don't agree with
<didrocks> which happened in the past
<t1mp> didrocks: we kind of are in that situation now, and we are thinking of ways to avoid that,
<t1mp> didrocks: so if there is no image that we can use for testing, we can still decide to approve MPs to go to staging
<didrocks> t1mp: seems you need to find a way to think why you can't land your MPs now
<didrocks> as you don't have any lock
<didrocks> or pend on us
<t1mp> didrocks: perhaps now with image 262 it will work,
<t1mp> didrocks: but the past week there was no image with which I could get 100% OK from all the tests
<didrocks> t1mp: well, as told you the other day, compare with just latest proposed image dashboard
<didrocks> t1mp: and see if you reproduce the same issues or not
<t1mp> didrocks: I was told we should use the proposed image, but there can always be some tests of which we are not sure they will pass without even having changes in UITK that we want to test
<didrocks> t1mp: you don't need to be 100%, you need to not regress the dashboard
<didrocks> meaning, each failure to be analyzed
<t1mp> didrocks: that would be relaxing our current standards of 100%.
<didrocks> if already in the proposed image -> ignore
<didrocks> t1mp: yeah, nothing into that involve using another branch though
<t1mp> didrocks: we have a lot of MPs, and we would have to analyze it for each MP? in the staging proposal, we would have to do that for each landing, not for each of the MPs that are part of the landing
<didrocks> t1mp: no, get one landing with a bunch of MP
<didrocks> test that
<didrocks> and reiterate
<Saviq> didrocks, can I have silo for row 49?
<Saviq> didrocks, in lieu of thostr I took over click scope landings
<didrocks> Saviq: sure, looking
<didrocks> Saviq: btw, any progress on the crashers?
<Saviq> didrocks, yours is still not reproducible
<Saviq> didrocks, davmor2
<t1mp> didrocks: ok, so we drop the high standards for the MPs and move those to the landing only
<didrocks> Saviq: theone in the dashboard?
<Saviq> didrocks, does not retrace
<Saviq> didrocks, /me needs to up kill timeout again...
<didrocks> Saviq: can you add a longer timeout?
<didrocks> yeah
<Saviq> didrocks, but!
<sergiusens> Mirv -> http://paste.ubuntu.com/7157039/ <- popey can you test
<didrocks> Saviq: as we have it at every image test run, it's quite high
<Saviq> didrocks, since that doesn't affect tests, I say that's an exit crash
<didrocks> sil2100: any news from bfiller on the telephony-service crash?
<didrocks> Saviq: we have one test which failed
<Saviq> in which case it'd be bug #1256360
<ubot5> bug 1256360 in Mir "unity8 crashed with SIGSEGV in glDeleteTextures() from mir::scene::GLPixelBuffer::~GLPixelBuffer() from mir::scene::ThreadedSnapshotStrategy::~ThreadedSnapshotStrategy()" [High,New] https://launchpad.net/bugs/1256360
<Saviq> didrocks, yeah, not a crash but a flakyness that we thought was fixed
<didrocks> Saviq: see 2 images ago
<didrocks> Saviq: argh
<didrocks> ok
<davmor2> Saviq, didrocks: I've not been able to reproduce it
<didrocks> Saviq: let's keep it on the radar, shall we? We'll downgrade it if we don't see more issues tomorrow, ok?
<didrocks> Saviq: still, bump the timeout
<slangasek> seb128: if it was in the trusty unapproved queue, it should still be there, shouldn't it?  A silo clean shouldn't have rights to remove packages from the unapproved queue
<didrocks> Saviq: assigned btw
<Saviq> didrocks, thanks
<Saviq> didrocks, yeah, would be nice if we had a "kill timeout none"
<slangasek> seb128: (which packages, and did this already get sorted while I was sleeping? :)
<didrocks> Saviq: +1
<Saviq> didrocks, I can't find the failed test in smoke?
<seb128> slangasek, that got sorted out thanks
<didrocks> Saviq: didn't you say you already analyzed it?
<Saviq> didrocks, yeah, but wanted to give it to Albert
<didrocks> Saviq: argh, it's been rerun, maybe vila would have the link
<seb128> slangasek, well, a silo clean does clean the ppa, or pocket copies are not actual copies for librarian pointers, so the target is cleaning and the queue item becomes buggy
<seb128> slangasek, though wgrant said it takes a week before the librarian data actually get cleared
<seb128> slangasek, so it's still ok if things are reviewed on a timelined fashion
<wgrant> Right, you have at least a week.
<didrocks> otherwise, I'll have to reuse the same tricks than for SRU
<didrocks> meaning, copying to another ppa
<slangasek> seb128: oh, right.  stupid unauditable pocket copies. :P
<didrocks> and requesting the sync from that
<didrocks> (this is the SRU mode of cu2d)
<seb128> yeah, that's what Laney suggested earlier
<didrocks> well, the code is already there just in case
<seb128> seems like the release team would like that
<didrocks> involves more complexities I guess if we kick something from unapproved and want to reland the same day
<vila> didrocks, Saviq : context ?
<didrocks> vila: the unity8 AP test failing, you mentionned you rerun it IIRC?
<didrocks> vila: do you have a link to it in any case?
<vila> on q-jenkins probably, on ci.u.c harder, let me check
<vila> didrocks, Saviq : https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/185/testReport/junit/unity8.shell.tests.test_emulators/DashAppsEmulatorTestCase/test_open_preview_Native_Device_/
<Saviq> vila, thanks
<didrocks> thanks vila ;)
<bfiller> didrocks: boiko looking at crashes, one due to qtubuntu/mir crash. he's trying to fix the indicator related crash - looks valid
<vila> . o O (I wish I understand how my memory kept track of 185...)
<Laney> didrocks: I'd hope the >7 day case is rare enough that we can reupload if that happens
<Laney> should be able to fish the code out of the tag in bzr anyways
<didrocks> bfiller: thanks! (what's the one due to qtubuntu/mir crash?)
<didrocks> Laney: yep
<bfiller> didrocks: don't know exactly, boiko can give the details
<didrocks> boiko: ? ;)
<didrocks> vila: human mysteryâ¦
<bfiller> didrocks: I believe he said dialer-app is crashing becuase mir crashes
<boiko> didrocks: let me paste the backtrace
<didrocks> oh, the dialer-app crash we have for so long?
<boiko> didrocks: not sure, might be a different one: http://paste.ubuntu.com/7157131/
<boiko> didrocks: but I would bet the root cause is the same: starting the application from command line instead of using upstart
<didrocks> boiko: interestingâ¦ I thought AP was using upstart though
<boiko> didrocks: nope, at least not for the telephony-apps
<didrocks> boiko: on silo 013, I never remember if address-book-app is click
<didrocks> boiko: ah, would make sense
<bfiller> didrocks: not yet, still a deb
<didrocks> thanks bfiller, boiko, publishing it
<boiko> didrocks: yesterday cwayne was showing me an MR to change the addressbook to be launched using upstart
<boiko> didrocks: thanks
<bfiller> boiko: I will file a bug for this MIR issue, looks to be a legimate bug
<didrocks> yw
<didrocks> (migrating now)
<boiko> bfiller: I think I will give it a try on making autopilot use upstart to launch the app
<bfiller> boiko: wouldn't that be an infrastructure change needed across all of the tests for all apps?
<didrocks> yeah, seems weird to be it needs to be defined on each app
<didrocks> the default should be to use upstart
<didrocks> with a possible override for very special cases
<boiko> bfiller: if the changes cwayne did for his address-book-app are correct, that's not really a big change
<bfiller> boiko: that stack trace you pasted was from the dialer-app.crash file?
<bfiller> didrocks, boiko, kgunn : here is a bug for the qtubuntu crash causing the dialer to crash: https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1297900
<ubot5> Ubuntu bug 1297900 in qtubuntu (Ubuntu) "crash QUbuntu: Could not create application instance" [Undecided,New]
<bfiller> note, this seems to be a different issue than the previous mir related crashes that were causing dialer to crash
<didrocks> bfiller: ah, interesting, so do you think it should be in a high priority list?
<didrocks> or do we put that as the other dialer-app crash "don't impact user experience, so no mention"
<bfiller> didrocks: well, I think it's high priority in that it possible would affect all apps during launching
<didrocks> ok, noting it down then
<bfiller> didrocks: not specific to dialer, but a platform bug that should be addressed I think
<didrocks> bfiller: yeah, understood
<davmor2> didrocks, Saviq: jfunk has agreed that the header issue shouldn't be a blocker as long as the bug remains tracked and isn't an issue in the new header code, so treat it as a bug against the new header.
<bfiller> didrocks: the good news is that on the device itself apps are launched via upstart-app-launch and won't go through this code path I believe
<didrocks> bfiller: yeah, so just high priority, not blocker
<bfiller> didrocks: yup
<didrocks> davmor2: so, he's going to track it?
<davmor2> didrocks: well I'll possibly need to track it and test it on the new header but yes it will be monitored
<didrocks> ok
<sil2100> dbarth: just one merge in the landing :o ?
<doanac> sergiusens: looking good for the first autopilot test: http://q-jenkins:8080/job/andy-smoke-daily-test/ws/clientlogs/friends_app/test_results.xml/*view*/
<doanac> based on my simple computer science experience if it works for x=1, it should work for x=infinity :)
<doanac> i'll let you know when its done though
<sergiusens> doanac, the concerning ones are music, calendar and gallery iirc; good to know it didn't break
<sergiusens> doanac, not sure if after this runs you want to do some subunit things
<doanac> sergiusens: yep. i'll start working on using subunit in our daily image testing after we get this landed
<tvoss> Mirv, the build succeeded \o/
<didrocks> ogra_: if you continue to troll on the ML, I'm about the send the "let's do a pool" argument!
<ogra_> haha
<dbarth> sil2100: ok, good now
<dbarth> sil2100: yes, just 1
<sil2100> dbarth: let me see if we can assign
<sil2100> tvoss: publishing then ;)
<sil2100> dbarth: in the meantime, please include some test plans for the landing :)
<sergiusens> popey, hey, sorry for reping, but did you see my message about a new gallery in the store?
<popey> sergiusens: i did not
<popey> so thank you
<dbarth> sil2100: yeah, the test plan must be huge, but i will put something together
<tvoss> sil2100, thx
<sil2100> dbarth: ok ;) If anything, a silo is assigned
<sergiusens> popey, then Mirv might have not see it either :-)
<dbarth> sil2100: saw that; thanks a lot
<didrocks> bfiller: I didn't get an update on bug #1297395 btw
<ubot5> bug 1297395 in mediaplayer-app (Ubuntu) "mediaplayer-app crashed with SIGABRT in __libc_do_syscall()" [Medium,Confirmed] https://launchpad.net/bugs/1297395
<didrocks> bfiller: do you think it's the same qtubuntu one?
<sergiusens> robru, double question; can you review the MR in line 50 and also provide a silo?
<davmor2> am I the only one that is now tired of not being able to hear calls cause the volume was turned down for the Music app.  Please can we have different volumes for all the sections pretty please :D
<sil2100> sergiusens: it's a new package, yes?
<sergiusens> sil2100, yes
<sil2100> sergiusens: not sure if robru is around yet - in the meantime I'll take a look at the packaging as well
<bfiller> didrocks: haven't looked at this yet
<didrocks> bfiller: ok, keeping on the list, feel free to answer on it
<bfiller> didrocks: will look into it today
<didrocks> sure, thanks!
<sil2100> sergiusens: commented on two issues that I noticed on first glance - thanks!
<sergiusens> thanks, will look
<sergiusens> sil2100, how do I demangle symbols?
<sergiusens> c++filt I know
<sergiusens> but in one shot
<sil2100> sergiusens: I have a nice line prepared for that, one moment
<didrocks> and it's in the wiki!
<sil2100> sed 's/ \(_.*\) \(.*\)/ (c++)"\1" \2/' symbols | c++filt >new_symbols (I use this)
<sergiusens> didrocks, yeah, I give that reply and it never works ;-)
<sergiusens> :-P
<sil2100> sergiusens: I also commented on the branch with a proposition more to the upstream about restricting which symbols they export ;p
<sil2100> sergiusens: since I see the symbols files are huge, not sure if we need all of those visible to the whole world!
<davmor2> sil2100: man that sed has such glinty eyes
<sil2100> It also makes managing symbols files much easier
<sergiusens> sil2100, that's jhodapp's problem I asked him about that and he said it should be abi stable
<sil2100> sergiusens: yeah, indeed that's why I mentioned it's more of a proposition for upstream, but still
<sergiusens> sil2100, yeah, I understand, it's going to be his problem and he will likely fix it if it comes to it
<sergiusens> sil2100, ok, I've pushed, thanks; let's wait for the bot to say I didn't screw up those symbols
<sil2100> sergiusens: ok, thanks for the fixes! I'll double check again, but I guess otherwise the packaging looks ok
<popey> sergiusens: approved gallery
<sil2100> tvoss: hi! So, regarding that process-cpp landing - there was no ABI break, right?
<sil2100> tvoss: just the soname got bumped?
<tvoss> sil2100, there was an ABI break, but no one used that API thus far
<tvoss> sil2100, that's why I bumped the so name
<sil2100> tvoss: since sadly, I discussed it with Mirv right now on what tests he did, and I think sadly we'll have to add to the silo some no-change rebuilds of all the rdeps for this package
<tvoss> sil2100, I discussed that with cjwatson, too
<tvoss> sil2100, why would we have to trigger the rebuilds if things still work? we tested it from Mirv's ppa
<sil2100> tvoss: what was his opinion on this? He also thinks it's needed? Since from my understanding, if I'm thinking correctly, this might lead to a situation where all the rdeps will be uninstallable
<sil2100> tvoss: since basically libprocess-cpp0 stops existing in the archive, and now dbus-cpp and the others are still depending on that package, can't find it and cannot be installed
<sil2100> tvoss: Mirv said he used his PPA with no-change rebuilds of all rdeps
<tvoss> sil2100, okay, I asked for that and people told me that there is no need for the rebuilds
<sil2100> So basically his PPA had the thing that we would need to have in the archive, I guess
<sil2100> hmm... I might misunderstand something, but I think this is how it would logically work
<tvoss> sil2100, okay, so we need empty mp's for all rdeps?
<sil2100> didrocks: ^ can you help me and tell me if I understand correctly? ;p
<sil2100> tvoss: probably, but let's wait for a packaging-master to comment, since Mirv also agreed on my concerns but we're both a bit weary
<didrocks> sil2100: I'm in a meeting
<didrocks> so just do what you think is the best
<sil2100> ACK ;)
<boiko> bfiller: sorry, I went for lunch, yes, it is from the dialer-app crash file
<sil2100> sergiusens: well, it seems that the package doesn't want to build on my system when using bzr bd - symbols file problem
<davmor2> popey: install an app and see if it is still listed in the Available section
<didrocks> sil2100: will stay in meeting, please lead that one
<sil2100> didrocks: ok
<sergiusens> sil2100, yeah, demangling broke
<sergiusens> sil2100, same can be seen on ci
<sergiusens> sil2100, can I just revert the demangling?
<sergiusens> didrocks, ^^
 * sergiusens doesn't like this part
<sil2100> C++ symbols are really a PITA to tell the truth, I think non-demangled symbols would result in a NACK from core devs though
<sil2100> sergiusens: who's upstream for this?
<sergiusens> jhodapp
<sergiusens> sil2100, the qt landings have non demangled symbols though
<cjwatson> The more I read the C++ FQA (sic) the more I think providing C++ interfaces at all is a mistake :-)
<cjwatson> (Not that I expect people to agree)
<robru> sil2100, didrocks: I have to step out, will be back in ~30 minutes. feel free to email me with anything you want me to take care of
<sil2100> sergiusens: you would have to ask some core dev if it's ok to provide mangled names in symbols files, but I would certainly not want something like that - I would opt for poking upstream, getting a nice symbols map and exporting only needed demangled symbols
<sil2100> robru: ok
<sergiusens> heh; while c++ is nice to write, it's really hard infra wise
<sergiusens> sil2100, well rsalveti gave me a review and said it was ok; he's a core dev
<sil2100> cjwatson, sergiusens: I noticed that once you restrict what you export in C++ then the symbols can be a bit less painfull ;)
<cjwatson> Absolutely
<sil2100> Ok then, I guess we can proceed with reverting the demangling
<cjwatson> Good idea in any library of course, it's just more obvious in C++
<sergiusens> sil2100, can you guide jim into doing that?
<sil2100> sergiusens: sure, let me send him an e-mail
<sil2100> We can take care of that in a separate landing then, I won't argue with a decision of a core-dev ;)
<sil2100> didrocks: so, from our meeting - a bug worth mentioning in our landing e-mail: https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1297965
<ubot5> Ubuntu bug 1297965 in unity-scope-click (Ubuntu) "If I install an app it still shows in Available section" [Undecided,Confirmed]
<sil2100> didrocks: Alan found another one that might be related: #1297436
<didrocks> ok
<sil2100> oh, ubot5 didn't react
<sil2100> LP: #1297436
<didrocks> sil2100: who is working on it?
<ubot5> Launchpad bug 1297436 in unity-scope-click (Ubuntu) "Blank preview when click not on store server" [High,Triaged] https://launchpad.net/bugs/1297436
<sil2100> didrocks: no one yet, proceeding to ping someone, it was filled in during the meeting
<didrocks> ok
<didrocks> sil2100: last upload did that?
<sil2100> didrocks: we're suspecting it has something to do with the scopes transition
<sil2100> davmor2: did you try bisecting when it appeared?
<didrocks> sil2100: ping pawel
<sil2100> didrocks: ok, it seems a fix for that bug is in the works, dobey knows about it and alecu has a branch fixing that in-progress
<boiko> didrocks: hey, so on silo landing-013 I have this message that account-plugins is in the UNAPPROVED queue, do I have to take any action on that?
<dobey> huh?
<sil2100> boiko: no, sadly, it's because of the beta freeze
<sil2100> boiko: we have to wait - we can force a release of the silo if needed, but we're only doing that when there is some high-priority needs
<sil2100> boiko: let me check the landing in mention
<boiko> sil2100: I just wanted to merge the changes on address-book-app and address-book-service to their respective trunks
<didrocks> boiko: or you can bribe the release team
<boiko> didrocks: that depends on how desperate renato is to get his stuff landed :)
<sil2100> ;)
<didrocks> heh
<didrocks> boiko: #ubuntu-release for such requests
<boiko> didrocks: ok, I will join there and ask
<boiko> thanks
<didrocks> yw
<didrocks> boiko: if you commit to really look at it, you can m&c with "ignore package in dest"
<didrocks> boiko: but please, look if it's getting block anywhere for no reason
<boiko> didrocks: sil2100: so, just to make sure, the address-book-{app,service} upload was ok, right? it is only the account-plugins that is unapproved
* fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: fginther | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<sil2100> boiko: yes, everything else landed in the archive
<didrocks> boiko: right!, those should have go to the destination if it doesn't say anything about it
<didrocks> boiko: they are fine without account-plugins btw?
<sil2100> boiko: just this one is in the unapproved queue
<boiko> didrocks: yes, they are
<boiko> didrocks: the account-plugins change is going to be needed later when we merge contact syncing support
<didrocks> ok, feel free to run "m&c with "ignore package in dest"
<boiko> didrocks: yep, will do
<boiko> didrocks: sil2100: thanks
<sil2100> boiko: just be sure to look at if it gets blocked somewhere or not later :)
<didrocks> boiko: don't overuse that option please :p
<sil2100> After the freeze
<boiko> didrocks: up to now I didn't even knew it was possible, and sure I don't plan to overuse that :)
<boiko> until when the freeze is going to be in effect?
<didrocks> boiko: if you have stuff blocked in UNAPPROVE and you know that the rest which transition is fine
<sergiusens> sil2100, can we get a testing landing silo for jhodapp even if the MRs aren't final?
<rsalveti> sergiusens: guess we can get a silo with the mrs we currently have
<rsalveti> and keep iterating that once we get the other ones
<rsalveti> they will be around later today afaik anyway
<rsalveti> reconfigure && build for every additional mr we get
<sergiusens> rsalveti, yeah, I can't reconfigure when new projects (trunk/source packages) show up; but that's the gist of it
<robru> hooray!
<rsalveti> sergiusens: I can, just ping me
<rsalveti> at least I could last time I tried
<rsalveti> but we have robru :-)
<rsalveti> he's like a landing machine
<robru> rsalveti: sure am! what needs doing?
<rsalveti> robru: nothing now, but might need help reconfiguring a silo later today
<sergiusens> rsalveti, robru well we can get one assigned for starters :-)
<robru> rsalveti: sure just ping me. I'll try to be responsive (I'm currently on a network that is blocking IRC, so I'm using the web client, so I may not see pings as promptly as I normally do)
<rsalveti> sergiusens: at https://code.launchpad.net/~sergiusens/media-hub/packaging/+merge/209926, don't we need to change the changelog version entry to be compatible with CI as well?
<t1mp> plars: I see the --no-provision landed :)
<rsalveti> like we had for ofono
<plars> t1mp: yep
<sergiusens> rsalveti, it already is; ci train adds the +$(date) by itself
<rsalveti> sergiusens: got it, great then
<t1mp> plars: ok, I'll try it now.
<t1mp> plars: provisioning now. When its done, I install the debs from the MR, and then I try run-smoke. Still have to see which parameters to use
<t1mp> kalikiana: ^
<didrocks> robru: btw, in case sil2100 didn't mention itâ¦
<didrocks> robru: the bug in CI Train was covered by test
<robru> yes?
<t1mp> plars: ImportError: No module named yaml
<didrocks> but dch changed between precise and trusty
<t1mp> plars: do I need python-yaml or python3-yaml?
<didrocks> and of course, I run the tests on my machine :p
<robru> didrocks: ahhhhhh
<didrocks> so the fix is in, not deployed (as trunk contains the requestid change)
<didrocks> which is all ready
<didrocks> spreadsheet-side as well
<didrocks> just not enabled
<didrocks> and I won't do that and bye bye :)
<didrocks> so my tomorrow morning :)
<robru> didrocks: good call
<plars> t1mp: python-yaml, but I think you might also need utah-client
<didrocks> robru: supposively, the change will result in:
<didrocks> - display an ID
<didrocks> - you copy and paste that ID
<sergiusens> didrocks, you need to start using golang :-)
<sergiusens> lol
<didrocks> if you reconfigure a silo:
<didrocks> - just click on the build
<plars> t1mp: I don't recall for sure, I know you need utah though
<didrocks> nothing else needed :p
<didrocks> sergiusens: yeah, I'll do that for the bot :)
<robru> didrocks: humm, still copy&paste? well as long as the ID is displayed without quotes the copy&paste will be easier ;-)
<plars> t1mp: you can try just python-yaml first if you like
<sergiusens> no abi breakage, symbol exposure issue or where did I build and run issue
<sergiusens> so much easier to back port a package
<didrocks> robru: yeah, unfortunately, still no plugin to "inject" that
<plars> t1mp: I know at one time utah-client was needed for the utah (non-autopilot) tests though
<t1mp> plars: what is the difference between run-smoke and run-autopilot-tests?
<plars> t1mp: run-smoke handles the whole process, run-autopilot-tests does... just the individual autopilot tests
<t1mp> plars: ./run-smoke --help at least doesn't say it needs yaml
<plars> t1mp: it imports it
<t1mp> plars: how/where do I get utah? I don't see a package in the archive
<plars> t1mp: ppa:utah/daily
<plars> t1mp: sorry, I mean ppa:utah/stable
<plars> t1mp: I doubt there would be much difference, but you just need the stable one
<t1mp> kalikiana: ^fyi, the provision.sh script is downloading the autopilot tests from lp for me :)
<sergiusens> robru, rsalveti ok, can we get a silo setup for line 50 then?
<robru> sergiusens: sure
<t1mp> kalikiana: I started with this ./provision.sh -n ~/network-manager-conf -w
<jhodapp> thanks robru
<robru> sergiusens: ok, got you silo 6. for future reference, please space-separate the list of packages (just like the MP list, it needs to be copy&pasted into a jenkins form that parses based on spaces)
<robru> jhodapp: you're welcome
<t1mp> plars: ./run-smoke adds the --no-provision option, but in ./run-smoke --help that option is not listed
<t1mp> plars: is that intentional?
<jhodapp> sergiusens, you might want to add a comment that says to land libhybris and gst-plugins-bad first
<doanac> sergiusens: the silo test completed for phablet-tools: http://q-jenkins:8080/job/andy-smoke-daily-test/4/
<doanac> seems pretty good
<rsalveti> jhodapp: why first, will it fail if not there?
<jhodapp> rsalveti, yes
<rsalveti> if so, then we need to bump the build-dep version requirement for them
<rsalveti> in a way that they will not be built because the latest libhybris and gst packages are not there yet
<jhodapp> rsalveti, makes sense
<plars> t1mp: it should be there, are you sure your bzr tree is up to date?
<plars> t1mp: I see it in --help with mine
<jhodapp> rsalveti, there's a tool to bump that right, I forget what it's called
<sergiusens> jhodapp, I'm actually in charge of that and have your list
<jhodapp> sergiusens, ok cool
<jhodapp> thanks
<rsalveti> jhodapp: you need to change debian/control and add that build version requirement in there
<rsalveti> for whatever packages that are depending on libhybris and gst-bad
<t1mp> plars: you are right, I am blind
<sergiusens> doanac, are those two failures just random ones?
<t1mp> it is there
<kgunn> robru: hey...after some discussion, i'm giving up line 40 (which is using silo16)....we decided to do it later with some other mp's post beta
<kgunn> not sure what the protocol is there....
<sergiusens> doanac, seems so to me
<jhodapp> sergiusens, need me to do that?
<t1mp> plars: I installed utah-client, but I still get a failure: http://pastebin.ubuntu.com/7158414/
<robru> kgunn: ahh, thank you
<sergiusens> jhodapp, do what? sorry, context switching is broken for me :-)
<jhodapp> sergiusens, from what rsalveti said: "if so, then we need to bump the build-dep version requirement for them
<jhodapp>  in a way that they will not be built because the latest libhybris and gst packages are not there yet"
<sergiusens> robru, you'll be happy to hear we are close to landing silo 10
<robru> sergiusens: always happy to hear from you!
<rsalveti> sergiusens: build version requirements for whatever packages that are depending on a newer hybris/gst
<rsalveti> in debian/control
<plars> t1mp: looks like you installed utah-client, but not utah
<sergiusens> jhodapp, yeah, that's not in the branch I have control over (media-hub) but the other ones
<t1mp> plars: I'll install utah-all then
<jhodapp> sergiusens, ok
<sergiusens> rsalveti, yeah, media-hub doesn't depend on hybris
<jhodapp> sergiusens, actually it does
<robru> sergiusens: just a heads up: you might run into a snag with silo 6 because you're attempting to rename the source package. in the past I've seen citrain not deal well with that. give it a shot for now, but you might end up having to push the source package rename directly to trunk first, then rebuild in the silo
<sergiusens> robru, if it comes to it, I'll wipe the changelog completely; music-hub never landed in archives
<sergiusens> robru, oh, I see what you mean
<sergiusens> robru, I'll manually merge it and use the second MR proposed
<sergiusens> jhodapp, I don't see any hybris packages in build-depends for media-hub
<robru> sergiusens: yeah, you might have to.
<t1mp> plars: it is still failing IOError: [Errno 2] No such file or directory: '/home/tim/dev/ubuntu-test-cases/touch/scripts/clientlogs/all/utah.yaml'
<jhodapp> sergiusens, yeah it needs to be added, libhybris-dev
<t1mp> plars: after I installed utah-all
<sergiusens> jhodapp, I'll wait for rsalveti's version of choice then
<t1mp> plars: is something missing? http://pastebin.ubuntu.com/7158446/
<jhodapp> sergiusens, you could just say the version > what is currently built for trusty
<plars> t1mp: 'ALL' is case sensitive i think
<t1mp> plars: I think I'm calling it wrong tim@ideapad:~/dev/ubuntu-test-cases/touch/scripts$ TESTS=all APPS=all ./run-smoke --no-provision
<t1mp> plars: so TESTS=ALL APPS=ALL ./run-smoke ?
<rsalveti> sergiusens: just put current+1
<rsalveti> ubuntuX where x = previous + 1
<plars> t1mp: -n
<plars> :)
<sergiusens> rsalveti, ack; there's no hurry anyways; it needs to build in the silo as well
<rsalveti> true
<t1mp> plars: ok, let's try that :)
<plars> t1mp: doesn't apply to you in this situation obviously, but if you do ever want to run without -n and have it provision for you, make sure that you have ubuntu-device-flash installed. It uses that instead of phablet-flash now
<t1mp> plars: cool.
<sergiusens> robru, https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=28
<t1mp> plars: I've been using ubuntu-device-flash for a while already :)
<sergiusens> robru, please take a look at the link tests as well
<sergiusens> robru, but there is no better test than a full ci run
<sergiusens> :-)
<robru> sergiusens: oh I agree! ;-)
<sergiusens> takes like 6 hours though :-P
<jhodapp> sergiusens, you can use this for media-hub, I just tested it: libhybris-dev (>= 0.1.0+git20131207+e452e83-0ubuntu13)
<jhodapp> sergiusens, I'll let you make that change to your branch, and I'll make the proper changes in the other branches
<sergiusens> jhodapp, yeah, just wait for it; I need to manually merge mine anyways
<jhodapp> sergiusens, that cool, we can change media-hub when you're ready then
<jhodapp> sergiusens, the other ones are almost updated
<robru> sergiusens: published
<t1mp> plars: there still seems to be a problem with utah :s http://pastebin.ubuntu.com/7158497/
<jhodapp> rsalveti, so the correct version of gst-plugins-bad will need to be seeded, there's no build-dep version to check for for that
<rsalveti> jhodapp: it's already seeded, so no worries, if not needed for build-time, then we're good
<jhodapp> rsalveti, right, ok
<sergiusens> robru, thanks
<jhodapp> rsalveti, how about gst-plugins-bad having the right libhyris-dev?
<sergiusens> robru, now I'm not holding the oldest silo anymore :-)
<rsalveti> jhodapp: that I'll change when uploading both to the silo ppa
<jhodapp> rsalveti, ok excellent, thanks
<t1mp> plars: shouldn't the script create the the utah.yaml file?
<robru> sergiusens: ;-)
<plars> t1mp: yeah, but utah is crashing for some reason before it gets there: OSError: [Errno 2] No such file or directory: '/var/cache/utah/autorun/inprogress'
<plars> t1mp: "it works on my machine" :)
<plars> t1mp: my best guess is there's some sort of utah setup step you're missing, doanac any ideas? http://pastebin.ubuntu.com/7158497/ is what he's seeing
<jhodapp> sergiusens, ok, other than the media-hub libhyris build-dep update and the one rsalveti will do for gst-plugins-bad depending on libhyris-dev, the other packages should be ready
<plars> oh
<rsalveti> alright
<doanac> t1mp, plars: is utah installed on this system?
<t1mp> plars, doanac I'm running the script without root priviliges
<doanac> if TESTS=ALL you'll need utah.
<t1mp> doanac: yes utah: Installed: 0.15+20140305~ubuntu14.04.1
<plars> doanac: I believe he's installed both utah and utah-client
<plars> t1mp: so am I
<doanac> t1mp: I think utah might need to be run as root
<plars> doanac: I think that's why it prompts him for sudo though
<t1mp> doanac: http://pastebin.ubuntu.com/7158497/ line 41
<t1mp> will it ask the password more ofteh?
<t1mp> *ofthen
<t1mp> *often
<t1mp> :s
<t1mp> :)
<t1mp> I'll try  sudo TESTS=ALL APPS=ALL ./run-smoke --no-provision
<doanac> i bet that doesn't fix it
<doanac> i'm thinking you are missing a utah package
<t1mp> I installed utah-all
<doanac> or you need to create this directory by hand: /var/cache/utah/autorun/inprogress
<t1mp> same error with sudo
<plars> doanac: I don't have that dir either, but it doesn't complain about it with me
<plars> so I'm not sure why it's looking for it
<t1mp> plars: did you try with TESTS=ALL APPS=AL and -n ?
<plars> t1mp: yep
<plars> oh, hang on
<t1mp> *APPS=ALL
<plars> t1mp: did you provision your device with provision.sh before making the modifications?
<t1mp> plars: yes, first I ran provision.sh, and then I installed some deb files
<t1mp> mkdir -p  /var/cache/utah/autorun/inprogress seems to help
<t1mp> something is running now
<boiko> robru: hey, is it known that sometimes the MRs are not marked as merged after clicking merge and clean?
<doanac> plars: nuclearbob recently made some client changes to utah near that area. I wonder if it now requires that directory and you and I are just on an older utah
<plars> oh
<plars> yeah t1mp you are on a much newer utah than me - I guess you got the daily after all?
<robru> boiko: no? it doesn't happen immediately...
<boiko> robru: it landed two hours ago
<t1mp> plars: sudo apt-add-repository  ppa:utah/stable && sudo apt-get install utah-all
<boiko> robru: only one of the MRs didn't get marked as merged, the other ones are OK
<boiko> robru: the code got merged though
<t1mp> I'll need to tweak the script probably for our use case. I don't need to run the idle tests that are running now
<t1mp> but first lets see if everything works without additional parameters/changes :)
<boiko> robru: no big deal, just checking if you want to debug something before I manually mark it as merged
<plars> I think maybe I'm just on the one I had before upgrading to trusty on this box
<boiko> robru: it is the https://code.launchpad.net/~renatofilho/address-book-app/optimize-app/+merge/210199 MR from row 17
<robru> boiko: did anything unusual happen, like was there a reconfig that dropped that MR? one MR merged into another MR or something?
<boiko> robru: nope, not that I know of, just regular MR dependency
<plars> t1mp: did you try just creating the directory?
<boiko> robru: if that's of no use for debugging, I can just mark it as merged manually
<t1mp> plars: yes I created the directory, and now the tests are working
<t1mp> plars: 20:30:50 < t1mp> mkdir -p  /var/cache/utah/autorun/inprogress seems to help
<plars> t1mp: ok, sounds like a bug in recent utah versions then
<plars> t1mp: let me know if you run into any more issues
<t1mp> plars: shall I report the bug or will you?
<plars> t1mp: if you could file one, that would be great
<robru> boiko: yeah just mark it merged for now. how often does it happen? just the once?
<boiko> robru: first time this happened since I started landing stuff using the CI train
<t1mp> ~/dev/ubuntu-test-cases/touch/scripts/clientlogs/ is filling up.. next challenge is how to parse all the log files to see what passed/failed
<robru> boiko: first guess would be that it's more a bug in launchpad. i don't think citrain has any code for explicitely marking branches as merged. my understanding is that citrain just merges the branches and then launchpad is the one that notices the merge commit and marks the MP merged.
<robru> boiko: or at least, the few odd times I've done manual merges, lp automatically mared the MPs for me after I pushed the merge commit, so I assume the same applies to jenkins/citrain
<boiko> robru: ah ok, got it, yeah, now that you mentioned, I remember having MRs marked as merged automatically in launchpad
<t1mp> plars: https://bugs.launchpad.net/utah/+bug/1298026
<ubot5> Ubuntu bug 1298026 in UTAH "/var/cache/utah/autorun/inprogress needs to be manually created" [Undecided,New]
<boiko> robru: btw, I have just added line 52 to the spreadsheet, whenever you get a free silo, would you mind assigning it?
<robru> boiko: sure thing!
<robru> boiko: ok you got silo 12
<t1mp> plars: is my pipeline correct? if I use provision.sh and then install UITK deb files, and then run-smoke, will all the AP tests be ran against the UITK version that I installed? Or will something be overwritten?
<boiko> robru: thanks!
<robru> boiko: you're welcome!
<t1mp> plars: and the UITK AP tests come from the ubuntu-ui-toolkit-autopilot package that is installed on the system right? Or from lp or a click package?
<plars> t1mp: hmm, well the toolkit tests do try to install (and thus remove) the autopilot tests for u1tk - ubuntu-ui-toolkit-autopilot
<plars> t1mp: hopefully that won't affect you?
<t1mp> plars: I installed ubuntu-ui-toolkit-autopilot myself, so I like to use that version
<plars> t1mp: will the version in the archive supersede it? or does yours have a higher version number
<t1mp> plars: I installed ubuntu-ui-toolkit-autopilot_0.1.46+14.04.20140321.1bzr948pkg0trusty892-0ubuntu1_all.deb
<plars> t1mp: as long as yours has a higher version number, then I would think that apt-get install ubuntu-ui-toolkit-autopilot would just do nothing
<plars> t1mp: otherwise, you'll get "upgraded"
<t1mp> plars: currently I have this on the device http://pastebin.ubuntu.com/7158704/
<t1mp> it looks like I still have the versions matching the .debs that I downloaded
<t1mp> so if 20140321.1bzr938... > 20140321.1-ubuntu1 I think I'm safe
<t1mp> IF that is the case. Seems logical but I'm not sure if b > -
<t1mp> plars: do you know how long a full test run like this will take?
<plars> t1mp: ~3 hours
<plars> t1mp: one thing to be aware of, even if your package doesn't get upgraded, it will get uninstalled after the toolkit tests run
<sergiusens> robru, hey, upon reconfiguring I now get this http://162.213.34.102/job/landing-006-0-reconfigure/18/console
<plars> t1mp: you may want to run *just* those tests after reinstalling and watch it very carefully
<sergiusens> robru, ah it seems it was never configured (from the prior build logs)
<t1mp> plars: oh, ok
<t1mp> plars: after the toolkit tests finished I don't need them anymore... but
<t1mp> plars: the other tests use the uitk-autopilot emulators. Are those part of the uitk-autopilot package?
<robru> sergiusens: yeah, that looks like what I mean about the source package rename not working. did you merge the MP manually yet?
<plars> t1mp: no idea
<robru> sergiusens: ok, looks good after a reconfigure. please build
<sergiusens> robru, yup, that's what I did, reason I wanted to reconfig :-)
<sergiusens> robru, just did m&c on silo 10
<robru> sergiusens: sweeeeeet, thanks
<boiko> robru: landing-012 tested
<robru> boiko: thanks!
<robru> boiko: published!
<boiko> robru: thanks!
<robru> boiko: you're welcome ;-)
<robru> boiko: please merge & clean silo 12 ;-)
<boiko> robru: yep, I was just waiting for rmadison to show the right version on trusty
<boiko> (not sure it is really necessary to wait for that, but in any case)
<robru> boiko: nope, citrain goes by what launchpad says, it's only necessary to wait for rmadison if you are intending to kick an image build shortly after and you want the new image to include your recently published silo. as I learned the hard way with image #257 ;-)
<boiko> robru: ah ok, got it, thanks :D
<robru> boiko: you're welcome!
<boiko> robru: well, I will keep on watching rmadison anyways, as I want to rebuild some messaging-app jenkins jobs using this version of history-service
<robru> boiko: ah, no worries
<robru> boiko: we're not crunched on silos like i was afraid we'd be
<boiko> robru: I guess people are rebasing/retesting stuff before submitting
<boiko> (at least that's what is happening in the apps team)
<boiko> robru: silo being cleaned already
<sergiusens> robru, I have a fast track landing; is there a bullet train :-P
<sergiusens> robru, kidding, but would be good to get phablet-tools/line 53 a silo
<robru> sergiusens: you better believe it! (well, aside from the beta freeze that's outside my control)
<robru> sergiusens: ok, you got silo 10
<robru> boiko: thanks
<boiko> robru: you're welcome!
<sergiusens> robru, heh, phablet-tools is trending on silo 10
<robru> sergiusens: it's a happy place.
<robru> alright everybody, I'm off for dinner, should be back in 3-4 hours, if anybody needs anything just shoot me an email and I'll get back to it later tonight.
#ubuntu-ci-eng 2014-03-27
<sergiusens> rsalveti, cyphermox, you around, need someone to publish https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=28
 * rsalveti checks
<rsalveti> looks fine, didn't test, but you tested it :-)
<sergiusens> rsalveti, I did as ogra_
<rsalveti> great
<rsalveti> sergiusens: done
<sergiusens> ty
* fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<imgbot> === trainguard: IMAGE 263 building (started: 20140327-03:05) ===
<imgbot> === trainguard: IMAGE 263 DONE (finished: 20140327-04:25) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/263.changes ===
<robru> rsalveti, gave you silo 12
<rsalveti> robru: thanks
<robru> rsalveti, you're welcome
<veebers> robru: hey would you have a moment to help me with a silo reconfig?
<robru> veebers, absolutely!
<veebers> robru: awesome thanks :-) I have update the MPs on line 21
<veebers> (as well as updating the description as requested)
<robru> veebers, is it all just autopilot? any new projects there?
<veebers> robru: no, just autopilot
<robru> veebers, ok, you should be able to take care of that yourself. have you been trained on the reconfig job?
<veebers> robru: ah right. No I haven't been trained to use it
<robru> veebers, ok i'll give you a crash course
<veebers> robru: do you mind stepping me through it now?
<veebers> awesome cheers
<robru> veebers, so in the spreadsheet, you'll see you're in silo 3. if you go to the 'landing-003' tab at the bottom of the spreadsheet, there'll be a bunch of big yellow buttons
<veebers> robru: right, I'll go to reconfigure
<robru> veebers, just remember you have to copy & paste the merge URLs into the reconfig job
<veebers> robru: ah I see. I need to put the MRs there
<robru> veebers, yeah
<veebers> robru: do I need anything in the sources param?
<robru> veebers, so that should work as long as you're not adding a new project that wasn't assigned to the silo before. if you need to add a new project, then it requires my help
<robru> veebers, not in this case. sources is only for things that aren't hosted on lp where you might want to do a manual upload (such as xorg or android)
<veebers> robru: right makes sense.
<veebers> robru: thanks for that, I have used the train before, just not the reconfig. I guess I could have figured it out myself, but didn't want to break anything :-)
<robru> veebers, just let me know if you have permission to do the config job. I don't have access to change the ACL so if it doesn't work for you, we need to ping didrocks and I'll just take care of the reconfig for right now
<veebers> ugh, why doesn't it ask me for permissions _before_ I can see the jenkins job page :-\
<veebers> robru: seems I have perms ok (I'm just watching the console output now)
<robru> veebers, yeah, that bites me all the time. sorry :-/
<veebers> heh no worries :-)
<veebers> robru: as soon as that config job is done I'm good to go and build etc. right?
<robru> veebers, yep. it might take a second to update the status in the spreadsheet, but that doesn't even matter. as long as the jenkins job says it's done, you can start the build job right after that (the script that updates the statuses in the spreadsheet has some lag, don't wait around for the spreadsheet if you care about efficiency)
<veebers> robru: awesome, thanks again for the help
<robru> veebers, you're welcome!
<Mirv> morning
<robru> Mirv, ah, you're here! goodnight ;-)
<Mirv> :)
<didrocks> Mirv: hey, FYI, don't assign any silo right now, I'm pushing the ID transition
<Mirv> ok
<didrocks> backend done, moving frontend
<tvoss|afk> good morning
<didrocks> frontend and sync available
<Mirv> didrocks: so, I could try assigning a silo now?
<didrocks> Mirv: I'm trying to assign some and see if there are any bugs before giving you the green light :)
<Mirv> ok :)
<sil2100> Are we migrated to the new way of silo assigment? ;)
<Mirv> sil2100: tests ongoing
<sil2100> \o/
<didrocks> grrr, as there was a bug spawning with writes, it doesn't want to execute any other script now :(
<Saviq> didrocks, hey, wecanhassilo for row 56 please?
<Mirv> Saviq: not before didrocks gets less grrr
<didrocks> Saviq: let me attribute it to you, this part is working
<didrocks> Saviq: however, you won't get status feedback for now
<Saviq> uh oh
<Saviq> didrocks, thanks, will manage
<didrocks> Saviq: landing-013
<Saviq> didrocks, thanks
<didrocks> frustrating, I introduced the bug when adding debugging :/
 * ToyKeeper hugs chrome's "tabs outliner" add-on...  makes it so much easier to keep track of bugs which need re-testing!
<didrocks> Saviq: status refresh are back!
 * didrocks just need to fix one bug (so 2 bugs for 500 lines rewrites, not bad)
<didrocks> auto assignement/removal works
<sil2100> \o/
<sil2100> So, when can we give it a spin too :D ?
<Saviq> sil2100, icanhassilo for row 57?
<sil2100> didrocks: can I try it out? ^
<tvoss> sil2100, I did an exploratory testing with silo 14, looks good
<sil2100> tvoss: I'm rebooting my phone now with those changes
<tvoss> sil2100, great :)
<tvoss> sil2100, once you are happy, I will set to testing -> yes
<didrocks> sil2100: sure, you can :)
 * sil2100 assigns!
<sil2100> Woooo
<didrocks> working all fine? :)
<sil2100> Yes! Almost thought that something's wrong with assigning the silo in the spreadsheet, but it finally updated \o/ It's awesome!
<sil2100> Saviq: assigned, silo 10
<didrocks> sil2100: well, there is the 2 minutes delay at most to get infos from the backend
<Saviq> sil2100, cools, what's new?
<didrocks> Saviq: basically, no need to copy and paste all MPs ans sources, only a request id (and no need to reassign manually on the frontend the selected silo by the backend)
<Saviq> didrocks, does that affect us (when reconfiguring), too?
<didrocks> Saviq: it's quite a big change in the whole spreadsheet logic for this
<Saviq> yup
<didrocks> Saviq: for now, you will need to get the request id
<didrocks> I'll change that after the landing meeting
<didrocks> so that it's automagic
<Saviq> okies cool
<didrocks> so basically, you will just have to press "build"
<didrocks> Saviq: FYI, siloMatrix is dead
<didrocks> the whole assignement is in the pending spreadsheet
 * didrocks removed ~120 functions calls with this
<Saviq> :)
<didrocks> sil2100: Mirv (if you ask yourself why the siloMatrix isn't there anymore) ^
<Mirv> ok :)
<sil2100> :D
<didrocks> Saviq: seb128: if you need a reconfigure for now, just ping us to give you your requestID
<didrocks> should be changes in < 1h hopefully
<didrocks> changed*
<seb128> didrocks, ok, thanks
<didrocks> sil2100: Mirv: to get an existing ID, just select the line and choose in the menu "assign silo"
<didrocks> it will give you an existing ID if it's already assigned
<didrocks> generate a new one otherwise
<sil2100> Ok, awesome
<sil2100> tvoss: looking good seemingly, let's publish
<tvoss> sil2100, ack
<tvoss> sil2100, did you hit merge&clean, yet?
<sil2100> tvoss: no no, I need to get a +1 on the packaging diff
<sil2100> And then we need to wait for it to land in the archive
<sil2100> didrocks: looks good, needing ACK -> http://162.213.34.102/job/landing-014-2-publish/lastSuccessfulBuild/artifact/packaging_changes_process-cpp_1.0.0+14.04.20140326.2-0ubuntu1.diff
<tvoss> sil2100, okay, so you keep me posted, when I can hit the button?
<sil2100> Sure
<Mirv> didrocks: when you have time, I tried and apparently succeeded in getting a silo landing-016 for qtlocation http://162.213.34.102/job/prepare-silo/701/console but it's not showing in the spreadsheet
<sil2100> Mirv: it might show up in a moment, how long did you wait already?
<Mirv> sil2100: 15 min so far
<Mirv> and yes so I looked from the discussion that it might take some time
<Mirv> it's a special case with no MP:s and only manual upload package, so it might trigger something differently
<sil2100> Mirv: it might be a bug then!
<vila> didrocks: ff/gtalk/sound combo mess, did you see my msg about 263 being green ?
<didrocks> vila: yeah, all fine, don't worry, thanks! :)
<didrocks> and good luck for your issue
<vila> didrocks: ack, thanks ;)
 * vila grabs the shotgun
<popey> where do we file bugs against individual scopes?
<popey> (the new ones)
<Saviq> sil2100, silo 13 can be published
<sil2100> Publishing
<sil2100> didrocks: do you have a moment for that packaging ACK ? :) (soname bump http://162.213.34.102/job/landing-014-2-publish/lastSuccessfulBuild/artifact/packaging_changes_process-cpp_1.0.0+14.04.20140326.2-0ubuntu1.diff)
<didrocks> sil2100: oh right, I was looking at that, yeah, +1
<didrocks> (and then forgot)
<sil2100> didrocks: thank you!
<didrocks> sil2100: all the rdepends are going are rebuilt?
<didrocks> s/are going /
<didrocks> to pick up the new soname?
<didrocks> sil2100: ^
<didrocks> tvoss: ^
<tvoss> didrocks, it's only rdepends not reverse build depends
<didrocks> $ reverse-depends libprocess-cpp0
<didrocks> Reverse-Depends
<didrocks> ===============
<didrocks> * libdbus-cpp2
<didrocks> * libprocess-cpp-dev
<didrocks> * libunity-mir1 [amd64 armhf i386]
<didrocks> * libunity-scopes0
<didrocks> tvoss: so, you did rebuild dbus-cpp, unity-mir and unity-scopes?
<didrocks> (I didn't watch the whole thing)
<sil2100> didrocks: yes
<didrocks> excellent :)
<sil2100> didrocks: they were in the silo ;) That was the thing I noticed yesterday and we rebuilt it
<didrocks> good work guys :)
<didrocks> sil2100: Mirv: Saviq: seb128: ok, now the self-reconfigure doesn't take any parameter anymore, just click "build", enjoy :)
<Saviq> didrocks, \o/
<sil2100> Ouuu yeeea
<dbarth> sil2100: hi, i have a policy question: one of our dependencies can't build on powerpc/arm64/etc. so webbrwoser-app will timeout building on those (dep-wait i guess)
<Chipaca> i've got a question about the trunk branch wrt ci train landing: does it have to be 'trunk'? does it have to be the focus of development on launchpad? something else?
<dbarth> so should we disable builds on the archs that won't work in the main package?
<sil2100> dbarth: so, was that dependency available on ppc arm64 before?
<cjwatson> dbarth: tell me about the specifics and I'll investigate
<dbarth> v8 has no assembler for those, and v8 is in blink, which itself is in oxide
<dbarth> so oxide won't build on those arches
<cjwatson> webbrowser-app was built on arm64/powerpc/ppc64el before
<sil2100> dbarth: oh, and that will make webbrowser-app unavailable for ppc again?
<cjwatson> dbarth: fwiw if you actually need this overridden you need an archive admin, sil2100 isn't empowered to override it I'm afraid
<dbarth> cjwatson: but is now moving to oxide as a /build-dep/ though
<sil2100> dbarth: ok, so I guess cjwatson might help you here, he might be the best person to take a decision if we can remove it from the archive for those archs or not
<cjwatson> jdstrand: did anyone consider the v8 portability story with oxide?
<dbarth> cjwatson: ah ok
 * sil2100 sadly has no power at all
<sil2100> ;)
<dbarth> cjwatson: was discussed yesterday or so, i think doko asked
<cjwatson> and what was the answer?
<dbarth> in the MIR for oxide (can't remember, i will just lookup the bug ;)
<dbarth> https://bugs.launchpad.net/bugs/1293681
<ubot5> Ubuntu bug 1293681 in oxide-qt (Ubuntu) "[MIR] oxide" [High,Fix committed]
<cjwatson> anyway, webbrowser-app has no rdeps on those architectures, so I can remove the binaries
<davmor2> Morning all
<cjwatson> dbarth: is there a landing PPA I can look at for more details though?
<dbarth> see comment #4
<cjwatson> I see.  It looks like a sad inevitability for now
<dbarth> cjwatson: in summary, google may do it on v8 for certain arches, but not all of them
<dbarth> right
<cjwatson> Please try to avoid adding lots more dependencies on this to other existing packages though
<cjwatson> The next case might not be easy to untangle
<dbarth> we'd need to rely on qtwebkit for those then
<dbarth> but that's just what we were trying to avoid to simplify the maintenance
<cjwatson> I get that you might need it occasionally
<cjwatson> I just don't want it leaking out all over the whole stack
<cjwatson> I assume most of this is contained to the webapps/webbrowser elements
<dbarth> yes
<dbarth> but the dependncy chain may not be as simple
<didrocks> we need to ensure that unity7 isn't going to dep on webapps then
<dbarth> i can check how far it goes
<didrocks> (which would be wrong)
<cjwatson> didrocks: that'd want to be no stronger than recommends anyway, right?
<didrocks> cjwatson: correct, but the first implementation 3 cycles ago was not optional, I think we need to check that's not coming back in another way
<dbarth> cjwatson: the landing ppa is https://launchpad.net/~ci-train-ppa-service/+archive/landing-009/ if you need it
<cjwatson> unity-webapps-service only depends on webapp-container on amd64 i386 armhf right now
<cjwatson> so if we can carry on with that kind of bodge then we should be fine
<dbarth> unity-webapps-service already limits the supported architectures you mean?
<cjwatson> yes
<dbarth> (looking up the branch)
<dbarth> ah ok
<cjwatson> in its dependency on webapp-container
<cjwatson> dbarth: ok, is this otherwise ready to land?  I can remove the problematic binaries, but I don't want to do so until you're actually ready to land this because otherwise there's a risk I'll have to do the work twice
<dbarth> we're not ready yet, nope
<dbarth> the silo was for checking all bits work together
<dbarth> and we caught this one
<cjwatson> dbarth: give me a shout when you are, then
<cjwatson> and otherwise consider this will-be-fixed
<dbarth> but to make sure: should we modify the packaging of webbrowser-app?
<cjwatson> I don't see why
<dbarth> ok, so we just let some builds fail, and the landing is a manual step
<cjwatson> they aren't even really failing, they're dep-waiting
<dbarth> right
<cjwatson> which is fine as long as it is made not to be a regression from trusty (which will happen by way of me removing the binaries)
<dbarth> ok thanks Colin
<dbarth> ah
<cjwatson> in fact that's actually better than a hardcoded architecture list
<dbarth> ok
<cjwatson> they suck, they take ages to unwind when we port things
<Chipaca> ahem. Sorry for the bad timing in asking my question, above :)
<Chipaca> i'll repeat:
<Chipaca> i've got a question about the trunk branch wrt ci train landing: does it have to be 'trunk'? does it have to be the focus of development on launchpad? something else?
<didrocks> Chipaca: hey, that's what we do advise strongly during the bootcamp, yeah
<didrocks> Chipaca: you have UDS session on CI Train about the reasoning, but mostly, it's about focus, being able to pick any MP and get it in
<Chipaca> didrocks: thing is, i'd like to have a different branch where dev branches land, so the server work isn't blocked on the ci train
<didrocks> Chipaca: for upstreams with a lot of branches, they are keeping up with it (even if the Airline is supposed to fix where you can end up with multiple MP conflicts)
<Chipaca> and then have the ci train merge that
<didrocks> Chipaca: your client and server are in the same branch?
<Chipaca> didrocks: the server depends on the client (because the client has the protocol, and acceptance tests, and the basic server, yes)
<didrocks> agreed, that for thing one, until we have the airline, it's more tricky
<Chipaca> that is: the production server is a specialization of the demo/test server that's in with the client
<didrocks> just to be clear, what we do want is:
<didrocks> - in case of regression/failure, upstream being reactive to fix it (and not "I don't care because I continue to push to my own trunk")
<didrocks> - a fix should be easy to pick from the devel branch without to have pulling the whole trunk
<didrocks> s/pulling/to pull/
<didrocks> (and if I mentionned both, it's because both happened and happens)
<Chipaca> didrocks: as I see it, if the only difference between the pre-trunk branch and trunk is the manual process involved in landing things on trunk, both of those are just as satisfied as without it, and it unblocks people from waiting on the train
<didrocks> Chipaca: depends on people I guess, but if you commit to not land into that, for your case, I think this can make sense
<Chipaca> didrocks: ok. And I understand how this could fail if we don't truly commit to the above, but if you're willing to give it a try I'll set it up
<didrocks> Chipaca: sure, you can do that :)
<Chipaca> didrocks: thanks
<didrocks> yw, thanks for the head's up :)
<Chipaca> didrocks: can you think of a name that communicates "this is where dev branches land before manual testing and ci train merging"?
<Chipaca> otherwise it'll be some variation of "staging" or "canary" :)
<Chipaca> or maybe just pre-trunk
<t1mp> Chipaca: we were discussing exactly the same for ubuntu-ui-toolkit
<didrocks> t1mp: their case is a little bit different as they need protocol to be available for the server side
<Chipaca> t1mp: ubuntu-ui-toolkit also has a server that might need a quicker turnaround than the client for security or performance reasons?
<t1mp> Chipaca: no
<didrocks> t1mp: btw, just telling, still no SDK requestsâ¦ so I don't understand why you are blocked on getting MP in
<Chipaca> t1mp: ah :)
<didrocks> Chipaca: I'm not imaginative on names
<t1mp> didrocks: because we run all the tests before happroving and before doing landing requests
<didrocks> t1mp: yeah, and so, you are not passing tests and can't bundle them in one big requests?
<didrocks> t1mp: the external communication seems that you are locked by us, I'm clearly unsure why
<t1mp> didrocks: yes we are not passing tests for the individual MRs. I don't think the MRs are wrong (lets say an MR without changes will even fail)
<t1mp> didrocks: so it is more a matter of our policies than not being able to create a landing request
<didrocks> t1mp: they are passing on the dashboard though
<didrocks> ok, please be clear in the communication then, it seems what I'm hearing back from your team telling to other people don't really match that
<t1mp> didrocks: yes images 262 and 263 seem good. yesterday I spent time trying to get the ubuntu-test-cases scripts running locally for testing but I didn't finish
<didrocks> t1mp: as told multiple times, (and during the bootcamp to the lander), the metric should be "do we have the same failures than in the dashboard and not more?"
<didrocks> not "do we pass all tests"
<didrocks> otherwise, you will be blocked on other people having their tests failing
<didrocks> (of course, you need to check that the tests that are failing are exactly the same and due to the same cause)
<t1mp> didrocks: yes that was the problem. So either I misunderstood our policies, or we have impossible policies for uitk MRs
<didrocks> t1mp: TBH, you policy seems really impossible to me, let's see I do a wrong commit in unity8 AP tests
<didrocks> then, sdk shouldn't be blocked on that
<didrocks> sdk should just not "aggreviate" the issue
<didrocks> (if that makes sense)
<t1mp> didrocks: yes it makes sense
<didrocks> the lower you are in the stack, the more responsabilities you have
<didrocks> but don't punish yourself more than you have to ;)
<didrocks> bzoltan: you should have a read here as well (the last 10 minutes) ^
<t1mp> well the idea of having 100% OK on all app AP tests is nice, but clearly not working well
<didrocks> yeah, clearly not reachable or you will release almost never
<didrocks> and then, you end up with that status
<didrocks> but for me, there was no ambiguity, I didn't know you have that policy
<didrocks> (of course, an AP failure can hide another one, but I think that's rare enough that we can afford the risk)
<t1mp> didrocks: still having a staging might make it possible. We don't require 100% for merging to staging, but before staging goes to landing/trunk we can wait for an image where we have 100%
<didrocks> t1mp: you will almost still never release in distro
<didrocks> t1mp: as from experience, we are not at 100% frequently
<didrocks> so I guess you are not going to fix your problem
<didrocks> just pushing it back on tree down the street
<t1mp> didrocks: we had images 250 and 262 now 100% on mako. I hope 100% will only become more frequent :)
<t1mp> but I cannot predict that of course
<didrocks> t1mp: well, better to deal with the reality for now and not having you blocking on that
<didrocks> and that's the policy that all other upstreams have btw
<t1mp> okay
<didrocks> or you won't be able to push code to distro and it won't be sustainable
<t1mp> bzoltan: ^ we can start to work with that now and see from there if we need/can improve the process?
<didrocks> t1mp: I guess the harder for you will be the first landing now that you have a lot of branches
<didrocks> but then, I think you will be in a similar situation than other trunks with a lot of commits
<t1mp> didrocks: we don't have to land all the branches at once, we can start with a few simple ones
<didrocks> t1mp: agreed, you can try multiple batches
<bzoltan> t1mp:  Would you join to Mumble?
<t1mp> ok
<t1mp> didrocks: I'm not a lander, so maybe I missed it, but what is the main argument against having a staging where the changes go first before landing them?
<t1mp> didrocks: sorry if you had to explain it several times before already
<didrocks> t1mp: bzoltan should have them, but you can see what I wrote 33 minutes ago on the same channel :)
<t1mp> didrocks: to Chipaca or me? (I'm reading through the backlog now)
<didrocks> to Chipaca
<didrocks> basically decolloration of concerns and release early, release often
<bzoltan> didrocks: decolloration?
<didrocks> bzoltan: separation of concerns
<bzoltan> didrocks:  pronouncing  it sounds ... hkhm... odd :D
<didrocks> yeah, I mistyped
<didrocks> decorrelation*
<bzoltan> didrocks: OK :) dick coloration
<didrocks> :p
<t1mp> with a staging we still want release early & release often, but there will be a buffer (that we should keep small)
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<didrocks> t1mp: the question is why? it seems you argument was the 100% tests passing
<didrocks> which won't get fixed by it
<t1mp> didrocks: true
<t1mp> well with the buffer we can wait for 100% before landing, but I'm not sure anymore if that's worth it
<didrocks> well
<t1mp> didrocks: it seems like we are too careful trying not to break anything
<didrocks> you won't be able to land the buffer often I think
<didrocks> as I told above :)
<didrocks> and when you land your buffer, there is a higher chance that you are going to have regressions (harder to decipher then) with things not catched up by automation
<jdstrand> cjwatson: re v8 portability> I'm not sure of the context of the question. if you are asking re MIR> yes, there is a question in the MIR bug with a statement. if re why in the 1st place> ppc64el didn't exist when the decision was taken and arm64 is expected from upstream
<cjwatson> just wondering about ongoing prospects.  it looks like the MIR answers that (not really to my liking, but never mind)
<jdstrand> as for the statement> as mentioned arm64 is expected. if we want ppc64el, we just have to work with upstream rather than distro patching
<jdstrand> I have to believe upstream will want to support arm64 devices at some point
<jdstrand> ppc64el I would think would be an easier port and more palatable to upstream than powerpc, but that is just a hunch
<Saviq> sil2100, hmm "Migration: One package at least is not available at the destination. thumbnailer (1.0+14.04.20140327-0ubuntu1) is in the UNAPPROVED queue." what's that about?
<Saviq> it's landing 013
<sil2100> Saviq: beta freeze
<sil2100> Saviq: because of beta freeze it seems thumbnailer is locked in unapproved
<Saviq> sil2100, ah right
<sil2100> Saviq: you can try bribing the release team to push it forward or simply wait for it to move on ;) Do you have another landing of thumbnailer nearing by or something?
<Laney> You should put that in the general status
<Saviq> sil2100, not that I know of, let me ask
<dbarth> another one about oxide
<Laney> The freeze is intended to stay on until the release, btw
<dbarth> ah jdstrand maybe you can help
<dbarth> should chris find a sponsor for uploading a new version of oxide
<dbarth> or should we go via the silo/ppa now that it's going to main?
<sil2100> A silo can be used for this if it's related to the landing
<dbarth> and do we have /very fast/ arm builders?
<sil2100> Then it will be pushed to the archive along the merge branches
<dbarth> oxide is webkit/chrome and takes ages
<sil2100> dbarth: our silo PPA's have the same builders as the archive has ;)
<cjwatson> dbarth: highbank is pretty good
<dbarth> so fast?
<dbarth> ie native
<cjwatson> silos are native, yes
<dbarth> ok then
<dbarth> ah cool
<dbarth> jdstrand: that's the way to go right? i'm not sure if we're already in main or just about to
<dbarth> (that should be the first new upload i guess)
<jdstrand> dbarth: that is an open question. we have to define how to do landings. in the meantime, we can do whatever is easiest. I can sponsor for chris, or we can go the silos route
<jdstrand> dbarth: what I've done with apparmor is have them upload to our security-proposed ppa, then I pocket copy from there to a silo after review
<jdstrand> dbarth: don't we have this same issue with webbrowser-app though?
<dbarth> ah
<dbarth> hmm, yes as we were discussing with cjwatson earlier
<jdstrand> dbarth: it isn't in main afaik-- it needs to be seeded or something needs to Depends/Build-Depends on it
<dbarth> he proposed to take care of the webbrowser-app archive injection
<dbarth> to avoid speical casing a build that should be kept clean of arch specific controls
<dbarth> ah right
<Saviq> sil2100, so, if the freeze is on until release, does that mean we can't land anything? or is thumbnailer just not exempt like other touch-only components?
<dbarth> jdstrand: right now i need a newer build somewhere like in silo 009, universe or main to have the silo be landable
<dbarth> or it just crashes webbapps
<sil2100> Saviq: I think we need to discuss that with the release team, so that we can release that through the block
<dbarth> jdstrand: i guess i should take oxide in the silo as well
<jdstrand> dbarth: how do you handle webbrowser-app? is it ppu or is oSoMoN core-dev?
<jdstrand> (that is another option btw, chris pursuing core-dev)
<dbarth> webbrowser-app lands via a silo
<jdstrand> I see
<jdstrand> we aren't setup for autolanding yet
<jdstrand> (via silo)
<dbarth> ok nw
<didrocks> Saviq: I need to rebuild landing-010
<didrocks> sorry, my fault
<didrocks> have you started the testing on it already?
<jdstrand> dbarth: so we need to do source package upload. do you want that via the archive or the silo?
<Saviq> didrocks, k, was about to test it, will wait then
<dbarth> jdstrand: via archive i guess; then we avoid the extra build
<jdstrand> sorry, I meant to say the other option is chris pursuing ppu (he could do core-dev too, but ppu should be much faster)
<dbarth> yup
<jdstrand> dbarth: I can avoid the build
 * jdstrand can do a copy
<dbarth> ah
<t1mp> plars: any ideas what can be wrong here?
<dbarth> jdstrand: but maybe we can stay in universe still this week and chris can upload right now
<jdstrand> but, it seems that via the archive is fine too
<jdstrand> that would work too
<dbarth> then once the silo is ready we do the seed / depend dance
<dbarth> and talk about silo landings again
<didrocks> Saviq: building now :)
<jdstrand> ftr, he can always upload to one of the security teams ppas. you then can ask me, an archive admin or a member of the citeam to copy the packages in
<jdstrand> (in to the silo)
<cjwatson> Saviq,sil2100: we'll be able to land thumbnailer after we're done with the beta
<cjwatson> Saviq,sil2100: it's just on non-touch images so it would be disruptive to land it *right now*
<jdstrand> dbarth: but, like I said in the email thread-- it is an open question how to do the landing since there will be multiple trees for dev, beta, stable, etc
<Saviq> cjwatson, ok, I misunderstood Laney, then
<dbarth> yup
<jdstrand> dbarth: have you communicated with chris that we need an upload prepared?
<sil2100> cjwatson: oh, ok, since I misunderstood Laney that the beta freeze is till the release, ok
<dbarth> jdstrand: yes
<sil2100> Thanks
<jdstrand> ok
<Laney> The *archive* freeze is
<dbarth> jdstrand: this is when he asked me of the route to take
<cjwatson> Laney is correct that the archive is still frozen until release, but we'll have more flexibility in accepting things past it after beta
<Laney> So you're going to see things going to the unapproved queue, that's what I mean
<jdstrand> sounds like just to the archive for today is fine. when it moves to main, we can do it via our ppas until we have an MP landing story
<jdstrand> dbarth: ok, I'll communicate that to him
<Saviq> Laney, cjwatson, got it
<dbarth> jdstrand: ok thanks
<sil2100> This freeze is even more troubling for the free-silo-count...
<cjwatson> it should be only hours now
<sil2100> cjwatson: phew ;)
<cjwatson> I went through this morning to find things that were only on touch and not other images and accept them, but most such had already been auto-accepted
<Mirv> sil2100: do you think line 7 should have some note about it being blocked by the oxide landing?
<seb128> cjwatson, is there anything that is preventing bugfixes uploaded to be accepted to trusty-proposed during the freeze (I guess we have a britney lock in place like for other milestones?)
<sil2100> Mirv: not sure, since it's obvious that webbrowser-app is simply locked
<cjwatson> seb128: I don't know whether we do or not; I haven't really been involved in this beta so I'm a little reluctant to suddenly parachute in
<Mirv> sil2100: yeah, I was more wondering if that landing has been discussed since it claims to be ready but doesn't have a silo (same goes for thostr's line 10)
<sil2100> Mirv: line 10 is unassigned because there are no silos free
<seb128> cjwatson, fair enough, thanks
<cjwatson> seb128: I mean I tend to agree that's generally more sensible as a practice, I just don't want to break something at the last minute ...
<sil2100> Mirv: 4 free silos means that we have like only 3 free and 1 preproduction
<sil2100> And our policy says to leave 3-4 free for emergencies
<seb128> cjwatson, yeah, agreed, we are unfreezing today anyway (if everything works out as planned)
<Mirv> sil2100: yep, we quite often have that amount only nowadays :)
<Mirv> but that should ease up later today like discussed
<cjwatson> I'll check with infinity as soon as he appears; we can probably unfreeze fairly soon if everything seems golden
<sil2100> Mirv: the landing line 7 was discussed but dbarth said that oxide landing is more high prio ;)
<seb128> cjwatson, it just feels like some of the easy bugs fixes could have been let it between monday and today, and blocked in proposed
<Mirv> 3 mor eislos
<cjwatson> yeah, I get it
<sil2100> Mirv: I hope so!
<Mirv> sil2100: yeah, thanks
<cjwatson> nobody seems to be panicking on #-release which is usually a good sign about now
<seb128> ;-)
<plars> t1mp: hi
<plars> t1mp: what's the problem?
<didrocks> Mirv: sil2100: the number of free silos don't count pre-prod
<didrocks> doesn't*
<sil2100> didrocks: oh :)
<Mirv> so 4, thostr could get one then too maybe for url-dispatcher? :)
<sil2100> Mirv: already assigned;)
<Mirv> sil2100: great, waiting for it to refresh
<Mirv> now the sheet is all covered again
<sil2100> \o/
<Chipaca> sil2100, Mirv, didrocks: Can I have a silo for row 32?
<sil2100> Chipaca: uuuh
<sil2100> Chipaca: is it a high urgency landing?
<Chipaca> sil2100: I'm going to bite my tongue and say "no" :)
<dbarth> sil2100: yes, we need that oxide silo please; we just have 1 at the moment
<sil2100> Chipaca: because we're low on landings because of the beta freeze and other landers not pushing their landings forward - let's wait a little bit if any silos get freed and revisit then
<Mirv> Chipaca: after beta gets released later today, it should be possible to get a silo from robru etc
<Mirv> or well, it will probably be automatically given
<Chipaca> fair enough
<Chipaca> Mirv: sil2100: i'll pester y'awl later today then :D
<sil2100> Chipaca: no worries, we'll assign a silo as soon as there's the possibility ;) We promise that it will not be too long!
<Saviq> sil2100, silo 008 can be published please
<sil2100> Saviq: awesome, thanks! Doing
<Mirv> unity-scope-click shouldn't be seeded outside touch, so that silo can be also freed then soon
<sil2100> Indeed
<Saviq> Mirv, sil2100, do you know if/why thumbnailer is seeded outside touch?
<Mirv> Saviq: yes
<cjwatson> Saviq: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.trusty/rdepends/thumbnailer/libthumbnailer0
<Saviq> cjwatson, thanks!
<Saviq> right, that makes sense
<Mirv> Saviq: thumbnailer -> UITK -> webbrowser-app -> unity-webapps-service -> bamfdaemon -> unity, about
<Mirv> that's why I needed to rebuilt half the world of Qt 5 dependencies before I could upgrade to it on my desktop without losing Unity 7
<Mirv> when migrating to Qt 5.2's libqt5core5a
<sil2100> didrocks: so, packaging ACK - it's a big one, since it has the removal of automake and vala deps - the --buildsystem cmake doesn't seem required, but I guess it's no blocker:
<sil2100> http://162.213.34.102/job/landing-008-2-publish/42/artifact/packaging_changes_unity-scope-click_0.1+14.04.20140326-0ubuntu1.diff
<Saviq> didrocks, sil2100, here's the respective MP https://code.launchpad.net/~dobey/unity-scope-click/drop-vala/+merge/212505
 * didrocks isn't going to argue on -Section: gnome
<didrocks> +Section: x11
<didrocks> but it's weird
<t1mp> plars: hello
<t1mp> plars: running *all* tests takes too long, so I was trying to run individual autopilot tests
<plars> t1mp: ok
<t1mp> plars: ah I forgot to paste the url when I asked for your help, let me look it up
<plars> :)
<t1mp> plars: http://pastebin.ubuntu.com/7162447/
<plars> t1mp: uhoh... give me a minute
<plars> t1mp: I think I may have a drive going bad
<plars> need to reboot
<t1mp> ok
<bzoltan> Mirv: sil2100: I am good with the line 31 ... do we have any chance to get a silo?
<t1mp> I cannot properly view that spreadsheet.. it seems its scrolling is discrete, I cannot go up and down in a single field
<t1mp> a larger screen would solve that also :)
<didrocks> Mirv: sil2100: as we are close from beta unfreeze, I think we can keep 1 silo for urgency (in addition to the preprod silo)
<didrocks> sil2100: +1 on the packaging change
<sil2100> didrocks: aye!
<sil2100> didrocks: thanks ;)
<Mirv> bzoltan: reading ^ yes, just a moment
<sil2100> bzoltan: sure ;)
<Mirv> sil2100: handling already
<sil2100> Mirv: thanks ;)
<sil2100> Saviq: ok, -click published o/
<t1mp> didrocks: ^we're following your suggestions now and doing a landing
<didrocks> t1mp: excellent news!
<plars> t1mp: typing from my phone now, my laptop HD appears dead. Looks like you had some sort of adb problem. Check your device, make sure you can adb shell to it and retry
<sil2100> Chipaca: assigning a silo for you as well
<Chipaca> oh, noes!
 * Chipaca grins
<Mirv> bzoltan: landing-018, feel free to click Build when ready
<bzoltan1> t1mp: didrocks: I still would be more relaxed to have each MR being tested against a good list of applications before even entering to the landing queue
<t1mp> bzoltan1: yes, me too.
<didrocks> bzoltan1: the thing is that we don't have applications tests which never failed
<bzoltan1> Mirv: sil2100: thank you gents
<t1mp> bzoltan1: in this case most of them were tested several times over the past days/weeks, but never with 100% OK in a qt52 image :(
<didrocks> bzoltan1: so always compare to the dashboard results is the key I guess
<bzoltan1> didrocks: that is a problem what we should fix :)
<didrocks> bzoltan1: well, I'm spending hours everyday to try to ensure that stays green
<t1mp> bzoltan1, didrocks having tests and not requiring them to be green makes them less useful. But I guess we all know that already
<bzoltan1> didrocks:  I am sure you do and I know that your effort are above human capabilities to keep that train moving!
<didrocks> t1mp: we do require, see the effort on the mailing list and blockers
<t1mp> plars: adb works fine. I tried again, and I get more output now but it fails the same: http://pastebin.ubuntu.com/7162910/
<t1mp> didrocks: yes, I saw that. That kind of inspired us to require the tests to pass for our MRs
<Chipaca> ðððð choo choo
<josharenson> fginther: Hi, I was told to get in touch with you regarding adding a test to the CI runs that occur for the Mir dev branch. Is this something you can help me with?
<t1mp> plars: is gallery_app not a valid value to pass with -t ?
<didrocks> ogra_: seems your bot didn't pick my new image build kick
<ogra_> oops
<ogra_> one sec
<t1mp> plars: maybe it should be -a gallery_app
<t1mp> me trying that
<ogra_> |HELP
<imgbot> I am the firendly image watchbot
<ogra_> hmm
<fginther> josharenson, yes, but in the future please ping the 'Vanguard' identified in the channel topic to make sure the request is properly handled (in case I'm not around)
<ogra_> didrocks, when did you start it ? it only scans all 5 mon
<ogra_> *min
<ogra_> (not months)
<didrocks> ogra_: humâ¦ 7/8 minutes ago I would say
<ogra_> lets give iit one more min
<imgbot> === trainguard: IMAGE 264 building (started: 20140327-14:15) ===
<didrocks> ahah :)
<ogra_> heh
<sil2100> ;)
<ogra_> imaptient you are :)
<didrocks> bfiller: davmor2: image building with the gallery-app click store revert ^
 * sil2100 knows that in reality imgbot is just ogra_ typing in stuff manually on his separate IRC session
<ogra_> there are two different cron jobs running for the check ... if they overlap it can take up to 10min
<didrocks> yeah
<didrocks> got it
<ogra_> sil2100, nah, i got speech input :P
<sil2100> hah ;)
<t1mp> plars: IT WORKS! tests are running! :)
<t1mp> kalikiana: ^^
<t1mp> kalikiana: ./run-smoke -n -a gallery_app
<ogra_> i would appreciate a silo for a direct upload for line 34 btw :)
<plars> t1mp: ok, I have a somewhat usable desktop back - there was too much scrollback for my phone to be very useful but it looks like it's working now?
<t1mp> plars: yes it looks like it. Still figuring out what is logged, like the versions of the apps and AP tests?
<sil2100> ogra_: if you need a direct upload, just state in the sources field the source package name ;)
<t1mp> kalikiana: I *guess* it checks the test version needed. I didn't tell any of the scripts to fetch gallery or its autopilot tests
<sil2100> ogra_: the link to the debdiff you can leave in the comments then
<t1mp> kalikiana: but I don't see it in the logs on my laptop
<ogra_> sil2100, you mean in the merge proposals field ?
<Chipaca> sil2100, Mirv, didrocks: Can I have a landing for silo 19?
<didrocks> Chipaca: debian/control still has the multiarch tag, right?
<Chipaca> didrocks: mutliarch:foreign, yes
<didrocks> Chipaca: so, you want to remove that as the package isn't multiarch anymore
<Chipaca> didrocks: the fix is that i was instlling the libexec as if it were mutliarch:somethingelse
<Chipaca> didrocks: it isn't?
<didrocks> Chipaca: let me check, but it's not into that diff
<didrocks> Chipaca: https://code.launchpad.net/~ubuntu-push-hackers/ubuntu-push/automatic/+merge/213058 I don't see it
<Chipaca> didrocks: sorry, what should you be seeing?
<didrocks> Chipaca: removal of Multi-Arch: foreign
<Chipaca> didrocks: but... why?
<didrocks> you don't install any multi-arch files
<Chipaca> I'm honestly confused, now
<Chipaca> cjwatson: halp?
<cjwatson> didrocks: that doesn't make sense
<cjwatson> didrocks: you're thinking of Multi-Arch: same
<didrocks> cjwatson would know more than I, but I'm pretty sure it needed to be removed
<didrocks> cjwatson: oh right
<cjwatson> didrocks: Multi-Arch: foreign is still fine here
<didrocks> sorry, yeah, my bad
<Chipaca> didrocks: this change is after talking with cjwatson; I know nothing :)
<didrocks> as it's an executable service
<Chipaca> *phew*!
<cjwatson> right, the problem was that it was bogusly installing files as if it were M-A: same when it isn't :)
<Chipaca> cjwatson: thanks :)
<didrocks> cjwatson: yeah, thanks for clarifying
<didrocks> Chipaca: published
<Chipaca> whee :)
<cjwatson> though that changelog version goes backwards
<cjwatson> which is kinda weird
 * sil2100 is back from lunch
<Chipaca> there's something funny in the changelog; hopefully it'll settle now that we've switched
<sil2100> So many landing, not enough free silos :<
<didrocks> cjwatson: well, the version is overriden by daily-release
<cjwatson> fair enough
<didrocks> or ci train rather
<Chipaca> i've got to go to my school run, will be back in an hour, feel free to merge&clean #19 while i'm away
<Chipaca> otherwise i'll do it when i return
<didrocks> Chipaca: seems you click "merge and clean" too soon btw :)
<didrocks> yeah, we'll probably do that to free up the silo as soon as it's published
<Chipaca> didrocks: yes :) hence my above :D
 * Chipaca will bbl
<didrocks> Saviq: m&c lines 24?
<didrocks> sil2100: I guess you should do it so that you can reassign one ^
<sil2100> Saviq: can you m&c silo 8?
* doanac changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: doanac | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<sil2100> Saviq, tvoss: so, how's the discussion going with the Qt upstream regarding that event-queue bug/feature?
<Mirv> did m&c for Saviq to get that silo into new use
<sil2100> Mirv: thanks!
<Saviq> Mirv, oh thanks
 * Saviq was in a looong meeting
<Saviq> sil2100, â that
<sil2100> It's freed \o/
<sil2100> ogra_: let me assign a silo for you maybe
<ogra_> as you like, i'm not in a hurry as long as i can upload today
<ogra_> if there are more urgent bits, take them first
<sil2100> ogra_: assigned, would be nice if you could upload today and release the silo soon ;p
<ogra_> yep, after the meeting i'm currently having
<tvoss> sil2100, we are still investigating, upstream has been quite helpful in understanding the underlying issue and greyback is working on a possible solution
<sil2100> tvoss: that's excellent news \o/
<sil2100> Thanks
<Saviq> sil2100, I'll try and land unity8 asap, and then right edge, so two silos will hopefully be freed
<sil2100> \o/
<sil2100> Chipaca: could you m&c silo 19?
<t1mp> plars: some times I have the issue again that i mentioned before
<t1mp> plars: it seems that the script calls adb reboot, and then tries to do something before the device is back online
<sil2100> Chipaca: ok, I'll press m&c then
<t1mp> plars: http://pastebin.ubuntu.com/7163364/ the error comes before the device is back up
<plars> t1mp: it's doing an adb-wait-for-device
<plars> t1mp: we see those adb protocol faults very rarely in production, and not so much lately
<plars> t1mp: it's not the same as a device that's missing (adb device not found error)
<plars> t1mp: I'm not sure why you seem to get them so much though
<plars> t1mp: I don't know if it would help, but you could also try specifying the adb serial with -s
<t1mp> plars: same result with -s
<plars> t1mp: you have the magic setup for reproducing these adb protocol faults then it seems. We had a lot of problems with them in the past, but they seemed to get better over time and nobody could explain them or even reproduce them reliably
<t1mp> plars: so I have the perfect setup for debugging them :)
<ogra_> plars, well, they happened when the USB gadget device was reconfigured for adb and mtp ... all code doing that (except for the android bits) was dropped recently
<ogra_> protocol faults shouldnt happen anymore since a while already
<plars> ogra_: yeah, we don't have problems with it in the lab for quite a while now
<plars> ogra_: t1mp is hitting them regularly at home though
<ogra_> t1mp, what image version and what device is that ?
<t1mp> ogra_: mako 262
<ogra_> plars, right, theoretically they cant happen anymore unless you use a broken cable or some such
<ogra_> since the gadget never gets reconfigured
<ogra_> t1mp, any other usb cable around you could try ?
<t1mp> hmm does this tell anything? http://pastebin.ubuntu.com/7163424/
<t1mp> ogra_: yes, I'll check now
<t1mp> ogra_: same result
<t1mp> interestingly, wait-for-device waits a while, then it fails. And if I check *immediately* after it fails, the device is back online
<t1mp> so wait-for-device seems to fail in the moment the device is coming online again
<t1mp> ogra_: in general I think the two cables I tried now are not broken, because I have been running a lot of autopilot tests over them which can last for hours, without cable problems
 * t1mp gotta go, bbl
<ogra_> t1mp, what android-tools-adb version do you run on your desktop
<dbarth> sil2100: checking about silo statuses: we have some sdk improvements to land: how is that possible right now with silo availability and freeze?
<dbarth> sil2100: that's phone html5/sdk; new apis
<davmor2> ogra_: what happened to imgbot again?
<ogra_> davmor2, nothing, anything wrong with it ?
<sil2100> dbarth: hmmm, so...
<ogra_> |HELP
<imgbot> I am the firendly image watchbot
<ogra_> davmor2, still there
<davmor2> ogra_: I see image 264 Building but no 264 is done
<sil2100> dbarth: currently we're a bit low on silos, but I hope we'll have more pretty soon, like around evening
<davmor2> ogra_: and I've just upgraded to it so it is :)
<ogra_> hrm
<ogra_> it says it is done in its local log too
<ogra_> bah, and it dropped at :35
<davmor2> ogra_: haha
<dbarth> sil2100: ok, so i'll prep a request for later today
<dbarth> thanks
<sil2100> dbarth: ok :) I'll make sure robru will assign it once we have free slots!
<ogra_> davmor2, thanks for pointing it out ... i have adjusted some bits, hopefully it works better now
<davmor2> ogra_: \o/
<dbarth> sil2100: there is the question of whether we should land new APIs right now though; it's mostly for phone, but the packages are in main :/
<dbarth> i guess we're not the only one landing new phone stuff, so what is the general policy?
<sil2100> dbarth: if it's for touch only and is covered by the standing touch FFe, then we can land it
<sil2100> We generally don't stop the line for touch specific features
<sil2100> didrocks: ok, so, since I'm not sure if you're up-to-date on the Qt-bug status, but from what Thomass mentioned, Qt upstream was very helpful and now greyback is working on a solution that can resolve the bug
<didrocks> sil2100: yeah, I saw it on the backlog, thanks for checking!
<dbarth> sil2100: ah ok, so i think we're covered there then
<sil2100> kenvandine, cyphermox: not to bother didrocks, could anyone of you guys take a look at https://code.launchpad.net/~sil2100/dee-qt/add_cpp_symbols/+merge/202679 and review? Upstream asked for some core dev to review it ;)
<ogra_> sil2100, silo-008 can be released
<josharenson> fginther: Are you still available? I apologize for dropping off, was having internet issues.
<sil2100> \o/
<sil2100> ogra_: published o/
<fginther> josharenson, I'm in the middle of a meeting. if you have a well defined request, you can just add a bug under ubuntu-ci-services-itself.  If this needs discussion can come back to this in about 2 hours?
 * sil2100 goes prepare for practice
<ogra_> sil2100, thanks !
<ogra_> plars, doanac, could we sit down some point next week and look how we get my bootchart script into your infra (http://paste.ubuntu.com/7162200/) ?
<plars> ogra_: sure, sounds good - I saw something about it requiring a dedicated device?
<ogra_> plars, well, it will need a fresh installation and will then hog the device for a while
<ogra_> i wouldnt run it in the normal dashboard run but in parallel somehow
<plars> sure
<didrocks> hum
<didrocks> ogra_: I don't see address-book-app listed
<ogra_> (with dedicated device i meant it should be run standalone, i think i mis spelled that a bit)
<didrocks> ogra_: on #264
<didrocks> is it expected?
<plars> ogra_: oh, I also wanted to ask you about ofono-phonesim and messaging-app tests on tablets - is that still an issue? Do we need to force installation of that?
<plars> ogra_: I don't have a tablet at home to mess with
<ogra_> plars, the tests look fine (same crashes as mako, no additional errors)
<ogra_> didrocks, i dont see addressbook-app uploaded
<didrocks> ogra_: it's been reverted in the store
<didrocks> by popey
<ogra_> hmm
<didrocks> I wonder if the revert took effect then
<ogra_> didrocks, and how would that help for a deb ?
<ogra_> http://people.canonical.com/~ubuntu-archive/click_packages/click_list
<didrocks> ogra_: bah
<didrocks> I'm stupid
<didrocks> I meant gallery-app
<ogra_> what version should that be at ?
<didrocks> 14:49:45          popey | "Changed published version to 2.9.1.934"
<ogra_> hmm
<ogra_> if dpkg --compare-versions "$newversion" gt "$version"; then
<ogra_> :P
<didrocks> ogra_: ahah, even with click?
<ogra_> yes, for all lines in the manifest
<didrocks> ogra_: how dare you comparing! we need to go backward sometimes :p
<didrocks> ogra_: but ok, so the click revert is in?
<ogra_> (the script is at the bottom of the page btw)
<ogra_> gimme a sec, checking
<ogra_> click:com.ubuntu.gallery	2.9.1.934
<ogra_> yep
<plars> ogra_: so I can close that one then?
<ogra_> plars, yeah, happily
<didrocks> ogra_: phew, all what counted to me :)
<ogra_> :)
<didrocks> kgunn: hey, are you coming to the landing meeting? You have some items on the blocker list and we didn't get an update
<didrocks> bfiller_afk: same question (ont the telephony-service-indicator)
<kgunn> didrocks: this conflicts for me today
<didrocks> kgunn: ok, do you mind answering on the ML once I send the email?
<kgunn> didrocks: yes..i'll try to address to my best whatever has my name on it
<didrocks> kgunn: same than yesterday :)
<didrocks> (so no surprise)
<didrocks> thanks!
<didrocks> plars: coming?
<didrocks> cyphermox: ?
<plars> didrocks: yes, I'm there now. I was on another call that was running over
<plars> didrocks: I have to leave early though
<Saviq> robru, hey, silo 10 can be published
<robru> Saviq, great, thanks
<Saviq> robru, I hope to clean one more silo today - 015 - need 010 to land first
<robru> Saviq, ok, i hit publish. not sure how long it will take with the beta freeze, you might want to ask *really really nicely* in #ubuntu-release
<Saviq> robru, :D
<Saviq> robru, thanks, will do once it's in proposed and pkgtests are done with
<robru> Saviq, ok. yeah, keep an eye on the spreadsheet. it might get stuck in UNAPPROVED which means then you really do have to poke release team about it
<Saviq> robru, it probably will since we don't have all the arches
<robru> ugh, oh yeah.
<didrocks> robru: for things that are not seeded in any flavors participating beta, there is an autoapproval mechanism
<robru> ahhh ok
<didrocks> robru: Saviq: you can see it on #ubuntu-release
<didrocks> FYI
<didrocks> 18:25:43          -- | Notice(queuebot) -> #ubuntu-release: Unapproved: unity8 (trusty-proposed/universe)
<didrocks> -> entering the unapproved queue
<didrocks> 18:26:43          -- | Notice(queuebot) -> #ubuntu-release: Unapproved: accepted unity8 [sync] (trusty-proposed)
<robru> so it's just when i'm working on webapps that stuff gets stuck ;-)
<didrocks> -> the accept (which is an autoaccept)
<didrocks> robru: not only that one, but mostly, seeded-in-ubuntu can help to know if it's going to be stuck in unapproved or not
<Laney> I don't think you have to poke
<Laney> Unless it's been a long amount of time and there is no milestone being prepared
<didrocks> Laney: I keep telling the same thing for silo assignementâ¦ doesn't work :p
<Laney> didrocks: You start deleting requests and I'll start rejecting packages :P
<robru> didrocks, actually I love getting poked for silo assignment, it means I don't have to watch the spreadsheet... push notificatons > polling ;-)
<didrocks> Laney: ahah ;)
<didrocks> robru: I prefer polling over notifications, got too many of them
<didrocks> but I guess different workflows and so on :)
<Laney> Yeah, you guys give positive reinforcement to poking
<didrocks> Laney: we should stay unresponsivness to being poked I guess :p
<didrocks> unresponsive*
<Laney> Correct, or tell people to wait their turn
<Laney> I sometimes do that when I click on a bug that someone pinged about and see "Filed 5 seconds ago"
<didrocks> ahah, internal timeout needed :)
<Laney> talent management
<Laney> I think the queues will start to get flushed soonish btw, it's probably too late to respin anything for beta now
<seb128> right, they just confirmed that on #ubuntu-release
<Laney> oh yeah, how about that
<seb128> no respin, either you are good or you don't ship an image for beta
<Laney> the borg has spoken
<seb128> lol
<didrocks> heh :)
 * didrocks waves good evening
<didrocks> (and good beta)
<didrocks> ;)
<seb128> didrocks, night
* doanac changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
 * t1mp back
<t1mp>   Installed: 4.2.2+git20130218-3ubuntu22
<t1mp>  [6~ogra_> t1mp, what android-tools-adb version do you run on your desktop
<t1mp> ogra_: ^ that version
<ogra_> trusty ?
<t1mp> yes
<ogra_> hmm
<ogra_> any USB hubs involved ?
<t1mp> ogra_: nope
<ogra_> strange
<t1mp> I'll try the other usb port on my laptop
<ogra_> there s no technical reason that you even *could* get a protocol error
<t1mp> same result with the other port
<t1mp> the moment the device should come back online, I get the protocol error
<ogra_> they only happen if the floor gets pulled out underneath adb ... i.e. if the usb gadget is removed or reconfigured
<t1mp> and immediately after that it is back
<ogra_> or if there is any hardware issue
<t1mp> once the device is online, the connection is stable
<t1mp> no problems with running 2 or 3h tests on device started via adb
 * t1mp dinner, bbl
<ogra_> right, but you seem to have at least one reconnect on boot there
<ogra_> which shouldnt happen
<cjwatson> https://launchpadlibrarian.net/170675785/account-plugins_0.11%2B14.04.20131126.2-0ubuntu2_0.11%2B14.04.20140325-0ubuntu1.diff.gz   quality changelog there
<ogra_> yay
<ogra_> i thought didrocks fixed that long ago
<ogra_> (we were discussion it in jan. for the first time i think)
<ogra_> *discussing
<seb128> ogra_, cjwatson: that happens when there is no commit message on the mp I think
<davmor2> popey: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1262711 does this effect you still since the home scope is gone?
<ogra_> seb128, right, didrocks wanted to add a guard for that so the package is considered FTBFS when that happens
<seb128> not sure how those projects are configured
<ubot5> Ubuntu bug 1262711 in unity8 (Ubuntu) "Unity crashes with lots of music displayed in expanded music category in home scope" [High,Confirmed]
<seb128> on e.g indicators the "build" step fails CI on missing commit messages
<ogra_> bug 1290771
<ubot5> bug 1290771 in Canonical Upstream To Distro "cupstream2distro should FTBFS if packages have an empty changelog" [Undecided,New] https://launchpad.net/bugs/1290771
<ogra_> just recently filed
<popey> davmor2: well, given it's gone, no. â»
<cyphermox> davmor2: I have a shiny new mtp in my ppa if you're looking for stuff to test :)
<cyphermox> it doesn't yet show up properly in media players, but it now doesn't log as stupidly, and notices when you delete or take pictures and stuff, outside of the MTP protocol itself
 * ogra_ hugs cyphermox 
<cyphermox> ogra_: ppa:mathieu-tl/ppa
<cyphermox> before I do a release with citrain though I'd like to make the media player support work
<cyphermox> and perhaps add the thumbnails for images too
 * davmor2 also hugs cyphermox but currently has his hands full I can test it first thing though
<ogra_> well, as long as it happens before release :)
<cyphermox> ogra_: it's on track, but yeah. there's also MMS stuff in NM I'm working on now
<ogra_> right, but thats blocked from landing during freezes anyway
<cyphermox> and urfkill which is getting in a better shape, but I still also need to look into reworking the bluetooth bringup :)
<cyphermox> yes
<cyphermox> I'm just saying there's lots in progress
<ogra_> i wouldnt expect the BT changes for trusty
<cyphermox> ogra_: ideally we probably should
<cyphermox> or in any case, we should if we want to land urfkill too
<ogra_> (like i dont plan to do the "move all HW specifics to android" switch before release)
<cyphermox> yeah
<cyphermox> it's a little complicated and high risk as we get closer to the release, given that we're changing how stuff happens at startup
<ogra_> yeah
<ogra_> while it is nice to roll with touch ... i kind of miss the freeze time where you only look at optimization and fixing
<cyphermox> me too.
<ogra_> with rolling we dont really have that time anymore
<cyphermox> well, you need to take it
<cyphermox> but I understand what you mean
<ogra_> yeah, but meanwhile the world changes underneath you
<cyphermox> it would be nice for a little less earth-shattering changes underneath, and more shininess
<ogra_> yep
<cyphermox> well, the mtp stuff is changes in that direction
<cyphermox> nothing earth-shattering, but just works better
<ogra_> yeah
<cyphermox> so far I haven't managed to break it -- photos shows up if you refresh the file manager; and disappear as soon as they are deleted
<cyphermox> I think that may be a limitation in gvfs / mtp; since I do send the proper events AFAIK
 * ogra_ rarely uses it ... as long as it doesnt scatter my desktop with messages i'm happy :)
<cyphermox> ahah
<cyphermox> no, now only two messages at all on a standard install, it says it starts and how many items in the DB on startup
<cyphermox> and you can easily make it as verbose as necessary if we need to debug stuff
<ogra_> yeah
<ogra_> thats cool
 * ogra_ grumbles at cpu hotplugging 
<ogra_> if i force all cores on i gain 3seconds boot time
<ogra_> if i force them on and then later enable hotplugging again i lose them again ... i dont get why
<ogra_> (the 3sec)
<robru> seb128, ogra_, cjwatson: there is definitely a check to stop MPs with no commit message from even building. I see that fire all the time. citrain won't even build the MP if there's no commit message.
<cjwatson> maybe it was non-empty but only whitespace, or something?
<ogra_> robru, well, it just did :)
<ogra_> and the bug above is still open
<seb128> robru, ogra_, cjwatson: I don't think it's true, those checks are a CI thing and the CI is configured differently by projects
<seb128> it's not from CI train, but from the CI that runs on mps
<ogra_> right
<robru> cjwatson, ogra_: i think it's more likely to be that the MP contained a debian/changelog with a release that wasn't UNRELEASED, last time I built a project with a changelog that said 'trusty' it made a +0.1 version with an empty bullet point
<ogra_> thats why didier asked me to file the bug against cupstream2distro
<robru> seb128, yes, there is *also* a CI thing that fails if no commit message is set. but I have *definitely*, *undoubtedly* on *dozens* of occaisions seen citrain report "build failed because no commit message was set"
<seb128> robru, CI train is calling the upstream CI, which is different by project
<seb128> robru, I know what you mean, but those checks come from the by-project CI, and not from the train
<robru> seb128, http://162.213.34.102/job/landing-001-1-build/72/console
<seb128> robru, I'm not discussing that, I hit those often
<seb128> I'm just telling you it's no a check from the CI train itself
<robru> seb128, how can it be defined per project? can you point at that code that chooses that?
<robru> boiko, got you silo 8 btw
<boiko> robru: nice! thanks!
<robru> boiko, you're welcome
<cjwatson> You should get a few silos clearing out soon
<seb128> robru, no, I don't, and I might be wrong there, check with didrocks tomorrow
<robru> cjwatson, thanks
<robru> seb128, got you silo 19 for line 37 anyway. eep!
<seb128> robru, thanks
<t1mp> ogra_ / plars any ideas what I could look for that causes these protocol faults after adb reboot?
<ogra_> how do you reboot ? "adb reboot" or from the logged in shell ?
<t1mp> ogra_: adb reboot, but I just tried reboot from shell on device and that gives the same problem
<ogra_> ok, i had hopes :)
<t1mp> ogra_: with the ubuntu-test-cases scripts I have the problem also (that's when I first noticed it)
<t1mp> yes me too, until 20s ago..
<t1mp> plars: would the tests fail if I edit the reboot-and-wait script not to do anything? Then at least I can run some tests with the scripts now
<ogra_> did you try just adding a sleep so adb waits a little ?
<t1mp> nope, didn't try that
<t1mp> I'm just getting started with these scripts https://code.launchpad.net/ubuntu-test-cases/touch and they use the adb wait-for-device
<ogra_> sounds like a valid workaround
* plars changed the topic of #ubuntu-ci-eng to:  Ubuntu CI Engineering Team | Vanguard: plars | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<plars> t1mp: some of them might interfere with others, not sure
<kgunn> cyphermox: robru....can i get some reconfig love on silo4 ? added a new mp
<robru> kgunn, is it a new project?
<kgunn> robru: nope just a new mp from mir
<robru> kgunn, we got some new crack today ;-)
<robru> kgunn, you can do the reconfig yourself, and you don't even have to copy&paste
<robru> kgunn, just click reconfig and it does it all for you
<kgunn> robru: oh...whoop whoop
<robru> thank didrocks for that ;-)
<kgunn> i recall the copy/paste...didnt realize new mp's as well
<robru> kgunn, yeah, you can reconfig yourself as long as it's not a new project. any change within existing projects is fine (add/remove mps)
<kgunn> sweet...ok, i'm off to try
<jhodapp> robru, could you rekick land-006 to build again?
<davmor2> cyphermox: I had 10 minutes befoer EOD \o/  so new mtp does indeed update when you remove stuff now \o/  Rhythmbox does indeed still just show unknowns but that is just for confirmations sake :)
<robru> jhodapp, sure
<jhodapp> thanks
<cyphermox> davmor2: yeah, as soon as I'm more done with NM and urfkill and others I'll get back and fix that, I already have a good idea what to do and how to do it, just need to write it in code
<cyphermox> I'll add thumbnails too so images should show up in nautilus
<davmor2> cyphermox: go work so far at least :)
<davmor2> s/go/good
<davmor2> cyphermox: oh interesting, so it updated if you delete but I had to hit refresh to show the file I added via adb
<cyphermox> yeah
<davmor2> cyphermox: so that is expected?
<cyphermox> I think that's broken in gvfs; going to need to dig deeper in that
<davmor2> cyphermox: oh hang on of course this box is on saucy still I'll give it a go in trusty after I set my box up again
<cyphermox> well I saw the same on trusty
<davmor2> cyphermox: at least it actually refreshes though it didn't before on adding or removing files so +1 :)
<robru> cjwatson, can I get you to push unity8 through proposed pretty please?
<cyphermox> davmor2: confirmed that this is a limitation in gvfs -- I can fix now :)
<bfiller> robru: landing-009 has been building for like 8 hours it seems
<robru> hmm
<bfiller> robru: don't think it's trying to rebuild oxide, but if it is that might explain it
<bfiller> should just be building webbrowser-app
<robru> bfiller, no, it looks like it's stuck in depwait for ppc64el, powerpc, and arm64.
<robru> bfiller, precisely because oxide is unavailable there
<robru> bfiller, the other arches are done building if you want to do some testing there
<bfiller> robru: should we change webbrowser app so it doesn't try to build on those arches? don't think oxide supports those yet
<robru> bfiller, that's fine by me
<robru> bfiller, you might want to consult cjwatson about this though, he knows more about it and also bringing up those arches seems to be his personal mission
<pmcgowan> bfiller, we should not support those arches anyway
<pmcgowan> bfiller, none of our apps should target them
<pmcgowan> was just wondering why that silo was still building
<pmcgowan> well arm64 is ok
<bfiller> robru: right, cjwatson webbrowser-app previously built on all the arches, but we're pushing a new version that using oxide backend instead of qtwebkit. oxide only builds for 3 arches
<robru> bfiller, oh right, I forgot this is technically a regression. so yeah, we need cjwatson to clear the previous binaries out so that it allows us to not build on those arches
<bfiller> pmcgowan: the apps don't target them specifically, but if arch set to "any" then it tries to build them if it has previosly
<pmcgowan> bfiller, right, we should call out the specific ones we care about
<bfiller> robru what's the syntax for specifying multiple specific arches in debian/control?
<robru> bfiller, one sec
<robru> bfiller, here's an example: https://code.launchpad.net/~bregma/unity8-desktop-session/restrict-target-arches/+merge/208397
<robru> line 17 of the diff
<boiko> robru: landing-008 tested and ready
<bfiller> robru: thanks
<robru> boiko, great!
<robru> bfiller, you're welcoe
<boiko> robru: you can leave my other request unassigned for now to not lock any silo (as I will only be able to build and test it tomorrow)
<robru> boiko, ok, just don't set it 'yes' then
<boiko> robru: well, it is ready, it is just that I am finishing my working day already :)
<boiko> robru: I will set it to No and then tomorrow morning I set it to yes again
<robru> boiko, ok :-P
<robru> yes please
<robru> thanks
<boiko> :)
<rsalveti> plars: robru: not sure if anyone wants to debug that: http://162.213.34.102/job/landing-007-1-build/60/console
<rsalveti> Connection failed, aborting. Check your network [Errno -3] Temporary failure in name resolution
<rsalveti> Traceback (most recent call last):
<rsalveti>   File "/var/lib/jenkins/citrain/citrain
<rsalveti> just triggered another rebuild
<robru> rsalveti, yeah, sometimes the network is flaky, just rebuild
<plars> retoaded: have you seen a lot of those lately?
<plars> rsalveti: yeah, let me know if it happens again
<rsalveti> sure, thanks
<retoaded> plars, haven't seen many at all here lately.
<robru> plars, i see it once a week maybe. not a huge problem, retry always works for me
<retoaded> plars, I don't believe that jenkins instance uses the labs network infrastructure though.
<Saviq> hmm robru, can you explain this failure http://162.213.34.102/job/landing-004-1-build/83/console ?
<Saviq> ah maybe I know
<robru> Saviq, this is due to having unity8 in more than one silo at a time
<Saviq> robru, oh
<robru> Saviq, in particular there's a version of unity that's in the archive, and not been merged yet.
<Saviq> robru, right, we have one stuck in proposed...
 * Saviq forces then
<Saviq> it's a prelim silo anyway
<robru> Saviq, yeah I guess force for now, but you will have to rebuild once that other one does merge & clean
<Saviq> robru, of course
<robru> ok
<bfiller> robru: can you kill the build on silo 9? I'm going to reconfigure with a new MR that restricts the arches
<robru> bfiller, ok
<rsalveti> jhodapp|bbl: hm, you merged gst 1.2.3 in your branch
<rsalveti> jhodapp|bbl: would be better if you could rebase your changes instead
<rsalveti> otherwise it's a pita to know what really changed
<rsalveti> with a rebase I can only do git diff <last-known-hash-from-upstream>..
<rsalveti> and create the diff needed by our package
<rsalveti> now I need to create another branch just with upstream
<rsalveti> and compare both branches
* plars changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<cyphermox> davmor2: fixed the case for pictures showing up in MTP now :D
<jhodapp> rsalveti, ok I'll keep that in mind going forward, had no idea it'd impact your part of the process since I didn't know exactly how you do things to push my changes
<rsalveti> jhodapp: yeah, no worries, did a diff from upstream..master
<rsalveti> jhodapp: seems it worked fine
<rsalveti> jhodapp: it's also easier when upstreaming the changes
<jhodapp> rsalveti, thank you, sorry for the extra trouble
<rsalveti> as you just check whatever is on top
<rsalveti> no worries
<jhodapp> rsalveti, yeah, just my inexperience with git
<rsalveti> yeah, it's almost impossible to do a rebase with bzr
<rsalveti> but with git is so easy :-)
<jhodapp> rsalveti, so you want rebase so that it mixes the upstream history with mine and keep things as distinct commits, right?
<jhodapp> rsalveti, btw, the tests all pass for me but I see that it's failing on amd64
<rsalveti> jhodapp: yeah, just upstream + your patches on top
<rsalveti> hm, mediahub here failed for amd64, i386 and armhf
<rsalveti> https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+packages
<jhodapp> thanks, was looking for that link again
<jhodapp> it fails for everything, crap
<jhodapp> that output isn't that helpful as it just segfaults
<jhodapp> rsalveti, oh hey, I just ran it in a schroot on amd64 and it segfaulted, so it's most likely the same thing
<rsalveti> yeah
<jhodapp> rsalveti, it's because it's trying to call into libhybris
<bfiller> robru: landing 1 ready for release
<rsalveti> jhodapp: right, thought it could be that
<rsalveti> jhodapp: so we either need to change the test to not do that, or simulate the hybris environment
<robru> bfiller, great
<rsalveti> as it needs to be tested in the builder
<rsalveti> jhodapp: gst-plugins-bad should be in the ppa in a few minutes
<jhodapp> rsalveti, well I'm in the process of rewriting/updating the tests for everything, so for now so we can get a test image, I'm going to disabled them
<robru> bfiller, just getting a core dev ack on the packaging changes
<bfiller> robru: np
<jhodapp> rsalveti, try the build again
<rsalveti> jhodapp: alright
<rsalveti> doing a rebuild
<jhodapp> rsalveti, it makes sense that the tests passed for me on arm...it's an actual device :)
<rsalveti> jhodapp: right :-)
<jhodapp> rsalveti, I'm definitely going to have to do some libhybris mocking
<jhodapp> rsalveti, be back in about 20 mins to check on the build
<robru> ogra_, hey what's going on in line 43?
<ogra_> nothing until you have a free silo for it :)
<robru> ogra_, it's not filled out right though.
<ogra_> what is missing ?
<robru> ogra_, if you're just doing a source package upload, put the source package name in the source package column. your MP list is invalid
<ogra_> you mean in the "additional" source packages ?
<ogra_> i kind of thought it was for additional packages :)
<robru> ogra_, it's for anything that isn't an MP...
<robru> ogra_, ok you got silo 7
<jhodapp> rsalveti, looks like media-hub passed now except for those 3 more obscure architectures due to missing libhybris-dev for those architectures
<ogra_> robru, merci
<robru> ogra_, you're welcome
<robru> jdstrand, did you want a silo for line 40? it looks ready but you didn't mark 'ready: yes'
<robru> bfiller, do you want a silo for line 42? looks ready but you didn't mark 'ready: yes'
<jhodapp> rsalveti, and why couldn't qtubuntu-media find libmedia-hub-dev, it should be getting created
<bfiller> robru: not yet, waiting to add another MR first
<robru> bfiller, ok no worries
<jhodapp> robru, how is the build order of MRs in a silo PPA determined?
<robru> jhodapp, the MR's are merged in the order they're listed, but the build order is determined by python-dictionary-access-order, eg, random-but-repeatable.
<jhodapp> robru, ok, because it almost seems like media-hub was built after qtubuntu-media in this landing ppa: https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+packages
<jhodapp> robru, but that's not good because qtubuntu-media needs libmedia-hub-dev
<robru> jhodapp, well it's entirely possible. if you need to specify a build order, then you should clarify the build dependencies in debian/control (eg, specify that one thing needs a specific new version of another thing). then the builds will happen in the right order.
<jhodapp> robru, ok, so I'm not sure what version will result since this is the very first time media-hub has been built (my packaging foo is not strong)
<jhodapp> robru, nevermind, scratch that
<robru> jhodapp, just use whatever version number exists in the PPA already, but say > than that number
<jhodapp> yeah ok
<jhodapp> robru, could you kick that landing ppa for me again?
<robru> jhodapp, you  mean the build job?
<jhodapp> yeah
<robru> jhodapp, which silo?
<jhodapp> 006
<robru> jhodapp, ok, building
<jhodapp> thanks
<robru> jhodapp, you're welcome
<cjwatson> robru: unity8> done
<robru> cjwatson, thank you!
<cjwatson> bfiller: if you listed specific arches in webbrowser-app's debian/control, please revert that.  it's quite unnecessary
<cjwatson> pmcgowan is technically wrong on this :)
<cjwatson> bfiller,robru: I've removed qtdeclarative5-ubuntu-ui-extras-browser-plugin webapp-container webbrowser-app from arm64/powerpc/ppc64el on trusty, so nothing should block on that any more
<robru> cjwatson, oh excellent, thanks again
<robru> cjwatson, bfiller is probably EOD, I'll email him
#ubuntu-ci-eng 2014-03-28
<cjwatson> yeah, there was a totally unnecessary change there, people need to stop being clueless about this :-/
<cjwatson> unnecessary and non-productive
<cjwatson> robru,bfiller: the reasoning is that we shouldn't have hardcoded arch lists where we don't need to; it's technical debt.  and in this case it didn't help in the slightest because a hardcoded arch list does not have any influence on proposed-migration's rules about regressions in architecture support.
<robru> cjwatson, heh.
<ogra_> robru, silo 7 is ready
<robru> ogra_, thanks
<robru> ogra_, please mark it as testing pass in the spreadsheet
 * cjwatson is beginning to get the impression that this stuff is only done right when he's around all the time :-/
<ogra_> oops, yep
<robru> cjwatson, maybe you should lead some kind of info session at the next sprint
<cjwatson> "stop freaking out about architectures you don't care about"
<cjwatson> end of session
<ogra_> :)
<cjwatson> basically just leave things alone unless people who know about this stuff tell you otherwise
<cjwatson> I mean seriously don't know what else to say
<robru> ogra_, ok published
<ogra_> thanks
<ogra_> bootspeed++ tomorrow ;)
<robru> ogra_, great
<robru> cjwatson, i would absolutely love to stop freaking out about arches. seems every day there's depwaits causing problems though. maybe if I wasn't spending all my time waiting for you to resolve depwaits I wouldn't freak out about it
<cjwatson> but this wasn't a problem
<cjwatson> iolypeople freaked out totally unnecessary
<cjwatson> sigh
<cjwatson> people
<cjwatson> freaked out totally unnecessarily
<cjwatson> lag
<cjwatson> and applied a change that did ABSOLUTELY NOTHING to fix the problem
<cjwatson> if people had done the basic due diligence of searching scrollback they would have found that I had explained the problem and solution in detail in this very channel
<cjwatson> so I am pretty pissed off that nobody could be bothered
<robru> cjwatson, IRC is the most ephemeral communication medium there is. not everybody has scrollback, not everybody was signed on when you said whatever you said. "just read the scrollback" is literally the worst advice you can give anybody.
<cjwatson> or, you know, wait until somebody qualified is around before committing flailing patches.
<cjwatson> doesn't take that long.
<cjwatson> my conclusion is that non-core-devs are not qualified to mess with the Architecture field.
<cjwatson> sure, in this case maybe it doesn't matter a whole lot, but this sort of flailing is why new ports are a vastly unnecessary amount of effort.
<cjwatson> which is why it annoys me
<infinity> Not even just new ports, but an old port suddenly getting a new stack available to it, and then having to unwind all the brain damage to make it work.
<infinity> (say, qtdeclarative on powerpc)
<cjwatson> it's short-termism.
<cjwatson> anyway, I also expected that explaining the situation to the webapps team engineering manager and agreeing with him that he would let me know when they were ready to land and I'd take care of it would be sufficient.
<robru> cjwatson, unfortunately bfiller and dbarth are different people. I question the assumption that you can tell dbarth one thing and expect bfiller to know it. I'm flattered, really, but we are not psychic.
<cjwatson> I expect people to not flail.
<cjwatson> Understand the consequences of your change before making it.  If the consequences are nil right now and maybe negative in the future, then try not making it.
<robru> cjwatson, you're a really pompous asshole, actually. Do you think we consciously decide to do ineffectual things? The arch change was made becuase we (get this) *actually thought it would solve the problem*
<cjwatson> well sorry but I keep trying to explain this and nobody seems to be listening, so I'm sorry if I get annoyed about it
<cjwatson> also just back from the pub :)
<infinity> It's not remotely the first time that the harm in arch restriction has been pointed out. :/
<cjwatson> but I wish people would recognise that we aren't actually doing these ports for fun
<infinity> Perhaps the most forcefully and grumpily.
<cjwatson> you and your "cjwatson's personal mission"
<cjwatson> I'm trying to get my job done
<robru> cjwatson, that was a joke because you're the only person I ever hear talking about this arch stuff.
<infinity> robru: Lots of us talk about it.
<robru> infinity, not to me, or in this channel.
<infinity> robru: But most of us don't hang out in here and talk about it.  Colin braves these waters.
<infinity> To be fair, this channel is a really narrow and limited view of Ubuntu development.
<robru> infinity, every channel is a really narrow and limited view of ubuntu development. that's the point of having channels.
<infinity> Except that crazy ubuntu-devel channel.
<infinity> Where this has been pointed out time and again.
<cjwatson> I have been saying for a couple of weeks now several variations of the theme "if you have a problem with the non-primary ports, please come and talk to us before you change things, we're happy to help"
<infinity> Granted, maybe seb and didier aren't relaying the messages back everytime someone like me gets annoyed, again.
<robru> infinity, yep, nope havent' heard about this from seb or didier for sure
<robru> cjwatson, yes, I've heard about it from you a few times, I'm sorry that I don't memorize every detail about -proposed, this might surprise you but it's (usually) not very relevant to the work that I do each day.
<cjwatson> right, so I've bent over *backwards* to help you guys at some really strange times for me
<infinity> robru: If proposed isn't relevant to you, then why go about trying to trick it? :P
<cjwatson> I had hoped that this might be an indication that I could be relied upon to help in the future
<robru> infinity, because in this rare and isolated case it became relevant briefly.
<cjwatson> and you don't have to memorise it, it's documented
<infinity> robru: Anyhow, can we pass around the very simple rule that "arch-restriction is for things that literally can never work on an arch" (like, say, powerpc-utils, or intel-pstate).
<robru> cjwatson, just checked the scrollback. 3hrs elapsed between when bfiller asked me for the arch details and when you got here. you can't really just expect people to wait 3hrs for whatever without trying things that they can do that they think might help
<cjwatson> people expect me to wait three hours for things all the time
<robru> infinity, ok, yes, some better communication is warranted
<robru> cjwatson, that's not what I said
<cjwatson> I'm afraid this is a particular hot button because it's something that causes porting teams to have to do lots of really boring work
<robru> cjwatson, of course we can be expected to wait up to a day if you're sleeping or whatever. but what I mean is, it's reasonable that while we're waiting, if we have an idea that we don't realize won't work, we'll try it.
<cjwatson> I guess I would be less frustrated if this were the first time
<cjwatson> from my perspective this is like the twentieth time I've had this.  I realise that from your perspective this may be unfair, sorry
<robru> cjwatson, you're right, I should have remembered, but I didn't, and bfiller just asked for the syntax before I could think it through and remember it wouldn't work
<cjwatson> and it's kind of impossible for me to guess who I need to inform about something.  FWIW my comment earlier was basically "I am happy to fix this for you, but please let me know when you're ready to land because if I do it earlier I might end up having to do the work twice and I'd prefer to avoid that"
<infinity> "Not knowing who to inform" is why I often just inform seb or didier and I suspect it gets lost in the telephone game.
<cjwatson> so I'd expected David to pass that on as necessary because it was explicitly an interaction thing
<infinity> I suspect Canonical upstreams aren't really aware of how amazingly opaque some of their uploads appear to the average core-dev, without doing commit-level blames.
<cjwatson> I'm not bothered by opacity in this case, I knew what was going on.  But I'd tried to be as helpful as clear as I could be
<cjwatson> *and clear
<jdstrand> robru: it wasn't ready at the time, but it is now
<robru> jdstrand, great
<jdstrand> robru: so, yes, if I could have a silo, that would be great (these are just bug fixes)
<jdstrand> robru: I'll do the pocket copy like last time
<robru> jdstrand, sure thing. you got silo 8
<jdstrand> robru: thanks!
<robru> jdstrand, you're welcome
<robru> cjwatson, ok, well, i don't think there's much left to say at this point. there were many small failures of communication. thanks for fixing the issue on your end. I emailed bill to tell him to revert the arch changes so he'll get to that tomorrow.
<cjwatson> ok, I'm sorry for being intemperate
<robru> cjwatson, ugh, me too
<cjwatson> is that silo ready to land so I can check it, or is it waiting for tomorrow?
<cjwatson> (I can't easily check it until it hits -proposed, unfortunately)
<robru> cjwatson, bill will have to rebuild it tomorrow, it's not ready
<cjwatson> ok, I'll be around until at least 1800 UTC, SMSable after that point
<robru> cjwatson, ok thanks
<rsalveti> jhodapp|afk: yeah, there's no specific order, you need to make sure the build-deps are specified correctly, and with the right version
<jhodapp|afk> rsalveti, yeah I did modify that but it didn't seem to do the trick
<jhodapp|afk> rsalveti, media-hub must come before qtubuntu-media, and so I set that build-dep version of media-hub for qtubuntu-media...didn't seem to make a difference
<jhodapp|afk> rsalveti, I take that back, it did make a difference, but it seems that the qtubuntu-media build, which uses a header from libmedia-hub-dev, uses headers from libdbus-cpp-dev, but those are missing from the build
<cjwatson> if you've set a strict build-dep then it would be impossible for the latter to build without the declared requirements
<jhodapp|afk> cjwatson, yeah
<cjwatson> jhodapp|afk: which silo's this?
<jhodapp|afk> 006
 * cjwatson looks
<cjwatson> jhodapp|afk: looking at https://launchpadlibrarian.net/170907017/buildlog_ubuntu-trusty-amd64.qtubuntu-media_0.7.1%2B14.04.20140327.4-0ubuntu1_FAILEDTOBUILD.txt.gz, it *looks* as though whatever package ships /usr/include/core/media/player.h is missing a dependency on libproperties-cpp-dev
<jhodapp|afk> cjwatson, let me check
<jhodapp|afk> cjwatson, nope, it has it as a build-dep
<cjwatson> runtime dep
<cjwatson> which package ships /usr/include/core/media/player.h ?
<jhodapp|afk> libmedia-hub-dev
<cjwatson> right, so libmedia-hub-dev should Depends: libproperties-cpp-dev
<cjwatson> Build-Depends isn't sufficient - that's only taken into consideration when building media-hub itself
<cjwatson> not when building stuff that depends on it
<jhodapp|afk> ah, I didn't know that
<jhodapp|afk> that makes sense now
<jhodapp|afk> cjwatson, thanks
<cjwatson> you generally don't want to fill in everything from Build-Depends into your -dev package's Depends, but anything that provides header files you include definitely needs to be there
<cjwatson> np
<jhodapp|afk> ok
<jhodapp|afk> learned something new today :)
<cjwatson> either the landing team folks or anyone in ~launchpad-buildd-admins can retry the failed builds after you've fixed media-hub
<cjwatson> (no need to trigger a fresh upload of qtubuntu-media)
<jhodapp|afk> ok
<jhodapp|afk> cjwatson, does that include you?
<jhodapp|afk> cjwatson, just pushed the fix, so it's ready to try the build again
<cjwatson> jhodapp: it does, although presumably it'll take a little while for media-hub to build and publish
<cjwatson> jhodapp: oh, have you poked the jenkins job?
<jhodapp> cjwatson, I just pushed a new version of media-hub
<cjwatson> jhodapp: right, but just to bzr, by the looks of things?
<jhodapp> cjwatson, yes
<cjwatson> ok, let me see if I can move that along for you
<jhodapp> thanks much
<cjwatson> jhodapp: media-hub building
<jhodapp> excellent
<cjwatson> infinity: I think I need to go to bed - could you retry qtubuntu-media/{amd64,armhf,i386} in https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+packages once the latest media-hub has built and published there?
<infinity> cjwatson: Yeahp.
<cjwatson> Ta
<bregma> rsalveti, would you be willing to grant me a silo for line 44?
<cjwatson> jhodapp: ^- handing over
<jhodapp> thanks cjwatson
<rsalveti> jhodapp: yeah, runtime build-dep only works automatically like that when you have a dependency at the library level
<rsalveti> not in the header itself
<rsalveti> but great that cjwatson was able to help you
 * rsalveti is preparing dinner
<jhodapp> rsalveti, ok, there's still much about packaging
<jhodapp> much to learn
<rsalveti> jhodapp: do you need me to trigger another build?
<jhodapp> rsalveti, yeah, try qtubuntu-media
<jhodapp> media-hub just about finished
<rsalveti> right, but I can trigger another rebuild for everything
<jhodapp> ok
<rsalveti> easier and good to know if we're all good in the dep level
<rsalveti> bregma: don't have enough permission to allocate a silo :-(
<rsalveti> oh, colin did a rebuild in the silo itself
<rsalveti> so yeah, let's just wait
<rsalveti> brb
<infinity> cjwatson: Hrm, was that expected to build? :P
<imgbot> === trainguard: IMAGE 265 building (started: 20140328-03:05) ===
<jhodapp> rsalveti, did you kick off another build for qtubuntu-media?
<rsalveti> jhodapp: nops, can do that
<rsalveti> just a sec
<jhodapp> rsalveti, k thanks
<jhodapp> rsalveti, media-hub builds just fine except for 3 architectures that libhybris isn't built for
<rsalveti> right, that's fine
<rsalveti> ok, triggered a new build for qtubuntu-media
<rsalveti> let's wait a few minutes and we should know if it worked or not
<jhodapp> alright, cross your fingers :)
<rsalveti> yeah :-)
<jhodapp> rsalveti, ok so I just need to temporarily disable the tests for this and then it'll build successfully
<rsalveti> are you sure?
<rsalveti> ../src/aal/aalvideorenderercontrol.cpp: In member function 'void AalVideoRendererControl::updateVideoTexture()':
<rsalveti> ../src/aal/aalvideorenderercontrol.cpp:162:97: error: cast from 'AalMediaPlayerService::GLConsumerWrapperHybris {aka void*}' to 'unsigned int' loses precision [-fpermissive]
<rsalveti>          frame.setMetaData("GLConsumer", QVariant::fromValue((unsigned int)m_service->glConsumer()));
<rsalveti>                                                                                                  ^
<rsalveti> check the latest build, failed for all arches
<rsalveti> armhf failed when running the test cases indeed
<jhodapp> rsalveti, yeah that's for the amd64 case and I fixed that earlier for my schroot
<rsalveti> and it failed differently on i386
<jhodapp> lol
<rsalveti> no, this was amd64
<jhodapp> ok
<rsalveti> sorry, thought you said arm64
<jhodapp> I'll fix that too with what I did earlier
<rsalveti> https://launchpadlibrarian.net/170926953/buildlog_ubuntu-trusty-i386.qtubuntu-media_0.7.1%2B14.04.20140328-0ubuntu1_FAILEDTOBUILD.txt.gz
<rsalveti> jhodapp: right, just let me know when you're ready for another rebuild
<jhodapp> k
<rsalveti> kgunn: when are you planning to land the landscape mode?
<kgunn> rsalveti: let me chat it up tomorrow...its definitely been pushed to back burner....
<kgunn> anyone begging for it ?
<rsalveti> no, just curious
<kgunn> i realize its nice...
<kgunn> ok, lemme check
<rsalveti> as you said you're about to land the right edge navigation I thought the landscape mode would be close as well
<rsalveti> but don't worry, as I said, just curious :-)
<jhodapp> rsalveti, so I have a fix for 2 architectures, but the i386 issue I'm not sure about yet...it's a clash between the qgl stuff and the platform GLES headers
<rsalveti> weird, conflicting declaration
<jhodapp> rsalveti, yeah, which we've seen before but I thought was taken care of more at a platform level
<jhodapp> or similar to it
<rsalveti> maybe you don't actually need to include the GLES headers when you already included qopengl.h
<rsalveti> or qgl.h
<rsalveti> just not sure why this didn't happen on amd64
<rsalveti> it could be a gles x gl thing (as qt uses gles only on armhf), but not the case here it seems
<jhodapp> rsalveti, hmm yeah
<jhodapp> rsalveti, I'm going to take a fresh look in the morning, my eyes are too tired
<jhodapp> rsalveti, have a great night
<rsalveti> yeah, better, you too
<imgbot> === trainguard: IMAGE 265 DONE (finished: 20140328-04:30) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/265.changes ===
<Mirv> jdstrand: I ran "watch only" built for landing-008 / apparmor, the publishing could work now
<Mirv> jdstrand: and yes, it worked now
<Mirv> didrocks: morning. when you have time, I'm getting an error when using prepare silo http://162.213.34.102/job/prepare-silo/728/console
<didrocks> oh?
 * didrocks looks
<didrocks> Mirv: what line is it?
<Mirv> prepare-silo-using-spreadsheet-info", line 89
<didrocks> Mirv: no, I meant on the spreadsheet :)
<Mirv> yeah, I was wondering :) line 35 seb
<didrocks> ok
<Mirv> I first tried the tempting "experimental" option, and got the same error
<didrocks> someone should have entered non ascii chars on the spreadsheet I guess
<didrocks> yeah
<Mirv> ascii should be enough for everybody
<didrocks> heh :)
<Mirv> yeah, it's on the unity7 landing line
<Mirv> â character
<Mirv> I can remove it or you can debug it
<didrocks> let me try something
<didrocks> Mirv: fixed!
<Mirv> so it seems from your prepare-silo run :)
<didrocks> yeah ;)
<didrocks> (and deployed)
<bzoltan> Hello Mirv, may I ask for  Silo for the line 47?
<Mirv> bzoltan: sure
<bzoltan> Mirv:  thanks
<Mirv> didrocks: there'd be messaging-app packaging ack http://162.213.34.102/job/landing-001-2-publish/63/artifact/packaging_changes_messaging-app_0.1+14.04.20140327-0ubuntu1.diff
<Mirv> bzoltan: landing-010 ready for build
<bzoltan> Mirv:  thanks
<didrocks> Mirv: +1
<Mirv> thanks
<Mirv> didrocks: can I bug you with NEW review of qtlocation packaging merge with Debian, for which I got FFe approval bug #1298208 ? FFe just states that I need to find a willing archive admin. it's ready to be published, and splits the -dev package into two plus adds doc packages.
<ubot5> bug 1298208 in qtlocation-opensource-src (Ubuntu) "[FFe] Qt Location sync packaging with Debian (new binary package)" [Wishlist,Triaged] https://launchpad.net/bugs/1298208
<Mirv> the reason for FFe was that the packaging merge introduces those "new" packages (old content though regarding the dev package)
<didrocks> Mirv: do you have a debdiff on the bug?
<didrocks> Mirv: it's a binary NEW, so yeah
<Mirv> didrocks: via the buildlog link, yes https://launchpadlibrarian.net/170841866/qtlocation-opensource-src_5.2.1-0ubuntu1_5.2.1-1ubuntu1.diff.gz
<Mirv> it's mitya57's work, I just commented and tested it
<didrocks> Mirv: you didn't discuss with him with the finale , and so on?
<didrocks> and it's inconsistent, some, still have :/
<Mirv> didrocks: finale?
<Mirv> so it's consensus on what Debian agrees to do when they package qtlocation fully
<didrocks> Mirv: like the last dep having ,
<Mirv> yeah, sure, that's just what pkg-kde does
<didrocks> arghâ¦
<didrocks> I hate when you get useless diff
<Mirv> they've removed my ,:s from many places :)
<didrocks> Mirv: weird that they impose their standard on us
<didrocks> as we are upstream for it
<didrocks> Mirv: I don't think it's good to sacrifize that
<Mirv> they don't see it that way, they just have their habits and if we keep bigger delta then it's harder for us to diff what's different in packaging to them
<Mirv> now I can do diff -urN debian/ ubuntu/ quite easily, but I need to keep on adapting to the styles they use
<Mirv> the interesting parts of the diff are the Breaks/Replaces and that qtlocation5-dev depends on the new qtpositioning5-dev, so everything continues to work
<Mirv> nothing else has really changed on practical level
<didrocks> Mirv: yeah, but what about our consistency?
<didrocks> Mirv: anyway, ok, it's not part of the archive review and we are not upstream (as upstream dev) for it
<didrocks> so +1
<Mirv> didrocks: our Qt packaging is nowadays pretty consistent with Debian, so we have less ending ,:s there to make it easier to diff between the two
<didrocks> but don't introduce the same on the other packages pleaseâ¦
<Mirv> wrap-and-sort -a -t is the default for everything we are upstream to
<didrocks> interesting that they don't unmangle the symbols
<didrocks> not sure how it builds on all archs
<Mirv> it built fine https://launchpad.net/~ci-train-ppa-service/+archive/landing-016/+packages
<didrocks> Mirv: ok, you can release
<Mirv> done
<Mirv> well, it's in the unapproved queue first since some others seed it
<didrocks> ok
<didrocks> Mirv: as we are low on silo, I would say let's assign/m&c ourselves today
<didrocks> sil2100: ^
<didrocks> if people aren't around
<Mirv> sure
<Mirv> soon at 3 again
<ogra_> hmm, seems screen unlocking failed for all tests ... would be so nice to have a powerd and a unity8 log (both had changes related to that)
<vila> yeah, just finished deciphering all nagios/pager duty mess about *4* makos having issues, 2 are down now
<vila> the others seem to have trigger a bunch of test failures indeed related to screen unlocking
<ogra_> right
<vila> I've restarted http://q-jenkins.ubuntu-ci:8080/job/trusty-touch-mako-smoke-daily/190/console as a full run
<vila> for #265 that is
<ogra_> and both, powerd itself (emulator related) and unity8 (taking over power setting management) had changes that could cause this
<vila> ogra_: we discussed the raise of mako failures yesterday, no explanation so far
<vila> ogra_: ha, great
<ogra_> i would actually blame the latter
<ogra_> i.e. the dbus address might have changed
<vila> ogra_: something that can be reproduced locally ?
<ogra_> dunno, 2M line here ... i'm still downloading
<ogra_> ;)
<vila> ;)
 * vila starts diff'ing MB files again O_o
<vila> failed to open trace file: [Errno 20] Not a directory: '/dev/null/.bzr.log' yeah really ? Someone did set HOME to /dev/null ???
<vila> not a failure, just....
<ogra_> created by some automation thingie ?
<vila> ogra_: forget about it, just a distraction, probably there for ages
<vila> ogra_: sorry for even mentioning it ;)
<ogra_> lol
<ogra_> aha, seems powerd changed its dbus policy file
<ogra_> http://launchpadlibrarian.net/170895519/powerd_0.13%2B14.04.20140129-0ubuntu1_0.13%2B14.04.20140327-0ubuntu1.diff.gz
 * ogra_ assumes thats related
<sil2100> geh, feel sicklish todays
<didrocks> sil2100: :( headache?
<didrocks> ogra_: yeah, agreed
<sil2100> didrocks: some pain in the bones and nausea, seems like I might be sick during the weekend
<sil2100> Lucky me ;p
<ogra_> 10min and my install will be done, i'll take a look
<didrocks> vila: I'm afraid that if the lock issue is still there, you would have to downgrade powerd on the device (we can help you getting the debs)
<didrocks> sil2100: argh, not nice. Too many germs exchange at your exercise time yesterday I guess :/
<ogra_> yay
<ogra_> http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-265.png
<didrocks> ogra_: powerd?
<ogra_> didrocks, no, my changes
<didrocks> again, all your fault! :)
<didrocks> please add that to your testing plan :p
<ogra_> all CPU cores are on now so we get a much snappier boot
<ogra_> and ureadahead works (as you can see in the disk usage chart there is a big burst at the start)
<didrocks> oh, you are not talking about screen unlocking?
<ogra_> i'm confident we can get to 20second boots :)
<sil2100> didrocks, Mirv: should we still leave 3 silos free, or should we only consider upmost 1?
<didrocks> sweet!
<ogra_> not at all
<ogra_> talking about the good things ;)
<didrocks> ogra_: heh, I thought you were on the bad things :)
 * ogra_ goes to look at the bad things now 
<didrocks> sil2100: I would go for it, and maybe assign more even, knowing that we can flush the unity8 split greeter one
<didrocks> sil2100: I would really count the flushable as "free ones"
<ogra_> http://paste.ubuntu.com/7167330/
 * sil2100 feels tempted to push the EXPERIMENTAL button
<ogra_> does it blink ?
<didrocks> ogra_: interface change?
<sil2100> ogra_: no :<
<ogra_> didrocks, permission change i think
<sil2100> But it's big and bluish
<didrocks> sil2100: it's robru doing that change, feel free, especially if you are not logged in
<didrocks> I asked him how that would react without getting logged in
<didrocks> and I don't know how this works with the options
<didrocks> ogra_: so, due to new powerd?
<didrocks> ogra_: can you try to revert powerd on your device?
<ogra_> didrocks, trying to chnage a part of the policy file change back, lest see
 * ogra_ reboots
<didrocks> ok :)
<ogra_> i think its only two lines at fault here ...
 * didrocks always like the "-ic" :)
<ogra_> if that doesnt help i'll do a complete revert
<didrocks> sounds good :)
 * ogra_ wits for the screen to suspend
<ogra_> bah, not enough
<didrocks> sil2100: rather than giving silos to ricardo, I would prefer we focus on fixing the blockers
<didrocks> sil2100: like the line 42 mentionned
<didrocks> (41 as well, but not ready yet)
<ogra_> didrocks, the prob is that the new autobrightness feature in unity8 uses the new powerd
<didrocks> ogra_: they were on the same silo I reckon?
<ogra_> no idea
<didrocks> seems not
<didrocks> Saviq: if we revert powerd, we will have to revert unity8?
<didrocks> weird those 2, if dependent on each others, were not in the same silo
<seb128> is anyone having a non uptodate device?
<ogra_> oh, wait, unlock-screen should only unlock ? it should not set the brightness ?
<Saviq> didrocks, yeah they were in separate silos indeed
<ogra_> i might be testing wrong
<ogra_> one sec
<didrocks> ogra_: yeah, only unlock
<didrocks> seb128: I do
<seb128> if anyone is having a non-uptodate-device I would appreciate testing of https://launchpad.net/~ci-train-ppa-service/+archive/landing-007/
<ogra_> ok, let me try that again
<seb128> it's integrating click updates to system updates
<seb128> didrocks, ^
<didrocks> seb128: not sure we have new click packages though
<seb128> didrocks, if you could install that and do your update with it
<didrocks> seb128: ok, only system update?
<seb128> didrocks, well, main goal is ensure system updates are still solid :p
<didrocks> k ;)
<seb128> if you have no clicks
<seb128> if clicks have a bug that's ok, that's new code/feature and not a regression
<ogra_> oh, finally !
<didrocks> ogra_: not done yet
<seb128> I tested both system and click updates for the record, and that has mocks and autopilot tests
<seb128> so it should be fine
<didrocks> ogra_: don't shout victory :p
<ogra_> haha
<seb128> hehe
<didrocks> seb128: we still have system-image-dbus failing, right?
<seb128> we have been bouncing back until bugs and tests were fixed, so hopefully it's ok
<didrocks> (the mock crashing for weeks now)
<seb128> on desktop?
<didrocks> on the phone at least
<didrocks> it's barry's but not sure if you knew about it
<Saviq> didrocks, I don't think we'd need to revert unity8, the call to powerd would fail, but I don't think would have any consequences
<seb128> not that I noticed
<didrocks> Saviq: ok, good, thanks! :)
<seb128> the tests are green on the phone when run through phablet-test-run
<didrocks> seb128: yeah, but there is a crasher
<seb128> I didn't run into it
<seb128> well anyway, settings should be fine, but an extra confirmation would be welcome
<seb128> thanks ;-)
<didrocks> yeah
<dbarth> sil2100: good morning; i have finished testing silo 011; good to publish for me
<didrocks> seb128: confirmed, no click package showing
<ogra_> didrocks, ok, rolling back gets it to work again, but i would like to look if there is any fix we can do
<seb128> I guess you have none in the downloader app either?
<didrocks> at least, the install seems to work
<sil2100> dbarth: I'm already on it!
<didrocks> seb128: well, I have the bug where it shows the same available than what I installed :p
<seb128> haha
<didrocks> ogra_: ok, I think we should give it 30 minutes
<didrocks> ogra_: and revert otherwise
<didrocks> we have no test result on latest image
<didrocks> not good
<seb128> didrocks, ok, anyway I managed to test some click update so it should be fine
<didrocks> seb128: it rebooted and its installing the update now (and logs confirms)
<seb128> didrocks, let me know when your update is done, if it worked fine I'm going to land the silo
<didrocks> seb128: so +1 for me
<seb128> didrocks, thanks
<ogra_> didrocks, well, then revert it ... i doubt i can find something in 30min
<didrocks> ogra_: powerd, ok?
<ogra_> didrocks, yep
<sil2100> didrocks: packaging ACK needed! Looking safe http://162.213.34.102/job/landing-011-2-publish/34/artifact/packaging_changes_unity-webapps-qml_0.1+14.04.20140327-0ubuntu1.diff
 * didrocks fires up the reverter!
<didrocks> THE reverter :p
<sil2100> ;)
<didrocks> ogra_: do we have a bug report to track it?
<dbarth> oh wow, that sounds terrifying
<ogra_> not yet
<dbarth> didrocks: btw, thanks an awful lot for the new citrain interface
<dbarth> the new reconfig screen "just works"
<dbarth> :)
<Saviq> sil2100, hi, when you think we're better with remaining silos, could we get one for row 49 please?
<didrocks> dbarth: heh, yw! :)
<sil2100> Saviq: let me see ;)
<sil2100> Oh, that's something fresh, didn't see it a few minutes ago!
<didrocks> ogra_: mind putting more infos on bug #1298869?
<ubot5> bug 1298869 in powerd (Ubuntu) "Screen unlock broken on image #265 through test automation" [Undecided,New] https://launchpad.net/bugs/1298869
<sil2100> Saviq: yes, crashers have a bigger priority, let me assign
<vila> ogra_: thanks for confirming !
<vila> http://q-jenkins.ubuntu-ci:8080/job/trusty-touch-mako-smoke-daily/190/console is busted as well
<didrocks> vila: another way is to revert that manually on the device
<didrocks> rather than reverting on the image
* ev changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: ev | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<vila> didrocks: that won't help the automated tests right ?
<didrocks> vila: do you know how to connect to the devices?
<didrocks> vila: it will, but you have to run all test runs manually
<ogra_> oha
<ogra_> root@ubuntu-phablet:/# cat /var/log/upstart/powerd.log
<ogra_> dbus name lost or unable to acquire dbus name, is another copy of powerd running?
<ogra_> g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
<vila> in the lab ??
<ogra_> which is funny... powerd works fine
<didrocks> vila: yeah, that's what psivaa_ is doing most of the time
<didrocks> vila: seems you don't know how to do? (I don't either), if so, just tell me and I revert in distroâ¦
<vila> didrocks: yeah, absolutely no idea, I think psivaa_ does that locally not in the lab
<didrocks> ok, revert uploaded then
<didrocks> vila: I'm sure it's in the lab as then, he rerun the official jobs
<vila> didrocks: the reason being that the devices are flashed and adding manual steps to an automated process... urgh, I wouldn't trust any results coming out
<didrocks> vila: he's doing that and then rerun all slaves jobs AFAIK
<didrocks> (so don't rerun the flash and so on)
<vila> didrocks: ok, I'll discuss about that with him when he;s back then
<didrocks> thanks :)
<didrocks> so 90% of pass rate -> means no app/shell test run :p
<didrocks> ev: I guess this value is really something to work on, the logic is misleading if you don't know about it ^
<tvoss> sil2100, didrocks Mirv can I get a preliminary silo for line 48?
<vila> didrocks: yeah, tests not run are errors and not counting them anymore is messy
<didrocks> tvoss: it's for experimenting? we are very low on silo, so we are rather reclaiming them
<didrocks> vila: +1
<vila> didrocks: but at least on http://ci.ubuntu.com/smokeng/trusty/touch/ you have the total. A variation from ~640 to 134 is a clear indication something went horribly wrong
<vila> didrocks: not enough, but still valuable
<tvoss> didrocks, not experimenting, marcus and me are confident that the changes are good, but would like to provide reviewers with testing packages, too
<didrocks> vila: yeah, that should be in red mayve
<didrocks> maybe
<didrocks> vila: like loosing > 10% of tests?
<didrocks> tvoss: do you think you will release within the day?
<tvoss> didrocks, that's the plan, yes. If not, we can immediately flush
<vila> didrocks: good idea, not sure how easy it is (you need to compare by device)
<didrocks> tvoss: seems legit then
<tvoss> didrocks, thanks
<Mirv> didrocks: you or me?
<Mirv> we've indeed two flushable silos for emergencies
<didrocks> tvoss: putting the request to being ready?
<didrocks> Mirv: I'm doing it
<Mirv> thanks
<didrocks> Mirv: I'm flushing line 46 due to powerd revert
<ogra_> YIPPIEE !!!!
<ogra_> (imgbot reconnected on its own ... finally :) )
<didrocks> ogra_: hum?
<didrocks> ok :)
<tvoss> didrocks, can do so, kept it in not ready for the lack of approval
<didrocks> tvoss: ok, making sense (I didn't read the description when I asked it)
<didrocks> ERROR:root:https://code.launchpad.net/~marcustomlinson/process-cpp/fix_env_var_split doesn't seem to be a valid merge proposal url
<didrocks> tvoss: ^
<didrocks> sil2100: hum, seems you are not around, I'm assigning line 42 as discussed above
<seb128> didrocks, sil2100: can you get a silo for the unity desktop bugfix update in l44 once we get some? (I know touch is important but the lts also is, why that one got skipped over to get other silos assigned?)
<didrocks> Mirv: you as well, let's try to favor the releases
<Mirv> yes, I read that
<didrocks> seb128: we have no more silo at all, I hope we can reclaim some before bregma starts his day
<tvoss> didrocks, fixed
<seb128> didrocks, right, you assigned some to Saviq though :p
<seb128> where you had some
<seb128> when unity was waiting for longer
<didrocks> seb128: I didn't, but saviq is around
<didrocks> bregma isn't
<ogra_> heh, i think i found the issue .... the at_console powerd policy was dropped
<seb128> I'm around and wanting to test unity desktop
<seb128> should I change the lander to me?
<didrocks> seb128: yes please
<seb128> done
<Saviq> seb128, didrocks, we have the split greeter silo that can be flushed if needed
<sil2100> Ok
<Mirv> I think we could consider freeing up "Silo ready" ones that have been so for days
<sil2100> seb128, didrocks: was in the bathroom, will assign 44 then
<seb128> didrocks, I've landed 2 desktop changes, so we are going to have 2 silos back soon, I would appreciate getting one for unity then
<Mirv> like line10, thostr isn't around
<seb128> sil2100, ^
<sil2100> Mirv: good point
<didrocks> seb128: 5 silos are blocked by UNAPPROVED
<didrocks> this is going to become more and more of a trouble
<seb128> Laney, cjwatson: ^ can you help to let some unapproved in to get silos back?
<sil2100> Mirv: let me free the url-dispatcher one
<seb128> infinity, ^
<Laney> I don't believe it is 5
<didrocks> seb128: I ditched one silo, just waiting for the sync to happen and will assign you that one
<Mirv> sil2100: yeah, just do it. it wasn't requested in the first place, we just gave it but it hasn't seen any action
<Laney> https://launchpad.net/ubuntu/trusty/+queue?queue_state=1
<didrocks> Mirv: sil2100: agreed, please add a comment
<seb128> Laney, ubuntu-themes qtlocaltion indicator-power ... at least 3
<seb128> Laney, apparmor = 4
<Laney> Yep
<ogra_> didrocks, i got a fix
<Laney> Still exaggerating
<Laney> But yes, I'll look
<seb128> Laney, by 1, and I think that was u-s-s that got autoapproved
<didrocks> Laney: hum
<Laney> So it was never blocked by that then
<seb128> but let's not nitpick
<didrocks> Laney: I saw 5
<didrocks> when I looked at the spreadsheet
<didrocks> let me compare
<seb128> Laney, I think the status was "in unapproved" for a short time
<seb128> Laney, please let's assume honest mistakes
<Laney> Okay, I was seeing more "raargh release team blocking our work" coming ;)
<sil2100> ;)
<seb128> Laney, well, we can do friday trolling if you want :p
<didrocks> ubuntu-themes, ubuntu-system-settings, qtlocation-opensource-src, apparmor, indicator-power
<didrocks> was the one listed
<seb128> Laney, but it's more "urg, no silo, want to land u-c-c and other things, please help me" ;-)
<didrocks> so yeah, 4 + u-s-s
<seb128> didrocks, right, u-s-s was a short/transient one, thanks to the autoapprove bot
<didrocks> yep
<Mirv> dbarth: how's the oxide resolving of ppc64el/arm64/powerpc issues going? at least the silo claims to be 'building' while the build job is just stuck because it doesn't build for those archs it used to build for before
<didrocks> so no "exageration", just the status when looking at it, but really 4 blocked
<ogra_> didrocks, see the bug, patch attached
<didrocks> ogra_: feel free to revert my revert then and send it away
<didrocks> ogra_: want me to have a look?
<ogra_> didrocks, that would be good
<sil2100> Mirv: cjwatson was to look into that issue with dbarth from what I remember, not sure how that ended up?
<ogra_> is revert-revert a plain upload ?
<ogra_> or do you need the MP dance
<didrocks> dbarth: sil2100: -1 on the packaging change
<didrocks> ogra_: no, plain upload
<ogra_> awseom, will do that after the meeting then
<didrocks> dbarth: sil2100: liboxideqt-qmlplugin is in universe, is the MIR approved?
<didrocks> yeah, meeting, and still in night suitsâ¦
<didrocks> let me change
<ogra_> heh
<sil2100> didrocks: oh, should we also consider MIR mismatch on Suggests as well?
<didrocks> sil2100: ah sorry, not awaken
<didrocks> you're right, suggests
<didrocks> sil2100: +1 then :p
 * ogra_ has collected a nice collection of bathrobes over the years 
<didrocks> sorry
<didrocks> forget about me
 * seb128 hands didrocks some coffee
<didrocks> ogra_: yeah, mine is just white, uninteresting to you guys
<sil2100> Ah :)
<didrocks> ogra_: coming in 2 minutes
<sil2100> dbarth: no worries then ;p
<sil2100> didrocks: in the meantime, I see that the oxide MIR seems Fix Committed already, so it might be even approved!
<dbarth> didrocks: the mir is approved for oxide, yes
<dbarth> didrocks: but we decided not to push to main (ie seed/depend) just yet while we verify the silo content
<dbarth> Mirv: cjwatson advised to not make specific package changes and handle uploads "manually" afaict
<dbarth> i think this is to keep the packaging clean and help with maintaining other ports
<Mirv> dbarth: ok, I aborted the hung build job then. the packages are there for amd64/i386/armhf for testing, but I'm not sure if there's a better way to handle this in CI Train or will we just force the publishing after manual testing done.
<dbarth> Mirv: perfect, yes we've been already using / testing those
<dbarth> just so i know (cause i may need a few rebuilds in that silo before it's good to publish)
<dbarth> should i ping you guys to fliush the hung builds each time, or would that clear itself if i do a ppa rebuild
<dbarth> (i don't want to break the nice ci system)
<Mirv> dbarth: someone needs to abort the running/hung job at http://162.213.34.102/job/landing-009-1-build/ first before running a rebuild
<Mirv> otherwise ok
<dbarth> noted, i should have access to that, otherwise i'll come here
<sil2100> dbarth: soo...
<sil2100> dbarth: it seems we'll have to rebuild the packages in silo 11 ;/
<sil2100> Or wait
<dbarth> sil2100: what's wrong?
<dbarth> oh
<didrocks> dbarth: you requested conflicting silos
<dbarth> sil2100: the changelog needs fixing
<didrocks> dbarth: not only changelog, binary package itself
<didrocks> you need to rebuild
<sil2100> dbarth: yeah, so, an ignore-conflicts was requested, and in the meantime we released another version of it
<didrocks> that's why it's an expectional option
<dbarth> did i?
<sil2100> dbarth: so now the package needs to be rebuilt and retested, so that we have everythin that's in trunk
<didrocks> not something to integrate on the workflow
<dbarth> ah i see
<dbarth> ok, nw, i'll do that
<dbarth> eh, fine by me
<dbarth> can i keep the silo up to ~3pm CET though?
<didrocks> Webapps fixes (pre-Oxide landing) dbarth
<didrocks> dbarth: you won't be able to build/retest before?
<dbarth> that one was published already
<didrocks> yeah
<didrocks> that's the conflicting one which was requested
<dbarth> i can publish faster
<Mirv> cleanins silo 007 (seb128's) that got published
<dbarth> just that i may request a new one just after
<seb128> Mirv, thanks
<dbarth> it's fine, i'll -retest and clear the deck
<didrocks> dbarth: thanks
<didrocks> dbarth: so rebuild
<didrocks> it will pick latest trunk
<seb128> Mirv, it was not a minute ago, you have notifications of changes or what? ;-)
<sil2100> Mirv, didrocks: cleaning silo 2
<didrocks> sil2100: great!
<Mirv> and silo-0... oh thanks lukasz :)
<Mirv> seb128: you're just too slow :)
<Mirv> we just happened to discuss the low amount of silos once again on the call so I browsed through
<seb128> Mirv, lol
<Laney> Mirv: did you find someone to new review qtlocation?
<Laney> (just read ScottK's comment)
<Mirv> Laney: yes, didier
<didrocks> Laney: I did it
<Laney> R0X0R
<didrocks> complained a little bit about wrap-and-sort
<didrocks> but that's it :p
<ogra_> didrocks, hmm., what about the version of powerd do i keep yours and increment to -ubuntu2 or should i just turn it into 0.13+14.04.20140327-0ubuntu2 ?
<Laney> 'did' as some kind of pre-review?
<didrocks> ogra_: 0.13+14.04.20140327-0ubuntu1
<sil2100> Mirv: we're doing silo mining today :D
<didrocks> Laney: yeah, looked at debdiff and binaries
<Laney> neat
<ogra_> didrocks, -0ubuntu1 ?
<didrocks> hum
<sil2100> uh
<didrocks> sorry
<didrocks> -0ubuntu2
<ogra_> :)
<didrocks> yeah
<ogra_> k
<ogra_> thanks :)
<Mirv> sil2100: :)
<sil2100> didrocks: suddenly http://162.213.34.102 stopped working for me
<didrocks> I thought the version was from yesterday
<sil2100> Is that just me?
<didrocks> ogra_: hum
<didrocks> ogra_: that's < than my version, right?
<didrocks> one sec
<sil2100> I get 503
<didrocks> let me look
<didrocks> ogra_: yeah, it's lower
<Mirv> oh, I thought it was my network or something, but now it indeed gives an error
<didrocks> ogra_: so you can use .1
<didrocks> 0.13+14.04.20140327.1-0ubuntu1
<didrocks> ogra_: then, feel free to push your change + tag directly into thei trunk
<didrocks> their
<ogra_> bah
<dbarth> sil2100: same here; service down
<didrocks> Laney: thanks for the accept btw :)
<didrocks> sil2100: urgh
<Laney> you know i'm a sucker for reducing diffs over debian
<didrocks> sil2100: Mirv: dbarth: I just restarted jenkins
<didrocks> same OOM kill
<sil2100> didrocks: thanks! uuh
<didrocks> funny that I sent an email to ev about prodstack today
<sil2100> heh ;)
<didrocks> seb128: dbarth: if you had jobs running, you may need to relaunch them
<didrocks> sil2100: mind help on deciphering?
<didrocks> sil2100: those should be "building" on the spreadsheet
<didrocks> still
<didrocks> so watch only?
<didrocks> (if they were "preparing", reprepare it needed)
<seb128> didrocks, thanks
<didrocks> yw
<didrocks> ogra_: powerd on the way? :p
<ogra_> didrocks, https://code.launchpad.net/~ogra/powerd/fix-1298869/+merge/213225
<didrocks> ogra_: ah, using a silo then?
<didrocks> as you have a MP
<dbarth> ok, restarting
<ogra_> well, i want the version to be proper
<didrocks> ogra_: ok, pease add the line and let's get that in quickly
<ogra_> didrocks, you can just wave it through i suppose ?
<sil2100> Ok
<sil2100> Will decipher ;)
<didrocks> ogra_: yeah
<ogra_> line 50
<didrocks> ogra_: assigned and building: http://162.213.34.102/job/landing-002-1-build/102/console
<didrocks> failing as expected
 * didrocks uses "force rebuild" to tell to ignore the revert in archive
<ogra_> hrm, i thought it generates a new version
<didrocks> http://162.213.34.102/job/landing-002-1-build/103/console
<didrocks> ogra_: yeah, it's just telling "you have a version in archive that I don't in your changelog, you need to ensure it's fine"
<didrocks> see*
<ogra_> ah
<didrocks> 2014-03-28 10:15:02,152 WARNING A version (0.13+14.04.20140327.is.0.13+14.04.20140129-0ubuntu1) is available at the destination archive for that component but is not in the destination branch which is still at 0.13+14.04.20140327-0ubuntu1. You need to ensure that your version contains the fix in the destination or you can force rebuild to bypass the check.
<didrocks> read the logs! :)
<ogra_> aha
<sil2100> Mirv: freeing silo 19 ;p
<sil2100> seb128: ^
<seb128> sil2100, thanks
<sil2100> Saviq: can you re-run the build for your silo 004?
<sil2100> Saviq: the jenkins outage caused the job to disappear
<Saviq> sil2100, sure
<sil2100> Saviq: thanks!
<ev> didrocks: we're OOM on the ci train jenkins? Didn't we give that thing 2G+?
<didrocks> ev: we couldn't change the machine, so it's still 1G
<didrocks> ev: as we told it's ok as we are going to move to prodstack
<didrocks> which has the G+
<didrocks> I really think we should just move ASAP as told in this morning email
<Mirv> sil2100: thanks :)
<tvoss> didrocks, did jenkins die on us?
<didrocks> tvoss: yeah, that's why I asked sil2100 to relaunch everything for you
<didrocks> argh, seems he didn't rerun yours :/
<didrocks> tvoss: doing
<sil2100> didrocks: didn't reach his yeat ;)
<tvoss> didrocks, thanks
<Mirv> didrocks: hmm, what happened to your line42 gallery-app assignment?
<sil2100> Is google down?
<Mirv> works here
<didrocks> Mirv: nobody assigned it I guess
<Mirv> didrocks: 11:23 < didrocks> sil2100: hum, seems you are not around, I'm assigning line 42 as discussed above
<ev> didrocks: ah yes, now I remember
<sil2100> Mirv, didrocks: ok, I can assign it now then
<ev> and yes, I haven't had a chance to dig into your mail yet, but I agree - we should finish the prodstack work quickly
<didrocks> Mirv: yeah, but we went even more down in term of silos
<Mirv> right
<didrocks> seems ok to assign it now then
<Mirv> thanks sil2100
<didrocks> thanks
<didrocks> ev: great :)
<didrocks> tvoss: no time lost FYI, as I just rerun with "watch only" (as everything was prepared and it was building in the ppa)
<tvoss> didrocks, cool, thank you
<cjwatson> infinity: I knew it fixed one problem, I didn't know about anything else :-)
<sil2100> Aw come on, again jenkins died
<sil2100> didrocks: ^ ?
<cjwatson> dbarth,Mirv: I removed webbrowser-app/{arm64,powerpc,ppc64el}, so it should no longer be a blocker from the archive's point of view.  I don't know if the silo stuff is confused by it but I shouldn't have thought it ought to be ...
<didrocks> hum
<cjwatson> dbarth,Mirv: if a build job still hangs, let me know?
<sil2100> What the heck is happening with that machine ;/
<sil2100> cjwatson: ok, thanks!
 * didrocks doesn't get it
<didrocks> -/+ buffers/cache:        519        476
<ogra_> didrocks, binary from soli 2 tested ... works fine ... (marked in the silo too)
<dbarth> cjwatson: we're just rebuilding it now
<dbarth> sil2100: ^^
<didrocks> ogra_: great!
<seb128> jenkins down?
<didrocks> yeah
<dbarth> we'll let you know if that breaks
<seb128> :-(
<didrocks> ev: it's really urgent to migrate :/
<didrocks> restarted
<ev> didrocks: just finishing an email and then I'll cut straight over to this
<ev> I'll make the day's focus helping you get the remaining prodstack changes done
<didrocks> ev: thanks :)
<didrocks> ok,
<didrocks> let me see what needs to be rerun
<didrocks> and do that in order
<didrocks> quickly
<didrocks> recrash
<didrocks> ok
<didrocks> let me try to restart the host
<sil2100> o_O
 * didrocks crosses fingers
<ev> okay, here we go
<didrocks> ev: I shouldn't have sent that email
<ev> didrocks: when you say "(DONE: this morning)" do you mean you got webops to update the code?
<ev> oh?
<didrocks> I'm sure canonistack got upset
<ev> lol!
<ev> poor thing
<didrocks> ev: the DONE was "DONE by me, directly"
<ev> does the prodstack deployment auto-update its code?
<didrocks> ev: yeah, it will as well
<didrocks> so, it's back
<didrocks> let's see
<didrocks> seb128: thanks
<ev> didrocks: erm, where? Grepping for update or pull doesn't turn up anything relevant.
<seb128> didrocks, for? retrying the silo 1? ;-)
<didrocks> seb128: yep
<ev> we should cut over to the canonical-is-charms version of the jenkins charm
<seb128> didrocks, yw! let's see if we managed to get through this time
<didrocks> ev: let me put things in shape before
<ev> sure thing
<sil2100> Should I rebuild anything?
<sil2100> Or wait for now?
<ev> ah, found it
<didrocks> ogra_: powerd done
<didrocks> sil2100: well, I did it, we needed to act quickly
<didrocks> ok, all done and published
<sil2100> No OOM?
<didrocks> sil2100: I rebooted the machineâ¦
<ev> didrocks: what do you want for the rsync frequency of those dirs?
<didrocks> and reconcialiate everything
<ogra_> yay
<didrocks> ev: hum, you didn't want to expose them directly?
<ev> oh right, I see now
<ev> yeah
<ev> and that data is safe for public viewing?
<didrocks> ev: the rsync is only for the out/ dir
<didrocks> ev: yep
<sil2100> hm, someone tried publishing 001? Since it's not tested yet
<didrocks> ev: so $AS_JENKINS $JENKINS_HOME/citrain/citrain/manual/setup-citrain --allsilos --prepare --deploydeploy --deploypreprod deploys latest code
<didrocks> ev: but actually, they just need to redo JENKINS_HOME/citrain/citrain/manual/setup-citrain --deploydeploy as per email
<didrocks> and I'm dealing with the rest
<didrocks> ev: hum, actually with the preprod/prod, I need to change the script
<didrocks> ev: will they rerun this job?
<ev> didrocks: just filed https://rt.admin.canonical.com/Ticket/Display.html?id=68826
<didrocks> [ -e $JENKINS_HOME/citrain ] || $AS_JENKINS bzr branch lp:cupstream2distro $JENKINS_HOME/citrain
<ev> you should have it in your inbox, so if there are additional instructions for webops, do add them there
<didrocks> ok
<didrocks> let me change the charm
<ev> should that actually be --deploydeploy? I assumed it a typo and wrote it as --deploy in the instructions
<didrocks> ev: no, we deploy the deploy job
<ev> working on the apache charm now
<didrocks> (the job use for future code update)
<ev> ah okay, please follow up on that email then
<ev> and when you do I'll take it over to #webops for score bumping
<didrocks> ok
<ev> upgrade-charm will call the install hook, for what it's worth
<ev> so that will handle installing python-requests
<didrocks> yeah
<didrocks> so it's fine if we use that
<didrocks> let me fix the charm to have the preprod thing
 * ev nods
<ogra_> didrocks, something in the changelog generation tried to be clever and appended a bug reference to my line with the bug reference :P
<ogra_> (it should probably check if there is an entry for this bug already before blindly appending it a second time)
<didrocks> ogra_: patches welcomed, should be easy enough :p
<didrocks> (but you need to take into account the fact that it can split in 2 lines and so on)
<didrocks> ev: ok, changes in the charm done and pushed
<didrocks> let me followup on your email
<seb128> sil2100, Mirv: can I get a silo for l36 next time you have one (pinging because I'm unsure if it's skipped over because it's further up in the table and people don't go to look there)
<sil2100> seb128: it's skipped because of lacking description ;p
<sil2100> seb128: see comment ;)
<seb128> sil2100, there should be a color in the comments entry when it's blocked on feedback :p
<seb128> sil2100, done
<sil2100> seb128: well, it seems the person commenting forgot about the color ;p Sorry ;p
<seb128> no worry!
<sil2100> seb128: let me add you a silo once we have one more free
<seb128> thanks
<sil2100> Mirv: merge and cleaning silo 16!
<Mirv> thanks again :)
<sil2100> yw :)
<didrocks> dbarth_: landing silo 11
<Mirv> I was polling on that one too since it was acceptes
<sil2100> I'm scanning the spreadsheet very frequently because of our free-silo deficiency
<dbarth_> didrocks: ah ok, thanks
<sil2100> seb128: assigning a silo for you, since one silo will be free now in some moments
<sil2100> didrocks: the 11 publish job failed somehow?
<didrocks> sil2100: yeah, I double click :/
<didrocks> sil2100: but the migration job fixed the status
<didrocks> sil2100: you can assign seb128's one, as the other is getting freed
<didrocks> sil2100: then, I think we have 0 requests ready pending on us
<sil2100> \o/
<didrocks> sil2100: I added a comment for the powerd one
<sil2100> didrocks: there's one url-dispatcher landing that we didn't assign, but as thostr doesn't seem around it seems pointless to assign
<didrocks> yeah
<Saviq> didrocks, 013 can be published please
<sil2100> Saviq: o/
<sil2100> didrocks: handling that
<didrocks> thanks :)
<didrocks> Saviq: on the unity8 crashers, davmor2 has another reproducer btw
<didrocks> he will file you with a bug for it
<Saviq> didrocks, yeah, we found a way, too (for the "browsing dash" one), Albert is on it
<didrocks> Saviq: do you have a bug for it?
<sil2100> didrocks: packaging ACK - copyright fixes: http://162.213.34.102/job/landing-013-2-publish/19/artifact/packaging_changes_unity-scope-texdoc_0.1+14.04.20140328-0ubuntu1.diff
<davmor2> From a bootstrap of of the latest image I add the music video and images  flick between scopes and hit the following:
<davmor2> _usr_bin_mediascanner-service-2.0.32011.crash
<davmor2> _usr_bin_mediascanner-service.32011.crash
<davmor2> _usr_bin_unity8.32011.crash
<davmor2> _usr_lib_arm-linux-gnueabihf_upstart-app-launch_desktop-hook.32011.crash
<didrocks> sil2100: +1, seems to match the content :)
<didrocks> mhr3: hey, maybe you sohuld be involved as well ^
<didrocks> (seeing mediascanner thingy)
<davmor2> didrocks, Saviq, mhr3: I'll report all 3
<didrocks> all 4 rather, no?
<davmor2> the last one I think is the notes bug that has been around on fresh installs for a while but I'll check on that
<didrocks> ok
<davmor2> didrocks: root@ubuntu-phablet:/var/crash# cat _usr_lib_arm-linux-gnueabihf_upstart-app-launch_desktop-hook.32011.crash | grep notes
<davmor2> AppID: com.ubuntu.notes_notes_1.4.253
<davmor2> DuplicateSignature: icon-path-unhandled-com.ubuntu.notes_notes_1.4.253
<davmor2> IconPath: /usr/share/click/preinstalled/.click/users/@all/com.ubuntu.notes/notepad
<didrocks> k
<davmor2> So I'll ignore that one :)
<ev> didrocks: gnuoy is looking at the RT now
<didrocks> but maybe upstart-app-launch should be more resilient to the crash
<didrocks> ev: ok, FYI, the last step once we transition will be to rsync 2 folders between canonistack and prodstack
<didrocks> ~jenkins/silos/ and ~jenkins/status
<didrocks> we stop jenkins on canonistack
<didrocks> rsync those
<didrocks> and start prodstack
<didrocks> hum, the url of things running won't match any reality though
<didrocks> we'll need to discuss :p
<davmor2> didrocks: by the way the system still writeable
<didrocks> davmor2: well, I didn't get any time to change itâ¦
<didrocks> davmor2: so yeahâ¦
<didrocks> and I don't envision having time soon
<mhr3> davmor2, pls ping satoris about the mediascanner crash
<davmor2> mhr3: will do once the report is done
<mhr3> ty
<ev> didrocks: *nods* gory details in #webops
<ev> we're working through how to expose /var/lib/jenkins/silos*
<Saviq> davmor2, let's see how our kill timeout coped! :)
<didrocks> ev: excellent!
<ev> didrocks: can you join #webops?
<didrocks> ev: I did 2s before you joined :p
<didrocks> asked*
<didrocks> ogra_: powerd in, building an image
<ogra_> one sec
<seb128> sil2100, lol (I was typing and got sidetracked, should have waited for the ready = yes :p)
<ogra_> let me get the bot back
<didrocks> get the bot back NOW! :)
<sil2100> ;)
<ogra_> |HELP
<imgbot> I am the firendly image watchbot
<ogra_> didrocks, go for it
<didrocks> ogra_: I already kicked it when I wrote "building an image"
<ogra_> (damned, i thought it was properly detection connection now ... )
<didrocks> it was really "building"
<ogra_> shit
<didrocks> not about to build :p
<ogra_> right
<didrocks> or I'm going to biuld
<sil2100> booo!
<didrocks> orâ¦ well, you got it :p
<ogra_> ah, the cron jobs had not kicked in yet
<ogra_> it should be fine
<imgbot> === trainguard: IMAGE 266 building (started: 20140328-11:55) ===
<ogra_> there it is
 * sil2100 already said it that's he knows it's jus ogra_ manually inputting this to imgbot - using voice recognition of course
<ogra_> heh
<sil2100> didrocks, didrocks: m&c'ing silo 11
<Mirv> merge and cleaning 011
<didrocks> m&c race!
<sil2100> !
<sil2100> :D
<sil2100> Who was first?!
<Mirv> sil2100: damn you, you take all the fun :D
<Mirv> sil2100: you, because my login had timed out
<sil2100> Mirv: ;)
<ogra_> hmm
<ogra_> ogra@anubis:~$ ps ax|grep compiz
<ogra_> 31691 ?        Sl   10564:13 compiz --replace
<ogra_> interesting times :P
<sil2100> Yessss I wooon! I wonder what I won though, what's the prize?
<Mirv> sil2100: 008!
<sil2100> ! Darn!
<Mirv> :D
<sil2100> Ok, today really feels like friday ;p
<Mirv> hehe
<sil2100> ubot5 just told me he doesn't know anything about Darn!
<ubot5> sil2100: I am only a bot, please don't think I'm intelligent :)
<sil2100> ubot5: then stop talking to me!
<ubot5> sil2100: I am only a bot, please don't think I'm intelligent :)
<sil2100> Mirv: in the meantime, I'll assign the last silo to seb128, as we will have 2 free in a moment
<seb128> sil2100, thanks!
<seb128> hum, interesting
<seb128> 4 ppc builds, 1 building libreoffice, 1 openjdk, 1 linux
<Mirv> yeah, seb handles his silos swiftly on average and doesn't leave them hanging around for a week :)
<seb128> so we are virtually down to 1 and having some hours backlog :/
<didrocks> seb128 has 4 silos for him, 20% of our silos!
<seb128> Mirv, ;-)
<seb128> didrocks, I'm doing that to be nice to Saviq, so he doesn't feel like he's the only one stealing all the available silos :p
<didrocks> seb128: ah, compassion, got it!
<seb128> ;-)
<Saviq> WHO ME?
<seb128> YES, YOU!
<didrocks> Saviq: 15% of our silos! how dare you! :)
* josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<Saviq> didrocks, that's only because I took over from thostr!
<didrocks> (well, more than 15% of our landings anyway ;))
<Saviq> didrocks, and when you say 15% that's manipulating - it's 3!
<didrocks> Saviq: that's stats! :)
<sil2100> ;p
<didrocks> stats are manipulation in essence
<Saviq> ;)
 * seb128 just notice that didrocks has no silo and wonder if the guy is doing any work
<seb128> no silo = slacking, right?
<didrocks> seb128: exactly, we should fire him!
<seb128> ;-)
 * seb128 hugs didrocks
 * didrocks hugs seb128 back
 * sil2100 hides as well
<Saviq> also, I'd have cleared one of them already if it wasn't stuck in proposed :P
<Saviq> there's too much hugging in this channel
<ogra_> especially for a friday !
<didrocks> yeah, let's stop being nice!
<didrocks> :)
<davmor2> sorry for the delay mother in law meds were  due I hadn't realised it was that late.
<didrocks> noooooooooooooooooo, but what is happening today?
<didrocks> jenkins down AGAIN
<ogra_> friday ...
<t1mp> jenkins started his weekend early
<jdstrand> Mirv: thanks-- I did that the first time, and it said it failed
<davmor2> mhr3: satoris what channel/time am I likely to get him on?
<seb128> didrocks, do you know what happened with https://code.launchpad.net/~attente/unity-gtk-module/no-handlers/+merge/211857 ? it ended up under CI bot in https://launchpadlibrarian.net/171027868/unity-gtk-module_0.0.0%2B14.04.20140328-0ubuntu1_i386.changes
<didrocks> Mar 28 12:03:10 juju-openstack-machine-2 kernel: [ 4954.407410] Out of memory: Kill process 934 (java) score 221 or sacrifice child
<sil2100> jdstrand: I think it wasn't migrated to the archive fully yet back then
<sil2100> Aw come ooon
<didrocks> jdstrand: the failed told you what exactly?
<sil2100> didrocks: it seems we never overused jenkins as much as today, as things are being marked as 'ready to land' really frequently
 * didrocks reboots
<didrocks> sil2100: yeah, but still, it's not like the load after 4 weeksâ¦
<sil2100> That's true ;|
<didrocks> ok back
<didrocks> let's watch ppa for what was building
<jdstrand> didrocks: http://162.213.34.102/job/landing-008-2-publish/46/console
<didrocks> sil2100: I start at the end of the list, you start from top?
<didrocks> jdstrand: did you run the build job with "watch ppa"?
<jdstrand> didrocks: I copied apparmor from security-proposed ppa to silo 008
<jdstrand> didrocks: I did
<didrocks> jdstrand: do you remember the run #?
<jdstrand> I'm not sure what this is. Build history says '46' was the issue
<didrocks> sil2100: landing-002 done
<didrocks> sil2100: landing-010 done
<jdstrand> didrocks: oh sorry, you meant for the build where I used WATCH_ONLY
<jdstrand> ?
<didrocks> sil2100: landing-001 done
<didrocks> jdstrand: yes
<Mirv> jdstrand: didrocks: it seemed to indeed work after I ran it with WATCH_ONLY
<didrocks> sil2100: landing-019 done
<didrocks> sil2100: landing-017 done
<sil2100> Oh oh
<didrocks> sil2100: landing-019 done
<sil2100> This always happens when I don't look at the irc window
<sil2100> Aaaa staph!
<sil2100> Not so faaast!
<didrocks> and end of the list
<seb128> didrocks, what, what?
<didrocks> sil2100: well, we have to be fast
<jdstrand> didrocks: http://162.213.34.102/job/landing-008-1-build/66/console?
<didrocks> seb128: new jenkins outage
<seb128> didrocks, oh, your restarted the jobs?
<seb128> shrug
<didrocks> seb128: I had to restart everything :/
<didrocks> well
<sil2100> ;/
<seb128> those were done out of ppc
<didrocks> we don't loose time, it's building in the ppa
<seb128> right
<didrocks> so only watch ppa
<seb128> we are blocked on ppc anyway
<seb128> it has some hours backlog
<didrocks> sil2100: please, you saw there was an outageâ¦
<didrocks> sil2100: so don't go aware from IRC, we need to work all together
<didrocks> seems I have to restart all of them alone, that's really really not niceâ¦
<didrocks> jdstrand: it seems you did it before the package was published in the ppa?
<didrocks> jdstrand: as it didn't show the source
<didrocks> jdstrand: like in the next run: http://162.213.34.102/job/landing-008-1-build/67/console
<jdstrand> didrocks: ah, I'll add that to my notes
<didrocks> jdstrand: yeah, basically, as people can iterate, we don't block on that until the publication
<didrocks> jdstrand: as for instance, they want to upload Mir, build it, and then push xorg, and only build xorg
<didrocks> so only during the publication we say "oh oh oh, we never monitor that package that you declared as part of your landing"
<didrocks> monitored*
<jdstrand> ok
<jdstrand> thanks for looking at it
<Mirv> what does the restarting after a crash involve? just aborting a job + rerunning with watch_only for those silos that were Building?
<didrocks> jdstrand: yw, it's always more puzzling with direct upload compared to using branch :)
<didrocks> Mirv: no abort, just running with watch only for the silos that were building
<didrocks> Mirv: or rerunning build if they were preparing (ideally only what wasn't send to the ppa)
<Mirv> ok, thanks. useful in case these become frequent.
<didrocks> Mirv: sil2100: so, something to know, the job links are only refreshed if the status change
<didrocks> it's to minimize spreadsheet writing
<sil2100> didrocks: in the spreadsheet?
<didrocks> yep
<didrocks> so if you go to silo 002
<didrocks> click on building
<didrocks> you see that there is no job
<didrocks> as it's still the old link
<didrocks> now that we restarted everything, the easiest for you is just to delete the status
<didrocks> (in the silo)
<didrocks> next sync will set the right one
<sil2100> didrocks: in the silo sheet?
<sil2100> Ok, I'll do that then
<sil2100> 13 migrated, m&c'ing!
<sil2100> Mirv: ^
<cjwatson> seb128: most of that was a mass give-back, ci-train should be ahead of it ...
<didrocks> sil2100: done for all
<sil2100> didrocks: I remember last time hm, it somehow suddenly refreshed itself?
<cjwatson> hmm.  openjdk-7, libreoffice, linux, scilab.
<cjwatson> that's a tedious set
<didrocks> sil2100: yeah, if new status message is != old status message
<didrocks> without counting the url
<cjwatson> I think linux is fairly close to done
<didrocks> -/+ buffers/cache:        745        249
<didrocks> we are quite short, indeed
<cjwatson> oh, maybe not, looking at the wrong bit of log :-/
<sil2100> Wonder why it's suddenly so bad
<didrocks> sil2100: unsureâ¦
<cjwatson> infinity: we could really use those new powerpc VMs :-/
<dbarth_> o/ line 53 for some polish on the OA settings; when a silo is available
<didrocks> -/+ buffers/cache:        756        239
<didrocks> now
<sil2100> didrocks: looking at it right now
<sil2100> I mean
<sil2100> dbarth_: ^
<sil2100> dbarth_: since I'm looking at the bugs
<didrocks> without any new processâ¦
<sil2100> dbarth_: since this bug: https://bugs.launchpad.net/ubuntu-system-settings-online-accounts/+bug/1289443 <- it modifies the UI, not sure if we won't need an UIF?
<ubot5> Ubuntu bug 1289443 in Online Accounts setup for Ubuntu Touch ""Cancel" button moves once authorization page loads" [Medium,In progress]
<sil2100> I mean, wait, not this one
<sil2100> Wrong bug
<sil2100> I meant this https://bugs.launchpad.net/ubuntu-system-settings-online-accounts/+bug/1289406
<ubot5> Ubuntu bug 1289406 in Online Accounts setup for Ubuntu Touch ""Accounts" header says "Online Accounts"" [Medium,In progress]
<sil2100> ...
<sil2100> *UIFe
<sil2100> Let me comment on the landing, give us a sign once it's 'cleared'
<dbarth_> sil2100: that's minor layout changes, and the string change is for a string that was already in the translation catalog
<sil2100> dbarth_: ah, ok
<sil2100> dbarth_: assigned
<sil2100> Ok, I drive to eat something, will have my PC with me, so will be available during lunch
<Saviq> sil2100, reconfigure silo 15 please
<ogra_> crap !
<ogra_> why does it think it lost connection :(
<didrocks> -/+ buffers/cache:        842        152
<didrocks> and down again
<didrocks> grrrrr
<didrocks> out of memory
<ogra_> no, that was me now
<didrocks> no no
<didrocks> jenkins is down again
<ogra_> ah
<ogra_> heh
<didrocks> sil2100 left for lunch, Mirv around?
<didrocks> ev: help
 * ogra_ renames this day from friday to downday
<didrocks> ev: is there any way even to add swap to the machine?
<ev> didrocks: the machine in canonistack?
<didrocks> ev: yep
<didrocks> 4th failure
<didrocks> we file the Gb of mem
<ev> didrocks: juju ssh ci-train-jenkins/0; dd if=/dev/zero of=/var/swap bs=1M count=$((1024 * 1024)); chmod 0600 /var/swap; swapon /var/swap
<ev> or something to that effect
<Saviq> ev, 1024 * 1024 megabytes?
<Saviq> or am I reading that wrong
<Mirv> didrocks: uh
<Mirv> going through
<Saviq> Mirv, didrocks, stuff's down, can we reconfigure silos?
<didrocks> Saviq: wait please
<Saviq> didrocks, ok
<didrocks> Saviq: yeah, ev was wrong, fixed it
<didrocks> however, i can't swapon
<cjwatson> you'd need to mkswap
<didrocks> yeah
<didrocks> ok done
<didrocks> Swap:         1023          0       1023
<didrocks> that should short-bandaid it
<didrocks> Saviq: do you need to reconfigure?
<didrocks> Saviq: or it's because of the outage?
<didrocks> (you don't need to)
<didrocks> thanks cjwatson, ev
<bfiller> dbarth_: I've repushed the MR for silo 9 after merging with latest osomon with-oxide trunk
<didrocks> imgbot: where are you with it?
<didrocks> hum
<didrocks> Mirv: where are you with it? (so that I can continue on the other end of the list)
<bfiller> didrocks: need to stop the build on silo9 because we need to rebuild it
<Mirv> didrocks: at the end now, but probably worth going over again
<didrocks> Mirv: ok
<didrocks> bfiller: ok, feel free :)
<bfiller> didrocks: how?
<Mirv> I'm now just rechecking the build jobs
<bfiller> didrocks: getting error when going to the biuld page
<didrocks> bfiller: http://162.213.34.102/job/landing-009-1-build/
<didrocks> bfiller: we just had a jenkins outage
<didrocks> hence the dead links
<didrocks> Mirv: ok, all sounds good
<didrocks> Mirv: even the reprepare :)
<didrocks> Mirv: did you remove the status field to update the links?
<didrocks> or should I?
<Mirv> didrocks: please do
<didrocks> ok
<Mirv> didrocks: there was more thing  landing-008 cleaning aborted?
<didrocks> (done)
<didrocks> ah
<didrocks> let me check
<bfiller> didrocks: sorry, I don't see any option to stop the build. Can you give me a pointer on that please?
<didrocks> Mirv: landed "cleaning silo", so you can use "only free silo" I guess
<didrocks> bfiller: on http://162.213.34.102/job/landing-009-1-build/
<didrocks> do you have a red cross next to the progress bar?
<didrocks> (can be a permission issue that I need to fix)
<didrocks> but you gave the rights to cancel builds normally
<Mirv> didrocks: ok, thanks, I'll do that since it seems to be cleaned indeed
<bfiller> didrocks: I do now thanks, had to login first
<didrocks> bfiller: oh sure, yeah, you have to login :)
<didrocks> bfiller: I hope that once we move to prodstack, we won't timeout as much on the sso loging
<didrocks> login*
<didrocks> Mirv: perfect, all should be sorted now
<seb128> cjwatson, right, as I said earlier, would be fine if we didn't get a combo linux/libreoffice/openjdk
<dbarth_> Mirv: we have so dep-wait builds stuck for webbrowser-app in silo 009, can you remove them?
<dbarth_> i'm about to start a new build
<ev> sorry about the mistakes in those swap commands :)
<dbarth_> bfiller: ^^ just waiting for some cleanup
<cjwatson> dbarth_: dep-waits clear automatically twice an hour FWIW
 * Saviq moves the tabs in CI Train ssheet all the time... \o/ for ux...
<didrocks> ev: no worry, thanks for the first step (I was thinking about attaching a swap partition) and thanks cjwatson
<didrocks> at least, it should help for a band-and solution
<cjwatson> dbarth_: and if you're going to start an entirely new upload anyway then they don't matter
<dbarth_> ah ok, thanks
<dbarth_> then i'll fire up the build now
<didrocks> Mirv: yeah, confirming the status is the right one
<Mirv> dbarth_: your build seems to have started correctly, let's see how it goes this time
<Mirv> didrocks: great
<dbarth_> Mirv: yup
<plars> ogra_, didrocks: looks like the rootfs has already built with the powerd fix so we should see a new image soon?
<ogra_> plars, yeah, soon
<imgbot> === trainguard: IMAGE 266 DONE (finished: 20140328-13:20) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/266.changes ===
<plars> oh
<plars> like now :)
<ogra_> :)
<didrocks> I'm sure ogra_ cheats :)
 * sil2100 on lunch at his girlfriends grandparents
<sil2100> Free food!
<didrocks> sil2100: you missed another outage :p
<didrocks> lucky you :)
<Saviq> icanhas silo 015 reconfigure please? :)
<sil2100> uuuuu ;p
<didrocks> Saviq: new component?
<Saviq> didrocks, yes, lxc
<Saviq> -android-config
<Saviq> source only
 * didrocks pushes
<Saviq> thank you
 * ogra_ just got the rejected mail :P
<ogra_> can i try again ?
<Saviq> ogra_, yeah
<Saviq> ogra_, but bump version
<ogra_> bah
<Saviq> PPAs are really adamant about same-version files
 * ogra_ starts ovber then
<Saviq> didrocks, ah, and ubuntu-touch-session is a new component there, too, for dropping surfaceflinger support
<didrocks> Saviq: reconfigured!
<Saviq> didrocks, thanks
<didrocks> yw
<ogra_> 0.153 uploaded
<plars> vila: I'm here
<Saviq> didrocks, uh oh http://162.213.34.102/job/landing-015-1-build/40/console ?
<boiko> didrocks: Mirv: sil2100: hey guys, just a heads up that row 41 on the spreadsheet is ready for silo assignment
<didrocks> Saviq: can you check with Mirv/sil2100?
<Saviq> didrocks, will do, sorry
 * Saviq used to pinging didrocks :)
<Saviq> there should really be a @landing-team
 * Mirv in hangout, sorry
<Mirv> boiko: assigning
<ogra_> and sil2100 eats his in-laws
<ogra_> err
<ogra_> *with his in-laws :P
<Mirv> boiko: ERROR:root:https://code.launchpad.net/~tiagosh/telephony-service/fix-indicator-voicemail doesn't seem to be a valid merge proposal url
<Mirv> obvious fix, please just ping when ready, I try to multi-task listening to the hangout and doing very simple tasks :)
<boiko> Mirv: oups, let me fix this, sorry, I got the branch instead of the MP URL
<Mirv> and Saviq's question unfortunately looks far from simple
<Saviq> there's more :|
<boiko> Mirv: fixed
<Saviq> http://162.213.34.102/job/landing-015-0-reconfigure/18/console :/
<sil2100> ;p
<Saviq> sil2100, Mirv, whenever you can â I can't reconfigure
<jhodapp> Can someone do a rebuild of qtubuntu-media in silo 006?
<sil2100> Saviq: ok
<sil2100> Saviq: doing!
<Saviq> sil2100, I mean that there's a failure when reconfiguring
<Saviq> sil2100, not that I can't because of new comp
<Mirv> sil2100: also related the earlier http://162.213.34.102/job/landing-015-1-build/40/console
<sil2100> Ok, hmmm
<Saviq> Mirv, I'm not sure it is indeed related, but yeah, both are my current issues with silo 015 :|
<sil2100> Looks strange
<jhodapp> sergiusens, you're able to kick off a new silo build, right?
<sergiusens> jhodapp, yes
<jhodapp> sergiusens, can you rebuilt qtubuntu-media in silo 006 please?
<jhodapp> *rebuild
<sergiusens> sue
<sergiusens> sure
<sil2100> Saviq: let me try and debug, but it might be something more tricky requiring jenkins access
<jhodapp> thanks
<Saviq> sil2100, thanks
<sergiusens> jhodapp, was the MR updated or is it a plain retrigger?
<jhodapp> sergiusens, MR updated
<sergiusens> great
<sil2100> Saviq: sooo... it might be a bad sign that in a moment everything in CITrain will be broken
<Saviq> sil2100, yeah, the message was rather scary
<Saviq> sil2100, IIUC it could not create a tmp file...
<Saviq> BAD
<sil2100>  java.io.IOException: No space left on device
<sergiusens> sil2100, what does this mean java.io.IOException: Failed to create a temp file on /var/lib/jenkins/jobs/landing-006-1-build/workspace ?
<sil2100> This makes me worry ;/
<sergiusens> oh
<sil2100> sergiusens: ouch, so it happened!
<sergiusens> jhodapp, guess I can't now..
 * ogra_ has some spare space in his basement ... want it ? 
<sil2100> And I think only didrocks has access to the machine, and he had some emergency
<sil2100> ogra_: please ;p!
<jhodapp> sergiusens, lack permissions?
<ogra_> sil2100, friday :)
<Mirv> sil2100: I'm on the server
<sil2100> Mirv: oh, you have the creds?
<Mirv> sil2100: just tell me what to rm -rf :)
<sil2100> I don't know, never been on that server ;) hmmm
<sil2100> Look for something big
<sergiusens> jhodapp, no space on servers
<jhodapp> oh gosh
<sil2100> Mirv: how much disk space is there? Maybe look through the jenkins dir and see if there are any leftover source directories that you could remove, i.e. such that won't be used
<sil2100> Like, some old versions of existing landings
<sil2100> The jenkins outages might have caused some leftovers laying around
<Mirv> sil2100: ok a bit freed, ubuntu-themes that was already released
<Mirv> oh, but / is different
<sil2100> Mirv: yeah, excellent, thanks - how much do we have left now?
<sil2100> We need to have free space here: /var/lib/jenkins/jobs/landing-015-0-reconfigure/workspace
<jhodapp> sergiusens, try it now?
<sil2100> So, i.e. /var/lib/jenkins
<Mirv> cd /var/lib/jenkins/jobs/landing-015-0-reconfigure/workspace
<Mirv> ls -l
<Mirv> :)
<Mirv> sil2100: ok there should be space there, right
<Mirv> sil2100: I think / being full is a problem too
<Saviq> ENOSPC :|
<ogra_> Mirv, so rm -rf / then ?
<sil2100> hmmm
<Mirv> df /var/lib/jenkins/jobs/landing-015-0-reconfigure/workspace
<Saviq> the issue was Failed to create a temp file on /var/lib/jenkins/jobs/landing-015-0-reconfigure/workspace
<sil2100> Again...
<Saviq> is that btrfs? ;D
<sil2100> Mirv: so, maybe / is in need of freeing as well
<Mirv> /dev/vdc1       82569580 10788052  67587244  14% /srv/juju/vol-0000011d
<Mirv> yeah working on it
<sil2100> Mirv: thanks, phew, good that you have access to that machine
 * sergiusens has the same issue Saviq has but on silo 6
<sil2100> Would be nice if I had access as well!
 * sil2100 needs to poke didrocks 
<sil2100> ALthough since we will switch soon, it's not that urgent
<Saviq> shall I try again?
<Mirv> sil2100: ok now
<Mirv> Saviq: yes
<sil2100> Saviq: yes
<Saviq> \o/
 * Mirv removed some useless app translations like French, + apt-get clean
 * Saviq wonders how bad ogra got âââ
<Saviq> "Verlassend" sounds like an unpleasant thing to have
<ogra_> my palm touched the touchpad while typing ...
<Saviq> SUCCESS
<ogra_> not siure why it thought i want to leave the channel :P
<sil2100> sergiusens: ^
<Mirv> Saviq: \o/
<sil2100> jdstrand: ^
<ogra_> yeah, thats a silly default message someone thought would be clever to translate literally
<seb128> Mirv, you removed french translations?!
<Saviq> rotfl
<Saviq> what will didrocks do!
<Mirv> :D
<Mirv> now he gets language of the savages on the server
<Saviq> Mirv, sil2100, any idea about the touch session failure http://162.213.34.102/job/landing-015-1-build/40/console ?
<sil2100> Saviq: looking
<sil2100> Saviq: this was the previous run? Or is it the one now?
<Saviq> sil2100, previous
<sergiusens> jhodapp, building now
<jhodapp> thanks
<Saviq> sil2100, I only kicked unity8 now
 * sergiusens will brb
<Saviq> sil2100, but that didn't look like a transient error
<jdstrand> sil2100: ?
<Saviq> sil2100, more like some packaging thing
<sil2100> Saviq: probably out of disk space caused it...
<Saviq> sil2100, could, ok will try
<Saviq> sil2100, ignore for now, then
<Mirv> sil2100: so our problem might be that / is used for pbuilder cache
<Mirv> argh, full again
<sil2100> Saviq: will keep an eye on this, but since we had basically 0 disk space, I would say everything could be broken and the same for pbuilder
<sil2100> Mirv: crap...
<Mirv> you're too quick!
<Saviq> sil2100, yup
<Saviq> uh oh
<sil2100> We need moar free space!
<Saviq> yeah, FAIL
<Mirv> sil2100: so / is 10GB and 90% of it is in /var/cache/pbuilder
<seb128> you probably have staled over build dirs from the reboots
<seb128> you can maybe have a look at cleaning those?
<sil2100> Mirv: check what seb128 is saying
<sil2100> seb128: thank for the pointer!
<sil2100> *thanks
<seb128> yw
<Mirv> I just wonder about potential pitfalls in removing the cow directories
<Mirv> but there's stuff from January etc
<seb128> I doubt there is any
<seb128> old timestamped one are probably fine to rm
<seb128> that's a cache
<seb128> well, that's from experience of using pbuilder locally, I don't use cow though
<sil2100> Caches are meant to be cleaned!
<t1mp> Mirv: on the landing proposal sheet, l.31 (zoltan's request) can you remove the tab_selection_timing MR from the list?
<seb128> but those are probably temp unpacked that didn't get cleaned because the logout didn't happen normally
<sil2100> t1mp: I can do it, Mirv is busy firefighting ;)
<t1mp> sil2100: okay, thanks
<t1mp> zsombi: ^ fyi. Let's hope that is the MR that caused the failures
<Mirv> maybe just pbuilder --clean
<zsombi> t1mp: fingers crossed!
<t1mp> sil2100: will that update sheet 18, and the silo and create new packages in the PPA?
<seb128> Mirv, well, be careful you don't wipe out dirs that are being used
<seb128> Mirv, starting by cleaning the ones with old timestamps should be safe
<sil2100> t1mp: the silo needs to be reconfigured and rebuilt, but that's basically just 2 buttons - which have to wait a bit since our jenkins right now is not usable
<sil2100> So it should be done in some minutes
<t1mp> sil2100: will you click those buttons for us? I don't have rights on the document
<sil2100> t1mp: sure
<t1mp> thanks
<t1mp> sil2100: how will I know when the new packages are in the PPA for testing?
 * Mirv ran apt-get -o Dir::Cache::archives=/var/cache/pbuilder/trusty-amd64/aptcache autoclean
<sil2100> t1mp: the status of the landing-018 will say Packages built - it says so right now, but after rebuilding it will once again say that it's building
<Mirv> sil2100: ok, plenty of space now, we just need to check whether everything still works
<sil2100> Mirv: thanks!
<sil2100> Saviq: can you retry again?
<sil2100> You would be our tester
<Saviq> sil2100, http://162.213.34.102/job/landing-015-1-build/44/console
<Saviq> going
 * sil2100 has his fingers crossed
<sergiusens> cannot copy extracted data for './usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_eh.a' to '/usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_eh.a.dpkg-new': failed to write (No space left on device)
<sergiusens> should  just wait for Saviq?
<sil2100> sergiusens: from when is that? Did you start it now?
<sergiusens> sil2100: 5 minutes ago or so
<sergiusens> before I rebooted
<sergiusens> http://162.213.34.102/job/landing-006-1-build/115/console
<sil2100> sergiusens: ok, so, we had another issue
<sil2100> sergiusens: you can re-try again I guess, it should be fine now
<sil2100> Sorry for that, we didn't expect this to happen
<dbarth_> sil2100: silo 011, it is /phone only/  in fact, i was confused
 * sergiusens retries
<sil2100> dbarth_: ah ;) Ok, then no worries!
<seb128> sil2100, Saviq, Mirv: that url from Saviq hit a cowbuilder cmd error
<dbarth_> sil2100: tested and verified to work, can land (and so no UIF requiredfor the phone case)
<sil2100> Saviq: did it just fail?
<sil2100> seb128: yea...
<Saviq> sil2100, yes, it's the same ubuntu-touch-session fail
<dbarth_> sil2100: but keep silo 011 handy, cause i have another one to land for alex-abreu again ;) please
<Saviq> sil2100, so not ENOSPC related
 * Saviq kicks one with just unity8
<alex-abreu> dbarth_, do we put the download api in it ?
<Saviq> http://162.213.34.102/job/landing-015-1-build/45/console
<sil2100> Saviq: it doesn't seem the same failure though
<alex-abreu> mandel, ping
<Saviq> sil2100, same " Use of uninitialized value $ans in pattern match (m//) at /usr/bin/debuild line 1005."
<rsalveti> morning
<Saviq> sil2100, as here http://162.213.34.102/job/landing-015-1-build/40/console
<Saviq> rsalveti, elo
<sil2100> Saviq: ah, right, it's more up now
<Saviq> sil2100, yeah, due to the new cache things
<rsalveti> sigh, just saw latest powerd caused issues
<Mirv> yeah it seems new stuff is being created on the server too
<sil2100> rsalveti: morning
<rsalveti> for the same annoying unlock logic we already had issues before
<mandel> alex-abreu, tell me :)
<alex-abreu> mandel, hey sorry to bother you again :)
<mandel> alex-abreu, no bother!!! tell me
<alex-abreu> mandel, was wondering what are the plans for the dl manager, in terms of landing (MIR) & backport to 13.10 (if it happens)
<alex-abreu> mandel, the idea is that I have the html5 bindings for it, but not sure when to land them
<mandel> alex-abreu, so, MIR yes as soon as I have all the packages ready and will ping the right person (mainly adding a few new packages for uploads etc..)
<Mirv> sil2100: so, two main filling up issues - old pbuilder cow directories probably from the reboots etc, and then the ever-filling pbuilder aptcache
<mandel> alex-abreu, those html5 bindings, were are they? in a diff project?
<mandel> alex-abreu, backporting is something I'll do if people request it :)
<alex-abreu> mandel, yup difff project where we (the #webapps team) handle the bindings
<Mirv> the latter was already there, but today's reboots got the first problem to finally fill to 100%
<alex-abreu> mandel, ok make sense, then I'll wait for the MIR to land it
<alex-abreu> mandel, https://code.launchpad.net/~abreu-alexandre/unity-webapps-qml/download-api
<mandel> alex-abreu, what I want to do is have an stable API (there are some changes coming for content-hub) before we make you do extra work
<mandel> alex-abreu, they are not big changes, but nevertheless
<Mirv> seb128: so for the time being the aptcache clean would have been enough. thanks for the comments/tips.
<alex-abreu> mandel, yeah, the content hub changes have landed alreayd I think, the ones that relate to the revamp of the api
<sil2100> t1mp: ok, UITK should be rebuilding now
<alex-abreu> mandel, ok I'll wait, & try to keep track of the changes in DL manager ... keep me in the loop of you can (we are the team working on html5 apps & the platform bindings)
<sil2100> Mirv: ok, a thing to remember then
<mandel> alex-abreu, yes, but there are some changes in the pipeline of download manager to accommodate to the content-hub + browser estoy
<mandel> alex-abreu, I'll make sure that you get all the info asap
<alex-abreu> mandel, ok I'll monitor the changes
<mandel> alex-abreu, I want to have everything landing on monday, then MIR then we can move fwd
<alex-abreu> mandel, ok so around next week ..
<mandel> alex-abreu, yes, that is the goal
<alex-abreu> works for me
<mandel> alex-abreu, the latests latest date will be the 4th, latest
<Mirv> t1mp: so, your request was handled? sorry, during the hangout a situation evolved :D
<sil2100> ;)
<sil2100> asac: so, the situation seems stable now
<alex-abreu> mandel, I am not in a hurry, thats fine, we are on shcedule, just dont like branches lying around
<mandel> alex-abreu, yes, I have the same feeling that is why I like to land everything asap
<alex-abreu> mandel, & wanted to make you aware of us :)
<mandel> alex-abreu, you've been in my radar since last time we talked hehe
<alex-abreu> cool
<seb128> Mirv, yw!
<alex-abreu> mandel,  the dlmanager will be a great piece in the platform apis much needed
<sil2100> Driving quickly home from lunch, Mirv is monitoring, afk for 5-10 minutes
<rsalveti> ogra_: thanks for fixing powerd, will update the testing plan and also propose another patch to just allow that interface that is needed for the unlock thing
<rsalveti> still don't want a normal user to be able to access everything that powerd exports
<asac> sil2100: awesome... what was done?
<asac> sil2100: please stay on alert :)
<rsalveti> sil2100: didrocks: can I get a silo for 46 now that powerd was fixed?
<asac> seems today is a fun day :)
<Mirv> rsalveti: he's driving, asssigning
<Mirv> asac: yes it is :)
<rsalveti> Mirv: thanks
<t1mp> Mirv: yes it was handled by sil2100
<Mirv> oh, boiko's request was left out in all this... :(
<rsalveti> ogra_: didrocks: how can I run the same logic used to unlock the screen as done in the lab?
<asac> Saviq: is your problem also solved?
<Saviq> asac, one of them
<asac> Saviq: whats the other?
<Saviq> asac, ubuntu-touch-session fails to build the package for some reason http://162.213.34.102/job/landing-015-1-build/44/console
 * Saviq tries locally
<mandel> alex-abreu, yes, I think that the over all pict with the download manager and content hub is looking great and having html5 bindings is just great
<asac> sil2100: can you check that once back?
<Mirv> Saviq: can I flush your greeter split out temporarily as described in it?
<rsalveti> asac: doanac: didrocks: can't we move the unlock screen logic to phablet-config or similar?
<Saviq> Mirv, yes
<asac> sil2100: Mirv: is the log i see here http://162.213.34.102/job/landing-015-1-build/44/console coming from launchpad?
<rsalveti> it seems this is specific to the lab setup, so hard to reproduce outside the lab
<asac> or is that preparing tsource packages?
 * Saviq wonders if it's the lack of -1ubuntu1 in the version
<Saviq> asac, preparing
<asac> rsalveti: you hit a big wound
<asac> rsalveti: talk sense into thomi
<doanac> rsalveti: i would love that. i've ask for it before
<rsalveti> asac: I know :-)
<Saviq> rsalveti, we are
<asac> doanac: how is the effort to standardize screen unlock going?
<Saviq> rsalveti, https://code.launchpad.net/~mterry/unity8/unlock-script/+merge/212170
<Mirv> Saviq: thanks!
<Mirv> rsalveti: landing-008
<doanac> asac: a script is now going into unity8 that should help
<asac> doanac: a script that makes it easy to unlock?
<rsalveti> Saviq: great, let me check
<asac> doanac: then where will the unlock logic go? and where will be maintained which test needs unlocking
<asac> ?
<Saviq> rsalveti, we need to have (parts of it) in unity8 so that we maintain it in case of changes, other parts in lightdm and potentially usc
<Saviq> rsalveti, and a bind-them-together script in $yet-unnamed-ubuntu-integration-test-suite
<doanac> asac: ^^^
<rsalveti> got it, cool
<ogra_> rsalveti, i noted down in the bug how to use the same logic
<Mirv> boiko: landing-013 for you, sorry for the delay, a bit chaotic today with jenkins crashing and filling up
<doanac> so the script is just no longer owned by my team. we still should strive for getting phablet-test-run smart enough to do this for a test
<rsalveti> ogra_: yeah, updating https://wiki.ubuntu.com/Process/Merges/TestPlans/Powerd
<Saviq> ogra_, any idea on this failure to build a source package http://162.213.34.102/job/landing-015-1-build/44/console (scroll up a bit)
<ogra_> rsalveti, perfect
<Saviq> it builds fine locally :/
<ogra_> Saviq, i have no clue what robru did to the branch ... i havent used it since he converted it to be a CI one
<asac> Saviq: rsalveti: doanac: do we agree that the test itself should export/declare whether it needs an unlocked screen or not?
<asac> even if we have a tool outside of the testharness that interprets that and does the unlock?
<rsalveti> that would be ideal
<rsalveti> a requirement for the test
<seb128> sil2100, Mirv: are you debugging Saviq's ubuntu-session issue?
<Mirv> boiko: I started a build for you too
<ogra_> asac, ++
<Mirv> seb128: sorry, no, I thought Saviq restarted it and it's ongoing, but I guess he removed that commit?
<doanac> asac: that's ideal, i'm not sure how we'd go about doing that and i suspect thomi will disagree
<asac> ok, so once our test declares that we dont need to maintain a separate list. thats a good start
<seb128> Mirv, there is still an issue with that source/component that need debugging
<doanac> but its ideal for me
<asac> then next question is: why the hell are we not hooking the unlock logic into a superclass of all our unity based autopilot tests?
<rsalveti> Mirv: thanks!
<asac> i have been asking for that for like a year
<doanac> asac: +10
<Saviq> seb128, Mirv, I _think_ it's because it doesn't have a -0ubuntu0
<seb128> Mirv, likely something in the vcs/debian dir that doesn't suit CI
<Saviq> ogra_, oh, it doesn't actually have any train-ci entries in debian/changelog
<asac> so the concrete class sets autounlock: true/false
<Saviq> asac, only problem we need to make sure of is that this doesn't affect testing outside of the device
<doanac> asac: and it can detect if its running on phone/desktop so if on desktop unlock is a noop
<asac> Saviq: what does testing outside of the device mean?
<Saviq> asac, on your desktop
<asac> requireScreenUnlocked
<asac> if you dont have a lock screen
<asac> this would just return
<asac> err do nothing
<asac> doesnt feel like a big deal
<asac> Saviq: are people really still testing apps on desktop?
<asac> Saviq: isn't the usefulness of that going down more and more?
<asac> i would imagine you usually want to use at least a few things of the touch platform to do anything not trivial
<asac> but maybe i am wrong :)
<Saviq> asac, apps are meant to run on desktop, too
<Saviq> asac, and if anything, it's just about the development process
<Saviq> asac, deploying to device every time you want to run a test when developing it is not good enough
<doanac> but you could still check if you are on a phone/desktop and know that unlock is a no-op
<Saviq> asac, verifying it after you know it's good on your host, sure, but not through the whole process
<Saviq> doanac, sure
<Mirv> seb128: Saviq: ubuntu-touch-session should drop debian/source/format (1.0) if it's wanted to be using CI Train now. otherwise it could be added to the "Additional source packages to land" and uploaded manually to the Landing PPA
<Saviq> ogra_, â
<Saviq> ogra_, it didn't get converted to train, upload manually?
<Mirv> that's the fastest way
 * Saviq fixes the line
<ogra_> Saviq, hmm ? robru said it did
<Mirv> ogra_: it seems it has needed traits mostly but it's probable the source format 1.0 is causing a proble still
<ogra_> Saviq, just upload then
<Saviq> ogra_, I can't
<Mirv> robru probably meant "it has been marked to be converted to CI Train", but it hasn't been ever released via CI Train
<ogra_> ??
<ogra_> its a PPA
<Mirv> dput ppa:ci-train-ppa-service/landing-015 *.changes
<Saviq> ogra_, I'm not on the team
<seb128> Mirv, you are sure the issue is the source format?
<Saviq> ogra_, that can upload
<Mirv> but right, ogra can, Savi qcan't
 * ogra_ sighs ... 
<ogra_> ok, i try very hard to have some breakfast atm, then i have a meeting
<ogra_> i'll do it after this
<Mirv> seb128: not really sure but it's the first thing that gets my attention. I'm just trying to formulate a solution, not The solution.
<seb128> ogra_, Mirv: we are sure that the issue is the v1 format?
<seb128> Mirv, that might need further debugging rather than guessing?
<Mirv> seb128: yes, but probably separately from this landing
<Mirv> I can't do it now
<seb128> Mirv, if that's the issue what about trying to convert to v3 and try again through CI train?
<seb128> why not?
<seb128> it seems like just bouncing the issue to the next one that is going to hit it
<seb128> and it's probably going to waste time to remember the issue next time
<seb128> it would be better handled now
 * Saviq can do that
<seb128> in a proper way
<seb128> Saviq, thanks
<Mirv> various reasons, I'm just trying to survive until sil2100 is back while didier is also away
<Mirv> but if you have time, please update the MR instead
<seb128> where is sil2100?
<Mirv> seb128: driving a car :D
<dbarth_> sil2100: silo 11 should be fully built now
<seb128> he said 5-10 min
<seb128> it was 30 min ago
<seb128> sil2100, ?
<Mirv> Saviq: so, debian/source/format -> 3.0 (native)
<Mirv> I just thought saviq couldn't change that as it's mzanetti's branch
<Saviq> Mirv, well, resubmit isn't difficult :)
<seb128> well, he can add another branch to the landing
<rsalveti> davmor2: auto-brightness should work with latest image (not yet on flo, working on it)
<rsalveti> davmor2: you just need to enable it in system-settings
<davmor2> rsalveti: nice I'm still breaking the last image but I'll certainly upgrade in a bit :)
<Saviq> that silo is gonna hate me :D
<davmor2> Saviq: we have a special silo just for you now number 666 now you'll know how a silo can hate ;)
<Mirv> Saviq: thanks! let's see how it goes. the native versions are a bit rarer but 3.0 (native) could help.
<plars> rsalveti, ogra_, ChickenCutlass: given the recent email about surfaceflinger support, can we kill off the sf4p job in CI?
<ogra_> plars, ask asac
<ogra_> i have never looked at it
<plars> ogra_: he said to ask you :)
<ogra_> move it then
<ogra_> *re
<asac> this was set up for ogra_ and rsalveti
<asac> :)
<ogra_> huh ?
<asac> they wanted to keep SF going
<rsalveti> yeah, I asked that
<asac> for enablement path
<ogra_> ah
<rsalveti> plars: it's fine to disable it
<asac> :)
<plars> ogra_: I think the answer is obviously "yes, kill it" as it makes no sense to run something that will always fail. So I guess what I'm really saying is "you all aren't looking at this anymore right?"
<rsalveti> plars: it was useful for a while, but yeah, can be killed now
<plars> thanks
<sil2100> Traffic jams
<sil2100> I'm online now
<seb128> sil2100, wb
<Mirv> sil2100: we missed you! :)
<sil2100> I know, sorry for that :<
<asac> sil2100: wb :)
<asac> can you check out saviq's issue? :)
<sil2100> Sure!
<sil2100> Mirv: you can go eat food made by your wife ;)
<Mirv> sil2100: sounds good :D in a moment
<sil2100> dbarth_: publishing your filo!
<sil2100> *silo
<Mirv> sil2100: so the ubuntu-touch-session hasn't seen a CI Train release before, and it's a native package versioning with debian/source/format set to 1.0. the first try Saviq is doing is change to 3.0 (native)
<Saviq> Mirv, didn't help :|
<Mirv> sil2100: ...and that didn't help
<Saviq> http://162.213.34.102/job/landing-015-1-build/46/console
 * Saviq wonders why it works locally
<Saviq> is debuild different on there or something...
<sil2100> Mirv: ok, I'll try taking it from here... so you tried the source format then?
<Mirv> sil2100: Saviq: the second thing I see is that .bzr-builddeb/default.conf has Native = true. I think we've actually converted all native packages to be non-native now, so it might be that we need to drop both debian/source/ dir _and_ that .bzr-builddeb option and get back to normal 0.145+date-0ubuntu1 format
 * Saviq tries
<Mirv> sil2100: Saviq: I'm just not 100% sure if we're not supporting 0.145+date format for some package, ie could it work or should the native part be forgotten
<sil2100> Mirv: I think it should work for all cases
<Mirv> sil2100: second thing, I needed to free up the greeter split silo since we're critically low on silos and I couldn't have fulfilled boiko's request otherwise
<sil2100> Mirv: ok, was Saviq informed? ;)
<Mirv> sil2100: yes he agreed :)
<Saviq> yup
<Saviq> mterry is away today anyway, so it's his fault :D
<sil2100> ;)
<Mirv> sil2100: the CI Train should handle all cases and _convert_ to non-native versioning, is my assumption, but do you know if we have some CI Train package that continues to use native versioning ie. no "-0ubuntu1" part but just appended time stamps?
<sil2100> Mirv: hm, no, actually I don't know of any package that would be right that
<Mirv> if it's the former, then indeed what saviq is now doing should work, ie. dropping the two native options and letting CI Train do its magic
<Saviq> Mirv, no... no go http://162.213.34.102/job/landing-015-1-build/47/console
<sil2100> Mirv: anyway, I think I never saw any native = True project in CITrain and cu2d ;/
<Saviq> wonder if I need to put one non-native version there at least
<Mirv> Saviq: ah, don't remove the .bzr-builddeb directory, just the native = True!
<Saviq> Mirv, oups
<sil2100> Saviq, Mirv: so, why suddenly we decided to use citrain for ubuntu-touch-session btw.?
<Saviq> sil2100, seb128 told us to :D
<sil2100> Normally we have been doing it the source way
<sil2100> Ah, ok ;)
<seb128> heh, I didn't told you that! you tried it and hit issues, I just said to not work around them because it's just going to delay the debugging and pushing to the next one who is going to hit it
<seb128> sil2100, Saviq: ^
<sil2100> Right!
<sil2100> Well, we can try working this out somehow anyway, let me dig into that now, need to familiarize on what's up
 * Mirv goes eat, I hope the world doesn't explode and also that robru would be online too soon :)
<Mirv> dinnertime
<Saviq> seb128, ;)
<sil2100> Mirv: ;p
<Laney> Saviq: debian/bzr-builddeb.conf
<Saviq> jeez
<sil2100> Mirv: I'll mup you if suddenly I would need access to the jenkins instance ;p
<Saviq> where else :D
<Laney> I have no idea whatsoever what the .bzr-builddeb one is
<Mirv> jeez, what's debian/bzr-builddeb.conf doing there...
<Mirv> sil2100: :)
<sil2100> .bzr-builddeb/default.conf is what you're looking for ;)
<Mirv> sil2100: yeah but that debian/ has ^ file
<sil2100> huh ;)
<Laney> make it say split = True only
<Laney> then bzr bd -S makes a proper package for me
<Mirv> Laney: it's now there in .bzr-builddeb/, which is what all other packages use
<sil2100> Yeah, that was the recommendation
<Mirv> but there was duplicate conf files
<Laney> Never heard of that
<sil2100> native = True is a bad option for cu2d packages
<Laney> I also don't get it if I branch that fix-source-package thing
<Mirv> Laney: https://wiki.ubuntu.com/DailyRelease/InlinePackaging
<sil2100> Laney: https://wiki.ubuntu.com/DailyRelease/InlinePackaging <- we used this since always in cu2d
<sil2100> Mirv: ;D
<sil2100> Mirv: go eat or you're starve!
<Saviq> \o/
 * Mirv goes
<Saviq> IN YOUR FACE
<Laney> weird
<Saviq> Laney, thanks!
<Laney> seems more obscure than a file in debian/
<Laney> np
<sil2100> o/
<sil2100> *you'll
<sil2100> seb128: I guess you're publishing your landings yourself, right? :)
<seb128> sil2100, yes, did I overlook any?
<seb128> sil2100, just publised 002
<seb128> we should have quite some silos back soon
<seb128> the release team has approved some items as well
<sil2100> seb128: no no, just never sure if I should publish your landings when they are set to ready or not ;)
<sil2100> Indeed, ido is still in proposed for isntance
<seb128> sil2100, I usually do it if I'm online, but if I'm not around feel free to do it
<sil2100> seb128: ok, thanks ;)
<sil2100> Still waiting for some silos to finally free up
<pmcgowan> bfiller, whats with silo 9 progress
<sil2100> I see the silo is still blocked on ppc, even though it shouldn't
<bfiller> pmcgowan: it built on supported arches, but CI train not showing correct status
<sil2100> pmcgowan, bfiller: let me retry something
<pmcgowan> ok cool so going to land?
<bfiller> sil2100: it's failing on unsupported arches but that's expected
<cjwatson> huh, what, I'm not sure my removal from last night took effect
<sil2100> bfiller: yes, but cjwatson removed those arches from the archive, so it should be good now
 * cjwatson goes to hit it harder
<sil2100> cjwatson: it might, probably the job jwas ran too early
<bfiller> pmcgowan: we can test it for sure
<sil2100> Let me rekick with watch only
<cjwatson> sil2100: no, it's literally still in the archive
<bfiller> pmcgowan: still waiting on fix to make existing webapps transition correclty, that's not in yet
<sil2100> cjwatson: ah, ouch
<cjwatson> oh, bah, this is exactly what I predicted, that I'd have to do the work twice
<cjwatson> https://launchpad.net/ubuntu/trusty/arm64/webbrowser-app
<sil2100> That's so sad, deleted and republished
 * cjwatson re-removes
<sil2100> cjwatson: thanks!
<asac> sil2100: any idea on the saviq case yet? :)
<Mirv> asac: it was solved
 * Mirv oh right, I'm not here
<sil2100> asac: it's solved ;)
<sil2100> asac: it seems there was a duplicate bzr-builddeb config that was forcing native even though we were fixing that
<Mirv> it needed fixing in three places :S
<sil2100> heh ;)
<sil2100> Yay for redundancy!
<sil2100> Proposed migration so slooow..! (ignore me)
<cjwatson> sil2100: removal should be effective in 30 mins or so
<sil2100> cjwatson: excellent, will re run the job then
<asac> sil2100: Mirv: awesome!
<cjwatson> check "rmadison -s trusty webbrowser-app" first, make sure it only lists supported arches
<sil2100> bfiller: so, in that time I'll re-run with watch only and we won't have that irritating infinite-wait anymore
<bfiller> sil2100: thanks
<cjwatson> sil2100: the compiz/unity and unity-gtk-module silos should be m&c-able nowish
<cjwatson> unity-control-center and ido are waiting for autopkgtests
<sil2100> cjwatson: thanks! I didn't see ido yet in update_excuses, so I started to worry
<cjwatson> it's still updating stats, but I'm watching the log
<cjwatson> it's there now
<sil2100> cjwatson: big thanks for the live-info ;)
<cjwatson> I might have saved you a whole minute ;-)
<sil2100> Every second counts!
<boiko> Mirv: sil2100: do you by chance know if the silo builders are cleaned up after each build (in terms of package installation)?
<sil2100> boiko: by silo builders, you mean those in the PPA?
<boiko> sil2100: yep
<cjwatson> PPAs start from a fresh chroot each time
<sil2100> boiko: so, they work like normal PPA's, so every time a build starts it starts in a clean environment
<boiko> sil2100: I'm just curious cause one of the telephony-service tests failed with a timeout, and for me this only happens when there is extra telepathy packages installed (like telepathy-logger for instance)
<sil2100> boiko: but the PPA is not cleaned every time the CITrain Build button is pressed
<boiko> cjwatson: sil2100: thanks
<sil2100> boiko: shouldn't be the case here, if the logs don't say it's installed than it can't be there
<cjwatson> it's definitely not possible for stale packages to be left around in a PPA build from a previous build
<boiko> ok, so I will have to debug why this is happening
<boiko> it is only on powerpc and ppc64el though
<sil2100> boiko: try creating a clean pbuilder chroot for powerpc and building it locally - it might be reproducible everytime on that platform
<boiko> sil2100: yeah. I will try that, thanks
<cjwatson> boiko: maybe it's just racy; it doesn't happen for me on porter-ppc64el
<ogra_> Saviq, so i see a bunch of MPs for the session stuff ... do you still need a direct upload from me or will it work now ?
<boiko> cjwatson: hmm, shouldn't be, but in any case, is there a way for me to trigger a rebuild only on those archs that have failed?
<Saviq> ogra_, works now
<ogra_> yay
<Saviq> ogra_, there were *3* places with Native = True or similar ;)
<sil2100> ;)
<ogra_> well, it was native before :)
<ogra_> blame rob
<sil2100> ogra_: yeah, 2 places with bzr-builddeb configs and the source format
<Laney> "No, REALLY REALLY native"
<Saviq> ogra_, bzr blames you :D
<cjwatson> boiko: I can
<ogra_> lol
<Saviq> ogra_, at least for debian/bzr-builddeb.conf
<ogra_> hmm, i cant remember ...
<ogra_> ... the age ... y'know
<ogra_> :)
<cjwatson> boiko: just trying on one for now though to avoid wasting builder time
<boiko> cjwatson: thanks
<boiko> cjwatson: meanwhile I will try to create a pbuilder chroot to try locally
<Saviq> blames lool for .bzr-builddeb/default.conf, and Renato for the last change to debian/source/format
<sil2100> !
<sil2100> Everyone's at fault!
<cjwatson> hmm, IWBNI if we could grant landers temporary access to their active silos in LP so that they could retry builds themselves
<cjwatson> s/ if//
<Saviq> oh oh oh, unity won't lock now after I unlock it??! /me wants :D
<Saviq> seb128, thanks for pushing â through
<seb128> Saviq, yw ;-)
<ogra_> what ? did he break the extra added security when locking ?
<seb128> sil2100, can I get silos for the 2 lines I added? we are back to 3 and some others cleaning soon
<sil2100> seb128: just started assigning
<seb128> sil2100, I would like to start builds before going for some exercice ;-)
<seb128> sil2100, excellent, thank you!
<sil2100> The spreadsheet takes a while to refresh ;)
<lool> Saviq: hmm?
* josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<cjwatson> boiko: hm, failed again
<Saviq> lool, nothing :)
<cjwatson> boiko: well, it's grotty, but if you're in a hurry and this is blocking you, then it might be best to just disable that test on the offending arches
<cjwatson> not great but it depends how much time you have available
<boiko> cjwatson: ouch, well, I will have to try that locally, but pcreate is failing here to create a powerpc chroot,
<cjwatson> you'll need the appropriate qemu bits
<boiko> cjwatson: is it qemu-user-static? I already have that one
<cjwatson> should be
<cjwatson> I'm not a pbuilder user though so not going to be much use debugging that
<boiko> cjwatson: no problems, thanks for the help
<sil2100> seb128: are you away for exercise already?
<seb128> sil2100, I just click clean on 3 silos and was about to go
<sil2100> seb128: if yes, then I'll m&c your branches
<seb128> sil2100, why?
<sil2100> Ah
<sil2100> Ok ;)
<seb128> sil2100, the table has the "cleaning" status ;-)
<sil2100> Already m&c'd dbarth_ silo ;)
<seb128> great
<seb128> back to 4 soon then
<sil2100> Yeah, now I see it, when asking it was still m&c possible ;)
<seb128> which gives some spare capacity for incoming demands
<sil2100> Thanks!
<seb128> yw, thanks for checking!
<cjwatson> sil2100: hm, I wonder if the landing-009-1-build job needs to be cancelled and restarted in order to notice that the archive now has " webbrowser-app | 0.23+14.04.20140324-0ubuntu1   | trusty         | source, amd64, armhf, i386"?
<cjwatson> or is that even something it will automatically notice at all?
<cjwatson> ... looks like that worked
<sil2100> cjwatson: yeah, I was already working on that ;)
<sil2100> cjwatson: the problem was that even though I fixed the jenkins job, the spreadsheet was out of date
<sil2100> I had to force it to update its status properly, since on the backend side everything was ok
<sil2100> cjwatson: but thanks for the fix!
<sil2100> Saviq: should I give you back the 'split greeter' silo?
<Saviq> sil2100, next week I think
<sil2100> k
<sil2100> tvoss: regarding silo 20 - if you want to rebuild packages from the silo, you have to explicitly say which packages you want to rebuild - i.e. write down their source pacakge names in the field during rebuild
<tvoss> sil2100, oh, my bad
<sil2100> cyphermox, kenvandine: did anyone of you had a moment to take a look at the dee add-symbol-files branch I mentioned yesterday? :)
<sil2100> I would love to get rid of that dh_makeshlibs -V already ;)
<cyphermox> didn't look
<plars> sergiusens: what are your plans with regards to phabletutils under phablet-tools? We were making use of detect_device in there, which throws an exception for flo.  I'm trying to decide if we should just implement our own, add support for flo in phablet-tools or what?
<kenvandine> sil2100, sorry... i must have missed that
<sil2100> No problem, nothing urgent ;)
<sil2100> Just somethign I would prefer dealing with sooner or later
<boiko> cjwatson: do you by chance have any example of a CMakeLists.txt that enables/disables stuff depending on the arch? (I'm trying to figure out the correct way of doing that)
<cjwatson> boiko: I fear I'm not really much of a cmake expert
* retoaded changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: retoaded | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<kenvandine> sil2100, give me a link, unless cyphermox is handling it
<sil2100> kenvandine: one moment ;)
<rsalveti> sil2100: can I haz a silo for 57?
<sil2100> kenvandine: https://code.launchpad.net/~sil2100/dee-qt/add_cpp_symbols/+merge/202679
<sil2100> rsalveti: let me look
<sil2100> ogra_: meeting!
<balloons> no call today?
<kenvandine> sil2100, shouldn't the symbols file have replaceme instead of the version?
<ogra_> balloons, feel free to join :)
<balloons> I'm sitting alone i one
<kenvandine> or is that not supported for c++
<ogra_> balloons, in the one from the calendar  ?
<balloons> d'oh, wrong g+ invite, hahahah
<ogra_> :)
<sil2100> Saviq: so, any progress on the unity8 crasher now that we might be able to retrace it?
<Saviq> sil2100, yeah, Albert just pushed a fix to be verified
<Saviq> sil2100, https://code.launchpad.net/~aacid/unity8/lvwphnoprocessevents/+merge/213306
<sil2100> Saviq: thanks!
<sil2100> Saviq: can't wait to see it in a silo ;p
<balloons> ping retoaded
<balloons> retoaded, the click job for calendar is failing to complete successfully because of a mv command at the end of the script. Can you have a look? http://s-jenkins.ubuntu-ci:8080/job/calendar-app-click/103/console
<davmor2> Saviq, didrocks, sil2100: Well stone me if that wasn't a waste of time bug #1299129
<ubot5> Error: Launchpad bug 1299129 could not be found
<davmor2> Saviq, didrocks, sil2100: Well stone me if that wasn't a waste of time bug #1299129
<davmor2> see even the bug bot hates me
<didrocks> davmor2: nice!
<davmor2> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1299129
<ubot5> Ubuntu bug 1299129 in unity8 (Ubuntu) "unity8 crashed with signal 7 in QMutex::lock()" [Undecided,New]
<davmor2> didrocks: read the stacktrace so after all that still no better off
<didrocks> davmor2: well, it will be for Saviq :)
<davmor2> any way teatime
<retoaded> balloons, looking
<Saviq> davmor2, yeah, same thing
<sil2100> uh
<sil2100> boiko: so, how's it going with those build problems?
<retoaded> balloons, kicked off another build, should complete this time
<balloons> retoaded, thank you much
<sil2100> balloons: hi! So, could you release something to the store for me? :)
<balloons> sil2100, I'd love to
<balloons> hopefully it goes better than popey and I's releases :-p
<boiko> sil2100: I asked tiago to disable the tests on ppc* for now, will rebuild soon
<sil2100> balloons: so, currently lp:~ps-jenkins/gallery-app/trusty-proposed is where the latest gallery-app is right now ;)
<sil2100> balloons: this will be merged into trunk pretty soon, but you can use it to release right now ;)
<sil2100> balloons: thanks!
<sil2100> boiko: excellent!
<retoaded> balloons, success
<davmor2> Saviq: that was expanding the apps which I guess will be a similar issue as didrocks reported too so looks like they might all be intertwined maybe :)
<davmor2> Saviq: that is of course not to say that something else triggered it and the lock up happened on expanding apps :)
<Saviq> davmor2, yeah, until we have those two killed, we won't dig deeper
<sil2100> Have a nice weekend guys, time to go to bed and get better o/
<davmor2> sil2100: enjoy bed if nothing else dude and get well
<davmor2> Saviq: oh there is a potential fix too by the look of it I might look at installing it and see what crashers I get over the weekend
<Saviq> davmor2, yeah there's two potential fixes
<Saviq> davmor2, attached in branches to https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1262711
<ubot5> Ubuntu bug 1262711 in unity8 (Ubuntu) "Unity crashes with lots of music displayed in expanded music category in home scope" [High,Confirmed]
<davmor2> Saviq: should I be worried by https://code.launchpad.net/~aacid/unity8/lvwphnoprocessevents/+merge/213306
<Saviq> davmor2, you mean CI results?
<davmor2> Saviq: yes
<Saviq> davmor2, bad whitespace in line 2112
<Saviq> davmor2, so no :)
<Saviq> davmor2, fwiw https://wiki.ubuntu.com/CrossBuilding should work for building unity8
<davmor2> Saviq: gah I hat this building stuff from source I'll have a look tomorrow if there is a build available.  I'm calling it a week :)
<davmor2> s/hat/hate
<boiko> cyphermox: rsalveti: robru: landing-013 properly tested already, good to go
<robru> boiko, thanks
<cyphermox> ok
<boiko> robru: do I need to clean the silo or did you already triggered that?
<robru> boiko, oh normally you would, but I did it since we're crunched for silos today.
 * robru is slightly impatient ;-)
<boiko> robru: ok, thanks
<robru> boiko, you're welcome!
* retoaded changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: -
<rsalveti> sergiusens: hey
<sergiusens> rsalveti: nice; it works :-)
<rsalveti> :-)
<bregma> robru, got a quickie needs a silo in line 58, you up to it?
<robru> bregma, hey, sure
<robru> bregma, sorry, was on lunch there
<robru> bregma, ok you got silo 2
<bregma> ta
<robru> yw
<bregma> robru, silo 2 is ready for publish
<robru> bregma, wow, already?
<bregma> told ya it was quick
<robru> nice
<bregma> it's a small package, and either it boots or it doesn't
<bregma> and it did
<robru> bregma, hah. ok, published!
<bregma> waited 2 hours for it to build in a PPA earlier today
#ubuntu-ci-eng 2014-03-29
<robru> bregma, alright! need anything before I go EOW?
<robru> or anybody else...
<robru> have a good weekend everybody!
<imgbot> === trainguard: IMAGE 267 building (started: 20140329-03:05) ===
<imgbot> === trainguard: IMAGE 267 DONE (finished: 20140329-04:40) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/267.changes ===
<ogra_> |HELP
<imgbot> I am the firendly image watchbot
<Laney> ogra_: srsly, please fix that typo :P
<ogra_> already done
<Laney> â¥
<ogra_> just struck me, hadn't restearted it yet
<Laney> |HELP
<imgbot> I am the friendly image watchbot
<Laney> very helpful
<ogra_> heh
<imgbot> cough
<ogra_> |STOP
<imgbot> AAAAARRRGH !!! (dying)
<infinity> How did that last account-plugins upload make it past the system with an empty changelog?
<infinity> https://launchpad.net/ubuntu/+source/account-plugins/0.11+14.04.20140325-0ubuntu1
<ogra_> Bug 1290771
<infinity> That seems pretty suboptimal.
<ubot5> bug 1290771 in Canonical Upstream To Distro "cupstream2distro should FTBFS if packages have an empty changelog" [Undecided,New] https://launchpad.net/bugs/1290771
<ogra_> imgbot: status 0
<ogra_> imgbot: help
<ogra_> bah
<ogra_> imgbot: help
<imgbot> I am the friendly image watchbot
<ogra_> imgbot: status 0
<imgbot> test status
<ogra_> imgbot: status 0
<imgbot> test status :ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de PRIVMSG #ubuntu-ci-eng :imgbot: status 0
<ogra_> imgbot: stop
<imgbot> AAAAARRRGH !!! (dying)
<ogra_> imgbot: status 267
<imgbot> test status 267 on mako total:667 pass:664 crashes:0 rate:99.6%
<ogra_> imgbot: stop
<imgbot> AAAAARRRGH !!! (dying)
<ogra_> imgbot: status 267
<imgbot> Test status for image 267 on mako total:667 pass:664 crashes:0 rate:99.6%
<ogra_> imgbot: status 268
<sergiusens> ogra_: are you using some django/web api provided or scrapping?
<ogra_> sergiusens, wget and html2text :)
<sergiusens> that's scrapping :-P
<ogra_> ultra scrapping ;)
<ogra_> closer to grinding perhaps :)
<ogra_> hmm, why did it die
<ogra_> imgbot: status 267
<sergiusens> doesn't like to grind I guess
<sergiusens> :-P
<ogra_> heh, no, thats fine, it doesnt like to tell me there has been no testing yet
<sergiusens> so it needs to grind
<ogra_> well, the grinding is an external script
<ogra_> imgbot: help
<imgbot> I am the friendly image watchbot
<ogra_> imgbot: stop
<imgbot> AAAAARRRGH !!! (dying)
<ogra_> imgbot: status 267
<ogra_> imgbot: stop
<imgbot> AAAAARRRGH !!! (dying)
<ogra_> imgbot: status 267
<ogra_> imgbot: stop
<imgbot> AAAAARRRGH !!! (dying)
<ogra_> imgbot: status 267
<imgbot> Test status for image 267 on mako total:667 pass:664 crashes:0 rate:99.6%
<ogra_> imgbot: status 268
<imgbot> Test status for image Image 268 for mako has not started testing yet
<ogra_> imgbot: status 255
<imgbot> Test status for image 255 for mako is not done testing yet
<ogra_> imgbot: status 268
<imgbot> Test status for image 268 for mako has not started testing yet
<ogra_> imgbot: stop
<imgbot> AAAAARRRGH !!! (dying)
<ogra_> imgbot: status 268
<imgbot> Image 268 for mako has not started testing yet
<ogra_> imgbot: status 255
<imgbot> Image 255 for mako is not done with testing yet
<ogra_> imgbot: status 267
<imgbot> Image 267 on mako total:667 pass:664 crashes:0 rate:99.6%
<ogra_> great
<ogra_> imgbot: stop
<imgbot> AAAAARRRGH !!! (dying)
<ogra_> imgbot: status 267 flo
<imgbot> Image 267 flo for mako has not started testing yet
<ogra_> lol
<ogra_> imgbot: stop
<imgbot> AAAAARRRGH !!! (dying)
<ogra_> imgbot: status 267 flo
<imgbot> Image 267 on flo total:667 pass:663 crashes:0 rate:99.0%
<ogra_> imgbot: status 267 manta
<imgbot> Image 267 on manta total:646 pass:627 crashes:0 rate:94.8%
<ogra_> imgbot: status 268 manta
<imgbot> Image 268 for manta has not started testing yet
<ogra_> imgbot: status
<ogra_> imgbot: status 255
<imgbot> Image 255 for mako is running tests
<ogra_> imgbot: stop
<imgbot> AAAAARRRGH !!! (dying)
<Laney> O_O
<Laney> Maybe you should do this in a test channel?
<ogra_> yeah, sorry, i'm done
#ubuntu-ci-eng 2014-03-30
<imgbot> === trainguard: IMAGE 268 building (started: 20140330 03:05) ===
<imgbot> === trainguard: IMAGE 268 DONE (finished: 20140330 04:35) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/268.changes ===
<ogra_> imgbot: status 268
<ogra_> bah
<ogra_> imgbot: status 268
<imgbot> needs numeric build id and optionally architecture (one of mako|flo|manta)
<ogra_> imgbot: status 268 mako
<imgbot> Image 268 for mako is still running tests
<ogra_> imgbot: status 268 mako
<imgbot> Image 268 on mako total:666 pass:666 crashes:0 rate:100%
<ogra_> imgbot: status 268 flo
<imgbot> Image 268 on flo total:667 pass:660 crashes:0 rate:98.7%
<bzoltan> Any chance to get the silo10 published on Sunday? :)
<ogra_> imgbot: stop
<imgbot> AAAAARRRGH !!! (dying)
<ogra_> imgbot, stop
<imgbot> AAAAARRRGH !!! (dying)
<ogra_> imgbot, stop
<imgbot> AAAAARRRGH !!! (dying)
<ogra_> imgbot, stop
<imgbot> AAAAARRRGH !!! (dying)
<ogra_> imgbot, stunt
<imgbot> /me rolls on it's back and purrs
 * ogra_ grumbles
<imgbot> ACTION
<imgbot> \x01ACTION
<imgbot> /me rolls on it's back and purrs
<ogra_> imgbot, stop
<imgbot> AAAAARRRGH !!! (dying)
 * imgbot rolls on its back and purrs
<ogra_> great
#ubuntu-ci-eng 2015-03-23
<rsalveti> Mirv: robru: slangasek: do we know who disable the import-images job from cron?
<robru> rsalveti: i know nothing.
<Mirv> rsalveti: same here, I've only seen ogra_ discussing import-images at times
<rsalveti> which sucks, as we don't have a new image now
<rsalveti> maybe ogra_ can get it fixed in a few
<Mirv> handling the images is maybe slightly bottle-neck:ish, ie when there is trouble there are few that can help.
<Mirv> in 2-3h, yes
<rsalveti> problem is that cronjob gets disabled without a single comment explaining why
<rsalveti> so impossible to know the reason
<rsalveti> and this happens quite often
<Mirv> right, that has happened before
<Mirv> it'd really use some small process that includes documentation
<rsalveti> yeah
<oSoMoN> good morning trainguards, can I please have a silo for line 74 ?
<Mirv> oSoMoN: ok
<oSoMoN> thanks Mirv!
<ogra_> mvo, do you know if the image importer was disabled due to snappy images ?
<ogra_> err s/images/issues/
<ogra_> Mirv, rsalveti, i'm doing a manual run now
<ogra_> hmm, runnin it with -v and i get no output ... strange
<ogra_> bah ... my crappy keyboard turned that into -vv :(
<mvo> ogra_: no, I was not aware of this, what happend? do you have details?
<mvo> ogra_: I only see a ftbfs on arm64
<ogra_> mvo, not beyond "someone disabled the cron job ... likely on friday"
<sil2100> Shouldn't disabling of the importer be annouonced on -release first?
<sil2100> Was there no rationale for that?
<ogra_> well, we usually announce it on -release ...
<ogra_> obviously the person that disabled it didnt announce it though
<ogra_> i cant really tell if it is broken, seems the -v switch that usually gives you the log doesnt work anymore
<ogra_> i see it moving in top though
<sil2100> huh
<sil2100> jibel: *pokes*
<imgbot> === IMAGE 144 DONE (finished: 20150323-09:55) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/144.changes ===
<Mirv> \o/
<ogra_> ha !
<sil2100> ogra_: maybe let's re-kick an image then? :)
<ogra_> yep, doing
<Mirv> QtWebKit removal progresses http://people.canonical.com/~ogra/touch-image-stats/20150321.changes
<ogra_> whee !
<Mirv> just two updates would be needed (webbrowser-app, ubuntu-html5-theme) and it should drop
<ogra_> cool, i'm eager to see what it drags with it
<imgbot> === IMAGE 145 building (started: 20150323-10:00) ===
<ogra_> sil2100, there is a new tzdata package we might want to pull into rtm
<sil2100> ogra_: on iiiit!
<ogra_> :)
<sil2100> (in case we do an OTA3 from RTM)
<ogra_> yeah, that was the idea
<imgbot> === IMAGE 145 DONE (finished: 20150323-11:25) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/145.changes ===
<sil2100> That seemed fast
<sil2100> hm
<davmor2> ogra_, sil2100: do my eye deceive me or is there no libc there either
<sil2100> Interesting
<sil2100> ogra_, davmor2: from what I see in the image manifest, the latest glibc is in there
<sil2100> ogra_, davmor2: actually, the previous image had it as well
<ogra_> oh, then it landed in 143
<ogra_> hmm, not there either
<sil2100> ogra_, davmor2: I see it got introduced first in 20150322
<sil2100> (from the manifests)
<sil2100> I wonder why I don't see it in changes
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/20150322.changes
<ogra_> it is there
<ogra_> seems not mapped to an iname number :/
<ogra_> *image
<sil2100> hm, but I checked consecutive image numbers
<sil2100> Has this rootfs not been used in any image?
<sil2100> Ah, maybe due to the importer being off?
<ogra_> http://system-image.ubuntu.com/ubuntu-touch/devel-proposed/mako/index.json has no trace of 20150322
<ogra_> yeah, i guess that confused everything
<ogra_> so it was in image 143 + 1/2
<ogra_> :)
<ogra_> 143 is 20150320 ... 144 is 20150323
<ogra_> so the importer skipped it ... let me cat the content to 144
<ogra_> done
<ogra_> oh, wait, 0321 is missing too
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/144.changes
<ogra_> that is the full changeset for the weekend
<davmor2> ogra_: oh so it's listed there then
<sil2100> ;)
<ogra_> davmor2, now it is ... i had to merge three changeloags
<davmor2> ogra_: I see what the issue is, before you were only checking the changelogs now you are looking at the changeloags it is showing up ;)
<sil2100> ogra_: can you tell me which changelog files have changed?
<ogra_> 20150321 and 20150322
<sil2100> ogra_: thanks :)
 * sil2100 lunch
<popey> sil2100: what's happening with the i-d crash fix?
<popey> I see yet another customer with a crashed i-d... https://twitter.com/CGaenzler/status/579067770765086721
<pmcgowan> Mirv, three days lots of use with silo 3 and no crashes
<popey> pmcgowan: did we get a yay or nay for the indicator-datetime to be fixed in rtm? and thus are we going to have another rtm release to make it worthwhile?
<popey> I keep hearing conflicting comments about whether the next OTA will be rtm or vivid based.
<popey> hard to know current stats
<popey> *state
<pmcgowan> popey, the next ota is rtm based
<pmcgowan> and the indicator fix is tagged to land
<Mirv> pmcgowan: sounds good. I finished with my AP + exploratory testing so I'll put the silo towards QA then
<popey> brilliant \o/
<pmcgowan> Mirv, my only hesitation is its a complete qt update for the one patch I suppose
<popey> pmcgowan: how about the eds fix bfiller landed in vivid?
<pmcgowan> and krillin not crashing
<pmcgowan> popey, which is that?
<popey> (would make calendar 10x better experience)
<popey> pmcgowan: https://code.launchpad.net/~renatofilho/qtorganizer5-eds/fix-1423185/+merge/252184
<Mirv> pmcgowan: qtdeclarative module rebuild, not others. but yes, it's one of the bigger modules. no reason why build result on rtm should differ though from the previous build other than this patch affecting pixmap handling.
<pmcgowan> Mirv, ack, my thinking was if it were to occur on krillin it would be REALY bad
<pmcgowan> popey, that seems worthy of a fix
<popey> pmcgowan: anything I need to do, or just poke bfiller nicely? :)
<pmcgowan> popey, I just poked him for his view, depends on frquency, does that happen all the time-ish?
<pmcgowan> considering calendar not quite prime time yet
<popey> pmcgowan: very easily reproducible, and with that fix it's night and day
<Mirv> pmcgowan: it seems it's luck if the crash doesn't happen on krillin so far. I added some details for QA to evaluate it now, including the debdiff (http://paste.ubuntu.com/10660930/)
<pmcgowan> Mirv, ack thanks
<pmcgowan> popey, then I am ok to land it, just a few lines
<popey> thank you
<pmcgowan> popey, that indicator fix is in silo 4 a long time, need qa to test
<popey> ah, okay. jibel ^^
<pmcgowan> popey, oh trello says it passed
<pmcgowan> popey, scratch that, that was not rtm
<pmcgowan> it needs to get in the queue
<popey> yeah it was passed in vivid
<rvr> didrocks: If you think that booting fine is enough, I'll sign off your silo right away ;)
<didrocks> rvr: it is for this change :)
<didrocks> just some binaries changing between packages
<didrocks> moving*
<rvr> didrocks: Done!
<didrocks> rvr: thanks :)
<jibel> popey, the card was missing from our board. I added it manually and will find someone to test it asap
<popey> thanks jibel !
<davmor2> didrocks: jibel: http://paste.ubuntu.com/10661235/ and root         1  2.4  0.2   3764  2288 ?        Ss   14:19   0:03 /sbin/init as a confirmation to rvr :)
<didrocks> thanks guys :)
<balloons> cihelp, I need an app added to core apps jenkins. I'd like jenkins to run on lp:help-app now.
<psivaa_> balloons: ack, will handle that and get back to you
<balloons> psivaa_, thanks, let me know if you need help. You should be able to clone something like all the clock app jobs for it. I added jenkins bot to the developers of the app, so it should be all ready to go
<psivaa_> balloons: ack, thanks
<psivaa_> balloons: do you need 'D09add_ppa~ubuntu-touch-coreapps-drivers~daily' hook too for this?
<balloons> psivaa_, yes
<psivaa_> i'm not sure what that hook does
<psivaa_> balloons: ack
<balloons> psivaa_, it adds the core apps ppa, which is needed in this case
<psivaa_> balloons: I could not see any tests directory, does this have a test-suite name?
<balloons> psivaa_, ohh right. It's not going to have the tests/autopilot structure of before. It does have tests, let me find the direcotyr
<psivaa_> some are in internals/
<balloons> psivaa_, though to be fair, you shouldn't have to care I suppose at first
<balloons> they will run as part of the build
<psivaa_> balloons: ack
<balloons> if we add something to tests/autopilot later it should all just work still right?
<psivaa_> i guess that should
<balloons> ok, so sounds like we are fine then?
<psivaa_> fginther: ^ in this case with no tests dir, what would be the testsuite-name in the cupstream2distro-config?
<psivaa_> fginther: 'test_suite:' in the config
<psivaa_> balloons: let me confirm
<elopio> ping cihelp: do you have an ETA for this bug? https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-snapshot/+bug/1389729
<ubot5> Ubuntu bug 1389729 in llvm-toolchain-snapshot (Ubuntu) "LLVM ERROR: Cannot select: intrinsic %llvm.x86.sse41.pblendvb" [Undecided,Confirmed]
<elopio> or maybe a workaround?
<elopio> it's affecting this execution: http://91.189.93.70:8080/job/reminders-app-vivid-amd64-ci/151/console
<psivaa_> elopio: we all are in a meeting, will come back to you once that's over
<elopio> thanks psivaa_.
<elopio> mzanetti: ^
 * mzanetti reading
<mzanetti> ack. thanks elopio
<cyphermox> barry: I'll take care of it ^
<barry> cyphermox: thanks
<cwayne> davmor2, ello, think you'll have time for a custom test this week?
<davmor2> cwayne: add it to the spreadsheet
<davmor2> cwayne: oh wait for vivid or rtm
<cwayne> davmor2, rtm
<balloons> psivaa_, so what's the verdict on the help app?
<sil2100> cyphermox, barry: I leave the train in your hands now :)
<psivaa_> balloons: help-app is now in the core app jenkins. could you check please
<balloons> psivaa_, awesome, checking
<sil2100> THanks guys o/
<balloons> psivaa_, the bot definitely picked things up and ran, and I just triggered a build too
<balloons> So build issues, but presumably nothing wrong with jenkins. I'll assume it's all good and work on the build. Thanks!
<psivaa_> balloons: ack, thanks
<psivaa_> elopio: regarding your ping about https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-snapshot/+bug/1389729, we dont have any workaround at the moment, and finding a fixer for the bug is proving difficult. reminders app CI is impacted by this and need to be handled mannually i suppose
<ubot5> Ubuntu bug 1389729 in llvm-toolchain-snapshot (Ubuntu) "LLVM ERROR: Cannot select: intrinsic %llvm.x86.sse41.pblendvb" [Undecided,Confirmed]
<rsalveti> robru: next image might be busted
<rsalveti> robru: dist-upgrade and my phone fails to boot
<robru> rsalveti: oh hey. I'm off this week ;-)
<rsalveti> alright :-)
<cyphermox> duly noted.
#ubuntu-ci-eng 2015-03-24
<imgbot> === IMAGE 146 building (started: 20150324-02:05) ===
<imgbot> === IMAGE 146 DONE (finished: 20150324-03:30) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/146.changes ===
<Mirv> btw all testing about #146 boot problems welcome, since my device is stuck running autopilot tests on #145
<bzoltan_> Mirv:  I could use a vivid silo for the UITK
<Mirv> bzoltan_: 012. conflicts with Saviq's/mzanetti's 015 but I guess the DPR is not yet landing
<ogra_> oh, since i got two Qt experts here ....
<ogra_> Mirv, bzoltan_, why doesnt this work: http://paste.ubuntu.com/10667273/
<ogra_> looks like a bug to me
<ogra_> (note that ricmm ponted me to ted, who pointed me to the sdk :) )
<Mirv> "I just package it" :D
<Mirv> ogra_: try asking on #ubuntu-app-devel
<ogra_> hardcoding the application name works fine
<Mirv> where also the rest of the SDK team is on besides zoltan
<Mirv> maybe it is a bug, but where
<sil2100> Morning
<sil2100> I seem to have a power outage at home
<sil2100> The power company mentioned it might take a few hours
<sil2100> Im on 3G right now
<Mirv> sil2100: :(
<Mirv> hangouts over 3G is doable, but hangouts might eat all the battery power..
<Mirv> and morning
<sil2100> And my data packet!
<sil2100> Since I dont have unlimited internet, geh
<sil2100> Mirv: for now please take care of teh train
<sil2100> Ill jump out and try finding a place for hangouts, but if not, I wont be able to make it
<sil2100> Leaving my irc session on this host though
<Mirv> sil2100: sure, teh train will be in good hands
<ogra_> imgbot, status 146 vivid
<imgbot> Status: succeeded, Started: 2015-03-24 02:02:04 UTC, Finished: 2015-03-24 02:57:56 UTC
<imgbot> Build URL: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/+build/23282
<imgbot> Changelog: http://people.canonical.com/~ogra/touch-image-stats/146.changes
<Mirv> ...whether it boots or not remains to be verified
<Mirv> if anyone can flash, please do. my device is stuck in AP duties.
<ogra_> well, it is the only one that built tonight ... all other flavours failed
<ogra_> i needed the build log :)
<sil2100> Trying to log into the ho
<sil2100> Can anyone give me the hangout link?
<ogra_> https://plus.google.com/hangouts/_/canonical.com/landing-meeting
<sil2100> Thanks
<Mirv> davmor2: as soon as the new XPS 13 is available :)
<Mirv> ie as soon as the remaining bugs are fixed... which they should be now, about
<Mirv> so hopefully April
<sil2100> Damn, not sure what they're blocking on this wifi, but damn
<bzoltan_> Mirv:  thanks for your kind assistance, I have just added the gles branch to the landing line. I wonder if my "reconfigure" worked ... if not, would you mind to reconf the silo12?
<mzanetti> trainguards: please reconfig silo 15 for me (I've added ubuntu-settings-components)
<bzoltan_> trainguards: ^^ same for silo 12 please too
<Mirv> eating, but booting up my mini laptop...
<Mirv> just a moment
<Mirv> bzoltan_: mzanetti: both done, in theory. "success" but "error". please ping sil2100 with https://ci-train.ubuntu.com/job/prepare-silo/4441/console + https://ci-train.ubuntu.com/job/prepare-silo/4442/console if it doesn't wor for you
 * Mirv resumes eating
<sil2100> huh
<sil2100> Success with error, love that
<Mirv> sil2100: I'm getting that "ERROR Silo config file changed out from under us!" on all reconfigs
<Mirv> and to me it'd look like that indeed also bzoltan_'s and mzanetti's silos were not really reconfigured because of that
<mzanetti> Mirv, yap, not actually reconfigured
<sil2100> Looking into that now
<sil2100> Home still has no power though...
<sil2100> hmm
<ogra_> Mirv, just FYI, latest image boots fine for me on arale
<ogra_> it triggered an apparmor cache rebuild though ... took quite a while to come up
<Mirv> great
<sil2100> Mirv: hm, there might be indeed a train issue right now
<sil2100> Without power and inrernet debugging is slow, but I'm getting there
<sil2100> Mirv: can you retry reconfiguring silo 12 for me?
<Mirv> sil2100: ok. with Atom processor it's slow for me too, but no problem :)
<Mirv> (I stuck at the lunch place since things to do kept coming)
<sil2100> No worries, thanks! ;)
<Mirv> 1.83GHz of sheer processing power
<Mirv> ...equal to PIII 900MHz or so
<davmor2> Mirv: just but a new laptop already ;)
<Mirv> davmor2: I _can't_ buy last year's model when the new one is almost within my reach if I hold my breathe :)
<sil2100> jibel, davmor2: were you able to double confirm the issues with first boot unity8 greeter missing?
<Mirv> sil2100: train is still being coward https://ci-train.ubuntu.com/job/prepare-silo/4445/console
<davmor2> sil2100: no
<davmor2> Mirv: don't do that you'll die before it's really you need air
<davmor2> s/really/ready
<sil2100> Mirv: hm hm, looking deeper, but looks like the new train code has some race and something somewhere touches the config inbetween the start of the job and the final check
<Mirv> davmor2: the shipping date is sooo close I just might be able to do it!
<Mirv> or I could settle for Precision M3800 Developer Edition shipping already now but it's a bit overkill and not so suitable for traveling (even though the 1.8kg is impressive for what it delivers)
<Mirv> sil2100: yeah, I wonder if no-one reconfigured anything yesterday and it wasn't found therefore earlier
<Mirv> sil2100: are the current steps to deploy an older version documented somewhere?
<Mirv> with robert away this week we might need to consider reverting if there are problems
<sil2100> hm, I think we had some documentation for that
<sil2100> I just hope publishing works
<sil2100> Mirv: want me to handle that ^? ;)
<Mirv> it does
<Mirv> sil2100: I'm already pressing the Publish button.. unless you want it? :) but I published two rtm silos earlier today just fine
<sil2100> Publish publish ;)
<sil2100> Thanks
<Mirv> looks like vivid publishing also works
 * sil2100 saves his precious packets
<Mirv> as does building and assigning silos
<Mirv> only reconfiguring is a problem
<Mirv> so... we can reconfigure by assigning a new silo and deleting the old one ;)
 * Mirv walks back to a faster machine
<sil2100> hah, nce workaround ;) Problem is that then the silo state is lost and everything needs to be rebuolt
<sil2100> I'll try reverting the train once I have my power back
* sil2100 changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: robru is on vacation! CI Train has issues with silo reconfs, issue investigated
<sil2100> It's 13 here already, I should have my power back on but it's still not
<sil2100> Let me publish silo 13
<Mirv> sil2100: too late :)
<sil2100> Awww, with this internet I'm too slow ;)
<sil2100> Power is back, yeah
<sil2100> Let me try getting the train back to shape
<jibel> sil2100, nuclearbob confirmed the black screen issue. It happens often on reboot since yesterday
<sil2100> jibel: on reboot even? Crap
<sil2100> That's a big blocker then
<sil2100> (IMO)
<sil2100> Mirv: found the issue... it seems after Robert's changes, reconfigures are broken in overall
<sil2100> Mirv: since they're impossible to work in the current state of the code
 * sil2100 tries to fix
<sil2100> Mirv: I would normally opt for a revert, but not sure if the new code didn't introduce some changes in the config files
<sil2100> And I don't want to break everything (tm)
<Mirv> right
 * sil2100 wonders why normal silo assignments worked though
<bzoltan_> Mirv: sil2100: I missed about 2 hours. Is there any news about the silo reconfigurations?
<Mirv> bzoltan_: just the above, sil is looking into the brokennes. we could assign a new silo and delete old one if in a hurry.
<bzoltan_> Mirv:  far from hurry ... I can test the silo during the night without the gles packages
<Mirv> true
<sil2100> Ah, I see why normal assignments work, yeah
<sil2100> Fix is on the ways
<sil2100> *way
<balloons> cihelp, I need a parameter adjusted on a jenkins job for the help app
<plars> balloons: what needs changing?
<balloons> plars, can you swap the pyflakes parm to pyflakes3?
<plars> balloons: sure, will do
<sil2100> Mirv, bzoltan_: waiting for CI to check the branch, then I merge and try redeploying the fix
<Mirv> \o/
<bzoltan_> sil2100: thanks mate, you rock as always
<mzanetti> sil2100, not sure about the status on that issue, just wanted to make sure you don't forget about the reconfig vivid/15 when it's resolved :)
<sil2100> mzanetti: ACK :)
<mzanetti> thanks :)
<rvr> oSoMoN: Silo 8 is approved.
<rvr> sil2100: ^^
<rvr> sil2100: You can respin the new image when you want :)
<oSoMoN> rvr, awesome, thanks!
<Mirv> ogra_: ack oxide version bumps? https://ci-train.ubuntu.com/job/ubuntu-landing-008-2-publish/lastSuccessfulBuild/artifact/webbrowser-app_packaging_changes.diff ^
<sil2100> \o/
<sil2100> Once webbrowser migrates, let's have a new image
<sil2100> On the other hand...
<sil2100> There's that serious regression anyway
<sil2100> So not sure if it makes sense, hm
<sil2100> jibel: do you guys know which component can be responsible for the black screen issue?
<jibel> sil2100, no
<jibel> sil2100, nuclearbob filed bug 1435871
<ubot5> bug 1421009 in qtbase-opensource-src (Ubuntu) "duplicate for #1435871 unity8 sometimes hangs on boot" [Undecided,In progress] https://launchpad.net/bugs/1421009
<jibel> ah it's duplicated already
<sil2100> Oh
<jibel> 'undecided' looks inappropriate
<oSoMoN> ogra_, hey, I need a core-dev ack for trivial packaging changes in silo 8: https://ci-train.ubuntu.com/job/ubuntu-landing-008-2-publish/89/artifact/webbrowser-app_packaging_changes.diff
<sil2100> Mirv: keep us updated on this bug please ;)
<Mirv> sil2100: yep, the current patches regressed autopilot tests and now albert gave me two more to try which are building now. although I wonder if libusermetrics should be added to the bug too since it appeared with an update of that, even if it triggers some old Qt bug.
<ogra_> oSoMoN, Mirv ACK
<Mirv> acketi ack
<Mirv> sil2100: added autopilot and libusermetrics to the bugreport with "Incomplete" since the former may be affected and the latter apparently triggered the bug even if technically didn't do anything wrong
<oSoMoN> ogra_, Mirv: thanks!
<Mirv> sil2100: oSoMoN ^ oh right.. Final beta freeze until Thursday evening :(
<oSoMoN> yeah, no worries, at this point itâs not really that urgent
<sil2100> hmmm
<sil2100> Yeah
<Mirv> sil2100: I'm again at https://ci-train.ubuntu.com/job/ubuntu-landing-018-1-build/122/console ... train digging the older version, seeing it's built and continuing without waiting.. I've tried build, build with specifying packages and build with specifying packages + force
<Mirv> hmm, was it watch_only then plus specifying packages that was needed..
<sil2100> hm
<balloons> plars, how's the change look?
<plars> balloons: I had to rerun it, just checked and it's merged now
<plars> balloons: Can you give it a try or do I need to restart a job for you?
<plars> balloons: I'll be curious to see if it does what you need
<bregma> trainguards, reconfiguring my silo always fails claiming its PPA has changed underneath it... am I doing something wrong or is it a known bug?
<bregma> (line 46, silo 29)
<sil2100> bregma: yeah, please see the topic ;)
<sil2100> bregma: the fix is ready but I'm witingn for webops to actually deploy that for us
<sil2100> Since we can't redeploy oursleves
<sil2100> *ourselves
<balloons> plars, yes i'll check ty
<sil2100> ogra_: anything against building a new vivid image now?
<ogra_> no, go ahead
<sil2100> Actually, wait, unity8 still didn't migrate
<sil2100> Argh, boottest regression
<sil2100> Saviq: ^
<sil2100> Saviq: so, unity8 fails to migrate due to a boottest failure: https://jenkins.qa.ubuntu.com/job/vivid-boottest-unity8/lastBuild/console
<sil2100> Not sure what's wrong, the log looks a bit bloated
<sil2100> cihelp: can you guys help me interpret the above boottest failure? ^
<fginther> sil2100, there's evidence of a race condition with apt here, I've restarted the test
<sil2100> fginther: thanks, fingers crossed it'll pass now :)
<fginther> "E: Unable to lock directory /var/lib/apt/lists/"
<sil2100> jibel, davmor2, rvr, popey: since robru is on holidays and there's not much to report (I suppose), let's skip today's evening meeting
<sil2100> We might do that for most of the week
<sil2100> If, of course, there's nothing urgent
<jibel> sil2100, works for me
<jibel> sil2100, only thing urgent is to build a new image :)
<sil2100> The vivid image I'll be kicking as soon as unity8 migrates
<jibel> ok
<sil2100> Since it was blocked on boottesting, maybe now it'll pass
<sil2100> bregma, Mirv, bzoltan_, mzanetti: I filled in the RT and poked webops, I hope they'll redeploy it soon
<sil2100> bregma, Mirv, bzoltan_, mzanetti: regarding the CI Train issues with reconfigure
<davmor2> sil2100: powermongery has gone to your head, I should never of made you admin ;)
<sil2100> davmor2: muhahaha
<sil2100> camako: hey! There might be a problem with releasing the new mir as we're in beta freeze, and I think mir is somehow partially seeded on the desktop
<camako> sil2100, I thought we were stabilizing vivid for the rtm sync.. How much longer does the freeze continue?
<sil2100> camako: we are, but the beta freeze means that there's a hard lock on the archive and things like mir can get pushed to unapproved automatically
<sil2100> Then we'll have to poke the archive admins
<camako> sil2100, so I'm confused. How are we stabilizing if we can't land? Is this only for a day or two or until Vivid is released (late April)?
<sil2100> bregma: you should be able to reconfigure now
<ogra_> camako, the beta freeze lasts til the beta image is fully tested
* sil2100 changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: robru is on vacation!
<cjwatson> sil2100: s/archive admins/release team/
 * bregma gives reconfiguration a go
<sil2100> camako: we can't do much against archive related procedures
<balloons> plars, is the parms line the same? B10pyflakes?
<ogra_> it is in place to make sure the image content cant change ... something that touch catches on the silo level ... distro can only do it by freezing the whole archive
<cjwatson> camako: it doesn't mean you can't land, it means landings require additional manual approval to make sure they don't disrupt image preparations
<cjwatson> camako: describing it as "can't land" is a gross mischaracterisation
<mzanetti> sil2100, ok, thanks!
<sil2100> mzanetti: should be reconfigured :)
<camako> sil2100, cjwatson... sorry on a hangout atm.. Will resume discussion in a bit
<sil2100> jibel: unity8 boottesting passed o/
 * sil2100 waits for the next migration
<sil2100> unity8 migrated, let me kick the new image
<imgbot> === IMAGE 147 building (started: 20150324-16:25) ===
<dbarth_> o/ hey trainguards, can i have a silo on line 62 ?
<sil2100> dbarth_: sure
<sil2100> dbarth_: for rtm?
<dbarth_> sil2100: yes, please
<dbarth_> (sorry forgot about the target release column)
<balloons> plars, things are still failing; and I don't see the default parms changed at all
<pmcgowan> sil2100, jibel we should hold off the vivid regression ass until we figure out the multiple audio issues in the latest images
<pmcgowan> pass not ass
<plars> balloons: do you happen to have a link, I'll take a look. Probably the jobs need to be redeployed
<balloons> plars, 91.189.93.70:8080/job/help-app-ci
<imgbot> === IMAGE 147 DONE (finished: 20150324-17:55) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/147.changes ===
<rvr> mandel: I'm testing silo 0 for rtm (ciborium). pot file needs update, because "Unmounting" is marked for translations, but is not available in Launchpad.
<rvr> [mandel] idle 125:43:47 ... I guess he's on holidays.
<rsalveti> rvr: nops, he's around
<rvr> rsalveti: mandel: As you can see, silo 0 was approved.
<rsalveti> rvr: great, thanks
<camako> sil2100, cjwatson, so last comment was we can land on vivid. What are the caveats? Do we need to ask anyone for permission etc?
<veebers> trainguards, ping can I get 004 published please? :-)
<pmcgowan> rsalveti, sil2100 are we not doing rtm proposed builds?
<rsalveti> pmcgowan: not by default, no
<pmcgowan> rsalveti, how come?
<rsalveti> pmcgowan: disabled in cron-job to avoid having images without any changes
<rsalveti> pmcgowan: we can enable cron anytime, or just build new images when we land new changes
<pmcgowan> rsalveti, we should kick some as there have been a number of landings
<rsalveti> sure, will do
<pmcgowan> was waiting for them
<pmcgowan> thanks
<rsalveti> robru: can you help me with https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-000-2-publish/32/console ?
<rsalveti> this was a job that got build via a sync
<elopio> rsalveti: on the topic it says that robry is on vacation.
<rsalveti> crap, indeed
<rsalveti> maybe cyphermox can help me with that then
<rsalveti> cyphermox: trying to publish silo 000/rtm https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-000-2-publish/32/console
<cyphermox> hum, why is it 000?
<cyphermox> I thought that one was meant for testing and all
<rsalveti> cyphermox: nops, it's a valid silo
<cyphermox> I see
<cyphermox> rsalveti: did you change anything in the silo config since you first requested it?
<rsalveti> cyphermox: nops
<cyphermox> I'm trying to know why it would be acting this way
<AlbertA> cihelp: it looks like mir amd64 builds done in cloud-worker-15 always time out, for example: https://jenkins.qa.ubuntu.com/job/mir-vivid-amd64-ci/1337/consoleFull
<AlbertA> cihelp: any ideas?
<cyphermox> rsalveti: clearly, this is broke
<cyphermox> thar.
<cyphermox> I fudged it to agree to publish
<thomi> AlbertA: I'll take a look
<veebers> cyphermox: hey, are you able to publish silo 004? :-)
<cyphermox> veebers: what kind of silo?
<veebers> cyphermox: bugfix for autopilot
<cyphermox> no, I mean is that a rtm silo or what?
<veebers> cyphermox: oh sorry, vivid
<veebers> ugh, fixing that now
<veebers> cyphermox: sorry about that, the MP has been fixed so it can be published again
<robru> cyphermox: rsalveti: reviewing the logs, it always as though mandel attempted a new sync which cleared the local silo state, but failed because the sync source had freed. Then your attempts at builds were just watch-only's which doesn't have enough teeth to regenerate the needed state.
<robru> cyphermox: rsalveti not sure why the build by mandel didn't fall back to distro, that's a feature that is supposed to exist, please file a bug against lp:cupstream2distro and I'll fix it next week when I'm back
<robru> "It appears as though" stupid swype.
<robru> cyphermox: rsalveti anyway this is the culprit: https://ci-train.ubuntu.com/view/1.%20Build/job/ubuntu-rtm-landing-000-1-build/153/console that's definitely a bug, it should sync from distro if the source silo has freed
 * robru back to vacation ;-)
<veebers> cyphermox/trainguards any idea on who can do that (or what to do here) we had barry ack the package changes in the merge to trunk MP
<rsalveti> robru: great
<sil2100> robru: thanks for the investigation, I'll try to look at it tomorrow then ;)
<cyphermox> veebers: I will, I was busy fixing dinner :)
<cyphermox> oh crap
<veebers> cyphermox: ah cool, sorry to be impatient :-)
<cyphermox> hm, did you have a freeze exception for this?
<veebers> No we didn't. I was told (by robru) that as it was a bug fix for autopilot it was required.
<cyphermox> ah, I see
<veebers> cyphermox: does this complicate things? (perhaps I messed up?)
<cyphermox> no, I had a moment of doubt, that's all
<veebers> ah ok, thanks for sorting this cyphermox :-) I hope you get to enjoy your dinner soon!
<cyphermox> ahaha already done
<cyphermox> we were tired so I threw together some pasta with a bottled sauce :P
<cjwatson> camako: if you're adding features, you should follow https://wiki.ubuntu.com/FreezeExceptionProcess; otherwise, uploads will be automatically held for approval and the release team notified, though you can ask on #ubuntu-release if you need to have something expedited
<cjwatson> camako: (speaking as an ex-release-team-member)
<sil2100> o/
<veebers> cyphermox: heh, sounds more interesting than the brown rice and chicken breast I've been boring myself with recently :-)
<cyphermox> I was supposed to make some chili with the slow cooker but I was so busy I forgot to get started early enough for food to be ready on time
<veebers> oh man, I totally want to get into using a slow cooker. Especially now that the season is cooling down
<veebers> cyphermox: hey I see that the autopilot package is in the unapproved queue in #u-release, what needs to happen next?
<cyphermox> probably wait until after beta is released to be let in, or you may ask in #u-release for it to be allowed in
<veebers> cool thanks, I'll ask and see what happens :-)
<cjwatson> (FYI autopilot was auto-accepted and didn't need manual interaction)
<cyphermox> cool, thanks for letting us know
<camako> cjwatson, thanks. We are not adding features. This is strictly a bug fix release.
<cjwatson> camako: yeah, don't tell me though, I'm ex-release-team :)
<cjwatson> camako: in that case, just land and then ask the release team to review (or wait for them to get round to it in their queue)
<cjwatson> camako: it may have to wait until after beta in any event, but that's only a couple of days
#ubuntu-ci-eng 2015-03-25
<cyphermox> camako: no worries, it's really that I got confused for a bit and worried I had approved this a little too quickly
 * Mirv notices both GTK3 and GTK2 on our Qt phone and wonders
<seb128> sil2100, Mirv, I do ack the 29 packaging changes just mentioned there ^
<seb128> Mirv, none is easy to drop
<seb128> Mirv, libqt5gui5 depends on gtk2 for some reason, I guess theming/integration?
<seb128> gtk3 is coming from e-d-s
<seb128> libaccount-plugin-1.0-0 as well
<Mirv> seb128: yeah the gtk2 theme plugin could be separated to its own package. yes, I'm looking at those at the moment and updating bug #1436211 as I go.
<ubot5> bug 1436211 in ubuntu-touch-meta (Ubuntu) "Remove GTK3 from phone images" [Undecided,New] https://launchpad.net/bugs/1436211
<seb128> Mirv, I can look at gtk3 if you want, that bug is missassigned btw, that's not a seed issue
<Mirv> seb128: it's not, I just assigned it as a "generic touch image related thing"
<Mirv> seb128: ok I'm done with the bug. it'd look like a long term thing to me but maybe one piece at a time it'd be possible to get closer to the goal.
<Mirv> adwaita-icon-theme, libtimezonemap1..
<Mirv> I'll file another bug against qtbase to separate the GTK plugin. I was actually inspired by a Linaro guy who mentioned in passing that Qt 5 depends on GTK2 which holds him from removing GTK2 on desktop...
<Mirv> he's filing the Debian bug so I can follow up what Lisandro & co think about it
<seb128> cool
<Mirv> oh, and thanks for the packaging ack
<seb128> yw
<seb128> Mirv, I'm unsure why e.g libaccount-plugin-google is installed
<seb128> we install account-plugin-google
<seb128> which
<seb128> Depends: libaccount-plugin-google | ubuntu-system-settings-online-accounts
<seb128> or we install u-s-s-o-a
<seb128> which should be good enough?
<seb128> ogra_, ^ do you know why?
<seb128> sil2100, Mirv, 17 should be ok to land as well btw
<ogra_> seb128, thats only good enough if ubuntu-system-settings-online-accounts is seeded or otherwise installed before the dep is looked for
<seb128> ogra_, it seems seeded?
<ogra_> imgbot, status 147 vivid
<imgbot> Status: succeeded, Started: 2015-03-24 16:23:18 UTC, Finished: 2015-03-24 17:21:12 UTC
<imgbot> Build URL: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/+build/23346
<imgbot> Changelog: http://people.canonical.com/~ogra/touch-image-stats/147.changes
<ogra_> lets look at the build log then :)
<sil2100> Oh
<sil2100> imgbot returns the build urls now?
<ogra_> seb128, in tasks the "or" deps are resolved in opposite order, might be thats the issue here
<ogra_> sil2100, since it knows the status command :)
<sil2100> Oh my ;)
<seb128> ogra_, hum, unsure what we need to change then?
<ogra_> cjwatson yesterday showed me the json api for livefs builds that i hadnt seen before ... i think i'll port imgbot to use that in the future
<sil2100> Unapproved merges, but I'm sure Laney know's what he's doing
 * sil2100 forces
<ogra_> seb128, switching the order in the deps of the package
<seb128> ogra_, would that bring the touch stuff on desktop (e.g just inverse the issue)?
<seb128> sil2100, oh, I can approve the merges
<seb128> sil2100, just let me know which ones
<sil2100> seb128: they're merged already :)
<ogra_> i dont know ... but if it really is that, you might just reverse the problem yeah
<seb128> sil2100, great ;-)
<seb128> ogra_, that seems weird though, alternative depends should work and not pull new thing in if the alternative is seeded
<ogra_> well, that is the reason why you can end up with different package sets installed depending if you install a task or a matepackage qith apt
<ogra_> *with
<ogra_> *meta ...
<Mirv> we've had multiple of this a | b problems where either touch or desktop gets hurt
<ogra_> iirc one way to solve this is to use add_package in livecd-rootfs' live-build config to explicitly pull your dep in ...
<Mirv> luckily the signon-ui-x11 could be just removed from images which resolved the previous one
<ogra_>         ubuntu-touch)
<ogra_>                 add_package install ubuntu-minimal ubuntu-touch systemd-sysv- packagekit
<ogra_>                 COMPONENTS='main restricted universe'
<ogra_> i.e. like we force systemd-sysv removal in this line
<ogra_> and add packaekit
<ogra_> *package
<ogra_> that should satisfy the dep ahead of the seed
<seb128> can we add ubuntu-system-settings-online-accounts there and see if that makes some of the not-wanted binaries drop from the image?
<ogra_> seb128, yup
<seb128> ogra_, thanks
<ogra_> seb128, uploaded ... i'll do a build once it landed and we'll see if it helps, else i'll revert again
<seb128> ogra_, thanks!
<ogra_> seb128, oops, stuck in beta freeze i fear
<seb128> ogra_, yeah, let's see if someone let that through or not
<sil2100> ogra_: are daily vivid images disabled?
<ogra_> not that i know of
 * ogra_ checks crontab
<sil2100> I just noticed I don't see a changes file (so maybe it's not built) for this night's image
<ogra_> nope
<ogra_> oh, the bot had a hiccup ... let me check
<sil2100> Ah :)
<Mirv> so much spreadsheet to fix again..
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/148.changes
<seb128> hum
<seb128> where can I see what packages are on the bq stable 20 image?
<seb128> or what rtm-proposed image it corresponds to?
<ogra_> http://cdimage.ubuntu.com/ubuntu-touch/ubuntu-rtm/14.09/daily-preinstalled/20150324/ i think
<ogra_> http://system-image.ubuntu.com/ubuntu-touch/ubuntu-rtm/14.09/krillin/index.json has the mapping
<ogra_> hmm, image 20 actually had 20150312 for which cdimage doesnt have the log anymore
<cjwatson> I'm sure it has the log, but perhaps not the image.
<cjwatson> We don't delete logs.
<ogra_> cjwatson, sorry, i meant the manifest
<cjwatson> That'll be on LP.
<ogra_> (which we likely have on LP)
<ogra_> right
<cjwatson> s/likely/certainly/
<cjwatson> Follow links from http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-touch/ubuntu-rtm/14.09/daily-preinstalled-20150324.log
<ogra_> seb128, a quick and dirty shell hack to get the mapping: wget -O- -q http://system-image.ubuntu.com/ubuntu-touch/ubuntu-rtm/14.09/krillin/index.json|grep description|uniq
<cjwatson> Oh, rather 20150312
<ogra_> yeah :)
<cjwatson> So http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-touch/ubuntu-rtm/14.09/daily-preinstalled-20150312.log links to https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu-rtm/14.09/ubuntu-touch/+build/22403 for armhf and there you have a manifest
<ogra_> yeah
<bzoltan_> brendand: I have pushed an update to the UITK landing MR (silo12) the changes does not effect the test results
<ogra_> seb128, sorry, i was distracted by other stuff, so adam doesnt want to let the livecd-rootfs change in and wants us to check with germinate first ... i cant really find anything there
<ogra_> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-touch.vivid/touch definitely doesnt list anything with "libaccount" in the name
* fginther changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: robru is on vacation! s-jenkins build slaves are down
<Ursinha> fginther: you beat me to it
<fginther> Ursinha, sorry
* Ursinha changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: s-jenkins build slaves are down, your CI jobs might be affected -- being investigated by cihelp | robru is on vacation!
<Ursinha> fginther: no problem :)
<fginther> that one is better
<seb128> ogra_, thanks for the image info
<seb128> ogra_, hum, unsure what to do for the libaccount thing then...
<ogra_> yeah, he lets it in anyway now
<ogra_> (see -release)
<bfiller> sil2100: what's the syntax to sync something from vivid to rtm again?
<kgunn> trainguards hey there can someone delete platform-api package from vivid silo 0 ?
<sil2100> bfiller: hey
* Ursinha changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: s-jenkins build slaves (and apparently some other services) are down, your CI jobs might be affected -- being investigated and escalated by cihelp | robru is on vacation!
<Ursinha> robru: sorry for the highlights :P
<sil2100> bfiller: it's "sync:ubuntu,vivid package_names_here"
<bfiller> sil2100: thanks!
<Mirv> kgunn: sure
<sil2100> kgunn: on it
<sil2100> ...or not
<sil2100> ;)
<kgunn> thanks guys!
<Mirv> kgunn: done
<rvr> camako: Approving silo 13 (mir)
<camako> rvr thanks
<camako> trainguards, with the freeze in effect, how do we proceed now that silo 13 (Mir) is QA approved?
<sil2100> camako: hey
<sil2100> camako: we can publish it and then poke the release team for an approval
<sil2100> camako: it's a bugfix release, yes?
<camako> sil2100, hey. Yeah purely bugfix.
<camako> sil2100, thanks, lemme know if you need me to do anything
<sil2100> camako: then I'm sure we'll be able to get this approved, let me publish it and poke someone from release
<camako> sil2100 ok thanks
<camako> "mir is in the abyss"... good one
<sil2100> It's in the queue, time to do some poking
* Ursinha changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Infra outage caused CI/autolanding service to be interrupted, issue being investigated and restored as of now | robru is on vacation!
<cyphermox> sil2100: you tell me when you go for lunch or whatnot so I can pick things up while you're away?
<sil2100> cyphermox: sure
<sil2100> I should be around for the next 3-4 hours though
<cyphermox> ok
<ogra_> seb128, seems livecd-rootfs migrated now ... if sil2100 doesnt oppose i'll kick a vivid image
<seb128> ogra_, nice!
<ogra_> kicked
<sil2100> No opposition here
<imgbot> === IMAGE 149 building (started: 20150325-14:45) ===
<sil2100> o/
<sil2100> camako: anyway, the mir situation might be a bit more complicated - it might need to stay in the queue
<sil2100> As it's seeded in all desktop images
<camako> sil2100, ack...  curious... what seems to be the issue? Do I need to do anything?
<sil2100> camako: not much we can do, it's all up to the release team
<brendand_> ogra_, has there been a recent look at the packages getting seeded in vivid?
<brendand_> ogra_, i've just been trying to free some space by removing packages (don't ask) and seen a few things that seem superflouous
<ogra_> brendand_, what do you need to know ... there were no massive seed changed, but nobody did a specific audit or anything
<ogra_> *changes
 * brendand_ thought hud was removed...
<sil2100> brendand_: I think the seed was never updated to remove it
<sil2100> ogra_, davmor2, jibel, popey, rvr: we're skipping the evening meeting due to nothing to discuss, I suppose 1 update per day is more than enough
<popey> ok
<jibel> sil2100, +1 to cancel evening meetings
<ogra_> sil2100, fine with me
<davmor2> sil2100: sure
<rsalveti> would indeed be nice to do a bit of seeds cleanup
<ogra_> yep
<ogra_> rsalveti, i'll put a todo card for me on trello
<rsalveti> ogra_: great
<ogra_> done
<dbarth> o/ trainguards, i have a special request on line 61; to release the last stable update of oxide to RTM
<dbarth> it takes a ppa copy to rebuild the package; the FFE clearance is via https://bugs.launchpad.net/ubuntu/+source/oxide-qt/+bug/1425599/comments/2
<ubot5> Ubuntu bug 1425599 in oxide-qt (Ubuntu) "[FFE] oxide 1.5" [Undecided,Invalid]
<dbarth> let me know
<ogra_> FFe for RTM ?
<dbarth> ah no sorry, that's not even needed; 1.5.5 is already in the vivid image
<sil2100> dbarth: looking
<sil2100> dbarth: on it
<sil2100> dbarth: hm
<sil2100> dbarth: so it seems you have overwritten an existing landing (probably caused by some spreadsheet issues again)
<imgbot> === IMAGE 149 DONE (finished: 20150325-16:10) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/149.changes ===
<ogra_> seb128, ^^^
<ogra_> so it worked
<seb128> ogra_, \o/
<seb128> ogra_, danke
<ogra_> will the images still work though ? :)
<seb128> Mirv, ^ one step toward no gtk3 :-)
<seb128> ogra_, haha, that's a good question
<sil2100> dbarth: can you re-enter your request? Since now it's merged with custom tarball stuff
<dbarth> sil2100: ah, indeed; i took the first empty line i found; i will re-enter it
<sil2100> Thanks :)
<sil2100> The spreadsheet probably did something funny
<dbarth> sil2100: line 66; i will let you clean up 61 though
<sil2100> dbarth: no worries, thanks
<sil2100> dbarth: uh, the line 66 looks wrong :) Shouldn't it have oxide-qt in the source list?
<sil2100> dbarth: the testplan seems to be for the custom tarball as well
<sil2100> (or maybe just my spreadsheet is broken)
<dbarth> uh
<dbarth> sil2100: should be better now
<sil2100> dbarth: ok, this might take a moment for the copy to happen as I need to rewrite the version
<dbarth> sil2100: and the source copy will trigger a 4-6h build anyway :/
<sil2100> dbarth: actually, I'll do a source sync ;)
<sil2100> Since the same version is in vivid now, right?
<dobey> so, we can land stuff again tomorrow in vivid right? and will be able to for the next 3 weeks until final freeze?
<dobey> trainguards: ^^
<sil2100> dobey: touch components shouldn't be affected by the beta freeze anyway, what packages did you want to release?
<dobey> well, things that are on the main ubuntu and derived images, are affected by the freeze right?
* Ursinha changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: CI/autolanding service restored, ping cihelp if your jobs are acting weird | robru is on vacation!
<dobey> sil2100: i'm just trying to get a clear view in my head of what we can land, and how long until we can't land anything :)
<infinity> dobey: After tomorrow, things get slightly less frozen, yes.  The queue will still hold anything that's seeded in images (like mir), but the review process will be light for things that obviously have no real effect on the final release.
<infinity> dobey: And anything that isn't on images is sliding in already with no human intervention.
<dobey> right
<kgunn_> trainguards feel free to blow away and reclaim vivid silo 9...no longer needed
<dbarth> o/ trainguards, can i have a reconfig on silo 005 (vivid) ?
<sil2100> Hey!
<sil2100> kgunn_: what happened? ;)
<sil2100> dbarth: on it
<kgunn_> sil2100: oh , we consolidated into silo 0....so silo 9 just no longer needed
<sil2100> kgunn_: ACK
<sil2100> kgunn_: thanks for that :)
<dbarth> ty !
<rsalveti> cyphermox: sil2100: can you guys check the status of line 53
<rsalveti> it's tested and so on, but can't make the status to change to require QA
<sil2100> rsalveti: looking at it now
<sil2100> rsalveti: a formula in the spreadsheet got removed
<sil2100> It's on now
<rsalveti> sil2100: thanks
<rsalveti> awe_: urfkill will finally show up for QA now ^
<awe_> thanks, was this another instance of stuck spreadsheet, or did I miss a step?
<rsalveti> awe_: stuck spreadsheet
<awe_> k, thanks
#ubuntu-ci-eng 2015-03-26
<imgbot> === IMAGE 150 building (started: 20150326-02:10) ===
<imgbot> === IMAGE 150 DONE (finished: 20150326-03:30) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/150.changes ===
<abeato> ToyKeeper, ping
<ToyKeeper> Hi.
<abeato> hi, we have a pretty critical customer fix in line 69 of the spreadsheet
<ToyKeeper> abeato: It's for RTM?  I thought we weren't releasing any more RTM-based images?
<abeato> ToyKeeper, is QA aware of it? just want to be sure so you can assign right priority :)
<ToyKeeper> (then again, vivid is kind of broken today at the moment...)
<abeato> yes, RTM
<abeato> don't know, but taking into account that there are a couple of critical issues (like this one), maybe there will be another rtm ota
<ToyKeeper> abeato: I don't see it on QA's testing board...  which might mean the bot failed.
<ToyKeeper> If there are crits to fix though, we should clarify ASAP whether there's another RTM image coming or not.
<ToyKeeper> Is anyone awake yet who can confirm that?
<abeato> ToyKeeper, probably pcmgowan should now, but not awake yet :(
<abeato> ToyKeeper, just forwarded you an e-mail with some info
<ToyKeeper> abeato: I'm not sure what's required to be able to test the bug, if it's about supporting specific carriers.  Could you add bug links to the trello card and possibly more info about how to test it?  (or that the intent is to ensure nothing else broke, if it's not directly testable)
<ToyKeeper> abeato: https://trello.com/c/VqQFF5Mt/
<abeato> ToyKeeper, difficult to test without the specific SIM card that triggered the issue
<abeato> ToyKeeper, so testing should be essentially sanity testing
<abeato> I'll add a comment in the card
<ToyKeeper> For example, I can't test 3G on it at all, because the radio is incompatible in my area.  And it's not supported by default anyway, I have to use custom APNs (and even that doesn't get MMS working).  I assume it needs to be tested where cell data actually works?
<ToyKeeper> s/it's not supported/my carrier isn't supported/
<abeato> ToyKeeper, rightm that's the thing to test
<abeato> ToyKeeper, just having data, even 2G is enough to make sure the fix did not break data connectivity
<abeato> comment added in trello
<abeato> ToyKeeper, anyway if you feel you cannot test this well we can wait for another QA team member, as said I just wanted to make sure this bug was know and prioritized by QA
<ToyKeeper> For now, I'm trying to get data to work pre-silo to find out if I'm even able to start testing.
<ToyKeeper> *crickets* ... chirp, chirp ...  No data yet.
<abeato> ToyKeeper, so bad... btw, if we don't have your operator in the apn database, please open a bug in https://bugs.launchpad.net/ubuntu/+source/android with your operator's data, we are trying to improve the DB
<ToyKeeper> I saw this work a couple times, months ago...  but I'm having no luck today.
<abeato> no worries, we can wait for somebody else
<ToyKeeper> It worked on mako last I checked, but still needs custom APN data.
<abeato> ToyKeeper, the other bug that would definitely go in if there is a new rtm ota is bug #1427439
<ubot5> bug 1427439 in Canonical System Image "Urfkill saved wrong WWAN state after enabling/disabling flight mode" [Critical,In progress] https://launchpad.net/bugs/1427439
<abeato> ToyKeeper, there is already a card in Trello for that, landing-006
<Mirv> ToyKeeper: abeato: FYI there's been a bit too loud noise about "no more rtm-14.09", in reality there will be one more image so yes approved critical fixes should getin
<Mirv> and that mobile internet thing surely qualifies
<abeato> Mirv, ok, thanks for the confirmation
<Mirv> the noise has just been there since it's equally critical to fix vivid in shape :)
<ToyKeeper> I moved both silos to the top for priority, and I should be around long enough to make sure the rest of the team is aware of them.
<abeato> ToyKeeper, great, thanks!
<ToyKeeper> I might be able to do silo 6; just getting the details now.
<abeato> cool
 * ToyKeeper just now figures out that "FM" means "flight mode" and not "frequency modulation"
<Mirv> :)
<ToyKeeper> abeato: Bug #1427439 comment 9 has steps to reproduce the issue, but I haven't been able to get it to actually fail yet.  Also, I have no WWAN section in urfkill/saved-states.  Does this require cell data to trigger the bug?
<ubot5> bug 1427439 in Canonical System Image "Urfkill saved wrong WWAN state after enabling/disabling flight mode" [Critical,In progress] https://launchpad.net/bugs/1427439
<abeato> ToyKeeper, no, no need for cellular data
<abeato> ToyKeeper, but have you already installed the silo?
<ToyKeeper> abeato: No, I was trying to trigger the issue pre-silo.
<abeato> ToyKeeper, hmm, weird that you don't have WWAN, are you sure you are in rtm?
<abeato> ToyKeeper, please paste saved-states too
<ToyKeeper> Dammit, I forgot to press enter to confirm the reflashing, and was testing on vivid.  :(
<ToyKeeper> Thanks, I feel pretty dumb.  :)
<abeato> the fix already landed in vivid :)
<abeato> :)
<ToyKeeper> abeato: Okay, now that I've got my head screwed on straight, the issue and its fix are confirmed.  I'll let the rest of the team sanity-check it if they like, but otherwise it seems ready to go.  (and I'm heading off to sleep)
<abeato> ToyKeeper, take rest, thanks a lot
<davmor2> popey: jibel meeting?
<sil2100> jibel, popey: ping pong
<popey> yeah, browser problems
<jibel> sil2100, sorry lost track of time
<sil2100> jibel: actually, talking about vivid testing... recently I noticed that cups sometimes acts funny in the background and starts eating 100% CPU for no reason
<sil2100> Need to report a bug
<imgbot> === IMAGE RTM 258 building (started: 20150326-10:35) ===
<sil2100> rvr: ping :)
<rvr> sil2100: pong
<sil2100> rvr: hey, I've been wondering - once you have some free time, could you maybe test the glibc fix for the recent touch regressions?
<rvr> sil2100: Of course
<sil2100> rvr: maybe install the new glibc and perform sanity on the image
<rvr> That's important
<rvr> Using rsalvetti's PPA?
<sil2100> rvr: the fix is not in any silo, it's in a normal PPA - the details are in the e-mail that rsalveti sent out
<sil2100> Yeah
<rvr> Ack
<rvr> I'll do that
<ogra_> sil2100, no business IRC for you today ?
<sil2100> ogra_: oh carp
<rvr> sil2100: rsalveti said that the fix won't be ready until Friday/Saturday, though
<sil2100> rvr: he said it won't be landing till Friday/Saturday, I guess it's ready right now
<sil2100> It's just we can't land it because of the freeze
 * sil2100 reads up again
<rvr> Ahhh
<sil2100> rvr: yeah, so the fix is good, but we can't land it - but infinity already has it on his radar
<Mirv> today evening the freeze will lift
<rvr> Right, then it's a good idea to check it early
<rvr> rsalveti: I am sanity checking latest image with the PPA, don't land glibc before it is done, please :)
<sil2100> rvr: thanks :)
<imgbot> === IMAGE RTM 258 DONE (finished: 20150326-12:05) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/258.changes ===
<ogra_> wheee, langpacks !
<sil2100> Wow, much langpacks, such tzdata
<sil2100> Well, good to have that anyway
<ogra_> yep, someone asked on the ML i think
<davmor2> sil2100: I think it was me that said not much had changes right ;)
 * sil2100 off to lunch soon
<Mirv> sil2100: can I get an ack that line #71 doesn't need QA signoff? only debian/ changed, diff:s can be seen at dput ppa:ci-train-ppa-service/landing-020 ../qtsvg-opensource-src_5.5.0~alpha-0ubuntu1~vivid1~test1_source.changes
<Mirv> I've smoke-tested upgrading on device, though
<Mirv> s/whateverpasted/https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-028/+packages/
<Mirv> ok that was inproper sedding, s%whateverpasted%url%
<Mirv> the new SDK website needs the docs packages in archives apparently due to some prodstack autogeneration
<cyphermox> ^ will assign myself
<camako> sil2100, any word on Mir release?
<sil2100> camako: the freeze should be down later today or somewhere tomorrow, so I suppose it can migrate then
<sil2100> Mirv: sorry, just got back from lunch (started a bit later than expected) - ACK ;)
<camako> sil2100, thanks
<Mirv> sil2100: thanks!
<rvr> sil2100: I finished sanity testing the PPA
<rvr> sil2100: I have 4 failures of 42 tests (didn't check OTA upgrades/MMS).
<rvr> sil2100: The four are related to issues with location
<rvr> sil2100: I saw some crashes during the test, though. One was the clock, and the other two, mediascanner and sync-monitor
<sil2100> rvr: hm, thanks
<sil2100> I wonder if those are related to the glibc fix or if they're just in vivid vanilla as well - I suppose that's nothing new
<rvr> sil2100: Music plays fine, as per test descriptions
<sil2100> Since the fix shouldn't cause crashes I suppose
<nik90> rvr, sil2100: May I ask if this is regarding the SDK ppa?
<rvr> nik90: We are talking about rsalvetti's PPA to fix issue with libc
<nik90> rvr, sil2100: I can confirm that clock app crashes on vanilla vivid without the SDK silo-12 which is supposed to fix that
<rvr> sil2100: I suppose
<sil2100> nik90: it's a bit different, but related to all things vivid basically
<rvr> nik90: Ah, nice to know
<sil2100> Excellent
<sil2100> nik90: thanks for the info :)
<nik90> that's why i asked :)
<sil2100> rvr: then I suppose it's 'good to go' once the freeze is gone?
<rvr> sil2100: Strictly by the sanity test suite, everything except location is ok, so yes.
<sil2100> pmcgowan: ^ :)
<sil2100> pmcgowan: the glibc fix so far looks good, not sure if there's much more testing that QA could to to double-check if it's all good now
<pmcgowan> sil2100, thats good but the real goal is that it unblocks a full regression since it reverts what broke us
<pmcgowan> sil2100, do we know when it can land in the archive?
<sil2100> pmcgowan: we should be able to land again later today
<davmor2> sil2100: Cancel Monger
<sil2100> hah ;)
<sil2100> I'm giving everyone more time to do actual work!
<ogra_> sil2100, just FYI, as soon as the freeze is lifted (most likely in a few hours) i'll trigger a new image that will then pick up the new libc in the archive
<sil2100> ogra_: you mean, after it actually gets out of -proposed, right?
<ogra_> sil2100, which will happen automatically once the freeze is lifted ... it sits there since last night, so i think all atd runs are done by now
 * ogra_ hasnt checked but i simply assume it :)
<ogra_> adam said if there ios a re-spin for beta needed it will migrate anway
<ogra_> *is
<ogra_> and end up in the re-spun desktop images
<ogra_> so either way we should be ready this evening
<sil2100> Excellent
<ogra_> yeah, i'm happy i can listen to music again :)
<om26er> pmcgowan, I ran the testplan ok for ofono. while I'll keep the silo installed, my testing is done.
<pmcgowan> om26er, great thanks
<pmcgowan> om26er, silo 6 is another hot fix candidate
<popey> cihelp: can someone please help with https://code.launchpad.net/~mzanetti/reminders-app/qmltest2/+merge/253598 which is failing possibly due to bug 1389729
<ubot5> bug 1389729 in llvm-toolchain-snapshot (Ubuntu) "LLVM ERROR: Cannot select: intrinsic %llvm.x86.sse41.pblendvb" [Undecided,Confirmed] https://launchpad.net/bugs/1389729
<cprov> popey: looking
<om26er> pmcgowan, inprogress
<sil2100> o/
<popey> cprov: thanks
<rvr> alex-abreu: Silo 5 (twitter pics). Does it need an updated twitter webapp?
<alex-abreu> rvr, yup :)
<rvr> alex-abreu: Can you provide the click package?
<alex-abreu> rvr, it needs the one from the branch in comment
<om26er> abeato, Hi!
<abeato> om26er, hi
<alex-abreu> rvr, sure
<om26er> abeato, is this the only change[1] for silo 6 ? [1]http://bazaar.launchpad.net/~mariusko/urfkill/master/revision/531
<cprov> popey: apparently we can't do much about it.
<rvr> alex-abreu: Great!
<popey> cprov: it seems to be causing our qmltests to fail. Do you have another solution to enable the tests to run without crashing?
<abeato> om26er, hmm, no, not really, there are more things
<abeato> om26er, but the package is not really using bzr, afaik it is a direct dput
<om26er> abeato, does this[1] look right the correct diff ? [1]https://launchpadlibrarian.net/201123299/urfkill_0.6.0~20141020.151220.1dc6cf4~rtm-0ubuntu1_0.6.0~20150318.103828.5539c0d.1~rtm-0ubuntu1.diff.gz
<abeato> om26er, that's an old change
<abeato> om26er, that last one seems correct
<cprov> popey: there is more info on https://trello.com/c/2f8qfYun/87-vanguard-reminders-app-ci-failures-due-to-https-bugs-launchpad-net-ubuntu-source-llvm-toolchain-snapshot-bug-1389729, but nothing leading to a solution or workaround on our side.
<om26er> abeato, ok. I am finding a bit difficult to filter out exact steps to reproduce bug 1427439 could you help please ?
<ubot5> bug 1427439 in Canonical System Image "Urfkill saved wrong WWAN state after enabling/disabling flight mode" [Critical,In progress] https://launchpad.net/bugs/1427439
<alex-abreu> rvr, ok sent
<abeato> om26er, sure
<abeato> om26er, following the steps in comment 9 should nake it happen
<abeato> *make
<rvr> alex-abreu: Received, thanks
<om26er> abeato, oh, great. didn't look that far down the comments. thanks
<abeato> np
<bzoltan_> om26er:  do you or anybody else knows why the UITK in the silo12 is blocked?
<om26er> rvr, ^ do you know. I see you started testing it yesterday.
<rvr> bzoltan_: Vivid silos are blocked right now until libc lands.
<popey> cprov: ok, thank you
<ogra_> bzoltan_, we are in beta freeze, nothing lands atm
<ogra_> should be lifted soon though
<pmcgowan> ogra_, touch only stuff can land I am told
<ogra_> pmcgowan, and the UITK is touch only ?
<pmcgowan> hmm, it could be argued
<ogra_> heh
<pmcgowan> its not seeded in desktop
<ogra_> no, but it touches elements that also kubuntu uses i think
<pmcgowan> rvr, we are not blocked on libc per se
<pmcgowan> ogra_, shouldnt
<ogra_> we are not blocked on libc at all
<pmcgowan> right
<ogra_> except for the next image build
<ogra_> (which is why i didnt EOD yet... waiting for infinity to lift the embargo later today)
<ogra_> and technically we should just unleash the UITK silo and hold it on the proposed migration level instead ... but after all it doesnt matter much where it gets blocked
<sil2100> pmcgowan: well, from what seeded-in-ubuntu says it's seeded in desktop
<ogra_> s/should/could/
<sil2100> pmcgowan: I think webbrowser-app pulls it in
<ogra_> yeah, i thought so too
<pmcgowan> oh sure the runtime is
<pmcgowan> oh well
<sil2100> Anyway, we won't have to wait too long I suppose
<ogra_> yeah
<dbarth> o/ hi trainguards, can i get a silo for line 58 ?
<sil2100> dbarth: on it
<sil2100> dbarth: uh, no free silos
<sil2100> dbarth: once the archive opens up we should have a few free
<dbarth> sil2100: ah, too bad; i'll try to land 1-2 to make some room for tomorrow
<bzoltan_> ogra_:  pmcgowan: I think the UITK can be considered as desktop component... after all the QtC is using it :)
<sil2100> dbarth: great :)
<pmcgowan> bzoltan_, that to, so you are blocked :)
<rvr> dbarth: alex-abreu: Hi. About silo 5... Checking the diff, there are no tests for the new API.
<alex-abreu> rvr, I didn't backport the tests
<rvr> alex-abreu: Please, do, we cannot land it without tests.
<alex-abreu> rvr, ok
<nik90> bzoltan_: you just handcuffed yourself by admitting to that :P
<sil2100> cyphermox: I need to EOD now, will you take care of the train now? :)
<cyphermox> ack
<sil2100> (I published urfkill)
<sil2100> Thanks
<sil2100> o/
<bzoltan_> nik90:  I am an honest idiot ... that is what my wife keeps telling me too
<nik90> bzoltan_: lol ;-)
<pmcgowan> om26er, I think its safe to sign off on silo 1
<om26er> pmcgowan, approved.
<cyphermox> charles: you'll have to wait a bit it looks like all silos are busy
<charles> cyphermox, no worries
<cyphermox> (which should get fixed after the beta is released and the archive team reviews some of the stuff in the queue)
#ubuntu-ci-eng 2015-03-27
<Mirv> hmm, where's the image again, it would have included a lot of things
<Mirv> aha, it's there, just no bot updates
<Mirv> kalikiana: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-008 is ready for testing, please also smoke test on vivid device for example on today's #151 image
<Mirv> even though it's essentially a no-change rebuild
<kalikiana> Mirv: would md5sum match count as tested? :-P
<Mirv> kalikiana: nope!
<ogra_> imgbot, status 151 vivid
<imgbot> Status: succeeded, Started: 2015-03-27 02:02:06 UTC, Finished: 2015-03-27 03:01:25 UTC
<imgbot> Build URL: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/+build/23484
<imgbot> Changelog: http://people.canonical.com/~ogra/touch-image-stats/151.changes
<ogra_> oh, new mir
<sil2100_> It got approved after the freeze got lifted
<kalikiana> Mirv: seems to be fine, clock and such still work, data is there after closing
<Mirv> kalikiana: thanks. mako or krilling, and #151?
<kalikiana> Mirv: krillin. shall I also check mako?
<ogra_> "We're sorry!" ... "Do you want to tell Mozilla about this crash ?"
<ogra_> GRRRRRRRRRRRRRRR !!!!!!!!!!!
<sil2100> ogra_: no worries! We'll be waiting ;)
<ogra_> sil2100, well, after restart my browser cant open any page at all anymore
<kalikiana> ogra_: use the ubuntu browser ;-)
<ogra_> haha
<ogra_> i would if it would support WebRTC (or hangouts)
<Mirv> kalikiana: sorry hangout just started at that point. no, krillin is enough, thank you!
<kalikiana> okay
<Mirv> kalikiana: publishing
<sil2100> \o/
<Mirv> (documentation changes only if anyone raises eyebrows on non-signoff)
<kalikiana> abyss? does it usually say that?
<kalikiana> ^^ mhall119
<kalikiana> docs got landed
<Mirv> yes it does :)
<sil2100> hmmm
 * sil2100 is a bit worried about the new python-autopilot dep in UITK
<Mirv> oh, lukasz is on it already
<sil2100> Didn't we actually want to get rid of python 2 on the images?
<sil2100> python-autopilot is the legacy, py2 AP
<sil2100> bzoltan_: do you know why the python2 AP dependency has been added to UITK? Was that a change from elopio? ^
<bzoltan_> sil2100: it was zsombi_  or kalikiana
<Chipaca> sil2100: bzoltan_: Saviq: i want out of the canonical-qt5-edgers group; who wants to (or who do you think should) take over as owner?
<bzoltan_> Chipaca:  I can be that
<Chipaca> bzoltan_: done!
 * Chipaca deletes all the build failure spam email :)
<sil2100> zsombi_, kalikiana: hey
<kalikiana> sil2100: what's up
<sil2100> kalikiana: did you add the python-autopilot dep to the UITK landing in silo 12?
<kalikiana> sil2100: yes
<kalikiana> for building documentation it's needed
<kalikiana> sphinx that is
<sil2100> kalikiana: is that explicitly required? As it's the py2 autopilot package, while we generally want to get rid of python 2 stuff from the images
<bzoltan_> Chipaca:  sweet :)
<sil2100> kalikiana: python3-autopilot is the py3 version
<kalikiana> sil2100: oh, I didn't intentionally choose py2 here, sorry
<kalikiana> sil2100: we seem to use it, though, for our ap package, that's why I ended up using it
<kalikiana> as an aside, none of this affects the image
<kalikiana> sil2100: I'm guessing it would be a good idea to | our python deps then
<kalikiana> you can't build or install without py2
<kalikiana> brb
<sil2100> Yeah
<sil2100> ogra_: can you ACK https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/lastSuccessfulBuild/artifact/ubuntu-ui-toolkit_packaging_changes.diff ?
<ogra_> sil2100, NACK ... not until there is a line talking about the added dep in the changelog
<ogra_> bzoltan_, ^^^ please fix
<bzoltan_> ogra_: sil2100: OK, give me little time please
<sil2100> bzoltan_: no retest will be needed, just this changelog change :)
<ogra_> yeah
<Mirv> Chipaca: sil2100 bzoltan_: haha for getting out of canonical-qt5-edgers, you must be getting my Qt 5.5 test build problems to your inbox? :D
 * Mirv forces people to do better filtering by causing a zillion build failures
<Chipaca> Mirv: yes :)
<Chipaca> Mirv: and as it's something i have absolutely no control over, it only serves to make me unhappy :)
<Chipaca> :) <- no longer getting the emails
<sil2100> ;)
<john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20150326-f0c5ba5.tar.xz
<john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20150326-f0c5ba5.changes
<john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-testresults-20150326-f0c5ba5.ods
<john-mcaleely> New vivid device tarball for krillin
<john-mcaleely> sil2100, ^
<sil2100> \o/
<sil2100> john-mcaleely: rtm, right?
 * sil2100 preparing lunch now
<john-mcaleely> sil2100, that one is for vivid. rtm a bit later today
<sil2100> huh
<sil2100> WTH
<ogra_> busy day for QA it seems
<ogra_> :)
<ogra_> if it only told them *what* :)
<sil2100> http://i.imgur.com/XBGU5uB.jpg
<sil2100> ;)
<boiko> trainguards: I need a silo for testing and start working on changes for the upcoming telepathy-qt release, can I just provide a src deb, or do I need to create an MR against vivid's telepathy-qt5?
<sil2100> boiko: hey!
<boiko> sil2100: hi :)
<sil2100> boiko: I suppose it's all up to you :) I think an MR can potentially be better as you can then modify it and rebuild as you wish, while the src deb you'd need someone with silo PPA upload rights to reupload the new version
<boiko> sil2100: well, I would need someone with upload rights anyway, as telepathy-qt is not a canonical upstream package\
<mhall119> thanks kalikiana
<sil2100> boiko: yeah, I suppose just request a silo an we'll try to deal with that somehow :) Source is fine in this case
<boiko> sil2100: nice! thanks!
<rsalveti> yeah, get the src package ready in a silo, then we can get someone to sponsor that later
<Mirv> (the gles needs rebuild too, or would not really but bzoltan_ updated the branch)
<om26er> ralsina, Hi! How can I verify fix in bug 1390663 ?
<ubot5> bug 1390663 in Ubuntu Push Notifications "Push notifications never seem to arrive" [Critical,In progress] https://launchpad.net/bugs/1390663
<ralsina> checking...
<Chipaca> om26er: you remember that poorly defined bug that was kinda sorta worked around, that was hard to test for, and that i don't think you found our change improved it for you?
 * Chipaca is going to have om26er hate him
<om26er> Chipaca, I have a fuzzy memory
<om26er> Chipaca, what about that bug ?
<Chipaca> om26er: that's this bug that ralsina is shepherding
<Chipaca> om26er: so, without the fix, if you toggle the network on and off a lot, push gets stuck and you don't get messages
<Chipaca> om26er: with this fix, it should not happen (as much, at least)
<om26er> Chipaca, hmm, thats good to know
<Chipaca> that is, it shouldn't happen beyond network manager itself getting confused and not giving you a connection
<Mirv> popey: ^
* nik90 changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: https://bugs.launchpad.net/ubuntu-clock-app/+bug/1421559 | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: CI/autolanding service restored, ping cihelp if your jobs are acting weird | robru is on vacation!
<nik90> sil2100: hmm I accidentally changed the topic
<nik90> can someone revert that pls
<nik90> Mirv: ^^
<jibel> sil2100, do you know why ubuntu-rtm/silo-009 is set to 'Packages Built' while content-hub and unity-scope-click failed to build on armhf?
<om26er> Chipaca, testing with 'hello app' enough ?
<sil2100> jibel: hm, interesting, let me take a look
<sil2100> nik90: ;)
<Chipaca> om26er: or 'poke', whichever is easier for you
<sil2100> nik90: I think the topic is more or less the same now
<sil2100> AH
<sil2100> The dashboard link
<sil2100> nik90: ok, fixing
* sil2100 changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: CI/autolanding service restored, ping cihelp if your jobs are acting weird | robru is on vacation!
<nik90> sil2100: yes, thnx :)
<oSoMoN> om26er, hey, Iâm seeing runs of webbrowser-app-ci marked failed even though all subjobs are passing, could you please take a look? an example is https://jenkins.qa.ubuntu.com/job/webbrowser-app-ci/1580/console
<sil2100> jibel: ok, so it seems the new Robert-train code acts in a different way than before
<jibel> bfiller, could someone check the build failure of ubuntu-rtm/silo-000 if it's something to land in RTM?
<om26er> oSoMoN, I would but I havent touched anything jenkins for a while. I think cihelp would be of more help
<om26er> or is it cihel as I see in the topic.
<bfiller> jibel: yes, Kaleo looking at it now
<sil2100> jibel: since kenvandine kicked a rebuild of only ubuntu-system-settings, the silo actually checked the status of *only* u-s-s in the PPA - and since that built fine it went 'hey, all's good'
<jibel> bfiller, thanks
<oSoMoN> om26er, oh, ok, sorry I pinged you because the job says that an e-mail was sent to your address with the failure, so I thought you were kinda responsible for it
<sil2100> jibel: even though all the other packages failed
<sil2100> jibel: I think we need to get that fixed so that it always checks the whole thing
<ev> oSoMoN: looking
 * sil2100 fills in a bug
<kenvandine> sil2100,  what did i kick?
<sil2100> kenvandine: no worries, everything good on your side ;)
<oSoMoN> cihelp, Iâm seeing runs of webbrowser-app-ci marked failed even though all subjobs are passing, can someone please take a look? an example is https://jenkins.qa.ubuntu.com/job/webbrowser-app-ci/1580/console
<kenvandine> oki... i don't recall rebuilding anything :)
<jibel> sil2100, yes, if one package fails to build then the whole silo must be set to 'failed'
<jibel> sil2100, thanks for freeing my Friday evening :)
<sil2100> jibel: you're welcome ;) We'll resume those next week since I want to keep robru in the loop, but as per our earlier intentions let's slowly try getting rid of twice-daily meetings ;)
<bzoltan_> sil2100: ogra_: the silo12 is up to date and the landing MR has the changelog entry as you have asked for
<om26er> Chipaca, when I first started the app and logged in, No messages where coming back
<om26er> Chipaca, I had to restart hello
<om26er> Chipaca, what logs you want to see
<Chipaca> ralsina: ^
<sil2100> bzoltan_: thanks! Looks fine
<sil2100> ogra_: what do you think now? https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/lastSuccessfulBuild/artifact/ubuntu-ui-toolkit_packaging_changes.diff
 * ogra_ hugs bzoltan_ 
<ogra_> sil2100, ACK ACK ACK !!!
<sil2100> Publishing
<om26er> ralsina, here are the push client logs http://paste.ubuntu.com/10689322/
<ralsina> om26er: ah yes, that's a bug in the hello app, I need to fix it. It should re-register when it gets focus
<om26er> ralsina, btw vibration/sound does not work with your app
<ralsina> om26er: it needs some love ... I'll try to make some time for it
<dbarth> o/ for QA signoff, silo vivid 005 is re-tested with the latest branch from renato; just to make sure it's back on your radar
<bfiller> sil2100: I need a reconfigure of rtm silo 0, changed it from a sync silo to an MR
<sil2100> bfiller: on it
<sil2100> bfiller: done :)
<bfiller> sil2100: thank you
<balloons> sil2100, I'm curious if you might lend an opinion on a cmake question, since I hear you are an expert ;-) I'm trying to figure out how to best recommend using libgtest. Do I put it in the cmake file and have cmake pull it, perhaps like http://paste.ubuntu.com/10689076/. Or do I install the libgtest-dev package and manually compile and copy the libs to /usr/lib?
<sil2100> balloons: hey! Not really an expert, I only used cmake vaguely so someone probably mixed something up, so sadly I can't give you professional advice here ;)
<balloons> sil2100, :-) Thought it would be fun to try and ask anyway. I usually bugged sergiusens with this stuff to be fair
<balloons> ty
<sergiusens> balloons: look at how mir does it ;-)
<balloons> sergiusens, ohh.. ty
<bfiller> sil2100: sorry, I need another reconfigure of rtm silo 0, added sync for qtvideo-node which is needed for one of the bug fixes
<sil2100> bfiller: ok, on it, although my system is a bit laggy since I'm building a big package
<sil2100> So it might take a few moments
<bfiller> np
<rvr> Flight mode is broken in latest Vivid proposed: https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1437425
<ubot5> Ubuntu bug 1437425 in indicator-network (Ubuntu) "Flight mode broken" [Undecided,New]
<sil2100> rvr: ouch
<sil2100> We had an urfkill upload yesterday IIRC
<ogra_> seems to be krillin specific
<jibel> rvr, works here, it takes several seconds though
<jibel> rvr, on latest krillin/vivid
<rvr> jibel: I asked davmor2 to confirm, and he did
<rvr> jibel: (as I'm doing sanity tests with the device tarball)
<davmor2> jibel: are you on devel-proposed or ubuntu-touch/devel-proposed/krillin.en
<jibel> rvr, I don't think it's broken previously the feedback was immediate and you saw the toggle going back and forth until it's completely offline, now it just do switches off. Can you confirm with the lander of urfkill
<jibel> davmor2, krillin.en
<rvr> davmor2: I'm in devel-proposed not krillin.en
<jibel> davmor2, which channel are you on?
<davmor2> jibel: krillin.en
<rvr> jibel: It is pretty broken for me. I wait a while, and it briefly does deactivate, but right after that, toogles are enabled again
<jibel> rvr, yeah that looks wrong and something to investigate. I cannot reproduce sorry.
<rvr> Ah, ToyKeeper landed a flight mode related silo: "URFKILL bug fix toggling flight mode."
<rvr> but in rtm
<jibel> however the BT toggle is broken, I cannot enable it
<rvr> cyphermox: abeato: ^
<rvr> ToyKeeper tested it, but om26er landed it
<abeato> rvr, I'm taking a look, but it probably has nothing to do with the latest urfkill landing
<sil2100> rvr: indeed that was RTM it seems
<abeato> that landed a few days ago, for rtm too, and rtm does not have that issue afaik
<rvr> abeato: Ack
<davmor2> abeato: nope rtm turns off as expected
<rvr> So then it is something else :-/
<abeato> hmm... libc update striking again?
<rvr> abeato: I tested Vivid yesterday with the libc silo, and this test was ok
<rvr> (flight mode)
<boiko> sil2100: sorry it took so long, I was busy with other stuff, but I have sent you the source package, so if you happen to have a free silo around :)
<balloons> cihelp, I need some help with the core apps jobs. I'm curious about moving them back to generic-mediumtests-vivid
<kenvandine> sil2100, i looked at bot line 53 and 55
<kenvandine> not sure what to do with either of them to assign a silo
<kenvandine> no sync or branch?
<sil2100> kenvandine: they're not ready :)
<kenvandine> ok, i thought so :)
<kenvandine> just checking
 * kenvandine ignores
<sil2100> kenvandine: let's not touch rows that don't have column J set
<kenvandine> i normally don't mark them as ready until that's filled out :)
<kenvandine> but thought maybe i had missed something special here
<kenvandine> sil2100, column J?  those both have J as yes
<sil2100> boiko: thanks, will push it once the silo gets configured :)
<boiko> sil2100: great! thanks!
<sil2100> kenvandine: now they do, so I assigned silos :)
<kenvandine> sil2100, but they don't have branches or sync packages?
<kenvandine> what goes in the silo with that?  i see additional packages to land filled out, but not sure how those make it to the silo
<sil2100> kenvandine: they have source packages mentioned
<kenvandine> yeah, but where do those come from?
<sil2100> kenvandine: for instance the silo for boiko will be pushed by me
<kenvandine> i just want to make sure i know what to do with this type of request when you eod :)
<sil2100> Where jdstrand I think has the permissions to push to the PPA himself :)
<kenvandine> ah
<kenvandine> dput :)
<sil2100> Yep
<kenvandine> so we just need to create the silo
<jdstrand> I do
<sil2100> Yeah
<kenvandine> empty
<jdstrand> and I will
<kenvandine> got it
<sil2100> :)
<fginther> balloons, hello.
<fginther> balloons, are you looking to resolve any specific problems?
<dobey> i think i did that maybe slightly wrong for the automatic trello card creation thing
<davmor2> sil2100: rtm custom tarball done, no cwayne though so I'll send him and email john-mcaleely is this something you can do now before I email cwayne
<john-mcaleely> davmor2, no, still a cwayne thing
<sil2100> davmor2: thanks! I don't think john-mcaleely can publish the custom tarball, but maybe that changed
<sil2100> john-mcaleely: ^ ?
<john-mcaleely> sil2100, ^^
<sil2100> Ok, thanks :)
<sil2100> Let's e-mail Chris then
<davmor2> woopwoopwooop.com
<sil2100> boiko: package building in your silo :)
<boiko> sil2100: thanks
<john-mcaleely> davmor2, so, location seems to be a bit busted in rtm for me
<john-mcaleely> do you see that?
<balloons> fginther, hey, yes I was thinking perhaps it might solve the clock app issues on https://code.launchpad.net/~nik90/ubuntu-clock-app/fixed-bottomedge-status/+merge/253998
<balloons> But it also might not.. Which led me the the question of when we might see the switch happen
<dobey> trainguards: what's the correct magic in the spreadsheet to get a qa testing request for a click package to automatically show up on trello?
<sil2100> dobey: on it :)
<kenvandine> dobey, i don't know anything about landing clicks, sorry :)
<kenvandine> jgdx, silo 28 is ready, but we should wait for silo 9 to land before building it
<sil2100> kenvandine: will take care of it, it's just an experimental feature now anyway
<kenvandine> sil2100, thx :)
<kenvandine> rvr, are you going to be able to get back to silo 9?
<kenvandine> or i guess someone else in qa could pick it up
<rvr> kenvandine: I only added information, haven't done anything with it :)
<sil2100> dobey: ok, should be good now
<dobey> sil2100: what was i missing?
<sil2100> dobey: a landing team member needs to approve it for landing
<dobey> oh
<fginther> balloons, I made some notes somewhere on when it might make since to try vivid again. Let me see if I can find them
<balloons> fginther, ack. It would be nice to have a run of that mp to see if it solves things
<fginther> balloons, I can look into trying that and see what happens.
<kenvandine> jgdx, ^^ https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-001-1-build/111/console
<kenvandine> jgdx,  please fix that branch
<john-mcaleely> davmor2, ignore that last. it seems to have been a one-off
<sil2100> kenvandine: I'll leave the train in your hands :) Still working on some packages, but you're the main trainguard now!
<om26er> Kaleo, ping
<om26er> Kaleo, re: fix for bug 1422762
<ubot5> bug 1422762 in camera-app "Camera should not change behavior when rotation lock is on" [High,In progress] https://launchpad.net/bugs/1422762
<om26er> Kaleo, with the .click from the silo installed, if I lock the screen and take a photo horizontally it is taken horizontally, even though the screen rotation is disabled
<om26er> bfiller, ^
<kenvandine> sil2100, ok :)
<bfiller> om26er: that is intended, the video always follows the orientation but not the controls on the app
<om26er> bfiller, isn't that confusing ?
<sil2100> kenvandine: thanks :)
<bfiller> om26er: perhaps
<om26er> bfiller, so If I record a video in landscape while the device rotation is locked in portrait it still records in landscape ?
<bfiller> om26er: yes
<kenvandine> i think it has to
<Kaleo> that's the only to produce a valid video really
<rsalveti> abeato: done, new image should show up in ~1.5h
<Kaleo> otherwise when you are going to read it it's going to be broken
<Kaleo> om26er, ^
<abeato> rsalveti, thanks... it was also that latest urfkill landing makes this trigger more easily
<rsalveti> rvr: davmor2: next image should have the new ofono, fixing this weird flight mode issue
<abeato> so a bad combination :)
<rsalveti> yeah
<rvr> rsalveti: Great!
<om26er> Kaleo, ok, I just wanted to make sure it was intentional
<Kaleo> om26er, thanks for double checking
<john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150327-f7072d0.changes
<john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150327-f7072d0.tar.xz
<john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-testresults-20150327-f7072d0.ods
<john-mcaleely> sil2100, ^ the rtm tarball you were expecting
<sil2100> \o/
<sil2100> Thanks :)
<om26er> Kaleo, the silo suggests it fixes bug 1373607 but I remember I landed a silo for qtvideo-node a few days ago that fixed this bug.
<ubot5> bug 1373607 in camera-app (Ubuntu RTM) "Switching the camera from rear to front to rear facing causing the controls to disappear" [High,In progress] https://launchpad.net/bugs/1373607
<Kaleo> om26er, you must have landed it in vivid no?
<Kaleo> om26er, this would be the same fix for rtm
<imgbot> === IMAGE 152 building (started: 20150327-19:10) ===
<om26er> Kaleo, perhaps
<om26er> Kaleo, I regularly face this crash in camera: https://errors.ubuntu.com/oops/75e66f1a-d4b4-11e4-90ca-fa163e4aaad4
<om26er> saw it once again while testing the silo
<Kaleo> om26er, not much to go in that report :(
<Kaleo> om26er, the stack is nearly empty
<om26er> Kaleo, yeah :/
<om26er> Kaleo, it always has this line "=> 0x2c:?Cannot access memory at address 0x2c"
<om26er> I thought it was fixed at one stage
<balloons> fginther, any luck?
<fginther> balloons, just kicked it off. Sorry ran into an accidental computer reset, then a meeting.
<fginther> balloons, http://91.189.93.70:8080/job/generic-mediumtests-vivid-test/11/
<pmcgowan> robru, hey soonsnap doesnt work for me, all the images are truncated that I send from my phone
<cyphermox> pmcgowan: robru isn't around
<cyphermox> he's on vacation this week, can I or kenvandine help with this?
<pmcgowan> cyphermox, no this is his app in the store
<kenvandine> i thought that was aquarius'
<pmcgowan> kenvandine, he made the site and robru made the webapp
<kenvandine> i see
<pmcgowan> oh so maybe its content hub thats the issue
<kenvandine> not if it's truncating it
<kenvandine> must be the upload
<pmcgowan> that would be the server but who knows
<bfiller> kenvandine: do you have publishing powers? rtm 0 needs to be published
<kenvandine> yup
<kenvandine> bfiller,  done
<bfiller> kenvandine: thanks
<kenvandine> np
<kenvandine> ah, the abyss
<kenvandine> bfiller, isn't there a click for camera-app too?
<kenvandine> i don't know how to publish that
<bfiller> kenvandine: yes, I will push that to the store
<kenvandine> ok
<bfiller> kenvandine: just want to rebuild it after the MR lands in trunk so the versioning is all correct
<kenvandine> i see
<imgbot> === IMAGE 152 DONE (finished: 20150327-20:55) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/152.changes ===
<balloons> fginther, looks like the run is done, but it didn't get to the autopilot tests: http://91.189.93.70:8080/job/generic-mediumtests-vivid-test/11/consoleText
<fginther> balloons, indeed, it hit https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-snapshot/+bug/1389729
<ubot5> Ubuntu bug 1389729 in llvm-toolchain-snapshot (Ubuntu) "LLVM ERROR: Cannot select: intrinsic %llvm.x86.sse41.pblendvb" [Undecided,Confirmed]
<balloons> right.. I'm mostly curious about the AP tests; we'll re-run without the qml tests
<balloons> fginther, or do you think it will end the same way?
<balloons> I suppose it will
<fginther> balloons, if the qml tests are disabled, it should make it to the autopilot tests
<balloons> fginther, right, but I wonder if the same bug will hit :-) I guess it's worth a shot if you think it may run
<fginther> balloons, the QML tests have to be disabled in the MP itself
<fginther> balloons, i think they wold run
<fginther> *would*
<nik90> fginther: hey, it seems when running the clock app tests on vivid jenkins, all the qml tests fail due to https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-snapshot/+bug/1389729
<ubot5> Ubuntu bug 1389729 in llvm-toolchain-snapshot (Ubuntu) "LLVM ERROR: Cannot select: intrinsic %llvm.x86.sse41.pblendvb" [Undecided,Confirmed]
<boiko> trainguards: could you please reconfigure vivid silo 21? I added a new component there (telepathy-ofono)
<nik90> fginther: I have disabled the qml tests for now since me and balloons are trying to figure out why the AP tests are failing on jenkins alone.
<nik90> fginther: can you make jenkins re-run the tests pls
<nik90> fginther: here's the log http://91.189.93.70:8080/job/generic-mediumtests-vivid-test/11/console
<fginther> nik90, yes. I have no idea how to fix or workaround that problem :-(. I can work on trying again with a fresh instance, but it will take a little bit of time
<fginther> nik90, yes, I can re-trigger
<kenvandine> boiko, sure
<nik90> fginther: yeah let's ignore the qml test failures for now..Just need to see the AP results. thnx
<fginther> nik90, balloons, http://91.189.93.70:8080/job/generic-mediumtests-vivid-test/12
<kenvandine> cyphermox, hey, i tried to reconfigure silo 21 for boiko, but it complained that i should have a trainguard reconfigure the silo :)
<kenvandine> 2015-03-27 21:09:06,822 ERROR telepathy-ofono was not in the initial list of components for that silo. Please ask the trainguards to reconfigure this silo for you.
<kenvandine> cyphermox, an MR was added to it, adding that package
<kenvandine> telepathy-qt5 in that silo was a manual upload
<kenvandine> cyphermox, oh... so i see on the wiki that only trainguards can reconfigure silos adding a new package
<kenvandine> but i don't know how to do it :)
<cyphermox> kenvandine: you use the landing tools assign a silo link from the spreadsheet
<kenvandine> i see
<kenvandine> confusing for a reconfigure :)
<kenvandine> but i recall now that it sort of the same thing :)
<cyphermox> yup :)
<kenvandine> boiko, done
<boiko> kenvandine: cool! thanks!
<kenvandine> np
<pmcgowan> cyphermox, whats up with rtm silo 8?
<balloons> nik90, fginther just interesting to see these runs take a LONG time. Thanks for the re-run
<fginther> balloons, yeah, I think the host might be having issues too :-(
<fginther> balloons, might need to create a new one from scratch
<cyphermox> charles: renatu: please check https://launchpadlibrarian.net/201394376/buildlog_ubuntu-vivid-armhf.qtorganizer5-eds_0.1.1%2B15.04.20150327-0ubuntu1_BUILDING.txt.gz
<cyphermox> qtorganizer5-eds fails to build, fails its tests.
<charles> cyphermox, thanks
<charles> that's renatu's patch, I'll let him sort it out :)
<charles> cyphermox, QA isn't doing nonphone testing, what's the procedure for landing the desktop-only change in silo 16?
<nik90> balloons, fginther: Its building clock-app atm. We should get the results very soon.
<bfiller> popey: whenever you're around, new camera-app in the store needs to be approved
<nik90> balloons, fginther: Hmm it seems to stopped for some strange reason. Its almost friday midnight. I am EOD.  Let's try again next week.
#ubuntu-ci-eng 2015-03-28
<imgbot> === IMAGE 153 building (started: 20150328-02:10) ===
<imgbot> === IMAGE 153 DONE (finished: 20150328-03:35) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/153.changes ===
#ubuntu-ci-eng 2015-03-29
<imgbot> === IMAGE 154 building (started: 20150329-02:10) ===
<imgbot> === IMAGE 154 DONE (finished: 20150329-03:35) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/154.changes ===
#ubuntu-ci-eng 2016-03-28
<pmcgowan> heya can someone check https://requests.ci-train.ubuntu.com/#/ticket/1145 to see if it published
<pmcgowan> trainguards ^
<dobey> pmcgowan: doesn't look like it is published
<pmcgowan> dobey, yeah
<dobey> the overlay ppa has a lower version than in the silo ppa, anyway
<pmcgowan> robru, any suggestion on that silo?
<pmcgowan> trainguards ?
<ssweeny> trainguards, https://requests.ci-train.ubuntu.com/#/ticket/1100 says "failed to build" but when I look at jenkins it seems everything went OK
<kgunn> ssweeny: but looking at the ppa it's backed by seems to indicate the armhf arch failed with
<kgunn> https://launchpadlibrarian.net/250214125/buildlog_ubuntu-vivid-armhf.location-service_2.1+15.04.20160328-0ubuntu1_BUILDING.txt.gz
<kgunn> other archs built fine
<ssweeny> kgunn, aha, thanks!
<ssweeny> interesting
<robru> ssweeny: yes, a successful jenkins run just means the *source* package build succeeded, you need to look at the PPA
<robru> pmcgowan: kenvandine: I suspect the diff is against vivid proper, logs look like it was switched to point at overlay after the diffs were generated, re-diffing just to be sure
<pmcgowan> robru, thanks
<robru> pmcgowan: kenvandine: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-1145/2016-03-28_17:21:02/vivid/android/packaging_changes.diff yes this diff looks much more sensible
<pmcgowan> robru, great can we go ahead and publish it then?
<robru> pmcgowan: sure, just needs a core dev, I can't do it. kenvandine ?
<robru> I gotta grab some breakfast, bbiab
<kenvandine> sure
<kenvandine> pmcgowan, that does look much better :)
<kenvandine> robru, the status is in generating diffs, can i publish like that?
<kenvandine> or do i need to wait for the status to change
<kenvandine> pmcgowan, publishing
<kenvandine> ERROR: No artifacts found that match the file pattern "*". Configuration error?
<kenvandine> robru, ^^
<robru> kenvandine: that's fine, that just means that it did a PPA copy directly rather than writing a manifest file for copying to the real archive
<robru> kenvandine: and yeah you could have published while the status was still 'generating diffs', diff generation was already over (as evidenced by the fact that you were looking at the finished diff), it just hadn't updated the status yet, which happens every 15 min.
<kenvandine> ok
<lpotter> robru: ping
<robru> lpotter: hi
<lpotter> hi. I get a 401 error when trying to create a new landing request
<robru> lpotter: have you ever used it before?
<lpotter> no :)
<robru> lpotter: so you're wanting access then? what are you working on?
<lpotter> yes, I need to try and land some QtNetworking fixes
<robru> lpotter: ok I'll add you to the team
<lpotter> thank you
<lpotter> I'm lorn-potter on launchpad, btw
<robru> lpotter: ok, I added you to the team, you'll have to log out and log back in. and read: https://wiki.ubuntu.com/citrain/LandingProcess I'll be around to answer questions periodically if you're unsure about anything
<lpotter> ta
<robru> yw
<lpotter> robru: what does that mean, or rather, what do I do to fix that? ^^
<robru> lpotter: i don't understand what you're trying to do
<robru> lpotter: let me know what your goal is, and I'll review your ticket
<lpotter> trying to build packages to test/land
<lpotter> copying them over from my ppa
<lpotter> and sorry, citrain noob here :)
<robru> lpotter: so I'll have to copy stuff from your ppa, the sync feature doesn't work like that, that's a vestigial feature from when ubuntu-rtm was a different distro
<robru> The error is that it's trying to adjust the version number and failing
<robru> lpotter: and do you have the gles package prepped?
<lpotter> no
<robru> lpotter: have you been coordinating with Mirv? He usually handles qtbase.
<lpotter> not on this one. I was instructed to do my own, since I have not yet created a landing request
<robru> lpotter: sorry got distracted. So if you're ready i can copy your packages in but you'll need the gles twin before you can actually publish this.
<lpotter> well, not going to publish it just yet, but will get the gles package up there
<robru> lpotter: OK let me know when you get the gles prepped and I'll copy both at the same time.
<lpotter> will do
#ubuntu-ci-eng 2016-03-29
<Mirv> lpotter: robru: vivid only landing could be ok at this point, there's another "something changed in xenial, an unit test fails" preventing my next qtbase dual landing. of course, xenial would need the same fix eventually.
<robru> Mirv: best to keep it in sync imho, but it's your call
<Mirv> robru: yeah it's best. sometimes I deviate if I'm waiting for the real upstream fix to backport to xenial while doing a special patch for vivid. I think lpotter's upstreaming of latest vivid changes is in progress and there's not yet something merged to backport to xenial/5.5
<Mirv> depends on the deadlines too. if this would be OTA-10 at the moment, then definitely vivid only since simply running double autopkgtests take time.
<robru> We're past the deadline for ota10 unless this has some kind of exception
<Mirv> then there's no hurry
<lpotter> ya this is OTA-11.
<lpotter> I've added qtbase-opensource-src-gles to my ppa
<abeato> Mirv, hi, quick question, is there any candidate image for ota-10 already? if not, should I assume that all we have now in rc-proposed will be included in OTA-10?
<Mirv> abeato: my understanding is that rc-proposed is OTA-10 still, until it's announced that OTA-11 work starts (at which point a OTA-10 specific snapshot PPA is made)
<abeato> Mirv, great, I wanted to be sure, thanks
<rvr> morphis: ping
<rvr> mardy: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1563007
<ubot5> Launchpad bug 1563007 in Canonical System Image "App is not installed after credentials are introduced" [High,Confirmed]
<rvr> mardy: Not sure whether it is related to unity-scope-click or to Online Accounts. The account is created.
<mardy> rvr: can you please paste the output of OAU_LOGGING_LEVEL=2 OAU_DAEMON_TIMEOUT=9999 online-accounts-service ?
<rvr> mardy: On it
<rvr> mardy: http://paste.ubuntu.com/15551027/
<mardy> rvr: thanks, do you ming adding it to the bug report as well?
<mardy> rvr: do you have something under /var/crash/?
<rvr> Hmm
<rvr> _usr_lib_arm-linux-gnueabihf_unity-scopes_scoperunner.32011.crash
<rvr>  #3  0xb38da05a in click::web::Response::replyFinished() () from /usr/lib/arm-linux-gnueabihf/unity-scopes/clickstore/com.canonical.scopes.clickstore.so
<pstolowski> sil2100, hey, there?
<sil2100> Hey
<sil2100> Yea
<pstolowski> sil2100, we need a no-change rebuild of cmake-extras, the new cmake in xenial-proposed breaks it; shall i go the normal route of empty MP via citrain?
<mterry> pstolowski: I uploaded a no-change rebuild to xenial.  Waiting for it to be approved
<pstolowski> mterry, awesome, thanks!
<sil2100> pstolowski: sorry, had meeting-after-meeting
<pstolowski> sil2100, np, mterry did the rebuild
<Saviq> trainguards, can you please add josharenson to ~ci-train-users? thanks :)
<sil2100> Saviq: on it (slowly as in a meeting)
<Saviq> nw
<Saviq> hanks
<Saviq> t
<Saviq> om
<sil2100> ;)
<sil2100> yw!
<jhodapp> sil2100, hey any idea why this silo keeps having a dependency wait issue for media-hub on vivid? My MR doesn't change how the build works and media-hub has been dual landable for months now
<john-mcaleely> ondra, sil2100 jibel - if you need it, an approved device tarball for landing adb changes
<john-mcaleely> https://requests.ci-train.ubuntu.com/#/ticket/1197
<john-mcaleely> just needs QA +1, and for ondra to have u-d-f ready :-)
<ondra> john-mcaleely I'm stacked with u-d-f
<ondra> john-mcaleely mvo is  not around, u-d-f needs some special magic that only mvo and sergio have. I tested mvo's own branch, but that still errros on me
<ondra> john-mcaleely so I can't really test change in u-d-f
<ondra> john-mcaleely otherwise I hand created ubuntu_command it things do work
<robru> jhodapp: what silo?
<jhodapp> robru, silo 51
<robru> jhodapp: not sure what to tell you, you depend on dbus-cpp >5 http://bazaar.launchpad.net/~phablet-team/media-hub/fix-1538703/view/head:/debian/control#L23
<robru> jhodapp: but overlay PPA only has 4.3: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/5964064/+listing-archive-extra
<jhodapp> robru, yeah but in debian/control.in it's 4.3 or above
<jhodapp> robru, and debian/control is supposed to be autogenerated from the control.in file
<jhodapp> maybe the person to talk to is tvoss since he set this all up
<robru> jhodapp: oh, well control.in answers everything. train changed the way this is handled
<robru> jhodapp: hang on I'll throw together a branch that fixes this.
<robru> (sorry just waking up)
<jhodapp> robru, ah perfect! no worries, thanks man
<robru> yw
<jhodapp> robru, did this change with your recent large updates?
<robru> jhodapp: yep, this is that 'ACTION REQUIRED' email from last week
<jhodapp> robru, ok I'll give it another read since I have related context now
<jhodapp> robru, makes much more sense now, didn't realize media-hub was doing this for its package
<robru> jhodapp: yeah unfortunately there's no index of what packages are doing this so I just have to wait until they explode and fix them as they come
<jhodapp> robru, makes sense...maybe start a list as they come in so you can keep track going forward?
 * jhodapp brb
<robru> jhodapp: dunno, back in the bad old days train kept a list of what packages it managed and it was quite the hassle to keep it updated. beter if things are more independant
<robru> jhodapp: hm so I ran a build with my branch but it didn't work, it's using the xenial SOVERSION in vivid. will poke a bit more
<jhodapp> robru, ok
<robru> jhodapp: huh this is really weird, I put in some debug logging and it says it's using the right $soversion but then the file magically comes out with the wrong name.
<jhodapp> robru, wrong name because of the version or a different part of the name?
<robru> jhodapp: I'm expecting the script to create debian/libmedia-hub-{client,common}4.install but instead it's creating ...5.install, eg, wrong $soversion
<jhodapp> yeah that is odd...has to come from the script though right?
<jhodapp> robru, I mean this was working before the train update
<robru> jhodapp: http://bazaar.launchpad.net/~robru/media-hub/pre_release_hook/view/181/debian/bileto_pre_release_hook#L67 this echoes "soversion: 4" and then creates files named ...5.install, you can't explain that.
<jhodapp> robru, so are you replacing the gen-debian-files.sh script in media-hub/debian/ or does the new hook just simply call this?
<jhodapp> ah I see
<jhodapp> rewriting it basically
<jhodapp> that's bizarre indeed
<robru> jhodapp: this is gen-debian-files.sh, just renamed to a well-known name that the train will run if it exists, and also fixing it to honor $SERIES env var because it no longer runs ina  chroot, so 'lsb_release -c -s' won't give correct values anymore.
<robru> jhodapp: hm actually it looks like the PPA contents are correct, it's just the silo diff that's wrong somehow...
<jhodapp> robru, could that be some cached silo cruft?
<robru> jhodapp: no I think debdiff is doing something funny...
<jhodapp> hmm ok
<robru> jhodapp: ok well anyway the build should be working now in vivid.
<jhodapp> robru, awesome thanks, so I'll merge your branch into mine then
<robru> despite debdiff reporting a wrong diff, sigh
<jhodapp> robru, is that problematic?
<robru> jhodapp: why? both branches are in the silo.
<jhodapp> oh didn't see you added it, nm then
<robru> jhodapp: well whoever reviews your packaging diff will likely be confused by the 5 in the dif when it should be a 4, but you'll just have to explain to them that the diff is wrong and the ppa contents are correct I guess.
<jhodapp> robru, ok thanks and I guess I'll keep an eye on it as well
<robru> jhodapp: alright you're welcome
<robru> slangasek: we on for the meeting?
<lpotter> robru: did you ever copy those packages for silo 60 for me?
<robru> lpotter: no i was waiting for you to do the gles one.
<lpotter> ok. it's there now
<robru> lpotter: OK what's your ppa again? And what silo did you get?
<lpotter> ppa:lorn-potter/servicenetworkppa silo 060
<robru> lpotter: so those are just vivid packages there, your silo is configured for xenial+vivid. Are you doing xenial or should i switch it to just vivid?
<lpotter> not sure. lets just do vivid for now
<robru> OK
<robru> lpotter: OK copied, build should start soon
<lpotter> thank you
<robru> You're welcome
#ubuntu-ci-eng 2016-03-30
<lpotter> ++fqvvx
<lpotter> geez qtbase takes forever to build...
<mardy> cjwatson: hi! Is this normal? https://launchpad.net/~mardy/+archive/ubuntu/phablet/+build/9416048
<mardy> cjwatson: seems to be stuck there
<cjwatson> mardy: no, I presume a compute node is sad, cancelling and retrying
<mardy> cjwatson: thanks
<cjwatson> mardy: (done)
<tvoss> robru, ping
<tvoss> robru, hey there, I have got a build for platform-api consistently failing for xenial whereas it passes reliably on vivid+o. Would you mind having a look? silo 74
<tvoss> sil2100, ^
<sil2100> In a moment
<Mirv> tvoss: all the simbackendtests seem to be failinng on xenial
<Mirv> tvoss: just use "trainguards" is easiest always, it'll higlight me, sil, robert, and others at times
<tvoss> Mirv, yeah, wondering why
<tvoss> Mirv, ack
<tvoss> Mirv, I'm doing a test build locally in a xenial chroot
<tvoss> Mirv, let's see
<Mirv> tvoss: erm. " Actual: 4-byte object <03-00 00-00>, Expected: core::posix::wait::Result::Status::exited"
<tvoss> Mirv, that's a result of the backend not being loadable
<Mirv> tvoss: it's almost two months since last platform-api landing, this could be something changed in xenial. I've been hit by some, including a glibc bug.
<tvoss> Mirv, interesting
<tvoss> Mirv, the build used to work fine before, though
<tvoss> Mirv, silo has been around for some time and actively rebuilding
<Mirv> tvoss: I see you had a successful build at 2016-03-22. assuming it's not something you changed in platform-api, it could be something change in xenial since then.
<tvoss> Mirv, yup
<Mirv> tvoss: at least this gcc-5 landing happened during the timeframe http://launchpadlibrarian.net/249840962/gcc-5_5.3.1-12ubuntu4_5.3.1-13ubuntu1.diff.gz
<Mirv> tvoss: and also the whole glibc 2.21 -> 2.23 upgrade https://launchpad.net/ubuntu/+source/glibc/+changelog that broke a single Qt unit test for me which took some hunting to find the culprit
<tvoss> Mirv, ack, I will do a deep dive in a local environment then, thanks for investigating
<popey> jibel: sil2100 is https://trello.com/c/qnhVyg2j/2936-1095-ubuntu-landing-050-ubuntu-ui-toolkit-bzoltan going to make OTA-10? It's blocking an update to music.
<ahayzen> popey, not blocking an update to music, it makes the *current* app startup horrible, eg a regression :-)
<popey> oh, yes, you're right!
<popey> ^ jibel sil2100 :)
<jibel> popey, it won't land unless bzoltan cherry picks the fix
<popey> bzoltan: ^
<ahayzen> it is this bug specifically https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1554897
<ubot5`> Launchpad bug 1554897 in ubuntu-ui-toolkit (Ubuntu RTM) "App with dark background flickers temporarily to white at startup" [High,Fix committed]
<bzoltan> popey:  what UITK rev do you need?
<popey> It causes a problem for "dark" apps like music and podbird
<popey> music is more adversely affected as it takes a while to load, so it is very noticable.
<popey> Also, being a default app we're breaking.
<ahayzen> bzoltan, we need this fix https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/fasterWindowColor/+merge/288661
<popey> ta ahayzen
<ahayzen> revision 1895 of staging it landed
<bzoltan> ahayzen:  why now? OTA10 is closing.
<ahayzen> because it has been in the queue for ages sortof expected it to be in ota10 :')
<popey> it's a regression in ota-10
<ahayzen> and when it says "Description of landing: OTA10 landing" ... that sortof leads you to think it'll be in ota10...
<bzoltan> ahayzen: popey: an OTA10 tag helps me to put it on our backlogs
<ahayzen> yeah this one seems to have missed having the usual canonical-devices thing + a milestone
<ahayzen> i think it was because it was found from the previous UITK silo while testing that
<bzoltan> ahayzen:  I can start pulling it in.. but it does take time.. only siloing and building takes ate least 24h if we are lucky
<ahayzen> ugh :-/
<ahayzen> bzoltan, what's the reason that this silo isn't landing through QA? https://trello.com/c/qnhVyg2j/2936-1095-ubuntu-landing-050-ubuntu-ui-toolkit-bzoltan
<bzoltan> jibel:  how much time we have?
<bzoltan> ahayzen:  That is not the same silo :)
<ahayzen> it includes that fix? no?
<ahayzen> that was the one i was assuming was going to land...
<bzoltan> ahayzen:  it is the next landing and it does include that fix ... but it does include a regression too
<ahayzen> ah !
<popey> So, pick your regresion or fix both?
<ahayzen> heh many options :-)
<jibel> bzoltan, if you can have a silo with just this fix today it can land for OTA10
<bzoltan> popey:  Fixing that silo will take a day
<popey> So a cherry pick then?
<bzoltan> jibel:  today? the Automated Signoff will take a day if not two
<popey> bzoltan: jibel this is what it looks like - from my phone running rc-proposed http://people.canonical.com/~alan/music.mkv
<bzoltan> popey: Confirmed
<john-mcaleely> jibel, I believe this device landing is needed for adb. Anything needed for it to be 'ready for qa'?
<john-mcaleely> jibel, https://requests.ci-train.ubuntu.com/#/ticket/1197
<john-mcaleely> I think I'm done with it
<bzoltan> jibel: popey: the silo35 is chewing on it already
<popey> heh, thanks.
<bzoltan> popey:  andf here comes the gles parade ... Mirv help me :)
<rvr> tvoss: morphis: Silo 47 approved
<Mirv> bzoltan: looks like your previous successful landing did not touch changelog at all https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/applauncher-fixes-gles/+merge/288861
<Mirv> bzoltan: now it seems the train is increasing the number on every build and if you want to keep the changelog change maybe try .2 next...
<tvoss> rvr, thank you
<bzoltan> Mirv: i am running after an escaping number :) It is not going well
<pmcgowan> sil2100, heya do we need a new custom tarball for mako? seems it hasnt been updated with the apps yet
<sil2100> pmcgowan: you mean the one in the BQ aquaris channel, yes?
<sil2100> Let me spin that one quickly
<AlbertA> trainguards: could somebody retrigger the arm64+armhf builds in the xenial ppa: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+packages
<sil2100> AlbertA: on it
<rvr> mterry: Hi. How can I check the name set in the wizard?
<mterry> rvr: you mean to confirm it got set correctly?  "cat /var/lib/extrausers/passwd" should show the new name instead of "Ubuntu"
<rvr> mterry: Ah, it does, great
<mterry> rvr: or, if you are on a tablet, the greeter will show your name
<mterry> rvr: awesome
<mterry> rvr: that was a surprisingly annoying bug to fix  :)
<rvr> mterry: Because the image partition is usually ro?
<ogra_> /var/lib/extrausers/passwd is rw ;)
<mterry> rvr: well the ro partition was part of it, but there were like 3 things that had to be fixed to get that right.  Each time, I'd be like "got it!" and then it still wouldn't work
<ogra_> (and adduser respects that with the right options)
<mterry> ogra_: but usermod didn't, had to fix it  :-/  But should be good now
<ogra_> cant you just use adduser instead of usermod ? i think adduser can modify too
<ogra_> (academic though ... since you fined it :) )
<ogra_> *fixed
<mterry> ogra_: well this usage was more like passwd -- wants to try /etc/passwd and fallback to extrausers gracefully.  And AccountsService was driving use of usermod, didn't want to hack/patch it to switch
<ogra_> passwd needs the --extrausers option
<ogra_> then it shoudl just ignore /etc/passwd
<ogra_> (for any write operations)
<bzoltan> jibel: popey: in the silo50 I have a fix to help the flaky builds on Xenuial. I am not going to port that fix to the silo35, so you need to take the silo35 as it is.. or I keep pushing builds as long as it gets OK. But xenial armhf should not be an issue for you.
<jibel> bzoltan, okay
<mterry> ogra_: no...  My memory is that adduser has an --extrausers option (because it doens't know where you want to add the new user).  I didn't add that though.  I do remember patching passwd (and now usermod) to fallback to checking extrausers if they can't find the provided user in /etc/passwd and extrausers exists (without any arguments, because the callers of
<mterry> such programs rarely know where the user will be ahead of time)
<ogra_> hmm, i thought adduser simply hands the option through to passwd
<ogra_> but i might mis-remember that +
<mterry> ogra_: I dunno.  I didn't add the --extrausers support, not sure how that works
<ogra_> yeah, that was sergiuens
<mterry> anyway, it should all work fine now
<mterry> Until we find another low-level tool that doesn't know about extrausers :)
<ogra_> chfn doesnt
 * ogra_ has that on the TODO to fix for snappy 
<AlbertA> sil2100: thanks! is there something up with the arm64 builders? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+build/9414590
<AlbertA> I don't see a build log...
<sil2100> Now that's strange
<sil2100> cjwatson: hey! Could you take a look what happened with the build AlbertA posted above? ^
<sil2100> We don't see the build-log for that
<cjwatson> that happens if the builder died catsastrophically.  retry
<sil2100> ACK
<sil2100> AlbertA: retried again
<cjwatson> I have crappy networking right now and it would take ages to check further
<AlbertA> cjwatson, sil2100: thanks gentleman :)
<AlbertA> gentlemen even...
<bzoltan> popey: jibel: the  vivid UITK  is there in the silo35.
<bzoltan> popey: jibel: the gles amd package is acting up.. i rebuild
<robru> Mirv: you're looking at the input merge. train generates gles changelog for you: http://bazaar.launchpad.net/~phablet-team/ubuntu-ui-toolkit/gles/revision/111
<jibel> Saviq, mterry 66 approved
<bzoltan> jibel: popey: the silo35 is ready for you. i can not flip the approved flag because the xenial armhf failed
<bzoltan> jibel: but if you want to release it the packages are there
<jibel> bzoltan, thanks, I'll force the flag
<jibel> ah I cannot if the build failed on one target
<jibel> bzoltan, this will land as part of silo 50 on xenial?
<bzoltan> jibel:  the silo50 has other fixes... including the build stability
<bzoltan> jibel:  not easy to cherry pick :)
<jibel> bzoltan, yes, I mean silo 35 won't be published to xenial?
<bzoltan> jibel:  I do not need it on xenial
<jibel> bzoltan, fine, thanks
<bzoltan> jibel:  I keep the dual landing because of the version clarity
<jibel> understood, not sure how the publication will work
<bzoltan> jibel: this change would fix the xenial armhf build http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/staging/revision/1913 But it tcan wait with the next real landing
<jibel> sil2100, ^ will this work? land only on vivid a dual landing silo?
<Saviq> jibel, great, thanks
<Saviq> mterry, can you publish please https://requests.ci-train.ubuntu.com/#/ticket/1186
<dobey> trainguards: can someone hit https://autopkgtest.ubuntu.com/request.cgi?release=vivid&arch=armhf&package=unity-scope-click&trigger=unity-scope-click%2F0.1.1%2B15.04.20160330-0ubuntu1&ppa=ci-train-ppa-service%2Fstable-phone-overlay&ppa=ci-train-ppa-service%2Flanding-075 please?
<dobey> or kenvandine ^^ :)
<mterry> Saviq: sorry was at gym, looks like it still needs publishing?
<robru> dobey: sorry, you need somebody with upload rights, train guards have no power there. maybe mterry ^
<dobey> well, sil2100 has the power i guess, but yeah
<mterry> robru, dobey: done
<dobey> thanks mterry
<robru> dobey: right but that's because he's a core dev and not because he's a train guard
<dobey> sure
<dobey> but a motu would be fine here too; i didn't know if you were motu or not (i guess not) :)
<robru> dobey: yeah I got nuthin
<rvr> bzoltan: Hi. Silo 35... I still see the menu bar turning white briefly with silo 35 installed https://private-fileshare.canonical.com/~vrruiz/top-bar-white.mp4
<rvr> bzoltan: Although problem is gone for music app
 * mterry feeds queuebot a cookie
<alecu> ping trainguards
<alecu> hi! I can't understand what failed here: https://requests.ci-train.ubuntu.com/#/ticket/1204
<robru> alecu: there's a unity8 autopkgtest failure in xenial.
<alecu> I see a regression for the autopkgtest for unity8, but the revert in the silo should not be causing that
<alecu> robru: right...
<alecu> robru: is there a way to retry?
<alecu> should I just try rebuilding?
<robru> alecu: no
<robru> that is the worst thing you can do, extremely wasteful
<robru> alecu: I guess there's some problem with unity8's autopkgtests, I don't really understand it, just ask QA nicely to add your silo to the queue
<alecu> robru: will do, thanks.
<robru> alecu: assuming you're ready to release I mean
<robru> you're welcome
<alecu> I guess ToyKeeper is the one to ask in this timezone...
<robru> yeah I think so
<ToyKeeper> Hmm?
<alecu> robru: we are ready to release, thanks.
<ToyKeeper> The silo bot should pick it up soon and add it to the QA queue.
<robru> ToyKeeper: no because britney is hung up on an unrelated unity8 autopkgtest failure, so the whole thing is marked as "failed" and won't get into the queue on it's own. needs to be poked
<ToyKeeper> I'd have to double-check, but I think the QA silo bot only cares about the "QA Signoff=Ready" flag.
<robru> ToyKeeper: that's what I'm saying, it won't get to ready because the autopkgtests are failed.
<ToyKeeper> Ah, and there it is.
<alecu> ToyKeeper: yes, it just showed up on the Trello board. Thanks!!!
<ToyKeeper> Er, [15:38:12] -queuebot/#ubuntu-ci-eng- dobey, https://requests.ci-train.ubuntu.com/#/ticket/1204 QA Signoff: Ready
<ToyKeeper> ^^^ That triggered the trello bot to add it.
<robru> ToyKeeper: uh ok, I don't understand how it approved that considering the glaring unity8 autopkgtest failure, this doesn't make any sense.
<ToyKeeper> I don't know how it got marked as ready, but that's all the trello bot cares about.  It assumes any other details are handled elsewhere.
<ToyKeeper> If a human overrides the other bots and marks it as ready, the QA bot will pick it up.
<robru> oh the unity8 failure went away *just now*, huh
<ToyKeeper> Anyway, I moved it to the top of the queue and marked it green.
<alecu> yay, thanks robru, ToyKeeper!
<ToyKeeper> I helped break it, so I kinda want to get it fixed quickly...
<robru> alecu: you're welcome
<Saviq> robru, can you please force-merge https://requests.ci-train.ubuntu.com/#/ticket/1186 - we need a follow up packaging thing to unstick those from proposed
<Saviq> https://requests.ci-train.ubuntu.com/#/ticket/1206 would be the follow-up (just packaging changes)
<robru> Saviq: sure. Sorry about the testsuite thing, i tried backporting dpkg from vivid to trusty to fix this but it fails to compile for no discernable reason. Not sure how to proceed other than migrating the train to xenial, which won't happen for a few months yet.
<robru> Saviq: pitti was saying it needs to be XS-Testsuite because trusty dpkg doesn't support Testsuite at all.
<Saviq> robru, that's fine, we shoulda had it explicit in any case
<Saviq> robru, ack, lemme fix
<Saviq> robru, well, you could build the source packages in a minimal xenial chroot (I know you don't wanna :))
<robru> Saviq: i just spent weeks ripping all the chroots out :-P
<Saviq> robru, I wanna talk to you about one more thing at some point - how do we share code between train and jenkaas - after all a whole lot of what we need in CI train is doing, too
<robru> Saviq: what kind of code do you want to share?
<Saviq> robru, everything up to (and maybe including) building packages
<robru> Saviq: i don't understand what that even means. All the train does is build packages.
<Saviq> robru, yup ;)
<Saviq> robru, fetch code from branches, build source packages, build binary packages, run autopkgtests - that's really the extent of what our jenkins instance is doing
<Saviq> some teams have a little more built on top
<robru> Saviq: train does not build binary packages or run autopkgtests, that's all handled remotely.
<robru> Saviq: i don't really understand what jenkaas is even doing for you, it sounds like you just want more silos.
<Saviq> robru, for one, it's triggered on MP changes
<Saviq> robru, for two, we have touch devices to run autopilot tests on in there
<Saviq> robru, three - we can build much faster than PPAs by cutting corners (ccache, prepopulated chroots etc.)
<Saviq> robru, four - report on MPs
<Saviq> robru, five - autolanding
<Saviq> robru, six - custom things on top
<robru> Saviq: yeah I'm not sure what to say. I don't see how they could share any code. I'm in the middle of tearing everything apart, no way I'm ready to handle any sort of stable api that other services could consume.
<Saviq> robru, which is why I said we ~"have to talk at some point"
<robru> Saviq: autolanding is the opposite of what the train does. That merges to trunk when branches are approved, doesn't wait for packages to publish.
<Saviq> robru, you don't need to explain the differences to me :)
<Saviq> robru, I just mean there's a lot of overlap which I'd really like to get rid of
<Saviq> nothing that needs to happen any time soon
<robru> Saviq: there's just a huge and bizarre impedance mismatch here, they're different tools that have different work flows and age only superficially similar.
<Saviq> robru, I don't want to take the whole of train and shove it into jenkaas
<Saviq> robru, but there are discrete work items that both need to do, and those common bits can arguably be abstracted to benefit both
<robru> Saviq: it sounds like you want jenkaas to create tickets and trigger builds for you.
<robru> Saviq: one thing i could consider is making silos auto-rebuild when new commits are detected but i worry that might not quite be what people want, eg rebuilding all conflicting silos when one merges.
<Saviq> robru, that was an idea at some point, but the latency of train is too big IMO for the MP level - we need as quick turnaround as possible
<Saviq> robru, no, train is good as is - I would just like to share the code that has the same result on both sides
<robru> Saviq: right, I'm working on reducing the latency, parallelism is coming soon so each build will only take a couple minutes
<robru> Saviq: OK, well think about specifically what features you'd need because i can't even picture really what bits you're wanting.
<Saviq> robru, fetch code, build source packages - that at least
<Saviq> robru, later, maybe, dealing with ephemeral PPAs where appropriate
<robru> Hmm
<robru> Once that code is even written :-P
<Saviq> robru, yup :)
<Saviq> robru, in the mean time, would you please be so kind as to review the two unreviewed branches in https://requests.ci-train.ubuntu.com/#/ticket/1206
<robru> Saviq: OK well the new paradigm is that everything is a super simple shell script so i might be able to commit to an api in there and you could just invoke the shell script for the steps you need rather than having to have a full train deployment
<Saviq> robru, that's my thinking exactly
<Saviq> robru, btw, not sure if you saw my twist to inline gles: https://code.launchpad.net/~unity-team/qtmir/inline-gles-quilt/+merge/290061
<robru> Saviq: you apparently didn't see my review
<robru> ;-)
<Saviq> robru, :)
<Saviq> just noticed the wrong sed, too
<robru> Saviq: nice approach though. I wonder if it might make sense to just make the train do the quilt and then let packages supply their patches. From a security perspective it'd be nicer than running arbitrary scripts.
<Saviq> robru, https://code.launchpad.net/~unity-team/qtmir/inline-gles-quilt/+merge/290061/comments/743560
<Saviq> robru, I don't see a reason why not - the sed on changelog can be automated, too so
<Saviq> robru, one disadvantage would be for people to do it locally
<Saviq> they'd need to do the sed manually
<robru> Right
<robru> Hmm
<robru> Saviq: maybe write some docs about how you generated the patch in the first place? I find quilt strange and fiddly to work with.
<Saviq> robru, oh easy, export QUILT_PATCHES=debian/gles-patches; quilt new convert-to-gles.patch; quilt add debian/*; # do your thing; quilt refresh
<Saviq> robru, then, when you want to update: quilt push -af; # fix up; quilt refresh; quilt pop -a
<Saviq> robru, but yeah, I'll add something to the branch
<Saviq> especially on the "how to update" bit
 * Saviq found it frustrating that ~/.quiltrc takes precedence over QUILT_PATCHES to be honest
<robru> Saviq: maybe I'll leave it as a script since I already have the infrastructure for running hooks, and then if somebody can get away with just having a sed, they're not forced to use quilt at all.
<robru> Saviq: I should probably decouple this gles stuff from the giant monster branch I'm working on...
<Saviq> robru, can you change https://requests.ci-train.ubuntu.com/#/ticket/1206 to QA: N/A? it's only dumb packaging changes
<robru> Saviq: heh, ok
<robru> Saviq: why are you dropping the testsuite header from qtmir>
#ubuntu-ci-eng 2016-03-31
<Saviq> robru, the test was invalid - it was trying to rebuild qtmir, which is not what autopkgtests are for and caused us trouble now that britney runs per trigger and not all of proposed
<robru> ah
<Saviq> thanks, g'night!
<robru> Saviq: night
<michi> trainguards: I have a weird failure in a silo.
<michi> ppc64el fails, but there is no build log: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-006/+build/9419613
<michi> Anyone around who can help?
<robru> michi: no idea. I just hit retry in the hopes that it gives a log next time
<michi> Itâs also failed in silo 59, same story there.
<robru> Well that's troubling
<michi> Itâs clearly an infrastructure thing. All the other arches built fine.
<michi> Trying a rebuild...
<robru> michi: right but if it was a one off, it'd seem more likely to work on a retry. If there's consistent failures then we may need to escalate to Colin
<michi> Yeah
<michi> robru: When does Colin normally come online?
<michi> I donât see him right now.
<michi> Ah, no, heâs around...
<robru> michi: UK time officially but he's known to keep irregular hours
<michi> Well, that makes it around 1 am or so over there...
<robru> michi: anyway the retries have logs showing live, just a question of if it'll keep them after
<michi> Iâll keep an eye on them, thanks.
<michi> robru: This is not looking good: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-006/+build/9419741
<michi> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-059/+build/9419724
<robru> michi: huh beats me. Maybe try wgrant
<michi> wgrant: ^
<michi> Can you help?
<michi> cjwatson: In the unlikely case that you are still around, it looks like something is broken with the ppc64el builders for the train.
<wgrant> robru, michi: Looking.
<robru> Thanks
<bzoltan> jibel: popey: I have fixed the 35 silo, so it is fully OK - https://requests.ci-train.ubuntu.com/#/ticket/1095 If you want it on OTA10 please put it on a quick line to QA and see if it is good for you.
<slangasek> robru: why do the silo descriptions link to swift objects that aren't readable? (e.g. https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-066, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-1186/2016-03-30_07:49:08/xenial/qtmir/content.diff)
<robru> slangasek: because the artifacts are deleted when the silo lands
<slangasek> robru: that silo isn't landed; it's stuck in -proposed
<slangasek> robru: relatedly: why is the qtmir from that silo reported to no longer have any autopkgtests?
<robru> slangasek: the description says landed right there. Probably force merged
<slangasek> ok so who's force merging and why?
<slangasek> (why do we even still allow force merges?)
<robru> slangasek: Saviq asked me to force merge that one because it was stuck because of the same issue with dpkg breaking the packages to not run autopkgtests
<slangasek> This doesn't get to land.  Someone needs to take responsibility for the fact that the autopkgtests have gone missing from the source.  Saviq ? (the only one of the three landers currently online...) http://autopkgtest.ubuntu.com/packages/q/qtmir/xenial/amd64/
<slangasek> robru: what "same issue"?
<robru> slangasek: it passed qa and just needed a small follow-up silo to fix the packaging to get it through proposed
<robru> slangasek: the dpkg ftbfs in the backport ppa was meant to fix this
<slangasek> hmm
<robru> slangasek: instead Saviq started a new silo with packaging fixes that restore the autopkgtests
<slangasek> I am unclear how it's dpkg's fault that the source package has no debian/tests directory
<robru> slangasek: basically the autopkgtests were broken by my dpkg-buildpackage work because apparently vivid and newer automatically add the Testsuite: field but the trusty version doesn't
<slangasek> or why it's acceptable to force-merge things that need source fixes in order to get into xenial
<slangasek> robru: I just downloaded the source package from the archive; it has Testsuite: in the .dsc file
<slangasek> but there are no actual debian/tests in the source package
<robru> slangasek: Hmmmmmmm
<robru> slangasek: i didn't actually look at it, I'm just going off what pitti told me
<slangasek> $ pull-lp-source qtmir && grep Testsuite qtmir*.dsc
<slangasek> Testsuite: autopkgtest
<slangasek> $
<robru> slangasek: pull-lp-source? That'll grab what's in xenial, not the broken one stuck in proposed
<slangasek> nope
<slangasek> pull-lp-source pulls the latest, == -proposed
<robru> slangasek: so I'm just going off https://bugs.launchpad.net/bileto/+bug/1564084
<ubot5`> Launchpad bug 1564084 in Bileto "Does not automatically add "Testsuite:" header any more" [Undecided,New]
<robru> slangasek: and this is the silo Saviq put together to fix it: https://requests.ci-train.ubuntu.com/#/ticket/1206
<slangasek> robru: right, so that's unrelated to what has happened to qtmir
<slangasek> that bug reports a problem with a unity8 package, not with qtmir.  qtmir has the Testsuite header, autopkgtest tries to test it, and it fails because there are no tests in the source (and I can't see from the diff where they've gone)
<slangasek> robru: however, if this was the bug you had suggested "only affected unity8", then that should certainly not be the case
<robru> slangasek: https://code.launchpad.net/~saviq/qtmir/drop-testsuite-header/+merge/290468
<slangasek> robru: where did the *tests* go?
<robru> slangasek: Saviq said somewhere they were no good so he got rid of them.
<slangasek> hmm
<robru> slangasek: anyway ticket 1206 is supposed to fix everything and make everybody happy
<slangasek> ok, then dropping the testsuite header is correct in that case
<slangasek> well, it does not make me happy to have fewer tests ;)
<robru> slangasek: it could have been rebuilt in the same old silo instead of force merging but he didn't want to re-qa the whole thing since it was already approved.
<robru> slangasek: from what he said it sounded like the tests had no value, or negative value (eg flaky tests that didn't actually test anything meaningful)
<robru> slangasek: I can't remember, I think it's in the scrollback in this channel if you look ~5 hours back
<slangasek> robru: ok; so I've found the packaging diff and I don't see how Saviq justifies the claim that the tests were no good
<slangasek> certainly not to where dropping them is better than keeping them
<slangasek> and if we're force-merging because a one-line update to debian/control requires a complete QA re-test, then isn't that a bug in the QA workflow?
<robru> slangasek: well if the silo is rebuilt for any reason it clears the qa approval
<slangasek> i.e., either a rebuild with no changes to the upstream source requires a full QA retest, or it doesn't - regardless of it's done in this silo or another
<robru> slangasek: bileto doesn't know that somethings' being rebuilt for a one line change or even for a no-line change
<slangasek> sure
<slangasek> but the lander can tell QA, and QA and rubberstamp
<robru> right
<robru> slangasek: anyway, I think the force-merge is sort of a red herring here, sure it's suboptimal but the real issue is just that you don't approve of the tests being deleted. which I think you should take up with Saviq since I'm not really familiar with why they're being dropped
<robru> slangasek: I can't seem to find the message, I thought it was IRC, maybe it was an MP comment or something somewhere
<slangasek> robru: no, I don't approve of the tests being deleted, *AND* I don't approve of things being force-merged and left in xenial-proposed
<robru> slangasek: I was under the impression that it's ok to force merge when things are stuck as long as people promise to keep an eye on it, and in this case Saviq has a new silo to fix this already prepped, so it seemed ok to me
<slangasek> robru: hmm; I wasn't aware that was the accepted practice - at this point in the release cycle, it does mean e.g. release team members going on wild goose chases in update_excuses
<robru> slangasek: how does force merge impact release team people? stuff sitting in proposed would look the same to them regardless of if the ticket is merged or not? I don't see the big deal with force merging really since it just means trunk is slightly ahead of distro for a short while. sometimes if there's two conflicting silos and one is being a little slow to
<robru> migrate I'll get asked for force merge so that the other silo can be rebuilt sooner, eg, to unblock people wanting to land conflicting silos.
<robru> slangasek: it's not an every-day thing but it happens sometimes when people are rushing to get OTAs out the door.
<slangasek> robru: hmm, perhaps it's marginal and you should ignore my late-night rant :) but it took extra time to track down the landing because it was force-merged, so it was no longer listed on requests.ci-train.u.c
<robru> slangasek: no i think your concerns are justified, there's definitely gaps in the discoverability of information in the system. just needs some iterations here and there
<popey> bzoltan: Thanks. i haven't tested a silo for a while, what's the easiest way for me to test that on a device?
<bzoltan> popey: I think that /usr/bin/citrain device-upgrade 35 [DEVICE-PASSWORD] is the easiest way
<popey> thanks
<tvoss> Mirv, for reference: https://code.launchpad.net/~thomas-voss/platform-api/build-modules-as-shared-libraries/+merge/290571
<Mirv> tvoss: oh, ok!
<popey> bzoltan: jibel silo 35 works for me.
<bzoltan> popey: Cool. The Automated Signoff is running, after that i think the packages can be released to xenial  too
<bzoltan> jibel: popey: ready to land https://requests.ci-train.ubuntu.com/#/ticket/1202
<popey> sweet!, thanks bzoltan
<bzoltan> popey:  with pleasure .. nice to fix bugs quickly
<popey> bzoltan: i see rvr has a problem with that landing
<popey> bzoltan: https://trello.com/c/nGHexJw8/3001-1202-ubuntu-landing-035-ubuntu-ui-toolkit-bzoltan
<popey> rvr: any chance you can put videos on people.canonical.com rather that private share, as they're inaccessible to community people. ta
<rvr> popey: I have problems accessing people, bad ssh config or something
<rvr> I'll try to fix
<bzoltan> rvr: popey: is that indicator color issue somehow related to this silo35?
<ahayzen> bzoltan, i think Tim's fix was just for MainView's .. that probably comes from Unity8 itself ? I think... and was there before silo035
<bzoltan> ahayzen:  indeed
<bzoltan> ahayzen: I can spend some time with checking how unity is using palette values, but not with this silo
<bzoltan> ahayzen: i would need a day to go thru all the color settings in unity
<ahayzen> yeah sounds like a separate issue to this one, silo035 was trying to fix the colours on app launch not todo with the shell
<jibel> tvoss, did you publish 33?
<tvoss> jibel, nope, do I need to?
 * sil2100 is on it
<jibel> thanks
<sil2100> https://code.launchpad.net/~thomas-voss/location-service/fix-1447110/+merge/289979
<sil2100> Needs approval
<sil2100> tvoss: ^
<tvoss> sil2100, ack
<tvoss> ssweeny, mind top-approving: https://code.launchpad.net/~thomas-voss/location-service/fix-1447110/+merge/289979
<ssweeny> tvoss, done
<tvoss> sil2100, ^
<rvr> bzoltan: Silo 35 approved
<sil2100> \o/
<sil2100> Publishing that as well
<sil2100> bzoltan: ^
<ahayzen> \o/
<sil2100> bzoltan: please review https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/fasterWindowColorTrunk/+merge/290458 and https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/cherry_pick-gles/+merge/290461
<sil2100> Eh
<sil2100> Publishing forcing the unapproved branches
<sil2100> We don't have time to spare
<tvoss> ssweeny, would you mind if we take https://requests.ci-train.ubuntu.com/#/ticket/1104 prior to your ls landing?
<ssweeny> tvoss, go right ahead :)
<sil2100> jibel, robru, rvr: I guess we cancel the LT meeting since we have the status meeting at the same time, right?
<sil2100> Or maybe we do both at once!
<jibel> sil2100, yeah, I didn't plan to attend the landing meeting
<jibel> it's a bit redundant
<pmcgowan> sil2100, jibel should be quick
<pmcgowan> sil2100, whats up with silo 68, its not publishing due excuses
<pmcgowan> trainguards can you check silo 68? does someone just need to push it?
<robru> pmcgowan: according to britney the android package has unsatisfiable depends but somehow QA approved it anyway.
<robru> pmcgowan: but yeah this doesn't block publication, if somebody wants to publish it they can
<pmcgowan> robru, this happened with something the other day and we just published
<pmcgowan> robru, who can publish it?
<robru> pmcgowan: any core dev can do it
<pmcgowan> that again :)
<pmcgowan> I nominate you for core dev
<pmcgowan> mterry, ?
<robru> pmcgowan: yeah that's on my to-do list but it's been getting away on me, sorry
<robru> ken is mysteriously not here, he's my go-to core dev
<mterry> pmcgowan: maybe...?  robru, what's the story with unsatisifable depends?
<robru> mterry: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-068/excuses.html but I dunno, i guess android package is special
<pmcgowan> mterry, this same thing happened with a silo the other day and ken just pushed it in
<pmcgowan> but I dont know why
<mterry> the hidden assumption there being that that was the right thing to do?
<pmcgowan> seemed to be, somehow ken knew it was bogus, but I really dont know
<robru> mterry: I see it this way: this silo isn't actually introducing the unsatisfiable depends (if you look at the diff), so I guess it's a false positive in britney or eg I guess the image builder just pulls it in regardless of the depends or something
 * mterry is going throught that silo's packaging diffs and then if nothing crazy, is happy to publish
<robru> mterry: yeah you should be reviewing diffs before publishing generally ;-)
<dobey> hrmm
<robru> mterry: https://requests.ci-train.ubuntu.com/#/ticket/995
<dobey> robru: i think it's because the autopkgtests environments don't have multi-arch on maybe? if i install "ubuntu-emulator-runtime" on my machine, it pulls in the :i386 one
<mterry> robru: uh.. android-tools-5.1.1r36+git20160322/debian/android-tools-adb.postinst does some crazy stuff, including modifying the current user's (whoever that might be when installing!) ~/.android/adb_usb.ini...
<robru> mterry: isn't postinst just run by root?
<mterry> robru: if you're running sudo, I'm guessing $HOME is still your user
<dobey> eww
<dobey> that is nasty
<robru> it's clearly just appending device IDs so that they work without clobbering the existing file
<mterry> robru: or creating the file
<mterry> robru: that's against policy though, to muck with user files.  I think we do it in very few cases.  But usually we have user-migration scripts to do that in a sane way
<dobey> and that obviously doesn't help other users on the system who aren't the one running the apt-get install/upgrade
<mterry> robru: er session-migration
<mterry> robru: This should use a session-migration script, not muck with files directly.  I can't ACK this
<robru> mterry: hang on, something funny is going on. I can't find this postinst script in the input mp.
<dobey> android-tools isn't managed in launchpad
<dobey> the indicator mp obviously won't have it
<robru> oh, manual packages. great
<dobey> yup
<dobey> i don't understand why that wasn't done in a patch though, instead of a hacky postinst
<robru> morphis: what's up with android tools? ^^
<dobey> the comment even claims the source has some list compiled into the default client; obviously we should be patching that list
<mterry> dobey: agreed
<dobey> ondra just left though i think
<pmcgowan> I don't even think thats true
<dobey> which part?
<pmcgowan> things work fine without those
<pmcgowan> I thought they were added elsewhere
<dobey> without the adb_usb.ini ?
<pmcgowan> yeah
<pmcgowan> BQ and Meizu is not exactly new to us
<dobey> oh they were
<dobey> +++ android-tools-5.1.1r36+git20160322/debian/patches/add-bq-vendor-id.patch	1970-01-01 00:00:00.000000000 +0000
<dobey> so someone needs to regeenrate a source package without the postinst muck, and re-upload to the silo ppa for both xenial/vivid
<dobey> (i don't have permissions to upload to the PPA)
<pmcgowan> who does?
<pmcgowan> I can email ondrej as he said he would be back online later
<dobey> i presume robru does. mterry does as well i guess, being a core dev
<dobey> mterry: ^^ can you strip that postinst muck out and tweak the version numbers, and re-upload to the PPA?
<robru> pmcgowan: yes for silo PPA uploads, it's core devs + me
<robru> but best let mterry do it so he can get it just right I think ;-)
<mterry> dobey: so...  looks like the old patch got dropped, but the new IDs are still in the merged debian-changes
<mterry> dobey: so I agree I'm not sure why the postinst stuff was done...
<mterry> pmcgowan: morphis is best to do this, is he not around?
<pmcgowan> mterry, dont know we can wait if its best
<dobey> probably best to know who did that change exactly, and why
<mterry> pmcgowan, robru: this is why I hate this "packaging-ACK" system -- last minute NACKs suck
<pmcgowan> indeed
<dobey> mterry: agreed
<robru> mterry: totally agree, but I can't think of a way to get the ACKs coming sooner. there's no way to stop people making mistakes until they try to publish
<mterry> dobey: well....  worst case if we strip out the bogus postinst stuff is that there is some manual config needed on dev machines.  But we won't break anything.  And that can be fixed by future patch...
<mterry> robru: unity8 has a merge checklist, one of which is getting a packaging ACK if there are packaging changes.  Hard to FORCE that on other projects, but they should all be doing that
<robru> mterry: agreed, should we talk to upper management and get this enforced on all projects? ;-)
<dobey> mterry: well, the IDs seem like they are still added. the diff just looks a little weird because the patches all have the source dir with version in them as the reference
<dobey> but maybe i read the diff wrong too
<dobey> who knows
<mterry> dobey: I agree they look like they are still added.  I'm just confused that the postinst stuff was added in first place.  So if our first blushes are correct, removing postinst bits is harmless.  If we're wrong, at worst some devs have to add some manual bits until someone can correct better...
<mterry> So I'm just going to do the quick change and hope it is enough
 * mterry patches
<dobey> mterry: well if the ID patches are required for existing phones, and they are in fact removed, i guess it will break adb for all the current devices too
<mterry> dobey: true...  not just dev machines but like all our test tooling  :)
<dobey> mterry: but i guess it will be easier to tell if the patches are still there in an unpacked tree, too
<mterry> dobey: I'll try it on my phones here at least
<dobey> ok
<dobey> if krillin still works, i guess it should be good
<dobey> robru: fwiw, i /hate/ the checklist thing on unity8
<dobey> would be nice to automate most of that work though
<mterry> dobey: oh why?
<mterry> dobey: ok...  recompiled locally, installed new adb.  did adb kill-server, made sure I didn't have my own ~/.android/adb_usb.ini...  Was able to get into both krillin and arale
<mterry> dobey: I guess that's good enough
<mterry> robru, pmcgowan: new android-tools for xenial & overlay are building in silo 68
<robru> mterry: thanks
<mterry> Packaging for everything else seemed fine enough
<robru> mterry: right, android was the one blocked by unsatisfiable depends, so that one was ok after all
<dobey> mterry: i find the whole concept of "copy and paste this big block of text into your MP and answer all the questions" a bit insulting really.
<mterry> dobey: eh I like it as a simple way to avoid forgetting things
<mterry> dobey: I'm a forgetful person  :)
<dobey> mterry: i like "make check" as a simple way of not forgetting things :)
<pmcgowan> mterry, awesome thanks
<dobey> i don't know if there are tools for covering all parts of the debian policy, but would be nice to automate some of the stuff that we require a packaging ACK for, when it is possible
<mterry> dobey: heh, snapshot the system before, if there are any deltas in $HOME, complain.  Repeat for all possible contents of $HOME  :)
<mterry> dobey: or I suppose just grep for ~ or $HOME in a clever way in debian/
<dobey> mterry: grep HOME debian/*.postinst seems easier
<dobey> heh
<mterry> dobey: but you won't catch malicious people assembling variable names out of H, O, M, and E, who just want to write code and hate your checker
<dobey> mterry: or encode it into some lintian check if there isn't one already
<dobey> well, we should fire those people :P
<mterry> dobey: yeah... but how to fire them automatically...?  :P
<dobey> mterry: like this: https://www.youtube.com/watch?v=Km6bFBSVty4
 * mterry dusts off his fax machine
<dobey> i guess we should also maybe have an apparmor rule that prevents dpkg scripts from screwing with $HOME
<dobey> whoot
<dobey> huh
<dobey> mterry: i still see the postinst block in the xenial packaging diff
<dobey> err, no
<dobey> vivid
<dobey> no, both
<mterry> dobey: do you see a new changelog entry by me?
<dobey> no
<mterry> dobey: the packages aren't "published" in that PPA yet
<mterry> dobey: I don't know what queuebot is on about
<dobey> oh
<dobey> hmm
<dobey> ah ok
 * mterry regenerates silo diffs
<mterry> pmcgowan, robru: so I'm guessing you need to re-acquire QA signoff on silo 68?  Probably a quick smoketest to make sure it's still working is enough?  Tell QA folks to rm ~/.android/adb_usb.ini, run "adb kill-server" and then try to adb into their device to confirm the change is OK.
<robru> ToyKeeper: jibel: ^
<mterry> dobey: chagnes regenerated
<pmcgowan> mterry, thanks
<dobey> great
<pmcgowan> mterry, is the whole silo rebuilding?
<mterry> pmcgowan: shouldn't be?  I did a diff-regeneration-only build, but that said it finished
<pmcgowan> great
<robru> mterry: ok I commented on the ticket & the trello board, hopefully qa notices that soon enough
<ToyKeeper> D'oh.  New adb silo isn't done after all?
<ToyKeeper> ... and the suggested test will break some other things I have running.  I may want to wait a bit until the other tests finish.
<pmcgowan> ToyKeeper, its a "really simple change" but prefer to sanity check
<robru> Saviq: if you get a sec pls review https://code.launchpad.net/~robru/qtmir/inline-gles-quilt/+merge/290646
<robru> ToyKeeper: "Tell QA folks to rm ~/.android/adb_usb.ini, run "adb kill-server" and then try to adb into their device to confirm the change is OK."
#ubuntu-ci-eng 2016-04-01
<Mirv> tvoss: you'll need to include the changelog entries for no-change rebuilds https://launchpad.net/ubuntu/+source/location-service/3.0.0-0ubuntu3 and https://launchpad.net/ubuntu/+source/location-service/3.0.0-0ubuntu4 in your MP:s changelog and have your UNRELEASED changelog entry be ubuntu5
<tvoss> Mirv, ack
<pmcgowan> jibel, can we mark 68 approved and get it published?
<jibel> pmcgowan, we are waiting u-d-f to publish it at the same time
<pmcgowan> jibel, is someone working on udf?
<pmcgowan> mterry, ok can we publish silo 68 now?
<mterry> pmcgowan: ah it got QA approval again?  sure let me look
<pmcgowan> mterry, yep and the u-d-f tool is available now
<mterry> pmcgowan: ?  I don't remember that
<pmcgowan> mterry, they go together
<pmcgowan> if you want to flash with new adb setup
<pmcgowan> that comes out of the phablet PPA
<mterry> pmcgowan: publishing
<pmcgowan> great
<sil2100> Mirv: hey! You still around? :)
<sil2100> Mirv: we would need someone with ubuntu-sdk-team permissions to do some binary package copies
<sil2100> huh
<sil2100> A lot of internal errors in bileto I see
<pmcgowan> mterry, seems that silo got stuck maybe
<ogra_> shake it
 * pmcgowan shakes silo 68
<cjwatson> sil2100: can we retry?  there seems to have been some kind of network blip affecting LP
<cjwatson> but things look OK at the moment
<sil2100> hm, let me do that
<sil2100> pmcgowan: well, silo 68 is good, don't worry
<sil2100> pmcgowan: all the packages are in the overlay, some of the packages are in UNAPPROVED since xenial is frozen
<pmcgowan> sil2100, great thanks
<sil2100> Some release team member will approve those
<sil2100> jibel, pmcgowan: eh, found the bug that was causing us missing the ubuntu-settings-components translations for the VPN view...
<pmcgowan> oh
<sil2100> jibel, pmcgowan: testing a fix right now, but it seems we weren't merging the mapping files from translation tarballs properly
<sil2100> So we'll have to re-spin langpacks once I check my fix locally
<sil2100> Which means we'll have new langpacks in a bit today
<sil2100> (I'll copy them over to the snapshot later)
<Mirv> sil2100: o/
<Mirv> sil2100: tell me
<sil2100> Mirv: yay! Soooo, we would need *binary* copies of the https://launchpad.net/~phablet-team/+archive/ubuntu/tools goget-ubuntu-touch package (the one from xenial) into xenial, wily and trusy in the stable SDK ppa (https://launchpad.net/~ubuntu-sdk-team/+archive/ubuntu/ppa)
<sil2100> Mirv: those have to be *binary* copies
<sil2100> Mirv: so just taking the xenial package of goget-ubuntu-touch and copying it with binaries to xenial, wily and trusty (yes, using the same versioning and same contents ;p)
<sil2100> As the package will not build in normal environments
<Mirv> sil2100: ok
<Mirv> sil2100: sorry, might take a few mins, need to sort something out
<sil2100> Mirv: could I also ask you to dput two packages there as well? I'll give you all the source bits
<sil2100> As my dputs obviously failed as I have no permissions to upload there
<sil2100> :<
<Mirv> sil2100: sure just queue them to my "I can type with my laptop's keyboard" queue :)
<sil2100> Thanks!
<sil2100> Mirv: the two packages in mention are here http://people.canonical.com/~lzemczak/packaging/
<Mirv> sil2100: hmm weird, it does not allow binary copying xenial package to wily/trusty, see errors https://launchpad.net/~ubuntu-sdk-team/+archive/ubuntu/ppa/+packages - unless it's because as it states "already building" since it's building the armhf version since the other PPA had only x86
<sil2100> hmmm
<sil2100> Mirv: what errors do you get? I guess it might be a strange case here
<sil2100> Let's wait for it to fail building for those and then try the bin-copy again
<Mirv> sil2100: look at the top of the page for the errors, I didn't clear them
<sil2100> Ah, indeed!
<Mirv> sil2100: I mean, normally I think it has been just fine to have exact same version number, but for a different series
<Mirv> (in PPA)
<sil2100> Yeah
<sil2100> That's what we have in the phablet tools PPA
<sil2100> One package with the same version for different series
<sil2100> It's bad practice but this is the only way we can make it work here
<sil2100> pmcgowan, jibel: new language-packs are building
<Mirv> sil2100: ah, hmm
<Mirv> sil2100: let me try copying inside the same PPA the now already copied one
<sil2100> pmcgowan, jibel: once those finish, how about we kick a new rc-proposed image?
<sil2100> Mirv: oh
<sil2100> Mirv: ok, maybe that will somehow work better
<Mirv> sil2100: well it "worked", I mean I was just trying because that what I've done earlier. but it only worked for wily because the armhf build for xenial had already failed, so indeed I need to wait for the armhf build before I can do the next :) so completing with trusty in 5 mins or so
<Mirv> sil2100: meanwhile uploaded the two android-tools packages
<pmcgowan> sil2100, sounds good
<Mirv> sil2100: android-tools trusty failed because of missing build dependency libsystemd-dev. wily succeeded.
<sil2100> Mirv: thanks! Ok, we'll try to solve that somehow, hmmm
<sil2100> We'll maybe have to tweak the package a bit, not just a brainless copy
<Mirv> sil2100: this was the tools package, for which you provided a source, not to goget-ubuntu
<sil2100> Yeah, I know :)
<sil2100> It was a brainless source copy, just changing the version I did
<Mirv> sil2100: ah, right :)
<Mirv> sil2100: I tried changing it to libsystemd-dev | libsystemd-daemon-dev, but the next build problem then is selinux related http://pastebin.ubuntu.com/15577772/ at least locally
<Mirv> tried uploading that now too but indeed probably needs some small code changes
<Mirv> sil2100: anyhow, goget-ubuntu-touch is now all done, and the android-tools wily
<sil2100> Mirv: thank you!
<sil2100> Mirv: ok, don't worry about android-tools, I got a green light to do a bin-copy - and now I have the powers to do that
<sil2100> Mirv: thanks again!
<Trevinho> sil2100: anyone who can publish https://requests.ci-train.ubuntu.com/#/ticket/1153 ?
<sil2100> Trevinho: will do in a moment
<Trevinho> sil2100: thanks
<Saviq> robru, you should rm .pc/
<Saviq> *not*
<robru> Saviq: nope, that has to go
<Saviq> meh, why's it a problem? debhelper/dpkg thinks quilt is in play?
<robru> Saviq: otherwise it gets included in the orig.tar which is horrible and wrong
<robru> Saviq: and then all your packaging diffs are going to start including these huge .pc blobs of horribleness
<Saviq> meh, just means you can go back when you unpack the tarball
<Saviq> right, that
<robru> Saviq: why would you want to go back? the -gles is produced in parallel with the regular one, so you always have both
<Saviq> robru, I rather mean during dev, but mah
<robru> Saviq: you can always bzr revert
<Saviq> yeah exactly
<robru> Saviq: the .pc dir is an implementation detail that really shouldn't be leaked out of the script
<Saviq> and find -name '*~' -exec rm {} + :P
<Saviq> whoever thought it would be a good idea to leave all those *~ files around after a revert...
<Saviq> robru, did you come up with a way to skip the test on gles?
<robru> Saviq: I just reverse-apply the patch at the start of the test so that -gles and nongles both run the test from the same start point
<robru> Saviq: it seems to have worked but now the tests fail at some other point I don't understand, can you look? https://launchpadlibrarian.net/250718484/buildlog_ubuntu-xenial-amd64.qtmir-gles_0.4.8+16.04.20160401-0ubuntu1_BUILDING.txt.gz
<Saviq> robru, Gerry replied via email, we'll have to look into it Monday
<robru> oh alright
<Saviq> robru, TBH I'd rather skip the test in gles rather than reverse-apply - because you end up with a different source tree after testing
<robru> Saviq: right, I'll fix that
<Saviq> a simple head debian/changelog | grep -q 'gles' or something
<robru> Saviq: but actually, are you sure the test is needed? because if the patch fails to apply then the source package build will fail in the train, you'll find out within a few minutes of clicking build.
<Saviq> robru, in CI we're not yet building gles
<robru> hmm
<Saviq> robru, and people running tests locally
<robru> fair
<robru> bbl, lunch
<sil2100> Goodnight o/
#ubuntu-ci-eng 2017-03-27
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2644 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/2644 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2644 Successfully built
-queuebot:#ubuntu-ci-eng- chunsang abeato, https://bileto.ubuntu.com/#/ticket/2593 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2611 Generating diffs
-queuebot:#ubuntu-ci-eng- chunsang abeato, https://bileto.ubuntu.com/#/ticket/2593 Publishing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2645 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/2645 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2645 Cancelling build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2645 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2646 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- abeato, https://bileto.ubuntu.com/#/ticket/2518 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2646 Generating diffs
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 zesty/mir: Failed to merge https://code.launchpad.net/~raof/mir/mesa-hybrid-output
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2611 Successfully built
-queuebot:#ubuntu-ci-eng- chunsang abeato, https://bileto.ubuntu.com/#/ticket/2593 Proposed pocket (zesty/media-hub). Release pocket (xenial/media-hub)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir-gles). Ready to build (xenial/mir, zesty/mir). Successfully built (xenial/qtmir, xenial/unity-api, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api, zesty/unity8)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2646 Successfully built
-queuebot:#ubuntu-ci-eng- chunsang abeato, https://bileto.ubuntu.com/#/ticket/2593 Release pocket
-queuebot:#ubuntu-ci-eng- abeato, https://bileto.ubuntu.com/#/ticket/2518 Needs rebuild due to higher version at destination (xenial/media-hub). Needs rebuild due to new commits (zesty/media-hub)
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2647 Preparing packages
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Preparing packages
-queuebot:#ubuntu-ci-eng- bzoltan, https://bileto.ubuntu.com/#/ticket/2647 Successfully built
-queuebot:#ubuntu-ci-eng- michi jamesh, https://bileto.ubuntu.com/#/ticket/2607 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Destination version missing from changelog (zesty/qtubuntu-print). Pending binary packages (xenial/ubuntu-printing-app, zesty/ubuntu-printing-app). Successfully built (xenial/qtubuntu-print, xenial/unity8-desktop-session, zesty/unity8-desktop-session)
<vigo> Laney, ping
<vigo> I'm taking 2629, should it work in kvm or does it need to be verified on bare metal?
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2648 Preparing packages
<Laney> vigo: Don't know, I was only involved at the edges - try asking boiko / renatu
<vigo> Laney, ack
<vigo> renatu, ping ^
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Preparing packages
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Preparing packages
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Destination version missing from changelog (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Successfully built (xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/unity8-desktop-session, zesty/unity8-desktop-session)
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 zesty/mir: Failed to commit https://code.launchpad.net/~aacid/mir/noChangeRebuild. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2648 Pending binary packages
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2616 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2616 zesty/compiz: Failed to commit https://code.launchpad.net/~ubuntu-mate-dev/compiz/fix-1611797. 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/2616 Preparing packages
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2648 Successfully built
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Needs rebuild due to new commits (zesty/unity8). Pending binary packages (zesty/qtmir). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity8, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Preparing packages
<renatu> vigo, hi, yes I was testing it on kvm. but boiko or tiago can give you more details
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2650 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Needs rebuild due to higher version at destination (xenial/mir, zesty/mir). Pending binary packages (xenial/qtmir, zesty/qtmir). Successfully built (xenial/miral, xenial/qtmir-gles, zesty/miral, zesty/qtmir-gles)
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2651 QA Signoff: Ready
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2616 Successfully built (zesty/unity). Uploading build (zesty/compiz)
<vigo> renatu, https://trello.com/c/9Kp1IFda/4082-2629-2629-messaging-framework-tone-generator-messaging-app-indicator-transfer-buteo-history-service-ubuntu-system-settings-onlin
<renatu> vigo, try install "account-plugin-sip-unity8" and "account-plugin-irc-unity8" it should allow you to create the accounts
<vigo> renatu, messaging-app crashes with the silo installed, just tried without it and workd
<vigo> works*
<renatu> vigo, I will try install it to help you. Until boiko appears. He probably now better about it
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Needs rebuild due to higher version at destination (xenial/mir, zesty/mir). Successfully built (xenial/miral, xenial/qtmir, xenial/qtmir-gles, zesty/miral, zesty/qtmir, zesty/qtmir-gles)
<vigo> renatu, ack, thanks!
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2616 Successfully built
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Needs rebuild due to burned version number
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Preparing packages
<boiko> vigo: hello
<renatu> vigo, looks like the zesty problem is a known issue. boiko can tell more about that
<boiko> vigo: tiago was testing on zesty and it seems things are not working very well there yet
<boiko> vigo: what problem are you seeing exactly?
-queuebot:#ubuntu-ci-eng- ahayzen jgdx, https://bileto.ubuntu.com/#/ticket/2605 Proposed pocket (zesty/ubuntu-system-settings). Release pocket (xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/ubuntu-system-settings, xenial/ubuntu-ui-extras, zesty/qtubuntu-print, zesty/ubuntu-printing-app). UNAPPROVED queue (zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Pending binary packages (zesty/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Destination version missing from changelog (zesty/qtubuntu-print). Pending binary packages (xenial/ubuntu-printing-app, zesty/ubuntu-printing-app). Successfully built (xenial/qtubuntu-print, xenial/unity8-desktop-session, zesty/unity8-desktop-session)
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2652 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir-gles). Needs rebuild due to new commits (zesty/unity8). Ready to build (xenial/mir, zesty/mir). Successfully built (xenial/qtmir, xenial/unity-api, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2646 Generating diffs
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Preparing packages
<rvr> renatu: Silo approved
<rvr> renatu: I filed a bug for this https://bugs.launchpad.net/canonical-devices-system-image/+bug/1676428
<ubot5> Ubuntu bug 1676428 in Ubuntu File Manager App "Breadcrumb path updates when trying to access a prohibited folder" [Undecided,New]
<renatu> rvr, thanks
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2562 QA Signoff: Approved
<rvr> renatu: There is a problem somewhere with Unity8 dialogs, as clicking to "Open" after downloading an image with the webbrowser doesn't fully open filemanager-app
<rvr> I see crashes
<renatu> rvr, zesty or xenial?
<rvr> renatu: Zesty
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Destination version missing from changelog (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Successfully built (xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/unity8-desktop-session, zesty/unity8-desktop-session)
<renatu> rvr, strange that was working during our tests. But could you report a but about that. I will try to take a look later
<rvr> renatu: Ack
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2639 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Preparing packages
<rvr> renatu: https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1676434
<ubot5> Ubuntu bug 1676434 in Ubuntu File Manager App "Downloading an image from webbrowser-app doesn't open filemanager-app" [Undecided,New]
<renatu> rvr, thanks again
<renatu> rvr, humm I think kenvandine has fixed that bug already. kenvandine could you confirm that ^^^
-queuebot:#ubuntu-ci-eng- michi jamesh, https://bileto.ubuntu.com/#/ticket/2607 Publish failed: Packaging diff requires ACK
<alan_g> ubuntu-qa: Fixed forgotten TA for 2641. (Sorry!)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2646 Successfully built
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Failed to build (xenial/mir, xenial/qtmir, xenial/qtmir-gles, xenial/unity-system-compositor, zesty/mir, zesty/qtmir, zesty/qtmir-gles, zesty/unity-system-compositor). Pending binary packages (xenial/miral, zesty/miral)
<davmor2> alan_g: thanks in the queue
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2652 Pending binary packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2639 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- michi jamesh, https://bileto.ubuntu.com/#/ticket/2607 Successfully built
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Failed to build (xenial/mir, xenial/qtmir, xenial/qtmir-gles, xenial/unity-system-compositor, zesty/mir, zesty/qtmir, zesty/qtmir-gles, zesty/unity-system-compositor). Successfully built (xenial/miral, zesty/miral)
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2652 Successfully built
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 QA Signoff:
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Needs rebuild due to new commits (zesty/ubuntu-terminal-app). Successfully built (xenial/ubuntu-terminal-app)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Needs rebuild due to new commits (zesty/qtubuntu). Pending binary packages (xenial/qtmir, xenial/qtmir-gles). Successfully built (xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu-gles, zesty/unity8)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Currently building (xenial/unity8, zesty/unity8). Failed to build (xenial/qtmir-gles). Ready to build (xenial/mir, zesty/mir). Successfully built (xenial/qtmir, xenial/unity-api, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api)
<vigo> boiko, hi, well messaging-app crashes for me and uss-online accounts hangs forever if I click on any account
<vigo> boiko, so better move to xenial right?
<boiko> vigo: even trunk messaging-app is giving some crashes here, so salem_ and I are debugging those, but if you want to start testing already, xenial+overlay is better indeed
<vigo> boiko, ack
<boiko> vigo: I have updated the silo's testing instruction with the packages needed to test, sorry I didn't include those before
<vigo> boiko, np, thank you
<vigo> :)
<boiko> renatu: have you seen this spinning forever in online accounts?
<renatu> boiko, no this is working for me
<boiko> renatu: even on zesty?
<renatu> yes
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Needs rebuild due to new commits (zesty/qtubuntu). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu-gles, zesty/unity8)
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Preparing packages
<boiko> vigo: just curious, were you testing on a native environment or on a vm?
<vigo> boiko, I'm using kvm
<vigo> boiko, http://pastebin.ubuntu.com/24261223/
<boiko> vigo, yep, we got the crash here, just having a hard time to get a useful backtrace :/
<vigo> when I click the group button a window shows up saying that is not pÃ²ssible sending messages atm
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir-gles). Pending binary packages (xenial/unity8, zesty/unity8). Ready to build (xenial/mir, zesty/mir). Successfully built (xenial/qtmir, xenial/unity-api, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api)
<vigo> boiko, can you see that?
<boiko> salem_: ^
<boiko> vigo: would you mind pasting (preferrably in private) the output of mc-tool dump?
<salem_> vigo, yes, if you have no accounts, or if no accounts are connected it is expected to see that message.
<vigo> salem_, I've got the acccount added in uss
<vigo> how can I check if it is correctly connected?
<salem_> vigo, you can check with "mc-tool dump"
<boiko> vigo: I'll forward your paste to salem_, ok?
<vigo> boiko, np
<boiko> vigo: can you just enter the onine account and see if the messaging-app checkbox is enabled?
<salem_> vigo, if you are using ssl, you have to change the default port to 6697. So either disable ssl for testing, or change the default tcp port.
<vigo> boiko, sure it is, just checked again
<boiko> vigo: ok, thanks
<boiko> vigo: just in case :)
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Failed to build (xenial/mir, xenial/qtmir, xenial/qtmir-gles, zesty/mir, zesty/qtmir, zesty/qtmir-gles). Pending binary packages (xenial/unity-system-compositor). Successfully built (xenial/miral, zesty/miral, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Needs rebuild due to new commits (zesty/unity8). Pending binary packages (xenial/qtubuntu, xenial/qtubuntu-gles, zesty/qtubuntu, zesty/qtubuntu-gles). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir-gles). Ready to build (xenial/mir, zesty/mir). Successfully built (xenial/qtmir, xenial/unity-api, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api, zesty/unity8)
<vigotron> vigo, test 1,2
<vigotron> boiko, working now
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Preparing packages
<vigo> bfiller, ping
<vigo> just watched your comment, thank you
<vigo> I'm using a xenial vm where irc worked fine
<bfiller> vigo, hi
<bfiller> vigo, the silo I mentioned is only needed on zesty when trying to create an online account from within the app (which seems broken anyway) but still need that silo to test
<bfiller> vigo, if you create the online account directly from system-settings it's working
<kenvandine> renatu, i don't know about the filemanager bug on downloads
<vigo> bfiller, that's what I was about to say, it crashes for me hehe
<kenvandine> renatu, but maybe your branch fixes that
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2562 Publishing packages
<renatu> kenvandine, this is because the ual was trying to launch the apps as X11. I remember that you fixed that
<bfiller> vigo, seems messaging-app on zesty has some crashes that we are debugging. Dialer with voip on zesty should be working though
<kenvandine> oh
<kenvandine> i think UAL fixed that
<vigo> bfiller, ack, thank you
<kenvandine> does other apps work?
<bfiller> kenvandine, renatu maybe it needs 2636
<bfiller> with the trust prompt fixes
<bfiller> that hasn't landed yet
<kenvandine> yeah
<kenvandine> likely
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Failed to build (xenial/mir, xenial/qtmir, xenial/qtmir-gles, zesty/mir, zesty/miral, zesty/qtmir, zesty/qtmir-gles). Pending binary packages (xenial/miral). Successfully built (xenial/unity-system-compositor, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2562 NEW queue (zesty/ubuntu-filemanager-app). Release pocket (xenial/ubuntu-filemanager-app)
<boiko> vigo: nice it works!
<boiko> vigo: bfiller: forgot to add one package to the list of required ones: telepathy-rakia
<boiko> as it doesn't come from the silo I totally forgot about that one
<boiko> vigo: sorry about that, was so focused on messaging-app that I forgot that one is needed for dialer-app
<vigo> boiko, \o/
<vigo> np :)
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Failed to build (xenial/mir, xenial/qtmir, xenial/qtmir-gles, zesty/mir, zesty/miral, zesty/qtmir, zesty/qtmir-gles). Successfully built (xenial/miral, xenial/unity-system-compositor, zesty/unity-system-compositor)
<vigo> boiko, as soon as I installed it, started to work
<vigo> :)
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2625 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2625 Failed to build
<rvr> oSoMoN: Do you know why Amazon webapp doesn't launch in Unity8? (zesty)
<oSoMoN> rvr, no
<vigo> boiko, ping
<vigo> I got voip working from dialer-app now but something else came up
<rvr> oSoMoN: Not reported?
<oSoMoN> rvr, not that I know of, but dbarth might know
<rvr> Right
<vigo> boiko, there is no sound within the call, I can hear the beeps before taking the call and three beeps once I hung up the call
<vigo> but I couldn't hear bfiller or through my cell phone
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Preparing packages
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2611 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir-gles). Needs rebuild due to new commits (zesty/unity8). Ready to build (xenial/mir, zesty/mir). Successfully built (xenial/qtmir, xenial/unity-api, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api)
<bfiller11> boiko, seeing a few issues on the silo with dialer and voip 1) no calls are every being displayed on Recents->All list. I see some on Recents->Missed but never on All
<bfiller11> boiko, 2) I get no audio on incoming calls after accepting the call
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 zesty/unity8: Failed to merge https://code.launchpad.net/~mzanetti/unity8/fix-super-hides-launcher
<bfiller11> boiko, vigo is never getting any audio I am getting it for outgoing but not incoming
<salem_> bfiller11, vigo  try sending a dtmf and check if that makes the sound work.
<bfiller11> salem_, yes that made it work for me
<salem_> bfiller11, I remember I saw that happening once when testing on qemu.
<bfiller11> salem_, that makes it work for me, not on vm running natively
<salem_> bfiller11, might not be related to the vm then. either audio routing or sip audio streams not being correctly setup.
<bfiller11> salem_, seems that way
<vigo> salem_, it is working now but just in one direction, it could be related to my mic in kvm I gues
<vigo> guess*
<vigo> I can hear bfiller11 correctly
<vigo> but he does not hear me
<salem_> vigo, yes, maybe try recording something with arecord to check if your mic is capturing audio correctly
<bfiller11> salem_, boiko, we need to look at the audio setup and see why pressing dtmf makes it work
<bfiller11> salem_, also any ideas why call log is not working?
<salem_> bfiller11, let me have a quick look
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles)
<vigo> bfiller11, just worked with my cell
<vigo> I could hear me through the laptop speakers
<vigo> and the voice telling my to hang up the call
<bfiller11> vigo, you could hear both directions?
<vigo> bfiller11, oh no
<vigo> I thought it was the phone too but it wasn't
<boiko> bfiller: vigo: salem_: sorry, had to go be off for a bit
<boiko> bfiller: vigo: if I remember correctly salem_ hit this problem of having audio only after DTMF on his VM, not sure what causes it, but comparing to empathy there is little difference in the way the gstreamer pipeline is configured :/
<bfiller> boiko, it's not just in VM
<bfiller> boiko, I can repeat it native
<boiko> bfiller: yeah, I know, just saying that salem_ hit that in the vm
<bfiller> boiko, understood but don't think it's a vm problem is what I mean. must be timing related somehow. but why would dtmf fix it either way?
<bfiller> doesn't make sense
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Preparing packages
<boiko> bfiller: from the audio routing perspective it doesn't make any sense, indeed, as audio streams and DTMF follow different routs
<boiko> routes
<boiko> bfiller: but it might be that rakia is simply not sending anything and when a DTMF is sent to se server it changes the contents (the streams) to start send and receive, let me check rakia's code quickly
<vigo> boiko, is there a bug for this audio issue?
<boiko> vigo: not a reported one (since the voip support is not on trunk yet)
<vigo> boiko, where the best place to file it?
<boiko> vigo: I would say telephony-service
<vigo> boiko, ack
<vigo> boiko, bfiller salem_ thanks!
<boiko> vigo: thanks for testing the changes :)
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Needs rebuild due to new commits (zesty/dialer-app). Ready to build (xenial/online-accounts-api). Release pocket (zesty/online-accounts-api). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/empathy, xenial/history-service, xenial/indicator-transfer-buteo, xenial/libircclient, xenial/messaging-app, xenial/messaging-framework
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Pending binary packages (xenial/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/unity8)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Successfully built
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Needs rebuild due to new commits (zesty/dialer-app, zesty/messaging-app). Ready to build (xenial/online-accounts-api). Release pocket (zesty/online-accounts-api). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/empathy, xenial/history-service, xenial/indicator-transfer-buteo, xenial/libircclient, xenial/messaging-app, xenia
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 Preparing packages
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Preparing packages
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 Failed to build
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Pending binary packages (xenial/dialer-app, xenial/messaging-app). Ready to build (xenial/online-accounts-api). Release pocket (zesty/online-accounts-api). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/empathy, xenial/history-service, xenial/indicator-transfer-buteo, xenial/libircclient, xenial/messaging-framework, xenial/mfw-plugin-irc, xe
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Ready to build (xenial/online-accounts-api). Release pocket (zesty/online-accounts-api). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/empathy, xenial/history-service, xenial/indicator-transfer-buteo, xenial/libircclient, xenial/messaging-app, xenial/messaging-framework, xenial/mfw-plugin-irc, xenial/telepathy-mission-con
#ubuntu-ci-eng 2017-03-28
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2386 Publishing packages
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Preparing packages
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2386 Release pocket (xenial/ubuntu-keyboard). UNAPPROVED queue (zesty/ubuntu-keyboard)
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Pending binary packages
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Successfully built
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Preparing packages
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Pending binary packages (zesty/dialer-app, zesty/messaging-app). Ready to build (xenial/online-accounts-api). Release pocket (zesty/online-accounts-api). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/empathy, xenial/history-service, xenial/indicator-transfer-buteo, xenial/libircclient, xenial/messaging-app, xenial/messagi
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Ready to build (xenial/online-accounts-api). Release pocket (zesty/online-accounts-api). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/empathy, xenial/history-service, xenial/indicator-transfer-buteo, xenial/libircclient, xenial/messaging-app, xenial/messaging-framework, xenial/mfw-plugin-irc, xenial/telepathy-mission-con
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2653 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2653 Generating diffs
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2653 Successfully built
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2625 Preparing packages
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2625 Failed to build
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Failed to build (xenial/mir, xenial/qtmir, xenial/qtmir-gles, zesty/miral, zesty/qtmir, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/mir). Successfully built (xenial/miral, xenial/unity-system-compositor, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2625 Preparing packages
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2625 Uploading build
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2625 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2654 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/2654 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2654 REJECTED queue
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2655 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/2655 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2655 REJECTED queue
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Needs rebuild due to new commits (zesty/ubuntu-terminal-app). Successfully built (xenial/ubuntu-terminal-app)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2653 Abandoning ticket
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Currently building (xenial/qtmir, xenial/unity8, zesty/unity8). Failed to build (xenial/unity-api). Needs rebuild due to higher version at destination (xenial/mir, zesty/mir). Needs rebuild due to new commits (zesty/qtmir). Pending binary packages (xenial/qtmir-gles). Successfully built (zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2656 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2611 Publishing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Currently building (zesty/unity8). Failed to build (xenial/unity-api, xenial/unity8). Needs rebuild due to higher version at destination (xenial/mir, zesty/mir). Needs rebuild due to new commits (zesty/qtmir). Successfully built (xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2657 Preparing packages
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2657 zesty/unity-settings-daemon: Failed to commit https://code.launchpad.net/~chrisccoulson/unity-settings-daemon/lp1542699. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2611 Release pocket (xenial/oxide-qt). UNAPPROVED queue (zesty/oxide-qt)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2656 Diff missing (zesty/networking-l2gw, zesty/vmware-nsx). Ready to build (xenial/networking-l2gw, xenial/vmware-nsx)
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2657 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/unity-api, xenial/unity8). Needs rebuild due to higher version at destination (xenial/mir, zesty/mir). Needs rebuild due to new commits (zesty/qtmir). Successfully built (xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles, zesty/unity-api, zesty/unity8)
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2657 Failed to build
-queuebot:#ubuntu-ci-eng- michi jamesh, https://bileto.ubuntu.com/#/ticket/2607 Publishing packages
<Saviq> trainguards, hey, any idea why https://bileto.ubuntu.com/#/ticket/2605 is stuck in UNAPPROVED?
<sil2100> Saviq: hey! I guess you're better off asking on #ubuntu-release, it's a main package and the zesty archives are frozen
<Saviq> oh they are already
<sil2100> So possibly no one looked at it yet in the queue
<xnox> Saviq, because Ubuntu is frozen for release, and everything requires release team review.
<sil2100> Yeah, we're basically in manual mode till release
<Saviq> ack
<vigo> kenvandine, ping
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2636 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2656 Generating diffs
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2656 Successfully built
<seb128> vigo, ken is probably still sleeping at this time, he's in the u.s
-queuebot:#ubuntu-ci-eng- michi jamesh, https://bileto.ubuntu.com/#/ticket/2607 Proposed pocket (zesty/storage-framework). Release pocket (xenial/storage-framework)
<sil2100> koza: hey!
<sil2100> koza: I'm looking at https://bileto.ubuntu.com/#/ticket/2354 right now - it says it's targetted for xenial main archive, is this supposed to be an SRU?
<sil2100> koza: if yes, then I suppose the changelog entry mentioning the new patch needs to have a bug reference assigned
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2636 Publishing packages
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Preparing packages
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2658 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2310 Abandoning ticket
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2636 Release pocket (xenial/unity8-desktop-session). UNAPPROVED queue (zesty/unity8-desktop-session)
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Destination version missing from changelog (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Needs rebuild due to burned version number (xenial/unity8-desktop-session). Successfully built (xenial/qtubuntu-print, xenial/ubuntu-printing-app). UNAPPROVED queue (zesty/unity8-desktop-session)
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Currently building (xenial/mir, xenial/qtmir, zesty/mir). Failed to build (zesty/qtmir). Pending binary packages (xenial/miral, xenial/qtmir-gles, xenial/unity-system-compositor, zesty/qtmir-gles). Successfully built (zesty/miral, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Preparing packages
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Currently building (xenial/mir, zesty/mir). Failed to build (zesty/qtmir). Successfully built (xenial/miral, xenial/qtmir, xenial/qtmir-gles, xenial/unity-system-compositor, zesty/miral, zesty/qtmir-gles, zesty/unity-system-compositor)
<koza> sil2100, hey
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2656 Publishing packages
<koza> sil2100, let me check what is going on and will let u know
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Currently building (xenial/unity8, zesty/unity8). Failed to build (xenial/unity-api). Needs rebuild due to higher version at destination (xenial/mir, zesty/mir). Needs rebuild due to new commits (zesty/qtmir). Successfully built (xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles, zesty/unity-api)
<jamesh> sil2100: are you able to publish https://bileto.ubuntu.com/#/ticket/2607 for me? (there are some minor packaging changes)
<jamesh> oh.  It's already done.
<jamesh> sil2100: never mind me.  Thanks!
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Preparing packages
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Destination version missing from changelog (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Successfully built (xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/unity8-desktop-session, zesty/unity8-desktop-session)
<sil2100> jamesh: hey! Yes, I published it in the morning :)
-queuebot:#ubuntu-ci-eng- ahayzen jgdx, https://bileto.ubuntu.com/#/ticket/2605 Proposed pocket (zesty/ubuntu-system-settings, zesty/ubuntu-ui-extras). Release pocket (xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/ubuntu-system-settings, xenial/ubuntu-ui-extras, zesty/qtubuntu-print, zesty/ubuntu-printing-app)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2656 Proposed pocket
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2657 Pending binary packages
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Destination version missing from changelog (zesty/qtubuntu-print, zesty/ubuntu-printing-app, zesty/unity8-desktop-session). Successfully built (xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/unity8-desktop-session)
-queuebot:#ubuntu-ci-eng- michi jamesh, https://bileto.ubuntu.com/#/ticket/2607 Release pocket
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2656 Release pocket
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/unity-api, xenial/unity8). Needs rebuild due to higher version at destination (xenial/mir, zesty/mir). Needs rebuild due to new commits (zesty/qtmir, zesty/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2636 Proposed pocket (zesty/unity8-desktop-session). Release pocket (xenial/unity8-desktop-session)
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2657 Successfully built
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Currently building (xenial/mir). Destination version missing from changelog (zesty/mir). Failed to build (zesty/qtmir). Successfully built (xenial/miral, xenial/qtmir, xenial/qtmir-gles, xenial/unity-system-compositor, zesty/miral, zesty/qtmir-gles, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Currently building (zesty/unity8). Failed to build (xenial/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- popey, https://bileto.ubuntu.com/#/ticket/2578 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2611 Proposed pocket (zesty/oxide-qt). Release pocket (xenial/oxide-qt)
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Destination version missing from changelog (zesty/mir). Failed to build (zesty/qtmir). Successfully built (xenial/mir, xenial/miral, xenial/qtmir, xenial/qtmir-gles, xenial/unity-system-compositor, zesty/miral, zesty/qtmir-gles, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Failed to build (xenial/unity8). Pending binary packages (zesty/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2636 Release pocket
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Destination version missing from changelog (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Needs rebuild due to new commits (zesty/unity8-desktop-session). Successfully built (xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/unity8-desktop-session)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Failed to build (xenial/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/unity8)
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Preparing packages
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Failed to build (zesty/qtmir). Needs rebuild due to new commits (zesty/mir). Successfully built (xenial/mir, xenial/miral, xenial/qtmir, xenial/qtmir-gles, xenial/unity-system-compositor, zesty/miral, zesty/qtmir-gles, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/unity-api, xenial/unity8). Needs rebuild due to higher version at destination (xenial/mir). Needs rebuild due to new commits (zesty/mir, zesty/qtmir, zesty/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2597 Publishing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2598 Publishing packages
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Currently building (zesty/telephony-service). Failed to build (xenial/telephony-service). Ready to build (xenial/online-accounts-api). Release pocket (zesty/online-accounts-api). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/empathy, xenial/history-service, xenial/indicator-transfer-buteo, xenial/libircclient, xenial/mess
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2597 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2598 UNAPPROVED queue
<boiko> trainguards: can someone please trigger a rebuild of telephony-service/xenial/arm64 on silo 2629?
<sil2100> boiko: on it
<boiko> sil2100: thanks!
<sil2100> boiko: done, yw!
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2611 Release pocket
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Failed to build (xenial/telephony-service). Pending binary packages (zesty/telephony-service). Ready to build (xenial/online-accounts-api). Release pocket (zesty/online-accounts-api). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/empathy, xenial/history-service, xenial/indicator-transfer-buteo, xenial/libircclient, xenial
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Publishing packages
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Publish failed: Packaging diff requires ACK
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Publishing packages
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Publish failed: Needs rebuild due to new commits
-queuebot:#ubuntu-ci-eng- ahayzen jgdx, https://bileto.ubuntu.com/#/ticket/2605 Release pocket
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Failed to build (xenial/telephony-service). Ready to build (xenial/online-accounts-api). Release pocket (zesty/online-accounts-api). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/empathy, xenial/history-service, xenial/indicator-transfer-buteo, xenial/libircclient, xenial/messaging-app, xenial/messaging-framework, xenial/
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Needs rebuild due to burned version number (xenial/ubuntu-system-settings). Needs rebuild due to new commits (zesty/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Preparing packages
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 Preparing packages
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Failed to build (xenial/ubuntu-printing-app). Pending binary packages (zesty/ubuntu-printing-app). Successfully built (xenial/qtubuntu-print, xenial/unity8-desktop-session, zesty/qtubuntu-print, zesty/unity8-desktop-session)
<boiko> sil2100: if you don't mind, could you please also trigger a rebuild of telephony-service/xenial/s390x on silo 2629?
<sil2100> boiko: sure
<sil2100> boiko: done
<ahayzen> ugh, is this the arm64 qml kernel issue again? it segfaults when running qmltests, but it fine on all other arches https://launchpadlibrarian.net/313182148/buildlog_ubuntu-xenial-arm64.ubuntu-printing-app_0.1+16.04.20170328-0ubuntu1_BUILDING.txt.gz
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Preparing packages
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Too many merge targets: lp:miral, lp:miral/release
<sil2100> ahayzen: ah ha! Might be, I did publish new kernels to -updates yesterday
<sil2100> wgrant: hey! Could you check the usual xenial arm64 kernel thingy? We had new kernels released yesterday, possibly manual intervention is required once again
<sil2100> wgrant: thanks!
<ahayzen> thanks sil2100 :-)
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 Abandoning ticket
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Preparing packages
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Failed to build (xenial/ubuntu-printing-app). Successfully built (xenial/qtubuntu-print, xenial/unity8-desktop-session, zesty/qtubuntu-print, zesty/ubuntu-printing-app, zesty/unity8-desktop-session)
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Failed to build (xenial/miral, zesty/qtmir). Needs rebuild due to new commits (zesty/mir). Pending binary packages (zesty/miral). Successfully built (xenial/mir, xenial/qtmir, xenial/qtmir-gles, xenial/unity-system-compositor, zesty/qtmir-gles, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2660 Preparing packages
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Ready to build (xenial/online-accounts-api). Release pocket (zesty/online-accounts-api). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/empathy, xenial/history-service, xenial/indicator-transfer-buteo, xenial/libircclient, xenial/messaging-app, xenial/messaging-framework, xenial/mfw-plugin-irc, xenial/telepathy-mission-con
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Failed to build (xenial/ubuntu-terminal-app). Successfully built (zesty/ubuntu-terminal-app)
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 Currently building (zesty/ubuntu-app-launch). Failed to build (xenial/ubuntu-app-launch). Pending binary packages (xenial/libertine). Successfully built (zesty/libertine)
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Failed to build (xenial/miral, zesty/qtmir). Needs rebuild due to new commits (zesty/mir). Successfully built (xenial/mir, xenial/qtmir, xenial/qtmir-gles, xenial/unity-system-compositor, zesty/miral, zesty/qtmir-gles, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Failed to build (xenial/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/unity8)
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2661 Preparing packages
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 Failed to build (xenial/ubuntu-app-launch, zesty/ubuntu-app-launch). Successfully built (xenial/libertine, zesty/libertine)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2660 Needs rebuild due to new commits (zesty/indicator-sound). Successfully built (xenial/indicator-sound)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2660 Preparing packages
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Pending binary packages
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2519 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2660 Pending binary packages
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2661 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Failed to build (xenial/miral, zesty/qtmir). Needs rebuild due to new commits (zesty/mir, zesty/miral). Successfully built (xenial/mir, xenial/qtmir, xenial/qtmir-gles, xenial/unity-system-compositor, zesty/qtmir-gles, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Successfully built
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2660 Successfully built
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Failed to build (xenial/miral). Needs rebuild due to new commits (zesty/mir, zesty/miral, zesty/qtmir). Successfully built (xenial/mir, xenial/qtmir, xenial/qtmir-gles, xenial/unity-system-compositor, zesty/qtmir-gles, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Currently building (xenial/unity8, zesty/unity8). Failed to build (xenial/unity-api). Needs rebuild due to higher version at destination (xenial/mir). Needs rebuild due to new commits (zesty/mir, zesty/qtmir). Successfully built (xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Failed to build (xenial/ubuntu-system-settings). Pending binary packages (zesty/ubuntu-system-settings)
<vigo> jhodapp, ping
<jhodapp> vigo, pong
<vigo> jhodapp, hey :) I just installed captive-redirect from candidate but I can't run canonical tests
<jhodapp> vigo, what's the problem?
<vigo> "canonical-se.....captive-redirect" does not appear as command
<vigo> I've captive from candidate and tests from beta as it says in the description
<vigo> on my pi3
<jhodapp> vigo: what version of the snap do you have installed?
<jhodapp> for the engineering tests snap
<vigo> jhodapp, it is 92 same in beta,candidate and stable
<vigo> while it is 142 in edge
<vigo> could be that last one the one up to date I guess
<jhodapp> vigo, I should version 6 for the snap locally for me
<jhodapp> vigo, what does snap list show?
<vigo> jhodapp, ohh version yes
<vigo> 6
<vigo> jhodapp, http://paste.ubuntu.com/24268700/
<jhodapp> vigo, let me verify on another box of mine, one min
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Currently building (zesty/unity8). Failed to build (xenial/unity-api, xenial/unity8). Needs rebuild due to higher version at destination (xenial/mir). Needs rebuild due to new commits (zesty/mir, zesty/qtmir). Successfully built (xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles, zesty/unity-api)
<vigo> jhodapp, sure :)
<jhodapp> vigo, you're right, it's not there
<jhodapp> vigo, ok...I suggest building the snap quickly yourself then...looks like we need a new release of this snap
<vigo> jhodapp, already tried
<vigo> tests available in edge
<jhodapp> vigo, you see it in the edge version?
<vigo> jhodapp, canonical tests edge have captive-redirect tests available
<jhodapp> vigo, ok...looks like the latest version just hasn't been tested itself to move to the stable channel
<jhodapp> vigo, just use the edge version then
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Failed to build (xenial/ubuntu-system-settings). Successfully built (zesty/ubuntu-system-settings)
<vigo> jhodapp, cool, thanks
<jhodapp> np
<jhodapp> vigo, yeah looks like it's normal to use the latest version out of edge...just confirmed this with my team
<vigo> jhodapp, ack thank you!
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/unity-api, xenial/unity8). Needs rebuild due to higher version at destination (xenial/mir). Needs rebuild due to new commits (zesty/mir, zesty/qtmir). Successfully built (xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles, zesty/unity-api, zesty/unity8)
-queuebot:#ubuntu-ci-eng- jhodapp, https://bileto.ubuntu.com/#/ticket/2628 QA Signoff: Approved
<vigo> jhodapp, what kind of device do I need for step 5?
<jhodapp> vigo, which one is step 5?
<vigo> jhodapp, job 5
<vigo> 5/5
<jhodapp> vigo, best to ask matteo, he wrote these tests
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2519 Publishing packages
<vigo> jhodapp, ack
<vigo> looks like he's not connected :\
<dobey> jibel, rvr, davmor2, vigo: hi, can we get a pass on silo 2660 please? it's a trivial change that only affects building under jenkins, that we need. thanks
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2663 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2519 Release pocket
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/unity-api, xenial/unity8). Needs rebuild due to higher version at destination (xenial/mir). Needs rebuild due to new commits (zesty/mir, zesty/qtmir, zesty/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 Successfully built
<dobey> meh
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2663 Dependency wait (xenial/unity8, zesty/unity8). Pending binary packages (zesty/unity-api). Uploading build (xenial/unity-api)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2663 Dependency wait (xenial/unity8, zesty/unity8). Successfully built (xenial/unity-api, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Failed to build (xenial/ubuntu-system-settings). Successfully built (zesty/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2664 Preparing packages
<kenvandine> wgrant, i think the arm64 builders are broken again :/
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Pending binary packages (zesty/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Preparing packages
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2640 Needs rebuild due to new commits (zesty/unity-api). Successfully built (xenial/unity-api)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2663 Pending binary packages (xenial/unity8, zesty/unity8). Successfully built (xenial/unity-api, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2663 Successfully built
<dobey> trainguards: hi, can someone please cancel and restart https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2664/+build/12371822 ? it seems the build has hanged
<tedg> dobey: on it
<dobey> tedg: thanks
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Successfully built
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2664 Successfully built
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Preparing packages
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 QA Signoff: Approved
<rvr> kenvandine: terminal-app silo is approved, ready to publish
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Publishing packages
<kenvandine> rvr, thx
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Release pocket (xenial/ubuntu-terminal-app). UNAPPROVED queue (zesty/ubuntu-terminal-app)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Successfully built
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Preparing packages
#ubuntu-ci-eng 2017-03-29
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (xenial/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 xenial/ubuntu-system-settings: Timed out
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (xenial/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 xenial/ubuntu-system-settings: Timed out
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (xenial/ubuntu-system-settings)
<kenvandine> bileto seems broken, nothing but 500 errors and my build timed out
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2665 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/2665 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2665 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2663 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2655 UNAPPROVED queue
<sil2100> davmor2: hey! Do you have a zesty desktop handy for testing? I would appreciate someone giving a spin https://bileto.ubuntu.com/#/ticket/2657 - just installing and checking if unity7 still runs fine
<vigo> jhodapp, ping
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2663 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/unity-api, xenial/unity8, zesty/unity-api)
<davmor2> sil2100: hey dude just caught your message in my email read...do you still need that silo looking at?
<sil2100> davmor2: hey! Yeah, if possible :)
<sil2100> I would feel bad for publishing the zesty binary without someone at least installing it
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Preparing packages
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Successfully built
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2666 Preparing packages
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2666 zesty/repowerd: Failed to commit https://git.launchpad.net/repowerd. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2667 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
<alf_> robru: Hi! I am getting "You must supply either a Commit Message on your MP, or a custom debian/changelog entry." in You must supply either a Commit Message on your MP, or a custom debian/changelog entry. However, my branch has a proper UNRELEASED entry.
<alf_> robru: that's in https://bileto.ubuntu.com/log/2666/build/1/
<alf_> robru: What am I missing?
<alf_> trainguards: ^^
<sil2100> alf_: let me take a look
<sil2100> alf_: ok, I don't have much experience with git MR and its bileto support, but I don't see any 'commit message' in https://code.launchpad.net/~repowerd-team/repowerd/+git/repowerd/+merge/321269 ?
<sil2100> alf_: Bileto for MPs needs a commit message as it uses it for the changelog entry for a given change
<alf_> sil2100: right, that's the point, that I have already provided a changelog entry and I don't want bileto to add anything to it. I thought this was supported (as is also implied by the error message: "...or a custom debian/changelog entry.")
<sil2100> alf_: I think the check is there always - if you modified debian/changelog then it will probably ignore the commit message then
<sil2100> alf_: you might want to fill in a bug for that
<vigo> jhodapp, ping
<alf_> sil2100: thanks
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2666 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Preparing packages
<alf_> sil2100: ok, I found the issue: My source branch and target/landing branch had the same contents (since I don't care about maintaining a landing branch history), so an empty diff. Bileto only takes into account changelog entries that are present in the diff between source and target.
<sil2100> alf_: yeah, saw the empty diff, I thought this was just a git issue
<sil2100> Ok then
<alf_> sil2100: fixed by ensuring landing branch didn't contain the commits updating debian/changelog
<sil2100> alf_: makes sense!
<sil2100> alf_: make sure that the debian/changelog custom entry you prepared is UNRELEASED though!
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2667 Generating diffs
<alf_> sil2100: yeap
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2666 Successfully built
<davmor2> sil2100: everything seems to be working here
<sil2100> davmor2: thanks!
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2657 Publishing packages
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Preparing packages
<jhodapp> vigo, pong
<vigo> jhodapp, I found something with captive snap
<jhodapp> vigo, ok
<vigo> it is not currently possible reinstall it after removing it
<vigo> if you define a rule and remove it then you can't reinstall it
<vigo> https://pastebin.canonical.com/184149/
<jhodapp> vigo, mind filing a bug against that snap here: https://bugs.launchpad.net/snappy-hwe-snaps/
<vigo> jhodapp, sure
<jhodapp> thanks
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Needs rebuild due to new commits (zesty/unity8). Ready to build (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles). Uploading build (xenial/unity8)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 zesty/unity8: Failed to commit https://code.launchpad.net/~lukas-kde/unity8/betterSessionManagement. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2657 UNAPPROVED queue
<vigo> jhodapp, https://bugs.launchpad.net/snappy-hwe-snaps/+bug/1677213
<ubot5> Ubuntu bug 1677213 in snappy-hwe-snaps "Can't re-install captive-redirect snap after setting up a rule" [Undecided,New]
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 xenial/ubuntu-system-settings: Timed out
<jhodapp> vigo, thanks!
<jhodapp> vigo, very thorough, thanks for the detailed steps
<kenvandine> sil2100, any idea what's wrong in silo 2621?  I keep getting timed out errors when building the xenial source package
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (xenial/ubuntu-system-settings)
<kenvandine> sil2100, i started happening after i changed it to use the zesty-overlay
<kenvandine> s/i started/it started/
-queuebot:#ubuntu-ci-eng- jhodapp, https://bileto.ubuntu.com/#/ticket/2631 QA Signoff: Failed
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2667 Successfully built
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Needs rebuild due to new commits (zesty/unity8). Ready to build (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles). Successfully built (xenial/unity8)
<kenvandine> sil2100, wondering if it has something todo with the zesty overlay
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Preparing packages
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Merging branches
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Error: This ticket contains packages that are queued for upload. Finalizing now will erase these packages and they will never arrive in the destination archive. You must contact #ubuntu-release to approve these uploads prior to merging
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Release pocket (xenial/ubuntu-terminal-app). UNAPPROVED queue (zesty/ubuntu-terminal-app)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Successfully built
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 xenial/ubuntu-system-settings: Timed out
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
<dobey> jibel: hi, can we get a skip through qa for https://trello.com/c/7uc5F5Ax/4090-2660-2660-indicator-sound-dobey please? it's only a change to get our jenkins CI moving along for that indicator
<jibel> dobey, sure, let me look
<jibel> dobey, done
<dobey> jibel: great, thanks!
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2660 QA Signoff: Approved
<vigo> ltinkl, ping
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2660 Publishing packages
<vigo> ltinkl,  I can't run kate and tiled with silo 2626
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (xenial/ubuntu-system-settings)
<ltinkl> vigo, hi, pong; it's because they are run now by default under xmir
<ltinkl> vigo, let me find the respective bug report
<vigo> ltinkl, ack thanks
<vigo> ltinkl, biab
<ltinkl> vigo, see https://trello.com/c/kVsB8pGq/4064-2555-2555-unity-api-unity8-qtmir-qtubuntu-qmenumodel-ltinkl for instructions how to run them natively
<ltinkl> vigo, the xmir bug is #1675364
<ltinkl> vigo, one more thing, we had to pop 2MPs from the silo in the last minute due to some CI issues; please update your trello card description from our silo (https://bileto.ubuntu.com/#/ticket/2626), 2 bugs on your list in trello are not (yet) fixed here
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Currently building (xenial/unity8, zesty/qtmir, zesty/unity8). Failed to build (xenial/qtmir, xenial/unity-api, zesty/qtmir-gles). Needs rebuild due to higher version at destination (xenial/mir, zesty/mir). Successfully built (xenial/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2660 Release pocket (xenial/indicator-sound). UNAPPROVED queue (zesty/indicator-sound)
<kenvandine> i don't see anyone else's silo complaining with the timed out error messages
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2669 Preparing packages
<dobey> kenvandine: ?
<kenvandine> i reconfigured silo 2621 to be zesty-overlay and xenial-overlay
<kenvandine> and now it keeps timing out creating the source packages
<dobey> we have zesty-overlay now?
<dobey> hmm
<dobey> i guess i should start landing things there instead of zesty?
<dobey> bugger
<sil2100> kenvandine: hmmm
<sil2100> kenvandine: let me take a look, but we'll need robru possibly
<kenvandine> sil2100, i just created a fresh silo to see if that behaves
<kenvandine> but doubtful
<dobey> doesn't look like it
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2595 Abandoning ticket
<kenvandine> yeah, 2669 seems to be sitting in the same place it usually times out too long
<sil2100> I wonder if maybe there's some assumption missing...
<sil2100> I'll try to look into this before robru starts his day
<kenvandine> sil2100, thanks!
 * kenvandine kills off duplicate silo
<vigo> ltinkl, thanks, trello card updated
 * dobey hopes someone will poke his package through unapproved
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2670 Preparing packages
<sil2100> kenvandine: ah, I see the problem - it seems with the switch to zesty-overlay it got busted in one place - all the source package builds are happening in the zesty/ directory, but the 'do_get_secondary' functions that are responsible for dual landings actually look for the source in zesty-overlay
<sil2100> I'll try to fix this, robru can follow up with some cleanup
<kenvandine> sil2100, thx
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2669 Ready to build
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2669 xenial/ubuntu-system-settings: Timed out
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir, xenial/unity-api, zesty/qtmir-gles). Needs rebuild due to higher version at destination (xenial/mir, zesty/mir). Successfully built (xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/unity-api, zesty/unity8)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Preparing packages
<sil2100> kenvandine: ok, hopefully fixed it
<kenvandine> sil2100, thx!
 * kenvandine tries
<sil2100> kenvandine: IIRC Bileto is auto-updated every 30 minutes, so in the next 30 mins you could re-try
<sil2100> kenvandine: so wait for now ;)
<kenvandine> ah, ok :)
<sil2100> I don't remember anything about the staging instance so this is a live-fix, no guarantee it actually fixes the problem
<sil2100> But we'll know once you re-run after the deployment
<Saviq> vigo|lunch, FWIW, apps not launching is bug #1675364
<ubot5> bug 1675364 in Canonical System Image "[regression] GTK and KDE apps fail to start under Unity8 (without gnome-session running)" [Critical,Triaged] https://launchpad.net/bugs/1675364
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2667 Generating diffs
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2670 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 xenial/unity8: Timed out
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Currently building (zesty/mir). Failed to build (xenial/qtmir, xenial/unity-api, zesty/qtmir-gles). Needs rebuild due to higher version at destination (xenial/mir). Successfully built (xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/unity-api, zesty/unity8)
<sil2100> kenvandine: hey! Could you maybe give it a spin now?
<sil2100> With luck it's deployed in production (or something)
<kenvandine> sil2100, sure
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Preparing packages
<salem_> trainguards, hey, could anybody trigger a rebuild of silo 2629/telephony-service/xenial/arm64 ?
<sil2100> a
<sil2100> salem_: on it
<salem_> sil2100, thank you!
<sil2100> salem_: done o/
<salem_> sil2100, awesome. thanks!
<sil2100> kenvandine: hah, looks like it works!
<kenvandine> sil2100, thanks!
<sil2100> robru: hey! I deployed a quick-fix for the dual-overlay landings - it seems to work, but please check the code if it doesn't break anything by accident (like, publishing to the wrong place or something) - but from what I checked it was safe
<sil2100> robru: feel free to make it prettier ;)
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Pending binary packages (xenial/telephony-service). Ready to build (xenial/online-accounts-api). Release pocket (zesty/online-accounts-api). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/empathy, xenial/history-service, xenial/indicator-transfer-buteo, xenial/libircclient, xenial/messaging-app, xenial/messaging-framework,
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2667 Successfully built
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Ready to build (xenial/online-accounts-api). Release pocket (zesty/online-accounts-api). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/empathy, xenial/history-service, xenial/indicator-transfer-buteo, xenial/libircclient, xenial/messaging-app, xenial/messaging-framework, xenial/mfw-plugin-irc, xenial/telepathy-mission-con
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2640 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2621 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir, xenial/unity-api, zesty/qtmir-gles). Needs rebuild due to higher version at destination (xenial/mir). Needs rebuild due to new commits (zesty/mir). Successfully built (xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/unity-api, zesty/unity8)
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2640 Successfully built
<morphis> vigo: ping
<vigo> morphis, pong
<morphis> vigo: you had a chance to look at https://bileto.ubuntu.com/#/ticket/2651 and https://bileto.ubuntu.com/#/ticket/2650 already?
<vigo> morphis, I'm currently working in unity8 silo and there are a couple of silos before those, but we'll be on them asap
<morphis> ok
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2674 Preparing packages
<vigo> mterry, ping
<vigo> how can I test it? Bug #1557634
<ubot5> bug 1557634 in qtmir (Ubuntu) "Unity8/Mir server crashes when given an invalid keymap" [Critical,In progress] https://launchpad.net/bugs/1557634
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2665 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2264 Successfully built
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2657 Proposed pocket
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 Publishing packages
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 Release pocket (xenial/libertine, xenial/ubuntu-app-launch). UNAPPROVED queue (zesty/libertine, zesty/ubuntu-app-launch)
<robru> kenvandine: did sil's fix get things working for you?
<kenvandine> robru, yes
<kenvandine> robru, working fine now, thanks!
<robru> kenvandine: ok great, I just wrote up a test case for it.
<kenvandine> cool, thanks
<robru> yw
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2264 Needs rebuild due to higher version at destination (xenial/libertine, xenial/ubuntu-app-launch). Successfully built (zesty/libertine, zesty/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Publishing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2641 Needs rebuild due to higher version at destination (xenial/qtmir, xenial/qtmir-gles). Successfully built (xenial/miral, zesty/miral, zesty/qtmir, zesty/qtmir-gles)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2663 Needs rebuild due to higher version at destination (xenial/unity8). Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/unity-api, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Failed to build (xenial/miral). Needs rebuild due to burned version number (xenial/qtmir, xenial/qtmir-gles). Needs rebuild due to new commits (zesty/mir, zesty/miral, zesty/qtmir). Successfully built (xenial/mir, xenial/unity-system-compositor, zesty/unity-system-compositor). UNAPPROVED queue (zesty/qtmir-gles)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Release pocket (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity8). UNAPPROVED queue (zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/unity8)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2634 Needs rebuild due to higher version at destination (xenial/qtmir, xenial/qtmir-gles, xenial/unity8). Successfully built (zesty/qtmir, zesty/qtmir-gles, zesty/unity8)
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2657 Release pocket
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2264 Needs rebuild due to higher version at destination (xenial/libertine, xenial/ubuntu-app-launch). Needs rebuild due to new commits (zesty/libertine). Successfully built (zesty/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2641 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2641 Failed to build (xenial/miral). Needs rebuild due to higher version at destination (xenial/qtmir, xenial/qtmir-gles). Successfully built (zesty/miral, zesty/qtmir, zesty/qtmir-gles)
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2570 Needs rebuild due to higher version at destination (zesty/apport). Successfully built (xenial/apport, yakkety/apport)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2660 Proposed pocket (zesty/indicator-sound). Release pocket (xenial/indicator-sound)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2450 Abandoning ticket
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2660 Release pocket
#ubuntu-ci-eng 2017-03-30
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Failed to build (xenial/ubuntu-app-launch). Successfully built (zesty/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2670 Preparing packages
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2670 zesty/ubuntu-system-settings: Failed to merge https://code.launchpad.net/~artmello/ubuntu-system-settings/keyboard-navigation
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2670 Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (xenial/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2667 Abandoning ticket
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2658 Diff missing
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2676 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2676 Currently building (zesty/miral). Failed to build (xenial/miral)
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2676 Failed to build (xenial/miral). Successfully built (zesty/miral)
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2658 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2665 Abandoning ticket
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2658 Successfully built
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2641 Abandoning ticket
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2676 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2676 Pending binary packages
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2625 Publishing packages
<sil2100> koza: hey! Any news on https://bileto.ubuntu.com/#/ticket/2354 ? i.e. if it's an SRU or overlay-landing?
<koza> sil2100, yes, I will provide the bug id
<sil2100> koza: thanks!
<koza> sil2100, bug id: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1510570; or you would like that I update the changelog and re-upload the packages there?
<ubot5> Ubuntu bug 1510570 in bluez (Ubuntu) "BLE pairing fail" [High,Confirmed]
<sil2100> koza: the changelog needs to be updated otherwise the SRU will be rejected - it needs to mention the bug ID in the entry in the form e.g. (LP: #number)
<koza> sil2100, right, I'll handle this
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir, xenial/unity-api, zesty/qtmir-gles). Needs rebuild due to higher version at destination (xenial/mir). Needs rebuild due to new commits (zesty/mir, zesty/unity8). Successfully built (xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2677 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2676 Successfully built
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2162 QA Signoff:
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2162 Needs rebuild due to higher version at destination (zesty/aethercast). Ready to build (xenial/isc-dhcp, zesty/isc-dhcp). Successfully built (xenial/aethercast)
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2625 Proposed pocket
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2625 Release pocket
<koza> sil2100, can I send the updated [changelog] src package to you for uploading to the silo? I do not have such rights, can't do it by myself.
<sil2100> koza: ah, sure ;) Damn, if I knew
<sil2100> koza: ok, let me just do it myself in that case, that'll save some unnecessary work from your side
<koza> sil2100, it is already done, just need to send src package
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2677 Destination version missing from changelog (zesty/indicator-location). Successfully built (xenial/indicator-location)
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2162 Needs rebuild due to new commits (zesty/aethercast). Ready to build (xenial/isc-dhcp, zesty/isc-dhcp). Successfully built (xenial/aethercast)
<sil2100> koza: thanks! Uploaded, will sponsor as soon as it builds
<sil2100> hm, actually, I could have just pushed that to xenial as is
<sil2100> koza: ok, I'll do that now - uploading to xenial
<sil2100> koza: (this means we can basically abandon the silo)
<sil2100> koza: I'll abandon the silo if you don't mind
<koza> sil2100, great please go ahead
<koza> sil2100, and thanks
-queuebot:#ubuntu-ci-eng- koza, https://bileto.ubuntu.com/#/ticket/2354 Abandoning ticket
<sil2100> koza: ah, one more thing - if you have a moment, could you update the bug description to fit the SRU template? https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
<sil2100> koza: I can do that later if needed, but I guess it should be easier for someone that knows the project
<koza> sil2100, sure, added to my list
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2676 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2676 Successfully built
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2676 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2676 Pending binary packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2676 Successfully built
<sil2100> robru: hey! Bileto is reporting such an issue with my silo: https://bileto.ubuntu.com/log/2677/status/14/ <- even though I took the selected diff and included it as part of the MP I'm trying to merge
<sil2100> robru: do I need to commit it to trunk, or is there a way I can force Bileto to acknowledge that the missing changelog entry has been added as part of the MP?
<dobey> sil2100: i think we need to merge it to trunk. do you need me to help with that since it's indicator-location?
<sil2100> dobey: no, it's fine
<sil2100> I'm on it
<dobey> ok i think i'll go get lunch then. if you break it i'll yell when i get back :)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Preparing packages
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2677 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Failed to build (xenial/ubuntu-app-launch). Needs rebuild due to new commits (zesty/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2677 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Currently building (xenial/unity8, zesty/unity8). Failed to build (xenial/qtmir, xenial/unity-api, zesty/qtmir-gles). Needs rebuild due to higher version at destination (xenial/mir). Needs rebuild due to new commits (zesty/mir). Successfully built (xenial/qtmir-gles, zesty/qtmir, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 Merging branches
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 Error: This ticket contains packages that are queued for upload. Finalizing now will erase these packages and they will never arrive in the destination archive. You must contact #ubuntu-release to approve these uploads prior to merging
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir, xenial/unity-api, zesty/qtmir-gles). Needs rebuild due to higher version at destination (xenial/mir). Needs rebuild due to new commits (zesty/mir). Pending binary packages (zesty/unity8). Successfully built (xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir, xenial/unity-api, zesty/qtmir-gles). Needs rebuild due to higher version at destination (xenial/mir). Needs rebuild due to new commits (zesty/mir). Successfully built (xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/unity-api, zesty/unity8)
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 Release pocket (xenial/libertine, xenial/ubuntu-app-launch). UNAPPROVED queue (zesty/libertine, zesty/ubuntu-app-launch)
<robru> sil2100: yes, as stated in the status log, you must commit that diff to trunk, not include it in your MP
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2670 Preparing packages
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2670 Successfully built
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Proposed pocket (zesty/unity8). Release pocket (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity8). UNAPPROVED queue (zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2634 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 Proposed pocket (zesty/libertine, zesty/ubuntu-app-launch). Release pocket (xenial/libertine, xenial/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Currently building (zesty/ubuntu-app-launch). Failed to build (xenial/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Failed to build (xenial/miral). Needs rebuild due to burned version number (xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/mir, zesty/miral, zesty/qtmir). Successfully built (xenial/mir, xenial/unity-system-compositor, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Proposed pocket (zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/unity8). Release pocket (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity8)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Destination version missing from changelog (zesty/ubuntu-app-launch). Failed to build (xenial/ubuntu-app-launch)
#ubuntu-ci-eng 2017-03-31
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2622 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Proposed pocket (zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles). Release pocket (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity8, zesty/unity8)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2626 Release pocket
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2634 Needs rebuild due to higher version at destination (xenial/qtmir, xenial/qtmir-gles, xenial/unity8, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/qtmir, zesty/unity8)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir, xenial/unity-api, zesty/qtmir-gles). Needs rebuild due to higher version at destination (xenial/mir). Needs rebuild due to new commits (zesty/mir, zesty/qtmir, zesty/unity8). Successfully built (xenial/qtmir-gles, xenial/unity8, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2564 Updates pocket
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 zesty/unity8: Failed to commit https://code.launchpad.net/~lukas-kde/unity8/betterSessionManagement. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Needs rebuild due to new commits (zesty/unity8). Ready to build (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles). Successfully built (xenial/unity8)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Currently building (zesty/mir). Failed to build (xenial/qtmir, xenial/unity-api, zesty/qtmir-gles). Needs rebuild due to higher version at destination (xenial/mir). Needs rebuild due to new commits (zesty/qtmir, zesty/unity8). Successfully built (xenial/qtmir-gles, xenial/unity8, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Preparing packages
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 zesty/qtmir: Failed to merge https://code.launchpad.net/~aacid/qtmir/drag_and_drop
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Preparing packages
<sil2100> dobey: hey! Thanks for the indicator-location review!
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir, xenial/unity-api, zesty/qtmir-gles). Needs rebuild due to higher version at destination (xenial/mir). Needs rebuild due to new commits (zesty/qtmir, zesty/unity8). Successfully built (xenial/qtmir-gles, xenial/unity8, zesty/mir, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Bad merges (zesty/qtmir). Currently building (xenial/mir, zesty/mir). Failed to build (xenial/miral, xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles). Successfully built (xenial/unity-system-compositor, zesty/miral, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Currently building (xenial/mir, zesty/mir). Failed to build (xenial/miral, xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles). Successfully built (xenial/unity-system-compositor, zesty/miral, zesty/qtmir, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Preparing packages
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 zesty/unity8: Failed to commit https://code.launchpad.net/~lukas-kde/unity8/betterSessionManagement. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Currently building (xenial/mir, zesty/mir). Failed to build (xenial/miral, xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles). Pending binary packages (zesty/miral). Successfully built (xenial/unity-system-compositor, zesty/qtmir, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Failed to build (xenial/ubuntu-printing-app). Successfully built (xenial/qtubuntu-print, xenial/unity8-desktop-session, zesty/qtubuntu-print, zesty/ubuntu-printing-app, zesty/unity8-desktop-session)
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Currently building (xenial/mir). Destination version missing from changelog (zesty/mir). Failed to build (xenial/miral, xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles). Successfully built (xenial/unity-system-compositor, zesty/miral, zesty/qtmir, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Needs rebuild due to new commits (zesty/unity8). Ready to build (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles). Successfully built (xenial/unity8)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2679 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Preparing packages
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Destination version missing from changelog (zesty/mir). Failed to build (xenial/miral, xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles). Successfully built (xenial/mir, xenial/unity-system-compositor, zesty/miral, zesty/qtmir, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2679 Currently building (xenial/ubuntu-system-settings, zesty/ubuntu-system-settings). Failed to build (xenial/ubuntu-ui-extras). Needs rebuild due to new commits (zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Currently building (xenial/qtmir, zesty/qtmir). Failed to build (xenial/qtmir-gles, xenial/qtubuntu-gles, zesty/qtmir-gles, zesty/qtubuntu-gles). Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/qtubuntu, xenial/unity8, zesty/qtubuntu)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2679 Failed to build (xenial/ubuntu-system-settings, xenial/ubuntu-ui-extras). Needs rebuild due to new commits (zesty/ubuntu-ui-extras). Successfully built (zesty/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Failed to build (xenial/qtmir-gles, xenial/qtubuntu-gles, zesty/qtmir-gles, zesty/qtubuntu-gles). Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/qtmir, xenial/qtubuntu, xenial/unity8, zesty/qtmir, zesty/qtubuntu)
<dobey> sil2100: sure
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 zesty/qtmir: Failed to merge https://code.launchpad.net/~unity-team/qtmir/qtmir.api
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2680 Preparing packages
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2680 zesty/unity8-desktop-session: Failed to commit https://code.launchpad.net/~mterry/unity8-desktop-session/systemd. 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/2373 Failed to build (xenial/qtmir, xenial/unity-api, zesty/qtmir-gles). Needs rebuild due to higher version at destination (xenial/mir). Needs rebuild due to new commits (zesty/qtmir, zesty/unity8). Successfully built (xenial/qtmir-gles, xenial/unity8, zesty/mir, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2680 Ready to build
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 zesty/unity8: Failed to merge https://code.launchpad.net/~nick-dedekind/unity8/multi-monitor
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2639 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir, xenial/unity-api, zesty/qtmir-gles). Needs rebuild due to higher version at destination (xenial/mir). Needs rebuild due to new commits (zesty/qtmir, zesty/unity8). Successfully built (xenial/qtmir-gles, xenial/unity8, zesty/mir, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2681 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2637 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2637 vivid/sync-monitor: Failed to add changelog message
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2637 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2637 vivid/sync-monitor: Failed to add changelog message
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Currently building (xenial/qtmir, xenial/qtubuntu, xenial/unity8, zesty/qtmir, zesty/qtubuntu, zesty/unity8). Failed to build (xenial/qtmir-gles, xenial/qtubuntu-gles, zesty/qtmir-gles, zesty/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2637 Ready to build
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2639 Successfully built
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2682 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/2668 Currently building (xenial/qtmir, xenial/unity8, zesty/qtmir, zesty/unity8). Failed to build (xenial/qtmir-gles, xenial/qtubuntu-gles, zesty/qtmir-gles, zesty/qtubuntu-gles). Successfully built (xenial/qtubuntu, zesty/qtubuntu)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2681 Failed to build (xenial/ubuntu-system-settings). Successfully built (zesty/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Currently building (xenial/unity8). Failed to build (xenial/qtmir-gles, xenial/qtubuntu-gles, zesty/qtmir-gles, zesty/qtubuntu-gles). Pending binary packages (xenial/qtmir). Successfully built (xenial/qtubuntu, zesty/qtmir, zesty/qtubuntu, zesty/unity8)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Failed to build (xenial/qtmir-gles, xenial/qtubuntu-gles, zesty/qtmir-gles, zesty/qtubuntu-gles). Pending binary packages (xenial/unity8). Successfully built (xenial/qtmir, xenial/qtubuntu, zesty/qtmir, zesty/qtubuntu, zesty/unity8)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Failed to build (xenial/qtmir-gles, xenial/qtubuntu-gles, zesty/qtmir-gles, zesty/qtubuntu-gles). Successfully built (xenial/qtmir, xenial/qtubuntu, xenial/unity8, zesty/qtmir, zesty/qtubuntu, zesty/unity8)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 zesty/ubuntu-app-launch: Failed to merge https://code.launchpad.net/~ted/ubuntu-app-launch/instance-compare
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 zesty/ubuntu-app-launch: Failed to merge https://code.launchpad.net/~ted/ubuntu-app-launch/instance-compare
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Preparing packages
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Bad merges (zesty/miral). Destination version missing from changelog (zesty/mir). Failed to build (xenial/miral, xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles). Successfully built (xenial/mir, xenial/unity-system-compositor, zesty/qtmir, zesty/unity-system-compositor)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Needs rebuild due to new commits (zesty/ubuntu-app-launch). Successfully built (xenial/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Currently building (zesty/ubuntu-app-launch). Failed to build (xenial/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2679 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Failed to build (zesty/ubuntu-app-launch). Pending binary packages (xenial/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2679 Failed to build (xenial/ubuntu-system-settings). Successfully built (xenial/ubuntu-ui-extras, zesty/ubuntu-system-settings, zesty/ubuntu-ui-extras)
<Saviq> kenvandine, hey, do you know anything about http://pastebin.ubuntu.com/24289476/ ?
 * Saviq tries to repro locally
<kenvandine> Saviq, nope
<Saviq> happens for all -gles packages in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2668/+packages
<kenvandine> not that i know of :)
 * Saviq digs
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Failed to build (xenial/qtmir-gles, xenial/qtubuntu-gles, zesty/qtmir-gles, zesty/qtubuntu-gles). Needs rebuild due to new commits (zesty/qtmir). Successfully built (xenial/qtmir, xenial/qtubuntu, xenial/unity8, zesty/qtubuntu, zesty/unity8)
<kenvandine> Saviq, both of those are available in zesty and the xenial overlay
<pmcgowan> kenvandine, whats the zesty overlay url?
<kenvandine> libubuntu-app-launch3-dev does have a newer version in zesty-proposed
<kenvandine> neither of these
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2637 Preparing packages
<kenvandine> pmcgowan, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.name_filter=&field.status_filter=published&field.series_filter=zesty
<Saviq> kenvandine, oh, I should probably enable overlay on zesty then
<pmcgowan> kenvandine, do you know the ppa: link to add it
<Saviq> pmcgowan, it's as usual, I think?
<kenvandine> pmcgowan, it's the same as the xenial overlay
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2637 vivid/sync-monitor: Failed to add changelog message
<Saviq> ppa:ci-train-ppa-service/stable-phone-overlay
<kenvandine> yeah
<pmcgowan> oh gotcha
<kenvandine> Saviq, neither of these packages are in the the zesty overlay though
<kenvandine> and nothing they depend on
<Saviq> ohkay, /me digs more then
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Failed to build (zesty/ubuntu-app-launch). Successfully built (xenial/ubuntu-app-launch)
<Saviq> kenvandine, ok, found the culprit "libertine-xmir-tools : Depends: libqt5gui5" - bregma's fixing
<Saviq> keep calm, carry on
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2637 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2637 vivid/sync-monitor: Failed to add changelog message
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Preparing packages
<renatu> trainguards, guys how I can solve this error? https://bileto.ubuntu.com/log/2637/build/6/info/
<tedg> renatu: Don't modify debian/changelog :-)
<tedg> renatu: https://code.launchpad.net/~renatofilho/sync-monitor/new-vivid-release/+merge/321609
<renatu> tedg, I created this mr just to try to solve the problem first. Without this I got the same error
<tedg> Oh, this is targetting vivid?
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2637 Preparing packages
<tedg> renatu: Why are you targetting vivid?
<renatu> tedg, I want to test on phone
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2637 vivid/sync-monitor: Failed to add changelog message
<tedg> renatu: I think you're gonna have to bump to 0.2.1 or something then.
<tedg> Or 0.3
<renatu> tedg, ok thanks. Let me try
<dobey> renatu: you're going to need different MPs which specifically target the vivid branch
<dobey> renatu: well, you really probably will only need the one fix for vivid, instead of the massive gmock change
<dobey> oh, there isn't a vivid branch
<dobey> ick
<kenvandine> Saviq, ah... that nonsense
<robru> renatu: yeah your trunk is a zesty trunk, you can't do vivid release from there because then your next zesty release will also have that change. Also then your zesty trunk won't match what's in zesty
<robru> renatu: so you need to branch trunk for vivid
<renatu> robru, so I need to branch "lp:ubuntu/vivid/sync-monitor" and backport the changes?
<dobey> not likely no
<robru> renatu: no because that won't reflect what's in the overlay
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2637 Ready to build
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Currently building (xenial/ubuntu-app-launch). Failed to build (zesty/ubuntu-app-launch)
<dobey> you need to create a vivid branch from what was last released into vivid overlay
<dobey> then propose just the one fix to that (you shouldn't need to do the gmock stuff there)
<renatu> dobey, ok thanks
<robru> renatu: what you need to do is check what version is in vivid overlay, find the most recent commit that reflects that version, then make a new branch that only has up to that commit, then target your MP at that new branch
<dobey> because you only want to release that fix to vivid, not all the other changes that have happened in zesty since
<dobey> robru: and copy the debian/changelog from the last vivid release into the new vivid branch, before making the new MP against it :)
<dobey> because the commit in trunk at that point likely has a too-new changelog still
<robru> Yeah
<dobey> or just fine the ci-train cache branch from that last silo that went into vivid, and copy it over and make it the vivid branch for the project
<dobey> if it's still on lp somewhere
<renatu> dobey, robru, current version on phone image is exaclty tha lats version on debian/changelog:  0.2+15.04.20160901.3-0ubuntu1
<robru> dobey: oh good point, it would be. But you still have to do the changelog fix because Bileto only pushes primary series of a ticket
<dobey> robru: oh i thought it pushed a branch for each series
<robru> dobey: nope
<dobey> renatu: ok, then you can just copy trunk to a new vivid branch, then copy the vivid-overlay changelog in and commit/push it on trunk, then make a new branch based off the vivid branch with just the calendar fix, and propose merging it into the vivid branch, then build that in the silo for vivid
<dobey> err, vivid+overlay
<robru> renatu: oh I see, sync-monitor hasn't had a release since before we dropped vivid from dual/trio series tickets
<renatu> dobey, by vivid branch you mean?  lp:ubuntu/vivid/sync-monitor
<robru> renatu: yeah, what dobey said
<robru> renatu: no
<robru> renatu: copy lp:sync-monitor to lp:sync-monitor/vivid and then take the changelog from the actual vivid package, copy it over the one in lp:sync-monitor/vivid, and commit that
<dobey> renatu: no. make a new branch for the sync-monitor project, and if you want create a series for it called vivid or something, and you can have it be lp:sync-monitor/vivid
<renatu> robru, dobey thanks
<robru> I'm amazed this isn't in the wiki, I'll add it
<ChrisTownsend> robru: Hey, so we have https://bileto.ubuntu.com/#/ticket/2576 which is stuck in -proposed due a latent dependency issue.  We will need to rebuild libertine, but u-a-l in that silo does not need rebuilt.  After this goes through QA, etc. and we publish it, will there be any bearing on u-a-l since the same version will already exist in xenial overlay and zesty?
<robru> ChrisTownsend: I'm not sure what you mean. You're going to rebuild libertine, re QA, and republish? The publish job will notice that ual is the same version and won't publish it again.
<ChrisTownsend> robru: Right, and ok, you answered my question.  Thanks!  Just wanted to make sure we weren't going to break anything:)
<bregma> again ;)
<ChrisTownsend> bregma: yes, again
<dobey> but breaking things fast is the most important meal of the day!
<robru> yes!
<robru> dobey: renatu: kenvandine: https://wiki.ubuntu.com/Bileto#Branching_for_a_Stable_Series pls review for clarity
<kenvandine> robru, i'll look
<robru> thanks
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 QA Signoff:
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 Preparing packages
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 Pending binary packages (xenial/libertine, zesty/libertine). Proposed pocket (zesty/ubuntu-app-launch). Release pocket (xenial/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Successfully built (xenial/ubuntu-app-launch). Uploading build (zesty/ubuntu-app-launch)
<kenvandine> robru, i think it's makes sense
<robru> great
<dobey> robru: i'd probably change all the "copy and the delete all the commits" to something like "find the revno of the last released version in the stable series, then do bzr branch lp:foo -r $REVNO newbranch && bzr push -d newbranch lp:~teamowner/project/series" and then associate the branch to the appropriate stable series on lp
<dobey> robru: "delete all the commitsand push" can get icky if one ends up pushing back to trunk :)
-queuebot:#ubuntu-ci-eng- larryprice, https://bileto.ubuntu.com/#/ticket/2576 Destination version missing from changelog (zesty/libertine). Proposed pocket (zesty/ubuntu-app-launch). Release pocket (xenial/ubuntu-app-launch). Successfully built (xenial/libertine)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2675 Destination version missing from changelog (zesty/ubuntu-app-launch). Successfully built (xenial/ubuntu-app-launch)
<robru> dobey: good idea thanks. Will fix in a bit, just stepped out
<ChrisTownsend> robru: The "Destination version missing from changelog (zesty/libertine)" for 2576 is due to a libertine stuck in -proposed, right?
<robru> ChrisTownsend: yeah
<ChrisTownsend> robru: Ok, so I need a coredev(?) to remove the -proposed version?
<robru> ChrisTownsend: that's an option
<ChrisTownsend> robru: What other options?
<robru> ChrisTownsend: you could also fix trunk
<ChrisTownsend> robru: Hrm, this is the landing in trunk.
<robru> Brb tho sorry
<ChrisTownsend> robru: No worries, it's eow, so we'll take it up Monday.  Thanks!
<dobey> ChrisTownsend: yes ask for it to be deleted from proposed
<ChrisTownsend> dobey: Ok
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Preparing packages
-queuebot:#ubuntu-ci-eng- boiko tiagosh renato bfiller, https://bileto.ubuntu.com/#/ticket/2629 Failed to build (xenial/telephony-service, zesty/telephony-service). Ready to build (xenial/online-accounts-api). Release pocket (zesty/online-accounts-api). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/empathy, xenial/history-service, xenial/indicator-transfer-buteo, xenial/libircclient, xenial/messaging-app, xenial/mes
#ubuntu-ci-eng 2017-04-01
-queuebot:#ubuntu-ci-eng- bschaefer, https://bileto.ubuntu.com/#/ticket/2683 Preparing packages
-queuebot:#ubuntu-ci-eng- bschaefer, https://bileto.ubuntu.com/#/ticket/2683 zesty/mir: Failed to commit https://code.launchpad.net/~mir-team/mir/0.27. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- bschaefer, https://bileto.ubuntu.com/#/ticket/2683 Ready to build
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2658 Successfully built
-queuebot:#ubuntu-ci-eng- dbarth, https://bileto.ubuntu.com/#/ticket/2682 Diff missing
-queuebot:#ubuntu-ci-eng- tsdgeos, https://bileto.ubuntu.com/#/ticket/2649 Bad merges (zesty/miral). Destination version missing from changelog (zesty/mir). Failed to build (xenial/miral, xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/unity-system-compositor). Successfully built (xenial/mir, xenial/unity-system-compositor, zesty/qtmir)
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Preparing packages
-queuebot:#ubuntu-ci-eng- ahayzen, https://bileto.ubuntu.com/#/ticket/2642 Successfully built
#ubuntu-ci-eng 2017-04-02
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Currently building (xenial/qtmir, xenial/unity8, zesty/qtmir, zesty/unity8). Failed to build (xenial/qtmir-gles, xenial/qtubuntu-gles, zesty/qtmir-gles, zesty/qtubuntu-gles). Pending binary packages (xenial/qtubuntu, zesty/qtubuntu)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Failed to build (xenial/qtmir-gles, xenial/qtubuntu-gles, zesty/qtmir-gles, zesty/qtubuntu-gles). Pending binary packages (xenial/qtmir, xenial/qtubuntu, xenial/unity8, zesty/qtmir, zesty/qtubuntu, zesty/unity8)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2668 Failed to build (xenial/qtmir-gles, xenial/qtubuntu-gles, zesty/qtmir-gles, zesty/qtubuntu-gles). Successfully built (xenial/qtmir, xenial/qtubuntu, xenial/unity8, zesty/qtmir, zesty/qtubuntu, zesty/unity8)
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2684 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2684 Destination version missing from changelog
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2684 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2684 Destination version missing from changelog
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2684 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2684 Successfully built
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2684 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2684 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2684 Successfully built
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2684 Publishing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2684 UNAPPROVED queue
#ubuntu-ci-eng 2018-03-26
-queuebot:#ubuntu-ci-eng- Trevinho, duflu, https://bileto.ubuntu.com/#/ticket/3190 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, duflu, https://bileto.ubuntu.com/#/ticket/3190 Successfully built
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3216 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, duflu, https://bileto.ubuntu.com/#/ticket/3190 Publishing packages
-queuebot:#ubuntu-ci-eng- Trevinho, duflu, https://bileto.ubuntu.com/#/ticket/3190 UNAPPROVED queue
<Trevinho> sil2100: ^
<sil2100> Trevinho: ACK, looking - so you say this won't be released for artful?
<sil2100> Just xenial?
<Trevinho> sil2100: yes
-queuebot:#ubuntu-ci-eng- Trevinho, duflu, https://bileto.ubuntu.com/#/ticket/3190 Proposed pocket
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3217 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3217 Uploading build
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3217 Pending binary packages
#ubuntu-ci-eng 2018-03-27
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3217 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3217 Pending binary packages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3217 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3206 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3206 Pending binary packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3206 Successfully built
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/3218 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/3218 Successfully built
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3217 Needs rebuild due to higher version at destination (bionic/nodejs). Release pocket (bionic/libnet-ssleay-perl, bionic/python2.7, bionic/python3.6, bionic/python3.7, bionic/ruby-openssl, bionic/ruby2.5). Successfully built (bionic/openssl)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/3218 Publishing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/3218 Proposed pocket
#ubuntu-ci-eng 2018-03-28
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3219 Diff missing
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3206 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3206 Successfully built
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/3220 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/3220 Pending binary packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/3220 Successfully built
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/3220 Publishing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/3220 Proposed pocket
#ubuntu-ci-eng 2018-03-29
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3215 Needs rebuild due to burned version number
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3219 Needs rebuild due to higher version at destination
#ubuntu-ci-eng 2018-03-30
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3215 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3206 Publishing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3206 Proposed pocket
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3206 Release pocket
#ubuntu-ci-eng 2020-03-23
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3982 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3986 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3986 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3985 Uploading build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3985 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3985 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3985 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3986 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3986 Successfully built
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Currently building (focal/ibus). Dependency wait (focal/node-unicode-property-value-aliases, focal/node-unicode-property-value-aliases-ecmascript). Diff missing (focal/unicode-data). Failed to build (focal/wine-development). Pending binary packages (focal/fntsample, focal/node-unicode-property-aliases, focal/node-unicode-property-aliases-ecmascript)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Dependency wait (focal/node-unicode-property-value-aliases, focal/node-unicode-property-value-aliases-ecmascript). Diff missing (focal/fntsample, focal/unicode-data). Failed to build (focal/wine-development). Pending binary packages (focal/ibus, focal/node-unicode-property-aliases, focal/node-unicode-property-aliases-ecmascript)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Dependency wait (focal/node-unicode-property-value-aliases, focal/node-unicode-property-value-aliases-ecmascript). Diff missing (focal/fntsample, focal/node-unicode-property-aliases, focal/node-unicode-property-aliases-ecmascript, focal/unicode-data). Failed to build (focal/wine-development). Pending binary packages (focal/ibus)
#ubuntu-ci-eng 2020-03-24
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Dependency wait (focal/node-unicode-property-value-aliases, focal/node-unicode-property-value-aliases-ecmascript). Diff missing (focal/fntsample, focal/ibus, focal/node-unicode-property-aliases, focal/node-unicode-property-aliases-ecmascript, focal/unicode-data). Failed to build (focal/wine-development)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Diff missing (focal/fntsample, focal/ibus, focal/node-unicode-property-aliases, focal/node-unicode-property-aliases-ecmascript, focal/unicode-data). Failed to build (focal/wine-development). Pending binary packages (focal/node-unicode-property-value-aliases, focal/node-unicode-property-value-aliases-ecmascript)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Diff missing (focal/fntsample, focal/ibus, focal/node-unicode-property-aliases, focal/node-unicode-property-aliases-ecmascript, focal/node-unicode-property-value-aliases, focal/node-unicode-property-value-aliases-ecmascript, focal/unicode-data). Failed to build (focal/wine-development)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Diff missing (focal/fntsample, focal/ibus, focal/node-unicode-property-aliases, focal/node-unicode-property-aliases-ecmascript, focal/node-unicode-property-value-aliases, focal/node-unicode-property-value-aliases-ecmascript). Failed to build (focal/wine-development). Proposed pocket (focal/unicode-data)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Generating diffs
-queuebot:#ubuntu-ci-eng- Laney Trevinho, https://bileto.ubuntu.com/#/ticket/3983 Publishing packages
-queuebot:#ubuntu-ci-eng- Laney Trevinho, https://bileto.ubuntu.com/#/ticket/3983 Publish failed: Diff missing
-queuebot:#ubuntu-ci-eng- Laney Trevinho, https://bileto.ubuntu.com/#/ticket/3983 Generating diffs
-queuebot:#ubuntu-ci-eng- Laney Trevinho, https://bileto.ubuntu.com/#/ticket/3983 Successfully built
-queuebot:#ubuntu-ci-eng- Laney Trevinho, https://bileto.ubuntu.com/#/ticket/3983 Publishing packages
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Proposed pocket (focal/unicode-data). Successfully built (focal/fntsample, focal/ibus, focal/node-unicode-property-aliases, focal/node-unicode-property-aliases-ecmascript, focal/node-unicode-property-value-aliases, focal/node-unicode-property-value-aliases-ecmascript, focal/wine-development)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- Laney Trevinho, https://bileto.ubuntu.com/#/ticket/3983 Proposed pocket
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Generating diffs
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Pending binary packages (focal/wine-development). Proposed pocket (focal/unicode-data). Successfully built (focal/fntsample, focal/ibus, focal/node-unicode-property-aliases, focal/node-unicode-property-aliases-ecmascript, focal/node-unicode-property-value-aliases, focal/node-unicode-property-value-aliases-ecmascript)
-queuebot:#ubuntu-ci-eng- Laney Trevinho, https://bileto.ubuntu.com/#/ticket/3983 Proposed pocket (focal/gnome-session, focal/gnome-shell, focal/gnome-shell-extension-ubuntu-dock, focal/gnome-shell-extensions, focal/mutter, focal/yaru-theme). Release pocket (focal/gnome-shell-extension-appindicator)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Proposed pocket (focal/unicode-data). Successfully built (focal/fntsample, focal/ibus, focal/node-unicode-property-aliases, focal/node-unicode-property-aliases-ecmascript, focal/node-unicode-property-value-aliases, focal/node-unicode-property-value-aliases-ecmascript, focal/wine-development)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Publishing packages
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Publish failed: Pending binary packages
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Pending binary packages (focal/unicode-data). Successfully built (focal/fntsample, focal/ibus, focal/node-unicode-property-aliases, focal/node-unicode-property-aliases-ecmascript, focal/node-unicode-property-value-aliases, focal/node-unicode-property-value-aliases-ecmascript, focal/wine-development)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Generating diffs
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Publishing packages
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Proposed pocket
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Proposed pocket (focal/ibus, focal/node-unicode-property-aliases, focal/node-unicode-property-aliases-ecmascript, focal/node-unicode-property-value-aliases, focal/node-unicode-property-value-aliases-ecmascript, focal/unicode-data, focal/wine-development). Release pocket (focal/fntsample)
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3984 Uploading build
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3984 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3926 Updates pocket
-queuebot:#ubuntu-ci-eng- Laney Trevinho, https://bileto.ubuntu.com/#/ticket/3983 Proposed pocket (focal/gnome-session, focal/gnome-shell, focal/gnome-shell-extensions, focal/mutter, focal/yaru-theme). Release pocket (focal/gnome-shell-extension-appindicator, focal/gnome-shell-extension-ubuntu-dock)
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3984 Generating diffs
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3984 Successfully built
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3989 Merging branches
-queuebot:#ubuntu-ci-eng- Laney Trevinho, https://bileto.ubuntu.com/#/ticket/3983 Release pocket (focal/gnome-session, focal/gnome-shell, focal/gnome-shell-extension-appindicator, focal/gnome-shell-extension-ubuntu-dock, focal/gnome-shell-extensions, focal/yaru-theme). Successfully built (focal/mutter)
-queuebot:#ubuntu-ci-eng- Laney Trevinho, https://bileto.ubuntu.com/#/ticket/3983 Release pocket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3985 Uploading build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3985 Successfully built
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3984 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3984 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3985 Uploading build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3985 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3985 Successfully built
#ubuntu-ci-eng 2020-03-25
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3990 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/3990 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3990 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3990 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3986 Successfully built (focal/libvirt). Uploading build (focal/qemu)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3990 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3986 Pending binary packages (focal/qemu). Successfully built (focal/libvirt)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3986 Diff missing (focal/qemu). Successfully built (focal/libvirt)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3991 Pending binary packages
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3991 Successfully built
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Currently building (focal/kio, focal/kwayland, focal/kwidgetsaddons, focal/modemmanager-qt, focal/networkmanager-qt, focal/sonnet, focal/threadweaver). Diff missing (focal/attica-kf5, focal/breeze-icons, focal/extra-cmake-modules, focal/kactivities-stats, focal/kapidox). Failed to build (focal/ktexteditor, focal/ktextwidgets, focal/kunitconversion, focal/kwallet-kf5, focal/kxmlgui, focal/kxmlrp
-queuebot:#ubuntu-ci-eng- ahasenack kanashiro, https://bileto.ubuntu.com/#/ticket/3977 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Currently building (focal/kunitconversion, focal/networkmanager-qt). Diff missing (focal/attica-kf5, focal/baloo-kf5, focal/bluez-qt, focal/breeze-icons, focal/extra-cmake-modules, focal/frameworkintegration, focal/kactivities-kf5, focal/kactivities-stats, focal/kapidox, focal/karchive, focal/kauth, focal/kbookmarks, focal/kcmutils, focal/kcodecs, focal/kcompletion, focal/kconfig, focal/kconfig
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Diff missing (focal/attica-kf5, focal/baloo-kf5, focal/bluez-qt, focal/breeze-icons, focal/extra-cmake-modules, focal/frameworkintegration, focal/kactivities-kf5, focal/kactivities-stats, focal/kapidox, focal/karchive, focal/kauth, focal/kbookmarks, focal/kcmutils, focal/kcodecs, focal/kcompletion, focal/kconfig, focal/kconfigwidgets, focal/kcoreaddons, focal/kcrash, focal/kdbusaddons, focal/kd
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Diff missing (focal/attica-kf5, focal/baloo-kf5, focal/bluez-qt, focal/breeze-icons, focal/extra-cmake-modules, focal/frameworkintegration, focal/kactivities-kf5, focal/kactivities-stats, focal/kapidox, focal/karchive, focal/kauth, focal/kbookmarks, focal/kcmutils, focal/kcodecs, focal/kcompletion, focal/kconfig, focal/kconfigwidgets, focal/kcoreaddons, focal/kcrash, focal/kdbusaddons, focal/kd
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Currently building (focal/kxmlgui, focal/qqc2-desktop-style). Diff missing (focal/attica-kf5, focal/baloo-kf5, focal/bluez-qt, focal/breeze-icons, focal/extra-cmake-modules, focal/frameworkintegration, focal/kactivities-kf5, focal/kactivities-stats, focal/kapidox, focal/karchive, focal/kauth, focal/kbookmarks, focal/kcmutils, focal/kcodecs, focal/kcompletion, focal/kconfig, focal/kconfigwidgets
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Diff missing (focal/attica-kf5, focal/baloo-kf5, focal/bluez-qt, focal/breeze-icons, focal/extra-cmake-modules, focal/frameworkintegration, focal/kactivities-kf5, focal/kactivities-stats, focal/kapidox, focal/karchive, focal/kauth, focal/kbookmarks, focal/kcmutils, focal/kcodecs, focal/kcompletion, focal/kconfig, focal/kconfigwidgets, focal/kcoreaddons, focal/kcrash, focal/kdbusaddons, focal/kd
#ubuntu-ci-eng 2020-03-26
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Diff missing (focal/attica-kf5, focal/baloo-kf5, focal/bluez-qt, focal/breeze-icons, focal/extra-cmake-modules, focal/frameworkintegration, focal/kactivities-kf5, focal/kactivities-stats, focal/kapidox, focal/karchive, focal/kauth, focal/kbookmarks, focal/kcmutils, focal/kcodecs, focal/kcompletion, focal/kconfig, focal/kconfigwidgets, focal/kcoreaddons, focal/kcrash, focal/kdbusaddons, focal/kd
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Diff missing
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Generating diffs
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Successfully built
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Publishing packages
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Proposed pocket
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Proposed pocket (focal/attica-kf5, focal/baloo-kf5, focal/bluez-qt, focal/breeze-icons, focal/extra-cmake-modules, focal/frameworkintegration, focal/kactivities-kf5, focal/kactivities-stats, focal/kapidox, focal/karchive, focal/kauth, focal/kbookmarks, focal/kcmutils, focal/kcompletion, focal/kconfig, focal/kconfigwidgets, focal/kcoreaddons, focal/kcrash, focal/kdbusaddons, focal/kdeclarative, 
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3992 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/3992 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3992 Failed to build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3986 Successfully built (focal/libvirt). Uploading build (focal/qemu)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3992 Generating diffs
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3993 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/3986 Pending binary packages (focal/qemu). Successfully built (focal/libvirt)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3991 Generating diffs
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3991 Publishing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3986 Diff missing (focal/qemu). Successfully built (focal/libvirt)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3991 Proposed pocket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3992 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3992 Pending binary packages
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Needs rebuild due to higher version at destination (focal/kquickcharts). Proposed pocket (focal/attica-kf5, focal/baloo-kf5, focal/bluez-qt, focal/extra-cmake-modules, focal/frameworkintegration, focal/kactivities-kf5, focal/kactivities-stats, focal/kapidox, focal/karchive, focal/kauth, focal/kbookmarks, focal/kcmutils, focal/kcompletion, focal/kconfig, focal/kconfigwidgets, focal/kcoreaddons, 
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3992 Successfully built
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Needs rebuild due to higher version at destination (focal/kquickcharts). Proposed pocket (focal/attica-kf5, focal/baloo-kf5, focal/bluez-qt, focal/extra-cmake-modules, focal/frameworkintegration, focal/kactivities-stats, focal/kapidox, focal/kauth, focal/kbookmarks, focal/kcmutils, focal/kcompletion, focal/kconfig, focal/kconfigwidgets, focal/kcoreaddons, focal/kcrash, focal/kdeclarative, focal
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3991 Release pocket
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Needs rebuild due to higher version at destination (focal/kquickcharts). Proposed pocket (focal/attica-kf5, focal/baloo-kf5, focal/bluez-qt, focal/extra-cmake-modules, focal/frameworkintegration, focal/kactivities-stats, focal/kapidox, focal/kauth, focal/kbookmarks, focal/kcmutils, focal/kcompletion, focal/kconfig, focal/kconfigwidgets, focal/kcoreaddons, focal/kcrash, focal/kdeclarative, focal
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3986 Pending binary packages (focal/qemu). Successfully built (focal/libvirt)
-queuebot:#ubuntu-ci-eng- ahasenack kanashiro, https://bileto.ubuntu.com/#/ticket/3977 Pending binary packages
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Needs rebuild due to higher version at destination (focal/kquickcharts). Proposed pocket (focal/attica-kf5, focal/baloo-kf5, focal/bluez-qt, focal/frameworkintegration, focal/kactivities-stats, focal/kauth, focal/kbookmarks, focal/kcmutils, focal/kcompletion, focal/kconfig, focal/kconfigwidgets, focal/kcoreaddons, focal/kcrash, focal/kdeclarative, focal/kded, focal/kdelibs4support, focal/kdesig
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3986 Diff missing (focal/qemu). Successfully built (focal/libvirt)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3986 Pending binary packages (focal/qemu). Successfully built (focal/libvirt)
-queuebot:#ubuntu-ci-eng- ahasenack kanashiro, https://bileto.ubuntu.com/#/ticket/3977 Successfully built
-queuebot:#ubuntu-ci-eng- ahasenack kanashiro, https://bileto.ubuntu.com/#/ticket/3977 Generating diffs
-queuebot:#ubuntu-ci-eng- ahasenack kanashiro, https://bileto.ubuntu.com/#/ticket/3977 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3986 Diff missing (focal/qemu). Successfully built (focal/libvirt)
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Needs rebuild due to higher version at destination (focal/kquickcharts). Proposed pocket (focal/attica-kf5, focal/baloo-kf5, focal/bluez-qt, focal/frameworkintegration, focal/kauth, focal/kbookmarks, focal/kcmutils, focal/kcompletion, focal/kconfig, focal/kconfigwidgets, focal/kcoreaddons, focal/kcrash, focal/kdeclarative, focal/kded, focal/kdelibs4support, focal/kdesignerplugin, focal/kdesu, f
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3978 Merging branches
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3985 Successfully built
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3994 Preparing packages
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3994 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3994 Pending binary packages
-queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/3915 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3985 Pending binary packages
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3994 Diff missing
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3994 Generating diffs
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3994 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3985 Successfully built
-queuebot:#ubuntu-ci-eng- ahasenack kanashiro, https://bileto.ubuntu.com/#/ticket/3977 Pending binary packages
-queuebot:#ubuntu-ci-eng- ahasenack kanashiro, https://bileto.ubuntu.com/#/ticket/3977 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3985 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3986 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- ahasenack kanashiro, https://bileto.ubuntu.com/#/ticket/3977 Generating diffs
-queuebot:#ubuntu-ci-eng- ahasenack kanashiro, https://bileto.ubuntu.com/#/ticket/3977 Successfully built
#ubuntu-ci-eng 2020-03-27
-queuebot:#ubuntu-ci-eng- ahasenack kanashiro, https://bileto.ubuntu.com/#/ticket/3977 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3995 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3994 Abandoning ticket
-queuebot:#ubuntu-ci-eng- ahasenack kanashiro, https://bileto.ubuntu.com/#/ticket/3977 Abandoning ticket
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3996 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3996 Uploading build
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3996 Pending binary packages
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3996 Diff missing
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3996 Generating diffs
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3996 Successfully built
#ubuntu-ci-eng 2020-03-28
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3997 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3997 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/3997 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
#ubuntu-ci-eng 2020-03-29
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3998 Preparing packages
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3998 Successfully built
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3998 Publishing packages
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3998 Proposed pocket
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3998 Release pocket
