[05:50] <hikiko> Hi
[07:41] <desrt> hello desktop
[07:59] <pitti> Good morning
 Hello desrt. Would you like to play a game?
[08:00] <desrt> i know this one!  global thermonuclear war!
[08:00] <desrt> pitti, duflu: hi :)
[08:00] <pitti> hey desrt!
[08:00] <pitti> hello duflu, how are you?
[08:00] <desrt> pitti: how's home?
[08:00] <duflu> Oh. Or is it "shall we play a game"?
[08:01] <pitti> desrt: nice and cozy, but as rainy as Brussels today :(
[08:01] <duflu> pitti: Hi, good. You?
[08:01] <pitti> desrt: how is the sprint?
[08:01] <pitti> duflu: good, thanks!
[08:01] <pitti> long nights due to our virtual sprints
[08:02] <desrt> pitti: the sprint is over
[08:02] <desrt> pitti: larsu and i are now in köln
[08:02] <desrt> (and i was not at the sprint anyway)
[08:24] <seb128> good morning desktopers
[08:31] <pitti> bonjour seb128 !
[08:31] <seb128> hey pitti
[08:32] <seb128> hey robert_ancell
[08:32] <robert_ancell> seb128, hi
[08:32] <seb128> robert_ancell, pitti, how are you?
[08:32] <pitti> seb128: bit tired, but good, thanks! how was your sprint?
[08:33] <seb128> pitti, I didn't go to that one, larsu_ and Laney did
[08:33] <seb128> how is your virtual one?
[08:34] <pitti> seb128: ah, I thought you were there as well, ok
[08:34] <pitti> seb128: took me three hours to get out of mojo's claws to finally install the CI train into juju-local :/
[08:34] <pitti> so only went to bed at 1:30
[08:34] <seb128> :-/
[08:34] <pitti> seb128: but, getting to a point where the deployment docs are working, and I landed my first fix :)
[08:35] <seb128> robert_ancell, so if I understood your email correctly, nobody worked on porting the aptdaemon rdepends to packagekit?
[08:35] <seb128> pitti, good :-)
[08:35] <robert_ancell> seb128, I was working on the software-properties-gtk one
[08:36] <seb128> robert_ancell, yeah, I saw a branch from you with some work
[08:36] <seb128> seems like we had a planning fail there :-/
[08:38] <Trevinho> Morning folks
[08:38] <seb128> hey Trevinho!
[08:39] <robert_ancell> seb128, I'm not seeing as much stuff as you are. The main ones are software-properties-gtk and language-selector
[08:39] <Trevinho> hey seb... How is it?
[08:39] <robert_ancell> I believe language-selector is not a major problem
[08:40] <seb128> robert_ancell, well they are not problems, they are work
[08:42] <seb128> robert_ancell, update-notifier apturl software-center also use python-aptdaemon
[08:42] <robert_ancell> seb128, well, software-center is going, so that doesn't matter
[08:42] <seb128> robert_ancell, is it? I though the plan was to keep it in universe
[08:43] <seb128> if it is then we need to fix things that rdepends on it in the same landing
[08:43] <seb128> like unity
[08:43] <seb128> also e.g xubuntu use it
[08:43] <seb128> are they fine switching to gnome-software?
[08:43] <seb128> same for ubuntukylin, studio, etc
[08:45] <robert_ancell> seb128, not sure what they want to do.
[08:45] <seb128> it's getting complicated/tricky :-:/
[08:45] <robert_ancell> seb128, It's always been complicated/tricky!
[08:46] <seb128> yeah, but I though somebody was handling porting the rdepends to use packagekit
[08:46] <seb128> I should have followed that more closely
[08:46] <robert_ancell> seb128, you got some spare cycles?
[08:46] <seb128> it's going to teach use to not have proper workitems lined up
[08:46] <alexarnaud> Hello everyone :)!
[08:46] <seb128> not really
[08:46] <seb128> hey alexarnaud
[08:46] <alexarnaud> how are you seb128 ?
[08:46] <seb128> I could make some, but on the detriment of other work
[08:47] <seb128> alexarnaud, good, though busy, you?
[08:48] <alexarnaud> seb128: fine, I've lot of work for the day :). I'm goingo to continue to learn packaging for porting Compiz from Ubuntu to Debian.
[08:48] <seb128> good luck
[08:49] <alexarnaud> Yesterday, I've discovered existance of debian helper
[08:49] <alexarnaud> :)
[08:52] <alexarnaud> hey willcooke :)!
[08:56] <robert_ancell> seb128, thinking more about it I'm not sure there's any real win updating aptdaemon to PK1.0. Perhaps it might be easier to package PK0.8 and have systems that aren't going to use PK1.0 use that instead.
[08:56] <robert_ancell> systems = non-Ubuntu distros
[08:57] <seb128> robert_ancell, what do you mean "package pk0.8"?
[08:57] <seb128> like have both versions in the archive?
[08:57] <robert_ancell> seb128, yeah
[08:57] <seb128> robert_ancell, well, then we would still have to port software-properties language-selector apturl update-notifier update-manager etc
[08:57] <robert_ancell> seb128, yep, that's still do-able
[08:58] <seb128> that's never going to be done by ff
[08:58] <seb128> it's on feb 18th
[08:58] <robert_ancell> It's pretty tight
[08:58] <seb128> we would first to fine somebody with cycles/wanting to work on that
[08:58] <seb128> find
[08:59]  * duflu offers a spare bicycle
[08:59] <seb128> lol
[08:59] <robert_ancell> duflu, we need tricycles dammit!
[08:59] <seb128> not sure that's going to help there but thanks :-)
[09:00]  * duflu rolls off via unicycle
[09:00] <seb128> robert_ancell, any idea how much work it is to port aptdaemon to pkgkit 1?
[09:00] <robert_ancell> seb128, I've previously looked at the code (and did just then) and it looks difficult to me unless you know the codebase.
[09:01] <robert_ancell> seb128, But the issue is we can never run both aptdaemon and PackageKit at the same time
[09:01] <seb128> why not?
[09:01] <robert_ancell> seb128, Doesn't aptdaemon provide the D-Bus interface?
[09:01] <seb128> well, they can't both do system changes at the same time you mean?
[09:01] <robert_ancell> They can't own the same bus name
[09:01] <willcooke> morning/evening all
[09:02] <robert_ancell> pitti, ^ that's what aptdaemon does right?
[09:02] <seb128> robert_ancell, seems you are right :-/
[09:02] <seb128> there goes that idea
[09:02] <seb128> willcooke, "good" morning
[09:02] <pitti> robert_ancell: correct, they Conflicts: to each other
[09:02] <robert_ancell> seb128, so the issue is by updating to PK1.0 is we break aptdaemon for everyone as it uses both the client libraries and it's own server implementation.
[09:03] <robert_ancell> seb128, by packaging PK0.8 we can avoid that
[09:03] <seb128> robert_ancell, it doesn't solve the conflicts
[09:03] <seb128> so we still need to port $world
[09:03] <seb128> we are basically screwed
[09:03] <robert_ancell> seb128, right, but it's not installed on Ubuntu. The other flavours, probably.
[09:03] <robert_ancell> I guess the tools need to support both.
[09:03] <seb128> shrug
[09:04] <seb128> like everybody is behind their schedules/features
[09:04] <robert_ancell> yeah
[09:04] <seb128> I don't see how we can get that much work done
[09:04] <robert_ancell> we're being killed by technical debt
[09:05] <seb128> or by trying to do a transition that doesn't give us much out of switching techs for the sake of switching
[09:05] <seb128> though it's getting more complicated due to new goals sort of forcing us there now
[09:05] <robert_ancell> seb128, the big win is getting out of this debt trap
[09:06] <seb128> that's not a win
[09:06] <robert_ancell> How's that not a win?
[09:06] <seb128> those stacks are being deprecated after the coming LTS anyway
[09:06] <robert_ancell> seb128, I'll believe it when I see it!
[09:07] <seb128> the old stacks have tech debts but they mostly work and we could roll on them for another cycle
[09:07] <seb128> anyway that discussion is not relevant since as said, new goals force us to move forwards now
[09:07] <robert_ancell> seb128, there's always options
[09:07] <larsu_> morning!
[09:08] <willcooke> morning larsu
[09:08] <seb128> hey larsu
[09:08] <larsu> morning seb128 and willcooke!
[09:08]  * larsu has a bit of a sore throat again
[09:09] <seb128> seems you don't get out of that since the end of summer :-/
[09:11] <larsu> apparantly, yeah
[10:01] <seb128> mvo, hey, if we want to port apturl/language-selector/update-notifier/software-properties/update-manager from aptdaemon to packagekit, do you know if there is anything that might prove problematic there? or pkgkit with aptcc should cover what we need?
[10:05] <mvo> seb128: they are conceptually similar so that should be not too hard
[10:06] <pitti> I can't remember, do we still use plugins for the old "apt" backend in language-selector?
[10:06] <pitti> if we use aptcc, that doesn't support plugins
[10:06] <pitti> but aptdaemon does
[10:06] <seb128> pitti, good question, how would that look like?
[10:07] <pitti> language_support_pkgs.py:    '''PackageKit WhatProvides plugin for locale().'''
[10:08] <pitti>       entry_points='''[aptdaemon.plugins]
[10:08] <pitti> modify_cache_after=language_support_pkgs:apt_cache_add_language_packs
[10:08] <pitti> [packagekit.apt.plugins]
[10:08] <pitti> what_provides=language_support_pkgs:packagekit_what_provides_locale
[10:08] <pitti> ''',
[10:08]  * pitti scratches head
[10:08] <pitti> so, I think that doesn't affect the installation of missing langpacks in the installer or post-inst note
[10:08] <pitti> it was meant to install missing langpacks/fonts/dicts if you e. g. install libreoffice
[10:09] <seb128> I see
[10:09] <pitti> this would then automatically install e. g. the German libo dict/thesaurus along with iht
[10:09] <seb128> did that ever work?
[10:09] <pitti> not the most important feature in the world of course, but I think that still works
[10:09] <seb128> I never noticed
[10:09] <seb128> hum, k
[10:09] <pitti> if you use aptdaemon, yes
[10:09] <pitti> e. g. if you install it from software-center
[10:09] <pitti> not with apt-get of course
[10:09] <seb128> right
[10:09] <seb128> willcooke, robert_ancell, ^
[10:09] <pitti> but aptcc doesn't support plugins
[10:10] <seb128> the situation sucks
[10:10] <seb128> we are screwed either way
[10:10] <pitti> seb128: so, don't consider that a blocker
[10:10] <pitti> just wanted to point it out, and it was a bit of thinking aloud
[10:10] <seb128> thanks for pointing it out
[10:10] <pitti> the main functionality of installing dicts/fonts etc. during/post install shouldn't be affected
[10:10] <pitti> (and that's rather crucial)
[10:10] <seb128> we still need to port all the things from aptdaemon to packagekit
[10:11] <pitti> we also used to use the what-provides stuff for installing drivers, but that's obsolete
[10:11] <seb128> so quite some work
[10:11] <seb128> and it's getting late in the cycle
[10:11] <pitti> is PK still as slow as it used to be?
[10:11] <pitti> a few years ago it was aaaaachingly slow, compared to apt or aptdaemon
[10:11] <seb128> good question, I didn't try
[10:11] <seb128> robert_ancell might know
[10:11] <willcooke> robert_ancell mentioned it was slow the other day
[10:11] <robert_ancell> pitti, it's better than it was, I'm not sure if it's better/worse
[10:12] <robert_ancell> willcooke, I wasn't sure if that was mostly gnome-software
[10:13] <pitti> OOI, what's the pressure of moving to PK?
[10:13] <pitti> I know aptdaemon isn't maintained much these days, but porting+maintaining PK also seems to be no small task
[10:14] <pitti> do we need new APIs?
[10:14] <seb128> basically we want gnome-software
[10:14] <pitti> click also needed the old PK (but I guess that's widely known and has been discussed/fixed)
[10:14] <robert_ancell> pitti, it was dropping software-center, helping get away from Python 2, and getting a stack that's maintained actively upstream.
[10:14] <robert_ancell> getting new features like firmware updates
[10:15] <pitti> aptdaemon is py3
[10:15] <seb128> getting fwupdate also
[10:15] <pitti> ah, ok
[10:15] <robert_ancell> when we discussed it before it seemed like it would be a similar amount of work to add the features to the existing stack / fix the issues versus switching.
[10:15] <robert_ancell> But it seems we're running out of runway here
[10:17] <seb128> robert_ancell, I guess gnome-software doesn't work with aptdaemon as a backend?
[10:17] <robert_ancell> seb128, we could make it work
[10:17] <seb128> how much work would that be?
[10:17] <happyaron> seb128, mind to approve open-gram's SRU upload from queue (trusty)?
[10:17] <robert_ancell> I think by tomorrow I could give a yes/no to that
[10:17] <seb128> I've no idea how different aptdaemon/pkgkit are
[10:17] <happyaron> ah sorry for interrupting...
[10:18] <seb128> happyaron, I'm not in the SRU team, sorry
[10:18] <seb128> willcooke, ^
[10:18] <robert_ancell> seb128, gnome-software is super modular, so we can write a new backend and ignore packagekit entirely
[10:18] <seb128> robert_ancell, that might be the easiest option
[10:18] <happyaron> seb128: ic
[10:18] <robert_ancell> seb128, yeah, that's a good idea.
[10:18] <robert_ancell> It gives us a lot of the wins.
[10:18] <seb128> well aptdaemon is supposed to provide pkgkit compat apis no?
[10:18] <willcooke> seb128, @ SRU or @ porting g-s to aptdaemon?
[10:18] <seb128> willcooke, g-s to aptdaemon
[10:19] <willcooke> You won't believe me, but I just wondered that myself
[10:19] <robert_ancell> The unknown is the interaction with appstream. Not sure if we can / should switch to that.
[10:19] <robert_ancell> My guess is yes.
[10:19] <seb128> willcooke, I don't believe you!
[10:19] <seb128> :p
[10:19] <willcooke> :)
[10:19] <seb128> robert_ancell, I've no idea what appstream does...?
[10:19] <robert_ancell> seb128, metadata
[10:20] <robert_ancell> seb128, It replaces the xapian stuff. I don't know a huge amount about it, but Laney is the expert.
[10:20] <willcooke> seb128, video here:  seb128, I was thinking outside the box, or pushing the envelope or something
[10:20] <seb128> right
[10:20] <willcooke> erm,
[10:20] <willcooke> seb128, here:  http://video.fosdem.org/2008/maintracks/FOSDEM2008-packagekit.ogg
[10:20] <willcooke> http://www.freedesktop.org/software/PackageKit/pk-intro.html
[10:20] <willcooke> oh, ffs - ignore those totally wrong links
[10:21] <robert_ancell> willcooke, looking like a PHB there
[10:21] <seb128> willcooke, #fail
[10:21] <willcooke> :D
[10:21] <seb128> ;-)
[10:22] <willcooke> Let's try that again
[10:22] <willcooke> hurr durr here's a link   https://wiki.debian.org/DEP-11
[10:22] <robert_ancell> seb128, willcooke, ok, so my plan now is spend tomorrow writing an aptdaemon plugin for g-s and see if that can work. That will allow us to drop software-center from Ubuntu (other distros can continue to use if they like) and get the new feature goodness (firmware updates)
[10:23] <willcooke> this is a plan made of win
[10:23] <robert_ancell> If that works we keep the rest of the stack as is.
[10:23] <willcooke> win and string and glue
[10:23] <willcooke> thanks a lot robert_ancell
[10:23] <seb128> robert_ancell, +1, sounds like the best way forward
[10:23] <willcooke> good work team
[10:23] <seb128> robert_ancell, also isn't aptdaemon having pkgkit compat?
[10:23]  * willcooke goes to steady his nerves with some breakfast whiskey 
[10:24] <seb128> robert_ancell, did you try to use g-s with aptdaemon and the compat layer?
[10:24] <robert_ancell> seb128, yeah, but it's an older version of packagekit that wont work with g-s and probably doesn't implement all the functions required. g-s is very picky with packagekit.
[10:24] <seb128> k
[10:24] <robert_ancell> seb128, this will require us making a packagekit-1.0 source package I guess
[10:24] <robert_ancell> Unless someone really wants to update aptdaemon
[10:25] <seb128> what do we need packagekit 1.0 for in this case?
[10:25] <seb128> if we use g-s with aptdaemon
[10:25] <willcooke> will we need to port fwupd as well?
[10:25] <robert_ancell> seb128, g-s requires it otherwise we'd need to use an ancient version.
[10:25] <willcooke> if so, then I think that can come later < @fwupdate
[10:26] <robert_ancell> Or patch out the packagekit backend (which would be a bit drastic)
[10:26] <seb128> well, we don't need it if we use the aptdaemon one...
[10:26] <seb128> best option would still be to port aptdaemon to pkgkit 1.0
[10:26] <seb128> I'm going to try to have a look today at how much work that would be
[10:26] <robert_ancell> yeah, that scares me though
[10:26] <seb128> but you said it was not trivial?
[10:26] <seb128> did pkgkit change that much?
[10:27] <robert_ancell> Not a huge amount, but I think there's a lot of details
[10:27] <robert_ancell> If I was a PackageKit backend and aptdaemon expert it would probably be easy
[10:27] <robert_ancell> You should try though
[10:27] <seb128> k
[10:28] <seb128> we need mvo ;-)
[10:28] <robert_ancell> We've always known that
[10:29] <robert_ancell> ok, I'm going to call it a night.
[10:30] <seb128> robert_ancell, have a good night!
[10:30] <seb128> thanks for staying around and the discussion
[10:31] <ksamak> hey all
[10:33] <alexarnaud> hey ksamak
[10:34] <willcooke> thanks robert_ancell
[10:46] <pitti> . o O { gnome-terminal -x aptitude } *cough*
[10:46] <larsu> haha
[10:46] <larsu> nice one pitti ;)
[11:40] <seb128> Trevinho, could you rebase nautilus 19_unity_open_location_xid.patch and 20_add_timestamp_to_operations.patch on 3.14?
[11:40] <seb128> the changes you did you 3.18
[11:40] <Trevinho> seb128: ok
[11:40] <seb128> Trevinho, thanks
[11:41] <Trevinho> seb128: is the lp branch already rebased?
[11:41] <Trevinho> I mean, is already using the 3.14?
[11:41] <seb128> 20_add_timestamp_to_operations.patch applies fine out of chunck
[11:41] <seb128> @@ -5112,6 +5155,7 @@ nautilus_file_operations_copy (GList *fi
[11:41] <meetingology> seb128: Error: "@" is not a valid command.
[11:41] <seb128>  	job->done_callback_data = done_callback_data;
[11:41] <seb128>  	job->files = g_list_copy_deep (files, (GCopyFunc) g_object_ref, NULL);
[11:41] <seb128>  	job->destination = g_object_ref (target_dir);
[11:41] <seb128> +	((CommonJob *)job)->action_timestamp = timestamp;
[11:41] <seb128> Trevinho, I'm working on it, I guess I could commit and let you fix those then?
[11:42] <Trevinho> seb128: fine, ping me once you've the branch ready
[11:50] <seb128> Trevinho, done
[11:50] <seb128> Trevinho, you need to d/l http://ftp.acc.umu.se/pub/GNOME/sources/nautilus/3.14/nautilus-3.14.3.tar.xz and rename it nautilus_3.18.4.is.3.14.3.orig.tar.xz
[11:50] <seb128> on that note, lunch!
[12:19] <alexarnaud>  I'm trying to port Compiz package from Ubuntu to Debian
[12:19] <alexarnaud> I've compiled successfully and launching it withtout major issue except configuration
[12:19] <alexarnaud> I've investigated to compare environement vairiables in Debian Sid and Ubuntu Devel (16.04) and I noticed that Compiz use file named "65compiz_profile-on-session" which checks environement variable "DESKTOP_SESSION" but as I know it's not the standard way. The right environment variable is "XDG_CURRENT_DESKTOP". Why don't we use this variable ?
[13:23] <Sweet5hark>  great. libreoffice 5.1.0~rc2 package is all fine and good -- except on ppc64el, were it fails with a very meaningless build log.
[13:23] <Sweet5hark> *grumble* *grumble*
[13:24] <Sweet5hark> does ppc64el have more or less users than OS/2 by now? asking for a friend.
[13:30] <willcooke> Sweet5hark, :)
[13:40] <ksamak> didrocks: do you know anything about this env var that alex describes? DESKTOP_SESSION vs XDG_CURRENT_DESKTOP
[13:40] <ksamak> is that needed as for ubuntu? cause we'd need to implement a non-standart way otherwise.
[13:41] <didrocks> ksamak: I'm not on the desktop team anymore FYI :) but yeah, we are using (and proposed) XDG_CURRENT_DESKTOP to know under which env your are
[13:41] <didrocks> I'm sure other on the channel would be able to help you as well
[13:41] <GunnarHj> pitti: Hi Martin, just noticed bug #1541288, and it's far above my level. Is it something you could handle?
[13:41] <ubot5`> bug 1541288 in language-selector (Ubuntu) "Support PackageKit" [Undecided,New] https://launchpad.net/bugs/1541288
[14:08] <willcooke> Trevinho, https://plus.google.com/+PopescuSorin/posts/Ga5MjfaZoJ5
[14:09] <ogra_> gravity broke the sidebar ?
[14:09] <ogra_> :)
[14:10] <ksamak> willcooke: Trevinho would you know any reason why XDG_SESSION_DESKTOP is used? and not XDG_CURRENT_DESKTOP, in compiz 65compiz_profile-on-session script?
[14:12] <seb128> ksamak, I think it was there before XDG_CURRENT_DESKTOP existed
[14:12] <ksamak> seb128: ok. i guess that's ok then if we add a condition to take that into account
[14:13] <seb128> ksamak, well we could probably change to use the new variable
[14:14] <ksamak> seb128: well, either you can do that, or we can adapt. as you fell
[14:15] <seb128> ksamak, let's wait for what Trevinho thinks
[14:23] <pitti> :x
[14:42] <pitti> GunnarHj: I can't make any promises time-wise, I'm afraid
[14:43] <GunnarHj> pitti: Ok. Any suggestion about who could do it instead?
[14:43] <pitti> this was discussed this morning, I haven't followed who does what; but I figure Robert will drive the transition and look for people?
[14:44] <GunnarHj> pitti: I see. Thanks.
[14:55] <willcooke> hey GunnarHj, we have an alternative plan in progress at the moment which would mean we dont need to port everything to PL
[14:55] <willcooke> *PK
[14:55] <willcooke> but that is just a hope at the moment while we investigate
[14:56] <GunnarHj> willcooke: Ok, thanks for letting me know. I just made a note at the bug report, but I suppose Robert is aware of what you just said.
[14:57] <willcooke> he is
[14:57]  * willcooke crosses his fingers
[15:00] <Trevinho> ksamak: so... That's a legacy thing that is exported by a compiz-gnome thing.  I aactually thing we could get rid of that since we don't care about that file anymore... We all set at upstart level
[15:00] <Trevinho> that var isn't either set
[15:07] <ksamak> Trevinho: so, if we get rid of that script, then ubuntu is still working. What about debian? should we modify that same script? so that COMPIZ_CONFIG_PROFILE is set correctly?
[15:10] <Trevinho> ksamak: well, since there's no unity in debian I think that's not need there as well
[15:14] <ksamak> Trevinho: well, one could imagine that people want different settings, according to a desktop?
[15:14] <ksamak> otherwise that'd kinda focus compiz on mate?
[15:15] <Trevinho> ksamak: sorry, what you mean?
[15:15] <Trevinho> The ubuntu profile was actually the profile for unity...
[15:16] <Trevinho> Mate should export his own profile in a startup script they have I guess
[15:16] <Trevinho> compiz-gnome package was acually quite hacked to be unitysh... We should have got rid of it, really...
[15:22] <ksamak> Trevinho: ok. question is, should we have gsettings.override for each desktop, in packages like mate-compiz-settings-XXX, or compiz loaded with different profiles in /etc/compizconfig/config according to XDG_CURRENT_DESKTOP
[15:23] <ksamak> probably it would be nice to just have to install compiz, and have it start with a working profile, for different desktops.
[15:23] <ksamak> so we should probably use XDG_CURRENT_DESKTOP now
[15:25] <Trevinho> ksamak: yeah, that's correct... However that script is not doing anything for that
[15:28] <ksamak> yeah, ok. what'd be the solution? should we submit a patch to you that works with XDG_CURRENT_DESKTOP?
[15:28] <ksamak> then you adapt?
[15:29] <ksamak> Trevinho:
[15:30] <ksamak> is there actually a good solution for you with unity and XDG_CURRENT_DESKTOP?
[15:31] <Trevinho> ksamak: that's fine... I've not been looking at compiz config for ages, but I think that having it to smartly pick the proper profile would be nice... However at unity level we've some mismatch as the profile is called "unity", and the compiz_config_ env has to stay to "ubuntu", while XDG_CURRENTE_DESKTOP="Unity" -_-
[15:31] <Trevinho> But we can sitll handle with env var as it used to be.
[15:32] <ksamak> ok.
[15:32] <ksamak> let's do that then
[15:39] <ksamak> didrocks: you did the session-migration package. in your opinion, could it be useful in the future for debian users? is the settings migration such a burden in the end?
[15:41] <didrocks> ksamak: it is, unsure if debian wants it
[15:41] <didrocks> I would say not required before there is a need :)
[15:43] <seb128> hey didrocks
[15:43] <seb128> didrocks, did you look at the nm error yesterday?
[15:50] <ksamak> didrocks: i'd agree, we'll package without then.
[15:50] <ksamak> thx
[15:53] <didrocks> yw!
[15:59] <GunnarHj> Hi Laney, do you have time to take a look at bug #1539885? There shouldn't be any obstacles.
[15:59] <ubot5`> bug 1539885 in trusty-backports "Please backport svtplay-dl 0.30.2016.01.10-1 (universe) from xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1539885
[16:08] <ximion> larsu, Lenay: hi! do you happen to be there?
[16:08] <ximion> Laney ^
[16:19] <willcooke> ximion, Laney is off today
[16:19] <willcooke> GunnarHj, fyi too ^
[16:20] <ximion> willcooke: he deserves it ;-)
[16:20] <willcooke> +1 :)
[16:20] <willcooke> ximion, thank you too for all your help at the sprint
[16:20] <ximion> thank you for inviting me :)
[16:21] <willcooke> you're very welcome!
[16:21] <ximion> I am just working on fixing some GS bugs, but one of these things will need us to carry around a patch forever, since upstream will never accept that behavior change upstream anymore8they just removed the feature)
[16:22] <willcooke> ximion, I think we /might/ end up with a few of those.  We're investigating porting g-s back to aptd because of all the rdepends we would have to fix otherwise
[16:23] <ximion> atm, GNOME Software will not show anything which doesn't have a metainfo file - you could change that previously via a config option, but that option got removed too now, and I want to give people a bit more time to write metainfo files
[16:23] <ximion> also, there are some usability issues with metainfo-only
[16:24] <ximion> willcooke: to be honest, using GS with aptd would be a terrible idea - it is using some PK-isms and relying on them, and fixing all of that in aptd will be really hard
[16:25] <ximion> larsu just found the reason why remove doesn't work at the sprint, and the reason is a really subtle API issue where aptcc does something slightly different that Fedora's hif backend
[16:25] <ximion> leading to breakage. With aptd, you would get a lot more of these
[16:52] <Trevinho> Uff, I can't attach a debdiff to launchpad... :-(
[16:53]  * ogra_ hands Trevinho some superglue
[16:54] <flocculant> don't use teeth to open that ...
[16:55] <seb128> Trevinho, why not?
[16:56] <Trevinho> seb128: got an error for 5 minutes... Now it worked. I guess it's thanks to ogra_'s superglue!
[16:56] <Trevinho> ogra_: thanks! :-D
[16:56] <seb128> ximion, use g-s with an aptd backend seems like the only reasonable alternative though, so if it's not possible we might just end up staying on software-center
[16:56] <ogra_> lol
[16:56] <Trevinho> seb128: so.... now (well add to your list actually) you could get this a look https://bugs.launchpad.net/ubuntu/+source/zeitgeist/+bug/919801/comments/47
[16:57] <ubot5`> Launchpad bug 919801 in zeitgeist (Ubuntu) "Unity dash file search is extremely slow" [Medium,In progress]
[16:57] <Trevinho> or is maybe Laney better for that?
[16:57] <seb128> ximion, since aptdaemon claims the packagekit dbus name they can't be co-installed, so we would need to port everything in the archive from aptdaemon to packagekit which doesn't seem feasable before feature freeze this cycle
[16:57] <seb128> Trevinho, k, adding to the list
[16:58] <Trevinho> ouch, forgot to add the headers descriptions...
[16:58] <ximion> seb128: what elase is using aptdaemon?
[16:58]  * Trevinho fixes that
[16:58] <seb128> Trevinho, do you look at refreshing the nautilus patches?
[16:58] <Trevinho> seb128: not yet, I wanted to finish this first...
[16:58] <Trevinho> I would have done it now... But let me addd the descriptions first
[16:58] <Trevinho> then I'll do that
[16:59] <seb128> ximion, apturl update-notifier update-manager lubuntu-software-center software-properties language-selector oem-config-gtk(it's in ubiquity)
[16:59]  * Trevinho 's TODO list is filling everyday with more stuff...... -_-
[16:59] <seb128> Trevinho, welcome to the club!
[16:59] <ximion> seb128: if the tools using aptd via PK are using normal PK calls, they should just depend on PK instead, and aptd should stop claiming to be PK - in that case, co-installing PK and aptd should work easily
[17:00] <seb128> ximion, no, most use the aptdaemon widgets
[17:00] <seb128> like AptProgressDialog
[17:00] <ximion> seb128: have yu tried making aptd stop taking the PK DBus name? I think previously there even was a aptdaemon-pkcompat package shipping just the PK compatibility stuff
[17:00] <seb128> http://bazaar.launchpad.net/~robert-ancell/software-properties/no-aptdaemon/revision/953 is an example of code that robert_ancell started changing
[17:02] <seb128> ximion, no, that would be the other option I guess, looking at changing aptdaemon, unsure we have people knowing the codebase available to work on it though :-/
[17:03] <ximion> seb128: seems to be a reason to maybe not have it in the release by default :P - btw, I did a non-aptd patch for s-p ages ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730807
[17:03] <ubot5`> Debian bug 730807 in software-properties "Please make SP use PackageKit for Apt-write actions" [Wishlist,Open]
[17:03] <ximion> not polished though, merely a demonstration thing
[17:04] <seb128> ximion, thanks for the pointer
[17:05] <seb128> so packagekit has no equivalent to AptProgressDialog?
[17:05] <ximion> no, PackageKit itself has no widgets at all, it's purely non-GUI
[17:05] <Trevinho> seb128: so proper patch should be there...
[17:06] <Trevinho> seb128: moving to nautilus now..
[17:06] <seb128> Trevinho, thanks
[17:06] <ximion> seb128: you can write your own widgets for it though (maybe at a central place and make other stuff use it then?)
[17:06] <ximion> I really think fixing aptd and aptd-using packages will be *much* easier than porting GS to use aptd
[17:07] <seb128> fixing aptd how?
[17:07] <ximion> not making it claim to be PK
[17:07] <ximion> to make both packages co-installable
[17:07] <seb128> I guess we could keep the widgets but make it call packagekit
[17:08] <ximion> that would be even easier, I guess
[17:08] <seb128> the other issue raised it that it seems packagekit is slow compared to aptd
[17:08] <seb128> but I guess we are going to have to have this way
[17:10] <ximion> PK is only slow if you use it in sync mode
[17:10] <ximion> but yeah, PK's design of shipping everything over DBus in small transactions makes the whole thing a bit slower then aptd, even though PK is written in C
[17:10] <ximion> one way to speed it up would be to make the aptcc backend use parallel transactions, which requires a threadsafe APT API
[17:11] <ximion> not sure if where are there already so this could work
[17:11] <ximion> at time, read actions are processed sequentially, which to no suprise is slow
[17:11] <seb128> I see
[17:12] <seb128> well I guess that work is not going to be for this cycle anyway
[17:12] <seb128> thanks for the input!
[17:15] <ximion> seb128: let's see, the last input on that I got from the APT team was quite positive
[17:15] <ximion> but it's unlikely to happen for the next release, that's right
[17:17] <larsu> ximion: ah cool thanks for tracking that down :)
[17:19] <ximion> larsu: I will prepare a fix for aptcc when I am done with the icon stuff on the generator and with injecting at least the unlocalized long descriptions of packages into the AppStream metadata
[17:19] <ximion> I think adding the descriptions to the metadata is the better long-term solution, before we drop support for apps without metainfo files
[17:20] <qengho> pitti: Hi. I have a patch for grub that fixes a problem in searching for devices. It only runs for zfs root and fixes a problem upstream isn't concerned with. Please take a look?  Debdiff at end of  https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1527727
[17:20] <ubot5`> Launchpad bug 1527727 in grub2 (Ubuntu) "grub-probe for zfs assumes all devices prefix with /dev, ignoring /dev/disk/..." [Medium,Confirmed]
[17:20] <ximion> larsu: since upstream removed the require-appdata option a while back - that's why I was suprised at the spring that it even existed ^^
[17:21] <larsu> ximion: ah that makes sense. Yeah I agree
[17:22] <larsu> ximion: please talk to robert_ancell about this as well (he's in .nz and not online right now)
[17:22] <larsu> ximion: or Laney I guess :)
[17:22] <ximion> I will wait for someone to implement the translation stuff then ^^ - since that will be much harder to do right. Maybe it won't even be needed and upstreams will ship metainfo files faster to get properly localized anetries
[17:22] <ximion> *entries
[17:22] <larsu> *maybe* :D
[17:23] <ximion> from my experience: likely not
[17:23] <larsu> ya...
[17:23] <ximion> but never give up hope :P
[17:24] <larsu> haha yeah
[17:24]  * larsu has to go
[17:25] <larsu> sorry
[17:25] <larsu> see you tomorrow or so
[17:55] <willcooke> ximion, seb128  - sorry was in a meeting
[17:59] <seb128> willcooke, no worry
[18:34] <Trevinho> seb128: I'm about to finish the sync, but need to go to out.. I'll push tomorrow
[18:35] <Trevinho> seb128: area also troubles with the wallpaper patch? I get a link error
[18:53] <andyrock> Laney: around?
[18:53] <Laney> andyrock: slightly
[18:53] <Laney> depends if you want something hard
[18:53] <andyrock> nope just an info
[18:54] <andyrock> there will be a local database of desktop files of the "installable" application when the transaction to g-s will be completed?
[18:55] <Laney> yeah, appstream is that
[18:55] <seb128> Trevinho, no worry, try to pull --overwrite maybe, I did fix some fuzzy bits a bit earlier and had issues with my checkout so pushed --overwrite
[18:56] <andyrock> Laney: /usr/share/appdata does not contain desktop files
[18:56] <Laney> you want actual desktop files?
[18:56] <Laney> nope
[18:56] <andyrock>  something like usr/share/app-install/desktop
[18:57] <andyrock> mmm we kind of need that for bamf
[18:57] <andyrock> I'll figure out something
[18:57] <andyrock> thanks for the info
[18:57] <Laney> for uninstalled things?
[18:57] <andyrock> to recognize app that are about to be installed
[19:02] <Laney> you have the icon and desktop file name and stuff from appstream
[19:04] <andyrock> Laney: but bamf requires the full path if the desktop file is not on a standard path
[19:05] <andyrock> the desktop file name is not enough if the installer has not yet installed the desktop file in /usr/share/applications
[19:06] <andyrock> I'll talk with Trevinho and we (he) will figure out something :D
[19:06] <Laney> how do you get the full path from app-install-data?
[19:06] <andyrock> the desktop files are there
[19:07] <Laney> what's that got to do with the path they end up in?
[19:07] <andyrock> well if you say to bamf: create me a new app so i can monitor it from the desktop id "gedit.desktop"
[19:07] <andyrock> bamf is going to look at the standard paths
[19:07] <andyrock> usr share applications and so on
[19:08] <andyrock> right now when you install an app using ubuntu-software-center
[19:08] <andyrock> u-s-c send to the launcher a full path to the dekstop files in /usr/share/app-data/desktop
[19:09] <andyrock> *sends
[19:09] <andyrock> so bamf is able to create a new app and unity is able to monitor it
[19:10] <andyrock> in a nuthsell g_desktop_app_info_new("gedit.desktop") returns NULL if gedit is being installed
[19:14] <Laney> andyrock: is it just so you can already add the launcher when a thing is being installed?
[19:15] <Laney> or is there something more to it?
[19:15] <andyrock> yep
[19:15] <andyrock> just that
[19:15] <andyrock> but there is another way ofr sure
[19:15] <andyrock> for sure
[19:15] <Laney> and then it is updated to the real desktop file / path later on?
[19:15] <Laney> by software-center telling you to do that or something
[19:15] <andyrock> yep
[19:15] <andyrock> it's bamf
[19:15] <andyrock> it's smart enough
[19:16] <andyrock> worst case we'll generate a temporary dekstop file using app stream data
[19:16] <andyrock> just for the name/icon
[19:17] <Laney> yeah pretty sure appstream has what you need for this
[19:17] <Laney> (y)
[19:25] <attente> i'm getting a '503  DNS error for hostname ubuntu: Name or service not known. If ubuntu refers to a configured cache repository, please check the corresponding configuration file.' error with apt-cacher-ng
[20:18] <willcooke> gnight all
[20:18] <willcooke> actually
[20:18] <willcooke> I'll catch up with robert first
[20:18] <willcooke> going afk for a bit though
[20:25] <didrocks> see you willcooke :)
[20:29] <seb128> didrocks, thanks for fixing the nm bug
[20:30] <seb128> didrocks, the second patch was removing the assert still, but different from the git one that was reverted?
[20:30] <didrocks> yw, thanks for pointing this at me seb128 :)
[20:30] <didrocks> yeah
[20:30] <seb128> yw!
[20:30] <didrocks> I did misread it at first
[20:30] <seb128> k
[20:30] <seb128> still at the office? or already back to the hotel?
[20:30] <didrocks> still at the office, days are crazy here :/
[20:31] <seb128> :-(
[20:31] <didrocks> (started at 8am, and same thing since Monday)
[20:32] <willcooke> who's laughing now?!??!?
[20:32] <willcooke> not me
[20:32] <willcooke> or seb
[20:32] <willcooke> or robert
[20:32] <willcooke> well, this was a bad argument
[20:33] <seb128> on that note, going to watch some IT crowd episodes ;-)
[20:34] <seb128> didrocks, good luck
[20:34] <willcooke> night seb128
[20:36] <didrocks> seb128: enjoy
[20:39] <pitti> Laney: argh, now I need yet another archive grep..
[21:26] <ximion> Laney: when you are back: please pull from master to get updates for the dep11-generator when you have the time
[21:27] <ximion> I found out we broke the icon logic afterall at the sprint ^^
[21:27]  * ximion pushes the fix soon
[21:38] <xnox> Laney, will you merge gnupg2? =) or may I steal it?
[21:40] <Laney> xnox: if the bug that I listed on merges.u.c is fixed
[21:40] <Laney> ximion: ok!
[21:40] <xnox> Laney, oh didn't see it. i'll check it out.
[21:41] <Laney> basically the answer is that it breaks stuff
[21:44] <Laney> pitti: yeah, good idea to take a second look at codesearch
[21:44]  * Laney goes away, see you tomorrow
[21:44] <pitti> night Laney!
[21:46] <sarnold> xnox: quite a lot changed with gnupg 2.1; it mostly looks for the better (the gpg-agent socket now has a well-known name and no more faffing about with trying to get an environment variable set before launching all the programs that may need it..  https://gnupg.org/faq/whats-new-in-2.1.html
[21:46] <xnox> sarnold, i am well aware. and a bunch of debian software breaks with keybox =)
[21:46] <sarnold> xnox: okay, good ;)
[21:46] <pitti> sarnold: oh nice, where is that?
[21:46] <xnox> sarnold, but having 1.4 and 2.0 is bad enough, but having 1.4 and 2.1 will be a bit nicer.
[21:47] <pitti> /home/martin/.gnupg/gpg-agent-info-donald ?
[21:47] <xnox> sarnold, such that hopefully i can unwind all the things to use 2.1. maybe not by this lts, but the one after.
[21:47] <sarnold> pitti: ~/.gnupg/S.gpg-agent iirc
[21:47] <pitti> sarnold: ok, I don't have that; (I'm currently exprimenting with i3, that might be the reason that I have troubls with the agent)
[21:47] <pitti> sarnold: thanks!
[21:48] <sarnold> pitti: oh fun :) I liked i3
[21:48] <pitti> wanted to see how a tabbed WM feels like
[21:50] <sarnold> I mostly abuse unity to pretend it's a tabbed WM.. it works just well enough that I haven't overcome the inertia of setting up the laptop-friendly widgets for a new WM.. :)
[22:04] <xnox> Laney, explain why you need that bug fixed.
[22:05] <xnox> Laney, in the new world order, the agent locations are known, thus no environment variables are needed to "share" it, or "discover" it.
[22:05] <xnox> Laney, my plan was to still e.g. export the vars in the upstart session job, but now simply with predictable names.
[22:05] <xnox> Laney, the upstart job can write that file out too. however we really don't need it, do we?
[22:06] <xnox> that bug is totally not a bug.
[22:06] <xnox> but a new feature.
[22:06] <xnox> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796931
[22:06] <ubot5`> Debian bug 796931 in gnupg-agent "gnupg-agent: no longer writes $GNUPGHOME/gpg-agent-info-$(hostname) file" [Serious,Open]
[22:07] <xnox> also, i don't see that file written on ubuntu right now, anyway, either....
[22:07] <xnox> agent is running and i don't have that file.
[22:10] <sarnold> pitti's got it, I wonder what created it :)
[22:24] <pitti> sarnold: supposedly /etc/X11/Xsession.d/90gpg-agent
[22:24] <sarnold> aha :)
[22:26] <Laney> xnox: If you break my setup that is a bug
[22:26] <Laney> I did the merge, I installed the package and I could no longer use the agent
[22:26] <Laney> So fix that or don't do the merge
[22:28] <Laney> It's an rcbug preventing it going to testing by the way
[22:30] <xnox> Laney, ack. And "your setup" is just a normal ubuntu desktop, with gnome-keyring, et. al.? right?
[22:30] <xnox> unity, not xmonad something rather, over vnc, in an lxd container, hosted in switzerland and accessed from canada? (you know stgraber like setups)
[22:30] <Laney> I explained in a posting to the bug
[22:30] <xnox> let me read it again then. i think i missed your post.
[22:31] <Laney> If you want to say "screw you" then get it closed in Debian first
[22:31] <Laney> and then fix or close the other rcbug too
[22:31] <Laney> and take the angry broken users on your own head
[22:32] <xnox> Laney, you know my solution right.....
[22:32] <xnox> it should be systemd socket activated, and have the socket in XDG_RUNTIME_DIR
[22:32] <xnox> having it in the GNUPGHOME is silly
[22:32] <xnox> "When I ssh into this container, keychain is used to start a gpg-agent" -> what is keychain?
[22:33] <xnox> what's inside the lxc container, well gpg, But does it have full desktop too inside the container, or just some script in ~/.bashrc to start an agent?
[22:33] <Laney> keychain starts it
[22:34] <Laney> eval $(keychain --eval --quick --quiet --agents gpg,ssh --host ${HOSTNAME})
[22:34] <xnox> ah, ok.
[22:34]  * xnox 's ubuntu has advised me to use apt-get to install keychain program
[22:35] <Laney> night!
[22:35]  * Laney is going to play a song or two on guitar hero
[22:35] <Laney> \m/
[23:02] <Trevinho> Laney: is that real guitar hero or FoF?
[23:02]  * Trevinho played with that (and with a PS guitar controller)
[23:18] <robert_ancell> ximion, do you know how to get the appstream package from the generator you and Laney set up? Laney said he had sent it but I can't find it anywhere
[23:19] <robert_ancell> Laney, oh, you are / were here
[23:20] <ximion> robert_ancell: hmm, I don't understand the question - which appstream package do you mean?
[23:20] <ximion> you mean the metadata? Laney has made a script for that
[23:20] <robert_ancell> ximion, yeah, where is that script?
[23:21] <ximion> it's at http://people.canonical.com/~laney/random-scripts/appstream.sh
[23:21] <robert_ancell> ximion, ta
[23:21] <ximion> not sure if it still works now that we have appstream.ubuntu.com
[23:23] <robert_ancell> ximion, seems to be working, thanks
[23:42] <robert_ancell> ximion, I'm confused about the appstream / packagekit relationship - does the G-S appstream plugin provide the list of available packages with metadata or does packagekit and appstream just refine them?
[23:44] <ximion> robert_ancell: the AppStream backend provides most of the metadata, the packagekit backend just refines it
[23:44] <ximion> by e.g. adding information about whether an application is installed or not, or what it's installed size will be
[23:46] <ximion> prior to PK 3.18, the packagekit backend also provided descriptions for some apps
[23:46] <robert_ancell> ximion, ok, I thought that was the case but wasn't sure
[23:46] <ximion> the current one just drops apps which don't have a description
[23:46] <ximion> I am working on a workaround for this right now, since upstream will not restore the previous behavior