=== robbiew is now known as robbiew_ === eeejay_away is now known as eeejay === bjf is now known as bjf-afk [00:07] is it too late to propose banshee for lucid? [00:09] eeejay, very funny [00:09] rickspencer3, obviously i am completely out of touch [00:10] eeejay, sorry man [00:10] we covered that in some depth at UDS [00:10] rickspencer3, ah, gotcha. and the verdict was no? [00:10] right [00:10] sticking with rhythm box for at least one more release [00:11] * eeejay is searching for meeting notes [00:11] actually, now that I think about it ... we didn't really cover it there [00:11] heh [00:11] I think we decided before we left, and only touched on it at the application selection meeting and the music store meeting [00:11] eeejay, why would you like banshee as the default music player? [00:12] speaking of which, are the major "desktop decisions" from UDS-L coalesced somewhere? [00:12] rickspencer3, i remember the major blocker being a11y. imho banshee has better a11y than rythmbox at this point. [00:13] dtchen, http://theravingrick.blogspot.com/ [00:13] of course, the real place to look is here: [00:13] http://piware.de/workitems/desktop/lucid/report.html [00:13] + it is really hard to spell rhythmbox [00:14] eeejay, well ... we're getting very mixed feedback about Banshee from current users, and also mixed messages about the roadmap [00:14] so for LTS, it was best to stick with rhythmbox [00:14] rickspencer3, ah, gotcha. [00:16] rickspencer3, anyway, a11y should not be a concern on banshee anymore in lucid+1, if users are repulsed by it, it's a different issue [00:16] yeah thanks to you [00:16] accessibility was certainly one key blocker [00:17] eeejay, "repulsed" might be a bit harsh [00:17] ;) [00:17] rickspencer3: thanks [00:17] dtchen, do you have any specific questions I can try to answer? [00:17] dtchen: not yet; I'll ping if/when I do. [00:18] err, rickspencer3 ^^ [00:18] dtchen, sounds good [00:18] though I will be dropping offline for the evening soon [00:18] you can always catch up with me tomorrow, or email me [00:19] right, e-mail is best for me, too [00:22] dtchen, rick.spencer@canonical.com === asac_ is now known as asac [01:27] Amaranth - does compiz need to read anything from GConf before it registers with the session manager? [01:29] chrisccoulson: not that I can tell, no [01:29] chrisccoulson: although it's pretty much one right after another [01:30] Amaranth - thanks === jtisme is now known as jtholmes === eeejay is now known as eeejay_away === eeejay_away is now known as eeejay [06:49] morning! I'll be away all this week as I'm giving my last ubuntu training session for companies :) [07:27] hello [07:47] Good morning [07:50] morning [07:58] bryce: thanks for the X requirements mail [08:04] tseliot: I am an upstream udev committer :) [08:05] pitti: aah, so you accepted your own commit :-) [08:05] tseliot: well, I did discuss it with Kay first [08:06] of course, that's the way it works, unless there's only 1 maintainer [08:06] is it just me or is the wiki down today? [08:07] for bryce and me, too [08:07] :-/ [08:09] Seems to be back up now, for me at least. I've not tried editing anything yet though... [08:10] Came back up about 40 minutes ago. [08:15] it's still down for me [08:15] hi pitti tseliot and others [08:16] hi baptistemm [08:16] whi is usually "responsible" of fontconfig, I did a packaging of 2 [08:17] ... 2.8.0 and ported the big patch inside, but I hardly understand how it works, so I would like a review [08:19] baptistemm: maybe asac knows [08:30] pitti, https://bugs.edge.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/444704 does it sound a valid bug for you? [08:30] Launchpad bug 444704 in gnome-disk-utility "should depend on crypsetup" [Undecided,New] [08:30] is it permitted to introduce new dependency in stable release? [08:39] it's not a bug I'd fix in a stable release [08:39] hm, I thought we'd install it by default even [08:39] * pitti reassigns to dk-disks [09:17] hello mvo [09:17] hey glatzor! [09:18] mvo, do you already have got any plany regarding the mime type handlers i software center? [09:19] glatzor: not yet - why? [09:19] glatzor: isn't that something that the session thing is doing? [09:19] or could be doing? [09:19] mvo, because I would like to query the data in sessioninstaller :) [09:19] glatzor: it should be easy to do with s-c [09:19] the data is in the xapian-db [09:21] mvo, in the long run it seems to make sense to merge sessioninstaller with software-center to share the widgets [09:21] * mvo nods [09:21] and the same data :) [09:23] hey glatzor mvo! [09:23] morning seb128 ! [09:30] hum, who is this guy who assign random bugs to the canonical desktop team now? [09:32] glatzor: agreed, I will see if I can work on this today, it should be relatively straightforward [09:32] xapian ftw! [09:33] hey seb128 [09:35] re [09:35] dsl ip change [09:35] I was saying, who is this guy assigning random bugs to canonical desktop team now? [09:36] seb128_: I just fixed those, BTW [09:37] pitti, thanks, I fixed some too and I noticed you changed some others already [09:39] who is that guy who merges poppler and screws up the versio number? [09:39] * pitti hugs seb128 [09:40] ups [09:40] * seb128_ hugs pitti [09:41] I think I did dch -i, then the new version update and forgot to change the revision [09:41] in any case good we don't want the debian version [09:41] we do now [09:41] they reverted the ABI change [09:41] they did revert upstream changes which I'm not sure is the way to go [09:41] and we don't really want a different API/ABI than Debian [09:41] well, was the abi change on purpose? [09:41] well, we'd have to fork all packages which use libpoppler-dev [09:42] we don't want a different api,abi than upstream [09:42] they will currently FTBFS [09:42] hello? [09:42] Debian is being ridiculous there [09:42] if the abi change was wanted upstream unstable is the right place to deal with it [09:42] playing undo upstream change is of no use [09:43] I don't want to keep distro patching upstream apis away [09:43] hm, they rejected the bug reports [09:43] grrr [09:43] this is hilarious [09:43] I told you that yesterday [09:43] * pitti goes to add a "if building on Ubuntu, use this poppler API, else use that" patch to cups then [09:43] libpoppler has no stable abi [09:44] what is the upstream bug for reference? [09:44] https://bugs.freedesktop.org/show_bug.cgi?id=25344 https://bugs.freedesktop.org/show_bug.cgi?id=25363 [09:44] Freedesktop bug 25344 in general "Fix for #2686 breaks printing (error -12)" [Critical,Resolved: notabug] [09:46] pitti, right, typical reaction from them there [09:46] they don't want to give garanty for libpoppler abi [09:46] customer applications should be using the glib bindings [09:46] I agree it's an issue [09:47] but what Josselin is doing is not useful either [09:47] in Debian unstable they could as well go over and fix the few applications using it [09:47] rather than patching away upstream changes [09:47] they will have to catch up with upstream at some point anyway [09:47] * pitti pokes joss to revert the change then [09:48] I doubt Debian wants to divert from upstream there [09:49] salut seb128_ [09:50] lut baptistemm [09:50] I did some packaging yesterday [09:52] I noticed [09:52] thanks but for stable updates you need extra steps, like adding a debdiff to the bug, giving justifications on why we need the update, etc [09:53] seb128_, nautilus packaging is buggy, there is a leftover from a patch i was working on [09:53] baptistemm, what is buggy? [09:53] okay, I'll the remaining steps tonight [09:53] you worked from a local checkout which had your changes? [09:53] s/is buggy/doesn't compile/ [09:53] no this is a debian patch I was working on [09:54] to integrate in my ppa to test to UI thing [09:54] that change is not in the ubuntu version [09:54] you probably used a locally modified source to base your work [09:55] no but it remains listes in debian/patches/series [09:55] get a fresh source from the mirror [09:56] the change is not coming from the ubuntu version [09:56] ou are working on a locally modified version [10:00] at least one can review fontconfig 2.8.0 which targets lucid :) [10:01] I'm not happy with this big patch lying in the packaging [10:01] it is a pain in the *ss to update [10:02] baptistemm, nobody likes having distro changes [10:02] but when we have some often that's for a reason [10:05] my complain is not about having distro patch but rather 1) this one is rather hard to update, and 2) I don't understand what it does but of lack of comments in the patch [10:05] but my fontconfig fu is low [10:13] pitti: seb128_: i think lightbreeze is assigning the bugs to canonical desktop since it is mentioned here.. > https://wiki.ubuntu.com/OneHundredPaperCuts#Patched%20Paper%20Cut%20Pipeline [10:13] but i'm still not sure how assigns or who is supposed to them though ;) [10:13] s/how/who [10:14] * pitti holds up his plate "work with upstream" [10:14] just dumping them on the desktop team's feet won't help anyone [10:14] especially not this cycle [10:14] ETOOMUCHTODO [10:14] it's not how FOSS works (or the desktop team's job either) [10:14] I'm happy to help where I can [10:15] but there is just too much to do right now [10:19] * mac_v feels there isnt a proper plan to actually fix bugs in the papercuts :/ , but rather everything has just been improperly hypothesized [10:22] mac_v, it's clear bugs don't get automagically fixed just because somebody decided to nominate those as hundredpapercut [10:22] it still help to build a list of usuability issues which would be nice to fix [10:24] seb128_: yeah , there is a big misunderstanding that the papercuts is actually a super squad to fix all the bugs , but folks dont know that only the suggestions are being make in hopes someone comes and fixes them ;) [10:25] made* [10:25] would be nice to fix that perception, it would perhaps stop people to nominate any bug as hundredpapercut because they figure that's what will make this bug open for 5 years fixed now [10:31] ex: > Bug #488129 :/ [10:31] Launchpad bug 488129 in nautilus "Nautilus usability" [Wishlist,Invalid] https://launchpad.net/bugs/488129 [10:36] seb128_, do you I pick git patches from 2-28 for gvfs and nautilus for the packaging update? [10:37] baptistemm, I get patches where they are, git, bugzilla, etc [10:37] why? [10:37] +want [10:40] I don't understand the question [10:40] "do you I" [10:41] is the question what I do? [10:41] or what you should do? [10:42] do you want I pick up git patches from 2-28 for gvfs and nautilus for the packaging update, I seen alex commited various fixes [10:43] dor do you prefer I just stick to latest releases, and we'll put patches later. [10:43] depends of what those changes fix [10:43] to be honest I'm not sure those updates will be accepted in karmic sru [10:43] do they fix any really annoying issue? [10:43] which is open on launchpad [10:44] we don't want to waste too much efforts on stable update now [10:44] we only want to fix issues annoying ubuntu users [11:47] mpt: hi.. do you have a list of how the IM clients use the label for the "invisible" status? empathy uses "hidden" but the gmail , yahoo and aol all use "invisible" , so does indicator applet... empathy being the odd one out , the empathy folks are willing to change it , they just want to know how others are named... [11:48] i'v seen an article of several IM clients being compared but dont recall where :( [11:48] does anyone use those things? ;) [11:48] lol ;) [11:48] (I'm a very light IM user, I've literally never forced my status) [11:48] mac_v, http://www.szetopia.com/im-presence [11:49] I'd go for "Automatic" and "Privacy" :) [11:49] mpt: awesome , thats the one [i think]... thanks :) [11:51] yup , thats the one i was looking for === MacSlow is now known as MacSlow|lunch [12:20] good afternoon everyone [12:20] hello chrisccoulson! [12:20] hey seb128_, how are you? === seb128_ is now known as seb128 [12:21] good! you? [12:21] mvo, the dist-upgrader acts weird on lucid, it wants to clean build-essential, gettext, g++ [12:21] and lot of other things [12:21] seb128 - yeah, not too bad thanks. i've just got back from town [12:21] so, time to make some coffee :) [12:21] I just got coffee too ;-) [12:22] I'm about to do my daily bootcharts [12:22] excellent :) [12:23] i'm going to have a look at gconf in a bit and try and figure out a way of avoiding that 500ms delay you see at the start of your session [12:23] I will try to spend some time on merges and updates too today [12:23] we are lagging being there [12:23] chrisccoulson, that would rock ;-) [12:23] yeah, i've not done much work on merges recently :( [12:23] i should do some ;) [12:23] don't worry about those [12:23] better to tackle login speed issues [12:23] we have time for updates and merges [12:24] we can wait for less buggy versions rather than jumping on early unstable [12:24] yeah, that sounds like a good plan [12:29] seb128: I have a look [12:37] mvo, I'm not sure why those were installed in fact, are they part of the default install? [12:43] seb128: I think we have it for dkms [12:44] mvo, don't bother with that, that's probably not something worth looking at in early lucid [12:44] not sure why I mentioned it ;-) === MacSlow|lunch is now known as MacSlow [13:06] is anybody else getting screen dimming too quickly in lucid? [13:07] ie being cut after like 1 minute inactivity [13:14] seb128: yep I got that too [13:14] got? you fixed it? [13:14] nope just put up with it [13:15] I wouldnt know how to fix it :) [13:27] vuntz, hey [13:28] vuntz, how would you make a .desktop hidden by default from a sysadmin perspective (ie not editing the package entry) [13:35] Amaranth, ^ [13:41] seb128: what do you mean exactly? [13:41] vuntz, let's say I'm a sysadmin and I don't want gedit in the menu [13:41] what should I do, which is not editing the .desktop or .menu [13:42] since those will be replaced on upgrade [13:42] no good way right now, I guess [13:44] installing a .desktop in /usr/local will not take over the /usr one right? [13:44] perhaps copying it into /etc/xdg/menus/ ? [13:44] oh [13:45] my best reply now is to dpkg-divert the ubuntu desktop [13:45] vuntz: add an exclude into a menu file in applications-merged/ ? [13:47] mclasen: ah, indeed [13:47] * vuntz never tried this [13:48] what format should that one have? [13:52] vuntz, hum, /usr/local/share/applications entry do overwrite /usr ones for the settings categories [13:52] do you know if that's wanted? [13:52] like if you try display-properties [13:52] settings = system, preferences [13:56] seb128: "If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used." [13:57] vuntz, well, should it overwrite those? [13:57] like if there is a gedit.desktop is both [13:57] should that be 2 entries or should it take only the first one? [13:57] and why does it work differently for the application menu and the system one [14:01] seb128: if they have the same name, /usr/local/share should win, yes [14:01] and it should work the same way [14:01] ok thanks [14:02] vuntz, ok thanks, I figured what was wrong [14:02] there was a gedit.desktop in my user dir [14:03] hello vuntz [14:04] gnome-settings-daemon-helper is only useful if you're running GTK1 applications isn't it? [14:05] chrisccoulson: I believe, yes [14:05] vuntz, oh btw I know where GUADEC is going to be now! ;-) [14:05] vuntz - awesome, we can remove it then :) [14:05] seb128: it's a secret! [14:05] chrisccoulson: what about not removing it and putting it another package? [14:06] vubtz - we could do, but we don't ship GTK1 anymore anyway [14:06] s/vubtz/vuntz [14:06] (stupid fingers) [14:06] chrisccoulson, use tab ;-) [14:06] there is only one v there [14:06] heh, that's handy :) [14:07] ah, theres 2 people if i type "se" [14:07] can't win everytime [14:14] chrisccoulson: does g-s-d-helper win us 2 seconds? :-) [14:14] pitti - unfortunately not :( [14:14] but it is cruft though ;) [14:19] mvo, hi, do you have a good algorithm for the de-duplication yet? [14:20] mpt: I have not done anything on this yet, the real challenge is making it fast [14:21] mvo, it seems like the sort of thing that could be calculated once whenever the repositories are changed/updated [14:22] mpt: possible [14:27] mvo, one complication is that if someone searches for "wesnoth-data", probably we should return that package, even though it's an integral part of Battle for Wesnoth [14:27] hmmm - "Various snmp software needs extracted MIBs from RFCs and IANA - which cannot be shipped - to be working as expected. Download and extract MIBs from RFCs and IANA?" Yes/No [14:27] ok :-/ [14:28] chrisccoulson, please tell me that's not in a GUI [14:28] mpt - it's a debconf question i just encountered whilst upgrading [14:28] mpt: I think we only should de-duplicate if there is a application and a package with the same information "wesnoth" app and "wesnoth" package. if we are too agressive on the de-duplication that will confuse people [14:28] darn [14:29] i've honestly got no idea whether i should select Yes or No. i guess i'll just drop a pin and see which one it lands on ;) [14:29] mvo, ok, that probably makes it faster too [14:29] mpt: or having a "search more" button or something, but not having a way for users to search the full namespace is not ideal [14:32] mvo, so tell me how silly this sounds [14:32] software item:: A piece of theoretically-installable software. Where `app-install-data` or an archive index refers to one or more applications inside a package, each application should be treated as a software item, but the package itself should not. All other packages should be treated as individual software items. [14:33] mvo, and then I'd clarify that the searchable text even for an application should include its package name [14:33] chrisccoulson, I got that one too [14:34] I just used the default option [14:34] mpt: give me a moment, I need to (carefully) parse it [14:34] seb128 - yeah, i did that too [14:34] i've still got no idea what it was really asking me to do though ;) [14:39] mpt: how about? software-item: [14:39] A package or a application. A application belongs into [14:39] exactly one package. If a search matches a application [14:39] and the package of this application only the application [14:39] is displayed in the search result. [14:41] an application isn't it? [14:42] mvo, maybe, but it's not just about search results [14:42] mpt: hm, so "System package/Net" will not show firefox? [14:42] mpt: or "System Package/Python" will not show python-wxtools [14:43] mpt: and only "Editra" and "PyShell" (the two apps that python-wxtools ships? [14:43] mvo, correct [14:43] mvo, but if you search for "python-wxtools" you would get back those two results [14:44] mvo, I don't know what you mean by "Net" there [14:44] mpt: "net" as a sub-section, its just a place holder [14:44] ok [14:45] mpt: I'm not sure its useful to de-duplicate it in the system tools category. if a user goes there, he expects (I assume) to see all package. I'm all in favor for de-duplication on searches [14:46] mpt: but if the user wants to browse a category in system packages, why should we hide something from him? he made the choice to go into this territory [14:46] mvo, we're not hiding it, it's right there in the "Developer Tools" department [14:47] mvo, "Tech Stuff" is not a place for every item, it's a place for those items that don't have a better home to go to [14:48] its a different approach of looking for items, I do think its "hidding" because its information that is not available to the user (a package entry) [14:48] even if he search he will only find apps, never the package [14:48] mvo, and then I'd clarify that the searchable text even for an application should include its package name [14:48] in the case of "python-wxtools" he will not be able to find the package, only the apps that are part of the package [14:48] right [14:49] mpt: please do not quote stuff that I already read, my point is a different one [14:49] ok, sorry I didn't understand you then [14:50] Remember we talked about working on ways of pulling things out of that department [14:50] e.g. fonts [14:50] which would mean they didn't appear in there any more, they appeared somewhere better [14:51] e.g. Graphics > Fonts [14:54] mvo, do you know how many packages there are that contain multiple applications? [14:56] in Main and Universe [14:56] I guess it partly depends on what tech stuff should mean. during the uds discussion it was said that its the "System package" place. if its the system package place I think people expect to find the system package there [14:56] if its not that, but just "other" with a new name, then that is different [14:58] *grumpf* disconnected [14:58] mpt: did you save anything after " ok, sorry I didn't understand you then" ? [14:59] (pasted) [14:59] thanks [14:59] mvo, if we showed every package in there, I don't think we could reasonably call it "System Packages" (or "Tech Stuff", for that matter), because gnome-games would be in there [15:00] So either it's "All Packages", or as you say, it's a souped-up "Other" [15:02] asac, do we need your gtk change to hide this warning in lucid? [15:02] The way I imagined it was, items appear only in one department (and one subsection) unless the maintainer specifically provides a secondary department(+subsection) [15:02] bbiab, meeting [15:06] sorry, something is not right with my network today [15:09] good morning all [15:09] pitti, does the dx team have a burn down charts set up? [15:10] hey rickspencer3 [15:10] morning rickspencer3 [15:10] hi seb128 [15:11] hi fagan [15:13] chrisccoulson, you were looking at some seahorse crash on session closing IIRC? [15:14] seb128 - the seahorse-agent crash with a gazillion duplicates? [15:14] yeah, that one is fixed in karmic-proposed now [15:14] chrisccoulson, is bug #439446 the same one? [15:14] Launchpad bug 439446 in seahorse "seahorse-daemon crashed with SIGSEGV in dbus_watch_handle()" [Medium,New] https://launchpad.net/bugs/439446 [15:14] that looks like a different bug [15:14] ok [15:14] thanks [15:15] that one has some 25 duplicates [15:15] I'm cleaning those now [15:15] seems also a crash at session closing [15:16] yeah, possibly. people get confused with those because they get the crash report when they log in [15:16] we should have a crash timestamp info clearly noted in the bug [15:17] to compare to the bug report time [15:33] rickspencer3, ping [15:33] rickspencer3, you are talking to yourself now? [15:33] seb128, kind of [15:34] I thought I was getting some serious irc lag, butt [15:34] now i know that I am ;) [15:34] lol [15:34] ok, time to be brave and try that glib 2.23.0 [15:34] if I don't come back that doesn't work great [15:37] seb128 - success? :) [15:37] yes! [15:38] let's get the crack in lucid ;-) [15:38] looks like glib 2.23.0 worked ok [15:43] hey pitti [15:44] seb128: what's hot and new about it? [15:44] hey djsiegel1 [15:44] sorry if those round-1 paper cuts were unexpected. We worked out at UDS that paper cuts with patches should be assigned to canonical-desktop-team, should we not do that? [15:44] seb128: from what i see yes. [15:45] we can drop it and file a RC bug to readd if nothing changes === bjf-afk is now known as bjf [15:50] pitti: ^^ [15:56] djsiegel1: if they were sent upstream, and have a patch, then please subscribe ubuntu-main-sponsors [15:56] which will also end up as being done by desktop team, but in a different context [15:56] ok [15:56] djsiegel1: I just reverted the flux from this morning, since few, if any, of them had applicable patches, and no rationale [15:57] it seems to me that this paper cut pipeline emphasises distro patching over upstreaming [15:58] Laney: yes it does [15:58] we did the opposite last cycle [15:58] and 15 paper cuts with patches rotted on the vine upstream [15:58] so we are trying distro-first this time [15:58] or, both simultaneously, rather [15:59] well, we will not apply things like string changes [15:59] unless they are also committed/accepted upstream [15:59] Hmm [15:59] ok [15:59] bug fixes are okay, of course, they just need to be submitted, but not accepted [15:59] Just because string changes are harder to apply? [15:59] string changes are a bit special in that regard (for translation issues) [15:59] ok [15:59] applying them is easy, but as soon as you do, you break all translations [16:02] I wonder if you could get upstreams on board for "paper cut days", like hug days but for patching [16:03] Laney: interesting [16:03] Laney: why not [16:04] real-time feedback might make everyone more happy [16:16] asac, it's the only diff we have over debian [16:16] asac, not being able to sync sucks [16:16] asac, I will drop it and reopen the lucid task for the bug I think [16:16]