[08:46] <ogra_> hmm, looks like someone enabled cron again yesterday
[08:47] <ogra_> FYI
  [08:47] <didrocks> ogra_: yeah, seems so. Well we already have one image, so that's ok
[08:47] <popey> we have a bot?
[08:47] <popey> (other than ogra_)
[08:48] <didrocks> we do have ogra's bot
[08:48] <didrocks> which isn't ogra :p
[08:48] <ogra_> yes, it is running in #ogra-test
[08:48] <popey> suh-weet
[08:48] <ogra_> i still have an issue with my daily DSL reconnect ... once thats fixed i'll run it here
[08:49] <ogra_> (adn will add more features .... i.e. changelog URLs with the success msg and promotion messages too)
[08:49] <didrocks> bzoltan: hey, I'll have to do a MP for the toolkit to be unblocked from proposed
[08:49] <didrocks> not sure if Mirv noticed it's stuck ;)
[08:50] <ogra_> oh, what happened to the meeting time ?
[08:50] <didrocks> bzoltan: I have to revert one of balloons's commit which adds a dep on AP
[08:50] <didrocks> ogra_: someone removed it…
[08:50] <didrocks> at canonical
[08:50] <ogra_> yes, and now it is in 10min
[08:50] <didrocks> he isn't in UE nor on IRC
[08:50] <ogra_> (says my notification)
[08:50] <didrocks> ah, I have to repush the new I created
[08:50] <didrocks> let me fix that
[08:50] <bzoltan> didrocks: what was that commit about? But of course OK.
[08:51] <bzoltan> didrocks: Ohh... that one, sure
[08:52] <didrocks> bzoltan: that one: http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/revision/951
[08:52] <didrocks> it adds a dep on python-autopilot
[08:52] <didrocks> which isn't in main
[08:52] <didrocks> and I don't want to block you on the MIRing :)
[08:52] <bzoltan> didrocks: thank you
[08:53] <Mirv> I've been so far busy cleaning up all the 5.2 related stuff I have lying around... lots of it
[08:53] <Mirv> plus starting precise/saucy builds of it
[08:54] <didrocks> bzoltan: mind having a look: https://code.launchpad.net/~didrocks/ubuntu-ui-toolkit/unblock-proposed/+merge/211267
[08:54] <didrocks> Mirv: with sil2100 out do you mind focusing on the landing today?
[08:54] <didrocks> Mirv: I think precise/saucy can wait for now
[08:55] <didrocks> bzoltan: if +1 for you, I'll restack that on the current (stuck) landing)
[08:55] <bzoltan> didrocks: I am good with it
[08:55] <didrocks> great, thanks :)
[08:56] <Mirv> didrocks: for the remaining day, sure. what's the current policy, AP fixes only or other successfully tested landings too?
[08:56] <didrocks> Mirv: yeah, sounds like a good approach
[08:56] <Mirv> didrocks: note the "or"? :)
[08:56] <didrocks> AP fixes only + successfully tested landings (safe)
[08:56] <didrocks> I would say
[08:56] <ogra_> seb128, are you guys doing the tests for system-settings yourself or do i have to contact QA about a change ?
[08:57] <Mirv> ok, thanks
[08:57] <didrocks> Mirv: and unblocking things that are going to be stuck in proposed due to missing new archs
[08:57] <seb128> ogra_, we are doing it, but QA has engaged on some refactoring/improvements for our tests
[08:58] <seb128> see e.g https://code.launchpad.net/~vrruiz/ubuntu-system-settings/autopilot-emulators-helpers/+merge/210861
[08:58] <didrocks> bzoltan: do you have a safe toolkit landing where we can add that MP?
[08:58] <seb128> ogra_, what's the issue?
[08:58] <didrocks> bzoltan: it will unblock a lot of arch deps
[08:58] <ogra_> seb128, it would be nice if the IMEI test wouldnt fail when there is no IMEI (like on tablets)
[08:58] <didrocks> bzoltan: I'm afraid line 18 is risky AP-wise, right?
[08:58] <ogra_> http://ci.ubuntu.com/smokeng/trusty/touch/manta/239:20140317:20140304/7178/ubuntu_system_settings/900882/
[08:59] <bzoltan> didrocks:  yes, there is a reason I did not turn it on yet
[08:59] <ogra_> http://ci.ubuntu.com/smokeng/trusty/touch/flo/239:20140317:20140304/7179/ubuntu_system_settings/901368/
[08:59] <seb128> ogra_, it works on desktop for me?
[08:59] <bzoltan> didrocks: let's find a safe one
[08:59] <ogra_> seb128, well, it fails on both tablet tests
[08:59] <seb128> ogra_, and I've definitively no imei here
[08:59] <didrocks> bzoltan: ok, in case you have nothing else in your luggages, I'll just land that one ;)
[08:59] <ogra_> seb128, but you also dont have the interface to ask for one ... perhaps thats the issue
[08:59] <seb128> ogra_, right, just saying, the "when there is no IMEI" is probably a wrong characterization of the issue
[08:59] <bzoltan> didrocks: that is the safest :)
[08:59] <seb128> ogra_, right, could be
[09:00]  * ogra_ assumes it uses getprop
[09:00] <seb128> ogra_, patches are welcome, I've no access to those devices
[09:00] <seb128> so I can't really debug/test
[09:00] <didrocks> bzoltan: ok, mind if I handle just with that one? (otherwise, everytime we have an app biulding, I have to remove some .debs)
[09:01] <Mirv> bzoltan: FYI regarding Qt 5.2 precise/saucy builds, here's where I'm currently https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta-proper/+packages
[09:01] <bzoltan> Mirv:  Perfect... I would suggest to slow down :) after the QtC dependencies and the QtC is there
[09:02] <bzoltan> didrocks: Yes, I thank you for fixing this
[09:02] <didrocks> bzoltan: great, dealing with it, no worry :)
[09:18]  * ogra_ gets new coffee
[09:30] <seb128> hum
[09:30] <seb128> trusty dist-upgrade failed
[09:30] <seb128> Unpacking libaccounts-qt5-dev (1.11+14.04.20140307-0ubuntu1) over (1.10+13.10.20131016.1-0ubuntu1) ...
[09:30] <seb128> dpkg: error processing archive /var/cache/apt/archives/libaccounts-qt5-dev_1.11+14.04.20140307-0ubuntu1_i386.deb (--unpack):
[09:30] <seb128>  tentative de remplacement de « /usr/lib/i386-linux-gnu/cmake/AccountsQt/AccountsQtConfig.cmake », qui appartient aussi au paquet libaccounts-qt-dev 1.11+14.04.20140307-0ubuntu1
[09:30] <seb128> Mirv, ^ known?
[09:30]  * seb128 removes libaccounts-qt-dev
[09:30] <ogra_> didrocks, hmm, the hangout link is gone from the reminder
[09:30] <seb128> oh, another one
[09:30] <seb128> dpkg: error processing archive /var/cache/apt/archives/qtcreator-plugin-cmake_3.0.1-0ubuntu5_i386.deb (--unpack):
[09:30] <seb128>  tentative de remplacement de « /usr/lib/i386-linux-gnu/qtcreator/plugins/QtProject/CMakeProjectManager.pluginspec », qui appartient aussi au paquet qtcreator 2.8.1-0ubuntu1
[09:30] <tvoss> good morning
[09:30] <tvoss> didrocks, can I get a silo for line 54?
[09:30] <didrocks> ogra_: I don't get a reminder
[09:30] <ogra_> oh ?
[09:31] <didrocks> tvoss: can you ping all EU people please? :p
[09:31]  * ogra_ always gets mail
[09:31] <didrocks> ogra_: look at the calendar, you should have it
[09:31] <ogra_> sigh
[09:31] <didrocks> Mirv: look at tvoss request, please?
[09:31] <psivaa_> didrocks: ogra_: the entry has been removed from my calendar as well
[09:31] <ogra_> that means i have to have a calendar open for it :/
[09:31] <didrocks> psivaa_: right, but you should have received a request
[09:31] <didrocks> psivaa_: someone removed the old one…
[09:32] <ogra_> and the old HO link doesnt work :(
[09:32] <psivaa_> didrocks: ok, looking for the new invite
[09:32] <didrocks> ogra_: hum, we are 5 in it
[09:32] <ogra_> yes
[09:32] <didrocks> psivaa_: did you find it?
[09:33] <ogra_> from the calendar it works (and has a name etc)
[09:33] <ogra_> but thats really annoying
[09:33] <psivaa_> didrocks: not yet. could i have the link just for today pls
[09:33] <didrocks> sure
[09:33] <ogra_> https://plus.google.com/hangouts/_/canonical.com/landing-meeting
[09:33] <didrocks> https://plus.google.com/hangouts/_/canonical.com/landing-meeting
[09:33] <Mirv> didrocks: tvoss: looking after the meeting or so
[09:37] <Mirv> tvoss: landing-017
[09:37] <tvoss> Mirv, thank you
[09:40] <davmor2> didrocks: https://bugs.launchpad.net/unity-mir/+bug/1290416
[09:41] <popey> ogra_: what installs /system/bin/netmgrd ? i.e. where should I file bugs in it?
[09:41] <ogra_> popey, the android package
[09:41] <ogra_> all of /system is owned by it
[09:41] <popey> which lp project is that?
[09:42] <popey> if i "ubuntu-bug" will it get relavent data?
[09:42] <ogra_> ubuntu
[09:42] <ogra_> well, it isnt "installed" as a deb
[09:42] <popey> ok, i just want to file a bug ☻
[09:43] <popey> https://launchpad.net/ubuntu/+source/android/+bugs ?
[09:43] <ogra_> and i dont think it will collect any specific data ... you want /system/bin/logcat -d, syslog and kern.log (or dmesg)
[09:43] <ogra_> yep
[09:43] <popey> magic, thanks
[09:48] <popey> bug 1293459
[09:54] <ogra_> geez, how big is that kern.log
[10:01] <popey> didrocks: sorry, doorbell, new microwave arrived. ☻
[10:01] <didrocks> popey: ahah, I see priorities! :) no worry, nothing special :p
[10:01] <Mirv> didrocks: there'd be a packaging ack (AP run ok) http://<IP_ADDRESS>/job/landing-011-2-publish/lastSuccessfulBuild/artifact/packaging_changes_address-book-service_0.1.1+14.04.20140314.4-0ubuntu1.diff
[10:02] <ogra_> btw in case someone is interested http://people.canonical.com/~ogra/touch-bootcharts/
[10:02] <popey> yeah, food > phones
[10:02] <didrocks> Mirv: have you rerun the calendar app tests? (as they are impacted)
[10:02] <ogra_> once the bot is fully active i will let it generate these automatically
[10:02] <didrocks> ogra_: oh nice!
[10:02] <ogra_> and i also think i can now add symlinks to the changelogs
[10:02] <Mirv> didrocks: no, not calendar app. calendar uses address book somehow?
[10:03] <didrocks> Mirv: sorry, messaging-app
[10:03] <ogra_> so that you can click on the right image id instead of having to look up the cdimage version first
[10:03] <didrocks> Mirv: other +1 on the change
[10:03] <didrocks> great :)
[10:03] <davmor2> ogra_: pretty consistent then at just over a minute :)
[10:04] <Mirv> didrocks: not messaging app yet, running now.
[10:04] <ogra_> davmor2, huh ?
[10:04] <davmor2> ogra_: the bootcharts
[10:04] <ogra_> davmor2, unity8 is starting after 20sec ...
[10:04] <ogra_> once the indicators are up you have the UI on screen
[10:04] <popey> davmor2: where to file the volume button bug ‽
[10:04] <ogra_> bootchart is looking for X11 mapping, so dont trust the overall time there ;)
[10:05] <davmor2> ogra_: hahah
[10:05] <ogra_> its about 30sec
[10:05] <davmor2> popey: I have no idea
[10:05] <davmor2> ogra_, didrocks^^ where to file the volume key issues
[10:05] <ogra_> the first boot is about 1min
[10:05] <ogra_> davmor2, no idea, either Mir, unity-mir or android
[10:05]  * popey picks one
[10:06] <didrocks> yeah, put it on Mir + android
[10:06] <didrocks> I would say
[10:06] <popey> kk
[10:06] <davmor2> right I'm off shopping
[10:07] <popey> https://bugs.launchpad.net/ubuntu/+source/android/+bug/1293478
[10:07] <tvoss> Mirv, seems like no packages are arriving in https://launchpad.net/~ci-train-ppa-service/+archive/landing-017
[10:09] <Mirv> tvoss: sorry, I've been so much tied with the 5.2 my CI Train service might not be completely hitch free :) I've understood it's the lander's job to kick the 'build' job after a silo has been assigned?
[10:09] <tvoss> Mirv, ah ... didn't know
[10:09] <tvoss> Mirv, done
[10:10] <Mirv> tvoss: ok. not seeing at http://<IP_ADDRESS>/job/landing-017-1-build/ though.
[10:10] <tvoss> Mirv, try a refresh :)
[10:10] <Mirv> works :)
[10:17] <psivaa_> didrocks: contrary to what i said in the meeting, the calendar_app failure is not flaky, the same failures are reproduced in the next run too :/
[10:17] <didrocks> psivaa_: oh, ok, well… good news in some way :)
[10:18] <psivaa_> didrocks: yea, ack :)
[10:18] <didrocks> maybe we should summon elopio for those
[10:20] <didrocks> Mirv: ok, so it seems we nede to dig why qtdeclarative5-unity-action-plugin isn't available
[10:20] <didrocks> as it's blocking the sdk
[10:20] <didrocks> and so multiple other archs
[10:20] <didrocks> and your recent publications are going to be blocked because of that as well
[10:21] <didrocks> it's Architecture: any
[10:21] <didrocks> ah, didn't built because of libhud2-dev
[10:22] <didrocks> which is arch: any
[10:22] <didrocks> failed on arm64
[10:22] <didrocks> some tests
[10:22] <didrocks> and dep dee-qt
[10:29] <Mirv> yeah I saw on #ubuntu-release that colin had tried to stab dee-qt but did not succeed, and Dimitri was encouraged to do the same
[10:34] <didrocks> I'm afraid as well at the hud not passing tests on arm64
[10:38] <popey> psivaa_: bug 1293489 for the record
[10:38] <popey> also bug 1293488
[10:38] <psivaa_> popey: ack, thanks
[10:46] <cjwatson> 13:34 <cjwatson> Trying to debug the dee-qt build on ppc64el is making me hallucinate
[10:46] <cjwatson> 13:34 <cjwatson> 62              connect(&model_qt, &QAbstractItemModel::rowsInserted, [&num_insertions] (const QModelIndex &parent, int start, int end) {
[10:46] <cjwatson> 13:34 <cjwatson> 63                  num_insertions++;
[10:47] <cjwatson> 13:34 <cjwatson> 64              });
[10:47] <cjwatson> 13:34 <cjwatson> step into that and I get:
[10:47] <cjwatson> 13:34 <cjwatson> (gdb) p signal
[10:47] <cjwatson> 13:34 <cjwatson> $5 = (void (QAbstractItemModel::*)(QAbstractItemModel * const, const QModelIndex &, int, int, QAbstractItemModel::QPrivateSignal)) 0x10016bf0 <QMapDataBase::createData()@plt+64>
[10:47] <cjwatson> 13:35 <cjwatson> where on earth did it get that function from?
[10:47] <cjwatson> 13:35 <cjwatson> powerpc has the same test failure; and there's actually not *that* much similar between powerpc and ppc64el, they're different word length and different endianness
[10:47] <cjwatson> that was my last brain-dump on dee-qt
[10:47] <cjwatson> it's easy to reproduce on porter-ppc64el.canonical.com
[10:48] <cjwatson> it looks like it's the caller's fault (i.e. disassembling the caller it does seem to be loading the wrong function pointer), but I lack the expertise to work out why
[10:48] <didrocks> tsdgeos: as you are on that one as well ^
[10:48] <didrocks> and mhr3 ^
[10:49] <tsdgeos> well i'm still trying to login into the machine :D
[10:51] <didrocks> cjwatson: hey, I'm not sure I'll put the right informations for the framework names on ubuntu-touch metapackage btw, are you doing so or should I just copy the existing entries you added? (then, we have to wait on jdstrand + click store side)
[10:52] <cjwatson> didrocks: I'll do it
[10:52] <didrocks> cjwatson: thanks
[10:52] <cjwatson> didrocks: I assume I need to leave ubuntu-sdk-14.04-dev1 in place for compatibility?
[10:52] <didrocks> cjwatson: yeah, and I propose that we remove it in a week
[10:53] <cjwatson> *shrug* no rush
[10:53] <didrocks> cjwatson: just wanted to clean as soon as possible as it was the deal
[10:54] <cjwatson> it doesn't matter
[10:54] <didrocks> (just updated the seed for the icon theme change btw, I'll let you regenerate the metapackage in the next upload)
[10:56]  * davmor2 fires manta to test the volume buttons
[10:56] <davmor2> Morning all
[10:56] <didrocks> hey davmor2
[11:05] <tsdgeos> cjwatson: seen my query?
[11:06] <cjwatson> Queries light up just as red as channel highlights :)
[11:08] <davmor2> popey: can you have another look at this https://bugs.launchpad.net/indicator-sound/+bug/1283191 I can confirm the volume indicator moves but if you move the slider to %50 and then press the vol up button the indicator increase as does the volume but the slider remains at %50
[11:08] <didrocks> davmor2: ah, so the volume is changing, but not the indicators?
[11:09] <davmor2> didrocks: no that is a separate issue altogether
[11:09] <popey> davmor2: nope, the indicator never moves for me
[11:09] <davmor2> didrocks: this it that the slider seems to be independant of the volume keys and indicator display
[11:14] <davmor2> didrocks: I added additional steps to the bug that should I hope make it clearer
[11:14] <didrocks> davmor2: sweet, thanks!
[11:15] <didrocks> seb128: do you think anyway from the indicator team can have a look? Seems like it can have been impacted by the desktop only changes
[11:15] <davmor2> didrocks: but again a separate thing balloons was seeing it in 208
[11:15] <didrocks> yeah
[11:15] <seb128> didrocks, what?
[11:15] <didrocks> seb128: https://bugs.launchpad.net/indicator-sound/+bug/1283191
[11:16] <seb128> didrocks, that's almost a month old, what desktop only changes? :p
[11:16] <didrocks> seb128: hum, that wasn't at the same time than the trigger > 100%?
[11:17]  * didrocks looks back at history
[11:17] <seb128> didrocks, it was
[11:17] <seb128> didrocks, but looking at http://launchpadlibrarian.net/167019111/indicator-sound_12.10.2%2B14.04.20140207-0ubuntu1_12.10.2%2B14.04.20140220-0ubuntu1.diff.gz I doubt that's it
[11:17] <seb128> well I guess we can check
[11:17] <didrocks> seb128: yeah, the date matches perfectly, but it seems really unlikely
[11:18] <didrocks> might worth a check if possible :)
[11:18] <seb128> yeah, I'm going to check
[11:18] <didrocks> thanks!
[11:18] <didrocks> seb128: just be aware there is another bug in latest images
[11:18] <seb128> didrocks, note that popey said it was working on image 206 on mako for him
[11:18] <didrocks> seb128: that keys are not working on touch
[11:18] <seb128> how do I test then?
[11:18] <didrocks> so better to go back to previous promoted one
[11:19] <seb128> shrug, ok
[11:19] <didrocks> seb128: yeah, seems multiple people have different pass/fail :/
[11:19] <didrocks> (didn't try myself TBH)
[11:19] <seb128> I really doubt it's indicator-sound's fault for the record
[11:19] <seb128> but let's see
[11:19] <popey> sound indicator works with 237
[11:19] <didrocks> thanks
[11:19] <didrocks> hum
[11:19] <didrocks> dave told the contrary
[11:19]  * didrocks is puzzled
[11:20] <didrocks> so, davmor2 before we all loose time on that, you told they were 2 bugs
[11:20] <popey> i have a #237 phone in front of me, and i can adjust the sound indicator using the hardware volume buttons
[11:20] <didrocks> one on indicator
[11:20] <didrocks> one on hw button
[11:21] <didrocks> ok
[11:21] <didrocks> so let's focus on the hardware button issues first
[11:21] <didrocks> and we'll see for the potential second issue next
[11:21] <didrocks> once the first is fixed
[11:22] <seb128> didrocks, my device is on r231 and using the hardware keys make the indicator change
[11:22] <davmor2> didrocks: Yes 2 bugs,  One is the slider in the indicator not moving when the hardware buttons change the volume the actual indicator shows the change, the other is that the volume down button doesn't work on mako and manta and according to ogra_ neither work on flo
[11:22] <seb128> no notification/sound player though, which makes it non obvious they are doing something
[11:23] <ogra_> davmor2, well, vol up seems to work with the little speaker icon ...
[11:23] <seb128> I just tested
[11:23] <didrocks> davmor2: where is the second bug report already?
[11:23] <ogra_> did only notice that now ... i was looking at the slider
[11:23] <seb128> open the sound indicator
[11:23] <seb128> use the hardware keys
[11:23] <seb128> it moves
[11:23] <seb128> (n4)
[11:24] <popey> yeah, it broken between 237 and 238 it seems
[11:24] <ogra_> davmor2, i think i'm seeing the same
[11:25] <davmor2> seb128: open the indicator, slide the slider to 50%, close the indicator, press the volume up button then drag the indicator back down and see what the slider is on
[11:25] <seb128> davmor2, it's updated for me
[11:26] <seb128> the icon in the panel is changing as well
[11:26] <seb128> but I'm r231 (e.g no current)
[11:26] <popey> i can reproduce that on 237
[11:26] <seb128> popey said 238 has the issue
[11:26] <seb128> or 237
[11:26] <popey> there are two issues here.
[11:26] <popey> (at least)
[11:26] <seb128> did it start on  237 ?
[11:26] <davmor2> indeed
[11:26] <seb128> what changed in that image,
[11:26] <seb128> ?
[11:26] <davmor2> ogra_: ^
[11:27] <popey> well in 237 with the procedure davmor2 just gave I have got the volume slider in the indicator stuck, but it worked fine a few moments ago
[11:27]  * popey reboots to try again
[11:27] <seb128> if you open the indicator and use the hardware buttons, is the slider moving?
[11:27] <popey> it was
[11:27] <popey> but after moving the slider to 50% it no longer does
[11:28] <seb128> ok, there is a bug confirmed
[11:28] <popey> (on 237)
[11:28] <davmor2> \o/
[11:28] <ogra_> i had the issue on 237 here
[11:28] <seb128> if you move the slider manually yes
[11:28] <seb128> I bet it's again a qml issue
[11:29] <seb128> the slider is bind to the sound property
[11:31] <seb128> but if you move it manually qml unset the binding and doesn't restore them
[11:32] <davmor2> didrocks: yes so 2 issues :)
[11:32] <didrocks> davmor2: so, we do have bug #1283191
[11:32] <didrocks> which isn't new
[11:32] <popey> yes
[11:32] <didrocks> the other "new" one is?
[11:33] <didrocks> (with 5.2)
[11:33] <davmor2> didrocks: yes and the new one is 52 only and is https://bugs.launchpad.net/ubuntu/+source/android/+bug/1293478
[11:33] <didrocks> excellent, thanks
[11:36] <dbarth> hiya, is it normal if i have the CI train in read-only mode?
[11:36] <dbarth> or can someone edit/re-config an MP list for me?
[11:38] <mhr3> tsdgeos, looks like some template magic brokeness on those platforms
[11:38] <mhr3> tsdgeos, not sure if you managed to figure out something
[11:38] <tsdgeos> no
[11:39] <tsdgeos> i'm still trying to figure out what to do after i log into the porter machine :D
[11:39] <tsdgeos> i tried creating a chroot but as i have no root nor fakeroot can't do that
[11:40] <mhr3> yea, i didn't even try porters, last time i checked i didn't have access to them :)
[11:41] <tsdgeos> i asked for it
[11:41] <tsdgeos> and got it
[11:41] <tsdgeos> btu not sure what to do next :D
[11:41] <mhr3> and that's why i didn't ask for the access :)
[11:44] <mhr3> didrocks, ok to publish row 45? or are we still in no-publish mode?
[11:45] <cjwatson> I've given tsdgeos advice by /msg
[11:45] <didrocks> mhr3: those looks fine & safe enough for me
[11:45] <didrocks> Mirv: mind looking in case of packaging changes and so on ^
[11:47] <cjwatson> didrocks: http://paste.ubuntu.com/7107703/
[11:47] <cjwatson> uploaded
[11:48] <didrocks> cjwatson: perfect, thanks!
[11:48] <didrocks> now, let's wait for jdstrand to update the click apparmor side
[11:49] <didrocks> mhr3: with pete on holidays, only tedg will be able to fix a test failure on arm64 for the hud, I guess?
[11:49] <cjwatson> arm64 porter boxes are a bit trickier, since the arm64 kit we have isn't IS-managed yet
[11:50] <cjwatson> But if somebody needs it, ask me and I can point you in the right direction
[11:51] <mhr3> didrocks, sounds about right
[11:51] <dbarth> didrocks: ping? sorry can you help with that read-only issue?
[11:51] <mhr3> didrocks, well.. marcus might be able to too
[11:51] <didrocks> dbarth: "that read-only issue"?
[11:51] <Mirv> mhr3: didrocks: ok will look
[11:51] <dbarth> ci-train spreadsheet is r-o for me
[11:52] <didrocks> dbarth: nothing changed, are you sure you are logged in with the right acount?
[11:52] <didrocks> account*
[11:52] <didrocks> cjwatson: it was the hud issue, Mirv told it built here, so great :)
[11:52] <dbarth> doh, was logged out :/ sorry
[11:54] <cjwatson> didrocks: "the hud issue" not sure what that means, but if it's fixed then marvellous
[11:55] <didrocks> cjwatson: yeah, in addition to dep on this dee-qt, there were some test failure on arm64
[11:55] <cjwatson> ah, caught up on #ubuntu-devel
[11:55] <cjwatson> yeah, I know
[11:56] <Mirv> yes, tests passed in the version for arm64 which is nice https://launchpadlibrarian.net/169517619/buildlog_ubuntu-trusty-arm64.hud_13.10.1%2B14.04.20140314-0ubuntu1_UPLOADING.txt.gz
[11:56] <Mirv> mhr3: mediascanner2 published
[11:56] <didrocks> yeah, I just hope it's not flaky
[11:57] <didrocks> anyway, so dee-qt is the biggest offender remaining to have a clearer view on the archive
[11:58] <davmor2> didrocks: so I guess stabilising 5.2 and then what is the next big thing new scopes?
[11:58] <Mirv> mhr3: oh, and you were also the lander for line 26 hud/libdbusmenu-qt. also done, after I did some extra testing myself.
[11:59] <Mirv> davmor2: oxide?
[11:59] <didrocks> davmor2: yeah, the icon theme change should be minor, so it's building/landing as wel speak
[11:59] <davmor2> Mirv: ohhhhh oxide would be nice :)
[11:59] <didrocks> the risky transitions happening are, AFAIK:
[11:59] <didrocks> - scopes
[11:59] <didrocks> - oxyde
[11:59] <didrocks> - python3 AP switch
[11:59] <ogra_> isnt the latter done yet ?
[12:00] <didrocks> ogra_: not enabled yet
[12:00] <ogra_> ah, k
[12:00] <didrocks> at least, it's easy to disable
[12:00] <didrocks> and don't even need an image rebuild
[12:00] <ogra_> yeah, i was kind f assuming that xnox had ripped py2 AP out already :)
[12:01] <mhr3> Mirv, thx
[12:01] <didrocks> heh, not yet! I think we can get that (if ready) as soon as we promote the first 5.2 image
[12:01] <ogra_> hmm, sad ... so the unity-system-compositor spinner works ... but only if i start it manually
[12:01] <ogra_> seems mterry forgot to add the --spinner option in his code ...
[12:02] <ogra_> but at least it works stable and the session comes up fine
[12:02] <didrocks> ogra_: maybe that was on purpose? he wanted more testing before enabling it
[12:02] <ogra_> (it should use the spinner graphics from recovery though :P )
[12:02] <ogra_> didrocks, well, his MP description talks about a --spinner option ... but there is none in the code
[12:02] <didrocks> ah :)
[12:03] <didrocks> so fail yeah ;)
[12:03] <ogra_> i guess just an oversight
[12:03] <ogra_> and it works stable on all devices, so shouldnt be an issue to add it
[12:16]  * cjwatson files RT#68468 to spruce up our porter box setup a bit
[12:22] <seb128> didrocks, davmor2, popey: https://bugs.launchpad.net/unity8/+bug/1283191 reassigned to unity8/retitled
[12:22] <didrocks> seb128: ah, great, thanks! :)
[12:22] <popey> thanks seb128
[12:22] <seb128> Saviq, ^ let me know if we are wrong, but that seems an issue on the qml side
[12:23] <davmor2> seb128: thanks for looking into it :)
[12:23] <Laney> seb128: hmm? That was about the hardware buttons but you changed it to be about interacting with the qml sliders?
[12:23] <seb128> yw!
[12:23] <seb128> Laney, it's about the slider which stops moving to reflect the actual value
[12:23] <seb128> Laney, it seems the classic "qml undo the property binding if you manually interact with the widget"
[12:24] <Laney> but you aren't manually interacting with the widget if you press the buttons
[12:24] <seb128> Laney, read the steps in the description
[12:24] <seb128> it starts with "set the slider to 50%"
[12:24] <seb128> it's the only way I could confirm it as well
[12:24] <Laney> what's the first lot of steps?
[12:25] <seb128> the description is buggy
[12:25] <Saviq> dednick, can you please evaluate bug #1283191 ?
[12:25] <davmor2> Laney: just read the second set, the first set were how balloons saw it the second were how I reproduced it and because the hardware buttons aren't currently working correctly
[12:26] <seb128> Laney, let me update it, it turned out to be "that happens only if you moved the slider manually"
[12:26] <dednick> Saviq:sure
[12:26] <Laney> For me the hardware buttons do nothing at all
[12:26] <Laney> maybe they are just broken
[12:26] <seb128> Laney, they do, look at the icon in the panel
[12:26] <Laney> I am looking at that
[12:26] <seb128> weird
[12:26] <davmor2> Laney: vol up works just vol down that shouldn't
[12:27] <seb128> Laney, seems like there is a regression in the hardware keys
[12:27] <Laney> oh right yes
[12:27] <davmor2> Laney: that's if you are on 139
[12:27] <Laney> up does work
[12:27] <seb128> Laney, but test with power otherwise, and the settings panel
[12:27] <seb128> if you change the screen settings the indicator update
[12:27] <Laney> that is two bugs then
[12:27] <seb128> if you use the indicator slider once, it stops updating
[12:27] <seb128> right
[12:27] <davmor2> Laney: hence moving the slider to 50% to test that vol up was working for me and spotting the issue with the slider :)
[12:28] <davmor2> Laney: indeed https://bugs.launchpad.net/unity8/+bug/1283191 is the slider and https://bugs.launchpad.net/ubuntu/+source/android/+bug/1293478 is the hardware one
[12:29] <Laney> yeah it's more complex than up working, because now it doesn't :P
[12:29] <Laney> oh well
[12:29] <Laney> ta
[12:30] <davmor2> Laney: it won't go up if it is at maximum ;)  and then you can only make it go down from the slider
[12:30] <davmor2> seb128: is there a plan for a mute/silence option in the sound indicator do you know?
[12:30] <seb128> dednick, don't get confused by the description, you can easily reproduce on the desktop, it's basically "open indicator, move slider, change sound from somewhere else, note how the slider doesn't reflect the change"
[12:31] <seb128> davmor2, I don't know, it's not in the design afaik, check with mpt ;-)
[12:31] <Laney> let's fix the description
[12:31] <dednick> seb128: ok. thanks
[12:31]  * Laney does
[12:31] <seb128> Laney, thanks
[12:34] <davmor2> seb128: thanks
[12:36] <Laney> there we go
[12:48] <sergiusens> popey, can you give https://myapps.developer.ubuntu.com/dev/click-apps/507/ a go; if it just launches; it's already a candidate for approval; bonus points for 'fetching the tests'; ridiculous points for running them
[12:48] <popey> sergiusens: hah, okay
[12:50]  * popey runs tests
[12:53] <tsdgeos> didrocks: found it (well actually i was pointed to it by qt people :D)
[12:54] <cjwatson> tsdgeos: yay
[12:54] <tsdgeos> didrocks: ld is broken (or qt is buggy)
[12:54] <tsdgeos> http://lists.linaro.org/pipermail/linaro-toolchain/2014-January/003942.html
[12:54] <tsdgeos> basically we need to recompile qt without -Bsymbolic-functions
[12:54] <cjwatson> Definitely qt, and not dee-qt?
[12:55] <tsdgeos> which i achieved by passing -no-reduce-relocations to qt ./configure
[12:55] <tsdgeos> cjwatson: yes
[12:55] <tsdgeos> i guess we only want that -no-reduce-relocations on broken stuff
[12:55] <cjwatson> I would expect some performance hit from dropping -Bsymbolic-functions :-/
[12:55] <cjwatson> Especially on a big C++ library like Qt
[12:56] <didrocks> yeah, that's going to be tricky
[12:56] <tsdgeos> i guess
[12:56] <cjwatson> And the ld patches linked in that thread are for ARM, not POWER
[12:56] <tsdgeos> cjwatson: it is triggered by the code that compares functiosn by pointers in connect calls
[12:56] <cjwatson> Have you tried the -pie -fPIE suggestion there?
[12:56] <tsdgeos> we don't use that much, so that's why dee-qt triggers it
[12:57] <tsdgeos> cjwatson: i'm not pointing you at the patches, i'm pointing you at another thread that discusses the same problem
[12:57] <tsdgeos> no i have not
[12:57] <tsdgeos> lunch
[12:57] <cjwatson> Presumably we could avoid it by using the old SIGNAL() thing, but that's not ideal
[12:58] <didrocks> I wonder why we don't see the same issue on armhf
[12:58] <cjwatson> Maybe our binutils is fixed
[12:58] <cjwatson> Oh hey look
[12:59] <cjwatson> export DEB_CXXFLAGS_MAINT_APPEND := -fPIE
[12:59] <cjwatson> export DEB_LDFLAGS_MAINT_APPEND := -pie -fPIE
[12:59] <cjwatson> fixes it
[12:59] <didrocks> cjwatson: on dee-qt?
[12:59] <cjwatson> Yeah, dee-qt/ppc64el
[12:59] <didrocks> excellent
[12:59] <cjwatson> Maybe DEB_BUILD_MAINT_OPTIONS=hardening=+pie would be a neater approach
[13:01] <didrocks> cjwatson: as you prefer, mind proposing a fix as you tested it? We can get that landing soon and then proceed the necessary rebuilds
[13:01] <davmor2> didrocks: I'm taking it we don't need the qt5.2 landing meeting anymore right?
[13:01] <didrocks> davmor2: please come
[13:03] <Mirv> oh, that
[13:04] <didrocks> elopio: coming?
[13:08] <popey> sergiusens: Ran 31 tests in 695.607s
[13:08] <popey> OK
[13:09] <sergiusens> popey, excellent
[13:09] <sergiusens> didrocks, rsalveti gellery should be synced in soon
[13:09] <didrocks> sweet \o/
[13:10] <cjwatson> didrocks: ok
[13:10] <rsalveti> sergiusens: great, what was the issue?
[13:10] <cjwatson> it may need the same fix copied-and-pasted elsewhere too, but I guess we'll see
[13:10] <sergiusens> rsalveti, some change in the admin protal for the store; seems it was created with multiple frameworks and got busted
[13:11] <didrocks> cjwatson: agreed
[13:14] <dednick> Saviq: https://code.launchpad.net/~nick-dedekind/unity8/lp1283191/+merge/211307
[13:14] <Saviq> dednick, yup, saw that, thanks!
[13:14] <cjwatson> didrocks: https://code.launchpad.net/~cjwatson/dee-qt/powerpc-pie/+merge/211308
[13:15] <didrocks> cjwatson: landing that one myself
[13:15] <cjwatson> Thanks
[13:15] <didrocks> thanks to you :)
[13:15] <cjwatson> Well, mostly tsdgeos ...
[13:15] <didrocks> and right tsdgeos ;)
[13:15] <cjwatson> Since I'd previously given up :)
[13:16] <jdstrand> didrocks (and cjwatson): fyi, click-apparmor should not have to be updated for the ubuntu-touch-meta change
[13:16] <didrocks> jdstrand: ok, nothing needed on your side, excellent!
[13:17] <jdstrand> for this one, no (it was already expecting those frameworks)
[13:18] <jdstrand> it is good to ask though (and I would encourage you to do so in the future)
[13:18] <didrocks> Mirv: you didn't tag the dee-qt you pushed manually
[13:18] <didrocks> Mirv: please ensure you tag what you push
[13:29] <davmor2> asac: https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1288876
[13:34] <seb128> didrocks, I noticed how you assign yourself slots and just ignore my desktop landing which was already there :p
[13:35] <didrocks> seb128: I'm trying to unblock the screw situation, Mirv and other landers should be able for other landing requests :)
[13:35] <seb128> k ;-)
[13:36] <boiko> didrocks: hi, how long should I wait for a package to migrate from trusty-proposed to trusty before starting to be worried about it?
[13:36] <didrocks> boiko: a couple of hours normally
[13:36] <cjwatson> boiko: which package?
[13:36] <cjwatson> You should look at the reports rather than passively waiting :)
[13:36] <seb128> boiko, https://wiki.ubuntu.com/ProposedMigration
[13:36] <boiko> cjwatson: didrocks: address-book-app
[13:37] <cjwatson> Right, that's blocked on dee-qt + hud (ultimately)
[13:37] <cjwatson> Which should be sorted soonish
[13:38] <cjwatson> I wonder if address-book-service needs the same hack as dee-qt
[13:38] <kgunn> mornin', i'm silo-cked on platform-api, but i'd like to get a silo to build anyway ?
[13:38] <kgunn> no sil around... didrocks or Mirv ?
[13:39] <kgunn> actually...just talked to sergio he says they're stuck, and silo4 can be freed up
[13:39] <Mirv> didrocks: thanks for noting
[13:40] <didrocks> kgunn: is this for the Mir lockup?
[13:40] <didrocks> or unity-mir one rather?
[13:40]  * kgunn feels something happened while he slept
[13:40] <kgunn> didrocks: this is for a new mir
[13:40] <Mirv> seb128: you're talking about unity-control-center line 56?
[13:41] <didrocks> kgunn: it's a bug that was supposed to be fixed with previous Mir (but doesn't seem to be though): bug #1290416
[13:41] <seb128> Mirv, yes ;-)
[13:41] <Mirv> kgunn: I think it'd be easiest if sergiusens could test the landing line 28 to unblock platform-api, as it has built already
[13:42] <Mirv> kgunn: or in other case agreeing to let that silo go for now
[13:42] <sergiusens> Mirv, nah, rsalveti won't budge ;-)
[13:42] <sergiusens> let it go if he needs it
[13:42] <Mirv> sergiusens: ok, thanks
[13:42] <Mirv> kgunn: just wait, I've queue :)
[13:42] <kgunn> Mirv: thank you sir!
[13:42] <kgunn> didrocks: ack on the bug...let me catch up on it, and i'll get someone chasing it
[13:43] <kgunn> i know we landed a fix for what we thot it was (null app surfaces for screen shots)
[13:43] <kgunn> but...it would seem this may be something elst
[13:43] <kgunn> or else even
[13:44] <didrocks> kgunn: ok, can you just get that into the Mir landing?
[13:44] <seb128> Mirv, thanks
[13:44] <didrocks> kgunn: I don't think we should do more landing in the current ones
[13:45] <Mirv> seb128: landing-018 for unity-control-center
[13:46] <kgunn> didrocks: per the bug report, this has been debugged to be unity-mir...not mir
[13:46] <kgunn> i don't think its good to block mir on a unity-mir bug
[13:47] <seb128> Mirv, I saw, thanks!
[13:47] <didrocks> kgunn: well, right now, we can't promote any image QT 5.2 because of that + other issues, so unsure to get a new Mir in addition to that
[13:48] <didrocks> kgunn: do you have fixes which justifies taking that changes?
[13:48] <cjwatson> didrocks: https://code.launchpad.net/~cjwatson/address-book-service/powerpc-pie/+merge/211319 too
[13:48] <kgunn> didrocks: the mir change is relatively small...also it has a critical fix for bregma for unity8 desktop preview
[13:48] <didrocks> boiko: mind adding that to your landing? ^
[13:49] <Mirv> kgunn: didrocks: well, anyhow, Mir has now landing-019 while the vibration platform-api/usensord change was postponed
[13:49] <boiko> didrocks: you mean to the existing one? or in the next one?
[13:49] <didrocks> kgunn: are you really really sure that your testing capacity will not result into additional regressions or screen freeze?
[13:49] <didrocks> boiko: existing one + rebuild
[13:49] <kgunn> Mirv: thanks...i'll at least do my little silo build dance :)
[13:49]  * bregma is getting prepared to be excited
[13:49] <didrocks> boiko: you should be able to self-reconfigure
[13:50] <kgunn> didrocks: are you asking am i going to test it enough ?
[13:50] <boiko> didrocks: yep, let me do that
[13:50]  * kgunn offended, considering he's the one that found the regression last build attempted and pulled back
[13:51] <didrocks> kgunn: it's more like do you think you will have enough time? The screen locking issues happen after hours it seems
[13:51] <boiko> didrocks: can I just add it, or should I go through the whole reviewing process for that MR? I can't test it though
[13:51] <kgunn> didrocks: are you conflating something ?....the fix for bregma is on dual screen startup ?
[13:52] <didrocks> boiko: that one is +1 from me, let me confirm
[13:52] <didrocks> boiko: done
[13:52] <bregma> kgunn, the fix for bregma is a crash on longin, regadless of how many screens are attached
[13:52] <boiko> didrocks: thanks
[13:52] <didrocks> kgunn: no, I just want that we don't make the issue aggravieting and blocking the Qt 5.2 promotion longer
[13:53] <didrocks> kgunn: and then the potential unity-mir fix being blocked on that landing
[13:53] <kgunn> didrocks: ack...let's do the build/testing, then make decisions
[13:53] <didrocks> kgunn: ok
[14:00] <rsalveti> sergiusens: didrocks: can't we also create tests for the sound indicator? just wondering if we could simulate the volume up/down issue with autopilot somehow
[14:00] <rsalveti> it'd be nice if we could add the test and fix the issue, so we avoid hitting the same regression in the future
[14:01] <didrocks> rsalveti: that would be a question for QA, but yeah, it's something needed
[14:01] <sergiusens> rsalveti, perhaps can be simulated with python-evdev? I'd ask elopio for the testing help though
[14:02] <rsalveti> sergiusens: right, but I don't want you to do it :-)
[14:02] <sergiusens> rsalveti, didrocks btw; seems the latest gallery is already synced; do we want a build?
[14:02] <sergiusens> rsalveti, don't worry, I don't want to do it :-)
[14:02] <kalikiana> can this bug get some attention? I rely on this and it's fundamentally broken https://bugs.launchpad.net/ubuntu/+source/phablet-tools/+bug/1284612
[14:02] <rsalveti> sergiusens: yeah, otherwise you'll own it forever
[14:03] <didrocks> sergiusens: yeah, +1
[14:03] <rsalveti> sergiusens: didrocks: it'd be nice to trigger a new build
[14:03] <rsalveti> sergiusens: go for it
[14:04] <sergiusens> kalikiana, that's a doanac` hidden feature; I'd get him in the loop with your reqs
[14:04]  * sergiusens triggers a build
[14:04] <tsdgeos> cjwatson: didrocks: you're welcome
[14:07] <kalikiana> sergiusens: heh, hidden. they might be surprised to find the ui toolkit testing process came to rely on this for cleanly flashing & installing packages for reliable test results
[14:07] <kalikiana> thanks
[14:08] <tsdgeos> cjwatson: didrocks: seems upstream doesn't recommend using that https://bugreports.qt-project.org/browse/QTBUG-36129 https://codereview.qt-project.org/#change,81095
[14:08] <sergiusens> kalikiana, hidden as in never promoted; the writable-image part yes; but the additional installs is a ci thing
[14:10] <cjwatson> tsdgeos: So, it doesn't seem that we have a problem here on ARM; perhaps our linker has a fix for this
[14:10] <rsalveti> sergiusens: please announce once you trigger the build as well
[14:10] <tsdgeos> cjwatson: yeah maybe
[14:10] <cjwatson> tsdgeos: If you'd really rather drop -Bsymbolic-functions, we should do that only on powerpc/ppc64el IMO
[14:10] <rsalveti> sergiusens: until ogra_ is done with is bot
[14:10] <rsalveti> *his
[14:10] <tsdgeos> cjwatson: i have no strong opinion tbh
[14:11] <cjwatson> tsdgeos: It would certainly be nice not to have to copy/paste this round among lots of packages, so maybe it's the right answer ...
[14:11] <tsdgeos> cjwatson: yeah, https://code.launchpad.net/~cjwatson/dee-qt/powerpc-pie/+merge/211308 seems to be at the wrong layer
[14:11] <tsdgeos> https://codereview.qt-project.org/#change,81095 is that one of the qt guys is proposing upstrea
[14:11] <cjwatson> I think it doesn't hurt, but it's probably be better to fix in Qt
[14:11] <tsdgeos> m
[14:12] <ogra_> rsalveti, well, the bot is running fine, i just have an issue with DSL reconnects ...
[14:12] <cjwatson> tsdgeos: Except that patch would be a performance hit on ARM
[14:12] <ogra_> let me pull it in here
[14:12] <cjwatson> tsdgeos: I'm pretty sure we don't want to make our linker have to re-resolve all internal Qt symbols every time we start a process
[14:12] <ogra_> !HELP
[14:12] <imgbot> I am the firendly image watchbot
[14:12] <ogra_> haha
[14:12] <ogra_> bot noise galore
[14:13] <cjwatson> tsdgeos: (really, the Qt fix is at the wrong layer too; the linker should be fixed.  but our toolchain maintainer is on vacation ...)
[14:13] <tsdgeos> cjwatson: honestly i know not much about it, but it would seem that it doesn't really the case, see the bug mentions "2. Only platforms with little number of registers (like IA32) see a significant runtime performance penalty: http://nebelwelt.net/publications/12TRpie/gccPIE-TR120614.pdf"
[14:13] <ogra_> (i just have to restart it manually on DSL reconnects ... image watching works fine)
[14:13] <rsalveti> ogra_: can't you run it in an internal server?
[14:13] <cjwatson> tsdgeos: You're misreading that
[14:13] <tsdgeos> cjwatson: may very well be :)
[14:13] <cjwatson> tsdgeos: That's saying that PIE only has a performance penalty on platforms like i386
[14:13] <rsalveti> ogra_: or get one at digital ocean, $5 a month
[14:13] <tsdgeos> ah
[14:13] <ogra_> rsalveti, perhaps ... once it is fully done :)
[14:14] <cjwatson> tsdgeos: removing -Bsymbolic-functions has a process-startup performance penalty regardless of architecture
[14:14] <cjwatson> tsdgeos: so we only want to remove it when we have no alternative
[14:14] <tsdgeos> ok
[14:15] <tsdgeos> cjwatson: then you should get yourself an account and comment in https://codereview.qt-project.org/#change,81095 otherwise it'll still fall on us for 5.3 or whatever if it gets approved
[14:15] <cjwatson> tsdgeos: nothing would stop us patching it back out :)
[14:15] <tsdgeos> cjwatson: if someone remebers about it
[14:16] <tsdgeos> cjwatson: besides i thought we didn't want to patch upstreams if possible
[14:16] <cjwatson> tsdgeos: better not to have to, but we're not short of distro patches for things *shrug*
[14:17] <sergiusens> rsalveti, feel free to do it; I can't login to nusakan
[14:17] <cjwatson> tsdgeos: and in the case where the fix in question is only in some distros' linkers, a distro patch is appropriate
[14:17] <rsalveti> sergiusens: removed the ssh proxy from your .ssh/config?
[14:17] <tsdgeos> cjwatson: ok
[14:17] <cjwatson> tsdgeos: honestly I'd rather know more about the linker issues in question before commenting
[14:17] <tsdgeos> cjwatson: sure
[14:17] <tsdgeos> cjwatson: want me to top approve https://code.launchpad.net/~cjwatson/dee-qt/powerpc-pie/+merge/211308 ?
[14:17] <sergiusens> rsalveti, am checking that now; I guess this is due to removing the default entry
[14:18] <cjwatson> tsdgeos: if you don't mind doing that for now, that'd be good; we can always back it out later
[14:18] <rsalveti> sergiusens: ok, doing a build
[14:18] <tsdgeos> done
[14:18] <rsalveti> [14:19] <sergiusens> rsalveti, yeah, my ssh config was missing the proxycommand for nusakan :/
[14:19] <imgbot> [14:19] <rsalveti> \o/
[14:20] <cjwatson> tsdgeos: though didrocks already landed it, https://launchpad.net/ubuntu/+source/dee-qt/3.3+14.04.20140317-0ubuntu1
[14:20] <popey> \o/
[14:20] <tsdgeos> ^_^
[14:20] <ogra_> :)
[14:21] <tsdgeos> cjwatson: didrocks: but not upstream, no?
[14:21] <tsdgeos> i.e. in lp:dee-qt
[14:21] <didrocks> tsdgeos: it will be merged back once in the release pocket (and so built on those archs)
[14:22] <tsdgeos> i see
[14:23] <didrocks> tsdgeos: FYI https://launchpad.net/ubuntu/+source/dee-qt/3.3+14.04.20140317-0ubuntu1
[14:23] <cjwatson> tsdgeos: I've left a comment on https://bugreports.qt-project.org/browse/QTBUG-36129#comment-236117 as best I can, anyway
[14:30] <bfiller> didrocks: is there a bug for messaging-app problems I'm hearing about?
[14:30] <didrocks> bfiller: I'm checking to not open a duplicate with olivier first
[14:30] <bfiller> didrocks: check with boiko please
[14:30] <didrocks> ah, boiko? ^
[14:30] <didrocks> libdee-qt5-dev 3.3+14.04.20140317-0ubuntu1 in trusty powerpc: universe/libdevel/optional/100% -> main
[14:30] <didrocks> libdee-qt5-dev 3.3+14.04.20140317-0ubuntu1 in trusty ppc64el: universe/libdevel/optional/100% -> main
[14:30] <didrocks> cjwatson: FYI ^
[14:31] <didrocks> cjwatson: and rebuilding hud now on those arch after next publisher cycle
[14:32] <boiko> didrocks: do you have a link to the build failures there?
[14:32] <didrocks> boiko: build failure?
[14:32] <boiko> didrocks: well, test failure
[14:32] <boiko> didrocks: the messaging-app things you mentioned
[14:33] <didrocks> boiko: sure, http://ci.ubuntu.com/smokeng/trusty/touch/mako/238:20140314.1:20140304/7158/messaging_app/897403/
[14:33] <didrocks> let me open a quick bug
[14:34] <boiko> didrocks: thanks
[14:35] <didrocks> boiko: bfiller: https://bugs.launchpad.net/messaging-app/+bug/1293610
[14:35] <boiko> didrocks: thanks, we will investigate that
[14:35] <didrocks> yw
[14:36] <bfiller> elopio: ^^^ wasn't this the test that you modified and we merged on friday?
[14:46] <bfiller> didrocks: silo 14 is ready to land
[14:49] <cjwatson> didrocks: oh yeah, overrides
[14:50] <cjwatson> didrocks: you need to promote libdee-qt5-3 too though
[14:50] <cjwatson> didrocks: and the other things that are obvious from rmadison -s trusty-proposed -S dee-qt
[14:50] <didrocks> oh right
[14:53] <seb128> is the datetime indicator showing incoming alarms on the current phone image for others? or is that known to be buggy?
[14:53] <didrocks> cjwatson: done
[15:00] <popey> seb128: which image?
[15:04] <popey> seb128: hmm, 237 i just added an alarm and see an icon
[15:04] <seb128> popey, r239 on n4
[15:04] <seb128> 'an icon'?
[15:04] <seb128> in the indicator?
[15:04] <ogra_> a little alarm clock
[15:04] <seb128> in the indicator?
[15:05] <ogra_> in the panel ...
[15:05]  * ogra_ forgot if its in that specific indicator
[15:06] <seb128> ogra_, well, if you open the indicator, is there an entry in the list?
[15:06] <seb128> popey, ^
[15:06] <popey> seb128: also tested on 239, i see an icon
[15:07] <popey> seb128: http://popey.com/~alan/phablet/device-2014-03-17-150701.png
[15:07] <popey> thats 239
[15:07] <seb128> popey, thanks
[15:07] <popey> np
[15:07] <seb128> popey, any chance you can try https://launchpad.net/~ci-train-ppa-service/+archive/landing-013/+files/indicator-datetime_13.10.0%2B14.04.20140314.1-0ubuntu1_armhf.deb ?
[15:07] <seb128> popey, just to confirm it doesn't regress it
[15:08] <popey> sure
[15:08] <seb128> thanks
[15:10] <seb128> bah, in fact it works for me as well, but I bet there is a tz issue
[15:10] <seb128> if I add one for in 15 minutes it doesn't show up, it's probably picking utc and thinking it's already over or something
[15:11] <popey> yeah, probably, i'm in utc, so it all works
[15:11] <popey> you should move to london ㋛
[15:11] <popey> "Fix released"
[15:12] <ogra_> just convince cameron to make french the default language in london :)
[15:13] <ogra_> seb might move in no time
[15:13] <cjwatson> The Daily Mail would *love* that
[15:13] <popey> seb128: your package works too
[15:13] <seb128> popey, thanks
[15:13] <popey> yw
[15:14] <seb128> how do I delete an alarm? :p
[15:14] <sergiusens> didrocks, Mirv can I get a silo for l22?
[15:15] <didrocks> cyphermox should be around as well ^
[15:15] <cyphermox> yup
[15:15] <cyphermox> on an off irc, dealing with flight mode
[15:16] <cyphermox> assigning now
[15:20] <sergiusens> thanks
[15:20] <sergiusens> didrocks, do you guys have a general highlight?
[15:20] <didrocks> sergiusens: no really, sorry
[15:20] <cyphermox> didrocks: got a crash: http://<IP_ADDRESS>/job/prepare-silo/530/console
[15:21] <didrocks> cyphermox: , between MP
[15:21] <didrocks> and it's not MP urls
[15:21] <didrocks> btw
[15:21] <didrocks> but branches
[15:22] <popey> seb128: swipe to delete
[15:22] <cyphermox> oh quite right
[15:22] <davmor2> awe, cyphermox: is there a way to do tethering via the cli and it is documented anywhere?
[15:22] <cyphermox> but it's not commas no
[15:22] <popey> (from the list of alarms in clock itself)
[15:22] <cyphermox> davmor2: no, you'll need to build your own config file
[15:22] <didrocks> cyphermox: ok, so the former ;) (patch would be neded so that it's more clear)
[15:22] <cyphermox> yeah
[15:22] <cyphermox> sergiusens: ^^ it's not merge requests but branches, can you fix?
[15:23] <davmor2> cyphermox: right thanks dude :)
[15:23] <davmor2> cyphermox: just making sure we weren't missing anything from our list of supported features :)
[15:23] <sergiusens> cyphermox, hmpf; yes, let me check
[15:24] <cyphermox> davmor2: nah, tethering should work just fine but you can't use just the NM config, you also need to enable the net gadget
[15:24] <seb128> popey, thanks
[15:24] <popey> np
[15:24] <cyphermox> it's called rndis if I remember correctly
[15:25] <sergiusens> cyphermox, done
[15:26] <davmor2> cyphermox: right but not in a trivial manner you would have to know what you were doing right?
[15:27] <davmor2> cyphermox: as in there is no magic "tether-me-now my-network-name" command or anything
[15:28] <cyphermox> didrocks: sergiusens: WARNING:root:Project name (ubuntu-system-image) doesn't align with the source package name (system-image)
[15:29] <didrocks> cyphermox: yeah, upstream knows about that (but it's just a warning now)
[15:29] <cyphermox> sergiusens: you're blocked by landing 007
[15:29] <cyphermox> didrocks: yeah just pointing it out in case
[15:29]  * ogra_ was planning to ship a script to set up tethering ages ago
[15:29] <ogra_> but i never got to it
[15:30] <cyphermox> sergiusens: line 11, which already has one of the merge proposals you want to land...
[15:30] <davmor2> cyphermox: just give 007 a parachute he'll jump not landing required ;)
[15:30] <cyphermox> urgh
[15:30] <cyphermox> davmor2: yeah ;)
[15:34] <imgbot> [15:35] <ogra_> there we go :)
[15:35] <didrocks> heh
[15:35] <ogra_> i should drop the dash there ... looks odd
[15:35] <didrocks> Saviq: disabling HUD bottom edge isn't going to break any apps AP tests, right?
[15:36] <popey> Saviq: you said shell rotation wasn't going to be landing for 14.04, but is there a plan to land fixed landscape mode for nexus 7 2013?
[15:36] <Saviq> popey, we're talking
[15:36] <popey> ah
[15:36] <Saviq> didrocks, it shouldn't, but it's difficult to say for sure...
[15:36] <sergiusens> mandel`, ^^
[15:36] <didrocks> Saviq: hum, so you impacted all apps without testing them?
[15:37] <mandel`> sergiusens, what am I suppose to read?
[15:37] <Saviq> didrocks, I impacted the shell, if the apps' test relied on the HUD (of which I don't know of any), it might impact them
[15:37] <sergiusens> mandel`, thostr has the log fix in a silo already
[15:37] <mandel`> sergiusens, ah, sweet!
[15:37] <didrocks> Saviq: why didn't you run their AP tests?
[15:37] <didrocks> knowing you can impact them?
[15:37] <sergiusens> mandel`, only one look at line 11 in citrain; the one you asked me for is line 22
[15:38] <Saviq> didrocks, good question, but probably didn't think it could
[15:38] <didrocks> hum, Mirv? ^
[15:38] <mandel> sergiusens, weird..
[15:39] <sergiusens> mandel, ideas? intervention?
[15:40] <sergiusens> didrocks, cyphermox mind if we take over that one? the owner of that branch (mandel) would prefer to land l22 instead of l11 I suppose
[15:40] <Saviq> didrocks, is there an easy way to run all of them, or would I need to waste hours to do so?
[15:41]  * Saviq misses the "auto" part of autopilot tests....
[15:41] <mandel> sergiusens, just what I was going to say
[15:41] <didrocks> Saviq: doing that manually is the only way I know of
[15:41] <sergiusens> cyphermox, I'm guessing ralsina created it; and it was assigned to throstr as he moved teams
[15:41] <didrocks> Saviq: but not running them can make us loosing 16h
[15:41] <didrocks> which is worse
[15:41] <mandel> sergiusens, didrocks and we need to change the lander, ralsina will probably not be doing it
[15:42] <ralsina> indeed!
[15:43] <cyphermox> fair enough
[15:43] <Saviq> didrocks, so what do you want to do? revert, or do we wait for smoke tests?
[15:44] <didrocks> Saviq: well, it's in an image, so it's already too late, but be ready to have a revert MP
[15:44] <didrocks> (just that feature ideally)
[15:44] <Saviq> didrocks, in any case, apps tests that rely on HUD need to stop
[15:44] <Saviq> didrocks, if there are any
[15:44] <didrocks> Saviq: yeah, but that should be tested and coordinated :)
[15:44] <didrocks> Saviq: maybe I'm too paranoïd, but I remember the hud hurting us
[15:45] <didrocks> Saviq: maybe no tests are dependent on it and everything will be fine
[15:46] <Saviq> didrocks, we might as well revert it already, I don't think smoketesting scripts got updated in time, truth be told I didn't want to land that branch yet, it snuck in :/
[15:47] <Saviq> didrocks, we've a unity8 landing almost ready to fix one of the flaky tests, could add it there
[15:47] <didrocks> Saviq: do you think we have test relying on that?
[15:47] <didrocks> Saviq: I look at the "hud" name in test, nothing, but maybe they are using that to click on thigs
[15:47] <Saviq> didrocks, unlocking the screen relied on a DBus interface that went away
[15:47] <didrocks> Saviq: ah, I think this is not enabled fortunately yet
[15:47] <didrocks> but ok
[15:47] <Saviq> didrocks, we switched to using unity8's autopilot process helpers
[15:48] <didrocks> Saviq: was that done?
[15:48] <didrocks> like today?
[15:48] <Saviq> didrocks, last week
[15:48] <didrocks> (it wasn't on Friday)
[15:48] <didrocks> Saviq: no, that was reverted
[15:48] <Saviq> didrocks, in -ci, but smoketesting didn't have unity8-autopilot, so it got reverted
[15:48] <didrocks> yeah
[15:48] <Saviq> didrocks, that's what I'm saying
[15:48] <didrocks> so right now, they don't use the AP tests, they are "swiping"
[15:48] <didrocks> right?
[15:49] <Saviq> didrocks, yes, but waiting for a dbus interface that the hud exposed
[15:49] <Saviq> didrocks, the current scripts do that, not the new ones
[15:49] <didrocks> argh
[15:49] <didrocks> so all tests will fail?
[15:49] <Saviq> didrocks, that's what I expect, sorry, it was a Friday afternoon brainfart it seems
[15:50] <didrocks> Saviq: ok, so please land the revert in this incoming landing
[15:50] <didrocks> let's get this unity8 in quickly
[15:50] <didrocks> and reckick an image
[15:50] <didrocks> cyphermox: FYI (the last 4 lines) ^
[15:51] <cyphermox> which landing is this?
[15:51] <cyphermox> I need to fettison line 11
[15:51] <didrocks> Mirv: please backlog tomorrow as well ^
[15:53] <Saviq> cyphermox, row 55
[15:54] <cyphermox> ok so just let me know when you're done testing so I can do my own too
[15:54] <mandel> sergiusens, can you be the lander for udm? or what do we do about that?
[15:54] <Saviq> didrocks, https://code.launchpad.net/~saviq/unity8/undisable-hud/+merge/211344
[15:55] <didrocks> Saviq: approving
[15:56] <tvoss> Mirv, didrocks I tested silo 17 locally, could one of you give it a spin on the phone, too?
[15:58] <sergiusens> mandel, cyphermox yes, I can be the lander
[15:58] <mandel> sergiusens, awesome
[16:00] <sergiusens> didrocks, cyphermox shouldn't be a problem as mandel is in our team; so the landings could be transfered to us
[16:08] <Saviq> didrocks, is there a project I could register a bug against for smoketesting relying on the unity8 interface?
[16:09] <didrocks> Saviq: for screen unlocking, you mean?
[16:11] <Saviq> didrocks, yes
[16:11] <didrocks> doanac`: I think it's again utah if I'm correct? ^
[16:11] <didrocks> against*
[16:12] <mhr3> didrocks, spreadsheet broken again? i'm getting 502s
[16:12] <doanac`> didrocks: lets use ubuntu-ci-services-itself. we don't use utah anymore for app testing in smoke
[16:12] <didrocks> ah ok, Saviq ^
[16:12] <Saviq> k
[16:13] <didrocks> mhr3: well, worse than usual…
[16:13] <doanac`> Saviq: you might use this bug: https://bugs.launchpad.net/bugs/1292585
[16:14] <Saviq> ah, I even already commented on it...
[16:25] <rsalveti> hm, can't open the ci train spreadsheet
[16:25] <rsalveti> getting 502
[16:25] <didrocks> yeah, that's what mhr3 mentionned as well
[16:25] <didrocks> and confirmed
[16:25] <rsalveti> I know hangouts are busted
[16:25] <didrocks> oh, as well?
[16:25] <rsalveti> http://downdetector.com/status/google-hangouts
[16:26] <didrocks> zomg, this is the day the Internet is going to crash!
[16:35] <cjwatson> https://code.launchpad.net/~cjwatson/accounts-qml-module/arch-any/+merge/211362 needed to unstick gallery-app from -proposed
[16:36] <robru> didrocks, no hangout today then? what should I do?
[16:37] <didrocks> robru: let's see if it's getting fixed in 25 minutes
[16:37] <didrocks> first
[16:37] <robru> didrocks, ok
[16:37] <didrocks> robru: can you deal manually cjwatson's requests as well please? ^
[16:37] <robru> didrocks, sure
[16:37] <didrocks> (no need for spreadsheet, just deal with it on the backend)
[16:37] <didrocks> thx!
[16:37] <robru> cjwatson, sorry what silo should that be added to?
[16:38] <cjwatson> haven't the foggiest
[16:38] <robru> didrocks, urgh, what is happening? does cjwatson have a silo or does he need a new one?
[16:39] <didrocks> robru: he needs a new one
[16:39] <didrocks> ok, ubuntu-ui-toolkit available now on ppc64el
[16:41] <robru> cjwatson, ok, I put you in silo 2 and started the build for you, since the spreadsheet is unavailable
[16:42] <cjwatson> thanks
[16:42] <robru> didrocks, hummmm I kinda like twiddling jenkins directly, we should just delete the spreadsheet ;-)
[16:42] <didrocks> robru: package fix only, so please go ahead with the publication once done
[16:42] <robru> didrocks, ah ok
[16:42] <didrocks> and yeah, cjwatson doing the fix is an implicit +1 on the packaging change :p
[16:42] <robru> didrocks, oh I see the diff now, yes that will require many hours of review ;-)
[16:42] <didrocks> heh
[16:46] <davmor2> didrocks: what's the plan re the landing hangout if hangouts are down?
[16:46] <didrocks> davmor2: as told 20 lines ago, let's see in 15 minutes, shall we?
[16:47] <davmor2> didrocks: you don't expect me to read all the scrollbacks all the time do you ;)
[16:48] <didrocks> davmor2: no, but then don't expect me to answer 10 times to the same question :)
[16:49]  * davmor2 sits back and waits for the next person to ask :D
[16:56] <Saviq> didrocks, cyphermox, landing-012 can be published (has the hud revert)
[16:56] <didrocks> great! I'll let cyphermox double-checking
[16:58] <ogra_> didrocks, with HO being dead, how do we meet now ?
[16:59] <didrocks> let's do it on IRC
[16:59] <didrocks> quickly
[16:59] <robru> didrocks, ok, i'm here
[16:59] <didrocks> popey: cyphermox: davmor2: plars_: around? let's do the meeting on IRC
[16:59] <plars> ack
[17:00] <didrocks> plars: so, first news for you, all tests are going to fail on current image
[17:00] <didrocks> no screen unlocking
[17:00] <didrocks> Saviq has a fix in landing-012 to revert a hud change for that
[17:00] <didrocks> cyphermox: robru: can you rerun the unity8 AP tests on your side and get that released? ^
[17:00] <plars> didrocks: you mean on 240?
[17:00] <didrocks> plars: yep
[17:00] <plars> ok
[17:00] <didrocks> then, once published, we can kick an image
[17:00] <plars> it wasn't looking good so far, that would explain it
[17:01] <popey> ok
[17:01] <didrocks> plars: remember 80% == 0 :)
[17:01] <didrocks> (or it's a coincidence)
[17:01] <plars> yep
[17:01] <boiko> didrocks: hey, so messaging-app AP tests are not failing anymore, is this something we still should look into?
[17:01] <didrocks> boiko: how/when?
[17:01] <plars> well, if you look at the details on the tests, it becomes clear quickly that something's not right
[17:01] <bfiller> didrocks: at fix was merged on friday for the issue, is it failing since then?
[17:02] <didrocks> bfiller: it was failing on Friday image
[17:02] <bfiller> didrocks: https://code.launchpad.net/~phablet-team/messaging-app/trunk
[17:02] <bfiller> didrocks: then it's fine now
[17:02] <robru> didrocks, with silo 12? sure thing
[17:02] <bfiller> didrocks: I mean if it hasn't failed since friday
[17:02] <didrocks> bfiller: let's see, one sec
[17:02] <didrocks> bfiller: well, we got one image since
[17:02] <bfiller> elopio was working on that fix
[17:02] <didrocks> bfiller: what was supposed to fix it from http://people.canonical.com/~ogra/touch-image-stats/20140317.changes?
[17:02] <didrocks> robru: thanks
[17:02] <didrocks> bfiller: the previous image was failing (it's the link)
[17:03] <sergiusens> cyphermox, didrocks so can we do the l22 l11 swap?
[17:04] <didrocks> ok, let's continue while bfiller and boiko are looking
[17:04] <didrocks> sergiusens: please ping the US team :)
[17:04] <cyphermox> I was trying to, but the spreadsheet went dead
[17:04] <didrocks> cyphermox: spreadsheet is back btw
[17:04] <didrocks> not sure it's working perfectly though :)
[17:04] <didrocks> robru: ^
[17:04] <sergiusens> didrocks, like by 4 minutes?
[17:04] <sergiusens> :-P
[17:04] <boiko> didrocks: so, this is the change that supposedly fixes the problem: http://bazaar.launchpad.net/~phablet-team/messaging-app/trunk/revision/79
[17:04] <sergiusens> didrocks, is rsalveti the US team as well?
[17:04] <didrocks> sergiusens: seems like he was devoted to
[17:04] <ogra_> no, he is the .br team
[17:05] <cyphermox> didrocks: yeah but some cells are still erroring
[17:05] <didrocks> boiko: no, that was on the failing image
[17:05] <robru> didrocks, humm lots of errors in that spreadsheet...
[17:05] <didrocks> boiko: look at the diff I posted: http://people.canonical.com/~ogra/touch-image-stats/20140317.changes?
[17:05] <didrocks> boiko: this is only what entered on the last image, which don't show the failure
[17:05] <sergiusens> cyphermox, well you are in the US team, care if we swap those two? and then kill l11?
[17:05] <boiko> didrocks: yep, I was wondering why messaging-app was not there, so it was already there in the failed image
[17:06] <didrocks> boiko: yeah, so it means that the test if flaky or show a flaky app behavior
[17:06] <didrocks> as the failure was on the image which contains the test change
[17:06] <bfiller> didrocks: i'm confused
[17:06] <bfiller> didrocks: I don't see any failed messaging-app test in the dashboard since March14ths
[17:07] <didrocks> bfiller: well, let's be exact: we have one image since March 14th
[17:07] <didrocks> where the tests ran
[17:07] <didrocks> this image is #239
[17:07] <didrocks> this one didn't show up the messaging-app failure
[17:07] <bfiller> didrocks: right
[17:08] <didrocks> the diff from previous image is http://people.canonical.com/~ogra/touch-image-stats/20140317.changes
[17:08] <didrocks> previous image was #238 on Friday
[17:08] <didrocks> this one showed the messaging-app failure
[17:08] <didrocks> and contains the commit you pointed me at
[17:08] <bfiller> ok
[17:08] <bfiller> elopio: can you help look at this then as you did the original MR to fix the issue?
[17:09] <didrocks> bfiller: so either the test is flaky, or the app behavior is flaky or something in http://people.canonical.com/~ogra/touch-image-stats/20140317.changes fixed it
[17:09] <didrocks> (but seeing the list, I don't see what)
[17:09] <bfiller> didrocks: well the fix was a sleep
[17:09] <bfiller> so just a race in the test most likely
[17:09] <didrocks> yeah, so maybe not enough in some circumstances
[17:09] <didrocks> yep
[17:09] <didrocks> hope it clarified :)
[17:10] <didrocks> robru: cyphermox: so, I propose that we rerun tests for risky landings until we can get an image promoted
[17:10] <cyphermox> ack
[17:10] <robru> didrocks, ok
[17:10] <didrocks> robru: cyphermox: the exact list of fix we are waiting on will be in the landing team email
[17:10] <didrocks> fixes*
[17:10] <robru> didrocks, ok no worries. just flashing now so I can test unity8
[17:11] <didrocks> robru: thanks!
[17:11] <didrocks> meanwhile, we are getting the archive resurecting on all arches
[17:11] <popey> didrocks: bug 1293690 on #239
[17:11] <didrocks> ubuntu-ui-toolkit just build on all arch
[17:11] <sergiusens> cyphermox, you might get a ping to death today :-P But after; how about a silo for l60?
[17:11] <didrocks> mhr3: see popey's bug? ^
[17:11] <robru> cjwatson, didrocks : publishing silo 2
[17:12] <didrocks> robru: excellent!
[17:12] <didrocks> cjwatson: robru: so with those 2 publishing, (toolkit being fine), I think qml-friends will be needed to have a look now
[17:12] <didrocks> robru: maybe an empty MP?
[17:12] <sergiusens> cyphermox, or I guess I can pass on the robru
[17:12] <robru> didrocks, what's wrong with it?
[17:12] <mhr3> didrocks, popey, i guess that's why there is mediascanner2 now
[17:12] <cyphermox> sergiusens: you need to wait, it's in progress
[17:12] <didrocks> robru: it couldn't built on all archs
[17:13] <robru> didrocks, oh ok, so just no-change rebuild?
[17:13] <sergiusens> cyphermox, ah, ok; sorry
[17:13] <robru> didrocks, yeah I can do it
[17:13] <didrocks> robru: now, all build-deps should be ready
[17:13] <bfiller> robru, didrocks : can we get line 38 published? all testing passed
[17:13] <didrocks> robru: yeah, with "force rebuild" :)
[17:13] <cjwatson> robru: thanks
[17:13] <robru> cjwatson, you're welcome!
[17:13] <robru> didrocks, ok
[17:13] <cjwatson> didrocks: qml-friends will want control file changes, surely?
[17:13] <cyphermox> didrocks: was going to assign l60
[17:14] <didrocks> cjwatson: I didn't check, I was thinking build-dep was the only thing, let me check
[17:14] <cjwatson> robru: er, you kinda published silo 2 before arm64 had finished building
[17:14] <popey> mhr3: why do I have mediascanner 1 and 2?
[17:14] <cjwatson> let's hope that doesn't explode
[17:14] <cjwatson> why didn't citrain notice that?
[17:14] <mhr3> popey, music app didn't transition yet
[17:14] <didrocks> cjwatson: I'll add the check tomorrow for arm64 enablement btw
[17:14] <robru> cjwatson, hrm? jenkins said it was done
[17:14] <cjwatson> robru: maybe jenkins doesn't check arm64 yet ...
[17:14] <didrocks> yeah, build doesn't
[17:14] <robru> cjwatson, ahhhh ok
[17:14] <didrocks> will do tomorrow
[17:15] <robru> cjwatson, so... how can I check if that exploded or not?
[17:15] <didrocks> robru: on friends, cjwatson is right
[17:15] <cjwatson> robru: doesn't look like it's actually copied, so you'll probably have to do it again later
[17:15] <didrocks> robru: you specify archs
[17:15] <didrocks> needs to be arch: any
[17:15] <robru> didrocks, ok, I will make the friends stack arch:any
[17:15] <didrocks> robru: qml-friends
[17:15] <didrocks> not sure for friends itself
[17:15] <robru> right
[17:15] <cjwatson> oh wait, it did at least sort of copy.  hmm.
[17:15] <robru> didrocks, probably nor friends but might be friends-app
[17:15] <didrocks> cjwatson: do you see any remaining build pile of arch rebuild needed?
[17:16] <didrocks> or tweaks?
[17:16] <cjwatson> looks like it's just going to build accounts-qml-module/arm64 again in the primary archive
[17:16] <didrocks> robru: cyphermox: please, get an image kicked once unity8 is in the image btw
[17:16] <cyphermox> yes,
[17:16] <robru> ok
[17:17] <cjwatson> didrocks: there'll be a few more, https://code.launchpad.net/~cjwatson/address-book-service/powerpc-pie/+merge/211319 needs to land for address-book-app to be happy
[17:18] <cjwatson> didrocks: it's mostly not too terrible now
[17:18] <didrocks> yeah
[17:19] <didrocks> cjwatson: we can as well wait for non change-noplatform
[17:19] <didrocks> cjwatson: we'll surely have some new landing requests
[17:19] <cjwatson> forr what?
[17:19] <didrocks> like the apps
[17:19] <cjwatson> *for
[17:20] <cyphermox> sergiusens: done
[17:20] <oSoMoN> robru, hey, I’ve got a landing that’s ready to go (silo 014), wondering what’s holding it off, can you help me figure it out?
[17:21] <robru> oSoMoN, yeah I'm not sure... I've been hesitant to land things due to other regressions going on. maybe didrocks can comment if it's safe to land
[17:21] <didrocks> robru: if you double check it, please land it
[17:21] <didrocks> let me look at that case
[17:22] <robru> didrocks, ok
[17:22] <oSoMoN> robru, would my personal assurance that it won’t introduce regressions help? ;)
[17:22] <cyphermox> why is it not closing bugs if it's bugfix?
[17:22] <robru> oSoMoN, unfortunately not, but it sounds like i have the green light to test it myself and land it
[17:22] <didrocks> (yep + cyphermox question)
[17:23] <robru> oSoMoN, so I can get to that in an hour or two, have a couple other things on my plate first
[17:23] <oSoMoN> robru, thanks, much appreciated
[17:24] <robru> oSoMoN, you're welcome
[17:24] <robru> cjwatson, so what happened with accounts-qml-module then? it looks like arm64 is just building in proposed.... is that ok? it'll publish and then I can merge?
[17:26] <cjwatson> robru: I think it should be fine, but I'll keep an eye on it
[17:29] <robru> cjwatson, ok
[17:31] <dbarth> robru: just adding to oSoMoN's request, as it blocks other fixes for the webapps as well; keep us posted when you get to it
[17:33] <boiko> didrocks: btw, rwo 17 of the spreadsheet (landing-011) built and tested with the powerpc fix for address-book-service
[17:34] <boiko> s/rwo/row/
[17:34] <didrocks> boiko: please ping the US landing team :)
[17:34] <boiko> didrocks: ok, will do, thanks
[17:34] <didrocks> no worry :)
[17:35] <boiko> robru: didrocks asked me to add one extra MR to the address-book fixes on row 17 of the spreadsheet, everything is built and tested, could you please release it once you get some spare time?
[17:36] <robru> boiko, sorry I'm confused. you want silo 11 released so you can start a new silo for address book? if you add a new MR to same silo it has to be rebuilt & retested
[17:36] <boiko> robru: it was already built and retested, I just need it to be published now
[17:37] <robru> boiko, oh ok ok. I'm just working on getting a big unity8 fix out, then kick an image build, then I can release that
[17:37] <boiko> robru: no problems, take your time
[17:38] <robru> didrocks, Saviq hummmm just 1 failure on unity8, is that acceptable? unity8.shell.tests.test_emulators.DashEmulatorTestCase.test_open_applications_scope
[17:38] <didrocks> robru: we are supposed to have none
[17:38] <didrocks> robru: so no, if it's flaky, better to confirm it was flaky before
[17:38] <didrocks> (looking at the dashboard can help)
[17:39] <didrocks> of course, not image #240 which will never never have tests passing :p
[17:40] <ogra_> didrocks, you could send someone to the lab to manually unlock the screen :)
[17:40] <ogra_> has to be quick with his finger though :)
[17:40]  * didrocks thinks of Saviq :)
[17:41] <sergiusens> ogra_, doesn't need to be quick; you have 10 seconds to do it
[17:41] <robru> didrocks, i don't see this failure in the last few images.
[17:42] <ogra_> sergiusens, :)
[17:42] <didrocks> robru: yeah, so, the goal is to know why and how (however, we need the fix as well, so it's a tradeoff)
[17:42] <didrocks> robru: check with upstream I guess
[17:42] <robru> Saviq, any thoughts on this? http://paste.ubuntu.com/7109406/ should it block getting your fix out?
[17:42] <didrocks> robru: the landing only have that fix?
[17:43] <robru> didrocks, well there's 3 mps.
[17:44] <didrocks> robru: yeah, so check if previous version had the same failure maybe (especially if this is reliable)
[17:44] <robru> didrocks, what, you mean rerun on image 240 stock?
[17:44] <didrocks> robru: yeah, just redowngrade manually
[17:44] <didrocks> unity8
[17:45] <didrocks> however, please keep me posted as it will mean that unity8 (even previous version) regressed us
[17:45] <robru> didrocks, ok, will take some time to rerun the tests.
[17:45] <didrocks> thanks
[17:58] <sergiusens> robru, cyphermox do we have ofono on the train?
[17:59] <robru> sergiusens, telepathy-ofono is on line 30 but it's marked as "not ready" (eg, does not yet have a silo0
[18:00] <sergiusens> robru, yeah, I mean just ofono
[18:00]  * sergiusens thinks not
[18:00] <sergiusens> robru, would like a silo for a source package push if possible
[18:00] <robru> sergiusens, no i don't see it
[18:00] <robru> sergiusens, ok
[18:01]  * sergiusens fills in sheet
[18:02] <sergiusens> robru, ah, you beat me to it :-P
[18:02] <robru> sergiusens, well please put better details in A61 ;-)
[18:02] <robru> sergiusens, ok, you got silo 7
[18:02] <sergiusens> robru, fixed description
[18:02] <robru> thanks
[18:03] <sergiusens> robru, if it's just a source package; I don't need to 'Build', right?
[18:03] <seb128> if the googledoc lost the "landed" status for some of the lines, how should those be indicated?
[18:03] <robru> seb128, unhide the rightmost columns and put 'Landed' on whatever row is really landed.
[18:04] <seb128> robru, thanks
[18:04] <robru> seb128, you're welcome
[18:05] <robru> OMG! I just remembered I have pizza in the fridge ;-)
[18:05] <rsalveti> sergiusens: I'm unofficially part of the us team, just here to help in case nobody is around :-)
[18:05]  * ogra_ thinks the oven is a way better place for it
[18:06] <rsalveti> oh, docs is back, seems hangout is still off
[18:06] <ogra_> use drums
[18:06] <sergiusens> rsalveti, well you might want to dput tony's fix to silo double o seven
[18:06] <ogra_> :)
[18:06] <rsalveti> sergiusens: why dput?
[18:06] <robru> ogra_, way ahead of you ;-)
[18:06] <sergiusens> rsalveti, no train for that
[18:06] <sergiusens> rsalveti, https://code.launchpad.net/~phablet-team/ofono/ppc64le-ftb/+merge/211152
[18:06] <ogra_> :)
[18:06] <rsalveti> sergiusens: thought train could handle any branch
[18:07] <sergiusens> rsalveti, if we want a train, we need to create a proper project and use trunk
[18:07] <rsalveti> sergiusens: is that a limitation? why can't we use any branch as target?
[18:07] <rsalveti> I mean, it's a merge proposal
[18:07] <sergiusens> rsalveti, we are using ofono, but not it's trunk
[18:07] <rsalveti> from to somewhere :-)
[18:07] <sergiusens> rsalveti, it's a limitation for the train
[18:07] <rsalveti> sergiusens: sure, but why that?
[18:07] <rsalveti> otherwise there's no way to handle lp:ubuntu/foobar
[18:08] <sergiusens> rsalveti, that's an ask didrocks question
[18:08] <rsalveti> and someone said that would be compatible
[18:08] <rsalveti> sergiusens: but I can dput, np
[18:08] <sergiusens> and one of the things that was discussed last week ;-)
[18:08] <robru> sergiusens, hummm, who told you train can't handle lp:ofono? I think as long as your MP points at the right branch it should be fine?
[18:08] <robru> sergiusens, (eg I'm not aware of train forcing merges to trunk, it should just merge to wherever teh MP is set)
[18:09] <rsalveti> robru: that's what I thought
[18:09] <cjwatson> that's definitely true, click merges aren't to trunk
[18:09] <robru> sergiusens, if didrocks told you that lp:ofono can't work in citrain, then I would trust him. but if you're just making assumptions I'd be inclined to think you're wrong here...
[18:11] <sergiusens> robru, no, didrocks did not say that; what was said was the we needed for it to be in trunk; as in the target can't be lp:ofono/ubuntu
[18:11] <rsalveti> File "/usr/lib/python2.7/dist-packages/autopilot/introspection/__init__.py", line 173, in get_proxy_object_for_existing_process
[18:11] <rsalveti> raise ProcessSearchError(message_string)
[18:11] <rsalveti> autopilot.introspection.ProcessSearchError: Sea
[18:11] <rsalveti> unlock screen is busted
[18:11] <robru> sergiusens, humm, didrocks said that? weird that i'm not aware of that
[18:12] <sergiusens> robru, then I'm all confused; let's get it working
[18:12] <robru> rsalveti, yeah, we're aware of the screen failing to unlock in image 240, i'm working on a revert fix for that.
[18:12] <rsalveti> robru: great
[18:12] <rsalveti> sergiusens: try configuring that silo pointing that mr that awe created
[18:13] <robru> ogra_, cyphermox: will one of you be around to kick an image build shortly? I'm just publishing unity8 right now.
[18:13] <sergiusens> rsalveti, iirc; it still needs to be added to cupstream2distro; right robru ?
[18:13] <cyphermox> robru: I'm around
[18:13] <rsalveti> robru: I can do it as well if needed
[18:13] <ogra_> robru, me too
[18:13] <rsalveti> sergiusens: thought not even that would be needed
[18:13] <robru> ok thanks guys, will ping when I see unity8 landed
[18:19] <ybon> hi o/
[18:20] <ybon> rsalveti: nik90 suggested me to ping you about an issue I have with QtLocation/Positioning, are you around? :)
[18:20] <rsalveti> ybon: it seems I'm, yes
[18:20] <ybon> great :)
[18:20] <ybon> I'm trying to port OSMTouch to Qt5.2
[18:20] <sergiusens> robru, so I'm going to use the branch as rsalveti wants; given that I moved souces: ofono; to a branch that contains ofono; do I need to reconfigure?
[18:20] <ybon> and I've the error PositionSource is not a type
[18:21] <rsalveti> oh, right, I know the api changed
[18:21] <robru> sergiusens, yes, any changes to MPs/sources requires reconfigure.
[18:21] <ybon> rsalveti: ah :)
[18:21] <sergiusens> robru, can you do that for me please?
[18:22] <robru> sergiusens, sure I can, but also you can too (landing team is now only required for reconfigs when the set of packages to be released changes)
[18:22] <sergiusens> robru, ok, so it's just 'reconfigure' with the added mr links?
[18:22] <robru> sergiusens, just did it for you thought
[18:22] <ybon> rsalveti: and btw I've tried to import from QtPosition as stated by the "official" doc, but the module doesn't seem installed on my laptop even if I have the libqt5positioning5 installed
[18:22] <robru> sergiusens, yep, if you click the reconfig button it asks for MPs and sources
[18:22] <sergiusens> robru, no worries; going to look at parameters you passed in
[18:22] <ybon> (What I mean by official doc: http://qt-project.org/doc/qt-5/qml-qtpositioning-positionsource.html)
[18:23] <ybon> (while our doc developer.ubuntu.com/api/qml/sdk-14.04/QtLocation.PositionSource/ )
[18:23] <robru> sergiusens, http://<IP_ADDRESS>/job/landing-007-0-reconfigure/9/parameters/ it's here but I guess you know how to find that ;-)
[18:23] <rsalveti> ybon: yeah http://qt-project.org/doc/qt-5/qtpositioning-index.html
[18:23] <sergiusens> robru, yeah, already closed the tab as I saw what I wanted and expected; thanks
[18:23] <robru> sergiusens, eheh thanks
[18:24] <ybon> rsalveti: thanks, that's yet a good clue for me :)
[18:24] <rsalveti> let me check if something is wrong at the packaging layer
[18:24] <rsalveti> might be missing the qml component for it
[18:24] <sergiusens> robru, just as an fyi; cupstream2distro is dead? or is it still used by the jenkins builder to approve an MR?
[18:24] <ybon> thanks :)
[18:25] <rsalveti> ybon: there's libqt5positioning5-plugins, let me see what else might be missing
[18:25] <ybon> I've it yet
[18:25] <robru> sergiusens, ehhhhh. much of citrain is actually built on top of cupstream2distro, so it's not "dead". also yeah, ps-jenkins-bot uses cu2d to figure which projects to do CI on. it's just the daily_release part that got shut off
[18:25] <sergiusens> robru, rsalveti http://<IP_ADDRESS>/job/landing-007-1-build/26/console
[18:26] <sergiusens> might be the versioning scheme causing issues
[18:27] <robru> sergiusens, definitely version related, huh, never saw that error before.
[18:27] <davmor2> am I the only one who hears this everytime I see 007 http://www.youtube.com/watch?v=Ii1tc493bZM
[18:27] <robru> sergiusens, if you update the MP to have a version like '1.12+14.04.20140317-0ubuntu1' it might fix it
[18:28] <sergiusens> robru, not sure we want that; it's an rsalveti call
[18:28] <sergiusens> robru, might break the whole import system from git
[18:31] <rsalveti> sergiusens: not going to break anything
[18:31]  * sergiusens changes version
[18:31] <rsalveti> sergiusens: so I guess you'd need to pile another MR to change the versioning to be similar to that
[18:31] <sergiusens> rsalveti, I can use that same MR
[18:31] <rsalveti> sergiusens: if you have commit rights, then yeah
[18:32] <sergiusens> rsalveti, it's on phablet-team, so yeah ;-)
[18:32] <rsalveti> great
[18:35] <rsalveti> ybon: do you have qtdeclarative5-qtpositioning-plugin as well?
[18:37] <ybon> rsalveti: let me check
[18:37] <ybon> rsalveti: no, I'm installing it now
[18:37] <rsalveti> Mirv: from what I understand qtlocation will not be supported anymore, and that users should instead use qtpositioning
[18:37] <ybon> and testing
[18:37] <rsalveti> Mirv: checking now the image and it seems that we're not installing it by default
[18:38] <ybon> rsalveti: sound much much better, thank you very much :)
[18:38] <rsalveti> Mirv: do we also need to update our sdk to reflect that?
[18:38] <rsalveti> ybon: great
[18:38] <rsalveti> bzoltan1: ^
[18:40] <rsalveti> cyphermox: Mirv: bzoltan1: I'd guess we also want qt bluetooth to be in by default as well
[18:40] <rsalveti> which is now part of 5.2
[18:40] <bzoltan1> rsalveti: most likely yes
[18:40] <rsalveti> bzoltan1: can you take care than to include both qtposition and qtbluetooth as part of our sdk?
[18:41] <bzoltan1> rsalveti: I will see it tomorrow...
[18:41] <rsalveti> bzoltan1: sure, because we don't have any by default installed at our current images
[18:42] <rsalveti> so if someone decide to use them, we'd need to seed them by default
[18:42] <rsalveti> and I believe that's currently coming from the sdk packages
[18:42] <rsalveti> hm, actually we have sdk-libs in our seeds
[18:43] <bzoltan1> rsalveti: yes...
[18:43] <rsalveti> bzoltan1: ogra_: is there the right place to add new qt components?
[18:43] <rsalveti> *that
[18:46] <ogra_> rsalveti, yeah
[18:46] <rsalveti> bzoltan1: alright, then just let me know if you want both to be included by default
[18:59] <robru> bfiller_afk, ok, I tested the webbrowser-app thing, it's looking good to me, just need to wait for unity8 to get through -proposed so we can kick an image before I can publish this.
[19:01] <robru> ogra_, cyphermox, rsalveti: I'm heading for lunch. if one of you happens to notice that unity8 made it through proposed, please kick an image. if not, i'll check when i get back and ping you again then.
[19:01] <cyphermox> sure
[19:02] <ogra_> yeah, still in proposed
[19:02]  * ogra_ doesnt think the minute counts here
[19:02] <ogra_> take your time for your pizza :)
[19:03] <robru> thanks
[19:09] <thomi> robru: cyphermox: Hi guys, I wonder if I could get one of you to reprovision silo 3 for me, since I've had to add a new MP to my landing line (#41) that introduces a new source package - I think that means I still need you guys to do the reprovision thing for me?
[19:10] <cyphermox> yes
[19:13] <cyphermox> thomi: done
[19:13] <thomi> thanks cyphermox
[19:14] <boiko> robru: just for me to organize the work here, do you have an ETA of when you'll be able to publish the address-book stuff on silo-011?
[19:23] <rsalveti> yay, qt 5.2.1 broke the emulator
[19:23] <rsalveti> nobody tested that
[19:23] <rsalveti> it seems a patch I added for 5.0 was dropped, will check
[19:28] <sergiusens> rsalveti, can I lol?
[19:28] <ogra_> only if you record it and publish on G+
[19:29] <davmor2> rsalveti: why would I test the emulator I had my hands full with a n4,7,10 :)
[19:30] <ogra_> because you like the slowness ?
[19:31] <sergiusens> ogra_, http://www.quickmeme.com/meme/354t3w
[19:31] <sergiusens> davmor2, http://www.quickmeme.com/meme/1coc
[19:31] <ogra_> lol
[19:32] <robru> boiko, should be soon, just waiting on unity8 to land so we can kick an image. maybe one hour?
[19:32] <robru> ogra_, cyphermox, rsalveti: speaking of that, looks like unity8 just landed, anybody kick an image yet? ;-)
[19:32] <ogra_> robru, it just migrated
[19:32] <cyphermox> robru: hold on, let's make sure
[19:33] <cyphermox> yah alright
[19:33] <cyphermox> ogra_: you already on it?
[19:33] <ogra_> feel free :)
[19:33] <cyphermox> ok
[19:33] <robru> boiko: ok. I'm still on lunch for a bit, will be back to do silo 11 shortly.
[19:33]  * ogra_ just wants to see the bot working once it is kicked :)
[19:34] <ogra_> (and finished)
[19:34] <cyphermox> robru: kicked a rebuild
[19:34]  * ogra_ waits for the bot to announce
[19:34] <cyphermox> bot?
[19:34] <ogra_> imgbot ...
[19:34] <cyphermox> oh look at that
[19:34] <ogra_> it monitors builds ... start and end for now
[19:35] <davmor2> sergiusens: nice
[19:35] <ogra_> should say something soon
[19:37] <davmor2> sergiusens, ogra_: http://www.quickmeme.com/p/3vubsv
[19:37] <sergiusens> robru, will the train cope with a version like: 1.12+bzrXXXX+14.04.20140317.1-0ubuntu1 ?
[19:37] <ogra_> with a hammer ?
[19:38] <davmor2> ogra_: If at first it doesn't break use a bigger hammer
[19:39] <ogra_> oh, another bug in the bot ...
[19:39]  * ogra_ slaps himself for hardcoding paths
[19:39] <davmor2> ogra_: sadtrombone.com
[19:39] <ogra_> davmor2, well, its all stgrabers fault
[19:39] <imgbot> [19:39] <ogra_> he made a change that exposed my lazy hacks :)
[19:40] <ogra_> and there is the bot :)
[19:42] <davmor2> ogra_: hahaha
[19:42] <sergiusens> robru, and how do I make the changelog be generated from a specific commit?
[19:44] <rsalveti>   * Drop upstream patches:
[19:44] <rsalveti>     - Add-workaround-for-GL-on-Android-emulator.patch
[19:44] <rsalveti> o/
[19:46] <boiko> robru: thanks
[19:47] <thomi> cyphermox: my silo build (http://<IP_ADDRESS>/job/landing-003-1-build/74/console) is complaining about the version in distro again, but this time for a component I don't own (libUAL) - I just want to make sure I'm doing the correct thing. I should make a new entry in d/changelog with a bumped version number?
[19:52] <sergiusens> robru, can I get a silo for l23 ?
[19:58] <robru> sergiusens, not sure, you'd have to try it. although I think it can only take a single plus sign, so maybe 1.12~bzrXXXX+14.04...
[19:58] <robru> sergiusens, and if you don't like the changelog, you can add your own debian/changelog entry by hand and citrain will preserve it
[20:00] <robru> sergiusens, and you got silo 2
[20:00] <sergiusens> robru, that would be lower than what's currently in though
[20:00] <robru> ogra_, when is it safe to start publishing things? (eg so they don't end up in the currently building image?)
[20:01] <sergiusens> robru, the current changelog is written by hand but seems to be ignored
[20:01] <ogra_> robru, hmm, i could add a marker to the bot for that ...
[20:01] <robru> sergiusens, ugh. how many MPs? just one?
[20:01]  * ogra_ notes down on his TODO
[20:01] <robru> sergiusens, which silo are we talking about? i'll check
[20:01] <sergiusens> robru, just one: https://code.launchpad.net/~phablet-team/ofono/ppc64le-ftb/+merge/211152 in 007
[20:01] <sergiusens> ogra_, if you get silo 007 you don't need to wait for no markers
[20:02] <ogra_> robru, once the 17.2 build shows up on http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/
[20:02] <robru> ogra_, thanks
[20:02] <ogra_> then it is safe to publish again
[20:02] <sergiusens> all double Os get license to land :-P
[20:02]  * sergiusens stops with the dumb jokes now
[20:03] <robru> sergiusens, haha, yes. I am going on a landing spree very shortly ;-)
[20:04] <robru> sergiusens, ugh, I see, citrain really puked on your changelog. that's a bug I've seen before but haven't been able to pin down... jdstrand was bitten by that recently but he managed to suppress it just by writing his own changelog. i think...
[20:05] <robru> jdstrand, what happened to your changelog in your first citrain landing? did you just end up dputting a manual upload to the ppa or did you get citrain to honor your changelog somehow?
[20:05] <jdstrand> I did write my own changelog. I have no idea what actually got it working
[20:05] <robru> crap
[20:05] <jdstrand> robru: it was a mystery
[20:05] <sergiusens> heh; I'll trial and error and try to note down
[20:05] <Saviq> robru, must be flaky, I didn't see that before, is that failing for you reliably?
[20:05] <jdstrand> I had it in both debian/changelog and in the MP. I think I needed UNRELEASED in the distribution name
[20:06] <robru> sergiusens, the only thing I can guess is that citrain's version is .1 above your version, so maybe try .1 above that and it'll honor it. So eg put your version as 1.12+14.04.20140317.2-0ubuntu1
[20:06] <robru> Saviq, just saw it one time unfortunately, didn't have time to test it further.
[20:08] <robru> sergiusens, there way it builds the changelog is by checking the tags at the destination branch, but in some cases even if the tag is there it doesn't find it. quite frustrating (usually when the version numbers are not in the expected format, as jdstrand's issue also involved version numbers different than we expect in citrain)
[20:08] <robru> I'll file a bug for didrocks
[20:08] <sergiusens> thanks
[20:09] <robru> jdstrand, where was the branch you used?
[20:10] <jdstrand> yeah, I had the right tag, but used native versioning
[20:10] <thomi> cyphermox: nvm, figured it out
[20:11] <cjwatson> sigh, one of these days I really must make LP show multiple dep-waits in its UI
[20:11] <jdstrand> https://code.launchpad.net/~jdstrand/click-apparmor/click-apparmor.lstat
[20:11] <jdstrand> robru: ^
[20:13] <robru> jdstrand, thanks
[20:13] <robru> sergiusens, jdstrand ok here's the bug: https://bugs.launchpad.net/cupstream2distro/+bug/1293780 feel free to add any details you think might be relevant.
[20:29] <boiko> robru: hey, just a heads up that line 30 on the spreadsheet is ready for silo assignment now
[20:29] <robru> boiko, thanks, on it
[20:31] <robru> boiko, ok, you got silo 9
[20:31] <boiko> robru: nice! building it. thanks.
[20:32] <robru> thank you
[20:32] <robru> ogra_, is it really 17.2 I'm waiting for? not 17.1? Why is 17.2 still not there?
[20:40] <robru> ogra_, nm, checked the .changes, yes it seems 17.1 contains an old unity and it really is 17.2 we're waiting for
[20:43] <robru> omg it's finally there!
[20:44] <robru> bfiller, dbarth: apologies for how long that took, just published silo 14!
[20:47] <robru> ogra_, there *must* be some point during the image build process at which the builder is done downloading packages from the archive (but before publishing the image itself) at which it's safe to begin publishing packages...
[20:47] <ogra_> robru, indeed
[20:47] <ogra_> but for that you need to log in directly to the livefs builder and watch the log
[20:48] <ogra_> (via w3m reloading)
[20:48] <robru> ogra_, maybe the builder itself should ping on IRC when it's done ;-)
[20:48] <bfiller> robru: thanks, I will merge and clean
[20:49] <robru> bfiller, you're welcome
[20:49] <ogra_> robru, sure, after about a week of code changes in the different build scripts it might be able to :P
[20:49] <robru> ogra_, great, what are you waiting for? ;-)
[20:49] <imgbot> [20:49] <ogra_> (our build setup is pretty complex, but i'll add a watcher to the bot to monitor the cdimage dir ... )
[20:50] <robru> ogra_, ok, thanks
[20:50] <popey> \o/
[20:50] <ogra_> robru, the post processing after the image is done is in max 10min ... so you dont lose much :)
[20:50] <robru> ogra_, oh, can you make your bot ping 'trainguard' in it's messages? we landers had agreed that would be our equivalent of 'cihelp'
[20:51] <robru> ogra_, ahh ok. I was thinking the build was taking like 2 hours, which would be 10m of downloading packages and then a long time for compiling/building.
[20:51] <ogra_> (at least for touch thats the case since we use the tgz directly from the livefs builder, post_processing is mainly renaming)
[20:51] <ogra_> for isos its all the mkiso stuff that runs ... and creating a squashfs etc
[20:52] <ToyKeeper> Sweet, a working new-image notifier?  :)
[20:52] <thomi> robru: cyphermox: I can't seem to get the silo build step to complete correctly. Are you able to take a look please? http://<IP_ADDRESS>/job/landing-003-1-build/75/console
[20:53] <ogra_> robru, trainguard added
[20:53] <thomi> I get "2014-03-17 20:37:35,174 INFO Some source packages were never published in the ppa: upstart-app-launch (0.3+14.04.20140317-0ubuntu1) autopilot (1.4+14.04.20140317.1-0ubuntu1)"
[20:54] <thomi> which looks like another case where that log message really needs to be an ERROR, not INFO
[20:54] <thomi> but... what am I doing wrong?
[20:55] <robru> thomi, looking
[21:01] <sergiusens> robru, any ideas with this error? http://<IP_ADDRESS>/job/landing-007-1-build/28/console
[21:01] <cyphermox> sergiusens: lookin
[21:02] <cyphermox> oh wow, that's a genuine bug
[21:02] <dbarth> robru: thanks for silo 14
[21:02] <robru> dbarth, you're welcome
[21:03] <dbarth> robru: could i get a green light for line 15
[21:03] <robru> thomi, ok, well it seems pretty clear that upstart-app-launch never made it to the PPA. not sure why though
[21:03] <dbarth> robru: i object to it being blocked by an ffe, as it's only fixes, which are important wether we have oxide or not
[21:03] <thomi> robru: right... but what do I do? Just try again and hope for the best?
[21:03] <dbarth> ie they apply to qtwebkit as well
[21:04] <dbarth> currently our webapp container boots into a blank screen :/
[21:04] <robru> thomi, for now I would say try it again. not sure. if it fails again I'll dig a bit deeper
[21:04] <thomi> robru: ok, ta
[21:04] <robru> thomi, you're welcome
[21:04] <dbarth> https://bugs.launchpad.net/unity-webapps-qml/+bug/1292174
[21:04] <bfiller> robru: any idea why this MR is not triggering CI? https://code.launchpad.net/~michael-sheldon/content-hub/peer_picker_ui/+merge/211092
[21:05] <robru> dbarth, hum, line 15 has libunity-webapps which conflicts with silo 6...
[21:05] <bfiller> robru: nm
[21:05] <robru> dbarth, if you do some testing on silo 6 i think we can publish that one.
[21:06] <robru> dbarth, because silo 6 was only ever blocked by qt5.2 but that's over now
[21:06] <robru> dbarth, or i dunno, maybe just add line 15 into silo 6, then do it all together. it looks like one of the MPs is already in silo 6.
[21:07] <sergiusens> cyphermox, so I wait?
[21:07] <cyphermox> yes please
[21:07] <sergiusens> ack
[21:08] <sergiusens> cyphermox, fwiw I noticed I didn't have a commit message set (as I did a resubmit) to try something out
[21:08] <sergiusens> could it be that?
[21:08] <dbarth> robru: yup, let me check
[21:09] <cyphermox> sergiusens: yeah, but it should still not crash if possible ;)
[21:09] <robru> dbarth, maybe I'm going crosseyed, i think line 15 is already a subset of silo 6 ;-)
[21:09] <sergiusens> cyphermox, of course :-)
[21:09] <dbarth> yes, we tried every opportunity to land, as you can see
[21:10] <cyphermox> sergiusens: set a commit message for now and it will pass
[21:10] <cyphermox> I'll push a branch to fix this issue
[21:10] <robru> dbarth, yeah, double-checked, line 15 is already contained in silo 6. please just test silo 6 and then I'll publish that. i'm deleting line 15.
[21:11] <ybon> rsalveti: should I still be importing QtLocation 5.0 or 5.2? 5.2 is not found atm, and with 5.0 I've this funny message: Error message: Qt Location requires app_id and token parameters.
[21:11] <ybon> Please register at https://api.developer.nokia.com/ to get your personal application credentials.
[21:11] <ybon> so I may need to change some syntax, but just to be sure I'm importing the correct version before going further
[21:13] <ybon> qtdeclarative5-qtlocation-plugin is already the newest version.
[21:16] <rsalveti> ybon: I'd think you just need to use qtposition
[21:17] <robru> boiko, apologies for the delay, just published silo 11.
[21:17] <boiko> robru: no problems, thanks!
[21:17] <robru> boiko, you're welcome
[21:18] <ybon> rsalveti: that's what I've tried, but then "Map is not a type", but let me check in the doc again, thanks for the clue :)
[21:21] <ybon> Humm, I don't see QtLocation in the listed modules: http://qt-project.org/doc/qt-5/modules.html
[21:22] <rsalveti> right, that's probably because most of it was moved to qtposition
[21:22] <ybon> And I don't see any Map on the QtPositioning API reference: http://qt-project.org/doc/qt-5/qtpositioning-qmlmodule.html
[21:25] <ybon> It seems to me, for what I can read now, that QtPositioning is, as suggested by name, for managing device position only, not map nor markers management
[21:27] <rsalveti> hm, right
[21:28] <sergiusens> doanac`, plars it just occured to me; could the new build watch look at changes to a certain file that wouldn't exist anymore? Or let me generalize; how do you figure out there's a new build?
[21:28] <sergiusens>  ogra_, maybe you know?
[21:29] <doanac`> sergiusens: we check if a file has changed. i was about to dig into that today. let me find the link
[21:29] <rsalveti> ybon: please also ping Mirv, as he probably knows better what changed in the qt stack
[21:29] <sergiusens> robru, hey, above when you said I got silo 2, that is a silo for you :-)  I wanted one for l22, goget-ubuntu-touch
 seems using rows isn't a good idea
[21:29]  * sergiusens got disconnected and didn't notice
[21:29] <rsalveti> ybon: he's off already, but should be able to reply you back in ~10 hours
[21:29] <sergiusens> doanac`, yeah, the device and channels all changed
[21:29] <doanac`> sergiusens: so for mako, we use: http://system-image.ubuntu.com/trusty-proposed/mako/index.json
[21:30] <sergiusens> doanac`, yeah, that doesn't exist anymore
[21:30] <doanac`> i've got this noted in our bug for that issue
[21:30] <robru> sergiusens, uh, something went wrong there.
[21:30] <sergiusens> doanac`, http://system-image.ubuntu.com/ubuntu-touch/trusty-proposed/mako/index.json
[21:30] <doanac`> i thought there were backward compatible links?
[21:30] <robru> sergiusens, silo 2 was supposed to be for goget
[21:30] <sergiusens> robru, yeah, line deletion during processing perhaps?
[21:30] <robru> sergiusens, could be.
[21:30] <doanac`> sergiusens: regardless, that's a trivial change
[21:30] <robru> sergiusens, gimme a sec to fix it
[21:30] <sergiusens> doanac`, great, I'm eager to know if I'm off the hook :-)
[21:31] <robru> sergiusens, lol, yeah, my thing is landed already
[21:31] <ybon> rsalveti: ok, thanks, I will try to ping him tomorrow (even if I will be in a workshop day)
[21:31] <ybon> I'm afraid map has been removed :s
[21:31] <sergiusens> doanac`, I thought so too from what stgraber told me
[21:31] <doanac`> sergiusens: our link doesn't exist anymore. plars looks like we need to do a quick reconfigure of our smoke jobs
[21:32] <sergiusens> doanac`, but they are links inside the channels.json, not at the filelayout level :)
[21:32] <doanac`> plars: i'll make a quick MP for us.
[21:33] <robru> sergiusens, ok, please click build on silo 2. despite what it says in the spreadsheet, jenkins knows to build goget.
[21:34] <ybon> (ping popey FYI in OSMTouch status)
[21:35] <sergiusens> robru, will do as soon as my view refreshes
[21:36] <sergiusens> ah
[21:36] <sergiusens> ok
[21:39] <sergiusens> robru, back to ofono, I get this now: http://<IP_ADDRESS>/job/landing-007-1-build/29/console
[21:40] <sergiusens> 2014-03-17 21:36:50,947 INFO Some source packages were never published in the ppa: ofono (1.12.bzr6858+14.04.20140317.1-0ubuntu1)
[21:40] <robru> sergiusens, damnit, that's the same thing that just happened to thomi
[21:40] <robru> thomi, did a rebuild fix it for you?
[21:40] <boiko> robru: I'm trying to understand the failure, do you have any idea what happened here: http://<IP_ADDRESS>/job/landing-009-1-build/30/console
[21:40] <thomi> robru: nope, same problem :(
[21:41] <robru> awesome
[21:41] <thomi> it just finished
[21:41] <thomi> heh.
[21:41] <thomi> "awesome" :)
[21:41] <sergiusens> thomi, thanks for making me feel not so lonely :-P
[21:41] <thomi> sergiusens: high five! o/
[21:41] <robru> boiko, well, that's the exact same problem that thomi and sergiusens just reported, so let's all dig in!
[21:41] <plars> sergiusens, doanac`: shouldn't the link take care of that?
[21:41] <sergiusens> cihelp is the jenkins bot still using a whitelist fo triggering jobs?
[21:42] <cjohnston> sergiusens: what job
[21:42] <sergiusens> plars, the explanation I gave doanac` should serve; we all understood incorrectly on what a link meant in stgraber's mind :-)
[21:42] <sergiusens> cjohnston, https://code.launchpad.net/~michael-sheldon/content-hub/peer_picker_ui/+merge/211092
[21:42] <boiko> robru: ah ok, I don't know much about the CI infrastructure, but I can try to find something if that helps
[21:42] <doanac`> plars, sergiusens: i think this is all we need: https://code.launchpad.net/~doanac/ubuntu-test-cases/system-image-url-update/+merge/211418
[21:42] <plars> doanac`: if not, then now is the time to do it - we need to regen the jobs so that the custom image changes are picked up (the normal images should be fine though)
[21:42] <sergiusens> cjohnston, we used to have this whitelist thing which never got to work with teams; and michael sheldon is new
[21:43] <plars> sergiusens: ah, I see
[21:43] <thomi> robru: so, both packages get uploaded (according to the logs anyway)
[21:43] <thomi> not sure what else to look at
[21:43] <robru> sergiusens, thomi, boiko: well it's very clear that the packages aren't getting uploaded. if you check the silos, the package names listed in the failure just aren't there.
[21:43] <sergiusens> plars, so the links are in the main channels.json :-)
[21:43] <cjohnston> sergiusens: looking
[21:44] <robru> cyphermox, any chance you can poke at this with us ^^^ jenkins is failing to upload packages to PPAs but the logs don't seem very useful.
[21:44] <doanac`> plars: shall i merge that change and regen the jobs?
[21:44] <robru> cyphermox, like I'm not seeing launchpad rejecting the uploads, just jenkins says it's uploaded and then launchpad never gets it
[21:44] <cjwatson> the failures there were because the librarian ran out of space
[21:44] <cjwatson> I'm getting things reprocessed
[21:45] <cyphermox> ah
[21:45] <plars> doanac`: just +1'd it - we could go ahead and change the custom-demo.py also, but I'm not sure it really matters
[21:45] <cyphermox> I was about to ping you or some other demi-god
[21:45] <robru> cjwatson, you mean the failures i'm talking about?
[21:45] <cyphermox> robru: yes
[21:45] <doanac`> plars: forgot those were separate configs
[21:45] <robru> cjwatson saves the day again! yay!
[21:45] <plars> doanac`: I made it a separate config on purpose, since I figured that would be the case
[21:45] <plars> doanac`: alternatively, I think we could just remove it
[21:46] <robru> thomi, sergiusens, boiko : ok sounds like cjwatson is on the case, we can force rebuild once he says so
[21:46] <cjwatson> robru: yes I do
[21:46] <sergiusens> great; thanks
[21:46] <plars> doanac`: but it's sorta nice as an example, and doesn't do anything on its own
[21:46] <thomi> awesome
[21:47] <doanac`> plars: i say we update it also. i'll patch that file and re-gen them
[21:48] <boiko> cjwatson: is the address-book-app promotion from trusty-proposed to trusty still blocked?
[21:49] <cjwatson> boiko: it's still waiting for https://code.launchpad.net/~cjwatson/address-book-service/powerpc-pie/+merge/211319, yes
[21:49] <doanac`> plars: jobs reconfigured and they've kicked themselves off.
[21:49] <cjwatson> boiko: you can see it on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[21:49] <plars> doanac`: ugh
[21:49] <plars> doanac`: because it's looking in a new location
[21:49] <cjwatson> boiko: looks like it should unblock shortly though
[21:49] <plars> doanac`: that's ok though
[21:50] <doanac`> yeah - the jobs hadn't run today
[21:50] <cjwatson> boiko: oh, bah, maybe not, address-book-service/powerpc still failed for some other reason
[21:50] <cjwatson> boiko: perhaps somebody who actually knows that code could look at it, rather than me trying to parachute in?
[21:51] <boiko> cjwatson: yes, I can get renato on it, but only tomorrow, he is gone already
[21:51] <cjwatson> sure
[21:53] <cjwatson> boiko: I can't do much more tonight either, anyway
[21:53] <cjohnston> sergiusens: the prereq has to be merged first
[21:53] <boiko> cjwatson: no problems, I will talk to renato tomorrow morning
[21:55] <boiko> cjwatson: just one question: is it possible to run the PPC build somewhere for testing?
[21:56] <cjwatson> boiko: https://wiki.canonical.com/InformationInfrastructure/ISO/BuildInfrastructure/PorterBoxes
[21:57] <rsalveti> popey: sergiusens: bug 1293797, is that because it still tries to update the app even if it's not compatible with the current framework?
[21:57] <cjwatson> boiko: ask #is to be added to the porting_team group if you aren't already; on porter-powerpc, use "schroot -c trusty-powerpc" to get into a trusty chroot, which you can then "sudo apt-get install" things in if you need to
[21:57] <popey> rsalveti: i believe so yes,
[21:57] <boiko> cjwatson: nice! I will do that (or ask renato to do that) tomorrow morning if we don't find the real problem before
[21:57] <boiko> cjwatson: thanks
[21:57]  * popey confirms
[21:59] <sergiusens> rsalveti, yeah, I put that in the email; not much we can do at this point wrt
[22:00] <sergiusens> cjohnston, the prereq has to be merged for the bot to run? that's a new req though
[22:00] <sergiusens> bfiller, ^^
[22:00] <cyphermox> boiko: the problem looks to me like you no longer build qtcontact5-galera from address-book-app, and it doesn't exist in the archive for powerpc to be used as a depends for address-book-app
[22:00] <cjohnston> sergiusens: I assume that it isn't smart enough to be able to merge the prereq and the required branch
[22:00] <cjohnston> then run the tests
[22:00] <cyphermox> it probably just needs to be dropped from the depends for address-book-app
[22:01] <cyphermox> oi, forget what I said, I was looking at -app, not address-book- service
[22:01] <boiko> cyphermox: so, qtcontacts5-galera comes from address-book-service I think, and it is failing to build on powerpc (tests failing)
[22:02] <cyphermox> yes
[22:02] <kgunn> silo 19 ready for publish
[22:02] <cyphermox> boiko: A connection to the bus can't be made
[22:03] <boiko> cyphermox: but that's after the tests were executed I think
[22:04] <cyphermox> indeed it is
[22:08] <boiko> cyphermox: I think the timeouts on the tests are not long enough, but I will create a branch replacing them by the correct implementation using QTRY_COMPARE() instead
[22:09] <cjwatson> oh, if it's just a timeout thing we could retry on sagari maybe
[22:09] <cjwatson> although it seems implausible that porter-powerpc wouldn't be fast enough
[22:10] <boiko> cjwatson: well, that's what I could infere from the source code of the failed tests
[22:10] <cjwatson> porter-powerpc is faster than most of our builders :-)
[22:10] <cjwatson> and it fails there
[22:11] <cjwatson> however, sagari's currently busy building a kernel
[22:12] <boiko> cjwatson: I think you are correct, one of the tests that failed was already using QTRY_COMPARE()  which waits long enough, might be something else
[22:12] <boiko> anyway, I will look into that tomorrow, I call it a day
[22:15] <kgunn> robru: if you want to publish silo 19 its ready...
[22:15] <robru> kgunn, ok, gotta test it a bit
[22:22] <sergiusens> popey, want to give this a quick test? https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=20
[22:22]  * popey clicks
[22:22] <popey> sergiusens: sure
[22:23] <popey> hang on, i already tested that
[22:24] <sergiusens> popey, yeah, but this time for the silo :-P
[22:24] <popey> uh ok
[22:24] <sergiusens> popey, I'm testing anyways; yeah, seems like double testing the same thing; but it's the way things are
[22:32] <robru> kgunn, seems pretty good, i'm just gonna let unity8 AP finish then publish
[22:44] <robru> tvoss, just published silo 17
[22:45] <popey> sergiusens: looks good
[22:51] <thomi> robru: cyphermox: did the silo publishing issue get fixed already?
[22:52] <robru> thomi, I think so. ask cjwatson though
[22:53] <thomi> cjwatson: ?
[22:54] <thomi> well, I'll kick it off anyway
[22:54] <robru> Saviq, hmmm in fact i can't reproduce that failure anymore
[22:54] <robru> thomi, yeah, i think i saw some builds working recently
[23:05] <sergiusens> robru, can we publish silo 002?
[23:06] <robru> sergiusens, on it
[23:09] <robru> sergiusens, done
[23:11] <sergiusens> thanks
[23:12] <robru> you're welcome
[23:20] <robru> ogra_, cyphermox, rsalveti: anybody around to kick an image build?
[23:20] <cyphermox> aye
[23:20] <robru> thanks
[23:21] <cyphermox> there. let's see if imgbot notices it better this time
[23:22] <cyphermox> what's this image for now?
[23:22] <robru> cyphermox, oh, well I landed a bunch of small stuff, and I'm about to land mir, and I want mir to have an image all to itself
[23:22] <robru> so I guess mir can be the last landing of the day, then cron can make a post-mir image
[23:23] <cyphermox> yes
[23:23] <cyphermox> i thought we were only landing safe stuff though
[23:23] <robru> cyphermox, well i've been testing stuff and it looks good
[23:23] <cyphermox> ok
[23:29] <imgbot> [23:29] <robru> nice
[23:36] <sergiusens> doanac`, hey, 241 was never triggered
[23:36] <sergiusens> plars, ^^
[23:57] <cjwatson> thomi: should be fixed, but I'm eod, any problems ask #launchpad-ops internal