[00:08] <racarr> !! I think I fixed it
[00:08] <ubot5> racarr: I am only a bot, please don't think I'm intelligent :)
[00:09] <racarr> :( fine
[00:36] <racarr> I think maybe I got it
[00:37] <racarr> but I may just be mis understanding...actually
[00:37] <racarr> tried build dependency as g++-4.9:native
[00:42] <racarr> hmm colinwatson suggests against using g++-4.9:native but doesnt say why in the reference I found
[00:47] <racarr> hahahahahaha
[00:47] <racarr> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760158
[00:47] <ubot5> Debian bug 760158 in dpkg "dpkg: please implement the new build profiles syntax" [Wishlist,Open]
[00:47] <racarr> no wonder build profiles aren't working
[00:47] <racarr> the patch was posted 4 days ago
[00:53] <racarr> lol ok it seems there really is no fix here but debian is on top of it. I'm going to make a script to modify debian/control to depend on g++-4.9-arm-linux-gnueabihf  instead of g++-4.9, build a source package, restore debian control
[00:53] <racarr> and call it "create-cross-compile-source" or some such...maybe useful enough to check in ill think about it
[00:53] <racarr> if nothing up will write an email with findings
[00:54] <racarr>  / comment on https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1353855
[00:54] <ubot5> Ubuntu bug 1353855 in unity8 (Ubuntu) "Explicit g++ 4.9 dependency breaks cross-building" [Undecided,Confirmed]
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[03:44] <duflu> RAOF: Can you comment on correct procedure for updating symbols.map here? https://code.launchpad.net/~vanvugt/mir/mircommon2/+merge/233310
[04:09] <RAOF> duflu: Done
[06:10] <duflu> RAOF: So if only adding new symbols then add a new block for SONAME+1 but don't bump SONAME?
[06:10] <duflu> Sounds futuristic
[06:11] <RAOF> New block for new version; SONAMEs reset the blocks ;)
[06:11] <duflu> RAOF: OK so what's the block named in the case of no new SONAME?
[06:12] <RAOF> The new Mir version would be an obvious candidate.
[06:12] <RAOF> But it actually doesn't matter at all as long as the string is unique across all versions.
[06:12] <duflu> RAOF: Hmm kinda makes sense but we presently use SONAMEs (kinda) in the symbols.map
[06:13] <RAOF> Right. Because when I first proposed it I used the Mir version and everyone was all “that'll be confusing” :P
[06:13] <duflu> All options are confusing in their own little way
[06:14] <RAOF> We could actually just use the output of uuidgen. It would be equivalent :)(
[06:14] <duflu> RAOF: OK, so for the simple case (and common case) where we've broken the ABI anyway, just continue bumping the SONAME in the symbols.map?
[06:14] <duflu> I say "continue" should be "start"
[06:14] <RAOF> Yes.
[06:15] <duflu> RAOF: Oh of course. Because there won't be users of the old version (already enforced by SONAME in dynamic loading)
[06:16] <RAOF> Well, there actually might be - in the case that something links against libmirfoo.so.X and additionally links against libbaz which links against libmirfoo.so.X-1.
[06:17] <RAOF> Which fails appalingly in the absence of symbol versioning, but can work with appropriate versioning (in this case, meaning things in mirfoo.so.X need different versions to mirfoo.so.X-1, which is satisfied by “bump the version to the new SOVER”).
[06:17] <RAOF> Of course, with our magical protobuf singleton that fails _anyway_, but it's a really useful property to have if we can fix the protobufing.
[06:17] <duflu> RAOF: I'm not convinced we're disciplined enough for symbol versioning to work out properly, but will continue supporting the effort :)
[06:18] <RAOF> Oh, for the immediate and mid-term future our versioning is just going to be ‘bump the SOVER, change the version’.
[06:19] <RAOF> But even that is useful, because when we _do_ get into a position to be more stable than that we can take advantage of “load multiple different SOVERs in the same process”, which you can only get if everything's always been versioned.
[06:20] <duflu> RAOF: So SONAME bump means bump symbols.map. But symbols.map should be bumpable more often than SONAME?
[06:20] <RAOF> Correct.
[06:20] <RAOF> Anytime you add something to symbols.map it should technically go in a new version section.
[06:24] <duflu> RAOF: Might be a good idea for new functions to just go in SONAME+1. Then assuming they don't change, that will remain true when we do finally break the ABI
[06:24] <RAOF> Oh, when we break the ABI then everything coalesces into a single new version.
[06:24] <duflu> RAOF: Exactly
[06:25] <duflu> And the new functionality added during SONAME-1 was already linked as symbol version SONAME
[06:26] <RAOF> Ah, but how do you distinguish between two different additions *before* the new SONAME?
[06:27] <duflu> RAOF: Crap
[06:27] <RAOF> eg: We release 0.7. In 0.8 we add some symbols, adding them to a new version bit. In 0.9 we add some more new symbols. Where do they go?
[06:28] <RAOF> Then in 0.10 we break ABI and everything gets folded into a single new version stanza, and that's ok.
[06:28] <duflu> RAOF: Ah, but if you break a new addition then by your own rules you would bump and coalesce everything anyway
[06:28] <duflu> Kind of
[06:28] <duflu> It wasn't part of SONAME-1 really
[06:28] <RAOF> duflu: Right, but what if you add things in too successive releases without breaking.
[06:29] <RAOF> I know this is largely theoretical, as it's predicated on us making two whole releases without breaking ABI, but longer term that won't be a joke :)
[06:29] <duflu> Versions then
[06:29] <RAOF> Of course, we at Canonical don't believe in versions and just continuously release from trunk :P
[06:30] <RAOF> But that's a swamp we can drain when we get to it :)
[06:49] <duflu> RAOF: Found somewhere we need to decide on the syntax of naming new blocks: https://code.launchpad.net/~kdub/mir/protobuf-exchange-buffer/+merge/232728
[06:59] <RAOF> To the rebuild button!
[07:00] <duflu> Yes please
[07:03] <RAOF> A symbol versioning guide?
[07:07] <duflu> RAOF: Just docs with sections titled "I have added new functionality" and "I have changed or removed existing functionality"
[07:08] <duflu> RAOF: I meant yes to the rebuild. It will help land things faster
[07:08] <duflu> https://code.launchpad.net/~raof/mir/remove-old-clang-workaround/+merge/233448
[07:09] <RAOF> I've pressed rebuild on everything of mine that should build.
[07:09] <RAOF> Including that one :)
[07:10] <duflu> RAOF: OK then. Bon weekend
[08:17] <duflu> anpok: Got a shiny new mesa coming to utopic soon?
[08:18] <anpok> i think a 10.3 based version is close to be released
[08:18] <anpok> I will have to talk marteen to include my patches. only one of them have been reviewed yet
[08:19] <anpok> there were some llvm related issues.. and lately ppc build issues to resolve
[09:22] <anpok> duflu: do you have a i915 system?
[09:22] <duflu> anpok: Yes, but they're way out of date. Needs reinstalling.
[09:23] <anpok> are those 945 and similar gpus still included in current intel processors?
[09:24] <duflu> anpok: No, a few years old
[09:24] <duflu> anpok: A few years old but still required to be supported by Ubuntu of course
[09:25] <duflu> (e.g. original Netbooks)
[09:25] <anpok> so also current atoms are now also served through i965?
[09:26] <duflu> anpok: I think so(?)
[09:27] <duflu> anpok: If you remind me, I'll have my i945 machines updated by next week
[09:27] <anpok> i have a intel atom netbook.. now trying an optimized build
[09:28] <duflu> Otherwise they gather dust
[09:29] <duflu> I usually do hardware support experiments on weekends, but not very often. Not for a long time now
[09:33] <anpok> yeah just i need to test the unity8-dash test with a non hacked mesa - hopefully the last iteration now
[09:34] <anpok> s/test/change
[09:43] <duflu> anpok: So after I do reinstall a machine or two you want me to also install nonstandard Mesa? :)
=== mpt_ is now known as mpt
[14:24] <robotfuel> kgunn:  do you know who the right person to assign this crasher to? https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1271879 we had more crashes for this yesterday on errors.ubuntu.com  from the long running tests.
[14:24] <ubot5> Ubuntu bug 1271879 in qtubuntu (Ubuntu) "qmlscene crashed with SIGABRT in qt_message_fatal()" [Undecided,Confirmed]
[14:28] <kgunn> robotfuel: sorry, i got lost in bug world y'day....didn't mean to ignore you
[14:29] <kgunn> robotfuel: sorry, i got lost in bug world y'day....didn't mean to ignore you
[14:30] <robotfuel> kgunn: heh that's okay I can always bug you again ;)
[14:33] <kgunn> robotfuel: so that's ancient ?
[14:33] <kgunn> is that right ?
[14:33] <kgunn> ...so the signature is the same ?
[14:33] <robotfuel> yes it is still crashing in yesterdays image
[14:34] <robotfuel> kgunn: https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1365673 has the latest errors.u.c link
[14:34] <ubot5> Ubuntu bug 1271879 in qtubuntu (Ubuntu) "duplicate for #1365673 qmlscene crashed with SIGABRT in qt_message_fatal()" [Undecided,Confirmed]
[14:39] <kgunn> robotfuel: any hints on when/what exactly makes it happen ?
[14:41] <robotfuel> kgunn: no I connected a camera to try to catch the crash, but it hasn't happened again today.
[14:43] <kgunn> robotfuel: so spoke to some guys....sounds like the original fix is still in place (e.g. unity-mir replaced by qtmir..but the change is there)
[14:43] <kgunn> they said that the unity8 log would be really helpful
[14:44] <kgunn> can you grab that if it happens ??
[14:44] <kgunn> robotfuel: ^
[14:44] <robotfuel> kgunn: I have the unity8 log, I just need to dig it out of jenkins
[14:44] <kgunn> sweet, thanks, just attach to the bug
=== om26er_ is now known as om26er|dinner
[15:26] <kgunn> robotfuel: think we can dedup 1271879....and close out 1365673 ?
[15:27] <robotfuel> kgunn: if that works better for you sure
[15:27] <kgunn> yes please
[15:32] <robotfuel> kgunn: I've added the crash files to 1365673
[15:32] <kgunn> tahnks
=== chihchun is now known as chihchun_afk
=== om26er|dinner is now known as om26er
[16:29] <Tassadar> Hi, I have a problem with some code in unity-system-compositor, namely the part which takes care of screen power off/on during suspend/resume after pressing the power button - http://bazaar.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk/view/head:/src/screen_state_handler.cpp#L162
[16:30] <Tassadar> the sequence of operations is "turn the screen of with blank call (under display->configure())" and _then_ set brightness to 0
[16:30] <Tassadar> android does it the other way around - it sets the brightness first
[16:31] <Tassadar> that's the reason why backlight on nexus 5 stays on all the time, the kernel driver refuses to set the brightness after the panel is powered down
[16:31] <Tassadar> is there anybody who knows if there's a specific reason why the screen panel is turned off before the brightness is set, or would it be okay to change the order to the one Android has?
[16:36] <kdub> AlbertA,^
[16:37] <kdub> I don't know of a reason
[16:39] <Tassadar> I'd try out if it works when I change the order, but setting up the build would probably take ages
[16:39] <racarr> Oh! I never said good morning hi everyone
[16:40] <racarr> sorry I slept through standup:). Standup:
[16:40] <racarr> Distracted from USC touchspot configuration by perfecting cross compile work flow
[16:40] <racarr> I think i've made a lot of progress though and will be writing up something good soon...
[16:40] <racarr> actually right now im using my new cross compile set up to test my USC changes
[16:41] <racarr> and then will submit those, then send some emails about cross compiling
[16:46] <AlbertA> kdub: Tassadar: yeah no particular reason
[16:47] <Tassadar> okay, so can I submit a merge request which changes the order?
[16:47] <AlbertA> Tassadar: yeah go ahead
[16:47] <Tassadar> hm, actually, I'd really like to test it out frist
[16:48] <Tassadar> what about "compositor->start();", does it matter if it is after or before display->configure()?
[16:49] <AlbertA> that one has to be after configure
[16:49] <Tassadar> okay
[16:49] <Tassadar> I'll try to build that package so I can see if it works or not and then submit the merge request
[16:51] <racarr> Shouldn't USC also have an explicit g++-4.9 dependency?
[16:51] <racarr> (went to apply my hack and failed)
[16:52] <AlbertA> Tassadar: for a quick test you can use these scripts
[16:54] <AlbertA> https://github.com/albaguirre/unity-dev-scripts
[16:54] <AlbertA> and do ./cross-compile.sh <usc directory>
[16:54] <AlbertA> and ./adb-push.sh usc
[16:55] <Tassadar> thanks
[16:57] <racarr> https://code.launchpad.net/~mir-team/unity-system-compositor/explicit-g++-dependency/+merge/233564
[17:17] <racarr> hmm having trouble getting sbuild top use my local apt repository for deps
[17:48] <kdub> racarr, i'm having sbuild problems too
[17:48] <kdub> although, mine might just be bad setup
[17:49] <racarr> kdub: There are a few problems along the way...it doesn't really work at the moment
[17:49] <racarr> I've got Mir to cross-build with a few hacks though just sturggling now to crossbuild USC against those packages
[17:49] <racarr> where is it giving up for you?
[17:50] <kdub> i'm still a few steps back
[17:50] <racarr> if its the g++-4.9 dependency, you just have to remove it, change it to g++-4.9:native, change it to g++-4.9-arm-blablabla, etc.
[17:50] <racarr> there's no actual fix atm...
[17:51] <racarr> debian upstream is working on some tooling changes to fix it as late as...last week I found
[17:51] <racarr> aha...
[17:52] <kdub> hmm, i'll probably run into that
[17:52] <kdub> every time i try sbuild its like spinning my wheels trying to find the magic key to get things going :/
[17:53] <racarr> aha :(
[17:53] <racarr> kdub: Do you know about https://wiki.ubuntu.com/SimpleSbuild
[17:53] <racarr> this has been the best set of directions for me
[17:53] <kdub> i'll try it out
[17:53] <kdub> 'simple sbuild' would be
[17:53] <kdub> ./go.sh
[17:53] <kdub> :D
[17:54] <racarr> lol
[17:55] <racarr> ok so the short story is
[17:55] <racarr> mk-sbuild --target armhf utopic
[17:56] <racarr> then, prepare the mir source (replace g++-4.9 in debian/control with g++-4.9:native)
[17:56] <racarr> build a source package
[17:56] <racarr> bzr bd -S --native -- -uc -us
[17:56] <racarr> -S for build source package, --native for build from working tree rather than try and download the upstream tarball
[17:57] <racarr>  -uc and -us are options for debbuild to skip signing
[17:57] <racarr> so you dont have to mess around with bumping the changelog
[17:57] <racarr> then you will have the .dsc in the directory one up
[17:57] <racarr> which you should now be able to build
[17:58] <racarr> DEB_BUILD_OPTIONS=nocheck sbuild --build amd64 --host armhf -d utopic <PATH-TO-DSC-FILE>
[17:59] <racarr> It's still going to be really slow though
[17:59] <racarr> big optimizations: pre-populated chroot (discussed on simplesbuild, prepopulate with buidl deps)
[17:59] <kdub> even at that though, still slow because its running through qemu
[18:00] <racarr> wait really.
[18:00] <racarr> I know pbuilder can use qemu but I thought sbuild was using a real cross chain
[18:01] <kdub> eh, i might be wrong, but I saw it fetching the qemu emulator
[18:01] <racarr> maybe it can use qemu!
[18:01] <racarr> I am pretty sure if you use --build amd64 and --host armhf
[18:01] <racarr> it should be a real cross chain though, the build I have running right now is using
[18:04] <racarr> well, I see cc1plus in my top outside of the chroot so.
[18:04] <racarr> its so confusing the "armhf" is called the "host" though
[18:04] <racarr> anyway with prepopulated chroots, and ccache
[18:04] <racarr> its actually quite fast...
[18:17] <Tassadar> kdub: AlbertA https://code.launchpad.net/~vbocek/unity-system-compositor/fix-hammerhead-backlight/+merge/233572
[18:18] <Tassadar> tested in on hammerhead and it works there, I hope it won't break anything else
[18:21] <kdub> racarr, okay, you're right, seems to be using the cross compiler
[18:21] <kdub> had to use that gcc 4.9:native thing
[18:26] <kdub> Tassadar, cool, thanks
[18:26] <Tassadar> that issue took way to long to track down)
[18:40] <racarr> Back in a few, off to doctor
[18:41] <racarr> kdub: :D Cool, hope you can get it working
[18:41] <racarr> my EOD task for today is I hope to write up
[18:41] <racarr> everything ive gathered, + the set of working instructions for the various
[18:41] <racarr> optimizations, etc
[18:41] <kdub> yeah, its going better than my previous attempts
[18:41] <racarr> and post it to warthogs/phone list or something in which case
[18:41] <racarr> someone who actually understands the tools will fill in the gaps
[18:42] <racarr> and maybe we will finally have a nice workflow for it :D
[18:42] <racarr> DOCTTOOOOOR TIME
[19:00] <fginther> kgunn, camako, can either of you recommend someone to look at the new jenkins mir-mediumtests results? https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/2671/console
[19:01] <fginther> this contains the modifications for the adb user changes
[19:01] <fginther> The results look similar to the last job which passed.
[19:02] <camako> fginther, RAOF is your guy... I'll ask him to look over..
[19:02] <kdub> camako, have you gotten qtmir to build under sbuild?
[19:03] <camako> kdub, no that's the only one because I think it uses some weird qml build files
[19:05] <kdub> camako, hmm, okay
[19:06] <camako> kdub, looking at the build logs... I guess I got over the qml build failures then I got this :
[19:06] <camako> The following packages have unmet dependencies:
[19:06] <camako>  sbuild-build-depends-qtmir-dummy : Depends: libubuntu-application-api-dev (>= 2.1.0) but it is not going to be installe
[19:06] <camako> d
[19:06] <camako> E: Unable to correct problems, you have held broken packages.
[19:07] <camako> kdub, is this what you're seeing?
[19:07] <kdub> i'm seeing
[19:07] <kdub> qmake: could not find a Qt installation of ''
[19:07] <kdub> and then qmake failes
[19:07] <camako> kdub, let me check earlier build files
[19:15] <camako> kdub, I take that back.. I did successfully built qtmir by itself.. What was failing for me is when I built qtmir with Mir packages coming from a local repo (also built with sbuild)
[19:15] <camako> I got that conflict and I haven't had a chance to investigate it yet
[19:16] <camako> I mean the 'unmet dep'
[19:17] <kdub> well, thats encouraging
[19:21] <kdub> camako, did you run into what I was seeing?
[19:21] <camako> kdub, no
[19:21] <kdub> okay, will keep poking at it
[21:05] <racarr> Back