[01:32] <robert_ancell> furkan, short answer - if the patch is good then yes
[01:33] <robert_ancell> furkan, does the upstream nautilus have the issue or is it in the removed code you talked about? If it does affect upstream it's better to get it accepted there first then bring the change back as a patch for Ubuntu.
[01:34] <robert_ancell> furkan, the full policy for getting changes into 14.04 is https://wiki.ubuntu.com/StableReleaseUpdates. This sort of change would fall under "Bugs which do not fit under above categories, but (1) have an obviously safe patch"
[01:39] <furkan> robert_ancell: great, thanks
[01:39] <furkan> robert_ancell: i found a series of upstream patches in nautilus which remove nautilus' wallpaper-drawing functionality
[01:40] <robert_ancell> furkan, yeah, they don't need that anymore as they use mutter instead I believe
[01:40] <furkan> robert_ancell: basically instead of drawing the wallpaper it draws a transparent background, and gnome-shell is left to draw the background
[01:41] <furkan> robert_ancell: considering that in ubuntu, lightdm draws the wallpaper at the login screen, does that mean that nautilus shouldn't have to draw it anymore in ubuntu either? i was going to try applying the same patches to ubuntu nautilus to see if it works
[01:42] <robert_ancell> furkan, I don't know if compiz does the right thing if we stop nautilus drawing it. That change is likely to be harder to SRU though.
[01:42] <furkan> robert_ancell: what i was going to try doing before i found those upstream patches was to run both gnome-control-center and nautilus in a debugger, and see how they both draw the wallpaper - because gnome-control-center draws it properly but nautilus doesn't (basically when you change the wallpaper in gnome-control-center it's fine, but then when you restart the computer it's incorrect because
[01:42] <furkan> nautilus redraws it)
[01:43] <furkan> they both use include the same library from libgnome, gnome-bg.h, to update the wallpaper of course
[01:43] <furkan> so i thought it might just be the parameters that nautilus passes into the function that might be incorrect
[01:46] <furkan> robert_ancell: oh and i confirmed that nautilus is the issue, because after updating the wallpaper in gnome-control-center, all i have to do to mess it up again is shut down nautilus by calling "nautilus -q" in a terminal, and then relaunching it, and then the background gets redrawn incorrectly
[01:47] <robert_ancell> furkan, nice debugging
[08:04] <mlankhorst> morning!
[08:09] <tmpRAOF> desrt: Would you like to review https://code.launchpad.net/~raof/mir/provide-event-fd/+merge/247794 at your leisure and check that it matches your demanding specifications?
[08:31] <desrt> tmpRAOF: can you show me a diff of the change?
[08:32] <tmpRAOF> desrt: That MP has the only client API change in it; do you want a diff of all the Mir internal bits?
[08:33] <desrt> tmpRAOF: this MP has massive diffs touching dozens of files...
[08:33] <desrt> including the server
[08:35] <tmpRAOF> desrt: http://paste.ubuntu.com/10011503/ is the API diff
[08:35] <desrt> thanks
[08:36] <desrt> tmpRAOF: contains a small docs bug, but otherwise looks good
[08:36] <desrt> you mention mir_connection_get_fd() in the docs, but that got renamed
[08:36] <tmpRAOF> Oh, what's the doc bug?
[08:37] <tmpRAOF> Hah, yes.
[08:37] <tmpRAOF> Ta.
[08:37] <desrt> also: it could be made a bit more clear (and i assume it is the case?) that the mir_connected_callback() will be called when i call dispatch?
[08:38] <tmpRAOF> You're correct, yes.
[08:38] <desrt> it's also not clear if i own (ie: am responsible for closing) the returned fd
[08:39] <tmpRAOF> Indeed.
[08:39] <tmpRAOF> Fair chop.
[08:39] <tmpRAOF> I presume you're happy with ‘you don't own the fd’?
[08:39] <desrt> something like "the fd is owned by the connect and will be closed by it.  do not close the fd for yourself."
[08:40] <tmpRAOF> Yeah.
[08:41] <mardy> hi! I'm trying unity8 on a Lenovo Ideapad s3-10t, and all I get is a mouse cursor on a black screen
[08:42] <willcooke> mardy, I think the logs are ~/.cache/upstart/
[08:42] <mardy> the unity8-dash.log is filled with "Ubuntu Platform API: unable to load selected module. -- Aborting"
[08:42] <mardy> willcooke: ^
[08:43] <desrt> tmpRAOF: one more concern: when precisely is the fd good for?
[08:43] <desrt> until _i_ close the connection?
[08:47] <seb128> mardy, try installing ubuntu-application-api2-test and see if that fixes it?
[08:48] <tmpRAOF> desrt: Yup. Until the end of mir_connection_release.
[08:50] <desrt> cool.  seems like what i expect.
[08:53] <tmpRAOF> desrt: Oh - so, it currently interacts badly with mir_*_sync calls (ie: they don't do their own dispatch, so if you're single-threaded and you call *_sync you'll deadlock). How much do you care about that?
[08:55] <seb128> good morning desktopers btw
[08:57] <desrt> tmpRAOF: hmm.  we current create_surface_sync
[08:58] <desrt> also swap_buffers_sync, release_sync, etc. etc.
[08:58] <desrt> so yes.  probably will be a problem :)
[08:59] <tmpRAOF> desrt: Ok. So I'll do the bit whereby the _sync calls will automatically dispatch() until the call returns.
[08:59] <desrt> ....
[08:59] <desrt> please don't do that
[08:59] <desrt> that's very scary
[08:59] <desrt> this is more or less mainloop recursion and it will cause _very_ strange problems
[09:00] <seb128> larsu, Laney, Trevinho, so, after the recent vivid update, bamf doesn't match my nautilus to its icon anymore but add a "?" to the panel/alt-tab instead
[09:00] <desrt> like if i get an event handler being called nested from within the code that someone called gtk_window_show() or something
[09:00] <desrt> this is madness
[09:00] <Trevinho> seb128: I think larsu fixed it as well, there's just a little change to do
[09:00] <tmpRAOF> Yeah, that was what I was afraid of.
[09:01] <seb128> Trevinho, when is the fix landing? ;-)
[09:01] <larsu> Trevinho: I did?
[09:02] <Trevinho> larsu: wasn't https://code.launchpad.net/~larsu/bamf/fixup-gtk-application-matching/+merge/247975 ?
[09:02] <tmpRAOF> desrt: So, your constraints are (1) please make *_sync work, and (2) please make sure nothing else gets dispatched while in a *_sync call. This seems sensible, and annoying.
[09:03] <desrt> tmpRAOF: sounds like you might need to do some queue reordering?
[09:03] <larsu> Trevinho: might be - I thought that was unrelated...
[09:04] <tmpRAOF> desrt: Posssssibly. Certainly if you mix async and sync calls we'll need to defer any outstanding callbacks from async calls.
[09:05] <desrt> tmpRAOF: yes.  please.
[09:06] <darkxst> hey seb128, totem with menu patch is on gnome3 ppa, can you try out it
[09:07] <darkxst> https://launchpad.net/~gnome3-team/+archive/ubuntu/gnome3/+build/6771128
[09:15] <seb128> darkxst, hey, good
[09:16] <seb128> darkxst, I didn't look into details but Laney mentionned that the new version needs grilo?
[09:16] <seb128> mardy, got it to work?
[09:17] <darkxst> seb128, I patched that already it just needs the MIR 1394731
[09:17] <darkxst> bug 1394731 which is approved pending split
[09:18] <seb128> great
[09:18] <darkxst> also bug 1416617
[09:21] <mardy> seb128: sorry, was in a meeting. No, but now the error message is different ("connection to Mir server failed..."), I'll check if unity8 is running
[09:22] <mardy> seb128: so, there is no unity8 running (only unity-system-compositor), and no fresh unity8 logs
[09:23] <darkxst> seb128, atleast I made tracker support optional, it does require various other grilo-plugins as mentioned in the MIR
[09:43] <mardy> Saviq: Hi! I'm trying the unity8 session on the Ideapad s3-10t, but unity8 is not running
[09:43] <mardy> Saviq: and I don't see any logs in ~/.cache/upstart/ for unity8
[09:44] <mardy> Saviq: any hints on how to debug it?
[09:59] <seb128> mardy, I replied to you earlier
[09:59] <seb128> mardy, did you try what I suggested?
[10:03] <mardy> seb128: yep: now the error message is different ("connection to Mir server failed...")
[10:11]  * seb128 looks at Laney
[10:11] <seb128> notify-osd-icons in a silo man!
[10:14] <pitti> hey seb128, ça va ?
[10:15] <seb128> pitti, salut, oui et toi ?
[10:16] <pitti> seb128: je vais bien, merci ! alors je suis un peu fatigué
[10:16] <seb128> pitti, tu es rentré chez toi ?
[10:17] <pitti> seb128: oui, la dernière nuit
[10:17] <pitti> j'ai prendu le train à 18:25 de Bruxelles
[10:23] <pitti> seb128: votre sprint commence maintenant, no ?
[10:23] <seb128> pitti, oui, ce matin
[10:27] <pitti> seb128: SVP, dis des salutations à didrocks, je ne poudrais pas dire au revoir hier
[10:27] <pitti> didrocks: oh, tu es ici -- ça va ?
[10:29] <seb128> pitti, done
[10:29] <didrocks> pitti: pas de problème! oui, on ne s'est pas croisé :)
[10:30] <didrocks> bien rentré apparemment ? :)
[10:30] <seb128> brb
[10:37] <pitti> didrocks: oui, tout va bien :)
[10:58] <Laney> seb128: adding https://code.launchpad.net/~laney/telephony-service/humanity-not-gnome/+merge/248128 to that landing
[10:58] <Laney> oh
[10:58] <Laney> you already publisheD!!!!!
[10:58] <Laney> !!!!!!!!!!!!!
[11:01] <Laney> huh
[11:01] <Laney> why doesn't the assign silo page work?
[11:02] <Laney> maybe because there's a conflict
[11:02] <Laney> (can't upload it because of that, oh well)
[11:06] <larsu> Saviq: we usually use lower-case for enum values in gsettings. The usage-mode key in com.canonical.Unity8 expects upper case - care for a patch or is this already API?
[11:06] <Saviq> larsu, it's not an API, and not meant to be - it's gonna go away completely
[11:06] <Saviq> larsu, so I wouldn't care much about this
[11:06] <larsu> Saviq: gsettings is an API
[11:06] <larsu> Saviq: apps crash if a schema is not installed or a key is missing
[11:07] <Saviq> larsu, no apps are supposed to use this
[11:07] <Saviq> larsu, it's a temporary solution
[11:07] <larsu> Saviq: I know what you mean. Just saying that you should treat it like a function in a public header file
[11:07] <Saviq> larsu, sure, I'll just delete it when we're not using it ;)
[11:08] <seb128> Laney, yeah, I didn't include because that component is already in a silo
[11:08] <Laney> oh well
[11:20] <didrocks> pitti: did you see bug #1417059? Do you think there is any reason that the default (after bootchart fork) is /sbin/init instead of systemd real path?
[11:20] <didrocks> pitti: I don't think you can run systemd-bootchart without systemd, no journal, no /run/log…
[11:20] <didrocks> and no timestamp
[11:21] <pitti> didrocks: I just saw the bug mail indeed (set the bug to triaged/low)
[11:21] <didrocks> pitti: I guess I'll just cook an upstream patch changing the #define to /lib or /usr/lib… ?
[11:22] <pitti> didrocks: correct; I guess it should just run lib/systemd/init (well, the rootlibdir you actually configured of course)
[11:22] <didrocks> yep
[11:22] <didrocks> ok, will do that after lunch
[11:22] <pitti> didrocks: might be a nice exercise for seb128 :)
[11:22] <didrocks> run seb128, run! :)
[11:22] <seb128> lol
[11:22] <seb128> I'm happy to do it
[11:23] <pitti> seb128: btw, you can get a really crappy, but at least somewhat useful bootchart with "systemd-analyze plot > /tmp/boot.svg
[11:23] <pitti> it's mostly useless for actually fixing things, but it's what you can get without actually polling and changing the boot
[11:25] <seb128> pitti, I did a bootchart by changing /sbin/init by hand
[11:25] <pitti> ah, or that
[11:25] <pitti> seb128: apt install systemd-sysv :)
[11:25] <seb128> yeah, I should do that
[11:25] <pitti> seb128: aside from NFS, juju, and maas everything ought to work now
[11:26] <pitti> larsu: I fixed the failed ifup@ stuff, BTW (in -7ubuntu1)
[11:26] <seb128> pitti, chart on my slow inspiron laptop is http://people.canonical.com/~seb128/bootchart-20150202-1145.svg
[11:27] <seb128> it's far from being maxed out on cpu or io
[11:27] <seb128> dunno why
[11:27] <didrocks> pitti: \o/ one more successful systemctl status after upgrade then!
[11:27] <seb128> like there is a 1.6s gap before mount
[11:30] <larsu> pitti: cool, thanks!
[11:31] <pitti> seb128: do you have a "sudo journalctl -b -o short-monotonic"? I wonder what's going on at that time
[11:31]  * pitti hasn't looked at bootcharts at all so far
[11:34] <seb128> pitti, http://paste.ubuntu.com/10014043/
[11:37] <pitti> [    4.633670] ubuntu-Inspiron-3138 systemd[1]: Inserted module 'autofs4'
[11:37] <pitti> [    7.088656] ubuntu-Inspiron-3138 systemd[1]: Cannot add dependency job for unit powerd.service, ignoring: Unit lxc-android-config.service failed to load: No such file or directory.
[11:37] <didrocks> pitti: yeah, we are discussing this
[11:37] <pitti> hm, nothing happens in between there; that might need another boot with "debug"?
[11:37] <pitti> (powerd.service ought to fail quickly)
[11:37] <seb128> desrt, food time
[11:38] <seb128> pitti, need to go for lunch, bbiab
[11:38] <didrocks> pitti: yeah, just the dep isn't there, the lookup should be quick
[12:16] <seb128> $$
[12:16] <seb128> ups
[12:17] <pitti> €€!
[12:17] <seb128> lol
[12:17] <seb128> put my other laptop on the keyboard of this one :-)
[12:17] <pitti> haha; no cat this time?
[12:17] <seb128> not this time :-)
[12:29] <seb128> didrocks, pitti, http://paste.ubuntu.com/10014758/ log in debug
[12:30] <seb128> [    6.709249] ubuntu-Inspiron-3138 systemd[1]: Failed to load configuration for clamav-daemon.service: No such file or directory
[12:30] <seb128> [    6.709271] ubuntu-Inspiron-3138 systemd[1]: Failed to load configuration for mysql.service: No such file or directory
[12:30] <seb128> [    6.709292] ubuntu-Inspiron-3138 systemd[1]: Failed to load configuration for postgresql.service: No such file or directory
[12:30] <seb128> wth with those?
[12:30] <seb128> I never installed those things on my system
[12:31] <seb128> oh, I guess that's from /etc/init.d/exim4
[12:31] <seb128> Should-Start lists those
[12:33] <pitti> yeah, so that's just cosmetical
[12:37] <seb128> well, that laptop has a slow rational disk
[12:37] <seb128> so maybe it's just spending time trying to poke for those missing services?
[12:38] <pitti> it seems to need 0.6 alone to read sysvinit rc links in /etc..
[12:38] <pitti> seb128: (sorry, slow, investigating something else ATM in #u-touch)
[12:39] <seb128> pitti, no worry, I'm looking at different issues as well
[12:39] <seb128> also the bootchart is very low priority
[12:44] <xnox> seb128: que re:bootchart?
[12:44] <seb128> xnox, ?
[12:44] <xnox> seb128: imho we should unblacklist sync of bootchart2, and resolve the pygui binary name conflict in bootchart
[12:45] <xnox> seb128: "also the bootchart is very low priority"
[12:45] <seb128> xnox, well, I mean optimizing boot under systemd
[12:45] <seb128> first get it to work
[12:45] <seb128> then optimize
[12:45] <pitti> bug 1353587
[12:45] <pitti> xnox: ^
[12:45] <xnox> seb128: and hasn't the bootchart been merged into systemd?
[12:45] <seb128> xnox, yeah, I used systemd-bootchart
[12:45] <pitti> I think he meant "boot speed", not necessaril "get the bootchart to work" -- that's easy :)
[12:46] <seb128> xnox, I just have a gap in my boot which I was trying to figure out
[12:46] <xnox> oh, ok.
[12:47] <xnox> pitti: why remove bootchart (1 / original)? it's the one that works with upstart, and we will have machines running upstart in 16.04, at least those that upgrade from 14.04
[12:47] <xnox> pitti: we can only, realistically remove bootchart in 16.10
[12:47] <pitti> xnox: well, "eventually"
[12:48] <didrocks> eventually \o/
[12:48] <pitti> xnox: we can retitle to s/after switching to systemd/after removing upstart/?
[12:48] <xnox> pitti: i made it so
[12:48] <Laney> cd ubuntulog
[12:49] <Laney> umm
[12:49] <pitti> no such file or directory
[12:49] <Laney> ls ...
[12:49] <Laney> CTRL D CTRL D
[12:49]  * Laney runs
[12:49] <xnox> ls: cannot access ...: No such file or directory
[12:49] <ogra_> "..." no such directory
[12:49] <ogra_> bah
[12:49] <ogra_> i'm to slo
[12:49] <ogra_> w
[12:50] <Laney> echo cake > ogra
[12:50] <ogra_> omnomnom
[12:50]  * xnox was expecting unknown IOCTL or some such =)
[12:52] <Laney> ogra < xnox
[12:52] <ogra_> uuuh !
[12:52] <xnox> xnox
[12:53] <xnox> Permission denied
[12:53] <xnox> =)
[12:53] <ogra_> :)
[12:53] <Laney> sudo!
[12:53] <ogra_> E: sorry, can not write to ROM
[12:54] <xnox> apparmor deny
[12:54]  * pitti shakes his head and does "cd /kitchen; more lunch" instead
[13:20] <willcooke> bregma, coming to talk to you about focus stealing
[14:03] <pitti> err, ubuntu-themes in the train? is that even being used in the train?
[14:03] <pitti> err, on touch?
[14:03] <pitti> we need to drop libmagickcore5-extra build dep
[14:03] <Laney> train isn't only touch things
[14:07] <seb128> pitti, yes it is on touch, ubuntu-mobile-icons is built from there
[15:06] <smallfoot-> Why is gnome-screensaver (3.6.1) and gnome-system-monitor (3.4.2) and gnome-system-log (3.9.90) so old? Why not 3.14?
[15:08] <desrt> smallfoot-: gnome-screensaver is no longer maintained upstream
[15:08] <pitti> there is no newer gnome-screensaver
[15:08] <desrt> hi pitti :)
[15:08] <desrt> missing you in .be
[15:08] <smallfoot-> ah, I see, that explains it
[15:08] <pitti> hey desrt, how are you?
[15:08] <desrt> pitti: good.  having a decent sprint so far
[15:08] <seb128> https://launchpad.net/ubuntu/+source/gnome-system-monitor/3.14.1-1
[15:09] <desrt> except that i'm sick :(
[15:09] <smallfoot-> How about gnome-system-monitor and gnome-system-log tho?
[15:09] <seb128> g-s-m is updated in vivid ^
[15:09] <pitti> smallfoot-: new system-monitor is in -proposed, but regresses; ses bug 1261608
[15:09] <smallfoot-> g-s-m is 3.9.90 not 3.14 in vivid
[15:09] <smallfoot-> pitti, ah thanks
[15:09] <pitti> g-s-log> no idea
[15:09] <smallfoot-> I see
[15:10] <seb128> gnome-system-log has no newer upstream
[15:10] <seb128> http://ftp.acc.umu.se/pub/GNOME/sources/gnome-system-log/
[15:10] <smallfoot-> really nice to see vivid has new gnome-terminal which was terribly old in utopic
[15:11] <smallfoot-> It would be nice if the xwayland package were updated, because it contains a bug
[15:13] <willcooke> bregma, can you point me to that tool for changing the focus stealing setting, and roughly where that setting is located in the tool?  I'm going to try changing it on my desktop and see what breaks
[15:14] <bregma> willcooke, CCSM, general settings
[15:15] <willcooke> bregma, thx
[15:15] <smallfoot-> Please update Chrome (from 39 to 40) and Firefox (from 34 to 35) in Vivid
[15:20] <ogra_> smallfoot-, no need to request that, work on these packages usually starts immediately when there is a new upstream
[15:21]  * pitti hugs seb128, our latest systemd hacker :)
[15:22] <seb128> smallfoot-, by "upgrade" you mean "downgrade"?
[15:22] <smallfoot-> ogra_, oh, upstream in debian?
[15:22] <seb128> smallfoot-, https://launchpad.net/ubuntu/+source/firefox/36.0~b2+build1-0ubuntu1
[15:22] <seb128> smallfoot-, can you check launchpad before asking for things that already happened?
[15:22] <ogra_> smallfoot-, these packages dont come from debian in ubuntu i think
[15:22] <smallfoot-> seb128, in repository, its only 34
[15:22] <seb128> smallfoot-, I just gave you the url of the current version
[15:23] <seb128> it's in the repository
[15:23] <ricotz> seb128, 36 is stuck in proposed
[15:23] <seb128> ricotz, I know, proposed is part of the archive technically :-)
[15:23] <ricotz> which is not suppose to be used ;)
[15:23] <seb128> yeah
[15:23] <seb128> still those questions are not useful
[15:24] <seb128> when something is proposed it's clearly being worked on
[15:24] <smallfoot-> I see
[15:24] <ricotz> yeah i know
[15:24] <smallfoot-> proposed is 36b2, but latest is 36b5
[15:24] <seb128> that's going nowhere
[15:24] <seb128> work is ongoing on those updates, please be patient
[15:24] <seb128> or help resolving issues by sending patches :-)
[15:24] <ogra_> +1
[15:24] <ricotz> smallfoot-, simply look for an ppa if you need it
[15:25] <smallfoot-> I don't *need* it
[15:25] <ogra_> you could help make it build on arm64, ppc and ppc64el ... that would speed it up ;)
[15:25] <ricotz> smallfoot-, ok, then you need to wait for the arch-specific build-failures to be resolved
[15:25] <smallfoot-> I see
[15:26] <ricotz> ogra_, or cheat like done with libreoffice ;)
[15:26] <smallfoot-> Will vivid have LibreOffice 4.4?
[15:26] <ricotz> it already has
[15:26] <smallfoot-> oh, it already has
[15:26] <smallfoot-> nice
[15:27] <ogra_> https://launchpad.net/ubuntu/+source/libreoffice FYI
[15:27] <ogra_> (works for every ubuntu source package ... )
[15:27] <smallfoot-> and I saw PHP 5.6 in -proposed..... vivid is looking to be a great release
[15:27] <smallfoot-> It would be nice if the xwayland package were updated, because it contains a bug
[15:29] <didrocks> smallfoot-: I guess you need to read https://wiki.ubuntu.com/ContributeToUbuntu#Maintaining_Ubuntu :)
[15:33]  * seb128 hugs pitti back, thanks for the review
[15:33] <pitti> seb128: my pleasure :)
[15:33] <seb128> kenvandine, hey, did you start looking at that clickable header u-s-s issue yet? pmcgowan assigned to you but I was just starting changing it, can do it if you want
[15:34] <kenvandine> seb128, i didn't
[15:34] <pmcgowan> seb128, sorry you are everywhere
[15:34] <seb128> kenvandine, want me to do it?
[15:34] <pmcgowan> :)
[15:34] <seb128> pmcgowan, lol, I'm not :-)
[15:34] <kenvandine> seb128, please do!
[15:35] <kenvandine> i need to start working on trust sessions in content-hub
[15:36] <seb128> pmcgowan, you did most of the work btw, you could go the extra mile and submit a mp if you want :-)
[15:37]  * seb128 test build that change
[15:37] <pmcgowan> seb128, heh, not really set up for that
[15:37] <seb128> pmcgowan, k, no worry :-)
[16:32] <willcooke> desrt, just going through my notes from earlier - you were flagged to open a bug for a spinny cursor
[16:45] <pitti> haha! we stole seb128 for maintaining systemd! http://cgit.freedesktop.org/systemd/systemd/commit/?id=6e1bf7ab998e
[16:45]  * pitti hugs seb128
[16:50]  * seb128 hugs pitti
[16:50] <seb128> pitti, danke schön :-)
[16:50] <larsu> party at the hackfest
[16:50] <larsu> seb128: s/ //
[17:16] <pmcgowan> seb128, that same symptom with the listitem is in other places as well, like About page
[17:19] <seb128> pmcgowan, where in about?
[17:20] <seb128> pmcgowan, the software and legal label don't react to tap here
[17:20] <pmcgowan> seb128, all the info fields like phone number
[17:20] <pmcgowan> guess they arent headers
[17:20] <seb128> pmcgowan, yeah, different issue
[17:20] <pmcgowan> but they react
[17:20] <pmcgowan> ok
[17:20] <pmcgowan> loosk the same
[17:20] <pmcgowan> ks
[17:22] <seb128> it's a toolkit thing
[17:23] <pmcgowan> seb128, they are still listitems without that flag set
[17:23] <pmcgowan> seb128, thats a qml thing afaik
[17:23] <seb128> we shouldn't have to set that flag on every item
[17:23] <seb128> there is a uitk bug from mpt about that
[17:32] <seb128> pmcgowan, the issue is mentioned on https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1242666
[17:32] <seb128> pmcgowan, right bug is https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1362305
[17:34] <pmcgowan> seb128, just wondering if we inherit the default from qt, but either way we can do what we need
[17:35] <seb128> pmcgowan, yeah, it just doesn't make sense to set that default on every listitem, the widget should just do it
[22:29] <Noskcaj_> Laney: Any reason you didn't just use my branch for gnome-system-monitor
[22:29] <Noskcaj_> ?
[22:31] <Noskcaj_> I'd not proposed the merge because there was an existing theme issue at the time
[22:33] <Laney> Noskcaj_: no sorry, I just didn't notice it
[22:33] <Noskcaj_> fair enough
[22:33] <Noskcaj_> While you're here, and progress on my MOTU application?
[22:33] <Laney> no further information
[22:33] <Laney> If I were you I'd try pinging the people who haven't voted directly
[22:34] <Laney> in public probably ;-)
[22:34] <Noskcaj_> ok
[22:34]  * Laney goes to bed, night!
[22:34] <Noskcaj_> bye
[22:46] <mlankhorst> Well I managed to get sick on my way back, or when I got back..