[04:16] <pitti> Good morning
[04:17] <pitti> Laney: what's the context of your ping for the new cgroup layout? do we need this now for something?
[07:01] <Saviq> larsu, uh, missed your last message - yeah there is a default property - but only one - and it only works as a list of children
[07:08] <larsu> Saviq: yeah, that's what I thought. Thanks
[07:11]  * didrocks is having a too low bread-shot level in blood
[07:16] <jibel> good morning
[07:33] <didrocks> salut jibel!
[07:34] <seb128> good morning desktoper
[07:34] <seb128> lut didrocks
[07:34] <didrocks> hey seb128!
[07:34] <seb128> pitti, salut
[07:34] <jibel> Bonjour didrocks
[07:34] <pitti> bonjour seb128
[07:34] <jibel> Bonjour seb128
[07:34] <pitti> ça va didrocks
[07:35] <pitti> hey larsu, how are you? in Berlin again?
[07:35] <didrocks> pitti: ça va bien, et toi?
[07:35] <pitti> didrocks: ça va bien aussi
[07:35] <seb128> pitti, reading backlog, http://irclogs.ubuntu.com/2013/07/16/%23ubuntu-desktop.html#t18:04 for Laney's comment about the cgroup thing
[07:35] <seb128> lut jibel
[07:40] <larsu> pitti: yep! Loving it here :)
[07:40]  * larsu needs to find a place, though
[07:40] <seb128> larsu, good morning ;-)
[07:40] <larsu> bonjour seb128, how are you?
[07:41] <seb128> larsu, I'm good thanks
[07:41] <seb128> larsu, enjoying the not-so-hot yet temperature in the morning ;-)
[07:42] <pitti> seb128: oh, does it become so hot at your place now?
[07:42] <seb128> pitti, 34.5°C yesterday afternoon
[07:42] <pitti> it's actually been quite pleasant here for the past week, about 23 degrees and sunny
[07:42] <larsu> it's not terribly hot here
[07:42] <seb128> which is a bit too much to my taste
[07:42] <larsu> seb128: crazy!
[07:42] <larsu> pitti: ya, same here. Perfect if you ask me :)
[07:42] <pitti> seb128: c'est trop chaud!
[07:42] <pitti> larsu: +1
[07:42] <seb128> pitti, en effet !
[07:47] <didrocks> bon, il a plu ici 2 minutes!
[07:47] <didrocks> seb128: thx!
[07:48] <seb128> didrocks, lol
[07:48] <didrocks> that's how I know you start working :p
[07:48] <didrocks> should I add *finally*?
[07:49]  * didrocks runs…
[07:49] <seb128> ;-)
[07:49] <seb128> roooh
[07:49] <didrocks> ;)
[07:49] <seb128> wait for 19h so I can make joke about you *already* stopping :p
[07:49] <didrocks> seb128: ahah ;)
[07:49]  * seb128 hugs didrocks
[07:49]  * didrocks hugs seb128 back
[07:50] <seb128> didrocks, larsu: great, charles' fix for indicator-session worked, the gmenu version is finally in saucy
[07:50] <didrocks> yeah, that's nice! :-)
[07:50] <pitti> il faut manger le diner à 19:00, pas travailler ..
[07:50] <larsu> seb128: great!
[07:50] <didrocks> pitti: avec une glace en dessert?
[07:50] <seb128> pitti, did you see my note about the cgroup thing? Laney thinks it might be creating the issue where gnome-session doesn't inhibit shutdown
[07:50] <pitti> didrocks: bien sûr !
[07:50] <didrocks> :)
[07:50] <didrocks> seb128: btw, you should thanks the mir team
[07:51] <didrocks> seb128: as they are breaking ABI everyday, I have to split stuff in 2 stacks
[07:51] <didrocks> and force one stack building, even when there is no change
[07:51] <pitti> seb128: we don't have the rearranged cgroups yet
[07:51] <seb128> go robert_ancell go ;-)
[07:51] <pitti> seb128: also, why would they affect inhibitors?
[07:51] <didrocks> seb128: so I'll use that hacking to enable the "force rebuild" option I guess :)
[07:51] <pitti> seb128: no, I just saw "reading scrollback", but no actual comment
[07:52] <seb128> pitti, the url to the irc log was on the same line
[07:52] <seb128> pitti, http://irclogs.ubuntu.com/2013/07/16/%23ubuntu-desktop.html#t18:04
[07:52] <seb128> "Laney	[pid  6011] inotify_add_watch(12, "/sys/fs/cgroup/systemd/machine", IN_MOVED_TO|IN_CREATE|IN_DELETE) = -1 ENOENT (No such file or directory)	18:04
[07:52] <seb128> Laney	That's why sd_login_monitor_new fails"
[07:52] <seb128> pitti, ^ I think Laney was suggesting that gnome-session was bailing out of setting the inhibitor due to that
[07:53] <seb128> but let's wait for him
[07:53] <pitti> aah
[07:53] <pitti> hm, why is that already in gnome 3.8? the cgroup reorg happened much after that
[07:58] <didrocks> sil2100: was the unity run with "check with whole ppa" gave good results yesterday?
[07:59] <didrocks> hey btw :)
[07:59] <sil2100> didrocks: hi! Not too good ;/
[08:00] <didrocks> sil2100: urgh, mhr3 and other unity people are on it?
[08:00] <sil2100> didrocks: one machine failed for unknown reasons, the second had still a lot of failures
[08:00] <didrocks> sil2100: well, at least, while they are analysing it, there are some stacks to fix/get on shape this morning :)
[08:00] <sil2100> didrocks: yes, mhr3 knew about it, he also ran bustle-pcap on one of the machines
[08:00] <didrocks> ok
[08:01] <sil2100> I know, it's raining red ;D
[08:01] <mhr3> the good news is that the hud thing was indeed fixed
[08:01] <didrocks> yep
[08:01] <sil2100> Oooh oooh?
[08:01] <mhr3> the bustle log looks reasonable now
[08:01] <Laney> good day!
[08:01] <sil2100> Oooh
[08:01] <sil2100> mhr3: hm
[08:02] <seb128> Laney, good morning!
[08:02] <sil2100> mhr3: but there are still a lot of failures
[08:02] <didrocks> hey Laney!
[08:03] <mhr3> sil2100, yea, i just re-approved one ap fix, should help, we'll see how things will look then
[08:03] <sil2100> mhr3: awesome!
[08:03] <Laney> pitti: that strace snippet is from a call inside logind; sd_login_monitor_new, which gnome-session calls and fails
[08:03] <mhr3> but tbh the unity tests look more flaky than ever :/
[08:03] <Laney> the commit I found was just some random poking around upstream :-)
[08:04] <pitti> Laney: ah, so sd_login_monitor_new() is generally broken in our version?
[08:04] <sil2100> It seems that due to all the delays with releases, we didn't really have any real unity testing, so probably all flackied up during that time
[08:04] <pitti> Laney: probably because we don't have a real pid 1; so this either needs some systemd-shim hack, or we need to change that test
[08:04] <Laney> pitti: Well, it appears to look for that /sys/fs/cgroup/systemd/machine which doesn't exist and bail out due to that
[08:04] <pitti> Laney: would you mind filing a bug about it?
[08:04] <Laney> Beyond that I can't tell you what it's for
[08:05] <Laney> The root bug we were poking at is that pressing shutdown stops the machine straight away
[08:05] <Laney> so I was looking at why g-sessino didn't inhibit it
[08:06] <pitti> I'll have a look what that thing is and how we can make this work, but I'd like to finish something else first (also, we might need to reassign to -shim)
[08:06] <Laney> I'm not certain this is the cause but it seems like a good place to start
[08:06] <Laney> will file; thanks
[08:06] <seb128> Laney, pitti: you can reuse the bug from Trevinho there I guess?
[08:06] <pitti> Laney: thanks; even if theres' something else, login_monitor_new() ought to work
[08:06] <pitti> sure, if there is one already
[08:06] <Laney> seb128: oh, there is one?
[08:06] <seb128> https://bugs.launchpad.net/bugs/1201180
[08:06] <ubot2`> Ubuntu bug 1201180 in gnome-session (Ubuntu) "Pressing power button turns off the PC ignoring the presence of another session manager" [Undecided,New]
[08:06] <Laney> ty
[08:10] <sil2100> didrocks: fixing the packages lists right now, since SDK has some new deps
[08:12] <sil2100> didrocks: also, it seems that now the UI toolkit depends on HUD directly
[08:12] <didrocks> sil2100: yeah, you need to shepard the dependencies between the stack
[08:12] <didrocks> and the hours I guess
[08:28] <sil2100> didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/stack_fixes_due_to_sdk/+merge/175218
[08:30] <didrocks> sil2100: did you read my comment on the hours/schedule to change?
[08:31] <didrocks> sil2100: it seems they are on the right order, but I wonder if we shouldn't keep them shorter
[08:31] <didrocks> sil2100: thoughts?
[08:32] <didrocks> sil2100: otherwise, +1 (we can reschedule them later on if needed)
[08:33] <sil2100> didrocks: the description has some commments on that
[08:34] <sil2100> didrocks: as I said in the description, the schedules might need tweaking, but as this  scheme works (and there are no deadlocks right now), then we can use a seperate merge for that
[08:35] <didrocks> sil2100: yeah, let's get that rolling then! approving, thanks! :)
[08:35] <didrocks> sil2100: I'll let you redeploy/rerun?
[08:36] <didrocks> one chromium finishes to hang…
[08:36] <sil2100> Yep!
[08:49] <seb128> tjaalton, mlankhorst: do you know if we will get an -intel new version soon? I see frequent corruptions since the xserver update in saucy :/
[08:54] <mlankhorst> seb128: well we didn't do that yet because last few releases intel broke badly
[08:55] <seb128> mlankhorst, no sign on a non broken one?
[08:55] <tjaalton> yeah and .12 is still broken for some
[08:55] <tjaalton> released last sunday
[08:55] <tjaalton> guess we could push that to x-staging
[08:56] <mlankhorst> sure, just give me a sec
[08:56] <seb128> tjaalton, mlankhorst: what sort of issue is the current version having?
[08:56] <mlankhorst> since it's a graphics driver I'm guessing one of the following 3: crashes, corruptions, or lockups
[08:56] <tjaalton> like it depended on some kernel fixes..
[08:56] <tjaalton> which is bad
[08:57] <seb128> hum, ok, I guess upstream is aware of it? do they have plan to fix that?
[08:57] <seb128> or do we need our kernel to include patches?
[08:57] <tjaalton> well it's kinda hearsay, although from another intel dev :)
[08:58] <tjaalton> running 3.9
[08:58] <tjaalton> so maybe if this one works good on 3.10 we could push it to saucy
[08:59] <seb128> tjaalton, do you have any xorg.conf workaround for those corruption issues?
[09:00] <tjaalton> i don't
[09:00] <seb128> oh, I don't have the xorg.conf with uxa set anymore
[09:00] <seb128> let me try to put that back
[09:00] <tjaalton> right, uxa might work
[09:00] <seb128> brb, restarting (need to restart xorg and since new kernel, I can as well reboot)
[09:06] <seb128> tjaalton, looks good with uxa again for me, I'm happy ;-)
[09:06] <seb128> the corruption was driving me crazy
[09:06] <tjaalton> seb128: ok, you'll notice when there's an update to test again :)
[09:06] <seb128> we should perhaps default to uxa if we can't update the driver?
[09:07] <seb128> or force the workaround define in the code
[09:07] <tjaalton> which hw did you have?
[09:07] <seb128> i5
[09:07] <tjaalton> generation?
[09:07] <seb128> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1189850
[09:07] <ubot2`> Ubuntu bug 1189850 in xserver-xorg-video-intel (Ubuntu) "saucy has frequent image corruption (intel, sna)" [High,Fix committed]
[09:07] <seb128> that has the apport details
[09:07] <Laney> mlankhorst: oh hey: http://cdimage.ubuntu.com/daily-live/current/ :D!
[09:07] <tjaalton> yeah, gen5
[09:08] <tjaalton> the current one should work fine on non-gen5 I guess
[09:08] <tjaalton> at least on my gen6 sandybridge
[09:08] <tjaalton> and gen4 laptop
[09:09] <mlankhorst> Laney: awesome \o/
[09:09] <mlankhorst> now lets hope I never have to worry about pand aagani
[09:09] <Laney> mlankhorst: check the .manifest file and see if it seems right please
[09:09] <tjaalton> seb128: apparently 2.21.12 works fine on 3.10
[09:10] <tjaalton> but let's get some testing first on the ppa
[09:10] <Laney> I need to upload livecd-rootfs again to do the same thing for kubuntu
[09:10] <mlankhorst> Laney: looks ok to me
[09:10] <Laney> great
[09:10] <seb128> tjaalton, thanks
[09:11] <Laney> my panda is still on quantal
[09:11] <Laney> maybe should upgrade it one day :P
[09:11] <mlankhorst> mine's still on precise atm
[09:11] <mlankhorst> but I can change it to raring by overwriting the first 100 mb on the sd card
[09:13] <mlankhorst> hm, I guess I could try if it actually boots or not..
[09:13] <Laney> might be useful
[09:13] <Laney> not sure I want to know though :P
[09:13] <mlankhorst> ah indeed, that is the real question..
[09:14] <Laney> but at least we know how to add extra packages if necessary ...
[09:17] <mlankhorst> you know what, I'm going to try..
[09:17] <Laney> you da man
[09:26] <sil2100> didrocks: interesting thing
[09:26] <sil2100> didrocks: the media stack -
[09:27] <didrocks> sil2100: I read #ubuntu-touch :p
[09:27] <sil2100> Could it be that something wrong is happening with the prepare jobs?
[09:27] <didrocks> oh, not that one?
[09:27] <didrocks> let me look
[09:27] <didrocks> sil2100: hum, what do you see in the prepare jobs?
[09:27] <didrocks> http://10.97.0.1:8080/view/cu2d/view/Head/view/Media/?
[09:28] <sil2100> didrocks: since, what I mean:
[09:29] <sil2100> didrocks: both the check and build jobs are waiting for 2.9.1+13.10.20130717-0ubuntu1, which is the correct thing to wait for
[09:29] <sil2100> didrocks: of camera-app
[09:30] <sil2100> didrocks: but the prepare job seems not to have pushed the camera-app to the PPA properly, as 2.9.1+13.10.20130717-0ubuntu1 is not there (there's only 20130708 or something)
[09:30] <didrocks> interesting
[09:30] <sil2100> didrocks: it says Successfully uploaded packages., but maybe it got rejected?
[09:30] <didrocks> hum
[09:30] <didrocks> http://10.97.0.1:8080/view/cu2d/view/Head/view/Media/job/cu2d-media-head-1.1prepare-camera-app/97/console
[09:30] <didrocks> it says nothing?
[09:31] <sil2100> didrocks: this was for foo
[09:31] <didrocks> ah :)
[09:31] <sil2100> http://10.97.0.1:8080/view/cu2d/view/Head/view/Media/job/cu2d-media-head-1.1prepare-camera-app/96/console
[09:31] <didrocks> sil2100: I was starting scratching my head :p
[09:31] <didrocks> yeah, so dput worked
[09:31] <sil2100> Since I wanted to re-run the stack, since I thought that maybe camera-app failed to build but someone restarted it in the PPA and it suddenly worked
[09:31] <sil2100> But then I noticed the version number is wrong (it's old)
[09:31] <sil2100> So hm, maybe a reject?
[09:32] <didrocks> sil2100: we receive normally a LP email by reject
[09:32] <didrocks> sil2100: but maybe a transiant launchpad issue which ignored that one
[09:32] <didrocks> but yeah, weird, we don't have it in the ppa
[09:32] <didrocks> sil2100: so, maybe try to rebuild it?
[09:33] <sil2100> didrocks: you mean, rebuild the stack with camera-app?
[09:34] <didrocks> sil2100: yeah, it should retrigger an upload
[09:35] <didrocks> sil2100: successfully this time, let's hope :p
[09:39] <didrocks> sil2100: btw, nice opinion on not publishing sdk until we figure out what's wrong :p
[09:42] <sil2100> ;p But I think I'll have to look into that AP problem myself, since gusch is not too eager to take a look ;)
[09:42] <sil2100> Well, maybe I should poke om26er
[09:42] <sil2100> om26er: ping!
[09:42] <om26er> sil2100, pong
[09:42] <sil2100> om26er: helllooo
[09:42] <sil2100> om26er: we're having a gallery-app AP failure that's a bit irritating, you think you could help out?
[09:43] <om26er> sil2100, yeah, sure. point me at the failures
[09:43] <sil2100> om26er: http://10.97.0.1:8080/job/autopilot-saucy-daily_release/470/testReport/ <- it's just a single failure
[09:43] <sil2100> For both machines it happens
[09:44] <sil2100> om26er: thanks!
[09:47] <darkxst> seb128, hi
[09:55] <seb128> darkxst, hey
[09:56] <darkxst> seb128, any further thoughts on what will happen with g-c-c for this cycle?
[09:56] <sil2100> I jump out now for some quick exercise, didn't have any this week!
[09:56] <sil2100> brb
[10:04] <didrocks> how waow
[10:04]  * didrocks sees force_release already in code!
[10:04] <didrocks> indeed, I've prepared for differente source of force_release, excellent! :)
[10:08] <darkxst> seb128, we really 3.8 this cycle
[10:09] <seb128> darkxst, hey
[10:09] <seb128> darkxst, lack a word, "want"?
[10:09] <darkxst> "need"
[10:09] <seb128> darkxst, though: that's work and we are busy and with other priorities, one step at time
[10:09] <seb128> darkxst, next step is ibus 1.5
[10:09] <seb128> then we can look at g-s-d
[10:09] <seb128> then we can look at g-c-c
[10:10] <seb128> darkxst, by "we" I guess you mean Ubuntu GNOME? And you "need" it because you decided you want the current version, rather than because we have flaws in the current one, right?
[10:11] <darkxst> seb128, yes and we need it because there is quite some stuff that can't be configured using 3.6
[10:12] <seb128> like?
[10:12] <darkxst> control of notifications per-app, privacy settings
[10:12] <seb128> we never had that and Ubuntu is still usable
[10:13] <seb128> they are "nice to have", not things "needed"
[10:13] <seb128> but yeah, updating would be "nice" ;-=)
[10:13] <darkxst> ubuntu has its own privacy panel
[10:13] <darkxst> but that is 99% useless in gnome-shell
[10:15] <mlankhorst> seb128: uploaded, enjoy :P
[10:15] <mlankhorst> (to x-staging)
[10:15] <seb128> mlankhorst, thanks
[10:15] <seb128> darkxst, right, but GNOME up to 3.6 didn't have that feature and I bet it neither stopped you to use gnome-shell or made you call GNOME 3.6 not usable
[10:16] <seb128> darkxst, e.g those are "nice to have" but users have been doing fine without those features for a decade
[10:17] <seb128> darkxst, well, anyway I agree the update would be nice, I just put in perspective how much we *need* to update
[10:19] <darkxst> well right, but in that case there are plenty of other "nice to have"s as well
[10:20] <seb128> there is always
[10:20] <seb128> the fact that GNOME is outdated doesn't stop people to use RHEL6 or Ubuntu LTS or Debian stable
[10:21] <seb128> but let's stop arguing on details, that's not useful
[10:21] <seb128> next steps are:
[10:21] <seb128> - get ibus 1.5 in
[10:21] <darkxst> and besides I have already fixed the main blockers, but if it gets left too late, no guarantee I will be able to get it done in time
[10:21] <seb128> - then look at updating g-s-d
[10:21] <seb128> - then look at g-c-c
[10:21] <seb128> my gut feeling is that g-c-c 3.8 is not likely to be for this cycle
[10:22] <seb128> we might want to look at making a g-c-c-gnome and a g-c-c-unity to unblock you guys
[10:22] <seb128> with both conflicting
[10:24] <darkxst> right that would be good
[10:42] <didrocks> seb128: sil2100: jibel: https://code.launchpad.net/~didrocks/cupstream2distro-config/support-manual-rebuild-and-mir/+merge/175247
[10:43] <didrocks> the change in cupstream2distro is deployed already: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/349
[11:00] <mlankhorst> Laney:  gasp, xorg started, but the pvr-omap4 module was not installed in /usr/lib/xorg/drivers
[11:01] <Laney> welp
[11:01] <Laney> the package is installed though
[11:01] <Laney> is that the bug we saw before?
[11:02] <mlankhorst> oh found out why
[11:02] <mlankhorst> libhybris-egl has equal priority to provide armhf yadda yadda egl
[11:02] <mlankhorst> so that priority needs to be bumped from 1000 to something higher
[11:03] <Laney> go go go
[11:03] <mlankhorst> or libhybris needs to be removed :P
[11:06] <mlankhorst> http://paste.debian.net/16518/ debdiff, I don't think pvr-omap4 is part of the xorg group
[11:07] <Laney> ty
[11:07] <Laney> can we drop those explicit xorg deps now?
[11:08] <Laney> actually I'd rather not mess with this beast
[11:08] <mlankhorst> and not really, unless you want to create /usr/lib/xorg/modules/drivers yourself
[11:11]  * Laney tries his new sbuild/armhf on amd64 chroot out
[11:17] <didrocks> seb128: sil2100: jibel: once you will have reviewed the other one, there is as well https://code.launchpad.net/~didrocks/cupstream2distro-config/skip-version-check/+merge/175253 (mostly to make seb128 happy ;))
[11:17] <didrocks> correspondant change in cupstream2distro is http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/351
[11:23] <sil2100> didrocks: reviewing both!
[11:32] <seb128> sil2100, thanks for reviewing those ;-)
[11:44] <sil2100> didrocks: what's with that mirslave stack ;p?
[11:44] <sil2100> I mean, the name ;)
[11:44] <didrocks> sil2100: it should be explained in the comment, is it nor clear enough? :)
[11:44] <didrocks> sil2100: basically mir deps
[11:45] <sil2100> It's clear clear ;)
[11:45] <didrocks> there is unity-system-compositor for now
[11:45] <didrocks> we'll have unity-mir soon :)
[11:45] <didrocks> sil2100: btw, once you will have finish with media/sdk and platform, do you want to clean unity-mir source?
[11:45] <didrocks> sil2100: so that we can have it as well under dailies :)
[11:46] <didrocks> (grabbing karma for upload rights :p)
[11:47] <sil2100> didrocks: sure ;) But that will have to wait after-luch!
[11:47] <didrocks> sil2100: sure sure ;)
[11:48]  * didrocks needs to take the only break of the day as well anyway :p
[12:29] <desrt> cyphermox_: hey
[12:30] <desrt> cyphermox_: the network indicator is a bit of of a mess :(
[12:30] <desrt> the service, i mean
[12:30] <desrt> i found a new bugs in it, including a crasher.... and fixed the crasher and it doesn't crash for me anymore
[12:30] <desrt> but it wasn't the same crasher you had a backtrace for
[12:31] <desrt> *a few bugs
[12:49] <mlankhorst> Laney: updating pvr-omap4 and restarting ubiquity worked
[12:49] <Laney> nice
[12:49] <Laney> try a kubuntu one tomorrow :P
[12:49]  * mlankhorst gives laney the evil eye
[12:50] <Laney> :-)
[12:54] <ricotz> desrt, Laney, hi :), jfyi, the new dbus-appinfo test hangs in a buildd/pbuilder
[12:55] <ricotz> (just relevant for glib 2.37.5+)
[12:55] <desrt> ricotz: interesting.  do you have any further info?
[12:55] <ricotz> desrt, sorry no
[13:00]  * desrt wonders what the deal with his internet is this morning
[13:09] <kenvandine> didrocks, i found a weird error from otto in the media stack autopilot tests
[13:09] <kenvandine> E: Too many packages installed. Exiting
[13:09] <kenvandine> W: Shutdown requested!
[13:09] <desrt> cyphermox_: let me know when you're awake
[13:10] <seb128> Laney, can you explain your sound.split('/').pop() ?
[13:12] <seb128> Laney, you don't want to just accept my version and mp yours over? ;-)
[13:12] <seb128> Laney, it would avoid me to have to rebase my 2 others branches that I already submitted (the scrolling on and the silent warning one), your change would create conflict
[13:13] <seb128> Laney, your version is also buggy and I'm not sure where to comment about the bug
[13:13] <Laney> how about telling me what it is
[13:13] <seb128> Laney, you .shift() truncated the filename after the first "." not after the last one
[13:14] <seb128> e.g "one.sound.ogg" is displayed as "one"
[13:14] <seb128> where my version display it as "one sound"
[13:14] <didrocks> kenvandine: how weird this is?
[13:14] <seb128> Laney, I'm not sure why you split on "/", none of those files have a "/" in their filename
[13:15] <Laney> To make it work for full paths too, if that happens
[13:15] <seb128> oh, ok
[13:15] <didrocks> kenvandine: that's how it's supposed to work ;)
[13:16] <kenvandine> didrocks, why does it complain that it installed too many packages?
[13:16] <kenvandine> or
[13:16] <kenvandine> is that really a comparison?
[13:16] <kenvandine> showing new deps?
[13:16] <seb128> Laney, so you want me to merge your version and rebase my 2 other branches I guess?
[13:16] <Laney> seb128: I don't really mind, but on principle it's not great if you can't do changes to a branch because others are already stacked on it
[13:16] <Laney> IYSWIM?
[13:16] <seb128> that's going to teach me to stack work on top of unapproved merge requests :p
[13:17] <didrocks> kenvandine: that's what the package list is for
[13:17] <Laney> let me think of a cool one-line way to fix that thing
[13:17] <didrocks> kenvandine: only installing what we need
[13:17] <seb128> Laney, rebasing is easy, let's do it the proper way
[13:17] <kenvandine> oh.... i see!
[13:17] <didrocks> kenvandine: https://wiki.ubuntu.com/DailyRelease/StackDependencies#Running_integration_tests_in_isolation
[13:17] <kenvandine> i was confused from it being in the otto-setup.log
[13:17] <didrocks> this is to ensure that ^
[13:18] <kenvandine> i thought that would have been more of a test failure
[13:18] <didrocks> kenvandine: you have the summary.log in the end
[13:18] <seb128> Laney, well, you can replace .push() by .slice(0,-1).join(" ") (what my version is doing)
[13:18] <kenvandine> ok
[13:18] <didrocks> showing that package installation: FAILED
[13:18] <Laney> yeah
[13:18] <didrocks> kenvandine: so I guess the list had to be refreshed to rerun the tests
[13:18] <seb128> Laney, is that fine if I merge yours with that change?
[13:18] <seb128> well merge in my branch and resubmit
[13:18] <didrocks> kenvandine: my goal at some point is to not block on that, but make the publication manual
[13:18]  * seb128 does that
[13:19] <didrocks> kenvandine: telling "warning warning, maybe there is a soname change and we need to publish X and Y"
[13:19] <kenvandine> didrocks, understand now
[13:19] <kenvandine> i thought it was more of a failure of building the chroot
[13:19] <kenvandine> makes sense now
[13:19] <Laney> seb128: ok, sounds fine
[13:20] <didrocks> kenvandine: you can now really trust when the otto job is red :)
[13:20] <didrocks> kenvandine: but yeah, at some point, the goal is red == infrastructure issue
[13:20] <didrocks> (once we have the dashboard)
[13:20] <didrocks> so that we don't have to wonder
[13:26] <seb128> Laney, new diff on https://code.launchpad.net/~seb128/ubuntu-system-settings/sound-display-names/+merge/175250
[13:26] <seb128> Laney, let me know if it's ok, so I can rebase my other branches ;-)
[13:27] <Laney> awesome
[13:27] <Laney> approving
[13:27] <desrt> g'morning Laney, seb128, didrocks, kenvandine
[13:27] <Laney> good day desrt!
[13:27] <kenvandine> good morning desrt!
[13:28] <didrocks> hey desrt! how are you?
[13:28] <Laney> it's a mere 28° today
[13:28] <seb128> Laney, thanks ;-)
[13:28] <seb128> desrt, hey, how are you?
[13:28] <desrt> didrocks: pre-coffee yet.  but improving quickly :)
[13:28] <desrt> it both feels like it should be thursday and tuesday today
[13:29] <desrt> but definitely not wednesday
[13:29] <desrt> i guess they decided on a compromise
[13:30] <Laney> I'm going to voice my discontent at this compromise by eating a delicious lunch
[13:30] <Laney> bbs
[13:30] <mlankhorst> does anyone here have a working unity?
[13:30] <desrt> Laney: occupy tastebuds!
[13:30] <desrt> mlankhorst: uhm... i do?
[13:30] <desrt> what does 'working' mean? :)
[13:31] <mlankhorst> actually having panels shown
[13:31] <desrt> ya... but i haven't done an upgrade in a little while
[13:31] <mlankhorst> none of the machines running saucy work for me, it seems
[13:31] <desrt> apparently they flipped the mir switch recently
[13:31] <desrt> may have something to do with it
[13:31] <desrt> i like attente was having problems yesterday
[13:31] <mlankhorst> I'm running plain Xorg
[13:35] <mlankhorst> hm running unity as root works
[13:36] <mlankhorst> I guess nvidia-tegra needs some permissions
[14:36] <jbicha> seb128: attente: I was thinking for ibus autostart that we add a switch in g-c-c that controls a new gsettings key so that we can autostart/stop ibus based on the key changing instead of an env var
[14:37] <seb128> jbicha, that shouldn't be needed
[14:37] <seb128> we should just make g-c-c set that key when there is > layout or im
[14:37] <seb128> what's the point of having an ui control?
[14:38] <jbicha> g-c-c doesn't show ibus layouts in the add layout dialog without ibus-daemon running
[14:38] <seb128> ok, so why would you want to not start ibus if it's needed?
[14:38] <seb128> or g-c-c should start it...
[14:39] <jbicha> so g-c-c should start it but then kill it again if an ibus method isn't activated?
[14:40] <seb128> yeah
[14:40] <seb128> or we decide ibus is a service that should run for everyone
[14:40] <seb128> is ibus needed for e.g an american user with a qwerty keyboard who is never going to use another layout or im?
[14:41] <jbicha> no, the American doesn't need it; AFAIK ibus is generally only needed for east Asian languages
[14:43] <seb128> well, it's also used for keyboard layouts nowadays it seems
[14:43] <seb128> which seems to be confirmed by what you just wrote
[14:44] <attente> we're not using it for layouts though, we still fall back onto xkbd for ordinary layouts
[14:46] <jbicha> yeah as long as I don't actually need an ibus method, I have no problem adding, removing or switching between keyboard layouts without ibus-daemon running
[14:47] <jbicha> and ibus-daemon does take up several MB of RAM
[14:47] <seb128> jbicha, attente: to me it feels like we should activate ibus if the keyboard config requires it and we should make g-c-c start it to allow configuring those
[14:48] <seb128> so a normal user with 1 layout wouldn't have it running
[14:48] <attente> g-c-c seems to already hard-code ibus engine names into it
[14:49] <attente> i wonder if we might as well hard-code things like the engine's display name, and only start the daemon if one is added
[14:51] <jbicha> attente: I believe the ibus engine whitelist was removed in 3.8 https://git.gnome.org/browse/gnome-control-center/commit/?id=c87d58
[14:51] <attente> because i guess we can avoid needing ibus-daemon if all we want to do is modify the list of engines used
[14:52] <sil2100> didrocks: when I'm creating a private library, should I provide a pkg-config file for it as well? Is it necessary or welcome?
[14:53] <sil2100> didrocks: and point me to where I can clean-up anything ;)
[14:53] <didrocks> sil2100: hum, you shouldn't need a .pc file
[14:53] <didrocks> sil2100: as it's private, nobody will need to link against it outside your project
[14:54] <sil2100> didrocks: since I saw the unity private bits have a .pc file exported ;p
[14:55] <sil2100> didrocks: ok then!
[14:55] <didrocks> sil2100: hum, I think it's for "private plugins"
[14:56] <didrocks> sil2100: you are cleaning unity-mir?
[15:03] <mlankhorst> hm
[15:03] <mlankhorst> some more digging.. best explanation seems to be that gnome-session is not actually starting anything
[15:15] <mlankhorst> heh
[15:15] <mlankhorst> gnome-session-check-accelerated-helper fails on arm..
[15:15] <mlankhorst> Laney: ^ feel like fixing panda some more? :X
[15:16] <Laney> me?
[15:17] <mlankhorst> if I replace gnome-session-check-accelerated-helper with /bin/true my tegra uses compiz correctly, I think panda will suffer from the same issue because it lacks libGL acceleration too, only EGL works..
[15:18] <mlankhorst> and if gnome-session-check-accelerated-helper fails, no unity gets spawned at all :/
[15:19] <jbicha> I didn't think anything used check-accelerated-helper any more
[15:21] <mlankhorst> well gnome-session uses it..
[15:24] <mlankhorst> check_gl() in main.c
[15:25] <mlankhorst>         if (gl_failed) {
[15:25] <mlankhorst>                 gsm_fail_whale_dialog_we_failed (FALSE, TRUE, NULL);
[15:25] <mlankhorst>                 gtk_main ();
[15:25] <mlankhorst>                 exit (1);
[15:25] <mlankhorst>         }
[15:30] <jbicha> oh and you don't have llvmpipe on arm, right?
[15:31] <desrt> seb128: accountsservice patches landing upstream today
[15:31] <mlankhorst> jbicha: there is acceleration, but it's handled through EGL
[15:31] <desrt> seb128: are there any other patches that we carry that we could drop for favour of using the new extensions framework?
[15:32] <seb128> desrt, great
[15:32] <desrt> stuff like background image, for example...
[15:32] <seb128> desrt, I guess so, background, keyboard layout, available messages
[15:32] <desrt> i agree with background and messages
[15:32] <seb128> 0011-add-background-file-support.patch
[15:32] <seb128> 0012-add-keyboard-layout-support.patch
[15:32] <seb128> 0013-add-has-message-support.patch
[15:32] <desrt> keyboard layout, i think stef has plans
[15:33] <seb128> ok, that works for me as well ;-)
[15:33] <desrt> is there anyone to do this work?
[15:33] <desrt> (i firmly believe that dropping patches it always worth the effort)
[15:34] <seb128> desrt, do you want to do it? otherwise I don't think anyone has spare cycle to rewrite stuff that work atm
[15:34] <desrt> i don't want to do it, no :p
[15:34] <desrt> let's let it sit until you update accountsservice again and watch the patches break :p
[15:34] <seb128> ok, I will keep on my "would be nice to get done" list and dispatch as appropriate
[15:34]  * didrocks sees an i386 package waiting for an hours being "starting in 1 minute" :/
[15:35] <didrocks> frustrating when waiting on this…
[15:35] <seb128> but that's likely to come after new ibus and g-s-d landing
[15:35] <Laney> private job land
[15:35] <didrocks> Laney: yeah, seeing that, would be great to have quotas :p
[15:35] <Laney> I blame chrisccoulson!
[15:35] <seb128> didrocks, yeah, all the builders are busy on private builds it seems
[15:36] <seb128> well one is not, but it's building openjdk
[15:38] <mlankhorst> anyway so I finally have my tegra working on saucy, then :P
[15:39] <Laney> I look forward to your patch
[15:39] <Laney> s/I look/upstream looks/? :-)
[15:41] <desrt> seb128: sounds like it'll be a while before the next release, in fact
[15:42] <mlankhorst> my fix is just commenting out that bullshit..
[15:42] <mlankhorst> I don't think upstream likes that
[15:42] <desrt> the vendor extension patches depend on an unstable glib, so they want to wait for the stable release before having a new accountsservice
[15:42] <seb128> oh ok
[15:42] <seb128> desrt, that makes sense
[15:43] <desrt> seb128: we have all of the good stuff vendor-patched in already anyway :p
[15:43] <seb128> yeah, the vendor stuff and the sane way to list users
[15:43] <seb128> so no really need of a new tarball atm
[15:43] <desrt> i'm trying to get the user heuristic stuff landed now
[15:44] <desrt> halfline says it looks good but doesn't have time to land it
[15:44] <desrt> but maybe soon
[15:44] <mlankhorst> is it really worth fixing this crap though? :S
[15:45] <desrt> mlankhorst: i think so... the work we're doing here is slated for inclusion in sssd, which we'll be using one day
[15:46] <desrt> and sssd is 'future' enough that we're going to be using accountsservice another year or two, i bet
[15:47] <mlankhorst> my 'fix' is #ifndef __arm__ do the check_gl stuff..
[15:47] <Laney> why don't you discuss why you think it's "crap" and "bullshit" with them?
[15:49] <mlankhorst> it's not as bad upstream because they have the fail whale at least :P
[15:51] <mlankhorst> but that one was harpooned in ubuntu
[16:02] <didrocks> grrr builders builders builders
[16:02] <didrocks> Laney: do we have any estimate on when chrisccoulson will stop annoying us? :p
[16:02] <didrocks> (is it an hour or multiple hours? ;))
[16:02] <chrisccoulson> it's not me
[16:02] <Laney> I can't see the builds :P
[16:02] <Laney> I just made a malicious guess
[16:02] <didrocks> chrisccoulson: private builds, it's you obviously!
[16:03] <sil2100> didrocks: just to be 100% sure, we can safely now switch to arch: any because of our nasty powerpc dodges? ;)
[16:03] <chrisccoulson> ;)
[16:03] <didrocks> sil2100: right right right :)
[16:03] <didrocks> chrisccoulson: we still like you, no need to lie! :)
[16:26] <sil2100> didrocks: hmmm, do you think this is correct? Tis my first time with a private library:
[16:27] <sil2100> https://code.launchpad.net/~sil2100/qtubuntu-sensors/lib_private/+merge/175331
[16:27] <sil2100> I hope I did the right thing to set RPATH for sensor plugin
[16:27] <didrocks> sil2100: ah, it's not unity-mir, I though it was that one :p
[16:27] <sil2100> didrocks: sooo, what should I clean up :) ?
[16:28] <didrocks> sil2100: hum, it the package building? as you didn't change the path
[16:28] <sil2100> It's building alright, as it uses local path
[16:28] <didrocks> sil2100: target.path is about RPATH?
[16:28] <kgunn> mlankhorst: ping
[16:29] <didrocks> sil2100: not sure what is using the RPATH in fact :)
[16:29] <sil2100> didrocks: so, I install now the lib in a private directory
[16:29] <didrocks> ah, there is only one package, hence why you didn't change any .install
[16:29] <sil2100> didrocks: sensors plugin when building, it uses -L../lib/, so during building it fetches the lib from the build dir
[16:29] <didrocks> sil2100: right
[16:30] <sil2100> didrocks: but then, later, so that it finds the lib, I used RPATH - not sure if that's correct?
[16:30] <didrocks> sil2100: sensors plugin are using qtubuntu-sensors?
[16:30] <didrocks> or they are part of the same package?
[16:30] <sil2100> didrocks: part of the same package
[16:31] <sil2100> didrocks: qtubuntu-sensors installs both the lib and the plugin
[16:31] <sil2100> didrocks: and the plugin uses the lib
[16:31] <didrocks> sil2100: ok, so that sounds good to me, but I would like to build the package to ensure :)
[16:31] <didrocks> sil2100: /usr/include/ubuntu-1/application/sensors/accelerometer.h:22:27: fatal error: ubuntu/status.h: Aucun fichier ou dossier de ce type
[16:31] <didrocks>  #include <ubuntu/status.h>
[16:31] <didrocks> and I cant' before of include ubuntu/ instead of ubuntu-1?
[16:31] <sil2100> didrocks: yeah, this is a problem with the platform-api I had
[16:31] <didrocks> (should this be versioned btw?
[16:31] <didrocks> )
[16:31] <didrocks> ah?
[16:32] <sil2100> didrocks: since hm, my platform-api packages install headers to ubuntu-1, while even the inners of platform-api headers reference ubuntu/ instead ;/
[16:32] <sil2100> I have to poke upstream about that
[16:32] <didrocks> sil2100: we should get that cleaned I guess
[16:32] <didrocks> sil2100: yes please :)
[16:32] <sil2100> Since something is clearly br0ken
[16:32] <didrocks> sil2100: otherwise, on principle, I +1
[16:32] <didrocks> but I want to build the package first :)
[16:40] <mlankhorst> kgunn: pong, but I'm gone soon and might not be tback till monday
[16:43] <kgunn> mlankhorst: robotfuel had logged a bug here https://bugs.launchpad.net/xmir/+bug/1201565, could you possibly help suggest to just get the info that RAOF would like...need a x expert:)
[16:43] <ubot2`> Ubuntu bug 1201565 in XMir "unity doesn't run in xmir session " [Critical,Triaged]
[16:43] <kgunn> we got the /var/logs/ & glxinfo....
[16:43] <mlankhorst> monday
[16:43] <kgunn> anything else you can think
[16:43] <mlankhorst> and just assign it to me for now so I won't forget
[16:44] <kgunn> ok....we'll try to make progress in the meantime
[16:44] <kgunn> mlankhorst: any suggestions....we can do the digging
[16:45] <kenvandine> has anyone looked at the packaging changes that blocked publishing of the SDK stack?
[16:45] <kenvandine> didrocks, sil2100: ^^
[16:45] <sil2100> kenvandine: stopp!
[16:45] <mlankhorst> oh fun race conditions..
[16:45] <sil2100> kenvandine: no publishing for now
[16:45] <kenvandine> that's what i was wondering :)
[16:46] <sil2100> kenvandine: we did not publish anything because SDK caused a small regression that broke gallery-app's AP test
[16:46] <mlankhorst> kgunn: well if it's a race condition I can't give any help without trying to reproduce it locally here..
[16:46] <kenvandine> ok, it's holding back media and friends
[16:46] <sil2100> kenvandine: so I'm holding it before Florian and his team fix it
[16:46] <kenvandine> but i think it's ok to publish those without sdk
[16:46] <sil2100> kenvandine: I know, it's in the works probably now
[16:47] <kgunn> mlankhorst: thanks
[16:47] <sil2100> I guess...
[16:47] <sil2100> Those don't use SDK, so indeed
[16:47] <kenvandine> friends-app does
[16:47] <sil2100> I meant, the new SDK ;p
[16:47]  * mlankhorst gone
[16:47] <kenvandine> but i need that published to fix a bug introduced by the SDK
[16:47] <kenvandine> yeah ;)
[16:48] <sil2100> kenvandine: maybe poke seb128 and didrocks about packaging changes and publish :)
[16:48] <sil2100> I tried to halt until all was known what's up and such
[16:48] <sil2100> didrocks: ^?
[16:48] <sil2100> didrocks: you think we should hold those stacks down?
[16:48] <didrocks> sil2100: we completely should
[16:48] <didrocks> sil2100: kenvandine doesn't need us to review, he has upload rights :p
[16:49] <sil2100> !
[16:49] <sil2100> :|
[16:49] <sil2100> ;)
[16:49] <kenvandine> i don't see anything in the sdk stack that would cause a problem with the current pending changes in the friends stack
[16:49] <kenvandine> it should be safe
[16:50] <kenvandine> i'm less confident with the media stack
[16:50] <kenvandine> i'll force publishing friends so we get the fix for the header issue
[16:56] <Laney> seb128: I'm thinking I might start looking at Time & Date, OK?
[17:02] <Laney> OK, let me know - I'll be back later/tomorrow
[17:02] <Laney> o/
[17:05] <didrocks> see you Laney
[17:08] <didrocks> FINALLY: https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+build/4802060
[17:25] <sil2100> didrocks: ok, deadline is nearing, and I'm currently blocked on the platform-api issue to have the task cleared, oh noes!
[17:25] <sil2100> ;(
[17:25] <didrocks> sil2100: well, you have other tasks like the cleaning new, and unity-mir, so not stuck ;)
[17:25] <sil2100> I will be beheaded!
[17:25] <didrocks> ahah
[17:25] <sil2100> I know, but I said it's a DEADline
[17:26] <didrocks> as long as you work on something else, no worry :)
[17:26] <sil2100> Let's gently move it to tomorrow, without anyone noticint!
[17:26] <sil2100> *noticing
[17:26] <didrocks> yep
[17:47]  * didrocks waves good evening
[18:01] <seb128> Laney, date&time: fine with me, check with larsu though, I think it's one of those that should re-use the menumodel from the indicator (though I'm not sure to understand how that works exactly/we still don't have example)
[18:02] <seb128> Laney, doing the UI in qml is simple enough that I'm not sure the model stuff is a win for the UI, it would be good to be able to trigger the actions this way tough
[20:16] <thomi> morning