| racarr | !! I think I fixed it | 00:08 |
|---|---|---|
| ubot5 | racarr: I am only a bot, please don't think I'm intelligent :) | 00:08 |
| racarr | :( fine | 00:09 |
| racarr | I think maybe I got it | 00:36 |
| racarr | but I may just be mis understanding...actually | 00:37 |
| racarr | tried build dependency as g++-4.9:native | 00:37 |
| racarr | hmm colinwatson suggests against using g++-4.9:native but doesnt say why in the reference I found | 00:42 |
| 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:47 |
| 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:53 |
| 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] | 00:54 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| duflu | RAOF: Can you comment on correct procedure for updating symbols.map here? https://code.launchpad.net/~vanvugt/mir/mircommon2/+merge/233310 | 03:44 |
| RAOF | duflu: Done | 04:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| duflu | RAOF: Oh of course. Because there won't be users of the old version (already enforced by SONAME in dynamic loading) | 06:15 |
| 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:16 |
| 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:17 |
| RAOF | Oh, for the immediate and mid-term future our versioning is just going to be ‘bump the SOVER, change the version’. | 06:18 |
| 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:19 |
| 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:20 |
| 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:24 |
| duflu | And the new functionality added during SONAME-1 was already linked as symbol version SONAME | 06:25 |
| RAOF | Ah, but how do you distinguish between two different additions *before* the new SONAME? | 06:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| RAOF | But that's a swamp we can drain when we get to it :) | 06:30 |
| 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:49 |
| RAOF | To the rebuild button! | 06:59 |
| duflu | Yes please | 07:00 |
| RAOF | A symbol versioning guide? | 07:03 |
| duflu | RAOF: Just docs with sections titled "I have added new functionality" and "I have changed or removed existing functionality" | 07:07 |
| 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:08 |
| RAOF | I've pressed rebuild on everything of mine that should build. | 07:09 |
| RAOF | Including that one :) | 07:09 |
| duflu | RAOF: OK then. Bon weekend | 07:10 |
| duflu | anpok: Got a shiny new mesa coming to utopic soon? | 08:17 |
| 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:18 |
| anpok | there were some llvm related issues.. and lately ppc build issues to resolve | 08:19 |
| anpok | duflu: do you have a i915 system? | 09:22 |
| duflu | anpok: Yes, but they're way out of date. Needs reinstalling. | 09:22 |
| anpok | are those 945 and similar gpus still included in current intel processors? | 09:23 |
| 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:24 |
| duflu | (e.g. original Netbooks) | 09:25 |
| anpok | so also current atoms are now also served through i965? | 09:25 |
| duflu | anpok: I think so(?) | 09:26 |
| 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:27 |
| duflu | Otherwise they gather dust | 09:28 |
| duflu | I usually do hardware support experiments on weekends, but not very often. Not for a long time now | 09:29 |
| anpok | yeah just i need to test the unity8-dash test with a non hacked mesa - hopefully the last iteration now | 09:33 |
| anpok | s/test/change | 09:34 |
| duflu | anpok: So after I do reinstall a machine or two you want me to also install nonstandard Mesa? :) | 09:43 |
| === mpt_ is now known as mpt | ||
| 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:24 |
| kgunn | robotfuel: sorry, i got lost in bug world y'day....didn't mean to ignore you | 14:28 |
| kgunn | robotfuel: sorry, i got lost in bug world y'day....didn't mean to ignore you | 14:29 |
| robotfuel | kgunn: heh that's okay I can always bug you again ;) | 14:30 |
| 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:33 |
| 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:34 |
| kgunn | robotfuel: any hints on when/what exactly makes it happen ? | 14:39 |
| robotfuel | kgunn: no I connected a camera to try to catch the crash, but it hasn't happened again today. | 14:41 |
| 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:43 |
| 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 | 14:44 |
| === om26er_ is now known as om26er|dinner | ||
| kgunn | robotfuel: think we can dedup 1271879....and close out 1365673 ? | 15:26 |
| robotfuel | kgunn: if that works better for you sure | 15:27 |
| kgunn | yes please | 15:27 |
| robotfuel | kgunn: I've added the crash files to 1365673 | 15:32 |
| kgunn | tahnks | 15:32 |
| === chihchun is now known as chihchun_afk | ||
| === om26er|dinner is now known as om26er | ||
| 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:29 |
| 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:30 |
| 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:31 |
| kdub | AlbertA,^ | 16:36 |
| kdub | I don't know of a reason | 16:37 |
| 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:39 |
| 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:40 |
| racarr | and then will submit those, then send some emails about cross compiling | 16:41 |
| AlbertA | kdub: Tassadar: yeah no particular reason | 16:46 |
| 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:47 |
| Tassadar | what about "compositor->start();", does it matter if it is after or before display->configure()? | 16:48 |
| 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:49 |
| racarr | Shouldn't USC also have an explicit g++-4.9 dependency? | 16:51 |
| racarr | (went to apply my hack and failed) | 16:51 |
| AlbertA | Tassadar: for a quick test you can use these scripts | 16:52 |
| 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:54 |
| Tassadar | thanks | 16:55 |
| racarr | https://code.launchpad.net/~mir-team/unity-system-compositor/explicit-g++-dependency/+merge/233564 | 16:57 |
| racarr | hmm having trouble getting sbuild top use my local apt repository for deps | 17:17 |
| kdub | racarr, i'm having sbuild problems too | 17:48 |
| kdub | although, mine might just be bad setup | 17:48 |
| 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:49 |
| 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:50 |
| racarr | debian upstream is working on some tooling changes to fix it as late as...last week I found | 17:51 |
| racarr | aha... | 17:51 |
| 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:52 |
| 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:53 |
| racarr | lol | 17:54 |
| racarr | ok so the short story is | 17:55 |
| racarr | mk-sbuild --target armhf utopic | 17:55 |
| 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:56 |
| 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:57 |
| racarr | DEB_BUILD_OPTIONS=nocheck sbuild --build amd64 --host armhf -d utopic <PATH-TO-DSC-FILE> | 17:58 |
| 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 | 17:59 |
| racarr | wait really. | 18:00 |
| racarr | I know pbuilder can use qemu but I thought sbuild was using a real cross chain | 18:00 |
| 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:01 |
| 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:04 |
| Tassadar | kdub: AlbertA https://code.launchpad.net/~vbocek/unity-system-compositor/fix-hammerhead-backlight/+merge/233572 | 18:17 |
| Tassadar | tested in on hammerhead and it works there, I hope it won't break anything else | 18:18 |
| 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:21 |
| kdub | Tassadar, cool, thanks | 18:26 |
| Tassadar | that issue took way to long to track down) | 18:26 |
| racarr | Back in a few, off to doctor | 18:40 |
| 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:41 |
| racarr | and maybe we will finally have a nice workflow for it :D | 18:42 |
| racarr | DOCTTOOOOOR TIME | 18:42 |
| 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:00 |
| fginther | this contains the modifications for the adb user changes | 19:01 |
| fginther | The results look similar to the last job which passed. | 19:01 |
| 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:02 |
| camako | kdub, no that's the only one because I think it uses some weird qml build files | 19:03 |
| kdub | camako, hmm, okay | 19:05 |
| 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:06 |
| 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:07 |
| 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:15 |
| camako | I mean the 'unmet dep' | 19:16 |
| kdub | well, thats encouraging | 19:17 |
| kdub | camako, did you run into what I was seeing? | 19:21 |
| camako | kdub, no | 19:21 |
| kdub | okay, will keep poking at it | 19:21 |
| racarr | Back | 21:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!