=== eeejay_away is now known as eeejay [00:10] chrisccoulson: do you think if suspend inhibition in Transmission is worth a SRU? [00:12] kklimonda, pitti is the one to ask about that really. but the change should be fairly trivial (and the current state is a regression), so that would probably a good SRU candidate if somebody wants to do the work [00:13] chrisccoulson: patch is ready (pretty trivial) in upstream repository, I can prepare a SRU later. I'll ask pitty tomorrow about it. [00:13] kklimonda - thanks :) [00:13] robert_ancell, regarding https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-default-apps, looks like you are down for seeding two new games [00:13] is that ok? [00:14] rickspencer3, yes, I don't think I have the authority to do the actual seeding so I'll ask pitti to do that but I think we should try those new games in the alpha and see how they go [00:14] k === asac_ is now known as asac === bjf is now known as bjf-afk === onestone____ is now known as onestone === eeejay is now known as eeejay_away === eeejay_away is now known as eeejay === richie is now known as Richie [06:46] jono: you here? [06:46] hey and471 [06:47] jono: any luck or do you need me to troubleshoot it some more with you [06:47] and471, I havent had time [06:47] been hacking on some other bits [06:47] jono, btw sorry about cutting out early, I have a restriction on my internet time and forgot to tell you :-) [06:47] jono, do you have time to do it now? [06:48] no worries [06:48] let me check out the branch [06:48] ok [06:50] and471: [06:50] File "bin/lernid", line 193, in connect_to_resources [06:50] self.chat.load_uri(chatirc) [06:50] AttributeError: 'LernidWebView' object has no attribute 'load_uri' [06:50] ok [06:50] jono, are you running karmic? [06:50] and471, yes [06:50] I did have Lernid originally running with WebKit [06:50] so something is odd in your code [06:51] jono: could you run the following in a terminal [06:52] jono: http://pastebin.com/d2cf6d69e [06:52] jono, just opaste eacvh line in and press enter [06:52] *paste *each [06:53] AttributeError: 'webkit.WebView' object has no attribute 'load_uri' [06:53] it has an issue with that attrib [06:54] jono, yeah, what I was testing is to see whether there was a problem with webkit or my code [06:54] jono, seems to be webkit [06:54] jono, okay can you find out the version of your python-webkit for me? [06:57] and471, 1.1.5-1 [06:58] jono, ah, I have a version form a ppa it seems [06:58] *from [07:00] and471, aha! [07:00] jono: does it work if you use python-webkit from this ppa https://launchpad.net/~webkit-team/+archive/ppa/+packages [07:03] and471, I don't want to get non-Karmic components [07:03] jono, oh ok [07:03] and471, also, why move to WebKit from GtkMozEmbed? [07:05] jono: it is meant to be a lot quicker, and I just hear better things about webkit, like it is easier to work with etc. [07:05] jono, anyway I am sure we can find a way for it to work [07:05] did your branch add anything else? [07:05] jono, yep, parsing of the schedule [07:05] and471, when I tried webkit it would not run the web IRC client [07:06] and471, parsing the schedule? [07:06] actually, I was working on that [07:06] tonight [07:06] I now have code to read in an iCal file and generate a schedule [07:06] just trying to figure out how to convert between timezones [07:06] jono, oh [07:07] jono, what I was doing is downloading JUST the content from the wiki using a special url [07:07] jono, and then presenting that [07:07] ahhh [07:07] yeah, I am thinking we need structured datra [07:07] jono, that way I don't have to do any converting between formats [07:07] bbiab [07:07] because then we can pop up notification bubbles 10mins before a session, convert timezones etc [07:11] Good morning [07:15] hello [07:18] jono, in which case your way seems to way to go :-) [07:18] jono, go forward with that idea, it is a lot better than mine [07:19] jono, btw to convert between timezones, I am sure you can just use the time module [07:19] jono, http://docs.python.org/library/time.html [07:19] jono, well have fun doing that! [07:20] jono, see ya [07:21] thanks and471 === YDdraigGoch is now known as Richie [08:07] pitti: hi ,regarding Bug 436755 , just wanted to mention that the deb from njpatel's ppa works but not sure why the repo version doesnt work [08:07] Launchpad bug 436755 in evolution-indicator "indicator-applet doesn't change icon when I recieve new e-mails via Evolution" [Low,Confirmed] https://launchpad.net/bugs/436755 [08:17] mac_v: hm, strange; does it have the same patch? [08:29] pitti: not sure , i havent checked , njp might know about it [08:32] pitti: one of the things i realised during testing njp's ppa was , it worked when i purged and then installed the deb [not sure how or why that is so] [08:32] nearly same as reported by the last comment === seb128_ is now known as seb128 === seb128 is now known as seb128_ [08:39] bonjour seb128_ === seb128_ is now known as seb128 [08:40] good morning everybody [08:40] hey pitti, how are you? [08:43] splendid, how are you? [08:46] very good thanks [08:46] I had a good night and weather is nice [08:47] go robert_ancell go [08:47] nice to see him tackling merges and updates and uploading while we are sleeping there ;-) [09:02] indeed, impressive how much work we can get done just by sleeping :) [09:05] pitti, I've uploaded a new sru for this indicator issues which failed verification [09:06] seb128: do you know "seed" and "gnome-js-common"? [09:06] thanks [09:06] pitti, yes, those are javascript for GNOME [09:06] pitti, njpatel forgot to add simple-patchsys to the rules [09:06] seb128: should we try to keep them out of main, or MIR/promote? [09:06] hah [09:06] I guess he didn't use a correct patch for his ppa upload [09:07] pitti, seed is used by gnome-games now... [09:07] so get it to main [09:07] that's why I ask [09:07] current CD builds break because of that [09:07] but I guess in the long run we'll need it anyway [09:07] yes [09:07] epiphany-browser uses it too [09:07] though that is in universe now [09:08] but it's an semi-official GNOME thing [09:08] I say semi because they are still arguing on gjs against seed [09:08] ie bindings based on xul or webkit [09:09] I would be in favor of keeping those out of the CD for lucid though [09:09] hmm [09:10] seb128: we could demote those two games [09:10] which games are those? [09:10] that's why I asked about doing the default-apps seed changes [09:10] I'm getting the sources right now [09:10] 28 meg to download... [09:10] lightsoff [09:10] seb128: it's not a b-dep, just binary [09:11] and swell-foop [09:11] we didn't plan to include those on the CD anyway [09:11] let's demote those [09:11] so I was about to change the seeds [09:11] +1 [09:11] but I still wonder whether to keep them on the DVD [09:12] doesn't hurt [09:12] i. e. the full gnome-games thing [09:12] ok, then we do need the MIR [09:12] I'll prepare both (seeds and MIRs) now [09:12] I need to do some mirs too [09:13] hey njpatel [09:20] seb128: hey! [09:22] njpatel, I've uploaded a new fix for this pop count issue, sorry that I didn't spot the previous one didn't have a patchsys rule [09:22] njpatel, ie the patch didn't get used, not sure why it worked for your ppa though... [09:22] seb128: oh, weird :-/ [09:23] seb128: thanks for sorting it out :) [09:23] np, sorry for not spotting the issue in the first upload [09:24] seb128: your right...that's so weird (just checked old evo-indicator's rules file) [09:24] seb128: dude, np :) [09:42] hey chrisccoulson_g1 [09:42] good morning everyone [09:42] hey chrisccoulson_g1 [09:42] yay G1 [09:42] chrisccoulson_g1, back to work? ;-) [09:45] hey seb128, yeah, I'm back to work today [09:46] but on a training course :) [09:46] to what are you trained? [09:46] pitti - you're a g1 owner too arent you? [09:46] chrisccoulson_g1: right, and I love it [09:47] seb128 - I'm on a training course about analog simulation. its all stuff I've done before, but there is a free lunch on offer :) [09:47] * pitti pulls and challenges chrisccoulson_g1 for a "The Schwartz Unsheated" duel [09:47] lol [09:48] heh :) [10:20] hey slomo [10:20] pitti, what is the story with poppler in debian now? [10:21] did everybody agreed on what to do? are people still arguing with upstream over the changes there? [10:23] seb128: Joss said that he reverted the ABI breakage for now to finish the testing migration [10:23] afterwards he'll upload a libpoppler5a with upstream's ABI again [10:23] which seems like a reasonable approach to me [10:23] bah [10:23] changing the name? [10:24] *shrug* it's not like upstream cares about it: ) [10:24] hi seb128 :) [10:24] no but I hate weird names and going to binary new and rebuilding things which don't need a rebuild [10:24] it has caused utter, UTTER, HARD pain [10:24] seb128: they do need a rebuild anyway [10:24] with the difference that with a rename you avoid breakage [10:24] no they don't? [10:24] sure they do [10:25] at least not softwares using the glib bindings [10:25] ie evince [10:25] things just maddingly fall apart if you don't [10:25] seb128: those shouldn't link against libpoppler5 directly then? [10:25] are you sure? [10:25] see the 9023423 cups bugs that were reported [10:25] they should not no but some do thanks to libtool [10:26] I would rather use Conflicts then changing naming but I don't strongly care either way [10:27] how would adding Conflicts: all over the place help to reduce the effort? [10:27] it rather seems like a lot of explicit changes for a temporary issue than just a clean no-change rebuild [10:27] slomo, you seem full speed on unstable versions for Debian ;-) do you know when is the freeze coming and what version of GNOME is expected? [10:27] seb128: no but last time i read something about it, the goal was 3.0 [10:28] pitti, oh I didn't say it would reduce the effort I just dislike weird library renames [10:28] seb128: btw, do you have ubuntu specific changes in gtk 2.19? [10:28] slomo, we don't have gtk 2.19 yet [10:28] you are crack addict nowadays ;-) [10:28] or you have lot of free time to deal with early unstable version bugs ;-) [10:31] seb128: i was working on a problem that i didn't make sense to me for a few hours yesterday... i needed distraction :) [10:32] lol [10:32] seb128: and gtk 2.19 is great, nothing seems to be broken ;) only glib 2.23 has some problems [10:32] slomo, I will have a look at syncing it from Debian [10:32] I want to do some testing first though [10:33] slomo, do you plan to start on 2.29 packaging too? [10:33] seb128: ok :) glib 2.23 makes many applications complain at startup, other than that it's fine too: (gvim:29639): GLib-WARNING **: g_set_prgname() called multiple times [10:33] seb128: only some parts that i'm interested in (glib, gtk, soup, epiphany), not sure about other stuff [10:34] ok [10:34] slomo, do you know what are the plan for gstreamer this cycle btw? [10:34] I would like to avoid having a karmic situation for the lts [10:34] the playbin2 changes created lot of new issues previous cycle [10:34] and we had to take quite to rewrites etc to fix easy codec install, etc late in the cycle [10:35] do you know if disruptive changes are coming this cycle too? [10:45] seb128: well, this changes were necessary because nobody reported bugs early enough ;) [10:45] seb128: i don't think this will happen again next cycle, it was bad timing everywhere [10:46] slomo, I don't blame anybody but when you have rewrite, etc you can expect issues [10:46] slomo, I'm just trying to figure if we can expect a bug fix cycle this cycle or if we need to be pro-active to avoid trouble [10:47] gst-plugins-base 0.10.26 has some more larger changes (related to playbin2 this time) that you don't have in any packages yet [10:47] after that i don't expect that this cycle there will be large rewrites/refactoring [10:48] ok good [10:48] mostly bugfixes or new features [10:48] thanks [10:51] seb128: btw, are you going to update epiphany/webkit in karmic updates? imho 2.28 is nothing you want to use ;) [10:52] slomo, no, not worth the trouble imho [10:52] I would recommend people to use firefox or chromium anyway [10:52] epiphany is a joke nowadays [10:53] do you know if a ppa exists with epiphany 2.29 and newest webkit? :) [10:53] they keep adding requirements on new libsoup or webkit anyway [10:53] that's not practical for stable updates [10:53] well, i don't like firefox and chromium :) midori might be another solution [10:54] I don't know about a ppa no... [10:54] let me have a look [10:55] launchpad has this nice feature listing ppa versions [10:59] slomo, https://edge.launchpad.net/~webkit-team/+archive/epiphany [11:00] slomo, that has a 2.29.1 build for karmic apparently [11:00] kenvandine, hey! Would be great if https://bugs.edge.launchpad.net/ubuntu/+source/indicator-session/+bug/491317 could be fixed; atm Empathy 2.29.x isn't installable without removing the session applet :( [11:00] Ubuntu bug 491317 in indicator-session "Shouldn't use libempathy" [Undecided,New] [11:01] cassidy, we don't have 2.29 [11:01] seb128: thanks [11:01] seb128, but you will in Lucid and as soon it's fixed in Lucid I can backport the packet to our PPA and so make it installable on Karmic [11:02] cassidy, right, makes sense [11:04] pedro_, hey [11:04] bonjour seb128 [11:04] pedro_, how are you? [11:05] seb128, good good, how about you? [11:05] good thank you! [11:44] slomo, oh btw is there any plan to make gst-plugins-good0.10 stop using libhal since it uses udev now? [11:44] or are both useful there? [11:49] * pitti gets a first panel with cached .desktop data [11:49] pitti, waouh! [11:51] seb128: both are useful, udev is only used for v4l2 while the hal plugin has audio sinks that use a hal udi as device name. it might make sense to write a new devkit plugin that does the same as the hal plugin later [11:51] oh ok [11:52] does that even work with pulse? [11:52] pitti - i'd be interested to see your panel work :) [11:52] chrisccoulson: so am I :) [11:52] I don't have a cache file generator yet, just a manually crafted one and the code to load it [11:52] i'm trying to think of ways to avoid gconf calls when loading the theme in g-s-d :) [11:52] that's what I'll tackle next [11:53] chrisccoulson: I just use a single pre-translated GKeyFile which has all the desktop files [11:53] that avoids all the stat()ing and translating [11:53] you still have to parse the actual data, of course [11:53] pitti - yeah, i was wondering if you were going to use a GKeyFile or not, or if you had any other ideas [11:54] i used the same thing for loading the required components in gnome-session [11:54] chrisccoulson: I started with a tab-separated-value approach, but that gets too fiddly [11:54] and probably won't save so much time, too [11:54] and maybe i might do something similar in g-s-d to create a cache of theme info :) [11:54] but the .cache file has a lot of unnecessary keys filtered out, pre-translated, and single-file [11:54] once I have a complete cache, I'll do some timing [11:54] cool:) [11:56] i tried looking at ways to improve gconf speed yesterday, but i think that's a non-starter really. i think we just need to delay reading from gconf for as long as possible when loading the session [11:56] and i've already got a gnome-session that can start the session without reading from gconf :) [12:00] chrisccoulson: but we do need to start gconf either way, right? [12:01] chrisccoulson: some people looked at gconf speed a cycle ago I think and some patches went in [12:01] I don't think we should spend lot of efforts on gconf now [12:01] we will get dconf next cycle [12:01] pitti - we do. but at the moment, it delays the whole session from starting. i was thinking that if we could start getting some session components loading and then start the gconf stuff whilst other things are loading, it might be slightly quicker [12:02] oh, right [12:02] seb128 - yeah, i'm not going to spend too much time looking at it [12:02] but delaying gconf use until later seems good [12:03] lunch time! [12:06] vuntz: bonjour [12:07] vuntz: if you have a minute, I have a first patch for gnome-menus caching: http://pastebin.com/f788f609d [12:08] vuntz: the .cache file is basically a single GKeyFile, one section per app, with strings pre-translated (thus it's called desktop..cache), and unnecessary fields stripped [12:08] vuntz: that provides per-directory caches (global cache is not really appropriate for distro integration), avoids lots of stat()ing, and i18n'ing [12:09] vuntz: do you think the general approach is okay? [12:22] pitti: err, one big GKeyFile? [12:22] vuntz: I started with a CSV, but that quickly gets clumsy [12:22] pitti: desrt was suggesting to use GVariant to have a binary mmap-able file [12:23] vuntz: is that in glib yet? [12:23] pitti: I guess your approach can work in the meantime, but I won't accept that upstream [12:24] pitti: not yet, will be merged "soon" [12:24] vuntz: ok, so if gvariant is faster, assume the patch would use variant instead of gkeyfile; what do you think about the general structure? [12:25] once gvariant lands, it's certainly promising [12:26] pitti: shouldn't the cache be somewhere in /var ? [12:26] (just reading the patch and commenting on details for now :-)) [12:27] vuntz: no problem, can do that [12:27] replacing '/' with '_' and prepending /var/cache/gmenu/ [12:27] vuntz: you'd lose the ability to have per-user cache files then, thoughh [12:27] (not that we want to integrate that by default, or that I deem it important to have) [12:31] pitti: one issue is that your stuff is not recursive [12:31] pitti: cached_dir_load_entries_recursive is really recursive [12:31] pitti: (ie, it calls itself for subdirs) [12:31] vuntz: that was actually deliberate [12:32] a parent dir's cache should include the children [12:32] so I would really rename functions :-) [12:32] no unnecessary start()/opendir()/parsing [12:32] ok [12:32] I mean, right now, it's probably okay if we want the patch to not be invasive [12:32] looks relatively sane [12:33] but to get it upstream, there's some renaming to do, and gvariant, I guess [12:33] vuntz: which function would you rename? cached_dir_load_entries_from_cache_file() doesn't suggest it'd be recursive? [12:33] vuntz: gvariant> indeed, looking forward to that [12:33] cached_dir_load_entries_recursive() [12:33] ah, well [12:33] I see [12:33] the cache builder needs to do the recursion [12:34] I guess it's okay [12:34] in fact, cache builder == remove cache, gmenu_lookup_tree(), build key-file from that [12:35] (my comments are really about style, which doesn't matter for now anyway :-)) [12:35] appreciated [12:35] it's the first time I hack on gmenu, so it took me some time to understand the structure [12:35] yeah, it's, hrm, messy [12:35] and you didn't even start trying to fix some monitoring bug [12:36] it should get rewritten with real gobjects instead of pseudo-objects that have pseudo-signals [12:37] so, if that won't land upstream, I can just as well write update-gmenu-cache in Python for simplicity [12:37] pitti: you probably also want to do something about gio, since g_app_info_get_all() will do the same [12:37] since that will need to be re-done anyway with gvariant [12:37] yep [12:38] vuntz: oh, and that doesn't use gnome-menus? [12:38] nope [12:38] okay [12:38] but I guess I'll do that once gvariant lands, to avoid doing things twice [12:53] good afternoon [12:53] pitti: can you take a look at bug 457123, is it a good candidate for sru now that the patch is ready? [12:53] Launchpad bug 457123 in transmission "Transmission doesn't prevent suspend when torrent is active" [Medium,Confirmed] https://launchpad.net/bugs/457123 === MacSlow is now known as MacSlow|lunch [13:31] "/away -all [13:32] kklimonda: looks sane enough [13:36] cassidy, i snagged bug 491317 [13:36] Launchpad bug 491317 in indicator-session "Shouldn't use libempathy" [Undecided,New] https://launchpad.net/bugs/491317 [13:36] will look at it today [13:37] although i doubt it can be fixed for karmic [13:37] but for lucid for sure :) [13:43] Hi any openbox users here? [13:52] kenvandine, hey, he said that's ok they will backport the fix in their ppa [13:52] 2.29 is not in karmic anyway [13:57] yep === MacSlow|lunch is now known as MacSlow [14:15] mdeslaur - can you recreate the screensaver crash? [14:16] chrisccoulson: no, unfortunately [14:16] that's a shame. i haven't seen it yet either :( [14:17] chrisccoulson: yeah...it's hard to debug problems we can't reproduce :( [14:19] it is. the last screensaver crash was hard enough to debug, and i could recreate that one (albeit, not very often) === robbiew-afk is now known as robbiew [14:35] * pitti smiles about his wife [14:35] I just showed her dotty [14:36] she currently has a task to create some XML and DTD, and to do a structure tree [15:41] grr... my laptop screen keeps dimming. how do I *really* disable delayed dimming? [15:41] pitti: my wife is finally learning html & css. good fun. [15:42] cj: my gf's on the Python wagon :) [15:42] I unchecked 'Dim display when idle' and pushed 'Set display brightness to:' up to 100% in the Power Management Preferences dialogue. [15:43] MenZa: onoes! what is the perl community going to do!? [15:43] :D [15:43] * cj scowls at the competition [15:44] vuntz, seb128: hm, using the single-reduced-keyfile approach is still slow, but it's an improvement [15:44] default: [15:44] cold cache: 7.9 [15:44] hot cache: 0.3 [15:44] patch: [15:44] cold cache: 2.7 [15:44] hot cache: 0.1 [15:44] (in seconds) [15:44] average of three runs [15:45] pitti: still much better. And the mmap file should help quite a bit for the remaining part [15:46] yeah [15:46] a nice standard serialization API for this kind of nested data structures is badly missing indeed [15:47] FYI, that's the time of [15:47] setlocale(LC_ALL, ""); [15:47] GMenuTree* tree = gmenu_tree_lookup("applications.menu", GMENU_TREE_FLAGS_NONE); [15:47] printf("%p\n", gmenu_tree_get_root_directory(tree)); [15:59] pitti, gains even small ones are welcome and that one is quite nice to get! [15:59] seb128: I'll upload it to a PPA [15:59] seb128: I have a call with Rick now and then I need to run [15:59] ok [15:59] seb128: once it's built, would you want to do a test run? [16:00] seb128: upgrade to it, then [16:00] sure [16:00] does it work out of the box? === bjf-afk is now known as bjf [16:00] or do I need to generate the cache by hand? [16:00] update-gnome-menus-cache /usr/share/applications/ > /usr/share/applications/$LANG.cache [16:01] seb128: then remove the ureadahead cache [16:01] boot once to regenerate it [16:01] and then another time [16:01] since this will take out all the *.desktops from readahead [16:01] and include the .cache [16:01] where is the cache? [16:02] seb128: I'll deal with those ^ in the final upload, but run out of time now [16:02] seb128: sorry, /usr/share/applications/desktop.$LANG.cache [16:02] /usr/share/applications/desktop.de_DE.UTF-8.cache [16:02] ^ for me [16:02] ok [16:02] seb128: I'll move it to var [16:02] and the the boot one? [16:02] I've never cleaned that by hand [16:02] but I'm interested in how much it brings [16:02] I usually let the distro do whatever is standard [16:02] seb128: /var/lib/ureadahead/pack ? [16:02] ok thanks [16:02] I never looked at how that works [16:02] it's just magic to me ;-) [16:03] see /var/lib/dpkg/info/ureadahead.postinst [16:03] rm -f /var/lib/ureadahead/pack /var/lib/ureadahead/*.pack [16:03] cool [16:03] I think I've everything I need for testing [16:03] I will let you know how it goes [16:03] seb128: if it's worth doing, I'll add the magic triggering bits, cache autogeneration, etc. [16:03] seb128: merci! [16:03] rickspencer3: call now? [16:05] seb128: oops; just noticed a "slight" bug -- application entries don't actually work :-( [16:05] but well, that should be easy to fix :) [16:05] still worth testing the speed? [16:05] seb128: yes, please [16:05] ok [16:05] seb128: just move away the .cache file and restart panel [16:06]