[00:17] <sergiusens> robru, hey, can you reconfigure l31-silo-003 for me? added an MR
[00:18] <robru> sergiusens, sure
[00:18] <sergiusens> robru, or do I not need to do that?
[00:18] <sergiusens> the MR targets the same project
[00:18] <robru> sergiusens, if you added an MP then I need to reconfig it, for now. we're working on a way to give you more autonomy here
[00:19] <sergiusens> ok, thanks
[00:19] <robru> sergiusens, ok done, please build.
[00:20] <sergiusens> thanks
[00:32] <sergiusens> doanac`, seems https://code.launchpad.net/~doanac/phablet-tools/autopilot-args/+merge/207315 still needs rebasing
[00:32] <sergiusens> doanac`, http://162.213.34.102/job/landing-003-1-build/35/console
[00:43] <sergiusens> fginther, failed again
[01:20]  * cyphermox logs off
[01:54] <asac> doanac`: plars: do you know why 206 is still in "running" state?
[01:54] <asac> as are 202 and 201
[01:54] <asac> here: http://ci.ubuntu.com/smokeng/trusty/touch/
[02:23] <asac> ok dropping out ... cu tomorrow
[04:08] <plars> asac: known bug being worked on: https://bugs.launchpad.net/qa-dashboard/+bug/1284298
[05:36] <bzoltan1> robru: ping
[05:37] <bzoltan1> robru: I see an entry in the CI train for UITK. Was not it so, that I am the releasing dude for the UITK?
[05:38] <bzoltan1> robru: That MR -> https://code.launchpad.net/~renatofilho/ubuntu-ui-toolkit/limit-alarms-fetch/+merge/207629 is not approved by the SDK team
[05:38] <bzoltan1> renato: ping
[05:39] <bzoltan1> Is anybody here from the CI?
[07:43] <bzoltan> hello didrocks
[07:43] <didrocks> hey bzoltan
[07:44] <bzoltan> didrocks: In the Self service CI (CI train) I watched the line nro 38 with some surprise. Does robru know that the UITK releasing belong to me and my team? He was about to release an MR what was not even approved yet.
[07:45] <didrocks> bzoltan: I don't know why he set himself as a lander. I told we are not lander for anything though
[07:45] <didrocks> bzoltan: so, I'll talk again about this with him
[07:45] <didrocks> bzoltan: the MP has landed bt
[07:45] <bzoltan> didrocks: thank you
[07:45] <didrocks> btw
[07:46] <bzoltan> didrocks: I am preparing a new MR bundle for today ...
[07:48] <didrocks> bzoltan: ok, just be aware (see emails) that we are not releasing anything that's not to fix all the issues we have on the image first
[07:48] <bzoltan> didrocks: clear and +1 that
[08:55] <mhr3> sil2100, y 29 no publish yet?
[08:56] <didrocks> mhr3: we don't publish anything that impact touch
[08:56] <didrocks> see the phone ML
[08:56] <mhr3> hmm
[09:12] <Laney> ralsina_: what was your rebuild in the updates silo about?
[09:13] <Laney> also, can we retry builds in the landing PPAs?
[09:14] <didrocks> Laney: you can request the ci team to do that if you don't want to rebuild the MP itself
[09:15] <didrocks> Laney: some other people like pitti, rsalveti have access to it
[09:15] <didrocks> you can have if you don't mind the spam :)
[09:15] <Laney> https://launchpad.net/~ci-train-ppa-service/+archive/landing-010/+build/5633952
[09:15] <Laney> you can give me it you want ;-)
[09:15] <Laney> procmail is a beautiful thing
[09:16] <didrocks> Laney: one sec, giving to you. please, if you need to dput to a ppa direclty some stuff, target the right one! :)
[09:16] <Laney> hah
[09:16] <didrocks> Laney: you have power!
[09:17] <sil2100> Power \o/
[09:17] <Laney> thanks didrocks!
[09:17] <didrocks> yw ;)
[09:17] <Laney> I guess the spreadsheet won't notice if the retry succeeds though
[09:17] <Laney> 'watch only'?
[09:18] <didrocks> exactly :)
[09:28] <sil2100> didrocks: hmm, there's no morning meeting today?
[09:28] <Mirv> omg my trusty is so borken today
[09:29]  * sil2100 didn't get an e-mail
[09:29] <didrocks> sil2100: hum, there is
[09:29] <didrocks> I did receive it
[09:29] <didrocks> https://plus.google.com/hangouts/_/calendar/Y2Fub25pY2FsLmNvbV91cTRvNmQyMWJvNmJ0bm1mcW9xZWtsNTdnOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t.us2orfbhb8ssqjui2u15tajj3s
[09:29] <sil2100> grrrr
[09:29] <sil2100> didrocks: thanks
[09:29] <popey> 20 seconds!
[09:29] <popey> (ish)
[09:30] <seb128> Mirv, what's the issue with trusty?
[09:31] <didrocks> Mirv: can you come to the meeting or you are really really broken?
[09:32] <Mirv> comig
[09:36] <Mirv> sil2100: the lightdm thing is the same I saw at the sprint. but I have really no idea what has happened otherwise. I upgraded and did this stuff less than hour ago...
[09:36] <Mirv> it's possible removing lightdm messed up /etc/group or something like that
[09:36] <seb128> Mirv, what's the issue with lightdm?
[09:38] <Mirv> seb128: the issue I've been seeing is a cosmetic one, some background parts like the machine name's turn to grey when pressing enter, ie the UI looks wrong. I got that fixed once by reinstalling lightdm including resetting its configuration.
[09:39] <seb128> that doesn't make sense
[09:39] <Mirv> seb128: the rest of my problems are probably related to lightdm removal scripts or such breaking up other things, plus the fact that installing lxde/gdm etc is not completely smooth either
[09:39] <seb128> reinstalling a package makes no difference
[09:40] <Mirv> seb128: it was a combination of things I don't remember all of which, but I thought to try again to find out what's the reason behind the UI ugliness
[09:52] <psivaa> Mirv: https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/87/artifact/clientlogs/ubuntu_weather_app/
[09:52] <psivaa> has the crash file
[09:56] <Mirv> psivaa: thanks, got it
[10:12] <tvoss> sil2100, ping
[10:14] <sil2100> tvoss: pong!
[10:14] <tvoss> sil2100, I guess we are meeting in an hour from now on?
[10:14] <sil2100> tvoss: yep
[10:14] <tvoss> sil2100, ack and thx :)
[10:14] <sil2100> ;)
[10:33] <didrocks> Mirv: is the qmlscene crash good enough to work on it?
[10:33] <didrocks> Mirv: do not hesitate to involve the SDK team as well on that one :)
[10:33] <Mirv> didrocks: it was not, for some reason, but I edited it manually to get backtrace which should be soon ready on the device
[10:34] <didrocks> hgreat ;)
[10:34] <Mirv> didrocks: the .crash was missing "Package:" line
[10:34] <didrocks> ah ok
[10:34] <didrocks> seems apport tried to report it without sucess
[10:34] <didrocks> success*
[10:34] <didrocks> (probably due to sdk in proposed)
[10:35] <Mirv> and because I didn't start 'screen' on the device, I'm now stuck with LXDE and lxdm-binary consuming 100% CPU until the retrace is finished :P
[10:35] <didrocks> ahah :)
[10:37] <sil2100> didrocks: so, we're waiting for rsalveti to appear regarding the unity8 crashes - Saviq tried mapping the crash to a specific library, but it doesn't seem to be possible
[10:38] <sil2100> didrocks: that memory range doesn't seem to be mapped to any library
[10:38] <Saviq> didrocks, yeah, I can't get any symbol out of those :|
[10:39] <Saviq> /we should build non-stripped system.imgs
[10:39] <didrocks> Saviq: yeah, I was about to say that
[10:39] <didrocks> Saviq: just build for one device
[10:39] <didrocks> that will be quicker
[10:39] <didrocks> (in case you are using the package)
[10:40] <Saviq> didrocks, you'll have to give me more data on that
[10:40] <didrocks> ok, one sec, downloading the source
[10:40] <didrocks> I'll tell you what I did for this :)
[10:40] <Saviq> didrocks, appreciated
[10:41] <didrocks> Saviq: ok, so: debian/android-targets
[10:42] <Saviq> didrocks, which pkg?
[10:42] <didrocks> remove all lines you don't want :)
[10:42] <didrocks> apt-get source android
[10:42] <Saviq> right!
[10:42] <Saviq> of course ;D
[10:42] <didrocks> then in debian/rules
[10:43] <didrocks> remove everything in the override_dh_install: after the dh_install call
[10:43] <sil2100> That's hacky ;)
[10:43] <didrocks> (the 2 tar commands)
[10:44] <didrocks> rm debian/ubuntu-emulator*
[10:44] <didrocks> as well
[10:44] <didrocks> (even if that's not strictly needed)
[10:44] <didrocks> so then build
[10:44] <davmor2> Morning all
[10:44] <didrocks> it will take only 15 minutes on my machines instead of 15 minutes*number of devices
[10:44] <didrocks> wb davmor2!
[10:45] <didrocks> Saviq: finally, just dpkg-deb -x android<yourdevice>.deb foo
[10:45] <didrocks> you will have the img in foo/usr…
[10:45] <didrocks> sil2100: well, yeah, we should add more hacks to only build successfully for some sources :)
[10:46] <didrocks> Saviq: you will need a 32 bits chroot, I was never have able to build it on x64 here
[10:46] <Saviq> didrocks, oh ok good to know
[10:47] <Saviq> didrocks, anything special I need to tell sbuild to not strip the binaries?
[10:47] <didrocks> Saviq: the usual NOSTRIP (that you can hardcode in debian/rules while you are it to ensure ;))
[10:48] <didrocks> and then, just something like sbuild -d trusty -c trusty-proposed+multiverse-i386 --arch i386 android_<version>-0ubuntu1.dsc -A should do it
[10:49] <Saviq> didrocks, ok, going for it!
[10:49] <didrocks> good luck, do not hesitate if you have any questoin
[10:49] <didrocks> question*
[10:51] <Saviq> didrocks, thinks we should consider building debug-enabled system.img as part of our image builds or do you think we could get -dbgsym packages out of it?
[10:52] <didrocks> Saviq: I thinkg we should just create some -dbg and have system.img without being stripped part of that package
[10:52] <didrocks> (I don't think we can automate that as -dbgsym)
[10:52] <Saviq> didrocks, mhm, /me files bug
[10:52] <sil2100> Yeaaa
[10:53] <didrocks> but I'm maybe just on crack, I'm sure Ricardo is way more knowledgeable than I on that crazy package :) (I can understand the debian/rules though, so it's a start :p)
[10:53] <didrocks> basically it's creating in your sbuild an armhf source
[10:53] <didrocks> (so you have a chroot in chroot)
[10:53] <Mirv> qmlscene bug #1284581 seems inside the (now obsolete) V8 engine of Qt
[10:54] <didrocks> Mirv: I'm about to send an email with latest state, would you mind answering that?
[10:54] <Mirv> didrocks: ok
[10:54] <Mirv> I wonder if that's something Android 4.4 related
[10:55] <Saviq> didrocks, bug #1284583
[10:56] <didrocks> Saviq: thanks, I'll discuss that once the firefighting is off with Ricardo
[10:57] <ogra> hmm
[10:57] <ogra> that will put quite some build time penalty on us
[10:58] <Saviq> ogra, how often do we build that though?
[10:59] <ogra> once or twice a month ... but if you are waiting for it to roll a test image it is annoying to wait 1h more :)
[10:59] <ogra> how often do you actually need dbg symbols inside android ?
[10:59] <ogra> twice a release for one specific arch ?
[10:59] <Mirv> lightdm back, compiz still broken
[11:00] <Mirv> seb128: oh, sorry, I managed to forget what triggered my tinkering with lightdm - after today's dist-upgrade + reboot, I was for some reason not able to type anything in lightdm
[11:00] <Saviq> ogra, in lieu of that package, clear information on how to get it would be nice
[11:00] <xnox> Saviq: one can trivially locally build android with debug symbols, but we can't ship a debug img easily as it's too big and unflashable.
[11:00] <Mirv> mouse worked. now after this adventure also typing works, plus the funny UI issues are gone
[11:00] <Saviq> xnox, unflashable? crap
[11:00] <xnox> Saviq: thus one uses gdbserver, with debug symbols on the host and debug things over adb.
[11:01] <ogra> Saviq, yeah, i would even vote to have a PPA with debug builds ...
[11:01] <sil2100> Mirv: you can work-around that by clicking on one of the indicators and then clicking away
[11:01] <xnox> Saviq: but since that relies on relative paths, one does a local android build with /detached/ symbols.
[11:01] <ogra> xnox, the system.img should be fine
[11:01] <Mirv> sil2100: aha... :D
[11:01] <xnox> Saviq: flashes the images to devices and then does adb remote debugging with gdbserver.
[11:01] <seb128> Mirv, oh, right, that's a quite frequently reported issue :/ you can use indicators to workaround the typing bug, that gives the focus back to the entry
[11:01] <ogra> as it doesnt rely on y specific flash size
[11:01] <sil2100> Mirv: you can then type normally - I have it like every second boot
[11:01] <didrocks> Mirv: email sent
[11:01] <ogra> (it lives inside the ubuntu rootfs)
[11:01] <xnox> Saviq: i think rsalveti / sergiusens can guide you how to do it.
[11:02] <Mirv> didrocks: ok
[11:02] <ralsina_> Laney: barry asked for one
[11:02] <xnox> Saviq: it's been a while since i last had to do it.
[11:02] <Saviq> xnox, yeah, rsalveti is being waited on ;)
[11:02] <xnox> =))))
[11:07] <Laney> ralsina_: ah, well you can give a package name to just try that particular one (system-image in this case) to not use resources unnecessarily
[11:07] <Laney> anyway, his stuff doesn't build :(
[11:19] <didrocks> bzoltan: on https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/ubuntu-ui-toolkit-RC_2502/+merge/208064, the commit message is used to commit to trunk
[11:19] <didrocks> bzoltan: and in the changelog
[11:19] <didrocks> a better description will be needed I guess :)
[11:47] <t1mp> bzoltan: that MR itself won't be merged right?
[11:48] <bzoltan> t1mp: didrocks:  that is just a testing MR, not meant to land
[11:48] <bzoltan> t1mp: didrocks: what I proposed to land is in the CI sheet
[11:48] <didrocks> bzoltan: ah ok :)
[11:48] <t1mp> bzoltan: ok, clear. that's what I thought :)
[11:49] <bzoltan> t1mp: didrocks: I want to be sure that there are no conflicts between the MRs
[11:49] <t1mp> bzoltan: ++
[11:49] <didrocks> bzoltan: sure sure, you just frightened me :)
[11:50] <bzoltan> didrocks: Sorry for that :)
[11:50] <didrocks> heh, no worry :)
[12:11] <bregma> didrocks, shall we move the OIF packages under ci-train or should I just move them to regular Debian-sync releases?
[12:11] <didrocks> bregma: I would say citrain
[12:12] <bregma> of course you would, I didn;t expect any other answer :)
[12:12] <didrocks> why did you ask then? :p
[12:12] <didrocks>  bregma: btw, I fixed my unity issues
[12:12] <didrocks> was due to the decor plugin still loaded
[12:12] <didrocks> however
[12:12] <didrocks> now, I have no more Ctrl + Alt + T working :/
[12:13] <sil2100> bregma: oh! I see unity7 landing is ready to be assigned a silo
[12:13] <bregma> sil2100, yeah, I just did than, need a silo if you please
[12:15] <seb128> bregma, sil2100: wait
[12:15] <sil2100> seb128: too late, silo assigned ;/
[12:15] <bregma> seb128, is there a fix from xnox about to appear?
[12:16] <sil2100> seb128: we can reconfigure in a moment
[12:16]  * sil2100 was trigger-happy
[12:16] <seb128> bregma, https://code.launchpad.net/~xnox/unity/no-debug-symbols/+merge/208093 from this morning
[12:16] <seb128> sil2100, no worry, I just want debug symbols to be fixed with that landing
[12:17] <sil2100> bregma: can you add that to the MP list if needed ^ ?
[12:18] <didrocks> seb128: do we know what changed? the default CFLAGS doesn't have -g now?
[12:18] <bregma> sil2100, added, does the silo need a reconfigure?
[12:19] <sil2100> Yes, reconfiguring
[12:19] <seb128> didrocks, I don't know, https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1284047/comments/1
[12:20] <didrocks> seb128: yeah, I just read your command, but seems changing changed on the default CFLAGS anyway
[12:20] <didrocks> I guess there are quite some impacts on various packages
[12:20] <bregma> didrocks, I've run into that same problem in other packages, it seems there was a change to debhelper at some point
[12:20] <didrocks> bregma: interesting, ok
[12:21] <bregma> it explicitly says to not set CFLAGS, so the packaging was broken before and just happened to work
[12:21] <seb128> bregma, didrocks: http://irclogs.ubuntu.com/2014/02/24/%23ubuntu-devel.html#t10:56
[12:21] <seb128> "debhelper changed to BuildType=None, that might affect cmake based projects..."
[12:21] <seb128> not sure that's the issue there though
[12:22] <seb128> didrocks, bregma: the default flags seems to be fine, it's the hackery in debian/rules which is buggy (otherwise dropping those lines wouldn't be enough to fix it)
[12:22] <didrocks> seb128: ah, thanks :)
[12:22] <didrocks> yeah, at the time, it was the only way to remove -Wall though
[12:24] <bregma> I had the problem with an autotools project that set CFLAGS in the debian/rules file, it started losing hardening and debug flags after the build toolchain was upgraded after the last Debian release
[12:25] <bregma> fact is, Unity doesn;t need those fancy build flags any more, so good riddance
[12:25] <seb128> k
[12:27] <didrocks> yep :)
[12:30] <Saviq> didrocks, hey, so I got:
[12:30] <Saviq> ubuntu-android-ramdisk+mako.img
[12:30] <Saviq> ubuntu-preinstalled-boot-armhf+mako.img
[12:30] <Saviq> ubuntu-preinstalled-recovery-armel+mako.img
[12:30] <Saviq> ubuntu-preinstalled-system-armel+mako.img
[12:30] <Saviq> ubuntu-ramdisk+mako.img
[12:30] <Saviq> ubuntu-ramdisk-recovery+mako.img
[12:30] <Saviq> I assume -system- is what I want to flash, anything else?
[12:30] <didrocks> Saviq: yeah, I don't think you segfaulted on the recovery :p
[12:31] <didrocks> and the ramdisk are included in the preinstalled ones
[12:31] <Saviq> didrocks, and the corresponding ubuntu-*tar.xz as rootfs?
[12:31] <didrocks> Saviq: no, the system img is what you need alone
[12:31] <Saviq> didrocks, can I flash the system.img alone?
[12:32] <ogra> no
[12:32] <didrocks> ogra: there will be a mismatch?
[12:32] <ogra> it lives inside the ubuntu system.img file
[12:32] <ogra> flashing it wont gain you anything
[12:32] <didrocks> oh right
[12:32] <didrocks> you need to rebuild the image with it
[12:32] <didrocks> argh
[12:33] <ogra> you need to boot into recovery, loop mount /userdata/system.img and then put the android system.img file into /var/lib/lxc/android in there
[12:33] <Saviq> ogra, ok, trying
[12:33] <didrocks> ogra: if you do that once booted, do you expect to see bad things happening with libhybris?
[12:34] <ogra> (in recovery mode it is actually /data/system.img iirc)
[12:34] <ogra> didrocks, nope, as long as the hybris version is still the same
[12:34] <ogra> same goes for the kernel
[12:34] <didrocks> ok :)
[12:35] <ogra> (the modules live inside the android system.img)
[12:35] <didrocks> ok
[12:39]  * Saviq is worried there's no symbols
[12:39] <Saviq> same size :/
[12:40] <sil2100> ;/
[12:43] <Saviq> no booting grr
[12:47] <didrocks> ogra: are you sure not flashing the system partition is correct? We don't use anything from it, right?
[12:47] <didrocks> ogra: because https://wiki.ubuntu.com/Touch/Building doesn't match
[12:47] <ogra> thats for the old flipped model
[12:47] <ogra> not for system-image
[12:48] <didrocks> ogra: should probably be updated :) do we have one for system-image with similar instruction?
[12:48] <ogra> i dont think so
[12:48] <Saviq> didrocks, didn't boot :|, /me wonders if 207 would help
[12:49] <didrocks> Saviq: I don't think it would especially help, if you are already on 207…
[12:49] <didrocks> ooppss
[12:49] <didrocks> on 206
[12:49] <didrocks> I meant
[12:49] <Saviq> didrocks, but anyway, the file should be bigger, shouldn't it :|
[12:50] <didrocks> yeah, it should
[12:51] <didrocks> the aosp build system is complex, not sure they respect our flags…
[12:51] <Saviq> didrocks, yeah, I'm waiting for Ricardo
[12:51] <Saviq> he'll do it in 5s
[12:52] <didrocks> yep, sounds better :)
[12:52] <ogra> smells like you missed some build option when rolling the android package
[12:53] <Saviq> added to debian/rules:
[12:53] <Saviq> export DEB_BUILD_OPTIONS=nostrip noopt debug
[12:54] <Saviq> and commented out all emulator-related things
[13:02] <alan_g> cjohnston: Our (Mir) CI has started failing all MPs. Can you tell if something changed? https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/
[13:05] <didrocks> ogra: we don't use trusty-preinstalled-touch-armel+mako.zip    anymore, right?
[13:05] <didrocks> in system-image
[13:05] <ogra> nope
[13:05] <cjohnston> looking
[13:05] <ogra> but some ports do ...
[13:05] <ogra> (which is why i didnt remove it yet from the build)
[13:06] <didrocks> yeah
[13:10] <cjohnston> alan_g|lunch: I don't see anything that changed. I'm wondering if a release of something else maybe effected it
[13:10] <cjohnston> alan_g|lunch: I'll ask fginther to look when he comes around
[13:21] <rsalveti> morning
[13:21] <rsalveti> didrocks: Saviq: still checking emails, do you have a crash file available and how to reproduce the crash easily?
[13:35] <rsalveti> didrocks: ogra: awesome, dashboard for 207 looks way better
[13:35] <rsalveti> the pulse fix I did yesterday still didn't land
[13:35] <ogra> well, kind of
[13:35] <rsalveti> that will reduce cpu usage as well
[13:35] <rsalveti> ogra: well, system-settle is better (not sure if fixed :-)
[13:35] <ogra> rsalveti, we seem to have set CONFIG_RT_GROUP_SCHED in our kernel ... seems that prevents rtkit-daemon from functioning
[13:35] <didrocks> rsalveti: I don't have the crash file handy, Saviq has one
[13:35] <ogra> system-settle was re-written
[13:35] <didrocks> rsalveti: yeah, you are hit by beta freeze
[13:36] <rsalveti> ogra: is that preventing or are we missing some other options?
[13:36] <didrocks> rsalveti: otherwise, not a lot of progress overall (see my email entitled "summaring up issues on current touch…")
[13:36] <ogra> rsalveti, seems it is preventing on purpose if i read the docs right
[13:36] <rsalveti> yeah, we'll get more fixes til end of my day
[13:36] <rsalveti> :-)
[13:37] <rsalveti> ogra: oh, ok
[13:37] <ogra> rsalveti, waiting for stgraber to show up, he should know if we need that option at all
[13:37] <ogra> i assume having pulse in rt mode will give us some boost in audio stuff :)
[13:37]  * ogra would love if the kbd even made click sounds when you type fast)
[13:37] <rsalveti> hahah
[13:38] <ogra> it kind of looses it if you get to a certain typing speed
[13:38] <ogra> rsalveti, oh, and hammerhead ucm files uploaded ;)
[13:38] <rsalveti> ogra: \o/
[13:38] <ogra> not final but at least people have sound
[13:39] <rsalveti> that's awesome anyway
[13:39] <ogra> and comes fully from the community ... thats what i like most about it
[13:39] <ogra> :)
[13:40] <rsalveti> yeah
[13:43] <Saviq> rsalveti, yes I've a .crash (plenty of them, actually)
[13:43] <Saviq>  rsalveti, way to repro: phablet-test-run -p unity8-autopilot -n unity8
[13:43] <Saviq> rsalveti, but if possible and you have some time, I'd like to learn how to tackle this next time
[13:44] <rsalveti> Saviq: basically https://wiki.ubuntu.com/Touch/Core/UbuntuDebugAndroid
[13:45] <rsalveti> Saviq: but first you'd need a local build of your android
[13:45] <rsalveti> then you can get the libs with debug symbols (we should probably be exporting that somehow via android-dbg
[13:45] <rsalveti> I'll try to get to that later this week)
[13:46] <rsalveti> repo init -u https://code-review.phablet.ubuntu.com/p/aosp/platform/manifest.git -b phablet-4.4.2_r1
[13:46] <rsalveti> repo sync
[13:46] <rsalveti> source build/envsetup.sh
[13:46] <rsalveti> lunch aosp_mako-userdebug
[13:46] <rsalveti> that should get you the 4.4 based images
[13:47] <Saviq> rsalveti, bug #1284583 btw :)
[13:47] <rsalveti> Saviq: thanks
[13:47] <Saviq> rsalveti, but yeah, problem is... http://pastebin.ubuntu.com/6993715/
[13:48] <rsalveti> right, smells like android
[13:48] <Saviq> rsalveti, also, you can't get the map if you only got a .crash file
[13:48] <rsalveti> interesting that I coudn't get any crash when running the autopilot test this weekend
[13:48] <Saviq> rsalveti, it doesn't always happen
[13:48] <rsalveti> oh, I thought you had procmaps in there
[13:48] <Saviq> rsalveti, ah you're right
[13:48] <Saviq> in the .crash directly
[13:49] <Saviq> rsalveti, once in every 20-30 runs
[13:49] <rsalveti> got it
[13:49] <rsalveti> Saviq: can I get your crash file as well
[13:49] <rsalveti> ?
[13:50] <Saviq> rsalveti, of course
[13:50]  * Saviq preprocesses
[13:51] <Saviq> rsalveti, and how do I get a symbolized local build? we actually tried to build a complete system.img with nostrip, but that didn't work (same .img file size, and didn't boot anyway)
[13:51] <rsalveti> Saviq: yeah, need to change the build rules internally
[13:51] <rsalveti> that's what I'm planning to do to fix your bug
[13:52] <Saviq> rsalveti, so yeah, problem with the maps part is that, according to what I was able to find, no library is actually mapped at the address where it crashed :/
[13:52] <rsalveti> oh, hm
[13:52] <rsalveti> could this be mir related?
[13:53] <rsalveti> I know we had tls issues with mir as they are heavily using tls with c++11 now
[13:54] <Saviq> rsalveti, one thing I know is the crash happens after libcrypto causes SIGILL
[13:54] <Saviq> if that has any bearing
[13:54] <rsalveti> hm, that always happens
[13:54] <rsalveti> when it's testing for supported features
[13:57] <Saviq> rsalveti, yeah I know, just saying
[13:58] <rsalveti> yeah, I got annoyed by that once already
[13:58] <Saviq> rsalveti, http://people.canonical.com/~msawicz/_usr_bin_unity8.32011.crash
[13:59] <Saviq> rsalveti, so yeah, as you can see maps doesn't mention anything :|
[14:01] <Saviq> rsalveti, that's why /me wanted a fully symbolic system.img, if at all possible :|
[14:01]  * sil2100 jumps out to the vet again, quickie
[14:10] <Saviq> sil2100, lol
[14:41] <fginther> alan_g, looking at the mir failures. the only difference I see so far is that there is a new libc version in the builds that are failing tests
[14:42] <alan_g> fginther: alf_ wonders if it could be related to https://bugs.launchpad.net/mir/+bug/1284653
[14:42] <fginther> alan_g, hmmm, libc went from libc6_2.18-0ubuntu7_amd64.deb to libc6_2.19-0ubuntu2_amd64.deb
[14:46] <fginther> alan_g, ok, based on this bug, it looks the issue has been identified. Can you work with the foundations team to get a new valgrind built?
[14:46] <alan_g> kgunn: ^^
[14:47] <kgunn> alan_g: fginther ...yep, trying to get someone to reply :)
[14:47] <fginther> kgunn, thanks!
[14:47] <Saviq> rsalveti, so... I'll be your PITA today, can you point me anywhere which would tell me how to actually nostrip system.img?
[14:48] <rsalveti> Saviq: no worries, getting dedicated to your issue now
[14:49] <rsalveti> didrocks: diwic found why pulse is always consuming ~2% of the cpu, and he found the fix as well
[14:49] <rsalveti> didrocks: should hopefully land in the archive later today
[14:49] <rsalveti> better battery life as well :-)
[14:54] <didrocks> rsalveti: excellent, let's hope we can convince the release team to accept it despite the beta freeze :)
[14:54] <rsalveti> yeah
[14:55]  * didrocks really goes for a run before it's raining
[14:57] <ogra> just wait, will save you the shower afterwards
[14:58] <ogra> (take some shower gel with you though)
[14:59] <thostr_> sil2100: can i get a silo for line 30?
[15:03] <rsalveti> Saviq: I think this is all you need to have a not-stripped image: http://paste.ubuntu.com/6994774/ (at build/)
[15:03] <rsalveti> Saviq: checking still
[15:04] <Saviq> rsalveti, /me builds
[15:04] <rsalveti> argh, still stripping
[15:04] <rsalveti> Saviq: you also need the vendor files which I forgot: bzr branch lp:~rocket-scientists/aal+/aosp-vendor-4.4.2 vendor
[15:05] <rsalveti> let me do a clean build as well
[15:06] <sil2100> thostr_: let me see
[15:06] <Saviq> rsalveti, and where do I put the vendor files?
[15:07] <rsalveti> Saviq: builddir/vendor
[15:07] <rsalveti> builddir is your build dir root directory
[15:07] <Saviq> rsalveti, I'm actually in `apt-get source android`
[15:08] <rsalveti> Saviq: oh, if you rebuild that it'll work fine, as it copies the files from the android-src-vendor package
[15:08] <rsalveti> Saviq: worked, not stripping anymore
[15:08] <Saviq> rsalveti, so just the TARGET_STRIP_MODULE=?
[15:09] <rsalveti> just apply as a package patch http://paste.ubuntu.com/6994804/
[15:09] <sergiusens> doanac`, hey, did you get my message last night about the ap args MR? still needs to rebase with xnox's changes
[15:11] <xnox> sergiusens: hm? anything needed from me?
[15:13] <sergiusens> xnox, not really; just push doanac` to merge to get your stuff in
[15:14] <Saviq> rsalveti, ok, and then I put the resulting system.img into loop-mounted system.img at /var/lib/lxc... and that should be it, right?
[15:17] <pmcgowan> fginther, is anyone from CI team assigned to qt5.2 related issues?
[15:20] <fginther> pmcgowan, not specifically that I'm aware of. ev, doanac`, plars, psivaa ^
[15:20] <pmcgowan> fginther, if not I would like someone to be, to help tracking during the landing
[15:21] <psivaa> fginther: pmcgowan: could be Mirv
[15:21] <psivaa> Mirv: apologies if you're not :)
[15:22] <pmcgowan> psivaa, well we need someone from the CI team to help Mirv
[15:22] <doanac`> sergiusens: forgot about the MP. i'll get it updated this morning.
[15:37] <fginther> pmcgowan, I'll follow up with ev
[15:37] <pmcgowan> fginther, thanks
[15:39] <doanac`> sergiusens: branch is updated now. thanks
[15:46] <sergiusens> great doanac`
[15:52] <rsalveti> Saviq: yes
[15:53]  * rsalveti back from lunch
[15:53] <rsalveti> Saviq: were you able to build the image?
[15:57] <rsalveti> Saviq: getting forbidden at your crash file
[15:58] <Saviq> rsalveti, yeah, just built, needed 40 mins, doesn't want to use ccache somehow
[15:59] <Saviq> rsalveti, grr, try again
[15:59] <rsalveti> thanks, downloading now
[15:59] <Saviq> rsalveti, stoopid people.c.c and its umask
[16:04] <Saviq> rsalveti, so yeah, not booting :/
[16:05] <Saviq> got a 0123456789ABCDEF        device
[16:05] <rsalveti> Saviq: anything in logcat?
[16:06] <Saviq> rsalveti, "android isn't running" when tried to get into lxc-console
[16:06] <Saviq> lxc-start: failed to run pre-start hooks for container 'android'.
[16:07] <rsalveti> right
[16:07] <rsalveti> can you check if logcat tells you something?
[16:08] <rsalveti> let me try to boot my image
[16:08] <Saviq> rsalveti, how do I logcat without android running?
[16:08] <Saviq> /bin/bash: line 0: exec: logcat: not found
[16:09] <ogra> /system/bin/logcat
[16:09] <Saviq> [  321.857652] EXT3-fs (loop1): error: can't find ext3 filesystem on dev loop1.
[16:09] <Saviq> [  321.939844] EXT2-fs (loop1): error: can't find an ext2 filesystem on dev loop1.
[16:09] <Saviq> [  322.009766] EXT4-fs (loop1): VFS: Can't find ext4 filesystem
[16:09] <Saviq> [  322.069677] adjust_soc: ibat_ua = -92200, vbat_uv = 4234436, soc = 100, batt_temp=331
[16:09] <Saviq> [  322.079810] FAT-fs (loop1): bogus number of reserved sectors
[16:10] <Saviq> [  322.079902] FAT-fs (loop1): Can't find a valid FAT filesystem
[16:10] <Saviq> ogra, no such file
[16:10] <Saviq> seems the generated system.img isn't mountable
[16:10] <ogra> oh, ah
[16:10] <ogra> wait a sec
[16:11] <ogra> bzr branch lp:project-rootstock-ng
[16:11] <ogra> Saviq, take a look at the "convert_android_img()" function
[16:11] <ogra> you want to do this first
[16:11] <rsalveti> oh, right
[16:11] <rsalveti> you need simg2img first
[16:11] <ogra> android-tools-fsutils
[16:11] <ogra> install that
[16:11] <sil2100> o_O
[16:12] <ogra> system-image converts the img file
[16:13] <Saviq> it grew to 840M...
[16:13] <Saviq> but yeah, that's mountable
[16:13] <rsalveti> lol, yeah
[16:14] <rsalveti> you probably want resizefs as well
[16:16] <Saviq> ok, that's better
[16:19] <didrocks> ogra: no, I still need a shower :) using some gel on the bicycle on the way back will be my next goal I guess :)
[16:19] <sergiusens> doanac`, so now that it's built can you check https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=21 against with your ci stuff?
[16:19] <ogra> optimization ftw :)
[16:19] <didrocks> heh
[16:20] <didrocks> ogra: well, not too much, yesterday I almost got a car/bike unattending meeting
[16:20] <didrocks> (and I was the bike)
[16:20] <ogra> ouch
[16:21] <didrocks> yeah, one way road, by bike are two ways
[16:21] <didrocks> when cars arrive on that road, they tend to only look at one direction… not both
[16:21] <Saviq> yay! we have a boot!
[16:22] <didrocks> there is a huge line drawn to say look at the bikes on the other side, but they don't… So I'm careful most of the time
[16:22] <didrocks> but this car was just racing…
[16:23] <didrocks> Saviq: so booting a 840M android image? :p
[16:23] <doanac`> sergiusens: ack.
[16:23] <Saviq> didrocks, no, 250M
[16:23] <didrocks> ah ;)
[16:23] <didrocks> still 5 times more
[16:24] <Saviq> didrocks, no
[16:24] <Saviq> didrocks, just twice
[16:24] <Saviq> didrocks, it's 107M currently
[16:24] <didrocks> ah, uncompressed, I was talking about the .zip size
[16:24] <Saviq> the stock one, that is
[16:24] <didrocks> yep
[16:26] <Saviq> yikes reports.qa is slow these days :/
[16:29] <rsalveti> yeah
[16:30] <didrocks> ogra: what does simg2img practically speaking? (no manpage, no --help)
[16:31] <ogra> sparse image to image
[16:31] <sergiusens> Saviq, it is, use the internal one through the vpn
[16:31] <seb128> didrocks, sil2100: l42 has the indicator-datetime fixes-only landing ready
[16:31] <ogra> sparse is a special format android uses ... theoretically it should be growable
[16:32] <rsalveti> Saviq: yeah, crashed in the heap, so might not be android related after all
[16:32] <rsalveti> Saviq: wonder if it could be tls related
[16:32] <didrocks> ogra: ah, and so, we convert to ext4?
[16:32] <sil2100> seb128: sure
[16:32] <ogra> didrocks, right, so we can mount it
[16:32] <Saviq> rsalveti, got a fresh .crash, let's see if I get anything...
[16:32] <didrocks> ogra: got it!
[16:33] <Saviq> rsalveti, no dice ;(
[16:33] <didrocks> Saviq: I guess you have as well the qt dbgsym?
[16:33] <Saviq> didrocks, it doesn't even get to qt
[16:33] <seb128> sil2100, thanks
[16:33] <didrocks> Saviq: sometime, for some unknown reasons, I saw some smashed stacktrace
[16:33] <didrocks> somtimes*
[16:33] <didrocks> with only 2 frames
[16:33] <didrocks> installed the qt debug symbols
[16:33] <sil2100> grrr
[16:33] <didrocks> and then, the stacktrace is readable and has more frames
[16:33] <Saviq> ok /me does again
[16:33] <rsalveti> Saviq: still heap?
[16:34] <didrocks> I have NO idea how this is possible if you ask me :)
[16:34] <rsalveti> Saviq: how could you easily reproduce that again? running autopilot?
[16:34] <rsalveti> Saviq: joining meeting as well?
[16:34] <Saviq> rsalveti, yeah, and yeah
[16:34] <didrocks> rsalveti: yeah, it's triggering it
[16:34] <rsalveti> great, testing with a fresh image now
[16:36] <Saviq> rsalveti, yeah, heap, and still no symbols
[16:36] <rsalveti> yeah, hate those crashes
[16:36] <rsalveti> we had similar issues with tls and gcc 4.7 x gcc .48
[16:37] <rsalveti> 4.8
[16:37] <rsalveti> ports is so slow for me :-(
[16:38] <sil2100> Then we're still in the blind ;/
[16:40] <rsalveti> not necessarily
[16:41] <ogra> rsalveti, us.ports.u.c isnt better ?
[16:41] <rsalveti> ogra: not much, probably because of ricmm
[16:41] <rsalveti> haha
[16:41] <ogra> ah, right
[16:41] <ogra> he trades the bytes for toilet paper
[16:43] <asac> printfs :/
[16:43] <rsalveti> I believe this might be tls related
[16:43] <rsalveti> or could be a side effect of forcing stuff to gcc 4.7 / 4.8
[16:45] <asac> are there other ways we can extract some info? valgrind, lttng etc.?
[16:45] <rsalveti> valgring should help, but the problem is that it only happens when running autopilot
[16:45] <ogra> pliers
[16:46] <asac> rsalveti: why is autopilot conflicting with the valgrind idea?
[16:46] <rsalveti> asac: not conflicting, but autopilot is running a bunch of tests, not only one that we can also run separately and get the crash
[16:47] <asac> right, but maybe valgrind always complains about stuff that later will cause this problem
[16:47] <rsalveti> could be
[16:47] <asac> so we might see it without reproducig it
[16:47] <rsalveti> autopilot is still running here
[16:49] <asac> rsalveti: what did we do to force stuff to 4.7?
[16:50] <ogra> add a build dep
[16:50] <rsalveti> asac: platform-api is using 4.7, because it's the same compiler used by the android package
[16:50] <rsalveti> together with that we're also building other packages with 4.7,like location-service
[16:50] <rsalveti> but we know we had heap issues when mixing both things together
[16:50] <didrocks> especially if you use C++11 features
[16:50] <rsalveti> like stuff built with 4.8 using platform-api that was built with 4.7
[16:50] <rsalveti> and we know that mir is now using tons of c++11 stuff
[16:51] <didrocks> (we have already been hit by that with 4.6 vs 4.7)
[16:51] <didrocks> gcc upstream fixed the ABI breakage, but not sure something else didn't slip in again
[16:51] <rsalveti> well, but that was fixed with 4.8
[16:51] <rsalveti> that's why it's so annoying
[16:51] <didrocks> so you think they rebreak the ABI the other way around?
[16:52] <didrocks> to be compatible with 4.6?
[16:52] <asac> so looking at latest image run, it seems the systemsettle dragon did fly away? or did we adjust the threshold?
[16:52] <rsalveti> abi was fixed with 4.8, that's why we have issues when mixing stuff built with 4.7
[16:52] <didrocks> ok
[16:52]  * didrocks remembers a nice nux vs unity7 explosion at the time
[16:52] <asac> you cant mix C++ stuff from differnet gcc versions
[16:53] <didrocks> asac: you should be able to as per upstream says
[16:54] <asac> maybe we still have 4.6 mixed in?
[16:54] <asac> :)
[16:54] <rsalveti> no, hope not
[16:54] <rsalveti> lol
[16:54] <asac> seems systemsettle is indeed again at > 99
[16:54] <tvoss> rsalveti, so Mir is bringing in 4.8 to the platform api, correct?
[16:54] <rsalveti> tvoss: yes
[16:54] <rsalveti> is unity8 using platform-api as well?
[16:54] <rsalveti> maybe indirectly
[16:55] <tvoss> Saviq, is unity8 using the mir-server implementation of platform-api?
[16:55] <Saviq> tvoss, it's using the ubuntumirserver QPA, so I'd say yes
[16:57] <tvoss> Saviq, rsalveti and at that point we have got a 4.7 x 4.8 mixture iirc
[16:57] <rsalveti> Ran 46 tests in 962.789s
[16:57] <tvoss> iiuc even
[16:57] <rsalveti> OK
[16:57] <rsalveti> Restoring shell
[16:57] <rsalveti> Saviq: ^
[16:57] <rsalveti> let me try again
[16:57] <ogra> asac, yeah, we just hardcoded that :P
[16:58] <Saviq> rsalveti, yeah, *sometimes* it works
[16:58] <Saviq> rsalveti, I mean it crashes maybe 5% of the time
[16:59] <asac> ogra: who gets the ida to hardcode a value that is not 100%? :)
[16:59] <tvoss> Saviq, rsalveti if it's a race, valgrind might help
[16:59] <asac> ogra: its 99.4 ... what a crazy idea :)
[16:59] <asac> or is there any insider meaning on 99.4?
[16:59] <ogra> asac, carefule people that know that you will look ;)
[16:59] <asac> :)
[17:00] <asac> lol
[17:00] <rsalveti> lol
[17:00]  * Saviq is down to 15M free on rootfs...
[17:00]  * ogra is silly today ... that what reading cgroup docs all day does to you
[17:00] <asac> err
[17:00] <Saviq> no, actually 8.1M
[17:01] <rsalveti> you could resize from recovery
[17:01] <ogra> Saviq, du -hcs /var/log/*
[17:01] <ogra> ;)
[17:01] <rsalveti> ricmm got the statically-linked recovery binary
[17:01] <ogra> rm -rf /var/log/*
[17:02] <rsalveti> rm -rf /
[17:02] <rsalveti> DONE
[17:02] <rsalveti> :P
[17:02] <Saviq> ogra, that's not rootfs ;)
[17:02] <ogra> :)
[17:02] <sil2100> Crap, meeting!
[17:02] <ogra> Saviq, oh, the android system ?
[17:03] <Saviq> ogra, no, ubuntu
[17:03] <Saviq> ogra, /var* is rw-mounted, isn't it?
[17:03] <Saviq> aaaaanyway
[17:03] <ogra> it is
[17:03] <asac> plars: how long do we wait for the top now?
[17:03] <Saviq> no dice
[17:03] <Saviq> #0  0x39c0d8f8 in ?? ()
[17:03] <Saviq> No symbol table info available.
[17:03] <Saviq> #1  0x39c2d7e8 in ?? ()
[17:03] <Saviq> No symbol table info available.
[17:03] <sil2100> hm hm
[17:04] <rsalveti> Saviq: can you try the following patch: http://paste.ubuntu.com/6995323/
[17:04] <plars> asac: I changed systemsettle yesterday so that we no longer use top to find the idle%, we use /proc/stat instead. Top is still used (same timings as before) to get data that can be used to see what was eating cpu though
[17:04] <rsalveti> under builddir/bionic
[17:04] <rsalveti> I can upload the image as well
[17:04] <Saviq> rsalveti, will do, building
[17:04] <asac> plars: sure, saw your commit... wonder if we also changed parameters for top_wait etc.
[17:05] <plars> asac: no, but there's a new parameter for the sleep between the /proc/stat snapshots. Default is 10 seconds (and it runs at each iteration as it would have when we use top) but it's configurable.  So basically it's sampling cpu usage for 10 seconds each iteration
[17:10] <Saviq> rsalveti, that's probably the time for you to tell me how to *not* build the package every time, as it takes 40 mins...
[17:11] <rsalveti> Saviq: first thing, are you only building for mako?
[17:11] <Saviq> rsalveti, yes
[17:11] <rsalveti> then yeah, only using ccache to be faster
[17:12] <Saviq> rsalveti, having followed didrocks' pointers on that
[17:12] <rsalveti> or just rebuilding without building the entire package
[17:12] <Saviq> rsalveti, well, yeah, I'm gonna go that way, dpkg-buildpackage -nc FTW
[17:12] <rsalveti> using lunch then make
[17:12] <rsalveti> :-)
[17:12]  * Saviq wonders why ccache in sbuild didn't cut it
[17:13] <rsalveti> argh, also got a crash when changing tls, but also in the heap
[17:13] <Saviq> libcaca? like wth does android use libcaca for!?
[17:14] <didrocks> rsalveti: yeah, I just have some hackish way to change debian/rules to just build for one device :)
[17:20] <rsalveti> let me try to disable android tls for arm, just like we do for x86 now
[17:20] <rsalveti> if we still get a crash, then it's not hybris
[17:24] <Saviq> rsalveti, I like it how you build a chroot in those debian/rules ;d
[17:24] <rsalveti> haha, yeah
[17:24] <rsalveti> xnox created most of that logic
[17:25] <ogra> we have some really weird package hacks in touch :)
[17:25] <ogra> if you want to see the worst, take a look at initramfs-tools-ubuntu-touch's build :)
[17:26] <xnox> rsalveti: i claim no ownership, it's all copied off other dodgy corners of our archive =))))
[17:26] <ogra> fakeroot and fakechroot stacked chroots building an initrd for arm on x86
[17:26] <balloons> sil2100, I have a potential fix for the terminal issue
[17:26] <rsalveti> xnox: :-)
[17:26] <xnox> Saviq: you can limit that package to only build flavour you are after to cut down the time....
[17:27] <sil2100> balloons: !
[17:27] <Saviq> xnox, I did
[17:27] <xnox> Saviq: oh, i see =) sorry.
[17:27] <sil2100> balloons: you were able to reproduce it? What was the problem?
[17:27] <xnox> we may still build things we don't use =/
[17:27] <Saviq> xnox, but I built in a ~clean sbuild every time, so it still took quite some time
[17:27] <Saviq> xnox, for some reason it doesn't use ccache
[17:28] <xnox> Saviq: there is little to cache.... and it tends to eat up more that cache provides.
[17:28] <xnox> Saviq: it takes ~35 minutes to build everything on my machine.
[17:28] <Saviq> xnox, everything?
[17:28] <xnox> Saviq: yes, i build in RAM.
[17:28] <Saviq> xnox, as in all the targets?
[17:28] <Saviq> xnox, yes, /me too
[17:28] <xnox> yes.
[17:29] <balloons> I haven't reproduced, but I suspect the issue is with the app catching the touch event.
[17:29] <Saviq> xnox, quad-core i7 with HT
[17:29] <xnox> 32GB ram + parallel 12.
[17:29] <Saviq> ok well
[17:29] <Saviq> still shouldn't be that much
[17:29] <Saviq> took 40 mins last time :/
[17:29] <xnox> Saviq: crank up DEB_BUILD_OPTIONS=parallel=x, to floor(RAM in GB/2)
[17:29] <xnox> Saviq: well, at the time it was 4 products, not sure how many it builds these days.
[17:30] <balloons> what we can do is clean up the test to assert a bit better about where the failure actually occurs to narrow this down
[17:30] <Saviq> xnox, 5 these days
[17:31] <balloons> and if the touch event isn't being captured, we can decide if it's an issue with the platform, or if we need to work around the timing issue
[17:31] <Saviq> xnox, and I usually use -j9
[17:32] <balloons> I'll tweak it a bit, and try it out.. phone is flashing new image now
[17:32] <xnox> Saviq: i find overcommitting to perform better, monitor the load if it's less than number of cores, you are stalling.
[17:32] <balloons> sil2100, sorry see my responses mixed above ^^ :-)
[17:34] <Saviq> huh... 80% idle at -j12... pfft!
[17:34] <sil2100> balloons: makes sense ;) We would at least know if it's really the case once it actually happens
[17:34] <sil2100> balloons: since so far from the logs all seemed ok
[17:34]  * Saviq wonders if byobu doesn't slow it down at that point...
[17:35] <balloons> sil2100, right, I was talking with bfiller_afk about the dialer app tests which had a similar thing.. the tests don't fail well, that is to say it's ambiguous as to what failed.
[17:37] <Saviq> xnox, hmm hmm, does it actually build in parallel for you?
[17:37] <Saviq> xnox, make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
[17:38] <rsalveti> Saviq: in case you want to disable android tls http://paste.ubuntu.com/6995480/
[17:38] <rsalveti> that will force it to use pthread_set/getspecific instead
[17:38] <xnox> Saviq: it used to.... can you paste full build log to paste.ubuntu.com for me to check?
[17:39] <rsalveti> last time I built the package I built all in parallel
[17:39] <rsalveti> it uses make now
[17:39] <Saviq> xnox, grr, just cleared the old logs...
[17:40] <Saviq> xnox, will get it to you asap
[17:40] <xnox> Saviq: well, whenver you build it again =)
[17:43] <rsalveti> while true; phablet-test-run -p unity8-autopilot -n unity8; done;
[17:43]  * rsalveti waits for the crash
[17:44] <xnox> =)))))))))))))
[17:45] <xnox> should have added "; alert" at the end.
[17:45] <xnox> rsalveti: to get the bubble notification.
[17:45] <rsalveti> lol, indeed
[17:45] <rsalveti> got that alias as well
[17:45] <xnox> it's default on all ubuntus i believe =)
[17:46] <rsalveti> oh, awesome
[17:47] <rsalveti> Saviq: got the same crash with android tls disabled :-(
[17:47] <rsalveti> so good and bad news
[17:47] <Saviq> I=0; while true; do I=$(( $I +1 )); echo -n "$I: "; if phablet-test-run -n unity8 &> /dev/null; then echo OK; else echo BAD; fi; done
[17:47] <Saviq> and on device:
[17:48] <Saviq> while true; do echo -n .; if ls /var/crash/*.crash &> /dev/null; then ps aux | grep apport | grep -v grep &> /dev/null && continue; echo; STAMP=$(date +%s); mkdir $STAMP; mv /var/crash/*crash $STAMP; ls $STAMP; fi; sleep 2; done
[17:49] <Saviq> rsalveti, and syntax error near: phablet-test-run :P
[17:49] <rsalveti> Saviq: yeah :P
[17:49] <Saviq> rsalveti, right, so any idea about next steps?
[17:50] <rsalveti> got another crash, checking
[17:50] <Saviq> xnox, http://paste.ubuntu.com/6995550/ partial, but should maybe be enough for you to see
[17:51] <rsalveti> yeah, heap again
[17:51] <xnox> Saviq: you don't set parallel option at all.....
[17:52] <xnox> Saviq: hence a serial -j1 build is enforced.
[17:52] <Saviq> xnox, sbuild -j9 usually did that for me?
[17:52] <xnox> Saviq: no, that doesn't work for a few releases now.
[17:52] <Saviq> xnox, oh!
[17:52] <xnox> Saviq: in ~/.sbuildrc, update $build_environment
[17:53] <xnox> Saviq: e.g. $build_environment = { 'DEB_BUILD_OPTIONS' => 'parallel=12'};
[17:53] <Saviq> xnox, you must be kidding me ;P
[17:53] <rsalveti> xnox: is there any way to also produce a 4.8 based gcc-arm-linux-androideabi?
[17:53] <xnox> Saviq: ditto in ~/.bash_aliases i have: export DEB_BUILD_OPTIONS='parallel=12'
[17:54] <Saviq> xnox, in _aliases?
[17:54] <xnox> rsalveti: sure, i can build a 4.8 based one. I was thinking that maybe platform-api is enforced to 4.7, because of all of android built using 4.7.
[17:54] <rsalveti> xnox: exactly
[17:54] <rsalveti> xnox: but wanted to give android a try with 4.8
[17:54] <xnox> Saviq: yeah, it's sourced by default in ~/.bashrc, and it means that I can replace ~/.bashrc with a stock one from /etc/skel easily =)
[17:55] <Saviq> xnox, yup
[17:55] <xnox> rsalveti: ack. I'm working on updating all cross-compilers, i'll ping you ones i have the ones you are after.
[17:55] <rsalveti> Saviq: is the autopilot test using the system-compositor as well?
[17:56] <rsalveti> xnox: awesome
[17:56] <xnox> rsalveti: x86-android fails to compile binaries for me, investigating, spinning up a 4.8 for arm-android should be quicker.
[17:56] <rsalveti> yeah
[17:57] <Saviq> rsalveti, nope
[17:57] <xnox> (2 down, 5 to go....)
[17:58] <rsalveti> Saviq: but are we disabling it before running the tests?
[17:58] <rsalveti> or better, should we?
[17:59] <Saviq> rsalveti, it shouldn't matter, it just displays fullscreen unity8 these days, doesn't it?
[18:00] <rsalveti> Saviq: right, but wonder if we could have issues with the framebuffer somehow as we'd have 2 servers running at the same time
[18:01] <Saviq> rsalveti, could be, I wasn't really involved in the u-s-c enabling, didn't know it even happened
[18:02] <rsalveti> right
[18:02] <Saviq> ok now it's definitely byobu slowing it down ^_^
[18:03] <Saviq> /my terminal stopped responding :D
[18:05] <rsalveti> Saviq: I'd also give it a try without u-s-c
[18:07] <rsalveti> meanwhile I'm rebuilding plat-api
[18:07] <ogra> as long as unity8 is stopped via upstart u-s-c should be fine
[18:07] <rsalveti> ogra: but I don't think unity8 autopilot tests are actually using u-s-c
[18:07] <rsalveti> it starts/stops unity8 a bunch of times
[18:07] <ogra> why would that matter ?
[18:08] <rsalveti> and probably starting it by hand, not using u-s-c mir socket
[18:08] <ogra> AP only generates user input, no ?
[18:08] <ogra> yeah, that would be evil
[18:08] <ogra> thats why i said via upstart is fine
[18:08] <Saviq> rsalveti, ogra, yeah, we're doing it via upstart
[18:08] <ogra> then you got the socket and all
[18:09] <rsalveti> alright, then it should be using u-s-c
[18:10] <Saviq> now that's better
[18:13] <Saviq> xnox, I think -jfoo still works, but I added an export of DEB_BUILD_OPTIONS to debian/rules temporarily, and that overrode it
[18:13] <rsalveti> zzzz, 15kb/s from ports
[18:14] <Saviq> rsalveti, apt-cacher-ng ftw, let me know if you need me to try anything
[18:14] <rsalveti> Saviq: just going to rebuild platform-api and location-service to use 4.8 instead
[18:14] <Saviq> rsalveti, mhm
[18:14] <asac> rsalveti: dont you use the US mirror?
[18:14] <asac> thought we had that set up for you americans
[18:15] <rsalveti> yeah, but that's also slow for me today
[18:15] <rsalveti> probably because of venezuela
[18:15] <rsalveti> lol
[18:15] <rsalveti> the main cable still goes via venezuela
[18:16] <Saviq> and ricmm isn't here to blame 'im
[18:17] <rsalveti> exactly, already pinged him twice
[18:17] <asac> robru-is-dying: is dying better than deathly?
[18:17] <rsalveti> he's probably fighting the government
[18:17] <robru-is-dying> asac, 'robru-is-deathly-ill' didn't fit, but i wasn't aware of the limit until i tried.
[18:17] <asac> robru-is-dying: isnt deathly the active (e.g. you are killing)? :)
[18:17] <asac> ah ok
[18:18]  * robru-is-dying seriously though is going to lie down for a bit
[18:18] <asac> robru-is-dying: get better
[18:19] <asac> robru-is-dying: who can sasign silos etc. in case a good fix comes up?
[18:19] <asac> cyphermox: ?
[18:19] <asac> cyphermox: will you be around for a bit?
[18:20] <Saviq> find [...] -o -name DEADJOE ?¿???
[18:20] <cyphermox> asac: just about to go out to get lunch
[18:21] <asac> cyphermox: but will be back, right?
[18:21] <cyphermox> I'll be back in an hour or so
[18:21] <cyphermox> yes
[18:21] <asac> cool. dont let us down :)
[18:21] <asac> enjoy!
[18:21] <asac> cyphermox: you are last man standing with full powers
[18:21] <asac> :)
[18:21] <cyphermox> until dinner, and then back again until very late
[18:21] <asac> but we only land regression fixes, so should be fine
[18:21] <cyphermox> sure
[18:21] <cyphermox> bbl
[18:41] <ogra> aww, crap
[18:42] <fginther> sergiusens, are you still fighting that unity8 MP? I was able to reproduce the failures on my maguro
[18:42] <ogra> igh sigh sigh
[18:44] <asac> fginther: maguro?
[18:44] <fginther> asac, it's what I have
[18:44] <ogra> so there was this accidential removal of click-update-manager (to upgrade apps) ... in image 194
[18:44] <sergiusens> fginther, haven't touched it yet
[18:45] <ogra> we seeded it back ... but havent promoted an image since
[18:45] <ogra> :(
[18:45] <ogra> people cant upgrade their apps since a week
[18:45] <sergiusens> fginther, but mzaneti explained that regardless, it would fail on otto
[18:45] <asac> ogra: thats awful
[18:45] <ogra> asac, yes
[18:46] <asac> ogra: how did that happen exactly? is that thing not seeded directly?
[18:46] <sergiusens> fginther, I wonder if I propsed an empty MR if I'll still get these failures
[18:46] <fginther> sergiusens, I'll build trunk and see
[18:46] <ogra> asac, it is, i was pinged by the click lens guys to drop it since they assumed a feature would have landed in system-settings to take over that task
[18:47] <doanac`> sergiusens: i've been testing the updated phablet-tools branch. I think it looks good
[18:47] <sergiusens> fginther, oh btw; if you tested at home, make sure /home/phablet/autopilot did not exist as it would take precedence
[18:47] <ogra> asac, it was added back two days later when we discovered that this feature didnt exist
[18:47] <sergiusens> doanac`, great; did you get clicks sort tested there as well (just in case)
[18:47] <ogra> asac, but we didnt promote anything since 194 ... which was the image that dropped it ... 202 has it back
[18:47] <fginther> sergiusens, what's the background on these tests not working on otto, is this a case where the tests need to be disabled on desktop?
[18:48] <ogra> asac, there is a thread about it on the ML from last week
[18:48] <sergiusens> doanac`, I did add prerequesites of what needs to work
[18:48] <sergiusens> fginther, a missing implementation in unity itself and the lack of a uri handler
[18:48] <doanac`> sergiusens: "clicks sort"?
[18:48]  * sergiusens rereads what he wrote
[18:49] <sergiusens> doanac`, clicks sort of :-
[18:49] <sergiusens> :-)
[18:49] <sergiusens> ah
[18:49] <doanac`> sergiusens: yeah. i tested some click packages. here's the apps i just finished testing: dropping_letters_app unity8 mediaplayer_app ubuntuuitoolkit gallery_app notes_app webbrowser_app
[18:50] <ogra> asac, it is in the "Landing team 20.02.14" thread
[18:51] <doanac`> sergiusens: actually - might have a problem: http://q-jenkins.ubuntu-ci:8080/job/andy-autopilot-trustytouch-daily_release/label=test_execution_service-mako/22/artifact/clientlogs/unity8/test_results.xml/*view*/
[18:51] <plars> Can someone with a flo give the webbrowser ap tests a try? This is twice (out of 2 tries) that I'm seeing it get stuck during those tests
[18:52] <plars> both times, on the webbrowser_app.tests.test_tabs.TestTabs.test_tabs_model test
[18:53] <doanac`> sergiusens: that almost looks like some python2/3 type stuff
[18:57] <sergiusens> doanac`, it is
[18:58] <sergiusens> xnox, look at http://q-jenkins.ubuntu-ci:8080/job/andy-autopilot-trustytouch-daily_release/label=test_execution_service-mako/22/artifact/clientlogs/unity8/test_results.xml/*view*/
[18:59] <sergiusens> very easy to fix in unity8 fwiw but maybe you want to keep using py2 for it for now
[19:03] <plars> balloons: you don't happen to have a flo do you?
[19:06] <balloons> plars, no I do not. manta and mako
[19:07] <rsalveti> Saviq: I just hate so much that it takes so much time to build c++
[19:07] <rsalveti> still rebuilding the packages that were using 4.7
[19:09] <rsalveti> ricmm: why do we have a circular dependency between platform-api and location-service?
[19:11] <plars> balloons: who's a good contact for webbrowser that might have a flo then, do you know? bfiller_afk?
[19:11] <ricmm> rsalveti: kind of, platform-api provides the hardware-api which is used by location-service
[19:11] <ricmm> in turn platform-api provides the application-api, which uses the location-service
[19:11] <balloons> I'm not sure if om26er has one, but he's pinged now
[19:11] <ricmm> but the dependency is only circular when both things change at once, it is always avoidable with sequential MRs
[19:11] <ricmm> as it should be, anyways
[19:11] <asac> balloons: we shipped you an N7 afaik
[19:11] <asac> balloons: let me see
[19:12] <rsalveti> ricmm: right, I'm just rebuilding both things with 4.8
[19:12] <asac> awesome... seems it didnt happen.
[19:12] <asac> let me get on it
[19:12] <balloons> asac, oO, news to me..
[19:12] <rsalveti> ricmm: so, you were not here, but basically we got an issue with unity8
[19:12] <asac> balloons: you got one allocated like 2-3 weeks ago
[19:12] <rsalveti> ricmm: thought it was tls, removed tls, still there
[19:12] <plars> asac: I'm just looking for someone who can help see what's going on with this webbrowser ap test on flo. I have flo up and running images in CI but it keeps getting stuck here
[19:12] <rsalveti> ricmm: crashing inside the heap
[19:13] <balloons> asac, gotcha, I'll expect it in the mail then. It would be useful to have, thank you
[19:13] <rsalveti> ricmm: weird crash, doesn't happen all the time
[19:13] <plars> I can't see any reason for it, but it's looking pretty consistent and not happening on other devices
[19:13] <rsalveti> ricmm: so we're now thinking what could be causing that crash, and one suggestion was the gcc 4.7 x 4.8 issue we had
[19:14] <ricmm> I'd like to reproduce it
[19:14] <rsalveti> ricmm: flash 207 on mako
[19:14] <ricmm> you always chose the one without battery
[19:14]  * ricmm charges mako
[19:14] <rsalveti> ricmm: then run the unity8 autopilot test for a few times
[19:14] <rsalveti> wait for the crash
[19:14] <asac> balloons: feel through the crack it seems. if you dont hae it by end of week, please ping
[19:15] <ricmm> rsalveti: ok
[19:48] <rsalveti> ricmm: able to reproduce it already? :P
[19:50] <ricmm> rsalveti: really?
[19:50] <ricmm> you know I'm still downloading
[19:50] <rsalveti> lol
[19:50] <rsalveti> indeed
[19:50] <rsalveti> will ping you again in ~8h then
[19:50] <ricmm> ok
[19:51]  * ricmm hangs up the 14.4k
[19:51] <rsalveti> haha
[19:51] <rsalveti> ricmm: any other idea about what might be causing this weird behavior?
[19:52] <ricmm> not really
[19:52] <ricmm> do you have a good trace handy?
[19:52] <rsalveti> ricmm: no trace, crash in heap
[19:52] <ricmm> but where were the threads
[19:52] <ricmm> who accessed the heap
[19:52] <ricmm> etc
[19:53] <rsalveti> ricmm: just the crash file
[19:53] <ricmm> :(
[19:57] <rsalveti> rebuilt stuff with 4.8 and now location service is consuming all the cpu
[20:01] <ricmm> rsalveti: cute
[20:06] <ricmm> rsalveti: download gonna take like 20 min, so gonna walk the dog
[20:16] <tvoss> rsalveti, location service is built with gcc 4.7
[20:16] <rsalveti> ricmm: Saviq: rebuilt stuff with 4.8 (location-service, libdbus-cpp, platform-api, libhybris), and still got the crash
[20:17] <rsalveti> reverting system-compositor now
[20:25] <Saviq> rsalveti, :/
[20:27] <rsalveti> to revert system-compositor: http://people.canonical.com/~rsalveti/ubuntu-touch-session_0.103rsalveti1_all.deb
[20:39] <cyphermox> robru-is-dying: you asleep yet? ignore if true.
[20:39] <cyphermox> just making sure we don't lose a team player ;)
[20:42] <rsalveti> Saviq: can you also give it a try without system-compositor?
[20:43] <Saviq> rsalveti, sure, lemme
[20:43] <rsalveti> we can at least get a better stack trace I guess
[20:44] <Saviq> (maybe)
[20:59] <ricmm> rsalveti: flashing done :D
[21:00] <rsalveti> Saviq: ok, got a crash without system-compositor but in mir now
[21:00]  * rsalveti getting dbg symbols
[21:01] <ricmm> rsalveti: did you rebuild these things stripped?
[21:01] <rsalveti> ricmm: yes, doing normal package build
[21:02] <Saviq> rsalveti, /me too
[21:02] <ricmm> do some nostrip bros
[21:02] <rsalveti> didn't rebuild mir
[21:06] <ricmm> rsalveti: so just running the test suite is enough?
[21:06] <rsalveti> ricmm: autopilot
[21:06] <ricmm> yea unity8-autopilot
[21:07] <rsalveti> doesn't fail all the time
[21:07] <Saviq> huh interesting, apport-cli showed me more symbols than apport-retrace -g...
[21:08] <rsalveti> argh, core is truncated
[21:08] <rsalveti> Saviq: got a good st?
[21:09] <Saviq> rsalveti, ah, fuck no, this was ThreadStacktrace
[21:09] <Saviq> rsalveti, same two fooked frames
[21:12] <rsalveti> Saviq: also in heap?
[21:12] <Saviq> rsalveti, yes
[21:15] <rsalveti> Saviq: same here
[21:16] <rsalveti> need to script it in a way that we can control the process with gdb or similar
[21:18] <Saviq> rsalveti, I did have that
[21:18] <Saviq> rsalveti, stop unity8
[21:18] <rsalveti> so we can dig the threads
[21:18] <Saviq> rsalveti, while true; do gdb -ex run -ex continue unity8; done
[21:18] <ricmm> does this even happen outside of autopilot?
[21:18] <Saviq> ricmm, yes
[21:19] <Saviq> rsalveti, from outside you need to pkill unity8 if it didn't crash and continue/quit gdb so that it clears the socket
[21:19] <rsalveti> alright, so the problem is starting unity8 I guess
[21:19] <Saviq> rsalveti, unfortunately adding more -ex to gdb resulted in it going over the segv
[21:19] <robru-is-dying> cyphermox, i'm in and out of consciousness. if you need something right now i can help, otherwise i'll be back later
[21:19] <Saviq> so the continue / quit had to be manual
[21:20] <rsalveti> right, ok
[21:20] <ricmm> well but at least that means it crashes every now and then
[21:20] <ricmm> on a normal start
[21:21] <Saviq> ricmm, yes indeed
[21:21] <ricmm> you dont need to interact with it for a while for it to crash
[21:21] <Saviq> ricmm, no, not at all
[21:21] <Saviq> ricmm, once you can interact, it won't crash any more
[21:21] <Saviq> it crashes very early
[21:34] <ricmm> Saviq: how often can you make it crash?
[21:34] <ricmm> I must have started it 30 timesn ow and nothing
[21:35] <Saviq> ricmm, maybe more often than that
[21:35] <Saviq> ricmm, but not by much
[21:35] <Saviq> ricmm, I got it maybe once in 20 runs
[21:36] <ricmm> we should have a rule
[21:36] <ricmm> if its once in 20 runs, its not a bug
[21:37] <ricmm> Saviq: the crash is before the first frame? before or after the SIGILL, etc
[21:37] <ricmm> just to speed this kill/restart up
[21:37] <Saviq> ricmm, after the SIGILL
[21:37] <ricmm> how long do I need to wait after it to make sure it wont happen
[21:37] <Saviq> ricmm, seconds, once you can interact with the launcher / greeter, it's not gonna happen
[21:38] <ricmm> k
[21:38] <Saviq> ricmm, :
[21:38] <Saviq> while true; do gdb -ex run -ex continue unity8; done
[21:38] <ricmm> yea im doing that
[21:38] <Saviq> ok
[21:38] <ricmm> but to be fair I can interact with the launcher before the sigill
[21:38] <Saviq> ricmm, not for real you can't
[21:39] <Saviq> ricmm, once it settles
[21:39] <Saviq> like when it doesn't take it a second to follow your finger
[21:39] <ricmm> oh ok
[21:44] <ricmm> rsalveti: any luck?
[21:45] <rsalveti> ricmm: still no
[21:45] <ricmm> I really cant make it crash
[21:45] <ricmm> getting tired of trying
[21:45] <rsalveti> keep trying
[21:45] <rsalveti> you'll get it at some point
[21:45] <ricmm> did you get it with non-test unity8 already?
[21:46] <rsalveti> nops
[21:55] <Saviq> :/
[21:56] <ricmm> got it to crash
[21:56] <ricmm> indeed in the heap
[21:57] <rsalveti> ricmm: anything useful in any other thread?
[21:57] <ricmm> im looking through them
[22:00] <ricmm> god I hate these boost bts
[22:11] <rsalveti> sergiusens: so, we need the new qtmultimedia in for 5.2, what else do you needed to change at that package?
[22:11] <rsalveti> besides just making it compatible with 5.2?
[22:14] <sergiusens> rsalveti, not much I think
[22:14] <sergiusens> are we pushing for 5.2 now?
[22:14] <sergiusens> rsalveti, just got back
[22:14] <ChickenCutlass> sergiusens: yes
[22:14] <sergiusens> dogs tried to bite me when biking to destination :-P
[22:15] <sergiusens> ChickenCutlass, rsalveti want me to do that now?
[22:15] <rsalveti> sergiusens: hahah
[22:15] <rsalveti> sergiusens: please
[22:15] <sergiusens> sure thing; I'll push to a ppa I control and then ask Mirv to sync
[22:15] <sergiusens> so we are landing everything?
[22:16] <rsalveti> we want it because we're doing a call for testing
[22:16]  * sergiusens rootstocks with qt 5.2
[22:29] <rsalveti> this is a hard one to reproduce
[22:29] <ricmm> took me like 40 times
[22:29] <rsalveti> ricmm: any news?
[22:29] <ricmm> now I have a horrible backtrace that means nothing to me
[22:29] <ricmm> I dont see any reference to areas near that heap area
[22:31] <ricmm> rsalveti: http://paste.ubuntu.com/6996845/
[22:31] <ricmm> memory around the offending heap area too
[22:35] <rsalveti> right
[22:45] <rsalveti> ricmm: with flo: http://paste.ubuntu.com/6996904/
[22:52] <ricmm> always at mapping + 0x38F8
[22:52] <ricmm> the mapping is 384 kbytes large
[22:53] <ricmm> too large :D
[22:53] <ricmm> time for some watchpoints and hope that it crashes again
[23:15] <xnox> sergiusens: that is fixed in lp:~xnox/unity8/py32ap
[23:15] <xnox> sergiusens: also staged for the upload.....
[23:16] <xnox> sergiusens: ptr will start running python3 compatible tests, but we have circular depends between unity8, ubuntu-ui-toolkit and phablet-test-run.
[23:17] <xnox> sergiusens: which is: lp:~xnox/unity8/py32ap     lp:~xnox/ubuntu-ui-toolkit/py32ap     lp:~xnox/phablet-tools/py2-3
[23:17] <sergiusens> xnox, we should of added it to the same silo; but sadly that is blocked
[23:17] <sergiusens> fear we are in a deadlock
[23:18] <xnox> sergiusens: depending on how testing is executed, you will get bogus results.
[23:18] <xnox> sergiusens: i know a very nice silo, called trusty-proposed.
[23:18] <xnox> sergiusens: also, the other two should be in silos as well, and since they are ppas, just add them in your test environment and test all three together.
[23:19] <sergiusens> xnox, well I don't make the rules; if doanac` is ok with it; it's fine
[23:19] <xnox> sergiusens: or don't do silly things, like testing unity8 with a click setup.
[23:19] <sergiusens> lol
[23:19] <sergiusens> that too
[23:19] <xnox> sergiusens: you shouldn't use phablet-click-test-setup to run unity8 tests. you should wipe /home/phablet/autopilot.
[23:19] <sergiusens> xnox, agreed
[23:20] <xnox> sergiusens: i mean, it will work, once unity8 update lands, but until then, you should have a clear state and only do: phablet-test-run -p unity8-autopilot -v unity8
[23:20] <xnox> without click-setup left around on your pythonpath.
[23:21] <sergiusens> xnox, that really depends on how the ci stuff is setup
[23:21] <sergiusens> xnox, and I'm not against you ;-)
[23:22] <sergiusens> xnox, but I was recently reprimanded so I have my tail hidden :-)
[23:23] <xnox> haha =)
[23:23] <xnox> sergiusens: sounds silly ;-)
[23:23] <xnox> sergiusens: if CI is not clearing /home/phablet/autopilot when executing unity8 or ubuntu-ui-toolkit tests, then it's testing wrong test-cases....
[23:27] <xnox> fginther: is /home/phablet/autopilot cleared (or otherwise is empty) before using .deb based tests? e.g. unity8-autopilot?
[23:28] <fginther> xnox, yes, it starts with a freshly flashed image and then just installs the debs from the MP
[23:28] <sergiusens> fginther, even on the image tests?
[23:29] <xnox> fginther: cool, thanks.
[23:29] <fginther> sergiusens, smoke image testing doesn't install debs.
[23:29] <fginther> sergiusens, it does use the click setup thingy I think
[23:29] <sergiusens> fginther, not even for unity8?
[23:30] <xnox> hm, i think i lost URL to the current silo status page.
[23:30] <fginther> sergiusens, I'll need to double check, this has changed recently
[23:31] <xnox> anyone has URL to spreadsheets, describing silo states?
[23:31] <fginther> plars, are any  .debs installed during touch smoke tests?
[23:31] <plars> fginther: yes
[23:31] <fginther> plars, any for unity8?
[23:32] <plars> fginther: don't think so
[23:32] <plars> fginther: wait
[23:32] <plars> fginther: yes there is
[23:32] <plars> fginther: python-gi
[23:33] <sergiusens> plars, what about the autopilot modules?
[23:33] <plars> fginther: I remember that one now - when everything shifted over to getting the tests from branches where possible, that was still required
[23:33] <sergiusens> xnox, this? https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=24
[23:33] <plars> fginther: no, iirc those get pulled in with phablet-click-test-setup and we run from those
[23:33] <fginther> plars, ok, that was my next question
[23:34] <xnox> sergiusens: yes, thanks.
[23:34] <fginther> plars, I don't see anything in the code to specifically pull in unity8-autopilot
[23:34] <plars> fginther: I take that back, unity8-autopilot is installed
[23:34] <fginther> hah
[23:34] <sergiusens> plars, when you run the unity8 tests; is /home/phablet/autopilot removed?
[23:34] <plars> no
[23:35]  * doanac` just got back from walk, reading backscroll
[23:35] <fginther> sergiusens, looks like I was wrong
[23:36] <xnox> sergiusens: funny how many fixes i have pending in various landings.
[23:36] <doanac`> plars, sergiusens: i just got a full daily-image run with this latest phablet-tools: http://q-jenkins:8080/job/andy-smoke-daily-test/2/#showFailuresLink
[23:37] <doanac`> looks like unity8 was the main issue, but there might be some other failures.
[23:37] <plars> we can't clear /home/phablet/autopilot - isn't that where all the click-test-setup bits go?
[23:38] <plars> doanac`: that doesn't look too good
[23:38] <sergiusens> I would think the click tests are ran while the image is read only
[23:38] <xnox> plars: sure, but it's also your PWD, thus if you install and expect to test: /usr/lib/python2.7/dist-packages/unity8/tests/, you are infact testing /home/phablet/autopilot/unity8/tests (as that is pulled in to provide unity8 emulators)
[23:38] <sergiusens> and then you switch to readwrite and do whatever is required with read write
[23:38] <xnox> (in read only images)
[23:38] <doanac`> looks like music_app is now failing cause it needs mock: http://q-jenkins:8080/job/andy-smoke-daily-test/2/testReport/junit/unittest.loader.ModuleImportFailure.music_app/tests/test_music/ ?
[23:39] <plars> xnox: but I thought phablet-click-test-setup ensured that we get the same bzr revno that matches the package installed
[23:39] <xnox> plars: correct. unity8 is not a click package.
[23:40] <doanac`> sounds like phablet-click-test-setup shouldn't install it as such?
[23:40] <plars> xnox: it checks the version of unity8
[23:40] <plars> see fetch_test_base in phablet-click-test-setup
[23:40] <xnox> plars: look at the phablet-click-test-setup code, it looks at clicks and pulls their matching sources, and pulls matching version unity8 / ubuntu-ui-toolkit by version number.
[23:41] <plars> xnox: exactly
[23:41] <xnox> if after executed that, the device is not cleared, and unity8-autopilot.deb is installed (or has been previously been installed, to be under test), it will be ignored.
[23:41] <xnox> we've asked here, to see if that is the case (that a fresh read-only image is used) when tests of unity8-autopilot are initiated.
[23:42] <xnox> unity8-autopilot.deb that is.
[23:42] <sergiusens> plars, it only works when you never switch to read write
[23:43] <plars> what's the problem you are trying to sort out? I'm missing the context
[23:43] <plars> what only works when you never switch to read/write?
[23:43] <plars> aiui, we are stuck on read/write until no extra packages need to be installed
[23:43] <xnox> plars: of there is no problem, we just don't know how to navigate jenkins to find out the info we lack. Where is all types of unity8 test results?
[23:44] <xnox> (as in raw console log, not empty test_results.xml)
[23:44] <plars> ah
[23:45] <sergiusens> plars, exactly; the stuff installed with phablet-click-test-setup is only to get the emulators and such required by the readonly tests; but if used wth debs; hast the potential to break
[23:45] <sergiusens> xnox, I guess we can just force to run ui toolit and unity8 in py2 mode with an ugly hack
[23:45] <xnox> sergiusens: maybe phablet-test-run shouldn't pull in unity8/uuit, if they appear to be already available.
[23:46] <sergiusens> xnox, they have it because they are in read write
[23:46] <xnox> sergiusens: and/or otherwise execute them form a different path.
[23:46] <sergiusens> xnox, but general developers don't go to read write
[23:47] <sergiusens> xnox, and the emulators they provide are required for all tests
[23:47] <xnox> sergiusens: let me play around here a little bit.
[23:48] <xnox> sergiusens: how come the log you showed me, gives errors? clearly that is not using a clean environment.
[23:48] <sergiusens> xnox, that's doanac` 's log, not mine
[23:49] <doanac`> what do we mean "not clean"? the fact that its using unity8 from /home/phablet/autopilot/unity8?
[23:49] <xnox> doanac`: the fact that /home/phablet/autopilot is present, when executing unity8 test-cases, yes.
[23:50] <doanac`> xnox: its how we've been running this since day1.
[23:50] <xnox> doanac`: which is uncovered, due to not me uploading the whole lot, as quickly as possible, to minimise discruption all in one go.
[23:51] <xnox> doanac`: you didn't do: phablet-test-run -p unity8-autopilot -n unity8 ?
[23:51] <doanac`> xnox, no. we run phablet-click-test-setup, and then phablet-test-run unity8
[23:51] <doanac`> python-gi gets installed before we run also
[23:52] <xnox> doanac`: without going read-write?
[23:52] <sergiusens> doanac`, oh, without installing unity8-autopilot?
[23:52] <doanac`> correct - we don't install unity8-autopilot
[23:52] <sergiusens> doanac`, that's awesome if so
[23:52] <plars> doanac`: it does seem to be installed on at least this device I'm looking at
[23:52] <sergiusens> doanac`, so you have pure readonly testing
[23:52] <plars> I'm not sure why though
[23:52] <xnox> doanac`: that will continue to work, after unity8/py32 branch lands. Otherwise, there is temporary dependency.
[23:52] <plars> it's not specified in the pkgs for unity8
[23:52] <doanac`> sergiusens: no. we have a read-write image, just not installing unity8-autopilot
[23:53] <xnox> sergiusens: unity8 is in a silo, as far as I can tell, can we reconfigure them together?
[23:53] <doanac`> xnox, sergiusens: so to level set what I did to cause the failure:
[23:53] <plars> ok, I misspoke, I was looking on one of the devices in the lab that may not have been the last one running the tests after all
[23:53] <sergiusens> xnox, we can; if unity8 is unlocked
[23:53] <plars> I don't see where we *should* be installing unity8-autopilot
[23:53] <doanac`> i took our latest phablet-test-run and tried to make it work with today's image
[23:54] <xnox> plars: that's all good.
[23:54] <sergiusens> doanac`, it's that the new test setup splits out py3 and py2
[23:54] <doanac`> sergiusens: yes.
[23:54] <doanac`> plus my 2 MPs
[23:54] <sergiusens> doanac`, so unity8 is running as py3 because it's emulators land there; but it's not py3 ready
[23:55] <xnox> doanac`: and the merge proposal to get the rest of it py3 ready, is in-flight....
[23:55] <doanac`> sergiusens: that's fine by me. i thought you wanted me to run the tests just to get an idea if any thing crazy had broke
[23:55] <sergiusens> doanac`, and that's great
[23:56] <sergiusens> xnox, which silo is unity8 in?
[23:56] <doanac`> so i think everything is okay and working as expected, right?
[23:56] <xnox> sergiusens: now, i'm not sure. help me read: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=0 line 33, tab pending.
[23:56] <sergiusens> doanac`, sort of; can't land this withtout landing the unity8 changes
[23:57] <xnox> sergiusens: let me send an email, about branch configurations.
[23:58] <sergiusens> xnox, it's row 33, but it's unsiloed
[23:58] <xnox> sergiusens: yeap, gotcha.