[05:50] Hi === tjaalton_ is now known as tjaalton === shiznix_ is now known as shiznix [07:41] hello desktop [07:59] Good morning [07:59] Hello desrt. Would you like to play a game? [08:00] i know this one! global thermonuclear war! [08:00] pitti, duflu: hi :) [08:00] hey desrt! [08:00] hello duflu, how are you? [08:00] pitti: how's home? [08:00] Oh. Or is it "shall we play a game"? [08:01] desrt: nice and cozy, but as rainy as Brussels today :( [08:01] pitti: Hi, good. You? [08:01] desrt: how is the sprint? [08:01] duflu: good, thanks! [08:01] long nights due to our virtual sprints [08:02] pitti: the sprint is over [08:02] pitti: larsu and i are now in köln [08:02] (and i was not at the sprint anyway) [08:24] good morning desktopers [08:31] bonjour seb128 ! [08:31] hey pitti [08:32] hey robert_ancell [08:32] seb128, hi [08:32] robert_ancell, pitti, how are you? [08:32] seb128: bit tired, but good, thanks! how was your sprint? [08:33] pitti, I didn't go to that one, larsu_ and Laney did [08:33] how is your virtual one? [08:34] seb128: ah, I thought you were there as well, ok [08:34] seb128: took me three hours to get out of mojo's claws to finally install the CI train into juju-local :/ [08:34] so only went to bed at 1:30 [08:34] :-/ [08:34] seb128: but, getting to a point where the deployment docs are working, and I landed my first fix :) [08:35] robert_ancell, so if I understood your email correctly, nobody worked on porting the aptdaemon rdepends to packagekit? [08:35] pitti, good :-) [08:35] seb128, I was working on the software-properties-gtk one [08:36] robert_ancell, yeah, I saw a branch from you with some work [08:36] seems like we had a planning fail there :-/ [08:38] Morning folks [08:38] hey Trevinho! [08:39] seb128, I'm not seeing as much stuff as you are. The main ones are software-properties-gtk and language-selector [08:39] hey seb... How is it? [08:39] I believe language-selector is not a major problem [08:40] robert_ancell, well they are not problems, they are work [08:42] robert_ancell, update-notifier apturl software-center also use python-aptdaemon [08:42] seb128, well, software-center is going, so that doesn't matter [08:42] robert_ancell, is it? I though the plan was to keep it in universe [08:43] if it is then we need to fix things that rdepends on it in the same landing [08:43] like unity [08:43] also e.g xubuntu use it [08:43] are they fine switching to gnome-software? [08:43] same for ubuntukylin, studio, etc [08:45] seb128, not sure what they want to do. [08:45] it's getting complicated/tricky :-:/ [08:45] seb128, It's always been complicated/tricky! [08:46] yeah, but I though somebody was handling porting the rdepends to use packagekit [08:46] I should have followed that more closely [08:46] seb128, you got some spare cycles? [08:46] it's going to teach use to not have proper workitems lined up [08:46] Hello everyone :)! [08:46] not really [08:46] hey alexarnaud [08:46] how are you seb128 ? [08:46] I could make some, but on the detriment of other work [08:47] alexarnaud, good, though busy, you? [08:48] 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] good luck [08:49] Yesterday, I've discovered existance of debian helper [08:49] :) [08:52] hey willcooke :)! [08:56] 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] systems = non-Ubuntu distros [08:57] robert_ancell, what do you mean "package pk0.8"? [08:57] like have both versions in the archive? [08:57] seb128, yeah [08:57] robert_ancell, well, then we would still have to port software-properties language-selector apturl update-notifier update-manager etc [08:57] seb128, yep, that's still do-able [08:58] that's never going to be done by ff [08:58] it's on feb 18th [08:58] It's pretty tight [08:58] we would first to fine somebody with cycles/wanting to work on that [08:58] find [08:59] * duflu offers a spare bicycle [08:59] lol [08:59] duflu, we need tricycles dammit! [08:59] not sure that's going to help there but thanks :-) [09:00] * duflu rolls off via unicycle [09:00] robert_ancell, any idea how much work it is to port aptdaemon to pkgkit 1? [09:00] 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] seb128, But the issue is we can never run both aptdaemon and PackageKit at the same time [09:01] why not? [09:01] seb128, Doesn't aptdaemon provide the D-Bus interface? [09:01] well, they can't both do system changes at the same time you mean? [09:01] They can't own the same bus name [09:01] morning/evening all [09:02] pitti, ^ that's what aptdaemon does right? [09:02] robert_ancell, seems you are right :-/ [09:02] there goes that idea [09:02] willcooke, "good" morning [09:02] robert_ancell: correct, they Conflicts: to each other [09:02] 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] seb128, by packaging PK0.8 we can avoid that [09:03] robert_ancell, it doesn't solve the conflicts [09:03] so we still need to port $world [09:03] we are basically screwed [09:03] seb128, right, but it's not installed on Ubuntu. The other flavours, probably. [09:03] I guess the tools need to support both. [09:03] shrug [09:04] like everybody is behind their schedules/features [09:04] yeah [09:04] I don't see how we can get that much work done [09:04] we're being killed by technical debt [09:05] or by trying to do a transition that doesn't give us much out of switching techs for the sake of switching [09:05] though it's getting more complicated due to new goals sort of forcing us there now [09:05] seb128, the big win is getting out of this debt trap [09:06] that's not a win [09:06] How's that not a win? [09:06] those stacks are being deprecated after the coming LTS anyway [09:06] seb128, I'll believe it when I see it! [09:07] the old stacks have tech debts but they mostly work and we could roll on them for another cycle [09:07] anyway that discussion is not relevant since as said, new goals force us to move forwards now [09:07] seb128, there's always options [09:07] morning! === larsu_ is now known as larsu [09:08] morning larsu [09:08] hey larsu [09:08] morning seb128 and willcooke! [09:08] * larsu has a bit of a sore throat again [09:09] seems you don't get out of that since the end of summer :-/ [09:11] apparantly, yeah [10:01] 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] seb128: they are conceptually similar so that should be not too hard [10:06] I can't remember, do we still use plugins for the old "apt" backend in language-selector? [10:06] if we use aptcc, that doesn't support plugins [10:06] but aptdaemon does [10:06] pitti, good question, how would that look like? [10:07] language_support_pkgs.py: '''PackageKit WhatProvides plugin for locale().''' [10:08] entry_points='''[aptdaemon.plugins] [10:08] modify_cache_after=language_support_pkgs:apt_cache_add_language_packs [10:08] [packagekit.apt.plugins] [10:08] what_provides=language_support_pkgs:packagekit_what_provides_locale [10:08] ''', [10:08] * pitti scratches head [10:08] so, I think that doesn't affect the installation of missing langpacks in the installer or post-inst note [10:08] it was meant to install missing langpacks/fonts/dicts if you e. g. install libreoffice [10:09] I see [10:09] this would then automatically install e. g. the German libo dict/thesaurus along with iht [10:09] did that ever work? [10:09] not the most important feature in the world of course, but I think that still works [10:09] I never noticed [10:09] hum, k [10:09] if you use aptdaemon, yes [10:09] e. g. if you install it from software-center [10:09] not with apt-get of course [10:09] right [10:09] willcooke, robert_ancell, ^ [10:09] but aptcc doesn't support plugins [10:10] the situation sucks [10:10] we are screwed either way [10:10] seb128: so, don't consider that a blocker [10:10] just wanted to point it out, and it was a bit of thinking aloud [10:10] thanks for pointing it out [10:10] the main functionality of installing dicts/fonts etc. during/post install shouldn't be affected [10:10] (and that's rather crucial) [10:10] we still need to port all the things from aptdaemon to packagekit [10:11] we also used to use the what-provides stuff for installing drivers, but that's obsolete [10:11] so quite some work [10:11] and it's getting late in the cycle [10:11] is PK still as slow as it used to be? [10:11] a few years ago it was aaaaachingly slow, compared to apt or aptdaemon [10:11] good question, I didn't try [10:11] robert_ancell might know [10:11] robert_ancell mentioned it was slow the other day [10:11] pitti, it's better than it was, I'm not sure if it's better/worse [10:12] willcooke, I wasn't sure if that was mostly gnome-software [10:13] OOI, what's the pressure of moving to PK? [10:13] I know aptdaemon isn't maintained much these days, but porting+maintaining PK also seems to be no small task [10:14] do we need new APIs? [10:14] basically we want gnome-software [10:14] click also needed the old PK (but I guess that's widely known and has been discussed/fixed) [10:14] pitti, it was dropping software-center, helping get away from Python 2, and getting a stack that's maintained actively upstream. [10:14] getting new features like firmware updates [10:15] aptdaemon is py3 [10:15] getting fwupdate also [10:15] ah, ok [10:15] 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] But it seems we're running out of runway here [10:17] robert_ancell, I guess gnome-software doesn't work with aptdaemon as a backend? [10:17] seb128, we could make it work [10:17] how much work would that be? [10:17] seb128, mind to approve open-gram's SRU upload from queue (trusty)? [10:17] I think by tomorrow I could give a yes/no to that [10:17] I've no idea how different aptdaemon/pkgkit are [10:17] ah sorry for interrupting... [10:18] happyaron, I'm not in the SRU team, sorry [10:18] willcooke, ^ [10:18] seb128, gnome-software is super modular, so we can write a new backend and ignore packagekit entirely [10:18] robert_ancell, that might be the easiest option [10:18] seb128: ic [10:18] seb128, yeah, that's a good idea. [10:18] It gives us a lot of the wins. [10:18] well aptdaemon is supposed to provide pkgkit compat apis no? [10:18] seb128, @ SRU or @ porting g-s to aptdaemon? [10:18] willcooke, g-s to aptdaemon === asac` is now known as asac [10:19] You won't believe me, but I just wondered that myself [10:19] The unknown is the interaction with appstream. Not sure if we can / should switch to that. [10:19] My guess is yes. [10:19] willcooke, I don't believe you! [10:19] :p [10:19] :) [10:19] robert_ancell, I've no idea what appstream does...? [10:19] seb128, metadata [10:20] seb128, It replaces the xapian stuff. I don't know a huge amount about it, but Laney is the expert. [10:20] seb128, video here: seb128, I was thinking outside the box, or pushing the envelope or something [10:20] right [10:20] erm, [10:20] seb128, here: http://video.fosdem.org/2008/maintracks/FOSDEM2008-packagekit.ogg [10:20] http://www.freedesktop.org/software/PackageKit/pk-intro.html [10:20] oh, ffs - ignore those totally wrong links [10:21] willcooke, looking like a PHB there [10:21] willcooke, #fail [10:21] :D [10:21] ;-) [10:22] Let's try that again [10:22] hurr durr here's a link https://wiki.debian.org/DEP-11 [10:22] 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] this is a plan made of win [10:23] If that works we keep the rest of the stack as is. [10:23] win and string and glue [10:23] thanks a lot robert_ancell [10:23] robert_ancell, +1, sounds like the best way forward [10:23] good work team [10:23] robert_ancell, also isn't aptdaemon having pkgkit compat? [10:23] * willcooke goes to steady his nerves with some breakfast whiskey [10:24] robert_ancell, did you try to use g-s with aptdaemon and the compat layer? [10:24] 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] k [10:24] seb128, this will require us making a packagekit-1.0 source package I guess [10:24] Unless someone really wants to update aptdaemon [10:25] what do we need packagekit 1.0 for in this case? [10:25] if we use g-s with aptdaemon [10:25] will we need to port fwupd as well? [10:25] seb128, g-s requires it otherwise we'd need to use an ancient version. [10:25] if so, then I think that can come later < @fwupdate [10:26] Or patch out the packagekit backend (which would be a bit drastic) [10:26] well, we don't need it if we use the aptdaemon one... [10:26] best option would still be to port aptdaemon to pkgkit 1.0 [10:26] I'm going to try to have a look today at how much work that would be [10:26] yeah, that scares me though [10:26] but you said it was not trivial? [10:26] did pkgkit change that much? [10:27] Not a huge amount, but I think there's a lot of details [10:27] If I was a PackageKit backend and aptdaemon expert it would probably be easy [10:27] You should try though [10:27] k [10:28] we need mvo ;-) [10:28] We've always known that [10:29] ok, I'm going to call it a night. [10:30] robert_ancell, have a good night! [10:30] thanks for staying around and the discussion [10:31] hey all [10:33] hey ksamak [10:34] thanks robert_ancell === Guest39001 is now known as fredp === fredp is now known as Guest91097 [10:46] . o O { gnome-terminal -x aptitude } *cough* [10:46] haha [10:46] nice one pitti ;) [11:40] Trevinho, could you rebase nautilus 19_unity_open_location_xid.patch and 20_add_timestamp_to_operations.patch on 3.14? [11:40] the changes you did you 3.18 [11:40] seb128: ok [11:40] Trevinho, thanks [11:41] seb128: is the lp branch already rebased? [11:41] I mean, is already using the 3.14? [11:41] 20_add_timestamp_to_operations.patch applies fine out of chunck [11:41] @@ -5112,6 +5155,7 @@ nautilus_file_operations_copy (GList *fi [11:41] seb128: Error: "@" is not a valid command. [11:41] job->done_callback_data = done_callback_data; [11:41] job->files = g_list_copy_deep (files, (GCopyFunc) g_object_ref, NULL); [11:41] job->destination = g_object_ref (target_dir); [11:41] + ((CommonJob *)job)->action_timestamp = timestamp; [11:41] Trevinho, I'm working on it, I guess I could commit and let you fix those then? [11:42] seb128: fine, ping me once you've the branch ready [11:50] Trevinho, done [11:50] 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] on that note, lunch! === hikiko is now known as hikiko|ln [12:19] I'm trying to port Compiz package from Ubuntu to Debian [12:19] I've compiled successfully and launching it withtout major issue except configuration [12:19] 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 ? === mzanetti_ is now known as mzanetti === hikiko|ln is now known as hikiko === alan_g_ is now known as alan_g|lunch [13:23] 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] *grumble* *grumble* [13:24] does ppc64el have more or less users than OS/2 by now? asking for a friend. [13:30] Sweet5hark, :) [13:40] didrocks: do you know anything about this env var that alex describes? DESKTOP_SESSION vs XDG_CURRENT_DESKTOP [13:40] is that needed as for ubuntu? cause we'd need to implement a non-standart way otherwise. [13:41] 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] I'm sure other on the channel would be able to help you as well [13:41] pitti: Hi Martin, just noticed bug #1541288, and it's far above my level. Is it something you could handle? [13:41] bug 1541288 in language-selector (Ubuntu) "Support PackageKit" [Undecided,New] https://launchpad.net/bugs/1541288 === alan_g|lunch is now known as alan_g [14:08] Trevinho, https://plus.google.com/+PopescuSorin/posts/Ga5MjfaZoJ5 [14:09] gravity broke the sidebar ? [14:09] :) [14:10] 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] ksamak, I think it was there before XDG_CURRENT_DESKTOP existed [14:12] seb128: ok. i guess that's ok then if we add a condition to take that into account [14:13] ksamak, well we could probably change to use the new variable [14:14] seb128: well, either you can do that, or we can adapt. as you fell [14:15] ksamak, let's wait for what Trevinho thinks [14:23] :x === s1aden is now known as sladen [14:42] GunnarHj: I can't make any promises time-wise, I'm afraid [14:43] pitti: Ok. Any suggestion about who could do it instead? [14:43] 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] pitti: I see. Thanks. [14:55] 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] *PK [14:55] but that is just a hope at the moment while we investigate [14:56] 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] he is [14:57] * willcooke crosses his fingers [15:00] 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] that var isn't either set [15:07] 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] ksamak: well, since there's no unity in debian I think that's not need there as well [15:14] Trevinho: well, one could imagine that people want different settings, according to a desktop? [15:14] otherwise that'd kinda focus compiz on mate? [15:15] ksamak: sorry, what you mean? [15:15] The ubuntu profile was actually the profile for unity... [15:16] Mate should export his own profile in a startup script they have I guess [15:16] compiz-gnome package was acually quite hacked to be unitysh... We should have got rid of it, really... [15:22] 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] probably it would be nice to just have to install compiz, and have it start with a working profile, for different desktops. [15:23] so we should probably use XDG_CURRENT_DESKTOP now [15:25] ksamak: yeah, that's correct... However that script is not doing anything for that [15:28] yeah, ok. what'd be the solution? should we submit a patch to you that works with XDG_CURRENT_DESKTOP? [15:28] then you adapt? [15:29] Trevinho: [15:30] is there actually a good solution for you with unity and XDG_CURRENT_DESKTOP? [15:31] 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] But we can sitll handle with env var as it used to be. [15:32] ok. [15:32] let's do that then === tkamppeter_ is now known as tkamppeter [15:39] 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] ksamak: it is, unsure if debian wants it [15:41] I would say not required before there is a need :) [15:43] hey didrocks [15:43] didrocks, did you look at the nm error yesterday? [15:50] didrocks: i'd agree, we'll package without then. [15:50] thx [15:53] yw! [15:59] Hi Laney, do you have time to take a look at bug #1539885? There shouldn't be any obstacles. [15:59] 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 === kenvandine__ is now known as kenvandine [16:08] larsu, Lenay: hi! do you happen to be there? [16:08] Laney ^ [16:19] ximion, Laney is off today [16:19] GunnarHj, fyi too ^ [16:20] willcooke: he deserves it ;-) [16:20] +1 :) [16:20] ximion, thank you too for all your help at the sprint [16:20] thank you for inviting me :) [16:21] you're very welcome! [16:21] 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] 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] 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] also, there are some usability issues with metainfo-only [16:24] 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] 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] leading to breakage. With aptd, you would get a lot more of these [16:52] Uff, I can't attach a debdiff to launchpad... :-( [16:53] * ogra_ hands Trevinho some superglue [16:54] don't use teeth to open that ... [16:55] Trevinho, why not? [16:56] seb128: got an error for 5 minutes... Now it worked. I guess it's thanks to ogra_'s superglue! [16:56] ogra_: thanks! :-D [16:56] 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] lol [16:56] 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] Launchpad bug 919801 in zeitgeist (Ubuntu) "Unity dash file search is extremely slow" [Medium,In progress] [16:57] or is maybe Laney better for that? [16:57] 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] Trevinho, k, adding to the list [16:58] ouch, forgot to add the headers descriptions... [16:58] seb128: what elase is using aptdaemon? [16:58] * Trevinho fixes that [16:58] Trevinho, do you look at refreshing the nautilus patches? [16:58] seb128: not yet, I wanted to finish this first... [16:58] I would have done it now... But let me addd the descriptions first [16:58] then I'll do that [16:59] 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] Trevinho, welcome to the club! [16:59] 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] ximion, no, most use the aptdaemon widgets [17:00] like AptProgressDialog [17:00] 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] http://bazaar.launchpad.net/~robert-ancell/software-properties/no-aptdaemon/revision/953 is an example of code that robert_ancell started changing [17:02] 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] 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] Debian bug 730807 in software-properties "Please make SP use PackageKit for Apt-write actions" [Wishlist,Open] [17:03] not polished though, merely a demonstration thing [17:04] ximion, thanks for the pointer [17:05] so packagekit has no equivalent to AptProgressDialog? [17:05] no, PackageKit itself has no widgets at all, it's purely non-GUI [17:05] seb128: so proper patch should be there... [17:06] seb128: moving to nautilus now.. [17:06] Trevinho, thanks [17:06] seb128: you can write your own widgets for it though (maybe at a central place and make other stuff use it then?) [17:06] I really think fixing aptd and aptd-using packages will be *much* easier than porting GS to use aptd [17:07] fixing aptd how? [17:07] not making it claim to be PK [17:07] to make both packages co-installable [17:07] I guess we could keep the widgets but make it call packagekit [17:08] that would be even easier, I guess [17:08]