[02:15] <fginther> veebers, yes, is this for an existing project (i.e. can you just submit an MP)
[02:16] <veebers> Hi fginther, yeah this is for libautopilot-qt
[02:18] <fginther> veebers, it appears to be already setup. If you submit an MP to test, the armhf ci job should save the deb files
[02:18] <veebers> fginther: ah right good idea :-) Thanks
[07:45] <asac> xnox: maybe your uploads have made our image go bloody? :)
[07:46] <asac> hmmm
[07:46] <asac> or not
[07:46] <asac> /usr/bin/dialer-app: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libmirprotobuf.so.0: undefined symbol:
[07:46] <asac> _ZN6google8protobuf18GoogleOnceInitImplEPiPNS0_7ClosureE
[07:46] <asac> http://ci.ubuntu.com/smokeng/trusty/touch/mako/164:20140205:20140115.1/6457/dialer-app-autopilot/735638/
[07:46] <asac> libprotobuf8:armhf from 2.5.0-5ubuntu2 to 2.5.0-7ubuntu1
[07:47] <asac> slangasek: ^
[07:50] <asac> not good to have a InitImpl function in an inline thingy
[07:50] <asac> i am sure that defeats the purpose of InitImpl
[07:51] <asac> feels like one of those SONAME bumps due to header bustage
[07:52] <asac> https://launchpadlibrarian.net/164839352/protobuf_2.5.0-5ubuntu2_2.5.0-7ubuntu1.diff.gz -> see: once.h diff
[09:00] <xnox> asac: all my changes are to do with shutdown on the desktop, plymouth is disabled on touch and i tested all my uploads on grouper before uploading.
[09:06] <asac> xnox: aye... already found protobuf as you can see :)
[09:31] <sil2100> ogra_: MEETING!
[09:31] <sil2100> Ouch, caps-lock
[09:32] <tvoss> didrocks, I'm here, too
[09:37] <asac> didrocks: so think to be safe we might want to have someone look at the ones that dont show the symbol crash ... like weather or terminal
[09:37] <asac> i guess its still the same
[09:37] <asac> but... you never know :)
[09:43] <cjwatson> I suspect libmirprotobuf being broken will make it pretty painful to investigate anything :)
[09:45] <tvoss> cjwatson, so downgrading libprotobuf8 helps here
[09:46] <cjwatson> that's no surprise at all
[09:46] <cjwatson> I don't need help diagnosing this, I'm busy testing the fix :)
[09:46] <cjwatson> but yes, I suppose you could check that e.g. terminal works after downgrading libprotobuf8
[09:47] <cjwatson> might be worth doing
[09:49] <ogra_> terminal input is broken ... (return and backspace dont work)
[09:49] <ogra_> so probably pick something else
[09:50] <cjwatson> or whatever, something that isn't showing the protobuf symbol crash but where autopilot just gives up in a huff
[09:51] <ogra_> system-settings doesnt start in the latest image for me ... should be good for a test
[09:55] <asac> terminal worked yesterday
[09:55] <asac> the AP
[09:56] <asac> so should be fine to check if the AP regressions go away
[09:56] <asac> tvoss: ^^ can you run terminal AP as well? or weather?
[09:56] <asac> tvoss: try clock
[09:56] <asac> http://ci.ubuntu.com/smokeng/trusty/touch/mako/164:20140205:20140115.1/6457/ubuntu-clock-app-autopilot/736007/
[09:56] <asac> that also failed and worked yesterday and we dont see the symbol crash
[09:57] <asac> so if that goes green with downgrade i feel pretty safe
[10:02] <asac> tvoss: trying :)?
[10:02] <asac> (sorry, but your device just seems ready to running that clock AP :))
[10:12] <tvoss> asac, trying now
[10:17] <tvoss> asac, just completed the terminal tests successfully
[10:22] <tvoss> asac, clock app tests are running, too
[10:26] <asac> nice one
[10:27] <asac> seems we just need to get those two things in, kick image and then can continue at reasonable pace :)
[10:27] <cjwatson> so, I can't get my emulator to work properly right at the moment.  when the slowest build ever finishes, can I hand somebody .debs to try out?
[10:27] <cjwatson> building on porter-armhf.c.c at the moment
[10:27] <asac> cjwatson: give them to tvoss
[10:27] <asac> sorry tvoss :)
[10:27] <tvoss> cjwatson, yup, just shoot them over
[10:40] <davmor2> didrocks: mako is screwed no apps opening on whatever image is currently out
[10:40] <davmor2> back in 20
[10:40] <didrocks> davmor2: yeah, would be nice if you can join our morning call :)
[10:41] <didrocks> davmor2: all that is dealt, for now, just wait for next image (we hope to kick it ASAP)
[10:46] <asac> cjwatson: tvoss: already shot something over to tvoss?
[10:47] <cjwatson> the hamsters are grinding as fast as they can
[10:47] <cjwatson> which is not very fast
[10:47] <cjwatson> I'll shoot over .debs as soon as I have them
[10:52] <cjwatson> you know, sod it, I'm going to dump this into trusty-proposed in parallel and block it there until it's tested
[10:53] <cjwatson> otherwise it's just another mumble-dozen minutes of build time
[10:54] <cjwatson> mumble and ccsm work fine with a local build of the new source here
[10:55]  * didrocks does the same with location-service meanwhile
[10:56] <didrocks> get that to a silo
[10:57] <asac> thanks :)
[10:57] <asac> hamsters :P
[10:57] <asac> staging in proposed sounds appropriate
[11:01] <davmor2> didrocks: what time is the morning meeting?
[11:04] <didrocks> davmor2: 9:30 UTC
[11:05] <davmor2> didrocks: hangouts?
[11:06] <didrocks> yep, it's a hangout
[11:07] <cjwatson> let's see if https://launchpad.net/ubuntu/+source/protobuf/2.5.0-8ubuntu1 beats my build on the porter box
[11:08] <ogra_> the last upload took 22mins on armhf
[11:09] <ogra_> wow
[11:09] <ogra_> and 19 on arm64 ... pretty slow for twice the bits :)
[11:09] <cjwatson> as I said on #ubuntu-devel, backlogged + slow database master
[11:10] <cjwatson> package size won't have been particularly relevant
[11:10] <ogra_> no, but i would have expected a 64bit CPU to build faster
[11:11] <cjwatson> oh you mean the protobuf build
[11:11] <ogra_> (though looking at ppc vs ppc64 the pcc variant is faster than the ppc64 one)
[11:11] <ogra_> yeah
[11:11] <cjwatson> our arm64 hardware is not exactly production-quality
[11:11] <ogra_> yeah, i guess
[11:12] <ogra_> well, even amd64 builds it slower than i386
[11:12] <cjwatson> also, arm64 and ppc64el lose out because those builders are hosted in 1SS, and there's some network slowness between that and the main Launchpad DC that nobody's ever been able to track down well enough to fix
[11:12] <cjwatson> that will utterly dominate any CPU performance in this case
[11:12] <ogra_> ah, so it isnt exactly the build time
[11:12] <ogra_> yeah, that makes sense
[11:13] <cjwatson> though it's true that the build itself was 14 seconds slower on ppc64el here
[11:13] <cjwatson> it also shows 300M more disk space used though
[11:13] <ogra_> wow
[11:14] <ogra_> thats a lot
[11:14] <davmor2> didrocks: I'll see what I can do then
[11:14] <cjwatson> the amd64 build itself was one second faster than its i386 counterpart, but about 340M more disk used
[11:15] <ogra_> seems the 64bit arches use more deps
[11:15] <cjwatson> you can't really do this kind of fine-grained comparison on single packages very sensibly anyway :)
[11:15] <ogra_> yeah, i just found it curious to see the numbers
[11:17]  * ogra_ grins about xnox' "say-no-to-x11" branches ... 
[11:17] <ogra_> its a quest !
[11:20] <cjwatson> tvoss: deb http://people.canonical.com/~cjwatson/tmp/protobuf/ ./
[11:20] <cjwatson> tvoss: though https://launchpad.net/ubuntu/+source/protobuf/2.5.0-8ubuntu1/+build/5555680 is done so you should just be able to pull it from trusty-proposed shortly
[11:20] <cjwatson> (or from the librarian)
[11:21] <cjwatson> in fact better to test the librarian builds really
[11:21] <tvoss> cjohnston, ack and thax
[11:21] <tvoss> thx
[11:22] <sil2100> s/cjohnston/cjwatson
[11:28] <cjwatson> tvoss: I need to go to the bike shop; if you test this and it looks good before I get back, feel free to close bug 1276531 and that should cause it to slide into trusty
[11:28] <tvoss> cjwatson, ack
[11:28] <cjwatson> thanks
[11:29] <tvoss> looks good so far, clock tests are running after installing the deb
[11:29] <cjwatson> ok, good, hopefully there'll be no surprises
[11:29] <ogra_> as long as apps start again ...
[11:29] <ogra_> :)
[11:40] <tvoss> ogra_, could you please install https://launchpad.net/ubuntu/+source/protobuf/2.5.0-8ubuntu1/+build/5555680/+files/libprotobuf8_2.5.0-8ubuntu1_armhf.deb and see if the apps start working again?
[11:40] <tvoss> ogra_, works for me
[11:40] <ogra_> sure
[11:44] <ogra_> tvoss, seems fine
[11:44] <ogra_> cjwatson, ^^^
[11:44]  * ogra_ has system-settings running again 
[11:44] <tvoss> ogra_, ack and thx
[11:44] <tvoss> ogra_, asac closing the bug that cjwatson pinged me
[11:45] <asac> nice one
[11:45] <asac> so we have ti testd?
[11:46] <asac> if so colin can release the proposed block
[11:46] <asac> didrocks: ?
[11:47] <didrocks> asac: doing CITrain training, but sil2100 is looking/helping
[11:47] <didrocks> he's working on dbus-cpp as well
[11:48] <tvoss> asac, closing the bug now, fine with you?
[11:48] <tvoss> asac, that unblocks the package in proposed and let's it migrate as I understand it
[11:48] <asac> is the stuff in archive?
[11:48] <asac> closing bug unblocks the package in proposed?
[11:48] <asac> i dont think so :)
[11:49] <asac> didrocks: fine with releating proposed block?
[11:49] <sil2100> asac: cjwatson said that closing the bug will cause the package to migrate
[11:49] <asac> for protobuf?
[11:49] <asac> ah cool
[11:49] <didrocks> asac: yep :)
[11:49] <sil2100> asac: ^
[11:49] <asac> if didrocks is happy lets try that
[11:49] <asac> interesting feature
[11:51] <tvoss> sil2100, so I'm setting it to fix committed or fix released?
[11:52] <tvoss> didrocks, ^?
[11:52] <sil2100> tvoss: not sure, cjwatson would be the one to know ;) We're betting on Fix Committed
[11:53] <tvoss> sil2100, done :)
[11:54] <sil2100> \o/
[12:14] <cjwatson> tvoss,sil2100: fix committed won't do anything, any actual closed state (e.g. fix released) is fine
[12:15] <tvoss> cjwatson, thx
[12:15] <cjwatson> I've fix-released it now
[12:15] <tvoss> cjwatson, thank you :)
[12:15] <cjwatson> asac: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-October/001068.html FYI
[12:15] <sil2100> cjwatson: hah, so me and didrocks guessed wrong ;)
[12:16] <ogra_> cjwatson, wow, sweet !
[12:16] <cjwatson> thanks for the tests
[12:17] <ogra_> (why did i never notice that mail)
[12:20] <davmor2> ogra_: because you get more than 1 mail a day?
[12:21] <asac> cjwatson: wow... so thats avail for everyone? cool stuff
[12:21] <ogra_> asac, note that date
[12:21] <asac> yes
[12:21] <asac> hence
[12:21] <asac> :)
[12:21] <ogra_> we have that since like ... forever
[12:21]  * ogra_ didnt know about it either ... i somehow missed that mail 
[12:21] <asac> well... i guess it this mechanic detail
[12:21] <cjwatson> start of this cycle isn't forever :)
[12:22] <asac> was not in my head
[12:22] <ogra_> :)
[12:22] <asac> i thought touch had a way to block through bzr
[12:22] <cjwatson> you do as well, yes
[12:22] <ogra_> we do
[12:22] <asac> yeah, but i was stuck at that :)
[12:22]  * ogra_ has only used it at release time though 
[12:22] <ogra_> i dont think we had to touch it since
[12:22] <cjwatson> what that mechanism gives you that the bug mechanism doesn't is that you can *unblock* during freezes
[12:22] <ogra_> (dider probably did)
[12:25] <rsalveti> morning
[12:38] <sil2100> davmor2: hi! I fixed the SMS OSK problem, it might be released sooner-or-later with some other changes
[12:39] <davmor2> sil2100: nice :)
[12:41] <rsalveti> argh, launchpad is just giving me timeout errors today
[12:41] <sil2100> Same here
[12:42] <ogra_> rsalveti, yeah
[12:42] <davmor2> rsalveti: it knows you are going to try and make it work
[12:42] <ogra_> some upgrade ... something needs regeneration ... everything gets slow for a while
[12:42] <rsalveti> right
[12:43] <rsalveti> didrocks: mlankhorst is finishing the xorg migration and then we should be good to publish mir
[12:44] <sil2100> rsalveti: \o/
[12:44] <rsalveti> hopefully nothing will explode :-)
[12:46] <cjwatson> ogra_: no, it's not about anything needing regeneration, please don't make things up :)
[12:47] <cjwatson> the master database system was being upgraded to precise (that's just finished), and so it was taken out of rotation and a slower slave was temporarily promoted to master
[12:47] <ogra_> i thought it needs to re-fill a db
[12:47] <ogra_> sorry
[12:47] <cjwatson> it's older hardware and can't quite do the job as quickly
[12:47] <cjwatson> but it's a lot better than taking all of LP down for an hour or two
[12:47] <asac> indeed
[12:47] <cjwatson> the slaves are replicated, it had everything, just not necessarily well-cached etc.
[12:48] <cjwatson> trying a few times should be sufficient; and I think wildcherry is being swapped back in RSN
[12:48] <didrocks> rsalveti: probably not, but I just want to kick an image with location-service and protobuf fix first
[12:48] <didrocks> rsalveti: then, we just publish xorg, mir… whatever
[12:49] <rsalveti> didrocks: great
[12:50] <rsalveti> didrocks: https://code.launchpad.net/~sergiusens/qtubuntu/empty/+merge/204183 can be merged already btw (from landing-1)
[12:51] <didrocks> rsalveti: you can click on "merge and clean"
[12:51] <didrocks> rsalveti: that would do it for you
[12:51] <didrocks> (in landing-001)
[12:51] <rsalveti> DONE
[12:52] <didrocks> \o/
[12:52] <didrocks> thanks rsalveti :)
[12:54] <rsalveti> :-)
[12:59] <sergiusens> rsalveti, yeah, don't confuse the landing box ;-)
[13:05] <rsalveti> nice, it keeps spinning to see if the packages are really gone
[13:05] <rsalveti> sergiusens: hey, welcome back
[13:05] <didrocks> rsalveti: yeah, it can take times to have them really cleaned
[13:05] <didrocks> rsalveti: see http://ppa.launchpad.net/ci-train-ppa-service/landing-001/ubuntu/dists/trusty/main/binary-armhf/Packages
[13:05] <didrocks> for instance
[13:05] <rsalveti> yeah
[13:06] <didrocks> but then, you should be fine, once everything is really cleaned, the line will change to "landed" and landing-001 will be available
[13:07] <sil2100> tvoss: how's it proceeding? Will we have to land dbus-cpp only or process-cpp as well?
[13:12] <tvoss> sil2100, dbus-cpp has to land
[13:12] <sil2100> tvoss: ACK
[13:21] <cjwatson> fixed protobuf is in trusty now, btw
[13:21] <ogra_> yay
[13:27] <sil2100> \o/
[13:28] <sil2100> So now just the fix from tvoss is needed ;
[13:30] <sil2100> tvoss: you have many eyeballs eyeballing you!
[13:31] <tvoss> sil2100, sure
[13:31] <tvoss> sil2100, that's not that new :)
[13:37] <tvoss> didrocks, I could use some help here: https://code.launchpad.net/~thomas-voss/dbus-cpp/force_gcc_4.7/+merge/204909
[13:37] <tvoss> didrocks, when trying to build with dpkg-buildpackage, gcc 4.8.x is chosen
[13:38] <didrocks> hum
[13:38] <didrocks> -Package: libdbus-cpp1.1
[13:38] <didrocks> 18+Package: libdbus-cpp1
[13:38] <didrocks> why was it changed in trunk and now it's back to compatbility?
[13:39] <tvoss> didrocks, shouldn't have been switched on trunk
[13:41] <didrocks> -- The C compiler identification is GNU 4.7.3
[13:41] <didrocks> -- The CXX compiler identification is GNU 4.7.3
[13:41] <didrocks> -- Check for working C compiler: /usr/lib/ccache/gcc-4.7
[13:41] <didrocks> -- Check for working C compiler: /usr/lib/ccache/gcc-4.7 -- works
[13:41] <didrocks> /usr/lib/ccache/g++-4.7 here (but I'm using ccache)
[13:45] <tvoss> didrocks, not working here, but let's just wait for the silo
[13:46] <didrocks> tvoss: hum, we aren't building dbus-cpp in a silo, right?
[13:46] <didrocks> as we can't ship the whole trunk
[13:46] <didrocks> which is != archive
[13:46] <didrocks> we only want your fix, right?
[13:49] <sil2100> didrocks: yes
[13:49] <sil2100> didrocks: that's why I'm dputting dbus-cpp to the PPA
[13:54] <didrocks> sil2100: still not published for me
[13:54]  * didrocks hesitates to bother LP guys as I guess it's a followup on the upgrade (and maybe catching up)
[13:55] <sil2100> Still not popping up for me as well ;/
[13:55] <cjwatson> the cron jobs are disabled right now for the second of the two db switches today
[13:55] <cjwatson> i.e. switching back to the real master
[13:55] <cjwatson> they should return in a few minutes
[13:55] <didrocks> ok, thanks cjwatson :)
[14:30] <sil2100> tvoss, didrocks: https://launchpad.net/~ci-train-ppa-service/+archive/landing-005/+build/5557271 <- it's using 4.7 here
[14:30] <sil2100> \o/
[14:30] <tvoss> sil2100, thanks
[14:30] <didrocks> /usr/bin/g++-4.7
[14:30] <didrocks> phew
[14:31] <didrocks> and the cherry-pick works
[14:31] <didrocks> contrary to trunk with half renaming :)
[14:31] <didrocks> let's see as soon as it's published
[14:31] <didrocks> got everything tested
[14:31]  * ogra_ likes cherries 
[14:31] <ogra_> with cream !
[14:31] <didrocks> and picks? :p
[14:32] <ogra_> indeed !
[14:42] <jibel> fginther, hey, there is something I don't understand with http://s-jenkins.ubuntu-ci:8080/job/address-book-service-trusty-amd64-ci/46/ maybe you can help
[14:42] <jibel> fginther, a header has been moved from src/addressbook.h to lib/addressbook.h and modified to add new methods
[14:42] <jibel> fginther, but the build seems to be grabbing the old version of the source package
[14:42] <jibel> and it fails with xxx as no member start()
[14:42] <jibel> fginther, any idea what could happen here?
[14:46] <fginther> jibel, looking
[14:46] <sil2100> tvoss: ok, so dbus-cpp failed because of symbols...
[14:47] <sil2100> tvoss: https://launchpad.net/~ci-train-ppa-service/+archive/landing-005/+packages
[14:47] <fginther> jibel, I know what this is and have an MP in the works to fix. The job configuration needs to be modified to bump the package version so that bzr bd will treat it as a 'new' upstream
[14:47] <sil2100> tvoss: to make sure I cherry-picked your fix correctly, here's the diff https://launchpadlibrarian.net/165051845/dbus-cpp_1.0.0%2B14.04.20140123-0ubuntu1_1.0.0%2B14.04.20140123-0ubuntu2.diff.gz
[14:47] <fginther> jibel, should be ready shortly
[14:48] <jibel> fginther, good, how shortly is it?
[14:49] <tvoss> sil2100, the cherry picking looks sane
[14:50] <sil2100> I'm not familiar with inter-toolchain problems, but can that be caused by the different toolchain?
[14:51] <fginther> jibel, I'll have address-book-service ready in a few minutes
[14:51] <jibel> fginther, perfect, thank you!
[14:56] <fginther> jibel, I've triggered a rebuild on that MP
[14:57] <rsalveti> didrocks: xorg-server is in, so once the build with location-service is done, we can try to land mir again
[14:57] <didrocks> rsalveti: right, I'll keep an eye and keep you posted
[14:57] <rsalveti> thanks
[14:58] <didrocks> rsalveti: btw, I forgot, but there is another override (which was in the message, but it's not that clear)
[14:58] <didrocks> rsalveti: there is an "ignore dest version check" option in publish
[14:58] <rsalveti> didrocks: tried that yesterday, but didn't make any difference
[14:59] <didrocks> IGNORE_VERSIONDESTINATION
[14:59] <didrocks> hum
[14:59] <didrocks> ah, that is a bug, the override should work
[14:59] <didrocks> do you remember which run?
[14:59] <didrocks> (I'll have a look)
[14:59] <rsalveti> let me check
[14:59] <rsalveti> didrocks: http://162.213.34.102/job/landing-002-2-publish/13/
[15:04] <didrocks> rsalveti: thanks, that should have worked, I'll give it a look
[15:04]  * didrocks first look at why google apps script is "thinking"
[15:20] <davmor2> sil2100: I got bored and now I am a time.sleep lord http://bazaar.launchpad.net/~davmor2/+junk/is_there_an_update/view/head:/isthereanupdate.py
[15:32] <balloons> ping sergiusens
[15:38] <sil2100> tvoss: once you're back from lunch, give us a status report ;)
[15:48] <sil2100> davmor2: sadly you'll have to wait some more even, we're still waiting for the dbus/location-service fix
[15:48] <davmor2> read the else it check once an hour after the first hour is gone :)
[16:04] <sergiusens> balloons, is it wrt to the click buddy mr bundle? :-)
[16:12] <tvoss> xnox, can gou give me a hand in tricking a dpkg-buildpackage to use gcc 4.7?
[16:13] <tvoss> xnox, my debian/rules looks like this: http://pastebin.ubuntu.com/6879879/
[16:17] <xnox> tvoss: drop line 7, not needed, as DEB_HOST_MULTIARCH is defined inside the include from line 9
[16:17] <balloons> sergiusens: sorry wifi here is horrid :-) Yes, let's talk click-buddy please
[16:17] <plars> didrocks: ogra_: any idea when to expect the next image?
[16:17] <xnox> tvoss: and you need a build-dependency on g++-4.7
[16:17] <xnox> tvoss:  and that should work, can I fetch the whole thing to test here?
[16:18] <didrocks> plars: no idea at all, tvoss and sil2100 are working on dbus-cpp fix
[16:19] <tvoss> plars, on it, need to figure out symbol file changes
[16:19] <sergiusens> balloons, I've have 3 hours in meetings now; but I can still pay attention to irc; so feel free to shoot
[16:21] <tvoss> xnox, sure @build dep, that's there, here is what I get: -- The C compiler identification is GNU 4.8.2
[16:21] <tvoss> -- The CXX compiler identification is GNU 4.8.2
[16:21] <tvoss> -- Check for working C compiler: /usr/bin/x86_64-linux-gnu-gcc
[16:21] <tvoss> -- Check for working C compiler: /usr/bin/x86_64-linux-gnu-gcc -- works
[16:21] <tvoss> -- Detecting C compiler ABI info
[16:21] <tvoss> -- Detecting C compiler ABI info - done
[16:21] <tvoss> -- Check for working CXX compiler: /usr/bin/x86_64-linux-gnu-g++
[16:21] <tvoss> -- Check for working CXX compiler: /usr/bin/x86_64-linux-gnu-g++ -- works
[16:21] <davmor2> ogra_: new n7 is razor right?
[16:21] <ogra_> davmor2, flo
[16:22] <davmor2> ogra_: right thanks
[16:22] <ogra_> razor is the old grouper with 3G iirc
[16:22] <xnox> tvoss: and what is the cmake package version number?
[16:22] <davmor2> thanks
[16:22] <tvoss> xnox, 2.8.12.1-1ubuntu5
[16:23] <xnox> tvoss: that should just work.
[16:23] <xnox> tvoss: can I please fetch the full source package / branch please?
[16:23] <tvoss> xnox, well, that would be my wish, too :)
[16:24] <xnox> tvoss: does adding -DCMAKE_CXX_COMPILER=$(CXX) and -DCMAKE_C_COMPILER=$(CC) to the end of dh_auto_configure make it work?
[16:24] <tvoss> xnox, let me check
[16:24] <xnox> (ugly & explicit and shouldn't be necessary...)
[16:25] <xnox> if that also doesn't help, it could be that there are custom toolchains or BuildTypes overriden in the CMakeLists in those sources.
[16:28] <tvoss> xnox, lp:~thomas-voss/dbus-cpp/force_gcc_4.7/
[16:30] <tvoss> xnox, that actually works
[16:34] <xnox> tvoss: =) and it does the right thing in the clean chroot / sbuild as well. \o/
[16:36] <tvoss> xnox, nope, the dirty line works
[16:37] <tvoss> :)
[16:37] <xnox> tvoss: i've cloned your branch and without modifying it, built it, and it used gcc-4.7.
[16:38] <tvoss> xnox, might well be that my system is just screwed up
[16:38] <rsalveti> didrocks: any news regarding the location service & image?
[16:38] <rsalveti> I know you'll be off soon :-)
[16:38] <xnox> tvoss: well, i built in a clean trusty sbuild, as ~= done by launchpad. So it will work there. And extra -DCMAKE_*_COMPILER will not hurt.
[16:40] <tvoss> xnox, great, as long as I can get dpkg-buidpackage to throw .symbol file issues at me
[16:42] <xnox> tvoss: ah, that =) note it will typically throw mangled symbols at you.
[16:42] <sil2100> rsalveti: tvoss is working on that ^
[16:42] <rsalveti> alright :-)
[16:42] <sil2100> rsalveti: the problem got found, fixed but now there's a lot of symbols mis-matches
[16:43] <ogra_> freking symbols ... rip them out !
[16:43] <xnox> tvoss: https://wiki.ubuntu.com/DailyRelease/FAQ#I.27m_exposing_a_new_C.2BAC8-C.2B-.2B-_symbols_in_my_library.2C_it_seems_that_some_packaging_changes_are_needed.2BICY- and read the portion about C++ mangled symbols and how to demangle them.
[16:43] <xnox> starting from "NB! For C++ ..."
[16:43] <xnox> tvoss: if something is not clear feel free to poke me, i've documented that bit of symbols management.
[16:47] <sil2100> xnox: the funny thing here is that we have some arch-dependent symbols as well
[16:47] <sil2100> xnox: like, some symbols differ for 32 bit archs and 64 bit archs
[16:48] <sil2100> xnox: I hacked around the symbols file before, but it's so terrible that my eyes burn
[16:52] <xnox> sil2100: you simply mark them optional, or restrict them by arch.
[16:52] <xnox> sil2100: if you filter and demangle C++ symbols they bleed your eyes less, and there is less per-arch variance.
[16:53] <xnox> sil2100: e.g. _ZN26AccelerometerSensorReading11qt_metacallEN11QMetaObject4CallEiPPv@Base 0.5.1+13.10.20130412ubuntu.unity.next-0ubuntu1
[16:53] <xnox> sil2100: becomes this:
[16:53] <xnox> (c++)"AccelerometerSensorReading::qt_metacall(QMetaObject::Call, int, void**)@Base" 0.5.1+13.10.20130412ubuntu.unity.next-0ubuntu1
[16:54] <xnox> sil2100: and it no longer varies per-arch (since it's encoded as "int", instead of a "N amount of bits int")
[16:54] <sil2100> xnox: yes, that's what I did previously
[16:55] <sil2100> xnox: but it took a long time to do, with a lot of vimdiff and copy+paste madness
[16:55] <xnox> sil2100: there isn't anything better than that =/ and i do agree that C++ generally makes ones eyes bleed =) hence the http://tgceec.tumblr.com/post/74534916370/results-of-the-grand-c-error-explosion-competition
[16:55] <sil2100> xnox: I know all this as the current symbols file uses a lot of (c++|optional) and (c++|arch=amd64 arm64 ppc64el) and such
[16:55] <xnox> (if one starts to poke symbols, or debug bugs in nested template initialisation)
[16:55] <sil2100> But yeah...
[16:55] <sil2100> xnox: :(
[16:56] <xnox> sil2100: yeah, "optional" is bad, cause it wouldn't catch regression on that arch. and it's sad that one has to expand 64bit arches like that =(
[16:57] <ogra_> well, we dont use that package anywhere except on armhf currently
[16:57]  * ogra_ would go with an interim fix and make it "Architecture: armhf"
[16:57] <ogra_> to finally get us unblocked
[17:02] <didrocks> tvoss: seems that you are pushing still some commits to the branch
[17:02] <didrocks> are you done or not really?
[17:08] <sil2100> tvoss: I have some symbols files ready right now, let's see how it goes
[17:24] <tvoss> sil2100, thx
[17:24] <sil2100> tvoss: actually, work on the symbols files on your branch normally
[17:24] <sil2100> tvoss: we'll temporarily drop the symbols file for this one upload
[17:24] <tvoss> sil2100, yup, that's what I'm trying to understand
[17:24] <tvoss> sil2100, build passes just fine here
[17:24] <sil2100> tvoss: to unblock stuff we'll be doing shlibs -V
[17:41] <tvoss> sil2100, ack
[17:41] <tvoss> sil2100, we can clean up the dbus-cpp branch tomorrow then
[17:42] <tvoss> didrocks, mind clarifying what you mean with abi not being in good shape?
[17:42] <didrocks> tvoss: I'm working on fixing things now, can explain afterwards, but weird that symbols keep changing for something which is at a 1.0.0
[17:43] <tvoss> didrocks, I really don't think that our assumption should be that interfaces don't change anymore
[17:43] <tvoss> didrocks, but we have had that conversation before
[17:44] <didrocks> in that case, it's not a library, but let's move on for now
[17:44] <thostr_> didrocks: sil2100: can anybody reconfigure silo8? (we found an issue while testing and have a new MP added)
[17:44] <ogra_> tvoss, shouldnt that become a 2.0.0 then ?
[17:44] <tvoss> ogra_, sure, happy to bump the major version number
[17:44] <ogra_> well first have some symbols files ;)
[17:44] <tvoss> didrocks, what is our easy to use way of sharing code between projects then?
[17:45] <tvoss> ogra_, I have, believe me, and I have been throught the process of updating them more often then I actually wanted to
[17:45] <tvoss> didrocks, and updating the symbols file really isn't easy but a real pain, just saying
[17:45] <didrocks> then, start acting as a library
[17:45] <didrocks> anyway again, I'm fixing things
[17:45] <didrocks> no time for chatting
[17:49] <sil2100> thostr_: in a moment, we're in firefighting mode right now ;)
[18:03] <thostr_> sil2100: have you reconfigured? it seems it got autoupdated, at least the silo now shows all MPs, so is this just a spread sheet feature or is jenkins job properly set up?
[18:04] <sil2100> thostr_: I did not do anything yet, still busy, but we noticed problems with google spreadsheets today already
[18:04] <didrocks> thostr_: I'm doing it now
[18:04] <thostr_> didrocks: thanks!!!
[18:04] <didrocks> the spreadsheet is updated automatically
[18:04] <didrocks> (it's a formula)
[18:04] <didrocks> this doesn't come from the backend
[18:04] <thostr_> didrocks: ok, so just let me know when it's reconfigured
[18:06] <didrocks> thostr_: done
[18:07] <thostr_> didrocks: thanks
[18:07] <didrocks> yw
[18:08] <didrocks> basic testing done
[18:08] <didrocks> jasoncwarner: asac: we didn't get any location as we have to wait for 10+ minutes, but the process doesn't go crazy ^
[18:08] <didrocks> so, we'll publish this
[18:10] <didrocks> tvoss: ogra_: entering proposed
[18:11] <tvoss> didrocks, ack
[18:11] <asac> ricmm: can you come back?
[18:12] <ogra_> didrocks, yay, finally
[18:13] <asac> ricmm: your P&P tab came up :)
[18:13] <asac> as scaring people
[18:17] <didrocks> kgunn: ok, so to keep you posted (even if the infos are already on the touch ML)…
[18:17] <didrocks> kgunn: we just published the fixes that will enable to get a better image
[18:17] <didrocks> this is migrating to distro
[18:18] <ogra_> didrocks, rsalveti is informed ... i'll do the image and he can do the rest then
[18:18] <didrocks> ogra_: thanks!
[18:18] <ogra_> both packages are not blocked in proposed or anything, right ?
[18:18] <kgunn> didrocks: ack
[18:19] <ogra_> (i.e. just a matter of waiting)
[18:19] <didrocks> kgunn: so, once the image is kicked (and I hope someone will have time to do very very basic dogfooding to ensure at least the image isn't is a worse shape…), rsalveti will publish Mir
[18:19] <didrocks> ogra_: shouldn't, but I'm staying, don't worry
[18:19] <ogra_> ok
[18:19] <didrocks> until they are in the release pocket at least
[18:19] <kgunn> ogra_: rsalveti just hit me up...i don't mind doing some quick testing
[18:19] <ogra_> the office should get better sofas for you :)
[18:19] <didrocks> ogra_: clearly… tell that to my manager :p
[18:19] <ogra_> jasoncwarner, ^^
[18:19] <didrocks> "special didrocks' order"
[18:20] <ogra_> :)
[18:20] <sil2100> ;)
[18:26] <rsalveti> kgunn: alright
[18:27] <rsalveti> didrocks: yeah, will quickly test the image, test the mir stuff to make sure nothing explodes and we'll try to land it again
[18:27] <didrocks> rsalveti: excellent, thanks a lot :)
[18:31] <rsalveti> ogra_: will brb (~1h), hopefully in time to test the new image :-)
[18:32] <didrocks> rsalveti: get a bigger dinner
[18:32] <rsalveti> yeah
[18:32] <didrocks> :)
[18:33] <ogra_> rsalveti, lol
[18:33] <ogra_> wishful thinking
[18:34] <didrocks> let's get them published in proposed first :p
[18:34] <ogra_> details
[18:34] <didrocks> ahah
[18:35] <ogra_> seems location-service is in dep-wait on ppc ppc64 and arm64
[18:36] <ogra_> and dbus-cpp on ppc64
[18:44] <ricmm> asac: sorry was cooking while on another call, no irc then
[18:45] <ogra_> in madrid you should get an IRC capable stove ;)
[18:48] <didrocks> ogra_: but that's expected
[18:48] <didrocks> it's not new
[18:49]  * didrocks recheck
[18:49] <ogra_> whee, location-service moved on
[18:50] <didrocks> dbus-cpp
[18:50] <didrocks> hum
[18:50] <ogra_> well, its just done on arm64
[18:50] <ogra_> give it a bit
[18:51] <didrocks> Missing build dependencies: g++-4.7
[18:51] <didrocks> argh
[18:53] <ogra_> sigh
[18:53] <didrocks> ok
[18:54] <ogra_> but thats ppc64
[18:54] <didrocks> so, let's remove them, checking rdepends first
[18:56]  * didrocks uses even more drasticness
[18:57]  * ogra_ looks in the other direction
[19:06]  * didrocks flushes
[19:06]  * ogra_ hears the gurgling 
[20:14] <jibel> cihelp can you tell me what I miss to have this https://code.launchpad.net/~jibel/address-book-app/abook_delete_contact_pickmode/+merge/203790 merged?
[20:14] <fginther> jibel, looking
[20:17] <fginther> jibel, this project is now under the ci-train process, are you familiar with that?
[20:18] <jibel> fginther, not at all
[20:18] <fginther> jibel, I was hoping you were and could tell me :-(
[20:18] <fginther> jibel, let's see what I can find
[20:18] <jibel> fginther, okay, I'll see with renato if he knows
[20:19] <balloons> fginther: LOLOLOLOLOL
[20:23] <fginther> jibel, I found some email sent to ubuntu-phone list on Jan 17 "[Ubuntu-phone] Introducing the new upstream release process: CI Train"
[20:26] <ogra_> [20:26] <ogra_> rsalveti, ^^^
[20:46]  * rsalveti back
[20:46] <rsalveti> ogra_: great, almost in time
[20:46] <ogra_> yeah, dbus-cpp got stuck so it took a bit longer
[20:46] <ogra_> (no gcc-4.7 pn ppc64)
[20:47] <ogra_> *on
[20:47] <rsalveti> right
[20:47] <ogra_> didier did some evil behind the scenes shuffling (not sure what) and it ended up in the archive now
[20:49] <rsalveti> great
[20:51] <Saviq> fginther, was calxeda-pbuilder offline for some time? the armhf builder got pretty queued up: http://s-jenkins.ubuntu-ci:8080/job/generic-mediumtests-builder-trusty-armhf/
[20:58] <balloons> rsalveti, fginther, or someone else on the phablet-tool team, would you be able to review https://code.launchpad.net/~jibel/phablet-tools/run_tests_from_custom_location/+merge/205033 ? I'd like to try and build upon this this week @ the sprint, so it would be helpful to get this merged in phablet-tools and released
[20:59] <rsalveti> balloons: sergio should be able to get that reviewed quickly
[20:59] <rsalveti> he's just not on-line now it seems
[20:59] <rsalveti> but I'll ping him once he's back
[20:59] <balloons> rsalveti: I was hoping to avoid bogging down sergio :-)
[21:00] <balloons> I've asked him a few other favors
[21:00] <rsalveti> don't worry, it's better for him to review this, since he's the maintainer anyway
[21:00] <ogra_> yeah, and just means more free drinks for him the next time you meet him
[21:00] <rsalveti> balloons: + wdir=/home/phablet
[21:01] <rsalveti> balloons: mind use wdir=/home/$USER ?
[21:01] <rsalveti> *using
[21:01] <balloons> ogra_: hehe.. so let's say I'm just trying to keep my drink bill lower eh? :p
[21:01] <jibel> rsalveti, I can change that, previously it was /home/phablet/autopilot/ which didn't exist anyway
[21:01] <ogra_> heh
[21:02] <rsalveti> jibel: yeah, as you're changing it anyway, let's get that fixed :-)
[21:02] <jibel> agreed :)
[21:09] <jibel> done
[21:09] <fginther> Saviq, in this case there is nothing wrong, we're just down a few machines due to an upgrade that needs to be done on the machines that are offline
[21:09] <fginther> Saviq, I also noticed the backlog and will try to get that upgrade finished
[21:15] <Saviq> fginther, yeah ok, saw that it's progressing now, just wanted to let you know in case something's gone awryt
[21:15] <Saviq> -t
[21:17] <fginther> Saviq, feel free to ping if you think something might be wrong, there's a chance that the monitoring is missing something
[21:21] <rsalveti> ogra_: did the cdimage part of the build finished already?
[21:21] <rsalveti> seems so, like 10 mins ago
[21:22] <ogra_> yeah
[21:22] <ogra_> but we should test before pushing the button on mir
[21:22] <ogra_> system-image will still take a bit
[21:22] <rsalveti> right, just wonder if the build was already done
[21:23] <rsalveti> *wondered
[21:23] <rsalveti> seems to be fine after I updated it by hand, will reflash from scratch using the latest image and enable the ppa to do some more testing with it
[21:24] <rsalveti> sergiusens: for you: https://code.launchpad.net/~jibel/phablet-tools/run_tests_from_custom_location/+merge/205033
[21:39] <sergiusens> rsalveti, hmmm, I already commented... that breaks ci
[21:39] <ogra_> [21:40] <rsalveti> \o/
[21:40]  * ogra_ OTAs on maguro 
[21:40] <ogra_> i really like the new upgrader
[21:40]  * tvoss grabs phone
[21:45] <jibel> sergiusens, how does it break CI?
[21:46] <sergiusens> jibel, it's in my comment; the change of the /home/phablet/autopilot path
[21:47] <ogra_> rsalveti, kgunn, i'd say go wild with Mir
[21:47] <ogra_> image looks ok on maguro
[21:47] <rsalveti> ogra_: looks fine indeed
[21:47] <rsalveti> testing on mako
[21:47] <rsalveti> will do a quick testing with latest mir again and will try to land it for real
[21:47] <ogra_> calls/sms work, apps start etc
[21:47] <jibel> sergiusens, but this path doesn't exist currently and there is always an error during tests
[21:47] <ogra_> (and top output looks sane too)
[21:47] <jibel> sergiusens, that's a bug that has nothing to do with this MP imo
[21:48] <jibel> sergiusens, for example https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/5089/console
[21:48] <jibel> bash: cd: /home/phablet/autopilot: No such file or directory
[21:48] <kgunn> ack flashing now
[21:48] <sergiusens> jibel, all the tests in ci run phablet-click-test-setup to get the click tests
[21:49] <sergiusens> jibel, I was acually hoping to have a generic test getter and a test runner; or do you think it better to merge all under the same script?
[21:50] <sergiusens> jibel, that last thing is actually a question :-)
[21:51] <jibel> sergiusens, from a test writer perspective it is better to have a single tool that makes everything. from a CI perspective separate tool is more flexible
[21:51] <jibel> sergiusens, now we can have a wrapper for dev/test writers that glues together separate tools
[21:52] <sergiusens> jibel, yeah, for click, I had click-buddy for that; in the end would build, install, provision and run
[21:53] <sergiusens> haven't really thought about the debs yet though
[21:53] <sergiusens> for click as well, I was removing the need to know the python module name and just knowing the click package name
[21:54] <asac> ogra_: we really got 165?
[21:54] <asac> :0
[21:54] <asac> thought that would never happen :)
[21:54]  * asac crosses finger
[21:54] <asac> s
[21:54] <asac> :)
[22:01] <ogra_> asac, yeah, and it is fine
[22:02] <ogra_> (hopefully the dashboard will agree ;) )
[22:02] <asac> ogra_: what is the best case? 1 test failure?
[22:02] <asac> or all green?
[22:03] <ogra_> i guess 1 failure on mako 15-17 on maguro
[22:03] <ogra_> i havent run the AP tests ... didrocks just wanted a short smoketest to make sure it doesnt go wild ... before we let Mir in
[22:04]  * ogra_ would expect us to be back at the old 1 and 16 failure scheme 
[22:06] <tvoss> ogra_, asac just started ap tests on my phone
[22:06] <ogra_> great
[22:09] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/20140205.1.changes ...
[22:09] <ogra_> the changeset looks fine and small as well
[22:13]  * ogra_ calls it a day 
[22:13] <ogra_> rsalveti, there is no need that you kick an image after Mir landed, at 3:00 UTC the cronjob will kick off anyway
[22:21] <rsalveti> ogra_: alright
[22:21] <rsalveti> ogra_: enjoy
[22:21] <ogra_> :)
[22:25] <rsalveti> kgunn: alright, landing
[22:25] <rsalveti> trying at least
[22:25] <kgunn> rsalveti: yep...all looked good here
[22:26] <kgunn> i just test u1 acct and loading a click app and all ok
[22:26] <kgunn> seems people got the AP stuff ok...and getting same results
[22:27] <rsalveti> kgunn: Finished: SUCCESS
[22:27] <rsalveti> it's happening
[22:29] <tvoss> ogra_, asac ap looks good here
[22:30] <asac> cool
[22:30] <asac> tvoss: all ?
[22:30] <tvoss> asac, nope, not finished yet
[22:31] <asac> but cool anyway
[22:35] <rsalveti> kgunn: should, should be all in proposed already
[22:35] <rsalveti> kgunn: hopefully landing in release in ~1 hour
[22:35] <rsalveti> will be afk for a bit, but will check in one hour
[22:38] <kgunn> rsalveti: thanks!
[22:45] <didrocks> rsalveti: hey, just checking back, now that the image is built (not sure about your dogfooding result), were you able to publish Mir? (seems google spreadsheet isn't really responsive here)
[22:47] <didrocks> oh, -changes tell me yes ;)
[22:47] <didrocks> I assume everything's fine then, great!
[22:47] <kgunn> didrocks: you still on? now can i hit merge/clean ?
[22:47] <rsalveti> didrocks: yeah
[22:47] <rsalveti> kgunn: not yet
[22:48] <didrocks> kgunn: you need to wait for Mir to be in the release pocket
[22:48] <rsalveti> kgunn: let's wait it to be released
[22:48] <kgunn> rsalveti: ah yeah...i see, gotta wait for that to say taht
[22:48] <kgunn> that
[22:48] <kgunn> ok
[22:48] <didrocks> kgunn: no harm done before, it will just tell you "not ready yet" :)
[22:48] <rsalveti> didrocks: all good for now
[22:48] <didrocks> rsalveti: excellent!
[22:49] <didrocks> kgunn: the status won't update on the spreadsheet, but I guess rsalveti will help you to know when it's ready. I'll try to work on updating the status automatically on the status when I get some time for that
[22:49] <kgunn> ack...thanks all for the help
[22:50] <kgunn> time to do it again :)
[22:50] <didrocks> yw! I hope everything's will be fine from now on :)
[22:50] <didrocks> kgunn: no client breakage/xorg involved this time? :)
[22:50] <kgunn> didrocks: sure...
[22:50] <didrocks> if so, should be easier
[22:50] <kgunn> didrocks: the real answer is to bring xorg guys into the fold and make them use landing
[22:51] <didrocks> kgunn: more than agreed. I think you saw my answer…
[22:51]  * didrocks sad is to have warned but seems the advice was dismissed
[22:51] <didrocks> s/sad is/is sad/
[22:52] <didrocks> but anyway, done now ;)
[22:52] <rsalveti> yeah
[22:53] <didrocks> see you tomorrow guys!