[02:05] <imgbot> [03:26] <Mirv> morning
[03:28] <Mirv> popey: music-app 409 uploaded https://myapps.developer.ubuntu.com/dev/click-apps/143/
[03:35] <imgbot> [03:35] <imgbot> [03:36] <ToyKeeper> ... and flashing.
[06:02] <didrocks> Mirv: hey, can you do me a favor?
[06:05] <Mirv> didrocks: what kind of?
[06:06] <Mirv> (but sure)
[06:07] <Mirv> veebers: hi. you've marked autopilot as being tested. so zero failures on the image testing suite of APs with the new autopilot now?
[06:08] <didrocks> Mirv: it seems that the AP tests on the image is stuck in the reboot
[06:09] <didrocks> Mirv: can you start from that?
[06:09] <didrocks> don't rerun the ones that already rerun
[06:09] <didrocks> (maybe just rerunning the unity8 to be sure)
[06:09] <didrocks> Mirv: you can maybe double check the new AP that way :)
[06:12] <Mirv> didrocks: right, we've partial results. and that's what I was thinking, adding the new autopilot into the mix...
[06:12] <Mirv> yep, makes sense, initiaintg
[06:12] <didrocks> Mirv: thanks a lot dude :)
[06:12] <didrocks> Mirv: that way, we'll get results from latest image + AP
[06:17] <jdstrand> hi!
[06:17] <jdstrand> may I have a silo for apparmor? (line 54 in pending)
[06:18] <Mirv> jdstrand: sure
[06:19] <jdstrand> fyi, the landing will happen pretty quickly cause we've built everything in the security-proposed ppa and it is already tested
[06:19] <Mirv> jdstrand: you got the best one, landing-001
[06:20] <jdstrand> \o/
[06:20] <jdstrand> thanks :)
[06:20] <Mirv> np
[06:23] <jdstrand> (and in case I wasn't clear, I'm pocket copying those without rebuilding)
[06:23] <jdstrand> (like I normally do)
[06:28] <didrocks> jdstrand: once you copy pocket, just a reminder to run "build" with "watch only" (and look at the job that it picks your packages)
[06:29] <didrocks> Mirv: maybe ensure your /var/crash is empty btw when running the unity8 tests
[06:31] <Mirv> good idea
[06:34] <jdstrand> didrocks: ack
[06:53] <didrocks> ogra_: not sure where you were with the bisecting (didn't see the script on the ML nor progress, I could have restarted this morning from where you left of…)
[07:12] <didrocks> jdstrand: you can self-publish I guess :)
[07:12] <jdstrand> didrocks: yes, I just tried, but I never seem to do this right
[07:12] <jdstrand> eg
[07:12] <jdstrand> https://ci-train.ubuntu.com/job/landing-001-2-publish/3/console
[07:13] <didrocks> jdstrand: let me look :)
[07:13] <jdstrand> I ACK_PACKAGING, then Build
[07:13] <jdstrand> s/I/I did/
[07:13] <didrocks> jdstrand: yeah, all sounds good, I think you triggered a bug… (never saw that one)
[07:13] <didrocks> jdstrand: let me one minute so that I can fetch the status
[07:14] <didrocks> jdstrand: "sources": ["apparmor", "", "lxc", "", "libvirt", "", "lightdm", "", "apparmor-easyprof-ubuntu"]
[07:14] <didrocks> (this is fetched from the spreadsheet
[07:15] <didrocks> I think there is a safeguard missing when iterating over your cell
[07:15] <jdstrand> oh, did I not format it right?
[07:15] <jdstrand> I guess if I removed the spaces, it would work?
[07:15] <didrocks> jdstrand: the main format is space separated, but I tried to support this one as well
[07:15] <didrocks> jdstrand: you have an override even to avoid a reconfigure
[07:16] <didrocks> not sure how it will handle those weird entries, but worth a try :)
[07:16] <didrocks> jdstrand: try IGNORE_MISSINGPROJECTS
[07:16] <didrocks> (that should say "yeah, I know, some projects are missing in the publication, go ahead")
[07:17] <didrocks> jdstrand: I'll look exactly what this bug is so that it doesn't occur anymore
[07:17] <jdstrand> ok. I'll add a note about space-delimited for next time
[07:17] <jdstrand> https://ci-train.ubuntu.com/job/landing-001-2-publish/4/console
[07:17] <jdstrand> success :)
[07:17] <didrocks> jdstrand: no, I should really support that ;)
[07:17] <didrocks> great
[07:17] <jdstrand> didrocks: thanks :)
[07:17] <didrocks> jdstrand: and I think I did (even \n, /…)
[07:17] <didrocks> jdstrand: sorry for this bug, will get to it :)
[07:17] <jdstrand> np
[07:18] <didrocks> jdstrand: you will then just need to m&c once it's in the released pocket (which, in your case, will just free up the silo)
[07:18] <didrocks> if we are low in silo, we'll probably do it for you
[07:19] <jdstrand> that's cool
[07:20] <didrocks> jdstrand: do you spot anything in http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/view/head:/citrain/prepare-silo-using-spreadsheet-info#L33 (only if you have a minute)?
[07:20] <didrocks> seems to me it should have supported your case
[07:21] <didrocks> probably US spaces (kidding)
[07:21] <sil2100> didrocks: hi! It seems to be a bit problematic on first look ;)
[07:22] <didrocks> hey sil2100!
[07:22] <didrocks> sil2100: oh, why?
[07:22]  * jdstrand looks
[07:22] <sil2100> didrocks: since you first split on whitespaces, if you have something like: "a, b, c" you get 'a,', 'b,' etc. and then split each of those by ',', so you will get 'a', '', 'b', ''
[07:22] <didrocks> ahah
[07:23] <didrocks> you're right
[07:23] <sil2100> And this might smell trouble ;p !
[07:23] <didrocks> indeed
[07:23] <jdstrand> there you go
[07:23] <didrocks> :)
[07:23] <didrocks> ok, let me do some changes + add new tests
[07:24] <didrocks> thanks sil2100, jdstrand
[07:26] <sil2100> yw o/
[07:27] <sil2100> didrocks: btw. autopilot it FINALLY set to tested \o/
[07:27] <sil2100> didrocks: should I publish, 'just like that'?
[07:27] <sil2100> Or should we wait for having smoketesting up?
[07:27] <didrocks> sil2100: yeah \o/ (and NO!) Mirv is running the whole image test and is using that opportunity to try with new AP
[07:28] <Mirv> sil2100: yep, I'm running tests with that, since we need some #276 AP info anyway it doesn't hurt to test the new AP at the same time
[07:31] <sil2100> \o/
[07:32]  * didrocks wrote the 6 new tests and have 4 failures
[07:32] <didrocks> time to fix the function!
[07:36] <didrocks> and fixed + deploying: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/579
[07:40] <didrocks> added as well http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/580 as another test
[07:40] <didrocks> (if we regress on that, all MPs uris would be broken)
[07:43] <sil2100> didrocks: indeed ;)
[07:43] <didrocks> sil2100: the unity8 crash during the tests, can you find the bug report related to that one?
[08:01] <sil2100> didrocks: yes, one moment ;)
[08:01] <sil2100> didrocks: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1256360 <- no movement though
[08:02] <sil2100> didrocks: from what Saviq mentioned, it's only happening on unity8 stop
[08:02] <didrocks> sil2100: ok, wanted to confirm it was that one
[08:02] <didrocks> yeah
[08:03] <didrocks> sil2100: maybe you can try to report one from the previous run or Mirv can?
[08:03] <didrocks> to ensure we have an up to date stacktrace
[08:03] <didrocks> Mirv should have the crash
[08:03] <didrocks> when running the AP tests
[08:03] <didrocks> so will be good to use apport-bug
[08:03] <didrocks> and ensure it's duplicating to that one (now that we have the timeout 60, we should be up to date)
[08:04] <sil2100> Mirv: did you get a unity8 crash during last testing? Could you maybe push it to LP?
[08:04] <didrocks> sil2100: do you know what happened on the bisect yesterday? I didn't see any news
[08:04] <Mirv> I have that, I'll try filing it at some point but not during running tests
[08:04] <didrocks> Mirv: yeah, after tests of course :)
[08:04] <didrocks> thanks Mirv!
[08:05] <Mirv> although I've unity8 testing failing anyway for some reason. I didn't debug it in addition to rebooting once, and I'm now running what is remaining of the other tests.
[08:05] <sil2100> didrocks: my mailbox is empty, I didn't see any messages on the channel related to that ;/
[08:05] <didrocks> sil2100: I probably misunderstood, but you were not going to bisect one image as well yesterday?
[08:05] <Mirv> sil2100: if you have spare device time you could run #276 unity8 AP tests just for fun, first as is and then with the autopilot PPA added
[08:05] <Mirv> but I'll get to that eventually
[08:05] <didrocks> Mirv: ok
[08:06] <didrocks> yeah, what Mirv tells make sense
[08:07] <sil2100> didrocks: no, no one told me to do any bisecting - Robert and Oliver were said on the meeting to do that
[08:07] <didrocks> ok, my memory is bad :)
[08:07] <sil2100> Mirv: let me reflash ;)
[08:07] <sil2100> I mean, flash latest and greatest, since I have a b0rken OSK now
[08:13] <ogra_> didrocks, bug 1302174 ... popey and robru were testing a fix over night, while i was running a test with all debugging enabled ... i had hoped rob would add his findings to the bug
[08:14] <didrocks> ogra_: so you are going to test that yourself I guess?
[08:14] <didrocks> ogra_: want more testing, do you have your reboot script?
[08:14] <ogra_> didrocks, still the same script
[08:15] <ogra_> i havent been near my test phone yet, i'll capture the logs soon (if it actually finally stopped, when i went to bed it was at 380 loops)
[08:15] <didrocks> ogra_: with sleep 10 then?
[08:15] <ogra_> sleep 30
[08:15] <didrocks> the script on the ML is sleep 10, so not the same :)
[08:15] <ogra_> well, we discussed it in the meeting yesterday
[08:16] <didrocks> ogra_: yeah, but that's why putting those infos on the ML would have enable people to help and try
[08:16] <didrocks> not having those only in a hangout meetings
[08:16] <didrocks> and then no result on the following day if robru doesn't publish results…
[08:17] <didrocks> also, if I had the bug on it, I would have tried this morning as well
[08:17] <didrocks> and I would have tricked seb128 or other to help confirming :p
[08:18]  * seb128 sees his name here and is getting nervous
[08:21] <ogra_> didrocks, well, it doesnt matter how long the sleep is as long as you can reproduce the hang ...
[08:21] <didrocks> ogra_: yeah, but now that you have a lead for a fix, that's fine :)
[08:22]  * didrocks turns rw mode on latest and start
[08:23] <seb128> bah
[08:24] <ogra_> bah, so my phone died right after i went to bed ...
[08:24] <seb128> one downside of the infra changes is that the auth is asking me for the freaking 2fa now
[08:24] <ogra_> and the log is totally mangled
[08:24] <didrocks> ogra_: with your patch suggestion?
[08:24] <ogra_> didrocks, no, i just had the idea after i had started the run with extra logging
[08:24] <ogra_> didrocks, thats why i was asking popey and robru to test the fix
[08:24] <didrocks> ogra_: ah ok, so there is hope :)
[08:25] <ogra_> up to now my "fix" is just a guess
[08:25] <ogra_> i was hoping to get detailed logs
[08:25] <didrocks> ogra_: yeah… well, let's try your fix anyway
[08:29] <didrocks> (running)
[08:32] <Mirv> are people running to the meeting?
[08:33] <didrocks> :p
[08:33] <didrocks> ogra_: sil2100? ^
[08:34] <sil2100> !
[08:49] <sil2100> Mirv: hmmm, I seem to be having problems with the unity8 suite, as my unity8 hangs up from time to time becoming unresponsive ;/
[08:51] <Mirv> sil2100: it happens that unity8 AP did run on the test infra. keep on poking, I seem to get 37 failures every time (basically it aborts or something), but I'm running with the new AP
[08:52] <Mirv> then there's the crash also that happens possibly the first time one stops unity8 ie just after starting phablet-test-run -n
[09:04] <Mirv> sil2100: I've some additional tests for you to run with pure #276: dialer-app messaging-app webbrowser_app
[09:05] <Mirv> so far I seem to have _same_ failures with both old and new AP
[09:05] <didrocks> ev: FYI, just got https://job/landing-001-3-merge-clean/build?delay=0sec
[09:06] <ev> didrocks: oooh
[09:06] <ev> it returns
[09:06] <ev> didrocks: if you leave that tab up and open ci-train.u.c in another tab, are you logged in?
[09:08] <sil2100> Mirv: will try those once unity8 finally finishes, since it seems b0rkish now
[09:12] <sil2100> Mirv: ok, unity8 finished: Ran 37 tests in 1216.179s
[09:13] <sil2100> Mirv: with the old AP - but some tests were 'hanging' unity8 up, but as we guessed, it might have been the crash on stop
[09:13] <sil2100> Mirv: let me run the other tests on the old AP
[09:17] <Mirv> sil2100: well I guess if I had success with _new_ AP, it wouldn't need repeating with old AP, or what do you think?
[09:17] <sil2100> I guess so!
[09:21] <Mirv> yeah ran out :)
[09:22] <Mirv> switching places
[09:23] <sil2100> dbarth: is line 26 ready for assigning a silo?
[09:26] <didrocks> ogra_: tell me if you I can do anything to help you
[09:27] <ogra_> will do
[09:39] <dbarth> sil2100: not yet, i'm still tsting / gathering branches
[09:39] <dbarth> sil2100: however you could rmove one line
[09:39] <dbarth> sil2100: line 6; we won't land that request as-is
[09:39] <dbarth> sil2100: the branches will be taken by bfiller for a silo which requires a part of them
[09:40] <dbarth> so feel free to remove the line
[09:45] <didrocks> dbarth: you can remove it yourself :)
[09:46] <didrocks> dbarth: just don't remove lines on assigned silos without doing m&c "only free silo" first
[09:46] <mandel> vila, ping
[09:47] <vila> mandel: pong
[09:47] <bzoltan> didrocks: I have a problem that the exports are not set from the .bashrc when I run the app test on my mako.
[09:47] <didrocks> bzoltan: sorry, I'm totally out of context it seems?
[09:47] <mandel> vila, hello! so I have been looking at other projects that might have similar issues on arm but I'm trying to drill down the real issue
[09:48] <mandel> vila, for what I can read in the comments f unity-scope-click the connections on arm are flacky (the qt connections)
[09:48] <mandel> vila, I would be very very very surprise that there is an issue in a combination of cmake + qt + arm but I'm trying to add some code to rule that out
[09:49] <bzoltan> didrocks: flashed the device with devel-proposed, turned to writable and executed ` phablet-test-run -p address-book-app-autopilot address_book_app` ... the app looks scaled down, like if the GRID_UNIT_PX were not set
[09:49] <mandel> vila, if that is the case I'll let you know all the info since we might have other projects with the same problem
[09:49] <vila> mandel: thanks !
[09:50] <didrocks> Mirv: sil2100: is that what you see as well? ^
[10:06] <dbarth> didrocks: ok, i thought you may have some formulas affected; i'll do the removal
[10:07] <didrocks> dbarth: not if it's not assigned
[10:07] <didrocks> dbarth: the system adapts to lines addition/removal
[10:07] <mandel> vila,  the arm nodes used by the js bot, are they virtualized?? The tests do pass on non virtualize envs, they seem to fail with qemu
[10:07] <sil2100> didrocks: didn't look at the screen while it was running...
[10:07] <sil2100> didrocks: let me try that
[10:08] <sil2100> Ah, address-book
[10:08] <sil2100> Didn't try that one yet
[10:08] <sil2100> Mirv: my device ended up in 9 failures while running tests for those 3 apps
[10:08] <sil2100> (on old AP)
[10:10] <vila> mandel: hmm, not virtualised AFAIK, fginther can confirm
[10:10] <vila> mandel: fail with qemu emulating arm ? Known to be slow...
[10:10] <mandel> vila, yes, and I get a segfault in an arm chroot in my machine :-/
[10:11] <mandel> vila, yes, on a nexus 4 and a nexus 7 everything works well
[10:12] <sil2100> bzoltan: the application looks fine here - why you use devel-proposed instead of trusty-proposed?
[10:13] <didrocks> sil2100: devel-proposed is pointed at trusty-propsoed and that's what should be used
[10:13] <vila> mandel: so the cyclops are calxeda afaik, not emulated
[10:13] <sil2100> ah, k
[10:13] <Mirv> bzoltan: didrocks  I see at least dialer app being very small, probably a regression somewhere.. and maybe related to the dialer/messaging AP failures too?
[10:13] <sil2100> Mirv: it might be, but the address-book-app here look ok right now
[10:13] <vila> mandel: would be nice to know if you run into an emulator bug or trigger a genuine one in the image/stack under test
[10:14] <bzoltan> Mirv: didrocks: the .bashrc exports are clearly not set
[10:14] <mandel> vila, I'm looking into it, is very strange...
[10:14] <didrocks> bzoltan: I'm unsure why sil2100/Mirv doesn't reproduce the same issue. Maybe something to discuss with sergio? he's the most up to date on those changes if possible
[10:14] <didrocks> ah, Mirv reproduces
[10:14] <didrocks> now
[10:15] <bzoltan>  Mirv: bzoltan: didrocks  I see at least dialer app being very small,
[10:15] <bzoltan> didrocks: yeps
[10:15] <mandel> vila, doint a builddeb from source in qemu segfaults, I'm compiling and going to do a make check in qemu and check the results, if they  failt and not segfautl I'm going to write an example test
[10:15] <mandel> vila, where it just emits the signal and waits for it, then I'll test that
[10:15] <vila> way to go !
[10:15]  * sil2100 waits for address-book tests to finish
[10:16] <sil2100> Then I'll re-run dialer-app tests to see if it's smaller than usual
[10:16] <Mirv> sil2100: the problems for me were dialer/messaging, not address book
[10:16] <Mirv> bzoltan: confirming
[10:17] <sil2100> Mirv: 11:49 < bzoltan> didrocks: flashed the device with devel-proposed, turned to writable and
[10:17] <sil2100> executed ` phablet-test-run -p address-book-app-autopilot address_book_app` ... the app looks scaled down, like if the GRID_UNIT_PX were not set
[10:17] <sil2100> Mirv: so, bzoltan mentioned address-book having the problem as well, but it doesn't seem to be the case on my device
[10:17] <sil2100> Which is strange, hmmm
[10:18] <sil2100> Mirv: was dialer-app smaller for you on all the tests?
[10:20] <Mirv> sil2100: dialer app was, yes. weird that there are differing experiences
[10:21] <Mirv> although well I didn't look the first time, but now. and I thought the AP fails would be related
[10:24] <sil2100> Mirv: here dialer-app was fine for all the tests, I had 1 failure out of 9 tests
[10:25] <bzoltan> Mirv:  for me _all_ apps are scaled down when run by the autopilot
[10:26] <t1mp> bzoltan: so only in autopilot, and not if you launch them from the apps scope?
[10:26] <didrocks> sil2100: you flashed clean on latest iso?
[10:27] <didrocks> sil2100: no rw mode with leftover updates?
[10:27] <ogra_> 54 loops with the revert to cgroup-lite up to now
[10:29] <didrocks> ogra_: reverted to 1.8?
[10:30] <sil2100> didrocks: hm, didn't flash it clean, let me maybe remove all user-data
[10:30] <ogra_> didrocks, nope, just installed cgruops-lite, turned cgmanager and cgproxy off with override files and set the start condition og lxc-android-config to started cgroup-lite
[10:30] <sil2100> ogra_: \o/
[10:30] <didrocks> ogra_: ok, keep us posted :)
[10:30] <ogra_> 59 :)
[10:30] <didrocks> ogra_: do you have something that we can test as well?
[10:31] <ogra_> if it doesnt hang until 300 i'll upload lxc-android-config with that change
[10:31] <ogra_> didrocks, well, do the steps i told above
[10:31] <didrocks> ogra_: I would have said 200 is enough :)
[10:31] <didrocks> if you prefer an additional 100 ones… :p
[10:32] <ogra_> well, my run over night only died at 363
[10:32] <bzoltan> t1mp: it looks perfectly normal when the app is launched from the Shell
[10:39] <Mirv> sil2100: can we compare the AP results now? so for new AP, I got 8 failures in messasing_app (out of 16), and 2 failures in dialer_app (out of 9). but then I also got the same with old AP.
[10:39] <Mirv> sil2100: but I still haven't been able to run unity8 AP for some reason, new or old AP.
[10:40] <Mirv> sil2100: so I'm thinking if you could upgrade to the autopilot AP and compare dialer + messaging + unity8 there to the new. oh, and did you run webbrowser_app?
[10:41] <Mirv> so far I don't have clear indications that the new autopilot would cause problems directly, but with all these other problems it's a bit hard to say for sure, so doube-checking would be welcome
[10:41] <dbarth> sil2100: o/ line 25 should be ready now
[10:42] <Mirv> didrocks: sil2100: but anyway with the new autopilot I've everything else 100% passing - only unity8, messaging, dialer, webbrowser would need double-checking with old/new so that we could at least understand whether we can release the autopilot
[10:42] <mandel> vila, bug #668799
[10:42] <mandel> vila, and bug #1098729
[10:42] <didrocks> I let you guys handle it :)
[10:43] <Mirv> yep, I'll run webbrowser again at least with old AP now, might be just something flaky.
[10:44] <sil2100> dbarth: \o
[10:44] <sil2100> Mirv: ok, so...
[10:44] <sil2100> Mirv: I had 1 failure on dialer-app and 8 on messaging-app, I ran webbrowser-app but didn't get any failures there seemingly
[10:45] <sil2100> Mirv: and I was able to run unity8 tests as mentioned earlier - they took much much longer because of the hangups, but it said that all succeeded, no failures
[10:45] <sil2100> Mirv: but I need to clean my environment
[10:46] <vila> mandel: you should subscribe to bug 1098729
[10:46] <vila> mandel: I'm not sure who you could ping to get progress on it though...
[10:46] <vila> may be ogra knows ^
[10:47] <Mirv> sil2100: ok, so that sounds about the same as I do, and you could check with the new AP if you also get similar results there
[10:47] <Mirv> sil2100: but it seems so far the new autopilot is not to blame
[10:48] <sil2100> Mirv: I'll give it a shot ;)
[10:49] <Mirv> thanks. at least we can probably get a result on the autopilot. then what's causing the size issues and AP failures is a whole another topic.
[10:52] <Mirv> dbarth: assigning the silo
[10:53] <sil2100> Mirv: assigning silo for seb128 then ;)
[10:54] <Mirv> cool
[10:54] <Mirv> dbarth: landing-001
[10:55] <seb128> sil2100, thanks
[10:58] <zbenjamin> ogra_: ping, bzoltan told me you are the right guy to ask if there is a way to get the device name (like mako, maguro..) when i run something on the device
[10:58] <zbenjamin> ogra_: i need to know which ubuntu-touch-session file contains the environment variables i need to set for executing a application in a debug session.
[11:00] <ogra_> zbenjamin, DEVICE="$(getprop ro.product.device)"
[11:00] <zbenjamin> ogra_: awesome thx!
[11:01] <ogra_> if you run it before the container (and thus the property system is up) DEVICE="$(grep ^ro.product.device= /system/build.prop |sed -e 's/.*=//')"
[11:02] <dbarth> Mirv: thanks
[11:02] <ogra_> mandel, try hallyn (in #ubuntu-devel ... though i'm not sure he is fancy caring for the armhf side of things)
[11:03] <zbenjamin> ogra_: i have to run it when executing a click app, so the device is fully booted
[11:03] <mandel> ogra_, thx
[11:03] <ogra_> zbenjamin, then the first one is what you want
[11:08] <ogra_> didrocks, i'm at 110 loops and still counting
[11:08] <didrocks> ogra_: let's cross fingers!
[11:12] <bzoltan> sil2100: Mirv: can I get a silo for line 28? These are two MRs need to be tested separate from the other UITK MRs
[11:13] <sil2100> bzoltan: sure
[11:14] <sil2100> bzoltan: these need urgent testing, right?
[11:15] <mhr3> sil2100, can i get silo for 27?
[11:15] <mhr3> sil2100, plus question, we bumped soversion, is it enough to list all the dependant pkgs in "additional source packages to land"?
[11:15] <sil2100> mhr3: oh, you just turned it to yes, sure
[11:16] <t1mp> sil2100: as urgent as any ;) I need to test it and land it, other changes are pending on it. But they are not related to any critical bug that is in the images now
[11:16] <sil2100> mhr3: hm, no - how many rdeps do you have?
[11:16] <mhr3> sil2100, 5-6... ish
[11:16] <t1mp> sil2100: ^I was referring to line 28 that bzoltan requested a silo for
[11:17] <sil2100> t1mp, bzoltan: since uitk already has a silo - if you really need to test this before the other lands, I can override conflicts for you and allow you to have a silo, but you need to remember to rebuild the silo once the other one lands
[11:18] <sil2100> mhr3: the "additional source packages to land" mean source packages which will be dput to the PPA
[11:18] <sil2100> mhr3: you would need to include at least empty MRs for those rdeps (for those that we do CITrain for) and then force_rebuild during build
[11:19] <t1mp> sil2100: ok
[11:20] <mhr3> sil2100, why is the empty mr necessary? isn't it the same as listing them there?
[11:21] <sil2100> mhr3: listing where? Additional source packages to land means that CITrain will 'expect' some additional source packages to be dputted to the PPA
[11:21] <mhr3> oh... ok i see
[11:21] <sil2100> mhr3: if you list them there, you would have to actually dput no-change rebuilds then
[11:22] <mhr3> right
[11:22] <mhr3> sil2100, ok, so let's build the lib and then i'll reconfigure and add mrs for all the rdeps
[11:22] <ogra_> wow !
[11:22] <sil2100> mhr3: ok ;) Let me assign then
[11:22] <ogra_> did anyone ever try to ssh from the terminal app ?
[11:23] <ogra_> it prints your password in clear text on the screen at the password prompt
[11:23] <sil2100> ogra_: sounds like a nice feature
[11:23] <sil2100> At least you won't make any mistakes!
[11:23] <ogra_> lol
[11:23] <t1mp> ogra_: *finally* a terminal app where we can see what we are typing :D
[11:23] <ogra_> beyond that it works really nicely !
[11:24] <t1mp> ogra_: change your password to 6 *s :)
[11:24] <ogra_> lol
[11:25] <t1mp> ogra_: http://www.bash.org/?244321 :D
[11:26] <davmor2> ogra_: did you get the zero size font issue on initial startup?
[11:26] <ogra_> davmor2, nope. started fine
[11:26] <davmor2> ogra_: ah is this a fresh install though or just and upgrade?
[11:27] <ogra_> davmor2, fresh install of 274 upgraded to 275
[11:27] <ogra_> loop 137 btw ...
[11:27] <davmor2> oh nice maybe it has been fixed then
[11:27] <ogra_> t1mp, heh, i know that one :)
[11:27] <ogra_> davmor2, but i never remember having it
[11:28] <ogra_> (though i only use the terminal occasionally
[11:28] <ogra_> )
[11:28] <sil2100> ogra_: keeping my fingers crossed!
[11:32] <davmor2> ogra_: this is on flo http://davmor2.co.uk/~davmor2/screenshots-phone/screenshot-20140404-122912.png if I change the font to 14 everything is fine then, but this is an older install so I'll do a fresh install and see if is shows up again
[11:33] <ogra_> ouch
[11:33] <ogra_> yeah, i dont get that
[11:36] <ogra_> yay
[11:36] <ogra_> 150
[11:39] <bzoltan> didrocks: ogra_: sil2100: sorry, I did not follow the logs... was there a response to the wrong scaling issue?
[11:39] <sil2100> bzoltan: it's not reproducible on my device, but Mirv saw it sometimes
[11:40] <ogra_> bzoltan, i didnt even recognize a question about the wrong scaling issue :P
[11:40]  * ogra_ reads backlog
[11:40] <bzoltan> sil2100:  I see it all the time with all autopilot tests...
[11:40] <bzoltan> ogra_: in brief... for me it seems that the .bashrc exports are missing when autopilot starts the apps
[11:41] <sil2100> hm, strange
[11:41] <ogra_> bzoltan, that either means you restarted lightdm (and thus the dbus/upstart adresses changed underneath you) without re-login on the shell, or that there is some bug we dont know about yet
[11:42] <ogra_> also make sure to have the latest phablet-tools
[11:42] <ogra_> adb shell handling was changed significantly by the foundations team recently
[11:42] <bzoltan> ogra_: All I do is a clean flash, make it writable (that reboots) install a bunch of packages as Mirv suggested and run the test
[11:43] <bzoltan> ogra_: I have the latest phablet t ools
[11:43] <ogra_> ad you only use phablet-test-run ?
[11:43] <sil2100> hmmm
[11:43] <ogra_> thats weird
[11:43] <ogra_> it was definitely adjusted for the changes ...
[11:44] <Mirv> the easiest way to reproduce is (maybe) running dialer_app tests, but even that doesn't seem to be the case for all
[11:44] <Mirv> so it seems weird
[11:44] <ogra_> phablet-tools 1.0+14.04.20140401-0ubuntu1
[11:44] <ogra_> thats what you need
[11:44] <sil2100> Mirv: hmm... with the new autopilot I get a bigger, varying number of failures, not sure what's up
[11:45] <ogra_> note that dialer and messaging app need ohhono-phonesim-autostart installed ... note also that other tests may fail if ofono-phonesim-autostart is installed, you want to make sure to remove it after testing the dialer or messaging app
[11:47] <Mirv> sil2100: here's all I have, for reference http://pastebin.ubuntu.com/7202885/
[11:47] <Mirv> I've now been trying to get the retrace out of the unity8 crash, but the device choked on that so I'm trying again and also on host
[11:48] <ogra_> Mirv, see above, did you properly install/uninstall ophono-phonesim-autostart ?
[11:48] <sil2100> Mirv: I ran 3 test suites at once now and got 27 failures o_O But maybe my device is not clean enough
[11:48] <davmor2> ogra_: you have a flo right?
[11:48] <ogra_> davmor2, yes
[11:48] <Mirv> ogra_: not installed, but note that #275 I had AP:s passing fine without
[11:49] <ogra_> Mirv, hmm, did you have a SIM during the test ?
[11:49] <davmor2> ogra_: can you bootstrap it to the latest and try and connect to wifi please
[11:49] <Mirv> ogra_: no SIM either
[11:49] <ogra_> and the tests passed ?
[11:49] <ogra_> that cant be
[11:49] <Mirv> :S
[11:49] <ogra_> either a SIM card or ophono-phonesim-autostart needs to be installed
[11:50] <Mirv> and #275 didn't have it somehow automatically?
[11:50] <ogra_> (i thought that was a dep of the two AP packages)
[11:50] <bzoltan> ogra_: I have 1.0+14.04.20140401-0ubuntu1
[11:50] <ogra_> the important point is that you need to purge it after the test
[11:50] <ogra_> bzoltan, hmm, and this is a fresh install with --wipe and --bootstrap ?
[11:51] <bzoltan> ogra_: with --wipe not with --bootstrap
[11:51] <Mirv> ogra_: it doesn't seem to be a dependency, but the results I posted on the mailing list yesterday with full pass rate for dialer/messaging were without SIM and with the same autopilot packages as today
[11:51] <ogra_> oh, you should always use --bootstrap
[11:51] <ogra_> else you end up with the former kernel/initrd
[11:51] <Mirv> ogra_: no, unfortunately not too fresh
[11:51] <Mirv> argh
[11:51] <Mirv> so I'm running some weird kernel/initrd then..
[11:52] <didrocks> ok, I'll be back in a few hours. If anything urgent, send me a message or ask seb to send on my personal emails. Working offline meanwhile
[11:52] <didrocks> sil2100: Mirv: ogra_: ^
[11:52] <didrocks> ogra_: keep up the successfully reboot meanwhile! :)
[11:52] <Mirv> ok didier
[11:52] <ogra_> the one that was installed with the last --bootstrap or if you did an OTA that got you a full flash with the one that came by OTA
[11:52] <ogra_> didrocks, loop 172
[11:52] <didrocks> \o/
[11:53] <Mirv> sil2100: have you had a change of unity8 AP with the new autopilot? if that passes, I'm inclined to believe the new autopilot is not a problem
[11:54] <davmor2> ogra_: interesting I did a reboot and then the popup for wifi pasword appears
[11:54] <ogra_> a small race perhaps
[11:54] <ogra_> most likely due to the system being under heavy load on a first boot after flash/OTA
[11:56] <davmor2> ogra_: I don't know I gave it 5 minutes before I retried and it didn't appear, however after reboot it appeared first time meh who knows
[11:57] <Mirv> FYI I can't seem to get a good retrace of the unity8 crasher, I'm instead getting this: http://pastebin.ubuntu.com/7202927/
[11:58] <Mirv> oh, but, on the desktop side.. let's see
[11:58] <Mirv> too many windows open
[12:01] <sil2100> Mirv: not yet, I'm still re-running test suites one by one to see which one of them had so many failures during last runs
[12:01] <sil2100> Mirv: webbrowser seems to pass 100%
[12:04] <Mirv> finally. bug #1302550 is my unity8 crash from today retraced.
[12:05] <Mirv> michi is not here, but he was interested
[12:05] <sil2100> Mirv: yeah, I poked him back, but he seems to be away now
[12:06] <sil2100> Mirv: he was poking me on the private channels which I rarely look at :<
[12:06] <Mirv> I msg:d him on the other network now with that
[12:06] <Mirv> same here
[12:13] <ogra_> 14:12:34 LOOP 200
[12:13] <ogra_> \o/
[12:21] <sil2100> \o\
[12:21] <sil2100> /o/
[12:21] <sil2100> ogra_: you still want to wait till 300?
[12:22] <ogra_> 250 at least
[12:22] <sil2100> Mirv: REALLY strange stuff just happened
[12:22] <sil2100> Mirv: I re-ran messaging, dialer and webbrowser and got 0 failures
[12:23] <sil2100> Mirv: but this time I didn't run all of them at once (with one phablet-test-run command), but ran first webbrowser, then messaging and then dialer
[12:23] <sil2100> And all tests passed, hm
[12:23] <sil2100> (while running new autopilot)
[12:23] <sil2100> It's really hard for me to get reliable test results ;/
[12:28] <Mirv> sil2100: familiar feeling you have there!
[12:29] <Mirv> sil2100: well, sounds good anyway for the new autopilot. like I posted to the mailing list, it's starting to sound - regarding the new autopilot - that if you get unity8 passing it's ok to be published
[12:29] <sil2100> Mirv: still running the tests, will know for sure in a moment
[12:30] <seb128> grrrr
[12:31] <seb128> sil2100, Mirv: I've an issue with silo 005, maybe you can help me? I reconfigured to add a branch, but the "build" job insists on not picking it up ... is there some secret magic I need to do?
[12:32] <sil2100> seb128: let me take a look
[12:32] <seb128> thanks
[12:33] <sil2100> seb128: hmm... I don't see you running the reconfigure job though
[12:34] <sil2100> seb128: let me run that
[12:34] <Mirv> hmm
[12:34] <seb128> sil2100, weird, I did click on it and the MPs list on the google tab has the 3rd mps listed
[12:35] <sergiusens> Mirv: sil2100 can I get a silo for usensord/l30?
[12:35] <seb128> sil2100, I might have hit again that sso bug where the first action after a timeout is not working
[12:35] <sil2100> seb128: yes, but the backend doesn't seem to have been reconfigured - maybe  the SSO kicked in and made it die
[12:35] <sil2100> seb128: I reconfigured now
[12:35] <seb128> sil2100, thanks
[12:35] <sil2100> seb128: can you retry building?
[12:36] <seb128> done
[12:36] <seb128> let's see
[12:36] <sil2100> seb128: \o/
[12:36] <seb128> it's confusing that the gdoc MPs list is different from what the backend sees
[12:38] <Mirv> sergiusens: sure
[12:39] <Mirv> sergiusens: landing-010 for usensord
[12:40] <seb128> sil2100, it worked, thanks
[12:43] <sergiusens> Mirv: ty sir
[12:53] <pmcgowan> Mirv, what is requiring all the qtquick stuff to be updated in latest image
[12:56] <sil2100> Mirv: damn, those unity8 tests take even longer now ._.
[12:57] <ogra_> i wonder if we should consider 263 reboot loops a successful enough test
[12:58] <sil2100> hmm
[12:58] <plars> ogra_: do you have a possible fix?
[12:58] <ogra_> plars, yes, see the bug
[12:58] <sil2100> ogra_: last time you said you got a failure after 300, right?
[12:59] <ogra_> sil2100, yeah
[12:59] <plars> ogra_: I had a test running overnight with 273 + systemd updates, it's still running after 587 loops
[12:59] <sil2100> I would say it's fixed after 260 though...
[12:59] <ogra_> sil2100, but that was with all debugging enabled
[12:59] <ogra_> which made the error appear less frequently it seems
[12:59] <ogra_> i now have all debugging off and the changes described on the bug in place
[12:59] <pmcgowan> sil2100, do you know why all those qtdeclarative packages are being updated?
[12:59] <sil2100> Mirv: unity8 tests all success on new AP, should I publish it?
[13:00] <ogra_> without the changes and deugging off i have never seen more then 120 loops
[13:00] <sil2100> pmcgowan: hm, not sure, let me look into that, one moment
[13:00] <ogra_> the average was rather in the 80s
[13:01] <plars> ah, ok so it was the lxc android bit after all. That's one that I couldn't upgrade from 273
[13:01] <ogra_> plars, well, it was the switch from cgroups-lite to cgmanager/cgproxy
[13:01] <plars> gotcha
[13:02] <sil2100> pmcgowan: so we had a qtdeclarative landing 12 hours ago, Timo had a fix for the LP: #1298978
[13:03] <sil2100> pmcgowan: so a lot of binary packages got upgraded
[13:03] <sil2100> ogra_: I would say...
[13:03] <sil2100> ogra_: "SHIP IT!"
[13:03] <ogra_> 271 btw :P
[13:04] <ogra_> err 272
[13:04] <ogra_> :)
[13:04] <pmcgowan> sil2100, so that one change triggered all those new packages?
[13:05] <pmcgowan> I guess the source package drives them all
[13:05] <pmcgowan> sil2100, thanks
[13:05] <pmcgowan> ogra_, seems you got it, why did that switch occur in the first place, out of curiosity
[13:06] <sil2100> pmcgowan: yeah, qtdeclarative generates around ~20 binary packages, so most of those probably come from that one
[13:06] <cjwatson> Binary packages always go together, yes
[13:06] <cjwatson> See   apt-cache showsrc qtdeclarative-opensource-src | grep -m1 ^Binary:
[13:06] <ogra_> pmcgowan, lxc uses cgmanager by default now
[13:06] <ogra_> pmcgowan, no idea why, upstream thing ... i just followed suit with the deps
[13:06] <pmcgowan> ogra_, did that change just happen or did it go through CI?
[13:06] <ogra_> pmcgowan, the package went through CI
[13:06] <pmcgowan> ok
[13:07] <ogra_> (the dependency switch)
[13:07] <Mirv> pmcgowan: those are all from the qtdeclarative src package, which got the date format patch
[13:07] <pmcgowan> Mirv, ok thanks
[13:07] <ogra_> and i dont think it was that crashy in the beginning
[13:07] <ogra_> the combo of that issue plus the updated udev started it
[13:07] <Mirv> sil2100: yes, I think so
[13:07] <pmcgowan> yeah thats a tough one
[13:08] <ogra_> before the udev chnage we saw more device crashes already apparently
[13:08] <ogra_> but not as broad
[13:08] <sil2100> ogra_: shiiip iiiit!
[13:08] <sil2100> ;)
[13:08] <ogra_> yeah, yeah ...
[13:08] <ogra_> on it :)
[13:10] <davmor2> sil2100: with that amount of iii's it sound more like sheep eat!
[13:11] <sil2100> hah
[13:11] <sil2100> ;)
[13:11] <sil2100> ogra_: just don't eat the sheep!
[13:12] <sil2100> Mirv: ok, so I'll publish autopilot now then
[13:12] <circ-user-JSua3> ogra_: and do not stop the testing, maybe you find some bug at loop 370 :)
[13:15] <sergiusens> ogra_: so you have a fix?
[13:16] <sergiusens> ogra_: nvm, /me read backlog
[13:17] <didrocks> back!
[13:18] <ogra_> http://paste.ubuntu.com/7203232/
[13:18] <sil2100> \o/
[13:19] <didrocks> ogra_: how many successful reboots?
[13:19] <ogra_> didrocks, i stopped at 278
[13:19] <didrocks> ogra_: you didn't wait for 300?
[13:19] <didrocks> I'm shocked :p
[13:19] <ogra_> haha
[13:19] <didrocks> ogra_: can't wait to have an image with that
[13:20] <didrocks> psivaa: plars: ev: can you reenable the automatic AP tests (now that we know next image shouldn't hang)
[13:20] <didrocks> nice work ogra_!
[13:20] <plars> didrocks: yep, on it
[13:20] <didrocks> thanks :)
[13:20] <ogra_> uploaded
[13:23] <sergiusens> Mirv: can you take action on silo 10 please?
[13:25] <sil2100> sergiusens: publishing, Mirv seems to be EOD already
[13:25] <didrocks> ogra_: let's look at it and kick an image as soon as it's published
[13:25] <sergiusens> sil2100: thanks
[13:25] <ogra_> didrocks, thats the plan
[13:27] <mhr3> sil2100, ehm, i can't reconfigure myself?
[13:27] <mhr3> ERROR:root:unity-scopes-shell was not in the initial list of components for that silo. You can't reconfigure the silo yourself. Please ask the landing team to reconfigure it for you.
[13:28] <didrocks> mhr3: was it in the initial list of component?
[13:28] <didrocks> or did you just add it?
[13:28] <sil2100> mhr3: yeah, so, when you reconfigure you cannot add 'new' components, only add new merges to existing ones
[13:28] <mhr3> hmm, that's new
[13:28] <sil2100> didrocks: he only had unity-scopes-api, wants to add additional packages
[13:28] <mhr3> right ^
[13:28] <didrocks> mhr3: so, I guess the error message is clear enough, no? :p
[13:28] <sil2100> mhr3: if you want new components, a landing team member needs to reconfigure the silo for you
[13:29] <mhr3> didrocks, it is, but i used to be able to do that
[13:29] <sil2100> Like, new packages
[13:29] <didrocks> this is a protection on purpose to avoid "locks" :p
[13:29] <didrocks> mhr3: hum, no ;)
[13:29] <didrocks> mhr3: or it was a bug, but I didn't change anything
[13:29] <didrocks> mhr3: you can add MP to existing components
[13:29] <didrocks> not add new components
[13:29] <mhr3> hm.. so anyway, someone reconf pls
[13:30] <sil2100> mhr3: doing
[13:30] <rsalveti> Saviq: thanks for taking care of the powerd UNRELEASED changelog fix
[13:31] <rsalveti> and morning folks :-)
[13:31] <didrocks> bzoltan: are you ready for line 28? if we assign it to you, you can release before Monday?
[13:31] <sil2100> mhr3: reconfigured o/
[13:31] <sil2100> rsalveti: morning
[13:31] <mhr3> sil2100, ty
[13:31] <sil2100> didrocks: I was waiting for the UITK to move out of -proposed
[13:31] <didrocks> ah
[13:31] <didrocks> previous utk
[13:31] <didrocks> sure sure :)
[13:31] <didrocks> I thought you blocked on unity8
[13:31] <sil2100> didrocks: yes ;) Didn't want to overuse the override ;p
[13:32] <didrocks> sil2100: yeah, don't :p
[13:32] <didrocks> sil2100: unity8 is in the split greeter one though
[13:32] <didrocks> sil2100: which isn't going to land, right?
[13:32] <bzoltan> didrocks:  sure, but the line 15 is queuing  https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=
[13:32] <didrocks> bzoltan: ok, so let's wait for it to pass UNAPPROVED
[13:33] <bzoltan> didrocks: +1
[13:33] <didrocks> bzoltan: while I wasn't around, did you find an explanation on the terminal/env variable issue?
[13:33] <didrocks> and discrepancy with sil2100?
[13:33] <sil2100> didrocks: ah, indeed, unity8 - so ignore conflicts would be anyway necessary, but still, didn't want to do it because of UITK
[13:33] <didrocks> sil2100: yeah, for that one, we have to wait
[13:33] <bzoltan> didrocks:  no, not yet
[13:33] <didrocks> ok
[13:33] <bzoltan> didrocks:  it is a problem ... a big one for us
[13:34] <sil2100> didrocks: we didn't find anything yet though... but at least me and Mirv we were able to do a +1 on the new autopilot
[13:34] <sil2100> As it didn't really regress anything
[13:34] <didrocks> bzoltan: yeah, I think you need to talk to sergiusens, he would maybe have a lead (the recent changes of env variables)
[13:34] <didrocks> sil2100: good
[13:34] <ogra_> rather xnox
[13:35] <didrocks> oh right xnox
[13:35] <ogra_> or slangasek
[13:35] <didrocks> bzoltan: ^
[13:35] <ogra_> they did the changes
[13:37] <didrocks> sil2100: seems you didn't notice line 30 btw
[13:37] <didrocks> for sergiusens
[13:37] <didrocks> I did change the hilight to yellow :p
[13:37] <didrocks> highlight
[13:37] <sil2100> Right! heh ;)
[13:37] <sil2100> Sorry, looking
[13:37] <sergiusens> it would be good to describe how phablet-test-run is affecting ui toolkit
[13:37] <ogra_> use <blink>
[13:37] <sil2100> ACKing that, core-dev change
[13:38] <sergiusens> sil2100: well, fwiw I'm a ppu uploader for that package too
[13:38] <sergiusens> *ppu for that package
[13:39] <cjwatson> ubuntu-ui-toolkit accepted
[13:39] <sil2100> cjwatson: thank you o/
[13:39] <alecu> mhr3: https://code.launchpad.net/~dobey/unity-scope-click/show-ratings/+merge/213090
[13:44] <boiko> didrocks: Mirv: sil2100: just a heads up, landing-009 is tested and ready to go
[13:45] <sil2100> boiko: o/
[13:45] <sil2100> boiko: handling that, thanks
[13:46] <bzoltan> didrocks: i see the UITK was accepted https://launchpad.net/ubuntu/trusty/+queue?queue_state=2&queue_text=
[13:47] <didrocks> bzoltan: yeah, (see 6 lines above ;))
[13:49] <fginther> mandel, pong
[13:50] <fginther> mandel, I may not have any more insight for you regarding your test failures, but we can chat about it
[13:51] <mhr3> sil2100, hmm, seeing something weird
[13:51] <mhr3> 2014-04-04 13:36:07,659 INFO No new useful revision published compared to dest, no need to upload this component
[13:51] <sil2100> mhr3: what's up?
[13:51] <sil2100> mhr3: ah, you need to force rebuild
[13:51] <sil2100> mhr3: that checkbox I mentioned
[13:51] <mhr3> ok
[13:51] <mhr3> sil2100, and more interesting one
[13:51] <mhr3> https://ci-train.ubuntu.com/job/landing-008-1-build/8/console
[13:52] <mhr3> very bottom
[13:54] <mandel> fginther, hi! I just want to make sure that the failure is due to the load and not the code or a combination of cmake + arm + qt + new signals
[13:54] <sil2100> uh
[13:55] <mandel> fginther, for me, if we can run the tests in one of the servers outside jenkins or at least ensure the pass with no load I'll be happy to work on a workaround
[13:55] <mandel> fginther, right now, the only info I have is that the people from the unity-scope-click had the same issue and moved from new signals to old ones in qt
[13:56] <sil2100> mhr3: that's from the run with force rebuild?
[13:56] <mhr3> sil2100, no, without
[13:56] <bzoltan> cjwatson: thanks!
[13:56] <sil2100> mhr3: maybe retry and let's see if it happens again
[13:56] <didrocks> sil2100: mhr3: if it's telling that there is no new useful revision published compared to dest, it means that the generated source package doesn't contain anything. It that expected?
[13:56] <mhr3> sil2100, seems the branch is screwed
[13:56] <didrocks> like no difference with distro
[13:57] <sil2100> didrocks: yes
[13:57] <didrocks> so no need to "force rebuild"
[13:57] <sil2100> didrocks: we want a no-change rebuild for new ABI-change
[13:57] <didrocks> as it's not an ABI break?
[13:57] <didrocks> ah ok
[13:57] <didrocks> so yeah, for that, you need to force rebuild :)
[13:57] <sil2100> ;)
[13:58] <didrocks> mhr3: remark at the bottom is worrying though
[13:58] <mhr3> didrocks, indeed
[13:58] <mhr3> i can't even branch the branch
[13:58] <didrocks> mhr3: it's just running bzr branch lp:unity-scope-click
[13:58] <mhr3> it's f-ed up
[13:58] <sil2100> ;/
[13:59] <ogra_> didrocks, got the lxc-android-config mail ... should be ready with the next publisher run
[13:59] <didrocks> ogra_: \o/
[13:59] <ogra_> i'll trigger the build then
[13:59] <didrocks> mhr3: yeah, same here…
[13:59] <didrocks> what did manuel do! :)
[14:00] <mhr3> i have a copy of the branch
[14:00] <mhr3> can try to push overwrite it
[14:07] <fginther> mandel, the best I can do is try a build on an isolated armhf node. I don't access to any armhf hardware outside of jenkins
[14:07] <mandel> fginther, that is more than enough, an isolated one would do the trick
[14:08] <fginther> mandel, another good experiment would be to upload to an armhf enabled PPA
[14:09] <mandel> fginther, my ppa supports that, I'll do it right now (although it will take some time to build)
[14:11] <fginther> mandel, do you have an MP ready to test?
[14:12] <mandel> fginther, the following one fails in a rather "consistent" way lp:~mandel/ubuntu-download-manager/udm-shared-libs
[14:13] <mandel> fginther, it has to new dependencies, cmake and google-mock, the rest you can get with the build-deps of ubuntu-download-manager
[14:29] <didrocks> ogra_: starting an image build
[14:29] <ogra_> didrocks, already running
[14:29] <ogra_> (bot is a bit slow it seems)
[14:30] <imgbot> [14:30] <didrocks> ogra_: oh?
[14:31] <didrocks> ogra_: not sure if my request will be cancelled then
[14:31] <ogra_> you cant cancel builds
 didrocks, got the lxc-android-config mail ... should be ready with the next publisher run
 ogra_: \o/
 i'll trigger the build then
[14:31] <ogra_> :P
[14:31] <didrocks> ogra_: not sure if you noticed
[14:31] <didrocks> actually
[14:32] <ogra_> so we'll get two builds in succession ... unlikely that we get test results in time for the EU workday then
[14:32] <didrocks> well, we'll get even more ocnfirmation :p
[14:32] <didrocks> ogra_: hum, not related to those 2 builds
[14:33] <didrocks> ogra_: the first image will publish
[14:33] <didrocks> then, the system take it
[14:33] <didrocks> and will start processing AP test results
[14:33] <didrocks> then, only the second image will start to be tested
[14:33] <ogra_> and 1.5h later the second one will show
[14:33] <ogra_> right
[14:33] <didrocks> yeah
[14:34] <didrocks> so it won't cancel the current tests
[14:40] <elopio> ping josepht: do you know why jenkins hasn't run the tests for this?
[14:40] <elopio> https://code.launchpad.net/~rhuddie/gallery-app/photo_selector/+merge/208761
[14:40] <Chipaca> could i have a silo for row #29 plz?
[14:40] <sil2100> Chipaca: looking
[14:42] <Chipaca> sil2100: ta
[14:43] <josepht> elopio: looking
[14:43] <Chipaca> sil2100: ta
[14:44] <sil2100> Chipaca: yw!
[14:44] <sil2100> boiko: you can m&c :)
[14:44] <boiko> sil2100: nice! thanks!
[14:45] <boiko> sil2100: done
[14:55] <bzoltan1> sil2100:  may I ask for a silo to the line 28? The last UITK MP just landed on trunk.
[14:55] <sil2100> bzoltan1: awesome o/ Yeah, let me do that
[14:55] <bzoltan1> sil2100:  sweet! Thanks
[14:56] <josepht> elopio: I've kicked off a build for that MP
[14:57] <elopio> josepht: thank you.
[14:58] <Saviq> rsalveti, sure
[15:01] <bzoltan1> sil2100: thanks!
[15:03] <sil2100> bzoltan1: yw!
[15:33] <vila> mup: help
[15:34] <vila> imgbot: help
[15:34] <imgbot> I am the friendly image watchbot
[15:34] <vila> imgbot: commands ?
[15:35] <ogra_> status <buildid>
[15:35] <ogra_> and it knows this one
[15:35] <ogra_> imgbot, stunt
[15:35]  * imgbot rolls on its back and purrs
[15:35] <vila> he he
[15:35] <ogra_> thats all it can
[15:37] <vila> imgbot: status 275
[15:37] <imgbot> Image 275 for mako has not finished the tests, status is: Running
[15:37] <ogra_> (takes a little, it is screen scraping the dashboard)
[15:38] <vila> no problem
[15:38] <vila> ogra_: can he output the url for the changes file ? happy to provide a patch if I can see the code
[15:38] <ogra_> vila, yeah, i can add that
[15:38] <ogra_> over the weekend
[15:38] <davmor2> ogra_: you want to add stunt beg and it say "Bot is on it's hind legs begging for an image, please give it an image"
[15:38] <vila> ogra_: no pressure, thanks a lot !
[15:38] <ogra_> vila, for the interim http://people.canonical.com/~ogra/touch-image-stats/
[15:38] <ogra_> :)
[15:39] <ogra_> davmor2, good idea, i might be adding it
[15:39] <vila> ogra_: yup, been using that so far
[15:39] <vila> ogra_: and clicking twice on the date column
[15:39] <sil2100> bfiller: I'll prepare folk for you and assign a silo
[15:40] <sil2100> bfiller: all the three patches are needed?
[15:40] <ogra_> vila, the date column ?
[15:40] <bfiller> sil2100: great, thanks. ping renato if you have questions about the folks patches. I think all three are needed. renato is that the case?
[15:40] <ogra_> (there are changelogs by image number at the top)
[15:40] <vila> ogra_: forget it, I just bookmarked http://people.canonical.com/~ogra/touch-image-stats/?C=M;O=D (last modified command sorry)
[15:40] <vila> s/command/column/
[15:40] <sil2100> renato: ^ ?
[15:40] <sil2100> :)
[15:41] <ogra_> ah
[15:41] <ogra_> i didnt know you can do that !
[15:41] <renato> sil2100, bfiller I have a mr ready if you want
[15:41] <renato> sil2100, only the first one
[15:41] <vila> ogra_: brain is weird, talking is good ;)
[15:41] <ogra_> :)
[15:41] <sil2100> renato: could you point me to it?
[15:42] <renato> sil2100, sure
[15:45] <imgbot> [15:45] <imgbot> [15:45] <ogra_> wow
[15:45] <ogra_> quite some changes
[15:45] <sil2100> renato: ok, I see it, let me just integrate that
[15:46] <vila> ogra_: but... it already display that url ! gee
[15:46] <ogra_> vila, but only once it reports build success
[15:46] <davmor2> ogra_: I think the freezes are like internet cakes and matrix spoons
[15:46] <renato> sil2100, https://code.launchpad.net/~renatofilho/folks/fixed-folks-disable-linking
[15:46] <ogra_> it doesnt have a "changelog <buildid>" command yet
[15:47] <renato> sil2100, this change: http://bazaar.launchpad.net/~renatofilho/folks/fixed-folks-disable-linking/revision/57
[15:47] <vila> ogra_: yeah or "last build" ?
[15:47] <ogra_> davmor2, ahg then we are fine ... we just need to put "includes personal matrix" on the box
[15:47] <vila> ogra_: nah
[15:47] <vila> ogra_: ignore me
[15:47] <vila> :)
[15:47] <davmor2> who said that
[15:48] <davmor2> ogra_: nice :)
[15:48] <davmor2> ogra_: I would prefer now including your delivery of internet cake :)
[15:49] <ogra_> om nom nom
[15:49] <ogra_> already eaten :P
[15:49] <davmor2> haha
[15:51] <kgunn> robru: wanna publish silo 11 ?
[15:51] <robru> kgunn, yes!
[15:52] <robru> kgunn, and done
[15:55] <bfiller> elopio: I'm testing gallery autopilot with your MR applied: https://code.launchpad.net/~elopio/gallery-app/override_toolbar/+merge/213703
[15:55] <bfiller> elopio: getting this failure: http://pastebin.ubuntu.com/7203809/
[15:55] <bfiller> elopio: any ideas what's happening?
[15:56] <elopio> bfiller: looking.
[15:57] <elopio> bfiller: the open_toolbar() is failing.
[15:57] <elopio> bfiller: let me give it a try. Are you running it on desktop?
[15:57] <bfiller> elopio: on device
[15:57] <bfiller> N4
[15:57] <elopio> bfiller: with the package from a silo?
[15:57] <bfiller> elopio: yes, from silo 14
[15:57] <elopio> ok, on it.
[15:58] <bfiller> elopio: thank you, I had to install it as deb as I don't have a click for the silo, so not sure if this factors into the problem at all
[16:01] <didrocks> cyphermox: coming?
[16:08] <seb128> can somebody reconfigure silo7 for me? I did a copy error earlier and listed a branch on a wrong source, changed that now
[16:10] <cyphermox> sergiusens: do we got a silo for the MMS stuff?
[16:11] <sergiusens> cyphermox: not yet; will get one soon; awe_ did you update your MR from yesterday to get siloed?
[16:13] <seb128> cyphermox, can you reconfigure silo7 for me?
[16:13] <cyphermox> seb128: sure
[16:13] <seb128> thanks
[16:16] <cyphermox> seb128: done
[16:16] <seb128> cyphermox, thanks
[16:17] <elopio> bfiller: I can reproduce it sometimes, I don't understand it yet.
[16:19] <bfiller> elopio: ok
[16:19] <cyphermox> seb128: started and aborted build?
[16:20] <seb128> cyphermox, yeah, local screwup, should be good now, sorry (had forgotten the commit message so I stopped it to add it and restarted)
[16:20] <sil2100> bfiller: I uploaded folks to the PPA already if anything, so all *should* be ok
[16:20] <cyphermox> yeah np
[16:20] <cyphermox> seb128: that used to break stuff, but didrocks' fixed it
[16:20] <seb128> good ;-)
[16:22] <didrocks> cyphermox: seb128: just be aware that the status won't be updated
[16:22] <didrocks> in the spreadshet
[16:22] <awe_> sergiusens, nope still working on the bug I mentioned during the standup
[16:22] <seb128> didrocks, cyphermox: that's ok
[16:23] <sergiusens> awe_: ok; I'm going for lunch; when I get back, I have an idea for the silo strategy
[16:23] <cyphermox> didrocks: robru: I'll be out for ~15 minutes, going to retrieve some curry for lunch
[16:23] <didrocks> cyphermox: enjoy!
[16:23] <robru> sweet
[16:24] <cyphermox> that's the one really cool thing about the Montreal office; very cheap amazing curry just down the street :)
[16:25] <bfiller> sil2100: great, thanks
[16:25] <didrocks> vila: ahah, you liked my comment telling "don't bother" :p
[16:25] <bfiller> sil2100: I started the build on that silo
[16:26] <fginther> mandel, http://s-jenkins.ubuntu-ci:8080/job/ubuntu-download-manager-trusty-armhf-ci-fjg/1/console
[16:26] <fginther> mandel, that's a run of your MP on its own armhf node
[16:26] <vila> didrocks: hehe, yeah. I can go with more: "less work" comments like that ;)
[16:27] <didrocks> vila: at your service :p
[16:29] <fginther> mandel, I just discovered some old, wedged test processes on that node. I'm going to clear them and try again.
[16:36] <elopio> bfiller: the only possible explanation I find is that we are trying to open the toolbar when it's opened, it hasn't started to close, but it will really soon, in less than the time it takes autopilot to select the button.
[16:37] <elopio> I can reorder the statements so that window is even smaller.
[16:37] <bfiller> elopio: ok
[16:38] <bfiller> elopio: do you think this is related to the emulator change you made or always been there?
[16:39] <elopio> bfiller: the window for failure has always been there. My change, or some other change in that silo might have make the test more prone to hit it.
[16:39] <elopio> but I can't know for sure.
[16:39] <bfiller> right
[16:40] <elopio> with this change in the order, I haven't been able to reproduce the error.
[16:40] <elopio> I'm getting sometimes a different one that says MediaSelector is not present, but lets go one by one.
[16:46] <robru> ogra_, sorry, so what's the status of the boot troubles? has a cause been identified? do I need to test further?
[16:46] <ogra_> robru, nope, all donee
[16:47] <robru> ogra_, ok thanks.
[16:47] <ogra_> robru, bug 1302174
[16:56] <elopio> t1mp: can you please review this one? https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1302706-click_toolbar_button_failure_window/+merge/214309
[16:56] <elopio> bfiller_afk: and as it would be bad for you to wait for a new release of the toolkit, this should work:
[16:56] <elopio> https://code.launchpad.net/~elopio/gallery-app/workaround1302706-fix1302706-click_toolbar_button_failure/+merge/214310
[16:58] <t1mp> elopio: wow.. does that mean the try takes so much time that the toolbar closes then?
[16:58] <t1mp> it should be like a millisecond, no?
[16:59] <t1mp> ah wait maybe I read it wrong
[16:59] <t1mp> elopio: get_button does not work when the button is not visible?
[16:59] <t1mp> why is that?
[16:59] <elopio> t1mp: it works when it's not visible.
[16:59] <t1mp> the button exists, it may just be in a toolbar that is under the screen at that time
[17:00] <elopio> it's not only the try what's making us hit the precise moment when the toolbar closes.
[17:00] <elopio> it's a combination of what's happened before we try to click the button, plus the select_single.
[17:01] <t1mp> elopio: I don't understand why you need the change
[17:01] <t1mp> elopio: if for _get_button it does not matter whether the toolbar is open, then why check before that instead of afterwards?
[17:02] <elopio> t1mp: this changes makes the failure window like 0.02 smaller.
[17:02] <elopio> what I want with that check is to make sure people don't forget to open the toolbar before clicking the button. It's not intented for the _get_button to work.
[17:02] <elopio> get_button will work if the toolbar is closed anyway.
[17:04] <elopio> t1mp: makes sense?
[17:05] <t1mp> I don't mind the change, code-wise maybe it looks a bit better if we do the check first, but functionally I see no difference
[17:05] <t1mp> elopio: the MR links to a bug, but it doesn't fix the bug right?
[17:06] <elopio> t1mp: yes, with this change, the gallery doesn't fail anymore.
[17:06] <elopio> without it, it fails like 1 out of 3 times.
[17:07] <t1mp> so without it, AP gets the button, then the toolbar closes, and then the test fails?
[17:07] <elopio> t1mp: yes.
[17:07] <t1mp> and with it, it checks for the toolbar to be open, and then gets the button, then clicks it, and the toolbar is still open?
[17:08] <elopio> yes.
[17:08] <t1mp> wow
[17:08] <elopio> and if it closes in the mean time, after getting the button we call open again. I think you added that part.
[17:09] <t1mp> ah yes, true. I overlooked that now
[17:09] <t1mp> I get it now.
[17:09] <t1mp> makes sense to check the pre-requisite at the beginning
[17:09] <mhr3> robru, 008 ready to publish
[17:10] <mhr3> robru, and good morning btw :)
[17:10] <robru> mhr3, good morning! just gotta get a core dev ack on those packaging changes
[17:11] <robru> cyphermox, packaging ack? https://ci-train.ubuntu.com/job/landing-008-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-scopes-api_0.4.2+14.04.20140404.1-0ubuntu1.diff
[17:11] <t1mp> elopio: I approved
[17:11] <cyphermox> sure let me look
[17:16] <cyphermox> robru: changelog looks very wrong (unreleased version added under a released one), and looking at the files there, the symlink to the shared lib looks unusual to me too; I need to look deeper than just the diff
[17:16] <robru> cyphermox, thanks
[17:17] <robru> mhr3, ^^ any ideas why that changelog looks weird?
[17:18] <mhr3> robru, hmm, looks like we didn't merge it properly
[17:18] <robru> mhr3, I think it would be fine to just drop that "UNRELEASED" section
[17:18] <mhr3> indeed
[17:19] <mhr3> robru, should i push that and do another rebuild?
[17:19] <t1mp> elopio: did you learn anything new related to this MR? https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-002/+merge/202171
[17:20] <elopio> t1mp: I'm having a headache with that one.
[17:20] <t1mp> I had that yesterday so I gave up ;)
[17:20] <elopio> I have a couple of ideas to try now, but I've spend all morning on it so I took a "break" :)
[17:20] <robru> mhr3, yeah
[17:21] <robru> mhr3, well, wait for cyphermox before rebuilding, he's checking other things
[17:25] <mandel> fginther, awesome thx
[17:31] <cyphermox> mhr3: " * Added ability for defining custom scope runner path, relative to scope's directories." was this added by a merge?
[17:32] <cyphermox> the line is too long, in theory. if it's a manual changelog addition, then it would be better to fix it, if it's automatic from citrain, then I'd just ignore it
[17:32] <mhr3> cyphermox, of course
[17:32] <cyphermox> ah, I mean the actual line in changelog
[17:33] <fginther> mandel, build #2 http://s-jenkins.ubuntu-ci:8080/job/ubuntu-download-manager-trusty-armhf-ci-fjg/2/console
[17:33] <mhr3> cyphermox, no, that's usually manual
[17:33] <mhr3> cyphermox, we mention api additions in changelog
[17:33] <cyphermox> mhr3: ok. since there is a change to do in changelog anyway for the unreleased entry, could you fix that too if it's there?
[17:34] <cyphermox> it's just trimming the line to 80 characters, possibly continuing below
[17:35] <mhr3> cyphermox, k, pushed
[17:35] <cyphermox> thanks
[17:35] <mhr3> cyphermox, anything else, or can i rebuild?
[17:35] <cyphermox> sorry for the nitpicking but while we were editing changelog. .. ;)
[17:35] <cyphermox> no, the rest checks out
[17:35] <cyphermox> feel free to rebuild, then I'll do another quick check of the diff once it's ready to publish
[17:46] <bregma> robru, line 37 is ready and eager to have a silo assigned if you're in the mood
[17:46] <robru> always!
[17:47] <mhr3> robru, 008 rebuilding, i'm keeping tested "yes" since there were just changelog changes
[17:47] <mhr3> pls publish once it builds
[17:48] <mhr3> and i'm heading home
[17:48] <robru> mhr3, thanks!
[18:27] <bfiller> elopio: thanks for your help, I will try your MR
[18:43] <t1mp> plars: hello
[18:44] <t1mp> plars: I am using the ubuntu-test-cases scripts now. they seem to work nice :)
[18:44] <plars> t1mp: great!
[18:44] <plars> t1mp: you can specify the image revision you want in run-smoke too now
[18:44] <t1mp> plars: I only had to replace all 'adb wait-for-device' by 'sleep 60' because wait-for-device always breaks after the device rebooted.. maybe a hardware problem? anyway not a problem with the scripts
[18:45] <t1mp> plars: I am running app AP tests now with ./run-autopilot-tests.sh -Q -a app_name
[18:45] <t1mp> plars: do you know of a way to get a list of apps that I can pass with -a?
[18:45] <t1mp> plars: how do I run the ubuntu-ui-toolkit tests? ./run-autopilot-tests.sh -a ubuntuuitoolkit ? will that work? or is -a only for click apps?
[18:47] <t1mp> plars: ah. image-revision can be useful :) if the newest image is broken. I am testing with 277 now and luckily that one seems good so far
[18:47] <plars> t1mp: that should work fine, and for a list, simply look at the dashboard: all those tests names in a completed run like http://ci.ubuntu.com/smokeng/trusty/touch/mako/274:20140402.1:20140331/7525/ for example
[18:48] <plars> t1mp: now be aware that some of those (the ones under /tests of that tree) are not autopilot tests, and can't be run with -a, you have to use -t for those
[18:49] <plars> t1mp: yeah, I think our guy in the lab that had to continuously reset all those devices yesterday was plotting my murder
[18:49] <plars> fortunately this one has bee lots better
[18:50] <plars> there have been a few failures on mako, but it's still running at least :)
[18:50] <t1mp> t1mp: ok, cool. just to know which test names I can use
[18:50] <t1mp> oh
[18:50] <t1mp> ubuntuuitoolkit has AP tests though
[18:50] <t1mp> plars: do you know why I have failures here? http://paste.ubuntu.com/7204499/
[18:51] <t1mp> they seem to be before and after the actual test
[18:53] <bfiller> robru: silo-09 is failing to build. I think it might be because sync-monitor package is not yet in the archive? any ideas? https://ci-train.ubuntu.com/job/landing-009-1-build/8/console
[18:53] <plars> t1mp: looks like systemsettle never saw it get idle enough
[18:54] <plars> t1mp: under clientlogs, there should be som top logs that give you more detail, or if the system is still in that state you can adb in and look at top
[18:54] <robru> bfiller, sounds like sync-monitor isn't building in split mode, let me check
[18:54] <plars> t1mp: it's looking for it to get down to 97.5% idle
[18:54] <plars> t1mp: but it looks like it's nowhere close to that
[18:55] <robru> bfiller, yeah, sync-monitor is lacking this file: http://bazaar.launchpad.net/~super-friends/friends/trunk/view/head:/.bzr-builddeb/default.conf
[18:55] <robru> bfiller, please add it and rebuild
[18:56] <bfiller> robru: ack, thanks
[19:03] <dbarth> robru: o/ silo 001 verified and ready for publication
[19:04] <robru> dbarth, published!
[19:09] <dbarth> robru: thanks; you can merge & clean later today if you need to free upthe silo, otherwise i'll do it on monday morning
[19:09] <robru> dbarth, great, i probably will, thanks
[19:23] <bfiller> robru: can you create a silo for line 36 please?
[19:24] <robru> bfiller, ok, you got silo 10
[19:24] <bfiller> cheers
[19:30] <bregma> hmm looks like there's a bug in the dark inner magic of ci-train, my build fails because the epoch in the version number confuses it
[20:11] <robru> bregma, log?
[20:12] <bregma> robru, https://ci-train.ubuntu.com/job/landing-018-1-build/4/console
[20:19] <robru> bregma, have we ever done a compiz release with citrain?
[20:21] <bregma> yep, last compiz release was 20140328
[20:21] <cyphermox> sergiusens: silo?
[20:23] <robru> bregma, indeed, just a week ago. bizarre. still poking
[20:25] <mhr3> bregma, is there a bug for the double lock issue?
[20:26] <robru> bregma, that is really strange. why doesn't the epoch version appear in any of the other places the version number is mentioned? Like, "dpkg-source -b compiz-0.9.11+14.04.20140404"
[20:26] <bregma> mhr3, there are several, I believe of subtly different shades
[20:26] <mhr3> bregma, got links to any?
[20:28] <robru> cyphermox, can you help me figure this out? I have no idea what citrain is doing here: https://ci-train.ubuntu.com/job/landing-018-1-build/4/consoleFull some kind of mismatch between the version string in the build job, and the version string that dpkg is using.
[20:29] <bregma> mhr3, https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1291088 is the main one
[20:30] <sergiusens> cyphermox: on my way; sorry got heads deep :-)
[20:30] <cyphermox> sergiusens: np
[20:33] <cyphermox> robru: ahah, it needs to strip epoch
[20:33] <cyphermox> haven't we landed compiz before in citrain?
[20:33] <robru> cyphermox, but I don't understand -- we've done a release of compiz just a week ago. what changed?
[20:36] <cyphermox> well either someone changed the changelog in a way they don't understand (but it doesn't seem to be the case) or someone changed that upload code and forgot to make sure to strip epoch from there
[20:36] <cyphermox> I would have thought it shouldn't strip it though
[20:38] <cyphermox> time to run it locally to see
[20:39] <sergiusens> cyphermox: can you ack this btw? https://code.launchpad.net/~sergiusens/nuntium/packaging/+merge/214101
[20:40] <sergiusens> you did on irc, but not the MR :-)
[20:40] <cyphermox> oh ok
[20:40] <sergiusens> cyphermox: and line 40 should hold the butter
[20:41] <cyphermox> thar
[20:45] <sergiusens> cyphermox: just need a silo assigned; nudge nudge
[20:45] <dbarth> robru: can we get a silo on line 38?
[20:46] <cyphermox> sergiusens: given that i'm participating in the landing though, it would be better if we find someone else when comes the time to do the publishing
[20:46] <robru> cyphermox, i'll be around to publish for a while yet
[20:46] <sergiusens> cyphermox: yeah; the publishing you shouldn't do; but silo assign
[20:46] <robru> dbarth, ok, you got silo 11
[20:46] <cyphermox> assigning right now
[20:47] <sergiusens> robru: we need to extensively test the silo; so it will be a while before publishing
[20:47] <robru> sergiusens, ah ok
[20:47] <cyphermox> eep
[20:47] <cyphermox> ofono has not debian/changelog ?
[20:49] <sergiusens> cyphermox: it gets autogenerated from the commit messages
[20:53] <cyphermox> well, there needs to be something broken
[20:53] <dbarth> robru: thanks
[20:53] <robru> dbarth, you're welcome
[20:54] <sergiusens> cyphermox: not working due to lack of changelog?
[20:55] <cyphermox> nah
[20:55] <cyphermox> jenkins borken
[20:55] <sergiusens> cyphermox: might be the packaging for nuntium as it only exists in the branch and not trunk
[20:55] <sergiusens> oh
[20:55] <sergiusens> usual Friday :-)
[20:55] <cyphermox> nah it's barfing on the ofono branch
[20:55] <cyphermox> cihelp
[20:55] <cyphermox> I have no idea how this is supposed to work :)
[20:56] <fginther> cyphermox, yo
[20:56] <cyphermox> fginther: yo
[20:57] <cyphermox> fginther: any idea why  bzr cat -d lp:~phablet-team/ofono/ubuntu debian/changelog or bzr cat -d lp:~phablet-team/ofono/cf-mms-techpref-simw debian/changelog  don't work on our dear citrain jenkins?
[20:57] <cyphermox> https://ci-train.ubuntu.com/job/prepare-silo/76/console
[20:57] <cyphermox> fginther: ^
[20:57]  * fginther looks
[20:59] <cyphermox> robru: so the issue with compiz is indeed that it seems like the build job should be ignoring the epoch from the version number. not sure why this hasn t failed previously... maybe didrocks changed things to try to fix something and forgot about this part
[20:59] <robru> cyphermox, seems easy enough to fix then. the only thing is that I don't know how to deploy citrain changes, do you?
[20:59] <bregma> can't you check the bzr history of the citrain source code?
[20:59] <cyphermox> ahahah
[21:00] <cyphermox> bregma: yes, we can
[21:00]  * bregma was waiting for the revelation that citrain was not under source control
[21:00] <cyphermox> ahah
[21:00] <cyphermox> we could deploy citrain via citrain
[21:00] <cyphermox> if only it was in the archive
[21:02] <fginther> cyphermox, it would be nice if stderr was logged in that exception message :-)
[21:03] <asac> citrain is by concept not archive specific. everything needs appropriate pre-merge testing
[21:04] <cyphermox> fginther: indeed
[21:04] <cyphermox> fginther: I assume you can deploy fixes for citrain?
[21:05] <cyphermox> I'll push a few small bugfixes to a branch and ask robru to verify, then we can deploy this?
[21:05] <cyphermox> fginther: if you could run the bzr cat commands on the citrain jenkins box though, I could probably figure out what's up with it
[21:06] <fginther> cyphermox, I can't deploy, IS needs to do that
[21:06] <robru> bah
[21:06] <cyphermox> ah, fun
[21:06] <cyphermox> can you run though?
[21:07] <fginther> cyphermox, robru, let me see what I have access to
[21:08] <fginther> cyphermox, robru, what is https://ci-train.ubuntu.com/job/deploy-citrain/ for?
[21:09] <robru> fginther, well isn't that something
[21:09] <cyphermox> shiny
[21:09] <robru> fginther, the answer to "what is this?" is "something that has only ever been used by Didier"
[21:10] <fginther> robru, but looks like the right rob
[21:10] <robru> fginther, yes indeed, just that I was never told about it ;-)
[21:10] <robru> fginther, so thansk
[21:11] <cyphermox> fginther: in any case, I made my own job to run bzr cat and it seems to work, so not sure what's up
[21:11] <cyphermox> I'll just try one last time and if it still fails, cry
[21:11] <fginther> cyphermox, that is what I was going to try :-(
[21:12]  * cyphermox cries
[21:12] <cyphermox> screw this, on failure we'll output both stdout and stderr
[21:19] <cyphermox> robru: https://code.launchpad.net/~mathieu-tl/cupstream2distro/bugfix-20140404/+merge/214340
[21:19] <robru> cyphermox, lgtm
[21:20] <cyphermox> ok, I'll push to cupsteam2distro naw
[21:21] <fginther> cyphermox, are you able to run that update job?
[21:21] <fginther> err, "deploy-citrain"
[21:21] <cyphermox> I want to think I understand what it does properly before I try
[21:24] <cyphermox> very cool
[21:26] <cyphermox> can I rerun the compiz build (silo 18)?
[21:28] <cyphermox> sergiusens: can you check what's up with debian/changelog?
[21:28] <cyphermox> https://ci-train.ubuntu.com/job/prepare-silo/78/console
[21:28] <cyphermox> I know the changes are supposed to get applied automatically, but there should still be a debian/changelog file
[21:29] <cyphermox> hey wait a second
[21:29] <cyphermox> this actually could rather be the numtium branches
[21:32] <cyphermox> urgh
[21:33] <cyphermox> sergiusens: can you merge the packaging straight into numtium project? we'll just skip messing with this for no reason
[21:33] <robru> cyphermox, yeah, rebuild 18 for sure
[21:33] <cyphermox> ok
[21:33] <sergiusens> cyphermox: sure; that's what I was trying to say :-)
[21:34] <cyphermox> ahah alright :)
[21:36] <cyphermox> robru: we'll know soon enough if everything goes well, but I see my changes got applied for the prepare job
[21:36] <cyphermox> so I think silo 18 will build fine too
[21:37] <sergiusens> cyphermox: done, also update mr list for train
[21:37]  * bregma looks forward to having part of Friday night off
[21:38] <cyphermox> thar, silo 19
[21:38] <cyphermox> bregma: isn't it nearing standard, EST timezone EOD ?
[21:39] <bregma> some of us have no use for standard EOD
[21:39] <cyphermox> ahah yeah
[21:39] <cyphermox> looking forward to going to get some vegan raw food nearby for dinner, since I'm staying in the office until very late tonight :)
[21:47] <cyphermox> robru: silo 18 looks good now, stuff is waiting for the build to complete
[21:47] <cyphermox> so I'll run out now for a bit, back soonish
[22:02] <robru> cyphermox, sweet thanks
[22:02] <robru> bregma, ^
[22:03]  * bregma keeps an eye on things
[22:27] <cyphermox> I'm back
[22:30] <bfiller> robru: would you be able to reconfig silo 9, we need syncevolution uploaded to the ppa from this patch: https://code.launchpad.net/~renatofilho/syncevolution/fix-photo-merge
[22:31] <robru> bfiller, sure
[22:31] <bfiller> robru: great, thanks
[22:32] <robru> bfiller, yeah, just need you to change the source packages cell (G34). it should just be a space-separated list of the source package names, no bullets, no urls
[22:32] <bfiller> robru: ok
[22:32] <robru> bfiller, thanks
[22:33] <bfiller> robru: done
[22:33] <robru> bfiller, ok, it's reconfigured. did you want me to upload the package or can you?
[22:34] <bfiller> robru: if you don't mind would be great
[22:34] <robru> sure
[22:36] <robru> bfiller, ok, it's uploaded, you should see that in a sec
[22:37] <bfiller> thanks robru
[22:37] <robru> bfiller, you're welcome!
[22:51] <bfiller> robru: silo 10 ready for release
[22:52] <robru> bfiller, done!
[22:54] <bfiller> robru: thanks, need a silo for line 41 as well
[22:54] <robru> bfiller, hmmmmm, might have to wait on that 1. we only have 1 left...
[22:54] <bfiller> robru: no rush
[22:55] <bfiller> robru: not critical, next week is fine
[22:55] <robru> bfiller, ok thanks
[23:11] <bregma> robru, I am pleased to announce landing-018 has passed its tests satifactorily and is ready for publish
[23:11]  * bregma starts uncorking the wine bottles
[23:16]  * bregma looks under the dirty dishes in the kitchen sink for an unchipped mason jar to drink from
[23:21] <Chipaca> landing-012 has also just passed it tests satisfactorily and is ready for publish
[23:21]  * Chipaca tips his glass towards bregma hopefully
[23:21]  * bregma pours
[23:21] <robru> bregma, unity publish on friday night? what could go wrong? ;-)
[23:21]  * Chipaca switches out for a bigger glass, in a single fluid motion that spills not a drop
[23:22] <robru> bregma, ok, published ;-)
[23:22]  * bregma thinks Chipaca is a little *too* practiced at this
[23:23] <bregma> thanks robru
[23:23]  * bregma unscrews the cap of the second bottle
[23:23] <Chipaca> bregma: :)
[23:23] <Chipaca> bregma: that'll do, thank you.
[23:24] <Chipaca> robru: sorry, i should've mentioned you by name. can i have a publish of landing-012 ?
[23:24] <Chipaca> wait, the protocol is to mention everybody
[23:24] <Chipaca> drat
[23:25] <robru> Chipaca, yes! (sorry, i missed your message among the celebrations)
[23:25] <Chipaca> i'll get the hang of this someday
[23:25] <Chipaca> >hick<
[23:26] <robru> Chipaca, ok, it's done
[23:27] <Chipaca> robru: thank you!
[23:27] <robru> Chipaca, you're welcome
[23:28] <Chipaca> robru: is there an easy way to know when it's safe to merge-and-clean?
[23:29] <robru> Chipaca, well, the spreadsheet will say so. but if you mean "can we get a push notification when it's safe", not really. it's just polling. usually about an hour.
[23:31] <Chipaca> robru: hmm... would it be very impolite of me to go to bed now, and worry about cleanup in the morning then?
[23:31] <robru> Chipaca, no worries. I can take care of it if it's late for you
[23:32] <Chipaca> not terribly late, but too late to be waiting around for an hour
[23:32] <Chipaca> robru: thank you again, then. i'm off.
[23:32] <robru> Chipaca, haha, get some sleep then. goodnight!
[23:32] <Chipaca> robru: you too!


[18:03] <Eickmeyer> OvenWerks: For edubuntu-installer, I ended up doing a complete rewrite, and I really like it, already submitted to the archive admins for inclusion. We *could* go this route for ubuntustudio-installer, and I could simply create a special handler for the backports PPA. https://code.launchpad.net/~edubuntu-dev/+git/edubuntu-installer
[18:03] <Eickmeyer> It's both a remover and installer all-in-one.
[21:50] <OvenWerks> Eickmeyer: could the backports PPA adition be turned into a package? and therefore perhaps have backports, Ardourlatest, kubuntu backports?
[21:51] <Eickmeyer> OvenWerks: Packages that enable PPAs are considered a no-no in the eyes of the archive admins, so those would have to be special handlers, which wouldn't be too difficult to implement. I already have an idea for how to do it.
[21:54] <Eickmeyer> (BTW, Lunar isn't likely to have an ardour-backports PPA as a whole new version of Ardour isn't likely to release before 23.04 EOLs)
[22:07] <OvenWerks> It would have been a quick solution :)
[22:15] <Eickmeyer> OvenWerks: Right. In an ideal world, new binary packages wouldn't have to go through archive admin approval, but anything that creates a brand new package automatically flags the archive admins and holds the packages. They then look at the contents and see what it does. If it breaches policy, it gets the NACK.
[22:19] <OvenWerks> I have nothing against admin and I figure that is a policy that makes sense
[22:20] <OvenWerks> I can think of ways it could be abused
[22:38] <Eickmeyer> Yeah, those ways are what are trying to be avoided.
[22:40]  * OvenWerks is surprised installer is allowed
[22:41] <Eickmeyer> Installer isn't a package that explicitly installs a PPA, though. It is a package that just happens to have a mechanism that enables a PPA.
[22:42] <Eickmeyer> The user has to give their password to enable it.
[22:42] <OvenWerks> Ah
[22:42] <Eickmeyer> Installing a package that does it via postinst isn't explicitly giving permission to enable the PPA, it's giving permission to install the package. There's a difference.
[22:45] <Eickmeyer> So, here's the question: Do we want to go with my zenity/qapt-based method, or do you want to continue to work on your glade-based method?
[22:45] <Eickmeyer> Just suggesting it so we don't reinvent the wheel.
[22:46] <OvenWerks> If you've done it it's fine
[22:46] <OvenWerks> I haven't started on anything. I am going back to controls.
[22:47] <OvenWerks> I even did some edits today on that. I think I had a bit of a block with it for a while.
[22:48] <Eickmeyer> Ok. I'll make a branch and work on it there. The special handler will just look for a fake package name (probably beginning with "SH-" so it knows what to look for) and enable PPAs from that.
[22:48] <Eickmeyer> Oh good!
[22:48] <OvenWerks> I have it so that PW can run with no interferance but I need to get jack/pulse working agian.
[22:49] <OvenWerks> Anyway, I need to pick up my Yf
[22:49] <Eickmeyer> Ok, have fun!