[06:27] <pitti> Good morning
[07:29] <didrocks> morning
[07:32] <happyaron> didrocks: hey
[07:32] <happyaron> attente_: qt5 version is uploaded to archive
[07:34] <didrocks> hey happyaron
[07:53] <pitti> bonjour didrocks, c,a va /
[07:53] <pitti> eek, what happened to my compose key?
[07:53] <didrocks> pitti: ça peut aller, et toi ?
[07:54] <pitti> didrocks: je suis fatigue', comme tous le jeudi apre`s basketball
[07:54]  * pitti switches keyboard layout twice, and voilà - compose key !
[07:54] <pitti> didrocks: and I'm fighting some issues with the latest cloud-init
[07:56] <didrocks> pitti: oh, still following up from yesterday?
[07:57] <pitti> didrocks: yeah, I just filed a bug for and worked around broken ssh
[07:57] <pitti> didrocks: and I'm now looking at why rsyslog stopped working (systemd's tests fail on that)
[07:57] <pitti> (on the cloud images)
[07:58] <didrocks> urgh
[07:58] <didrocks> yeah, I imagine for cloud-init, rsyslog forwarding may be important :)
[08:00] <seb128> hey didrocks pitti
[08:00] <pitti> bonjour seb128
[08:00] <didrocks> hey seb128
[08:00] <pitti> go rsyslogd --  no manpage, no useful --help
[08:00] <pitti> oh sorry, it does have a manpage
[08:01] <pitti> open error 13, file '/var/log/syslog': Permission denied
[08:01] <pitti> ah-haa
[08:02] <pitti> that's fun, that should affect every new installation where /var/log/syslog doesn't already exist..
[08:02] <didrocks> the acl changes?
[08:02] <didrocks> oh?
[08:03] <pitti> hah, seb128 filed that as bug 1401984, and we added a tmpfiles.d for it ages ago
[08:05] <pitti> didrocks: no, the ACL is still there
[08:06] <didrocks> interesting
[08:06] <didrocks> pitti: btw, now, I'll use any opportunity to check if systemd-timesyncd is activated or not
[08:07] <didrocks> just to know if that random starts condition only happens in a vm or not
[08:07] <seb128> woot, a systemd upload where the changelog is not the usual 3 screens long summary of the ubuntu delta :-)
[08:07] <pitti> seb128: oh, it's usually just one screen :)
[08:07] <pitti> the other two are the changes in Debian :)
[08:07] <seb128> hehe
[08:08] <didrocks> pitti: it does try to start it on my system, and but as I already have /tmp as tmpfs, I didn't notice…
[08:08] <pitti> didrocks: yeah, same for me I guess; but timesyncd seems to start reliably here
[08:08] <didrocks> the condition failed is funny
[08:08] <didrocks>            ConditionFileIsExecutable=!/usr/sbin/ntpd was not met
[08:08] <didrocks> -rwxr-xr-x 1 root root 672624 févr.  9 19:12 /usr/sbin/ntpd
[08:09] <didrocks> pitti: I don't understand yet why it becames a RequiresBy=tmp.mount though
[08:10] <didrocks> waow, here, it's required even by more things than in the vm
[08:10] <didrocks> RequiredBy=colord.service systemd-timesyncd.service local-fs.target rtkit-daemon
[08:10] <didrocks> local-fs.target is because I guess it's in my fstab
[08:10] <didrocks> seb128: do you have /tmp on tmpfs?
[08:11] <seb128> didrocks, that would show in "mount" right?
[08:11] <seb128> I guess not
[08:12] <pitti> didrocks: oh, so if you have ntpd it should indeed *not* start
[08:12] <pitti> does it?
[08:12] <didrocks> seb128: yeah, it should. So systemctl status tmp.mount says it's not active? (and can you paste the RequiredBy line of systemctl show tmp.mount?)
[08:13] <didrocks> pitti: right
[08:13] <seb128> didrocks, inactive indeed
[08:13] <seb128> ● tmp.mount - Temporary Directory
[08:13] <seb128>    Loaded: loaded (/lib/systemd/system/tmp.mount; disabled; vendor preset: enabled)
[08:13] <seb128>    Active: inactive
[08:13] <seb128> RequiredBy=rtkit-daemon.service systemd-timesyncd.service colord.service
[08:14] <didrocks> so colord isn't running for you I guess
[08:14] <didrocks> neither rtkit-daemon
[08:14] <seb128> $ systemctl status colord
[08:14] <seb128> ● colord.service - Manage, Install and Generate Color Profiles
[08:14] <seb128>    Loaded: loaded (/lib/systemd/system/colord.service; static; vendor preset: enabled)
[08:14] <seb128>    Active: active (running) since mer. 2015-03-04 07:52:18 CET; 1 day 1h ago
[08:14] <didrocks> ok, I don't understand it seems :/
[08:14] <didrocks> pitti: any idea? ^
[08:15] <didrocks> 1. it's not an explicit Requirement
[08:15] <pitti> didrocks: no idea, sorry
[08:15] <didrocks> 2. it's listed as RequiredBy and the same layout starts sometimes tmp.mount in a vm (I was thinking via systemd-timesyncd.service)
[08:15] <didrocks> pitti: yeah, I smell something really fishy…
[08:16] <didrocks> I guess we'll keep the "fail on no disk space" this cycle anyway
[08:16] <didrocks> thanks seb128 :)
[08:16] <seb128> yw
[08:17] <pitti> didrocks: but timesyncd should never start in a  VM, btw (ConditionVirtualization=no); if you want to test it that way, drop that line
[08:18] <didrocks> pitti: it never starts, but it tries to activate (and show, brings the RequiredBy=) at some boot
[08:18] <didrocks> so basically, it's either "inactive" or "condition failed"
[08:18] <didrocks> in the second case, it started tmp.mount
[08:18] <didrocks> and tmp.mount shows it in RequiredBy= even if we don't see it in the unit file
[08:19] <didrocks> but in seb's case, it seems that even tmp.mount shows RequiredBy=colord.service (for also on unknown reason), having colord.service started didn't activate tmp.mount
[08:21] <didrocks> my only bet is that colord is started via something else
[08:21] <seb128> it's of type dbus
[08:21] <seb128> so it's maybe dbus activated?
[08:21] <seb128> does dbus activiate respects the requirements?
[08:22] <didrocks> I guess so
[08:22] <didrocks> and that would explain at least this unmatched dep
[08:22] <didrocks> no
[08:23] <didrocks> it doesn't respect, I guess systemd just see a process and say "oh, it's that unit"
[08:23] <didrocks> so mark it as running
[08:23] <didrocks> I still don't know why those appears in RequiredBy=, there is nothing explicit, particuarly for systemd-timesync
[08:24] <didrocks> (we could think of PrivateTmp=yes for colord would transition to tmp.mount)
[08:24] <seb128> didrocks, what appears in what requiredby?
[08:24] <didrocks> seb128: $ systemctl show tmp.mount | grep Required
[08:24] <didrocks> RequiredBy=colord.service systemd-timesyncd.service local-fs.target rtkit-daemon.service
[08:25] <didrocks> if you systemctl cat (or open) unit files, they don't have a Requires=tmp.mount
[08:25] <didrocks> if you grep in /lib/systemd/systemd/*service, no sign of tmp.mount being mentioned as a requirements in any unit
[08:39] <pitti> man, git bisect run is so awesome
[08:41] <larsu> ya. Feels like magic whenever I use it
[08:41] <larsu> morning pitti :)
[08:41] <pitti> hey larsu!
[08:42] <pitti> yeah; start it, let your computer burn and smoke, and enjoy a Piña Colada :)
[08:42] <pitti> or, in my case, work on NFS instead :)
[08:42] <seb128> is that different from bisect?
[08:42] <seb128> does it auto-flag good/bad and how?
[08:42] <pitti> seb128: it is a bisect, but in fully automatic mode
[08:42] <seb128> how do it determine the outcome?
[08:42] <pitti> seb128: you toss it a script, and looks at its exit code
[08:42] <seb128> k
[08:42] <pitti> 0 -> good, < 125 -> bad, 125 -> untestable (e. g. doesn't build)
[08:43] <pitti> > 128: abort
[08:43] <pitti> so as soon as you have an automatic test case you can let it run
[08:43] <pitti> seb128: I did that for the boot hang: my test case was to run an autopkgtest in QEMU with rebooting 30 times
[08:43] <larsu> ... and let it find your bug for you
[08:43] <pitti> so it went through ~ 1100 commits with that test case in about 2 hours
[08:44] <pitti> (now running it for the /var/log issue)
[08:44] <larsu> pitti: watch out, you're dangerously close to replacing yourself with a script
[08:44] <pitti> I wish I could -- one of these days I *actually* want a Piña Colada!
[08:44] <seb128> lol, I wonder if https://plus.google.com/u/1/+MathieuTrudelLapierre/posts/bFdphmbgAz8 is real :-)
[08:44] <seb128> pitti, nice!
[08:45] <pitti> cyphermox: ♥
[08:45] <ochosi> larsu: i vaguely recall you said you don't wanna work on that just yet, but i just patched a panel plugin for xfce to use symbolic icons, it's fairly easy and straightforward (if you'd be interested in doing that for indicators, i mean)
[08:45] <larsu> ochosi: ah cool. It's not that much work, is it?
[08:46] <larsu> ochosi: we'd need to merge ubuntu-mono-dark and -light first
[08:46] <larsu> which is something I've been looking at again yesterday when I added window decoration buttons for both
[08:46] <ochosi> larsu: this is pretty much it: http://git.xfce.org/panel-plugins/xfce4-pulseaudio-plugin/commit/?id=314286b6f7da37472dcc69adfe64b66c07d580ec
[08:46] <ochosi> and no, not necessarily
[08:46] <ochosi> just ship the symbolic variants in the parent theme
[08:47] <ochosi> the -dark variant will inherit automatically
[08:47] <larsu> ochosi: the parent theme for both is humanity iirc
[08:47] <larsu> hm, why do you preload icons?
[08:48] <ochosi> larsu: oh, that's just how that particular plugin was written
[08:48] <ochosi> i didn't want to change anything there apart from the icons
[08:48] <ochosi> it preloads all icons at once and then uses the appropriate one per volume
[08:48] <ochosi> not sure whether that's more efficient than loading what you need at the time
[08:49] <larsu> shouldn't make that big of a difference
[08:49] <ochosi> prolly not
[08:49] <larsu> icons are mmapped anyway
[08:49] <larsu> all you do is waste some memory
[08:49] <larsu> but it's not a lot, so whatevs
[08:49] <ochosi> yeah, it's fairly little
[08:50] <ochosi> so basically what i'd propose is start with indicator-sound as a testcase
[08:50] <ochosi> use the symbolic icons for the panel button and the menu icons
[08:51] <ochosi> (which will be nice because the icons will finally *always* be recolored correctly with all themes)
[08:51] <larsu> ochosi: indeed
[08:51] <larsu> but!
[08:51] <larsu> indicator-sound colors it's icon sometimes
[08:51] <ochosi> yeah
[08:51] <larsu> we'd need to add a css class in that case and add that to the theme
[08:51] <ochosi> symbolic icons obviously account for that
[08:51] <larsu> *themes
[08:51] <ochosi> nope
[08:51] <ochosi> well, at least not really
[08:52] <ochosi> as long as the symbolic icons have the error state, you should be fine by just setting that state
[08:52] <larsu> this only works for one state, though, and I'm not sure that e.g. Ambiance and Radiance use the same color there
[08:52] <larsu> or is that state colorable from the theme as well?
[08:53] <ochosi> it's "success_color", "warning_color", "error_color"
[08:54] <ochosi> https://developer.gnome.org/gtk3/stable/GtkIconTheme.html#gtk-icon-info-load-symbolic
[08:54] <ochosi> afaik that's all in the icon, nothing required in the theme
[08:56] <larsu> ochosi: ah, those *are* css styles
[08:56] <larsu> ans we already do style them
[08:56] <larsu> *and
[08:56] <ochosi> yeah, sry, but in fact you have to set a class within the icon
[08:57] <larsu> right
[08:57] <ochosi> so it's both, the theme sets the color and the icon has to have the class set on the paths that should be recolored
[08:57] <ochosi> so basically for the blocked stuff you just copy an existing symbolic icon and set the class of all paths to "warning"
[08:57] <larsu> so we'll still need to set the corresponding class on the gtkimage I guess
[08:58] <ochosi> not sure, no
[08:58] <larsu> how else would it know when to recolor?
[08:58] <ochosi> it automatically looks inside the svg and sees the class
[08:58] <ochosi> at least that's how i think it works
[08:58] <larsu> yeah but it needs to know _when_ to draw that part
[08:58] <ochosi> so you have "audio-volume-blocked-symbolic" or something
[08:59] <larsu> oh
[08:59] <larsu> so we'd need to change the icon then
[08:59] <larsu> ya, could do
[08:59] <ochosi> and that has the "warning" class set
[08:59] <ochosi> so all themes would color the icon accordingly
[08:59] <ochosi> so it's not about re-using existing icons, although that might be possible as well
[08:59] <ochosi> simply by adding a class
[08:59] <ochosi> and removing it conditionally from the style contexxt
[08:59] <larsu> yeah what you're describing makes more sense to me
[09:00] <ochosi> so the icons remain the same, i think the -blocked is already a separate icon
[09:00] <larsu> ochosi: this is early-next cycle work though - don't want to mess with that now
[09:00] <ochosi> yeah, sure
[09:00] <ochosi> if you wanna start the transition and need some help lemme know
[09:01] <ochosi> would be good to do that for all indicators
[09:01] <larsu> indeed, it would
[09:01] <larsu> ochosi: thanks! Will do
[09:01] <ochosi> okeydokey :)
[09:01] <larsu> thanks for pointing me towards this
[09:02] <ochosi> np, btw, you might want to talk to gnome upstream and see whether they see any reason to include a "blocked" icon in adwaita-icon-theme
[09:02] <ochosi> that way this would sort of become a standard
[09:02] <ochosi> (since nobody seems to care about the fd.o icon spec anymore these days and gnome is the defacto standard for icon-names)
[09:02] <ochosi> (nobody loves fd.o anymore :'( )
[09:04] <Laney> yo
[09:06] <larsu> ochosi: there's quite a lot of stuff hosted on fd.o and we've been adding new stuff to the specs
[09:06] <seb128> hey Laney
[09:06] <larsu> ochosi: icons is a bit failed...
[09:06] <larsu> morning Laney!
[09:06] <seb128> Laney, wants to update gtksourceview3 in debian/sync the update? ;-)
[09:07] <larsu> yes!
[09:07] <larsu> he wants!
[09:07] <seb128> that should fix bug https://bugs.launchpad.net/gedit/+bug/1428333
[09:07] <ochosi> larsu: yeah, i was specifically referring to that spec, not all of them are as outdated as the one for icons
[09:07] <seb128> well combined with https://git.gnome.org/browse/gedit/commit/?id=d48cd10bf0bb99ead7b1af1ead52f1e554ad239d
[09:08] <didrocks> morning Laney
[09:10] <Laney> hey seb128 didrocks larsu
[09:10] <Laney> umm yeah okay
[09:10] <seb128> danke
[09:10] <larsu> Laney: that commit depends on gtk 3.16, so please upload that as well
[09:10] <seb128> lol
[09:11]  * larsu <-- on troll day. Won't be here tomorrow
[09:11] <seb128> which depends on bluez5, so while you are at it...
[09:11] <larsu> HAHA
[09:11] <larsu> nice one
[09:11] <ochosi> larsu: btw, how did you fix the scale grabbing in indicator-sound?
[09:11] <seb128> :-)
[09:12] <seb128> larsu, want to review https://code.launchpad.net/~3v1n0/libdbusmenu/custom-stock-item-label/+merge/251840 ? it's a one liner
[09:12] <larsu> seb128: yes, a long time ago?!
[09:12] <seb128> larsu, what a long time ago?
[09:12] <larsu> seb128: oops, this was supposed to go to ochosi
[09:12] <seb128> larsu, was that for ochosi? he asked "how"
[09:13]  * larsu can't read, and can't type
[09:13] <ochosi> larsu: wait, but that happened during this cycle, no? i remember not being able to click the volume scale correctly
[09:14] <larsu> ochosi: it did. I think the issue was that something reset the volume while you were dragging it
[09:14] <seb128> larsu, ochosi, http://launchpadlibrarian.net/195548750/ido_13.10.0%2B15.04.20141103-0ubuntu1_13.10.0%2B15.04.20150122-0ubuntu1.diff.gz
[09:14] <seb128> that one?
[09:15] <ochosi> that looks like it could be it
[09:15] <seb128> https://code.launchpad.net/~larsu/ido/fix-volume-slider/+merge/247198
[09:15] <seb128> is the corresponding mr
[09:16] <larsu> indeed, thanks seb128
[09:16] <seb128> yw
[09:16] <ochosi> awesome, thanks seb128
[09:16] <seb128> yw
[09:16] <larsu> the volume resetting stuff was about the notification popping up
[09:16] <ochosi> so is that a change that is gtk3 version specific or anything?
[09:17] <ochosi> cause i remember it broke with gtk3.14 in the indicator
[09:18] <larsu> ochosi: yes. I remember not bothering to figure out the actual change that caused the issue, but there was quite some work done in gtk on event handling
[09:18] <larsu> all I did was not propagating events from the menu item to the scale in all cases
[09:19] <ochosi> yeah, i wonder whether that works on older gtk3 releases as well
[09:19] <larsu> ochosi: don't try?!
[09:20] <ochosi> heh
[09:20] <ochosi> well, tbh for the plugin that i linked earlier we copied the indicator's scale menu item
[09:20] <larsu> ochosi: port to popovers!
[09:21] <larsu> it's the future
[09:21] <ochosi> yeah, we haven't decided about those things yet
[09:21] <ochosi> basically that needs a global xfce decision
[09:21] <larsu> right, makes sense
[09:22] <ochosi> and we've only just released 4.12 last weekend
[09:22] <ochosi> so my work is more or less exploratory at this stage
[09:23] <larsu> seb128: the bug linked to this MR is WontFix by both tedg and mpt...
[09:24] <larsu> (the dbusmenu issue)
[09:24] <larsu> ochosi: yeah I saw. Congrats on 4.12 :)
[09:24] <larsu> seems people like it
[09:24] <seb128> larsu, feel free to reject the change
[09:25] <ochosi> larsu: hah, that is a very diplomatic statement "some ppl like it" :) i'm just happy we could finally move out of the stalling and now there's a clear goal (port to gtk3)
[09:26] <larsu> ochosi: I didn't say "some" ;)
[09:26] <ochosi> oh ooops :)
[09:26]  * ochosi wonders why/how he managed to misread that
[09:26] <larsu> I read some reviews and they were mostly positive
[09:26] <larsu> that's what I meant
[09:26] <larsu> haven't tried it myself yet
[09:27] <ochosi> yeah, no dramatic changes, which is generally an xfce policy
[09:27] <larsu> but yeah, I'm glad you guys are releasing again :)
[09:27] <ochosi> yeah, took a while and a lot of personal effort
[09:27] <larsu> oh, mpt reopened that bug...
[09:27] <larsu> man, such a non-issue
[09:27] <larsu> ochosi: I can imagine
[09:37] <ochosi> larsu: btw, i'm not sure you're interested in this sort of redesign, but i had an idea for indicator-sound that would rid you of the mute menuicon
[09:38] <ochosi> larsu: basically, only have a volume icon on the left (the one on the right is a bit superfluous really, i mean what's that scale gonna do? decrease the volume?) and make that a button instead of an icon which on click mutes
[09:38] <ochosi> larsu: well un/mutes obviously
[09:39] <Sweet5hark> moin
[09:39] <larsu> ochosi: both icons already do something (move the slider all the way in that direction)
[09:40] <larsu> ochosi: I personally dislike having mute separately from volume, but this is an issue to take up with mpt. He designed the sound menu
[09:40] <ochosi> larsu: oh right, i never even noticed that
[09:40] <larsu> ochosi: https://wiki.ubuntu.com/Sound
[09:40] <ochosi> guess some hover-effect on the icons would help users to notice that
[09:41] <Sweet5hark> ... feeling trollish today, I have to note that larsus Berlin and my home of Hamburg both moved up in the 2015 imercer quality of living ranking, kicking out Canadians and kiwis.
[09:41] <ochosi> larsu: so it's actually less of a departure from the current state, mostly adding a feature where clicking that icon again will restore the previously set volume...
[09:41] <larsu> ochosi: feel free to file a bug for i-sound and assign mpt (or the ux team)
[09:41] <larsu> yeah, that would be weird though
[09:42] <larsu> Sweet5hark: economist ranked toronto the most livable city
[09:42] <ochosi> not if there's only one icon
[09:42] <mpt> Don’t assign teams to bugs, real people don’t see them
[09:42] <larsu> Sweet5hark: and really, I trust those guys more :)
[09:42] <larsu> mpt: sorry. And hi!
[09:43] <mpt> Good morning :-)
[09:43] <ochosi> mpt: does that idea even make sense to you? i guess there's no use in writing something up when you already know that's not what you want
[09:44] <Sweet5hark> larsu: you should move to Hamburg then, economist ranks them first in Germany (Top 14 globally) followed by Frankfurst as next german city ;)
[09:45] <larsu> Sweet5hark: haha, you're funny.
[09:45] <larsu> :O
[09:45] <larsu> Sweet5hark: seriously though, I totally believe that Hamburg is more livable than Berlin
[09:45] <larsu> they look at all kinds of factors
[09:46] <Sweet5hark> larsu: this is why our rents and real estate prices are where yours are only slowly going to ...
[09:46] <larsu> Sweet5hark: actually, not so slowly these days...
[09:47] <larsu> Sweet5hark: but then, we have quite some catching up to do compared to HH
[09:47]  * larsu should visit there properly
[09:47] <larsu> never really been to the city
[09:47] <mpt> ochosi, sorry, I just read back 60 minutes but don’t see any bug or MR reference … What’s the idea?
[09:48] <larsu> mpt: remove mute in favor of the buttons next to the volume slider
[09:48] <ochosi> mpt: yeah, no MR/bugreport yet, i basically proposed dropping the mute menuitem, only using one sound icon to the left of the scale and using that as mute-button. adding a hover-style to that icon would help users see what it does
[09:58] <flexiondotorg_> The MATE team have found a bug in upower that affects mate-power-manager.
[09:58] <flexiondotorg_> Fedora has a simple patch that is confirmed as working.
[09:58] <flexiondotorg_> https://bugs.launchpad.net/ubuntu-mate/+bug/1428337
[09:58] <flexiondotorg_> Could someone take a peek?
[09:59] <larsu> flexiondotorg_: sure. Please add upower to the bug and link an upstream bug (create one if it doesn't exist)
[09:59] <flexiondotorg_> larsu, Thanks.
[10:00] <pitti> or rather, move it to upower, doesn't seem to be m-p-m's fault
[10:00] <pitti> flexiondotorg_: I'll have a look later and commit it upstream (but still debugging some stuff)
[10:04] <mpt> ochosi, larsu: This is going back far enough that I need to refer to what I wrote at the time to remember why I did stuff. <https://wiki.ubuntu.com/Sound#A.2BIBw-Mute.2BIB0-> says ‘The first item, “Mute”, makes it easy to urgently silence unwanted sound using a pointing device.’ Just the tiny button to the left of the slider wouldn’t be clickable nearly as quickly.
[10:05] <mpt> Especially (but not only) while bug 552920 remains unfixed.
[10:06] <flexiondotorg_> pitti Also affects gnome-power-manager
[10:07] <pitti> why?
[10:07] <pitti> is there another bug which needs to be fixed there?
[10:07] <pitti> looks like a crash in libupower-glib
[10:08] <larsu> mpt: there are no submenus involved there...
[10:08] <mpt> ochosi, larsu: The only reason the volume slider icons do *anything* when clicked is that I thought, “well if someone *did* click them, what would they be expecting to happen?” — not because I expected anyone to use them as the primary way of doing something.
[10:08] <flexiondotorg_> pitti, I am just linking to where that bug has been experienced.
[10:08] <mpt> larsu, eh? I didn’t mention submenus :-)
[10:09] <larsu> mpt: oh! I thought the bug you mentioned was about that, but it's about menut titles. Sorry
[10:09] <larsu> mpt: makes more sense now :)
[10:10] <larsu> mpt: I like https://wiki.ubuntu.com/Sound#Mute, which is basically what the left menu item now does
[10:10] <larsu> but I don't think it would be well received if we switched this now
[10:11] <larsu> especially since many laptops have a "mute" key with an led which is on while the sound is muted
[10:12] <mpt> Is that software-controllable?
[10:13] <mpt> For convergence!!!!1 I guess we’ll need to change one or the other eventually :-)
[10:13] <larsu> haha, indeed
[10:13] <larsu> I don't know, it's probably not controllable on all machines
[10:25] <ochosi> mpt: yeah, understandable, and i wouldn't propose this as a change for this cycle anyway
[10:27] <ochosi> mpt: and i guess i'd only have one icon but bump the size of that to 22 or 24px, so it's more easily clickable
[10:30] <mpt> ochosi, that would increase the height of the item as a whole, and I’m not a fan of menu items of slightly varying heights — it looks accidental
[10:31] <ochosi> what about the playback controls then? :]
[10:32] <mpt> Those (a) are massively different, not slightly, and (b) have borders around them clearly indicating their non-standard-ness :-)
[10:34] <ochosi> sure, makes sense
[10:41] <Laney> did anyone check the gnome-terminal wrapper?
[10:47] <ochosi> larsu: there is something wrong with your commit or the idoscalemenuitem still. if you try to hover the scale-button, it isn't drawn in hover style. however, if you hover approx 50px to the left of the scale-button it gets the hover-style applied
[10:47] <ochosi> noticed when porting your change to the plugin i'm working on
[10:48] <larsu> indeed :(
[10:48]  * larsu makes a note of fixing this
[10:49]  * Laney gets a keyboard layout debconf prompt on latest dist-upgrade
[10:49] <Laney> cccccccyyyyyphhhhhhhherrrrrrrmooooooooooooxxxxxxxxxxxxxxxxxxx
[10:51] <didrocks> Laney: opportunity for you to switch to a french layout!
[10:51] <Laney> I 'ate french!
[10:51] <didrocks> :p
[10:52] <larsu> Laney: don't be so 'ateful
[10:52]  * Laney fluffles all French #ubuntu-desktoppers
[10:53] <didrocks>  /msg seb128 when did we discuss last time we would lay off a non french person in the desktop team?
[10:53] <didrocks> oups ;)
[10:53]  * Laney looks at mlankhorst
[10:53] <didrocks> roh, he left, that doesn't count!
[10:54] <larsu> haha lol
[10:54]  * Laney slinks away :(
[10:54] <mlankhorst> you can still fire me :P
[10:54] <Laney> hey mlankhorst
[10:54] <Laney> do you have to move somewhere for intel?
[10:54] <mlankhorst> no, still working from home
[10:54] <Laney> nice, didn't know that they did this
[10:54] <mlankhorst> they only do it when you were already working on something related from home
[10:55] <didrocks> seems Laney is getting infos for his next job :p
[10:55] <mlankhorst> nothing wrong with that
[10:55] <Laney> heheh
[10:55] <didrocks> this is sad, even no willcooke for teasing!
[10:55] <Laney> when the cat is away
[10:56] <mlankhorst> http://thedailywtf.com/articles/Up-or-Out-Solving-the-IT-Turnover-Crisis :P
[10:56] <Laney> haha
[10:56] <Laney> I see what you're calling yourself
[10:57] <mlankhorst> naww but it's going to be hard to top Xmir, and X is on the way out :(
[10:58] <mlankhorst> I'm investigating on how to make GLES2 work on X in arm, it's harder than desktop :P
[11:00] <mlankhorst> afk a bit
[11:24] <didrocks> pitti: would you suggest to use ID_FS_TYPE to get a file system type (I don't use udev in the script, so I will just build a new udev_device_new_from_devnum for this), or is there any other way that is easier?
[11:24] <pitti> didrocks: if you don't use udev already, calling blkid might be easier
[11:25] <didrocks> ok, by directly getting the TYPE tag
[11:25] <pitti> $ blkid -s TYPE -o value /dev/sda3
[11:25]  * didrocks looks
[11:25] <pitti> btrfs
[11:25] <didrocks> thanks pitti :)
[11:31] <pitti> didrocks: ah, Lennart's recent answers clarify that quite a bit?
[11:31] <pitti> e. g. colord also has PrivateTmp=yes
[11:34] <didrocks> pitti: yeah, that was what I was infering here
[11:35] <didrocks> pitti: but so, if any of those runs, it means that users will have tmpfs by default on vivid
[11:35] <pitti> oh, what a disaster :)
[11:36] <didrocks> pitti: so, either was mask the unit by default, either we enable it for everyone, not feeling well to have different experience here in case of bugs, wdyt?
[11:37] <pitti> didrocks: can we discuss that in #d-systemd?
[11:37] <didrocks> sure
[12:17] <MacSlow> Trevinho, seb128: hey folks... have you perhaps seen a glitch with current vivid (desktop) like this yet: unity/compiz reacts sluggish once qmlscene is started to run a .qml file?
[12:18] <MacSlow> Trevinho, seb128: just wondering if it's just on my system or a general issue
[12:56] <Laney> blah
[12:56] <Laney> lost my compose key
[12:56] <Laney> now I can't type my gpg passphrase!
[13:07] <Laney> restarting u-s-d fixed it
[13:57] <Trevinho> mlankhorst: mh not saw that..
[13:57] <Trevinho> err... sorry, I meant MacSlow|lunch ^
[13:58] <Trevinho> MacSlow|lunch: nothing outside the qmlscene itself, which is something qt related
[13:59] <MacSlow|lunch> Trevinho, I'll still have to try it on my laptop (intel gfx) to have a comparison to my desktop (nvidia, binary blob driver), where I've seen this
[14:00] <MacSlow|lunch> Trevinho, unity's app-switcher was also affected... being very slow and sluggish to respond to a first invocation
[14:00] <Trevinho> mh
[14:00]  * Trevinho has no nvidia to check with
[14:00] <MacSlow> Trevinho, I'll get back to you after I tried it on my laptop
[14:01] <Trevinho> andyrock has one btw ^
[14:07] <MacSlow> Trevinho, andyrock: hm... no issues on my laptop (intel gfx)
[14:08] <cyphermox> seb128: pitti: yes, we can "Spock" our old five dollar bills by drawing hair and such on John A. Macdonald. Legal, but not very appreciated ;)
[14:09] <pitti> haha
[14:09] <cyphermox> pitti: btw thanks for fixing NM autopilot :)
[14:09] <pitti> cyphermox: it's autopkgtest, but you're welcome :)
[14:10] <cyphermox> uh, right
[14:46] <Laney> mardy: hi, are you planning to drop windows live (msn) messenger support from $uoa_component?
[15:05] <mardy> Laney: mmm... no, should I?
[15:06] <Laney> mardy: it's gone now
[15:06] <mardy> Laney: you mean that Live doesn't exist anymore?
[15:09] <Laney> There's some dodgy patch to use a not shut down server, but basically yes
[15:15] <Laney> http://ismsndeadyet.com/
[15:44]  * didrocks doesn't understand the open() behavior on an overlay fs
[15:45] <Laney> mardy: ↑ forgot to highlight you
[15:54] <desrt> didrocks: which overlay fs?
[15:54] <desrt> aufs? overlayfs? other?
[15:54] <desrt> it changes depending on the FS
[15:54] <didrocks> desrt: overlayfs
[15:54] <desrt> overlayfs is the weirdest one
[15:54] <didrocks> desrt: basically, I try to detect on which fs type a file is (for a systemd patch)
[15:54] <desrt> if you open() a file and there is nothing in the overlay then it will open() the file in the underlay
[15:54] <desrt> which is weird
[15:55] <didrocks> yeah, that's what I see
[15:55] <desrt> since if you then open() and trunc the file from another process, the person who opened it will still see the underlay file
[15:55] <desrt> they do it in the name of performance
[15:55] <desrt> since the 99% case is that there is no overlay file
[15:55] <didrocks> yeah, my issue is different and probably in the open options I'm using
[15:55] <mardy> Laney: thanks; I guess it's a matter or editing the rdepends of account-plugin-windows-live, and remove it as a dependency?
[15:55] <desrt> and keeping around all of those extra files the kernel (and constantly doing checks to see if the file has been created each time you access it) is very expensive
[15:56] <didrocks> desrt: for using blkid to get the fs type, I first need to have the device name, and so, I'm getting the devnum from the fd of that file (and so, I open() it)
[15:56] <desrt> hah.
[15:56] <didrocks> desrt: until I touch the file, open() works well
[15:56] <Laney> mardy: I don't know exactly what'd need changing, but yes I'm sure it's mostly deleting
[15:56] <didrocks> and I get the squashfs type on the live
[15:56] <desrt> st_dev is completely screwed up on overlays...
[15:56] <Laney> mardy: We'd also want to SRU this to 14.04 at least I think
[15:56] <didrocks> desrt: once I modify the file, open() returns an < 0 fd
[15:57] <desrt> eh?
[15:57] <desrt> you mean to say, it fails
[15:57] <desrt> presumably with some helpful hint in errno
[15:57] <didrocks> yeah
[15:57] <didrocks> ell
[15:57] <didrocks> well
[15:57] <didrocks> helpful being "No such file or directory"
[15:58] <desrt> are you using openat() on the dir or something?
[15:58] <didrocks> desrt: oh screw that, it's the probe failing
[15:58] <desrt> heh
[15:58] <didrocks> desrt: I was on the original script to check the error message
[15:58] <didrocks> so yeah, due to the bad st_dev
[15:58] <didrocks> hum…
[15:59] <didrocks> how can I know then I'm on an overlayfs system?
[15:59] <desrt> the 'usual tricks' go out the window here
[15:59] <desrt> ie: traversing the chain up and comparing st_dev at each point
[15:59] <desrt> i think the best mechanism it to consult /proc/mount
[15:59] <didrocks> urgh, ok :p
[16:00] <desrt> i'm planning to make similar changes in glib, fwiw...
[16:00] <desrt> overlays are kind shit for this reason
[16:00]  * desrt can't type today
[16:00] <didrocks> desrt: basically systemd got tricked because to check if a file is a mount point, it checks the file device block, then the dir device blocks
[16:00] <didrocks> and of course, they are different (as for dir, they are 0)
[16:00] <desrt> ya... that's what you're supposed to do
[16:00] <desrt> at least in the old world :)
[16:01] <desrt> now i think you'll just have to check /proc/mounts
[16:01] <didrocks> "nice" :)
[16:01] <desrt> this is sort of what led me to my recent work on the mount monitor code in glib
[16:02] <desrt> we have some serious pain coming in the next couple of years as overlays-in-containers get more popular
[16:02] <desrt> and there is still a lot of work to do there
[16:02] <didrocks> right, I bet this is not the only "exception" due to overlays
[16:03] <desrt> anyway... i hope you're enjoying yourself :)
[16:03] <didrocks> desrt: totally, it's yet-another-supposively-10-minutes-hack-which-won't-be-one :)
[16:04] <desrt> heh.  welcome to my life :p
[16:04] <desrt> nothing can ever be easy -- otherwise someone else would have done it by now :p
[16:04] <didrocks> pitti: FYI btw, (context: bug #1411140) ^
[16:04] <didrocks> desrt: heh, yeah, I see. Didn't I tell you I prefer using glib than having to code at the same low level without it? :)
[16:05] <pitti> glib! glib! glib!
[16:05] <desrt> didrocks: i'm afraid today's glib won't help you a lot here
[16:05] <desrt> well, the mount monitor stuff would help, i guess
[16:05] <didrocks> desrt: yeah, in that particular case, agreed :)
[16:05] <desrt> since it provides a nice wrapping around /proc/mounts
[16:05] <desrt> but this isn't saving you the 'hard work' really
[16:05] <desrt> also: it's not very efficient today
[16:05] <didrocks> oh, like with separators or structured?
[16:06] <desrt> https://developer.gnome.org/gio/stable/gio-Unix-Mounts.html
[16:06] <desrt> _get_mount_path() _get_device_path() _get_fs_type() etc
[16:07] <desrt> all it really saves you, though, is the parsing
[16:07] <desrt> which is not difficult to do
[16:07] <desrt> this is meant more as an abstraction layer to help on platforms that don't have /proc/mounts
[16:07] <desrt> macos has some weird syscalls for that info, for example
[16:08] <desrt> there is no efficient mechanism for doing a lookup, as an example.  that's something i want to add.
[16:08] <didrocks> interesting, yeah, lookup part would avoid looping over manually
[16:08] <didrocks> anyway, no glib for me :p
[16:08] <didrocks> only my eyes to cry
[16:09] <desrt> :)
[16:09] <didrocks> (<-- insert sad violon music here)
[16:09]  * desrt isn't sure what he'd do without didrocks around to provide a constant injection of sadness
[16:09] <didrocks> rohhh :)
[16:10] <desrt> no.  it's good :)
[16:10] <desrt> gotta have balance, you know
[16:10] <didrocks> ahah
[16:11] <desrt> anyway... all of this chatting has reminded me that i was going to solve a bug for you
[16:11] <desrt> and i should get back to that
[16:11] <desrt> but, as with all things, ... it won't be easy :p
[16:12] <desrt> (the race between installing a new desktop file and file monitors being slow)
[16:12] <didrocks> desrt: well, no urgency yet, I have the workaround :)
[16:12] <didrocks> desrt: but would be nice to get it right, indeed!
[16:13] <didrocks> did you find any clever idea on it?
[16:13] <desrt> didrocks: i dreamed up an elaborate system for solving this problem
[16:13] <didrocks> "elaborate" ;)
[16:13] <didrocks> and "system"
[16:13] <didrocks> so 10 minutes hack? :)
[16:13] <desrt> hah
[16:13] <desrt> i gotta land this massive filemonitor branch first
[16:13] <desrt> then it will be a "10 minute hack" ;)
[16:14] <desrt> basically, providing a mechanism for file monitors to reach into the backend and say "run your queue RIGHT NOW"
[16:14] <desrt> and then check if any events are pending on themselves
[16:14] <didrocks> oh, so this will just flush the queue
[16:14] <desrt> well
[16:14] <didrocks> not afraid of massive things being queued at that moment?
[16:14] <desrt> it will poll the kernel too
[16:15] <desrt> which is part of my concern.....
[16:15] <didrocks> yeah, I see :/
[16:15] <desrt> the way desktop directories work, this could be annoying
[16:15] <Sweet5hark> Your build system is doing madness, should you a/ fix one problem and hope it does sane things elsewhere b/not use a build system everyone know to be brittle, whose only feature is fixing portability issues with 1990ies unixes, which your software doesnt run on and never will? Discuss: https://harald.hoyer.xyz/2015/03/05/libtool-getting-rid-of-180000-sed-forks/
[16:15] <desrt> since we have a file monitor at each level -- ~/.local/share, /usr/local/share, /usr/share, the config dirs, any extra XDG_DATA_DIRS, etc.
[16:15] <desrt> so that would be like 6 poll() calls maybe
[16:15] <didrocks> yeah, it can be expensive polling
[16:16] <desrt> well, the call would be really really fast, i'm sure
[16:16] <desrt> but it's still 6 syscalls, 5 of which are pointless
[16:16] <didrocks> indeed
[16:16] <desrt> so figuring out some way to consolidate that .....
[16:16] <didrocks> at least, happy that I gave you a challenging use case!
[16:16] <desrt> it also interacts badly with the case where the dir is not created yet
[16:17] <desrt> :)
[16:17] <desrt> this stuff will be generally useful eventually
[16:17] <desrt> will be nice to be able to query file monitors for this info in the generic sense
[16:17] <desrt> like for the /proc/mounts monitor... would be really useful to know if a change event was pending or not
[16:18] <didrocks> right, so it can be quite generically reused that way
[16:39] <andyrock> MacSlow, Trevinho sorry I was at class
[16:39] <andyrock> do you still need my help?
[16:39] <MacSlow> andyrock, np
[16:39] <MacSlow> andyrock, well I just wanted to ask for your folks view on an issue I'm seeing here...
[16:40] <andyrock> sure I can reproduce it?
[16:40] <andyrock> *how
[16:40] <MacSlow> andyrock, from the looks of it, it's only restricted to nvidia (binary-blob) based ssystems...
[16:40] <andyrock> i got one
[16:40] <andyrock> MacSlow, ^^^
[16:41] <MacSlow> andyrock, when ever I start qmlscene on the desktop to view a .qml file... QtCreator no longer updates window-contents and the compiz/unity app-switcher gets really sluggish
[16:41] <MacSlow> andyrock, I'm on vivid with the latest updates pulled (yesterday evening)
[16:41] <MacSlow> andyrock, this issue does not happen on my all-intel laptop
[16:41] <andyrock> MacSlow, mmm you started getting it with last update?
[16:42] <MacSlow> andyrock, I can't easily test it against the nouveau-driver right now
[16:42] <MacSlow> andyrock, yeah... I recognized this late yesterday
[16:42] <andyrock> MacSlow, also can you pastebine a .qml file so I can test it?
[16:42] <andyrock> or a normal one is just fine?
[16:42] <MacSlow> andyrock, any one will do
[16:45] <andyrock> MacSlow, we pushed a fix for compiz yesterday
[16:45] <Laney> larsu: yo, someone just pointed out out that GTK_MESSAGE_OTHER GtkMessageDialogs have an image-missing icon on Ubuntu
[16:45] <Laney> http://paste.ubuntu.com/10541027/
[16:45] <Laney> doesn't happen with vanilla gtk
[16:45] <Laney> do you think it could be caused by the 'restore traditional look' patch?
[16:47] <MacSlow> andyrock, http://pastebin.ubuntu.com/10541037/ is a qml that will certainly trigger it
[16:47] <MacSlow> andyrock, it seems it's related to constant animations going on
[16:48] <MacSlow> andyrock, wait... you need the png that goes with it...
[16:49] <MacSlow> andyrock, http://macslow.org/foreground-particle.png http://macslow.org/background-particle.png
[17:06] <andyrock> MacSlow, i cannot reproduce it here
[17:06] <andyrock> would be helpful if you can try to downgrade compiz
[17:08] <MacSlow> andyrock, so my compiz is at 1:<IP_ADDRESS>+15.04.20150303-0ubuntu1 right now
[17:08] <andyrock> MacSlow, same here
[17:09] <MacSlow> andyrock, so to what version do I need to get back?
[17:09] <andyrock> MacSlow, just one before
[17:10] <MacSlow> andyrock, 1:<IP_ADDRESS>+15.04.20150227-0ubuntu1 I assume then
[17:10] <andyrock> yep
[17:10] <andyrock> MacSlow, assuemd that you had regalluary updated your system
[17:12] <MacSlow> andyrock, I seem to still have 1:<IP_ADDRESS>+15.04.20150213-0ubuntu1 1:<IP_ADDRESS>+15.04.20150227-0ubuntu1 1:<IP_ADDRESS>+15.04.20150303-0ubuntu1 in my /var/cache/apt/archives
[17:12] <andyrock> try one by one if you can
[17:13] <andyrock> yesterday we pushed a small fix that solved the black window nvidia issue
[17:13] <andyrock> but should not be releated
[17:13] <andyrock> but we got also another big fix for nvidia in the last few weeks
[17:14] <MacSlow> andyrock, just the compiz-package should be enough right?
[17:15] <andyrock> MacSlow, yep
[17:15] <andyrock> MacSlow, it should include compiz-plugins
[17:15] <andyrock> Trevinho, ^^^
[17:15] <andyrock> can you confirm?
[17:19] <MacSlow> andyrock, hm... seems with compiz-plugins compiz-core and libdecoration I need to downgrade too...
[17:20]  * MacSlow wonders how much he fucked up his system by now
[17:20] <andyrock> MacSlow, usually it easier to just build your own compiz :D
[17:21] <MacSlow> well I'm lazy at my eod :)
[17:21]  * MacSlow restarts...
[17:24] <kaea> As a single user, how can I alter my username in a clean way (where is all places my user is connected to) or am I better off to just create a new user and give same permissions? (if so how do I know my current permissions etc)
[17:26] <Laney> larsu: http://paste.ubuntu.com/10541369/ ?
[17:29] <didrocks> eod -> see you guys!
[19:53] <achiang> are unity webapps still a thing? more specifically, there's a webpage i like that plays music; would love to be able to control it from sound indicator.
[20:07] <dobey> achiang: they're sort of a thing. i don't know if unity8 has sound indicator integration though
[20:07] <dobey> but should work under unity7 still afaik
[20:10] <Laney> just tried lastfm and got an aptd crash when I asked for the webapp to be installed. :D
[20:16] <dobey> nice
[20:16] <Laney> can't report it because glib is out of date
[20:16]  * Laney gets a trace manually
[20:17] <Laney> Traceback (most recent call last):
[20:17] <Laney>   File "/usr/lib/python3/dist-packages/aptdaemon/pkcompat.py", line 589, in _remove_from_connection_no_raise
[20:17] <Laney>     self.pktrans.Destroy()
[20:17] <Laney> AttributeError: 'NoneType' object has no attribute 'Destroy'
[20:18] <Laney> helpful


[20:09] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: xfce4-session 4.15.1 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-xfce4-session-4-15-1-released-tp59565.html (by Simon Steinbeiss)