[02:37] Argh. Stupid C libs which use #defines as exported functions. [02:39] !!! [02:40] Please don't #define gnome_keyring_attribute_list_new () in your header, even if it *is* a one-liner. [02:49] that sounds slightly dodgy [02:49] It works as long as you only care about C. [02:49] but not if you care about trying to use an API in python [02:50] Right. In that case, or say, C#, it's a royal pain in the arso. [02:50] Particularly if the one-liner it wraps depends on how gcc feels like laying out a union on this particular arch on this particular Monday. [02:52] \o/ FAIL [02:52] at least its easy to fix [02:52] unlike deleting a symbol [03:26] Mmm, dolmades. [03:41] Yum. I haven't had those for ages. [03:42] Neither had I, until lunch time :) [06:06] ♪ OOOooooh, it's fun to charter an accountant and sail the wide accountanceee ♫ [06:09] ! [06:15] lifeless: You can't tell me that you've never felt like breaking into song while dealing with banks! [06:16] no [06:16] or rather, yes, I can tell you that. [06:18] Not even the accountancyshanty? [06:19] -no- [06:20] I shall have to tut in disbelief as I drink my tea, then. === ara_ is now known as ara [07:16] hi [07:18] i need help [07:18] there's somebody [07:20] Seba: it is usually best to "just ask", but probably even better to do so in #ubuntu [07:21] okay [07:22] i need some opinions, please compare these themes, which one do you like more? http://img339.imageshack.us/img339/3923/comparison.png [07:24] and here another comparison of the same themes http://img84.imageshack.us/img84/4789/comparison2.png === hyperair is now known as Guest93522 [07:35] hello [07:52] Man, I wish it wasn't so easy to kill gnome-keyring-daemon. [07:56] RAOF: as in, by using it? [07:56] lifeless: Yes. [07:56] In possibly slightly buggy ways, but just by using it. [07:57] In fact, by using it through libgnome-keyring, too. [07:58] bzr shelve is the best thing since sliced bread. [08:16] good morning [08:34] bonjour didrocks [08:34] salut [08:34] Guten Morgen pitti [08:34] pitti: how was your week-end? [08:34] baptistemm: salut ;) [08:36] didrocks: pretty good! we've been to a trance/techno concert on Saturday night, with a famous DJ from Berlin ("Paul Kalkbrenner"), went for Bowling on Sunday, and some bicycling [08:36] didrocks: and I finally managed to tidy up our cellar [08:36] didrocks: how was your's? [08:36] oh, trance/techno, sounds good ;) [08:36] was a great party indeed [08:37] with DST we slept until 11 on Sunday.. [08:37] yeah, I can imagine! [08:37] pitti: well, I was alone at home this week-end. I went out between two rains to take some fresh air and had a long walk in parks. Apart from that, I had some time to continue working on Quickly and playing Final Fantasy 13 :) [08:38] oh, fortunately we still had some sun on the weekend [08:38] didrocks: ah, some gaming again? nice [08:38] I don't find a lot of time for that these days unfortuantely [08:38] * pitti plays Battle for Wesnoth every now and then [08:39] pitti: yeah, it was a long time I didn't play. But I can't resist to final fantasy :) [08:39] ahah, Battle for Wesnoth is good :) [08:39] (for beta testing, of course ;)) [08:39] hey didrocks & pitti, how are you? [08:39] didrocks: FF> ah, that's Manga style? [08:39] bonjour seb128! c'est bien, merci! [08:39] hey seb128! I'm fine thanks, ready for the week, and you? [08:40] oh, gdm has finished building; /me -> gdm debugging, off IRC for a bit [08:40] pitti: not really Manga (well, the older one had super deformed persons with big head and small body), but it's no more the case since FF 10 [08:40] didrocks, I'm good thanks, I can't say I'm ready for the week yet but maybe after coffee... :-) [08:40] *coffee is loading* [08:40] :) [08:40] hehe [08:41] I know what pitti means [08:41] I like BRuce Willis [08:41] the drawing etc [08:41] grabbing a cup of coffee, brb [08:42] i'm from argentina you know [08:42] here it is 4:40 am [08:43] I personally knew Mark SHuttleworth} [08:52] why do people here are so bad, and wont even say a hello [08:54] Seba: I said good morning when conntecting and you were already connected. Furthemore, not everyone is looking at IRC 100% all the time [08:58] seb128: remember when I said auto-login is not working on my parents box anymore? that was wrong and it works just fine. what caused the confusion was that the gnome-screensaver is now using lock_enabled=True by default (in karmic it was false) [09:00] mvo, oh ok, good [09:00] I reported a bug about the later, but I realize its difficult to fix, idealy it would not use the lock for auto-login systems [09:02] we need work to get autologin to work as you would like it to be working [09:02] you still ie get to enter your keyring password right now [09:03] so autologin is not really nopassword login [09:03] didrocks, I'm starting on updates, let me know if you want to do some today [09:04] doing rhythmbox, gtksourceview, pygtksourceview now [09:04] seb128: sure, I will. I'm just finishing some Monday cleanup first (probably will take still one hour) and then, jump into updates [09:04] I will do cleaning later [09:04] I got some 680 bug emails during weekend [09:05] urgh :( Only 300 hundreds for me. still ok but well… [09:05] seb128: right, the keyring password for network-manager I noticed too, shall I file a bugreport on this or is it on the radar already? [09:05] mvo, it's not a bug? [09:05] and it's not n-m [09:05] you would get it for empathy if it was not there [09:06] or for whatever you will start using the keyring [09:06] you need a password to unlock the keyring [09:06] I discussed a bit with ted [09:07] but that's not for lucid [09:07] seb128: *shurg* I worked around it by using /etc/network/interfaces so that NM does not ask for it [09:07] seb128: I think its not a regression (or is it?) so we should be fine [09:07] you can use an empty keyring password too [09:07] no it's not [09:07] * mvo nods [09:08] we got bugs about that since before hardy [09:08] it's better now, by then login into gdm was not unlocking the keyring for you [09:08] now it does if you use the same password for both [09:09] * pitti uploads the n+1st keyboard layout fix [09:11] go pitti go! [09:25] okay, then, good morning [09:26] I'm soy happy with my new netbook [09:26] you see, it's no easy at here Argentina, to buy a netbook [09:26] so dont just label me ""what a stupid thing to share with us [09:27] so, this is an Asus eee PC 100ha [09:27] using it right now [09:28] I have a question [09:29] nothing [09:29] well I have to go [09:33] heh :) I noticed noticed something funny, I use a panel on top with window list applet on top (like most people I guess). now with the new arraow for minimize/maximize I was confused for a moment. the arrow points downwards, but I want to make the window go upwards into the window list [09:35] I guess it works well as a metapher if the windows goes to the bottom panel [09:37] seb128: Doing some patch reviews, trying to work out why https://bugs.edge.launchpad.net/ubuntu/+source/enchant/+bug/474062 is marked as fixed in ubuntu? Any pointers for me? I've had a look and it doesnt seem that patch is fixed in lucid yet [09:37] Ubuntu bug 474062 in enchant "kmail crashes when composing message" [High,Fix committed] [09:37] stefanlsd, hey [09:37] looking [09:38] stefanlsd, I think I forgot about this one, I add it to my queue [09:39] seb128: cool. thanks, i can do it if you like and prep a sru for karmic [09:39] I don't really care about karmic right not to be honest, lucid is due soon and I don't see why people would stay on karmic [09:40] but feel free to work on that if you want [09:40] seb128: yeah. sure. ok, will wait for you to fix lucid :) [09:51] i'm trying to build firefox from bzr, but fail, see http://pastebin.ubuntu.com/405893/. Any advice? The branch lp:~mozillateam/firefox/awesome-browser-branding is not accessible at the moment [10:02] didrocks, doing gvfs libgnomekbd [10:02] seb128: ok, will be available in 5 minutes if all is going well (crossing fingers) [10:04] pitti: g'd morning, no one else has reported that bug (the incorrect mute icon at start up). This seems like a regression as I had this before but it was fixed when i changed the way I used the libindicate image api. I cannot reproduce it here and am uncertain where to go to from here. do you know of anyone else who has had similar issues ? [10:05] ronoc: it came up in the release meeting, but I'm not sure whether that all just originated from my testing [10:05] ronoc: so, from my POV it's fine to set this as "low" priority then === vuntz_ is now known as vuntz [10:05] if it doesn't affect a lot of systems [10:06] pitti, I'm going to spend the morning testing to see if I can catch any other 'oversights'- will keep an eye out for it though. [10:07] ronoc: don't waste too much time on it then; thanks for your efforts! [10:07] pitti: np as i said will test on 64bit later on to see again if it turns up ... [10:09] seb128: doing nautilus-action and alacarte [10:11] didrocks, ok, thanks [10:14] mvo: do you know which bit of code checks for new releases for VT logins? I just got a whole slew of python-apt "deprecated method" warnings when logging into a VT [10:14] * pitti doens't see anything in /etc/profile.d [10:15] pitti: I thought that is fixed now with the latest update-manager, but if not I can fix it [10:16] I just got it after a dist-upgrade, and rebooting [10:16] /usr/lib/update-manager/check-new-release [10:16] is the file [10:16] mvo: I assume that there's a cache somewhere? it doesn't happen at each login [10:16] pitti: yes, its cached for 24h [10:16] mvo: how is that called during login? [10:16] pitti: its in motd via /etc/update-motd.d/91-release-upgrade [10:17] cache is stamp=/var/lib/update-notifier/release-upgrade-available [10:17] ah [10:17] thanks [10:18] mvo: so it might actually be that motd was generated before the dist-upgrade (which then brought the fix) [10:18] mvo: I'll watch this then; danke [10:18] pitti: thanks [10:18] mvo: other question, where is the "system wide" place for proxy now? /etc/environment? [10:18] fwiw I can not reproduce it currently [10:19] mvo: I don't see anything explicitly proxy related in /etc/cron.daily/apt [10:19] pitti: yes, plus /etc/apt/apt.conf [10:19] hello everyone [10:19] pitti: correct, it sets using the apt config plus environment [10:19] hey chrisccoulson, good morning; had a nice weekend? [10:19] hey pitti - yeah, it was ok thanks [10:19] did you have a good weekend too? [10:20] chrisccoulson: yes, was fine; cleaned up the cellar, we went to a trance/techno concert, some bicycling, and bowling yesterday evening [10:20] I really sucked at bowling yesterday, though, but it was still fun [10:21] nothign like the 170 points I beat seb128 with, or so :) [10:21] * pitti hugs seb128 [10:21] lol [10:21] * seb128 hugs pitti [10:21] hey chris [10:21] hey chrisccoulson [10:21] hey seb128, how are you? [10:21] pitti - you had quite a busy weekend then :) [10:22] quite good, thanks! [10:22] what about you? [10:23] GNOME 2.30 today! [10:23] pitti - for bug 549552, the easiest way for me to fix it is to add another radio button in addition to "Solid" which says something like "Use theme settings" or something like that. i didn't do that though due to the UI freeze [10:23] Launchpad bug 549552 in gnome-terminal "[lucid] solid colour BG is transparent" [Low,Triaged] https://launchpad.net/bugs/549552 [10:23] pitti, do you want to do gvfs 1.6? [10:23] seb128 - yeah, i had quite a good weekend, but i didn't get much done [10:23] since you have the new bzr source checkout already handy ;-) [10:23] chrisccoulson: oh, it's too hard to read the level from the theme and select the "transparent" option? [10:24] seb128: yes, I do [10:24] pitti, danke! [10:24] seb128: so I can try import-orig :) [10:24] hehe [10:24] let me know how it's working! [10:25] seb128: I'll also do gdu 2.30.1 [10:25] pitti -the logic gets a lot more complicated then. eg, what happens if the user changes the transparency or background settings whilst it is defined in the theme? (how does it know where to get the settings from?) [10:25] pitti, thanks [10:25] doing nautilus [10:26] chrisccoulson: if the user has transparency settings in his gconf, it should use that IMHO [10:26] pitti - i already added a preference for using the theme settings, but i just coupled it to the solid radio button for the time being because i couldn't really modify the preferences dialog [10:26] chrisccoulson: ah, I see what you mean -- if the user wants to "reset" to system/theme settings [10:26] pitti - yeah, that's the issue [10:26] chrisccoulson: please subscribe ubuntu-release and ubuntu-doc and ask for a new radio button then [10:26] pitti - thanks, will do [10:26] chrisccoulson: but I wouldn't mind using the three that we have [10:27] it's not that complicated to set it to a visually appealing level, after all [10:27] seb128 - i did some bug fixes in g-s-d and gnome-desktop at the weekend [10:27] they're in bzr if you feel like doing any sponsoring ;) [10:27] chrisccoulson, oh, nice, do you need sponsoring? [10:27] good, doing that now [10:27] thanks [10:27] did you fix any of the lucid crashers assigned to you? [10:29] seb128 - not yet, but i'm going to look at those this week [10:29] there's only 1 isn't there? [10:30] I though 2 [10:30] but maybe it's the same listed twice in the list [10:31] ie once for the lucid task and once as a a normal bug [10:31] yeah, i think that might be the case [10:32] hey chrisccoulson ;) [10:32] i got the volume change event sounds working in g-s-d now, but that was quite hacky to make it work [10:33] hey didrocks, how are you? [10:33] chrisccoulson: I'm fine, thanks. busy over the weekend, but ready for having a good busy week, you? ;) [10:34] yeah, i'm good too thanks. i've got quite a busy week ahead as well this week [10:38] seb128: doing glibmm and gtkmm (do not hesitate if you think I should do other things before) [10:40] didrocks, don't you need glib 2.24 for those? [10:41] I'm doing that locally now [10:41] didrocks, I would let the *mm stack on the side to after everything else to be honest [10:41] it's low priority to get in compared to other things [10:42] seb128: ok, but I only see bug-buddy available now? oh gnome-color-manager just arrived too [10:42] seb128: doing those so ^ [10:42] lol ok [10:42] both are in universe [10:43] didrocks, I would focus on what we ship and use [10:43] seb128: yeah, but do you see anything else I can do for now? :) [10:43] but your choice [10:43] didrocks, gnome-applets? [10:43] zenity [10:43] gtk-doc [10:43] didrocks, ^ [10:44] seb128: oh, we are commited to zenity? never noticed it was in main :) ok, doing those 3 [10:44] thanks [10:44] didrocks, gtk-doc is depwait on highlight for month now [10:46] you can drop the build-depends on it, somebody just raised that issue some days ago there, the use is optional and has been turned on by debian [10:47] seb128: ok, I will drop the b-d so, thanks for the notice [10:51] hrm, I'm still missing message notifications. grey->white isn't eye-catching enough for IMs imho :/ [10:51] seb128: want me to do glib2.0, too? [10:53] seb128, pitti: tracker was a recommends in hardy so for hardy->lucid upgrades people get a new tracker. do we care (we no longer install tracker by default). should update-manager do anything here? [10:54] mvo: it's still in main, so I think we shouldn't do anythign special with it [10:54] if so, we'd rather should demote it [10:54] * mvo nods [10:54] my feeling as well [10:54] demote+1 [10:54] so, that gvfs update was easy [10:54] it has been discussed with upstream previous week in a meeting about those tech for next cycle [10:54] we should demote tracker [10:55] fine for me [10:55] we should demote deskbar-applet too [10:55] for lucid+1 [10:55] mvo, no, for now [10:55] oh [10:55] the current version is so crappy they don't want users [10:55] ie they don't want people to run it [10:55] ok [10:56] and tracker should be demoted too for lucid? [10:56] ok I'm not clear [10:56] 0.6 is crap and is what we have now [10:56] 0.7 is good [10:56] they don't want 0.6 used [10:56] -- lucid/main build deps on libtrackerclient-dev: [10:56] totem [10:56] so they want us to demote the lucid one [10:56] that's it [10:57] seb128: and remove it on upgrades I presume? [10:57] mvo, that would be nice [10:57] mvo: wouldn't that happen with universe demotion anyway? [10:57] yes, please remove it on upgrades :) [10:57] well it's always the same issue [10:57] it's hard to know if people actually use it [10:57] -- lucid/main build deps on deskbar-applet: [10:57] tracker [10:57] pitti: only if universe is not enabled. its the old problem that we do not know if the user cares for the app or not [10:57] but in most case it creates sluggish systems for no use [10:57] ok, that should sort out itself then [10:58] mvo: how does it currently compute the list of "obsolete" packages then? [10:58] just packages which disappeared entirely? [10:58] pitti: it records the ones before the initial apt-get update [10:58] pitti: and uses auto-remove information too [10:58] ah [10:59] pitti: but currently it will not auto-remove demotion unless universe is disabled [10:59] seb128: so, can totem's b-d be dropped easily? [10:59] pitti - yes [10:59] seb128: d- and tracker are just seeded on "dvd", so dropping is easy; want me to unseed? [10:59] pitti, yes, I will do that change [10:59] pitti, yes please [11:01] seb128: both unseeded [11:01] asac: any idea why we put "abrowser" onto the DVD? [11:01] pitti, danke [11:02] seb128: while we are at it, what about ekiga? [11:02] seb128: dvd also still has nautilus-cd-burner, I think that should go as well? [11:02] pitti, you can demote as far as I'm concerned [11:02] yes [11:03] should maybe be cleaned from the archive too [11:03] n-c-b [11:04] since upstream deprecated it in favor of brasero a cycle ago and stopped any work on it too [11:04] seb128: n-c-b still has 4 rdepends [11:04] (in universe) [11:04] ok [11:04] so demote for now [11:05] seb128: d-a, tracker, ekiga, n-c-b demoted and unseeded [11:06] which means that totem is now unbuildable [11:06] I will upload that one soon to fix that [11:06] great, thanks [11:08] mvo: would it be easy to remove nautilus-cd-burner on upgrades? [11:08] seb128: taking glib2.0 upgrade then, if that's alright? [11:09] pitti, sorry I'm already building it [11:10] ah, even better [11:10] * pitti -> back to RC bug fixing [11:10] pitti: trivial [11:10] mvo: can you, please? [11:10] sure [11:11] mvo: danke [11:11] lets find a good solution for this in lucid+1, the current demote list is long and scary, auto-removing e.g. emacs22 without being sure that emacs23 gets installed is not good IMO [11:11] same for gcompris, some people may still use it or xsane [11:11] mvo: ah, I remember that I had to remove this manually after the upgrade, indeed [11:12] emacs22 seems to be an easier problem, though (it's obsoleted by a new version emacs23, not just us saying "go back to universe") [11:13] right, the right action is pick emacs23 and remove 22 [11:15] pitti, seb128: nautilus-cd-burner and deskbar-applet are now removed [11:15] * mvo goes for lunch [11:16] mvo, thank you! [11:16] cheers, [11:17] mvo: thanks [11:18] seb128: I'm actually pondering whether we shouldn't remove tracker as well [11:18] that wouldn't kill the database etc, so if you really want it you could reinstall it from universe [11:18] right [11:18] +1 from me [11:19] mvo: ok, can you please do that as well, then? [11:27] seb128, there is a bug about pitvi displaying version number in title. planning on fix in lucid? [11:27] nigelb, don't know [11:28] there is a debdiff there as well, if you want it in, I'll just subscribe sponsors (chanced upon it during patch review) [11:28] right, do that [11:28] thank you :) [11:28] I've still some 500 unread bug emails from weekend [11:28] and other priority that version numbers [11:28] but good to have in on the queue ;-) [11:28] whoa [11:29] I was just doing patch review, thought I might ask you since its in main :) [11:29] right, subscribe sponsors [11:30] how nice, I have to redo debdiff [11:30] that debdiff was done some time earlier, prior to new version of pitivi in ubuntu [11:45] pitti: as regards Jockey, can I add an optional argument in the kernel module handler? I would like to add something like module_alias=None so that if it's set to something other than None we can deal with cases like nvidia where we have "nvidia" as the alias and different module names such as nvidia_current, nvidia_$flavour [11:49] pitti: without this, calling KernelModuleHandler.enabled() for nvidia won't work as it will look for nvidia_$flavour instead of nvidia [11:50] and we need to make sure that 1) nvidia is loaded 2) the module alias corresponds to the right nvidia_$flavour. I've added a function in nvidia-common to deal with 2) but we still need to take care of 1) [11:56] tseliot: hm, I thought we explicitly changed the handler to look for module nvidia_$version [11:56] before, it just looked for "nvidia", which stopped working with the new alternatives based system [11:56] tseliot: why do we need an "nvidia" alias? [11:57] pitti: right but the point is that now it says that the driver is not enabled (lsmod | grep nvidia_current doesn't return anything) [11:57] tseliot: uh, did the module names change recently? [11:57] tseliot: on the sprint they were named like nvidia_96 etc., which is why I changed that in the first place [11:57] pitti: I think we should do something like 1) check that nvidia is loaded 2) look up the alias and see what it points to [11:57] and since they are different packages, they should have different module names, too? [11:58] no, the names are still nvidia_current, etc. [11:58] tseliot: the modalias files also have per-version modules [11:58] tseliot: hm, I still fail to understand the problem then, I'm afraid [11:58] it worked during the sprint, so something must have changed since then? [11:59] I'll show you the output of jockey [11:59] and /proc/modules, too? [12:00] http://pastebin.ubuntu.com/405938/ [12:00] sure [12:01] pitti: here you go: http://pastebin.ubuntu.com/405939/ [12:02] pitti: maybe I didn't mention the fact that we add a file in /etc/modprobe.d which does "alias nvidia nvidia-current" [12:02] tseliot: hm, why do we need that? [12:02] (among other things) [12:02] http://pastebin.ubuntu.com/405939/ is indeed "wrong" [12:03] i. e. it would explain why the jockey handler is broken now [12:03] pitti: because the x driver tries to load the "nvidia" kernel module [12:03] not nvidia_current, etc. [12:03] tseliot: and we can't change that to use nvidia_$version? [12:04] pitti: not with a closed driver, I guess [12:04] oh, and jockey handler sets Driver "nvidia" [12:04] meh, why does /proc/modules care about aliases.. [12:05] tseliot: so, I really don't fancy introducing such hacks into the general KernelModuleHandler [12:05] pitti: "modprobe --resolve-alias" allows you to "unmask" the alias [12:05] it's an nvidia package hack, so it ought to be in the nvidia handler [12:06] tseliot: so, what should the canonical module name be? nvidia or nvidia_current? [12:07] as long as X, jockey, kernel, etc. keep talking about different names, we'll always have some desync between them [12:07] if the versioned modules are handled by the alias system, then they should _only_ be handled there [12:07] pitti: if you do something like modprobe --resolve-alias nvidia you will get nvidia_current (or whatever other flavour you're using) [12:07] tseliot: can we just change the module name in data/handlers/nvidia.py to "nvidia", for all versions? [12:08] (and likewise the nvidia-$version-modaliases packages) [12:08] tseliot: def enabled() already jumps through some hoops to check if the module is the current aliternative [12:09] pitti: and would all of the drivers show up in Jockey? If so, I would just override enabled() in the nvidia handler [12:10] tseliot: as in karmic, only those versions will appear which have a match in the modalias files [12:10] tseliot: in karmic, all versions used "nvidia", too [12:10] so it would be much closer to what we had before [12:10] tseliot: enabled() is already overrideen in the nvidia handler, for testing alternatives [12:10] seb128: chrisccoulson: doing g-p-m [12:10] oh, is there a gpm 2.30 now? [12:10] didrocks, ok [12:11] yes [12:11] pitti: yes, do you want to do it? [12:11] didrocks, you might want to let it to pitti or chrisccoulson they do it usually [12:11] didrocks: I planned to, but I won't rip it out of your hands :) [12:11] pitti - yeah, it seems like we did most of the bugfixes between us for 2.30 ;) [12:11] I just didn't see it in versions.html [12:11] yes, this will be patch dropping party :) [12:11] pitti: you can do it if you want, there are still other things to do :) [12:12] didrocks: as you wish [12:12] didrocks: but this is probably the one which I'm still most familliar with [12:12] pitti: sure, it was only if you were busy ;) [12:12] ok, doing that then [12:14] seb128: doing evolution-mapi (I know this is in universe and I can't test it, but still a lot of company ask for it), nevertheless, if you have other suggestion, I'm happy to do them (evolution 2.28.3.1 maybe?) [12:14] seb128: sorry, not evolution mapi, evolution 2.28.3.1 [12:14] (evolution mapi should be related to evolution 2.30.0 I guess) [12:14] pitti: wouldn't it be easier to just return false if either of these conditions is false? 1) self._alternatives.resolve_module_alias('nvidia') == self.module 2) self.module_loaded('nvidia') [12:14] didrocks, right [12:15] didrocks, I'm not sure the new evo has anything new, I think that was a win32 buildfix compared to what we have [12:15]