[00:08] <kgunn> robru: cyphermox_ ok..mir in silo13 is all good....just finished testing....
[00:08] <kgunn> if someone would like to upload all the packages...i'll hit merge after dinner!
[00:08] <kgunn> just ping here
[00:15] <robru> kgunn, on it
[00:17] <robru> cyphermox_, actually I need you to ack the packaging here; http://162.213.34.102/job/landing-013-2-publish/
[03:03] <thomi> robru: cyphermox_: Could one of you gentlemen please re-generate my silo? I've needed to remove an MP from the landing plan since it's going to be too complicated to land
[03:03] <cyphermox_> thmo ack
[03:03] <cyphermox_> ugh
[03:03] <thomi> :)
[03:03] <cyphermox_> thomi: alright, doing it now ;)
[03:03] <thomi> cyphermox_: perhaps you could click the 'build' button for me as well please :)
[03:03] <cyphermox_> sure
[03:04] <thomi> I mean, once the silo bit is done
[03:04] <thomi> thanks
[03:04] <cyphermox_> I still see two MPs in the spreadsheet?
[03:05] <thomi> cyphermox_: yeah, there used to be three
[03:06] <thomi> cyphermox_: I already removed one from the list
[03:06] <cyphermox_> hmm, but then someone re-configured it when you added the third?
[03:06] <thomi> cyphermox_: yes, robru did
[03:06] <thomi> earlier
[03:06] <cyphermox_> because I recall configuring it for just two earlier :)
[03:06] <cyphermox_> ok
[03:07] <thomi> yeah... turns out one of the MPs needs to be landed atomically with a new unity8, which I didn't realise
[03:10] <cyphermox_> thomi: http://162.213.34.102/job/landing-006-1-build/23/console
[03:11] <thomi> cyphermox_: thanks!
[03:11]  * thomi watches the wheels spin
[03:12] <cjohnston> the wheels on the train go round and round
[03:19] <cyphermox_> chu chu
[03:20] <thomi> I thought the weeks on the *bus* went round and round?
[03:23] <cjohnston> must be different over there.. over here we have wheels on the bus ;-)
[03:24] <cjohnston> but we don't have a CI Bus, thankfully
[03:41] <robru> cjohnston, CI bus was what we had before ;-)
[03:43] <cjohnston> robru: from what I understand, a bus moves too fast for what we had before
[03:44] <robru> zing!
[03:45] <cjohnston> maybe the CI segway.. if you tilt a little too much in any direction it falls over
[03:56] <cyphermox_> the ci crawl?
[03:56] <cyphermox_> thomi: I'm logging off now
[03:56] <thomi> cyphermox_: thanks for your help - this won't be ready to land till tomorrow anyway
[03:56] <cyphermox_> ok
[03:57] <thomi> our test job takes *hours*
[03:57] <cyphermox_> well, you'll have someone else to look into that stuff (assuming there is nobody else not in didrocks' team) in 3 hours or so
[03:58] <thomi> cyphermox_: yeah,
[03:58] <cjohnston> cyphermox_: crawling isn't really a vehicle, and since we are for some reason sticking with vehicles for transportation.... ;-/
[03:58] <robru> cyphermox_, CI rollerblades ;-)
[03:58] <cjohnston> hehe
[03:59] <thomi> ci hoverboard
[03:59] <thomi> just.. don't take it out over water
[03:59] <robru> YOU NEED POWAH!
[03:59] <thomi> :)
[03:59]  * robru -> EOD. goodnight!
[03:59] <thomi> o/
[08:29] <didrocks> mandel: hey, tell me once you are around :)
[09:15] <popey> My phone is stuck on "Checking for updates..."
[09:16]  * popey blames the connection in the office
[09:19] <didrocks> popey: seems multiple people are complaining about updates, I didn't boot my phone yet
[09:20] <asac> hmm... thats scary i guess :/
[09:20] <popey> I'm getting 50% packet loss here, so blame that at the moment
[09:20] <sil2100> My phone is updating right now
[09:20] <popey> (on my laptop, not phone)
[09:24] <didrocks> popey: as psivaa isn't around, do you mind making the update test results health statement this morning?
[09:25] <didrocks> (and same for tomorrow I guess :))
[09:25] <popey> if I could get any kind of connection aside from ssh, maybe
[09:26] <ogra_> bah, sigh, no new Mir
[09:26] <didrocks> popey: waow, even to ci.ubuntu.com?
[09:26] <didrocks> ogra_: yeah, seems it was published too late
[09:26] <popey> i get 50% packet loss on all my devicess
[09:27]  * popey pokes is
[09:29] <ogra_> hmm, and bug 1277589 has no cause found yet either
[09:29] <ogra_> :(
[09:29] <ogra_> pretty bad
[09:29] <didrocks> yeah
[09:29] <ogra_> (seems a lot of people get it now
[09:29] <ogra_> )
[09:30] <sil2100> didrocks: be there in a minute
[09:31] <ogra_> grr, headset issues
[09:32] <didrocks> popey: get your packets back and join us! ;)
[09:33] <popey> will try
[10:00] <didrocks> mandel: so that you know, thostr_ is doing a release of ubuntu-download-manager (today is quiet, we have some free slots for doing so)
[10:00] <didrocks> so you are getting into CI Train, starting Monday, you will be doing it yourself though
[10:01] <didrocks> (as you dep on qt btw, we have again some packages to remove on powerpc and similar archs. This is safe to do in term of reverse-depends though, just need to jump in some ooopses)
[10:12] <popey> ogra_: http://paste.ubuntu.com/6915695/ see that - instructions from rsalveti for flo...
[10:12] <popey> line 16 - where does trusty-preinstalled-touch-armhf.tar.gz come from?
[10:12] <ogra_> popey, see the "paste from" :)
[10:13] <ogra_> popey, line 16 comes from line 12
[10:13] <popey> well yeah, hence me asking you ☻
[10:13] <ogra_> oh !
[10:13] <popey> well, no, 12 downloads ubuntu-touch.rootfs-armhf.tar.gz
[10:13] <ogra_> thanks !
[10:13] <ogra_> yeah
[10:13] <ogra_> popey, though i think with Mir 1.5 in the archive you should be able to use the last proposed tarball from cdimage
[10:14] <ogra_> (which then would be rightly named)
[10:14] <popey> got a url?
[10:15] <ogra_> http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/pending/
[10:15] <ogra_> pick the tar.gz
[10:16] <popey> http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20140213/trusty-preinstalled-touch-armhf.tar.gz ya ?
[10:16] <popey> ffs, can't resolve cdimage.ubuntu.com in the office
[10:17] <ogra_> right
[10:18] <Mirv> didrocks: ok bzoltan is having problems with the tests, and I shared my testing methods on how I was able to land qtbase earlier this week so hopefully it helps him.
[10:19] <didrocks> Mirv: excellent, keep us posted please :)
[10:19] <didrocks> Mirv: on the one dashboard test failure, seems legit?
[10:21] <Mirv> didrocks: regarding that, I've asked (but not gotten response yet) from elopio/kalikiana about a recent textfield fix in trunk - do they think it'll fix that flaky test too
[10:22] <didrocks> Mirv: ah excellent, thanks for the catchup!
[10:22] <didrocks> sil2100: were you able to upgrade successfully?
[10:25] <mardy> hi! I'd like to ask if there's anything blocking row 240 of the Landing Asks document, since it's not being picked up for landing
[10:28] <popey> Hmm. just crashed unity by swiping back and forth between home and music..
[10:29] <popey> cant easily reproduce it though
[10:29] <didrocks> sil2100: mind looking at mardy's request? ^
[10:31] <didrocks> sil2100: argh, you didn't disable ubuntu-ui-toolkit from daily release and upstream merger as we discussed yesterday, doing so
[10:38] <ogra_> popey, with 4.4 ?
[10:38] <popey> um
[10:39] <popey> good question, how can I tell? ☻
[10:41] <Mirv> didrocks: ok the SDK team believes the new method is much more robust and likely to fix that failing/flaky test
[10:41] <didrocks> Mirv: excellent, thanks for confirming
[10:41] <didrocks> let's see sil2100's feedback on the other results
[10:41] <didrocks> once he's around ;)
[10:41] <sil2100> Well, I didn't do uitk since Mirv was doing it ;)
[10:42] <sil2100> I mean, since I thought that Mirv is dealing with it then he will also disable it as well
[10:42] <sil2100> mardy: looking
[10:43] <popey> ogra_: on flo... unpacking rootfs tarball to system-image ...
[10:43] <popey> that is taking a very very long time
[10:45] <didrocks> sil2100: I'm talking about the other tests :)
[10:45] <didrocks> not the uitk one
[10:45] <didrocks> the weather one seems to be the most important one
[10:46] <ogra_> popey, well, its ~500M
[10:46] <ogra_> popey, you can't tell if you downloaded .img friles from rsalvetis place ?
[10:47] <ogra_> (if you use these you use 4.4.)
[10:47] <popey> yeah, its 4.4
[10:47] <popey> taken at least 20 mins so far
[10:48] <ogra_> thats definitely wrong then
[10:49] <sil2100> mardy: I guess it's fine to release, but we don't do any cu2d landings for touch anymore, so it would have to be released through citrain
[10:50] <ogra_> popey, i'd start over, after 20min the whole process should be done
[10:50] <ogra_> popey, what release is your host on ?
[10:50] <ogra_> this has only been tested on trusty yet
[10:50] <popey> trusty
[10:50]  * popey tries again
[10:51] <davmor2> Morning all
[10:52] <davmor2> popey: what you trying?
[10:52] <ogra_> if that hangs again, please change "set -e" to "set -ex" at the top of the script and pastebin me the output
[10:52] <popey> alan@deep-thought:~/flo/project-rootstock-ng$ ./rootstock-touch-install ./trusty-preinstalled-touch-armhf.tar.gz ../system.img
[10:52] <popey> thats what i'm doing
[10:52] <popey> davmor2: can you dogfood 178 on maguro pls?
[10:53] <davmor2> popey: yeap
[10:53] <popey> ta
[11:00] <popey> ogra_: taken 10 mins
[11:00] <ogra_> and done ?
[11:01] <popey> no
[11:01] <popey> so running with -ex
[11:01] <sil2100> huh
[11:04] <popey> ogra_: loads of errors appearing on device
[11:04] <ogra_> on device ?
[11:04] <popey> Error in select (Bad file number)
[11:04] <popey> in recovery mode
[11:04] <popey> but the script finished!
[11:04] <ogra_> popey, you had android 4.4 installed and run at least once ?
[11:04] <ogra_> ah, good
[11:04] <popey> http://paste.ubuntu.com/6924941/
[11:04] <popey> yes
[11:04] <ogra_> see if ubuntu is up after the reboot then :)
[11:05] <ogra_> where did you see the errors ?
[11:05] <popey> at the bottom of the device
[11:05] <popey> rebooting asks "ROM may flash stock recovery on boot. Fix?" THIS CAN NOT BE UNDONE."
[11:06] <popey> Options are "No" and "Yes - disable recovery flash"
[11:06] <popey> still getting Error in select (Bad file number) appearing at the bottom
[11:06] <ogra_> erm
[11:07] <ogra_> did you do line 6 and 7 of the paste ?
[11:07] <ogra_> looks like you have a broken recovery or boot.img
[11:07] <popey> http://imgur.com/ja7Kkvq
[11:08] <popey> yes
[11:08] <popey> do i have to reboot between each?
[11:08] <ogra_> you need to boot into the newly flsahed recovery
[11:08] <ogra_> *flashed
[11:08] <ogra_> not between, no
[11:09] <popey> i must have done that
[11:09] <popey> because i used fastboot so there's no other way
[11:09] <popey> i mean, i had to boot into recovery to do the rootstock
[11:09]  * popey starts fresh
[11:09] <davmor2> ogra_: fastboot for the recovery is done at the bootloader page so there is no choice but to reboot into the new recovery :(
[11:10] <ogra_> ah, right
[11:10] <popey> ok, done boot and recovery and booted into recovery
[11:11]  * ogra_ doesnt get how you ended up in the flash mode after the acript called "adb reboot"
[11:11] <ogra_> *script
[11:11] <sil2100> Aaaah, CRAP
[11:11]  * sil2100 needs coffee
[11:11]  * popey re-runs the rootstock
[11:11] <popey> flash mode?
[11:11] <popey> it didnt reboot
[11:12] <popey> after i ran the script I was left sat there in recovery
[11:12] <ogra_> oh !
[11:12] <ogra_> it automatically reboots normally
[11:13] <ogra_> hmm, looking at your output it seems like it failed right after pushing the android image
[11:14] <davmor2> ogra_, didrocks, popey: hmmm this could be an issue upgrade to 178 I'm assuming has left me with a blank screen on reboot
[11:14] <ogra_> are you sure the USB cable is good ?
[11:15] <popey> davmor2: a few people have reported that over the last few days
[11:15] <ogra_> aha
[11:15] <ogra_> mount: mounting /dev/block/loop0 on /cache/system/ failed: Device or resource busy
[11:15] <popey> i saw the google screen last week on one update, rebooted again and it was fine
[11:15] <popey> oh
[11:16] <ogra_> seems there is a bug in the cleanup code ... i need to make sure that gets unmounted so a second run doesnt fail
[11:16] <davmor2> hmm apparently this is build 179
[11:18] <davmor2> didrocks, ogra_, popey: http://paste.ubuntu.com/6924986/
[11:18] <popey> thats not 178 ☻
[11:18] <ogra_> 179 is 1h old :)
[11:19] <sil2100> Interesting
[11:19] <ogra_> but only has html5 app changes and dialer and addressbook updates
[11:19] <davmor2> popey: all I did was update I didn't realise that 179 had been released too
[11:19] <ogra_> nothing that should cause issues
[11:21] <davmor2> ogra_: so adb is connecting fine.  The system seems to be running just no shell.  I'll have a look though /var/crash  do you know what logs are likely to be useful?
[11:21] <ogra_> syslog in any case
[11:21] <ogra_> lightdm might be interesting too
[11:21] <ogra_> and unity8 indeed
[11:22] <davmor2> ogra_: no lightdm listed under ps aux
[11:23] <ogra_> root@ubuntu-phablet:/# ps ax|grep light
[11:23] <ogra_>  1425 ?        Ssl    0:01 lightdm
[11:23] <ogra_>  1551 ?        Sl     0:01 lightdm --session-child 10 16
[11:23] <ogra_> thats 176
[11:24] <davmor2> _usr_lib_arm-linux-gnueabihf_qt5_libexec_QtWebProcess.32011.crash
[11:24] <davmor2> _usr_lib_arm-linux-gnueabihf_upstart-app-launch_desktop-hook.32011.crash
[11:24] <davmor2> _usr_sbin_system-image-dbus.0.crash
[11:24] <ogra_> and we got a new lightdm in 177
[11:24] <davmor2> those are in var crash ^
[11:25] <ogra_> well, if lightdm doesnt stRT I'D BLAME LIGHTDM
[11:25] <ogra_> OOPS
[11:25] <sil2100> didrocks: so, I couldn't reproduce the weather app failure here yet, but the test suite seems to act a bit strangely - when the test finishes, it leaves my system with a white screen, as if some application was starting
[11:25] <ogra_> sorry
[11:25] <didrocks> sil2100: interesting, can you try to reach upstream?
[11:25] <ogra_> davmor2, reboot once to make sure it is still not booting, then make the image writable and downgrade lightdm
[11:26] <davmor2> ogra_: let me grab some logs first
[11:26] <didrocks> dbarth_: I do see your packages in the ppa: https://launchpad.net/~ci-train-ppa-service/+archive/landing-012/
[11:26] <Mirv> dbarth_: regarding line 20, we can assign a silo to it but there's the column for you that you've assured that the branches are ready and merge proposals are following the CI Train guidelines. please check those and then change it to Yes.
[11:27] <didrocks> Mirv: I prefer robru to deal with the requests from the webapps team
[11:27] <didrocks> I think we should have waited for Monday
[11:27] <popey> ogra_: 15 mins again and it's just sat there. I adb shell, and then ls /cache/system and it hangs
[11:27] <didrocks> once dbarth_ is trained
[11:27] <ogra_> popey, sigh
[11:27] <Mirv> didrocks: ok, that's fine for me, dbarth_ just pinged me on another channel and I asked him to join here
[11:27] <didrocks> seems that didn't happen, so either we wait or robru is taking the extra maintenance when migrating them
[11:27] <ogra_> popey, it worked for many people since two weeks ... i dont get that
[11:27] <ogra_> popey, could the disk be full or something =
[11:27] <ogra_> ?
[11:28] <dbarth_> didrocks: should i delay my releases until i get trained, or robru wakes up? this needs to be ready for the app show down, i don't think that helps me much to deal with that request this way
[11:28] <dbarth_> seriously
[11:28] <davmor2> ogra_: same issue on the phone mailing list by the look of it
[11:28] <dbarth_> didrocks: so what do you say?
[11:28] <ogra_> davmor2, yes, i need to knwo if rolling back lightdm helps
[11:28] <popey>  /dev/block/loop0       2015824   1231968    681456  64% /cache/system
[11:28] <davmor2> ogra_: yeap I'm just grabbing logs
[11:28]  * Mirv goes back to piloting
[11:29] <didrocks> dbarth_: well, seems like you need urgent release at the last minute which isn't helpful as well ;) but I think we have enough work and can't take more from some people not trained (I think you shouldn't have been moved to CI Train before that time)
[11:29] <dbarth_> it's not last minute
[11:29] <ogra_> davmor2, http://launchpadlibrarian.net/165746075/lightdm_1.9.7-0ubuntu1_1.9.7-0ubuntu2.diff.gz
[11:29] <didrocks> dbarth_: you can wait Monday then?
[11:29] <ogra_> davmor2, please check the permissionf of that dir
[11:29] <ogra_> *permissions
[11:30] <dbarth_> we'll test in a private ppa, and do thinks without the citrain
[11:30] <dbarth_> robru moved us there, but that's yet another great idea that wastes our time
[11:30] <sil2100> Wow, weather-app test just failed, but a different failure
[11:30] <didrocks> dbarth_: not sure why you are speaking about line 12, this was already migrated
[11:30] <dbarth_> i hope it can be better next week
[11:30] <ogra_> (doesnt really look like it could be the cause though)
[11:30] <didrocks> silos 12
[11:30] <seb128> ogra_, I don't see how adding a || true to a command could do a difference
[11:30] <didrocks> interesting…
[11:30] <ogra_> seb128, yeah
[11:31] <popey> ogra_: maybe should I try an older rootfs?
[11:32] <ogra_> popey, or mine
[11:32] <ogra_> popey, older doesnt have the new mir
[11:32] <popey> ogra_: the link in the pastebin?
[11:32] <ogra_> yeah
[11:32] <popey> http://people.canonical.com/~ogra/ubuntu-touch/ubuntu-touch.rootfs-armhf.tar.gz
[11:32] <popey> ok
[11:32] <davmor2> ogra_: drwxr-x---  2 lightdm     lightdm       40 Feb 13 11:13 lightdm
[11:32] <ogra_> looks ok
[11:32] <ogra_> thanks
[11:33] <ogra_> davmor2, thats mako ?
[11:33] <davmor2> ogra_: no maguro
[11:33] <ogra_> oh
[11:33] <davmor2> ogra_: the guy on the list is mako though
[11:34]  * ogra_ wonders if the 4.4 capable Mir even supports maguro ... 
[11:34] <popey> ogra_: so ./rootstock-touch-install ./ubuntu-touch.rootfs-armhf.tar.gz ../system.img
[11:34] <popey> right?
[11:34] <ogra_> yes, always the same
[11:34] <davmor2> ogra_: it worked yesterday on 176 was that pre mir?
[11:34] <ogra_> davmor2, yes
[11:35] <popey> and should I be concerned about lots of errors "E: Can't mount /cache/recovery/ubuntu_command", and command log last_log last_install ?
[11:35] <ogra_> davmor2, oh, wait
[11:35] <ogra_> davmor2, the new Mir is not in any image yet
[11:35] <ogra_> i was mixing up with new unity
[11:35] <ogra_> 178 had the new unity
[11:35] <didrocks> sil2100: do you see what happens when it's failing?
[11:36] <davmor2> ogra_: right how do I rollback lightdm
[11:36] <popey> (there is no /cache/recovery on this device)
[11:36] <ogra_> and 179 only app stuff
[11:36] <didrocks> vila: http://ci.ubuntu.com/smokeng/trusty/touch/, is that expected?
[11:36] <didrocks> (see the top 2)
[11:36] <ogra_> didrocks, broken install
[11:36] <didrocks> seems that test for 179 didn't start?
[11:37] <davmor2> didrocks: 179 is a blank screen
[11:37] <didrocks> urgh
[11:37] <davmor2> see mailing list and message here earlier as soon as I hit it ;)
[11:37] <ogra_> INFO:phablet-flash:Waiting for install to finish on device. Please do not unplug device until phablet-flash finishes.
[11:37] <ogra_> ERROR:phablet-flash:Installation is taking too long or an error occured along the way.
[11:37] <ogra_> davmor2, i dont think thats related
[11:38] <ogra_> the error is that it cant install at all
[11:38] <didrocks> davmor2: I thought you were are 178
[11:38] <ogra_> wont get as far as even attempting to boot
[11:38] <didrocks> not 179
[11:38] <didrocks> http://people.canonical.com/~ogra/touch-image-stats/20140213.1.changes
[11:38]  * didrocks wonders why no new Mir
[11:38] <ogra_> yes, no relevant changes
[11:38] <davmor2> didrocks: I thought 178 was the update turns out it was 179 :(
[11:38] <ogra_> didrocks, britney perhaps ?
[11:38] <didrocks> mir still in proposed
[11:38] <didrocks> yep
[11:38] <ogra_> didrocks, was xorg-server rebuilt ?
[11:39] <davmor2> didrocks: I'm just diagnosing this and then I'll flash 178
[11:39] <didrocks> ogra_: probably not, let's wait for the Mir guys being in
[11:39] <didrocks> ogra_: davmor2: ok, so you are looking at 179?
[11:39] <ogra_> didrocks, yes, buut 178 had no relevant changes for any of these failures
[11:39] <ogra_> err
[11:39] <ogra_> 179
[11:40] <ogra_> didrocks, issues must have come from 178
[11:40] <didrocks> ogra_: but this one booted though :/
[11:40] <ogra_> didrocks, yes, blame UTAH
[11:40] <ogra_> didrocks, did it boot ?
[11:40] <ogra_> did you see the screen ?
[11:40] <ogra_> :P
[11:40] <vila> didrocks: no idea, cihelp ^
[11:41] <didrocks> ogra_: let me retry to flash 178
[11:41] <ogra_> didrocks,  note that davmor2 talks about maguro ... where we saw the install-and-boot error
[11:41] <ogra_> (and might have tested 177 actually)
[11:42] <cjwatson> mir> looks like it needs xorg-server, indeed
[11:42] <didrocks> ogra_: well, that won't explain why we have failures on mako and maguro on 179
[11:42] <ogra_> didrocks, well, the lightdm change doesnt look related, i would blame unity8
[11:43] <cjwatson> oh, xorg-server was uploaded but is stuck, let's see
[11:43] <didrocks> ogra_: I won't blame anything yet
[11:43] <ogra_> didrocks, well, the package set is tiny
[11:43] <didrocks> unless we confirms that 178 isn't fine
[11:43] <didrocks> yeah
[11:43] <didrocks> let me reflash on mako 178
[11:43] <didrocks> with -b
[11:43] <ogra_> didrocks, http://people.canonical.com/~ogra/touch-image-stats/20140213.1.changes has absolutely nothing that could block a boot
[11:43] <cjwatson> wonder why xorg-server/ppc64el just started failing to build with an array-bounds error
[11:44] <ogra_> and http://people.canonical.com/~ogra/touch-image-stats/20140213.changes only has unity8 and lightdm ... but the latter only adds a || true in a postinst
[11:44] <didrocks> ogra_: I agree, but better checking that wondering
[11:44] <cjwatson> I've overridden the never-passed autopkgtest failure there, but ppc64el will need to be sorted out
[11:45] <didrocks> thanks cjwatson
[11:45] <ogra_> popey, my flo has a dead battery, will try to reproduce once i can boot
[11:46] <didrocks> cjwatson: sent to mlankhorst on #ubuntu-desktop
[11:46] <popey> ogra_: tried again with your tgz and it's taking a while again, 10 mins so far
[11:46] <ogra_> 10mins is fine
[11:47] <popey> ok
[11:48] <ogra_> ok, booted into recovery
[11:48] <ogra_> ~ # grep cache /proc/mounts
[11:48] <ogra_> /dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw,nodev,noatime,nodiratime,data=ordered 0 0
[11:48] <popey> ogra_: crashed ..
[11:48] <ogra_> ~ # ls /cache/
[11:48] <ogra_> backup      lost+found  recovery
[11:48] <popey> @lost connection to yold - did it crash?@
[11:48] <popey> ffs us keyboard layout strikes again
[11:48] <ogra_> popey, so you said you dont have /cache in your recovery ?
[11:49] <popey> i have cache
[11:49] <popey> ~ # grep cache /proc/mounts
[11:49] <popey> /dev/block/loop0 /cache/system ext2 rw,relatime,errors=continue 0 0
[11:49] <popey> ~ # ls /cache/
[11:49] <popey> system
[11:49] <davmor2> ogra_: :( root@ubuntu-phablet:/# apt-get install lightdm=1.9.7-0ubuntu1
[11:49] <davmor2> Reading package lists... Done
[11:49] <davmor2> Building dependency tree
[11:49] <davmor2> Reading state information... Done
[11:49] <davmor2> E: Version '1.9.7-0ubuntu1' for 'lightdm' was not found
[11:50] <ogra_> davmor2, yeah, cant be lightdm ...
[11:50] <ogra_> davmor2, rather try to flash the former image and see if that one boots
[11:50] <ogra_> popey, so your recovery img is broken
[11:50] <ogra_> popey, we need to tell rslveti :)
[11:50] <popey> wonder if the dodgy wifi is to blame
[11:51] <ogra_> i doubt it
[11:51] <popey> acce604b1e31ece2e8bd618b887154d3  recovery.img
[11:51] <davmor2> ogra_: will do,  I've grabbed /var/log, /var/crash, and /home/phablet/.cache incase any of it is needed
[11:51] <ogra_> davmor2, good
[11:51] <popey> just re-downloaded and same md5sum
[11:52] <ogra_> popey, yes, i doubt it has to do with the download
[11:52] <ogra_> gimme a sec
[11:53] <davmor2> ogra_: well I found it easier to just grab likely log locations rather than pussyfoot around grabbing one or two files and find out you missed one :)
[11:53] <ogra_> popey, how big is yours
[11:53] <popey> ʘ‿ಠ
[11:53] <ogra_> err
[11:53] <popey> -rw-rw-r-- 1 alan alan   9977856 Feb 13 09:41 recovery.img
[11:53] <ogra_> your recovery.img :)
[11:54] <ogra_> hmm, same size
[11:54] <ogra_> popey, try this one http://people.canonical.com/~ogra/ubuntu-touch/flo-recovery.img
[11:54] <popey> ok
[11:54] <ogra_> and see if there is a /cache/recovery
[11:54] <didrocks> ogra_: reflashed 178 with -b, works here
[11:54] <ogra_> (it is from the 7th, yours is from tonight)
[11:54] <didrocks> let me upgrade now
[11:55]  * ogra_ crosses fingers
[11:55] <ogra_> i'll try maguro soon
[11:55] <ogra_> just trying to nail down poey
[11:55] <ogra_> 's issue
[11:55] <didrocks> sure
[11:56] <didrocks> system settings is stuck in checking for updates… though
[11:56] <didrocks> root      2727  2.5  0.8  31840 15880 ?        Sl   11:55   0:02 /usr/bin/python3.3 /usr/sbin/system-image-dbus
[11:56] <didrocks> ok, let's try to kill it
[11:56] <davmor2> ogra_, didrocks: right 178 is currently being flashed we'll see if the issue is there lowering it to 177 if it is
[11:57] <didrocks> ok, good now
[11:57] <didrocks> (downloading 179)
[11:58] <davmor2> hmmm qt5.2.1 broken my install on mako that is running 4.4.2 :( not good
[11:58] <ogra_> davmor2, geez, stop bresaking two things at the same time !
[11:59] <ogra_> -s
[11:59] <popey> You don't get paid double for breaking twice the things you know davmor2 !
[11:59] <davmor2> ogra_: no choice in the matter I'm being bombarded with requests to break stuff :)
[12:00] <ogra_> well, i would prefer if you didnt break 179 for once :P
[12:00] <davmor2> ogra_: I didn't that was someone else I just confirmed they broked it ;)
[12:01] <ogra_> pfft ... your mail signature is a self fulfilling prophecy !
[12:01] <davmor2> :D
[12:01] <popey> haha
[12:02] <didrocks> ok, stuck on the google logo, not even sure it tried to reboot in recovery
[12:03] <popey> ogra_: its doing more stuff
[12:03] <popey> ogra_: still getting this "Error in select (Bad file number) a lot though, which is worrying
[12:03] <didrocks> Applying update: version-179.tar.xz
[12:03] <didrocks> Done upgrading: Thu Feb 13 12:00:18 GMT 2014
[12:03] <didrocks> I:Ubuntu update completeUbuntu update complete.
[12:03] <ogra_> ogra@styx:~/Devel/branches/rootstock-ng$ adb shell grep cache /proc/mounts
[12:03] <ogra_> /dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw,nodev,noatime,nodiratime,data=ordered 0 0
[12:03] <ogra_> popey, hmm, using a freshly downloaded recovery from rsalveti
[12:04] <ogra_> just re-flashed it here
[12:04] <didrocks> ogra_: ok, recovery applied then
[12:04] <didrocks> but it's clearly 179
[12:04] <ogra_> didrocks, i wasnt talking to you, this is a flo device
[12:04] <popey> ogra_: gnnnnnnn, cache not mounted on mine
[12:04] <didrocks> ogra_: I'm talking to you, was testing on mako :)
[12:04] <popey> it thinks its done though
[12:04] <ogra_> oh, you refer to the backlog
[12:04] <ogra_> sorry
[12:05] <popey> ogra_: http://paste.ubuntu.com/6925152/
[12:05] <ogra_> popey, where exactly do you see that ?
[12:05] <popey> at the bottom of the recovery window
[12:05]  * didrocks reboots in rw mode
[12:05] <ogra_> popey, ah
[12:06] <ogra_> never had that
[12:06] <popey> this is a brand new out of the box flo with 4.4 on it
[12:06] <davmor2> ogra_: ah actually the mako breakage might be related to the maguro one, You have to enable the ppa and then do a dist-upgrade which might of pulled in the package that has broken the release :) So the 2 could be connected \o/ only one breakage then :)
[12:06] <ogra_> didrocks, thats so weird, since we had no changes that could cause it in 179
[12:06] <didrocks> sil2100: progress on 178 test results? :)
[12:06] <didrocks> ogra_: I know, I'm digging in the bisecting
[12:06] <didrocks> asac: FYI image busted ^
[12:06] <popey> ogra_: rebooted and it's broken - busybox shell
[12:06] <ogra_> popey, yes
[12:06] <popey> ☹
[12:07] <ogra_> popey, did you see /cache mounted this time ?
[12:07] <popey> in busybox?
[12:07] <ogra_> no, in recovery before running the script
[12:08] <popey> dunno, didn't check
[12:08] <ogra_> oh
[12:08] <ogra_> reboot to recovery and check please
[12:08] <popey> k
[12:08] <ogra_> the errors you see are most likely from trying to untar a corrupt file
[12:09] <didrocks> ogra_: ubuntu-touch-session
[12:09] <didrocks> it's the cause
[12:09] <didrocks> let me reupgrade it
[12:09] <popey> ogra_: nope, not mounted
[12:09] <ogra_> if there is no /cache mounted it wont fit on disk when pushing it in place
[12:09] <didrocks> ogra_: and yeah, the diff makes no sense
[12:09] <ogra_> crap
[12:09] <ogra_> didrocks, it only adds a single file
[12:09] <didrocks> a single line even if tagged x86 can hurt :p
[12:10] <didrocks> rebooting with latest u-t-s
[12:10] <ogra_> file, not line
[12:11] <didrocks> yeah, marked as x86
[12:11] <ogra_> popey: adb shell mount /dev/block/platform/msm_sdcc.1/by-name/cache /cache
[12:11] <popey> mount: mounting /dev/block/platform/msm_sdcc.1/by-name/cache on /cache failed: Invalid argument
[12:11] <ogra_> didrocks, let me check the logic that handles this file
[12:11] <ogra_> popey, the cache dir is there ?
[12:12] <didrocks> ogra_: ok, confirming it's u-t-s
[12:12] <popey> ogra_: yes
[12:12] <popey> ~ # ls -ld /cache
[12:12] <popey> __bionic_open_tzdata: couldn't find any tzdata when looking for localtime!
[12:12] <ogra_> didrocks, right, there must be a bug in the logic handling the file
[12:12] <popey> __bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
[12:12] <popey> __bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!
[12:12] <popey> drwxr-xr-x    2 root     root             0 Feb 13 12:08 /cache
[12:12] <didrocks> ogra_: let put 30 minutes, we need to rekick an image soon (which will unfortunately have both autopilot and mir :/ then)
[12:12] <ogra_> i cant reboot my flo atm ... one sec
[12:12] <didrocks> ogra_: can you prioritize that one?
[12:12] <ogra_> didrocks, yeah, let me see if it is obvious, if n we'll just roll back
[12:13] <didrocks> davmor2: so… I think we juste need your feedback on image 178 now
[12:13] <didrocks> ogra_: yeah, sounds legit, keep me posted :)
[12:13] <didrocks> sil2100: all the tests failing on maguro… all flaky, nothing new?
[12:14] <ogra_> device=$(getprop ro.product.device)
[12:14] <ogra_> [ -e /etc/ubuntu-touch-session.d/$device.conf ] && . /etc/ubuntu-touch-session.d/$device.conf
[12:14] <ogra_> thats the code dealing with the file
[12:15] <sil2100> didrocks: nothing new it seems, still looking at the messaging-app ones though, since those seem to fail due to introspection issues
[12:15] <ogra_> weird
[12:15] <sil2100> didrocks: I mean, flakyness in autopilot when things are slow
[12:16] <didrocks> sil2100: thanks, so no blocker from your POV?
[12:16] <davmor2> didrocks: it's just finished and I have the starter page so I would say that 178 is good and it is just 179 that is broken
[12:16] <thostr_> can anybody reconfig silo 11 for me?
[12:16] <sil2100> didrocks: no, re-ran address-book-app with high load here on my mako and it still didn't fail, so I would say we're pretty +1
[12:16] <ogra_> davmor2, right
[12:16] <davmor2> didrocks: I'll run the tests though
[12:16] <didrocks> sil2100: davmor2: thanks!
[12:16] <ogra_> we found the issue already
[12:17] <didrocks> sil2100: mind reconfiguring for thostr_?
[12:17] <ogra_> and if LP would stop timing out i could research it
[12:17] <sil2100> thostr_: sure
[12:17] <ogra_> *SIGH*
[12:17] <didrocks> ogra_: the diff contains bzr
[12:17] <didrocks> changes
[12:17] <ogra_> didrocks, yeah
[12:18] <popey> thostr_: is the reply from Andrew on bug 1273625 sufficient for you/james for mediascanner?
[12:18] <ogra_> the former as well, that was my fault ... shouldnt make a difference in the binary
[12:18] <didrocks> ogra_: yep
[12:18] <thostr_> popey: yes, looks good
[12:19] <thostr_> sil2100: reconfigured?
[12:19] <ogra_> didrocks, argh
[12:19] <sil2100> thostr_: reconfigure running
[12:19] <didrocks> ogra_: hum? good argh,  bad argh?
[12:19] <ogra_> bad argh
[12:20] <ogra_> the branch is all messed up
[12:20] <didrocks> ogra_: maybe, let's revert directly, without taking the branch and then taking time to recover?
[12:20] <ogra_> gimme a sec
[12:20] <didrocks> ok
[12:21] <sil2100> thostr_: done
[12:21] <davmor2> ogra_, didrocks: so u-t-s has been updated on the mako too so that would most likely be the cause for its death too :)
[12:21] <thostr_> sil2100: thanks
[12:21] <ogra_> ah, phew, ricardo merged stuff from the last upload, seems all fine
[12:21] <didrocks> davmor2: it's know/sured it's that one, thanks :)
[12:22] <didrocks> davmor2: btw, if you want to play with 179, update to it
[12:22] <didrocks> davmor2: turn rw mode
[12:22] <didrocks> after reboot adb shell
[12:22] <davmor2> didrocks: yeah I was testing 4.4.2 and qt5.2.1 on mako combined so I was hoping it wasn't the qt5.2.1 at fault :)
[12:23] <didrocks> davmor2: just put and dpkg -i https://launchpad.net/~ci-train-ppa-service/+archive/landing-005/+build/5577180/+files/ubuntu-touch-session_0.96_all.deb
[12:23] <didrocks> and reboot
[12:23] <sil2100> hmmm
[12:23] <sil2100> Ah, wait, nevermind!
[12:24] <didrocks> the google logo is really beautiful :)
[12:24]  * didrocks shutdown his phone
[12:26] <ogra_> didrocks, did it boot if you just removed the file or did you rolll back the whole package ?
[12:26] <didrocks> ogra_: I did roll back the whole package
[12:26] <didrocks> I can remove the file, one sec
[12:26] <didrocks> rm /etc/ubuntu-touch-session.d/generic_x86.conf
[12:27] <didrocks> reboooooting :)
[12:28] <didrocks> ogra_: hum, doesn't seem to work
[12:28] <didrocks> maybe the bzr diff makes it horrible to see the real diff
[12:28] <ogra_> lol
[12:28]  * ogra_ found it 
[12:29] <ogra_> ogra@styx:~/Devel/tmp$ ls -l usr/share/ubuntu-touch-session/
[12:29] <ogra_> total 4
[12:29] <ogra_> -rw-r--r-- 1 ogra ogra 395 Feb 13 04:39 usc-wrapper
[12:29] <ogra_> missing the executable bit :P
[12:29] <ogra_> how silly
[12:29] <didrocks> argh
[12:29] <ogra_> didrocks, make it executable
[12:29] <didrocks> doing
[12:29] <ogra_> i bet it boots
[12:29] <davmor2> didrocks: I have a working mako again now
[12:30] <didrocks> davmor2: \o/ tell us if you see anythying worrying (but don't dogfood it at whole length, we'll have another one in the next couple of hours)
[12:30] <didrocks> ogra_: yep
[12:31] <didrocks> ogra_: issue with not using bzr bd to build the package and so the direct tarball pack removed the executable bit?
[12:31] <davmor2> didrocks: I'll come back to testing that after I'm dogfooding 178 on maguro first.  I'll test the mako when I look to the qt 5.2.1 testing after :)
[12:31] <didrocks> davmor2: hum, didn't you +1 on 178 maguro?
[12:32] <davmor2> didrocks: no 178 got bypassed I went from 176 to 179 and hit the dead maguro
[12:32] <didrocks> 13:16:37  davmor2 | didrocks: it's just finished and I have the starter page so I would say that 178 is good
[12:32] <didrocks> ah
[12:32] <didrocks> the it's just finished -> I thought dogfooding
[12:33] <didrocks> ok, tell us if we can promote it ;)
[12:33] <davmor2> didrocks: no that was to say that 178 worked where as 179 didn't
[12:33] <didrocks> oki
[12:33] <ogra_> didrocks, uploaded directly
[12:33] <didrocks> ogra_: thanks!
[12:34] <didrocks> ogra_: the first one who see it published in the release pocket… let's rekick an image
[12:34] <davmor2> bugger m-i-l needs to go to hospital.  I'll be back shortly
[12:34] <didrocks> asac: back to DEFCON0 :p
[12:34] <ogra_> didrocks, right
[12:34] <ogra_> didrocks, you mean 5
[12:34] <ogra_> :P
[12:34] <ogra_> 0 would be after thermonuclear war i think
[12:34] <didrocks> hum, depends how you see the as in a card deck I guess
[12:34] <didrocks> ace*
[12:35] <didrocks> but ok, I was wrong in the order :p
[12:35] <didrocks> ogra_: another good reason to use a silo btw
[12:35] <didrocks> you are really testing what goes to the distro
[12:35] <asac> didrocks: so good or bad?
[12:35] <asac> all good?
[12:35] <didrocks> asac: all good -> next image will be fine again
[12:35] <ogra_> asac, yep
[12:37] <didrocks> ogra_: the recovery doesn't contain any device-specific code, right?
[12:37] <ogra_> asac, two issues ... i hadn't merged back changes in time into the tree, so rsalveti did that ... and he didnt use a silo and tested so he missed that his manual merge had dropped the executable bit on a session start script
[12:37] <ogra_> didrocks, a lot ... the same amount as the android container image does
[12:38] <didrocks> who guessed executable bits was important? :p
[12:38] <ogra_> didrocks, like fstab and a device specific init.rc
[12:39] <didrocks> ogra_: ah, yeah, makes sense
[12:39]  * didrocks is trying some recovery experiments while the fix is flowing
[12:39]  * ogra_ twiddles thumbs waiting for britney
[12:39] <ogra_> it already built
[12:40] <didrocks> I'm sure this is going to make it faster :p
[12:40] <ogra_> yeah, twiddling thumbs speeds up everything
[12:40]  * ogra_ notes the time and gets some breakfast 
[12:41] <asac> ogra_: he should use a silo then
[12:42] <asac> rsalveti: ^^
[12:46] <ogra_> asac, yes, next time i guess :)
[12:46] <asac> sure. i think its not well understood that silos can nicely be used for package only uploads too
[12:46] <asac> so we should market that more explicitely
[12:46] <didrocks> in that case, we can directly use the branch with MP
[12:46] <didrocks> that would be even more in line
[12:48]  * popey looks for an rsalveti to save him from tablet insanity
[12:48] <ogra_> it was a silly coincidence of a broken merge with an otherwise 100% safe change
[12:48] <cjohnston> asac: didrocks, should we work on changing the 'landing instructions' in the topic?
[12:49]  * ogra_ would likely have made the same mistake if he had done the same change
[12:49] <didrocks> popey: with puppet eyes :)
[12:49] <asac> cjohnston: good point
[12:49] <didrocks> ogra_: yeah, he was the victim of your changes :p but it clearly means that we should always test the final product :p
[12:49] <ogra_> yes
[12:49] <didrocks> ogra_: do you want that we put your branch in CI Train?
[12:50] <ogra_> ++
[12:50] <cjohnston> didrocks: we also need to better promote that your team handles ci train issues
[12:50] <didrocks> ogra_: we need to have the ps-jenkins bot having commit rights to it
[12:50] <didrocks> cjohnston: I think with yesterday's jasoncwarner email, that was quite clear
[12:50] <ogra_> didrocks, how do i do that ?
[12:50] <ogra_> https://code.launchpad.net/~phablet-team/session-manager-touch/trunk is the branch
[12:50] <didrocks> cjohnston: I didn't see many requests that you were trapped into though (at least during my work days)
[12:50] <didrocks> hum
[12:50] <didrocks> I think that should be good
[12:51] <didrocks> let me look at the bot
[12:52] <didrocks> ogra_: ok, all is good then
[12:52] <ogra_> great
[12:52] <didrocks> ogra_: I think you should write a small procedure like "test that the phone boot"
[12:52] <didrocks> and you will be done
[12:52] <didrocks> ogra_: do you want to join Monday's bootcamp?
[12:52] <ogra_> didrocks, yeah
[12:53] <didrocks> let me add you to the list :)
[12:53] <cjohnston> didrocks: it didn't seem very clear to me.. I've forwarded on probably 4 or 5 people to your team since this started, not sure about the rest of the ci team
[12:54] <thostr_> sil2100: didrocks: robru: can I get a silo for line 18?
[13:00] <didrocks> ogra_: what's the difference between ubuntu-ramdisk-recovery+mako.img and ubuntu-preinstalled-recovery-armel+maguro.img?
[13:01] <ogra_> didrocks, one is just a ramdisk ... the other is a partition image
[13:02] <didrocks> ogra_: so, we always flash the partition image, right? Not really sure to know that difference
[13:03] <didrocks> ramdisk is just initrd for me
[13:03] <didrocks> so nothing to do with recovery and so on
[13:03] <ogra_> the partition image is created by a specific android img tool ... so you can just dd it
[13:03] <ogra_> it has a filesystem
[13:03] <ogra_> the inird is just an initrd
[13:04] <ogra_> (no filesystem on the latter)
[13:06] <didrocks> ah ok, so even recovery has a traditional ramdisk, ok
[13:06] <didrocks> thanks ogra_
[13:06] <thostr_> didrocks: sil2100: can I finally get a silo???
[13:06] <ogra_> well, it not a traditional one, its an android one (using bionic binaries only)
[13:07] <didrocks> thostr_: I can't get/assign to everyone everything. I would hope the work would be divided between different people
[13:08] <didrocks> in addition to that, I see you have 3 silos already
[13:08] <didrocks> 2 being ready
[13:08] <didrocks> and one with a merge conflict
[13:08] <kgunn> sil2100: i know robru hit publish for mir about 9 hours ago...but the packages seem not published yet ?
[13:08] <didrocks> maybe those can be worked upon in between?
[13:08] <kgunn> silo 13
[13:09] <kgunn> bbiab, a.m. house duties
[13:09] <didrocks> kgunn: xorg was stuck in proposed (one failing test which never passed on ppcel64)
[13:10] <didrocks> kgunn: it fails to migrate from proposed
[13:10] <didrocks> was xorg really rebuilt against latest mir?
[13:12] <ogra_> didrocks, i thought you asked rob in last nights meeting to do that
[13:12] <didrocks> ogra_: I did, I wonder if they did bump the build-dep
[13:12]  * didrocks downloads the deb
[13:14] <didrocks> hum
[13:14] <didrocks> so, it seems to have picked the right version
[13:15] <ogra_> weird
[13:15] <ogra_> well, didnt cjwatson say above he unstuck it in the proposed-migration ?
[13:15] <didrocks> because of xorg autopackagetests failing
[13:16] <didrocks> so, now, in update_output.txt, he shold consider Mir + folks with xorg
[13:16] <cjwatson> No, I unstuck half of it
[13:16] <ogra_> ah
[13:16] <cjwatson> mlankhorst is working on the rest, which is fixing the build on xorg-server/ppc64el
[13:16] <didrocks> ah, the out of date on ppc64el
[13:16] <didrocks> ok, making sense
[13:16] <didrocks> thanks cjwatson
[13:16] <cjwatson> xorg was really rebuilt against latest mir, but it won't take effect until it doesn't regress arch support
[13:17] <didrocks> yeah
[13:17] <ogra_> well ... at least we dont need to be worried about getting autopilot and Mit into the next image at the same time
[13:17] <ogra_> *Mir
[13:17] <cjwatson> The autopkgtest was firefox not xorg, but it was an rdep of xorg-server
[13:17] <didrocks> ogra_: that was my evil thought :p
[13:17]  * ogra_ frantically reloads remadison in his terminal 
[13:17] <didrocks> cjwatson: ok, I mixed your 2 statements and only reread the 2 second migration
[13:17] <cjwatson> I did wonder why you thought mir was going to be in quickly
[13:18] <didrocks> kgunn: so, you need mlankhorst to fix xorg build on ppc64el, that's why the spreadsheet is telling you everything is blocked in proposed
[13:32] <ogra_> [13:33] <didrocks> ogra_: \o/
[13:34] <didrocks> davmor2: "moar" results on image 178?
[13:46] <asac> popey: ogra_: you guys had upgrade issues today, right?
[13:46] <popey> i didnt
[13:46] <asac> like the hard to reproduce "cant upgrade" bug
[13:46] <ogra_> asac, yesterday
[13:46] <popey> i had stupid canonical wifi issues
[13:46] <asac> do you
[13:46] <asac> popey: but that auto recovered after you got better network?
[13:46] <asac> ogra_: how did you fix it?
[13:46] <ogra_> but i didnt do a "normal" upgrade since
[13:46] <popey> yes
[13:46] <asac> ogra_: do you know whats going on?
[13:46] <ogra_> asac, upgrade via cmdline always works
[13:46] <asac> popey: how was the feedback/error reporting?
[13:47] <asac> ogra_: did you not investigate?
[13:47] <ogra_> bug 1277589
[13:47] <popey> asac: it span for ages then said "Timeout"
[13:47] <popey> so fine enough for my issue
[13:47] <ogra_> asac, barry and mandel are investigating ... i wanted to take a look actually, but then 179 broke
[13:47] <asac> ogra_: whats that blacklist?
[13:47] <ogra_> asac, a list of blacklisted keys
[13:47] <ogra_> it gets downloaded from the server (and usually is there)
[13:47] <asac> mandel: how is investigation going?
[13:48] <ogra_> there must be something deleting it to early or some such
[13:48] <ogra_> or it is corrupt
[13:48] <asac> FileNotFoundError if corrupt?
[13:49] <ogra_> well, the traceback shows a gpg error
[13:50] <ogra_> it might try to decrypt it or some such, fail and then trigger the file not found a level above
[13:54] <ogra_> asac, the prob with debugging is that it doesnt happen reliably for everyone and randomly across devices ... the upgrader is also configured to immediately remove all downloaded files after it ran (or died) so you can only inspect if they are there while actually downloading
[13:55] <ogra_> asac, popey reported it for the first time around image 166 ... where we got a new libqt5networking (not sure thats the exact name) ... might be related to that and mandel wanted to look into this
[13:57] <thostr_> could anybody reconfig silo 11 again (sorry)
[13:58] <didrocks> sil2100: are you back? I'll need to leave, can you get the pending requests? ^
[14:01] <kgunn> didrocks: read the scrollback....so i don't understand, wasn't it just a rebuild of xorg-server ?
[14:01] <didrocks> kgunn: yeah, but the rebuild didn't pass on ppc64el
[14:01] <didrocks> when it used to
[14:01] <didrocks> so stuck in proposed
[14:02] <kgunn> didrocks: doesnt that make you wonder....like, if i hadn't requested a rebuild...that likely would be broken in general ?
[14:02] <ogra_> kgunn, mlankhorst is (or was at least) on it in #ubuntu-devel
[14:02] <kgunn> e.g. is there some missing mechanism to catch xorg integration?
[14:02] <didrocks> kgunn: yeah, not related to Mir at all
[14:02] <didrocks> kgunn: well, we'll need the ppa to build on arm64 and ppc64el so that you know it before copying to proposed
[14:03] <didrocks> that will be possible once we have more hw
[14:03] <didrocks> right now, we only know about such issue once it's in proposed
[14:03] <didrocks> but at least, you can see that there is an issue thanks to merge and clean
[14:03] <kgunn> didrocks: of course....i was just thinking in a broader sense of xorg being part of ubuntu product...but somehow it generated a problem on its own within a week
[14:04] <ogra_> kgunn, yeah, because the PPAs can not build for two of the architectures yet
[14:04] <ogra_> we're kind of flying blind on arm64 and ppc64el
[14:06] <didrocks> ogra_: do you know what makes recovery rebooting with --update-ubuntu ?
[14:06] <ogra_> didrocks, nope
[14:06] <thostr_> sil2100 seems to have lunch... :(
[14:07] <ogra_> didrocks, most likely a script shipped inside the device tarball
[14:07] <didrocks> thostr_: weird, maybe asac may know, but yesterday he disappeared for 2 hours, seems the same today
[14:07] <didrocks> ogra_: I'm looking for it
[14:08] <ogra_> didrocks, probably system-image-upgrade from /sbin
[14:08] <thostr_> didrocks: sure... I just neeeeeed somebody pressing the reconfig button...
[14:08] <didrocks> ogra_: right, that's the script executed
[14:08] <ogra_> (just a guess though, i dont have a device in recovery here atm)
[14:08] <asac> didrocks: Mirv: can you reconfigure thostr silo while sil is way?
[14:08] <kgunn> ppc64el....powerpc reminds me of the mobile world when we kept having to support AMPS after 3G was out..
[14:08] <didrocks> asac: well, I keep doing that (configuring/assigning), I would love other people to look at jump into it (and not only doing that when I'm not around)
[14:08]  * didrocks sighs
[14:09] <asac> didrocks: right. think the reconfigure silo feature for trusted lander is what will help here ... once we get the time fo rhtat
[14:10] <didrocks> asac: it's not about reconfiguring, assigning as well
[14:10] <didrocks> asac: did most of the publication and assignement and reconfiguring today for instance
[14:10] <asac> didrocks: sure, step by step
[14:10] <didrocks> thostr_: done
[14:10] <asac> i know
[14:11] <didrocks> asac: seems people are away for hours multiple time of the day and there is no issue
[14:11] <didrocks> I should start doing the same…
[14:11] <asac> didrocks: those are your people :)
[14:11] <thostr_> didrocks: thanks
[14:11] <davmor2> ogra_, didrocks: was there a new qtsensors land recently?  it seems now that if you open a web app and then cover the light sensor the screen blanks.  Not sure if that is meant to happen?
[14:11] <Mirv> asac: o/ sure I could have
[14:11] <didrocks> asac: and I'm not a manager
[14:11] <asac> Mirv: why didnt you reconfigure the silo for thostr?
[14:11] <asac> didnt know that he wanted that?
[14:12]  * asac thinks introducing the trainguard nick
[14:12] <bzoltan> didrocks: the address-book-app tests give pretty consisntant failures for me on mako with today's image -> http://pastebin.ubuntu.com/6925644/
[14:12] <didrocks> asac: thostr_ only pinged sil2100 and I
[14:12] <asac> that gest highlighted would help parallelizing requeste better
[14:12] <asac> and distribute workload
[14:12] <ogra_> davmor2, not that i'm aware of
[14:12] <asac> as long as ONE of 3 is avail it should be good
[14:13] <davmor2> popey: can you try that? open the bbc news app and cover the light sensor
[14:13] <Mirv> asac: so that'd work like the ci_help? sounds good, so everyone wouldn't need to remember all the nick names of the landing team members
[14:14] <asac> Mirv: right. thnk we coudl do it lik the CI Vanguard... just have a common nick, but also put the ones currently active into topic
[14:16] <davmor2> Mirv: good news 5.2.1 is really nice :)
[14:16] <davmor2> Mirv: I'll run some autopilot tests against it once I'm done testing 178
[14:17] <davmor2> didrocks: okay I don't see ant new issues with 178.  However there is this annoying light/proximity sensor issue that I don't remember seeing before
[14:18] <didrocks> bzoltan: mako or maguro?
[14:18] <davmor2> didrocks: but that shouldn't stop the presses I think it is really minor
[14:18] <didrocks> davmor2: ok ;)
[14:18] <didrocks> ogra_: promoting?
[14:19] <davmor2> didrocks: whose the beest person to talk to about the sensor issue will it be thostr_ team?
[14:20] <bzoltan> didrocks: mako
[14:20] <rsalveti> didrocks: ogra_: sorry for the noise, didn't noticed the '-x' when merging back ogra_'s changes
[14:20] <didrocks> bzoltan: image 178? I don't see that issu eon the dashboard
[14:20] <asac> jibel: your testcase on the download/udpate bug
[14:20] <bzoltan> didrocks: I know...
[14:20] <ogra_> rsalveti, well, it was at least 50% my fault (if not more)
[14:20] <asac> jibel: has anyone been able to confirm it like that?
[14:20] <ogra_> rsalveti, dont worry, we found it in the end
[14:21] <jibel> asac, I don't know I didn't ask anyone to confirm
[14:21] <ogra_> didrocks, will do if people stop pinging me in 20 channels :P
[14:21] <davmor2> rsalveti: don't worry we'll all blame ogra_ anyway ;)
[14:21] <rsalveti> yeah, thanks for that :-)
[14:21] <jibel> davmor2, ^can you?
[14:21] <rsalveti> hahah
[14:21] <didrocks> rsalveti: no worry, we are recovering right now :) (but it shows we need to really build the binary and test from it, we always can have this kind of weird descrepency)
[14:21] <rsalveti> popey: sorry, didn't read the entire backlog, but were you able to flash your flo?
[14:21] <didrocks> ogra_: we live in the same sad world :p
[14:21] <rsalveti> didrocks: yup
[14:21] <popey> rsalveti: yeah, all done. thanks.
[14:21] <rsalveti> popey: great, what was the issue
[14:21] <rsalveti> ?
[14:21] <davmor2> jibel: can I what?
[14:21] <didrocks> davmor2: hum… I would say zoltan's or phonefundation
[14:22] <popey> i have no idea rsalveti - i flashed back to stock android and started again, worked
[14:22] <jibel> davmor2, reproduce the download/upgrade bug
[14:22] <asac> bash: cd: /home/phablet/autopilot: No such file or directory
[14:22] <jibel> davmor2, bug 1277589
[14:22] <davmor2> jibel: I was able to upgrade to 179 earlier so no
[14:22] <davmor2> jibel: it's a racy bug as far as I can tell
[14:22] <jibel> davmor2, I added a test case this morning, and I repeated it 3 times
[14:23] <ralsina> didrocks: is there a chance of landing ask row #242 ?
[14:23] <asac> davmor2: jibels instructions install 176 and try upgrading to 179
[14:23] <asac> did ou start from 176 too?
[14:23] <davmor2> jibel: oh sweet hang on then
[14:23] <cjwatson> kgunn: the mechanism for catching xorg integration is exactly the one that's firing right now
[14:24] <didrocks> rsalveti: can that wait on Monday? You will have the self-service checkin and there is a little bit too much noise to land it right now
[14:24] <davmor2> jibel, asac: right let me look into this issue on the sensors first and then I'll do a run
[14:25] <rsalveti> popey: did you boot android after oem unlock?
[14:25] <kgunn> cjwatson: ....what i didn't say was AMPS made loads of money :)
[14:25] <popey> rsalveti: probably not, no.
[14:25] <davmor2> popey: that'll be why I had it yesterday :)
[14:25] <popey> rsalveti: i did oem unlock then immediately on to the flashing
[14:25] <rsalveti> didrocks: sorry, what do you want to wait for monday?
[14:25] <rsalveti> popey: right, that was the issue then
[14:25] <popey> yay
[14:25] <popey> glad we got to the bottom of it, thanks rsalveti
[14:26]  * rsalveti is still waking up
[14:26] <didrocks> rsalveti: argh, sorry was for ralsina
[14:26] <didrocks> ralsina: can that wait on Monday? You will have the self-service checkin and there is a little bit too much
[14:26] <popey> need to make the instructions nice and explicit for numpties like me ☻
[14:26] <didrocks> noise to land it right now
[14:26] <rsalveti> didrocks: great, I'm not that crazy then :-)
[14:26] <davmor2> popey: reflash android boot into it enable developer mode and then try again
[14:26] <cjwatson> kgunn: we can probably start building ppc64el in the CI PPAs after the dump-and-rebuild we're about to do
[14:26] <Mirv> davmor2: great! :)
[14:26] <ogra_> popey, i thought the "please boot into android 4.4 at least once after oem unlock" would be enough, sorry
[14:26] <cjwatson> depending on whether the finer-subdivided builders work out
[14:26] <didrocks> rsalveti: heh, indeed or you are awaken enough, let's say ;)
[14:26]  * Mirv -> shop, patch pilot shift done too
[14:26] <cjwatson> arm64 is a more difficult state of affairs
[14:27] <ogra_> popey, pastebin needs <blink> tags
[14:27] <ogra_> :)
[14:27] <popey> it doesnt say that
[14:27] <kgunn> cjwatson: so let's pretend i'm selfish about mir landing on arm/touch images....what's my eta ?
[14:27] <ogra_> "first make sure to have booted android 4.4 on the device at least once and that the bootloader is unlocked (fastboot oem unlock)"
[14:27] <popey> grammatically it says boot 4.4 at least once. also, make sure bootloader is unlocked.
[14:27] <ogra_> yeah
[14:27] <popey> but not "boot after unlock"
[14:27] <ogra_> i need to improve my english :)
[14:27] <cjwatson> kgunn: I don't know how far mlankhorst has got.  I was helping him out earlier
[14:28] <popey> hehe
[14:28] <popey> \o/ education all round
[14:28] <ogra_> :)
[14:28] <popey> everyone wins
[14:28] <popey> thanks ogra_
[14:28] <ogra_> well, thanks for reserching
[14:29] <davmor2> ogra_: pffff playing the english isn't my first language card again ;)
[14:30] <didrocks> sil2100: really not around still? :/
[14:30] <ogra_> :D
[14:30] <ralsina> didrocks: sure, it an wait until monday
[14:30] <didrocks> ralsina: thanks a lot, that's a relief :)
[14:30] <rsalveti> oh, mir is stuck, that's why the ppc64el discussion
[14:30] <didrocks> rsalveti: yep, due to xorg
[14:30] <rsalveti> at least I can still use the packages from my ppa
[14:31]  * rsalveti creates another x86 rootfs
[14:31] <rsalveti> ogra_: we need to get the tarball published for that as well
[14:31] <rsalveti> ogra_: what was blocking us?
[14:31] <didrocks> thostr_: cyphermox_ is on now, so you can direct your requests to him :)
[14:31] <rsalveti> the name for the x86 emulator is generic_x86
[14:31] <thostr_> didrocks: thanks
[14:31] <cyphermox_> didrocks: thanks for throwing me under the bus ;)
[14:32] <davmor2> bzoltan: Hey dude so with a web app open if I cover the sensors is the screen meant to blank?
[14:32] <didrocks> cyphermox_: you're really welcome! :)
[14:32] <ogra_> rsalveti, cdimage
[14:32] <ogra_> rsalveti, nees code changes
[14:32] <ogra_> *needs
[14:32] <rsalveti> ogra_: would you mind changing it?
[14:33] <rsalveti> you know the codebase better
[14:33] <bzoltan> davmor2: no idea...we should ask dbarth or alex-abreu
[14:33] <davmor2> bzoltan: thanks
[14:33] <ogra_> rsalveti, if i find any spare time today ... everyone seems to have issues flashing or upgrading today ... not sure what made me the go-to guy
[14:33] <rsalveti> ogra_: haha :-)
[14:39] <ogra_> 000 Image 180 DONE [14:39] <ogra_> oops
[14:39] <ogra_> [14:39] <asac> does the syntax matter?
[14:40] <asac> for something
[14:40] <asac> hehe
[14:40] <ogra_> asac, i know some poeple highlight on [14:40] <popey> ☻
[14:40] <popey> o/
[14:40] <asac> they do?
[14:40] <asac> :)
[14:40] <ogra_> :)
[14:40]  * asac will from now on highlight on =**=
[14:40] <asac> :)
[14:40] <asac> actually
[14:41] <asac> =***=
[14:41] <asac> three star general summoning that is
[14:41] <ogra_> but you need someone to type that :P
[14:42] <ogra_> the [14:46] <didrocks> rsalveti: stupid question, but if I adb shell while I'm in recovery, try to change /sbin/system-image-upgrader, after rebooting I still get the old version, the partition is in ro mode but I don't get yield at changing things?
[14:46] <didrocks> rootfs on / type rootfs (rw)
[14:46] <didrocks> though
[14:47] <rsalveti> didrocks: hm, it's just an initramfs though
[14:47] <ogra_> didrocks, its an initrd
[14:47] <ogra_> tmpfs ...
[14:47] <rsalveti> right
[14:47] <didrocks> rsalveti: ah ok, so I need to build the recovery partition and flash that for my testing?
[14:47] <ogra_> you would have to unpack the img, change it and re-pack
[14:48] <didrocks> ok
[14:48] <plars> 180 is flashing now in ci
[14:48] <mandel> ogra_, sorry I was out for lunch, I have been able to reproduce it a couple of times (or at least I think so) in the s-i tests
[14:48] <didrocks> great plars!
[14:48] <ogra_> mandel, did you try to roll back the libqt5networking stuff ?
[14:49] <ogra_> to see if it goes away then ?
[14:49] <mandel> ogra_, yes, and it that case it does not, qnetwork is updated when something in qt is changed, afaik so that the entire qt uses the same version number and in that udpate it was due to something related to GL
[14:50] <mandel> ogra_, I'm looking in every possible direction and barry is going to test it with ricks phone
[14:50] <ogra_> k
[14:50] <mandel> ogra_, in the mean time we have more logging in udm etc.. to try to see exactly the state of udm
[14:51] <ogra_> mandel, the syslog in the bug seems to not download the blacklist file
[14:51] <ogra_> while the client log seems to indicate it asked for it
[14:51] <mandel> ogra_, indeed, it seems an issue there and is weird.. maybe that is the issues and not the network, that is why the logging has been increased in trunk
[14:52] <mandel> ogra_, if we can reproduce it with the new logging we might be able to see the exact request files
[14:52] <mandel> ogra_, there was a bad merge added to udm in the img that removed ALL logging :-/
[14:52] <ogra_> ah, crap
[14:56] <jibel> mandel, if you can provide a .deb with the new logging, I can install it and try it.
[14:57] <mandel> jibel, le me find one for you..
[14:57] <didrocks> mandel: jibel: I think thostr_ has latest trunk in one silo
[14:57] <didrocks> so you will be even able to test latest of latest :)
[14:58] <mandel> didrocks, that would be great, I have packages but not for armhf
[14:58] <mandel> but I could build one, but if there is a silo, better
[14:58] <jibel> didrocks, okay, ping me when there is something ready
[14:58] <didrocks> jibel: ping :p
[14:58] <didrocks> mandel: jibel: https://launchpad.net/~ci-train-ppa-service/+archive/landing-011/
[14:59] <mandel> didrocks, jibel or this => https://code.launchpad.net/~mandel/+recipe/ubuntu-download-manager-daily-demo
[14:59] <didrocks> mandel: as told this morning, thostr_ is doing this landing for you, just ensure that everything is tested :)
[14:59] <didrocks> mandel: this deb will hopefully go to distro, so the more testing…
[14:59] <mandel> didrocks, superb,should I write a testing wiki plan??
[15:00] <didrocks> mandel: I didn't dare asking you that, but yeah, that will be already done for next week :)
[15:00] <ogra_> didrocks, until the phones run out of diskspace indeed, because syslog filled it up :P
[15:00] <didrocks> and can help on testing that one
[15:00] <thostr_> mandel: so, yes, ppa is ready and contains the very latest changes tvoss just did two hours ago
[15:00] <didrocks> ogra_: I thought we got it fixed, didn't we?
[15:00] <mandel> didrocks, awesome :)
[15:00] <ogra_> didrocks, nope, we still dont have a complete plan
[15:00] <didrocks> thostr_: please coordinate with mandel on the testing to ensure everything is covered
[15:00] <ogra_> didrocks, and the kernel needs quietening
[15:00] <ogra_> apw wanted to look into that
[15:00] <didrocks> ogra_: argh :p
[15:00] <mandel> thostr_, great, let me know when you need me and I'll be there
[15:00] <ogra_> the android drivers are very noisy
[15:02] <Laney> hmm
[15:02] <Laney> I guess I need to manually flash back to the previous image
[15:03] <didrocks> Laney: if image #179 -> see phone ML
[15:04] <Laney> seems likely!
[15:04] <ogra_> Laney, there is a workaround
[15:04] <ogra_> or just use system-image-cli to upgrade to 180
[15:06]  * didrocks is going for a run
[15:07] <Laney> ogra_: is adb shell supposed to work?
[15:07] <ogra_> yep
[15:07] <ogra_> always
[15:07] <Laney> I just get the Google logo forever
[15:07] <Laney> and adb doesn't find any device
[15:08] <ogra_> hmm, adb should always start ...
[15:08] <ogra_> even if the initrd cant boot it panics to an adb shell
[15:08] <Laney> ho hum
[15:08] <ogra_> there is only one small time where there cant be adb ... probably it is just slow ?
[15:08] <Laney> I left it for 90 minutes over lunch ;-)
[15:09] <ogra_> thats strange
[15:09] <ogra_> tried a reboot already ?
[15:10] <Laney> just did
[15:10] <Laney> I'll just do the manual thing
[15:11] <apw> ogra_, i did ask someone to get me a dmesg to look at with all the buttons pressed but didn't see much to expect hugly overly full logs from
[15:11] <apw> ogra_, if you have one which is doing that, could you atach the log to a bug for me
[15:12] <ogra_> apw, let it suspend and wake it up ... the power mgmt makes a lot of noise each time it suspends
[15:12] <ogra_> i think jdstrand even mentioned that in the bug
[15:12] <ogra_> with some syslog snippet
[15:13] <ogra_> apw, bug 1270248
[15:19] <Laney> ogra_: which file on cdimage is the important one?
[15:20] <ogra_> Laney, none .. cdimage is only input for the system-image.ubuntu.com creation
[15:20] <Laney> I need to flash manually, can't I just take from there?
[15:21] <ogra_> Laney, bzr branch lp:project-rootstock-ng ... take a look at the rootstock-touch-install script
[15:21] <ogra_> pull the system.img and tar.gz from cdimage to use it for a manual flash
[15:22] <ogra_> note that you need to init system-image-cli if you want OTA upgrades to happen later
[15:22] <ogra_> (system-image-cli --channel devel -b0 -v)
[15:22] <Laney> does phablet-flash still work? :-)
[15:22] <ogra_> should too
[15:22] <ogra_> but its in "maintenance mode" :)
[15:23] <ogra_> rootsotck-ng is the way for a manual install
[15:23] <davmor2> Mirv: do you want qt5.2.1 testing on anything other than mako or is that your target for now?
[15:23] <Laney> okay, I'll try that then
[15:24] <ogra_> Laney, http://paste.ubuntu.com/6915695/ ... ignore all the stuff above line 9
[15:24] <tedg> So I'm looking at silo 5 and it's saying that url-dispatcher never made it to the PPA, which is what the PPA says too, but it seems in the log there is an upload.
[15:24] <tedg> I'm not sure where to go with it at this point.
[15:24] <ogra_> (and indeed you want to get the official tarball)
[15:25] <tedg> http://162.213.34.102/job/landing-005-1-build/38/consoleText
[15:25] <Laney> ogra_: okay, I don't see that the one from ~ogra is used anyway
[15:26] <jibel> mandel, I reproduced the upgrade bug with udm 0.3+14.04.20140213.3-0ubuntu1 from the PPA. Which log do you want?
[15:26] <Laney> man, I only get 4MB/s from cdimage these days
[15:26] <Laney> SHOCKING
[15:26] <ogra_> Laney, yeah, messed up instructions :)
[15:26] <ogra_> but it should give you the right idea
[15:26]  * ogra_ trusts your cleverness to get along 
[15:26] <mandel> jibel, old under /var/log/ubuntu-download-manager please
[15:26] <mandel> all
[15:26] <mandel> gosh.. I'm so tired I'm typing the wrong words..
[15:34] <jibel> mandel, log file attached to the bug report
[15:34] <mandel> jibel, superb, thx
[15:34] <Laney> come on rootstock, you can do it
[15:34] <tedg> So, I guess, can someone rebuild silo 5 and we'll see if it happens again?
[15:35] <mandel> jibel, what file did it say it was missing?
[15:36] <ogra_> mandel, search for blacklist
[15:36] <ogra_> not in the log
[15:36] <mandel> ogra_, exactly!
[15:36] <ogra_> something prevents the request from reaching u-d-m
[15:36] <jibel> mandel, /var/lib/system-image/blacklist.tar.xz
[15:37] <ogra_> jibel, timestamp ?
[15:37] <jibel> ogra_, timestamp of what?
[15:37] <ogra_> jibel, that file :)
[15:37] <ogra_> was it put in place right now
[15:37] <ogra_> or is it a leftover from a former try
[15:37] <mandel> ogra_, look at the top of the file => Log file created at: 2014/02/13 15:19:48
[15:38] <jibel> ogra_, how can I provide the timestamp of a missing file
[15:38] <mandel> ogra_, I have greatly improved udm logging :)
[15:38] <jibel> ?
[15:38] <ogra_> jibel, lol, i thought you meant the file was there in that path :P
[15:38] <ogra_> mandel, yeah, i was confused
[15:40] <mandel> I'm going to improve the logs even more by adding a tag per group download to be added in every download owned by the group
[15:40] <ogra_> mandel, so in the communication only system-image, dbus and u-d-m are involved, right ?
[15:40] <mandel> jibel, ogra_, barry it looks like udm never gets asked for that file
[15:41] <mandel> ogra_, yes, is just between udm and s-i
[15:41] <ogra_> couldnt be that i.e. system-settings has some code that filters out files with the name "blacklist" or some other weird stuff
[15:41] <ogra_> so that the request never gets through
[15:41] <mandel> ogra_, system settings should not be doing anything AFAIK
[15:41] <bfiller> didrocks: I have 4 requests in CI train. I had forgotten to change the ready column to yes (: But done that now, so whenever you guys have a chance they need silos
[15:41] <ogra_> yeah, that was just hypothetical
[15:41] <mandel> ogra_, system setting just talks with si, but is a good idea
[15:41] <ogra_> and because i could blame seb128 if it was true :P
[15:42] <seb128> ogra_, keep trying! :p
[15:42] <mandel> ogra_, I think I'm going to add a log line per create download so that we see the exact struct sent to udm
[15:42]  * ogra_ prepares for friday :)
[15:42] <ogra_> mandel, good idea
[15:42] <ogra_> i wonder if dbus polkit policies changed somehow
[15:42] <mandel> seb128, is your fault, is a consensus between spain and germany, also, you broke the euro ;)
[15:42]  * ogra_ digs changelogs
[15:43] <seb128> lol
[15:43] <ogra_> LOL ... and look who did the last polkit upload :)
[15:44] <ogra_> but the changelog seems unrelated
[15:44] <Laney> excellent, haz working image
[15:44] <ogra_> yay
[15:53] <davmor2> Mirv: hmmm no ringtone on qt5.2.1
[16:00] <tedg> cjohnston, Can you rebuild a silo? http://162.213.34.102/job/landing-005-1-build/
[16:00] <seb128> tedg, "rebuild"?
[16:01] <tedg> seb128, The build failed for an unknown reason, seems the PPA didn't get the package even though it says that it uploaded :-/
[16:01] <tedg> seb128, So I need someone who can hit the "build" button.
[16:02] <seb128> tedg, I can do that for you, but it's weird
[16:02] <tedg> seb128, Cool, thanks, yes it is.
[16:02] <tedg> Don't know how dput can say yes and the PPA can say no.
[16:03] <cjohnston> tedg: nope.. we don't do train
[16:03] <tedg> cjohnston, Ah, okay.
[16:03] <tedg> I guess we need a train vanguard as well
[16:03] <seb128> tedg, didrocks had a manual dput vanishing earlier, I would say launchpad bug
[16:03] <ogra_> conductor is the right name i thinnk
[16:04] <seb128> tedg, restarted a build
[16:04] <tedg> seb128, Thanks
[16:04]  * tedg crosses fingers
[16:04] <seb128> yw
[16:05] <sil2100> Let me see the problem there
[16:06] <sil2100> hmm, I still don't see the url-dispatcher in the PPA though
[16:07] <tedg> sil2100, Yeah, I couldn't find it anywhere.  Trying a rebuild.
[16:07] <sil2100> Seems to be uploaded in the logs, so maybe now LP will do the right thing
[16:08] <sil2100> tedg: yep, I see it now
[16:08] <sil2100> tedg: it should be good this time
[16:11] <seb128> sil2100, bregma:
[16:11] <seb128>  unity-plugin-scopes : Depends: libunity-core-6.0-8 (>= 7.0.0) but it is not going to be installed
[16:11] <seb128> using the ppa3
[16:11] <seb128> seems like that package needs to be added to the unity7 landing
[16:11] <seb128> I've added a comment on the landing-003 tab of CI train
[16:12] <bregma> seb128, unity-plugin-scopes is not a part of Unity7, perhaps there's a serious breakage somewhere
[16:13] <seb128> bregma, it's not part of unity7 but it depends on libunity-core-6.0-8
[16:13] <sil2100> hmmm, we already released an libunity last week I think?
[16:13] <seb128> bregma, or britney enforces that all rdepends get rebuilt
[16:13] <seb128> bregma, landing that update is going to make unity-plugin-scopes not installable until it's rebuilt with the new soname
[16:13] <bregma> I suspect there are some too-strict package version dependencies somewhere
[16:14] <seb128> that's a soname change
[16:14] <seb128> not a versionning
[16:14] <plars> didrocks, ogra_: vila opened a task for me to clarify something about http://ci.ubuntu.com/smokeng/trusty/touch/maguro/177:20140212.1:20140115.1/6560/default/762914/ for you, but I'm not sure I understand the request. The test failed, but looks likely to be just a temporary issue resolving ports.ubuntu.com (yay dns)
[16:14] <seb128> bregma, it needs to be rebuild with soname=9
[16:15] <sil2100> Ah, it's -core
[16:15] <plars> didrocks, ogra_: I say that... I'm looking at 180 though and it seemed to fail the same thing
[16:15] <vila> plars: the question was about the validity of the following test results if the  image was  not installed properly
[16:16] <ogra_> right
[16:16] <ogra_> plars, it looked like the install failed and we werent sure if the device didnt just move on and tested what was on the device already (i.e. the former image)
[16:17] <bregma> seb128, OK, it looks like unity-plugin-scopes is the only rdepends I can find, so that should be the only dependent missing
[16:17] <sil2100> bregma: if you can prepare a merge for unity-plugin-scopes with the dep bump then I can quickly add it to the landing of unity7
[16:17] <sil2100> It will then build an ready
[16:18] <bregma> sil2100, it may take a while, this is the first I've ever heard of that package and all my resources are tied up, so go do what you need to do and it'll be ready by the time you get back
[16:18] <plars> ogra_: where are you seeing the image install failed?
[16:19] <sil2100> bregma: thanks :) Excellent!
[16:19] <ogra_> plars, the install-and-boot test on iirc 178 failed
[16:19] <ogra_> plars, we werent sure what to make out of that
[16:19] <plars> ogra_: it shouldn't just move on if the install fails, in fact, in 179 we did see it fail to install and it didn't move on
[16:20] <plars> ogra_: 178? on which device?
[16:20] <plars> it passed on maguro
[16:20] <plars> http://ci.ubuntu.com/smokeng/trusty/touch/maguro/178:20140213:20140115.1/6565/
[16:20] <plars> the link I got was about 177
[16:20] <plars> 179 failed to install, but I think that was seen by everyone
[16:21] <plars> I have results on both 177 and 178 on both devices though
[16:22] <ogra_> plars, oh, right, then 177
[16:22] <ogra_> sorry its a massively insane day today
[16:22] <plars> ogra_: 177 passed on the install also
[16:22] <plars> ogra_: the test that this is doing is just trying to apt-get install curl
[16:22] <plars> oh, or is that the install you mean
[16:23] <plars> this is just one of the basic/default tests
[16:23] <plars> and appears to be occasionally failing to resolve ports.ubuntu.com (failed 177, 180, passed 178)
[16:23] <plars> but the image installation did succeed
[16:24] <ogra_> plars, sorry i need tiome to look at what we had this morning again , i'm in 5 things at once atm
[16:24] <kgunn> sil2100: robru ...not sure which, but i understand mlankhorst has uploaded 2:1.15.0-1ubuntu6 which
[16:24] <kgunn> fixes the ftbfs issue on ppc64el
[16:24] <plars> ogra_: I understand - if you still have concerns ping me when you get time, otherwise we can discuss further in the standup
[16:24] <kgunn> and will require rebuild against mir....one more time :)
[16:24] <thostr_> sil2100: robru: anybody to reconfigure silo 11?
[16:26] <ogra_> plars, ++
[16:27] <cjwatson> kgunn: why will it require a rebuild against mir?
[16:28] <cjwatson> did you reupload mir?
[16:28] <kgunn> cjwatson: because mir is in a build silo which had an abi break on the client...of which xmir is a client
[16:28] <cjwatson> wasn't mir already copied into -proposed though?
[16:29] <kgunn> cjwatson: i'm unsure.... sil2100 robru didrocks ^ ?
[16:29]  * kgunn would love to find out he doesn't need a rebuild
[16:30] <cjwatson> afaics xorg-server was just waiting on the ofono-phonesim autopkgtest to complete
[16:30] <cjwatson> which should be done
[16:31] <cjwatson> I think it will migrate next run
[16:31] <didrocks> plars: on 177, does it mean we got 177 tested or 176?
[16:31] <cjwatson> and specifically I suspect that reuploading xorg-server will only slow things down at this point so please hold off on that
[16:32] <plars> didrocks: in the results for 177 that I posted above, it installed 177 and tested 177. I don't see anything there indicating otherwise, but if you do please show me
[16:32] <plars> I'll be happy to look further
[16:33] <didrocks> plars: http://ci.ubuntu.com/smokeng/trusty/touch/maguro/177:20140212.1:20140115.1/6560/default/762914/ ended up in error
[16:33] <didrocks> plars: on installing curl, so we didn't know if it fetched 177
[16:34] <plars> didrocks: sure we do: http://ci.ubuntu.com/smokeng/trusty/touch/maguro/177:20140212.1:20140115.1/6560/install-and-boot/ in the install and boot test it passed
[16:34] <plars> didrocks: the test case in default that tries to apt-get install some package is just that - try to apt-get install some small package
[16:34] <plars> didrocks: this is completely separate from the image installation
[16:35] <didrocks> plars: what the goal of this test?
[16:35] <plars> didrocks: if the image install fails to complete, the tests do not continue trying to run (see image 179 as an example)
[16:35] <plars> didrocks: it was one of the tests requested early on, to just try to make sure apt-get install works.  It's certainly less useful today than it was back then
[16:35] <didrocks> plars: ah ok, the name is confusing :)
[16:36] <didrocks> thanks for the explanation!
[16:36] <plars> sure :)
[16:44] <thostr_> cyphermox_: sil2100: robru: anybody there you can configure silo 11???
[16:47] <davmor2> jibel, asac: I've just been able to upgrade from 176 → 180
[16:53] <seb128> tedg, your slot5 worked this time
[16:54] <tedg> seb128, Yeah, but url-dispatcher failed to build :-/  The Upstart mock doesn't have enough for the new UAL.
[16:55] <jibel> davmor2, thanks for trying
[16:57] <seb128> didrocks, the CI train when status #ERROR
[16:58] <seb128> the landing slot tabs are empty as well
[16:58] <didrocks> argh
[16:58] <didrocks> I can't do everything, people ask me to reconfigure, rerun stuff, I need to write the email
[16:58] <didrocks> and seems nobody in the list is here
[16:58] <didrocks> asac: can we get some help? I have some appointement and again, won't make it…
[16:59] <seb128> can somebody retry https://launchpad.net/~ci-train-ppa-service/+archive/landing-010/+build/5585972
[16:59] <seb128> it failed because of the xorg transition in proposed
[17:00] <didrocks> sil2100 isn't again around, for the past 30 minutes, I'm really unimpressed
[17:00] <seb128> kgunn, congrats, mir 0.1.5 is finally in trusty ;-)
[17:01] <kgunn> seb128: thanks so much!
[17:01] <seb128> kgunn, I've not done a lot, just helped to nudge some of the issues with the last upload
[17:02] <kgunn> it takes a village...
[17:02] <kgunn> thanks robru!
[17:03] <kgunn> sil2100: one thing...when i hit merge it says "no because xorg-server (2:1.15.0-1ubuntu5) is not published yet"
[17:04] <cjwatson> seb128: retry> done
[17:04] <kgunn> is it because we need it to say 2:1.15.0-1ubuntu6
[17:04] <didrocks> cyphermox_: sil2100: ogra_: robru: coming?
[17:04] <seb128> cjwatson, thanks
[17:04] <seb128> kgunn, that might be a bug in didrocks' check logic, since the version copied from the ppa was superseeded by a manual upload
[17:04] <asac> didrocks: the meeting? i am still on another meeting, but tell me what i should do
[17:05] <seb128> not sure that case is handled correctly (seems not)
[17:11] <asac> cjohnston: how can i change the /topic?
[17:11] <cjohnston> asac: /topic my new topic
[17:12] <cjwatson> in decent clients you can probably do /topic <tab> or some such and have it prefilled with the current topic
[17:26] <cyphermox_> didrocks: sil2100: robru: I'd assign line 22
[17:26] <didrocks> cyphermox_: sounds risky-less to me
[17:26] <didrocks> kgunn: seb128: hum, right, I didn't handled that case
[17:26] <didrocks> kgunn: but there is a trick!
[17:26] <cyphermox_> risky-less?
[17:27] <cyphermox_> you mean we're back in damage-control mode? :)
[17:27] <didrocks> cyphermox_: without any risk, so yeah, please do assign :)
[17:27] <cyphermox_> ahaha ;)
[17:27] <didrocks> kgunn: seb128: you can run merge and clean with IGNORE_PACKAGES_NOTINDEST
[17:27] <didrocks> that should work
[17:27] <didrocks> please tell me
[17:27] <kgunn> will do
[17:27] <cyphermox_> only four landings avail though
[17:28] <didrocks> kgunn: in fact, that's on purpose, because if someone push a version to distro without using a silo (they could have used the silo to fix it), we don't know what version corresponds to what
[17:28] <didrocks> cyphermox_: yeah, most of them will be freed soon
[17:29] <ogra_> [17:29] <ogra_> (sorry that it took so long)
[17:29] <cyphermox_> alrighty
[17:29] <cyphermox_> brb
[17:29] <seb128> didrocks, thanks for the hint
[17:29] <didrocks> yw ;)
[17:29] <didrocks> ogra_: thanks!
[17:30] <robru> didrocks, sorry so with image promoted ^ does that mean it's now safe to publish mediascanner? or do I have to wait for the next image build?
[17:30] <didrocks> robru: mediascanner is fine
[17:30] <didrocks> robru: please wait for the other one :)
[17:30] <didrocks> that dogfooding and results on image 180 are good
[17:30] <didrocks> and the image for Mir kicked in
[17:30] <robru> didrocks, what other one? upstart app launch?
[17:31] <robru> didrocks, sorry i'm confused. so i can publish mediascanner now?
[17:31] <mandel> ogra_, pmcgowan, barry I have requested build in my ppa for the latests udm + some extra useful branches (will be merged to trunk later) that will logs all requests done by s-i to udm and the data they contains and will add tags to the logs per download to track in an easier manner what is going on
[17:31] <mandel> while that builds I'm going to walk the dog and will be back with you
[17:32] <mmcc`> ping fginther - I see you started a new jenkins ci job for my unity-scope-click MP here: https://jenkins.qa.ubuntu.com/job/unity-scope-click-ci/281/ -- it looks like there are unmet deps, but only on ARM. can you help me figure that out?
[17:32] <ogra_> mandel, so pmcgowan just tried to downgrade system-settings (since that shows up in the changelog and also had update related changes)
[17:32] <didrocks> robru: upstart app launch, why didn't you ask on the meeting? :/
[17:32] <ogra_> mandel, while it worked after downgrading the package, it is indeed not a proof for anything since it always has worked on and off
[17:32] <ogra_> mandel,  but i think it might give us a hint
[17:32] <robru> didrocks, i did but it wasn't clear
[17:32] <didrocks> robru: so please ask :)
[17:33] <mandel> ogra_, los mato.. I hope it is not system settings..
[17:33] <didrocks> no need to reash the discussion on IRC after that :/
[17:33] <ogra_> mandel, http://launchpadlibrarian.net/165161694/ubuntu-system-settings_0.1%2B14.04.20140203-0ubuntu1_0.1%2B14.04.20140206-0ubuntu1.diff.gz i'm just looking at the diff here, but probably you or barry can make more out of the code
[17:33] <mandel> ogra_, the new udm will give us lots of info about the dbus communication, asap I have a deb I'll ping you all
[17:33] <pmcgowan> ogra_, where are the update bits stored after download?
[17:33] <robru> didrocks, well, yes, because it's unclear to me. your messages are seemingly contradictory. "it's fine" "please wait"
[17:33] <didrocks> 18:30:14   didrocks | robru: mediascanner is fine
[17:33] <didrocks> 18:30:28   didrocks | robru: please wait for the other one :)
[17:34] <didrocks> meaning "the other one" is the other one we discussed
[17:34] <fginther> mmcc`, sure, let me take a look
[17:34] <didrocks> upstart-app-launch
[17:34] <didrocks> meaning not mediascanner
[17:34] <robru> didrocks, yes. "please wait for the other one" is incredibly ambiguous. it could mean that mediascanner needs to wait for the next image build
[17:34] <ogra_> sergiusens, where does the new flash tool store its downloads iirc it is not ~/Downloads anymore
[17:34] <didrocks> robru: ok, I was just telling back what we discussed doing the meeting
[17:34] <didrocks> mediascanner -> OK
[17:34] <robru> ok, thank you.
[17:34] <didrocks> upstart-app-launch -> wait for the Mir one
[17:35] <didrocks> (wait for the Mir image to be kicked in)
[17:35] <robru> cyphermox_, need packaging ack: http://162.213.34.102/job/landing-009-2-publish/
[17:35] <ogra_> pmcgowan, i think its some hidden dir in your home (i never used the new tool)
[17:37] <fginther> mmcc`, I forgot to specify the demo-stuff ppa on the rebuild
[17:37] <robru> pmcgowan, are you talking about the go version of ubuntu-device-flash? it stores the images under ~/.cache/ubuntuimages
[17:37] <davmor2> Mirv: hmmm no audio in calls is a little annoying :(
[17:37] <pmcgowan> robru, whatever updater does
[17:38] <pmcgowan> I dont have that dir
[17:38] <fginther> mmcc`, I've triggered a new build with the right ppa
[17:38] <robru> pmcgowan, the old flasher stores in ~/Downloads/phablet-image or something like that
[17:38] <pmcgowan> robru, not the flasher, the normal update mechanism
[17:38] <asac> renato: i think he is talking about "on device"
[17:39] <asac> not on your desktop if you use phablet-flash
[17:39] <asac> er
[17:39] <robru> in that case i dunno
[17:39] <asac> pmcgowan: https://bugs.launchpad.net/ubuntu-system-image/+bug/1277589
[17:39] <asac> pmcgowan: from that i would think /var/lib/system-image/...
[17:39] <asac> hmm
[17:39] <asac> or not :)
[17:39] <asac> sorry ignore that
[17:40] <asac> pmcgowan: look here: https://bugs.launchpad.net/ubuntu-system-image/+bug/1277589/comments/5
[17:40] <asac> so /android/...
[17:40] <ogra_> pmcgowan, ooh
[17:40] <ogra_> you didnt say on the device
[17:40] <ogra_> pmcgowan, they are gone
[17:40] <mmcc`> fginther: great, thanks
[17:40] <ogra_> it stores them in /cache/recovery
[17:40] <asac> ogra_: he is in the context of "my device upgrade failed" :)
[17:40] <ogra_> asac, i know i work with him on it since 1h
[17:40] <asac> hehe
[17:41] <asac> so how would he care about not-device :P
[17:41] <ogra_> asac, he is my guineapig
[17:41] <asac> thats awesome
[17:41] <ogra_> asac, because the plan was to flash back to a former image
[17:41] <ogra_> asac,  replacing two packages fixed the issue
[17:41] <pmcgowan> ogra_, they are there, I never applied them
[17:41] <ogra_> asac,  but we need to redo that
[17:41] <pmcgowan> so I should be able to clean them out and try again
[17:41] <kenvandine> robru, i have verified the fix in silo 004 fixed the crasher i was getting
[17:41]  * asac wonders if this will make the issue unreproducible for pmcgowan 
[17:41] <ogra_> pmcgowan, right, but you wont be back on a clean image
[17:42] <ogra_> asac, we'll see
[17:42] <robru> kenvandine, ... great? what crash?
[17:42] <pmcgowan> ogra_, I dont know how to flash an older version, let me check
[17:42] <kenvandine> the signal disconnect fix that was listed in the landing
[17:42] <kenvandine> it was causing a content-hub crash
[17:42] <kenvandine> but only in a branch of content-hub that hasn't landed yet :)
[17:42] <robru> kenvandine, ok. we have to wait on that landing until we get a new image with the new mir though
[17:42] <kenvandine> but it was a bug in ual
[17:43] <kenvandine> robru, sure, just reassuring you that it does fix it :)
[17:43] <robru> kenvandine, ok good. we'll I'll probably hit publish in 2-3 hours depending on how long the next image build takes
[17:43] <ogra_> pmcgowan, ubuntu-device-flash --channel devel-proposed --revision 169
[17:43] <robru> ogra_, in fact please ping me once the next image is built
[17:43] <ogra_> (or was it 170)
[17:43] <kenvandine> then i can start to think about landing the hub :)
[17:44] <pmcgowan> ogra_, ok, yes 169
[17:44] <ogra_> k
[17:44] <ogra_> robru, did anyone fire off a build ?
[17:44] <robru> kenvandine, if you have a sec waiting for ual, can you review these two smallish package diffs? http://162.213.34.102/job/landing-009-2-publish/
[17:44] <dobey> doanac: can you re-trigger the job on https://code.launchpad.net/~dobey/unity-scope-click/rnrclient/+merge/206223 ? jenkins pbuilder seems to be breaking a lot lately for package deps for some reason :(
[17:45] <doanac> dobey: looking now.
[17:45] <kenvandine> robru, both look fine, assuming  libunity-scopes-dev >= 0.3.1 has landed
[17:45] <kenvandine> which i assume so
[17:46] <robru> kenvandine, yep, thanks
[17:46] <kenvandine> np
[17:47] <doanac> doanac: queued up now: http://s-jenkins.ubuntu-ci:8080/job/unity-scope-click-ci/285/
[17:49] <ogra_> robru, there is no image build running anywhere, do you plan to kick one ?
[17:49] <ogra_> (or does didrocks do ?=
[17:49] <didrocks> ogra_: see my email
[17:49] <ogra_> ahm sorry, was waiting for the G*
[17:50] <ogra_> who needs email nowadays :)
[17:50] <ogra_> didrocks, thanks ... will you fire that off ?
[17:51] <didrocks> ogra_: I don't think, we want to wait on plars giving green light on 180 before
[17:52] <didrocks> that he finished restarting/rekicking tests
[17:52] <ogra_> didrocks, ok,. because robru asked me to watch for it
[17:52] <robru> ogra_, sorry I just assumed you would be the one kicking it
[17:52] <plars> didrocks: I might still have time to rekick at least that camera test - but it was clearly a case where the screen just didn't unlock
[17:52] <ogra_> so it will just be the 3am cron build then
[17:52] <plars> assuming there's time before 181 hits of course
[17:55] <dobey> doanac: thanks
[17:55] <robru> ogra_, is it 3AM utc? that's a long time to wait before landing anything. in fact that means i can't land anything for my whole shift
[17:56] <robru> or i guess just ual
[17:56] <ogra_> robru, then have cyphermox_ click the button on the isotracker to get a build going
[17:56] <robru> ok
[17:59] <plars> Ubuntu CI Engineering Team | Vanguard: plars | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but chooose right timezone | Landing instructions: http://goo.gl/8H1Du3 | Known Issues: -
[18:04] <plars> robru, cyphermox_, ogra_: if/when you do kick off the build, can you still announce it here? That's really helpful :)
[18:05]  * ogra_ always does so :) 
[18:05] <rsalveti> can't we have a bot for that? :-)
[18:05] <ogra_> and if i'm around once you need a build i'm happy to start one
[18:05] <rsalveti> that would be awesome
[18:05] <ogra_> rsalveti, ++
[18:06] <ogra_> ... if i find a spare minute ...
[18:06] <plars> ogra_: and I really like that you do that
[18:10] <didrocks> kgunn: seems it worked, right?
[18:11] <asac> fginther: https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1279875
[18:11] <didrocks> kgunn: just a note for the future, do you mind giving more infos (the mir one was perfect, the Unity8 one just mentionned "Unity8" though)
[18:11] <asac> fginther: can we comment on that?
[18:11] <asac> doanac: ^^ :)
[18:11] <asac> actually you are the vandguard
[18:11] <asac> sorry fginther
[18:12] <doanac> asac: i'll coordinate.
[18:13] <asac> doanac: yeah. plz update bug etc.
[18:13] <asac> thx
[18:13] <plars> actually I'm guarding the van as of about 13 min. ago doanac if you want me to take it
[18:14] <doanac> plars: sure. i won't stop you :)
[18:15] <cjohnston> asac: doanac for all of the history we have the jobs have taken >50 minutes on average.. just saying it's longer than it used to isn't very helpful
[18:17] <plars> cjohnston: yeah, we only seem to have back to Jan 31 though
[18:17] <cjohnston> correct
[18:18] <cjohnston> but used to could be 6 months ago
[18:18] <asac> cjohnston: not sure what the problem is
[18:18] <asac> if you need more info from the bug reporter, ask him :)
[18:18] <asac> i think they are just desparate that it was much faster
[18:18] <asac> and now its slower
[18:18] <asac> so... :)
[18:19] <sergiusens> ogra_, .cache/ubuntuimages
[18:19] <ogra_> sergiusens, yeah
[18:19] <ogra_> sergiusens, i answered the wrong question anyway :)
[18:19] <ogra_> so it wasnt relevant anymore :)
[18:24] <kgunn> didrocks: ack
[18:28] <mmcc> ping fginther -- looks like this job: https://jenkins.qa.ubuntu.com/job/unity-scope-click-ci/283/ fails on unmet deps on both architectures now.
[18:38] <bfiller> fginther: can you kick CI to build this? https://code.launchpad.net/~bfiller/camera-app/desktop-mode-support/+merge/203226
[18:38] <bfiller> fginther: and this: https://code.launchpad.net/~bfiller/mediaplayer-app/icons-and-sharing/+merge/206255
[18:41] <cjohnston> bfiller: please use the vanguard
[18:42] <bfiller> doanac: can you kick CI to build this? https://code.launchpad.net/~bfiller/camera-app/desktop-mode-support/+merge/203226
[18:42] <bfiller> doanac: and this: https://code.launchpad.net/~bfiller/mediaplayer-app/icons-and-sharing/+merge/206255
[18:43] <cjohnston> bfiller: there is already one running for the first
[18:43] <plars> bah
[18:43] <plars> I just realized I missed the /topic :)
[18:43] <ogra_> :)
[18:44] <plars> bfiller: looking at https://code.launchpad.net/~bfiller/mediaplayer-app/icons-and-sharing/+merge/206255 it looks like it's pending to run still
[18:44] <plars> for the first time
[18:44] <bfiller> cjohnston: is there a way to tell from the MR that a build is in progress?
[18:44] <cjohnston> nope
[18:44] <bfiller> thought not
[18:45] <cjohnston> it runs automatically when there is a new revno
[18:45] <cjohnston> its only if there isn't a new revno that one would manually need to be run
[18:45] <plars> as for https://code.launchpad.net/~bfiller/camera-app/desktop-mode-support/+merge/203226 the link there doesn't seem to work
[18:45] <plars> cjohnston: is that something you've seen before?
[18:45] <cjohnston> plars: desktop-mode-support is already rerunning
[18:46] <cjohnston> http://s-jenkins.ubuntu-ci:8080/job/camera-app-ci/162/console
[18:46] <plars> cjohnston: ok, so that's why I get the 404 maybe?
[18:47] <cjohnston> plars: http://s-jenkins.ubuntu-ci:8080/job/camera-app-ci/ it looks to only keep 5 jobs
[18:47] <fginther> plars, cjohnston, the last build on https://code.launchpad.net/~bfiller/camera-app/desktop-mode-support/+merge/203226 was over 14 days old and the original job was purged
[18:47] <cjohnston> ahh... the 14 day rule
[18:47] <cjohnston> but yes, there is one currently runnin
[18:47] <cjohnston> g
[18:48] <cjohnston> fginther: the current build running is doing revno 243, but there is now a 244.. after it finsihes with 243 I assume it would pick up 244 and run?
[18:48] <fginther> cjohnston, correct
[18:49] <cjohnston> fginther: if I were to kill the build for 243 what would that do, as I assume bfiller would rather have the results for 244
[18:50] <fginther> cjohnston, that's supposed to work, it should start testing 244 at the top of the hour
[18:50] <fginther> mmcc, ack, I'll unwind the deps and get back to you
[18:50] <cjohnston> fginther: should we offer then to kill the one for 243 or just let it be?
[18:52] <plars> cjohnston: I would think it's still useful to have both in case 244 fails, you'd want to know if it was 243 or 244 that caused it right?
[18:53] <fginther> cjohnston, killing it gets to 244 faster, if it's urgent that will help
[18:53] <cjohnston> then I guess it's up to bfiller
[18:53] <bfiller_afk> cjohnston: yes please, kill 243
[18:53] <bfiller_afk> ty
[18:53] <dobey> gah, why is this happening? https://jenkins.qa.ubuntu.com/job/unity-scope-click-trusty-amd64-ci/183/console
[18:53] <mmcc> dobey: I've already pinged fginther, see just above
[18:54] <dobey> seems to be failing to install some deps, but everything should be available
[18:54] <dobey> mmcc: oh, ok
[18:54] <cjohnston> plars: do you want to kill or want me to
[18:55] <plars> cjohnston: I can do it, one sec
[18:56] <plars> cjohnston: actually, I think 243 finished already
[18:57] <cjohnston> ack
[18:58] <robru> bfiller_afk, silo 9 ready for building qtorganizer5-eds
[18:59] <plars> I think 244 tests are just waiting on calxeda-pbuilder at the moment if I'm reading it right
[19:10] <mlankhorst> if you keep building xorg-server against universe I'm going to derail your ci train! >:o
[19:13] <mlankhorst> no seriously please fix that :-)
[19:14] <asac> mlankhorst: what are we doing exactly?
[19:14] <asac> mlankhorst: building against mir?
[19:14] <asac> mlankhorst: which part is in universe?
[19:17] <rsalveti> asac: when we build stuff in a ppa we always have universe enabled by default, right?
[19:17] <rsalveti> Ubuntu components:
[19:17] <rsalveti>  Use all Ubuntu components available.
[19:17] <rsalveti>  Use the same components used for each source in the Ubuntu primary archive.
[19:17] <rsalveti> there's an option in there
[19:17] <asac> rsalveti: sre, but thats not the problem i think
[19:17] <asac> sure
[19:17] <rsalveti> currently they are all using the first one
[19:17] <rsalveti> asac: it is
[19:18] <rsalveti> asac: because then we just copy the package over when publishing it
[19:18] <asac> so with universe enabled, installing build-deps xorg-server installs different -devs?
[19:18] <asac> rsalveti: sure, we lack a safety net
[19:18] <asac> for these cases
[19:18] <asac> but it shouldnt matter if we dont build against universe packages
[19:18] <rsalveti> not sure, but I believe that would be the case
[19:18] <asac> in the first place... unlesee build-deps resolves differently with universe enabled
[19:18] <rsalveti> let's wait for mlankhorst
[19:18] <rsalveti> yeah
[19:18] <asac> i want to know what we build agianst for xorg in particular
[19:18] <asac> because we cant disable universe
[19:19] <asac> so i rather want to understand if we can MIR a subset of things
[19:21] <bfiller> robru: thanks
[19:33] <plars> ogra_, cyphermox_, robru: tests finished on 180. camera_app reran and passed already on mako. I'm rerunning a few things on maguro but I don't expect any big surprises if you want to kick something off. I'm also rerunning unity8 on mako due to a crash file showing up, but iirc that still happens from time to time
[19:34] <ogra_> i'll kick one then
[19:34] <ogra_> robru, is everything you want in that image in the archive proper ?
[19:34] <robru> ogra_, yes
[19:34] <ogra_> great
[19:34] <robru> ogra_, just the mir 0.1.5 landing i was concerned about getting in an image
[19:35] <ogra_> [19:36] <robru> alright, i'm off for lunch. back in an hour.
[19:37] <popey> haha, lunch!
[19:37]  * popey forgot about that today
[19:38] <cyphermox_> ah, thanks ogra
[19:38] <cyphermox_> I was waiting to see the results on maguro before kicking the image
[19:38] <ogra_> cyphermox_, ah, sorry for stealing your work :)
[19:40] <cyphermox_> np ;)
[20:17] <cjwatson> mlankhorst: why don't you just fix the build-dep to prefer main?  that's best practice *anyway*
[20:18] <cjwatson> mlankhorst: ambiguous build-deps are bad, sooner or later it could easily have confused germinate in any case
[20:18] <cjwatson> mlankhorst: and your approach is one of the things standing in the way of archive reorg
[20:20] <kgunn> robru: sorry to be a pest...got a hot one i'd like to land, for mwc line 31 if i could get a silo
[20:34] <sil2100> ;)
[20:35] <sil2100> robru: I guess it's good to assign a silo I think ^
[20:38] <ogra_> whoops
[20:38] <ogra_> [20:38] <ogra_> (sorry, was distracted in other channels)
[20:38] <ogra_> robru, go wild ! :)
[20:39] <sil2100> Yeeehaw, publishing publishing!
[21:03] <sil2100> jdstrand: hi! Are you around?
[21:06] <jdstrand> sil2100: yes
[21:10] <tedg> kenvandine, So I have the patch you want in silo 4… just needs a core-dev to press publish… do you know how I could find a core-dev for that?  :-)
[21:11]  * kenvandine :)
[21:11] <kenvandine> robru, do we have the green light to publish that?
[21:11] <tedg> kenvandine, It's going to put a package in the new queue, do I actually need an archive admin as well?
[21:12] <kenvandine> yes
[21:12] <tedg> K
[21:12] <kenvandine> i need to step out for a little bit... i'll ping when i'm back to see if i can assist
[21:12] <kenvandine> bbiab
[21:12] <tedg> Cool
[21:13] <sil2100> jdstrand: so, we had these 2 singular failures in our morning-UTC image in the security testcase
[21:13] <sil2100> jdstrand: those did not happen in the next images, but we just wanted you to take a look if maybe it looks suspicious to you or not
[21:13] <sil2100> jdstrand: http://ci.ubuntu.com/smokeng/trusty/touch/mako/177:20140212.1:20140115.1/6557/security/
[21:14] <jdstrand> sil2100: hold on, meeting
[21:15] <sil2100> jdstrand: thanks ;) It's nothing urgent anyway
[21:15] <jdstrand> this failure is surprising:
[21:15] <jdstrand> Checking '-w /run/user/32011/orcexec.test'... !FAIL! (unexpected rc=0)
[21:39] <sil2100> robru: do you know if bregma said +1 to the unity7 landing?
[21:43] <bregma> sil2100, I'm having a few issues running tests locally, I want to clear them up first... and seb128 says he found some regressions
[21:44] <sil2100> bregma: ah, ok - if anything the silo has the rebuilt unity-scopes-shell package that was required
[21:44] <sil2100> bregma: just give us a sign by e-mail or tomorrow on IRC when it's ok and we'll press the buttons
[21:44] <sil2100> bregma: thanks!
[21:45] <bregma> sil2100, what happens if I need new packages built to pick up fixes?
[21:46] <sil2100> bregma: if you have a merge with a fix ready, then just ping robru or cyphermox_ (for US timezone) or me or didrocks (for EU timezone) with the merge request, we'll add it to the list and press 'rebuild'
[21:46] <bregma> super, thanks very much
[21:46] <sil2100> bregma: so that the fix gets built along with all the other changes in the PPA for testing
[21:46]  * sil2100 goes now
[21:46] <sil2100> o/
[22:01] <robru> kgunn, ok, on it
[22:01] <cyphermox_> robru: poke
[22:02] <cyphermox_> I'll take 29, 30 if you're not already preparing them
[22:02] <robru> kgunn, silo 6 is ready to build
[22:02] <robru> kenvandine, yep, with image 181 out i think we can publish pretty much anything
[22:03] <cyphermox_> how did image 181 look wrt tests?
[22:03] <kenvandine> robru, cool
[22:03] <kenvandine> robru, do you need me to do anything?
[22:04] <robru> kenvandine, if you could ack the packaging: http://162.213.34.102/job/landing-004-2-publish/lastSuccessfulBuild/artifact/packaging_changes_upstart-app-launch_0.3+14.04.20140213-0ubuntu1.diff that'd be great
[22:04] <robru> cyphermox_, ;-)
[22:04] <robru> cyphermox_, 0 failures!!! yay!!! ;-)
[22:05] <cyphermox_> robru: running...
[22:06] <kenvandine> robru, only thing i don't like is the diff adds a changelog entry for the previously released version
[22:06] <kenvandine> +  * debian/*symbols: auto-update new symbols to released version
[22:13] <robru> kenvandine, that does look a little bit goofy, but if you look closely, the original changelog just had an empty bullet point, which is definitely a bug in the system, so this is an improvement
[22:13] <fginther> mmcc, this build successfully now \o/ https://code.launchpad.net/~mikemc/unity-scope-click/dlmgr-add-udm/+merge/205733
[22:13] <kenvandine> robru, yeah, i think it's harmless
[22:13] <mmcc> fginther: yep, thanks for fighting that for us!
[22:14] <kenvandine> but an archive admin will need to look too, since this will end up in NEW
[22:14] <kenvandine> ok, i'll ack it
[22:14] <robru> kenvandine, thank
[22:14] <robru> s
[22:18] <robru> cyphermox_, oops, missed your message. yeah you can assign 29 and 30 if you want
[22:19] <cyphermox_> alright
[22:23] <cyphermox_> bfiller: mediaplayer-app and camera-app desktop-mode fixes mp's have silos nao
[22:23] <cyphermox_> robru: do you know if didrocks mentioned someplace whether the upper limit of silos was defined?
[22:24] <robru> cyphermox_, I was never told of an upper limit. Just that there are 20 now but more can be defined as necessary.
[22:25] <robru> cyphermox_, unless launchpad has some limitations on the number of PPAs a team can have, or google has a limit on the number of spreadsheet pages, I don't think citrain itself has any built in limits.
[22:25] <cyphermox_> right
[22:25] <cyphermox_> I was just wondering if it was carved in stone somewhere
[22:25] <robru> cyphermox_, well you can dig into the code if you want ;-)
[22:26] <cyphermox_> I can just ask LP how many ppas are defined for citrain
[22:26] <cyphermox_> I'll quickly set up a script to graph slot use
[22:26] <cyphermox_> *silo
[22:26] <robru> cyphermox_, yeah, i'd like some better visualization of how many silos are free. the current autofill dropdown list doesn't give a good idea
[22:26] <cyphermox_> exactly
[22:27] <tedg> robru, Thanks for publishing the UAL silo
[22:27] <robru> tedg, no worries
[22:29] <thomi> tedg: how many more libUAL MPs are there before all the bits I care about are landed?
[22:29] <tedg> thomi, Heh, those are the ones robru just published
[22:30] <thomi> all of them? sweet
[22:30] <tedg> thomi, Not sure how long it takes to get through proposed.
[22:30] <tedg> Guessing an hour or two
[22:30] <robru> tedg, I would assume within the hour unless they fail one of the -proposed tests.
[22:31]  * tedg has been studying for these tests
[23:31] <robru> cyphermox_, got time for a packaging review? https://code.launchpad.net/~robru/cordova-ubuntu/3.4-packaging/+merge/206304
[23:32] <robru> cyphermox_, this one is NEW so it needs a pretty rigorous thrashing
[23:46] <bfiller> cyphermox_: awesome, will test all my landings tonight