[06:23] <pitti> Good morning
[06:26] <larsu> pitti: guten morgen!
[06:26] <pitti> hey larsu, wie gehts?
[06:29] <larsu> pitti: gut danke! War gestern bei einem pub quiz. Und dir?
[06:33] <pitti> larsu: auch gut, danke! wir hatten ein schoenes 4-Tage Wochenende in Trier
[07:14] <didrocks> morning
[07:17] <seb128> lut didrocks
[07:18] <didrocks> salut seb128
[07:19] <pitti> bonjour didrocks et seb128
[07:19] <seb128> hey pitti, wie gehts?
[07:20] <pitti> seb128: gut, danke! wir hatten ein schoenes 4-Tage-Wochenende in Trier mit Freunden
[07:20] <didrocks> oh, pitti is back!
[07:21] <didrocks> pitti: how were your days off?
[07:21] <didrocks> nice! :)
[07:21]  * didrocks 's german is good enough to understand that without google translate :)
[07:22] <seb128> pitti, oh ok, that's why you were not online on friday ;-)
[07:22] <pitti> seb128: yeah, had Fri and Mon off
[07:22] <seb128> great
[07:22] <seb128> had fun there?
[07:23] <pitti> seb128: yes, it was a great surprise for Michael; we all hid in their room when they arrived :)
[07:24] <seb128> :-)
[07:24] <pitti> we did some nice hiking, looking at some ancient Roman things, and it was nice to see each other again
[07:24] <didrocks> good weather?
[07:24] <pitti> seb128: et nous avons vu un film -- les filles de Monsieur Claude
[07:25] <pitti> c'était drôle !
[07:25] <pitti> didrocks: oui
[07:25] <seb128> pitti, c'était en français ?
[07:26] <pitti> seb128: non, le traduction allemand, mais c'est un film français
[07:26] <seb128> ok
[07:26] <didrocks> seb128: "Qu'est-ce que qu'on a fait au Bon Dieu" est le titre français on dirait
[07:26] <pitti> ah, I just translated the German title literally
[07:26] <seb128> oh ok
[07:27] <seb128> I know that movie
[07:27] <didrocks> pitti: yeah, they changed it under that name for non french translations apparently
[07:27] <seb128> it had good reviews in France
[07:27] <pitti> didrocks: as-tu le vu ?
[07:27] <didrocks> non, je ne l'ai pas vu
[07:27] <didrocks> juste cherché, car le titre ne me disait rien :)
[07:59] <pitti> didrocks: wow, you've been busy :)
[07:59] <didrocks> pitti: isn't it? :) I'm waiting on Lennart to review my patch though, (was fun to play with mount namespace)
[08:00] <didrocks> pitti: on the *dm things and alternatives, I want to catch up with you once you are done with your backlog
[08:06] <didrocks> pitti: and a proposal on how to handle debian alternatives with systemd (a more generic one, avoid the postinst snippets)
[08:06] <didrocks> avoiding*
[08:09] <didrocks> pitti: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770404#71 (as you are not in CC)
[08:11] <jibel> pitti, is there any info I can add or anything I can do to help debugging bug 1394063?
[08:14] <pitti> jibel: I think it happens on any hardware which sends out key events for those
[08:14] <pitti> so someone needs to merge u-settings-daemon with gnome-settings-daemon wrt. brightness handling (it probably changed with upower 0.99)
[08:43] <willcooke> morning all.  cold today
[08:46] <didrocks> hey willcooke
[08:52] <willcooke> hey didrocks
[08:52] <willcooke> https://git.gnome.org/browse/gtk+/log/?h=wip/mir-gdkgl
[08:52] <willcooke> Trevinho has been very busy :)  ^^^
[09:00] <seb128> hey willcooke
[09:00] <seb128> yeah, saw that with Trevinho
[09:00] <seb128> I hope they don't work conflict/duplicate efforts with people in our team
[09:00] <willcooke> we need a plan to get that in to the desktop next image.
[09:01] <willcooke> Shall we discuss that in the meeting later on?
[09:01] <willcooke> which reminds me...
[09:04] <Laney> yo
[09:05] <didrocks> plait
[09:05] <didrocks> ©
[09:06] <willcooke> https://plus.google.com/+DidierRoche/posts/jWJFV4e7C8a
[09:06] <willcooke> I like Coder Toolbox from qengho
[09:06] <willcooke> And ali123's "SDK Manager" is easy to understand
[09:06] <didrocks> seems you are not alone, it's been +1 ;)
[09:07] <didrocks> sdk manager is misleading IMHO though
[09:07] <didrocks> you can expect it's ubuntu's sdk
[09:07] <willcooke> fair point
[09:07] <didrocks> maybe I'm biased because android's studio sdk manager is called "sdk manager" alone :)
[09:08] <willcooke> ahhh
[09:08] <seb128> hey Laney, how are you?
[09:09] <didrocks> I guess I'll challenge my chance and try running now
[09:13] <seb128> didrocks, morning exercice now
[09:13] <didrocks> seb128: rain-free exercise rather :p
[09:14] <seb128> didrocks, good luck
[09:14] <didrocks> or rain-free-tentative exercise rather ;)
[09:14] <didrocks> thanks!
[09:15] <Laney> hey seb128, doing alright thanks, started packing last night ;-)
[09:15] <Laney> you?
[09:15] <Laney> I'm suspicious that I only had 2 LP emails this morning
[09:18] <seb128> I'm good thanks
[09:18] <seb128> packing, exciting ;-)
[09:18] <Laney> going to need more boxes
[09:18] <Laney> we have a billy from ikea
[09:18] <seb128> you need to subscribe to more packages!
[09:18] <Laney> 50% of the stuff from it = 4 boxes
[09:34] <Sweet5hark> moin
[09:35] <willcooke> hey Sweet5hark
[09:44] <seb128> hey Sweet5hark
[09:45] <Sweet5hark> seb128: heya
[10:33] <seb128> Laney, testing your nautilus update, it vanished from the launcher on upgrade
[10:34] <seb128> we need to deal with the .desktop rename one way or another
[10:35] <larsu> seb128: settings migration can't handle this?
[10:35] <larsu> (what was it renamed to?)
[10:36] <seb128> larsu, what settings do you want to migrate?
[10:36] <seb128> larsu, nautilus.desktop to org.gnome.Nautilus.desktop
[10:36] <seb128> hate that transition, even if I know desrt likes it
[10:37] <larsu> ya, it's necessary
[10:37] <seb128> I don't think it's "necessary"
[10:38] <seb128> it's just that people decided they wanted to do activation this way
[10:38] <larsu> com.canonical.Unity.Launcher favorites
[10:38] <seb128> well, that's one setting
[10:38] <seb128> what about gnome-panel
[10:38] <seb128> or xfce's launcher
[10:38] <larsu> seb128: we can do activation without that. We want tons more apps and try to avoid them stepping on each other's names asap
[10:39] <larsu> seb128: right, we'd need migration path for all of those...
[10:39] <seb128> that sucks
[10:39] <larsu> indeed
[10:39] <seb128> we can't even know "all of them"
[10:39] <seb128> I vote for renaming back the .desktop to nautilus.desktop in the package
[10:39] <larsu> the other option is to put a map old_name -> new_name into GIO
[10:40] <seb128> that wouldn't work
[10:40] <seb128> e.g unity's launcher is not using gio to check if the .desktop exists
[10:40] <seb128> or I don't think it is
[10:40] <seb128> having an hardcoded list would also sucks
[10:40] <larsu> they don't?
[10:40] <seb128> not sure
[10:41] <larsu> do they spider /usr/share/applications/ themselves?
[10:41] <seb128> I wouldn't be surprised if they use some Qt api
[10:41] <seb128> at least in unity8
[10:41] <seb128> next you tell me we need to patch qt as well
[10:41] <seb128> that's path to madness
[10:42] <larsu> fair enough
[10:42] <seb128> imho the only workable options are to undo the rename
[10:42] <larsu> ugh
[10:42] <larsu> this won't solve the problem forever
[10:43] <seb128> why not?
[10:43] <seb128> but I'm unsure to understand what problem that rename is supposed to solve
[10:43] <larsu> we'll always need to carry the patch
[10:43] <larsu> is what I meant
[10:43] <seb128> yeah
[10:43] <seb128> but we do care about compat and upgrades
[10:43] <seb128> shame that upstream doesn't :/
[10:43] <larsu> dbus also doesn't allow names without at least one '.' in it iirc
[10:43] <larsu> so activation won't work
[10:44]  * larsu checks
[10:44] <larsu> >>> Gio.dbus_is_name('nautilus')
[10:44] <larsu> False
[10:45] <seb128> I wonder if we could workaround it with shipping the old .desktop with NoDisplay= or something
[10:45] <seb128> though that might be not displayed since that's what the key means
[10:45] <larsu> Actually=org.gnome.Nautilus
[10:46] <larsu> but then we'll need to patch things agin
[10:46] <larsu> *again
[10:46] <seb128> yeah
[10:46] <seb128> well, I just fail to see a way to not screw upgrades without carrying a patch
[10:47] <seb128> I wish people would think about upgrades before designing/implementing new cool ideas :/
[10:47] <larsu> how is gnome handling this?
[10:47] <seb128> they don't
[10:47] <seb128> which is my complain
[10:47] <seb128> GNOME doesn't care about upgrades
[10:47] <seb128> they let that problem to distros
[10:47] <Laney> I don't see why they wouldn't if someone came up with an idea
[10:48] <larsu> so people on fedora will lose nautilus in their dash?
[10:48] <Laney> let's see what desrt has to say
[10:48] <seb128> I guess
[10:48] <seb128> Laney, we already discussed it on this channel when desrt was around
[10:48] <seb128> we didn't find a good option iirc
[10:48] <seb128> or did you suggest the copy with NoDisplay by then?
[10:48] <Laney> don't remember
[10:48] <seb128> though i'm unsure if NoDisplay might not confuse things
[10:48] <Laney> try it
[10:49] <seb128> well, I don't know what to try
[10:49] <seb128> I can't try every piece of code dealing with .desktop we have
[10:49] <seb128> I don't even know what those are
[10:49] <seb128> users could be using gnome-panel, xfce-panel, kde, $whateverotherlauncher
[10:49] <seb128> cairo dock
[10:49] <seb128> not to mention mimetype handlers
[10:50] <seb128> we currently have nautilus.desktop as being the default handlers for directories
[10:50] <Laney> I think the NoDisplay would be on the dbus activatable one if we did it that way around
[10:51] <seb128> I guess that would work
[10:51] <Laney> I don't know, I'm not clued up on this stuff
[10:51] <seb128> well, let's undo the renaming in the packaging then
[10:51] <seb128> at least until we figure out how to properly deal with it
[10:51] <larsu> I agree
[10:52] <Laney> ...
[10:52] <larsu> we should deal with it, though
[10:52] <Laney> let's wait for desrt to see if that would work?
[10:52] <Laney> it's not like we can update it today anyway
[10:53] <seb128> right
[10:54] <seb128> on that note, lunch, bbiab
[10:54] <larsu> enjoy!
[10:54] <larsu> Laney: oh, we haven't updated yet? Let's wait, then
[10:55] <Laney> nah, it's just in the ppa
[10:55] <Laney> needs new gtk :-)
[10:55] <larsu> ah right
[10:55]  * larsu hurries
[11:00] <Sweet5hark> hmmm, I might be riding a dead horse here ....
[11:01] <Sweet5hark> my kernel just decided it would be better for all of us, if my machine emergency reboots ...
[11:03] <Sweet5hark> thermal thermal_zone0: critical temperature reached(128 C),shutting down <- do you want fries with that?
[11:10] <larsu> Laney: not only is nautilus gone from the launcher, it also doesn't start for me
[11:11] <Laney> ?
[11:11] <Laney> nautilus -q;  nautilus ?
[11:11] <larsu> actually, it is running nad providing the desktop, but doesn't show any windows
[11:11] <Laney> nautilus -w?
[11:11] <larsu> that works, but I need to do tht even after a reboot
[11:37] <mitya57> xnox: you are TIL for gnome-keyring, mind if I upload a merge? https://launchpad.net/~mitya57/+archive/ubuntu/gnome-test/+sourcepub/4586839/+listing-archive-extra
[11:39] <Laney> larsu: "  * d/p/01_fix-new-window-manage-desktop.patch: Fix opening of new browser
[11:39] <Laney>     windows when nautilus is managing the desktop, cherry-picked from
[11:39] <Laney> sounds promising ;-)
[11:39] <Laney>     upstream, should really Closes: #766021"
[11:40] <Laney> that's https://git.gnome.org/browse/nautilus/commit/?id=ae4d4960d1c3e6316de0d1fd01fd34c88f65d673
[11:41] <larsu> Laney: sounds good. thnks for tracking it down
[11:41]  * Laney tries
[11:41] <Laney> I did notice behaviour like that but somehow convinced myself it was fixed
[11:42] <Laney> weird
[11:43] <Laney> git pull --rebase ♥
[11:51] <Laney> yep, this fixes it
[11:51]  * Laney updates ze PPA
[11:52] <larsu> thanks!
[11:55] <larsu> man, our theming is incredibly inconsistent
[11:55] <larsu> for example, nautilus' toolbar buttons have a border and gedit's don't
[12:40] <seb128> larsu, we don't really have app customization in the theme, specific rules are probably copies from the upstream ones because that was better than nothing
[12:42] <larsu> seb128: much of this is our theme trying to be very smart, not the apps
[12:43] <seb128> k
[12:44] <larsu> I can kind of see the old-style vs new-style argument for toolbars, but it _is_ very inconsistent
[12:44] <seb128> I don't even notice them being different
[12:44] <seb128> as an user I mean
[12:44] <seb128> what differences are we speaking about?
[12:45] <larsu> buttons in toolbars sometimes have a border (nautilus, evince) and sometimes don't (gedit, libreoffice)
[12:46] <seb128> gedit has a border for me
[12:46] <seb128> but that's gtk 3.14
[12:46] <seb128> and you maybe don't call the shape around it "border" ;-)
[12:46] <larsu> right, we consider this to be a bug :)
[12:46] <larsu> seb128: the theme does ;)
[12:47] <seb128> has that been reported?
[12:47] <seb128> or is that so subtle that nobody ever noticed?
[12:47]  * seb128 boots an utopic vm to look at how things are there
[12:48] <larsu> you reported it
[12:48] <seb128> hum
[12:49] <seb128> I'm confused
[12:50] <larsu> I noticed :)
[12:50] <seb128> larsu, http://people.canonical.com/~seb128/border.png
[12:50] <seb128> that doesn't have a border?
[12:50] <larsu> it does...
[12:50] <larsu> but shouldn't
[12:51] <larsu> whereas nautilus' toolbar buttons have a border and should
[12:51] <larsu> this is what I mean by inconsistent :)
[12:51] <seb128> why should nautilus have a border?
[12:52] <seb128> or you is that "should" according to our theme
[12:52] <seb128> and not "should to be right"
[12:53] <larsu> "should" according to our theme - and I agree, it looks stupid without
[12:53] <seb128> k, I think I understand now ;-)
[12:53] <seb128> sorry for being slow
[12:53] <larsu> haha, you're not slow ;)
[13:04] <Sweet5hark> seb128: I think I will have a 4.3.4 utopic and a 4.2.7+ trusty sru for you this week ...
[13:07] <seb128> Sweet5hark, great
[13:15] <Sweet5hark> (... and a 4.4.0~beta1/vivid for the ppa)
[13:28] <didrocks> pitti: someone mentionned udev for the new UDTC names, it's tempting ;)
[13:29] <didrocks> http://blog.didrocks.fr/post/Ubuntu-Developers-Tools-needs-you-for-its-new-name%21#comment-1711690429
[13:29] <willcooke> :D
[13:30] <willcooke> How about "System for automatically pulling in the latest environments and libraries which are of specific interest to developers"
[13:30] <willcooke> os just "systemd"
[13:30] <willcooke> for short
[13:30] <didrocks> ahah
[13:32] <Sweet5hark> willcooke: oh, its Friday!
[13:32] <willcooke> :D
[13:37] <mlankhorst> ok easy part done :/
[13:39] <willcooke> mlankhorst, ?  Does it work?
[13:40] <mlankhorst> yeah but missing support for timestamps, frame counters, and scheduling at a specific frame because mir doesn't support it.
[13:40] <willcooke> nice work that man :)
[13:41] <willcooke> mlankhorst, are we tracking the features we need but don't have somewhere?
[13:41] <mlankhorst> not right now, but I guess I should open some bugs
[13:41] <willcooke> yes please!
[13:41] <willcooke> We agreed with kgunn that we would open bugs for feature requests and then they can manage them from LP
[13:41] <mlankhorst> ok
[13:42] <willcooke> we toyed with the idea of a spreadsheet or similar, but that was thrown out as a bad idea :)
[13:42] <willcooke> guess who came up with that idea ;)
[13:42]  * willcooke loves spreadsheets
[13:42] <willcooke> but yeah, LP is the best place for them
[13:43] <willcooke> mlankhorst, when you're creating them please subscribe me to them as well so I can keep track
[13:43] <willcooke> (or just send me a link and I can sort it out from there)
[13:44] <mlankhorst> sure
[13:44] <willcooke> thanks!
[14:58] <willcooke> chrisccoulson, hi!  How's that build server holding up?  All ok?
[14:59] <chrisccoulson> willcooke, I can log in to it. I've not had a chance to set it up yet, but will hopefully get round to that tomorrow
[14:59] <chrisccoulson> thanks :)
[14:59] <willcooke> coolio, let me know if you need anything
[15:18] <mlankhorst> ok, xmir -rootless glxgears appears to work as intended (no copy done), xmir glxgears fullscreens too, xmir glxgears in a small window too. but vblank only works with -rootless for now. :P
[15:23] <willcooke> nice mlankhorst  :)
[15:23] <willcooke> bregma, ^^
[15:23] <mlankhorst> not really in any type of efficient fashion though
[15:24] <bregma> mlankhorst, is the a PPA where my guys can grab binaries to test?
[15:24] <mlankhorst> bregma: I'm still ironing out the bugs :P
[15:24] <desrt> mmmm.  serial for breakfast
[15:25] <bregma> mlankhorst, we are not unused to bugs
[15:25] <mlankhorst> currently lacking is support for syncing window movement with mir, placing windows at an arbitrary position (useful for menus), resizing..
[15:25] <mlankhorst> no support for cursor, it's hidden and default mir cursor is used
[15:27] <mlankhorst> I don't think I can boot up a desktop on xmir at this point :P
[15:30] <willcooke> oh, it's meeting time already
[15:30] <willcooke> #startmeeting Desktop Team Weekly Meeting 2014-11-25
[15:30] <meetingology> Meeting started Tue Nov 25 15:30:58 2014 UTC.  The chair is willcooke. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:30] <meetingology> Available commands: action commands idea info link nick
[15:30] <didrocks> hey
[15:31] <willcooke> Roll call: attente_, desrt, didrocks, fjkong (out), happyaron(out), laney, larsu, mlankhorst, qengho, seb128, sweet5hark, themuso (out), tkamppeter, robert_ancell (out)
[15:31] <desrt> word up
[15:31] <mlankhorst> bregma: yeah, seems I'm lacking TextureFromPixmap support :P
[15:31] <willcooke> #topic attente_
[15:32] <willcooke> Hey attente_ - how goes?
[15:32] <attente_> hi
[15:32] <attente_> not much from me, trying to figure out why new windows are not appearing with the gtk mir backend under u8
[15:32] <willcooke> attente_, did you see the commits to Gtk Mir backend from Trevinho?
[15:34] <willcooke> https://git.gnome.org/browse/gtk+/log/?h=wip/mir-gdkgl
[15:34] <attente_> willcooke: no i hadn't
[15:35] <attente_> i'll try it out though
[15:35] <seb128> quite some of those landed in trunk as well
[15:35] <willcooke> no worries, could you sink up with him and make sure we're not duplicating efforts
[15:35] <willcooke> would love to see the relevant pieces in Desktop Next image when they are ready
[15:35] <mlankhorst> sink up!
[15:35] <seb128> https://git.gnome.org/browse/gtk+/log/?qt=author&q=marco
[15:35] <willcooke> *sync :)
[15:36] <seb128> we should probably land the new GTK first
[15:36] <willcooke> ack
[15:36] <seb128> then backport the mir backend from trunk
[15:36] <desrt> it's a trivial backport
[15:36] <desrt> there's only one minor conflict due to adding libepoxy
[15:36] <seb128> yeah, independant files
[15:37] <seb128> should be just copy over and some makefile hacking
[15:37] <desrt> the trouble is in configure.ac
[15:37] <seb128> k
[15:37] <desrt> but it will take about 2 minutes to figure it out...
[15:37] <seb128> should have written autotools
[15:37] <seb128> rather than makefile :p
[15:37] <willcooke> :)
[15:37] <desrt> nah... there are makefile changes too
[15:37] <desrt> but they're not problematic :p
[15:37] <seb128> ;-)
[15:38] <seb128> enough said on the topic I think :-)
[15:38] <willcooke> :)
[15:38] <willcooke> ok, so attente_ some stuff for you to check out there, and please ping Trevinho as necessary
[15:38] <willcooke> let me know if I can do anything to help
[15:38] <willcooke> #topic desrt
[15:38] <desrt> hi hi
[15:39] <willcooke> what goes?
[15:39] <desrt> i added a patch to gsettings to improve efficiency in cases where people are not watching for changes
[15:39] <desrt> but this made some people unhappy (because in order to work, you need to watch for changes and then read a setting)
[15:39] <desrt> so then i reopened an ancient bug about being able to find out (as an object) when people connect signal handlers to you, in gsignal
[15:39] <desrt> i wrote a patch for that, awaiting review
[15:40] <desrt> i also did some misc hacking on bluetooth over the weekend mostly to scratch some personal itches on improving the bluetooth tether experience in NetworkManager
[15:40] <desrt> finally, i had a meeting last week with a couple of samsung engineers and amigadave talking about kdbus and what we will do
[15:40] <seb128> what was the outcome of that meeting?
[15:41] <desrt> for me, the task is working on the gvariant serialisation code to make it compatible with both (a) serialising to vectors in the style kdbus wants and (b) deserialising messages containing memfds
[15:41] <desrt> for dave the ask is adding zero-copy api to GBytes
[15:41] <desrt> for samsung guys the task is getting their patches to actually send a message...
[15:41] <desrt> we're planning to have regular meetings now every wednesday
[15:42] <desrt> we also now have #kdbus irc for us to sync up with the guys doing the kernel work
[15:42] <desrt> and we've already gotten a few feature requests handled in the past couple of days this way
[15:42] <desrt> and a bugfix...
[15:43] <desrt> (fin)
[15:43] <willcooke> great!
[15:43] <willcooke> say hi to Dave from me
[15:43] <desrt> willcooke: done :)
[15:43] <willcooke> :)
[15:43] <larsu> lol
[15:43] <willcooke> seb128, any more questions on the kdbus stuff before we move on?
[15:44] <seb128> no
[15:44] <willcooke> #topic didrocks
[15:44] <didrocks> hey
[15:44] <desrt> willcooke: "hi back"
[15:44] <desrt> ;)
[15:44] <didrocks> Ubuntu developer desktop:
[15:44] <didrocks> * Multiple reviews on intellij and pycharm support on udtc
[15:44] <didrocks> * Discussed and draw a plan with upstream jayatana guy (having java appmenu support). Waiting on him to merge his sources now
[15:44] <didrocks> * We are not going to patch fonts this cycles after discussion with the upstream guy (I can follow up on details if needed)
[15:44] <didrocks> * Will and I launched the contest for a new name! (http://blog.didrocks.fr/post/Ubuntu-Developers-Tools-needs-you-for-its-new-name%21), we welcome any proposals!
[15:44] <didrocks> Systemd:
[15:44] <didrocks> * Proposed and now waiting for upstream review my patch to fix the missing machine-id bug
[15:44] <didrocks> * Continued (long) discussions and tests on DM and systemd unit alternatives handling… We will probably pilot some solutions on ubuntu compared to debian
[15:44] <didrocks> * Continued (even longer) discussions on /usr and /etc separation
[15:44] <didrocks> Misc:
[15:44] <didrocks> * catchup with the DMB on behalf of the desktop team
[15:44] <didrocks> * Bluez 5 validation is waiting on TheMuso to upload pulseaudio 6 (git snapshot) to the bluez ppa.
[15:44] <didrocks> EOF
[15:45] <Laney> s/DMB/CC/
[15:45] <willcooke> thanks didrocks, and thanks again for standing in for me at the CC meeting (and Laney)
[15:45] <didrocks> Laney: oh right ;)
[15:45] <didrocks> yw
[15:45] <willcooke> #topic FJKong
[15:45] <willcooke> * Completed Pulseaudio package merging, and built test debs for armhf just in time to...
[15:45] <willcooke> * Started updating Ubuntu/Debian packaging for Pulse 6, currently 5.99.1. Am aware of the desktop team bluez5 PPA and will upload it there for testing with bluez 5 once ready for testing.
[15:45] <willcooke> * Discussion with Debian and upstream about fixed point vs floating point performance on armhf, nobody has done any benchmarking atm. Debian uses fixed point on all arm architectures, we use floating point on all arches we support.
[15:46] <willcooke> #topic happyaron
[15:46] <willcooke> Please email me your report happyaron
[15:46] <Laney> was that TheMuso?
[15:46] <seb128> willcooke, was that FJKong section the one from Themuso?
[15:46] <willcooke> argh
[15:46] <willcooke> copy & paste error
[15:46] <willcooke> one sec
[15:46] <seb128> hehe
[15:46] <Laney> spoilers
[15:46] <willcooke> * pinyin searching : I have write some code and shell scripts to get a maping table for converting Chinese character.
[15:46] <willcooke> when supply a Chinese character it will return all available pronunciation, next step some more work need to be done
[15:46] <willcooke> * Tracking a sogoupin bug: statusbar can be drag out of screen.
[15:46] <willcooke> * meeting with NUDT:
[15:46] <willcooke> 1 Discussing file manager feature
[15:46] <willcooke> 2 Nudt give more suggestion about pinyin searching
[15:47] <willcooke> #topic Laney
[15:47] <Laney> • Patch pilot
[15:47] <Laney> • Nautilus 3.14, some headerbar patches required for dialogs etc (fwded), in PPA
[15:47] <Laney> • Evolution 3.12.8
[15:47] <Laney> • Found a crash bug in v4l which broke cheese, worked with upstream for a fix
[15:47] <Laney> • Fixed upgrade failure in gnome-flashback
[15:47] <Laney> • Uploaded new point releases of webkigtk/{vivid,utopic,trusty}
[15:47] <Laney> ∘ Helped out with some test uploads to diagnose a webkit/ppc64el bug in vivid
[15:47] <Laney> • SRU libgdata point release to fix a Google contact sync failure
[15:47] <Laney> • Made ureadahead's triggers interest-noawait to fix upgrade failure
[15:48] <Laney> • Updating glib2.0 glib-networking ATM (working on test failures)
[15:48] <Laney> • Went to the CC meeting to talk about desktop team and DMB (two birds with one stone)
[15:48] <Laney> • On holiday next week
[15:48] <Laney> ✍
[15:48] <willcooke> thanks Laney
[15:48] <willcooke> good luck with the move
[15:48] <seb128> Laney, webkit, I noticed early that there was an update waiting for SRU verification for a while
[15:48] <seb128> should we try to verify it?
[15:48] <seb128> or should we rather get the new update in and verify that?
[15:49] <Laney> yeah we should verify it if nobody else does
[15:49] <seb128> so verify twice
[15:49] <seb128> rather than nagging to get the new update in and do one verification only on that one?
[15:49] <Laney> hang on wtf, that bit was false
[15:50] <seb128> the one is the SRU pocket is 17 days old
[15:50] <seb128> so I assumed you had yet another one you uploaded since
[15:50] <Laney> forget the bit where I said I updated the stable releases, that is just lies
[15:50] <seb128> didn't check ;-)
[15:50] <Laney> it was a patch to vivid only
[15:50] <seb128> k
[15:50] <Laney> but ya, should verify that
[15:50] <seb128> in that case I'm going to verify the one currently in the queue
[15:50] <seb128> thanks!
[15:51]  * Laney is distro-syncing a rawhide vm currently
[15:51] <Laney> \o/
[15:51] <willcooke> #topic larsu
[15:52] <larsu> hey. Not much news here. Continued working on the gtk update
[15:52] <larsu> got a bit overzealous with trying to clean up the theme
[15:52] <larsu> turned out I broke all kind of corner cases
[15:52] <larsu> and am now taking a more modest approach
[15:52] <willcooke> :)
[15:53] <larsu> also some of the usual stuff: code reviews etc
[15:54] <willcooke> fin?
[15:54] <larsu> oui
[15:54] <willcooke> #topic mlankhorst
[15:54] <mlankhorst> I've been working on rootless Xmir, glamor 2d acceleration works at this point, dri2/opengl is a WIP. Rootless flipping works, normal flipping does not, texture_from_pixmap does not work yet it seems, I'm investigating why... so no compiz yet. :P
[15:54] <mlankhorst> that's about all from me
[15:54] <willcooke> good stuff,. thanks mlankhorst
[15:54] <mlankhorst> np
[15:55] <willcooke> keep me abreast of those bugs for kgunn  and team once they're opened
[15:55] <mlankhorst> I want to get compiz running first, after that they start to become important :)
[15:55] <willcooke> ack
[15:55] <willcooke> #topic qengho
[15:55] <qengho> Hey hey!
[15:55] <qengho> * done: chromium release, v39. Security fixes, and a search-credit fix. GPU blacklist experiment was a failure.
[15:55] <qengho> * to-do: compiler still not available for precise.
[15:55] <qengho> * in-progress: more Cr-on-mir hacking.
[15:55] <qengho> * enormous storm here in Florida today. may need scuba gear to go to kitchen.
[15:56] <qengho> EOF
[15:56] <willcooke> thx qengho
[15:56] <kgunn> mlankhorst: cool!
[15:56] <kgunn> mlankhorst: what do you mean by "normal flipping" ?
[15:56] <kgunn> at the Fb ?
[15:56] <kgunn> RAOF: ^
[15:56] <seb128> qengho, chromium triggers an apport prompt due to some i965 .so on start, is that a known issue?
[15:57] <willcooke> kgunn, mind holding on 5 mins for end of the meeting?  Sorry, shouldnt have pinged you :)
[15:57] <seb128> qengho, I've that for some time, I assumed it would get resolved by some update but that doesn't seem to happen so I'm asking ;)-
[15:57] <seb128> ;-)
[15:57]  * kgunn feels ashamed :)
[15:57] <willcooke> totally my fault kgunn
[15:57] <qengho> seb128: yes. the intel GPU driver tries to do more than the chromium sandbox allows. I think you'll see the fix in kernel update.
[15:58] <seb128> qengho, ok, do you know if there is a bug report about that?
[15:58] <qengho> kernel, thoutgh? sandbox is userspace.
[15:58] <qengho> seb128: I'll get you an answer about what should fix the problem.
[15:58] <seb128> thanks
[15:58] <seb128> it makes chromium pretty unusable
[15:58] <willcooke> qengho, thanks for sorting out those GOOG issues last week.  Much appreciated.
[15:58] <qengho> :)
[15:58] <seb128> well, it hangs on start due to apport, then you can't use websites like gmaps
[15:59] <seb128> willcooke, you can continue on the topics btw
[15:59] <willcooke> ah, kk
[15:59] <willcooke> in which case
[15:59] <willcooke> #topic seb128
[15:59] <seb128> :-)
[16:00] <seb128> (4 days week, vac on thurday)
[16:00] <seb128> • spent a full day doing sponsoring/patch pilot (I didn't do some of the previous rounds so it was overdue)
[16:00] <seb128> • some desktop updates and merges for vivid
[16:00] <seb128> • looked at translations issue on ubuntu touch and vivid
[16:00] <seb128> • some playing around with systemd in preparation for the Ubuntu switch (switched my vivid to it, tested for regression, gave some feedback, looked a bit at the standard jobs)
[16:00] <seb128> • debugged an ubuntu-ui-toolkit regression that impacted settings, tested and potential fix and confirmed that it works
[16:00] <seb128> • ubuntu-system-settings for touch
[16:00] <seb128> ∘ reviewed changes from others (mostly backport from trunk commits to rtm)
[16:00] <seb128> • usual share of bugs triaging and desktop discussions

[16:00] <willcooke> thanks seb128  :)
[16:00] <seb128> yw!
[16:00] <willcooke> #topic Sweet5hark
[16:01] <willcooke> he ded
[16:01] <willcooke> #topic TheMuso
[16:01] <willcooke> * Completed Pulseaudio package merging, and built test debs for armhf just in time to...
[16:01] <willcooke> * Started updating Ubuntu/Debian packaging for Pulse 6, currently 5.99.1. Am aware of the desktop team bluez5 PPA and will upload it there for testing with bluez 5 once ready for testing.
[16:01] <willcooke> * Discussion with Debian and upstream about fixed point vs floating point performance on armhf, nobody has done any benchmarking atm. Debian uses fixed point on all arm architectures, we use floating point on all arches we support.
[16:01] <willcooke> #topic tkamppeter
[16:02] <seb128> willcooke, if you go alphabetical, did you skip robert_ancell's update?
[16:03] <willcooke> he wasnt in the user list of the channel, so he's at the end of my slightly alphabetical list :)
[16:03] <seb128> oh ok ;-)
[16:03] <willcooke> looks like tkamppeter is out anyway
[16:03] <willcooke> so..
[16:03] <willcooke> #topic robert_ancell
[16:03] <willcooke> Worked on:
[16:03] <willcooke> - TPM key support. Got hardware, did handover, started work
[16:03] <willcooke> - Released simple-scan 1.15.2
[16:03] <willcooke> - Bug triage, fixing, merge reviews
[16:03] <willcooke> Currently working on:
[16:03] <willcooke> - TPM key support
[16:03] <willcooke> #topic any other business
[16:04] <willcooke> I'm on holiday on Thursday, so I've cancelled meetings etc
[16:04] <willcooke> Please let me know if you want to reschedule, otherwise we can catch up next week
[16:04] <willcooke> anyone got anything else before we end?
[16:04] <seb128> desrt, larsu, Laney, we need to discuss handling of the GNOME .desktop renames (the one for e.g gedit.desktop to org.gnome.gedit.desktop)
[16:04] <seb128> but that's fine as after meeting
[16:04] <seb128> I don't think we need to hold everyone for that
[16:05] <willcooke> oh, and it's Thanks Giving in the USandA on Thursday, so those guys are out
[16:05] <willcooke> (maybe until next week?  Is Friday a holiday too?)
[16:05] <desrt> willcooke: a lot of people take friday off for the 4-day long-weekend
[16:05] <seb128> (if it's not I guess many are going to take a VAC anyway)
[16:05] <willcooke> Have a turkey filled weekend y'all
[16:05] <willcooke> #endmeeting
[16:05] <meetingology> Meeting ended Tue Nov 25 16:05:58 2014 UTC.
[16:05] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2014/ubuntu-desktop.2014-11-25-15.30.moin.txt
[16:05] <willcooke> thanks everyone
[16:05] <willcooke> kgunn, we're done, sorry about that
[16:06] <tkamppeter> willcooke, sorry here is my part
[16:06] <tkamppeter> - system-config-printer: Fixed several bugs concerning driver download
[16:06] <tkamppeter> - cups-filters: Apply Kyocera quirk workarounds in pdftops also to Utax.
[16:06] <tkamppeter> - Bugs.
[16:06] <willcooke> nw, thx tkamppeter
[16:11] <cyphermox> seb128: didrocks: did either of you try the bluez5 package?
[16:12] <seb128> cyphermox, no, I didn't see a call for testing, but I can if you think the ppa is ready for that
[16:12] <seb128> don't we need pulse to be updated first?
[16:12] <didrocks> cyphermox: couldn't yet, did you? I thought you wanted to try with pulseaudio?
[16:12] <didrocks> (see also emails you were in CC)
[16:13] <cyphermox> I did, but I saw diwic's email
[16:13] <cyphermox> so I looked into it, and the upstart job fix is in the PPA
[16:13] <cyphermox> so I don't know why it hangs, it doesn't do that here
[16:15] <cyphermox> seb128: didrocks: it's ready to play with if you don't care too much about whether your bluetooth works
[16:15] <cyphermox> given that there still isn't pulse, or an updated gnome-bluetooth, indicator, and whatnot
[16:15] <seb128> cyphermox, what is expected to not work?
[16:15] <cyphermox> sound, at the very least
[16:15] <seb128> k, so it's pretty much not ready to be tested?
[16:16] <seb128> I mean I don't see much point to test if most of the desktop integration is not going to work anyway
[16:16] <cyphermox> well, I can't really put in more time than preparing the bluez package itself
[16:16] <Sweet5hark> willcooke: sorry, was caught in traffic. Not much: sru for utopic, trusty for bug 1389858 and bug 1342175, tweaking 4.4.0~beta2 to build on vivid, various toolchain/pbuilder/tooling updates
[16:17] <cyphermox> then it's a matter of doing the releases for the gnome bits
[16:17] <seb128> cyphermox, didrocks or I can probably handle the gnome/indicator components
[16:18] <seb128> desrt, did you read the chan backlog about how to handle the GNOME .desktop renames? I know we already discussed that a bit some time ago, but it starts being an issue ... do you have a clever idea on how we should deal with those?
[16:18] <desrt> seb128: i had a couple of ideas, indeed
[16:18] <desrt> i don't seem to remember them now :(
[16:19] <cyphermox> seb128: provided we had gnome-bluetooth updated, you could do a lot of testing via gnome-shell I'd think
[16:19] <desrt> we forgot to discuss this in washington :(
[16:19] <seb128> cyphermox, why not unity?
[16:19] <seb128> desrt, yeah :/
[16:19] <willcooke> thx Sweet5hark
[16:21] <didrocks> seb128: you know the indicator code to update it to the new API?
[16:22] <seb128> didrocks, EPARSE
[16:22] <cyphermox> seb128: because for unity won't you need the indicator?
[16:22] <seb128> the indicator code needs porting?
[16:22] <cyphermox> probably
[16:22] <seb128> well, I don't know how much the client apis changed
[16:22] <seb128> and it much porting is needed
[16:23] <seb128> I can have a look for sure
[16:23] <cyphermox> I haven't had a look into the indicator enough to know
[16:23] <seb128> didrocks, no, I don't know the codebase but I can have a try to it
[16:23] <seb128> cyphermox, ^
[16:23] <didrocks> seb128: ok, cyphermox told he wouldn't take a long to him to deal with it, but if you have some cycles for it, why not :)
[16:24] <cyphermox> whomever looks into it, I don't expect it would take much time
[16:24] <didrocks> I hope it's not using bluez dbus API too much, it heavily changed
[16:26] <seb128> robert_ancell wrote that indicator otherwise
[16:26] <seb128> I'm going to have a look, if it's easy I can do it, otherwise I can try to bounce it to rob ;-)
[16:27] <larsu> seb128: when do you want to discuss?
[16:31] <didrocks> ahah :)
[16:31] <seb128> larsu, I tried "now" but desrt and Laney don't seem to be much around
[16:31] <seb128> so maybe let's try another day
[16:31] <larsu> ok
[16:31] <larsu> desrt is busy in #gtk :)
[16:32] <seb128> yeah, I see that
[16:32] <seb128> he also said he forgot the ideas he had to deal with the issue
[16:32] <desrt> well
[16:32] <seb128> so maybe he needs some time to think about it before we discuss
[16:32] <desrt> there are two approaches
[16:32] <desrt> well, three, really
[16:32] <desrt> one is that we have some central database
[16:32] <desrt> one is that we add AlsoKnowAs= to desktop files
[16:32] <desrt> one is that we define a new type of desktop file that is an alias for another
[16:33] <desrt> but i remember having one thought in particular earlier: i think downstreams should deal with this
[16:33] <desrt> gnome-shell handles it by hardcoding a list.  unity could do the same.
[16:33] <desrt> and then the counter-thought was: mime associations
[16:33] <desrt> but that could also be handled with a downstream list patched into gio
[16:34] <larsu> why downstream?
[16:34] <larsu> I think it makes sense for upstream to ship a desktop file with AlsoKnownAs
[16:34] <larsu> the only problem there is that we don't seem to know what needs patching...
[16:34] <larsu> seb128 said gio might not be enough
[16:35] <seb128> desrt, what about kde/qt?
[16:36] <desrt> seb128: *shrug*
[16:37] <desrt> there is absolutely nothing we can do for them unless someone also writes a patch there
[16:37] <desrt> oh.  the other thing:
[16:37] <seb128> desrt, well, one thing we could do is to not rename .desktops...
[16:37] <desrt> we _could_ install NoDisplay desktop files
[16:37] <desrt> seb128: we can't not do that
[16:38] <desrt> particularly since we're getting systemd after all
[16:38] <desrt> dbus activation is a permanent part of our future
[16:38] <desrt> also: having only one application identifier is a good thing
[16:38] <seb128> shrug
[16:39] <desrt> shrug if you want, but if you rename them back from what upstream did then the app simply won't start
[16:39] <seb128> I don't think that we can claim not carring about upgrades and compatibility because "dbus activation is the futur"
[16:39] <seb128> we can fix dbus activation to deal with old style names if really needed
[16:39] <desrt> seb128: you're arguing against a strawman
[16:39] <desrt> nobody is saying that we shouldn't care about back compat
[16:39] <desrt> but pretending that the change didn't happen isn't going to work
[16:40] <seb128> it happened to like 5 apps
[16:40] <seb128> so no on scale of things it didn't happen and we could decide to change things
[16:40]  * larsu is still in favor of hard coding those 5 apps somewhere
[16:40] <seb128> it's not a made deal
[16:40] <seb128> larsu, desrt is saying that every single of our apps shipping a .desktop is going to need to do that
[16:41] <larsu> true...
[16:41] <desrt> it's true -- we're going to have to deal with this one way or another
[16:41] <seb128> I vote for "don't rename and fix dbus activation to deal with name without imposing those rules
[16:42] <desrt> seb128: you're voting for a losing battle
[16:42] <seb128> we can distro patch...
[16:42] <desrt> also kde and qt?
[16:42] <seb128> if upstream doesn't want to deal with it
[16:42] <seb128> I guess?
[16:42] <desrt> this is a fd.o spec change agreed to by kde and they'll be using it soon
[16:42] <desrt> they're just a bit behind us on this one
[16:42] <seb128> but it's mind boggling that everybody is fine with just screwing backward compat
[16:42] <desrt> seb128: you're fighting a strawman again
[16:43] <desrt> we have three good solutions for fixing the backcompat problem
[16:43] <larsu> seb128: we're trying to consolidate the way we refer to applications (gsettings, dbus, and now desktop files)
[16:43] <Laney> What's the issue with the NoDisplay?
[16:43] <desrt> "ignore the issue and patch us back to 2012" is not one of them
[16:43] <seb128> "patch every toolkit to have an coded list that needs to be updates every time an app change" is not either
[16:43] <seb128> updated
[16:43] <desrt> seb128: that was one suggestion
[16:43] <seb128> right
[16:43] <seb128> it's not a good one
[16:44] <desrt> i offered three
[16:44] <seb128> so we don't have 3 good ones
[16:44] <desrt> good is a relative term
[16:44] <seb128> it's not any better than "rename back those .desktop"
[16:44] <desrt> i disagree
[16:44] <desrt> but *shrug*
[16:44] <seb128> let's agree to disagree then
[16:44] <seb128> it's also really frustrating to just make it a downstream issue...
[16:45] <desrt> i agree, if only for the mime associations
[16:46] <desrt> which is what i stated when i summarised the situation
[16:46] <seb128> do you know if there was any mention on the upgrade issue, during the xdg discussion?
[16:46] <desrt> nobody has raised it yet
[16:47] <desrt> before during or after
[16:47] <seb128> k, I guess I'm going to do that then ;-)
[16:47] <desrt> Laney: having two almost-identical copies of the desktop file installed is annoying
[16:48] <seb128> I've also started bugging inviduals apps about the side effects of their rename on their users
[16:48] <larsu> desrt: remember the gnome-calculator switch?
[16:48] <desrt> also: if the NoDisplay version has the old style name then it cannot be used with dbus activation, which removes the entire point of that exercise
[16:49] <Laney> I could deal with annoying for a while until we get AlsoKnownAs=
[16:49] <desrt> AlsoKnownAs= is a non-starter without some help from eg. update-desktop-database
[16:49] <desrt> which we could do
[16:49] <desrt> in fact, these two things together are my preferred solution
[16:50] <Laney> Well, yes, I believe there would be some engineering required
[16:50] <desrt> just saying: gio is not about to spider the entire directory looking through AlsoKnownAs= lines on every open attempt
[16:50] <desrt> but i also dismiss the [Alias] thing as an unnecessary burden for apps
[16:51] <desrt> adding one line to your desktop file: we can convince pretty much everyone to do that
[16:51] <desrt> installing a whole other file: lame
[16:53] <desrt> the only remaining question is what exactly the update tool does: it could create a cache file or it could generate the alias files for us
[16:53] <seb128> I still think it's wrong for apps to do that
[16:53] <desrt> seb128: to do what?
[16:53] <seb128> rename their desktop
[16:54] <desrt> i'm sorry that you feel that way
[16:54] <seb128> appdev needs to wake up, if they want to support their users they need to stop kicking them this way
[16:54] <desrt> seb128: this is kinda _our job_
[16:54] <seb128> the only reason it's ok is because gedit 3.16 can't be installed on RHEL
[16:54] <seb128> or that packages come from distros
[16:55] <seb128> if we had real ISVs they wouldn't let such things go
[16:55] <desrt> seb128: as if anybody working on gedit works for redhat?
[16:55] <seb128> s/RHEL/Debian if you prefer
[16:55] <seb128> or s/RHEL/Ubuntu LTS
[16:55] <desrt> so upstream loves rhel and debian but hates ubuntu?
[16:55] <seb128> just pick any platform which is not going to get updated update-desktop-database and gio to handle your new key
[16:55] <seb128> no
[16:56] <desrt> seb128: apps have dependencies
[16:56] <seb128> upstream don't think about their users
[16:56] <seb128> the issue is there for RHEL and Debian as much as Ubuntu
[16:56] <seb128> those changes is screwing all users on all distros
[16:56] <seb128> which is my point
[16:56] <seb128> if appdev had a clue about what they are doing they would oppose to those changes
[16:56] <desrt> honestly, so far you're the first who complains
[16:56] <seb128> they just don't realize the problems they create
[16:57] <desrt> and we already have a plan to deal with it and it will be in place by vivid release
[16:57] <seb128> sure, those rename didn't hit any user yet
[16:57] <desrt> past that, i have trouble understanding why you're so upset
[16:57] <seb128> the plan is a workaround for something that shouldn't have been broken to start with
[16:58] <desrt> seb128: we had very good reasons for making that change
[16:58] <seb128> you would have very good reason to do incompatible ABI changes to glib as well, it would make your job much easier
[16:58] <seb128> but yet you don't do it because compat is important
[16:58] <desrt> i'm going to go for a walk
[16:59] <desrt> walks are nice
[16:59] <seb128> enjoy :-)
[16:59] <desrt> everyone should go for a walk....
[16:59] <Laney> s/walk/climb/?
[16:59] <seb128> s/climb/swim/?
[16:59] <seb128> :-)
[16:59] <seb128> desrt, walking is not going to make that problem go away though...
[17:00] <Laney> Anyway, apart from not understanding what desrt means by [Alias], I don't mind working up a strawman for NoDisplay
[17:00] <Laney> Could be done in packaging
[17:00] <seb128> it's still wrong
[17:00] <seb128> what if firefox does a similar rename
[17:00] <seb128> what happens when we try to roll that new firefox on precise?
[17:00] <Laney> We're there now, I think we should deal with it
[17:01] <seb128> sure
[17:01] <seb128> that question still stands
[17:01] <Laney> Shame that it's considered at this late stage
[17:01] <seb128> what's the strategie when we need to roll such updates on precise?
[17:01] <Laney> but we can bring some value and improve the situation
[17:01] <Laney> so ...
[17:01] <seb128> I don't think it's too late to raise the issue that those changes are problematic
[17:01] <seb128> and maybe an alternative solution should be considered
[17:01] <seb128> so far it's like 5 GNOME apps that renamed
[17:02] <seb128> it's not like it was a done deal for the ecosystem
[17:02] <Laney> we have the outline of a proposal
[17:02] <seb128> that proposal fails to deal with app updates on old systems though
[17:03] <seb128> I still think the changes are fundamentally wrong for that reason
[17:04] <Laney> I don't understand what you mean really, part of the proposal is adding back the old desktop file
[17:05] <seb128> we need something genrating the alias though no?
[17:05] <seb128> or is your suggesting to just add back the old .desktop with a NoDisplay and do no other change?
[17:06] <Laney> I think the NoDisplay might be on the activatable desktop file, but yes
[17:09] <seb128> Laney, that's not matching any of the 3 suggestions from desrt though?
[17:16] <Laney> Heh
[17:24] <desrt> nobody went for a walk/climb/swim
[17:24] <desrt> so the concern is now what?  qt?
[17:25] <Sweet5hark> seb128: I just wanted to ask you to upload the trusty SRU, but found two more new fixes upstream from 2 hours ago ...
[17:25] <desrt> where's what's on my mind about why we don't want to have a bunch of extra .desktop files installed: adding and removing associations will become stupidly complicated
[17:26] <desrt> imagine text/plain being associated with both gedit.desktop and org.gnome.gedit.desktop
[17:26] <desrt> or if it's associated with gedit.desktop but then the user wants to unassociate it with org.gnome.gedit.desktop
[17:27] <desrt> other than that, the solution is mostly viable, aside from the ugly of having two copies of the (almost) same file installed
[17:27] <desrt> except that we cannot seriously ask upstream to do this
[17:28] <desrt> that's where the tooling could help, though
[17:36] <seb128> desrt, sorry, was on the phone
[17:38] <seb128> desrt, well, my concern is not only qt, it's also that I fear that working around incompatible changes bite us back at some point, I wish whoever worked on that solution would have had upgrades and stability in mind, but I guess I'm late to argue on that one :/
[17:39] <seb128> desrt, it just feels like those are things we (as a group) use to care more than we do nowadays and it somewhat makes me sad
[17:40] <seb128> desrt, one of the concerns is that we need support in e.g gio, but then firefox is going to rename it, and we are going to security update the new version on trusty, and what happens there?
[17:41] <desrt> SRUing new firefox releases is insane.  QED.
[17:41] <desrt> i know we have to do it... but we can't honestly expect a smooth ride there all the time
[17:41] <desrt> there is always going to be some tinkering
[17:42] <seb128> rolling new apps versions on a stable OS is what other platforms do
[17:42] <seb128> like you can install any $current app on winXP still
[17:42] <desrt> and they all ship gigantic wads of library support with them
[17:42] <desrt> we can static-link everything if that's what you prefer :)
[17:42] <seb128> that wouldn't resolve that .desktop issue
[17:43] <desrt> it would.... each app would have its own (new) copy of gio :)
[17:43] <seb128> the winXP panel is not going to read your new gio to get the matching list
[17:43] <seb128> so your favorites icons would still bug
[17:43] <desrt> and in that direction, the app would ship the old copy of its desktop file in the built-for-xp case
[17:43] <desrt> your comparison isn't fair
[17:43] <seb128> I guess I would be fine if our apps would build the compat desktop
[17:44] <seb128> if built with old glib
[17:44] <desrt> if you think that apps install binary-exact-copies of themseves regardless of the windows version you're insane
[17:44] <desrt> to expect us to do the same is an unfair comparison
[17:44] <seb128> no
[17:44] <seb128> but then our app should install the old .desktop name if glib < 2.43
[17:44] <desrt> (and yet, i try to develop a system that lets us do that....)
[17:44] <desrt> right... well now you hit on the absolute fundamental difference
[17:45] <desrt> gedit doesn't care about running on old distro releases
[17:45] <desrt> or almost anyone else
[17:45] <desrt> they gain much more from using new gtk features
[17:45] <seb128> I think app dev care, because that's where their majority users are
[17:45] <desrt> which already de-facto blocks them from ever working on older releases anyway
[17:45] <seb128> talk to firefox or pidgin or chrome or ...
[17:45] <desrt> right.  absolutely.
[17:45] <desrt> and they take extra steps
[17:45] <desrt> just like they would have to for winxp
[17:46] <desrt> but quite a lot of apps _don't_ care about that
[17:46] <seb128> do they don't care
[17:46] <seb128> or do they just not realize it's an issue?
[17:46] <desrt> when they opt into using bleeding-edge gtk features, they're making a pretty explicit decision
[17:46] <seb128> but they don't have datas on where they users are and what they want
[17:46] <seb128> right
[17:46] <seb128> I'm fine with those GNOME apps
[17:46] <desrt> stuff like desktop files isn't even on the radar at that point
[17:47] <seb128> I just wonder what happens when e.g pidgin is going to ask themselve that question
[17:47] <desrt> they could ship a second desktop file, NoDisplay
[17:47] <desrt> *shrug*
[17:47] <seb128> right
[17:47] <seb128> it just feels like that most apps are going to need to do that
[17:48] <seb128> which makes me thing that maybe the system could have been designed better to not enforce a rename
[17:48] <desrt> only the ones that care
[17:48] <seb128> which would avoid all those isues
[17:48] <seb128> it would be the best of both worlds
[17:48] <desrt> we wanted to encourage renaming, though
[17:48] <desrt> we discussed not requiring it
[17:48] <seb128> well, the issue is that people message the advantage of renaming, but they don't mention the side effects
[17:49] <seb128> so it's sort of misleading requests
[17:49] <desrt> weighing the pain of the fact that an app doesn't even currently known the name of its own desktop file, problems with application matching in the shell, etc. that we've had for years
[17:49] <desrt> against the one-time pain of a rename
[17:49] <seb128> I've started filling a couple of bugs on apps, I'm curious to know what maintainers think
[17:49] <desrt> please let me know the result of your research
[17:49] <seb128> will do
[17:50] <desrt> i agree that we should have had something in place to deal with the renames more smoothly
[17:50] <desrt> but i still think renaming is desirable
[17:50] <seb128> well, renaming is desirable
[17:50] <seb128> I just wish it wouldn't be mandatory to be able to be dbus activated
[17:50] <seb128> like please make all new stuff use the new scheme
[17:51] <seb128> but it should have been possible for old apps to stay in some compat mode
[17:51] <desrt> people would never have done it otherwise
[17:51] <desrt> even for new apps
[17:51] <desrt> people don't read documentation -- only cargocult
[17:51] <desrt> the only way to get people (even new apps!) to change is to make something like this mandatory
[17:51] <desrt> look at the fuckup with people installing gsettings keys in /apps/ and such
[17:51] <desrt> this is the sort of idiocy that occurs when you let people do what they want
[17:51] <desrt> and that was my fault
[17:52] <desrt> first thing anybody making a new app is going to do is copy existing-app.desktop
[17:52] <seb128> yeah, well it's the stick approach
[17:52] <seb128> not sure I agree with it
[17:52] <desrt> i consider dbus activation to be a rather nice carrot, actually
[17:52] <seb128> especially that you apply the stick on the users
[17:52] <desrt> nobody is forcing a rename
[17:53] <desrt> but people want the carrot....
[17:53] <seb128> you could have given them that without forcing a rename
[17:53] <seb128> but yeah
[17:53] <desrt> i just explained why i didn't do that
[17:53] <seb128> right, and I'm not sure I agree
[17:53] <desrt> so we're back at agreeing to disagree :)
[17:53] <seb128> it's like we just break users because devs don't read
[17:54] <desrt> it's a legitimate concern
[17:54] <seb128> it feels like the wrong people pay the price
[17:54] <desrt> and we don't have to break users...
[17:54] <desrt> backcompat is often a dance in workarounds
[17:54] <desrt> and we'll have one here
[17:54] <seb128> I've yet to be convinced we can have a robust solution
[17:54] <desrt> ya... there are going to be some issues no matter what we do
[17:54] <desrt> but they're actually very minor
[17:54] <seb128> sure your solution work in 90% of cases
[17:55] <seb128> but they imply patching toolkits
[17:55] <desrt> maybe.
[17:55] <desrt> (ideally)
[17:55] <seb128> and then you have cases like firefox to old releases
[17:55] <seb128> which are going to bite us
[17:55] <seb128> those 10% are going to have a cost
[17:55] <desrt> i disagree with that
[17:56] <desrt> SRUing firefox is always black magic
[17:56] <desrt> if one of those bits of black magic is renaming a desktop file then so be it
[17:56] <desrt> this is absolutely our job
[17:57] <seb128> well, I'm sure it's going to be bite some users
[17:57] <desrt> plus...
[17:57] <desrt> if you think firefox is going to be using dbus activation inside 5 years you're dreaming :)
[17:57] <seb128> would they only be people getting e.g the new shotwell from the yorba ppa
[17:57] <seb128> or the new gedit from the gnome3 ppa to install on utopic
[17:58] <desrt> that's not going to work for long unless that ppa also has new gtk
[17:58] <desrt> and then it may as well have new glib too
[17:58] <desrt> anyway... i think we both understand each other's position well enough
[17:58] <seb128> well some apps, shotwell for example, try to not require versions > current_lts
[17:58] <desrt> and i am probably not going to work on this this week
[17:58] <seb128> because they care about being able to provide the current version to lts users
[17:58]  * desrt wants to get out of the serialisation business first
[18:00] <seb128> yeah, no worry, it's not a problem that we need to solve today or this cycle
[18:00] <desrt> i'd like to solve it this cycle
[18:00] <seb128> for what it's worth I would be happy to rename those desktop backs until we have a way to deal with those cases better
[18:00] <seb128> or to let Laney try the NoDisplay .desktop copy thing
[18:00] <desrt> for now that won't be a problem
[18:00] <seb128> I'm still going to email xdg list about that
[18:01] <seb128> I feel like people ovelrooked the upgrade issues
[18:01] <seb128> it sucks to loose you preferred apps on upgrade
[18:01] <desrt> propose a Aliases= or FormerlyKnownAs= or AlsoKnowAs= or whatever field
[18:01] <desrt> this is the easiest almost-no-effort way for apps to provide us with the info that we need to do anything
[18:01] <seb128> how would that work? every toolkit/codebase would need to be updated to look to the alias?
[18:02] <desrt> any decent system that we decide on will work based on that plus something that either happens during dpkg build or at the time of update-desktop-database
[18:02] <seb128> I don't know how many "independent parsers" we have out there
[18:02] <desrt> we are absolutely not using that field directly at runtime
[18:02] <seb128> k
[18:02] <desrt> (screw compatibility concerns -- i'd reject it on performance concerns alone)
[18:02] <seb128> so you would create dummy .desktop in the cache for those aliases?
[18:02] <desrt> maybe.
[18:03] <desrt> the other alternative is generating a aliases file that contains a mapping of old names to new ones
[18:03] <desrt> which we'd have to modify toolkits to understand
[18:03] <seb128> right
[18:03] <seb128> then we face the "how many codebase don't use toolkits to deal with those files"
[18:03] <desrt> i'm not sure which solution i like best yet
[18:03] <seb128> like just do ini style parsing
[18:03] <desrt> but having app authors add the field to their desktop file is definitely a part of whatever approach we end up taking
[18:04] <desrt> seb128: that's an argument for the NoDisplay approach
[18:04] <desrt> but seriously....
[18:04] <desrt> if you're doing this yourself, i hate you
[18:04] <willcooke> could we make it super easy for them, like providing a script to do it for them?
[18:04] <desrt> there are 2 or 3 decent libraries for doing this stuff
[18:04] <desrt> use one
[18:05] <desrt> willcooke: to do what?
[18:05] <willcooke> update the .desktop files
[18:05] <desrt> from upstream we only expect that they add a single line to their desktop file with the old name
[18:05] <desrt> nobody will have trouble with that
[18:05] <willcooke> oh, ok
[18:06] <desrt> the rest is magic on our side
[18:06] <desrt> (one way or another)
[18:07] <desrt> seb128: another reasonable solution would be to chew through the user's config and change all references to use the new names
[18:07] <seb128> not possible
[18:07] <desrt> why not?
[18:07] <didrocks> (that's going to fun on the unity side, because IIRC, they inotify the .desktop file which will disappear on package unpack, and consequently, remove it from the launcher before we remove the tool)
[18:07] <seb128> when would you do that?
[18:07] <desrt> seb128: from the existing framework we have for this sort of on-login-or-on-updates changes
[18:07] <seb128> also what if some configs are sqlite databases?
[18:07] <desrt> the one that didrocks copied from upstream and improved
[18:08] <seb128> you can't simply grep/sed
[18:08] <didrocks> session-migration you mean?
[18:08] <desrt> seb128: do you know of an example of that?
[18:08] <desrt> didrocks: yes
[18:08] <seb128> you would need custom handlers understanding programs
[18:08] <desrt> seb128: yes.  that's precisely my point.
[18:08] <seb128> desrt, no, but I don't claim to know how every launcher out there works
[18:08] <desrt> seb128: we'd have a system one for the mimeapps
[18:08] <desrt> seb128: unity would need one
[18:09] <desrt> generally, any laucher-type app might want to provide one
[18:09] <larsu> desrt: the sound and message indicators would need this as well
[18:09] <larsu> they watch XDG_DATA_DIRS/applications
[18:09] <desrt> but honestly, those sort of apps should have code to update themselves to the new names internally anyway
[18:10] <larsu> at least messages does, not sure about sound tbh
[18:10] <larsu> desrt: how? The way we've identified them now is by their .desktop
[18:10] <larsu> I think teaching toolkits and apps about a mapping file will be easier to handle
[18:10] <desrt> that's precisely what i'm suggesting
[18:11] <desrt> the only change is when we do it -- immediately or at access
[18:11] <desrt> and also how much we can share
[18:11] <desrt> if we just update the mimeapps stuff on first login after (or at) new installation of renamed desktop files then we can avoid touching mime association code completely
[18:11] <desrt> in either gio or qt
[18:11] <desrt> big +1 from me there
[18:12] <desrt> then all that's left is apps (mostly launcher, i think) that store desktop file names internally
[18:12] <desrt> and those will have to be handled case-by-case, perhaps with help from the toolkit
[18:13] <larsu> right
[18:13] <larsu> totally like this approach
[18:14] <desrt> i'm sure it has some problem we didn't think of yet
[18:14]  * desrt goes back to serialising
[18:14]  * desrt is very much trying not to context switch again
[18:15]  * larsu goes to exercise
[18:29] <GunnarHj> seb128: still there?
[18:31] <seb128> GunnarHj, sort of but about to start dinner
[18:32] <GunnarHj> seb128: Ok, this is short. I updated my gdm MP, but haven't been able to really test it. There is something strange when running gdm on my box (commented on the MP).
[18:45]  * willcooke EOD
[18:54] <seb128> GunnarHj, sorry, disconnect, you were asking something?
[18:56] <GunnarHj> seb128: Well, I was mostly complaining about the fact that I'm not able to run gdm. Commented on it at:
[18:56] <GunnarHj> https://code.launchpad.net/~gunnarhj/ubuntu/vivid/gdm/config-error-dialog/+merge/239729
[18:56] <GunnarHj> seb128: Can it be that there is a missing dependency?
[19:04] <seb128> GunnarHj, sorry, I don't know about that, would require debugging
[19:06] <GunnarHj> seb128: Right. I might file a bug report later. (The problem is about gdm in general, and not specific to my proposed changes.)
[21:38] <TheMuso> didrocks: I expect to have pulse 6 RC1 uploaded to the bluez5 PPA by EOD today.
[21:39] <TheMuso> I parctically had it done yesterday, but I am getting some weird quilt/dpkg behavior which I am stumped about, so need to dig further.