[02:05] <imgbot> === IMAGE 111 building (started: 20150225-02:05) ===
[03:05] <imgbot> === IMAGE RTM 244 building (started: 20150225-03:05) ===
[03:25] <imgbot> === IMAGE 111 DONE (finished: 20150225-03:25) ===
[03:25] <imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/111.changes ===
=== salem_ is now known as _salem
[04:16] <imgbot> === IMAGE RTM 244 DONE (finished: 20150225-04:15) ===
[04:16] <imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/244.changes ===
[09:32] <sil2100> jibel: hey, will you be doing those ota tests for the latest rc image as per what alex requested yesterday?
[09:53] <davmor2> sil2100: we already test ota in the regression suite what would we need to ota again for, or is this something else?
[09:54] <davmor2> sil2100: we also test ota in the sanity suite too
[09:55] <john-mcaleely> I think AK just wanted to confirm that, so we're probably ok
[10:02] <sil2100> ok then
[10:03] <sil2100> Let me find a quiet place here and launch my laptop
[10:10] <sil2100> Double-confirming - we want image number 19 from RC to the stable channel, right?
[10:10] <sil2100> (for krillin)
[10:11] <sil2100> john-mcaleely: ^
[10:12] <sil2100> Ok, anyway promoting
[10:12] <john-mcaleely> sil2100, yup
[10:12] <john-mcaleely> phew ;-)
[10:16] <sil2100> hm, it's taking its sweet time
[10:19] <sil2100> ogra_: copy-image takes an awefully long time, is that normal?
[10:19] <sil2100> ogra_: usually it's almost instant
[10:19] <ogra_> heh, usually it takes a long time ... interesting that it was quick for you the last times
[10:20] <ogra_> it re-packs the rootfs tarball for each toplevel arch once
[10:20] <sil2100> Yeah, it was done in a few seconds normally
[10:20] <ogra_> so the first armhf and the first x86 run are both slow
[10:20] <ogra_> subsequent armhf runs are fast since only the index files get updated
[10:20] <sil2100> Ok then, I'll leave it running in screen since I need to move now, I'm probably sure krillin should be copied in a few moments
[10:21] <sil2100> john-mcaleely: ^ I won't be around to announce once it's done, but it'll be done ;)
[10:21] <ogra_> can take ten mins
[10:21]  * sil2100 moves
[10:21] <john-mcaleely> sil2100, great!
[10:22]  * john-mcaleely runs u-d-f query in a loop :_)
[10:23] <john-mcaleely> looks like it's done sil2100 :-)
[10:25] <davmor2> sil2100: why do you want your laptop in space?
=== greyback__ is now known as greyback
[11:50] <sil2100> davmor2: how come in space? ;)
[11:52] <davmor2> sil2100: you wanted to find somewhere quiet to launch your laptop :)
[11:53] <davmor2> sil2100: most people just turn them on, you apparently launch them :D
[12:00] <nerochiaro> sil2100: not sure if you are the right person to ask to, but do you know how does CI decide what packages to install before running AP tests ? specifically python packages
=== _salem is now known as salem_
=== MacSlow is now known as MacSlow|lunch
[12:53] <greyback> Any reason why silos do not have debug packages generated? It would help me right now
[12:55] <Mirv> greyback: the answer a couple of weeks ago was that we should have a "new, better system" in a couple of weeks. I'm not sure what the status is :)
[12:55] <cjwatson> greyback: There are some problems with doing them across the board (which will hopefully be lifted soon, it's just that there's been quite an impressive dependency chain within Launchpad to get there including a complete librarian data migration), but I can retrieve them for you for a single silo as long as it was built reasonably recently
[12:55] <Mirv> oh, there is it, the status
[12:55] <cjwatson> https://bugs.launchpad.net/ubuntu-lt/+bug/1420185
[12:55] <ubot5> Launchpad bug 1420185 in Ubuntu Landing Team "A way to provide ddebs to landing PPA:s?" [Wishlist,New]
[12:55] <Mirv> sounds complex, but nice
[12:56] <cjwatson> I think it's still reasonably only "weeks" since I said that :)
[12:56] <greyback> cjwatson: ok am glad they're on the way at least. I'd very much appreciate mir debug packages from silo0
[12:56] <cjwatson> greyback: OK, give me a few minutes to track them down.
[12:57] <cjwatson> greyback: Just mir, not the other packages?
[12:57] <greyback> cjwatson: well if you're copying... :)
[12:58] <cjwatson> greyback: This is fairly time-consuming per-package, so would prefer to know what you actually need
[12:58] <cjwatson> greyback: Argh, I think they may have been GCed already, sorry
[12:59] <greyback> cjwatson: ah ok, no worries
[12:59] <greyback> sbuild won't take too long
[12:59] <greyback> thanks anyway
[12:59] <cjwatson> We can reasonably reliably get them as long as the build was less than two or maybe three days ago.
[13:00] <cjwatson> But the builders don't keep them around forever, and the ghastly hack that is ddebs.ubuntu.com doesn't keep them for PPAs either ...
[13:02] <bzoltan_> Mirv:  may I ask for an RTM silo to land the UITK branch?
[13:04] <Mirv> bzoltan_: looking
[13:06] <Mirv> bzoltan_: I can assign a silo, if you're sure the fix is still wanted in before vivid switch?
[13:07] <Mirv> bzoltan_: you've got the Bond silo. btw https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/textHandlerCleanUpRTM/+merge/247388 links to four bugs, of which only one has canonical system image target
[13:16] <bzoltan_> Mirv:  I expect it to land by tomorrow or latest on Friday. Depends onthe load of QA
=== salem_ is now known as _salem
[13:39] <Mirv> bzoltan_: so just to make sure you didn't miss, you got the ^ 007 rtm silo
=== _salem is now known as salem_
[13:55] <nerochiaro> does anyone know in which way CI decides what packages to install before running AP tests ? I have a problem with some packages being not isntalled despite being specified in debia/control and in manifest.json
[13:56] <nerochiaro> fginther: Mirv: cjwatson: sil2100: ^^^ ? (or maybe point me to the right person I can ask to. thanks)
[13:56] <sil2100> nerochiaro: hey!
[13:57] <sil2100> nerochiaro: sorry, I was AFK
[13:57] <nerochiaro> sil2100: hi
[13:57] <nerochiaro> sil2100: np
[13:57] <nerochiaro> i had forgotten too for a while :)
[13:57] <sil2100> nerochiaro: you mean for a click package, right?
[13:57] <nerochiaro> sil2100: yes, for camera app
[13:57] <nerochiaro> sil2100: specifically looking at this issue: http://rtm-dashboard.ci.ubuntu.com/smokeng/utopic/touch_stable/krillin/243:20150224:20150216-fe747ac/349/camera_app/154770/
[13:58] <sil2100> nerochiaro: not sure about CI, since you would have to ask them to get more detailed info, but I think phablet-test-click-setup is only fetching selected bzr branch of the click package and install ubuntu-ui-toolkit and unity8 AP tests
[13:58] <sil2100> nerochiaro: plars would know more about smoketesting though
[13:58] <nerochiaro> sil2100: ok thanks, let's see if he can help them
[13:58] <nerochiaro> then
[13:58] <plars> nerochiaro: just waking up, what's going on?
[13:59] <cjwatson> nerochiaro: I'm afraid I have no idea about the CI bits
[13:59] <nerochiaro> plars: was just wondering how can i make sure to tell AP to install the packages that my tests need
[13:59] <plars> nerochiaro: if this is about camera, I know veebers was looking at it yesterday... ah ok
[13:59] <nerochiaro> plars: different issue
[13:59] <plars> nerochiaro: which test, and which dependencies does it need?
[14:00] <nerochiaro> http://rtm-dashboard.ci.ubuntu.com/smokeng/utopic/touch_stable/krillin/243:20150224:20150216-fe747ac/349/camera_app/154770/
[14:00] <nerochiaro> plars: it does need python3-wand
[14:00] <nerochiaro> plars: it is the test linked above
[14:01] <plars> nerochiaro: I'll stick it on our vanguard queue, if nobody else gets to it then I'll be able to do it in just a bit, does that work for you?
[14:02] <nerochiaro> plars: just to be sure i understand: it is something you guys need to do, it is not something we can specify somewhere in the package manifest, right ?
[14:02] <nerochiaro> plars: because in the package.json we have this, and i was wondering what it is for then:
[14:02] <nerochiaro>     "x-test": {
[14:02] <nerochiaro>         "autopilot": {
[14:02] <nerochiaro>             "autopilot_module": "@AUTOPILOT_DIR@",
[14:02] <nerochiaro>             "depends": [
[14:02] <nerochiaro>                 "python3-wand",
[14:02] <nerochiaro>                 "python3-mediainfodll"
[14:02] <nerochiaro>             ]
[14:02] <nerochiaro>         }
[14:02] <nerochiaro>     }
[14:02] <plars> nerochiaro: I forget, is camera a click or a debian test?
[14:02] <nerochiaro> plars: camera builds both click and debian, but i think we run tests as click
[14:03] <plars> nerochiaro: if it's pulling in a deb for the test, it *should* get any dependencies with it. However clicks don't use that
[14:03] <plars> yeah, clicks are so disrespectful, they don't even bother to see stuff like that :)
[14:03] <plars> nerochiaro: so is python3-mediainfodll needed also?
[14:03] <nerochiaro> plars: yes please, both of them
[14:04] <nerochiaro> plars: and the vanguard queue i guess will work if it is done in a reasonable amount of time
[14:04] <nerochiaro> plars: thank you
[14:05] <plars> nerochiaro: within the next couple of hours most likely
[14:05] <nerochiaro> plars: most excellent. thank you
[14:05] <plars> nerochiaro: for it to be in there, and land in the test code, etc
[14:05] <plars> fully "done"
[14:06] <nerochiaro> plars: it will do nicely. and a quick question before i let you go get your morning coffee ;) , are these tests re-run only when there is a new image, or we can ask them to be re-run with a certain merge request code  to see if it really fixes issues ?
[14:07] <plars> nerochiaro: they should already be run for MP landings, are they not?
[14:08] <nerochiaro> plars: what i see CI posting in the MR comments is basically only for vivid, not for RTM, unless I am missing something
[14:08] <plars> nerochiaro: ah, not sure on that, but I'll check. Certainly it will be run for every new image though
[14:09] <nerochiaro> plars: ok, thanks. if there is any way to access RTM tests results for merge requests, please let me know.
[14:11] <plars> nerochiaro: don't things normally land in vivid though, and then migrate to rtm? What do you land in rtm directly?
[14:15] <nerochiaro> plars: maybe i am not very clear on the process, but RTM is still on utopic
[14:15] <plars> nerochiaro: looks like someone asked for it last night too, the deps already had a mp for it and should be there soon
[14:15] <nerochiaro> plars: great
=== MacSlow|lunch is now known as MacSlow
=== plars changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping plars | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: -
[15:10] <rsalveti> kenvandine: it seems we got a better fix for the bluetooth mr, will validate https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-018 later today again
[15:10] <rsalveti> if indeed a good fix, then it would be nice to have it for rtm as well
[15:11] <kenvandine> rsalveti, cool
[15:14] <seb128> rsalveti, kenvandine, I acked the trunk mp and testing it with my car (which didn't work) and with keyboard and audio transmitter (which still work)
[15:14] <seb128> tested even
[15:16] <rsalveti> cool
[15:16] <seb128> rsalveti, kenvandine, there are a bunch of bluetooth fixes in trunk, but rtm is basically over from what I understood from pmcgowan, e.g we just want to focus on rebasing on vivid now?
[15:16] <kenvandine> seb128, yeah
[15:17] <rsalveti> seb128: well, not yet over :-)
[15:17] <kenvandine> well... soon :)
[15:17] <rsalveti> once vivid is stable and we get a plan to move to it
[15:17] <kenvandine> we might land some fixes soonish before rebasing
[15:17] <rsalveti> "stable"
[15:17] <seb128> rsalveti, well, basically I asked if we can get bugs added to the approved rtm list and that was the reply
[15:17] <rsalveti> right, but we will be landing critical issues
[15:17] <seb128> is that considered one?
[15:17] <rsalveti> the idea was just to avoid landing issues that are not critical/high enough
[15:18] <rsalveti> seb128: that might help pairing with quite a few cars out there
[15:18] <rsalveti> and we have a bug from bq for it, so possibly
[15:18] <seb128> indeed, mine for example :-)
[15:18] <pmcgowan> that one might warrant a backport
[15:18] <seb128> do we want to backport ssp pairing as well?
[15:19] <seb128> that's used by e.g some keyboards
[15:21] <rsalveti> seb128: keyboard pairing is not yet supported in RTM
[15:21] <rsalveti> iirc
[15:21] <pmcgowan> sil2100, did we promote the last rtm image?
[15:23] <seb128> rsalveti, k
[15:23] <seb128> rsalveti, where is the list of what is supported or not?
[15:28] <sil2100> pmcgowan: yes :)
[15:28] <rsalveti> seb128: would need to check the debdiff for that :-), but I think input is not yet supported because that only landed in vivid
[15:28] <sil2100> pmcgowan: only the krillin one so far, but I'll have time to promote the rest in a minute
[15:30] <seb128> rsalveti, oh, that's what you mean. Yeah, I added the ssp/keyboard pairing to vivid, I was just wondering if we should backport that as well
[15:31] <rsalveti> seb128: afaik for the input to be useful it'd also require a new mir
[15:31] <rsalveti> the current mir in RTM is unable to add new input devices dynamically
[15:31] <seb128> rsalveti, ah ok, let's forget about it then
[15:31] <rsalveti> yeah
[17:05] <robru> sil2100: meeting?
[17:10] <davmor2> sil2100, jibel, ogra_: landing meeting or is it cancelled?
[17:10] <ogra_> i'm in the release plannin meeting atm
[17:11] <ogra_> wont make LT today
[17:12] <davmor2> we cancelled landing team
[17:35] <Mirv> evening hi
[17:36] <robru> Mirv: hola
=== alex_abreu is now known as alex-abreu
=== alan_g is now known as alan_g|EOD
[18:29] <robru> oSoMoN: how's it going? you really ready for a publish? ;-)
[18:30] <oSoMoN> robru, if you mean silo 25, I hit "build" again by accident…
[18:31] <oSoMoN> I meant to rebuild silo 8, mixed up the two
[18:32] <robru> oSoMoN: hmmm. so is 25 ready to publish? the dashboard says so...
[18:33] <oSoMoN> robru, it is, and it’s actually already in -proposed, awaiting for the beta1 freeze lift to migrate to release
[18:33] <robru> oSoMoN: oh, k. hm
[18:33] <oSoMoN> which is why building it again was completely useless…
[18:33] <robru> oSoMoN: yeah if it was already published, I just gotta fix the status or it won't automerge once it lands...
[18:34] <oSoMoN> ah, sorry about that
[18:40] <robru> oSoMoN: no worries.
[18:40] <robru> oSoMoN: ok I think I fixed it, within 5 min or so we should see 'Migration: blah blah' message.
[18:42] <Mirv> it's 24, not 25, which is in -proposed
[18:42] <Mirv> oh, and I'm not really here
[18:42] <Mirv> 20150224, that is
[18:46] <oSoMoN> yeah, I’m not really here either
[18:46]  * oSoMoN disappears
=== plars 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: -
[19:13] <robru> Mirv: thanks for the heads up, fixed
[21:49] <john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150225-b67e0b6.changes
[21:49] <john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150225-b67e0b6.tar.xz
[21:50] <john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-testresults-20150225-b67e0b6.ods
[21:50] <john-mcaleely> new device tarball, for the logs and the morning :-)
[21:50] <john-mcaleely> (also in the citrain spreadsheet, currently line 57)
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem