[00:25] <kgunn> robru: i'm around in lieu of camako
[00:25] <robru> kgunn, I just wrote you an email ;-)
[00:25] <kgunn> weeee mail
[00:27] <robru> kgunn, long story short, mir is building ;-)
[00:28] <kgunn> robru: yeah, i actually read (most of) the backlog....what a tangled web of gcc shennanigans
[00:49] <slangasek> kgunn, robru: I see mir built now on armhf
[00:49] <slangasek> so yes, temporary bug in gcc-4.9 which would have been much more temporary if the silos were using -proposed
[00:51] <robru> slangasek, so clearly we need to identify the stakeholders and determine why it was chosen to disable -proposed in the first place, and make a case for enabling it permanently
[00:56] <slangasek> robru: yep, agreed; should we bring this up on tomorrow's landing team call?  or ubuntu-phone?
[00:57] <ogra_> PPAs are always defaulting to use -proposed
[00:57] <robru> slangasek, yep, the landing team call would be a good start. ultimately didier will been to be involved, beyond that I'm not sure who else (probably didier would know who else)
[00:57] <ogra_> we only had one occurence once where we explicitly disabled building from there when cjwatson recommended it to us to work around a breakage
[00:58] <robru> ogra_, currently all silos have -proposed disabled
[00:58] <ogra_> and that silo was definitely set back to "normal" (i.e. use -proposed)
[00:58] <ogra_> ugh
[00:58] <robru> ogra_, and I have no idea why, or who made that choice
[00:58] <ogra_> thats wrong and not desired ... i'm sure that sil2100 wasnt the one changing the default
[00:59] <ogra_> he knows we need to build with it enabled
[00:59] <robru> ogra_, last week I came close to enabling -proposed for all silos but backed down at the last second because i wasn't really sure what I was doing, or why it was set that way
[00:59] <ogra_> slangasek, robru, i'll carry it into tomorrows morning meeting
[00:59] <slangasek> ok
[01:00] <slangasek> I think we need to understand who made this change and why; will the right people be in the meeting to answer that question?
[01:00] <ogra_> i know that i set ppa-19 back to use proposed when we did the workaround ... and i see it still has that setting
[01:00] <robru> slangasek, well, there's a good chance that anybody related to citrain will be in that meeting. except for didrocks and asac, they won't be there and they might know something
[01:01] <ogra_> well, sil2100 should definitely know who changed it
[01:01] <ogra_> i dont thinnk asac knows or cares ... but didier might
[01:01] <ogra_> he will be online to ask at least ... even if he doesnt come to that meeting anymore
[01:02] <ogra_> looking through the current PPAs it seems rather random
[01:03] <ogra_> 18 and 19 both build with proposed
[01:03] <ogra_> 17 doesnt
[01:03] <robru> ogra_, I just enabled 16 and 18 today to workaround a failing build on arm
[01:03] <robru> ogra_, but last week when I was looking at this, they all had -proposed disabled
[01:03] <ogra_> robru, can you make sure it is enabled in all of them ?
[01:03] <robru> ogra_, yeah I can do that
[01:03] <ogra_> thanks
[01:03] <robru> you're welcome
[01:03] <ogra_> :)
[01:04]  * ogra_ wonders why he is chatting at 3am and slowly sneaks bedwards :) 
[01:05] <robru> ogra_, hm, did you do the first 10 already? somebody beat me to those ;-)
[01:05] <ogra_> nope, i didnt touch anything
[01:05] <ogra_> only looked
[01:06] <ogra_> (but from the other end)
[01:06] <robru> weird, so as of just now, 1-10, 16, 18, and 19 had them enabled, the rest were disabled. I enabled them all.
[01:06] <robru> but last week, I think on thursday, they were definitely all off
[01:07] <ogra_> i know for sure it was on when we disabled it for silo 19 back then
[01:08] <ogra_> and i never checked the others
[01:08] <robru> ogra_, did you somehow disable them all? ;-) I only know how to do it one at a time ;-)
[01:08] <ogra_> (assuming they would all use the same default)
[01:08] <robru> infinity, slangasek : https://launchpadlibrarian.net/177744514/buildlog_ubuntu-utopic-armhf.unity-scope-click_0.1%2B14.10.20140616-0ubuntu1_FAILEDTOBUILD.txt.gz unity-scope-click still failed even after rebuilding with -proposed.
[01:08] <ogra_> can general landers change the setup ?
[01:08] <robru> ogra_, I think you have to be in the ppa-service team (eg if you have upload rights to the silos)
[01:08] <ogra_> right
[01:09] <robru> ogra_, https://launchpad.net/~ci-train-ppa-service/+members#active 11 suspects...
[01:09] <slangasek> robru: ok; so one of the linkage failures is fixed, two still outstanding there
[01:09] <slangasek> I'll keep digging
[01:09] <robru> plus whoever can control ps-jenkisn...
[01:09] <robru> slangasek, thanks
[01:09] <slangasek> robru: which silo is this in?
[01:09] <robru> slangasek, that one's from 18
[01:09] <robru> slangasek, https://launchpad.net/~ci-train-ppa-service/+archive/landing-018
[01:11]  * robru EODish, still around if you need me though
[01:37] <kgunn> slangasek: thanks for the help
[02:04] <imgbot> [02:46] <kgunn> slangasek: just for the conversation about building against proposed...although the packages built, they wouldn't install
[02:46] <kgunn> b/c the packages in the image don't match what's in proposed
[02:46] <kgunn>  libmirclient7 : Depends: libstdc++6 (>= 4.9.0-7ubuntu1) but 4.9.0-6ubuntu1 is to be installed
[02:47] <kgunn> ...i started to go down the install proposed pocket packages path...but think i'll just wait a bit
[02:50] <robru> kgunn, is that just for armhf? I guess you should enable proposed on the device to be able to install ;-)
[03:29] <imgbot> [03:29] <imgbot> [04:16] <slangasek> kgunn: yes, installing them would then also require enabling -proposed
[07:16] <Mirv> sil2100: hey. I didn't publish the autopilot yet even though it's marked as tested. is there any background to that, or should we just publish it?
[07:17] <Mirv> dbarth: you've a branch, not MP, listed in that Chrome Extension
[07:17] <dbarth> uh
[07:20] <dbarth> Mirv: ok, now does that play ;)
[07:23] <Mirv> ok :)
[07:30] <Wellark> rsalveti: bug #1329945 should be fixed in ofono, not indicator-network
[07:30] <Wellark> it's the ofono percentages that are reported wrong
[07:31] <Wellark> it's ofono's job to scale whatever strenghts the modem reports to the range of 0-100 %
[07:36]  * Mirv has "Binder_2" consuming 100% CPU and only Google logo :(
[07:37] <Mirv> funnily the Binder_2 has pid that ps says is /system/bin/sensorservice instead
[07:45] <asac> slangasek: ogra_: to find the background story of -proposed in ci train, you need to check with didrocks
[07:46] <asac> he is in -touch etc.
[07:52] <sil2100> hmmm
[07:54] <asac> sil2100: all good?
[07:54] <asac> :)
[07:58] <sil2100> asac: yeah, just had some hardware failures here (unrelated)
[07:59] <sil2100> Mirv: ok, I checked this landing, it's good to go - I'll publish it in a moment
[07:59] <sil2100> Damn, #85 was a lucky build
[08:03] <sil2100> thostr_: hi! I see you have silo 13 for the 'forward-port' of HUD and I don't see it being built :)
[08:04] <sil2100> thostr_: could you move that silo further please?
[08:13] <thostr_> sil2100: in process of testing this right now
[08:15] <Mirv> is anyone else having "only Google logo shown" today more than earlier? I did --wipe --bootstrap but after upgrading to Qt 5.3 and reboot I was with google logo and probably not related in anyway to 5.3. also after downgrading I can't get anything on the screen.
[08:15] <Mirv> initctl gives "Unable to connect to Upstart: Empty address ''"
[08:17] <Mirv> historically I've seemed to end up in these situations occasionally, but this is a new record
[08:54] <cjwatson> slangasek: I think the argument for -proposed was to have silos be landable in isolation rather than being tied up in complex transitions, but it's clearly a two-edged sword.  My preference for a way forward would be for the new "airline" engine to have a simple switch for whether to build with -proposed or not, defaulting to on; if you needed to land something quickly that you knew was otherwise going to be tied up in a messy ...
[08:54] <cjwatson> ... transition then you'd turn it off
[08:58] <ogra_> cjwatson, the point was that seemingly the default was to have -proposed off ... which wasnt intentional but an oversight after utopic opened it seems
[08:58] <ogra_> (see #ubuntu-touch)
[08:58] <cjwatson> ogra_: Oh, interesting, I didn't know that was unintentional
[08:59] <ogra_> we used to have it on in trusty ... due to pre-release issues it was switched off apparently
[08:59] <ogra_> and forgottent to switch back ...
[08:59] <ogra_> -t
[09:06] <cjwatson> ogra_: this is probably inevitable with any system where the setting isn't automatically maintained
[09:06] <ogra_> well, only a few people can change it and usually we dont touch the default
[09:07] <cjwatson> Yeah, but it ought to be reset automatically when reconfiguring
[09:07] <ogra_> yeah, thats true
[09:07] <cjwatson> Otherwise drift is inevitable, in fact even more so because it's a rare thing people forget about
[09:08] <cjwatson> Hm.  Is this actually settable over the LP webservice?
[09:08] <ogra_> only for members of the owning team
[09:09] <cjwatson> well sure
[09:09] <cjwatson> I just couldn't find the setting in the apidoc
[09:10] <cjwatson> Oh, it's the ArchiveDependency on the primary archive
[09:11] <cjwatson> OK, yeah, that makes a degree of sense
[09:14] <popey> ~/48
[09:14] <popey> bah!
[09:26] <t1mp> Mirv: I installed landing-005 ppa with image 84, and now the device doesn't boot any more
[09:27] <t1mp> Mirv: it reboots, but gets stuck on the Google screen.. on desktop I get a message that nexus 4 cannot be mounted. I can still adb to the device
[09:27] <t1mp> perhaps the qt5 in the silo is broken?
[09:41] <brendand> popey, we have success
[09:41] <brendand> popey, let's get it out there
[09:42] <brendand> popey, i guess we should re-evaluate other tests suites that kill the keyboard and try and remove that (if they pass without it)
[09:43] <ogra_> ++
[09:43] <popey> awesome.
[09:43] <popey> brendand: can you leave a comment on the merge please?
[09:47] <oSoMoN> sil2100, hey, would you mind publishing silo 12 for me?
[09:47] <sil2100> oSoMoN: sure, just got the ping :)
[09:49] <sil2100> Ok, I see it was +1'ed by Didier, publishing!
[09:55] <Mirv> t1mp: nope, the PPA is working but the gcc just broke, so when you upgraded you got that too
[09:56] <t1mp> Mirv: this is weird right? http://pastebin.ubuntu.com/7657616/
[09:57] <asac> sil2100: will 84 be promoted?
[09:57] <asac> :)
[09:57] <t1mp> Mirv: I tried to flash image 83 to fix it, but it still is stuck at the google screen, and /etc/ubuntu-build says I have image 84...
[09:57] <sil2100> asac: most likely! QA is doing dogfooding and we're assessing the translations issue
[09:57] <asac> that would be fantastic. it has my pet bug fixed
[09:58] <sil2100> Pet bug? ;)
[10:00] <Wellark> is this a known problem?
[10:00] <ogra_> sil2100, yeah, he is always evil to his pet bugs and wants to kill them :P
[10:00] <Wellark> /usr/lib/gcc/arm-linux-gnueabihf/4.8/../../../arm-linux-gnueabihf/libprocess-cpp.so: undefined reference to `std::__once_call@GLIBCXX_3.4.11'
[10:00] <ogra_> Wellark, where do you see that ?
[10:04] <Wellark> ogra_: silo builds
[10:04] <ogra_> which silo
[10:04] <Wellark> like here: https://launchpadlibrarian.net/177764561/buildlog_ubuntu-utopic-armhf.dbus-cpp_3.0.0%2B14.10.20140617-0ubuntu1_FAILEDTOBUILD.txt.gz
[10:04] <Wellark> silo 2
[10:04] <Wellark> https://launchpad.net/~ci-train-ppa-service/+archive/landing-002/
[10:05] <ogra_> hmm, that should have built ...
[10:05] <ogra_> Wellark, see #ubuntu-devel ... there is a new gcc and a new libstdc++
[10:05] <ogra_> might be related
[10:05] <ogra_> (tell doko please)
[10:06] <sil2100> Seeing all this I'm really getting more afraid of building a new image ;)
[10:06] <Wellark> well, seems that process-cpp is broken in the archive
[10:07] <ogra_> Wellark, please tell doko about it, seems ot be fallout of the new gcc
[10:07] <ogra_> (or rather libstdc++)
[10:07] <sil2100> Wellark: right, best if you poke on -devel about this
[10:07] <sil2100> Why is it so that everytime a new gcc appears we get breakages on all fronts
[10:08] <ogra_> well, it is hard to silo a new gcc and test against the whole archive :)
[10:08] <ogra_> we usually only get a new toolchain at the beginning of a release cycle though
[10:09] <ogra_> so you dont see that fallout as much
[10:20] <ogra_> asac, wasnt your bug inside the gmail app ? you should be able to update that standalone
[10:21] <ogra_> (or was it in the webapp container ?)
[10:24] <asac> ogra_: hmm. right. i haven't setup my ubuntu one because i couldnt update without it, but that works now, so guess i should go ahead
[10:26] <Mirv> t1mp: ok I should have a easier to do fix for you now
[10:27] <davmor2> ogra_, sil2100: oh new shinies look at dialer, messaging and contacts
[10:27] <Mirv> t1mp: if you unpack http://people.canonical.com/~tjyrinki/gcc/fix_gcc.tar to your phone and use dpkg -i *.deb , everything should work again (both with and without Qt 5.3)
[10:27] <ogra_> davmor2, yep, saw it ... pretty useless on my flo though :) ... but i saw the changelog and looked at the start pacges of the apps already :)
[10:28] <davmor2> ogra_: contacts isn't if you add irc nicks :D
[10:28] <ogra_> yeah, my flo gets re-flashed to often, i never set up the google syncing there
[10:28] <sil2100> davmor2: yeah ;) Yesterday they wanted to land a redesign of those, right?
[10:28] <sil2100> Too bad the UITK bits didn't land with tit
[10:28] <sil2100> *it
[10:28] <sil2100> (not tit)
[10:29] <sil2100> -_-
[10:29] <davmor2> sil2100: it landed they look pruetty
[10:29] <ogra_> yeah
[10:29] <t1mp> Mirv: thanks! that did it http://pastebin.ubuntu.com/7657742/
[10:29] <ogra_> cant wait to actually see and use them on my phone
[10:30] <Mirv> t1mp: yeah. then if you need to dist-upgrade (eg. Qt 5.3 PPA or something), you need to dpkg -i *.deb those again afterwards (or one could use various other ways too of course)
[10:30] <sil2100> Oh, a downgrading tarball!
[10:43]  * sil2100 goes for lunch
[11:07] <popey> Mirv: when you have a moment, could you please upload http://s-jenkins.ubuntu-ci:8080/view/click/job/filemanager-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.filemanager_0.3.205_armhf.click to the store?
[11:14] <Mirv> popey: omg I feared for this day - the day something _changes_ so that I need to figure out the magic of click-toolbelt again. so, it might take some time.
[11:14] <popey> oof
[11:16] <Mirv> I've notes from the last time, when the official instructions was "do python setup.py install in a loop until it works"
[11:21] <popey> nice
[11:21] <popey> maybe your cert timed out?
[11:22] <popey> guessing now ☻
[11:35] <Mirv> popey: my error is ImportError: cannot import name _compare_digest
[11:36] <Mirv> ogra_: could you get https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.utopic.fix_qtsensors/+merge/223389 in? it's blocking Qt 5.3 (found out only now that the Qt Creator / SDK got functional)
[11:47] <Mirv> popey: done! https://bugs.debian.org/749491 's tip solved it for me (although I was unsuccessful in compiling/installing from a fresh checkout, the tip fixed the old installation dir)
[11:47] <ogra_> Mirv, added and uploaded
[11:48] <popey> thanks Mirv !
[11:49] <popey> sil2100: file manager updated in store, /cc brendand
[11:49] <sil2100> !
[11:49] <sil2100> :D
[11:49] <sil2100> popey: \o/
[11:49] <Mirv> thanks ogra_!
[12:03] <sil2100> Ok, I have to jump out to the dentist now...
[12:03] <sil2100> brb
[12:11] <thostr_> can anybody reconfigure silo 18?
[12:18] <rsalveti> Wellark: about bug 1329945, it shouldn't be fixed in ofono :-)
[12:18] <rsalveti> there was a thread in upstream mailing list about this already
[12:18] <rsalveti> it's not linear, and it's basically converting asu (1-31) to percentage
[12:18] <rsalveti> Wellark: we could change ofono to report asu instead, but then the same logic would apply in indicator-datetime
[12:20] <rsalveti> Wellark: and the tech specifics should also be handled in the client code
[12:20] <thostr_> is there anybody from the landing team online?
[12:21] <rsalveti> Wellark: https://lists.ofono.org/pipermail/ofono/2011-January/007827.html
[12:21] <ogra_> thostr_, Mirv and sil2100 ... (but sil is at the dentist)
[12:22] <thostr_> ogra_: thanks
[12:22] <thostr_> Mirv: can you reconfigure silo 18
[12:23] <seb128> thostr_, what did you change? did you add new components? if it's only mps from the same projects any lander can reconfigure
[12:24] <thostr_> seb128: we added a new component in order to get it finally compiling
[12:25] <seb128> k, I was just mentioning it in case
[12:25] <seb128> you need Mirv then I guess
[12:25] <thostr_> seb128: yep, trying... :)
[12:27] <t1mp> Mirv: if I add the qt53 ppa on my desktop, will that also break the compiler?
[12:32] <rsalveti> Wellark: updated https://code.launchpad.net/~rsalveti/indicator-network/change-signal-strength-thresholds-android/+merge/223344, can you please check that again
[12:32] <rsalveti> ?
[12:32] <rsalveti> and bug 1329945 as well
[12:32] <rsalveti> as I said, we can't simply change ofono to behave as you expected
[12:53] <asac> rsalveti: can you help thostr_ reconfigure a package in a silo?
[12:56] <Mirv> t1mp: I don't think the gcc-4.9 affects anything else than eg. platform-cpp that's being used on the phone and specifically uses gcc 4.9 (4.8 is still the default)
[12:56] <rsalveti> sure, that is the issue?
[12:56] <rsalveti> /usr/lib/gcc/arm-linux-gnueabihf/4.8/../../../arm-linux-gnueabihf/libdbus-cpp.so: undefined reference to `std::__once_call@GLIBCXX_3.4.11'
[12:56] <rsalveti> /usr/lib/gcc/arm-linux-gnueabihf/4.8/../../../arm-linux-gnueabihf/libdbus-cpp.so: undefined reference to `std::__once_callable@GLIBCXX_3.4.11'
[12:56] <rsalveti> yay \o/
[12:57] <rsalveti> when rebuilding indicator-network
[12:58] <asac> thostr_: ^^
[12:58] <asac> thostr_: what is the issue? rsalveti might be able to help
[12:58] <asac> 14:21 < thostr_> Mirv: can you reconfigure silo 18
[12:58] <asac> rsalveti: Mirv: ^
[12:58] <thostr_> rsalveti: that's the same issue we see also for scopes
[12:58] <rsalveti> crap
[12:59] <rsalveti> seems tvoss is not around
[12:59] <thostr_> rsalveti: tvoss might have a solution: https://code.launchpad.net/~thomas-voss/process-cpp/bump-so-name-and-major-version/+merge/223390
[12:59] <thostr_> but in order to test this I need somebody to reconfigure my silo
[13:00] <rsalveti> oh, this is painful
[13:00] <ogra_> rsalveti, known, libstdc++6 is broken
[13:00] <ogra_> doko is working on it afaik
[13:00] <rsalveti> bumping process-cpp is a pita
[13:00] <rsalveti> alright
[13:00] <ogra_> see backlog in #ubuntu-devel
[13:00] <ogra_> ate some peoples monrings already :)
[13:01] <rsalveti> right, seems to be in progress
[13:01] <rsalveti> will come back to this later then :P
[13:01] <ogra_> heh, yeah, we can largely stop all builds
[13:01] <ogra_> and wait for the fix ...
[13:02]  * ogra_ knows why he perfers packages full of shell scripts :P 
[13:02] <ogra_> (instead of C++ code)
[13:09] <Mirv> thostr_: done.
[13:09] <thostr_> Mirv: thanks
[13:09] <Mirv> it seems I skipped to timp's hilight earlier, sorry
[13:11] <Mirv> it looks like we'd have unity8/Qt crasher fixed now in 5.3
[13:11] <dobey> hmm
[13:11] <dobey> i don't think a reconfigure will fix it...
[13:16] <Mirv> popey: davmor2: if you have time, your ability to crash Unity 8 would be needed with the Qt 5.3 PPA - it seems to be Unity 8 crasher would be now fixed with Albert's fix that landed. note that you need unpack + dpkg -i *.deb the tarball from http://people.canonical.com/~tjyrinki/gcc/fix_gcc.tar to overcome the gcc-4.9 breakage in archives if you dist-upgrade
[13:16] <Mirv> it's the bug #1328485
[13:18] <t1mp> I think I ran into a new bug in Qt 5.3 https://bugs.launchpad.net/qtubuntu/+bug/1330977
[13:28] <Mirv> works fine here though :P but running Ubuntu in VM like in there might cause some difference
[13:28] <t1mp> note that in general (non-qt apps), mousewheel/2-finger scroll works fine
[13:31] <Mirv> so indeed I guess what'd be needed is Macbook user on native Ubuntu that'd test if there's a difference, or if it only happens in VM
[13:35] <kgunn> sil2100 Mirv ...so long story short, mir ftbfs last night for armhf, it was gcc4.9 bug fix stuck in proposed, so silo 16 got built against proposed...so it build but doesn't seem to boot...so i'm thinking
[13:36] <kgunn> silo 16 might need to get rebuilt again, but no against proposed...
[13:36] <kgunn> thots?
[13:37] <kgunn> ah...might be related to https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1328485/comments/12
[13:38] <dobey> thostr_, Mirv: i'm confused. why is process-cpp in silo 18?
[13:38] <Mirv> kgunn: yeah the gcc-4.9 is now in too, so no help in there
[13:39] <kgunn> Mirv: how do i see whether or not a silo will build against proposed or not ?
[13:39] <Mirv> dobey: I don't know myself why it was added specifically to that silo
[13:40] <Mirv> kgunn: I don't know, but from previous build logs like https://launchpadlibrarian.net/177743823/buildlog_ubuntu-utopic-armhf.mir_0.3.0%2B14.10.20140616.5-0ubuntu1_UPLOADING.txt.gz you can see that -proposed is in there.
[13:40] <thostr_> Mirv: it was added in an attempt to get it building
[13:41] <thostr_> dobey: ^
[13:42] <dobey> thostr_: unity-scope-click doesn't use process-cpp. the issue there is libunity-scopes-api. but i don't know if we should be rebuilding all the cpp libs in the silos just to try and get things building with the new libstdc++
[13:45] <sil2100> I hate dentists
[13:45] <dobey> sil2100: surely better than abi breakage in c++ compilers though
[13:45] <sil2100> ...true
[13:45] <sil2100> ;)
[13:47] <Mirv> popey: davmor2: installing the mediascanner2 enabled music-app with pkcon install-local got me a working music app on Qt 5.3
[13:47] <popey> Mirv: same here ☻
[13:47] <Mirv> yeah it seems pretty good, even if it has some known limitations at the moment
[13:47] <davmor2> Mirv: popey: \o/ nice to see that one line fix land ;)
[13:48] <popey> hah
[13:48] <Mirv> remaining Qt 5.3 blockers would be the UITK toolbar bug, and oSoMoN/chrisccoulson's Oxide landing (could we maybe have a pre-release to build against Qt 5.3 already?), and... hey, that was it?
[13:48] <dobey> this reminds me of that time when everyone in open source avoided c++ because gcc kept breaking abi
[13:48] <davmor2> popey: so is that going to land properly?
[13:48] <popey> yeah, once tests pass
[13:48]  * popey pokes balloons 
[13:49] <davmor2> popey: don't do that you might burst him
[13:49] <Mirv> and a third blocker whatever is needed from lool/pmcgowan regarding frameworks
[13:50] <dobey> popey: don't do that! the balloons will pop
[13:50] <Mirv> but we now have the SDK, Unity 8 crashes seem gone, music-app with that ^ .click package works. pretty awesome for today's fixes!
[13:51] <Mirv> oh and fourth blocker... rsalveti, are the -gles packages actually strictly speaking needed at the day of Qt 5.3 landing?
[13:51] <rsalveti> Mirv: yes
[13:51] <rsalveti> can try to get to that later today
[13:51] <rsalveti> is that the only blocker now?
[13:52] <rsalveti> Mirv: emulator is critical now, we can't regress it
[13:53] <mandel> sil2100, hello, can ou take a look at https://code.launchpad.net/~mandel/ubuntu-download-manager/leak-symbols/+merge/222472
[13:53] <Mirv> rsalveti: ok. when do you think you could look at the issue I emailed you about?
[13:53] <sil2100> mandel: hey! Let me take a look in a moment :)
[13:53] <Mirv> ok :)
[13:53] <mandel> sil2100, awesome, thx
[13:53] <Mirv> rsalveti: yeah I was mainly thinking if the emulator images are sort of snapshots that don't break at the moment something is upgrade, or if it needs to be always simultaneous
[13:53] <Mirv> rsalveti: but yes certainly we can't regress it
[13:53] <Mirv> rsalveti: I think the qtbase-gles in the PPA is properly synced, and if one could install the end result probably the other 6 package rebuilds wouldn't pose a problem. I also updated the qtdeclarative-gles there too but obviously it couldn't be built.
[13:54] <Mirv> qt3d, qtubuntu, ubuntu-ui-toolkit are just no-change rebuilds and qtmultimedia + qtlocation probably don't have much changes to think about
[13:54] <rsalveti> right, we just need to get base done correctly indeed
[13:54] <rsalveti> will try to get to it later today
[13:55] <Mirv> thanks
[13:58] <t1mp> Mirv: the no-scrolling in qt53 is quite annoying for me ;)
[13:58] <t1mp> Mirv: fyi, https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/fixEmptyToolbarQt53
[14:00] <Mirv> t1mp: use Ubuntu compatible hw :) but seriously, it's weird though what could be changing to make it incompatible inside VM or something like that, but of course the event handling does often see changes. but also weird that zsombor had the same problem on trusty / 5.2 too
[14:00] <Mirv> t1mp: awesome. did you check all of gallery + notes + dropping letters yet?
[14:00] <t1mp> Mirv: uhm. I fixed the non-visible toolbar items in notes-app.. but the UITK test still fails :s
[14:01] <Mirv> t1mp: hehe. better have gallery and dropping letters handy too if it seems tricky / volatile
[14:01] <t1mp> Mirv: no, I understood that zsombi did NOT have problems with either trusty or utopic with 5.2. Only with 5.3 he had problems
[14:01] <t1mp> zsombi: ^ right?
[14:02] <Mirv> t1mp: he said "< zsombi> Mirv: mine one never worked with mouse wheel"
[14:02] <t1mp> Mirv: mine == qtc with qt5.3
[14:03] <Mirv> t1mp: nope, he was using trusty (no 5.3 there), but then reported that 5.2 on utopic (different VM?) worked
[14:03] <t1mp> lets wait for zsombi to clarify
[14:03] <alan_g> cihelp: can you see what's different about the mako CI environment today? Mir is having a hard time that doesn't appear to relate to the MPs being built: https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/
[14:03] <zsombi> t1mp: like what?
[14:04] <t1mp> zsombi: did your mousewheel work in trusty and in utopic with qt5.2? And did it break with qt5.3?
[14:04] <zsombi> t1mp: mouse wheel scrolling with QtC or UITK gallery doesn't work with Qt5.3
[14:04] <t1mp> zsombi: and with qt 5.2?
[14:04] <zsombi> t1mp: it works like charm
[14:05] <t1mp> zsombi: ok, thanks for clarifying :)
[14:05] <t1mp> Mirv: ^ works fine with 5.2
[14:05] <Mirv> zsombi: and that's also on macbook with Ubuntu in VM? and it works also in 5.2+trusty, not just 5.2+utopic?
[14:05] <zsombi> Mirv: yes
[14:06] <t1mp> Mirv: I can also confirm that 5.2+trusty works fine inside the same vm
[14:06] <Mirv> ok, I'm adding the tag back and changing the subject a bit. thanks.
[14:06] <Ursinha> alan_g: hi, I'll have a look
[14:10] <stgraber> asac: I'm around now, what silo needs reconfiguring?
[14:15] <sil2100> kgunn: regarding landing line 9...
[14:16] <kgunn> yes?
[14:16] <sil2100> kgunn: I see it will lock many components, some of which are already allocated - you want an override for that? What is the ETA for this to land?
[14:17] <kgunn> AlbertA: ^
[14:17] <kgunn> sil2100 so we're ready now...but if we need to wait we will
[14:18] <kgunn> sil2100 so to answer more clearly, yeah, we wanna lock...
[14:18] <kgunn> if already locked projects, we'll need to wait
[14:23] <sil2100> kgunn: ok then, let's at least wait for one unity8 related silo to land
[14:28] <sil2100> mandel: so far looking at the symbols and the maps it looks really nice! This is why I like export maps, as then we only have the right symbols in symbols files in overall
[14:28] <mandel> sil2100, indeed, that was a great tip! I'll be using them from now on
[14:29] <sil2100> mandel: even though CI liked the merge, I'll just do a quick test build locally to test something and approve :)
[14:29] <dobey> export maps can be a huge pain though, with cmake
[14:29] <mandel> sil2100, sure, better safe than sorry
[14:29] <mandel> dobey, I did not have that many problems with them
[14:29] <mandel> and cmake :)
[14:29] <elopio> sil2100: this page has no instructions to test the mediaplayer
[14:29] <elopio> https://wiki.ubuntu.com/Touch/Testing
[14:30] <sil2100> Oh, hm
[14:33] <sil2100> elopio: the wiki doesn't want to load for me right now...
[14:33] <dobey> mandel: if you only have one .so, or all your .so builds  that link to the first .so have all required symbols under the same namespace, it's easy. but if you have a library and plug-ins for qml or other things that link to your .so, it can be a pain :)
[14:34] <elopio> sil2100: I can update it. But I would like to put the same command that jenkins uses, and I'm not sure which one is it.
[14:34] <asac> stgraber: think that is solved now :)
[14:34] <asac> stgraber: in general wonder if you know enough to help out on such things if sil is at lunch etc.
[14:34] <asac> thostr_: your silo reconfigure was solved, right?
[14:35] <mandel> dobey, I do have several .so and a qml plugin but the plugin is no allowed to use anything internal so it should throw errors if it uses private symbols, but I get the point, there are some of them I would have liked to hide even more
[14:35] <thostr_> asac: yes... however, we don't get anything build
[14:36] <sil2100> thostr_: what's wrong? Toolchain issues, or some other problems?
[14:36] <thostr_> yes, still gcc 4.8/4.9 issues
[14:36] <stgraber> asac: I can assign silos, reconfig, land, ... so long as Jenkins let me anyway (had some permission problems last week, hopefully it's all fixed now). Though I'm on US eastern so I doubt I'll be very helpful for when sil2100 is at lunch since I'll likely still be sleeping at that time :)
[14:36] <sil2100> I see that doko has a new gcc prepared in his PPA
[14:37] <dobey> mandel: yeah, the problem is that when you add the export map arguments to the target in cmake, cmake adds those export maps to any other targets that link to that target as well
[14:37] <sil2100> stgraber, asac: I guess normally when I'm having lunch Mirv is still around as support - this time the dentist was a bit unfortunate, as I'm not the one controllin the date and time for that one
[14:37] <mandel> dobey, really, even when you use set_target_properties?
[14:39] <dobey> mandel: i think so
[14:39] <sil2100> dobey: now that is something I didn't know, huh... well, never had problems with this as I only used those for simpler projects
[14:39] <sil2100> Where there was either one .so or 2-3 independent ones
[14:40] <mandel> dobey, , I've use nm a does not show other symbols, but I might just have been lucky
[14:40] <dobey> sil2100, mandel: i had problems with this when adding export maps to ubuntuone-credentials
[14:40] <dobey> mandel: well, the export map doesn't add symbosls that shouldn't be there
[14:41] <dobey> mandel: but it can block symbols from showing up, that should be there, in some cases :)
[14:41] <mandel> dobey, yes, but I have done nm on a target that was linked a diff one and saw no issues in udm
[14:42] <dobey> mandel: nm won't show you a list of symbols that you should have exported, but didn't. :)
[14:42] <mandel> dobey, I know, but I do look at the ones I'm expecting and all of them are there
[14:42] <mandel> again, might be luck
[14:44] <dobey> mandel: well, independent libs are independent. so there are a lot of things that can affect (or not affect) how it works
[14:45] <dobey> thostr_: i think we just need to wait for doko to get the libstdc++ issue fixed in the archive, then rebuild the silos
[14:45] <thostr_> dobey: yes
[14:46] <dobey> is there a silo that has something which actually uses process-cpp, in it?
[14:46] <asac> sil2100: dont worry. just trying to figure how more can help out :)
[14:46] <asac> think we have a gap in EU timezone still
[14:55] <kgunn> thostr_: just catching up on backlog a little...you able to build? or just not boot ?
[14:56] <kgunn> i was unable to build, but then they retargeted my silo to build against proposed...which built, but i can't seem to boot...and i suspect its related to this gcc churn still
[14:56] <kgunn> just wondering as a data point to support or deny my theory
[14:58] <lool> Mirv: hey, I'd like to add -dev2 frameworks in whatever silo the qt 5.3 landing gets; which one would that be?
[14:58] <lool> dont think touch-meta is CI-ed though
[15:01] <thostr_> kgunn: yes, both has issues
[15:07] <dednick> fginther: just taking a look at some unity-system-compositor/devel & platform-api/devel CI jobs, and they dont seem to be using the mir staging ppa (from devel) for building.
[15:08] <dednick> fginther: unity-mir/devel is doing it correctly. This someone added D09add_ppa~mir-team~staging hook into job params.
[15:08] <dednick> s/this/think
[15:10] <fginther> dednick, one moment
[15:12]  * elopio stands on the vanguard line.
[15:13] <elopio> fginther: the messaging app jobs fail to install ofono. Could be a chroot problem.
[15:16] <fginther> dednick, I can get that added shortly
[15:16] <dednick> fginther: thanks!
[15:20] <fginther> elopio, I'm assuming this isn't normal:
[15:20] <fginther> /var/log/upstart/otto-setup.log: Setting up ofono (1.12.bzr6868+14.10.20140513.1-0ubuntu2) ...
[15:20] <fginther> /var/log/upstart/otto-setup.log: invoke-rc.d: unknown initscript, /etc/init.d/ofono not found.
[15:20] <fginther> /var/log/upstart/otto-setup.log: dpkg: error processing package ofono (--configure):
[15:20] <fginther> /var/log/upstart/otto-setup.log:  subprocess installed post-installation script returned error exit status 100
[15:21] <dobey> thostr_, asac: can we move process-cpp out of silo 018? unity-scope-click doesn't use it, and I don't want the process-cpp change to require gcc-4.9 to be blocked on libstdc++ abi compat issue being fixed or all the libs being rebuilt, when unity-scope-click doesn't use the library
[15:21] <elopio> fginther: yes, that's the problem.
[15:21] <elopio> I have the same version working without problems on my machine.
[15:21] <elopio> and the tests pass on mako. The error is only on trusty.
[15:21] <elopio> s/trusty/utopic
[15:22] <elopio> on the jenkins' utopic.
[15:25] <thostr_> dobey: removed.
[15:25] <thostr_> sil2100: can you reconfigure silo 18
[15:26] <sil2100> thostr_: sure
[15:26] <dobey> thanks
[15:27] <sil2100> thostr_: done
[15:27] <thostr_> sil2100: thanks
[15:32] <fginther> alan_g, I compared the package list from the passing run to the failing run, about the only difference is a new gcc 4.9.0-6ubuntu1 -> 4.9.0-7ubuntu1
[15:32] <fginther> alan_g, at least that's what is different in the mako image
[15:33] <fginther> alan_g, all 4 of the test failures appear to be the same segmentation fault in mir_performance_tests
[15:33] <alan_g> fginther: thanks.
[15:42] <fginther> dednick, unity-system-compositor/devel & platform-api/devel CI jobs are updated now
[15:43] <dednick> fginther: thanks
[15:43] <fginther> dednick, will also make sure the others are updated while I'm at it
[15:44] <alan_g> kgunn: ^^
[15:58]  * ogra_ will be a moment late to the meeting (finishing dinner)
[15:58] <sil2100> ogra_: ok
[16:14] <fginther> elopio, I have no idea yet why ofono is failing to install. I tried some live debugging on one of the otto nodes, but it installed cleanly. I'll take a closer look at what it's doing after lunch
[16:19] <thostr_> asac: ogra_: sil2100: doko says the package is about to be published. could you ping us (or everybody) once it is actually published so that we can start trigger builds
[16:19] <ogra_> its in afaik
[16:19] <ogra_> and the silos build against proposed anyway
[16:19] <ogra_> so you should be good
[16:19] <thostr_> ogra_: ok
[16:19] <elopio> fginther: thanks. sergiusens also said that it could be systemd. And awe was the last to touch the package, so they might be able to help you.
[16:26] <popey> what is /system/bin/sensors.qcom ?
[16:27] <popey> thats taking 10% of my cpu after the reboot
[16:27] <popey> as is messaging app
[16:27] <ogra_> ricmm, ^^^^
[16:27] <popey> nowhere near as bad as it was, but still
[16:27] <popey> http://paste.ubuntu.com/7659216/
[16:28] <popey> thats with the screen off
[16:28] <popey> shouldn't these apps be paused ?
[16:28] <ogra_> "these apps" ?
[16:28] <popey> messaging, apps which I started
[16:28] <ogra_> i only see messaging-app
[16:29] <popey> right, previously it was addressbook, this time it is messaging
[16:29] <ogra_> yes, it should be sigstopped after a while
[16:29] <popey> oh, its a deb, these aren't constrained are they?
[16:29] <ricmm> popey: is that withthescreenlocked?
[16:30] <ricmm> arghh this keyb
[16:30] <popey> yes
[16:30] <imgbot> [16:30] <ricmm> popey: does it go to sleep when dismissing to the right?
[16:31] <popey> uh, i have no apps foregrounded
[16:31] <popey> I'm sat at the app scope
[16:31] <popey> and address-book is eating 40% now
[16:31] <popey> sil2100: ^
[16:31] <ricmm> so address-book does the 40% every now and then
[16:31] <ricmm> renato can tell you more about that one
[16:31] <ricmm> but it not sleeping is a whole different issue
[16:31] <popey> define "every now and then"
[16:31] <ricmm> can you test other apps?
[16:31] <ricmm> dismiss and so on
[16:31] <popey> define "dismiss"
[16:32] <popey> close in app scope?
[16:32] <ricmm> swipe back to shell
[16:32] <popey> right
[16:32] <ricmm> so send to bg
[16:32] <popey> k
[16:32] <popey> whatever app I open, and swipe away, if I get back to app scope, address-book is always eating 40%#
[16:32] <ogra_> [16:33] <ogra_> :)
[16:33] <popey> swine ☻
[16:33] <sergiusens> popey: close the camera app and see if the sensor cpu consumption lowers
[16:33] <ricmm> so my question is if the *other* apps you open, get suspended
[16:33] <ricmm> once you go back to the dash
[16:33] <ogra_> heh
[16:33] <ricmm> they should be suspended 3 seconds after you show the dash
[16:33] <popey> yes
[16:33] <ricmm> ok, so just address book
[16:33] <popey> addres-book does too sometimes
[16:33] <ricmm> sometimes? wth
[16:34] <ricmm> so wait out a full 4 seconds before checking if its suspended
[16:34] <ricmm> when you swipe to dash
[16:34] <popey> its all good now
[16:34] <popey> but earlier, it was eating 40%
[16:34] <popey> and I had that after reboot, then re-open those apps
[16:34] <ricmm> right, about that, I remember renato saying something about it in malta
[16:34] <popey> sergiusens: i dont have camera open
[16:34] <ricmm> but I dont know details, sorry
[16:35] <popey> ok
[16:35] <davmor2> popey: so for me I've just done a reboot syncevo- .... was using 93% for 3-5 seconds and now is fine.  highest cpu usage now is top at 2.)%
[16:35] <ricmm> the 10% CPU in sensors.qcom and *-app is a known issue
[16:35] <davmor2> 2.0% even
[16:35] <popey> ok
[16:35] <ricmm> and will be solved with my soon-to-land orientation work
[16:35] <popey> thanks ricmm
[16:35] <ricmm> or re-orientation
[16:35] <popey> if it's all known then good good
[16:36] <popey> renato: got a bug for the 40% address book cpu eating?
[16:36] <renato> popey, ricmm, yes I saw that once, but I was unable to figure out what was happening
[16:36] <renato> popey, are you able to reproduce it?
[16:36] <popey> I have had it twice in the last hour
[16:36] <popey> i have 350 contacts if that makes any difference
[16:37] <popey> and two google accounts setup to sync
[16:37] <renato> popey, I do not think so I am testing with 1500 contacts :D
[16:37] <popey> get you mister friends!
[16:38] <davmor2> popey: and I thought you had too many ;)
[16:39] <robru> seb128, you got silo 12
[16:44] <popey> renato: filed a bug for it bug 1331078
[16:44] <renato> popey, thanks
[16:44] <popey> np
[16:45] <dobey> wheeeeeee :(
[16:51] <dobey> so new binutils didn't quite fix things, eh?
[16:52] <davmor2> popey: yay 6 reboots and now I see it but only when the addressbook is in the foreground the minute I switch to another app or close the addressbook it goes down to 0
[16:53] <t1mp> Mirv: would you like to review this? https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/fixEmptyToolbarQt53/+merge/223412
[16:54] <t1mp> Mirv: did you notice an invisible header in galler-app with qt 5.3? I don't know if that bug exists with qt 5.2
[16:54] <davmor2> popey: 4196 phablet   20   0  260964  61376  32380 T  0.0  3.3   0:53.33 address-boo+
[16:55] <davmor2> in foreground  4196 phablet   20   0  260964  61376  32380 S 45.5  3.3   0:55.98 address-boo+
[16:55] <popey> davmor2: tap power rather than swipe the app away
[16:56] <davmor2> popey: slowly drops to 0.0 again
[16:57]  * dobey wonders what to do about gcc 4.9 breakage
[16:58] <davmor2> dobey: it's been fixed apparently unless there is another breakage
[16:59] <dobey> davmor2: it's still broken on arm afaict. the missing symbols in libfoo issues are gone now, but the previous issue of missing symbols in the thing being built, is back
[16:59] <dobey> https://launchpadlibrarian.net/177798305/buildlog_ubuntu-utopic-armhf.unity-scope-click_0.1%2B14.10.20140617.5-0ubuntu1_FAILEDTOBUILD.txt.gz
[16:59] <dobey> aka, back to where we started :-/
[16:59] <ogra_> dobey, that must be on your side, doko reverted everything
[17:00] <Laney> nein
[17:00] <Laney> https://bugs.launchpad.net/ubuntu/+source/gcc-4.9/+bug/1329089/comments/9
[17:00] <dobey> ogra_: reverted? he uploaded a new snapshot of binutils is all
[17:00] <Laney> someone retried evo though, so watch if that works
[17:00] <Laney> https://launchpad.net/ubuntu/+source/evolution/3.12.2-1ubuntu1/+build/6105753
[17:00] <ogra_> dobey, he uploaded a complete revert in that new revision
[17:01] <dobey> ogra_: that's not what the diff says
[17:02] <ogra_> gcc-4.9 (4.9.0-7ubuntu2) utopic; urgency=medium
[17:02] <ogra_>   * Revert the fix for libstdc++/60326, introducing PR libstdc++/61532.
[17:02] <ogra_> thats what the changelog says here
[17:02] <dobey> ogra_: oh, i was looking at binutils
[17:03] <ogra_> dobey, which PPA/silo is that ?
[17:03] <dobey> ogra_: 018
[17:03] <dobey> it's only failing on arm
[17:03] <ogra_> says published  34 mins ago ...
[17:04] <ogra_> you might have just had an unlucky timing
[17:04] <dobey> the build log has the 4.9.0-7ubuntu2 version of libstdc++6
[17:04] <dobey> so that reversion is there
[17:04] <ogra_> hmm, then i dont know
[17:04] <dobey> but it's the same compilation issue on arm that we started with in the ppa yesterday
[17:05] <ogra_> slangasek, ^^^^ any idea ? that should build now as i understand it
[17:06] <dobey> the MP that's being merged in that silo built fine on arm in jenkins
[17:06] <slangasek> ogra_: olli_ has escalated this silo 018 failure to me
[17:06] <ogra_> ah, k
[17:06] <slangasek> this is a different failure than the one before, and resembles the earlier failures from gcc-4.9 4.9.0-6ubuntu1
[17:06] <dobey> looks like jenkins already has a libstdc++6 and -dev package installed before it starts the build though, so i can't tell what it has
[17:06] <dobey> right
[17:08] <slangasek> unity-scope-click seems to have also changed in the silo; so I'm test-building the new version with the previous libstdc++
[17:08] <dobey> slangasek: yeah, there is a change that introduces usage of std::unordered_set, which i suspect is the root of why this is happening there
[17:10] <dobey> i don't understand what gcc would be doing different on arm for that though
[17:36] <ogra_> sil2100, no mail today ?
[17:36] <sil2100> ogra_: writing it now, got preempted ;)
[17:36] <ogra_> :)
[17:36] <sil2100> My scheduler is sometimes really aggressive
[17:37] <ogra_> mine is only surprising :)
[17:37] <ogra_> (when unexpected meetings pop up and the like)
[17:45] <imgbot> [17:45] <imgbot> [17:45] <slangasek> dobey: building current unity-scope-click with previous libstdc++6 does not hit this error (it hits the previous error of std::__once_callable).  So the latest regression seems to again be on the gcc side, not on the unity-scopes-click side.
[17:46] <slangasek> although, I do notice now that the actual failing reference (from the original failure) is from /usr/lib/arm-linux-gnueabihf/libunity-scopes.so, not from anything in the tree; perhaps libunity-scopes needs a rebuild
[17:46] <slangasek> (independent of the latest gcc problem)
[17:47] <dobey> slangasek: original failure? i didn't see libunity-scopes in the original failure (this is the same failure as original, that i'm seeing now)
[17:47] <slangasek> dobey: sorry, by "original" I mean the one with gcc 4.9.0-7ubuntu1
[17:47] <dobey> the libunity-scopes missing symbols failure occurred prior to doko's latest reversion
[17:48] <dobey> slangasek: one sec, let me look at the gcc upload history
[17:50] <dobey> slangasek: ok, so the issue with -7ubuntu1 could possibly be fixed by rebuilding libunity-scopes-api and everything it in turn also depends on (rebuilding it alone i expect might fail with similar errors to what we got with it)
[17:50] <slangasek> maybe
[17:50] <slangasek> looking into it now
[17:51] <dobey> slangasek: but that won't fix the issue now with -7ubuntu2 i don't think
[17:51] <slangasek> correct
[17:51] <slangasek> but if that means there are two issues, I want to make sure we've got a handle on how to fix both of them so we're not losing more time to this
[17:51] <dobey> right
[17:52] <dobey> i just don't want to also lose time rebuilding the world with 4.9, and then having this same issue still re-appear again afterword
[17:55] <dobey> slangasek: thanks for looking into this. i wish i could be more help
[17:55] <slangasek> it's not your responsibility to deliver a working toolchain, it's ours ;-P
[17:56] <dobey> slangasek: indeed. but i like to understand what's broken when it's affecting my code :)
[17:57] <renato> popey, I have a branch to you to test: https://code.launchpad.net/~renatofilho/address-book-app/fix-1331078/+merge/223458
[17:58] <sil2100> ogra_: https://plus.google.com/109159869108744115904/posts/SJ69CfvNPyc
[18:00] <Ursinha> /ci/topic
[18:00] <Ursinha> argh
[18:21] <popey> renato: will take a look a bit later.
[18:37] <sil2100> Ok, I guess it's time for me to EOD, see you guys tomorrow o/
[18:55] <kgunn> robru: mind unpointing silo16 at proposed?
[18:55] <kgunn> seems i'm getting ftbfs there
[18:56] <robru> kgunn, silo 16 has proposed enabled
[18:56] <robru> oh "unpointing", thought you said "updating"
[18:56] <kgunn> robru:  no worries...i should use better speech
[18:56] <robru> kgunn, ok, proposed disabled, give it a shot
[19:00] <tedg> What's the status of the gcc 4.9 transition?
[19:00] <tedg> Silo tomorrow or risk today? :-)
[19:08] <robru> tedg, kgunn seems to still be struggling
[19:10] <tedg> robru, He's an aggie though. I mean real people :-)
[19:10] <robru> aggie?
[19:10] <tedg> Texas A&M graduate. A fair number of "blond jokes" in Texas are aggie jokes.
[19:10] <robru> heh
[19:11] <robru> tedg, so anyway, slangasek or dobey would be the best people ask about the gcc thing.
[19:11] <tedg> robru, Example: Did you hear about the Aggie that moved to Louisiana? Raised the average IQ in both places.
[19:11] <dobey> s/or dobey//
[19:11] <robru> ouch
[19:13] <tedg> robru, Do know some examples of the failures. I'm seeing something on gcc4.8 that is weired with process-cpp. Not sure if it's migrated and seeing the reverse transition.
[19:14] <robru> tedg, got a log?
[19:14] <tedg> robru, https://launchpad.net/~ted/+archive/ppa/+build/6106103/+files/buildlog_ubuntu-utopic-i386.pay-service_0.1%2B14.10.20140602-0ubuntu1_FAILEDTOBUILD.txt.gz
[19:15] <slangasek> tedg: so far the issues we've been seeing have been link-time; I don't know anything about test suite failures
[19:15] <tedg> Okay, might be something else then.
[19:15] <tedg> Just kinda weird. Doesn't happen locally.
[19:16] <slangasek> tedg: unless it's the case that this is one of the libraries that requires revdeps to be built with the matching compiler
[19:16] <slangasek> actually, process-cpp is listed on bug #1329089
[19:16] <slangasek> but tvoss marked it as not affected
[19:16] <robru> tedg, I dunno much about this C++ stuff. your thing is just a test failure though, kgunn was having some build failures before even testing
[19:17] <slangasek> tedg: might be worth checking with tvoss; might also be worth checking if building pay-service with g++-4.8 instead of g++-4.9 makes a difference.
[19:17] <slangasek> tedg: were you reproducing locally on i386 or amd64?
[19:17] <slangasek> (s/reproducing/failing to reproduce/)
[19:17] <tedg> slangasek, That seemed to be built with 4.8, not sure why that is, but I was curious if that was the issue.
[19:17] <tedg> PPA fails on both.
[19:17] <slangasek> ok
[19:18] <slangasek> all of the fixes we've been slathering on gcc-4.9 have been link-time changes, so this is either bug #1329089 or an unknown issue
[19:19] <slangasek> ah, but this build is with the current gcc-defaults, so you are using gcc-4.8 for the build anyway
[19:19] <slangasek> g++-4.8, even
[19:19] <slangasek> and process-cpp hasn't been rebuilt since May, so that's also unrelated here
[19:20] <slangasek> tedg: so unless there's another library in your stack, other than process-cpp, affected by bug #1329089, it appears to be an unrelated issue
[19:21] <tedg> It could be me just screwing up too :-)
[19:24] <slangasek> well, whatever it is, it doesn't look related to gcc-4.9 AFAICS
[19:24] <slangasek> the sure way to rule that out, if you can reproduce it, is to try downgrading libstdc++6 to the trusty version and rerunning the test
[19:25] <kgunn> slangasek: uh....i'm getting FTBFS again...
[19:25] <kgunn> /usr/lib/gcc/arm-linux-gnueabihf/4.8/../../../arm-linux-gnueabihf/libmirserver.so: undefined reference to `std::__once_functor@GLIBCXX_3.4.11'
[19:26] <kgunn> same 2 funcs tvoss was mentioning
[19:26] <kgunn> sorry meant to paste
[19:26] <kgunn> https://launchpadlibrarian.net/177815633/buildlog_ubuntu-utopic-armhf.unity-system-compositor_0.0.3%2B14.10.20140617.4-0ubuntu1_FAILEDTOBUILD.txt.gz
[19:29] <dobey> tedg: is there a single MP for that pay-service build? or is it a bunch of MPs?
[19:30] <tedg> dobey, I moved it into a single
[19:30] <dobey> tedg: what's the url for the MP?
[19:30] <tedg> dobey, It's a secret! :-)
[19:30] <tedg> dobey, https://code.launchpad.net/~indicator-applet-developers/pay-service/devel/+merge/223106
[19:33] <dobey> tedg: and what ppa was that build failure in?
[19:34] <tedg> dobey, Just mine.
[19:34] <tedg> Virtualized, nothing special, etc.
[19:35] <dobey> oh it failed on amd64 too
[19:35] <dobey> weird
[19:35] <tedg> Yeah, trying trusty
[19:36] <tedg> Just to remove that variable.
[19:36] <tedg> It's an odd failure though. And didn't happen on Jenkins.
[19:36]  * tedg blames Launchpad ;-)
[19:37] <dobey> yeah i think it's unrelated to the gcc 4.9 stuff
[19:39] <dobey> on the other hand, you did change that code :)
[19:40]  * tedg claims bzr blame is a liar
[19:41] <slangasek> kgunn: yes, __once_functor has gone away again between 4.9.0-7ubuntu1 and 4.9.0-7ubuntu2; it was not present in libstdc++6 from 4.8; we should try a no-change rebuild of libmirserver
[19:42] <kgunn> slangasek: that's exactly what i _think_ i had done, e.g. force rebuild/ignore
[19:42] <slangasek> this doesn't help with the unity-scope-click failure, which is about __get_once_mutex() refs being generated by the headers; but a no-change rebuild of libmirserver should fix that unity-system-compositor build failure
[19:42] <slangasek> hmm
[19:42] <slangasek> which ppa is this in?
[19:43] <slangasek> 016
[19:44] <slangasek> mir failed to build
[19:44] <slangasek> and unity-system-compositor needs mir rebuilt first
[19:44] <kgunn> slangasek: mir is listed first in the mp list...
[19:44] <kgunn> this is how it always builds
[19:45] <slangasek> kgunn: sorry, not sure what you mean
[19:45] <slangasek> the order of the mps in the landing does not enforce ordering of the builds
[19:45] <slangasek> you would need versioned build-dependencies to do that
[19:45] <kgunn> slangasek: hmmm, not what didier said long ago...
[19:45] <kgunn> slangasek: my silos would fail constantly...unity-mir, usc, platform-api are all rdeps of mir
[19:46] <kgunn> so mir has to build first
[19:46] <slangasek> regardless, the mir it's building against was built against libstdc++6 4.9.0-7ubuntu1; we need it rebuilt (successfully) against libstdc++6 4.9.0-7ubuntu2 and u-s-c to be retried against it once built
[19:46] <dobey> well, it doesn't matter which one builds first, if the builds are failing anyway
[19:46] <slangasek> well, in this case all of these packages were being tried in parallel
[19:46] <kgunn> slangasek: and those rdeps are version dep'd on mir
[19:47] <kgunn> in fact that is the only change for those (e.g. mir >= 0.3.0)
[19:47] <slangasek> but there's already a mir >= 0.3.0
[19:47] <slangasek> and it has the wrong abi and needs rebuilt
[19:47] <kgunn> slangasek: how so? i'm doing force-rebuild...it should be blown away
[19:47] <dobey> kgunn, slangasek: mir failed to build on arm in that silo, for similar reasons as to why unity-scope-click is failing, afaict
[19:47] <slangasek> evidently it's still in the ppa?
[19:48] <kgunn> if it doesn't blow away the new version of mir in the ppa then that _is_ a bug
[19:48] <kgunn> robru: ^
[19:48] <dobey> /usr/include/c++/4.8/mutex:779: undefined reference to `std::__get_once_mutex()'
[19:48] <kgunn> wouldn't you agree
[19:48] <slangasek> anyway, root cause - mir ftbfs,
[19:48] <slangasek> /usr/include/c++/4.8/mutex:779: undefined reference to `std::__get_once_mutex()'
[19:48] <kgunn> slangasek: agreed
[19:48] <tedg> I think that's a "fix with CI Airline" bug.
[19:48] <robru> robru, what's going on? build is failing because of previous silo contents?
[19:48] <kgunn> tedg: thanks ted :P
[19:48] <kgunn> robru: not necessarily
[19:49] <slangasek> robru: that appears to be the implication; kgunn wanted u-s-c in https://launchpad.net/~ci-train-ppa-service/+archive/landing-016/+packages built against the mir there, but mir ftbfs on armhf and u-s-c was still tried
[19:49] <tedg> kgunn, No, seriously. I think it's the same thing that bit ricmm with the platform API versioning.
[19:49] <robru> kgunn, you're right that CI Train is sloppy about previous silo contents. if necessary I can move you to a different one
[19:49] <kgunn> robru: let's do that
[19:49] <slangasek> robru: all that would do is make the package dep-wait
[19:50] <robru> slangasek, right, as infinity advised, but then we can retry the build
[19:50] <robru> right?
[19:50] <slangasek> there's no build for you to retry
[19:50] <slangasek> need to sort out the toolchain breakage under mir
[19:50] <robru> slangasek, well, after I upload to a new silo there would be
[19:50] <slangasek> no, retrying the build would be a waste of time
[19:50] <robru> slangasek, ok, let me know what I can do to help ;-)
[19:51] <slangasek> robru: you could remove the old mir binary packages from the silo, if you want? :)
[19:51] <slangasek> then when we get this fixed it should retry automatically
[19:51] <robru> slangasek, just mir or blow away the whole silo?
[19:51] <slangasek> robru: just the /old/ mir binaries
[19:51] <slangasek> no need to take out the successfully-built amd64/i386 binaries from the current source
[19:52] <slangasek> ->lunch
[19:52] <kgunn> this seems not copacetic
[19:52] <kgunn> then you've got sort of mish-mash of built-against-archive per archs....
[19:53]  * dobey notes we have too many things that get abbreviated as u-s-c
[19:53] <robru> slangasek, kgunn ok well I've deleted all the superseded binaries
[19:54] <kgunn> robru: ack
[19:54]  * kgunn goes to look at ppa
[19:54] <robru> kgunn, it'll probably look mostly the same since the newest-built binaries are still there
[19:54] <kgunn> and btw, tedg...yeah you're right
[19:55] <kgunn> robru: curious...is there a way to target just armhf ?
[19:55] <robru> kgunn, not that I know of... not in a ppa anyway. locally crossbuilding is a thing
[19:56]  * tedg assumes that kgunn means he was right about the aggie jokes
[19:56] <kgunn> stop it tedg
[19:56] <kgunn> :)
[20:02] <kgunn> dobey just a double check, so https://code.launchpad.net/~thomas-voss/process-cpp/bump-so-name-and-major-version didn't help you ?
[20:02] <dobey> kgunn: no, unity-scope-click doesn't use process-cpp
[20:02] <dobey> so rebuilding it with gcc 4.9 would be completely useless for us :)
[20:08] <tedg> Uhg, fails on trusty too. So odd.
[20:12] <dobey> tedg: what commands are those tests running exactly?
[20:13] <tedg> dobey, brings up the dbus interfaces and throws a few messages at it. gdbus.
[20:16] <dobey> tedg: but what is the command process-cpp is running exactly? it could just be the commands are failing to start because of permissions restrictions on the launchpad builders, which don't exist in jenkins or locally
[20:17] <robru> dobey, mhr3: you guys want a reconfig on silo 18? I see a new MP in there that wasn't part of the original build
[20:17] <tedg> dobey, It's running under dbus-test-runner, so that should be building the dbus session for the tests.
[20:17] <dobey> robru: what new mp?
[20:18] <robru> dobey, somebody added https://code.launchpad.net/~thomas-voss/process-cpp/bump-so-name-and-major-version/+merge/223390 into your unity-scope-click in silo 18
[20:18] <dobey> robru: no, that MP should not be in silo 18
[20:18] <robru> but just in the spreadsheet, it hasn't been reconfigured or built yet
[20:18] <dobey> robru: it was reconfigured/built there earlier, but it is completely unrelated to unity-scope-click
[20:19] <dobey> robru: it should be removed from the silo config
[20:19] <robru> dobey, ok, not sure how that got there, but I pulled it out
[20:19] <dobey> or i guess just from the spreadsheet if that's the only place it appears
[20:19] <robru> yeah
[20:20] <robru> unfortunately I have no way of knowing who put that in the spreadsheet there.
[20:21] <dobey> robru: there was some confusion about all the build failures this morning and thostr_ asked for it to be added to the silo. i later asked for it to be removed, as it's unrelated to the scope, and i didn't want the scope failing to block landing process-cpp if that change needs to land for other things
[20:21] <robru> dobey, ah ok
[20:29] <kgunn> robru: hey mind punching reconfig on silo16 ? on tvoss' advice gonna give his mp a shot
[20:30] <robru> kgunn, alright
[20:31] <robru> kgunn, oh you need the MP URL, not the branch URL
[20:31] <kgunn> damn it...doh!
[20:32] <kgunn> robru: ok...now
[20:33] <robru> kgunn, alright you are go for build
[21:22] <dobey> slangasek: hey. just curious if you've been able to figure anything out yet with the once_mutex stuff
[21:26] <kgunn> robru: well...that was interesting...fail, can you reconfig silo16 again ?
[21:28] <robru> kgunn, sure
[21:29] <robru> kgunn, done
[21:30] <kgunn> ta
[21:35] <oSoMoN> robru, hey, can we publish silo 7 ?
[21:36] <robru> oSoMoN, well, it's not marked testing pass. did you test it?
[21:36] <robru> actually not even built ...
[21:36] <robru> weird status
[21:36] <oSoMoN> robru, yes, packages were copied from another PPA over to the silo
[21:37] <oSoMoN> robru, and it’s been tested and acked by dbarth and myself
[21:37] <robru> oSoMoN, oh, I see, it's not an MP. I'll have to WATCH_ONLY build it before citrain will let me publish
[21:37] <oSoMoN> robru, is that a trigger for the script that updates the status?
[21:38] <robru> oSoMoN, yeah, pretty much
[21:38] <dobey> kgunn: i don't think a reconfig is going to help mir build on arm though :)
[21:39] <slangasek> dobey: no progress yet; it was lunch then phonecall for me.  I'm going to braindump to a bug report ASAP
[21:39] <dobey> slangasek: ok, thanks
[21:39] <kgunn> dobey after a discussion with tvoss i add his process-cpp mp...i didn't have hope, but worth a shot, so reconfig was ridding the silo of that
[21:40] <robru> oSoMoN, ok, published
[21:40] <oSoMoN> robru, awesome, thanks!
[21:40] <robru> oSoMoN, you're welcome!
[21:40] <kgunn> dobey so i think we double-proved it didn't help
[21:42] <dobey> ah
[21:42] <dobey> kgunn: time to submit a paper to the New England Journal of WTF then, perhaps ;)
[21:43] <kgunn> lol
[21:44] <kgunn> dobey yeah, i didn't really get why he even thot'd help...i mean, seems to me this is just mismatch symbols on libstd
[21:45] <dobey> i'll just have to wait for foundations to fix it i guess
[21:45] <oSoMoN> robru, what does "oxide-qt (1.0.2-0ubuntu2) is in no known space (and time)" mean?
[21:45] <robru> oSoMoN, means it hasn't been copied to proposed yet, should be there soon though
[21:46] <oSoMoN> ah ok, it kinda sounded scary…
[21:46] <dobey> whee, and now jenkins is starting to catch up with archive brokenness
[22:22] <renato> elopio, ping
[22:56] <robru> boiko_, you got 13
[22:58] <elopio> renato: pong
[22:59] <renato> elopio, one of the tests was failing
[22:59] <renato> elopio, I create a woraround
[22:59] <renato> workaround
[22:59] <renato> let me send you the link
[22:59] <renato> http://bazaar.launchpad.net/~renatofilho/address-book-app/new-visual-contact-editor/revision/210
[22:59] <renato> I think this is a bug on SDK,
[23:00] <renato> is very hard to scroll if you have fields on the flickable
[23:03] <elopio> renato: I'm looking at the video of the error.
[23:03] <elopio> seems wrong indeed.
[23:03] <renato> elopio, I was able to reproduce the problem on my desktop
[23:03] <elopio> renato: so, sometimes, you swipe and nothing happens?
[23:04] <renato> elopio, yes the field eats the events
[23:04] <renato> if you have a field in the are where you click
[23:05] <renato> but works in the second time
[23:06] <elopio> renato: got it. Can you please report a bug and mention it on the workaround comment?
[23:06] <renato> ok
[23:07] <elopio> renato: and are you sure it will always work doing it twice?
[23:07] <elopio> if not, then maybe it would be a better idea to return to the tabs to focus while the bug is fixed.
[23:07] <renato> elopio, there is a bug alredy: https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1205024
[23:10] <renato> elopio, works for me :D, lets wait for jenkins
[23:11] <boiko_> robru: thanks
[23:11] <robru> boiko_, you're welcome
[23:13] <elopio> renato: I confirmed the bug. I can see it happening here too.
[23:17] <elopio> fginther: late ping about the gatekeeper job. For when you have some time, I'll be here.