[00:10] <kklimonda> chrisccoulson: do you think if suspend inhibition in Transmission is worth a SRU?
[00:12] <chrisccoulson> 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] <kklimonda> chrisccoulson: patch is ready (pretty trivial) in upstream repository, I can prepare a SRU later. I'll ask pitty tomorrow about it.
[00:13] <chrisccoulson> kklimonda - thanks :)
[00:13] <rickspencer3> 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] <rickspencer3> is that ok?
[00:14] <robert_ancell> 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] <rickspencer3> k
[06:46] <and471> jono: you here?
[06:46] <jono> hey and471
[06:47] <and471> jono: any luck or do you need me to troubleshoot it some more with you
[06:47] <jono> and471, I havent had time
[06:47] <jono> been hacking on some other bits
[06:47] <and471> jono, btw sorry about cutting out early, I have a restriction on my internet time and  forgot to tell you :-)
[06:47] <and471> jono, do you have time to do it now?
[06:48] <jono> no worries
[06:48] <jono> let me check out the branch
[06:48] <and471> ok
[06:50] <jono> and471:
[06:50] <jono> File "bin/lernid", line 193, in connect_to_resources
[06:50] <jono>     self.chat.load_uri(chatirc)
[06:50] <jono> AttributeError: 'LernidWebView' object has no attribute 'load_uri'
[06:50] <and471> ok
[06:50] <and471> jono, are you running karmic?
[06:50] <jono> and471, yes
[06:50] <jono> I did have Lernid originally running with WebKit
[06:50] <jono> so something is odd in your code
[06:51] <and471> jono: could you run the following in a terminal
[06:52] <and471> jono: http://pastebin.com/d2cf6d69e
[06:52] <and471> jono, just opaste eacvh line in and press enter
[06:52] <and471> *paste  *each
[06:53] <jono> AttributeError: 'webkit.WebView' object has no attribute 'load_uri'
[06:53] <jono> it has an issue with that attrib
[06:54] <and471> jono, yeah, what I was testing is to see whether there was a problem with webkit or my code
[06:54] <and471> jono, seems to be webkit
[06:54] <and471> jono, okay can you find out the version of your python-webkit for me?
[06:57] <jono> and471, 1.1.5-1
[06:58] <and471> jono, ah, I have a version form a ppa it seems
[06:58] <and471> *from
[07:00] <jono> and471, aha!
[07:00] <and471> jono: does it work if you use python-webkit from this ppa https://launchpad.net/~webkit-team/+archive/ppa/+packages
[07:03] <jono> and471, I don't want to get non-Karmic components
[07:03] <and471> jono, oh ok
[07:03] <jono> and471, also, why move to WebKit from GtkMozEmbed?
[07:05] <and471> 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] <and471> jono, anyway I am sure we can find a way for it to work
[07:05] <jono> did your branch add anything else?
[07:05] <and471> jono, yep, parsing of the schedule
[07:05] <jono> and471, when I tried webkit it would not run the web IRC client
[07:06] <jono> and471, parsing the schedule?
[07:06] <jono> actually, I was working on that
[07:06] <jono> tonight
[07:06] <jono> I now have code to read in an iCal file and generate a schedule
[07:06] <jono> just trying to figure out how to convert between timezones
[07:06] <and471> jono, oh
[07:07] <and471> jono, what I was doing is downloading JUST the content from the wiki using a special url
[07:07] <and471> jono, and then presenting that
[07:07] <jono> ahhh
[07:07] <jono> yeah, I am thinking we need structured datra
[07:07] <and471> jono, that way I don't have to do any converting between formats
[07:07] <and471> bbiab
[07:07] <jono> because then we can pop up notification bubbles 10mins before a session, convert timezones etc
[07:11] <pitti> Good morning
[07:15] <baptistemm> hello
[07:18] <and471> jono, in which case your way seems to way to go :-)
[07:18] <and471> jono, go forward with that idea, it is a lot better than mine
[07:19] <and471> jono, btw to convert between timezones, I am sure you can just use the time module
[07:19] <and471> jono, http://docs.python.org/library/time.html
[07:19] <and471> jono, well have fun doing that!
[07:20] <and471> jono, see ya
[07:21] <jono> thanks and471
[08:07] <mac_v> 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:17] <pitti> mac_v: hm, strange; does it have the same patch?
[08:29] <mac_v> pitti: not sure , i havent checked , njp might know about it
[08:32] <mac_v> 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] <mac_v> nearly same as reported by the last comment
[08:39] <pitti> bonjour seb128_
[08:40] <seb128> good morning everybody
[08:40] <seb128> hey pitti, how are you?
[08:43] <pitti> splendid, how are you?
[08:46] <seb128> very good thanks
[08:46] <seb128> I had a good night and weather is nice
[08:47] <seb128> go robert_ancell go
[08:47] <seb128> nice to see him tackling merges and updates and uploading while we are sleeping there ;-)
[09:02] <pitti> indeed, impressive how much work we can get done just by sleeping :)
[09:05] <seb128> pitti, I've uploaded a new sru for this indicator issues which failed verification
[09:06] <pitti> seb128: do you know "seed" and "gnome-js-common"?
[09:06] <pitti> thanks
[09:06] <seb128> pitti, yes, those are javascript for GNOME
[09:06] <seb128> pitti, njpatel forgot to add simple-patchsys to the rules
[09:06] <pitti> seb128: should we try to keep them out of main, or MIR/promote?
[09:06] <pitti> hah
[09:06] <seb128> I guess he didn't use a correct patch for his ppa upload
[09:07] <seb128> pitti, seed is used by gnome-games now...
[09:07] <seb128> so get it to main
[09:07] <pitti> that's why I ask
[09:07] <pitti> current CD builds break because of that
[09:07] <pitti> but I guess in the long run we'll need it anyway
[09:07] <seb128> yes
[09:07] <seb128> epiphany-browser uses it too
[09:07] <seb128> though that is in universe now
[09:08] <seb128> but it's an semi-official GNOME thing
[09:08] <seb128> I say semi because they are still arguing on gjs against seed
[09:08] <seb128> ie bindings based on xul or webkit
[09:09] <seb128> I would be in favor of keeping those out of the CD for lucid though
[09:09] <pitti> hmm
[09:10] <pitti> seb128: we could demote those two games
[09:10] <seb128> which games are those?
[09:10] <pitti> that's why I asked about doing the default-apps seed changes
[09:10] <seb128> I'm getting the sources right now
[09:10] <seb128> 28 meg to download...
[09:10] <pitti> lightsoff
[09:10] <pitti> seb128: it's not a b-dep, just binary
[09:11] <pitti> and swell-foop
[09:11] <pitti> we didn't plan to include those on the CD anyway
[09:11] <seb128> let's demote those
[09:11] <pitti> so I was about to change the seeds
[09:11] <seb128> +1
[09:11] <pitti> but I still wonder whether to keep them on the DVD
[09:12] <seb128> doesn't hurt
[09:12] <pitti> i. e. the full gnome-games thing
[09:12] <pitti> ok, then we do need the MIR
[09:12] <pitti> I'll prepare both (seeds and MIRs) now
[09:12] <seb128> I need to do some mirs too
[09:13] <seb128> hey njpatel
[09:20] <njpatel> seb128: hey!
[09:22] <seb128> 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] <seb128> njpatel, ie the patch didn't get used, not sure why it worked for your ppa though...
[09:22] <njpatel> seb128: oh, weird :-/
[09:23] <njpatel> seb128: thanks for sorting it out :)
[09:23] <seb128> np, sorry for not spotting the issue in the first upload
[09:24] <njpatel> seb128: your right...that's so weird (just checked old evo-indicator's rules file)
[09:24] <njpatel> seb128: dude, np :)
[09:42] <seb128> hey chrisccoulson_g1
[09:42] <chrisccoulson_g1> good morning everyone
[09:42] <pitti> hey chrisccoulson_g1
[09:42] <pitti> yay G1
[09:42] <seb128> chrisccoulson_g1, back to work? ;-)
[09:45] <chrisccoulson_g1> hey seb128, yeah, I'm back to work today
[09:46] <chrisccoulson_g1> but on a training course :)
[09:46] <seb128> to what are you trained?
[09:46] <chrisccoulson_g1> pitti - you're a g1 owner too arent you?
[09:46] <pitti> chrisccoulson_g1: right, and I love it
[09:47] <chrisccoulson_g1> 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] <seb128> lol
[09:48] <chrisccoulson_g1> heh :)
[10:20] <seb128> hey slomo
[10:20] <seb128> pitti, what is the story with poppler in debian now?
[10:21] <seb128> did everybody agreed on what to do? are people still arguing with upstream over the changes there?
[10:23] <pitti> seb128: Joss said that he reverted the ABI breakage for now to finish the testing migration
[10:23] <pitti> afterwards he'll upload a libpoppler5a with upstream's ABI again
[10:23] <pitti> which seems like a reasonable approach to me
[10:23] <seb128> bah
[10:23] <seb128> changing the name?
[10:24] <pitti> *shrug* it's not like upstream cares about it: )
[10:24] <slomo> hi seb128 :)
[10:24] <seb128> no but I hate weird names and going to binary new and rebuilding things which don't need a rebuild
[10:24] <pitti> it has caused utter, UTTER, HARD pain
[10:24] <pitti> seb128: they do need a rebuild anyway
[10:24] <pitti> with the difference that with a rename you avoid breakage
[10:24] <seb128> no they don't?
[10:24] <pitti> sure they do
[10:25] <seb128> at least not softwares using the glib bindings
[10:25] <seb128> ie evince
[10:25] <pitti> things just maddingly fall apart if you don't
[10:25] <pitti> seb128: those shouldn't link against libpoppler5 directly then?
[10:25] <seb128> are you sure?
[10:25] <pitti> see the 9023423 cups bugs that were reported
[10:25] <seb128> they should not no but some do thanks to libtool
[10:26] <seb128> I would rather use Conflicts then changing naming but I don't strongly care either way
[10:27] <pitti> how would adding Conflicts: all over the place help to reduce the effort?
[10:27] <pitti> it rather seems like a lot of explicit changes for a temporary issue than just a clean no-change rebuild
[10:27] <seb128> 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] <slomo> seb128: no but last time i read something about it, the goal was 3.0
[10:28] <seb128> pitti, oh I didn't say it would reduce the effort I just dislike weird library renames
[10:28] <slomo> seb128: btw, do you have ubuntu specific changes in gtk 2.19?
[10:28] <seb128> slomo, we don't have gtk 2.19 yet
[10:28] <seb128> you are crack addict nowadays ;-)
[10:28] <seb128> or you have lot of free time to deal with early unstable version bugs ;-)
[10:31] <slomo> 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] <seb128> lol
[10:32] <slomo> seb128: and gtk 2.19 is great, nothing seems to be broken ;) only glib 2.23 has some problems
[10:32] <seb128> slomo, I will have a look at syncing it from Debian
[10:32] <seb128> I want to do some testing first though
[10:33] <seb128> slomo, do you plan to start on 2.29 packaging too?
[10:33] <slomo> 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] <slomo> seb128: only some parts that i'm interested in (glib, gtk, soup, epiphany), not sure about other stuff
[10:34] <seb128> ok
[10:34] <seb128> slomo, do you know what are the plan for gstreamer this cycle btw?
[10:34] <seb128> I would like to avoid having a karmic situation for the lts
[10:34] <seb128> the playbin2 changes created lot of new issues previous cycle
[10:34] <seb128> and we had to take quite to rewrites etc to fix easy codec install, etc late in the cycle
[10:35] <seb128> do you know if disruptive changes are coming this cycle too?
[10:45] <slomo> seb128: well, this changes were necessary because nobody reported bugs early enough ;)
[10:45] <slomo> seb128: i don't think this will happen again next cycle, it was bad timing everywhere
[10:46] <seb128> slomo, I don't blame anybody but when you have rewrite, etc you can expect issues
[10:46] <seb128> 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] <slomo> 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] <slomo> after that i don't expect that this cycle there will be large rewrites/refactoring
[10:48] <seb128> ok good
[10:48] <slomo> mostly bugfixes or new features
[10:48] <seb128> thanks
[10:51] <slomo> seb128: btw, are you going to update epiphany/webkit in karmic updates? imho 2.28 is nothing you want to use ;)
[10:52] <seb128> slomo, no, not worth the trouble imho
[10:52] <seb128> I would recommend people to use firefox or chromium anyway
[10:52] <seb128> epiphany is a joke nowadays
[10:53] <slomo> do you know if a ppa exists with epiphany 2.29 and newest webkit? :)
[10:53] <seb128> they keep adding requirements on new libsoup or webkit anyway
[10:53] <seb128> that's not practical for stable updates
[10:53] <slomo> well, i don't like firefox and chromium :) midori might be another solution
[10:54] <seb128> I don't know about a ppa no...
[10:54] <seb128> let me have a look
[10:55] <seb128> launchpad has this nice feature listing ppa versions
[10:59] <seb128> slomo, https://edge.launchpad.net/~webkit-team/+archive/epiphany
[11:00] <seb128> slomo, that has a 2.29.1 build for karmic apparently
[11:00] <cassidy> 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:01] <seb128> cassidy, we don't have 2.29
[11:01] <slomo> seb128: thanks
[11:01] <cassidy> 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] <seb128> cassidy, right, makes sense
[11:04] <seb128> pedro_, hey
[11:04] <pedro_> bonjour seb128
[11:04] <seb128> pedro_, how are you?
[11:05] <pedro_> seb128, good good, how about you?
[11:05] <seb128> good thank you!
[11:44] <seb128> slomo, oh btw is there any plan to make gst-plugins-good0.10 stop using libhal since it uses udev now?
[11:44] <seb128> or are both useful there?
[11:49]  * pitti gets a first panel with cached .desktop data
[11:49] <seb128> pitti, waouh!
[11:51] <slomo> 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] <seb128> oh ok
[11:52] <pitti> does that even work with pulse?
[11:52] <chrisccoulson> pitti - i'd be interested to see your panel work :)
[11:52] <pitti> chrisccoulson: so am I :)
[11:52] <pitti> I don't have a cache file generator yet, just a manually crafted one and the code to load it
[11:52] <chrisccoulson> i'm trying to think of ways to avoid gconf calls when loading the theme in g-s-d :)
[11:52] <pitti> that's what I'll tackle next
[11:53] <pitti> chrisccoulson: I just use a single pre-translated GKeyFile which has all the desktop files
[11:53] <pitti> that avoids all the stat()ing and translating
[11:53] <pitti> you still have to parse the actual data, of course
[11:53] <chrisccoulson> pitti - yeah, i was wondering if you were going to use a GKeyFile or not, or if you had any other ideas
[11:54] <chrisccoulson> i used the same thing for loading the required components in gnome-session
[11:54] <pitti> chrisccoulson: I started with a tab-separated-value approach, but that gets too fiddly
[11:54] <pitti> and probably won't save so much time, too
[11:54] <chrisccoulson> and maybe i might do something similar in g-s-d to create a cache of theme info :)
[11:54] <pitti> but the .cache file has a lot of unnecessary keys filtered out, pre-translated, and single-file
[11:54] <pitti> once I have a complete cache, I'll do some timing
[11:54] <chrisccoulson> cool:)
[11:56] <chrisccoulson> 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] <chrisccoulson> and i've already got a gnome-session that can start the session without reading from gconf :)
[12:00] <pitti> chrisccoulson: but we do need to start gconf either way, right?
[12:01] <seb128> chrisccoulson: some people looked at gconf speed a cycle ago I think and some patches went in
[12:01] <seb128> I don't think we should spend lot of efforts on gconf now
[12:01] <seb128> we will get dconf next cycle
[12:01] <chrisccoulson> 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] <pitti> oh, right
[12:02] <chrisccoulson> seb128 - yeah, i'm not going to spend too much time looking at it
[12:02] <seb128> but delaying gconf use until later seems good
[12:03] <seb128> lunch time!
[12:06] <pitti> vuntz: bonjour
[12:07] <pitti> vuntz: if you have a minute,  I have a first patch for gnome-menus caching: http://pastebin.com/f788f609d
[12:08] <pitti> vuntz: the .cache file is basically a single GKeyFile, one section per app, with strings pre-translated (thus it's called desktop.<localename>.cache), and unnecessary fields stripped
[12:08] <pitti> 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] <pitti> vuntz: do you think the general approach is okay?
[12:22] <vuntz> pitti: err, one big GKeyFile?
[12:22] <pitti> vuntz: I started with a CSV, but that quickly gets clumsy
[12:22] <vuntz> pitti: desrt was suggesting to use GVariant to have a binary mmap-able file
[12:23] <pitti> vuntz: is that in glib yet?
[12:23] <vuntz> pitti: I guess your approach can work in the meantime, but I won't accept that upstream
[12:24] <vuntz> pitti: not yet, will be merged "soon"
[12:24] <pitti> 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] <pitti> once gvariant lands, it's certainly promising
[12:26] <vuntz> pitti: shouldn't the cache be somewhere in /var ?
[12:26] <vuntz> (just reading the patch and commenting on details for now :-))
[12:27] <pitti> vuntz: no problem, can do that
[12:27] <pitti> replacing '/' with '_' and prepending /var/cache/gmenu/
[12:27] <pitti> vuntz: you'd lose the ability to have per-user cache files then, thoughh
[12:27] <pitti> (not that we want to integrate that by default, or that I deem it important to have)
[12:31] <vuntz> pitti: one issue is that your stuff is not recursive
[12:31] <vuntz> pitti: cached_dir_load_entries_recursive is really recursive
[12:31] <vuntz> pitti: (ie, it calls itself for subdirs)
[12:31] <pitti> vuntz: that was actually deliberate
[12:32] <pitti> a parent dir's cache should include the children
[12:32] <vuntz> so I would really rename functions :-)
[12:32] <pitti> no unnecessary start()/opendir()/parsing
[12:32] <pitti> ok
[12:32] <vuntz> I mean, right now, it's probably okay if we want the patch to not be invasive
[12:32] <vuntz> looks relatively sane
[12:33] <vuntz> but to get it upstream, there's some renaming to do, and gvariant, I guess
[12:33] <pitti> vuntz: which function would you rename? cached_dir_load_entries_from_cache_file() doesn't suggest it'd be recursive?
[12:33] <pitti> vuntz: gvariant> indeed, looking forward to that
[12:33] <vuntz> cached_dir_load_entries_recursive()
[12:33] <vuntz> ah, well
[12:33] <vuntz> I see
[12:33] <pitti> the cache builder needs to do the recursion
[12:34] <vuntz> I guess it's okay
[12:34] <pitti> in fact, cache builder == remove cache, gmenu_lookup_tree(), build key-file from that
[12:35] <vuntz> (my comments are really about style, which doesn't matter for now anyway :-))
[12:35] <pitti> appreciated
[12:35] <pitti> it's the first time I hack on gmenu, so it took me some time to understand the structure
[12:35] <vuntz> yeah, it's, hrm, messy
[12:35] <vuntz> and you didn't even start trying to fix some monitoring bug
[12:36] <vuntz> it should get rewritten with real gobjects instead of pseudo-objects that have pseudo-signals
[12:37] <pitti> so, if that won't land upstream, I can just as well write update-gmenu-cache in Python for simplicity
[12:37] <vuntz> pitti: you probably also want to do something about gio, since g_app_info_get_all() will do the same
[12:37] <pitti> since that will need to be re-done anyway with gvariant
[12:37] <vuntz> yep
[12:38] <pitti> vuntz: oh, and that doesn't use gnome-menus?
[12:38] <vuntz> nope
[12:38] <pitti> okay
[12:38] <pitti> but I guess I'll do that once gvariant lands, to avoid doing things twice
[12:53] <kklimonda> good afternoon
[12:53] <kklimonda> pitti: can you take a look at bug 457123, is it a good candidate for sru now that the patch is ready?
[13:31] <pitti> "/away -all
[13:32] <pitti> kklimonda: looks sane enough
[13:36] <kenvandine> cassidy, i snagged bug 491317
[13:36] <kenvandine> will look at it today
[13:37] <kenvandine> although i doubt it can be fixed for karmic
[13:37] <kenvandine> but for lucid for sure :)
[13:43] <daemonza> Hi any openbox users here?
[13:52] <seb128> kenvandine, hey, he said that's ok they will backport the fix in their ppa
[13:52] <seb128> 2.29 is not in karmic anyway
[13:57] <cassidy> yep
[14:15] <chrisccoulson> mdeslaur - can you recreate the screensaver crash?
[14:16] <mdeslaur> chrisccoulson: no, unfortunately
[14:16] <chrisccoulson> that's a shame. i haven't seen it yet either :(
[14:17] <mdeslaur> chrisccoulson: yeah...it's hard to debug problems we can't reproduce :(
[14:19] <chrisccoulson> it is. the last screensaver crash was hard enough to debug, and i could recreate that one (albeit, not very often)
[14:35]  * pitti smiles about his wife
[14:35] <pitti> I just showed her dotty
[14:36] <pitti> she currently has a task to create some XML and DTD, and to do a structure tree
[15:41] <cj> grr... my laptop screen keeps dimming.  how do I *really* disable delayed dimming?
[15:41] <cj> pitti: my wife is finally learning html & css.  good fun.
[15:42] <MenZa> cj: my gf's on the Python wagon :)
[15:42] <cj> I unchecked 'Dim display when idle' and pushed 'Set display brightness to:' up to 100% in the Power Management Preferences dialogue.
[15:43] <cj> MenZa: onoes!  what is the perl community going to do!?
[15:43] <MenZa> :D
[15:43]  * cj scowls at the competition
[15:44] <pitti> vuntz, seb128: hm, using the single-reduced-keyfile approach is still slow, but it's an improvement
[15:44] <pitti> default:
[15:44] <pitti> cold cache: 7.9
[15:44] <pitti> hot cache: 0.3
[15:44] <pitti> patch:
[15:44] <pitti> cold cache: 2.7
[15:44] <pitti> hot cache: 0.1
[15:44] <pitti> (in seconds)
[15:44] <pitti> average of three runs
[15:45] <vuntz> pitti: still much better. And the mmap file should help quite a bit for the remaining part
[15:46] <pitti> yeah
[15:46] <pitti> a nice standard serialization API for this kind of nested data structures is badly missing indeed
[15:47] <pitti> FYI, that's the time of
[15:47] <pitti>     setlocale(LC_ALL, "");
[15:47] <pitti>     GMenuTree* tree = gmenu_tree_lookup("applications.menu", GMENU_TREE_FLAGS_NONE);
[15:47] <pitti>     printf("%p\n", gmenu_tree_get_root_directory(tree));
[15:59] <seb128> pitti, gains even small ones are welcome and that one is quite nice to get!
[15:59] <pitti> seb128: I'll upload it to a PPA
[15:59] <pitti> seb128: I have a call with Rick now and then I need to run
[15:59] <seb128> ok
[15:59] <pitti> seb128: once it's built, would you want to do a test run?
[16:00] <pitti> seb128: upgrade to it, then
[16:00] <seb128> sure
[16:00] <seb128> does it work out of the box?
[16:00] <seb128> or do I need to generate the cache by hand?
[16:00] <pitti> update-gnome-menus-cache /usr/share/applications/ > /usr/share/applications/$LANG.cache
[16:01] <pitti> seb128: then remove the ureadahead cache
[16:01] <pitti> boot once to regenerate it
[16:01] <pitti> and then another time
[16:01] <pitti> since this will take out all the *.desktops from readahead
[16:01] <pitti> and include the .cache
[16:01] <seb128> where is the cache?
[16:02] <pitti> seb128: I'll deal with those ^ in the final upload, but run out of time now
[16:02] <pitti> seb128: sorry, /usr/share/applications/desktop.$LANG.cache
[16:02] <pitti> /usr/share/applications/desktop.de_DE.UTF-8.cache
[16:02] <pitti> ^ for me
[16:02] <seb128> ok
[16:02] <pitti> seb128: I'll move it to var
[16:02] <seb128> and the the boot one?
[16:02] <seb128> I've never cleaned that by hand
[16:02] <pitti> but I'm interested in how much it brings
[16:02] <seb128> I usually let the distro do whatever is standard
[16:02] <pitti> seb128: /var/lib/ureadahead/pack ?
[16:02] <seb128> ok thanks
[16:02] <seb128> I never looked at how that works
[16:02] <seb128> it's just magic to me ;-)
[16:03] <pitti> see /var/lib/dpkg/info/ureadahead.postinst
[16:03] <pitti> rm -f /var/lib/ureadahead/pack /var/lib/ureadahead/*.pack
[16:03] <seb128> cool
[16:03] <seb128> I think I've everything I need for testing
[16:03] <seb128> I will let you know how it goes
[16:03] <pitti> seb128: if it's worth doing, I'll add the magic triggering bits, cache autogeneration, etc.
[16:03] <pitti> seb128: merci!
[16:03] <pitti> rickspencer3: call now?
[16:05] <pitti> seb128: oops; just noticed a "slight" bug -- application entries don't actually work :-(
[16:05] <pitti> but well, that should be easy to fix :)
[16:05] <seb128> still worth testing the speed?
[16:05] <pitti> seb128: yes, please
[16:05] <seb128> ok
[16:05] <pitti> seb128: just move away the .cache file and restart panel
[16:06] <pitti> to get the default situation back
[16:06] <seb128> ok
[16:07] <pitti> seb128: uploaded to desktop PPA now
[16:07] <seb128> ok
[16:07]  * pitti pushes to bzr, too
[16:20] <cj> so... any clue why my laptop monitor keeps dimming?
[16:32]  * pitti -> off for today
[16:32] <seb128> pitti, bye
[17:07] <jcastro> rickspencer3, FYI I will be tracking the priority set of applications on my blueprint
[17:07] <jcastro> wrt dx-lucid-application-indicator
[17:08] <kenvandine> jcastro, cool
[17:08] <jcastro> once I get the DX team to commit to the list I will add it to my bp, file the bugs for each one, etc.
[17:20] <bryce> can someone tell me what version of gnome is being targeted for Lucid?  (ATI wants to know for fglrx)
[17:29] <baptistemm> bryce, I would guess 2.30
[17:30] <baptistemm> better to ask to seb128
[18:27] <chrisccoulson> hello seb128
[18:28] <seb128> hey chrisccoulson
[18:28] <seb128> how are you?
[18:28] <chrisccoulson> yeah, not too bad, although a bit tired. just got back in from work
[18:28] <chrisccoulson> how are you?
[18:29] <seb128> pitti, the gnome-menus caching is a 0.5 second win apparently
[18:29] <kenvandine> seb128, awesome
[18:29] <seb128> chrisccoulson, quite good, thanks, feeling like I didn't make best use of my time for 2 hours though
[18:30] <chrisccoulson> how come?
[18:30] <seb128> I tried to install karmic on computer which failed at grub stage
[18:30] <chrisccoulson> ah, that's not good
[18:30] <seb128> then the installer wouldn't go after the timezone steps in the installer
[18:30] <chrisccoulson> did you get it working in the end?
[18:30] <seb128> and usb-creator just fail on lucid
[18:31] <seb128> so I had to reboot my laptop to create a new usb key from a cdrom boot...
[18:31] <seb128> no
[18:31] <seb128> I've an install done but no grub booting it
[18:31] <seb128> I just finished rewriting the key
[18:31] <seb128> at least I managed to try the gnome-menus caching changes from pitti meanwhile
[18:31] <chrisccoulson> i had issues installing karmic on my desktop, but it turned out to be my fault in the end
[18:32] <chrisccoulson> yeah, that looks quite promising
[18:32] <seb128> I hate the multi-disk with win scenario
[18:32] <seb128> I never know where to install grub
[18:32] <seb128> and I'm always scare to nuke the winxp bootloader and get people angry
[18:32] <chrisccoulson> i don't have that issue any more :)
[18:32] <chrisccoulson> well, i have multiple disks, but only one OS
[18:33] <seb128> default install picked sdb which is were the linux partition is
[18:33] <seb128> that failed though
[18:33] <seb128> I'm not sure about using sda since I don't want to overwrite the win bootloader
[18:33] <chrisccoulson> my issue was that i used to use dmraid on my machine, and when i nuked that, there was still some metadata left on the disk, and it messed things up
[18:34] <seb128> yeah, I noticed you had quite some fun during karmic with your boot config
[18:35] <seb128> especially with the boot speed changes which landed
[18:35] <chrisccoulson> yeah, i had a lot of issues with that, but mainly down to my wierd config ;)
[19:39] <fagan> can someone help me diagnose a bug in lucid? Im having panels dissapear and reappear every 2 or 3 seconds
[19:44] <kklimonda> will we have a simple way to install only selected packages from -backports in 10.04 ?
[19:44] <chrisccoulson> fagan - is gnome-panel just crashing?
[19:45] <fagan> It seems to load but then removes itself then reloads
[19:45] <fagan> it does that over and over
[19:45] <chrisccoulson> right, it will do that if it's crashing
[19:46] <fagan> I dont know how to debug it without being able to access terminal
[19:46] <chrisccoulson> but you would either need to obtain a backtrace of that, or enable apport and have it catch the crash instead
[19:46] <fagan> I cant get to terminal
[19:46] <chrisccoulson> why not?
[19:47] <fagan> Alt+f4 cant stay open long enough and I cant get it through the menu
[19:47] <chrisccoulson> hmmm, why not just switch to a VT instead?
[19:47] <chrisccoulson> the panel is not really needed to get access to a terminal
[19:48] <fagan> Oh ok so what should I be looking for?
[19:48] <chrisccoulson> well, you should probably try enabling apport first
[19:49] <chrisccoulson> if it's crashing, you can submit a crash report then
[19:49] <fagan> chrisccoulson: isnt apport enabled already?
[19:49] <chrisccoulson> i don't think it's enabled this early on in the cycle
[19:50] <fagan> Oh ok so ill enable apport and see what that picks up
[19:50] <chrisccoulson> cool, thanks
[19:50] <seb128> fagan, you should be able to right click on the desktop and create a launcher
[19:50] <seb128> works usually to open a command line
[19:50] <chrisccoulson> heh, i didn't think of that
[19:51] <chrisccoulson> i just normally switch to a VT when debugging core desktop components
[19:51] <fagan> ill be back in 10 and ill see what I can find out
[20:02] <fagan> ok so to start apport I need to sudo service apport start?
[20:03] <fagan> ok so to start apport I need to sudo service apport start?
[20:05] <fagan> chrisccoulson: the original crash was in libsnmp-base
[20:12] <fagan> apport isnt picking up the crash. It only says seg fault in terminal when I try load gnome-panel manually. I also tried with compiz on and compiz off it still seg faults.
[20:12] <fagan> This is something bad
[20:18] <fagan> The only thing of interest I can see is (gnome-panel:7947): Gdk-WARNING **: /build/buildd/gtk+2.0-2.19.1/gdk/x11/gdkdrawable-x11.c:952 drawable is not a pixmap or window
[20:19] <fagan> But that might be unrelated
[21:00] <chrisccoulson> oh, fagan has disappeared now
[21:00] <chrisccoulson> i wonder if he's figured out how to enable apport yet :-/
[21:59] <seb128> hey robert_ancell
[22:00] <robert_ancell> seb128, hey
[22:00] <seb128> how are you?
[22:01] <robert_ancell> seb128, good
[22:01] <seb128> cool
[22:02] <fagan> ooh I think my problem maybe a python issue because firefox crashed and complained about python
[22:02] <seb128> robert_ancell, I would like to change a bit versions.html this cycle but want to discuss it with you before
[22:02] <robert_ancell> seb128, sure
[22:02] <seb128> I'm slightly annoyed by having things there we don't care about
[22:02] <seb128> ie openssh
[22:03] <seb128> you are the one who added those, what were you aiming at?
[22:03] <seb128> having all the things on the cd there?
[22:03] <robert_ancell> seb128, just adding everything on the cd
[22:03] <seb128> I sort of what to use the list for desktop team todolisting
[22:03] <seb128> what -> want
[22:03] <robert_ancell> seb128, I propose you just quote out the things we don't want in the versions.py and we see if anyone (including me) complains
[22:04] <seb128> so things we don't touch would be nice out of the way
[22:04] <seb128> other thing is that we need a way to fix a serie
[22:04]  * fagan cant pastebin because firefox and chrome dont stay alive :(
[22:04] <seb128> like dbus is 1.3 and we want 1.2
[22:04] <seb128> and I think it's what we want
[22:04] <seb128> how would you suggest handling that?
[22:05] <robert_ancell> seb128, that one is harder..  that was when I started looking at launchpadlib to do that as it tracks that information.  I couldn't get it to work though
[22:05] <seb128> adding an extra optimal argument to the list?
[22:05] <robert_ancell> seb128, the bit I was worried about was the potential increase in download times.
[22:05] <seb128> why?
[22:05] <robert_ancell> seb128, agreed, extra arg will do it for now
[22:06] <seb128> the current list is (component, url)
[22:06] <seb128> if we had (component, url, optionalserie) we could use the extra argument for version matching
[22:06] <seb128> that should not mean anything else for downloads
[22:06] <robert_ancell> yes agreed, don't block on me.
[22:07] <seb128> ok
[22:07] <robert_ancell> I don't know how long it takes to run on pittis box but it takes ages for me here :)
[22:07] <seb128> next thing I would like to do is a way to update the list without querying upstream urls and launchpad
[22:07] <seb128> just refreshing ubuntu and debian versions
[22:08] <seb128> and gnome for things in the vuntz's list, that's quick too
[22:08] <fagan> brb
[22:08] <seb128> right
[22:08] <robert_ancell> seb128, yes, I was looking at two scripts - one to basically do what vuntz is doing for all upstreams and the other to generate the list and check for LP bugs
[22:09] <robert_ancell> run the second one on demand (or near to demand)
[22:10] <robert_ancell> and ideally to trigger the former from email on the GNOME FTP list
[22:10] <seb128> right
[22:10] <seb128> anyway that's some extra work
[22:10] <seb128> I think I will start by adding the serie thing
[22:11] <seb128> that will avoid having people working on things we don't want to update
[22:11] <robert_ancell> sure, it's all incremental stuff (though I talk to the LP guys now and then how we can do it with their data)
[22:11] <seb128> and clean a bit the list
[22:11] <robert_ancell> yes
[22:11] <robert_ancell> +1
[22:11] <seb128> :-)
[22:11] <seb128> totem merged, that one was annoyed
[22:11] <robert_ancell> (just please leave the data in the versions.py so we can use it at a later time if we want it)
[22:12] <robert_ancell> yes I tried totem and gave up the other day
[22:12] <seb128> good point, I will comment those
[22:12] <seb128> the remaining merges start being annoying
[22:12] <robert_ancell> they're all annoying :)
[22:13] <seb128> well some are trivial
[22:13] <seb128> like copy the lpi patch and be done
[22:13] <robert_ancell> some have more changelog than merge!
[22:13] <seb128> I just keep the current changelog entry ;-)
[22:13] <seb128> btw don't bother merging the changelog
[22:14] <robert_ancell> I now have to deal with three layers of merging - oem project specific + oem + ubuntu + debian
[22:14] <seb128> just drop the previous entries if you do a summary
[22:14] <seb128> hehe
[22:14] <seb128> oh btw we usually start at ubuntu1 not ubuntu0
[22:15] <seb128> (you used ubuntu0 for the file-roller one)
[22:16] <robert_ancell> oh I keep screwing up the version numbers...
[22:17] <fagan> ok so I need someone to walk me through debugging this crash. Command by command please because I dont have a clue about debugging
[22:17] <fagan> first how do I start apport?
[22:20] <fagan> chrisccoulson: help ^
[22:21] <chrisccoulson> fagan - you need to enable apport in /etc/default/apport
[22:21] <chrisccoulson> and then restart it with "sudo service apport restart"
[22:22] <chrisccoulson> i've got to disappear for a bit, but i'll be back later
[22:23] <fagan> cool ill see what i can find out
[22:24] <fagan> hmmm im getting a weird error when I try start apport
[22:25] <fagan> http://pastebin.ubuntu.com/333457/
[22:25] <chrisccoulson> i'm back again for a few minutes, it was a false alarm ;)
[22:25] <chrisccoulson> i've no idea what that error means
[22:25] <fagan> pitti: ^^^
[22:25]  * fagan thinks its a python problem
[22:30] <fagan> Ok the recent crashes I got were for libsnmp-base libfreetype6-dev so what do those packages do that can crash gnome-panel with a segfault
[22:33] <fagan> Ok after fiddling about a little I know where the segfault is
[22:33] <fagan> Its something to do with the menus
[22:37] <fagan> anyone any ideas?
[22:42] <fagan> http://pastebin.ubuntu.com/333471/ chrisccoulson here is a better error why gnome-panel is crashing
[22:51]  * fagan feels very alone with his problem and will reinstall in the morning but still wants to figure out the problem
[22:51] <robert_ancell> seb128, can you look at the metacity update I did - it doesn't seem uploadable by me
[22:52] <robert_ancell> (in bzr)
[22:52] <seb128> why not uploadable?
[22:55] <seb128> robert_ancell,  ^?
[22:55] <robert_ancell> bug 490214
[22:56] <robert_ancell> permissions - is metacity on the ~ubuntu-desktop list?
[22:56] <seb128> what error do you get on upload?
[22:56] <robert_ancell> I'll try again
[23:03]  * ccheney will finally get to see snow again at home, was gone to UDS last year when it happened and hadn't happened in about 15 years before that
[23:03] <seb128> robert_ancell, time to go to bed for me, I will check with pitti tomorrow if you didn't upload during your day
[23:03] <seb128> or rather if it your upload doesn't make it to lucid
[23:04] <seb128> 'night everybody!!
[23:04] <robert_ancell> seb128, "Signer is not permitted to upload to the component 'main'."
[23:04] <robert_ancell> seb128, night!
[23:04] <seb128> robert_ancell, ok, will check with pitti tomorrow and get that fixed if somebody knows what's going onj
[23:04] <seb128> bye
[23:10] <pitti> robert_ancell: seems metacity is in "core" then; I sent the command to the -desktop ML some days ago
[23:10] <pitti> edit_acl.py, I meant (for checking permissions)
[23:10] <robert_ancell> pitti, ok, thanks!
[23:11] <pitti> robert_ancell: need sponsoring for metacity?
[23:11] <ph8> hey all, i've got a 3 screen nvidia setup and i've got a problem with moving windows. Often when i click a window's toolbar and drag it the last window i had selected gets dragged instead - any idea what's up with that?
[23:11] <robert_ancell> pitti, yes please - might as well upload it now
[23:16] <pitti> robert_ancell: FYI, upgrades from gutsy are no longer supported, so we can drop delta from that
[23:16] <pitti> (preinst bits)
[23:17] <robert_ancell> pitti, cool, I was going to ask about that. What is the rule about what we have to support upgrading from?
[23:18] <pitti> robert_ancell: version -> version, LTS -> LTS in general
[23:18] <robert_ancell> ok
[23:18] <pitti> robert_ancell: so, we need to keep upgrade quirks for "since last LTS" until the next LTS is released
[23:18] <pitti> i. e. currently we need to keep all upgrade quirks since hardy, until after lucid's release
[23:19] <pitti> robert_ancell: want to drop that delta and remove from changelog before upload?
[23:19] <robert_ancell> sure, will do now
[23:20]  * robert_ancell compiling metacity...
[23:26] <chrisccoulson> fagan - i'm not convinced that error message is anything to do with the crash. but, without a backtrace, it doesn't really tell me anything at all
[23:31] <robert_ancell> pitti, ready to upload
[23:32] <pitti> thanks! nice, that dropped a lot of cruft
[23:33] <pitti> robert_ancell: BTW, now that you can upload most bits, do you know that/how to use debuild -v with merges?
[23:33] <robert_ancell> no
[23:34] <pitti> robert_ancell: so, with -v<version> the source.changes will include all changelogs since (not including) version
[23:35] <pitti> robert_ancell: i. e. that on -changes@ you both see the last one as usual ("merged from debian blabla") and also the actual changes from Debian
[23:35] <pitti> robert_ancell: <version> should be "last version in Ubuntu"
[23:35] <robert_ancell> ah ok
[23:35] <robert_ancell> can you do that from bzr-buildpackage?
[23:35] <pitti> i. e. here I did "bzr bd -S -- -sa -v1:2.28.0-0ubuntu1"
[23:36] <pitti> yes, it takes debuild arguments after --
[23:36] <robert_ancell> I notice you can't do bzr-buildpackage -S -sa which is annoying
[23:36] <robert_ancell> yay!
[23:36] <pitti> -S is special
[23:36] <pitti> -S -- -sa works
[23:36] <pitti> another useful thing is bzr bd -- -b -us -uc for a test build
[23:36] <pitti> you get the idea
[23:37] <robert_ancell> nice
[23:43] <pitti> good night everyone!
[23:51] <bryce> pitti, http://www.phoronix.com/scan.php?page=news_item&px=Nzc2Mw