| RAOF | To the espresso machine repairer! | 00:21 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| duflu | Oh, looky. utopic gets 0.6! https://launchpad.net/ubuntu/+source/mir | 01:44 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| duflu | alf_: Around? | 06:10 |
| alf_ | duflu: yes | 06:30 |
| duflu | alf_: Since 0.6.0 got released today we're getting bug reports of https://bugs.launchpad.net/mir/+bug/1348515 | 06:35 |
| ubot5 | Ubuntu bug 1348515 in Mir "libmircommon-dev 0.6.0+14.10.20140811-0ubuntu1 fails to install/upgrade, does not replace mircommon-dev 0.5.1+14.10.20140728-0ubuntu1" [High,In progress] | 06:35 |
| duflu | Do you want to revive the fix? | 06:35 |
| RAOF | Urgh :( | 06:36 |
| duflu | Should only affect developers. Unfortunately due to other bugs even non-developers will be -dev packages already | 06:37 |
| duflu | will *have* | 06:37 |
| alf_ | duflu: RAOF: So, I am not sure what the right fix is. Probably change < 0.5.1+14.10.20140722-0ubuntu1 to << 0.6~ ? | 06:40 |
| duflu | alf_: Surely "<< 0.6" ? | 06:41 |
| RAOF | 0.6~ would be right(erish) | 06:41 |
| duflu | Righterish then | 06:41 |
| alf_ | duflu: RAOF: ok, let me propose that then | 06:42 |
| alf_ | duflu: @cross-compile with 4.9, I have to change the cross compilation cmake file to explictly use 4.9. Does the current plain '...-g++' work for you? | 06:44 |
| duflu | alf_: It does now. Today's updates insisted on replacing the 4.8 one with 4.9 | 06:45 |
| alf_ | duflu: ok, thanks | 06:45 |
| duflu | Come to think of it I had experimented with 4.9 x-compiles a while back and forgot about it | 06:46 |
| duflu | alf_: I didn't mean to ask you to fix the bug. Only that you already had a fix in progress :) | 06:54 |
| duflu | And in 24 hours we may well have a lot more duplicates coming in from utopic users | 06:55 |
| duflu | (un)fortunately not a large proportion of users are set with with LP accounts to report bugs | 06:55 |
| alf_ | duflu: no worries, it's a trivial fix (assuming it works). Come to think of it again, perhaps you are right, the tilde in (<< 0.6~) doesn't make much sense (doesn't hurt either) | 06:56 |
| alf_ | RAOF: ^^ ? | 06:56 |
| RAOF | alf_: Doesn't matter much either way :) | 06:57 |
| alf_ | well, unless someone releases 0.6~ver, but then again someone may release 0.6~~ :) | 06:58 |
| duflu | Debian version sorting looks complicated :P | 07:00 |
| RAOF | Bah, ok, then. I'll write a double-buttocked stub platform. | 07:02 |
| alf_ | RAOF: duflu: https://code.launchpad.net/~afrantzis/mir/fix-mircommon-debian-replaces/+merge/230583 | 07:05 |
| duflu | alf_: Ta | 07:06 |
| seb128 | is https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1354564 an issue somebody is looking at? | 08:26 |
| ubot5 | Ubuntu bug 1354564 in unity8 (Ubuntu) "Keyboard no longer works in Unity8 desktop session" [Undecided,Incomplete] | 08:26 |
| seb128 | real keyboard not working on unity8-mir-desktop sessions | 08:26 |
| duflu | seb128: Sorry, I didn't notice that one. I'll make sure we don't lose track of it | 08:47 |
| seb128 | duflu, thanks | 08:48 |
| ogra_ | hmm, there seems to be a new hard dependency on freedreno in Mir ... the 0.6.0 release pulled that inot the touch images which makes the tarball grow by 4MB ... is this hard dep actually nercessary ? | 08:59 |
| ogra_ | (we are very short on space in touch and will never use freedreno there) | 09:00 |
| duflu | ogra_: That's probably not from Mir directly, but something else Mir uses. See Mir doesn't mention it: http://bazaar.launchpad.net/~mir-team/mir/0.6/view/head:/debian/control | 09:09 |
| duflu | ogra_: Try removing "freedreno" and see what packages complain? | 09:14 |
| ogra_ | http://paste.ubuntu.com/8034516/ | 09:15 |
| ogra_ | seems libdrm ... via mesa :/ | 09:15 |
| ogra_ | s/via/and/ | 09:16 |
| alf_ | ogra_: the question is: why are we pulling in mesa and libdrm on the phone in the first place? | 09:17 |
| ogra_ | alf_, some deps i think ... | 09:18 |
| anpok | shlib deps? | 09:19 |
| anpok | on mirserver .. | 09:19 |
| anpok | nm, looked at the x86 build.. | 09:20 |
| alf_ | ogra_: some mir packages depend on libegl1-mesa (>= 7.8.1) | libegl1-x11 and libgles2-mesa (>= 7.8.1) | libgles2 , perhaps we could change these so they are satisfied by what touch provides with the android drivers? | 09:22 |
| ogra_ | alf_, yeah that would be good i guess ... if we can drop mesa we definitely should | 09:23 |
| alf_ | ogra_: hmm, the libhybris packages doesn't provide libgles2 nor libegl1(-android) or similar, not sure what the policy for libegl packages is | 09:29 |
| ogra_ | lets wait for rsalveti i guess :) | 09:29 |
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| === chihchun is now known as chihchun_afk | ||
| === dandrader_ is now known as dandrader | ||
| === pete-woods is now known as pete-woods|away | ||
| === dandrader is now known as dandrader|lunch | ||
| racarr | Morning | 16:13 |
| Saviq | incomiiiing! | 16:24 |
| mterry | :) | 16:24 |
| mterry | Hey folks! | 16:24 |
| mterry | I need help with a promotion-blocking bug | 16:25 |
| mterry | I'm seeing behavior where /run/user/32011/mir_socket_trusted is created, but the normal mir_socket file in that directory is *not* | 16:25 |
| mterry | Any guesses on what code path would cause that? | 16:25 |
| dednick | alan_g: ^ | 16:26 |
| kdub | mterry, is the MIR_SERVER_FILE set? or did it go to /tmp/ somehow? | 16:27 |
| kdub | also, the default is based on XDG_RUNTIME_DIR | 16:27 |
| mterry | kdub, let me double confirm env | 16:27 |
| dednick | mterry: check for tmp/mir_socket | 16:28 |
| mterry | MIR_SERVER_FILE=/run/user/32011/mir_socket and XDG_RUNTIME_DIR=/run/user/32011 for unity8, which should be creating these | 16:28 |
| mterry | dednick, no such file | 16:28 |
| dednick | although i don't know why the trusted one would be at a different location | 16:28 |
| mterry | /run/mir_socket exists, but that's for USC | 16:29 |
| mterry | kdub, ^ see above about the environ | 16:29 |
| dednick | mterry: what about MIR_SOCKET ? | 16:30 |
| kdub | the trusted file can be changed via MIR_SERVER_PROMPT_FILE | 16:30 |
| kdub | mterry, its somewhat strange that MIR_SERVER_FILE is set in the environment | 16:31 |
| mterry | MIR_SOCKET=/run/user/32011/mir_socket but MIR_SERVER_HOST_SOCKET=/run/mir_socket | 16:31 |
| mterry | kdub, ^ | 16:31 |
| mterry | kdub, the unity8 upstart job sets that | 16:31 |
| kdub | mir won't parse MIR_SOCKET, iirc | 16:31 |
| dednick | mterry: is MIR_SOCKET set outside of the unity8 env? | 16:31 |
| kdub | oh, I take that back | 16:32 |
| mterry | dednick, I think lightdm does | 16:32 |
| dednick | kdub: it's something in u8 upstart | 16:32 |
| kdub | it does parse MIR_SOCKET | 16:32 |
| mterry | dednick, does set it rather | 16:32 |
| mterry | kdub, MIR_SOCKET is set to the same as SERVER_FILE. But when unity8 started, it was set to /run/mir_socket | 16:33 |
| mterry | kdub, which is normal Mir operation, as I recall (to re-set the var for the sake of any subprocesses) | 16:33 |
| kdub | and no failures? sounds like something's not set or not parsed as expected | 16:36 |
| kdub | like, forgive me if you know all this but | 16:38 |
| mterry | kdub, I don't see a message in unity8 log | 16:38 |
| kdub | MIR_SERVER_FILE will set the server's socket file for clients to that server | 16:38 |
| kdub | MIR_SERVER_HOST_SOCKET will set the socket for a nested mir to connect to | 16:38 |
| mterry | Yes. And those values are seemingly set correctly for unity8 | 16:39 |
| mterry | I'm just not seeing the mir_socket file existing | 16:39 |
| mterry | Though I *am* seeing the mir_socket_trusted file | 16:39 |
| dednick | hm. wonder if someting closed the file. | 16:39 |
| mterry | dednick, uh oh | 16:42 |
| mterry | dednick, I think I see a scenario where that might happen in fact | 16:42 |
| mterry | but this would all explain unity8-dash, but not the weird unity8 behavior... | 16:42 |
| mterry | kdub, I may see the problem. I think it's not Mir. It's a job deleting the mir socket after unity8 makes it | 16:43 |
| kdub | mterry, ah, okay | 16:43 |
| mterry | kdub, thank you for looking! | 16:44 |
| kdub | yep, no problem | 16:44 |
| kdub | mterry, MIR_SERVER_CONNECTOR_REPORT=log also has a helpful line about where mir creates the socket too | 16:45 |
| === alan_g is now known as alan_g|EOD | ||
| rsalveti | alf_: ogra_: libhybris is not providing that because we decided (a bunch of months ago) that going with updates-alternatives was actually better | 17:23 |
| rsalveti | and removing mesa is not that trivial actually, I think we might have deps issues with some other packages | 17:24 |
| rsalveti | but we can try I guess | 17:24 |
| rsalveti | something we can try before rtm I'd guess | 17:24 |
| rsalveti | but it might be tricky | 17:24 |
| rsalveti | maybe we can ask help from foundations | 17:24 |
| ogra_ | yeah | 17:25 |
| === dandrader|lunch is now known as dandrader | ||
| ogra_ | rsalveti, i asked pat to actually organize a cross team event to review the seeds/manifests before RTM | 17:26 |
| rsalveti | great | 17:27 |
| ogra_ | i guess we should just do it then | 17:27 |
| ogra_ | or at least inspect it | 17:27 |
| rsalveti | but mesa is so core that it might not be that trivial | 17:27 |
| ogra_ | yeah, i have no high hopes | 17:27 |
| rsalveti | just sucks that mesa brings a bunch of extras | 17:27 |
| ogra_ | definitely ... that drm crap is annoying | 17:27 |
| ogra_ | (and so bloated) | 17:28 |
| rsalveti | yeah | 17:28 |
| * ogra_ remebers we are fighting drm deps since the arm team startd | 17:28 | |
| ogra_ | thats like 4 years already .... still no solution | 17:29 |
| racarr | is everything failing CI due to this lxc-android-config stuff now? | 18:05 |
| racarr | / are the appropriate people notified | 18:05 |
| kdub | hmm, I saw that this morning for the 1st time on a RAOF branch | 18:05 |
| kdub | is it happening everywhere? | 18:05 |
| kdub | racarr, ^^ | 18:09 |
| racarr | kdub: It happened to your branch now | 18:17 |
| racarr | and my branch yesterday 2 times | 18:17 |
| racarr | in a row | 18:17 |
| racarr | seems all over :( | 18:19 |
| racarr | fix-1348330 I mean | 18:19 |
| racarr | has there been a change in the partitioning setup that one of the makos hasn't received (shot in the dark lol...) | 18:20 |
| racarr | not really sure what could be goiung on | 18:20 |
| kdub | racarr, yeah, seems dpkg is trying copy cross-partition, and the device won't let it | 18:23 |
| kdub | for lxc-android-config | 18:23 |
| racarr | mm | 18:24 |
| racarr | robotfuel: Are you still master of the mediumtests-runner-mako ? | 18:32 |
| racarr | I think we need to remove the dist-upgrade from the CI job | 18:32 |
| racarr | e.g. lxc-android-config isnt supposed to be runtime upgraded | 18:33 |
| robotfuel | racarr: josharenson took that over I think. I can take a look though | 18:48 |
| josharenson | robotfuel, it can probably be removed.. It was there when glmark2 required adding a ppa | 18:49 |
| josharenson | oh wait | 18:49 |
| josharenson | no I'm not sure why it was there... | 18:50 |
| racarr | I think it just seems like a good idea right | 18:50 |
| === ValicekB_ is now known as ValicekB | ||
| racarr | dist upgrade why not | 18:50 |
| racarr | and someone forgot it wasnt safe on the phones (I mean I have seen this CI output dozens of times and never remembered lol) | 18:50 |
| racarr | if we don't want to mess with it upgrading the makos may be enough to fix things for now...not sure of the timing | 18:50 |
| josharenson | yeah it was in the script to begin with... what could it hurt to remove it? | 18:50 |
| racarr | of last promotion/the lxc-android update | 18:51 |
| josharenson | I'll remove it now, and watch the builds | 18:51 |
| racarr | uhhh | 18:51 |
| racarr | I don't think it could hurt anything | 18:51 |
| racarr | just have to make sure the makos are kept up to date | 18:51 |
| racarr | with images | 18:51 |
| racarr | not sure how that is handled | 18:51 |
| josharenson | racarr, uh I don't see a dist upgrade happening... grep agrees, let me look closer | 18:52 |
| josharenson | at least in the mir-medium-test-runner-for-jenkins job | 18:53 |
| racarr | josharenson: https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/2386/console | 18:57 |
| racarr | + apt-get dist-upgrade -y --force-yes | 18:57 |
| racarr | btw ive always wondered what is a medium test | 18:57 |
| racarr | lol | 18:57 |
| josharenson | racarr, I see it there, but its not in the lp project that I have commit access to | 18:58 |
| racarr | ah | 18:58 |
| josharenson | and I also have no idea what a mediumtest is | 18:58 |
| josharenson | we should be running hardtests | 18:58 |
| racarr | lol | 18:58 |
| josharenson | anyways, robotfuel, you know where the dist-upgrade comes from? | 18:59 |
| robotfuel | it might be in the jenkins job | 19:00 |
| robotfuel | it was from a long time ago :P | 19:00 |
| racarr | looks like its part of some "preinstall" step | 19:02 |
| robotfuel | racarr: josharenson http://bazaar.launchpad.net/~mir-team/+junk/mir-medium-test-runner-for-jenkins/view/head:/mir_install_packages.sh is where it's at | 19:04 |
| robotfuel | line 18... | 19:04 |
| racarr | :) | 19:05 |
| josharenson | robotfuel, so I'm very confused now... Is the jenkins job pointing to the project in ~josharenson/+junk/ or ~mirteam/+junk | 19:06 |
| josharenson | because my version of the file doesn't have that | 19:06 |
| robotfuel | josharenson: lp:~mir-team/+junk/mir-medium-test-runner-for-jenkins is in the job config | 19:08 |
| josharenson | robotfuel, I thought we changed that in Malta? | 19:09 |
| === mardy_ is now known as mardy | ||
| === dandrader is now known as dandrader|bbl | ||
| kdub | josharenson, robotfuel, racarr kinda trailed off... but is that problem setting up the lxc-android-config still ongoing? https://jenkins.qa.ubuntu.com/job/mir-mediumtests-utopic-touch/ | 20:34 |
| kdub | trying to figure out when its worthwhile to retrigger landings | 20:35 |
| josharenson | kdub, I didn't make any changes, so its probably still happening.. Since the issue isn't part of the single lp repo I have access to, there isn't anything I can do I don't think :-/ | 20:35 |
| kdub | josharenson, ack, I'll go agitate over in #ubuntu-ci-eng | 20:37 |
| josharenson | gl | 20:37 |
| racarr | Is anyone using sbuild to cross compile mir? | 20:50 |
| racarr | I am having difficulties... g++-4.9:armhf : Depends: gcc-4.9:armhf (= 4.9.1-5ubuntu1) but it is not going to be installed | 20:50 |
| kdub | i've tried with sbuild, but havent had much luck | 20:55 |
| racarr | cross-compile-chroot isnt working for me anymore either :( | 21:05 |
| racarr | The C compiler "/usr/bin/arm-linux-gnueabihf-gcc" is not able to compile a | 21:05 |
| racarr | simple test program bla bla bla | 21:05 |
| racarr | but blank output | 21:05 |
| kdub | racarr, did you do the transition to 4.9? | 21:06 |
| kdub | i had to like configure the alternatives to get it going a bit ago | 21:06 |
| racarr | kdub: Hmm? On the host or in the chroot. This is a new chroot. | 21:08 |
| racarr | host is 4.9 | 21:08 |
| kdub | host, right | 21:08 |
| kdub | lemme try to regenerate the chroot from devel, a few mins | 21:08 |
| racarr | kdub: Thanks :) | 21:13 |
| fginther | kdub, moving here now... Right now, the disabled test will likely cause all MPs to fail. Is it better to remove the test and allow MPs to pass? | 21:29 |
| kdub | fginther, I guess camako or kgunn_ should make that call | 21:30 |
| kdub | although I'm becoming a bit backlogged, I'd prefer to wait | 21:31 |
| fginther | camako, kgunn_, to catch you up. the mir-mediumtests-runner-mako test is causing a new version of adbd to be installed. This will wedge the phone and require a human to restart it. I've had to disable the test so that all of the phones don't die | 21:31 |
| fginther | a new image is likely to resolve this, allowing for a proper fix to be implemented to deal with this problem the next time | 21:32 |
| kgunn_ | camako, i defer to you, but kinda feels like we should catch the next image | 21:36 |
| * camako is looking at the script | 21:38 | |
| camako | kgunn_, everyone on the team runs the tests that this script runs (and more) on a regular basis.. so it's ok for a while.. | 21:40 |
| kgunn_ | camako, you bet, that argument makes sense | 21:41 |
| camako | kgunn_ this is the script I was looking at before the release... It has other problems as well, e.g. demos don't work | 21:41 |
| kgunn_ | ack | 21:42 |
| fginther | camako, kgunn_, so the request is to continue testing MPs, but remove this test until the next image? | 21:42 |
| camako | fginther, I think it's fine.. what 's the ETA on the image? | 21:42 |
| fginther | camako, about 6 hours | 21:42 |
| camako | fginther, not a problem | 21:43 |
| camako | fginther would you mind giving me a heads up when you've reenabled it? | 21:43 |
| kgunn_ | ok, still having fun-with-computers TM...rebooting | 21:43 |
| camako | fginther, also , the 0.4, and 0.5 specific scripts can now be removed.. We'll soon need 0.7 :-) (will let you know when) | 21:44 |
| fginther | camako, sure. If for some reason the next image doesn't contain the expected version of adbd, I'll need to keep it disabled. Will give you a notice either way | 21:46 |
| fginther | assuming the image arrives before I go to bed tonight (which it should0 | 21:46 |
| camako | fginther, np, I'll change the title on IRC/mir to let people know that they need to run the tests manually until further notice | 21:47 |
| racarr | fginther: There were other issues before the new version of adb being installed, i.e. upgrading lxc-android-config | 21:49 |
| racarr | which apparently should never be done | 21:49 |
| fginther | ugh | 21:49 |
| racarr | so I think the problem is dist-upgrade being run on | 21:49 |
| racarr | the phones | 21:50 |
| racarr | as part of CI | 21:50 |
| racarr | right? It's just not safe | 21:50 |
| racarr | and I don't think there is any particular need to do it | 21:50 |
| fginther | racarr, In that context I agree, although I've heard it argued the other way that without a dist-upgrade it's missing potential bug fixes, etc. | 21:52 |
| racarr | hmm | 21:52 |
| fginther | racarr, I'm not even sure if this was pulled in due to a dist-upgrade (I assume you are right, but haven't checked yet) | 21:53 |
| racarr | yes perhaps not | 21:53 |
| racarr | the lxc-android-config was | 21:53 |
| racarr | maybe we need | 21:53 |
| racarr | a blacklist of packages | 21:53 |
| racarr | not to upgrade | 21:53 |
| racarr | i.e. the script can, apt-get update, apt-get dist-upgrade --simulate or whatever it is | 21:54 |
| racarr | remove lxc-android-config, adb, etc | 21:54 |
| racarr | upgrade all remaining packages | 21:54 |
| fginther | racarr, right, that would be an option. Sure we can figure out some way to avoid insalling those | 21:54 |
| === dandrader|bbl is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!