#ubuntu-ci-eng 2014-04-21
<Chipaca> Mirv: I assume you're not really here
<Mirv> Chipaca: depends :)
<Chipaca> Mirv: i'm looking for a silo :)
<Chipaca> so i'm a silo seeker
<Mirv> Chipaca: for which one, it looks the last one has already?
 * Chipaca looks
<Chipaca> *gasp*!
<Chipaca> Mirv: I hadn't even looked; assumed i needed to ask :)
<Chipaca> \o/
<Mirv> Chipaca: hehe. problem solved, then :)
<Chipaca> man, the double / in the url gets on my nerves.
<Mirv> that's terrible, yes
<Chipaca> Mirv: where's the code that drives this, do you know?
<Chipaca> this == the integration between the spreadsheet and the build farm
<Mirv> Chipaca: it's in the spreadsheet's "Script editor..." but probably needs some extra permissions
 * Chipaca looks
<Chipaca> it's in the metadata tab
<Chipaca> Mirv: if you can edit the metadata tab, removing the ending / in B2 should fix the links
<Chipaca> it's entirely possible the other ones on that tab need a similar fix, but I haven't looked :)
<Mirv> Chipaca: fixed! I hope it's not so that something else assumes it's there, which is entirely possible
<Chipaca> Mirv: I'll tell everybody you broke on purpose it if they ask
<Mirv> thanks, much appreciated
 * Mirv goes back to spring cleaning and sun bathing activities
<mandel> ogra_, when is landing being resumed?
* josepht changed the topic of #ubuntu-ci-eng to: ChipacaUbuntu 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: -
<ogra_> mandel, for 14.04 tomorrow ... for th rest once the new distro exists
<mandel> ogra_, ok, so I have no change of landing udm today :(
<ogra_> isnt it a public holiday in spain too ?
<mandel> ogra_, AFAIK it is not
<ogra_> ah
<mandel> ogra_, I have triple checked hehe
<ogra_> heh, here it is
<mandel> ogra_, oh, then.. go and do something!
<ogra_> i am !
<ogra_> :)
 * ogra_ plays with his ebook reader app :) 
<mandel> ogra_, ahhh ok.. do you mindif I ask you a question, I flashed my device as follows: ubuntu-device-flash --channel trusty-proposed --revision 290 --bootstrap
<mandel> ogra_, yet, when I try to check for a system image update I get that I'm up to date.. yet the last image in 301, right?
<ogra_> depends on the device last is 301 for all supported ones
<ogra_> we stopped building for grouper and maguro at some point ... maguro is at 188 ... grouper was somewhere in the 200s
<mandel> ogra_, this is a mako
<ogra_> supported devices should see an update though
<mandel> ogra_, it should not be a problem, and If I do a device-flash without the revision number I get the correct one
<mandel> ogra_, and udm has nothing to do with that check :)
<mandel> ogra_, play with you eboor reader, I'll try to fix it
<mandel> ogra_, also, add support for kindel books ;)
<ogra_> haha, its a super simple thing that converts pdfs into a click package
<ogra_> (effectiverly converting the pdf into a html doc that the app embeds in a webview)
<ogra_> nothing i plan to reelease actually ... (well, i'll make it public for others, but nothing for the store since you need to run the conversion tool to create the click for a specific book)
<mandel> ogra_, oh, well ok, no kindle for me in ubuntu-touch then hehe
<ogra_> i wrote it mainly to scratch my own itch
<mandel> ogra_, have we change anything in the system dbus activation front?
<ogra_> you could convert to pdf and then use it :)
<mandel> ogra_, udm works on the desktop yet not on the phone
<ogra_> not that i konw of
<mandel> ogra_, I'm tempted to do a webapp for kindle..
<ogra_> (though i still suspect there is something wonky in dbus on the phone)
<Chipaca> robru, cyphermox, rsalveti, sil2100, Mirv, didrocks, if any of you happen to be around, silo 8 is ready for landing :)
<mandel> ogra_, weird.. I'm getting dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonical.applications.Downloader was not provided by any .service files
<Chipaca> in other news, I'm going to have lunch
<ogra_> mandel, as phablet user ?
<mandel> ogra_, with sudo
<mandel> ogra_, and /etc/dbus-1/system-services has com.canonical.applications.Downloader.service
<mandel> ogra_, but it the online one.. weird...
<ogra_> hmm, system bus then
<ogra_> are yu making sure you query the system and not the session bus ?
<mandel> ogra_, correct
<mandel> ogra_, 100%
<mandel> ogra_, the session one does work..
<ogra_> hmm, then thats really weird
<mandel> ogra_, don't worry, get back to your ebooks, I'll eat and will think about it
<ogra_> unless there is polkit blocking something
<Chipaca> mandel: lunch is always the right answer
<ogra_> but that should likely return a different error
<Chipaca> pmcgowan: issue that was driving load on phones has been worked around on the server; work around for the client is in a silo
<Chipaca> pmcgowan: (wrt ubuntu push, this is)
<Chipaca> pmcgowan: and good morning :)
<pmcgowan> Chipaca, morning
<pmcgowan> good stuff
<plars> rsalveti: you around today?
<plars> rsalveti: I built one of those serial cables for my nexus and I'm experimenting with it
<plars> rsalveti: I tried it with image 274, and as we sorta figured, when reproducing that stuck boot bug that we had on that image, it doesn't get far enough to get a console
<plars> rsalveti: other than the init conf to launch getty on that line once it's started, did you have any other ideas for how the serial cable might be used to get more control over the device?
<mandel> ogra_, no worries, I have some ideas after lunch hehe
<mandel> Chipaca, as you said ^
<fginther> balloons, I encountered an error when testing the music-app trunk on a device. It looks like org.nemomobile.grilo is not part of the package: http://s-jenkins.ubuntu-ci:8080/job/generic-click-autopilot-runner-mako/96/testReport/music_app.tests.test_music/TestMainWindow/test_next_previous_with_touch_/
<balloons> fginther, grilo hasn't been integrated into the build yet.. I'm not sure of the exact status.. it's supposed to change at some point but hasn't yet
<balloons> do you want to pick a different app?
<fginther> balloons, yes, any recommendations? calendar appears to get a lot of traffic
<balloons> calendar has been going through a lot :-)
<sergiusens> fginther: look at the click view for music app for the 'hack'
<fginther> sergiusens, thanks
<mandel> ogra_, fixed the issue :)
<sergiusens> ogra_: are you on holidays today?
<mandel> sergiusens, yes he is
<mandel> sergiusens, or he should
<mandel> sergiusens, can you pass me the url of the build?
<sergiusens> mandel: you should know how to get to that by now ;-)
<mandel> sergiusens, meh.. you are right, but is easier asking you hehe
<sergiusens> mandel: step one https://wiki.ubuntu.com/citrain
<mandel> sergiusens, I know how to find it, I'm just being laz
<mandel> y
<sergiusens> mandel: step 2, select silo 11
<sergiusens> mandel: then look at Status
<sergiusens> mandel: I'm going to be giving you the pedantic explanation ;-)
<mandel> sergiusens, nooooooooooooo don't be a parent!
<mandel> sergiusens, there is a failure with the given msg => WARNING A version (0.1+14.04.20140417-0ubuntu1) is available at the destination archive for that component but is not in the destination branch which is still at 0.1+14.04.20140410.1-0ubuntu1. You need to ensure that your version contains the fix in the destination or you can force rebuild to bypass the check.
<mandel> sergiusens, which is for the click scope because nothing changed, can that be ignored?
<sergiusens> mandel: I can do that, but are you sure that what's in the archive matches current trunk?
<mandel> sergiusens, yes, or did https://ci-train.ubuntu.com/job/landing-011-1-build/23/console fail due to another reason?
<sergiusens> mandel: from what it says; 0.1+14.04.20140417-0ubuntu1 is in the archive but not in trunk; so if you force rebuild; you may lose stuff that's in the archive; so I'll ask again; are you sure you want to force rebuild?
<mandel> sergiusens, I just want to force a rebuild for umd, not for click scope. But I'm 100% sure that there si no diff between the click scope trunk and the branch we have
<mandel> sergiusens, I just triple checked, so, yes, I'm sure
<mandel> :)
<sergiusens> ok, let me just rebuild udm, you weren't specific in the orig request ;-)
<sergiusens> deploying will also probably fail if this failed; so keep that in mind to tell the train people
<mandel> sergiusens, ok, will let them know, for now I just want to test in mako to ensure that I fixed the dbus activation bug
<sergiusens> mandel: you probably need to change the commit message for this: https://code.launchpad.net/~mandel/unity-scope-click/rebuild-with-udm/+merge/214935
<mandel> sergiusens, very good point, doing
<mandel> sergiusens, done
<sergiusens> mandel: https://ci-train.ubuntu.com/job/landing-011-1-build/24/console
 * sergiusens goes for lunch
<mandel> sergiusens, thx
* fginther changed the topic of #ubuntu-ci-eng to: ChipacaUbuntu 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: -
<balloons> sergiusens, do you have some time this afternoon to have a look at file manager. I remmeber you commenting on the merge dpm did to put the plugin inside the click package. However, the resulting click doesn't run on the device and complains of missing the plugin. Is there something simple we're missing?
<sergiusens> balloons: my whole click chroot setup is a mess and any attempt to recreate it fails though, so I'll need to sort that out first
<balloons> sergiusens, I've been there.. :-) No worries. Nothing off the top of your head that would cause the click to fail? The contents show the plugin, and it's in the right place
<balloons> ^^ afaict
<sergiusens> balloons: how does it fail?
<balloons> https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1294301
<ubot5> Launchpad bug 1294301 in Ubuntu File Manager App "Cmake generated click doesn't work" [Critical,Confirmed]
<balloons> sergiusens, basically it fails to launch the app, giving the feedback that it cannot find the folderlistmodel plugin
<sergiusens> balloons: is it installed into the right location? inside lib/$arch ?
<balloons> sergiusens, click contents show ./lib/arm-linux-gnueabihf/org/nemomobile/folderlistmodel/libfolderlistmodel.so
<sergiusens> balloons: is the paths casing correct?
<sergiusens> let's move to #ubuntu-touch, this is not related to ci
<balloons> true, sry guys :-)
<mandel> sergiusens, everything fixed in silo 11 omer added a comment in the spreadsheet that is not longer valid, can you change it or should we wait for him?
<sergiusens> mandel: he should change it
<mandel> sergiusens, ok, no problem then
<josharenson> fginther, re our discussion last week: I've written a 'performance test' that depends on the deb package glmark2-es2-mir. Now that that's done, how do I go about getting that package/PPA added to the script that sets up the testing environments (at least on tablets)?
<fginther> josharenson, I'll need to do that step. What's the PPA?
<josharenson> Currently, the ppa is ppa:mir-team/staging
<fginther> josharenson, do you have an MP with your changes ready to test?
<josharenson> Yes
<josharenson> fginther: getting link
<josharenson> https://code.launchpad.net/~josharenson/mir/install_glmark2/+merge/216504
<fginther> josharenson, I've made an initial branch for the test runner scripts: lp:~canonical-ci-engineering/+junk/mir-performance-tests-runner-touch, but it's missing the correct command line to initiate the test
<josharenson> fginther: where is the $test_suites variable set?
<fginther> josharenson, it's set within the jenkins job
<fginther> that part needs a little cleanup, working on it now
<josharenson> fginther, so is that the part that needs to be modified? Chris made it seem that if I followed a certain naming convention, they would just run
<fginther> josharenson, I hadn't considered doing it quite like that, but yes, that should work.
<josharenson> fginther, ... alright, does that mean the functionality is already in place?
<fginther> josharenson, I should just be able to add the PPA and update the test suite list to include "test_glmark2-es2-mir"
<fginther> josharenson, let me give this a try with your MP
<josharenson> fginther, can you clarify how it runs test_glmark2-es2-mir? The MP generates an executable "mir_performance_tests" that runs that test case..
<fginther> the jenkins job will run mir_performance_tests via phablet-test-run
<josharenson> fginther, awesome, _should_ work just fine
<fginther> josharenson, I've got a test started here: http://s-jenkins.ubuntu-ci:8080/job/mir-performance-tests-trusty-touch/
<fginther> josharenson, it'll take some time for the build, the tests should run immediately after
<josharenson> ok, the test generates a json file
<josharenson> fginther, will that be part of the jenkins artifacts?
<fginther> josharenson, we'll have to add that. phablet-test-run can copy artifacts, but it will need to be told what to look for in this case
<josharenson> fginther, sure, its a constant, sensical filename
#ubuntu-ci-eng 2014-04-22
<rsalveti> plars: sorry, was off today
<rsalveti> plars: you could try to start the console before the container is fully up
<rsalveti> and see if it helps at least
<didrocks> sil2100: Mirv: hey! FYI, I've changed quite extensively the status computation on the CI Train spreadsheet to get some new features unblocked I'm working on. If you see anything unusual, do not hesitate to tell me :)
<sil2100> didrocks: ok ;) Thanks! What are the new features? Is it for the ci bot? ;p
<didrocks> sil2100: it's for the bot, I wanted to finish the data side before getting to the bot side :)
<didrocks> nothing should be visible in the change (as long as you don't look at the hidden columns)
<didrocks> but the formulas have changed
<Mirv> didrocks: ok :) I took away "/" from B2 in metadata since Chipaca was annoyed by the double "//":s in the URL:s, but it will need to be added back if there was some URL that then lacks the "/" (all URL:s seemed to work for me)
<sil2100> didrocks: coolio ;) Was there any news regarding CI Airline lately?
<didrocks> sil2100: I guess ask the CI guys. They are working on it, I see tickets flowing!
<didrocks> Mirv: you have done that in every silos?
<Mirv> didrocks: I tried all the button links in two silos, I guess the links should be identical in each silo?
<didrocks> Mirv: ah, metadata, yeah! all is fine, thanks ;)
<Mirv> yes, metadata, that :)
<didrocks> Mirv: maybe it's what was breaking the redirect?
<Mirv> didrocks: hmm, that's possible too
* psivaa-afk changed the topic of #ubuntu-ci-eng to: ChipacaUbuntu CI Engineering Team | Vanguard: psivaa | 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> ChipacaUbuntu - I wonder what that is ;)
* popey changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | 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: -
<Chipaca> ooh, i was in the topic?
<Chipaca> morning, all :)
<Chipaca> NoNameYet_xnox: some day you too will be famous
<NoNameYet_xnox> Chipaca: lol =)
<ogra_> once he has a name for sure ;)
<Chipaca> baby steps
<NoNameYet_xnox> Chipaca: this is a protest for inability to upload things into development series =)
<ogra_> ++
<ogra_> i was expecting to see a post over the easter weekend ...
<ogra_> seems i was wrong
<Chipaca> lamp posts, maybe?
<Chipaca> sil2100: Mirv: didrocks: good morning! Could I have a landing for silo 8 / row 25, please?
<Chipaca> or is that what NoNameYet_xnox is complaining about
<sil2100> Chipaca: let me see :)
<sil2100> Chipaca: ah, you mean, you want it landed?
<Chipaca> NoNameYet_xnox: are you complaining about there not being a dev series yet, or are you complaining about not having package upload rights?
<Chipaca> sil2100: um.... is that silly of me?
<ogra_> Chipaca, no dev series
<sil2100> Chipaca: yeah, well, we would recommend waiting for U to open, since the other road is making the upload as an SRU - which might even take more time than waiting for U
<ogra_> Chipaca, we are completely stuck until mark comes across with a name
<sil2100> So I would recommend joining NoNameYet_xnox in the protest!
<Chipaca> sil2100: well... the fixes there would be nice to have on a stable image, unfortunately. Is that SRU land, or do we cut stable images from dev series too?
<didrocks> popey: sil2100: ogra_: Mirv: davmor2: do we need to have a meeting this morning?
<popey> happy to.
<ogra_> didrocks, we need to talk about python-evdev ... there was a long discussion about us bringing it back on the foundations ML
<davmor2> didrocks: yes
<davmor2> :D
<ogra_> but we can do that on IRC
<didrocks> ogra_: IRC is fine for me
<ogra_> ok
<Mirv> hmmkay
 * davmor2 slaps didrocks with a kipper for getting him up this early for no good reason ;)
<sil2100> didrocks: so no meeting? I personally have nothing to report, due to things being blocked landing-wise ;)
<ogra_> didrocks, so barry seems to have had the expectation that dropping of python-evdev actually removes all of python2 his mail sounds slightly unhappy that we brought it back in
<Mirv> davmor2: "this early", 5 hours ago! :)
<didrocks> sil2100: yeah, I think it's useless
<didrocks> ogra_: well, it didn't removed it, right?
<didrocks> ogra_: we saw it only removed python-evdev itself
<ogra_> didrocks, we did for a few images ...
<didrocks> but nothing else
<ogra_> which shows that it does *not* drop any other packages
<didrocks> ogra_: did he even checked on those images before?
<davmor2> Mirv: look just cause you live in the Wrong timezone is not our problem ;)
<didrocks> ogra_: exactly
<didrocks> ogra_: did he track/check that?
<didrocks> or work on why?
<ogra_> didrocks, no, but he insists it has to go any wants the change reverted in an SRU ...
<ogra_> seems gallery app keeps py2 around additionally
<ogra_> https://code.launchpad.net/~barry/gallery-app/py3autopilot/+merge/208055
<ogra_> another proposed SRU for that case
<Mirv> I'm taking some time to please bzoltan to try to get saucy qt 5.2 backport ~done
<didrocks> ogra_: he needs to talk to the SRU team about it anyway
<ogra_> didrocks, not sure what to do, i dont think we should break the world with SRUs
<bzoltan> Mirv: that would be awesome :)
<didrocks> ogra_: well, let him lead that and do all the paperwork
<ogra_> and dropping evdev again will surely cause extra work in the infra
<didrocks> ogra_: I don't care for us, it's easy to bring it back if it's broken
<UtilitarianUvula> My SRU is small, cherry picked to address problems in what got into the stable image
<UtilitarianUvula> FWIW :)
<didrocks> ogra_: he better has to fix the packaging and ensure he doesn't regress
<didrocks> ogra_: if he wants that
<ogra_> didrocks, it still breaks testing
<didrocks> ogra_: so, it's a no
<didrocks> ogra_: it's him who wants to bring that issue, it's him to fix it
<ogra_> which means infra needs work or we keep it as is
<didrocks> not us
<didrocks> and he needs to coordinate with the infra guys
<didrocks> let him lead that
<didrocks> if it's important to him
<ogra_> well, he noeeds to know about the additional work it causes
<didrocks> being clear we won't accept it if it's not all polished
<didrocks> yeah, I didn't see that in any ML I'm in
<ogra_> no, itsthe foundations ML
<didrocks> right
<didrocks> so if he wants that, tell him that he needs to do the work
<didrocks> and coordinate with the needed people
<NoNameYet_xnox> didrocks: coordinate exactly what?
<NoNameYet_xnox> didrocks: the gallery-app merge-proposal is stand alone, porting remaining portions of ap to python3.
<ogra_> NoNameYet_xnox, changing and fixing all tests
<ogra_> NoNameYet_xnox, that wont help if the automated tests all fail
<didrocks> NoNameYet_xnox: apparently ogra_ is telling that dropping python2 from the image will impact the infra
<ogra_> we rolled back because there were issues
<ogra_> right the issue was only found because the infra tests went flat
<NoNameYet_xnox> didrocks: gallery-app merge proposal has nothing to do with dropping python2 from the image, as in just merging that will not cause python2 to be dropped from the image.
<ogra_> NoNameYet_xnox, barry wants python-evdev gone again
<NoNameYet_xnox> cihelp
<didrocks> NoNameYet_xnox: were we talking about the gallery-app MP?
<ogra_> NoNameYet_xnox, whioch causes the automated tests to fail
<didrocks> NoNameYet_xnox: read the beginning of the discussion
<ogra_> gallery-app is just a side note here :)
<ogra_> NoNameYet_xnox, and the gallery-app fix is fine if it passes testing ... its is the breaking of the other tests due to dropping -devdev that causes issues for us since all tests would have to be touched and app devs would always need to test in rw mode)
<ogra_> *-evdev
<popey> NoNameYet_xnox: did you autopilot test sudoku before uploading to the store?
<NoNameYet_xnox> ogra_: that's why i said -evdev should be seeded into ubuntu-touch seed, instead of relying on transitive dependency from one package.
<ogra_> NoNameYet_xnox, right, i was with you on that one but others insisted to just revert the change
<ogra_> which was done in the end
<NoNameYet_xnox> popey: sudoku ? sudoku was published at 180 2 weeks ago and i didn't upload that recently.
<popey> NoNameYet_xnox: sorry, I meant stock ticker. my bad
<ogra_> same thing :)
<popey> hah
<NoNameYet_xnox> popey: i did a while a go, but not on the latest-greatest trusty image. it will be a while until i can upgrade to retest on recent. (dual-boot is preventing installing upgrades due to "not enough battery")
<popey> NoNameYet_xnox: we always autopilot test before uploading core-apps to the store. please can you run it next time before upload?
<NoNameYet_xnox> popey: ok. in this particular case, it can't go worse, since stock-ticket autopilot tests have never passed =)
<NoNameYet_xnox> popey: and they were fixed to finally work in recent commits.
<popey> â»
<NoNameYet_xnox> popey: when my phone charges up enough, i'll rerun the tests.
<popey> k
<popey> Thank you.
<UtilitarianUvula> Mirv: in answer to your quesiton on the spreadsheet, it can also go to U, yes; I'll be merging trunk (which has these changes) into automatic (which these changes were cherrypicked from) once things are landed
<UtilitarianUvula> you know, the closer we get to Zaftig Zebra, the more nervous I am every time a name needs to be announced
<pete-woods> didrocks: hi, is there any information about how the CI train works with SRUs?
<didrocks> pete-woods: just do as usual, and don't diverge too much, like focus on bug fixing
<pete-woods> basically I have a bug fix for something in trusty main, and wondered what the process would be, (being a person who has never had upload rights, that sorta thing)
<pete-woods> as usual means use CI train? or means follow the SRU page on the wiki?
<ogra_> both :)
<didrocks> pete-woods: yeah, both
<didrocks> just follow the SRU page
<UtilitarianUvula> didrocks: are stable images only cut from stable releases?
<didrocks> and proposed your fix to trunk
<didrocks> UtilitarianUvula: for now, yes
<didrocks> it's still under discussions
<UtilitarianUvula> ok :)
<pete-woods> didrocks, ogra_: okay, thanks guys, that makes sense :)
<didrocks> pete-woods: yw ;)
<Mirv> UtilitarianUvula: yeah I meant only U or also T. for SRU you need to file a bug with Impact/TestCase/RegressionPotential and also otherwise follow the https://wiki.ubuntu.com/StableReleaseUpdates instructions
<UtilitarianUvula> Mirv: ah, ok. But to SRU I need it in U first :)
<ogra_> well, it needs to land in U at the same time at least
<ogra_> (you can do paperwork and prepare the trusty side even without U existing)
<UtilitarianUvula> okie doke
<UtilitarianUvula> should I create a new bug for all the things fixed in the branch, or should I tag each bug fixed in the branch separately?
<UtilitarianUvula> the former sounds like less hassle
<mandel> om26er, hello! so you were right and umd was broken!!! sorry for doubting you! mea culpa!
<mandel> om26er, I have updated the code and now it works perfectly ok (I have tested and retested) can you take a look?
<om26er> mandel, sure no problem, Since the release is out i guess you wont need my testing onow
<mandel> om26er, probably not, but you added a comment and it does not feel right if I edit it :)
<mandel> om26er, is better that you do it
<om26er> mandel, yes, sure. let me do that.
<mandel> om26er, awesome, thx
<didrocks> ogra_: I kicked an image to check that the infra is working fine
<ogra_> ok
<davmor2> Morning all
<imgbot> === trainguard: IMAGE 303 building (started: 20140422 10:00) ===
 * popey spies a bazillion webapps from ogra_ 
<ogra_> haha
<ogra_> only 15
 * didrocks goes for a run
<mardy> Can please someone help me in making Jenkins build this: https://code.launchpad.net/~mardy/signon-ui/oxide/+merge/215661 ?
<davmor2> ogra_: did you poach popey 's create a webapp is one easy script or something
<popey> not my script
<ogra_> i have my own script
<ogra_> :)
<ogra_> but i just learned that the app name doesnt come from the .desktop file anymore
 * ogra_ edits all the app neames :(
<popey> yeah, when i saw them appear in the store I thought "he probably doesn't want that"
<ogra_> and with bild.de we finally have the true yellow press in the store
 * ogra_ notices that no brit is brave enogh to upload a sun.co.uk webapp :P
<davmor2> ogra_: that's cause we'd rather chew our own arms off
<NoNameYet_xnox> ogra_: haha
<ogra_> davmor2, well, you dont have to use it :)
<imgbot> === trainguard: IMAGE 303 DONE (finished: 20140422 11:15) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/303.changes ===
<ogra_> didrocks, seems to still work
<popey> anyone else see nothing "available" from the app scope on #302?
<popey> http://popey.com/~alan/phablet/device-2014-04-22-122428.png
<sil2100> Works fine here
<davmor2> popey: how many apps do you have open?
<ogra_> same here
<popey> davmor2: 5
<popey> just the ones you see on that screenshot
<ogra_> is your U1 auth messed up perhaps ?
<popey> its there
<popey> dunno how I'd know if it was messed up tbh
<ogra_> heh, me neither
<popey> ah!
<popey> if I search, i then see available category
<davmor2> popey: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-04-22-122906.png same 5 apps open
<popey> nowsearching unblocked it
<sil2100> Notabug, ship it!
<popey> we did!
<sil2100> Oh...
<sil2100> ;)
<davmor2> only click updates right?
* 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: -
* retoaded 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: iSCSI server is down affecting s-jenkins and q-jenkins
* retoaded 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: iSCSI server is down affecting s-jenkins and q-jenkins
<bfiller> sil2100: hi, can I have a silo assigned for line 26 please?
<sil2100> bfiller: sure, give me a moment ;)
<rsalveti> morning
<Mirv> bfiller: sil2100: assigned
<bfiller> thanks guys
<sil2100> ;)
<Mirv> bfiller: as usual, it targets trusty still so if you want to land it to trusty you'll need SRU bug filed
<Mirv> and if you want to land it to U series, you need to wait until we have a name for U...
<sil2100> Well, for experimenting and testing, silos are good anyway
<sil2100> Since we don't have too many reliable usages now anyway before U is opened
<bfiller> Mirv: are we building anymore trusty phone images?
<Mirv> bfiller: today we built one, and probably tomorrow too at least if U doesn't open. I don't know the grand plan, though.
<alecu> hello
<sergiusens> Mirv: is there any plan in motion to be able to still release the gallery, camera et.al. as just click? I gess bfiller can continue work on that side
<sergiusens> a merge and commit without a publishing
<ogra_> sergiusens, there is  big MP from barry to switch gallery to py3
<sergiusens> ogra_: can't go into trunk, which means it can't get to the click which means it is also blocked with our current infra
<ogra_> yes, it is SRU blocked anyway
<ogra_> without a U release where it can land first
<sergiusens> ogra_: if it were just a click package it can get to the store
<cjwatson> In the past we've gone ahead with SRUs in advance of the next series opening
<sergiusens> ogra_: no need for SRUs there
<cjwatson> I don't see why we should suddenly start hard-blocking on that now
<ogra_> cjwatson, yeah, i would expect it could land at the same time at least
<ogra_> so that the SRU work could already be done
<cjwatson> We just need to make sure that we copy things forward as needed
<ogra_> sergiusens, well, not so sure ... we should actually define how we update core apps for released systems ...
<sergiusens> ogra_: all core apps have been getting updates since saucy was released ;-)
<ogra_> probably less strict than SRUs but we kind of need to make sure they get enough testing on the old image etc
<ogra_> did anyone ever test them against saucy ? :)
<sergiusens> ogra_: well that was one of my complaints about autopilot making a change in it's API; apps became untestable
<ogra_> right ...
<ogra_> :/
<ogra_> that will bite us at some point i guess
<ogra_> (i really dont care if they work on saucy but we will have to test backwards compatibility from some point on)
<ogra_> (once we had our first "stable" release)
<sergiusens> ogra_: anyways, fwiw, I thought the store for clicks would of been treated the same as a partner archive
<sergiusens> ogra_: I would put emphasis to still run the click tests on trusty now (as part of ci)
<ogra_> right
<ogra_> well, i think core apps that we actually ship by default need some special treatment wrt testing backwards compatibility
<sil2100> Damn, thunder close by
<ogra_> russians ?
<ogra_> :)
<popey> lol
<rsalveti> plars: would you mind trying the serial console with http://paste.ubuntu.com/7307282/?
<rsalveti> that will give you a tty1 right after the kernel is done booting
<ogra_> rsalveti, why wait on cdmanager ?
<ogra_> *cg
<plars> rsalveti: will do
<rsalveti> ogra_: don't need to wait on it specifically, just wanted it to be started together with the container
<rsalveti> and not blocked by it
<ogra_> i would just start on startup :)
<ogra_> then you can even watch the container starting :)
<rsalveti> right, let me try if that would work
<rsalveti> plars: ogra_: yeah, startup went fine as well: http://paste.ubuntu.com/7307308/
<ogra_> right, as long as the device node exists and getty is available it shoudl be fine
<rsalveti> yup
<ogra_> botrh is dealt with in the initrd
<plars> rsalveti: that seems to get me a login pretty early
<ogra_> cool
<plars> but...
<ogra_> dont say that !
<ogra_> :)
<plars> it's hard to say if adb is available by then anyway
<rsalveti> oh, it's not
<ogra_> it isnt
<ogra_> adb starts after the container
<rsalveti> adb needs the container to be up
<ogra_> or after the container properly failed
<plars> the hope here was that even if the device gets wedged in a state where nothing works (stuck booting but can't get to fastboot, or recover, or adb, or anything) that we could use this to recover from it
<ogra_> if the container didnt attempt to start at all you are screwed
<rsalveti> plars: you can still
<plars> ok, so this would get us shell access earlier at least
<ogra_> (on my list for fixes in U)
<rsalveti> just use the tty to reboot the phone
<plars> could be some corner cases still
<ogra_> i doubt serial will hellp you with the fastboot case
<plars> so now we just need a good way to shove this into the device at install time.. I also added --autologin root so that we get a shell rather than a login
<plars> ogra_: yeah, I suspect there are lots of cases where we're still screwed
<plars> ogra_: so the other avenue we're pursuing is instrumenting the buttons with relays
 * ogra_ wonders why you dont just deply a hacked up adbd job that always starts regardless
<rsalveti> sudo reboot -f bootloader should get you back to the bootloader
<ogra_> right
<plars> which is still complicated I guess since sometimes we don't know what power state the device is in, but in theory you could have it hold the power button down for [? seconds] and also hold the volume up/down for [? seconds] and end up at the bootloader ready to flash a known good image
<rsalveti> ogra_: you could still get adb in some weird states
<rsalveti> uart would always work
<ogra_> true but i guess thats a very rare corner case
<sergiusens> plars: keep in mind that the boot into fastboot sequence is different per device ;-)
<plars> sergiusens: yeah
<rsalveti> yeah, and uart would only work for mako atm
<plars> sergiusens: these devices need a big debug plug on them that gives you full control, so that our lives would be simple :)
<ogra_> they do have it ... if you buy these devices without the case and call them devboards ...
<ogra_> :)
<rsalveti> hm, nexus 7 could have the same uart interface, let me check
<plars> rsalveti: so these plugs might work on flo also?
<rsalveti> will check
<plars> rsalveti: https://plus.google.com/104363289464878469115/posts/AbvyWECLPXo
<rsalveti> right
<plars> https://android.googlesource.com/kernel/tegra/+/b0d6be9e2033745e46624e518f55e067b75bcd50
<rsalveti> but this is for the older n7
<plars> rsalveti: sounds like the n5 might have it also
<plars> rsalveti: can't find anything about manta though
<ogra_> call samsung :)
<rsalveti> yeah, I think they all have an easy way to get uart
<plars> http://www.abclinuxu.cz/blog/Lorris/2013/12/serial-console-on-google-nexus-5
<rsalveti> great
<plars> ogra_: yeah, I'll just call their customer support line and ask about that
<plars> heh
<ogra_> *g*
<rsalveti> plars: yeah, so we could make it work for both mako and flo
<plars> sergiusens: any way with u-d-f to specify an extra/local custom tarball to add at install time? Something like this could go in at install time so it's there from the first boot like that, but I'm guessing this conf file won't be part of the normal image for obvious reasons
<ogra_> you just have to dump it in the right place before the device reboots i guess
<ogra_> or even after install and a forced reboot to recovery
<rsalveti> can't it just be part of the custom tarball?
<rsalveti> or do we need more than one custom tarball?
<sergiusens> plars: wrt rsalveti is on the right track
<ogra_> rsalveti, no, but we need to deploy that tarball
<rsalveti> ogra_: flashing it with u-d-f
<sergiusens> ogra_: what would it have and how do you guarantee it's not stepping on anythings toes?
<ogra_> does u-d-f have an option to inject that ?
<plars> sergiusens: but u-d-f doesn't give us an option to do that, and also, what if we are already testing the custom image?
<rsalveti> we could add the support for multiple custom tarballs, which I believe it was discussed before already
<sergiusens> plars: well I had no requirement for that; was trying to follow the upgrade spec as close as possible
<plars> we really just need to deploy one file, and it's not one that would exist already. but we can't wait until the first boot to deploy it
<ogra_> dumping a signed tarball into /cache/recovery and rebooting into recovery should be enough, no ?
<plars> sure
<sergiusens> I would rather have stgraber's opinion on this
<sergiusens> ogra_: to sign it you would need access to the magic keys
<sergiusens> I can't sign client side
<ogra_> wasnt there an option for unsigned ...
 * ogra_ thought he saw some MP pass by recently 
<sergiusens> plars: it doesn't need to be a customization tarball; just an extra tarball in the image server
<ogra_> https://code.launchpad.net/~jani/goget-ubuntu-touch/tls-skip-verify/+merge/216141
<plars> sergiusens: but I can't put this on the image server
<sergiusens> ogra_: that's for the https server itself
<plars> that's the point
<ogra_> ah, k
<sergiusens> plars: not even on a different channel?
<plars> sergiusens: not if we're going to test the same images
<ogra_> well, if you modify them you taint them in any case
<sergiusens> plars: well it's sort of the same if you are going to inject it anyways
<plars> sergiusens: this is to help make the smoke testing devices more resilient so we have another avenue to recover them if we get a busted image
<ogra_> and if you do that you can as well just adb push ...
<plars> ogra_: and if the image we just flashed is busted?
<ogra_> then you have serial to force it back into bootloader at least
<sergiusens> plars: can't we have this always in and triggered form initrd from a property? ogra_ rsalveti?
<plars> ogra_: then we wouldn't have the opportunity to adb push
<ogra_> sergiusens, i have "fix adbd if no container is there" on top of my TODO
<sergiusens> plars: I can add the option to inject; but it needs to be signed; or you need to discuss this with stgraber at least
<ogra_> wont need a property
<ogra_> but yeah, we could ship some code for special cases
<rsalveti> we could have a property for it, but not sure if we want this enabled by default
<ogra_> properties dont work without container though
<ogra_> apart from grepping presistent.$prop files
<rsalveti> atm we could safely have an upstart job that could start a tty at the right UART
<rsalveti> we're starting adb by default
<ogra_> right
<ogra_> but how do you know the UART device ?
<rsalveti> it'd just need to parse proc/cmdline to find out the right UART
<ogra_> assuming you want that job to be generic
<ogra_> ok, thats trivial
<rsalveti> yup
<ogra_> but only works if the cmdline has a console= entry
<rsalveti> that's fine
<ogra_> (and one that points to an existing device node actually)
<sergiusens> ogra_: rsalveti plars I still prefer to have a .*-debug channel; it would also be used to enable adb once we disable it by default
<sergiusens> and by handling it on the server/image side; we can keep in sync and not play catch up
<ogra_> well, we want to have a developer mode
<ogra_> even on images where  its disabled by default
<plars> sergiusens: that also means we'd need a -debug of things that already have customizations (customized image)
<sergiusens> ogra_: yeah, but you need to manually enable it ;-)
<ogra_> sergiusens, yeah
<ogra_> manually or via a script
<sergiusens> plars: custom images only really on the customization framework; changing the boot cmd goes away from a customization scope
<sergiusens> custom images only really stick to the customization framework; changing the boot cmd goes away from a customization scope
<plars> sergiusens: I wasn't suggesting to change the boot command, just add in that extra file under /etc/init
<sergiusens> plars: well file placing is supposed to stay in /custom for customization
<plars> ah, I see
<sergiusens> plars: just saying, while you say you are customizing the image; it is far from a custom image that we promote as custom images
<plars> so it's more than just something a customization tarball can add
<sergiusens> plars: any tarball can add anything, so we are fine there; it's just not a custom image if you add that mod (market speak)
<ogra_> lets just ship the needed bits by default and add switches to en/disable them
<plars> ogra_: as long as that switch can be flipped before the first boot, but then I think we're back to the same problem
<ogra_> it could be a cmdline option ... but that would mean to need to modify the boot.img
<ogra_> or it could be a property ... for that you would have to touch some file in /data/property/ from recovery
* 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: iSCSI server is down affecting s-jenkins and q-jenkins
<rsalveti> I'd like the developer mode to be enabled via a property or such
<rsalveti> and for that we could use a custom tarball as well
<ogra_> hmm
<sergiusens> yeah, let
<ogra_> i dont want to force people to custom tarballs for just setting a switch
<sergiusens> let's just no call it custom tarball
<sergiusens> as it seems to confuse people
<sergiusens> ogra_: well it's only for ci
<ogra_> adb shell touch /data/property/persist.plars.mode
<ogra_> ;)
<plars> ogra_: that doesn't get wiped when you flash?
<ogra_> if itr does you just touch it again while you flash
<plars> sure, so we would just  need a --pwned option in u-d-f
<rsalveti> ogra_: right, the custom is just because we can deploy custom properties with it
<ogra_> --plarsed :)
<rsalveti> but yeah, anyway, we could hack it around
<rsalveti> let's just enabled it by default and we can clean everything up once we create the developer mode switch
<ogra_> right, we just need to put it under the switch later
<plars> sure, this could probably all be part of the developer mode once we have a real consumer/product mode for it to be distinct
<ogra_> right
<ogra_> we should probably aggregate all that into one package
<ogra_> so that you can just omit that package at build time for images that are not supposed to ever have a dev mode
<plars> yeah
<ogra_> didrocks, did you plan to have an evening meeting ?
<ogra_> (its not like much changed since the morning)
<sil2100> I wouldn't mind, but I don't have too much to say/discuss landing-wise still
<ogra_> right, and landings are still getting to -proposed only anyway
<ogra_> or did anything migrate to -updates yet
<didrocks> ogra_: we do have an image
<didrocks> so I guess just a 10 minutes one would be find
<ogra_> sure
<didrocks> fine*
<ogra_> not like it has any interesting changes though :)
<didrocks> ogra_: what? popey's changes are uninteresting? :)
<ogra_> nah, but i trust them to be heavily tested anyway
 * popey hugs ogra_ 
<popey> nice recovery
<ogra_> and tehz CI infra is off
<ogra_> so we dont get any automated results
<didrocks> ogra_: hum, why?
<didrocks> plars: ? ^
<ogra_> didrocks, see the ML
<plars> didrocks: apparently there's a storage failure in the dc
<didrocks> ah, like 10 minutes ago :p
<didrocks> don't ask me to be fresh on the last 10 minutes ;)
<ogra_> pfft
<sil2100> ;)
<didrocks> robru: popey: coming?
<robru> didrocks, any word when U is going to open?
<ogra_> lol
<didrocks> robru: I don't know more than you. We need a name first :p
 * ogra_ points robru to sabdfl 
<ogra_> please ask there
<Laney> srsly
<Laney> we should redesign this new name process :(
<ogra_> robru, dont count on being able to land anything in U this week ... even if we have a name it will take a few days to get everyhitng up and runnning
<robru> ok
<ogra_> Laney, ++
<ogra_> we should juat use random letter generators
<ogra_> *just
<Laney> like the early nexus 7 images?
 * Laney sniggers
<robru> didrocks, so what are we doing with landings then? should I just take the week off? ;-)
<ogra_> you can land stuff in trusty-proposed
<Laney> not anything though
<robru> just fixes right?
<ogra_> SRU stuff, yeah
<Laney> https://wiki.ubuntu.com/StableReleaseUpdates#When
<sil2100> robru: it is best to ask everyone if they want their fix to land as an SRU or maybe they prefer waiting for U ;)
<robru> sil2100, well I doubt anybody will *prefer* to wait an extra week on their landings.
<ogra_> and make sure they understand how much paperwork an SRU can be :)
<robru> sil2100, it's more like "how life threatening is this landing?"
<sil2100> robru: well, SRUs can take a week as well, and a lot of paperwork which we will not do for them
<sil2100> robru: so sometimes it might not be even worth it
<robru> sil2100, oh, we're not doing the SRU paperwork? yippee!
<ogra_> why would you
<asac> all went fine today?
<ogra_> asac, what would you expect to have "gone"
<ogra_> we are all stuck
<ogra_> new release cant open
<asac> ok i realize it was a bit of a loaded question :)
<ogra_> heh
<asac> I take, besides that it seems to be all good :)
<ogra_> nothing moved, so nothing broke :)
<ogra_> well, not true, popey landed some well tested click packages and didier rolled an image including them
<asac> see
<asac> thats how it should be; just hold the line by name :P
<asac> lol
<ogra_> heh
<robru> ogra_, cyphermox : I seem to be getting red light of death on my nexus 4. you guys ever seen this? http://forum.xda-developers.com/nexus-4/general/final-fix-nexus-4-red-light-death-t2250454
<robru> i'm not really well equipped for opening the phone
<robru> guess i gotta go buy some torx wrenches... sigh
<pmcgowan> robru, you should not need to
<pmcgowan> red light is good, let it charge
<robru> pmcgowan, yeah, I've seen it before where it won't turn on but then i let it charge for a few hours and it's fine... but in this case it was plugged in through the entire easter weekend
<pmcgowan> robru, with the wall wart?
<pmcgowan> it can get in a state where its not actually charging
<robru> pmcgowan, no, plugged into laptop usb
<pmcgowan> yeah usb not good enough
<pmcgowan> when its low, needs more amps
<robru> pmcgowan, ok, it's plugged into the wall now, i'll give it a shot again in a bit
<pmcgowan> ok
<robru> hmmm now it's turned itself on after just a couple minutes of charging ;-)
<pmcgowan> robru, perfect
<pmcgowan> thats what it do
<robru> pmcgowan, thanks, saved me a long trip to the store ;-)
<pmcgowan> in my experience they can always be revived
<pmcgowan> plug in, loooong press, what for redlight, let it charge
<robru> pmcgowan, yeah, I've revived it a couple times before, but usually only after it had been unplugged for a long time. never seen it die after being plugged in all weekend
<pmcgowan> that is odd
<pmcgowan> but if laptop was off, usb was too
<robru> pmcgowan, no no, laptop is always on ;-)
<kgunn> asac: you on?
<kgunn> wondering if there is like a master view of transitioning touch from trusty to whatever "u" is gonna be
<kgunn> and sort of a hidden question there, if i think we're gonna land mir soon... e.g.  non-blocking swap buffers which fixes qt gui thd block
<kgunn> should that be for both trusty and "u"
<robru> kgunn, from my perspective, the only value of landing fixes in trusty is if they impact the unity8 preview session for desktop users... if you're talking about phone-only fixes then they should just wait for u.
<kgunn> robru: thanks...in that instance it sounds like a "u" target
<kgunn> sorry to be so out of touch, if i land something today...is it "u" by default?  or does it go to trusty ?
<kgunn> i would assume "u"...
<robru> kgunn, well it goes to "trusty" because u doesn't exist yet. but it can't get to trusty without going through SRU, which is a lot of paperwork and extra testing
<robru> kgunn, so for the most part all landings are blocked until u gets created, unless we're talking about some critical desktop fix, then we can SRU it for trusty
<pmcgowan> kgunn, we can all take vacation until mark has a name
<robru> pmcgowan, yes, that's what ogra told me earlier today ;-)
<pmcgowan> I see NoNameYet is catching on
 * kgunn thinks ...what!?!?!
<robru> it does seem a little bit silly to me that our entire operation is completely held up on one guy picking a codename. I'm not sure why we couldn't just open an archive called literally "u" and starting landing there, and then just rename it later
<cjwatson> Sadly that would break a bunch of stuff
<cjwatson> I spent some time thinking about it last cycle and thought "nah, Mark will have learned his lesson and this won't happen again"
<robru> cjwatson, does your IRC client ping you at every mention of "archive"? ;-)
<cjwatson> No, I just happened to be reading ...
 * kgunn also considers old will shakespeare...a rose is a rose
<cjwatson> I also thought about making the version the primary "name" rather than the codename, although that also has complicated problems associated with it
<josharenson> doanac, I had a build fail yesterday, but I think I fixed it. How do I manually kick of the jenkins job again?
<doanac> josharenson: can you share the MP?
<cjwatson> Basically I was kind of not motivated to work on this because it's a really stupid problem to have to spend any cycles at all on fixing, rather than just having a dratted codename in the first place
<doanac> josharenson: we are in the midst of an outage so it might not be possible at this very moment
<sergiusens> cjwatson: more importantly, what happens after z?
<robru> cjwatson, true
<kgunn> someone needs to file a bug on the next release that's a showstopper that says we can't release w.o a name for next
<robru> sergiusens, easy, it'll just be zz ;-)
<cjwatson> sergiusens: I assume we wrap around.  I've been whack-a-moling all the cases where people assume codenames are sorted alphabetically for some time
<josharenson> donac: :-p bummer. The MP is https://code.launchpad.net/~josharenson/mir/install_glmark2/+merge/216504 if its possible
<cjwatson> kgunn: AFAIK we actually have a codename, we're just blocked on Mark blogging about it so that we're allowed to make it public
<kgunn> lol
<cjwatson> I kid you not
<robru> cjwatson, how do you "fix" code that sorts ubuntu codenames alphabetically? just hard-code the list without sorting?
<doanac> josharenson: you've done the right thing. I believe this isn't running because our jenkins servers are affected by the outage
<doanac> a new commit on the branch should trigger jenkins to re-run
<cjwatson> robru: Well, you fix the data so that that code doesn't need to exist
<robru> ah
<josharenson> doanac, ok I'll just be patient
<cjwatson> robru: e.g. a while back we fixed the versions of packages in -backports to be ubuntu14.04.1 or similar rather than trusty.1, that kind of thing
<cjwatson> robru: And there's distro-info for mapping codenames to versions
<robru> cjwatson, BUT WHAT HAPPENS IN 2099?! WHAT THEN?!?! ;-)
<cjwatson> I see no problem with 1.0~ubuntu100.04.1 :-)
<robru> good call
<cjwatson> Versions act sensibly with that kind of thing
<cjwatson> We'll all have made our millions from the 2038 bug by then anyway
<renato> hi guys could you check why jenkins did not build this MR: https://code.launchpad.net/~renatofilho/address-book-app/fix-1306798/+merge/216732
<dbarth> robru: good evening, we have a new silo ready to land (silo 005)
<robru> dbarth, it'll probably have to wait until U opens unless you feel the fixes are important enough for SRU for desktop trusty.
<dbarth> robru: what are the options? severity level expected for an SRU?
<dbarth> robru: you can see the bug reports, we're talking about links not opening in g+ or facebook for example
<dbarth> robru: ie, good to land imo for phone at least, and desktop when updates are considered appropriate
<pmcgowan> dbarth, can we get a blanket SRU for webapps?
<pmcgowan> what ever happened to that
<robru> dbarth, yeah, we do tend to SRU everything for webapps
<robru> dbarth, https://wiki.ubuntu.com/StableReleaseUpdates#When
<dbarth> right, i think that qualifies
<dbarth> pmcgowan: could do yes, since we'll have some more to close the gap with what we had when using the browser as a container
<dbarth> (vs the new oxide)
<pmcgowan> dbarth, right, be worth greasing the landings now
<pmcgowan> based on the bug set target
<robru> dbarth, ok i'll hit publish on that silo, I see 2/3 of those bugs are already in SRU format, will need that third one converted into an SRU
<dbarth> oh sure?
<dbarth> fine
<dbarth> let me search the main sru request we had
<robru> dbarth, this is the one to SRU-ify: https://bugs.launchpad.net/unity-webapps-googleplus/+bug/1308784
<ubot5> Launchpad bug 1308784 in unity-webapps-googleplus (Ubuntu) "External links broken in Google+" [High,Fix committed]
<renato> robru, could you check why jenkis did not build this branch? https://code.launchpad.net/~renatofilho/address-book-app/fix-1306798/+merge/216732
<robru> renato, well, jenkins is down. but that's more of a fginther question.
<dbarth> robru: https://bugs.launchpad.net/unity-webapps-googleplus/+bug/1308784
<ubot5> Launchpad bug 1308784 in unity-webapps-googleplus (Ubuntu) "External links broken in Google+" [High,Fix committed]
<dbarth> robru: the description should be better now
<robru> dbarth, great, thanks
<robru> dbarth, i'll subscribe ubuntu-sru to those bugs and then it's up to them.
<dbarth> thank you
<dbarth> i'll m&c tomormrow morning
* 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: iSCSI server is down affecting s-jenkins and q-jenkins
<balloons> fginther, ping
<fginther> balloons, pong
<balloons> fginther, lol your email answered my question. I was really wanting music to have the real device testing for mp's. The mp I'm proposing requires it
<balloons> music still has the plugin issue, so, got it :-)
<fginther> balloons, how far off is that problem from being solved?
<balloons> fginther, let me see
<sergiusens> fginther: can we add the testing of the clicks pre store landing? as in the ones in the 'click' view?
<sergiusens> just a post build job that installs and runs the tests
<balloons> fginther, sounds like it's rolled up in media-hub, and is *soon*
<fginther> sergiusens, I had started some work on what you are describing, but that got redirected by working on a different method with balloons and others
<fginther> sergiusens, we're trying to basically do autolanding with the click build and test as a part of that
<balloons> right.. so there's no confusion.. the click that was generated by the mp that passed everything can go into the store
<balloons> less work, less surprises I hope
<sergiusens> balloons: it's not part of media hub
<sergiusens> balloons: your music problem is tied to grilo and media scanner
<fginther> sergiusens, is this something that would directly help you, because converting all the projects to this method may be a little ways off. Adding a test job to the current click build jobs may be a short term solution
<balloons> sergiusens, well mediascanner 2.0 is supposed to drop the plugin
<balloons> I guess I'm misspeaking to say mediahub is a requirement then, eh?
<sergiusens> fginther: if you do what I ask, we can atest off the bat that a click app passes it tests and upload directly to the store
<sergiusens> balloons: yeah, media hub was a req for removing qtpowerd, which it already has been
<plars> I just heard that q-jenkins has storage again, and confirmed that the image tests on 303 are now running
<sergiusens> fginther: this would also offload testing autopilot manually from popey and myself
<balloons> sergiusens, I believe what's happening does that already
<balloons> you remove an MP, it generates a click, tests in on the device and you approve. You can then simply grab that click and place it into the store
<balloons> *review an MP, hah
<sergiusens> balloons: what if you need multiple MRs?
<fginther> balloons, I do have some concerns about this working right away. we've already noticed that some apps are not passing when testing on the phone
<sergiusens> balloons: what if we need a new translation pushed? Those don't go through MP/MRs
<fginther> sergiusens, I'll try to do an interim solution to testing of clicks. it's just a bit of work
<balloons> sergiusens, yes it doesn't eliminate building a click from trunk
<sergiusens> fginther: balloons in the following weeks; I'm adding x86/armhf fat click packages; those would also be harder to test from MPs I guess
<balloons> sergiusens, but I don't think we should force testing on the click build.. that's a parm or separate job
<sergiusens> balloons: that's why I said post build step ;-)
<sergiusens> it's different job
<balloons> sergiusens, any hopes of landing this btw? Or did I miss it? https://code.launchpad.net/~sergiusens/phablet-tools/emu_prov/+merge/207440
<fginther> balloons, it would be implemented as two separate jobs, using the existing job to build it and then another job to run the test
<balloons> sergiusens, click-buddy still needs some love for armhf builds I think.. I'm still using my own chroot.. I'm guessing you too
<balloons> fginther, fair enough
<sergiusens> fginther: balloons to summarize one job builds trunk -> if it passes, it runs the tests in a job (passing the click as a parameter)-> if it passes, a possibility of pushing to store (passing the click as a parameter)
<sergiusens> balloons: my chroot is currently broken; I can't build anything
<balloons> sergiusens, you want jenkins to push to the store?
<sergiusens> balloons: yes; to mitigate the one password/key to rule them all problem
<balloons> sergiusens, yes I remember your broken chroot :-)
<balloons> sergiusens, I like that
<balloons> uploading has been streamlined, it's completely possible
<sergiusens> balloons: wrt to click-buddy; I'm going to try and get consensus with zbenjamin during sprint time and just do everything once; we have a google doc rolling with some loose ideas
<balloons> sergiusens, yes I've been working on the file manager click build issues, and one of the issues is click-tools and qtcreator don't agree on the manifest file layout
<balloons> so at the moment I'm not sure of a way to allow building with both to work
<balloons> sergiusens, do you mind sharing the doc with me?
<sergiusens> balloons: yeah, I'll have to find it again though :-)
<balloons> :-)
<josharenson> josepht, I'm trying to get lp:qa-dashboard to run locally, and I'm having some issues. Are you able to help?
<bfiller> robru: can I have a silo for line 28 please?
<robru> bfiller, sure thing, you got 16
<bfiller> robru: cheers
<bfiller> robru: and one for line 29 too please
<robru> bfiller, ok, you got 18 ;-)
<bfiller> thanks
<robru> you're welcome
<josharenson> cjohnston do you happen to _not_ be eod?
#ubuntu-ci-eng 2014-04-23
<cjohnston> josharenson: I am.. any chance we can chat tomorrow?
<josharenson> cjohnston, sure im GMT-8
<cjohnston> josharenson: im east coast. just ping me when you come around
<josharenson> cjohnston: thanks
<Mirv> morning
* 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: iSCSI server is down affecting s-jenkins and q-jenkins
<vila> retoaded: nagios alert on 10.98.191.23 which is not referenced on https://wiki.canonical.com/UbuntuEngineering/CI/Lab (so I have no idea what this host is about), I won't worry about it but may be you will ?
<vila> retoaded: hmm, could  10.98.191.23 be one of the VMs for s-jenkins ? It seems a lot of jobs are pending there and all VMs are offline. That seems related to your latest email about the wraith fallouts for naartjie
<Mirv> I wonder if anyone has opinion on possible downsides of disabling -Bsymbolic on armhf (or actually any non-x86)? bug #1304709
<ubot5> bug 1304709 in qtbase-opensource-src (Ubuntu) "Runtime signal connection errors when using the new signal style" [Undecided,New] https://launchpad.net/bugs/1304709
<Mirv> upstream has made the change in 5.3.0 anyhow
<Mirv> oh, now looking at the bug report it reminds me seeing cjwatson & co discussing it earlier. so I wonder if mandel's bug could be workarounded with the dee-qt's "-pie -fPIE" too.
<Mirv> (the upstream bug report https://bugreports.qt-project.org/browse/QTBUG-36129)
<cjwatson> Disabling -Bsymbolic on armhf has potential significant performance effects for process startup, so I think we should try to avoid it if we can
<cjwatson> Or rather -Wl,-Bsymbolic-functions, I guess you mean
<Mirv> "-Bsymbolic*", the patch bypasses a test that would add them. well in that case I think we'll need a bug to remind us to patch that change _out_ of 5.3.0 when the time comes.
<cjwatson> Perhaps worth verifying my intuition about what effect it actually has
<cjwatson> But Qt seems like exactly the sort of hot spot that -Bsymbolic-functions is best at
<didrocks> sil2100: davmor2: popey: coming?
<sil2100> Yes, logging in
<didrocks> psivaa: you as well?
<psivaa> didrocks: sorry could you give me the link pls?
<didrocks> sure
<didrocks> https://plus.google.com/hangouts/_/canonical.com/landing-meeting
<Mirv> err what happened to my hangout
<psivaa> didrocks: thanks
<Mirv> so I marked the four in queue packages as tobechecked
<sil2100> Aaargh, mail ;/
<sil2100> Curse you mailman!
<sil2100> didrocks: what's the channel with the bot again?
<didrocks> sil2100: #ubuntu-ci-choo-choo
<sil2100> ...;p
<sil2100> :P
<didrocks> Mirv: are you sure the QA team is checking? I think they are not anymore
<didrocks> Mirv: mind double checking if they check? :)
<davmor2> popey: do you have a 5Ghz network?
<Mirv> didrocks: I mean "to be checked" by us, the status of those unapproved items
<popey> davmor2: dunno, how will i tell? â»
<popey> (I think I do)
<sil2100> Mirv: thanks! ;)
<Mirv> so for example I SRUfied now bug #1297297 since it's already in proposed. the other three items in UNAPPROVED would need double-checking from the authors if they are ok with them landing to U instead (ask the packages to be rejected) or if they want them SRUed
<ubot5> bug 1297297 in unity-scope-click (Ubuntu) "Click scope crash during search when going out of WiFi" [Critical,In progress] https://launchpad.net/bugs/1297297
<davmor2> popey: at some point you would of set 2 id's for the network one as popey and one as popey 5g or they clash :D
<popey> i have the same essid for 2.4 and 5
<davmor2> popey: interesting mine clashed when I did that
<popey> further confounded by the fact that I have two access points
<popey> both with the same ESSID, so effectively four networks
<popey> tempted to change them to popey_2.4 and popey_5g so it's easier to spot
<Mirv> dbarth: your webbrowser-app landing had the bugs already SRUfied, thanks! I just nominated the bugs for trusty as well.
<didrocks> Mirv: ah ok ;)
<davmor2> popey: can you try and connect strictly to the 5g one and see if osm gives you a location
<sil2100> Mirv: let's divide work then
<Mirv> sil2100: yeah could you then maybe check the bfiller's and boiko's landings?
<sil2100> Mirv: I take bfiller's one
<sil2100> Ok
<popey> davmor2: ok, will take a while, lemme change network names now â»
<sil2100> Mirv, didrocks: so the landings from bfiller and boiko have either no bugs assigned or not SRUed at all - I'll poke the authors and/or landers if they want to proceed with SRUifying them or rejecting and waiting for U
<didrocks> sil2100: thanks!
<Mirv> sil2100: thanks!
<dbarth> Mirv: thank you
<dbarth> yes, we did our homework to go into -updates
<popey> davmor2: http://popey.com/~alan/phablet/device-2014-04-23-100233.png
<popey> â¨
<popey> its confused, rebotting
<mandel> cjwatson,  Mirv I did use -pie and fPIE to fix the issue and it worked like a charm
<mandel> didrocks, is there a way I can take the training to help with the ci train in my team, that way we have sergio in the American time zone and me in CET
<didrocks> mandel: yeah, we extended the list on demand. But we don't offer anymore training for now. You should coordinate with some other landers to get some hint (it's pretty easy). When you are ready, I can then just add you to the team
<mandel> didrocks, awesome, I'll speak with sergio then :)
<didrocks> great ;)
<didrocks> keep me posted!
<didrocks> Saviq: seb128: so, the bot CI Train is now in beta ;) you can join #ubuntu-ci-choo-choo if you are interested
<didrocks> you can inspect status, and get notification when it makes sense to you
<davmor2> popey: sadtrombone.com
<Chipaca> can somebody here give me a hand with three bugs I'm wanting to shepherd through SRU?
<Chipaca> I'm at âAsk the Ubuntu bug control team to nominate the bug for the appropriate Ubuntu release(s)/series (e. g. the current LTS and latest stable release).â
<Chipaca> I'm on that team, but am unsure how to nominate a bug :)
<Chipaca> bugs are: https://bugs.launchpad.net/ubuntu-push/+bug/1297969 https://bugs.launchpad.net/ubuntu-push/+bug/1309237 https://bugs.launchpad.net/ubuntu-push/+bug/1309231
<ubot5> Launchpad bug 1297969 in ubuntu-push (Ubuntu) "Check cert" [High,In progress]
<ubot5> Launchpad bug 1309237 in ubuntu-push (Ubuntu) "Work around whoopsie returning null string during session start" [Critical,In progress]
<ubot5> Launchpad bug 1309231 in ubuntu-push (Ubuntu) "Client should exp backoff reconnect even when connect was successful" [High,In progress]
<NoNameYet_xnox> Chipaca: done
<cjwatson> You need to access it through the /ubuntu/+source/ubuntu-push/ hierarchy rather than /ubuntu-push/
<cjwatson> Then you get a "Nominate for series" or "Target to series" link, depending on your privilege level
<Chipaca> i get "target"
<Chipaca> to milestone
<Chipaca> og!
<cjwatson> Not that
<Chipaca> oh! nominate to series
<Chipaca> for*
<cjwatson> Right
<Chipaca> ok :)
<Chipaca> hadn't seen that before :D
<Chipaca> s/seen/noticed/
<Chipaca> anyway. Thank you, NoNameYet_xnox
<cjwatson> But you have to be going through the distribution URL namespace
<Chipaca> cjohnston: right. Ta.
<Chipaca> and now... i ask to have it landed?
<Chipaca> given that next step is "put it into proposed"
<NoNameYet_xnox> Chipaca: yeap. all three look good to go into -proposed unapproved queue.
<Chipaca> now, i've got a row with all of them fixed all together
<NoNameYet_xnox> Chipaca: also subscribe "~ubuntu-sru" to all three.
<Chipaca> do i need to do three separate rows/builds/etc?
<NoNameYet_xnox> Chipaca: it can go as a single build. it's just it will only be promoted to -updates once all three bugs pass verification.
<Chipaca> sweet
<Chipaca> sil2100, Mirv, didrocks, could i have a landing (into ... "proposed unapproved"? if that's a thing from your pov) of row 24?
<Chipaca> NoNameYet_xnox: this is in universe; is it still ubuntu-sru?
<NoNameYet_xnox> Chipaca: yes.
<NoNameYet_xnox> Chipaca: all processes are the same for the whole archive.
<sil2100> Chipaca: we can try pushing it as an SRU if you want
<Chipaca> sil2100: that's what I'm aiming for, yes
<Chipaca> sil2100: hence the paperwork on the bugs
<sil2100> Chipaca: ok, so I see still 2 bugs requiring description SRUification ;)
<Chipaca> sil2100: which ones are they?
 * Chipaca looks
<sil2100> Chipaca: it's https://bugs.launchpad.net/ubuntu-push/+bug/1309432 and https://bugs.launchpad.net/ubuntu/+source/ubuntu-push/+bug/1308145 it seems
<ubot5> Launchpad bug 1309432 in ubuntu-push (Ubuntu) "Ubuntu Push client should ensure it only runs once per session." [High,In progress]
<ubot5> Launchpad bug 1308145 in ubuntu-push (Ubuntu) "Supurious numbers in brackets in notifications" [Undecided,In progress]
<Chipaca> yep
<Chipaca> forgot about those less-than-zomg-urgent ones :)
<Chipaca> on it
<sil2100> Thanks :) !
<sil2100> Chipaca: I already nominated the bugs and subscribed sru team
<Chipaca> sil2100: ta
<sil2100> Chipaca: there's one change in the changelog that doesn't mention a bug number... could you elaborate a bit about that change? Since I need to assess if it can be pushed alongside an SRU
<sil2100> Chipaca: I mean the change for: "gave the client the ability to get config from commandline (...)"
<sil2100> From Samuele
<Chipaca> sil2100: I was a bit lazy, there
<Chipaca> the merge was easier that way
<Chipaca> sil2100: where should i elaborate?
<Chipaca> (there are better reasons than just my laziness)
<sil2100> Ah, hm, since we normally only SRU fixes or small modifications - I see the commit is a bit biggish - is it something that's required by the other fixes?
<sil2100> I'm simply worried that the SRU team might find this inappropriate or somethin
<sil2100> g
<Chipaca> sil2100: you know how in all the SRUs i'm having to edit the config file? that change makes it possible to just add a commandline flag instead
<Chipaca> sil2100: testing (especially telling other people to test) becomes a lot easier
<Chipaca> that was my rationale for it, anyway
<Chipaca> sil2100: when you say the commit is big, you mean for that change, or overall?
<sil2100> Chipaca: what's the regression potential of that change?
<sil2100> Chipaca: I meant that one change - it's big in the sense of 'big as for something that's not related to a bug being fixed for the SRU'
<sil2100> ;)
<Chipaca> sil2100: if somebody has a corrupt upstart thing that happens to be working now, this would break it
<Chipaca> or otherwise has rubbish after the push-client command
<Chipaca> that's now looked at and complained about
<Chipaca> I could roll it out of the patchset if it's a problem
<sil2100> Chipaca: let's consult it with someone from the SRU team
<Chipaca> having to explain it underlined how weak a reasoning it was, really :)
<sil2100> cjwatson: hi Colin, do you have a moment to help us evaluate an SRU situation?
<Chipaca> (i still think it's nice to have and low risk, si yes)
<Chipaca> so*
<sil2100> Chipaca: yeah, I also would prefer not to remove it unneccesarily
<Chipaca> anyway, back to editing bug descriptions
<cjwatson> I don't have a problem with the above if it makes it easier to test SRUs
<sil2100> o/
<sil2100> cjwatson: thanks :)
<cjwatson> But expect to have to roll it back if the regression potential turns out to be actual
<sil2100> cjwatson: should we create a 'bug' for that one and indicate the bug number in the changelog, or can we simply leave the changelog entry alone?
<sil2100> (with no bug assigned for that 'testing enhancer')
<Chipaca> the diff itself is https://code.launchpad.net/~pedronis/ubuntu-push/client-takes-cmd-line-flags-as-well/+merge/215617 and its prerequisite, if that's any use in the conversation
<cjwatson> It would be helpful to have a bug just in case we discover that it regresses independently from the rest
<sil2100> cjwatson: ok, thanks o/
<Chipaca> cjwatson: ta. Will file.
<sil2100> Chipaca: so, could you create a bug for that commit, mention the regression potential there (according to the SRU guidelines) and attach it to the changelog?
<sil2100> Chipaca: I could create the bug for you, but I guess you know best what exactly that commit does
<Chipaca> yep
<sil2100> Thank you :)!
<Chipaca> updated description for https://bugs.launchpad.net/ubuntu-push/+bug/1309432
<ubot5> Launchpad bug 1309432 in ubuntu-push (Ubuntu) "Ubuntu Push client should ensure it only runs once per session." [High,In progress]
<Chipaca> and updated the description for https://bugs.launchpad.net/ubuntu/+source/ubuntu-push/+bug/1308145
<ubot5> Launchpad bug 1308145 in ubuntu-push (Ubuntu) "Supurious numbers in brackets in notifications" [Undecided,In progress]
<Chipaca> (that was a lot of typing)
<Chipaca> (I'm leaving "supurious" because it's my favorite neologism)
* vila 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: none
<sil2100> ;)
<sil2100> Chipaca: looking awesome - now just that new bug for that enhancement and we're good to do some publishin'
<Chipaca> https://bugs.launchpad.net/ubuntu/+source/ubuntu-push/+bug/1311600
<Chipaca> sil2100: ^
<ubot5> Launchpad bug 1311600 in ubuntu-push (Ubuntu) "Ubuntu Push client takes no commandline arguments" [Undecided,New]
<sil2100> Chipaca: fast! Thanks, nominating
<sil2100> Chipaca: can you append (LP: #1311600) to the changelog of that branch? We'll have to re-build though, but it will be fast as no re-testing will be required
<ubot5> Launchpad bug 1311600 in ubuntu-push (Ubuntu) "Ubuntu Push client takes no commandline arguments" [Undecided,New] https://launchpad.net/bugs/1311600
<Chipaca> sure, give me a bit
<Chipaca> sil2100: build failed, looking for the "ignore" button :)
<Chipaca> sil2100: hmm. It doesn't like me.
<didrocks> Chipaca: yeah, this is to prevent you shooting on your feet
<didrocks> (once you get a successfull build, you don't want to rebuild most of the time and people misclicked)
 * Chipaca likes his feet
<didrocks> Chipaca: the error message doesn't help you? :)
<sil2100> Chipaca: just run the build job with ubuntu-push as the packages to rebuild ;)
<sil2100> No other flags should be needed
<Chipaca> mucho bettero!
<Chipaca> didrocks: the error message told me to run it again with "ignore"
<didrocks> Chipaca: yeah, and you rerun with "force rebuild"
<Chipaca> https://ci-train.ubuntu.com/job/landing-008-1-build/49/console
<didrocks> not "ignore step"
<Chipaca> this is true
<didrocks> Chipaca: I'm happy to take any better/more clear wording
<Chipaca> in my defense, i did that because i read the descriptions on those options, and the ignore sounds like it ignore things if the force doesn't work
<Chipaca> oh!
<Chipaca> oooh
<Chipaca> didrocks: s/ignore if/ignore whether/ and i would've probably understood
<didrocks> Chipaca: changing! thanks :)
<Chipaca> didrocks: and has, not hasn't, with whether
<Chipaca> negaitve logic breaks my brain a bit i'm afraid
<didrocks> :)
<Chipaca> sil2100: packages built
<sil2100> Chipaca: \o/ Lookint at that, thanks!
<sil2100> Oh noes!
<sil2100> :<
<Chipaca> sil2100: what?
<sil2100> Chipaca: bad news, we'll have to rebuild again :< The changelog mentions (LP: #216466) as the bug number, which is some other bug (not the one you filled in)
<ubot5> Launchpad bug 216466 in filezilla (Ubuntu) "Update to latest upstream version" [Wishlist,Fix released] https://launchpad.net/bugs/216466
<sil2100> Chipaca: it should be (LP: #1311600)
<ubot5> Launchpad bug 1311600 in ubuntu-push (Ubuntu) "Ubuntu Push client takes no commandline arguments" [Undecided,New] https://launchpad.net/bugs/1311600
<Chipaca> what
<Chipaca> where did that come from :-(
<sil2100> Chipaca: https://launchpad.net/~ci-train-ppa-service/+archive/landing-008/+sourcepub/4100678/+listing-archive-extra <- :<
<Chipaca> i can't even copy and paste
<sil2100> Happens to everyone, no worries ;p
<Chipaca> i'll go get a mug of coffee and shame, and do it over
<Mirv> a random copy paste mangler easter egg would be fun
<ogra_> that would require working copy paste, no ?
<sil2100> ;p
<sil2100> Chipaca: I'm only sad because now you'll have to wait for it to build again!
<sil2100> I would always prefer that our landers have a swift landing with good memories of it ;p
<Mirv> so there's some motivation for implementing a working copy paste.. with a twist
<sil2100> Mirv: please, don't! Or someone will actually implement what you wish for!
<sil2100> ;p
<Chipaca> ogra_: not if "mangle" means "paste some bytes from /dev/urandom"
<ogra_> heh
<Chipaca> ogra_: trying to decide whether "shuf -n1 /usr/share/dict/words" or "fortune -os -n 15" would be better paste replacement
<ogra_> thats lame, you should pull random words online and call it "cloud integrated pasting"  ;)
<sil2100> Chipaca: I see it's basically built, I should be able to publish soon :) Looks good so far
* cprov 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: none
<Chipaca> sil2100: \o/
<sil2100> Chipaca: published! Let's now make sure the it doesn't get missed by the SRU team :)
<Chipaca> sil2100: how do I do that?
 * Chipaca opens up international-pizza-delivery.com
<sil2100> Chipaca: we'll be poking around, now worries
 * Chipaca closes it again, that stuff is expensive
<sil2100> Nagging people in your stead ;p
 * Chipaca hugs sil2100 
<Chipaca> thanks :)
<sil2100> Chipaca: yw! Thanks for doing the paperwork :)
<Chipaca> i won't lie, i hate the paperwork
<Chipaca> at the same time i understand why it's there, so... :-\
<popey> davmor2: I can't actually get on 5Ghz here! I have deleted all network manager system-connections and rebooted, and it just keeps asking for the password
<davmor2> popey: oh dear
<davmor2> popey: works fine here
<popey> davmor2: i have connected to a 5G connection at someone else's house with it
<popey> but can't get on mine
<popey> no idea why
<ogra_> popey, tried different channels ?
<ogra_> (on the AP side)
<popey> ogra_: will fiddle
<davmor2> popey: 	Auto (Current channel 36) seems to work fine for me I don't know if that helps any at all
<popey> ta
<popey> mine is on 36 too
<popey> "N Only (5Ghz)"
<ogra_> well,  its also a matter of overlapping them with different APs
<ogra_> especially if you have different speeds there
 * popey switches to "mixed"
<popey> popey.mooo.com/screenshots/device-2014-04-23-141802.png
<popey> wtf
<popey> tried connecting to 5ghz, it failed and dropped back to 2.4
<popey> now shows a button next to both
<ogra_> lol
<ogra_> whats that last one
<ogra_> unfriendly neighbors
<davmor2> popey: yeah and you think I live in a rough neighbourhood don't get none of that here I'll have you know. (Too thick to change the defaults normally, but shhhhh)
 * Saviq wants U :|
<josepht> Unholy Uguisu
<sil2100> bfiller, boiko: hi guys! I'd like to ask some questions regarding your landings
<davmor2> josepht: you mean it not unkind unicorn
<boiko> sil2100: sure
<sil2100> bfiller, boiko: so, first of all a question regarding the two ones that are published and blocked in UNAPPROVED - they either have no bugs assigned or those bugs are not SRU-ready
<sil2100> bfiller, boiko: so the question is:
<josepht> davmor2: Uni-horned Unicorn? :)
<boiko> sil2100: yeah, well, last week I asked if I should do anything regarding the packaging being unapproved, and I was told to just wait, so that's what I have been doing :D
<sil2100> bfiller, boiko: should we try doing the paperwork and pushing those as SRU, or you prefer we reject those and re-publish once U is open?
<bfiller> sil2100: how do I make them SRU ready?
<bfiller> sil2100: and how long until U is open do we think?
<mhr3> sil2100, is there anything more i have to do for line #20?
<sil2100> bfiller: each merge/fix should have a LP bug assigned, and that bug should be a bug-fix and be formatted according to the SRU needs (i.e. https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template )
<bfiller> sil2100: ok thanks. let me take a look and see if we want to do an sru or not
<sil2100> mhr3: no, I guess that landing is safe, it needs to serve its time in -proposed now
<sil2100> bfiller: ok! Thanks :) Since the SRU process can take a while itself, so it's usually evaluating and 'guessing' which makes more sense
<mhr3> sil2100, very well, thx
<davmor2> bfiller: ah just the chap.  You said in a 14.04 update that MMS was supported.  I have an MMS request from my Mom this morning that points to the providers web site to view I had assumed this would go away with the MMS support is that not the case?
<bfiller> davmor2: it's not supported yet, it's in the work in progress category
<davmor2> bfiller: damn I must of mis-read thanks
<bfiller> sil2100: what's the quickest way to get the fixes into the image? that's what I'm most interested in really
<bfiller> davmor2: it's coming soon though
<ogra_> before or after mark announced U ?
<ogra_> :P
<ogra_> bfiller, the normal SRU process applies
<ogra_> (for getting fixes into the image)
<ogra_> oh, that remonds me ...
<ogra_> *reminds
 * ogra_ promotes 303 to devel
<bfiller> ogra_: so we're still spinning trusty images then/
<bfiller> ?
<ogra_> if they are worth it
<bfiller> what's the time estimate for U images?
<ogra_> ask mark
<ogra_> as lojng as we dont have a name we cant even open the archive
<sil2100> Yeah...
<sil2100> bfiller: well, it's hard to say  what's the fastest way
<ogra_> once the name is there opening the archive (to a usable state) takes a day or two ... then the build tools need adjustment for the new name, then we can start first test images
<ogra_> there is a wikipage somewhere
<bfiller> so guessing we're at least a week a way
<ogra_> https://wiki.ubuntu.com/NewReleaseCycleProcess
<ogra_> thats the one i think
<ogra_> (note it expects that the name exists 1month before the release)
<sil2100> bfiller, boiko: just give me a ping once you decide what you want to do with your landings :)
<mandel> sil2100, didrocks small question, when will I be allows to start landing again for udm? do I have to wait until he u name?
<ogra_> mandel, where do you want to land ?
<mandel> ogra_, touch
<ogra_> lol
<mandel> ogra_, whatever that is :)
<ogra_> so udm doesnt go into server ? :P
<mandel> ogra_, or the moon ;)
<ogra_> mandel, if you spaniards dont know what to target, how do you expect to win the game tonight ?
<mandel> ogra_, and get blamed for heartbleed, no :P
<ogra_> mandel,  do mean landing for U ?
<ogra_> or for a trusty SRU
<mandel> ogra_, U would be easier than a SRU and is just for mms support and browser integration, things we do not have in trusty
<ogra_> SRUs can land ...
<mandel> ogra_, there is a game going on tonight? /me checks
<ogra_> U cant land before an archive exists
<ogra_> mandel, ral vs bayern ?
<ogra_> *real
<mandel> ogra_, oh, that.. I should watch that
<mandel> ogra_, I'm more of a rugby man :)
 * ogra_ surely will :) 
<ogra_> ah
<mandel> ogra_, I will just to cheer for the spaniards, you are not allowed to have a better economy && good football, that is the reason we wond the worldcup
<ogra_> haha
<ogra_> brazil will show i guess :)
<bregma> hey sil2100 I see you looking at my line 31: all the bugs are now prepared for SRU, it's ready for a silo assignment when everything is ready on your end
<sil2100> bregma: hey! Yes, I saw that, was browsing the bugs like 15 minutes ago
<sil2100> I nominated some already
<bregma> I just finished editing the last one
<sil2100> Awesome!
<sil2100> Let me just browse through them quickly and assign a silo
<sil2100> We're a bit low on those, but hey, it's not like we're landing anything besides those
<sil2100> bregma: silo 14 for you :)
<ogra_> didrocks, btw, did you notice that you get the image update together with the update of the three click packages that were added in 303 ...
<ogra_> kind of redundant :P
<didrocks> ogra_: yeah, it's not the most optimized UI :)
<ogra_> lol, you blame the UI ?
<ogra_> (just pointing out it is pointless to re-roll images only for click updates ... since you will always get it twice then)
<ogra_> oh, just for teh record ... 303 promoted btw
* 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: alderamin down
<bfiller> sil2100: line 21 sync-monitor: I filed SRU bug here https://bugs.launchpad.net/ubuntu/+source/sync-monitor/+bug/1311719
<ubot5> Launchpad bug 1311719 in sync-monitor (Ubuntu) "changes to contacts in address-book-app are not getting auto synced" [High,Fix committed]
<bfiller> sil2100: would like to get that promoted.
<bfiller> sil2100: line 18 can be rejected and pushed to U
<sil2100> bfiller: hmmm, ok, I need to consult about the sync-monitor thing, because right now the package that's in UNAPPROVED doesn't have any link to the bug being fixed
<sil2100> So it will be hard for the SRU team to track this bug
<bfiller> sil2100: I can resubmit if it's easier to reject that one and do it again
<sil2100> cjwatson: hi! Sorry to bother again, but what do you think? We have a package in UNAPPROVED that's not linked to any bug - the bug is now prepared, but we're not sure if we should reject this upload and try re-publishing with the bug linked in?
<popey> didrocks: I'll miss landing call this evening, have a meeting clash
<didrocks> popey: ok, no worry!
 * ogra_ guesses there wont be much do discuss anyway ... still 
<mhr3> sil2100, silo for 33 pls?
<didrocks> mhr3: no need to ping us, we are getting pings
<sil2100> mhr3: sadly, no silos...
<sil2100> I mean, we have like 1
<didrocks> on :#ubuntu-ci-choo-choo :)
<mhr3> didrocks, woooo, as in there's a bot? :)
<didrocks> mhr3: you can join there!
<sil2100> Because of no-U and SRU it's like, geh
<didrocks> :)
<ogra_> sil2100, i'd call it relaxing
<sil2100> Ok, I jump out to the doctor, bbl
<ogra_> finally time to do all that overdue paperwork etc :)
<ogra_> ... and cleaning the office ...
<bfiller> fginther: are the CI jobs supposed to already be producing a click for gallery-app? don't see it anywhere in artifacts
<fginther> bfiller, unfortunately, you'll need drill down through a couple of jobs to find it. From gallery-app-ci, you can go to the generic-click-autopilot-trusty-touch job, then the generic-click-builder-trusty-armhf job which will have the click package
<bfiller> fginther: ok, thanks. Any plans to surface this in the Launchpad MR page?
<fginther> bfiller, I had not thought about that... I'll look into it
<bfiller> fginther: cool, possible could just add it to the artifacts zip file that is already created
<didrocks> cyphermox: robru: coming?
<bfiller> fginther: so I'm here but can't figure out how to drill further: https://jenkins.qa.ubuntu.com/job/generic-click-autopilot-trusty-touch/
<fginther> bfiller, the console logs will contain the links to the specific build for each job
<fginther> so if you start with https://jenkins.qa.ubuntu.com/job/gallery-app-ci/812/console, you'll see "generic-click-autopilot-trusty-touch #86"
<fginther> and then the console log for that will point to "generic-click-builder-trusty-armhf #98"
<sil2100> Back
<ogra_> Front
<rsalveti> utopic unicorn!
<ogra_> !!
<sil2100> OH!
<sil2100> YESSSS \o/
<sil2100> The unicorn is ouuunnn!
<fginther> sil2100, so now that we're opening a new release, do you know how the 14.04 project branches will be handled? Is this going to be through lp:cupstream2distro-config or is the ci-train going to handle this also?
<sil2100> fginther: I would suppose ci-train will handle this as well, but I guess that's a valid question to poke Didier tomorrow morning
<sil2100> fginther: I'll try to poke about that in the EU meeting and just inform you once you appear
<fginther> sil2100, thanks. for the foreseeable future, we'll still need to maintain the config files in lp:cupstream2distro-config for the -ci jobs, but it would help to know if the former daily-release process will pick anything up
* 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: alderamin down
<robru> fginther, my understanding is that daily_release is only used for saucy SRUs. there shouldn't be any current branches still using it.
<fginther> robru, and trusty SRUs will be handled by the ci-train?
<robru> fginther, I assume so.
<fginther> robru, that's my assumption as well
<robru> fginther, didrocks would have the final say on that, but I can't image we'd want to transition trusty SRUs to the old daily_release stuff.
 * robru is secretly hoping that daily_release gets shut off and deleted when saucy EOL's ;-)
<fginther> robru, agreed, I'll be sure to poke him tomorrow if sil2100 doesn't get to him first
<josharenson> josepht, is this a good time for you?
<josepht> josharenson: sure
<josharenson> josepht, so I'm writing a performance test suite (well, currently only 1 test), that I would like to integrate into the existing QA dashboard. I have the code from lp:helipad, but was wondering if you could provide some tips on setting up a local instance as I'm running in to a lot of issues.
<cjohnston> josharenson: first, don't use lp:helipad
<josharenson> cjohnston, ... ok I also have lp:qa-dashboard
<josepht> josharenson: what sort of issues are you having setting it up?
<cjohnston> josharenson: it's meant to be deployed on precise
<josharenson> cjohnston, josepht, I have installed old versions of django and postgres and I can kind of get the server running but obviously there are many errors when trying to interact with the db... how do you recommend I proceed? Is there some sandbox environment available?
<cjohnston> josharenson: deploy a precise instance in canonistack and I'll help you setup
<josharenson> ... where do I do that?
<cjohnston> josharenson: you could also use lxc if you like and that's easier for you
<cjwatson> bfiller: yes, please do resubmit that sync-monitor change - we can't do any kind of SRU validation tracking without a bug number
<cjwatson> bfiller: I've rejected the existing upload
<bfiller> cjwatson: will do
<cjwatson> thanks
* 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: alderamin down
#ubuntu-ci-eng 2014-04-24
<Saviq> soo if I want something landed in utopic, do I need to rebuild/retest?
<sil2100> I... I'm not sure yet ;p But you need to rebuild for sure, not sure if the infra is switched already
<didrocks> sil2100: maybe try to dput something just for test in a silo for utopic?
<didrocks> and see if it builds
<didrocks> but on the infra you need to free the silo
<didrocks> and reassign
<didrocks> settings series to utopic
<mardy> asac: hi! Did you hold that famous meeting yet? :-)
<sil2100> didrocks: ok, let me test it myself then ;)
<sil2100> didrocks: yeah, all seems to work ok in this regard - should we poke upstreams to fork their trunks to trusty branches?
<sil2100> didrocks: or should we wait for the SRU-ones to land in trunks first?
<didrocks> sil2100: for stuff that are in SRU mode, let's have them proceeded into -updates first I would say
<didrocks> sil2100: otherwise, trunk == utopic for now I would say
<didrocks> sil2100: want me to change the spreadsheet to use utopic by default?
<Mirv> I think utopic by default would make sense, SRU:s are a separate thing
<sil2100> didrocks: yes, I think that makes sense
<didrocks> ok, changing, one sec
<sil2100> And yeah, the good thing about CITrain is also that actually dividing where 'trusty' commits ended and where 'utopic' started is easily doable
<sil2100> ;)
<didrocks> done
<didrocks> if you need a SRU, ensure that you change the series to "trusty"
<didrocks> when assigning a silo
<didrocks> remember that the block is per release/component
<didrocks> (not only by component)
<didrocks> so, we have a way to exit if upstream which are blocked in a SRU wants to land something else :)
* psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | 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: alderamin down
<Saviq> sil2100, didrocks, so I should rebuild the silo to land in U? or do you need to reconfigure first?
<sil2100> didrocks: indeed :) But what about merge targets? Since if someone that's blocked on an SRU landing wants something else landed in U, it's troublesome as the both the SRU and the U landing would target the same trunk branch
<didrocks> Saviq: we will remove and reassign a silo for you
<sil2100> Saviq: I'll reconfigure your silo and will ask for a rebuild
<Saviq> sil2100, thanks
<didrocks> sil2100: you have to remove and reassign, I protect, on purpose on series change IIRC
<didrocks> hum, maybe not with the prepare job
<didrocks> sil2100: you can try the prepare job, (but not in reconfiguration mode)
<didrocks> let me knows if this work
<Saviq> didrocks, no worky https://ci-train.ubuntu.com/job/landing-007-1-build/26/console
<Saviq> didrocks, and CI-SNCF didn't ping me about the failed job, that expected?
<sil2100> huh
<sil2100> What the heck is that
<Saviq> something doesn't know about utopic
<didrocks> Saviq: fixed, please retry
<didrocks> let me see why the bot didn't ping, maybe it's just the double rsync latency
<didrocks> Saviq: ah no, it's just that the status isn't updated, all issues with jenkins
<Saviq> didrocks, kk
<didrocks> Saviq: like, if there is a crash, I'll need to hook something up telling "infra issue"
<didrocks> Saviq: anyone, just retry now :)
<didrocks> anyway*
<Saviq> already done
<Saviq> didrocks, https://ci-train.ubuntu.com/job/landing-007-1-build/27/console
<didrocks> ah, we need the debootstrap
<didrocks> hum
<didrocks> we don't have a job for that though and don't have ssh access to the machine
<didrocks> sil2100: interested in doing that? let's chat during the meeting
<didrocks> Saviq: mind waiting a little bit so that we can do it properly?
<Saviq> didrocks, sure, let me know when you need a guinea pig
<didrocks> yeah ;)
<sil2100> Let's chat on the meeting :)
<sil2100> Saviq: so, I think you'll still have to wait a bit :)
<dbarth> Mirv: ping? hi, this is about line 37
<dbarth> wondering how to land that
<Mirv> dbarth: you could land it to utopic series now that it's open. maybe check with bzoltan1 on how trusty SDK updates are supposed to be done - SRU:s or PPA
<bzoltan1> Mirv:  PPA
<Mirv> dbarth: ok, so then just to a normal landing as soon as normal landings are possible to utopic, and a trusty version can be done via https://launchpad.net/~ubuntu-sdk-team/+archive/ppa
<dbarth> Mirv: ok
<dbarth> Mirv: are there silos available right now?
<bzoltan1> Mirv:  how to proceed with the Silo9 now? It is tested and good to go
<Mirv> dbarth: silos are really full right now, so for utopic update I'd wait a little bit until we know we can release something there
<Mirv> bzoltan1: it states it requires a QA sign off, and then the bugs would need to be SRUfied. but if you're targeting utopic, it needs reconfiguration against utopic series and a rebuild.
<Mirv> since as seen at https://launchpad.net/~ci-train-ppa-service/+archive/landing-009/+packages the package is built for trusty (since utopic wasn't open back then)
<bzoltan1> Mirv:  absolutely targeting U
<bzoltan1> Mirv:  for obvious reasons I will not test again the reconfigured/rebuilt packages
<Mirv> bzoltan1: alright. so, I just added a note for now since we've not yet landed anything to utopic, but at least utopic is out there now.
<bzoltan1> Mirv:  OK... i just would like to back on the normal track as quick as possible
<Mirv> prepare-silo told me that it's preferred to free the silo and reassign it when changing series, and aborted, so that's why only a note so that maybe all similar cases can be handled at the same time
<bzoltan1> Mirv:  I reconfigured and started the build again... we can start the whole hustle from scratch if you wish so
<Mirv> bzoltan1: it rebuilds against trusty still there, so it's not better. let's restart when we have everything needed for utopic landings.
<bzoltan1> Mirv:  so you can not assign a U Silo to the landings?
<sil2100> Saviq: I re-ran the build in your silo, it *should* work now, let's see how it works
<Saviq> sil2100, thanks!
<Mirv> bzoltan1: I can, but I'd rather see one complete utopic landing done first. so, slightly later.
<bzoltan1> Mirv: :) we could be that one utopic landing :)
<Mirv> bzoltan1: yep, let's see. I'll handle the reconfiguring anyhow in a bit.
<bzoltan1> Mirv:  super, please ping me when I should start to be excited :)
<didrocks> sil2100: Mirv: Saviq: bzoltan1: for the record, we won't publish them though. We'll need a rebuild once the toolchain is updated
<didrocks> so, it's only exploratory :)
<Saviq> :|
<Saviq> do we know ETA?
<sil2100> :|
<didrocks> Saviq: something you should ask on #ubuntu-release. Seems like EOW from what I read
<sil2100> |:
<ogra_> i wouldnt count on EOW ... rather monday/tuesday
<Mirv> didrocks: right. I expected there are toolchain changes upcoming still, but good to know for sure.
<Mirv> only binutils updated so far in practice
<Mirv> and some boost libs
<ogra_> yep
<ogra_> and skype
<ogra_> :)
<xnox> Mirv: there ain't much toolchain changes this time around. we are not going with 4.9 =(
<xnox> so that's actually it - ruby, boost, binutils.
<Mirv> xnox: oh, no gcc 4.9? it's already two days old! :)
<Mirv> ok so after binutils has migrated to release pocket maybe then it's good
<Mirv> ogra_: I did make a note of the same thing you mentioned on #release :)
<ogra_> skype you mean ?
<ogra_> yeah, its awfuk to have it as the very first upload of a new series
<ogra_> *awful
<Mirv> yeah, being the first :)
<ogra_> but i guess adam had a reason
<ogra_> (traditionally we opened with a vim upload in teh past)
<xnox> ogra_: it wasn't an upload, but a copy.
<ogra_> xnox, yet it is the first package to show up on changes :)
<cjwatson> Probably a quirk of list moderation actually
<cjwatson> Oh, no, it has an earlier Date.  Whatever
<cjwatson> But yeah, I think Adam was just walking down the checklist and initialising partner (with a copy, as xnox says)
 * didrocks goes for a run
<sil2100> brb
<sil2100> Ok, I'm going for some lunch and to the pharmacy
* 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: alderamin down
<Mirv> bzoltan: landing-009 is now totally utopic (and already built), but as discussed above we'll need an ack that the toolchain is DONE and then one more rebuild.
<bzoltan> Mirv: Ultracoool
<fginther> didrocks, will the 14.04 maintenance branches be handled by ci-train or daily-release or something else?
<didrocks> fginther: all riding the train!
<sil2100> ;)
<fginther> didrocks, thanks. I'll be updating the lp:cupstream2distro-config stack files to transition to utopic and adding the 14.04 branches. I assume that this has no impact on the ci-train, right?
<didrocks> fginther: no, the branch is now all yours! :)
<fginther> \o/
<fginther> :)
<bfiller> sil2100: line 25 can be published and bug is setup for SRU. We'd like to get this one into SRU
<sil2100> bfiller: looking o/
<sil2100> Choo chooo
<didrocks> ;)
<alecu> the trainbot sounds great!
<alecu> didrocks: would it make sense to include the traincon level in the topic?
<didrocks> alecu: hum, nice idea, mind opening a feature request against cupstream2distro so that I don't forget about it?
<alecu> sure
<didrocks> thanks!
 * ogra_ would really love if we could redefine "traincon" to something you dont have to look up all the time
<ogra_> i.e. self explaining
<alecu> https://bugs.launchpad.net/cupstream2distro-config/+bug/1312211
<ubot5> Launchpad bug 1312211 in cupstream2distro Configuration "Traincon level is not shown on #ci-choo-choo topic" [Undecided,New]
<didrocks> alecu: thanks! assigning it to me
<sil2100> ogra_: what do you mean? Traincon is self-explanatory...
<sil2100> Everyone knows it's a synonim for phonecon
<ogra_> sil2100, i would it like to have something like TRAINCON-GOOD instead of TAINCON-0 ... so you dont need to look up the number scheme of what means what
<ogra_> (which i can never recall)
<ogra_> or -RED vs -GREEN
<alecu> ogra_: that's not very descriptive for colorblind people! ;-)
<ogra_> lol
<ogra_> especially males with red/green weakness ... right :)
<didrocks> sil2100: I hope you liked the photo btw!
<sil2100> didrocks: yes! It was awesome ;)
<didrocks> sil2100: it's the train I'm competing against every day :)
<sil2100> didrocks: uh, I hope it's faster than it looks ;p
<didrocks> (there is an island in the park I'm running, and on this island, there is this train ;))
<didrocks> it's not
<didrocks> I can surely do 2 loops when it's doing one :p
<sil2100> Oh my god, didrocks is fast like Flash! He can overrun a TRAIN
<sil2100> :O
<didrocks> \o/
<didrocks> then, don't show the photo in that case :p
<ogra_> flash gordon ?
<ogra_> then i want a photo of him in the right outfit please :)
<ogra_> (red tights and all) :)
<didrocks> ogra_: sure sure, remember as well that I'm borrowing my shampoo now for the bike ride back in case it's raining :p
<ogra_> didrocks, you should run ubuntu kylin ... then you can stop at the kylin software store and wont get wet http://people.canonical.com/~xnox/kylin-store.png
<didrocks> ahah :)
<alecu> ogra_: is that image real? !!!
<ogra_> alecu, apparently
 * alecu downloads the iso
<fginther> didrocks, does ci-train maintain a list of project branches that is allowed to merge to?
<didrocks> fginther: no, we are not preventing anything on purpose
<fginther> doanac, hmm... so you could release something to the archive based on lp:unity8 in one ticket and something based on lp:unity8/utopic in the next?
<fginther> s/ticket/landing/
<sil2100> didrocks: hm, I've been wondering - I have published qtorganizer5-eds for SRU some time ago, and I don't see it anywhere right now - it's not in the UNAPPROVED queue, it's not in -proposed, it's as the description - in some unknown time and space o_O
<fginther> err, doanac sorry misfire
<fginther> didrocks, hmm... so you could release something to the archive based on lp:unity8 in one landing and something based on lp:unity8/utopic in the next?
<didrocks> sil2100: maybe it's linked to the outage and was never treated?
<didrocks> fginther: yeah, on purpose
<didrocks> fginther: however, all MPs should be targetting the same destination
<fginther> didrocks, that makes sense
<didrocks> sil2100: let me see at least if the sync req was proceeded
<didrocks> sil2100: I don't see anything from today
<didrocks> hum, a stale processâ¦
<sil2100> huh
<didrocks> weird that rsync timeout didn't work
<didrocks> I think it's due to the outage, probably
<Chipaca> sil2100: so, the push bugs got a (possibly automated) comment from raof about testing them. Should I do that, or should I get somebody else to? Feels a little bit dishonest for me to do it unless everybody knows that that's what's going on :)
<didrocks> sil2100: killed then, next run should get it in unapproved
<sil2100> didrocks: oh, so no action needed from my side?
<didrocks> sil2100: watching is enough! :)
<sil2100> Chipaca: hmm, usually someone else needs to do it ;) Maybe you could poke someone from your team?
<Chipaca> I'll rope somebody in :)
* 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: alderamin down
<josharenson> fginther, http://s-jenkins.ubuntu-ci:8080/job/mir-performance-tests-trusty-touch/ failed. I'm looking in to why, but I see a typo in the name of the ppa that the job adds
<fginther> josharenson, ah yes, thanks for pinging me... I was able to get the mako job to run and pass - s-jenkins.ubuntu-ci:8080/job/mir-performance-tests-runner-mako/3/
<josharenson> fginther, cool.
<fginther> josharenson, it is missing the log file
<fginther> or json results file
<josharenson> fginther, that was my next question... The file _should_ be saved on the device in the directory where the test is run.
<fginther> josharenson, what's the file name?
<fginther> josharenson, or can it be specifed as an option to mir_performance_tests?
<josharenson> fginther, its currently glmark2_fullscreen_default.json
<slangasek> didrocks: I'm very glad you implemented an SNCF bot rather than a RENFE bot
<didrocks> slangasek: indeed, we are all about security. Maybe not full speed, but we value safety :)
<slangasek> didrocks: well, I was thinking more about RENFE's website being a java-exception-throwing monstrosity ;)
<sergiusens> didrocks: can I show you something on the choo choo thing?
<didrocks> slangasek: oh really? never had to dealt with it (fortunately it seems)
<didrocks> sergiusens: sure
<sergiusens> ty
<sergiusens> didrocks: meh; when I did it last time I got a bunch of (12:49:12) CI-SNCF: Couldn't find anything matching this status request:
<didrocks> oh?
<didrocks> let me try in PM, but that worked
<sergiusens> didrocks: pastebin would of been easier :-P http://paste.ubuntu.com/7323252/
<slangasek> didrocks: well, it might only throw java exceptions when you try to unsubscribe from their spam, not sure
<didrocks> sergiusens: ahah, I know!
<didrocks> slangasek: that's how you ensure fidelity, right? :)
<didrocks> sergiusens: there is "status" in the line, and so then it treats itself
<sergiusens> didrocks: lol
<didrocks> actually, can be fun, if you set "inspect <line>" in the description, you can recursively DDOS it
<didrocks> ok, I need to ignore what CI Train is telling on the channel I guess :p
<sergiusens> didrocks: also, why is it called landing-xxx instead of silo-xxx?
<didrocks> which is again another patch on the upstream IRC library, I don't know why say what :)
<didrocks> sergiusens: it's been always called like that (ppa name)
<didrocks> blame asac for the ppa name choice :)
<sergiusens> didrocks: heh; wow; I always read silo-xxx :-P
<sergiusens> thanks
<sergiusens> looks good
<didrocks> sergiusens: striking news of the day! :)
<didrocks> sergiusens: I'll look at your issue, but normally, it should ignore itself what it's telling already, maybe a race somewhereâ¦
<didrocks> ogra_: you can join, not sure there is much for you though
<didrocks> plars: same ^
<didrocks> robru: cyphermox: coming?
 * ogra_ expects your will sit there saying "choo choo" all the time anyway
<ogra_> but i'll come :P
<plars> I can't make it right at this moment. Sorry
<davmor2> didrocks: so your idea of a train is more like sl -al :D
<didrocks> :)
<bregma> mmmm, I like this ci-bot choo choo
<ogra_> bregma, http://37.media.tumblr.com/tumblr_lvv9lsZLab1r4vmplo1_500.gif
* 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: alderamin down
* 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: alderamin coming back online
<Chipaca> sil2100: question for you sah
<Chipaca> sil2100: we're having a bit of trouble reproducing the issue behind one of the bugs on other-people's-in-my-team's phones
<Chipaca> sil2100: ideas?
<Chipaca> sil2100: (all but one of the bugs are already 'verification-done' by my team)
<Chipaca> sil2100: (the issue is a race between push and network devices coming online)
<fginther> josharenson, can you check http://s-jenkins.ubuntu-ci:8080/job/mir-performance-tests-runner-mako/5/console? the json data file is being created empty and it looks like glmark probably isn't even running.
<josharenson> fginther, sure. if the executable isn't run, an empty file is created as a method of failing gracefully (since we cant check for the exe at compile time)
<josharenson> fginther, ah I see
<josharenson> fginther, does the jenkins job start a mir server?
<fginther> josharenson, it looks like all it does is install packages, reboot phone, stop unity8 and lightdm, then run the test
<josharenson> fginther, ah, the benchmark isnt running because there is no mir server running
<josharenson> fginther, let me look at some of the other tests and see how they handle this.. unless you know of an easier way
<fginther> josharenson, I don't know of any other mir testing like this, so I don't have any experience here
<josharenson> fginther, the solution is easy, it just needs to run an executable before the test starts.. reliably determining the location of the exe and handling failures may be harder
<fginther> josharenson, do you have a device to test with?
<josharenson> fginther, yes
<fginther> josharenson, ok, so are working on "reliably determining the location of the exe and handling failures"
<fginther> ?
<josharenson> fginther, that is my next step.. working head down in something else atm
<fginther> josharenson, ok, that's fine. I just didn't want this to fall through the cracks if I had assumed the wrong thing
<josharenson> fginther, haha it won't, thanks for checking
<kgunn> fginther: hiya...i'm kinda antsy for this one to merge...is 2 hrs too impatient ?
<kgunn> https://code.launchpad.net/~vanvugt/mir/fix-1308941/+merge/217021
<kgunn> i guess i can manual merge if needed....
<fginther> kgunn, looking
<fginther> kgunn, looks like it's almost done, another 10-15 minutes
* 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: alderamin coming back online
* 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: -
#ubuntu-ci-eng 2014-04-25
<Mirv> alecu: please comment on the bug #1297297 marking it "verification-failed" in case you want to stop the SRU process for it and have it removed from trusty-proposed where it now is
<ubot5> bug 1297297 in unity-scope-click (Ubuntu) "Click scope crash during search when going out of WiFi" [Critical,In progress] https://launchpad.net/bugs/1297297
<alecu> Mirv: sorry, I've not seen it landing, I just saw it as Approved
<Mirv> alecu: yeah, it seems the automated message was missing probably because it got into -proposed on release day, but it's indeed there
<alecu> great then, let's keep it
<Mirv> alecu: ok, so either verify it 'done' or 'failed' after testing so that the package can move in trusty archives
<alecu> Mirv: I proposed to reject that merge proposal, because our /devel branch now gets rid of that code altogether
<Mirv> right, but it still probably makes sense to have that crash workaround in trusty too?
<alecu> Mirv: yes, indeed
<Mirv> ok, good to know
<alecu> Mirv: but, I will not be able to verify it: the bug is very hard to reproduce
<alecu> I only managed to do it once after turning off and on my router about 50 times
<alecu> Mirv: I can do the usual testing for the package, though.
<Mirv> alecu: right. I guess your team knows the best anyhow on how to verify it. like testing that it does not seem to be regressed in other ways, and that while testing you didn't get crashs.
<Mirv> alecu: I think usual testing should be enough, since you're the upstream too there
<alecu> great
<alecu> Mirv: I'll test it later today (was heading for bed right now...), thanks for pointing this out!
<Mirv> alecu: yep, good night, I was expecting you to answer in 12h or so :)
<mardy> didrocks: hi! Did you discuss using a branch other than trunk for synchronizing with the archives, in your last meeting?
<didrocks> mardy: hey, it wasn't in the discussion IIRC
<mardy> didrocks: that's a pity, having to work on other branches (I created "master") is not fun at all
<didrocks> mardy: talk with jfunk. He's the one handling those calls and agenda
<didrocks> mardy: anyway, this will be automated in the airline, as discussed some months ago
<didrocks> mardy: until then, if you want to go to that path, as you did, you can, but you have to deal with it yourself
<mardy> didrocks: OK, thanks
<didrocks> yw
<sil2100> Choo chooo, time for some coffee
<didrocks> :)
<ogra_> bah, the shell crashed over night while the phone was sitting on my nightstand :(
<popey> ogra_: it usually crashes for me in some way (unity/mir or something) when I wake it up after sleep
<ogra_> it has done that for the first time for me
<ogra_> i usually read on it in bed before sleeping ... usually it is still up in the morning
<davmor2> Morning all
<popey> Mirv: when you have a moment could you please push http://s-jenkins:8080/view/click/job/filemanager-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.filemanager_0.3.163_armhf.click file manager to the click store?
<Mirv> popey: ok, in a bit
<popey> thanks Mirv
<bzoltan1> ogra_: do you know who one can tell from adb/shell that the device is up and running with a healthy shell?
<ogra_> bzoltan1, adb shell pgrep unit8 ... but that will not tell you andthing about the health or if it is actually visible on screen indeed
<ogra_> *unity8
<ogra_> *anything
<popey> cihelp, can someone cleanup so i can build reminders please? s-jenkins:8080/view/click/job/reminders-app-click/15/console
<popey> hudson.util.IOException2: remote file operation failed: /home/ubuntu/jenkins/workspace/reminders-app-click at hudson.remoting.Channel@135a132e:cyclops-node10
<psivaa> popey: looking
<popey> thanks
<bzoltan1> ogra_: that is something, thanks... I try to detect  from the QtCreator if the emulator is up or not
<psivaa> popey: that job appears going ok now. on a different node though. pls ping us back if you still see issues
<popey> ok, ta
<Mirv> popey: just to reassure, http://s-jenkins:8080/view/click/job/filemanager-app-click/122/artifact/out/com.ubuntu.filemanager_0.3.163_armhf.click ? the previous url timed out since there is .164 now
<popey> Mirv: yes, 163 please
<popey> thanks Mirv
<Mirv> popey: np, https://myapps.developer.ubuntu.com/dev/click-apps/159/
 * didrocks goes for a run
* 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: -
<sil2100> Jumping out for a minute to drive my girl to the train station
<sil2100> brb
<sil2100> Back
<ogra_> Front
<seb128> Rear
<kgunn> didrocks: my apologies....can we chat now? had a family issue come up i need to take care of in 30 min
<didrocks> kgunn: sure, no worry
<davmor2> sil2100: surely you drive a car not a girl that's just cruel
<kgunn> didrocks: https://plus.google.com/hangouts/_/canonical.com/quick-sync-on
<didrocks> kgunn: yeah, already there!
<dbarth> sil2100: o/ line 36ready;
<dbarth> sil2100: i removed one branch though, but that makes the silo request more coherent (ie, all for fixing google apps)
<sil2100> dbarth: o/
<sil2100> dbarth: the bugs are SRU ready there?
<sil2100> davmor2: ;p
<davmor2> sil2100: you're only doing that because you know I'm right ;)
<dbarth> sil2100: they are SRU'ed yes
<sil2100> dbarth: thanks! Will assign in a moment, need to resolve something first
<dbarth> sil2100: cool
<sil2100> uh
<sil2100> bregma: why did you run merge-and-clean with the ignore flag?
<sil2100> didrocks: ^
<sil2100> bregma: compiz and unity are still in UNAPPROVED, they didn't even get to -proposed yet - it seems very risky to me
<bregma> the binaries are in unapproved, no?
<sil2100> Yes, but what if they get rejected still?
<sil2100> You'll have the release in trunk, but there will be nothing in the archive
<bregma> if they don't get approved we need to do new patches anyhow
<sil2100> Trunk will be out-of-sync with the archive, which is exactly what we don't want happening
<sil2100> Please don't use the ignore flags without asking the landing team before doing that - or maybe you talked already with didrocks or Mirv about this?
<bregma> apologies
<seb128> bregma, sil2100: one other issues is that "syncs" are not real copies, they are pointers to the librarian, when you clean the ppa the original sources is going to be garbage collected
<sil2100> seb128: yeah, they're around for 7 days after deletion though, but only 7
<seb128> so the items in the queue might become un-usable
<seb128> right
<seb128> hopefully the SRU team gets to those before they are claimed abck
<seb128> back
<sil2100> didrocks: ^ just so you know that such a situation happened
<didrocks> one sec, back from meeting
<didrocks> backlogging
<bregma> hopefully it won;t take >7 days for approval for these fixes, they're for pretty serious bugs
<sil2100> dbarth: soooo, anyway, regarding the silo! So, webbrowser-app seems blocked by your earlier SRU - I can free it as it's already in -proposed, but it would be awesome if you could assign someone from your team to do the testing of the package in proposed
<didrocks> bregma: please don't use flags without coordinating with the LT
<didrocks> first
<sil2100> dbarth: working on changing it from verification-needed to verification-done :)
<sil2100> dbarth: as long as you tell me it's being worked on and tracked, then I will 'land' the silo and assign the other one
<didrocks> bregma: well, please push for your SRUs to get approved now
<didrocks> bregma: we won't do the tracking, it will be off our radar
<dbarth> sil2100: i did the testing personally and commented on the bug
<sil2100> \o/
<dbarth> sil2100: but i thought we'd need someone external
<sil2100> FAST
<dbarth> sil2100: i did it this week ;)
<sil2100> dbarth: ok, yeah, it's best if it's not the one fixing the bug ;p
<dbarth> right, judge and party
<sil2100> dbarth: but if you already said +1 on it, at least we know it's not completely broken
<dbarth> sil2100: that, i can attest
<sil2100> Ok, so I'm landing that and tracking so it doesn't get lost
<sil2100> Thanks!
<dbarth> sil2100: i'd say land, yes, since it goes in -proposed
<dbarth> sil2100: hold on though
<dbarth> sil2100: to check we're talking of the same bug
<dbarth> sil2100: we're talking about line 22, right?
<sil2100> dbarth: yeah, I see the comment on one of the bugs tehre
<dbarth> ok, we're good then
<sil2100> There is still this one without comment, but well, we can land it in trunk anyway, as -proposed is -proposed
<sil2100> https://bugs.launchpad.net/webbrowser-app/+bug/1309138
<ubot5> Launchpad bug 1309138 in webbrowser-app "[webapp-container] reload() does not work" [High,In progress]
<dbarth> sil2100: yup please, i tested it 3 times in silo, so i doubt it can go that wrong
<seb128> didrocks, sil2100, bregma: compiz/unity SRU accepted
<didrocks> great!
<didrocks> thanks for the hint
<seb128> yw!
<sil2100> o/
<sil2100> Thank you :)
<alecu> Mirv: I've installed #302 on the phone from scratch, installed the click-scope from proposed and I've followed the test plan for it.
<alecu> Mirv: everything works fine for me.
<alecu> Mirv: should I tag that bug as verified? https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1297297
<ubot5> Launchpad bug 1297297 in unity-scope-click (Ubuntu) "Click scope crash during search when going out of WiFi" [Critical,Fix committed]
<didrocks> robru: around the corner?
<didrocks> ogra_: nothing for you I guess, but you can join
<ogra_> ah, then i'll take the opportunity to skip today
<ogra_> :)
* 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: -
* 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: -
#ubuntu-ci-eng 2015-04-20
<Mirv> tvoss: hello. https://code.launchpad.net/~thomas-voss/location-service/fix-1441619/+merge/256460 is unapproved so it couldn't be published to the overlay PPA.
<tvoss> Mirv, hey there, we are still iterating on the MP, but need the silo for testing purposes
<Mirv> tvoss: hmm, it was sent to QA sign-off and QA spent quite many hours with it already?
<tvoss> Mirv, very unlikely
<Mirv> tvoss: landing-030, that is
<Mirv> https://trello.com/c/aB4OnkXF/1406-ubuntu-landing-030-location-service-tvoss testing throughout Friday by alesage
<tvoss> Mirv, I for sure did not mark it as tested :)
<Mirv> tvoss: someone did
<Mirv> tvoss: although, QA should have spotted the num/device/tester fields weren't filled in
<Mirv> anyway, unfortunate but that could have been caught by QA because of those missing details
<tvoss> Mirv, interesting, I will try to find out what happened
<Mirv> I added a comment that it should not be published. if/when you do more changes to the MP, it's best to set the QA Signoff needed back to Required and Tested back to No.
<tvoss> Mirv, I'm waiting for final testing in the London office (the bug was originally filed there)
<Mirv> tvoss: ok, let's see. it's of course still possible it's good as is and wouldn't need retesting by QA, but let's see.
<tvoss> Mirv, yup
<alesage> Mirv, tvoss, was the silo approved in error?
<tvoss> alesage, yup, I don't know who set it to tested, yet
<Mirv> alesage: apparently, although there's a chance it will not need further changes. but there's an error in the QA process - the three bits of info (image #, device, tester) were not filled in, QA process should check those
<Mirv> before starting signoff
<oSoMoN> ubuntu-qa: good morning, any chance silo 7 can be validated soon for landing in the overlay PPA ? Iâve a got a pile of approved MRs for webbrowser-app to land, and theyâre blocked on this one
<sil2100> ugh...
<sil2100> Hey everyone
<sil2100> I think I need to go back to bed for a few more minutes
<sil2100> Don't feel too good
<sil2100> In case I don't make it for the meeting, feel free to use it as you wish
<Mirv> sil2100: happy jetlagging! :) or hopefully just that.
<Mirv> and not ubuflu.
<Mirv> rsalveti: pleas push your qtmultimedia changes to https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtmultimedia-opensource-src
<Mirv> at some point
<popey> hmm, my phone has frozen
<tvoss> sil2100, ping
<davmor2> popey: wasn't that Madonna '00's come back song
<Mirv> your phone has frozen, when your kernel's not open
<sil2100> ugh, not sure if this is a really bad jetlag or ubuflu, feel really tired and mopped out
<sil2100> And sick
<sil2100> Mirv: sorry for leaving the train duties mostly on your shoulders today again ;(
<Mirv> sil2100: no problem, not much load so far anyway except answering questions
<Mirv> I just wonder if I should go for a late lunch or if I should stay home if UPS delivers my Bq
<Mirv> eating is overrated
<sil2100> ;p
 * sil2100 would still be sleeping if not for the UPS delivery man ringing on his door
<dbarth> o/ trainguards, could i get a reconfig for silo 6 please (i re-added a merge proposal which was blocking us earlier)
<dbarth> the normal reconfigure tool did not accept the addition of a line
<sil2100> dbarth: let me try doing that for you
<Mirv> sil2100: reconfiguring
<Mirv> sil2100: ^
<sil2100> Ah ;)
<sil2100> Ok
<sil2100> Mirv is too fast for me today
<Mirv> dbarth: ^
<dbarth> thank you
<davmor2> sil2100: ha, you need to drink less on ubuntu trips
<Mirv> tvoss: please reset the tested fields now that you rebuilt it
<tvoss> Mirv, ack
<tvoss> Mirv, done
<Mirv> thanks
 * Mirv got Bq finally!
<ogra_> yay
 * davmor2 steals Mirv bq not any  more psych
 * Mirv quickly tests that machines vs machines works ok also on Bq
<ogra_> Mirv, we can only consider that proven if the last level works though
<Mirv> right, well just a moment in that case
<davmor2> 6 hours later Mirv becomes productive enough to say good night
<davmor2> ogra_: it does see my finally completed it post on g+
<ogra_> davmor2, that doesnt say anything about Mirv's phone ... this test indeed only works individually
<Mirv> you never know when there's a bug lurking
<davmor2> Mirv, ogra_ : no I found the bug
<davmor2> didn't I mzanetti :D
<mzanetti> huh?
<ogra_> is that a verb now ?
<ogra_> like "I googled..." ?
<davmor2> mzanetti: Found the bug in Machines vs Machines
<mzanetti> grr... yes... you did
<davmor2> Mirv, ogra_: ^ see
<mzanetti> and stop reminding me every other day about it... :D
<davmor2> mzanetti: you can blame ogra_ and Mirv this time :)
<mzanetti> davmor2, just kidding... it just still annoys me that this bug is unfixable
<mzanetti> with the given resources, that is
<zbenjamin> unfixable bug? oO
<mzanetti> zbenjamin, yeah... would require me to verify and tweak all levels again
<mzanetti> but there's absolutely no chance I'll do that a second time for free
<zbenjamin> mzanetti: is it that annoying?
<davmor2> zbenjamin: only to mzanetti
<davmor2> zbenjamin: most users will never notice it :)
<oSoMoN>  ubuntu-qa: hey guys, any chance silo 7 can be validated soon for landing in the overlay PPA ? Iâve a got a pile of approved MRs for webbrowser-app to land, and theyâre blocked on this one
<rvr> oSoMoN: Is not the highest priority silo right now :-/
<davmor2> oSoMoN: and because of iso testing testers are reduced too
<rvr> oSoMoN: How is it tested, anyway?
<oSoMoN> rvr, davmor2: I understand that, thatâs fair enough. When do you estimate someone could get to it? Tomorrow? The day after? Next week?
<oSoMoN> rvr, I need to update the manual test plan (there will be autopilot tests but in a subsequent MR), I havenât done so until I know for sure when it will actually be tested
<rvr> oSoMoN: If US team is fully available, I expect tomorrow or so, but cannot say for sure.
<oSoMoN> rvr, ok, thanks
<davmor2> oSoMoN: just the wrong week to try and land stuff :D
<oSoMoN> you mean the wrong month, right?
<vila> fgimenez: nooo, come back !
<vila> :)
<vila> \o/
<vila> fgimenez: so, with the plugin hint, I've found https://github.com/pradels/vagrant-libvirt and https://github.com/fgrehm/vagrant-lxc
<vila> Is this what you had in mind /
<vila> https://github.com/adrahon/vagrant-kvm is dead according to the project itself
<fgimenez> yep, the libvirt one, i'm testing it and seems to work
<fgimenez> something like this http://paste.ubuntu.com/10856404/, i haven't see it up yet, but seems to go fine
 * vila nods
<vila> re-installing vagrant ;)
<rvr> charles: Silo 27 approved
 * Mirv reconfigures and publishes
<Mirv> charles: rvr: how was it missed that powerpc FTBFS:d in the silo 027? if something like that happens, the silos houldn't be set as having been tested. I guess it's flaky and can be fixed at this point, but it should have been done earlier.
<rvr> Mirv: ?
<Mirv> rvr: so the indicator-location build had failed in that PPA you reviewed. I'm just noting it should not have been set as tested if there's a build failure.
<rvr> Mirv: Ahh
<charles> wtf
<charles> and https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-027/+build/7337699/+files/buildlog_ubuntu-vivid-powerpc.indicator-location_13.10.0%2B15.04.20150417-0ubuntu1_BUILDING.txt.gz has cycled out
<charles> I'll start a rebuild so we can see where the FTBFS is
<Mirv> charles: stop
<charles> Mirv, ack
<Mirv> charles: I restarted the powerpc build only, and it succeeded now https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-027/+build/7337699
<Mirv> charles: I wouldn't really worry if it's 32-bit powerpc only that's flaky, although at leisure it could be investigated if it could be made more trustworthy
<charles> Mirv, dyk if there's still a url for the ftbfs run somewhere?
<charles> I'd like to know where it failed
<Mirv> charles: rvr: published (to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages) - it seems it didn't pick up my powerpc rebuild yet as a binary copy, so there's a chance the failure can be seen again there.
<Mirv> charles: I think it's gone at the moment the single arch rebuild is done
<Mirv> charles: it was in tests, anyway, but I just don't have it open anymore
<dbarth> o/ trainguards, could you update silo 11 with a newer build of oxide; took too long to validate and now we have 1.6.4 officially stable
<elopio> ping fginther: you mentioned last week that the run we see in the dashboard are not completed because the phone dies.
<elopio> do you have some time to talk about that?
<pmcgowan> dbarth, we should really land that today
<dbarth> pmcgowan: that's not the one you want, 1.7.0pre is still building in the phablet ppa
<dbarth> the one with the arale fixes
<pmcgowan> dbarth, I just want one to land don't care which one :)
<pmcgowan> little worried about 1.7 this late
<dbarth> 1.7 is 1.6 branched, so not many changes yet
<pmcgowan> dbarth, so why is 1.6 in a silo then?
<elopio> ping fginther: you mentioned last week that the run we see in the dashboard are not completed because the phone dies.
<elopio> do you have some time to talk about that?
<fginther> elopio, sure
<dbarth> pmcgowan: to release to all releases / models, whereas 1.7.0pre should be for the other image
<dbarth> i that works
<pmcgowan> I see
<elopio> fginther: is there a bug reported for the project that makes the phone die?
<pmcgowan> dbarth, when will 1.7 go into a silo? it should be prioritized ahead of the other
<fginther> elopio, this one: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1421009
<ubot5> Ubuntu bug 1421009 in qtbase-opensource-src (Ubuntu) "unity8 sometimes hangs on boot" [Critical,In progress]
<pmcgowan> dbarth, and does oSoMoN  know this plan?
<elopio> thanks fginther. And is that the only problem afecting the runs?
<oSoMoN> pmcgowan, landing 1.6 now is the normal process (1.6 was declared stable last week), 1.7 was just branched
<dbarth> pmcgowan: as soon as the build works
<fginther> elopio, there is an occasional error encountered when ubuntu-device-flash gets an EOF when downloading the image that isn't handled (and I don't think there is a bug for this).
<elopio> fginther: great. We are just making a small research to see if some of the errors are caused by our tools or tests. Do you know about something we can do to improve the runs?
<fginther> elopio, there are some things on the automation side and assuming more things could fail would help. For example, running each test suite individually would help improve the number of results (but take longer to run).
<elopio> fginther: thanks, I'll get back to you if I have more questions. And please let us know if you find another problem.
<Mirv> dbarth: from where?
<dbarth> Mirv: hang on, we're still figuring that out
<Saviq> trainguards, do landing into the PPA go through the QA process just as they did for vivid until now?
<Saviq> and please Icanhassilo â?
<Mirv> Saviq: yes, and yes
<om26er> Kaleo, Hi!
<Kaleo> om26er: hey
<om26er> Kaleo, did you see the autopilot test failure bugs that I reported ?
<Kaleo> yep
<Kaleo> is it urgent? can it wait until our next sprint?
<Kaleo> Monday
<om26er> Kaleo, I have one MR to fix a failure, you may review that.
<Kaleo> oh right
<Kaleo> yep
<om26er> Kaleo, also its not urgent but I believe soon the dashboard is going to be an important criteria for image promotion.
<Kaleo> ok
<kenvandine> renatu, i freed the old syncevolution silos
<om26er> kenvandine, Hi!
<kenvandine> hey om26er
<om26er> kenvandine, re: silo24 the behavior seems to be a bit different from Indicators
<kenvandine> how so?
<kenvandine> i haven't re-tested since dednick pushed a fix
<om26er> kenvandine, if I go to flight mode from the indicator, the switch gets disabled till the toggle finished while in the App I can enable/disable the switch always
<kenvandine> is that different than without the silo?
<om26er> kenvandine, no, no change visually for both with or without the silo.
<kenvandine> om26er, yeah, i suspect there's some special treatment there in the indicator, not sure
<kenvandine> om26er, are you testing the latest build, with the fix from today?
<om26er> kenvandine, yes.
<kenvandine> om26er, awesome!
<om26er> kenvandine, the behavior is correct inside wifi panel. The inconsistency is on the main settings page.
<kenvandine> oh
<kenvandine> yeah, but not related to the silo
<kenvandine> but perhaps it could benefit from the same component
<om26er> kenvandine, hmm, ok, just wanted to make sure the behavior I am seeing is expected.
<kenvandine> om26er, that's expected, but doesn't mean it shouldn't be improved
<om26er> kenvandine, hmm how do we proceed, would you fix that first or want the silo to land as-is ?
<kenvandine> if it isn't a regression, we should land it
<kenvandine> and i think that's what you were saying
<om26er> yep, not a regression.
<kenvandine> cool
<kenvandine> please file a bug about it
<kenvandine> there must be some special treatment in the indicator, we could apply the same in settings
<robru> kenvandine: https://code.launchpad.net/~nick-dedekind/ubuntu-system-settings/1390136.laggy-backends/+merge/253395 this MP looks funny (4 Needs Fixing reviews), why did it go for QA?
<kenvandine> robru, oh... let me fix that
<kenvandine> we found a regression friday
<kenvandine> so i bumped it out of approved
<kenvandine> he fixed it today
<robru> kenvandine: so those reviews are old? i hope the package that QA reviewed is acceptable
<kenvandine> it is
<kenvandine> i reviewed his fix today
<robru> kenvandine: k, will publish
<kenvandine> just forgot to ack the MP too
<kenvandine> robru, thx
<robru> kenvandine: you're welcome!
<robru> brb
<rsalveti> robru: pmcgowan: was sil around today?
<pmcgowan> not that I noticed
<rsalveti> wonder if we're good with the new overlay PPA already
<pmcgowan> yeah that worked fri for a landing
<rsalveti> missing an email with better info/instructions
<pmcgowan> I think its all the same and transparent
<rsalveti> and if the new images are already published with the overlay
<pmcgowan> they shold be afaik
<rsalveti> alright, I'm just hoping the vivid landings will go to the overlay ppa by default
<rsalveti> if so, good
<pmcgowan> didnt steve's email say so?
<rsalveti> but would be nice to have an email as well
<rsalveti> maybe I missed something
<pmcgowan> seems so
<pmcgowan> see email from steve on fri
<rsalveti> oh, indeed
<pmcgowan> actually sat
<rsalveti> great, don't know why it got lost in my mailbox
<robru> rsalveti: there's an email explaining it on the internal phablet list. Sent by Steve and my reply has more precise instructions.
<robru> Heh, yeah
<rsalveti> we have 2 emails, on public and one private
<rsalveti> but we got a few landings at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay, so all good
<pmcgowan> rsalveti, at least something got done :)
<rsalveti> robru: yeah, you said the missing info that I was looking for
<rsalveti> the special L column
<rsalveti> too many emails
<robru> bzoltan_: zbenjamin: please approve your merges: https://ci-train.ubuntu.com/job/ubuntu-landing-004-2-publish/51/console
<robru> zsombi: rather ^
#ubuntu-ci-eng 2015-04-21
<robru> alex-abreu: https://code.launchpad.net/~abreu-alexandre/unity-webapps-qml/improve-embedded-ui-params-passing/+merge/250329 need this top-approved
<rsalveti> Mirv: https://code.launchpad.net/~rsalveti/kubuntu-packaging/qgstreamercapturesession_avoid_race_eos/+merge/256881
<Mirv> rsalveti: thanks!
<bzoltan_> robru: ohh, what a begginer mistake :) thanks... now the MRs are approved
<bzoltan_> Mirv: ^
<Mirv> bzoltan_: nice!
<bzoltan_> Mirv:  I am sorry ... I simple forget about approving the MRs ..
<Mirv> bah, now we'd need packaging ack
<Mirv> robru: the diffs fixing is still underway, right?
<robru> Mirv: should be fixed...
<Mirv> robru: it's saying the source is a new package https://ci-train.ubuntu.com/job/ubuntu-landing-004-2-publish/lastSuccessfulBuild/artifact/ubuntu-ui-toolkit_packaging_changes.diff
<Mirv> bzoltan is probably pretty sure he has landed ui toolkit before
<bzoltan_> few times
<robru> Buh
<robru> Mirv: go back to the old build job for now. Will investigate that tomorrow
<Mirv> robru: thanks!
<robru> Mirv: https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/129/ this one I think
<robru> You're welcome
<Mirv> robru: yes, found it
<robru> Great
<Mirv> asking for packaging ack on #ubuntu-devel
<Mirv> got ack
<popey> sil2100: cwayne bug 1446499 after updating today from store - it's gone.
<ubot5> bug 1446499 in unity8 (Ubuntu) "Updating today scope from store kills scope, doesn't restart" [Undecided,New] https://launchpad.net/bugs/1446499
<ogra_> popey, does it come back after reboot ?
<popey> not rebooted yet
 * ogra_ stays away from updating
<Mirv> I can confirm
<Mirv> and does not come back after reboot
<popey> gah!
<popey> victorp: ^
<sil2100> huh
<sil2100> bzoltan_: we'll have to poke the release team about this one
<sil2100> bzoltan_: i.e. about qtcreator-plugin-ubuntu - it's critical, so should be good to get approved
<bzoltan_> sil2100:  thanks. it is silly to catch a critical bug at that late phase and even sillier to shoot twice on the same bug.
<ogra_> popey, can we pull it from the store worst case ?
<popey> not sure, last time I did that, I kinda got chided by beuno
<Saviq> cihelp, the provision script's been aborting for me with this error http://pastebin.ubuntu.com/10860323/ for a few days now, that expected?
<popey> ah no, I can "unpublish" okayt
<ogra_> popey, well, or block it ... we should make sure not more people upgrade to it
<popey> (it was revert to previous version he didn't like)
<ogra_> ah, yeah
<popey> ~380 people have updated so far
<ogra_> damn
<popey> shall I unpublish do you think?
<ogra_> yeah
<popey> done
<ogra_> if it is reproducable we should prevent more damage
<ogra_> and i see you pinged victorp already ... i guess we need a quick fix to unscrew the users
 * popey adds a comment to the bug to say I unpublished
<popey> well, they can reboot and then re-fave the scope
<popey> but that's not very pleasant, and no discoverable
<ogra_> i thought it is gone ?
<sil2100> popey: cwayne should be around in a few hours to help out if anything
 * Saviq thinks it was renamed to "dashboard" wasn't it?
<sil2100> In the meantime let's unpublish
<ogra_> already happened :)
<Saviq> likely why it disappeared from the favorite list
<ogra_> ouch
 * popey wonders how this was tested :(
<ogra_> yeah, we have no support for that
<sil2100> I wonder if it was signed off by QA at all
<ogra_> yup
<ogra_> weird
<popey> ok, well we have a bug and they can look when they wake
<sil2100> This might be another hole in our process
<sil2100> Normally testing of the today scope happens on new custom tarballs
<Mirv> thanks popey
<popey> np
<Saviq> popey, just to confirm, can you see in "gsettings get com.canonical.Unity.Dash favorite-scopes"
<popey> Saviq: i have already rebooted and re-added..
<Saviq> popey, sure, that's fine, still interesting to know what the scope id is
<popey> ['scope://com.canonical.scopes.dashboard_dashboard', 'scope://unity-scope-nearby', 'scope://clickscope', 'scope://com.canonical.scopes.news_unity-scope-news', 'scope://musicaggregator', 'scope://videoaggregator', 'scope://com.canonical.scopes.photos_photos']
<Saviq> popey, if you don't care for your favourites list, could you `gsettings reset` it?
<popey> I'd rather not.
 * Saviq wonders if they updated the default
<Mirv> oh, it can be readded. but how do I get it to be the first on again instead of last one?
<popey> oh go on then
 * sil2100 will upgrade the package
<sil2100> Mirv: you can re-order
<Mirv> long press
<Mirv> sil2100: found
<Saviq> Mirv, long-press, drag by handle
<sil2100> Mirv: just long-press it on the manage screen
<sil2100> Yeah ;)
 * popey mails the phone list to let people know how to undo this.
<Mirv> almost discoverable
<Saviq> Mirv, good news: manage dash is likely going away
<popey> Saviq: resetting has done this:-
<popey> phablet@ubuntu-phablet:~$ gsettings get com.canonical.Unity.Dash favorite-scopes
<popey> ['scope://clickscope', 'scope://musicaggregator', 'scope://videoaggregator']
<popey> :(
<Saviq> popey, weird, that's mako/rtm?
<popey> no
<popey> retail bq
<Saviq> huh
<Mirv> yeah, I got my retail bq yesterday
<Saviq> popey, fwiw, you can `gsettings set com.canonical.Unity.Dash favorite-scopes "['scope://com.canonical.scopes.dashboard_dashboard', 'scope://unity-scope-nearby', 'scope://clickscope', 'scope://com.canonical.scopes.news_unity-scope-news', 'scope://musicaggregator', 'scope://videoaggregator', 'scope://com.canonical.scopes.photos_photos']"` to get back your list
<popey> thanks
<Saviq> but the reset is scary, /me flashes krillin to see in a moment
<Saviq> this would mean that the custom tarball doesn't override the default
<Saviq> but that'd be *really* weird
<ogra_> Saviq, why would it
<sil2100> Strange, I don't see the today scope update on my krillin, huh
<ogra_> the custom tarball installs what is in it as upgrade time, thats it ... if there is a newer version of something it ships in teh store this will always override
<ogra_> sil2100, because it was unpublished already :)
<Saviq> ogra_, I meant the gsettings key
<Saviq> ogra_, the default list of favourite scopes is just apps, music, video unless it's overridden by custom tarball
<ogra_> the default is likely schipped as system wide schema ...
<sil2100> Ah, it was already, ok ;)
<ogra_> so if the user has the key set, it will override the system one
<Saviq> ogra_, which is why going `gsettings reset ...` should get it back
<ogra_> yeah
<ogra_> it doesnt ?
<Saviq> ogra_, and popey did the reset, and was presented with just the 3 scopes
<popey> http://people.canonical.com/~alan/clicks/com.canonical.scopes.dashboard_1.7.15_armhf.click is the offending click if you really want it sil2100 :)
<Saviq> this is what makes me wonder
<sil2100> popey: thanks ;)
<Saviq> Mirv, confirmed silo 15 makes CPU settle
<Mirv> Saviq: thanks! I tested both that use case and the one I found.
<sil2100> jibel: ping
<Saviq> ogra_, oh, they're not using gsettings overrides but a dconf one...
<ogra_> lovely
<Saviq> ogra_, popey, sil2100, IMO a bug in unity-scopes-shell, letting pete-woods know
<Saviq> pete-woods, https://bugs.launchpad.net/today-scope/+bug/1446499/comments/12
<Saviq> pstolowski, â
<ubot5> Ubuntu bug 1446499 in unity-scopes-shell (Ubuntu) "Updating today scope from store kills scope, doesn't restart" [Undecided,Confirmed]
<victorp> ogra ping
<ogra_> victorp, hey
<victorp> just saw the pings from you and popey, whats up?
<ogra_> victorp, today scope in the store is broken
<ogra_> victorp, we unpublished it, but it went out to ~350 users
<victorp> ok..
<victorp> what are you installing it on? arale or krillin?
<Mirv> krillin stable
<sil2100> victorp: on krillin
<ogra_> retail devices
<Saviq> ogra_, victorp, I wouldn't say "the scope is broken" any more
<ogra_> well, the user exÃ¼perience is broken once you install the update :)
<Saviq> it's the update process that's broken
<ogra_> ("the scope is broken is shorter :P )
<Saviq> yeah ok, details on the bug
<sil2100> Saviq: ok, might indeed be the case here
<ogra_> Saviq, well, it also didnt get any QA it seems
<sil2100> Although I think that updating the scope without QA is a bad thing in overall
<Saviq> ogra_, sure, FWIW I'd say the problem is race-y, too
<ogra_> yeah
<Saviq> so not everyone will hit it
<sil2100> Some people said it was fine for them
<Mirv> sil2100: where? at least on the bug report the reply was "fine if you readd it" if I understood it correctly.
<sil2100> Mirv: on the mailing list
<Mirv> sil2100: oh, ok. good if it doesn't hit everyone.
<victorp> ogra_, sil2100 first of all , dont make things up
<victorp> :)
<sil2100> Mirv: one person said that he upgraded and today scope remained on the favorite list
<Mirv> sil2100: so it seems
<pstolowski> Saviq, commented, it's as you described
<victorp> if you have a scope favourited and you  updated it to a new version it *always* removes it from the fav list
<victorp> Saviq, ^^
<victorp> but should still appear in your bottom edge list
<ogra_> victorp, ugh
<sil2100> victorp: so that's by design?
<victorp> i thought that had been reported, it happens to me with the child scopes we favourited
<Saviq> victorp, yeah, that's correct, but shouldn't be the case should it
<victorp> well seems like bad desing :)
<sil2100> ;)
<ogra_> that sounds pretty broken ... like if an update would remove the icons i added from the launcher
<victorp> right, I thought it was a bug that had been reported , my bad for not checking
<victorp> ogra_, agreed
<victorp> so the more concerning part would be why is not appearing in the bottom edge with respect today scope
<ogra_> victorp, good that we catched it then ... better if a QA test had catched it before it went to the store though :)
<Mirv> do we have phased store updates in plans similar to image updates?
<victorp> ogra_, it wouldnt, because this only happens if you update from the scope, if you update custom is doesnt
<pstolowski> victorp, so it's not appearing on the bottom edge list under 'Also installed' ?
<ogra_> victorp, well, a new music app doesnt go into the store without QA run ... this scope apparently did according to QA
<ogra_> also i thought it is in the manage scopes tool, but under new name ?
<victorp> ogra_, what are you talking about?
<sil2100> This is one of the holes in the process, every new click that's by default on the image and gets upgraded needs QA sign-off
<sil2100> Even the today scope
<ogra_> victorp, with what exactly ?
<ogra_> victorp, that the scope didnt get QA before oing to the store ?
<victorp> I am telling you the scope is not broken, is the "update a scope from the store" process that is doing this , you just have notice it now
<ogra_> *goin
<ogra_> ah !
<ogra_> right, i didnt get that ...
<victorp> pstolowski, so reading the bug from popey it appears after reboot
<popey> victorp: only if you re-add it.
<ogra_> popey, in the manage... list
<popey> yes
<victorp> popey, what do you mean by re-add it?
<Mirv> victorp: from user point of view it's gone for good and doesn't come back. I didn't find it in the management either untils someone told it that it's in there.
<popey> sorry, re-favourite it
<victorp> popey, ack
<victorp> ok, first of all - this has nothing to do with the today scope
<ogra_> popey, well, this was about: is it in the manage scopes area only after a reboot or is it there right after upgrade
<victorp> that is the behaviour of all scopes you update from the sore
<victorp> store
<popey> ok.
<pstolowski> so it's two problems actually; manage list didn't refresh until reboot, and the scope needed to be favorited again
<victorp> if it wasnt in the bottom edge after update and then shows after a reboot, that still has nothing to do with the scope
<popey> But the fact that it's the default first scope, it uncovers a bug
<ogra_> sure
<victorp> pstolowski,  +!
<victorp> +1
<victorp> popey, exactly
<victorp> as far as I can tell the team is just publishing to the store scopes that where added to custom-proposed , which is tested ogra_
<victorp> I didnt get an update notice
<ogra_> because we unpublished it
<popey> i pulled it from the store around 40 mins ago
<victorp> but if they had to change the version for whatever reason, it would have trigger it
<ogra_> and you dont get noticxes for apps/scopes
<victorp> i.e. change on mantainer name in manifest
<victorp> so I dont think qaing this more would have helped, what we need is the beta/alpha channel in the store so we can test upgrades
<victorp> I believe beuno's team is already working on that
<popey> well if someone had installed the click on a retail bq device they would have noticed the scope disappear
<victorp> so, can we open 2 bugs to track the issues that pstolowski has highlighted
<popey> and hopefully file the right bug?
<ogra_> right, we would at least have catched one of the issues here
<popey> but I suspect nobody QA'd it on a _retail_ bq image.
<popey> because that's the only one shipping it by default
<victorp> popey, I understand that this issues are new to you, but we have know about them for a while, I just thought they were being addressed
<popey> or they did, and ignored the fact that the scope disappeared
<victorp> popey, more probably that
<popey> victorp: new to me and thousands of bq retail handset owners
<ogra_> yeah
<victorp> popey, ok and? I am not sure what you are asking me?
<popey> ok. where is the bug tracking the fact that scopes disappear, and need a reboot?
<victorp> I think we need two bugs for that
<popey> the assumption that things are being fixed because "we read:I already know about them" is a broken process.
<victorp> can you please open them popey?
<popey> i opened one, I don't know what the second one is.
<victorp> popey, sure - if you expect me to find all the bugs that is also broken :)
<popey> I didn't say you. I implied QA
<popey> If someone is QAing something and they spot something is broken, I'd expect a bug.
<popey> my point being nobody filed a bug for these issues because "we know about it"
<ogra_> victorp, if you found that bug before (knew about it), someone must have seen it but not filed it ... thats the broken part
<popey> but yeah, I'll file the bugs for you.
<popey> exactly
<victorp> anyway, this is going in circles, there are two bugs in unity8 Saviq.. favouriting does not survive an update from the store , and the bottom edge/manage dash does not seem to always register updates.
<ogra_> victorp, when interacting with the users it helps if we can point to a bug
<victorp> let me know if you need anything else
<victorp> ogra_, 100% agreed
<ogra_> i.e. popey could have pointed it out in the warning mail he sent
<Saviq> victorp, both are unity-scopes-shell bugs
<victorp> Saviq, ack
<victorp> Saviq, are you happy just tracking the issues on 1446499
<popey> i added a second
<popey> bug 1446536
<ubot5> bug 1446536 in unity-scopes-shell (Ubuntu) "Scope disappears from bottom edge on update" [Undecided,New] https://launchpad.net/bugs/1446536
<Saviq> victorp, popey, thanks
<victorp> ta! popey
<Saviq> pstolowski, one more related, not sure if that's -scopes-shell exactly or the scope backing Manage Dash â
<popey> so do we re-publish today in the store?
<popey> because this is a "known" bug?
<Mirv> I think it's really bad from user pov
<ogra_> well
<Saviq> yeah, but then otherwise we'd block any core scope updates until we release the next OTA...
<ogra_> we dont have a system update planned
<Mirv> well right, true
<ogra_> so the fix wont land before next OTA
<Mirv> people will learn to use scopes at least..
<ogra_> i wonder if there is a way to hack around it from the scopeside
<Saviq> ogra_, not likely
<pstolowski> Saviq, ok, so this is the second problem from the 1st bug
<ogra_> yeah, i was fearing that
<Saviq> ogra_, it's basically a case of "oh, the scope went away, let's drop it from favourites"
<ogra_> so either we live with the bug (very bad imho) and re-publish ... or we hold back all scope changes til it is fixed
<Saviq> pstolowski,
<Saviq> https://bugs.launchpad.net/today-scope/+bug/1446499/comments/16
<ubot5> Ubuntu bug 1446499 in unity-scopes-shell (Ubuntu) "Updating scope from store removes it from favorites" [Undecided,Confirmed]
<ogra_> victorp, any opinion ?
<pstolowski> Saviq, yeah, that would be simple to do, but would mean we never get rid of uninstalled scopes. unless we purge at startup
<Saviq> pstolowski, hook on uninstall won't do, as it's based off of the .ini file already?
<pstolowski> Saviq, sorry, i can't parse what you're saying ;). i'm just talking about the plugin which purges favorites whenever registry is updated (and scope disappears)
<Saviq> pstolowski, sure, I'm saying that a hook on uninstall could trigger the removal from favourites, unless this is basically what happens already?
 * Saviq wonders how relevant this discussion is in light of "scopes as apps"...
<pstolowski> Saviq, ah, no. it's handled completly by the shell
<pstolowski> * shell plugin
<pstolowski> Saviq, yeah, becomes irrelevant then ;)
<Saviq> well, kinda
<Saviq> it just moves from Manage Dash to $wherever_we_store_favourites (like in click scope or something, to display at the top)
<dbarth> jibel: o/ i'm trying to get an idea whether silo 6 is considered for testing, or if there is something blocking landings in the overlay ppa
<dbarth> i may have another silo next, with branches targeted for desktop (w updates and potential srus); let me know
<jibel> dbarth, it is in the triaged queue, it should be verified soon-ish
<dbarth> ok, nw
<bregma> trainguards, point of procedure: do I need to get an ACK from the Ubuntu release team first to land silo ubuntu/landing-020 (#1446256) or does it just land and go into the UNAPPROVED queue and get ACKed from there?
<dbarth> jibel: thanks
<sil2100> bregma: we could publish it without an ACK, but it's best to coordinate beforehand especially if the bug that's being fixed is not set to critical
<sil2100> bregma: without the ACK it would en up in UNAPPROVED, but might get rejected due to lack of infromation etc.
<bregma> sil2100, thanks
<Mirv> sil2100: bregma: since it's seeded I think it's even required to go via release team https://wiki.ubuntu.com/FinalFreeze
<Mirv> for example qtcreator-plugin-ubuntu was unseeded universe package but unity is a different beast
<Mirv> anyway, it's still >1.5 days so it's ok to go to vivid normal instead of proposed
<Mirv> davmor2: Bq now passes my official seal of approval requirements when I'm now writing this from Bq after using a menu shortcut to login + screen -dr and I've added Ctrl-D, Ctrl-P and Ctrl-N to the ctrl menu
<jibel> sil2100, Mirv bregma if it is ready publish it, we need it on the image
<sil2100> jibel: ok
<sil2100> Mirv: let me publish the unity silo then
<Mirv> sil2100: ok
<sil2100> The release team will deal with it ;)
<bregma> that's right, pass the buck
<davmor2> Mirv: it did anyway, I told you you were just using it wrong ;)
<Mirv> davmor2: that too :)
<davmor2> Mirv: did you like the osm touch app by the way?
<davmor2> Mirv: and don't play uu or we'll lose you forever :D
<Mirv> davmor2: the osmtouch is a familiar one to me, I've used it mako quite a bit. even though I didn't use mako "really really" (so this Bq is what I really give my "normal use case" for), I did use it for browsing and location
<Mirv> davmor2: it's ok but I need something closer to Osmand~ - offline vector maps, voice navigation
<Mirv> and if I would have click chroot creation not broken on my vivid I'd give a Navit or Marble a try to get something built
<Mirv> but alas I've not found the reason why click is totally busted on my machine
<davmor2> Mirv: here does turn by turn it you switch down to walking rather than driving :)
<Mirv> davmor2: here is closed source, I want OSM maps too :)
<Mirv> I prefer OSM in general even without closed/open over google maps and here maps
<davmor2> Mirv: whine whine whine ;)
<Mirv> just so much more "love" into details in there, like stairs, tree locations or cow locations when people go crazy in details :)
<Mirv> well maybe not cow unless there's real time tracking objects feature in OSM
<Mirv> davmor2: no I just want to make it win win win for me :)
<davmor2> Mirv: it's not working because it hates you, hate it back it works for me ;)  It might be all the dev stuff you have in place for other stuff is interfering maybe?
<Mirv> davmor2: :) I won't install any dev stuff on the Bq (except for stuff like customizating terminal settings etc). but no apt etc hacking.
<davmor2> Mirv: what you really need is a new dell laptop and a fresh install of vivid that will fix it and your broken screen too :D
<Mirv> oh right the chroot, yes
<Mirv> davmor2: I'd like to understand the actual bug in there, I've already gone through two difficult ones but it still now fails at the end of it (used to be: in the beginning)
<Mirv> but it's annoying since at the end of click chroot creation it wants to unmount my encrypted home after which my desktop is busted
<davmor2> Mirv: blame pitti or ogra that normally gets things fixed ;)
<Mirv> davmor2: I don't blame anyone, I file bugs!
<davmor2> Mirv: you do it all wrong don't you :D
<Mirv> but true, I'll get a fresh machine soon (~month?). but I hate it when there's some bug that might really affect other people too.
<Mirv> I'm sure other people are running into that previously filed bug #1436835 too
<ubot5> bug 1436835 in click (Ubuntu) "click chroot build fails on vivid" [Undecided,New] https://launchpad.net/bugs/1436835
<davmor2> Mirv: you could try throwing a kvm install or an lxc install and try running it in there and then figure out the difference between the base install and the version on your desktop to figure out why it hates you
<davmor2> Mirv: I wonder if it is the QT versions you are building playing havoc with the system maybe?
<Mirv> davmor2: true, although I can also just run 14.04 LTS from my server and do stuff there
<Mirv> davmor2: no, I
<Mirv> davmor2: 'm not building Qt on this machine, but in a chroot on my server machine
<Mirv> davmor2: similar to that filed bug ^ I've messed around with schroot before and configuration files a lot, and ideally click would detect the most common misconfigurations instead of blowing up
<davmor2> Mirv: are you testing the QT packages on that machine though?  Ie is it expecting to install qt 5.3.1 and getting qt5.3.4 that you've installed or something crazy like that?
<Mirv> davmor2: one problem is that I've already checked everything I can regarding click & schroot against a clean install and I fail to find anything relevant. that way I found that missing fstab in that previous report.
<Mirv> davmor2: no, and since Click creates a fresh chroot it does not care what's on the host system
<Mirv> oh well yes, I do occasionally have Qt PPA:s here and test them, but I also purge them afterwards
<pstolowski> popey, hey, any idea how can i test a potential fix for the problem of today scope update, without you actually publishing it?
<pstolowski> (i need any scope update to test it)
<popey> pstolowski: good question
<popey> pstolowski: maybe someone on the team has a scope of some kind that we can push to the store under a new test name?
<davmor2> popey: pstolowski: surely you can just install it locally?
<popey> that could work too, but does the problem trigger with pkcon?
<davmor2> popey: I'm assuming pkcon is doing the installing from the update
<popey> worth testing in both ways
<pstolowski> davmor2, popey that sounds like a good suggestion; isn't it 'click install --local...' that i need?
<popey> I tend to "pkcon install-local --allow-untrusted foo.click"
<pstolowski> ok
<davmor2> pstolowski: ^ what he said
<pstolowski> yeah, thanks
<pstolowski> popey, the fix goes only into vivid i presume?
<popey> well as I understand it there will be no more rtm-1409 / utopic based OTAs so vivid makes sense, but check with sil2100
<sil2100> Yeah
<pstolowski> sil2100, popey ack
<pstolowski> victorp, who can provide me with an updated version of today scope .click?
<victorp> cwayne or kylen
<pstolowski> ty
<ogra_> victorp, so whats our plan forward, do we hold back scope landings until after next OTA ?
<victorp> ogra_, landings to?
<ogra_> since the fix can only come from a OTA
<ogra_> scope landings to the store
<victorp> yes, at least for the agregators
<victorp> that are currently favourites
<ogra_> ok
<cwayne> pstolowski, whats up?
<victorp> we can still update them via OTA
<victorp> that seems to work fine
<ogra_> yeah
<ogra_> in general that shows a problem though ...
<ogra_> being stuck with store landings because we need an OTA for the underlying fix
<ogra_> i wonder if there is a way around
<davmor2> ogra_: include the fix in a store package but then that would get messy
<ogra_> davmor2, well, in this case we couldnt
<pstolowski> cwayne, sent you an email. bbiab
<ogra_> davmor2, a click cant ship system bits ... and the rootfs would even have to be writable to replace the broken parts
<ogra_> in snappy, where the system bits will be framewworks, this will be fixable via the store
<davmor2> ogra_: unless it is in core
<ogra_> well, core is small enough that it shouldnt affect us
<ogra_> but yeah
<popey> sil2100: moving back over here. i see pstolowski|lunch is going to talk to cwayne when he wakes.
<popey> sil2100: lets wait for that conversation to happen.
<cwayne> sil2100, i've been here :) got him a click
<cwayne> oops popey ^
<popey> there we go :)
<popey> thanks cwayne (sorry for all the pings)
<cwayne> 7:30AM meetings ftw
<popey> :)
<cwayne> or ftl i guess :P
<cwayne> wake up and the whole worlds on fire
<sil2100> cwayne: ;p
<sil2100> Ok, let me wait for pstolowski|lunch to give some input and then we decide
<sil2100> I want to know how hard this will be to fix
<sil2100> Well, hm, actually, since this happens in stable there's no way to fix it proper I suppose
<sil2100> So I'm sure we'll just re-publish it in a few moments
<pstolowski> sil2100, i'm working on a fix for first part of the issue (https://bugs.launchpad.net/today-scope/+bug/1446499), should have a fix for vivid today
<ubot5> Ubuntu bug 1446499 in unity-scopes-shell (Ubuntu) "Updating scope from store removes it from favorites" [Undecided,In progress]
<davmor2> cwayne: I know giving you that petrol can for christmas was a bad idea
<davmor2> knew even
<pstolowski> sil2100, and there is a slight chance https://bugs.launchpad.net/ubuntu/+source/unity-scopes-shell/+bug/1446536 is not affecting vivid, but i haven't checked yet
<ubot5> Ubuntu bug 1446536 in unity-scopes-shell (Ubuntu) "Scope disappears from bottom edge on update" [Undecided,Confirmed]
<sil2100> pstolowski: I suppose all of those issues require changes on the scopes infra, right?
<sil2100> In this case I guess we can re-publish the scope to the store, nothing we can do short term to fix this
<pstolowski> sil2100, only unity shell plugin
<sil2100> pstolowski: then I think there's no use holding up the today scope
<sil2100> pmcgowan: ^ I'll ask popey to re-publish the today scope to the store
<pmcgowan> sil2100, I thought there is an issue replacing favorite scopes, or did I miss something
<sil2100> pmcgowan: there is an issue, but to fix it we would need to promote an image with a quick-fix which is still in progress, not sure if we want that
<pmcgowan> sil2100, we shouldn't put it back until that issue is fixed
<sil2100> pmcgowan: indeed
<sil2100> pmcgowan: ok, so we agree that we want to re-publish today scope then
<sil2100> (it's not even a real update)
<pmcgowan> sil2100, I was saying not to republish it
<sil2100> Oh?
<sil2100> Ah, ok, in this sense you mean
<sil2100> hm
<pmcgowan> my understanding is folks get an update and it "disappeares"
<popey> correct
<sil2100> From what I know it can be re-added through the favorites, right?
<popey> also correct, after a reboot
<sil2100> Ah, after a reboot
<pmcgowan> we can talk during rtm call, but I think we keep it back
<popey> without a reboot it's just gone, from a user perspective.
<sil2100> popey: so it's gone from the list without rebooting? Then indeed it's a bit more serious, I got the wrong impression from what victor was saying then
<sil2100> We could re-spin a new image once the fix is ready
<ogra_> sil2100, well, se my conversation with victorp above ... there was agreement to hold back all favorite scopes
<ogra_> until after next OTA
<sil2100> ACK
<ogra_> they need to come with custom tarball updates for the moment
<sil2100> Yeah, missed this conclusion it seems
<pstolowski> sil2100, but the fix needs to target vivid only, correct?
<sil2100> pstolowski: I suppose right now that's the plan, next OTA is planned to be vivid-based so no need to do a backport for RTM
<rvr> rsalveti: Silo 2 approved
<pstolowski> sil2100, great
<victorp> sil2100, once it is fixed please let me know
<sil2100> I don't think pushing the scopes to the store is enough high-priority for OTA-3.5
<sil2100> victorp: ACK
<ogra_> sil2100, no, we always have the custom tarball as fallback ...
<ogra_> and there it works
<sil2100> Indeed
<sil2100> Just as before
<sil2100> rsalveti: silo 002 is for touch specifically, right?
<sil2100> Ok, I suppose so, let me publish then
<ogra_> sil2100, mind if i kick a vivid image to check the space the hud frees up ?
<sil2100> ogra_: oh, you pushed the hud removal? :)
<sil2100> ogra_: sure, go on ahead
<ogra_> yeah
<ogra_> running
 * sil2100 is still a bit detatched from the world
<imgbot> === IMAGE 180 building (started: 20150421-13:25) ===
<ogra_> oh, even a round image number :)
<Mirv> thostr_: what's the status of line 13 scopes bg test silo, is it cancelled or do you want a test silo for it?
<Mirv> bfiller: what's the status of the syncevolution calendar fix landings, need silos?
<thostr_> Mirv: line 13 can be removed
<Mirv> thostr_: ok, thanks!
<bfiller> Mirv: already in silos, testing now
<Mirv> bfiller: oh.. so lines 27 and 33 are old ones for the same thing and can be removed?
 * Mirv the cleaner
<fginther> Saviq, the phone provisioning script relies on phablet-click-test-setup to install the test sources as directed by the click packages, but this doesn't work for some apps now. I've created an MP to address this: https://code.launchpad.net/~fginther/phablet-tools/skip-missing-click-tests/+merge/256931
<Saviq> fginther, cool, I wasn't sure whether this was a critical error, it looked dangerous (it removed all the tests it just downloaded?)
<fginther> Saviq, yeah, the error would cause the cleanup to be triggered before copying anything to the phone
<Saviq> fginther, right, so it only worked for me because I ran unity8 tests, not anything else
<Saviq> (I mean running the actual tests)
<fginther> Saviq, that makes sense, calculator app is what it currently making it bomb on devel-proposed images. I'll work on getting the patch upstream, but it might not before the release
<Saviq> fginther, 'stood
<sil2100> boiko: hm, is the request line 58 a critical fix requiring a OTA-3.5? I see the bug is only high
<Saviq> OTA-3.5??
<sil2100> boiko: was there a client's request to spin an rtm image for that?
<boiko> sil2100: so, bfiller asked me to get rtm silos and pmcgowan will evaluate the need for a hotfix
<sil2100> boiko: ok then
<boiko> sil2100: same thing for the rtm silo 003 I already have
<sil2100> Saviq: OTA-3.5, so a hotfix release ;)
<Saviq> sil2100, should we think about targeting the scope update bug for this too?
<sil2100> boiko: I thought so, but the severity of the bug got me confused
<sil2100> Saviq: maybe, although I'm not sure if there are real plans for the hotfix release
<Saviq> ok ;)
<sil2100> I'll know more after the RTM status meeting later today
<Saviq> if there are, we should, if there are none, we shouldn't :)
<oSoMoN> rvr, Iâve seen that youâre testing silo 7, thanks! I just added a corresponding manual test to https://wiki.ubuntu.com/Process/Merges/TestPlan/webbrowser-app
<bfiller> Mirv: silo 27 (ubuntu) and silo 5 (rtm) are the silos we are testing
<oSoMoN> rvr, note that most of the functionality is unit-tested already
<rvr> oSoMoN: Yeah, I'll begin soon, just had lunch
<bfiller> Mirv: for sycnevo
<bfiller> Mirv: not sure what the other lines are
<rvr> oSoMoN: Ack
<Mirv> bfiller: yes, those are lines 54/55, you have also line 27 "Fix for lp:1438662 - Calendar sync not working" for vivid and line 33 for syncing to rtm :) I'll remove those
<bfiller> Mirv: ack, thanks
<Mirv> sil2100: I've gone through the spreadsheet now again, finding many "already landed" and such, and now hitting the archive button
<sil2100> Mirv: thanks for the clean up! :)
<dbarth> o/ line 44 for an oxide packages copy
<dbarth> as a binary copy please, to minimize the build time and land in time for the image
<boiko> sil2100: can you please free vivid silo 004? we are done testing already, I will remove the row from the spreadsheet
<boiko> sil2100: actually quick question: can I just remove the row from the spreadsheet, or should I just clear its contents?
<sil2100> boiko: hey!
<sil2100> boiko: let me take care of that - we need to remove the silo as well :)
<boiko> sil2100: ok, thanks, it's silo 004 and row 20
<boiko> sil2100: maybe you can reuse that silo for line 45? ;)
<sil2100> boiko: ;)
<sil2100> boiko: assigning those in a moment, had to finish up a meeting
<boiko> sil2100: no hurry, take your time
<imgbot> === IMAGE 180 DONE (finished: 20150421-14:40) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/180.changes ===
<sil2100> dbarth: regarding the oxide request - I suppose this is supposed to land to the main vivid archive, right?
<rsalveti> ogra_: ^
<rsalveti> nice
<rsalveti> just hope that removing libdbusmenu-qt5 doesn't break anything
<rsalveti> :-)
<sil2100> rsalveti: it doesn't have any touch rdeps, so I think we're safe ;)
<dbarth> sil2100: hmm, considering the final freeze, i would land in the overlay ppa
<ogra_> yeah if it breaks something it needs a dep somewhere
<dbarth> sil2100: it will be available in the security updates anyway
<rsalveti> but should be good
<rsalveti> ogra_: how much did we save with such changes?
<ogra_> down to 462M from 486M for the cdimage tarball :)
<ogra_> i havent summed up the unpacked size ... but likely around 40-50M
<sil2100> dbarth: so it will be released to vivid later after final-freeze then?
<dbarth> yes, as an official security update
<dbarth> sil2100: chris is copying 1.6.4 there as well anyway
<sil2100> Ok then
<sil2100> Oh, actually I thought the next security update will have 1.7
<pmcgowan> dbarth, sil2100 if it lands in security pocket we pick it up from there
<pmcgowan> and wouldnt need it in the ppa
<sil2100> Right, that will be after final-freeze though
<sil2100> dbarth: do you need to have it ASAP?
<sil2100> That's why I didn't assign a silo yet, need to clear out all the doubts
<sil2100> We have plenty of free vivid silos, but oxide is very storage exhaustive
<pmcgowan> sil2100, we do need it asap yes
<pmcgowan> we need it last week :)
<sil2100> hah, you don't like the crashing T&C ;) ?
<pmcgowan> oh right thats still in there
<sil2100> I guess the earlier it's on our images the better, more dogfooding time - although it's faring pretty well on 14.09
<cjwatson> storage> I'm tempted to set the size of all ci-train-ppa-service landing-* archives to 20480 across the board
<cjwatson> They're a bit of a random mix right now
<dbarth> sil2100: yes, please
<bfiller> sil2100: mind reconfiguring ubuntu silo 10? I added another project to the list of MR's
<cjwatson> There are two in excess of that, but neither is using all that space right now, and I suspect that they're only set that large because of the lack of garbage collection we had a while back
<sil2100> bfiller: done
<bfiller> sil2100: thanks
<pstolowski> sil2100, can i have a silo for row #45?
<sil2100> pstolowski: on it :)
<pstolowski> awesome, thanks :)
<rvr> oSoMoN: Approving silo 7
<oSoMoN> rvr, awesome, thanks!
<sil2100> dbarth: oxide-qt copied to the oxide silo ;)
<sil2100> jibel, robru, davmor2, popey, rvr, ogra_: do you want to discuss anything on the landing meeting today?
<jibel> sil2100, no
<ogra_> nope, i think the disaster recovery this morning was fine :)
<ogra_> nothing to discuss
<rvr> sil2100: Is the last episode of Games of Thrones a valid topic? ;)
<sil2100> rvr: oh shit
<davmor2> sil2100: it's okay you can say you hate us we won't take it personally :P
<sil2100> davmor2: ;)
* 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: n/a
<sil2100> davmor2: I'm just a good listener, and robru mentioned multiple times he wants to have time to wake up properly in the mornings
<sil2100> ;)
<davmor2> sil2100: pfffff
 * ogra_ hands dbarth bucket and mop for silo 22
<dbarth> oops
<ogra_> :)
<dbarth> yes, let me check
<kalikiana> ping cihelp, the license check in Jenkins is rejecting https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/generatedApDocs/+merge/256913 the files in question are MIT licensed generated files; adding _build to the excluded folders as can be seen in the branch would resolve it, I don't know where that script is maintained, though
<oSoMoN> trainguards: silo 7 is landing, and Iâm seeing that webbrowser-app is in the proposed pocket. I thought it would go directly into the overlay PPA, whatâs up with that?
<sil2100> oSoMoN: let me take a look
<sil2100> oSoMoN: ouch, ok, someone set the column name but didn't reconfigure
<sil2100> Ok, let me reconfigure and re-publish - thanks for noticing!
<oSoMoN> sil2100, I did change the destination PPA column after reading slangasekâs announcement, sorry I didnât know it required a reconfigure
<sil2100> oSoMoN: no worries, I should have double checked when publishing, I usually do but it was probably published in a hurry ;p
<oSoMoN> sil2100, alright. IÂ guess the package can be easily rejected from proposed so as to not affect the archive, right?
<slangasek> sil2100: can you copy the package from -proposed back to the overlay ppa?  then I can delete it from -proposed
<sil2100> slangasek: sure thing, on it now
<sil2100> slangasek: ok, package copied (should be in the overlay PPA)
 * sil2100 switches context back to UITK
<slangasek> sil2100, oSoMoN: ok.  In thinking about it, I realize that removing the package means it won't be re-copiable back to w when it opens without a new upload; so I think I'm going to leave the package in -proposed for now, which is valid
<sil2100> slangasek: makes sense, indeed
<oSoMoN> slangasek, sil2100: thanks
<oSoMoN> sil2100, can I merge and clean the silo now?
<sil2100> oSoMoN: yes :)
<sil2100> Just use the force flag if anything
<oSoMoN> ok
<robru> sil2100: don't forget the dashboard is authoritative; check for 'stable-phone-overlay' there before clicking publish
<sil2100> robru: right'o! Forgot about that, was actually checking in the JSON configs
<robru> sil2100: yeah, sorry I should have added that info to the dashboard sooner. Didn't think of it until yesterday morning.
<sil2100> robru: I read that you added that, but somehow with all the stuff happening it just jumped out of my head
<plars> kalikiana: Looking...
<rvr> dbarth: Approving silo 6
<sil2100> o/
<robru> mardy: dbarth: https://ci-train.ubuntu.com/job/ubuntu-landing-006-2-publish/88/console need some MPs approved
<robru> sil2100: good evening!
<bzoltan_> sil2100:  I think you need to fix the version of the gles
<sil2100> bzoltan_: eek, will do that, maybe some typo
<sil2100> In one moment, OTP now
<sil2100> Ok, on it now
<sil2100> bzoltan_: hmmm, the version looks fine to me, I can see it in the PPA
<sil2100> Did I do something wrong?
<sil2100> bzoltan_: argh, and I see another problem ;/
<sil2100> bzoltan_: why do I see other changes in the PPA's changelog?
<sil2100> Isn't trunk = what's in the archive?
<sil2100> Ah!
<sil2100> Ok, it's all ok
<sil2100> It's in the overlay PPA and the diff is made against the archive
<sil2100> nvm
<sil2100> bzoltan_: could you check the PPA and merge and tell me what I'm doing wrong? I see that CI Train builds the package correctly, so the versionin needs to be ok, but nothing gets uploaded to the PPA
<robru> sil2100: ask an archive admin to check why the upload was rejected. I don't see any obvious reason for it (eg, that version doesn't already exist in the ppa as far as I can see...)
<sil2100> robru: I poked cjwatson, but maybe I could poke slangasek as well
<robru> sure
<sil2100> slangasek: hey, you have a moment?
<cjwatson> slangasek: I handled sil2100's request on #ubuntu-touch
<cjwatson> sil2100: slangasek doesn't have LP log access AFAIK
<sil2100> slangasek: ...unping
<sil2100> cjwatson: thanks :)
<sil2100> cjwatson: I think I'll try to fetch the source and re-upload myself with debuild -S -sa to make sure we upload the tarball
<cjwatson> sure
<sil2100> I have no idea why it didn't include it in the upload
<kalikiana> plars: any idea at all?
<plars> kalikiana: we were discussing how to handle it, fginther has an MP for it in flight
<sil2100> ogra_: btw. smoketesting is busted for 180...
<ogra_> sigh
<ogra_> sil2100, thats your falt though ...
<ogra_> *fault
<ogra_> package ubuntu-ui-toolkit, version 1.2.1485+15.04.20150417.1-0ubuntu1 not found in https://api.launchpad.net/devel/ubuntu/vivid
<sil2100> Oh uh!
<ogra_> i guess you want to re-roll the immage after that landed :)
<ogra_> to have the versions match
<sil2100> ogra_: not particulary my fault, more like 'our fault' and pointing at the LT ;p
<sil2100> No no, it's because it's in the overlay PPA
<ogra_> ah
<sil2100> A re-spin won't fix it
<ogra_> right
 * sil2100 sighs ;)
<sil2100> Actually, damn, I might need to change my commitlog generation scripts too ;/
<ogra_> robru, will the citrain script take the overlay ppa into acocunt somehow ...
<ogra_> (and does it need to ?)
<dbarth> robru: on it
<ogra_> or do we just assume everything yu need for testin is actually in the image or silo
<robru> dbarth: thanks
<robru> ogra_: it shouldn't need to, as those packages get rolled into image builds
<ogra_> robru, right, but if the image is a day behind and the silo got built against the overlay PPA your silo packages might be uninstallable
<ogra_> until the image has the overlay packages available
<ogra_> thats surely only a corner case though
<robru> ogra_: the silo ppas now depend on the overlay ppa so it should take care of itself shouldn't it?
<ogra_> not with the citrain script where we /dev/null all sources.lis entries except the silo
<ogra_> the overlay package would not be available ... but the silo has a dep against it
<ogra_> as i said, likely just a corner case ... but it could happen
<robru> ogra_: i don't really understand how ski dependencies work
 * sil2100 really needs to go AFK now
<sil2100> o/
<sil2100> Be back later
<robru> ogra_: "silo dependencies". Anyway if it happens you'll just have to install the overlay ppa and dist upgrade
<ogra_> robru, well, the image has foo-123 ... i upload foo-124 to the overlay ppa ... now you push package bar to a silo that depends on foo ... and gets a binary dep via shlibdeps against foo-124 ...
<ogra_> bar will be uninstallable in the image unless i enable the overlay ppa or until the foo package hits the image
<ogra_> right, if thats our answer that is fine
<ogra_> (it might taint your image and the test might be moot though )
<robru> ogra_: well, I've seen in some cases already that necessary deps were copied from distro into a silo ppa, specifically because citrain tool doesn't add distro updates on purpose. So if such a case arose, people should just copy the dep from the overlay ppa back to the silo.
<ogra_> cool, thats fine then
<robru> ogra_: i think it's a rare case. If it happens a lot we can consider changing the tool, but i believe qa specifically requested the tool only install silo contents, and nothing else.
<ogra_> yeah
<robru> kalikiana: bzoltan_ ping? Need merges approved https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/48/console
<robru> dbarth: uh, so empathy was in your silo and that got copied into the overlay ppa, was that on purpose? should we delete that?
<robru> dbarth: I mean it was in your silo PPA but not in your silo config, seems like a mistake.
<robru> Laney: ^ you uploaded this empathy into silo 6 PPA, did you intend for that to wind up in the overlay PPA?
<robru> Laney: I guess if you wanted that uploaded to distro you'll have to copy it from the overlay ppa yourself. https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay
<bzoltan_> robru:  do you still need my approval? As I see the MRs are landing
<robru> bzoltan_: not sure where you see that? the link says "ERROR" and https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/generatedApDocs/+merge/256970 is still unapproved
<robru> (I approved one because I could, I don't have permission on the other)
<bzoltan_> robru:  ohh.. the main. I approved
<bzoltan_> robru:  yes, the gles you could, thanks for that
<robru> bzoltan_: great, thanks
<dbarth> robru: it does seem like a mistake indeed
<dbarth> robru: i wonder why it got pulled in, except that for qa purposes you needed to make sure that empathy was not listed in teh FB/MSN account settings
<om26er> plars, Hi!
<om26er> plars, the dashboard is showing multiple runs as 'Running' wonder whats causing that ?
<plars> om26er: it looks like phablet-click-test-setup blew up quite badly
<plars> it seems to be causing us all sorts of grief lately
<om26er> plars, can you report bugs for phablet-click-test-setup, I can look into fixing those ?
<plars> om26er: fginther has a patch for the one we hit last week, not sure what this one is yet
<fginther> om26er, plars, that's an error I had not seen before
<plars> fginther: yeah, it seems to have started in the latest image
<om26er> plars, can you share the stacktrace ?
<plars> om26er: https://jenkins.qa.ubuntu.com/job/vivid-touch-mako-smoke-daily/544/console
<plars> package ubuntu-ui-toolkit, version 1.2.1485+15.04.20150417.1-0ubuntu1 not found in https://api.launchpad.net/devel/ubuntu/vivid
<plars> ti seems something change in uitk?
<om26er> there is a new uitk uploaded today, yes.
<robru> plars: om26er: the new one from today is version ...0421, and it's sitting in the UNAPPROVED queue (eg not in the archive at all). shouldn't have anything to do with this ...0417.1 issue you're seeing
<robru> indeed, ...0417.1 doesn't exist: https://launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+publishinghistory
<plars> robru: om26er: this ought to be simple to reproduce locally by doing a fresh install and running phablet-click-test-setup
<robru> plars: fresh install of what? you mean the latest image on a krillin?
<plars> robru: yes, or even on mako
<robru> plars: is it picking up 0417.1 from a ppa or something?
<fginther> plars, robru, om26er, indeed I can reproduce it locally.  The problem appears to be that 1.2.1485+15.04.20150417.1-0ubuntu1 is coming from a PPA and not the archvie
<fginther> phablet-click-test-setup does not know how to extract sources from PPAs
<robru> heh
<plars> robru: right
<plars> so I guess this is the overlay ppa because vivid is frozen
<robru> oh duh, 0417.1 is in the overlay ppa
<robru> plars: yeah
<robru> fginther: plars: so I guess p-c-t-s needs to grow awareness of the overlay ppa
<plars> om26er: ^
<fginther> robru, yep... trying to think of how this might be done
<robru> fginther: catch that exception and fallback to downloading the package from the ppa?
<fginther> robru, ideally it could just find the PPA from looking at the attached phone
<robru> fginther: but the phone doesn't have the ppa enabled; the packages from the ppa are rolled right into the images.
<robru> as far as I know
<fginther> robru, my mako does indicate that uitk came from a PPA, is this correct?
<fginther> $ apt-cache policy qtdeclarative5-ubuntu-ui-toolkit-plugin
<fginther> qtdeclarative5-ubuntu-ui-toolkit-plugin:
<fginther>   Installed: 1.2.1485+15.04.20150417.1-0ubuntu1
<fginther>   Candidate: 1.2.1485+15.04.20150417.1-0ubuntu1
<fginther>   Version table:
<fginther>  *** 1.2.1485+15.04.20150417.1-0ubuntu1 0
<fginther>         500 http://ppa.launchpad.net/ci-train-ppa-service/stable-phone-overlay/ubuntu/ vivid/main armhf Packages
<robru> fginther: oh, ok, great. I wasn't aware that it worked that way. looks right
<fginther> robru, plars, I can find the uitk source urls with the follow two queries: https://api.launchpad.net/devel/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay?ws.op=getPublishedSources&source_name=ubuntu-ui-toolkit&source_package_version=1.2.1485+15.04.20150417.1-0ubuntu1
<fginther> then https://api.launchpad.net/devel/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/4955514?ws.op=sourceFileUrls
<rvr> boiko: ping
<fginther> I'm trying to hack in some changes, but I'll have to jump offline for a few hours soon
<rvr> boiko: You sent another silo to ubuntu-rtm
<fginther> plars, om26er, robru, this appears to work (it's a huge hack)
<fginther> https://code.launchpad.net/~fginther/phablet-tools/skip-missing-click-tests/+merge/256931
 * fginther -> away for a while
<om26er> plars, can you please deploy that ?
 * om26er >> out
#ubuntu-ci-eng 2015-04-22
<imgbot> === IMAGE 181 building (started: 20150422-02:10) ===
<fginther> plars, robru, FYI, I patched phablet-click-test-setup and retriggered the tests for image 180
<plars> fginther: thanks for looking at that. I had to step away for a while but I'm back now. Anything else needed right now?
<fginther> plars, I don't think anything else is needed right now. I saw that your other change landed, so hopefully this will be a full run
<plars> fginther: indeed
<fginther> plars, a much better fix is needed for p-c-t-s, but it can wait until at least tomorrow :-)
<fginther> plars, so far so good: http://q-jenkins.ubuntu-ci:8080/job/vivid-touch-mako-smoke-daily/545/console
<fginther> made it past the click test sources install
<plars> Awesome
<imgbot> === IMAGE 181 DONE (finished: 20150422-03:25) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/181.changes ===
<Mirv> ToyKeeper: happen to be around? can you confirm that om26er passed silo 015 but just forgot to flip the switch in the spreadsheet? the trello is authorative, isn't it?
<ToyKeeper> Mirv: If it's passed on trello, it should be okay to flip the switch in the spreadsheet.
<Mirv> ToyKeeper: indeed, I just wanted to hear it from someone in the team. thanks!
<ToyKeeper> Mirv: That's qtubuntu-camera, yes?
<Mirv> ToyKeeper: no, qtdeclarative
<ToyKeeper> Mirv: Er, sorry, wrong silo-015 card.  :)
<Mirv> "Approving it now." ends om26er's last trello comment
<Mirv> :)
<ToyKeeper> Mirv: In any case, it looks like he just didn't flip the switch.
<Mirv> thanks for confirming
<Mirv> robru: thanks, packaging diffs seem all good now!
<robru> Mirv: you're welcome!
<sil2100> popey, ogra_, Mirv: anything to discuss during the landing meeting?
<ogra_> nothing specifically from me
<sil2100> Mirv: actually I wanted to poke you regarding the unity8 hang silo, but I can do it here too
<sil2100> Mirv: do you think it can be passed to QA sign-off now that it's planned to be landing in the overlay PPA?
<sil2100> Mirv: this is a blocker for the nearest release
<Mirv> sil2100: I discussed it yesterday, and albert was of the opinion that we can't land it until all the upstream branches have been merged upstream. and there's sense in that, not only to assure quality (even though I don't see any problems in my testing) but also because even though we have the PPA it's supposed to be copied to w as is - and currently, the patches make some KDE legacy apps not start
<Mirv> upstream has promised to fix the kuniqueapplication problem. but so far the big patch set is still not merged in upstream qt 5.5.
<sil2100> Mirv: do we have any other means of fixing the bug in the meantime?
<Mirv> tsdgeos: ^ can give an opinion about other means of fixing the QDbus problem, although I guess they have been thought (and tried) before already.
<popey> sil2100: no
<sil2100> jibel: hey, you have anything urgent to discuss during the landing meeting?
<jibel> sil2100, just which rtm silo do we land?
<jibel> sil2100, 3, 4, 6 and 7 are ready for QA
<sil2100> jibel: I think pmcgowan wasn't clear on what he wants and when we want it
<Laney> robru: It needs to get into vivid via SRU
<davmor3> sil2100, jibel: My net went down last night I'm using my mifi for now but it means my irc and emails are dead probably best to get me on telegram for anything important I'm going to try the hangout via mifi and see what restrictions I need to put in place
<Laney> dbarth: do you know about this?
<sil2100> So I would defer until he's around again
<dbarth> Laney: i just now the silo went into the overlay ppa
<dbarth> Laney: you saying i should do the sru paperwork now?
<Laney> dbarth: Needs to go into vivid via SRU
<sil2100> davmor3: I was thinking of cancelling today's landing meeting so no worries ;)
<Laney> dbarth: So the bug will need the paperwork, yes
<Laney> Let me know if you need help uploading it
<dbarth> Laney: what's the timing btw?
<Laney> for?
<dbarth> the sru process
<davmor3> sil2100:no really cancel mongering the morning meetings too damn you
<dbarth> ie, 0-day srus (not the case i think) vs 1st batch
<Laney> the SRU team can accept it whenever
<dbarth> ah ok
<sil2100> davmor3: ;)
<Laney> I don't know what they'll choose but it doesn't matter either way for us IMHO
<sil2100> jibel: so until we have a clear direction from pmcgowan I would say let's not sign off any RTM silos
<Laney> well, I think FB chat XMPP is closing on April 30th so it should be in -updates by then
<jibel> sil2100, okay
<sil2100> Pat anyway wanted us to concentrate all strength on vivid and you-know-what
<Laney> dbarth: did anyone care for precise/trusty/utopic?
<dbarth> Laney: not really yet
<dbarth> Laney: but that could be limited to just the MSN/FB bugfix though
<Laney> yes
<dbarth> ie not the whole silo
<Laney> this is the bit that I care about ;-)
<Laney> well, that I care about most
<sil2100> davmor3: today in return we'll have the evening meeting ;)
<Mirv> oh, ok no meeting
<davmor3> Yay I might be online proper by then, but I still want to try the mifi in a hangout, so jibel don't cancel the morning qa meeting it's an import experiment :D
<Mirv> sil2100: hey, you were on the UITK update yesterday. it seems robru landed it to vivid (and it's in -proposed), was that intentional or should it be republished to the overlay PPA?
<davmor3> jibel:^
<davmor3> is that the t=landing you were on about?
<davmor3> - t=
<Mirv> ..or should release team allow it to go in. I didn't catch the whole topic but I undestood it might be it should be in vivid proper?
<davmor3> Mirv: jibel was just on about it in another channel I think it is deliberate, we are waiting on it landing for real for the iso to be respun
<Mirv> ok
<davmor3> Mirv:it is a big assumption on my part but being as UITK were mentioned twice in such a small span of time I can only assume it is the same one :)
<jibel> davmor3, Mirv it is blocked in proposed currently http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<Mirv> davmor3: yes it most probably is
<jibel> pitti is looking at the failure
<Mirv> ok, thanks for the update
<sil2100> Mirv: it's intentional
<Mirv> good
<tsdgeos> sil2100: Mirv: there is no way to "fix it" other than this, you can workaround it my not using qdbus :D
<mandel> Mirv, I have had no code reviews, but is due to the fact that it needs to be tested on the phone first (talking about line 52)
<Mirv> mandel: ok
<Mirv> assigning a silo
<mandel> Mirv, is a huge improvement for location, and you know, you need to walk around :-/
<mandel> Mirv, sweet! (I know, I sound like a stoner \o/ )
<Mirv> mandel: yeah location improvements are very welcome :)
<sil2100> I like the sound of that
<sil2100> ;)
<sil2100> hmmm
<sil2100> bzoltan_: I'll have to release a no-change rebuild of UITK to trunk in a moment, sorry for messing with your trunk ;)
<sil2100> bzoltan_: there's some chaos regarding vivid now
<bzoltan_> sil2100:  just tell me if I need my help
<bzoltan_> sil2100:  I mean :) if _you_ need my help
<sil2100> bzoltan_: sure, again sorry for that ;)
<davmor3> bzoltan_: man talking about helping yourself in the 3rd person isn't that one of the signs of insanity ;)
<bzoltan_> davmor3: helping  myself in my native language has an other meaning :D
<oSoMoN> trainguards: can I have a silo for line 53, please?
<sil2100> oSoMoN: looking
<sil2100> oSoMoN: assigning :)
<oSoMoN> thanks!
 * sil2100 off to lunch
<john-mcaleely> davmor2, so, do vivid krillin device tarballs need signoff at the moment?
<john-mcaleely> same Q to jibel , I guess ^
<davmor2> john-mcaleely: yes as vivid is the next target for ota
<john-mcaleely> cool davmor2 one is incoming then :-)
<pmcgowan> j
<davmor2> pmcgowan: is this some new form of alphabet game?
<pmcgowan> jibel, sil2100 if QA has bandwidth we can test rtm silos to be ready for a hotfix next week
<pmcgowan> davmor2, no typing in wrong window it seems
<cwayne> davmor2, sil2100: so I got a +1 from davmor2 to push a vivid tar awhile ago, but I'd missed the message.  the tarball hasnt been built since then, am I ok to push it, or should I build a new one and have it go through qa again?
<pmcgowan> jibel, sil2100 but anything for vivid has precedence over rtm silos
<davmor2> cwayne: build a new one there might be apps and stuff that need updates and put it through the process :)
<cwayne> davmor2, okie dokes
<cwayne> davmor2, building, will let you guys know when ready
<john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20150422-a57ecca.tar.xz
<john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20150422-a57ecca.changes
<john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-testresults-20150422-a57ecca.ods
<john-mcaleely> sil2100, ^ new device tarball for krillin vivid
<Mirv> sil2100: jibel: I flipped the switch based on the most recent discussion. also did some retesting with #181 while the AP suite was run against #175 during the weekend.
<Mirv> ^ regarding that 018 fix
<fginther> om26er, FYI touch smoke testing for 181 completed
<om26er> fginther, \o/
<om26er> fginther, the failure rate looks alarming
<fginther> om26er, looks like 180 still thinks it's running because the jobs exceeded the 5 hour timeout. I'll see about scaling out some more to fix that problem
<fginther> om26er, indeed, I've seen it look better
<ChrisTownsend> cihelp: Hi!  We are getting intermittent "out of space" failures on our Unity 7 ci runs.  For example: https://jenkins.qa.ubuntu.com/job/unity-vivid-amd64-ci/86/console and https://jenkins.qa.ubuntu.com/job/unity-vivid-i386-ci/86/console
<boiko> rvr: hi, regarding the rtm silo, it is another fix that bfiller and pmcgowan want to evaluate to maybe be released as a hotfix
<rvr> boiko: Right, only hotfixes will be allowed
<fginther> ChrisTownsend, ah, someone will have a look at this
<boiko> rvr: yep, that's why I proposed the fix and got the silo
<ChrisTownsend> fginther: Ok, thanks
<pmcgowan> rvr, if there is anything for vivid that gets priority this week
<rvr> pmcgowan: Ack, thanks. jibel also updated me with the upcoming priorities.
<sil2100> rvr, davmor2, jibel: new device tarball ready and in the tarballs sheet
<ogra_> we have a taballs sheet ?
<ogra_> nice :)
<davmor2> sil2100: there should be a new custom from cwayne soon too
<sil2100> ogra_: yeah, not fully functional though
<davmor2> sil2100: it would be much easier if we had say a database and a web form maybe /me runs and hides from the explosion that is sil2100 head with the rage overload :D
<sil2100> davmor2: all in the works ;)
<davmor2> sil2100: the spreadsheet is dead long live the spreadsheet?
<sil2100> davmor2: robru's working on a replacement and so far things are moving forward nicely from what I know
 * davmor2 hugs robru 
<ogra_> sil2100, are we there yet ?
<Saviq> trainguards, silo please â :)
<sil2100> ogra_: robru's working on it from scratch, so there's still work to be done
<sil2100> But I trust in robru's abilities
<sil2100> ;)
<ogra_> :)
<sil2100> Saviq: on it
<sil2100> (more on the evening landing meeting)
<sil2100> Saviq: oh! I like the sound of that request
<Saviq> :)
<sil2100> This would mean one less blocker on our list, thanks!
<rvr> Saviq: Approving silo 17
<sil2100> \o/
<sil2100> Nice, this would unblock silo 25 then
<cwayne> davmor2, sil2100 added custom tar for vivid to spreadsheet
<sil2100> cwayne: thanks! Let me approve it for QA sign-off
<Saviq> rvr, awesome, thanks
<sil2100> davmor2, jibel, rvr: approved the custom tarball request
<Mirv> Saviq: approves https://code.launchpad.net/~saviq/unity8/fix-flake8/+merge/256510 + https://code.launchpad.net/~saviq/unity8/fix-mock-indicator/+merge/256958
<Saviq> Mirv, done
<Saviq> sry
<Mirv> Saviq: no problem. regarding packaging, I fear you'd need to add  Replaces: unity8-autopilot (<< 8.02+15.04.20150421.1-0ubuntu1) to the unity8-fake-env's fields, otherwise desktop users having both installed would have a upgrade error when the new files in unity8-fake-env conflict with the old files in unity8-autopilot
<Saviq> Mirv, oh...
<Saviq> Mirv, think you could upload with a bumped -ubuntu or shall I fix/rebuild?
<alex-abreu> trainguards can you publish silo 23
<sil2100> alex-abreu: on it
<sil2100> alex-abreu: needs a rebuild...
<sil2100> alex-abreu: unbuilt commits in https://code.launchpad.net/~abreu-alexandre/unity-webapps-qml/improve-embedded-ui-params-passing/+merge/250329
<Mirv> Saviq: please fix + rebuild normally in the MP
<Saviq> ok
<fginther> ChrisTownsend, The 'no space left on device' issue has been resolved for the moment. Will still need to address it with a longer term solution, but any unity7 builds in flight should be ok to proceed now
<ChrisTownsend> fginther: Great, thanks so much!
<sil2100> pstolowski: hmm, assigning silo for 55, but you mention it's an alternative fix to silo 20?
<sil2100> pstolowski: so only one of them will land, right?
<pstolowski> sil2100, hey, my row #55 is targeted at devel cause i've no other way of building and testing it other than a silo. isn't it going to be an issue? when i confirm it works, it will be merged into devel and then MP'ed again for landing in trunk
<pstolowski> sil2100, correct, we've disscussed it today. the best fix would be lowest in the stack, which is scopes api. only one fix will land eventually
<sil2100> pstolowski: ok, so there will be a real landing with MPs to trunk after those approaches get tested, right?
<pstolowski> sil2100, yes
<sil2100> Ok, let me mention that in the comment fields
<om26er> fginther, Hey! how did the dashboard fix ? did you deploy your change for phablet-tools ?
<Saviq> Mirv, if you're still around - it just published https://launchpadlibrarian.net/204011489/unity8_8.02%2B15.04.20150421.1-0ubuntu1_8.02%2B15.04.20150422-0ubuntu1.diff.gz
<Saviq> only the PPA decided it's going to be a good idea to show the complete changelog
<fginther> om26er, yeah. I hacked the local version of phablet-click-test-setup until there is more time for a proper fix
<om26er> fginther, will code in your MR do it for me as well ?
<om26er> I am seeing the same issue locally as well
<fginther> om26er, yes, it should work (it worked for me locally as well)
<Mirv> Saviq: not really around but checking anyway :)
<om26er> fginther, great, seems to have worked for me.
<Mirv> ricmm_: unapproved https://code.launchpad.net/~ricmm/qtubuntu-media/abi-session-reattach/+merge/255860
<ricmm_> jhodapp: ^
<Saviq> Mirv, thanks
<ricmm_> alesage: ping, did you do exploratory testing against media-hub and all media stuff?
<alesage> ricmm_ yes I ran the test plan
<alesage> if we're being specific :)
<ricmm_> I'm not being specific, I'm asking about non-specific exploratory testing ;)
<ricmm_> although to be fair, one of the test plan points if exploration
<jhodapp> ricmm_, approved
<alesage> ricmm_ fairly spoken
<ricmm_> so you did pressure it with heavy exploratory
<alesage> ricmm_, I didn't find anything that wasn't explained; a file format unsupported, e.g.
<sil2100> Mirv: you go EOD now!
<Mirv> sil2100: just a moment! :)
<sil2100> ...;p
<Saviq> Mirv, yeah, just after you publish my silo! :D
<alesage> if I tap at the end of a track I can unleash chaos ricmm_ but I've presented this before to jhodapp
<jhodapp> alesage, indeed you have
<Mirv> Saviq: indeed, now publishing, upgrade on desktop with both installed went fine
<sil2100> jibel, popey, davmor2, rvr, robru: let's have a quick evening meeting today to sync up on everything
<sil2100> ogra_: ^
<rvr> sil2100: Ack
<ogra_> sil2100, yeah ... curious about the OTA3.5 :=
<ogra_> :)
<popey> sil2100: okay
<Mirv> ricmm_: so ack on 028? (I just made sure it targets the overlay)
<sil2100> alex-abreu: so that rebuild that was needed - was that change something not impacting real code?
<sil2100> alex-abreu: asking to check if it needs a re-test or not
<alex-abreu> sil2100, yes it was fixing the tests that were flacky
<sil2100> dbarth: just to make sure - you testing the oxide-qt silo 16, right? Since the status is not right due to a CI Train error and  the packages are there
<sil2100> alex-abreu: ACK
<ricmm_> Mirv: I believe so
<ricmm_> jhodapp: ^^
<ricmm_> jhodapp: ack on the silo? to land in overlay
<Mirv> that will be the most acked silo ever
<jhodapp> ricmm_, one min, I am checking one last possible regression for Alan
<ricmm_> ok
<Mirv> ok
<Saviq> oh, robru, things get pushed to trunks on publication now, not on migration? that on purpose?
<Mirv> Saviq: overlay is very migrated right away
<sil2100> Saviq: there's no proposed-migration in the overlay PPA, it's basically a copy-package from silo to the destination
<dbarth> sil2100: oSoMoN was yes; i'm on 1.7.2 at the moment
<sil2100> dbarth: on 1.7.2? Not 1.6.2? :o
<Mirv> ^ so not yet
<oSoMoN> dbarth, 1.6.4 is good to go as far as Iâm concerned
<sil2100> *1.6.4 I meant
<Saviq> Mirv, d'oh
<sil2100> oSoMoN, dbarth: ok, I'm confused a bit - I know we essentially want 1.7.2 on the phone ASAP, but we only have a silo with 1.6.4 right now
<dbarth> oSoMoN, sil2100: i think we can release this one now
<sil2100> dbarth: by release you mean free up and clean?
<oSoMoN> sil2100, we want 1.6.4 first, then 1.7.2
<oSoMoN> sil2100, 1.7.2 is still being validated
<sil2100> oSoMoN, dbarth: ok, so silo 16 still makes sense then
<oSoMoN> yes
<sil2100> But it's ready for QA sign-off, right?
<sil2100> oSoMoN, dbarth: if it is, could you guys mark it as such in the spreadsheet?
<oSoMoN> dbarth, your landing, can you please mark it ready for QA validation?
<dbarth> yup, will do
<sil2100> Thanks guys :)
<sil2100> robru: do you have a good way of setting silo 16 state into a sane one? It's the oxide-qt encoding bug
<sil2100> robru: pong, meeting if anything
<davmor2> jibel: meeting
<jibel> davmor2, I won't attend
<davmor2> jibel: nw
<jhodapp> Mirv, ok silo 28 is ready
<jhodapp> ricmm_, ^
<Mirv> jhodapp: thanks
<jhodapp> thanks Mirv
<rsalveti> jhodapp: did we land the playlist support?
<rsalveti> and the session reconnect I guess
<jhodapp> rsalveti, yep
<jhodapp> we did
<rsalveti> alright :-)
<rsalveti> just hope it's not going to break anything
<rsalveti> lol
<jhodapp> it shouldn't
<jhodapp> :)
<jhodapp> QA went through it too
<rsalveti> not going to be concerned
<rsalveti> too many issues already
<kalikiana> plars: anything on the licensing issue?
<robru> sil2100: sorry, you have to edit config json by hand. I'll try to fix oxide diffs today
<kalikiana> fginther: or maybe you know, if plars isn't around. supposedly you were looking into the license check issue
<fginther> kalikiana, the license check has been updated, sorry I was only able to verify it a short time ago
<fginther> kalikiana, the latest results are on https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/generatedApDocs/+merge/256913
<sil2100> robru: thanks :)
<sil2100> robru: btw. how's the replacement going? What technology you settled on finally?
<sil2100> robru: regarding the template - I inspired myself on some existing webpage that I don't know anymore, so you'll just have to rip-out it from the tracker if anything
<sil2100> robru: it was glued up quickly so don't expect anything fancy ;)
<sil2100> I even use bootstrap there out of lazyness
<kalikiana> fginther: super! thanks a lot!
<sil2100> rvr: ^ as I said, QA-sign offs are pilling up ;)
<rvr> sil2100: Close the gates! :D
<robru> sil2100: heh, ok thanks. for the replacement, I'm using flask. as a quick prototype it's using json blob files but the plan is to transition to a real db once I have more of the pieces in place. for now it's going well but there's a lot of pieces missing still
<kgunn> trainguards hey could i get a vivid silo for line 6 of the sheet ? this is the old MWC demo silo...getting a request to reconstitute
<rvr> robru: sil2100: I have a new card for silo 28, was that a mistake? In the dashboard, it's empty.
<sil2100> robru: great to hear, doing things in iterations sounds like a sane plan
<sil2100> rvr: hmmm
<sil2100> rvr: that's a strange thing, the silo was there before the meeting
<rvr> sil2100: alesage approved a silo with the same description an hour ago.
<sil2100> rvr: ah!
<sil2100> rvr: yeah, so I think the trello card appeared since there was a moment when it was switched back to 'needs QA'
<sil2100> rvr: while it actually was QA granted
<sil2100> rvr: I would remove that card
<robru> sil2100: 28 was freed here: https://ci-train.ubuntu.com/job/check-publication-migration/111266/console
<robru> kgunn: line 6 is in silo 0.... ?
<kgunn> robru: huh...thanks....i thot i gave it up
<kgunn> i feel sheepish
<robru> kgunn: hehe, no worries. let me know if it needs a reconfig or whatever. IIRC you had given up a different one.
<kgunn> thanks robru, i did update one the projects already there, so i do need a reconfig.....hadn't silo'd in a while,  is there no link to reconfig in the sheet ?
<kgunn> ah-ha...new instructions
 * kgunn reads
<robru> kgunn: yeah the spreadsheet imploded a bit and we had to try something different to reduce the load. the old reconfig link was really resource-heavy in the way it generated URLs.
<kgunn> i see
 * sil2100 needs to jump out for a few hours, be back later
<sil2100> o/
<robru> bfiller: silo 15 doesn't need qa?
<bfiller> robru: I don't think so because it's just the deb which isnt' used and it's autopilot test fixes only
<bfiller> not going to upload any click to the store
<robru> bfiller: ah ok
<robru> bfiller: just need you to approve the MP https://code.launchpad.net/~artmello/gallery-app/gallery-app-fix_autopilot_tests/+merge/256159
<bfiller> robru: done, sorry about that
<robru> bfiller: tahnks
<kenvandine> bfiller, i have some settings branches i'd like to land, they only fix tests so will be quick to land
<kenvandine> bfiller, mind if i slide in front of silo 10?  it'll mean a rebuild after mine is published
<bfiller> kenvandine: fine with me
<kenvandine> since that silo will still need to go through qa verification, etc
<bfiller> kenvandine: yup, I'm testing that now
<kenvandine> ok, so you don't mind a rebuild in a couple hours?
<kenvandine> it won't affect your testing
<bfiller> kenvandine: that's fine
<kenvandine> cool
<kenvandine> robru, ^^ why did settings go to proposed instead of the overlay ppa?
<kenvandine> i thought the silos were configured to go to the overlay ppa automatically
<robru> kenvandine: it's automatic if you let me do it.
<kenvandine> oh... sorry :/
 * kenvandine sobs
<robru> kenvandine: I wrote an email with the specific steps necessary for landing team + core devs
<kenvandine> i saw something, thought it was only for silos created before the change
<kenvandine> sorry...
 * kenvandine gets it rejected
<robru> kenvandine: oh yeah, for new silos you need to set the PPA in column L and then the rest is taken care of
<robru> kenvandine: since you already have the silo, you need to set the PPA in column L, reconfigure, WATCH_ONLY, republish
<kenvandine> ok
<robru> kenvandine: so once that's copied, just run the merge job manually with FORCE, it'll merge your MPs correctly even though the package didn't make it to vivid as the silo is configured for
<kenvandine> bfiller, silo 10 is rebuilding now
<imgbot> === IMAGE 182 building (started: 20150422-20:50) ===
<ogra_> oh ?
<imgbot> === IMAGE 182 DONE (finished: 20150422-22:10) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/182.changes ===
<ToyKeeper> dbarth ... is gone, d'oh.
<ToyKeeper> Silo 16 failed.  It makes web apps crash.
<rsalveti> wtf
#ubuntu-ci-eng 2015-04-23
<imgbot> === IMAGE 183 building (started: 20150423-02:10) ===
<imgbot> === IMAGE 183 DONE (finished: 20150423-03:25) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/183.changes ===
<rsalveti> ogra_: small one https://code.launchpad.net/~rsalveti/ubuntu-touch-session/fixing_expect_upstart_obexd/+merge/257202
<ogra_> rsalveti, approved
<sil2100> Mirv: we have one free silo - do you want to take it? ;)
<Mirv> sil2100: well.. I think I'd rather wait for a better situation. I need to first to do the actual rebasing (of this Qt 5.6 code...) anyway and can build locally, plus thumbnailer branch isn't ready
<sil2100> dbarth_, oSoMoN: ping
<oSoMoN> sil2100, pong
<oSoMoN> whatâs up?
<sil2100> dbarth_, oSoMoN: the oxide 1.6.4 silo seems to have some webapp problems (QA double-confirming now), did that pop up during your testing as well?
<sil2100> Also, how's progress with 1.7.2 testing?
<oSoMoN> sil2100, I didnât see any issues with webapps with 1.6.4, what kind of issues?
<oSoMoN> sil2100, we found a blocker with 1.7.2, Chris wrote a fix and we will have to update the silo to 1.7.4
<oSoMoN> I mean 1.7.3
<sil2100> oSoMoN: ToyKeeper commented on trello: "Fail: This silo fixes the HERE T&C but makes web apps crash on start."
<sil2100> You can check the details there
<sil2100> davmor2 will try to reproduce
<oSoMoN> I did my testing on krillin
<dbarth_> pong
<dbarth_> 1.7.3 working great here
<dbarth_> checking the trello board now
<dbarth_> oSoMoN: i wonder if the crashers are arale and same as what we saw yesterday
<dbarth_> ie, the sandbox model change triggered by the newer kernels
<dbarth_> ToyKeeper: around? can you confirm the tests were on arale?
<ToyKeeper> dbarth_: Yes, it was on arale.
<oSoMoN> dbarth_, it shouldnât be related, afaiu thatâs a change in chromium itself
<dbarth_> right
<dbarth_> webbrowser-app works, because of the security policy, but all webapps would crash because of that newer kernel
<dbarth_> well, i guess 1.7.3 comes handy then
<oSoMoN> dbarth_, still, we should try and publish 1.6 first
<dbarth_> but just not on arale
<dbarth_> sil2100: how's that doable ? ie, release 1.6.4 to all but vivid/arale
<dbarth_> and line up 1.7.3 in a silo for the image
<dbarth_> sorry it is that complicated
<oSoMoN> dbarth_, Iâm not an expert on that, but I donât think thatâs doable, the same archive and overlay PPA feed all images
<dbarth_> so 1.6.4 for vivid is toasted; there's just the security updates for other releases which will be releasable
<dbarth_> and 1.7.3 is the only one we can try on vivid proper
<sil2100> dbarth_: we can't release something that's broken for arale...
<dbarth_> 1.7.2 was already working fine on mako, 1.7.3 fixes issues on arale
<sil2100> Since our goal is arale
<dbarth_> sil2100: precisely
<dbarth_> so unfortunately the 1.6.4 step was a waste of efforts
<sil2100> No worries, let's just try making sure 1.7.3 is good for everything
<dbarth_> i'll double check on krillin and mako right now
<sil2100> Thanks :)
<jibel> sil2100, so we stop on 1.6.4 and wait for a new silo with 1.7.3?
<sil2100> jibel: yeah... there's no use in 1.6.4 it seems ;/
<jibel> k
<sil2100> It was broken on arale from the start it seems
<jibel> dbarth_, ETA for a new version?
<sil2100> At least it seems to be already built...
<oSoMoN> dbarth_, no 1.6.4 was not a waste of efforts, it still needs to go to vivid-security
<dbarth_> jibel, oSoMoN: 1.7.3 is built indeed
<dbarth_> the build won't install on krillin/rtm-14.09 though, because of build deps; it will take a source copy into a silo to get rid of media-hub/qt5.4 build deps i guess
<dbarth_> i'm on reviving my mako which fainted out of battery last night
<dbarth_> jibel, sil2100, oSoMoN: initial testing on mako/vivid is positive: problems fixed and we even get background audio playback for free ! :) \o/
<sil2100> Ou yeah
<sil2100> \o/
<dbarth_> and arale was working fine earlier today on my arale with the key webapps as well + webgl in the browser + CTR as well
<dbarth_> maybe we can unfold the rest of the test suite with oSoMoN and hand that over back to QA early this afternoon
<sil2100> dbarth_: that's great news - when do you think it would be ready for a silo? Maybe we could re-use the 1.6.4 silo and just copy over the newer oxide
<oSoMoN> ubuntu-qa: any chance silo 21 will be validated before the landing gates for vivid close tonight?
<sil2100> Would be great, we can't have the RC without a new oxide
<dbarth_> sil2100: ah silo yes: can you transfer the build to whichever is free
<sil2100> dbarth_: btw. there's silo 11 that has oxide 1.5.6 in it, let me free that up then
<rvr> oSoMoN: It's in the queue, so there are chances.
<dbarth_> oSoMoN: so that 1.6.4 silo is not needed anymore, since the other releases will be via the normal security pocket
<jibel> oSoMoN, priority is 16, 18, 25 and 27. It can be verified once these are done
<dbarth_> sil2100: right, this one is outdated anyway
<sil2100> jibel: do we have anyone on 18 from our current timezone?
<jibel> rvr, which silo are you on?
<dbarth_> jibel: and so 16 becomes 11, as i guess oxide is the priority item
<rvr> jibel: I've been trying to validate 7, but I'm blocked and will take 27 after repartitioning
<jibel> dbarth_, ack
<oSoMoN> dbarth_, sure the silo is not needed any longer, but the testing was not a waste of time
<dbarth_> oSoMoN: no, you're right
<oSoMoN> jibel, rvr: thanks, you guys are doing a great job of validating our work, keep it up :)
<sil2100> chrisccoulson: hey! So I would like to copy 1.7.3 from the phablet PPA to a silo PPA but I see that it's suffixed with ~ppa1 - would you want to publish it with this version to the touch overlay PPA?
<jibel> rvr, can you continue alesage verification of 18?
<rvr> jibel: Sure
<jibel> rvr, thanks
<sil2100> dbarth_, oSoMoN, jibel: I'll copy oxide-qt 1.7.3 to silo 16, but it'll be with the ~ppa1 suffix
<sil2100> I think it should be fine to publish it with such a version
<sil2100> Since we're publishing to the PPA nad 1.7.3 will appear in security with the right version sooner or later anyway
<oSoMoN> sil2100, the changelog doesnât include the 1.7.3 changes, I donât think that build is intended for publication as is
<oSoMoN> chrisccoulson, can you confirm? ^
<chrisccoulson> sil2100, oSoMoN, that's fine. I didn't include the extra change as it disables a feature that was already disabled in previous releases
<oSoMoN> ok, thanks
<sil2100> ACK
<sil2100> So I guess it's fine to copy
<oSoMoN> seems so
<sil2100> cjwatson: hey! Could you maybe bump the size of https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+packages for us? :)
<sil2100> cjwatson: thanks!
<cjwatson> sil2100: how about I implement my suggestion from the other day to set all silos to 20480MB across the board?
<cjwatson> (then I'm going back to being on holiday)
<cjwatson> sil2100: that's done now (the across-the-board thing)
<sil2100> cjwatson: thanks :)
<sil2100> Works fine for us at least
 * sil2100 off to a family lunch
<jibel> dbarth__, oSoMoN is oxide 1.7 ready for testing? or it'll never land on time.
<oSoMoN> jibel, it is, Iâll be testing in parallel with you guys
<rvr> Mirv: ping
<Mirv> rvr: pong
<rvr> Mirv: I have installed silo 18
<Mirv> rvr: I've just updated both trello and the bug report with my afternoon's test findings. it seems the problem is that U1 account disappears on reboots (usually) when using th e silo.
<rvr> Mirv: I can reproduce the problem. When I hit to "Install", nothing happens. But then, in Ubuntu System Settings, the account was gone.
<rvr> Mirv: Yes, I confirm.
<Mirv> so when I tested before that I updated to silo first, then added account and tried installing apps I didn't see a problem
<Mirv> sil2100: ^ unfortunately even thought the unity8 hang is gone it does not seem the current upstream state of the patches is good enough for us, or alternatively there's some complications in backporting them to 5.4
<Mirv> tsdgeos: ^ 018 does not seem good for our use, even forget about KDE legacy apps for a while
<Mirv> tsdgeos: did you discuss with thiago about the current state and Merge ETA?
<tsdgeos> Mirv: i haven't been able to get him on IRC the last two days
<tsdgeos> so n
<tsdgeos> o
<Mirv> I noticed some of the MR:s actually had been merged, but not the bunch of it
<Mirv> I wonder if the route of "use DBus less like we did until February" is a possible workaround
<Mirv> for the boot issue
<tsdgeos> Mirv: it could i guess yes
<Mirv> pete-woods: tsdgeos: do you think anything in http://bazaar.launchpad.net/~unity-team/libusermetrics/trunk/revision/189 - which triggered the issue in February, could be changed in a way that for example libusermetrics and Unity8 wouldn't use the DBus at the same time so Unity8 wouldn't randomly hang during the boot?
<Mirv> like delaying the libusermetrics until a bit later, or getting a signal from unity8 to proceed or something like that
<pete-woods> Mirv: well I'm hesitant to just assume it's interaction like that. it could be libclick blocking, or a bunch of different things
<Mirv> pete-woods: in the bug report there was this piece of information earlier "I got a symbolic trace out of all the threads. It seems to be a dbus lock between usermetrics and networkmanager bits."
<pete-woods> Mirv: okay, well I suspect that if it's happening now, it could easily have happened before that change
<pete-woods> the change you linked just adds a new source for translations
<pete-woods> it doesn't really change the way we use DBus
<Mirv> pete-woods: yes, it could, but the thing is that it didn't, and because upstream still doesn't have a complete fix we're wondering if we can trigger it back one way or another to the shape that things don't collide during bootup (unity8 <-> networkmanager <-> libusermetrics)
<Mirv> there were other landings in http://people.canonical.com/~ogra/touch-image-stats/106.changes for sure too, but it's mostly general libraries
<tsdgeos> Mirv: honestly i'd rather get us to put someone to work on fixing those patches were needed and other software if needed than doing fragile changes hoping a lock won't happen
<tsdgeos> but i'm not the manager :D
<Mirv> sil2100: ^ we need a manager! :)
<Mirv> sil will read the backlog once back from his family lunch
<Saviq> trainguards, looking at https://launchpadlibrarian.net/204090374/unity8_8.02%2B15.04.20150423-0ubuntu1_source.changes is it on purpose that the "added:" string is on the same line?
<Saviq> in the most recent changelog
<Mirv> Saviq: probably not and robru will want to add a \n in there
<Saviq> Mirv, is it the plan to list things like dependency changes and such in there? (TBH listing added/removed files feels extreme IMO)
<Mirv> Saviq: well I'd have thought deps would be the first to be added, but maybe that's experimentation now
<sil2100> Mirv: wazzup?
<sil2100> Reading backlog
<sil2100> Mirv, tsdgeos: ok guys, do we have any other short-term options to get this bug resolved?
<tsdgeos> sil2100: define short-term :D
<sil2100> Like, anything we can do till EOD
<sil2100> ;p
<sil2100> Or, at max till Monday
<sil2100> tsdgeos: btw. since it's been a while since I had this info - could you remind me how often the unity8 hang on boot happens?
<tsdgeos> sil2100: i guess it depends on how unlucky you are
<tsdgeos> i'd go with "not very often"
<tsdgeos> but since it's race dependant, it happens more on first boots after flashing when the qml cache is being built
<tsdgeos> so it's kind of bad for first experience if your first boot ever gets you a deadlocked phone
<sil2100> Right, so it's as I thought then... no quick workaround we can do to make the race happen less frequently for first boots?
<tsdgeos> not that i know of
<sil2100> Damn...
<sil2100> pmcgowan: we might have a slight problem ^
<pmcgowan> I have been listening
<pmcgowan> tsdgeos, Mirv so what is it that is racing
<tsdgeos> pmcgowan: qtdbus code
<pmcgowan> tsdgeos, was looking for a bit more, like its libusermetrics doing somethign while ...
<tsdgeos> pmcgowan: there is lots of things we use that use dbus, one case we've seen is libusermetrics watching a dbus signal while qt-networkmanager waiting for networkmanager answering on how many networks there is
<tsdgeos> but wouldn't say this is the only such case
<tsdgeos> basically the qtdbus code is not good when used from multiple threads
<pmcgowan> thats awful
<rsalveti> yeah
<rsalveti> unity8 can't hang on boot
<rsalveti> sil2100: even if it hangs like 1/10
<rsalveti> on factory that is a lot
<pmcgowan> yeah factory is more the issue that customer since thats the first boot
<ogra_> rsalveti, thats just because we dont produce enough phones :P
<sil2100> Right
<sil2100> That's why I always advertised this issue as a 'ship blocker'
<sil2100> And now it finally seems that we're stuck with a ship blocker without a good way to workaround/fix it
<sil2100> It was important enough for us to actually agree on getting so many devel patches to Qt ;p
<sil2100> Still, it seems we have bugs
<sil2100> tsdgeos, Mirv, pmcgowan: maybe we could have some additional people looking into solving this issue?
<tsdgeos> sil2100: those patches are going to eventually hit upstream and we while eventually move to that upstream version, so we should just use them and make sure they are good enough imho
<tsdgeos> s/while/will
<pmcgowan> tsdgeos, so you suggest we fix the patches
<sil2100> I would say that sounds like a good idea, but do we have enough experienced manpower to do it till the EOW?
<sil2100> There's also the risk that those patches introduced additional regressions
<sil2100> So we need to proceed carefully
<ogra_> heh
<ogra_> EOW sounds so far away
<ogra_> you could have said "tomorrow" :)
<sil2100> ogra_: ;)
<tsdgeos> sil2100: EOW? i doubt we can do anything before tomorrow, no
<sil2100> ogra_: tomorrow is like 8 letters, while EOW is 3 - I obviously took the shortest one ;)
<ogra_> wo, are you sure you are not german ?
<ogra_> *wow even
<sil2100> tsdgeos, pmcgowan: we could of course proceed with building the RC image and in the meantime hope for the boot-hang fix, and then do a delta test once we release it
<sil2100> But...
<sil2100> Qt is such a low-level component and shared by so many applications that the delta testing will mean re-runing a lot of tests
<ogra_> yeah, wouldnt buy us much
<sil2100> So *at best* we'll need one more day to finish testing
<tsdgeos> sil2100: yes, you basically need to test "everything" since nowadays dbus is everywhere in our stack
<pmcgowan> sil2100, tsdgeos the part I missed is what regressions did we see with the patches, or did they just not solve the problem
<sil2100> pmcgowan: it solves the problem, but there are issues with things like unable to install apps and accounts disappearing
<sil2100> So pretty serious regressions
<pmcgowan> sil2100, tsdgeos and why on first boot
<tsdgeos> pmcgowan: first boot is more common because there's no qml cache built yet, so things run "at a different speeed"
<pmcgowan> tsdgeos, can we preseed the cache
<tsdgeos> pmcgowan: i guess we could, ricmm_ would know more, but the hang may still happen, tests indicate that a bit less frequently, but would still be there
<Mirv> sil2100: I'd say "fix Qt" is what's wanted, but meanwhile if anything could arranged during boot to not have multiple threads accessing DBus, similar to what we had until February 20th when libusermetrics changed behavior, we'd be in a fragile yet similar to before-Feb20th situation
<tsdgeos> Mirv: honestly i think it's unfair to blame it on that libusermetrics change, has anyone tested that reverting that change makes it less frequent?
<Mirv> Saviq: tsdgeos: can you share your unity8 booting script you used to the bug report? I mean, if experimenting with the boot process. I remember you were able to get it by cleaning cache all the time and rebooting 10-30 times.
<Mirv> tsdgeos: it's unfair to blame it on that, but we've data that the problem didn't exist before that day of http://people.canonical.com/~ogra/touch-image-stats/106.changes
<Mirv> it's not really "libusermetrics" problem, but "what happens during boot triggering Qt problem"
<Saviq> Mirv, while true; do adb shell rm -R "~phablet/.cache/QML"; ./tools/unlock-device || break; done
<Saviq> Mirv, where ./tools/unlock-device is from lp:unity8
<tsdgeos> Saviq: don't you need to restart unity8 at some point?
<tsdgeos> ah  ./tools/unlock-device does it
<Mirv> Saviq: thanks. it looks like unlock-device is the thing that reboots?
<tsdgeos> ignore maself
<Saviq> tsdgeos, Mirv, yeah unlock-device does it all
<sil2100> Mirv, tsdgeos: how many people do we have that could work on fixing the Qt patches to not cause these regressions?
<sil2100> Mirv: my memory is weary so I don't remember what the situation was in February - we didn't have any hangs like this then, right?
<Saviq> sil2100, we don't have anyone dedicated to upstream Qt work
<Mirv> sil2100: yes, there's some amount of info in the bug report but one can also see it in the dashboard results and boottest results before/after 20150221 image
<tsdgeos> Saviq: i guess between 0 and ~300 depending on how selective you want to be :D
<tsdgeos> sil2100: i mean âââ
 * tsdgeos hides from the bad joke
<sil2100> ;)
<sil2100> I think we should really consider assigning someone to do Qt-specific bugs for usptream, I know tsdgeos is doing a lot of work with Qt but maybe we could dedicate someone only to this purpose
<sil2100> But that's something for the future
<tsdgeos> i mean i have "some" experience with the dbus code, i produced a patch that shifted the deadlock from one place to another different place :D
<tsdgeos> no idea if there's someone with qtdbus experience
<Mirv> going through our upstream committers, tsdgeos and mardy are ones who have 1-2 QDBus commits
<sil2100> Do we have any leads what might be causing the regression in accounts and app installation?
<sil2100> Actually, I'll read the latest comment in the bug
<Mirv> sil2100: yes, do that. it sounds like QDBus is simply failing during boot in some way resulting in the account getting removed on an error either during boot or later when an app is tried to be installed. the account handling in u-o-a could be handled more error-pronely, but the question is what else might be broken (even though all AP:s pass and the Unity8 hang is now gone)
<rvr> rsalveti: ping
<Mirv> so the options are 1. fix Qt (long term), 2. experiment with boot ordering without touching Qt to try to get to February situation in DBus usage during boot, 3. make u-o-a more error-prone so that the current 018 is usable as is
<rsalveti> rvr: pong
<Mirv> 3. if there are no other regressions, it seems like everything problematic with or without the PPA is related to boot time simultaneous use
<sil2100> Mirv: maybe we could get someone from u-o-a to take a look at that - they might know exactly what u-o-a does and how it might break QDBus in our current situation
<rvr> rsalveti: https://trello.com/c/OpyHNSgA/1441-ubuntu-landing-027-ofono-awe-rsalveti
<rsalveti> rvr: are these new issues?
<sil2100> mardy: ping
<mardy> sil2100: I'm from u-o-a, I've seen my name highlighted a few times in this channel, but i didn't understand yet what bug we are talking about :-)
<Mirv> sil2100: I guess that'd be mardy who also has a bit of QDBus experience. he's probably EOD for today. but yes he could install 018 silo and try to see if the problem can be workarounded in u-o-a.
<rvr> rsalveti: I was verifying "Blocked SIM card keeps on asking for PUK"
<mardy> Mirv: still 22 mins to go :-)
<Mirv> mardy: if you install 018 and add U1 account and install apps, the U1 account disappears either during next boot or after the next boot when you try to install an app.
<rvr> rsalveti: And i haven't been able to fully unblock my SIM card so...
<Mirv> mardy: related to bug #1421009
<ubot5> bug 1421009 in qtbase-opensource-src (Ubuntu) "unity8 sometimes hangs on boot" [Critical,In progress] https://launchpad.net/bugs/1421009
<tsdgeos> mardy: so there's a qtdbus bug in which it deadlocks, we have upstream patches from thaigo that fix that by moving lots of stuff into threads and generally "doing stuff better" but it seems some part of the accounts stack regresses because of it
<rsalveti> rvr: hm, need help from alfonso here
<rvr> abeato: ^^
<abeato> rvr, what do you mean? have you blocked your SIM?
<rvr> abeato: To test PUK, yes
<abeato> rvr, ok, and which is the issue?
<rvr> abeato: I've been trying to verify  "Blocked SIM card keeps on asking for PUK" and found some issues described in the trello card https://trello.com/c/OpyHNSgA/1441-ubuntu-landing-027-ofono-awe-rsalveti
<rvr> abeato: Right now, it asks me for new PIN, but when introduced, it says "Incorrect PUK"
<rvr> abeato: But there are other issues as well
<rvr> abeato: Did you test this?
<abeato> rvr, I did
<abeato> in krillin and arale
<abeato> rvr, which phone are you using?
<abeato> note that for mako there is no change
<rvr> abeato: Arale, vivid-proposed 183
<abeato> rvr, ok let me try again
<abeato> rvr, "New pin cannot be introduced because the accept button is not enabled"?
<abeato> that is very weird
<rvr> abeato: The whole workflow is very weird :-/
<sil2100> mardy: so, this is a critical thing for us, the unity8 hang on boot is a ship blocker and the fix silo is causing apparent regressions in u-o-a
<rvr> Charging the iPhone to unblock and retry
<sil2100> mardy: we would need some assistance to help us fix the Qt patches we imported so that u-o-a works properly - or maybe even fixing u-o-a if needed
<mardy> sil2100: I'm checking the source code of uoa, to see if I'm doing something stupid
<tsdgeos> mardy: "known" thing that doesn't work anymore is using qtdbus before there's a qapplication around
<mardy> sil2100, Mirv, tsdgeos: so, uoa is registering the service name just before registering the object; indeed there's the risk of a race condition there
<mardy> it would explain why the service was activated and yet why no object was found at the "/" path
<Mirv> so, it might be a race condition _enabled_ by multi-threading of QDBus?
<mardy> tsdgeos: I'm instantiating QCoreApplication as the very first step
<mardy> Mirv: well, it could, though I'm not sure that this race condition is very likely
<mardy> Mirv: how easy is it to reproduce this bug?
<Mirv> mardy: the bug of having U1 account disappearing when using the 018 happens all the time
<Mirv> mardy: if you have U1 account before upgrading to the silo, it appears. also if you readd the account, even though app installation then works for the rest of that boot, the account will disappear (seemingly) every time during the next reboot or the app installation after reboot
<mardy> Mirv, sil2100: do you want to try this? https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/lp1421009/+merge/257267
<mardy> Mirv: well, it might be that the system is especially busy when booting, so times get slower and race conditions become more likely to happen
<Mirv> mardy: thanks, trying
<mardy> Mirv: however, the RequestAccount method which I see failing in your comment to the bug, is an API which gets called when one wants to *create* a new account, not when authenticating. I wouldn't expect that to be called on boot
<sil2100> mardy, Mirv: thanks guys!
<Mirv> mardy: that gets called when I try to install an app, before which the account has probably already disappeared
<Mirv> and since the account is not there, u-o-a decides to add one
<pmcgowan> sil2100, jibel  once we clear the current qa backlog we should only let in fixes for blockers
<pmcgowan> which we will need to land after today it seems likely
<sil2100> Yeah, we'll close the gates shortly
<pmcgowan> sil2100, I am ok clearing what is ready for qa
<abeato> rvr, testing in arale channel tangxi-vivid-proposed, image 18 it seems fine: PIN retries number right when starting the phoe, PUK retries ok too
<abeato> rvr, ofono (1.12.bzr6894+15.04.20150423-0ubuntu1)
<rvr> abeato: I just unlocked the SIM, trying again too :-/
<sil2100> om26er: how does silo 25 look so far? :)
<rvr> sil2100: It was rebuilt
<rvr> sil2100: And I haven't seen om26er online since then
<sil2100> hmmm
<pstolowski> sil2100, hey, landing-020 can be freed
<sil2100> pstolowski: ACK :)
<pstolowski> sil2100, i've updated landing-026 with the final MP to land in trunk, but reconfigure failed, can you re-check? also removed your comment for landing-026
<rvr> abeato: How did you open the pin unlock screen, after reboot or via indicator-network?
<sil2100> pstolowski: let me reconfigure that too
<om26er> sil2100, landed.
<sil2100> pstolowski: will it be ready for QA?
<pstolowski> sil2100, btw, i got Problem accessing /job/-0-reconfigure/parambuild. Reason: not found (404)
<abeato> rvr, I enabled it in system settings, then I rebooted and entered it from unity
<sil2100> om26er: excellent! \o/
<sil2100> Publishing
<sil2100> pstolowski: hm, probably bug in the spreadsheet
<om26er> so there seems to be something wrong with xchat and notifications in 15.04, they don't appear in the messaging menu
<rvr> abeato: Can you try to lock your SIM card opening the SIM unlock page via indicator network?
<pstolowski> sil2100, depends how fast it builds.. i tested the original branch and it worked, so if i have it built today, i should finish testing it in the evening
<sil2100> pstolowski: yeah, hm, spreadsheet issues I see
<abeato> rvr, I don't get that... the only way I see I could do that is trying to enable SIM lock, failing 3 times and then getting the SIM blocked, waiting for PUK
<abeato> rvr, is that what you mean?
<rvr> abeato: With your SIM unlocked. Reboot your phone, unlock the device, dismiss the SIM unlock screen. Go to indicator network, click on Unlock SIM button.
<om26er> rvr, Saviq pinged me when the silo was rebuilt.
<abeato> rvr, ok,
<rvr> om26er: Cool
<sil2100> Ok, officially scripts on the spreadsheet are broken
<sil2100> Looking into why
<abeato> rvr,  there is no unlock SIM button in the indicator network if the SIM is unlocked
<rvr> abeato: Sorry, I ment, that the SIM is not in PUK mode.
<abeato> rvr, ok, I see now what you mean, the behaviour is radically different if you try to unlock from indicator network instead of directly after booting
<abeato> rvr, yes, number of PIN retries is wrong, etc.
<abeato> rvr, but I do not know if this is a regression
<abeato> rvr, my guess is that this was happening without the latest ofono changes
<abeato> rvr, the ofono state seems to be fine but looks likes unity/indicator is not noticing
<abeato> weird
<rvr> abeato: Ok, so confirmed that it's not just me. Let me check without silo packages.
<abeato> rvr, good catch... I thought we could not enter phone without entering the PIN nowadays
<abeato> so I had never tried the "x" on start ;)
<rvr> abeato: :)
<abeato> rvr, if you enter PIN/PUK on boot all is fine
<rvr> abeato: Right, so it seems the behavior of SIM unlock screen is different when launched from the indicator
<abeato> yep
<sil2100> robru, Mirv: so it seems the spreadsheet scripts are now borken and getRange().getValue() doesn't return anything useful
<om26er> bfiller, Hi! I am testing silo21 so needed to look at design docs to really understand bug 1351177 -- oSoMoN left early for an appointment, I read. Can you provide the docs link ?
<sil2100> robru, Mirv: ok, issue fixed
<ubot5> bug 1351177 in webbrowser-app "Suggestions improvements" [Medium,In progress] https://launchpad.net/bugs/1351177
<sil2100> robru, Mirv: this spreadsheet is so fragile that it's crazy - the reason why things stopped working is that someone by accident moved some other sheet in front of the Pending sheet
<sil2100> And this is the result now &
<sil2100> ^
<sil2100> jibel, rvr, davmor2: expect duplicate trello cards
<bfiller> om26er: https://docs.google.com/a/canonical.com/presentation/d/1Qrd4Flfs3EH-fI79IfrYgLdAx2nce-L7ve8NKLCX324/edit
<sil2100> Saviq, damn, unity8 went to vivid, I think there was some glitch in the spreadsheet
<sil2100> Saviq: let me copy it to overlay and free the silo
<Saviq> sil2100, yeah, I saw the migration msg, was wondering if that's some weirdness of publishing to overlay...
<Saviq> sil2100, would've pung you soon if it didn't recover ;)
<sil2100> Saviq: copied and merging :) Sorry about that
<Saviq> sil2100, nw
<Saviq> sil2100, but yeah, must've been some glitch, overlay was selected as the target
<sil2100> pstolowski: silo reconfigured ;) Will it be ready for QA?
<sil2100> Mirv is probably away already, any brave souls around to test silo 18 again with the small fix from mardy ?
<pstolowski> sil2100, when is the deadline? i can test tonight
<sil2100> pstolowski: we want to close the gates soonish
<Mirv> sil2100: mardy: tsdgeos: pstolowski: yes I should be away... and will be just after this. it's now possible it's shifted to not happening during boot - three times now, after adding an account and rebooting, the account is still there if checked via system settings. so it's possible this is fixing u-o-a boot time problem! but it now always (still) disappears when it's rebooted and "Install" is clicked in a store, so maybe a similar fix to mardy's 
<Mirv> that definitely got cut somewhere, right?
<sil2100> pstolowski: your change is maybe not a ship blocker, but it's a good fix which wouold be nice to have
<tsdgeos> Mirv: i guess it's possible yes
<sil2100> Mirv: where do you think we should do a similar fix as well?
<rvr> abeato: Not completely sure that is not a regression, without the silo I can't type the PUK to follow.
<Mirv> sil2100: whatever the app installation does via dbus, like querying the accounts or something
<abeato> rvr, you can't enter PUK?
<rvr> abeato: The accept button is not enabled :(
<pstolowski> sil2100, i know, but realistically, the build will take ~1.5h, and hopefully it doesn't fail on a flaky test we discovered lately
<abeato> rvr, even if you try from the screen on boot?
<Mirv> now I even got add account + reboot + install app without problem, similar to sometimes the boot didn't remove the account before. so it seems there's a similar racy condition when pressing the install button for the first time after reboot.
<sil2100> Mirv: we need to find someone from the click app installation to take a look at that then
<sil2100> \o/
<pstolowski> sil2100, so i can conclude my testing in about 2h
<Mirv> sil2100: that mardy's example code sounds promising in the sense that it can be used as an example by someone who understands what/where happens when app is wanted to be installed
<sil2100> Mirv: ok, I'll try to forward it to the right place
<Mirv> sil2100: thanks! check up with alec_u who is checking with his team as seen on -touch
<sil2100> pstolowski: ^ do you know anything about this?
<sil2100> Ah, ok, I see on -touch
<sil2100> :)
<dbarth__> sil2100: we're still testing, and investing some occasional issues with tabs and webapps when the system is loaded
<dbarth__> sil2100: how much are you blocked on oxide?
<pat__> dbarth__, we have 3 or 4 things that need to land to be done, oxide is one
<sil2100> dbarth__: it's a ship blocker, since without it the T&C won't show up
<sil2100> So it's one of the criticals as pmcgowan says
<sil2100> pmcgowan: might as well close the landing gates to anything that's not a blocker for us I suppose
<pmcgowan> sil2100, lets land what has been preped for QA
<pmcgowan> ready for testing and in testing
<sil2100> pmcgowan: right, that's the plan, after the gates are closed those silos that are ready are still signed-off and landed
<pmcgowan> then yes
<dbarth__> well, then 1.7.3 is an improvement overall
<sil2100> But after closing we don't accept new landings (besides blockers in this case)
<dbarth__> still not sure what those white screens are made of; chris is on it
<sil2100> dbarth__: I suppose the webbrowsing quality on arale is still better, I think we had the white screens on the old oxide as well
<dbarth__> but then it means another 6-8h of build time before we can re-test a fix
<pmcgowan> then we should make sure its the last fix we need
<dbarth__> pmcgowan: that "fix" is more an hypothesis right now; in the absence of a solution in the next hours, the tradeoff is improved, more polished exp (flickering, gl, CTR)
<dbarth__> pmcgowan: but at the cost of increased browsing instability when the system is loaded with many webviews
<pmcgowan> dbarth__, surely chris can do inceremental builds quicker than that to test?
<dbarth__> pmcgowan: at least, yes
<pmcgowan> we have no choice now but to land 1.7 dbarth__
<sil2100> Maybe since davmor2 is already testing 1.7.3, we could land it anyway and anticipate a probable 1.7.4 with the fixes
<sil2100> But in case it's not feasible in our timeframes simply stay around with 1.7.3 (and the instabilities)
<dbarth__> pmcgowan: i'd rather land 1.7, i think that's a better version overall
<pmcgowan> its no longer a choice afaik
<pmcgowan> there is no rather
<davmor2> sil2100: there are definitely issue with tabs in 1.7.3
<dbarth__> ok, deal
<pmcgowan> we could land it with that known and do as sil2100 says
<pmcgowan> if it allows some regression testing to start
<sil2100> The unity8 on-boot hang worries me a bit
<sil2100> Worst thing is we'll probably have to wait till tomorrow to know more on that one
<rvr> abeato: Ok. This is what I found.
<sil2100> Anyway, let me close the gates
<rvr> abeato: In vivid proposed 183, without silos, in the "boot" SIM lock screen, things work just fine.
<sil2100> rvr, jibel, davmor2, om26er, ToyKeeper, alesage: landing gates will now be closed, sign-off only those silos that are are ready now and those that are blockers for release - consult me or Pat in this case
<rvr> abeato: I'm able to lock the SIM after three unsuccessful trials, count is updated, and PUK can be introduced and SIM can be unlocked.
<rvr> sil2100: Ack
<rvr> sil2100: Silo 10 is in, I understand.
<ogra_> sil2100, FYI ... initramfs-tools-ubuntu-touch uploaded ... will be interesting if it actually builds at all in the PPA (it uses a werid multi wrapped build process)
<alesage> Mirv, on silo 18, app store => install PodBird (my fav!) => UO sign-up => two factor, then spinning orange wheel
<sil2100> rvr: yeah, those that are ready now can be still signed-off and landed, but we prioritize those silos that have blockers
<sil2100> alesage: yeah... even with the additional change it still seems to have some racy parts in the application installation
<alesage> sil2100, ack, was going to ask for other D-Bus test cases around this change
<sil2100> alesage: actually, as part what was mentioned in -touch, could you try using some other online accounts in click apps?
<sil2100> We were actually wondering if U1 is the only one having issues
<alesage> sil2100, ok shall do
<sil2100> alesage: thanks! :0
<sil2100> We need as much info as we can
<abeato> rvr, and what happens when doing things from indicator network, without silos?
<robru> sil2100: yeah I've seen getRange() fail before, apparently the ranges need to be extended when new rows are added. There is a script that does that, but it seems to intermittently fail. Usually it fixes itself if you just add more rows later.
<Mirv> alesage: sil2100 just a quick note that I've seen spinning orange wheel after two factor as often also without the ppa, so that part is probably not regression, the account disappearings are
<sil2100> Mirv: ACK
<alesage> Mirv, intriguing
<rvr> abeato: No count is shown. After PIN is locked, it doesn't switch to PUK.
<abeato> rvr, then we can conclude that it is not a regression from silo 27 and that bug was already around, isn't it?
<rvr> abeato: Closing and opening it ("Unblock SIM" from indicator network) does show the PUK screen.
<rvr> abeato: Introducing the PUK unlocked it.
<rvr> abeato: But screen remains there.
<rvr> abeato: Closing and opening the screen, shows "introduce the new PIN".
<abeato> rvr, yep, pretty similar to what happened with the silo
<rvr> abeato: So all problems are in this screen.
<rvr> abeato: But the silo doesn't address this. The PIN can be unlocked when booting.
<rvr> PIN Lock + PUK unlock works fine from boot.
<abeato> rvr, the silo addresses the case when the SIM is PUK-blocked
<abeato> that is, you cannot recover the SIM
<abeato> without the silo it incorrectly asked for PUK
<abeato> with the silo it tells you that your SIM is completely blocked
<rvr> abeato: Yes, you can
<abeato> rvr, I am talking about the case when you introduce a wrong PIN 3 times and a wrong PUK 10 times
<abeato> so you cannot use the SIM
<rvr> abeato: Ahhhhh... and the wrong PUK 10 times, I see
<abeato> that's what the bug talks about
<abeato> the change also makes sure you know the number of retries available all times
<rvr> Right, right
<abeato> it is just that the terminology for this is soooo confusing...
<rvr> err
 * rvr doesn't want to block his SIM card
<abeato> hehe
<abeato> you can ask mzanetti to test the silo ^^
<abeato> he had the blocked SIM
<rvr> Is any other way to test it? :-/
<abeato> not really ;-(
<sil2100> jibel: hey! So, the landing gates closed, but we can't really create an RC image without the Qt fix for unity8 hangs
<sil2100> jibel: this might shift the build of the RC...
* 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: devel (vivid) touch landing gates now closed!
<rvr> abeato: If I block my SIM card I need to go to the store, to get a duplicate ... I'll check this at the end.
<abeato> rvr, I completely understand
<davmor2> rvr: what this?
<rvr> davmor2: A test that involves a SIM card being blocked after 10 unsuccessful PUK trials.
<alesage> Mirv, sil2100  reverting to trunk i'm not seeing the spinning orange wheel for several trials when signing up for UO--is simply removing the account an authentic test of signing up again?
<abeato> rvr, however mzanetti already did some testing (see comments in bug #1436820)
<ubot5> bug 1436820 in ofono (Ubuntu RTM) "Blocked SIM card keeps on asking for PUK" [Medium,Confirmed] https://launchpad.net/bugs/1436820
<cwayne> sil2100, davmor2 what happened to krillin vivid custom tar, is that blocked at the gate now?
<alesage> sil2100, I'll chase the other online clicks now with the silo
<davmor2> rvr: yeah I'm not about to test that either :D
<rvr> davmor2: haha
<abeato> don't know if that can be considered enough or not
<rvr> abeato: We prefer to check ourselves
<sil2100> cwayne: I guess it's not blocked, but I think QA might be busy with arale as that has higher priority ;)
<rvr> When possible, of course
<sil2100> cwayne: I know it's on their list but there's a lot of blocker/criticals for arale that still need tending
<rvr> cwayne: QA overflow!
<cwayne> figured as such, just wanted to make sure I hadn't missed a +1 again :)
<abeato> rvr, yep understandable
<davmor2> cwayne: no I will ping you in every known format so you don't miss it again
<cwayne> davmor2, i await your smoke signals
<Mirv> alesage: I didn't see the spinning wheel today with the ppa at all, and once without the ppa. not sure when it happens.
<davmor2> cwayne: if you find bird poo on your car don't shoot it it's the carrier pigeon and it's flown a long way
<cwayne> davmor2, can you instruct it to poop on my neighbors car instead
<davmor2> cwayne: hahaha
<ogra_> cjwatson, bah ... does a package build in the overlay PPA  actually prepend the overlay PPA to sources.list ? (initramfs-tools-ubuntu-touch just exploded in my face trying to use the PPA line as mirror for debootstrap)
<boiko> sil2100: hi, where can I check what changed from one vivid-proposed image to another?
<ogra_> imgbot, status 183
<imgbot> Error: There does not seem to be any build with the number 183
<ogra_> imgbot, status 182
<imgbot> Error: There does not seem to be any build with the number 182
<ogra_> imgbot, status 183 vivid
<imgbot> Status: succeeded, Started: 2015-04-23 02:02:06 UTC, Finished: 2015-04-23 02:57:41 UTC
<imgbot> Build URL: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/+build/25796
<imgbot> Changelog: http://people.canonical.com/~ogra/touch-image-stats/183.changes
<ogra_> boiko, ^^
<boiko> ogra_: thanks!
<pstolowski> sil2100, my silo just built... i guess it's too late (i need ~20 minutes for testing)
<sil2100> pstolowski: I would still think about it
<boiko> ogra_: and for krillin is that the same?
<pstolowski> sil2100, ok.. testing
<ogra_> boiko, yes, different versioning though ...
<ogra_> imgbot, map 183 vivid
<imgbot> mako ubuntu version: 183 maps to krillin version: 196"
<imgbot> mako ubuntu version: 183 maps to generic_x86 version: 185"
<sil2100> pmcgowan: ^ pstolowski has the fix for the scopes disappearing during upgrade - it's not critical to have for RC I suppose since they're all in custom tarball, but maybe it could be a good idea? What do you think?
<sil2100> pmcgowan: considering that we'll anyway blocked on building the RC image with the unity8 hang bug...
<ogra_> boiko, vivid is all mapped against mako so you need the map command to actually find the krillin version
<boiko> ogra_: great! thanks!
<pmcgowan> sil2100, sure good to land
<ogra_> i guess i need to change that at some point
<sil2100> pstolowski, davmor2, rvr, ToyKeeper: ^ please make sure that silo 26 is also signed-off once set as ready
<boiko> imgbot, map 181 vivid
<imgbot> mako ubuntu version: 181 maps to krillin version: 195"
<imgbot> mako ubuntu version: 181 maps to generic_x86 version: 184"
<boiko> imgbot, map 182 vivid
<imgbot> mako ubuntu version: 182 maps to krillin version: 195"
<imgbot> mako ubuntu version: 182 maps to generic_x86 version: 184"
<pmcgowan> sil2100, rvr we have been waiting for silo 24 so if thats now ready for QA would like to get those
<rvr> pmcgowan: Ack
<pmcgowan> thanks
<sil2100> pmcgowan: indeed, that's a blocker fix so it's good to have that
<sil2100> pmcgowan: too bad jibel is not around, I wanted to consult with him what to do in this situation with the RC, but I guess we'll decide that tomorrow morning
<alecu> sil2100: with latest silo-18 in mako #183, logging into U1 after clicking "Install", or logging into U1 from system settings->accounts are working much better. Still, the account was still deleted after reboot.
<sil2100> alecu: deleted after reboot? Damn, I actually thought it would be the other way around with this silo installed
<pmcgowan> sil2100, we can make an image tonight but I suspect we need another prior to regression tests starting
<pstolowski> sil2100, marked silo 26 tested
<sil2100> pstolowski: excellent
<sil2100> pmcgowan: ok, so I'll be logging off in some minutes, but I'll log in in a few hours to maybe kick an image - want as many silos to land as possible
<alecu> sil2100: and just while I'm saying this, I'm attempting to log in again, only to get the spinner showing forever after clicking in "Sign In"
<alecu> sil2100: so, please disregard my previous comment
<alecu> top shows that unity8 and online-accounts are pegging the cpu, will take a screenshot of that.
<pstolowski> sil2100, signing off for today. cu!
<alecu> so, the "spinner forever" seems to be some weird interaction between unity8, online-accounts, and system-settings: http://pasteboard.co/2MKyOsZ9.png
<alecu> actually, it's online-accounts-ui
<alecu> http://pasteboard.co/2MKR1ed7.png
<alecu> ten minutes, and still spinning.
<cjwatson> ogra_: The context archive itself always comes first, yes.  You should probably do something like checking the Origin of release files, or you could just exclude ppa.launchpad.net perhaps
<cjwatson> ogra_: I see you attempted to do the latter, but it would work better if you wrote "ppa.launchpad.net" rather than "ppa.launchpa.net". :-)
<alesage> Mirv, still seeing this spinning circle reliably, happens in settings proper (store process not implicated), http://pastebin.ubuntu.com/10873064 , http://pastebin.ubuntu.com/10873079 <= unity8 log
<alesage> sil2100, ^^
<ogra_> cjwatson, gah, damned ...
<ogra_> cjwatson, thanks though !
<alecu> alesage: I'm seeing the spinner too, both from the store and from system settings.
<alesage> alecu whew I'm not crazy :)
<alecu> alesage: are you on arale? the cpu usage is very different from the screenshot I pasted above from a mako.
<alesage> alecu arale, yes
<alecu> great.
<alesage> alecu, sil2100 FWIW other normal accounts (Twitter, Google, FB) don't appear affected
<alecu> and using dbus-monitor there doesn't seem to be any unusual dbus traffic while the spinner is shown and the processes are chewing the cpu....
<sil2100> alecu, alesage: thanks for looking into that guys, I'm actually wondering what's causing all those issues
<sil2100> alecu: be sure to document your findings in the unity8 hang bug ;)
<alesage> sil2100, not seeing without silo at least to this point
<sil2100> I need to AFK now for a while, but will be back in 3-4 hours
<rvr> abeato is no more
<rvr> rsalveti: davmor2 found a problem with the "after-PUK"
<rvr> on silo 27
<davmor2> rvr: I think rsalveti is off too ircc
<davmor2> iirc even
<ogra_> yeah, traveling
<rvr> Ok
<rvr> davmor2: I'll send them an email
<ogra_> he wont be around before monday officially ... (probably drops by on the weekend though)
<ToyKeeper> mandel: I see a note on silo 24 saying to contact you about testing the change.  What's needed to test it?
<davmor2> rvr: http://people.canonical.com/~davmor2/screenshot20150423_192816321.png
<davmor2> rvr: does that on hitting the X or if you just don't press anything
<rvr> davmor2: :-O
<davmor2> rvr on the initial purple screen that looks correct
<davmor2> rvr: you can't drag anything in, you can't swipe it either because that isn't unlocked yet :(  had to remove the sim to get into the phone to get the screenshot
<davmor2> I'll try and get a purple one too
<rvr> Sounds really bad
<rvr> Ok, copied your comments to the card and sent an email to abeato with cc to rsalveti
<mandel> ToyKeeper, hello! sorry I was out for dinner
#ubuntu-ci-eng 2015-04-24
<imgbot> === IMAGE 184 building (started: 20150424-07:20) ===
<Mirv> that was late
<ogra_> yeah, recently they are all late, very weird
<ogra_> oh, but this one was manual :)
<ogra_> the cronjob is disabled it seems
<sil2100> Yeah ;)
<sil2100> I wanted to build this one yesterday night, but we lost internet access and I couldn't log into nusakan
<sil2100> So I gave up and just did it in the morning
<Mirv> hmm
<mardy> Mirv: to debug the problem with silo 18, you could do "echo LoggingLevel=2 > ~/.config/signond.conf", then send me the syslog
<Mirv> mardy: ok. I'm testing something else right now to workaround the problem, but writing that down.
<Mirv> sil2100: tsdgeos: mardy: etc: hmm. I may have a workaround for #1421009, based on the unity8 boot loop test case ...
<tsdgeos> Mirv: you mean seed the cache?
<Mirv> tsdgeos: no.
<Mirv> and you're not going to be impressed :D but... 30 reboots now solid.
<Mirv> http://paste.ubuntu.com/10877014/
<tsdgeos> he he
<imgbot> === IMAGE 184 DONE (finished: 20150424-08:40) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/184.changes ===
<sil2100> Evil
<sil2100> ...but we like evil
<sil2100> Mirv: give me a sign what to test and how, I need to prepare my device
<Mirv> sil2100: start with the Test Case I added in bug #1421009 description so that you can verify you can get the problem on an unmodified vivid. maybe after around 10-20 minutes (or earlier), you should notice it is not rebooting anymore, the script execution has stopped and if you check the device the unity8 lock screen has a black background and it's hanged (at least on my mako). note that "Unlock attempt 1 failed" is normal and happens on each boot
<ubot5> bug 1421009 in qtbase-opensource-src (Ubuntu) "unity8 sometimes hangs on boot" [Critical,In progress] https://launchpad.net/bugs/1421009
<Mirv> it's useful to know the bug we're fixing in the first place. meanwhile, I'm trying with lower values and will give the next piece of instructions when you're able to reproduce the bug
<Mirv> ogra_: from what I can deduce, .override file is identical to a .conf file and simply is executed instead of the .conf file when .override exists?
<mardy> Mirv: right, the networkmanager qt plugin uses dbus to talk to NetworkManager; the bug might be there
<ogra_> Mirv, well, if you only put lines ther that exist in the .conf it will replace them ... i.e. you can just have an override with a "start on" stanza that replaces the default
<sil2100> Mirv: the loop is to be executed on the desktop, right?
<sil2100> Ah, right, I see adb commands
<sil2100> So yes
 * sil2100 executes it on vanilla vivid
<ogra_> yummy, vanilla
<ogra_> now you made me think about icecream !
<davidbarth> o/ hello trainguards, could i get a reconfiguration of silo 22 please? (I swapped a branch for another)
<Mirv> ogra_: oh, like section based? so I could have network-manager.override with only content http://pastebin.ubuntu.com/10877298/ ?
<ogra_> Mirv, that should work, yeah
<Mirv> mardy: yeah, this'd be the workaround for the original bug of unity8 hanging without affecting Qt DBus even though that means Qt DBus is still not multi thread safe (but the only real problem we know to have is so far the boot problem)
<ogra_> (try it first indeed)
<Mirv> sil2100: yes
<davidbarth> ah no in fact i can reconfig myself; all good
<sil2100> Mirv: so far vanilla vivid is looping pretty nicely, no hang for now
<sil2100> chrisccoulson: ping
<sil2100> chrisccoulson, davidbarth: hey guys, how's the work on 1.7.4 going?
<sil2100> chrisccoulson, davidbarth: it seems QA can't sign-off oxide 1.7.3 due to the tab experience being completely broken
<sil2100> chrisccoulson, davidbarth: so we would really need a fixed version today...
<Mirv> sil2100: I think it's really slow going in order to know if we have a fix for real. tsdgeos said 30 boots should be safe, but I'm not sure if they tested on arale (but then again, don't we have "1/10" reports on arale currently?)
<sil2100> Mirv: not sure how many reboots it was right now, probably around 20, and so far it's still looping
<sil2100> I'll let it go for 20 more minutes
<Mirv> sil2100: ok, that's not really good news, since of course we'd need to be reliably to reproduce the problem in order to say there's a workaround
<chrisccoulson> sil2100, a fix for what?
<sil2100> chrisccoulson: davidbarth mentioned there's a hypothetical fix in the works for stability with many webviews
<sil2100> chrisccoulson: since QA mentioned that webbrowser has really really broken tab functionality with 1.7.3, so I hoped this fix might help
<chrisccoulson> sil2100, I'm not aware of that. I had an occasional browser crash which disappeared after updating my image, and trunk is a bit broken
<sil2100> davmor2: ^ can you report the oxide issues you saw to chrisccoulson with details?
<sil2100> Maybe those issues you saw are new and neither davidbarth or chrisccoulson saw those
<davmor2> sil2100: yeap next bug on my list
<chrisccoulson> it would be nice if people actually reported issues to me. I wasn't aware of it and there obviously is no fix if I'm not aware of it
<davmor2> sil2100: oSoMoN commented on them
<sil2100> chrisccoulson: I suppose it was something that was reported to oSoMoN or davidbarth
<sil2100> davmor2: he didn't forward it to chrisccoulson then?
<sil2100> Mirv: btw. did we have any confirmed cases of the hang happening on arale at all?
<Mirv> sil2100: I guess we'll need to collect info. does ogra or jibel know? I thought "someone" has tested that arale randomly fails to boot / hang at unity8 lock screen.
<Mirv> sil2100: comment #52 on the bug states that "I see this on normal boots of mako and arale; roughly 30% of the time...
<Mirv> 30% is a lot, though, so I wonder if the test case is the best possible?
<ogra_> i never see that
<Mirv> the really, really original bug report states what we know that sometimes a test fails because of the boot issue, on krillin specifically
<Mirv> tsdgeos: Saviq: so when you were executing the unity8 boot loop test case, was that mako/krillin/arale?
<davmor2> chrisccoulson: sil2100 https://bugs.launchpad.net/ubuntu/+source/oxide-qt/+bug/1448010
<ubot5> Ubuntu bug 1448010 in oxide-qt (Ubuntu) "Browser tab movement is jumpy and unpridicatble in 1.7.3" [Undecided,New]
<tsdgeos> Mirv: mako
<chrisccoulson> davmor2, but this is a webbrowser-app feature. Oxide doesn't have anything to do with the tab spread
<tsdgeos> sorry my interwebs are awful today
<davmor2> chrisccoulson: hmmm I wonder why it is so smooth in the older version then?
<Mirv> ok I'll continue with my mako then anyhow, regardless of how it goes with arale
<Mirv> sil2100: the removal of QML cache is supposed to simulate first boot from factory
<sil2100> Mirv: so far no hangs
<davmor2> chrisccoulson: let me have a play on krillin this morning I'l capture a video
<Mirv> sil2100: I'm not really sure if that's good news or bad news ;)
<sil2100> Yeah ;p
 * sil2100 wants it to hang finally
<chrisccoulson> oSoMoN ^
<sil2100> Mirv: ah ha!
<sil2100> Mirv: I think it happened!
<Mirv> sil2100: five tries, script errors out, unity8 hanged?
<sil2100> Mirv: ': Unlock attempt 1 failed, script output: 'Error: Timeout was reached - now the screen is on the main screen but without the libusermetrics wheel, just the clock and a black screen
<sil2100> Consecutive unlock attempts fail
<sil2100> Device unresponsive
<sil2100> Ok, win
<Mirv> sil2100: can you copy-paste the so far log to a file, then grep passed file | wc -l ?
<Mirv> so we get the amount of reboots that were done
<oSoMoN> chrisccoulson, davmor2: thanks, I triaged the bug accordingly, IÂ donât have my arale handy right now, but Iâll test and confirm this afternoon
<chrisccoulson> oSoMoN, thanks
<sil2100> Mirv: 57
<davmor2> oSoMoN: checking on krillin too
<Mirv> sil2100: ouch, that's awfully lot
<sil2100> Well, might not mean anything, races involve probability and probability likes to be a jackass
<Mirv> sil2100: then it's possible we don't really know if my workaround helps or not, even though on mako it'd generally happen quicker
<sil2100> Mirv: let me spin it here then
<abeato> trainguards, can I have a silo for lone 53?
<abeato> s/lone/line
<Mirv> abeato: ok
<sil2100> Mirv: let me try with your workaround now
<abeato> thx
<Mirv> sil2100: yeah, just apply it manually for now, I haven't progressed on testing the .override etc
<Mirv> sil2100: I'm not sure if it matters but it seemd the indentation is with tabs, so I did it similarly for those sleep lines
<sil2100> Ok, running it now
<Mirv> I now had only "sleep 1" and only after, not before, and got failures after 22 reboots. so I'm now going to be more systematic and getting a couple of errors without changing anything, and then try really hard with eg. sleep 2/2 or so. my original sleep 4/4 ran for about 50 boots, which is less than your arale (but arale might hit it less often, as reportedly 30 should be enough on mako)
<sil2100> Mirv: I have bad news
<sil2100> :<
<sil2100> Mirv: the workaround seems to not work, after 17 loops it hanged
<Saviq> Mirv, mako
<davidbarth> sil2100: on that issue, there is no fix, cause the problem itself is not fully understood; we couldn't reproduce issues yesterday evening, apart from the oom_killer
<davidbarth> while i was observing non-oom_killer related problems earlier in the afternoon with oSoMoN
<sil2100> Things look better and better with our RC ;)
<Mirv> sil2100: :( so it seems a) arale might be different beast, b) it's really fluctuating, and 30 reboots after all is not enough to test a fix, or even 50
<sil2100> Mirv: http://paste.ubuntu.com/10877628/ this is my n-m.conf
<Mirv> sil2100: looks similar to what I tested
<Mirv> mmh, a bit frustrating, but I wonder if we understand enough of the problem, and if all the black background errors are caused by this problem or something else
<Mirv> on my krillin rtm I had a reboot when I had similar unity8 hang / black background
<Mirv> Saviq: tsdgeos: is there anything else that would be useful to check when the failure happens, to check whether we're hitting this DBus problem or something else?
<tsdgeos> Mirv: gdb and see the backtrace
<Mirv> tsdgeos: from the running process, or would it be ok to check the .crash file after it's generated?
<Saviq> Mirv, if it rebooted then it's not the deadlock
<tsdgeos> Mirv: it doesn't generate a .crash file
<Saviq> Mirv, the deadlock does not cause a crash, so that must've been something different
<Mirv> Saviq: what, my krillin example? I meant, after a reboot I once had a black background on krillin and a hang, I didn't check it further than eventually forced a reboot by pressing power button
<Mirv> sil2100: do you still have it running or did you reboot? you could try gdb -p [pidofunity8] and bt
<Saviq> Mirv, if you have a deadlock on boot, the only reason we know is dbus, but what tsdgeos said - attach when it's hung and see the trace
<Mirv> tsdgeos: Saviq: anyway, for testing the eventual upstream fix, it seems 30 reboots is not enough, and not even 50. we don't know the upper limit of possibly passing reboots without changes.
<Mirv> Saviq: ok, thanks
<sil2100> Mirv: still have it running
<Mirv> sil2100: oh right your next run. I also started my next run already, the previous one on mako (without changes) failed after 30 reboots.
<Mirv> it seems our previous test case was not good enough, so we need to have a real test case before any fix can be tested
<sil2100> The bt:
<sil2100> (gdb) bt
<sil2100> #0  0xb621a620 in syscall () from /lib/arm-linux-gnueabihf/libc.so.6
<sil2100> #1  0xb63cfe12 in QBasicMutex::lockInternal() () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
<sil2100> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
<Mirv> ah right still running as in still that failure there, nice
<sil2100> Yeah ;)
<Mirv> tsdgeos: is that ^ enough to validate that it's this dbus problem? clearly a locking problem but can we get the DBus visible some way?
<davmor2> Mirv: does that mean we are back to landing QT7 to fix the world?
<Mirv> davmor2: we're back to finding out what was the problem in the first place
<davmor2> Mirv: :(
<Mirv> when we have a test case, in addition to Qt 7 we might take my idea of adding a delay but apply it somewhere like for example inside unity8 before it calls usermetrics or NM or something
 * sil2100 off to prepare lunch
<sil2100> Mirv: indeed, that might make sense
<Mirv> since the only known problem right at the moment is a boot time random failure
<Mirv> tsdgeos: unping, I got a better retrace now on my mako which involves QDBus and I can improve the test case now
<tsdgeos> sorry was busy elsewhere
<Mirv> sil2100: if you're still there with the arale hang when you come back from lunch, try sudo apt install qtbase5-dbg libc6-dbg and backtrace again, and compare if you get the same QDBusDispatchLocker related line that I'll be adding to the bug test case
<sil2100> Mirv: installing packages while preparing roast
<sil2100> Mirv: yeah, I see it's locking on QDBusDispatchLocker indeed
<sil2100> Let me pastebin the whole backtrace (bt, not bt full)
<sil2100> Mirv: http://paste.ubuntu.com/10878086/ <- but I suppose you have the same
<Mirv> sil2100: yeah, I updated the description, looks the same. now we at least have what to look for, but we'd need the upper limit of reboots that can happen without the problems seen. I'm currently guessing a 100, although it might be lower on mako (30 my maximum so far)
<Mirv> tsdgeos: if we follow up on the idea that Qt patching at this point still seems risky, and the only known problem is the boot time simultaneous DBus usage, can you think of as ugly hacks as mine inside Unity 8 that would eg separate Network Manager <-> usermetrics calls by delaying eg usermetrics? I can take care of all testing once I've the test case 100% proof.
<Mirv> regression on boot time is less worse than the possibility of a deadlock
<Kaleo> trainguards: need a silo for row 54 :) camera-app landing
<Mirv> Kaleo: ok
<Kaleo> Mirv, thanks!
<Mirv> Kaleo: I don't where bot went but you got silo 011
<Kaleo> Mirv, thank you
<sil2100> tsdgeos, Mirv: keep me updated guys ;)
<Mirv> sil2100: I'm currently just getting data on the upper limit of possibly successful reboots on mako without any changes. but it seems mako is slower at it than your arale :) I've only 3 runs now collected, and the current one is at 36 at the moment without problems.
<Mirv> sil2100: btw, did you really mean to publish ubuntu-keyboard, ubuntu-system-settings to vivid in the morning...
 * Mirv hopes w will open soon :)
<sil2100> Aaaaa
<sil2100> Ok, I'll never get used to checking the dashboard for the target
 * sil2100 copies it over to the overlay PPA
 * sil2100 sighs
<sil2100> Fixed, that what happens when one publishes in haste
<oSoMoN> ubuntu-qa: whatâs the status of testing of silo 21 ? I understand that, given that it was already under review when the freeze happened, it still has a chance to land, is that correct?
<rvr> Hmm
<davmor2> oSoMoN: I think om26er is looking at it not sure he is on yet though
<sil2100> oSoMoN: I think Omer is testing it
<rvr> oSoMoN: om26er is not connected
<sil2100> Don't see him around right now, but he's the one that has it on his plate
<sil2100> davmor2, rvr: hey, any news on the ofono silo?
<sil2100> Did they rebuild it and re-handed-over for testing?
<rvr> davmor2: ?
<oSoMoN> om26er, hey, whatâs the status of testing on silo 21 ?
<om26er> oSoMoN, in progress, I just signed in, Will be tested in an hour.
<oSoMoN> om26er, thanks. you had questions yesterday, sorry I wasnât around to answer them, did you manage to get everything answered?
<om26er> oSoMoN, yes, Bill answered them later in the day but unfortunately I was near EOD then.
<oSoMoN> ok
<pmcgowan> oSoMoN, so per your last report the tabs behavior is not new?
<oSoMoN> pmcgowan, correct, it exists on the current vivid-proposed image
<pmcgowan> oSoMoN, so while thats not good, it would say to me we can land 1.7
<oSoMoN> pmcgowan, yes, in any case itâs very unlikely that this issue is linked to oxide at all (the tabs list view uses image captures, not live webviews)
<sil2100> Oh, it does?
<sil2100> Then why didn't QA accept it?
<sil2100> davmor2: ^ did you compare with webbrowser in the old oxide?
<pmcgowan> oSoMoN, yeah I wondered about that
<pmcgowan> more arale graphics dependent
<sil2100> Then there's some serious misinformation going on here
<oSoMoN> yeah, it really feels like something lower down in the graphics stack
<pmcgowan> sil2100, I think just an assumption as not previously reported for some reason
<pmcgowan> sil2100, so lets see if we can land that silo now
<sil2100> davmor2, rvr, om26er: can we get anyone of you guys signing-off the oxide silo once again?
<davmor2> sil2100: so silo16 is good to go as is if that is the consensus. it's only blocked due to the tab behaviour
<davmor2> pmcgowan: ^
<sil2100> Ok, setting it to signed-off and publishing
<pmcgowan> davmor2, vg
<sil2100> chrisccoulson: you have PPU rights for oxide, right?
<cwayne> sil2100, did that unity-api fix for favorited scopes make it in?
<sil2100> mandel: hey!
<sil2100> mandel: http://bazaar.launchpad.net/~mandel/location-service/better-position-selection/revision/202 has not been built in silo 24
<mandel> sil2100, triggering, sorry some docs updates and forgot
<sil2100> mandel: it's a change in code, but this basically shouldn't require a re-test I suppose...
<mandel> sil2100, nope, is just adding a const to a method and some typos
<sil2100> mandel: anyway, let's rebuild and re-push
<sil2100> Mirv, tsdgeos: any news on the hang by any chance? ;)
<mandel> sil2100, is building already, sorry for that
<sil2100> No worries, there was so many things today that I missed pinging you actually
<tsdgeos> sil2100: i haven't been doing any of that today, left it in Mirv's hands
 * sil2100 needs to AFK for a bit, bbl
<Mirv> tsdgeos: did you note my question about workarounds 2.5h ago or did your network eat it?
<tsdgeos> Mirv: that was me being at lunch and then not realizing, sorry :/
<tsdgeos> Mirv: so i take delaying nm wasn't good?
<Mirv> tsdgeos: yes, at least not enough on arale. plus, we might have over 50 reboots without problems currently so testing a fix or workaround would require a hundred or so.
<Mirv> but given how the boot problem came to be, some workaround should be realistic
<tsdgeos> i disagree
<tsdgeos> Mirv: anyway delaying metrics is kind of hard
<tsdgeos> since it's the first thing that you see on the phone
<tsdgeos> delaying that is not a good idea i'd say
<ogra_> sil2100, is there also a ringtone related rc blocker open currently ?
<ogra_> (just got asked in  meeting)
<Mirv> tsdgeos: a 1s delay in the right spot for example when NM is still initializing wouldn't too bad, but I'm open to any suggestions to avoid parallel qdbus usage during boot up
<Mirv> tsdgeos: I'm not sure if nm is only called when indicators are shown, but optimally the deparallization would happen when ubuntu logo is still spinning.
<tsdgeos> Mirv: no nm has nothing to do with the indicators in here, it's qt's internal nm backend, not the "indicator nm" backend
<Mirv> tsdgeos: you know it the best, I was just guessing why they overlap
<tsdgeos> Mirv: honestly i don't know much more than you
<mandel> sil2100, build done successfully, no need to test the addition of const to a var
<oSoMoN> trainguards: QA signed off silo 21, can it be published, please?
<Mirv> tsdgeos: yeah, but you might throw some MP:s showing example how to affect unity8 calling things that call qdbus. the key would be to first have a bad workaround that works, and when we know we can have a workaround, we can think how the workaround could be non user visible. of course there may be other components besides u8 to tinker, like whatever calls qt nm backend (I thought it might be indicator)
<tsdgeos> Mirv: i don't think i'll be able to work on that, i'm on london next week on a sprint
<Mirv> tsdgeos: ok. of course all about prioritization at the end. I can try continue trying things I can think of.
<oSoMoN> trainguard: ping? (re silo 21)
<oSoMoN> I meant, trainguards
<rvr> The team named '~ci-train-ppa-service' has no PPA named 'ubuntu/landing-026'
<rvr> Hmm
<robru> oSoMoN: done
<rvr> robru: Have you changed anything or it is me?
<robru> rvr: the ppa would be named 'landing-026'
<oSoMoN> robru, thanks man!
<robru> oSoMoN: you're welcome
<robru> rvr: what tool are you using that gave that error?
<rvr> robru: I updated yesterday to Vivid, so maybe my phablet-tools-citrain is not the correct one
<robru> rvr: the version in vivid should be fine, I haven't touched that code in quite a while...
<robru> rvr: what's the command you ran?
<rvr> citrain device-upgrade 26 <passwd>
<robru> rvr: hm it worked for me...
<robru> rvr: where did the error come from? phablet-config? can you show me a paste of the command output?
<rvr> robru: http://paste.ubuntu.com/10879757/
<robru> rvr: what image is flashed on your phone? that sounds like you have an ancient version of add-apt-repository from before rtm split
<rvr> robru: Thing is, this worked before
<rvr> I was just reflashing to check an issue without and then with the silo
<robru> rvr: right. so the thing is, nothing changed in citrain script in many many months ;-) citrain calls phablet-config, phablet-config calls add-apt-repository. So for some reason you got a version of add-apt-repository that doesn't understand ppa:team/distro/ppa-name syntax
<rvr> Weird
<rvr> Well, manually it works o_O
<robru> rvr: https://pastebin.canonical.com/130321/ here's my paste, worked fine. that's on krillin, not sure what image number though
<rvr> robru: launchpad connection is very slow, maybe is that
<robru> mandel: https://code.launchpad.net/~thomas-voss/location-service/fix-1447161/+merge/257097 need this approved.
<rvr> Approving silo 26
<sil2100> Back
<ogra_> rvr, were you looking into silo 02 before ... seems there is a wrong test plan and i cant log in to the spreadsheet to change it
<sil2100> ogra_: what test plan should it have?
<sil2100> I can change it
<ogra_> "install the VibrateMe app, set vibration to 20sec ... suspend the phone via power button ... without fix it wont stop, with fix it will stop vibrating after the selected time"
<ogra_> (the current test plan completely works around the usensord API we want to test by using sysfs)
<robru> rvr: did you mark it in the spreadsheet?
<sil2100> ogra_: modified o/
 * ogra_ hugs sil2100 
<ogra_> sil2100, did you see my ping in the backlog ?
<sil2100> robru, rvr: I published silo 26, it's a critical
<ogra_> ChickenCutlass, asked me about a ringtone bug he thought was an RC blocker
<sil2100> ogra_: let me check that
<ChickenCutlass> ogra_ yes pmcgowan has the bug number
<ogra_> since i dont remember that being mentioned in the LT meeting i thought i'd betetr ask you :)
<rvr> ogra_: silo 2 is alesage
<sil2100> ogra_: hm, yeah, I don't see it in the priorities spreadsheet, but I remember seeing the bug somewhere before
<rvr> robru: Yeah, I marked it
<pmcgowan> https://bugs.launchpad.net/ubuntu/+source/telephony-service/+bug/1447606
<ubot5> Ubuntu bug 1447606 in Canonical System Image " incoming call ringtone is not played repeatedly" [Critical,In progress]
<ogra_> rvr, thanks ...
<ogra_> sil2100, i guess we want that on the blocker list :)
<alesage> ogra_, validating that now
<ogra_> alesage, thanks
<sil2100> Hah, I knew I saw this bug somewhere, but the title was misleading ;)
<robru> oh, queuebot has been offline since noon yesterday
<sil2100> Yeah, it's on the blocker list
<ogra_> (likely needs krillin as this is the only device actually going to deep sleep)
<ogra_> sil2100, awesome, thanks
<ogra_> ChickenCutlass, all fine then
<alesage> ogra_, that helps thanks
<ChickenCutlass> great
* robru 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: devel (vivid) touch landing gates now closed! queuebot is on vacation, please ping trainguards manually
<sil2100> pmcgowan: the vibration fix just landed \o/
<pmcgowan> sil2100, nice, just hit that this morning
<sil2100> queuebot: welcome back!
* robru 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: devel (vivid) touch landing gates now closed!
<sil2100> pmcgowan: btw. what magic could you do to make tsdgeos and maybe some people from Unity8 help Mirv with the unity8 hang-on-boot issue?
<sil2100> Since that's the biggest thing blocking us from testing, and I think it would require as many people possible working on this starting next week
<pmcgowan> sil2100, agreed will see where I can find more eyes on it
<cjwatson> heads-up, you may have problems publishing anything that started building in silos between about 13:26 and 17:59 UTC today due to us having to revert the switch to new-style ddebs until we fix a problem with it
<cjwatson> #launchpad-ops internal if you need details
<cjwatson> (I'm afraid I have to go and can't help further, but some information is better than none)
<davmor2> sil2100: pmcgowan, abeato: after a rocky start silo 007 is good.
<pmcgowan> yay
<pmcgowan> abeato, do we need to tweak rtm silo 0 also?
<ChrisTownsend> cihelp: Hi!  We've been seeing a weird failure on our 386 Unity CI runs.  For example: https://jenkins.qa.ubuntu.com/job/unity-vivid-i386-ci/95/console
<ChrisTownsend> Notice that gdk is trying to open a Mir backend which is completely wrong.
<wgrant> camera-app in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-011/+packages will need to be rebuilt if it's heading for a primary archive.
<wgrant> But it looks like it's headed for the overlay PPA, in which case it's fine.
<wgrant> sil2100: ^^
<mandel> robru, is approved, right?
<sil2100> wgrant: yes, it's for the overlay PPA
<robru> mandel: well, it wasn't at the time I pinged, but then sil2100 rammed it through
<mandel> robru, ah, it should have, weird
<sil2100> pmcgowan: thanks :)
<sil2100> mandel: I overrode one unapproved branch as it was a blocker fix with high priority
<davmor2> pmcgowan: if it has the same fix in for puk code yes
<mandel> sil2100, perfectly ok, I though everything was approved, jhodapp went through both branches
<pmcgowan> davmor2, yeah I am not sure
<jhodapp> sil2100, mandel I had approved both branches
<sil2100> jhodapp: there was a branch from tvoss that wasn't approved IIRC
<sil2100> Anyway, all good now
<jhodapp> sil2100, ok great
<davmor2> pmcgowan: on a plus side I have a crapped out sim to test it with now
<pmcgowan> its the little things
<pmcgowan> davmor2, very funny btw, robot overlords
<davmor2> pmcgowan: thought it would be appreciated :)
<cjwatson> Ah, perhaps my publishing warning doesn't apply to vivid, because you're sending everything to the overlay PPA.
<cjwatson> It will probably still apply to ubuntu-rtm/14.09.
<cjwatson> And I see wgrant worked that out before me :)
<cjwatson> wgrant: How did that work?  Presumably the overlay PPA has ddebs switched off too ...
<cjwatson> Oh, the check is just for primaries isn't it
<wgrant> cjwatson: Yes, it's just that I didn't want weird stuff in the primary archive that gets sent out to mirrors and blah.
<wgrant> The check is really obsolete now that publish_debug_symbols is a flag.
<wgrant> I may just remove the check on Monday.
<ChrisTownsend> cihelp: Anybody available to help today?
<fginther> ChrisTownsend, sorry about that. I'll have a look
<ChrisTownsend> fginther: Ok, no worries, just didn't know if I should ping again on Monday:)
<ChrisTownsend> fginther: And thanks
<fginther> ChrisTownsend, I don't see anything obviously wrong just yet. I've kicked off a couple of test builds to see if something has gone wrong with that specific builder. Will get back to you when that's finished
<ChrisTownsend> fginther: Ok, it's very strange.  I've seen this on 2 separate MP's only on 386.
<fginther> ChrisTownsend, these builders are also used for mir, which made me think there was a possible process leak that caused the problem, but I don't see any evidence of that yet, it was just my first guess
<ChrisTownsend> fginther: Ok, thanks
<jhodapp> robru, can I please get a silo for line 55?
<robru> jhodapp: one sec
<jhodapp> k
<robru> jhodapp: silo 2
<jhodapp> thanks robru
<robru> jhodapp: you're welcome
<alecu> ping trainguards: hi! I'm trying to reconfigure ubuntu/landing-014, and I get this: """ERROR unity-scope-click was not in the initial list of components for that silo. Please ask the trainguards to reconfigure this silo for you."""
<sil2100> alecu: hey! Yeah, we'll reconfigure it for you in a moment
<alecu> thanks! but isn't it like 4AM in your timezone? you should have eowd already!
<alecu> :-)
<sil2100> Noo, it's midnight here, still early
<sil2100> Although I need to go to sleep soon since I need to wake up in 7 hours for practice
<sil2100> alecu: reconfiguring
<cwayne_> sil2100, psh, who gets 7 hours of sleep :P
<sil2100> cwayne_: hey, if I finish work now I won't be able to go to sleep straight away ;p
<sil2100> I'll be lucky to be done with everything in an hour ;)
<cwayne_> not with that attitude you won't
<sil2100> I think I'll kick a new image in the meantime
<alecu> thanks!
<imgbot> === IMAGE 185 building (started: 20150424-22:15) ===
<sil2100> o/
<imgbot> === IMAGE 185 DONE (finished: 20150424-23:35) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/185.changes ===
#ubuntu-ci-eng 2016-04-25
<dbarth_> jibel: o/ i commented on the oxide silo card; we found a regression so we'll need to respin a build
<jibel> dbarth_, silo 38?
<jibel> okay
<dbarth_> jibel: yes silo 38; sorry
<charles> grumble
<jin_> jibel, Hello jibel,
<jin_> could you help us to approve this one in your Trello?
<jin_> jibel, https://requests.ci-train.ubuntu.com/#/ticket/1312
<jin_> jibel, we will have a release about Telegram
<jin_> sil2100, hey man
<sil2100> jin_: hey!
<jin_> sil2100, HI!!!
<jin_> we will have a release of Telegram
<jin_> could you help to sign off that? since it is a click package request
<jin_> sil2100, this one! https://requests.ci-train.ubuntu.com/#/ticket/1312
<jibel> jin_, set to ready for QA. I'll be on our board soon.
<sil2100> jin_: ^
<jin_> jibel, super!!!!!
<jin_> sil2100, hey thanks man!!
<sil2100> jin_: I didn't do anything really ;) It's all in QA's hands now
<jin_> sil2100, OKAY, I gotcha man!
<Saviq> kgunn, jibel, I think the only reason for mir 0.22 not being ready for QA is something with s390x in the builders
<Saviq> Mirv, can you recap â?
<jibel> Saviq, okay, that answers my question. Thanks.
<kgunn> oh boy
<Mirv> Saviq: jibel: yeah s390x autopkgtests are stuck due to s390x machines failing, but there is no other blocking issue on silo 019
<Mirv> mzanetti: I think it would be useful (at least I'd be interested) documenting why removing stuff adds support in https://code.launchpad.net/~mzanetti/ubuntu-touch-session/enable-obex-push/+merge/291978 - and what are the opp and filesystem removed
<Mirv> mzanetti: like a comment in the MP
<mzanetti> Mirv, done
<tedg> So I've fixed an issue on the card in the QA tracker. I put a comment in. Is there anything else I'm supposed to do?
<dobey> tedg: wait patiently ?
<tedg> Hehe, I can do that.
 * tedg waits
 * tedg waits
 * tedg waits
<tedg> Hmm, perhaps not.
<tedg> ;-)
<dobey> !patience | tedg
<ubot5> tedg: Don't feel ignored and repeat your question quickly; if nobody knows your answer, nobody will answer you. While you wait, try searching https://help.ubuntu.com or http://ubuntuforums.org or http://askubuntu.com/
<dobey> tedg: or ping whomever was testing it i guess, if it's urgent
<tedg> It's not that urgent, just wanted to make sure I was using the tools right.
<Mirv> mzanetti: cool, fun option :)
<rvr> mzanetti: Saviq: Silo 13 approved
<Saviq> rvr, \o/
<salem_> jibel, ping
<jibel> salem_, pong
<salem_> jibel, hey, just wanted to check if we have any update on silo 55 with the unity8 test failures. Can we get that silo on the testing queue?
<jibel> salem_, why is unity8 failng?
<salem_> jibel, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-vivid-ci-train-ppa-service-landing-055/vivid/armhf/u/unity8/20160418_180555@/log.gz
<salem_> jibel, I don't know, I thought that was a known issue.
<jibel> salem_, I don't know. Did you ask the unity8 team?
<salem_> Saviq, ^^ do you know if this is a known issue?
<jibel> salem_, this patch touches something related to account service and the failing test is the account page in the wizard.
<jibel> salem_, maybe it's a coincidence but worth checking
<jibel> but it fails on only one arch
<salem_> jibel, yes, that's why I believe it's unlikely to be caused by our patch. I had this very same problem on a past telephony-service landing.
<jibel> salem_, we didn't force silos recently due to flaky tests in unity8
<salem_> jibel, I think this is the silo I am talking about: https://requests.ci-train.ubuntu.com/#/ticket/1203
<jibel> salem_, get a confirmation from the unity8 team and we can move on. Otherwise you can also re-run the tests on i386
<salem_> jibel, ok, thanks
<AlbertA> trainguards: any ideas why the s390x tests just never complete? https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-019/excuses.html
<dobey> AlbertA: i gues that only gets updated once every 50m-1hr now, so perhaps should get updated the next pass
<dobey> (as i don't see anything on the running.shtml anyway)
<AlbertA> dobey: thanks, it's been like that for 4 hrs though... normal?
<dobey> 4 hours?
<dobey> the generated time says it was generated an hour ago
<dobey> the s390x tests might have only finished in the last hour?
<dobey> oh, now it's just updated again and still in progress
<dobey> robru: ^^ any idea
<AlbertA> dobey: yeah I hit approve on https://requests.ci-train.ubuntu.com/#/ticket/1303 about 4 hours ago... all other tests have finished
<AlbertA> except those... and not sure if they are even running
<dobey> AlbertA: right, but when you hit approve is unrelated to when they actually run :)
<dobey> other than they will run sometime after that
<AlbertA> ok
<dobey> but i don't see them in the queue, so i can only assume they've already finished
<dobey> and now the xenial queue is empty on http://autopkgtest.ubuntu.com/running.shtml
<dobey> so i guess something is certainly wrong there
<dobey> but i don't know what. i'd say we need to get robru to poke
<AlbertA> dobey: I see thanks
<sil2100> hmmm
<sil2100> Well, robru is on leave this week, so this might be tricky
<dobey> oh
<robru> sil2100: dobey more of an issue for pitti
<robru> Fortunately the debug logs are still enabled from last time
<robru> Also qa status can be overridden even if britney fails so no big deal
<sil2100> AlbertA: could you poke pitti about it on #ubuntu-devel or #ubuntu-touch ?
<robru> Bbl
<AlbertA> sil2100: yeah thanks
#ubuntu-ci-eng 2016-04-26
<tedg> Looking for a MOTU or core-dev to help publish a silo, anyone around?
<tedg> Specifically: https://requests.ci-train.ubuntu.com/#/ticket/1292
<Mirv> tedg: publishing
<sil2100> oSoMoN, dbarth_: hey guys! How's work on https://requests.ci-train.ubuntu.com/#/ticket/1286 going?
<oSoMoN> sil2100, Iâm validating it again as IÂ write, hopefully that build is the last one
<dbarth_>  sil2100: same for webapps
<sil2100> Excellent, thanks!
<sil2100> jibel: I suppose it would be really cool if we could do a OTA-10.1 re-spin for the emulator with the oxide fix in it
<sil2100> oSoMoN, dbarth_: are there any other changes in the new oxide besides the fix for the emulator?
<dbarth_> sil2100: a fix for the regression
<oSoMoN> sil2100, yes, itâs a new version of oxide (1.13 -> 1.14)
<dbarth_> sil2100: here: https://bugs.launchpad.net/oxide/1.14/+bugs
<ubot5> Ubuntu bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress]
<dbarth_> the critical one
<sil2100> Ouch, that might be a bit complicating stuff
<oSoMoN> sil2100, see https://bazaar.launchpad.net/~oxide-developers/oxide/packaging.xenial/view/head:/debian/changelog
<jibel> sil2100, sure we could release the emulator only
<om26er> sil2100, Hi! can you tell when does a .click package gets into the image ?
<om26er> there was a release of dekko last week and its still not in the image, or am I missing something ?
<sil2100> om26er: hey!
<sil2100> om26er: so it's a bit complicated as most of our clicks are shipped with our images through custom tarballs
<sil2100> So as long as no new device tarball was published, the new versions won't be pre-installed
<sil2100> *device=custom
<om26er> sil2100, how can I request a new tarball ?
<sil2100> om26er: you need to reach out to penk, he's the one currently taking care of those... sadly currently the custom tarball release part is a bit detached from ours
<sil2100> I could also prepare one, but I have no idea if they don't have any other changes staged
<sil2100> You can find penk on our internal channels, he's on a Chinese timezone
<sil2100> (or by e-mail)
<om26er> sil2100, hmm, sounds complicated. Will talk to penk
<dbarth_> sil2100: i just marked silo 38 approved again, ie the newest oxide build
<sil2100> \o/
<pstolowski> jibel, qa hello, fyi, since silo 71 is not yet under testing, i'm currently adding a few more MPs to it & rebuilding, so this silo will be ready later today
<jibel> pstolowski, no problem. I removed the card another one will be created when it is ready for testing again
<rvr> ChrisTownsend: Silo 80 approved
<nik90> rvr, Hi, once again, I'm here if you have any questions about uNav :)
<rvr> nik90: Ack :)
<robru> sil2100: hey what's the plan for dual silos? I'm around to flip the switch to yakkity if you need
<robru> sil2100: https://code.launchpad.net/~robru/bileto/yakkity/+merge/292991
<robru> sil2100: what's the plan for duals? steve says it's not as simple as just s/xenial+/yakkety+/
<robru> sil2100: I've undone the change where the primary series of a dual silo is targetted at overlay ppa at least.
<dobey> triples!
<robru> dobey: for real? seems nobody is around
<dobey> robru: yes. i don't see why it shouldn't be possible to do a triple landing
<robru> dobey: obviously it's possible to do a triple landing it's just an insane burden to expect people to validate three different sets of packages on three different releases. (or 6 different sets of packages in the case of GLES stuff)
<dobey> robru: what do you mean by validate? it's not like previously we had qa running tests for xenial builds; otherwise i guess the xenial phone images would work
<dobey> robru: maybe it's not a good thing for GLES (i don't know for sure), but it's certainly valid for some packages
<robru> dobey: I mean the developers are required to ensure that their builds work in both xenial & vivid before sending to qa.
<dobey> as long as we have to support vivid-overlay anyway
<dobey> robru: well, "work"
<dobey> robru: there's no way to ensure stuff works when the phone won't boot
<robru> dobey: I don't understand why we bother to have duals at all if people are just dumping untested garbage all over xenial.
<dobey> robru: well it's not entirely untested, and certainly not garbage
<dobey> we're probably doing more testing than is done for a lot of the stuff that's just copied over from debian unstable
<dobey> if only via unit/integration/autopilot tests
<bregma> that doesn't look right
<dobey> fun
<bregma> I'm just guessing, but the fringe-area localizer has stopped meshing with the grapple grommet somewhere?
<bregma> perhaps the Filbert flange is out of quarter?
<bregma> try reversing the polarity of the neutron flow across the flux capacitor
<kenvandine> oh joy... train wreck
<bregma> maybe just try turning it off and back on again?
<kenvandine> :)
<kenvandine> bregma, but i'm not from IT
<kenvandine> lol
<robru> Oh jeez
<robru> I'm here
<robru> ok I have a fix on trunk, should hit prod within an hour
<robru> dobey: bregma: kenvandine: ^
<robru> my bad guys, sorry
<bregma> :)
<kenvandine> robru, thx
<robru> kenvandine: yw
<kenvandine> yay... it's working :)
<bfiller> robru: could you rebuild indicator-datetime for i386 on silo 9 please?
<robru> bfiller: done
<bfiller> robru: thank you
<robru> bfiller: you're welcome
#ubuntu-ci-eng 2016-04-27
<Mirv> robru: ^ we've that kind of errors
<Mirv> I see there have been changes in the trunk
<Mirv> (of cupstream2distro)
<Mirv> but sil2100 can look at it when he's up
<robru> bzoltan_: Mirv: terribly sorry, I've identified the issue, working on a fix.
<robru> bzoltan_: Mirv: ok I've pushed a fix to trunk, you should see that hit production in 10 minutes, deepest apologies.
<robru> Alright looks good, I'm off
<greyback> trainguards: hey, would it be possible to re-kick this build: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-069/+build/9637542
<greyback> it succeeds with all other arches & on all xenial builds, just i386 vivid failed. Suspect flaky test
<sil2100> greyback: on it
<Mirv> thanks robru!
<oSoMoN> Mirv, I confirm that silo 42 fixes bug #1488364
<ubot5> bug 1488364 in Oxide "[Qt 5.5] OxideQSslCertificate::issuer doesn't work in Qml" [Medium,Triaged] https://launchpad.net/bugs/1488364
<Mirv> oSoMoN: thanks!
<oSoMoN> Mirv, thanks to you for the backport!
<Mirv> you're welcome
<pstolowski> hey trainguards, got autopkg failure https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-071/xenial/armhf/u/unity-scope-click/20160427_085222@/log.gz which seems unrelated to the changes in silo 71
<pstolowski> a dependency problem
<charles> flaky test
<charles> grumble
<bzoltan_> robru:  no probs thanks for fixing it
<pstolowski> sil2100, hey, can you help with silo 71 again? see my earlier msg above
<sil2100> pstolowski: hey!
<sil2100> pstolowski: sorry, was in a meeting, let me take a look
<mzanetti> jibel, hey, tiagosh told me you were blocking their silo on a unity8 failure
<mzanetti> jibel, if it's "qmltestrunner::Wizard::test_accountPage()" that's a known issue (flakiness) in unity8 and not their fault. We have a fix for it in silo 27
<jibel> mzanetti, I am not blocking anything :)
<mzanetti> hmm... ok, that was the information I got
<jibel> mzanetti, I am just not forcing a silo without understanding why it's failing
<jibel> mzanetti, yeah that's the test
<mzanetti> right. so it is failing because of britney being muuuch slower than our jenkins. it passes in our jenkins but is flaky (rather constantly) on britney
<mzanetti> so, just to let you know that this particular test failure is not the app's silo's fault
<jibel> mzanetti, okay, I just needed a confirmation from the unity8 team
<mzanetti> ack
<mzanetti> thanks
<jibel> salem_, silo 55 marked ready for qa. It should land today or tomorrrow
<salem_> jibel, awesome, thank you!
<pstolowski> sil2100, hey, have you found anything about silo 71? I just rebuild a while ago and got depednency error again (click scope, xenial only)
<sil2100> pstolowski: yeah, looked at it and again looking, hard to say what might be the cause here - did you poke the unity8 guys if they saw such an error on their silos before?
<sil2100> (since it's part of unity8's autopkgtest deps)
<pstolowski> sil2100, hmm i think i was looking at older version of excuses after rebuilding it.. apparently click scope tests is still in progress
<sil2100> I don't see them running on the autopkgtest page though
<sil2100> pstolowski: could you maybe try poking pitti? He has much more experience in autopkgtests, he might know if those are running or something died horribly
<tedg> Hello, I need a MOTU/core-dev to publish this silo for me please: https://requests.ci-train.ubuntu.com/#/ticket/1305
<sil2100> tedg: hey! I checked it briefly in the morning, did you have someone doing a preNEW review (from the archive admins)?
<tedg> sil2100: I asked seb128 to review the packaging, but I'm not sure what else is needed.
<tedg> (and I fixed the things he asked me to)
<seb128> tedg, the packaging looked good out of the few things I pointed out
<tedg> Happy to follow other steps as needed, but I'm not sure what they are.
<sil2100> seb128: if it got your blessing then I guess it's good to go ;)
 * sil2100 can proceed with publishing then
<pstolowski> sil2100, will do, thanks
<seb128> sil2100, tedg, I can have another look but not today, at a sprint and wrapping up now
<sil2100> seb128: ok, will wait for a final ACK from you
<sil2100> tedg: would it be ok with you to wait till tomorrow ^ ?
<seb128> tedg, it was looking good so probably fine, feel free to land
<sil2100> Since an archive admin needs to +1 it since this lands straight to xenial-overlay right now, so a NEW-like review is in order
<tedg> sil2100: Yes, I think that's fine, it does have a couple strings in it. So end of the week would be good.
<tedg> sil2100: After that, how do we do seed changes for overlays? https://code.launchpad.net/~ted/ubuntu-seeds/policy-kit/+merge/291966
<sil2100> tedg: we have local branched-off versions in the overlay that we manually upload - I can pick up this change from you and push it to the xenial and vivid overlays
<sil2100> Right now it's a bit complicated as we're still not doing landings for yakkety, but yeah, leave it on my plate and I'll make sure it's in all the right places
 * sil2100 puts it on his list
<tedg> sil2100: Ah, I see, cool, thank you!
<oSoMoN> sil2100, could you please publish silo 38, when you have a moment?
<sil2100> oSoMoN: sure, on it now
<sil2100> Wooo \o/
<bzoltan_> sil2100:  When is the feature freeze for OTA11?
<davmor2> bzoltan_: string freeze is Friday, selected none string changes can land after that
<bzoltan_> davmor2: cool, thanks.. so my silo can still make it :)
<jibel> bzoltan_, which silo?
<oSoMoN> trainguards: automated signoff of silo 10 failed, but looking at the failure (in unity8âs qmluitests), itâs obvious itâs got nothing to do with browser changes, can someone with the appropriate permissions re-run that test please? I donât seem to be allowed
#ubuntu-ci-eng 2016-04-28
<bregma> hey robru question for you: I have an old silo with a bunch of MPs for packages I want to get rid of, is there a way to remove them or should I just abandon the silo and start afresh?
<robru> bregma: you can abandon and reassign the same ticket, no need to make a new ticket. I'm also capable of clearing out the old packages but I'm afk and in vacation ;-)
<bzoltan_> jibel: 047
<bzoltan_> jibel: https://requests.ci-train.ubuntu.com/#/ticket/1322
<jibel> bzoltan_, ok, it's already in our queue, I thought there was another one.
<jibel> bzoltan_, it should land this week
<bzoltan_> jibel:  given that you will not find a problem what I missed
<ToyKeeper> charles, ondra: Question for you on ticket 1299 (indicator-display): https://trello.com/c/gzf3hdwh/3111-1299-ubuntu-landing-035-indicator-display-charles-ondra
<bzoltan_> jibel: :)
<mterry> trainguards: got an odd publish error, what's this mean? https://ci-train.ubuntu.com/job/ubuntu-landing-033-2-publish/3/console
<robru> mterry: it means everything published successfully
<mterry> robru, got a funny way of showing it!
<robru> mterry: (the error is that there's no artifacts, artifacts are only used for publishing to archive, but duals go to overlay ppa)
<robru> mterry: yeah Jenkins is poorly configured, sorry
<mterry> robru, huh ok I get that
<mterry> robru, but yup ^ merging, cool
<mterry> robru, thanks man
<robru> mterry: you're welcome. Jenkins is slowly on its way out so things will make more sense eventually
<oSoMoN> Mirv, good morning! do you have permissions to re-run the failed run at https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-010/excuses.html ? I apparently donât
<jibel> sil2100, do I need a silo to revert lxc in xenial in the overlay or you just copy the packges?
<oSoMoN> jibel, do you know if there are packages in the archive with autopkgtests that run autopilot tests? I wanna do that for webbrowser-app but getting "X11: DisplayNameError('',)" when the tests are run by britney
<sil2100> jibel: let me just copy those over, only the lxc source was needing revert right?
<sil2100> What about the fixed lxc-android-config?
<jibel> yeah we'd need to revert to lxc 2.0.0~rc2-0ubuntu2
<jibel> sil2100, and this change in lxc-android-config.conf http://paste.ubuntu.com/16092480/
<jibel> sil2100, devel-proposed won't be awesome, but at least it'll boot
<jibel> (all the scopes are blank, cannot setup wifi, cellular connection is unreliable, clicks don't work, lot of blank pages everywhere, ...)
<sil2100> Ok
<sil2100> Remember, devel-proposed is yakkety right now, so staging will be awesome - I'll leave yakkety as it is
<jibel> sil2100, right, staging
<jibel> won't be awesome either
<oSoMoN> sil2100, hey, do you have permissions to re-run the failed run at https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-010/excuses.html ? I apparently donât
<Saviq> mterry, can you recycle for oSoMoN â
<Saviq> and we really need to look into the wizard tests
<sil2100> oSoMoN: on it
<sil2100> oSoMoN: re-running
<jibel> oSoMoN, not from the top of my head. Maybe autopilot itself?
<oSoMoN> Saviq, sil2100: thanks
<oSoMoN> Saviq, is that test known to be flaky?
<Saviq> oSoMoN, yes
<oSoMoN> :/
<oSoMoN> jibel, thanks, Iâll check autopilot itself
<jibel> oSoMoN, if the failing test is test_account something, it's a know flaky test fixed in another silo
<oSoMoN> good
<Saviq> oSoMoN, we've got a landing which fixes that up for QA already, though
<oSoMoN> jibel, given that itâs the only failed test and that itâs known to be flaky, is it really worth a re-run? or can silo 10 go to QA validation directly maybe?
<jibel> oSoMoN, I'll move it to ready
<oSoMoN> cheers
<oSoMoN> autopilot doesnât seem to have autopkgtests
<jibel> oSoMoN, we have a discussion next week to run autopilot tests as part of the landings after autopkgtests and before manual verification
<jibel> oSoMoN, we'll start with unity8 but can also involve you in the discussion if you want to
<oSoMoN> jibel, fwiw I always run the autopilot tests myself on at least one device and desktop before marking a silo ready for QA, and I would expect others to do the same
<oSoMoN> running the tests really is (should be) part of the development process
<Mirv> oSoMoN: mterry sorry guys I'm not feeling well today
<jibel> davmor2, ^ thanks!
<davmor2> jibel: no worries nice improvement in speed/flow on krillin and frieza with it :) which I'm sure Mirv will confirm for you :)
<jibel> davmor2, I confirm. I tried it too
<rvr> Mirv: mzanetti: Apart from the usual location apps, anything else to check in silo 67?
<oSoMoN> jibel, Iâm not seeing silo 10 on the QA trello board, anything (other than the unity8 flaky test) blocking it?
<rvr> oSoMoN: Automated Signoff	Failed
<rvr> oSoMoN: I think is that
<sil2100> \o/
<jibel> oSoMoN, looking
<jibel> oSoMoN, the status was still 'Required'
<jibel> changed again
<oSoMoN> jibel, thanks
<davmor2> and sil2100 there randomly cheering for himself
<sil2100> I'm just cheering for the mir silo, woo!
<sil2100> seb128: hey! We have a new ABI bump of mir with new sonames, can I get a +1 from your archive-admin binNEW powers on it? All looks good as always:
<sil2100> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-1303/2016-04-27_09:13:44/xenial/mir/packaging_changes.diff
<seb128> sil2100, why is that change not documented in the changelog?
<seb128> -               android-headers (>=4.4.2) [i386 amd64 armhf],
<seb128> +               android-headers-23,
<seb128> the arch list is not needed anymore?
<seb128> looks fine otherwise
<mzanetti> rvr, one sec, I'll give you an app to test with
<mzanetti> rvr, http://notyetthere.org/data/mambogps.mzanetti_0.1_armhf.click
<rvr> mzanetti: Ack
<mzanetti> rvr, without the silo, routing will not work
<mzanetti> rvr, with the silo, it should
<rvr> mzanetti: These test instructions should be added to the silo :-/
<mzanetti> rvr, right... sorry... I didn't set up that silo and Mirv did not know about this app
<rvr> mzanetti: How do I add a route?
<mzanetti> rvr, bottom edge
<rvr> mzanetti: Nice, it works
<mzanetti> cool :)
<rvr> Silo approved
<rvr> oSoMoN: Hi
<rvr> oSoMoN: I'm testing silo 10. I shared a link to twitter, but I can't see the title
<rvr> oSoMoN: Hmm.. reading the bug thread, seems it needs changes in other projects. So, anything special to check?
<oSoMoN> rvr, indeed, thereâs also a bug in content-hub, so there is no visible change in the browser atm
<oSoMoN> so nothing to check, really
<oSoMoN> rvr, you can check that when sharing a link the URL is correctly being shared (no regression)
<rvr> oSoMoN: Yeah, it shares the URL fine
<rvr> oSoMoN: Then, approving the silo
<oSoMoN> rvr, thanks
<oSoMoN> Mirv, sil2100: can one of you publish silo 10 please? Iâm not allowed to due to packaging changes
<kenvandine> tedg, did you get a preNEW review for silo 53?
<tedg> kenvandine: For the polkit agent?
<kenvandine> yeah
<tedg> kenvandine: Yes, I got seb128 to review it, and suggest changes. He wanted to double check those changes but is sprinting.
<kenvandine> ok
<kenvandine> tedg, so you made the changes right?
<tedg> kenvandine: Yes, of course :-)
<kenvandine> sure... :)
<kenvandine> tedg, i'm going to hold off publishing it then
<awe_> sil2100, morphis asked me about the required change to livecd-rootfs that we want to coordinate with the NM 1.2 landing
<awe_> it looks like davmor2 will finish silo testing today
<davmor2> morphis: get ready for it
<bzoltan_> Mirv: or sil2100: would you know somebody who could trigger a retest for this https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-047/excuses.html ?
<greyback> sil2100: hey, dednick and I flashed our mako with latest rc-proposed, but noticed that the mir version that is installed is from vivid, not from the overlay
<greyback> something seems to be preventing the newer mir installing
<greyback> sil2100: please ignore, whatever it was has gone away
<Mirv> bzoltan_: restarting
<Saviq> trainguards, can someone please copy oxide (both vivid and xenial) in ppa:saviq/train to silo 69, thanks!
<Saviq> (and potentially cancel the current builds so that we don't waste builders' time)
<Mirv> Saviq: done
<Saviq> Mirv, thanks
<Saviq> sil2100, can you please recycle the failure in https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-027/excuses.html - I'll keep an eye out for whether it repeats
<bzoltan_> Mirv:  would you do the same for th eamd64 too please https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-047/excuses.html
<kgunn> trainguards could someone retrigger arm64 vivid build on https://requests.ci-train.ubuntu.com/#/ticket/1336
<robru> kgunn: done
<kgunn> thanks
<robru> Yw
<jgdx> rvr, I'm here for an hour if you need anything
<tedg> When will xenial-overlay packages be pushed into Yakety
#ubuntu-ci-eng 2016-04-29
<oSoMoN> jibel, good morning! silo 15 is affected by the same unity8 flaky test that affected silo 10 yesterday :/ (https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-015/excuses.html), can that failure be ignored?
<oSoMoN> Mirv, alternatively, can the failed tests on https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-015/excuses.html be re-run please?
<mterry> good morning!
<jibel> oSoMoN, ^^ done
<jibel> morning
<mterry> jibel, (did you see my previous message about flaky silo 27 tests?  I timed out of irc soon after)
<jibel> mterry, I didn't
<mterry> jibel, hello!  silo 27 was ready for QA review earlier this week, but had to rebuild a package due to a mir release.  It's since been stuck in autopkg flaky test hell.  So it appears as "failed automated signoff" while I keep retrying tests.  Just wanted to let ya'll know it's actually ready to be tested.
<mterry> * mterry is retrying last failing test now
<mterry> ^ that was it
<mterry> jibel, oh...  I thought I'd had experiences where setting that field to Ready would immediately reset itself to Required if the automated tests weren't passed
<jibel> mterry, there is a magic incantation
<mterry> jibel, ah ok
 * mterry just wanted to make sure he wasn't crazy and fields really did change themselves  :)
<jibel> don't worry it really did
<oSoMoN> jibel, thanks
<Mirv> oSoMoN: rerun done too
* Mirv changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? Use JenkaaS: http://bit.ly/jenkins-docs | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known issues: robru on sick leave until May, sil2100 away on Friday, Mirv semi-sick..
<Mirv> but I'm around, today somewhat better than yesterday, no throwing up so far
<oSoMoN> Mirv, glad to hear that youâre feeling better! and thanks for the re-run
<ToyKeeper> charles, ondra: Question for you on ticket 1299 (indicator-display): https://trello.com/c/gzf3hdwh/3111-1299-ubuntu-landing-035-indicator-display-charles-ondra
<charles> ToyKeeper, shoot
<ToyKeeper> charles: Ah, the question is at the link.  Getting a crash which looks new, can't repro it without the silo.
<charles> eep!
<charles> looking
<charles> ondra, this crash ToyKeeper's seeing looks like an issue for you on adb ^
<ondra> charles I will have a look
<ondra> charles I have today off, so it will have to be next week though
<charles> so we're pushing this back past ota 11?
<charles> :/
<ToyKeeper> It doesn't seem like it should be caused by the silo, but I haven't been able to repro without it.
<jibel> charles, are there string changes?
<charles> jibel, no
<jibel> if not it can still land early next week
<charles> jibel, cool
<charles> ondra, happy weekend :)
<charles> ToyKeeper, I'm not seeing the crash, what setup are you testing on?
<ToyKeeper> charles: It was krillin rc-proposed 321 and arale rc-proposed 313.
 * ToyKeeper tries it again with 323+315.
<charles> ToyKeeper, I've got a krillin rc-proposed 323 here too, so maybe try that first :-)
<charles> ToyKeeper, hmm. I'm not seeing it on krillin rc-proposed 323 + citrain device-upgrade 35 ... after hitting yes in the popup prompt, I tried reconnecting w/phablet-shell after 10, 30, and 60 seconds, all succeeded, and nothing from adb in /var/crash
<charles> ToyKeeper, from your description it sounds like the interval is important
<ToyKeeper> charles: I got this just a moment ago: https://errors.ubuntu.com/oops/9fc10040-0deb-11e6-9ed8-fa163ef911dc
<ToyKeeper> ... following instructions in https://wiki.ubuntu.com/Process/Merges/TestPlan/indicator-display (adb-prompt-after-boot)
<charles> ok. Will walk through adb-prompt-after-boot
<ToyKeeper> (except I allowed adb connections and then connected, disconnected, then connected again to check for crashes)
<ToyKeeper> The usb disconnect/reconnect might be relevant, not sure.
<ToyKeeper> But I still don't see how the silo could cause it, since it's only a UI change.
<charles> ToyKeeper, yep, getting it here as well. Same config as before, tested with adb-prompt-after-boot and then reconnecting after 10, 30, 60 sec
<charles> I don't understand what in that silo could cause this
<charles> hmmm
<ToyKeeper> Seems like it must be a pre-existing issue which just hasn't triggered on its own due to poor luck or something.
<charles> ToyKeeper, one last thing before I punt this to Monday when ondra gets back
<charles> ToyKeeper, could you try one more time with a fresh install of silo 35?
<Wellark> trainguards: what does this error mean? https://ci-train.ubuntu.com/job/ubuntu-landing-067-0-status/8016/consoleFull
<oSoMoN> Mirv, would you mind publishing silo 15 for me, please? itâs got minor packaging changes
<popey> davmor2: rvr uploaded music 1003 to the store, thanks for your help!
<rvr> popey: You're welcome :)
<davmor2> popey: I only passed it on but I will bathe in the reflective glory ;)
<jgdx> rvr, there are no instructions
<jgdx> I have no means of testing this
<rvr> jgdx: We cannot release something untested
<jgdx> rvr, I mean then making an actual connection, we can test that the correct fields are set
<jgdx> rvr, http://pastebin.ubuntu.com/16124855/
<Wellark> davmor2: could this silo get a QA exemption: https://requests.ci-train.ubuntu.com/#/ticket/1342
<Wellark> only strings being added, no functional changes
<Wellark> davmor2: sorry, if you are not the right person to ask this
<rvr> jgdx: That test only checks that the data is saved. We should test the connection to an actual VPN, so we are 100% that what we deliver to users is working and there are no surprises.
<davmor2> Wellark: how do you mean a qa exemption, if it is a change it needs to land through qa, if it is just string changes then we can probably fast track it, but jibel would be the better person to speak to
<rvr> Wellark: I see some changes to the code as well
<rvr> Wellark: SwitchItem::UPtr Factory::newMobileDataSwitch()
<jgdx> rvr, I agree. Please fail the silo and I'll escalate this.
<rvr> Wellark: We surely can fast track it, but not direct approve it
<rvr> jgdx: No need to fail it, as it only needs a VPN somewhere. I will move it to the first lane.
<jgdx> rvr, who's going to provide the VPN servers?
<rvr> jgdx: In QA we don't have the time or resources to do that. And not sure IS can help.
<davmor2> jgdx, rvr: did pete-woods have an instance somewhere that had a vpn that covered all the instances?  The other alternative would be create a juju setup that can be launched and dropped as needed maybe
<Wellark> rvr: the code changes are trivial to introduce the strings to the code bases. nothing is actually done with the added lines
<jgdx> davmor2, if pete can provide QA with the infrastructure they need to test a slew of vpn scenario, great
<morphis> Mirv: ping
<jgdx> trainguards: hey, does this build [1] need any special parameters. I don't think it has required this before? [1] https://requests.ci-train.ubuntu.com/#/ticket/1343
<Mirv> oSoMoN: done
<Mirv> morphis: pong. I can only occasionally stay up.
* Mirv changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? Use JenkaaS: http://bit.ly/jenkins-docs | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known issues: robru on sick leave until May, sil2100 away on Friday, Mirv sick leave but occasionally around.
<Mirv> (but still, getting better today, I've been able to eat some)
<Mirv> jgdx: that might require more brain power I currently have, it complains as if the source would not have been properly prepared for CI Train (https://ci-train.ubuntu.com/job/ubuntu-landing-058-1-build/53/console), but .bzr-builddeb and debian/source/format seem fine to me
<Mirv> jgdx: it complains about the .gitignore/.bzrignore files under docs/example-server/ that are not even part of the MP, while the trunk of lp:ubuntu-push seems untouched since last CI Train landing so I'm a bit puzzled
<jgdx> Mirv, me too, but yeah. Get well!
<bfiller> fginther: could you please add the vivid overlay ppa to jenkins jobs for lp:indicator-datetime
<bfiller> fginther: this ppa specifically http://ppa.launchpad.net/ci-train-ppa-service/stable-phone-overlay/ubuntu/ vivid/main
<bfiller> renatu: ^^^^
<renatu> bfiller, the citrain works, we need only on jenkins jobs that run automatically on mr
<bfiller> renatu: yes, I asked to change the jenkins jobs
<renatu> bfiller, ok, sorry
<Saviq> rvr, hey, any issues with silo 27? got an ETA?
<rvr> Saviq: Just checked that libertine is working fine, still have to finish with minor changes
<rvr> Saviq: It will be done today
<Saviq> rvr, ack, thank you
<Saviq> mterry, mzanetti, FYI â
<mzanetti> :)
<mterry> \o/
<rvr> Saviq: mterry: One thing...
<mterry> hrm
<rvr> Saviq: mterry: In the launcher and the switcher, the libertine apps don't show any icon
<Saviq> intense
<Saviq> hum
<rvr> Do I file a bug for that?
<rvr> Is it expected?
<mterry> rvr, interesting...  I didn't notice that before.  Yes please.  That would be an ubuntu-app-launch bug
<rvr> mterry: https://bugs.launchpad.net/ubuntu/+source/ubuntu-app-launch/+bug/1576722
<ubot5> Ubuntu bug 1576722 in ubuntu-app-launch (Ubuntu) "No icons in the launcher and switcher for libertine apps" [Undecided,New]
<rvr> mterry: Would be great to fix that before OTA11
<rvr> It's specially ugly in the launcher
<jibel> morphis, ^^ done
<morphis> jibel: awesome!
<morphis> davmor2: ^^
<mterry> rvr, indeed
<mterry> tedg, ^ bug noticed during testing -- any ideas there?
<davmor2> \o/
<tedg> mterry: larry is working on a mega fix for that, like theme support and everything.
<tedg> mterry: It'll be a lot better than what we have.
<mterry> tedg, is ual returning nothing right now or something that u8 doesn't understand?
 * mterry just trying to figure out if there's a u8 side fix here too
<tedg> mterry: It's returning a very simplistic understanding of how icon themes work, so it doesn't always find the icon.
<tedg> mterry: https://code.launchpad.net/~larryprice/ubuntu-app-launch/find-theme-icons
 * tedg is literally reviewing the branch right now
<mterry> tedg, do you know of an app that we could install and see an actual icon?  just to confirm that it will work all fine once fixed?
<mterry> rvr, ^ looks like it's being worked on as we speak, but doubtful it will make ota11
<mterry> rvr, based on what tedg said, I suspect *some* (probably older / crappily-packaged) apps would actually show an icon still.  But most won't
<tedg> mterry: Can't find one... I'm looking.
<tedg> mterry: rvr: I think we'll be in for OTA11, we've got a week! :-)
<rvr> tedg: Go! :)
<tedg> mterry: No, the old code was worse that I thought, it'd basically only work if the desktop file had an absolute path.
<tedg> mterry: But what we're doing is having libertine-scope use the same code, so that if libertine scope shows an icon U8 should get the same icon.
<tedg> synergy or something like that
<mterry> tedg, hrm...  libertine scope shows an icon in this case (inkscape)
<mterry> tedg, so at least today (without that branch) the scope is a little smarter.  That's expected?
<mterry> inkscape.desktop seems to just specify "inkscape" as icon.  So yeah, u8 won't be able to find it
<tedg> mterry: Yes, next version of libertine-scope.
<mterry> tedg, cool
<tedg> mterry: larry is making both changes
<tedg> mterry: He was working on making the libertine-scope code better, but then I stole him to make UAL better :-)
<mterry> tedg, great.  My big fear was just that qtmir or u8 needed fixes, but sounds like no.  /me rests easier
<rvr> Saviq: mzanetti: This bug is not fixed https://code.launchpad.net/~lukas-kde/unity8/upcomingEventETA/+merge/292539
<mzanetti> rvr, how did you test it?
<rvr> mzanetti: I created an alarm for 16:00, and when it was less than a minute, the indicator was still showing 4 minutes
<rvr> I took a screenshot
<mzanetti> rvr, yeah, not fixed for alarms yet. only for calendar events...
<mzanetti> rvr, we discovered that quite late and decided to fix it in a new branch for alarms
<mzanetti> (for some reason I don't know alarms and calendars are ran through different code parts)
<mzanetti> there's some comments about this in the branch
<mzanetti> MP
<rvr> mzanetti: Ahh, ok
<Saviq> rvr, /me files a bug for OTA11 then
 * rvr tries with the calendar
<rvr> Saviq: Ack
<Saviq> rvr, bug #1576741
<ubot5> bug 1576741 in unity8 (Ubuntu) "Upcoming event ETA going out of sync" [High,Triaged] https://launchpad.net/bugs/1576741
<Wellark> jibel: hi. could I get a fasttrack qa signoff for this as it's only adding a string in the source tree but no functional changes:
<Wellark> https://requests.ci-train.ubuntu.com/#/ticket/1349
<jibel> Wellark, sure, when it's ready for qa
<Wellark> jibel: any idea how long it takes for the automated signoff?
<Wellark> like 15 minutes, 1h, 2h, etc.
<jibel> Wellark, no, it all depends on hw availability and length of the queue
<Wellark> ok
<jibel> can be a couple of minutes to ....
<rvr> mzanetti: I have a problem with calendar app and cannot create an event, is there any other way to test it?
<mzanetti> rvr, creating it on the google calendar and syncing it :/
<rvr> mzanetti: Good idea
<rvr> renatu: Do you know what's going on? https://bugs.launchpad.net/canonical-devices-system-image/+bug/1576752
<ubot5> Ubuntu bug 1576752 in Ubuntu Calendar App "Date and time not saved creating a new event" [Undecided,New]
<renatu> rvr, to use the calendar-app with rc image you need it from trunk
<renatu> rvr, I marked your bug as duplicated of this one: #1574502
<renatu> rvr, a new version of calendar app is planed for next week
<rvr> renatu: Ah, great!
<rvr> mzanetti: Sync'd with Google Calendar, confirmed that now it updates fine :)
<Saviq> w00t, /me has desktop notifications
<rvr> Saviq: jibel: Approving silo 27
<jibel> rvr, \o/ thnkas!
<jibel> thanks*
<awe_> jibel, did you follow the thread re: the livecd-rootfs landing on #phablet?  https://requests.ci-train.ubuntu.com/#/ticket/1352
<robru> jgdx: it is failing because you have .bzrignore and .gitignore in a subdirectory in your source tree... The tarball that gets created strips those out but then the source tree still has them so it's considered an illegal change. Can you refactor your project to not need those?
<robru> Wellark: that error means that the train built a version of u-s-s and pushed it to a lp branch, but the package it uploaded to the ppa could not be found. Could be caused by cancelling the build job at the wrong time, or a ppa upload failure. Try rebuilding if it's still an issue
<mterry> rvr, thanks for silo 27 review!  publishing  :)
 * mterry is excited to enable libertine goodness
<tedg> mterry: Installed larry's branch and I have icons on the panel and the switcher
<mterry> tedg, oooh great
<Saviq> rvr, awesomes, thanks
<Saviq> oh publish already!
<tedg> mterry: Saviq Is there a plan to do the background color thing like U7? The icons are there, but they look kinda dumb :-)
<tedg> https://usercontent.irccloud-cdn.com/file/S4dK2ITx/Switcher%20with%20icons
<rvr> tedg: Awesome!
<rvr> Good weekend, everyone!
<alex-abreu> alesage, ping
<alesage> alex-abreu, pong
<alex-abreu> alesage, not sure I understand why britney failed here https://requests.ci-train.ubuntu.com/#/ticket/1056
<alesage> alex-abreu, let's ask robru , I'm new to this format
<alex-abreu> what I can gather from it seems more like a glitch error than one related to the branches
<alesage> alex-abreu, would have to look at the history but yes it looks like an infrastructure thing
<alex-abreu> robru, ^ ?
<robru> alesage: alex-abreu: never seen that one before, seems to imply a problem on amd64. Try asking pitti
<alex-abreu> robru, do you know if he is around?
<robru> alex-abreu: well he's in Germany so probably EOW at this point. Sorry
<alex-abreu> robru, could you re trigger britney?
<robru> alex-abreu: maybe try asking some people in #ubuntu-release, they know more about britney than i do. Just make sure to link to the excuses page so they don't have to dig it up
<robru> alex-abreu: it runs every hour or so, i can't run it manually, no
<alesage> alex-abreu, jibel also might have an opinion here
<alesage> knowing absolutely nothing about, I wonder if a dependency change removed X/xvfb support for this build, e.g.
<alex-abreu> alesage, I asked #ubuntu-release, and there seem to be a packaging issue w/ the click package debian config, which is rather unfortunate since it is unrelated to the silo itself and has been there for ever
<alesage> alex-abreu, bad timing :)
<alex-abreu> alesage, yes the worst ...
<alex-abreu> robru, just wondering, in the case of a packaging change (dep update) do we have to flag the ppa/silo in a specific way?
<Saviq> robru, hey, https://ci-train.ubuntu.com/job/ubuntu-landing-027-2-publish/5/console Â¿?
<robru> alex-abreu: uh, no? The diff will indicate packaging changes
<robru> Saviq: yes, that is a successful publish
<Saviq> robru, tell that to bileto ;)
<Saviq> ah there we go
<robru> Saviq: bileto correctly indicates that the silo is landed, not sure what your issue is
<Saviq> robru, it didn't refresh
<Saviq> robru, but more than that, I was surprised by the red ball and FAILURE
<robru> Saviq: yes, Jenkins is poorly configured. It's just confused because there's no artifacts.
<Saviq> robru, ack, was just wondering if artifacts were in fact expected
<robru> Which there wouldn't be when everything is copied directly to overlay PPA
<Saviq> are we doing triple landings yet?...
<robru> Saviq: i implemented it but then i was told to hold off by Pat
<Saviq> ack
<robru> Saviq: apparently the plan is to keep duals as xenial and vivid, let yakkety lag while trying to get a working xenial image
<Saviq> ohkay
<alex-abreu> robru, think you could have a look at https://code.launchpad.net/~abreu-alexandre/webapps-core/packaging-fix/+merge/293441 ?
<robru> alex-abreu: seems reasonable to me but I'm not familiar with the package so i can't say if those deps are needed elsewhere.
<robru> alex-abreu: one thing that's weird is that britney only complained about amd64, your change drops the deps on all arches
<alex-abreu> robru, the package is rather meaningless actually, since it is just an empty shell ... the project just builds the click packages per se,
<alex-abreu> robru, yes the deps are actually wrong
<robru> alex-abreu: OK well lgtm then.
<alex-abreu> not sure why it was setup that way
<alex-abreu> alesage, i'll probably miss the window by a few hours then
<alesage> alex-abreu, alexabreu I'll be around for a while, feel free to ping
<alexabreu> robru, can you +1 https://code.launchpad.net/~abreu-alexandre/webapps-core/packaging-fix/+merge/293441 (if you are ok w/ it) ?
<kenvandine> alesage, we have a couple string changes in silo 10, should be really easy to validate
<kenvandine> alesage, autopkgtests haven't run yet
<alesage> kenvandine, I'm bribeable
<kenvandine> alesage, :-D
<robru> alexabreu: done
<alexabreu> robru, thx
<robru> alexabreu: you're welcome
#ubuntu-ci-eng 2016-04-30
<kenvandine> alesage, silo 10 passed autopkg tests
<kenvandine> but i guess it's too late
<kenvandine> alesage, oh.. it's under testing :)
<kenvandine> woot
<alesage> kenvandine, I'm finding that this silo removes unity8, what am I missing?
<kenvandine> that has nothing to do with the silo
<kenvandine> i bet it's the pinning
<kenvandine> so the landing from earlier today had a depends on a mir landing before it
<kenvandine> alesage, basically make sure you have the stable overlay ppa pinned as well as the silo ppa
<kenvandine> alesage, actually that makes no sense... i installed this silo with citrain a few hours ago
<kenvandine> it didn't remove unity8
<kenvandine> alesage, is your image the latest?
<kenvandine> you will need the image that was built earlier today
<alesage> kenvandine, yes we only work with the freshest images
<kenvandine> hmmm
<alesage> kenvandine, I'll do some manual installing
<kenvandine> thx
<kenvandine> i used citrain to install it on my mako and on my turbo
<kenvandine> worked on both
<kenvandine> but the landing from earlier that pulls in aethercast depends on mir 0.22 from the overlay
<kenvandine> and we had some problems with images that were built before that landed in the overlay because of pinning
<alesage> kenvandine, ack
<alesage> kenvandine, around?  http://paste.ubuntu.com/16138204/
<alesage> feeling a bit blocked
<kenvandine> alesage, looking
<kenvandine> alesage, aethercast is in the overlay ppa
<kenvandine> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages
<kenvandine> alesage, so it's not trying to resolve deps against the overlay
<kenvandine> and we don't have an image built with aethercast yet, since it just landed today
<alesage> kenvandine, what's the cost to your strings?  I confess I don't know how this deadline works
<kenvandine> i'm unsure as well
<kenvandine> i just know today is the deadline :)
<kenvandine> add-apt-repository ppa:ci-train-ppa-service/stable-phone-overlay
<kenvandine> will fix your problem
<alesage> kenvandine, I'm surprised that I'm not in that state already
<kenvandine> i thought that should be enabled already
<kenvandine> but we ran into that yesterday where it wasn't pull updates from there
<alesage> or no I haven't used the citool here :/
<kenvandine> you could even just download the deb
<kenvandine> it's in the ppa and will be in the next image :)
<kenvandine> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-046/+build/9664321/+files/aethercast_0.1+15.04.20160429.2-0ubuntu1_armhf.deb
<kenvandine> actually https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+files/aethercast_0.1+15.04.20160429.2-0ubuntu1_armhf.deb
<alesage> alright but this is the last deb I'm downloading tonight
<kenvandine> that's the copied version of it
<kenvandine> alesage, understood :)
 * kenvandine appreciates the effort
<kenvandine> someone needs to look into why we aren't resolving deps from the overlay ppa anymore, that has caused quite a bit of headaches this week
<kenvandine> i know we used to
<kenvandine> alesage, any luck?
<alesage> kenvandine, wound up just adding the ppa as you suggested, perusing the new 30 second timeout feature
<kenvandine> cool
<alesage> kenvandine, probably could've sorted that, have just grown used to the citrain convenience I guess
<kenvandine> yeah
<kenvandine> i think citrain used to ensure the overlay ppa was added
<kenvandine> anyway... a bunch of us had unity8 removed from our phones yesterday with the citrain tool :)
<kenvandine> a bunch == me and at least one other
<kenvandine> :)
<alesage> kenvandine, ok maybe that's a problem then
<alesage> kenvandine, appears good but will cruise a little more, ttfn
<kenvandine> thx!
#ubuntu-ci-eng 2017-04-24
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2569 Needs rebuild due to burned version number (xenial/qtbase-opensource-src). Ready to build (xenial/qtbase-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2722 Abandoning ticket
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2726 Generating diffs
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2726 Successfully built
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2720 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2728 Abandoning ticket
<xnox> sil2100, somehow bileto is not offering to upload into artful, even though it should pick that up from launchpad.
<xnox> do you know how to trick bileto into offering landings into artful?
<sil2100> xnox: yeah, I know how to do that
<sil2100> Let me fix that in 5 minutes
<sil2100> Or at least 'I think I know how to do that'
<sil2100> ;)
<sil2100> Anyway, one moment
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 artful/compiz: Failed to commit https://code.launchpad.net/~banw/compiz/compiz.colorfilter. 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/2730 Ready to build
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2726 Publishing packages
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2726 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2716 Needs rebuild due to burned version number
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2727 Diff missing (artful/cinder, artful/glance, artful/keystone, artful/nova). Ready to build (artful/case, artful/kombu, artful/python-amqp, artful/python-aodhclient, artful/python-automaton, artful/python-castellan, artful/python-ceilometermiddleware, artful/python-cinderclient, artful/python-cliff, artful/python-debtcollector, artful/python-futurist, artful/python-heatclient, artful/python-iron
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/2731 Preparing packages
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2732 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/2732 Dependency wait
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 artful/unity: Failed to build source package
<Trevinho> sil2100: any idea?
<Trevinho> gpg: skipped "6309259455EFCAA8": No secret key
<Trevinho> gpg: dpkg-sign.mBU1yAp4/unity_7.5.0+17.10.20170424-0ubuntu1.dsc: clearsign failed: No secret key
<Trevinho> dpkg-buildpackage: error: failed to sign .dsc and .changes file
<Trevinho> 2017-04-24 14:55:08,841 ERROR artful/unity: Failed to build source package.
<sil2100> uh?
<Trevinho> https://bileto.ubuntu.com/log/2730/build/2/
<sil2100> Let me try looking into that in a few minutes
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2733 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Ready to build
<sil2100> Trevinho: just to make sure, that's reproducible, right?
<Trevinho> sil2100: let me give a retry
<sil2100> Trevinho: not too many people are using MPs nowadays in Bileto, you're probably the first one since a week ;)
<Trevinho> sil2100: yeah, I noticed that..
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Preparing packages
<Trevinho> I can also do the manual way, but...
<Laney> Trevinho is about to end up maintaining it
<Trevinho> :|
<Laney> you mean :D
<Trevinho> ok, I like history, but it's not a good reason to be the only one who has to do all this software conservacy... ð
<sil2100> ;)
<Laney> a nice old gentleman working in a dusty archive somewhere keeping ancient software alive
<Laney> occasionally phd students come by to study, but they never stay long
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 artful/compiz: Failed to build source package
<sil2100> Trevinho: ok, I see it failed again, diving into that
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Ready to build
<sil2100> Trevinho: not much I can do to fix that for now it seems, no vanguard for webops as well
<sil2100> Trevinho: looks like something happened to the GPG key, maybe during the redeployment or something
<sil2100> Trevinho: I'll fill in an RT and continue poking webops
<Trevinho> sil2100: I see.. ok
<Trevinho> thanks
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2732 Dependency wait
<sil2100> That's the beauty of delegating infra access to other teams
-queuebot:#ubuntu-ci-eng- bschaefer, https://bileto.ubuntu.com/#/ticket/2683 Ready to build
#ubuntu-ci-eng 2017-04-25
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 artful/unity: Failed to build source package
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2734 Preparing packages
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2734 zesty/compiz: Failed to build source package
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Ready to build
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2734 Ready to build
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Failed to build
<sil2100> Trevinho: hey! Just in case - the gpg error has been fixed now, I ran the build job and it succeeded
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2735 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2736 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2735 Currently building (xenial/mir). Failed to build (zesty/mir)
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2736 Dependency wait
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2735 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2735 Currently building (xenial/mir). Failed to build (zesty/mir)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2689 Updates pocket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2724 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2737 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2737 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/2737 Generating diffs
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2733 Ready to build (artful/uim). Successfully built (artful/gnome-applets, artful/gnome-panel, artful/gnubiff, artful/indicator-applet, artful/sensors-applet, artful/workrave)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2737 Successfully built
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2735 Failed to build (zesty/mir). Pending binary packages (xenial/mir)
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2735 Failed to build (zesty/mir). Successfully built (xenial/mir)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2697 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2697 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2697 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Successfully built
#ubuntu-ci-eng 2017-04-26
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2721 Updates pocket
* sil2100 changed the topic of #ubuntu-ci-eng to: For help with bileto, highlight "trainguards" | JenkaaS: http://bit.ly/jenkins-docs | Bileto: https://bileto.ubuntu.com | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: no active trainguards available
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 artful/compiz: Failed to build source package
<Trevinho> sil2100: again gpg: dpkg-sign.Da1ZGa9o/compiz_0.9.13.1+17.10.20170426-0ubuntu1.dsc: clearsign failed: No secret key
<Trevinho> dpkg-buildpackage: error: failed to sign .dsc and .changes file
<Trevinho> https://bileto.ubuntu.com/log/2730/build/9/
 * sil2100 sighs
<davmor2> sighs back
<sil2100> Trevinho: on it
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Needs rebuild due to new commits (artful/compiz). Successfully built (artful/unity)
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2734 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2697 Publishing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2737 Publishing packages
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2734 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2697 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2737 Proposed pocket
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2734 Preparing packages
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2734 Pending binary packages
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2734 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Preparing packages
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2732 Diff missing
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2738 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2738 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/2738 Generating diffs
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2733 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2738 Successfully built (xenial/libvirt, yakkety/libvirt). Uploading build (zesty/libvirt)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2738 Successfully built
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2733 Successfully built
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2700 Abandoning ticket
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2733 Publishing packages
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2733 Publish failed: Bad merges
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2733 Publishing packages
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2733 Proposed pocket
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2733 Proposed pocket (artful/ubuntu-themes). Release pocket (artful/gnome-applets, artful/gnome-panel, artful/gnubiff, artful/indicator-applet, artful/sensors-applet, artful/uim, artful/workrave)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2737 Release pocket
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2733 Release pocket
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2732 Diff missing (artful/barbican, artful/cinder, artful/glance, artful/heat, artful/horizon, artful/ironic, artful/keystone, artful/manila, artful/networking-bgpvpn, artful/networking-ovn, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/nova, artful/openvswitch). Failed to build (artful/neutron)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2732 Diff missing (artful/barbican, artful/cinder, artful/glance, artful/heat, artful/horizon, artful/ironic, artful/keystone, artful/manila, artful/networking-bgpvpn, artful/networking-ovn, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/nova, artful/openvswitch). Failed to build (artful/neutron)
#ubuntu-ci-eng 2017-04-27
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Pending binary packages (artful/compiz). Successfully built (artful/unity)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Successfully built
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2732 Generating diffs
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2732 Generating diffs
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2732 Failed to build (artful/neutron). Pending binary packages (artful/nova-lxd). Successfully built (artful/barbican, artful/cinder, artful/glance, artful/heat, artful/horizon, artful/ironic, artful/keystone, artful/manila, artful/networking-bgpvpn, artful/networking-odl, artful/networking-ovn, artful/networking-sfc, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artfu
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2732 Diff missing (artful/nova-lxd). Failed to build (artful/neutron). Successfully built (artful/barbican, artful/cinder, artful/glance, artful/heat, artful/horizon, artful/ironic, artful/keystone, artful/manila, artful/networking-bgpvpn, artful/networking-odl, artful/networking-ovn, artful/networking-sfc, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/nova, art
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2738 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2738 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2738 Successfully built
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2732 Diff missing (artful/nova-lxd). Pending binary packages (artful/neutron). Successfully built (artful/barbican, artful/cinder, artful/glance, artful/heat, artful/horizon, artful/ironic, artful/keystone, artful/manila, artful/networking-bgpvpn, artful/networking-odl, artful/networking-ovn, artful/networking-sfc, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/n
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2732 Generating diffs
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2732 Successfully built
<xnox> sil2100, is bileto working normally for the britney migrations testing? e.g. this artful ticket has been built a while back, yet no sign of even /running/ in progress adt tests https://bileto.ubuntu.com/#/ticket/2730
<xnox> it seems none have been scheduled yet.
<xnox> hm, unless it was rebuilt again
<sil2100> xnox: it should work normally from what I know
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 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/2739 Diff missing (artful/sqlalchemy). Failed to build (artful/neutron)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Diff missing (artful/sqlalchemy). Failed to build (artful/neutron, artful/python-neutron-lib, artful/python-oslo.db). Pending binary packages (artful/alembic)
<xnox> sil2100, something is odd with https://bileto.ubuntu.com/#/ticket/2730 it was built 8h, and i presume it is periodically checked if hte britney stuff is finished; but as far as i can tell britney stuff failed to kick off, as by now it should have generated at least the excuses page stating that tests got kicked off.
<xnox> but this did not seem to happen.
<sil2100> xnox: hm, let me experiment with my silo and see if it's not something globally broken or anything
<sil2100> It would make things easier if it's something reproducible
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Currently building (artful/python-neutron-lib, artful/python-oslo.db). Diff missing (artful/alembic, artful/migrate, artful/sqlalchemy). Failed to build (artful/neutron)
<xnox> sil2100, build something small; for artful; and wait for britney tests to be triggered.
<xnox> i see things triggered for xenial/zesty but not for artful at the moment.
<xnox> then again i think this unity+compiz silo is the first one for artful.
<sil2100> xnox: I had a silo with compiz for artful, wonder if this will work
<sil2100> Oh crap, it's not zesty anymore
<sil2100> I mean not artful anymore
<sil2100> Forgot I changed it to zesty
<sil2100> Ok, creating a new ticket
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2740 Preparing packages
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Diff missing (artful/alembic, artful/migrate, artful/python-oslo.db, artful/sqlalchemy). Failed to build (artful/neutron). Pending binary packages (artful/python-neutron-lib)
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2740 Successfully built
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Diff missing (artful/alembic, artful/migrate, artful/python-neutron-lib, artful/python-oslo.db, artful/sqlalchemy). Uploading build (artful/neutron)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Diff missing
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Diff missing (artful/alembic, artful/migrate, artful/python-neutron-lib, artful/python-oslo.db, artful/sqlalchemy). Pending binary packages (artful/neutron)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Diff missing
#ubuntu-ci-eng 2017-04-28
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2741 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/2741 Generating diffs
-queuebot:#ubuntu-ci-eng- jamespage cpaelzer, https://bileto.ubuntu.com/#/ticket/2732 Publishing packages
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Diff missing (artful/alembic, artful/migrate, artful/neutron, artful/python-neutron-lib, artful/sqlalchemy). Pending binary packages (artful/python-oslo.db)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2741 Pending binary packages
-queuebot:#ubuntu-ci-eng- jamespage cpaelzer, https://bileto.ubuntu.com/#/ticket/2732 Proposed pocket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2741 Successfully built
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Diff missing
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Currently building (artful/cinder, artful/glance, artful/heat, artful/keystone, artful/manila, artful/networking-sfc, artful/neutron, artful/neutron-lbaas, artful/nova). Diff missing (artful/alembic, artful/migrate, artful/python-neutron-lib, artful/python-oslo.db, artful/sqlalchemy). Failed to build (artful/barbican). Pending binary packages (artful/ironic, artful/neutron-dynamic-routing, art
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2742 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/2742 Generating diffs
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Currently building (artful/neutron, artful/neutron-lbaas, artful/nova). Diff missing (artful/alembic, artful/cinder, artful/glance, artful/heat, artful/ironic, artful/manila, artful/migrate, artful/networking-sfc, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/python-neutron-lib, artful/python-oslo.db, artful/python-pykmip, artful/sqlalchemy). Failed to build (artful/vmware-nsx).
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2742 Uploading build
-queuebot:#ubuntu-ci-eng- jamespage cpaelzer, https://bileto.ubuntu.com/#/ticket/2732 Proposed pocket (artful/barbican, artful/cinder, artful/glance, artful/heat, artful/horizon, artful/ironic, artful/keystone, artful/manila, artful/networking-bgpvpn, artful/networking-odl, artful/networking-ovn, artful/networking-sfc, artful/neutron, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/nova, artful/nova-lxd). Release pocket (artful/openvs
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Diff missing (artful/alembic, artful/barbican, artful/cinder, artful/glance, artful/heat, artful/ironic, artful/keystone, artful/manila, artful/migrate, artful/networking-sfc, artful/neutron, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/python-neutron-lib, artful/python-oslo.db, artful/python-pykmip, artful/sqlalchemy). Failed to build (artful/nova, artful
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2742 Successfully built
<xnox> sil2100, any idea about running proposed migration for artful yet?
<xnox> i am pondering to release unity/compiz to the artful archive as is, such that adt tests are run there.
<xnox> and take it from there.
<xnox> Trevinho, are you ok with throwing https://bileto.ubuntu.com/#/ticket/2730 at the archive, and run the autopkgtests there? it will do so anyway.
<xnox> it seems like bileto doesn't know how to do autopkgtests for artful yet.
<Laney> xnox: They started investigating it in #webops earlier
<Trevinho> xnox: I alredy proposed that... But I prefer to have the tests done
<xnox> Trevinho, but they will be done as part of the proposed migration. As in nothing will land in artful, until adt tests complete in artful-proposed.
<xnox> Trevinho, or you want to do them twice, as it is currently done? (once in bileto without artful-proposed, and then again in artful-proposed?!)
<Trevinho> xnox: I'm fine with that, I just can't publish anyway... So it's all on Laney's hands. I guess we're not in hurry so we can wait bileto to be fixed too...
<Trevinho> But in fine with everything
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Publishing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Publish failed: Bad merges
<xnox> sigh
<xnox> not enough approved branches.
<Trevinho> xnox: free to go again now
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Publishing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Publish failed: Packaging diff requires ACK
<Laney> what's the big hurry?
-queuebot:#ubuntu-ci-eng- jamespage cpaelzer, https://bileto.ubuntu.com/#/ticket/2732 Proposed pocket (artful/barbican, artful/cinder, artful/glance, artful/heat, artful/horizon, artful/ironic, artful/keystone, artful/manila, artful/networking-bgpvpn, artful/networking-odl, artful/networking-ovn, artful/networking-sfc, artful/neutron, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/nova). Release pocket (artful/nova-lxd, artful/openvs
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Successfully built
<Trevinho> Laney: I guess xnox wants to get rid of upstart quickly
<xnox> we have a couple of dozen packages to remove and unwind this cycle.
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Publishing packages
<Laney> Well this one is ready.
<Laney> I don't see why it has to be in RIGHT NOW.
<xnox> Trevinho, https://code.launchpad.net/~muktupavels/compiz/gwd-hidpi/+merge/323100 this one has still needs review status =( i guess you are not charming enough to  toggle that on the compiz project, or something?
<xnox> Laney, i have time now to do this; but my pipeline is very busy upcoming weeks with building things out of all things on Windows =/
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Publish failed: Bad merges
<Trevinho> xnox: fixed
<xnox> yeah
<Trevinho> xnox: I'm in drinks time here though, so... I don't want anything responsibilty for this braking stuff (but when I approved was good, and day time ð)
<Trevinho> *any
<Trevinho> *breaking
<xnox> i am running that ppa on my laptop and did test all the claimed features, everything seemed to be ok
<Trevinho> xnox: ð
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Successfully built
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Currently building (artful/pegasus-wms). Diff missing (artful/alembic, artful/anki, artful/archipel-core, artful/automx, artful/barbican, artful/bauble, artful/blogofile, artful/buildbot, artful/childsplay, artful/cinder, artful/csvkit, artful/db2twitter, artful/elixir, artful/flask-sqlalchemy, artful/gertty, artful/glance, artful/glare, artful/gourmet, artful/griffith, artful/heat, artful/ibi
-queuebot:#ubuntu-ci-eng- jamespage cpaelzer, https://bileto.ubuntu.com/#/ticket/2732 Proposed pocket (artful/barbican, artful/cinder, artful/glance, artful/heat, artful/horizon, artful/ironic, artful/keystone, artful/manila, artful/networking-bgpvpn, artful/networking-odl, artful/networking-sfc, artful/neutron, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/nova). Release pocket (artful/networking-ovn, artful/nova-lxd, artful/openvs
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Currently building (artful/mistral, artful/osmalchemy). Diff missing (artful/alembic, artful/anki, artful/aodh, artful/archipel-core, artful/automx, artful/barbican, artful/bauble, artful/blogofile, artful/buildbot, artful/childsplay, artful/cinder, artful/csvkit, artful/db2twitter, artful/elixir, artful/epigrass, artful/flask-sqlalchemy, artful/gertty, artful/glance, artful/glare, artful/gnoc
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Currently building (artful/senlin). Diff missing (artful/alembic, artful/anki, artful/aodh, artful/archipel-core, artful/automx, artful/barbican, artful/bauble, artful/blogofile, artful/buildbot, artful/childsplay, artful/cinder, artful/csvkit, artful/db2twitter, artful/elixir, artful/epigrass, artful/flask-sqlalchemy, artful/gertty, artful/glance, artful/glare, artful/gnocchi, artful/gourmet,
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Diff missing (artful/alembic, artful/anki, artful/aodh, artful/archipel-core, artful/automx, artful/barbican, artful/bauble, artful/blogofile, artful/buildbot, artful/childsplay, artful/cinder, artful/csvkit, artful/db2twitter, artful/elixir, artful/epigrass, artful/flask-sqlalchemy, artful/gertty, artful/glance, artful/glare, artful/gnocchi, artful/gourmet, artful/griffith, artful/heat, artfu
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Generating diffs
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 artful/python-authkit: Failed to verify DSC file python-authkit_0.4.3-2.dsc
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Generating diffs
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 artful/zope.sqlalchemy: Failed to verify DSC file zope.sqlalchemy_0.6.1-2.dsc
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Generating diffs
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 artful/magnum: Failed to verify DSC file magnum_4.1.0-0ubuntu2.dsc
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Generating diffs
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 artful/python-sqlalchemy-utils: Failed to verify DSC file python-sqlalchemy-utils_0.30.12-4.dsc
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Generating diffs
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 artful/archipel-core: Failed to verify DSC file archipel-core_0.6.0-1.dsc
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Generating diffs
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Publishing packages
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Publish failed: Diff missing
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Generating diffs
<jamespage> hmm - anyone got any ideas on the verification failures for the diffs on https://bileto.ubuntu.com/#/ticket/2739
<jamespage> ?
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 artful/murano: Failed to verify DSC file murano_3.2.0-0ubuntu1.dsc
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2740 Preparing packages
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Diff missing
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Generating diffs
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Diff missing
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2740 Failed to build (artful/unity). Successfully built (artful/compiz)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Successfully built
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2743 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Publishing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Proposed pocket
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2740 Dependency wait (artful/unity). Destination version missing from changelog (artful/compiz)
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2743 Generating diffs
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2743 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Proposed pocket (artful/unity). Release pocket (artful/compiz)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2730 Release pocket
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2740 Needs rebuild due to new commits
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/2734 Needs rebuild due to new commits
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2718 Needs rebuild due to new commits
<sil2100> Trevinho, xnox: just in case you guys are still around - Bileto britney autopkgtests should now be working
<sil2100> Trevinho, xnox: it's all a bit slowish today so drop me an e-mail if there are still problems, but I checked in an experimental silo and I got excuses back for artful + saw the tests running
<xnox> sil2100, win!
<sil2100> One thing that I didn't manage to test is if the excuses page gets correctly updated with test results, but I'm sure it is as since it generates it successfully and updates the ticket then why shouldn't it
<sil2100> Since I only got an excuses page with the Test running tests, but I saw the tests being run, just would need to wait another 30 minutes to check if the excuses page got refreshed
#ubuntu-ci-eng 2017-04-29
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Publishing packages
-queuebot:#ubuntu-ci-eng- jamespage cpaelzer, https://bileto.ubuntu.com/#/ticket/2732 Needs rebuild due to higher version at destination (artful/barbican, artful/cinder, artful/glance, artful/heat, artful/ironic, artful/keystone, artful/manila, artful/networking-sfc, artful/neutron, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/nova). Proposed pocket (artful/horizon, artful/networking-bgpvpn, artful/networking-odl). Release pocket (
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Proposed pocket
-queuebot:#ubuntu-ci-eng- jamespage cpaelzer, https://bileto.ubuntu.com/#/ticket/2732 Abandoning ticket
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Proposed pocket (artful/alembic, artful/anki, artful/aodh, artful/archipel-core, artful/automx, artful/barbican, artful/bauble, artful/blogofile, artful/buildbot, artful/childsplay, artful/cinder, artful/csvkit, artful/db2twitter, artful/elixir, artful/epigrass, artful/flask-sqlalchemy, artful/gertty, artful/glance, artful/glare, artful/gnocchi, artful/gourmet, artful/griffith, artful/heat, ar
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Proposed pocket (artful/alembic, artful/anki, artful/archipel-core, artful/automx, artful/barbican, artful/bauble, artful/blogofile, artful/buildbot, artful/childsplay, artful/cinder, artful/csvkit, artful/db2twitter, artful/elixir, artful/epigrass, artful/flask-sqlalchemy, artful/gertty, artful/glance, artful/glare, artful/gnocchi, artful/gourmet, artful/heat, artful/ibid, artful/ironic, artf
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Proposed pocket (artful/alembic, artful/archipel-core, artful/automx, artful/barbican, artful/bauble, artful/blogofile, artful/buildbot, artful/childsplay, artful/cinder, artful/csvkit, artful/db2twitter, artful/elixir, artful/glance, artful/glare, artful/gnocchi, artful/gourmet, artful/heat, artful/ibid, artful/ironic, artful/ironic-inspector, artful/keystone, artful/magnum, artful/manila, ar
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Proposed pocket (artful/alembic, artful/archipel-core, artful/automx, artful/barbican, artful/bauble, artful/blogofile, artful/buildbot, artful/cinder, artful/csvkit, artful/db2twitter, artful/elixir, artful/glance, artful/glare, artful/gourmet, artful/heat, artful/ibid, artful/ironic, artful/ironic-inspector, artful/keystone, artful/magnum, artful/manila, artful/migrate, artful/mistral, artfu
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Proposed pocket (artful/alembic, artful/archipel-core, artful/automx, artful/barbican, artful/bauble, artful/blogofile, artful/buildbot, artful/cinder, artful/csvkit, artful/db2twitter, artful/elixir, artful/glance, artful/gourmet, artful/heat, artful/ibid, artful/ironic, artful/ironic-inspector, artful/keystone, artful/magnum, artful/manila, artful/migrate, artful/mistral, artful/murano, artf
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Proposed pocket (artful/alembic, artful/archipel-core, artful/barbican, artful/blogofile, artful/cinder, artful/glance, artful/heat, artful/ibid, artful/ironic, artful/keystone, artful/manila, artful/migrate, artful/mistral, artful/murano, artful/networking-sfc, artful/neutron, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/nova, artful/pegasus-wms, artful/p
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Proposed pocket (artful/alembic, artful/archipel-core, artful/barbican, artful/blogofile, artful/cinder, artful/glance, artful/heat, artful/ibid, artful/ironic, artful/keystone, artful/manila, artful/migrate, artful/mistral, artful/murano, artful/networking-sfc, artful/neutron, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/nova, artful/pegasus-wms, artful/p
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Proposed pocket (artful/alembic, artful/archipel-core, artful/barbican, artful/blogofile, artful/cinder, artful/glance, artful/heat, artful/ibid, artful/ironic, artful/keystone, artful/manila, artful/migrate, artful/mistral, artful/murano, artful/networking-sfc, artful/neutron, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/nova, artful/pegasus-wms, artful/p
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Proposed pocket (artful/alembic, artful/archipel-core, artful/barbican, artful/blogofile, artful/cinder, artful/glance, artful/heat, artful/ibid, artful/ironic, artful/keystone, artful/manila, artful/migrate, artful/mistral, artful/murano, artful/networking-sfc, artful/neutron, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/nova, artful/pegasus-wms, artful/p
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Proposed pocket (artful/alembic, artful/barbican, artful/blogofile, artful/cinder, artful/glance, artful/heat, artful/ibid, artful/ironic, artful/keystone, artful/manila, artful/migrate, artful/mistral, artful/murano, artful/networking-sfc, artful/neutron, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/nova, artful/pegasus-wms, artful/python-neutron-lib, art
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Proposed pocket (artful/alembic, artful/barbican, artful/blogofile, artful/cinder, artful/glance, artful/heat, artful/ironic, artful/keystone, artful/manila, artful/migrate, artful/mistral, artful/murano, artful/networking-sfc, artful/neutron, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/nova, artful/pegasus-wms, artful/python-neutron-lib, artful/python-os
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Proposed pocket (artful/alembic, artful/barbican, artful/blogofile, artful/cinder, artful/glance, artful/heat, artful/ironic, artful/keystone, artful/manila, artful/migrate, artful/mistral, artful/murano, artful/networking-sfc, artful/neutron, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/nova, artful/python-neutron-lib, artful/python-oslo.db, artful/senlin
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Proposed pocket (artful/alembic, artful/barbican, artful/cinder, artful/glance, artful/heat, artful/ironic, artful/keystone, artful/manila, artful/migrate, artful/mistral, artful/murano, artful/networking-sfc, artful/neutron, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/nova, artful/python-neutron-lib, artful/python-oslo.db, artful/senlin, artful/sqlalchem
<chatter29> hey guys
<chatter29> allah is doing
#ubuntu-ci-eng 2017-04-30
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Needs rebuild due to higher version at destination (artful/anki). Proposed pocket (artful/alembic, artful/barbican, artful/cinder, artful/glance, artful/heat, artful/ironic, artful/keystone, artful/manila, artful/migrate, artful/mistral, artful/murano, artful/networking-sfc, artful/neutron, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/nova, artful/python-n
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2739 Needs rebuild due to higher version at destination (artful/anki, artful/murano). Proposed pocket (artful/alembic, artful/barbican, artful/cinder, artful/glance, artful/heat, artful/ironic, artful/keystone, artful/manila, artful/migrate, artful/mistral, artful/networking-sfc, artful/neutron, artful/neutron-dynamic-routing, artful/neutron-fwaas, artful/neutron-lbaas, artful/nova, artful/python-n
#ubuntu-ci-eng 2018-04-23
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3245 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/3245 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3245 Diff missing
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3246 Preparing packages
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3246 Generating diffs
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3246 Successfully built
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3246 Publishing packages
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3246 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3246 Proposed pocket
#ubuntu-ci-eng 2018-04-24
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3194 Diff missing (xenial/dpdk, xenial/rdma-core). Ready to build (xenial/debhelper)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3195 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3247 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/3247 Abandoning ticket
#ubuntu-ci-eng 2018-04-25
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3248 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/3248 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3248 UNAPPROVED queue
#ubuntu-ci-eng 2018-04-26
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3249 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/3249 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3245 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3224 Needs rebuild due to higher version at destination (xenial/libvirt, xenial/qemu). Ready to build (yakkety/libvirt, yakkety/qemu, zesty/libvirt, zesty/qemu)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3248 Proposed pocket
#ubuntu-ci-eng 2020-04-20
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4029 Preparing packages
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4029 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4029 Preparing packages
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4030 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4030 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4015 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4030 Uploading build
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4030 Successfully built
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4029 Uploading build
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4029 Pending binary packages
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4029 Successfully built
#ubuntu-ci-eng 2020-04-21
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4031 Preparing packages
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4031 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4031 Preparing packages
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4032 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4032 Preparing packages
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4031 REJECTED queue
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4032 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4032 Proposed pocket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4034 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/4034 Diff missing
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4029 Pending binary packages
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4029 Successfully built
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4029 UNAPPROVED queue
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4030 Proposed pocket
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4031 Proposed pocket
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4029 Proposed pocket
#ubuntu-ci-eng 2020-04-22
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4034 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4034 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4034 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/4035 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
#ubuntu-ci-eng 2020-04-23
-queuebot:#ubuntu-ci-eng- wgrant, https://bileto.ubuntu.com/#/ticket/4036 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4037 Preparing packages
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/4033 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/4033 Failed to build (focal/xapian-bindings). Uploading build (focal/squirrel3)
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/4033 Diff missing (focal/squirrel3). Failed to build (focal/xapian-bindings)
#ubuntu-ci-eng 2020-04-24
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4034 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4012 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/4013 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3981 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3986 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3985 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3992 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3959 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3956 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3942 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3962 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3928 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3885 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3900 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3898 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3902 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3864 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3883 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3869 Abandoning ticket
-queuebot:#ubuntu-ci-eng- ginggs, https://bileto.ubuntu.com/#/ticket/4025 REJECTED queue
#ubuntu-ci-eng 2020-04-25
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4038 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4039 Preparing packages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4039 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4038 Abandoning ticket
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4040 Failed to build
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4041 Pending binary packages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4041 Diff missing
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4039 Pending binary packages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4041 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4041 Successfully built
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4039 Diff missing
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4039 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4039 Successfully built
