[03:36] <hyperair> say, if i'm booting with pid1=systemd, is the user-init supposed to be systemd or upstart?
[03:37] <hyperair> right now i see systemd --user run as the lightdm user, but upstart --user run as me
[03:37] <hyperair> O_o
[07:23] <didrocks> morning
[07:25] <pitti> seb128, didrocks, Laney: btw, I just found "systemd-inhibit" -> much nicer than the gdbus call that we talked about a few weeks ago
[07:26] <didrocks> pitti: oh, great tip!
[07:32] <seb128> good morning desktopers
[07:32] <seb128> hey didrocks Laney pitti
[07:34] <didrocks> hey seb128 ;)
[07:37] <mlankhorst> morning
[09:03] <Laney> howdy
[09:05] <didrocks> hey Laney
[09:07] <Laney> pitti: neat find!
[09:08] <didrocks> Laney: does this ring a bell to you: /usr/bin/ld.bfd.real:.libs/libbluetooth.ver:2: syntax error in VERSION script
[09:08] <didrocks> ?
[09:08] <didrocks> (just in case, poking ;))
[09:09] <Laney> nope, haven't seen that before, sorry
[09:09] <didrocks> no worry :)
[09:09] <Laney> probably need to find out about VERSION scripts now :P
[09:09] <didrocks> yeah, I'm not seeing any though, so I need to check in the deps
[09:10] <Laney> what's .libs/libbluetooth.ver?
[09:10] <didrocks> I guess the libbluetooth from gnome-bluetooth (or the bluetooth panel)
[09:11] <didrocks> anyway, I'll check, but having the u-c-c fork is really making it difficult to remerge some stuff from upstream
[09:12] <Laney> I argued at the time for having it as a git fork of g-c-c, but lost :)
[09:13] <didrocks> yeah, not sure if I won't let that update to someone else TBH :p
[09:17] <seb128> hey Laney
[09:18] <seb128> didrocks, isn't robert_ancell working on that? he added a workitem to the blueprint?
[09:19] <seb128> Laney, the issue with backporting is not the vcs is use, it's the number of changes that went into the panels since our version
[09:19] <seb128> in use*
[09:19] <didrocks> seb128: well, he answered by email "nobody is doing it"
[09:19] <seb128> didrocks, when?
[09:19] <didrocks> just added a WI, but not sure he'll jump on it
[09:19] <didrocks> seb128: this night
[09:20] <seb128> oh, right, he didn't put his name on the wi on the blueprint
[09:20] <seb128> so probably don't count on it ;-)
[09:20] <didrocks> seb128: yeah, the g-c-c change was easy
[09:20] <Laney> speak for yourself, I find cherry-picking to be way easier than manual bending of patches
[09:20] <didrocks> just dropping patches
[09:20] <seb128> dropping a revert?
[09:20] <didrocks> yeah, 3 of them actually
[09:21] <seb128> k, makes sense
[09:21] <didrocks> but u-c-c doesn't work that well
[09:21] <didrocks> well, let's see if he's on that, I just spent 30 minutes just in case it was quick
[09:21] <seb128> Laney, I'm not saying that cherry picking is not nice, but the code is so different there is only so much you can effectively cherrypick
[09:22] <seb128> if you try to cherry pick a commit that apply to a source that doesn't even exist in your tree I fail to see how cherrypick makes your job easier
[09:22] <Laney> we would have updated more things if it were easier
[09:22] <Laney> definitely
[09:23] <didrocks> seb128: oh, actually: https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1401362
[09:23] <didrocks> so maybe he's looking at it
[09:23] <Laney> nice ;-)
[09:23] <seb128> Laney, I disagree with that, the reason we didn't update is mostly because we wanted to stay away from the UI redesigns upstream did
[09:23] <seb128> that's the reason we did our version to start with
[09:24] <seb128> didrocks, cool :-)
[09:25] <tammy> willcooke, ping, did you see my email?
[09:25] <Laney> that's why it's a fork
[09:25] <seb128> right, so don't blame the diff on the vcs used
[09:26] <seb128> tammy, he's off sick
[09:26] <Laney> what?
[09:26] <tammy> seb128, oh! thank you :)
[09:26] <Laney> I am maintaining my point which is that we would have had the choice to take things but it is much more difficult to do that now so we just don't do it in reality
[09:27] <seb128> I disagree with that
[09:27] <Laney> we find bugs and take fixes then but nothing proactive happens
[09:27] <Laney> fine
[09:27] <seb128> I did update some panels previous cycle
[09:27] <seb128> and the vcs is not an issue/what stopped me to backport more stuff
[09:27] <Laney> It stops *me*
[09:27] <seb128> it's the fact that the new code refactor UIs and we don't want those
[09:27] <Laney> The same issue applies for u-s-d
[09:28] <seb128> k, you want to be religious on vcs fine
[09:28] <seb128> but it doesn't stop others in the team
[09:28] <seb128> so I don't think you can blame things not happening on the vcs choice
[09:28] <Laney> it's not a religious argument
[09:29] <seb128> not but it's a lame argument "I would work on it if I had it my way, but since you guys prefer working that way I just don't give a damn"
[09:29] <Laney> great, yes, that's what I said, thanks
[09:30] <seb128> yw
[09:31] <seb128> thanks for throwing the argument in our faces
[09:31] <Laney> dude
[09:31] <seb128> yeah, I'm really annoyed
[09:31] <didrocks> waow, session crash…
[09:32] <seb128> if we were using a git version of u-c-c we wouldn't be in any different situation in regard of bluez5
[09:32] <seb128> not even sure what that had to do with the discussion
[09:34] <Laney> I don't really know how to carry on without inflaming more
[09:35] <seb128> yeah, you should perhaps have thought about that before throwing the "if you guys didn't do stupid vcs choices we would be in a better situation"
[09:35] <seb128> anyway, let's move on
[09:50] <mlankhorst> willcooke: get well soon
[09:57] <Laney> hey ;-)
[09:58] <didrocks> good morning Laney :)
[09:59] <Laney> the skies are actually clear and blue today, quite nice
[09:59]  * didrocks used Men In Black device on both dudes
[09:59] <Laney> bet it's cold out there
[09:59] <didrocks> getting warmer here, but really cloudy
[10:00] <Laney> http://www.bbc.co.uk/weather/2641170
[10:00] <Laney> uh oh
[10:05] <Laney> heeeeeeey larsu, so I'm just pulling your patches for gtk - is unity going to need a fix too for the dash?
[10:06] <seb128> oh, speaking about unity, the launcher loosing the firefox/tb icons with the new gtk (having them replaced by a "?") is that a bamf issue?
[10:06] <seb128> did anyone talked to Trevinho yet about that?
[10:08] <Laney> e.g. nautilus has a big icon still & I guess there will be random others even if we fix the cases we find
[10:09] <larsu> Laney: yes :/
[10:09] <larsu> Laney: I'm almost ready with an update for those patches, too. But I guess we can just update the package again
[10:09] <Laney> shrug, just going to put it in the PPA right now
[10:10] <larsu> ok. Im busy breakfasting and making tea anyway
[10:10] <larsu> :P
[10:10] <larsu> thanks!
[10:10] <Laney> if you update for their approach that's better I suppose
[10:11] <larsu> I see their point
[10:11] <larsu> but they bring it across weirdly
[10:11] <larsu> "it's better to have obvious bugs than subtle ones"
[10:12] <larsu> imo, if the bug is subtle enough that nobody notices, it's not a bug
[10:14] <Laney> guess he really hates scaled icons :P
[10:14] <Laney> "miserable" made me laugh
[10:15] <larsu> ya
[10:15] <larsu> I'll fix it by choosing the smallest non-scaled icon (if it exists)
[10:15] <larsu> we might still end up with icons that don't quite fit the text or inconsistently sized icons
[10:15] <larsu> but at least menu items will always be the same height
[10:16] <larsu> and we'll never have screen-filling menu items
[10:20] <didrocks> larsu: challenging design?
[10:20] <didrocks> :)
[10:23] <larsu> didrocks: ya :)
[10:58] <didrocks> tseliot: hey, IIRC, you worked on plymouth, right?
[11:02] <tseliot> didrocks: yep
[11:05] <didrocks> tseliot: I'm trying to experiment the fsck progress with systemd. I have issue to be able to run it under my X11 tty
[11:05] <didrocks> tseliot: I just tried sudo plymouthd --no-daemon --tty=`tty` --debug
[11:05] <didrocks> after installing the plymouth-x11 package
[11:06] <didrocks> and most of the time, it exits successfully, returning 0
[11:06] <didrocks> no debug info that can give a clue
[11:06] <didrocks> does it ring a bell to you?
[11:07] <didrocks> (I have no other plymouthd process running)
[11:08] <didrocks> some other time, the process stays, but any command like plymouth quit or plymouth ping, plymouth --show-spash does nothing…
[11:08] <didrocks> splash*
[11:11] <tseliot> didrocks: it can hang from time to time, so you'll have to kill the process
[11:12] <tseliot> didrocks: halfline in #plymouth can probably help you debugging that
[11:12] <tseliot> (he's upstream)
[11:12] <didrocks> tseliot: great! I'll move the discussion there then, thanks :)
[11:13] <tseliot> np
[11:31] <Sweet5hark> moin
[11:31] <xnox> didrocks: we have an excellent page on plymouth on wiki.ubuntu.com which tells how to do stuff.
[11:32] <xnox> didrocks: it does work in x11 mode last tiem i've checked.
[11:32] <xnox> didrocks: also, our upstart-mountall-plymouth integration uses an extension to plymouth protocol to transmit fsck progress updates.
[11:32] <xnox> didrocks: systemd-fsck should learn to do the same, but at the time I didn't have time to figure that one out.
[11:33] <xnox> https://wiki.ubuntu.com/Plymouth#Running_Plymouth_.22post-boot.22
[11:33] <xnox> unless plymouth is completely broken under systemd/logind/new-upstream/something else
[11:39] <didrocks> xnox: I read about that page ;)
[11:39] <xnox> didrocks: ;-) ok
[11:39] <didrocks> xnox: but yeah, that's the issue, most of the time, the plymouthd daemon returned
[11:39] <didrocks> xnox: I have a good grasp on systemd-fsck now
[11:39] <xnox> didrocks: it usually works for me, but i'm on dual-screen so don't know.
[11:40] <didrocks> xnox: not sure if that comes into play, but well, I have it shown at this boot :)
[11:50] <Trevinho> seb128: might be something like that, but strange that firefox is affected
[12:17] <didrocks> xnox: tseliot: are we only supporting in the ubuntu logo theme "fsck:*" updates? like no other update as: plymouth --update foo
[12:17] <xnox> didrocks: correct. in ubuntu-logo and the text themes.
[12:18] <xnox> didrocks: so there is fsck progress on serial/text plymouth mode - e.g. reboot with forcefsck and hit ESC to see the text updates as well.
[12:19] <xnox> didrocks: we do not support plymouth "update" aka windows package upgrade in progress mode, nor messages / progress / etc for that mode.
[12:19] <didrocks> xnox: ok, systemd does it differently for the text mode (as we display the /dev/console messages)
[12:19] <didrocks> it's just forwarding the fsck progress there
[12:21] <didrocks> xnox: ubuntu-text is when we press escape? (or when we install like an nvidia card)
[12:21] <xnox> didrocks: let me check... cause there is a text one which we do not use at all.
[12:21] <didrocks> seems to be the later
[12:22] <didrocks> however, I don't see the fsck implementation as ubuntu-logo there
[12:28] <xnox> didrocks: ubuntu-logo theme & details plugin have mountall's fsck support.
[12:30] <didrocks> xnox: so, we don't use the ubuntu-text one?
[12:30] <didrocks> or it's just that if you have a nvidia card (or in virtualbox for instance), you don't have fsck support?
[12:31] <xnox> didrocks: one can use it, it just has no fsck progress output.
[12:31] <didrocks> xnox: yeah, so, I understood it right, thanks!
[12:32] <didrocks> xnox: also, the details plugin don't have the same logic than for ubuntu-logo
[12:32] <xnox> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/660151 <- if you feel like implementing =)
[12:32]  * didrocks wonders if we shouldn't fix all this having the same logic
[12:32] <xnox> didrocks: correct details plugin is more functional output, that is which mountpoint and which progress % it is.
[12:32] <didrocks> yeah
[12:33] <didrocks> so, it means, we'll have it in double
[12:33] <xnox> didrocks: i find the stock logic to be useless but "UX-user friendly"
[12:33] <didrocks> like /dev/console
[12:33] <didrocks> and this one
[12:33] <didrocks> xnox: the details plugin shows /dev/console output, right?
[12:33] <xnox> didrocks: "fsck 3 out of 7 disks 34% done; C cancel?"
[12:34] <didrocks> xnox: no, I just meant the /dev/console content, as plymouth ownes it
[12:34] <xnox> didrocks: kind of yes. plymouth steals /dev/console and the details plugin is printed there. Thus with Esc button one can switch between ubuntu-logo <-> details plugin.
[12:34] <didrocks> yeah
[12:34] <didrocks> so, we already have progress with systemd thanks to that
[12:35] <didrocks> (details progress, as all fsck -C are forwarded there)
[12:35] <xnox> ah cool.
[12:36] <xnox> patching systemd-fsck to send fsck messages to playmouth "mountall-style" would be useful, and then drop the fsck handling in the details plugin.
[12:36] <didrocks> xnox: that or having the fsckd daemon to get that upstream
[12:36] <xnox> most themes don't process those at all.
[12:36] <xnox> didrocks: good luck.
[12:37] <didrocks> xnox: they did that proposal actually :)
[12:37] <xnox> as far as i can tell none of that ever landed anywhere... =(
[12:37] <xnox> well, i'm out of date then.
[12:37] <didrocks> they don't want plymouth doing the logic
[12:37] <didrocks> they would prefer that we just send one update with a string
[12:37] <didrocks> and having fsckd doing that (this fsckd would be part of systemd)
[13:57] <tseliot> didrocks: yes, what xnox said
[14:22] <Laney> attente_: hey, do you know if anyone has checked the mir backend on gtk 3.14.5?
[14:22] <Laney> getting some build errors here
[14:23] <Laney> using the patch that was in bzr, this is
[14:31]  * desrt yawns
[14:32] <desrt> Laney: good morning :)
[14:32] <Laney> hey desrt
[14:32] <Laney> how's .ca?
[14:33] <desrt> it's snowing right now
[14:33] <desrt> which is potentially problematic, because they're currently replacing brickwork on our building
[14:34] <desrt> i get the impression that this is the sort of thing that you don't do while it's snowing
[14:34] <desrt> Laney: getting properly settled in?
[14:35] <Laney> maybe you'll have a free winter wonderland indoors
[14:36] <Laney> ya
[14:36] <Laney> some guys are here doing some work atm
[14:36] <desrt> did you score a dedicated office?
[14:37] <Laney> oh yes that was one of the requirements
[14:37] <Laney> had that in the previous place too
[14:37] <desrt> :)
[14:37] <desrt> standing desk time
[14:37] <Laney> this is larger though
[14:37] <Laney> there's a big void behind me
[14:37] <Laney> maybe a sofa?
[14:38] <desrt> nah.  pinball machine.
[14:38] <Laney> oh man
[14:48] <larsu> morning desrt :)
[14:49] <desrt> hihi
[14:49] <larsu> see the bug about g_menu_popup()?
[14:49] <larsu> ignore the name, of course. But nice concept.
[14:53] <desrt> no.  i didn't.
[14:55] <larsu> also, mclasen and hergertme are adding action group api
[14:55] <larsu> I think we might want to deliver on the description at some point...
[14:56] <larsu> I think they want to make get_muxer() public
[14:56] <larsu> (as an action group, of course)
[15:03] <desrt> scary
[15:04] <desrt> actiongroup is actually a shit api for the muxer
[15:04] <desrt> because of the signal scaling issue
[15:04] <desrt> that's why the observer interface was invented
[15:04] <desrt> worth noting that the newly added support for signal connection reporting could solve approximately half of that problem...
[15:08] <larsu> because we don't need to watch when noone is listening?
[18:00] <Laney> time to go out on bike in http://www.raintoday.co.uk/ and (a) give blood (b) mop floors at old house
[18:01] <Laney> joy ;-)
[18:01] <Laney> ttyl
[20:40] <darkxst> Sarvatt, anychance you can take a look at my patch bug 1392954
[21:11] <ricotz> darkxst, hi, better use tabs as in the original source
[21:33] <darkxst> ricotz, hi thanks, fixed