[10:00] <seb128> pitti, where are you hiding today? ;-)
[10:07] <pitti> seb128: with the security team, to discuss executable file handling policy
[10:07] <seb128> pitti, ok, I'm available for login speed or apport when you want
[10:08] <pitti> shouldn't take long any more
[10:19] <kklimonda> pitti: care to take a look at bug 408600? It hits all poor ubuntuone users out there ;)
[10:22] <pitti> kklimonda: sure, will sponsor
[11:26] <didrocks> seb128, pitti: I'm a bit puzzled about one thing in mime association. If I make a file -i xxx and getting applications/ogg, the file seems to match the following mime types in mimeinfo.cache:
[11:27] <didrocks> application/x-ogg, application/ogg, audio/ogg are taken into account in the "open with" box but video/ogg is not matched. Where is the magic? :)
[11:27] <didrocks> In addition to this, the priority (without defaults.list) is matched on the first element in the audio/ogg line independently to its location in mimeinfo.cache.
[11:27] <seb128> didrocks, file is not using the shared-mime-info database
[11:28] <seb128> didrocks, /usr/share/mime/packages/freedesktop.org.xml has the magic detection
[11:28] <seb128>       <match value="OggS" type="string" offset="0"/>
[11:28] <seb128> and .ogv
[11:28] <seb128> is what shared mime info is using
[11:28] <didrocks> seb128: oh ok. Is there a magic command to know what is the accurate mime file using this additional rules?
[11:29] <seb128> the xdgmime can use the filename or content
[11:29] <seb128> they call that fast or slow detection I think
[11:29] <seb128> the defaults.list ordering is not revelant
[11:29] <seb128> it's meant to list one default by mimetype
[11:29] <seb128> not to have a sorted list
[11:29] <seb128> same for the cache file
[11:29] <didrocks> seb128: yes. I was talking about the ordering in mimeinfo.cache in fact
[11:30] <didrocks> yes, that's confirm what I experience here
[11:30] <seb128> that's why we said we need to change the cache semantic
[11:30] <didrocks> seb128: I'm just a bit confused about the mime.cache and mimeinfo.cache (on the xdg list they assume that mimeinfo.cache is only a GNOME thing)
[11:30] <seb128> there is no mime.cache?
[11:31] <didrocks> seb128: on the xdg list, they say that mime.cache is what should be used and that mimeinfo.cache is GNOME specific thing
[11:31] <seb128> oh, that's a cache of all the shared mime info datas
[11:31] <seb128> it doesn't have default selection choice, etc
[11:32] <rickspencer31> bryce: where r u?
[11:33] <seb128> rickspencer31, he was in front of you 1 minute ago before you moved
[11:33] <seb128> rickspencer31, still there
[11:33] <seb128> ie sitting just next to me and pitti
[11:33] <didrocks> seb128: so, if mimeinfo.cache is specific to GNOME, it would be difficult to make the changes apply to fdo
[11:33] <seb128> didrocks, http://lists.freedesktop.org/archives/xdg/2008-January/009112.html
[11:34] <seb128> didrocks, read this discussion
[11:34] <didrocks> ok, thanks. Reading it now :)
[11:34] <seb128> didrocks, the whole discussion rather than this specific email I think
[11:35] <didrocks> seb128: yes, I've already head to the root of it :)
[11:53] <jpds> Morning.
[11:54] <jpds> Does anyone know why I'm missing icons on all my right-click menus on karmic? http://spooky.ubuntuwire.com/~jpds/2009-08-04-115224_1280x800_scrot.png
[11:54] <jpds> I'm created a brand-new user, changed icon themes, but I still get no icons...
[11:56] <kklimonda> jpds: that's upstream decision
[11:57] <ruslanr> jpds: http://www.andreasn.se/blog/?p=103 & http://bugzilla.gnome.org/show_bug.cgi?id=557469
[11:59] <jpds> How annoying.
[14:49] <bcurtiswx> hey all, bug #400485 is one I think should be looked at by you guys :-)
[15:14] <asac> seb128: https://edge.launchpad.net/~asac/+archive/ppa/+files/gnome-bluetooth_2.27.8-0ubuntu1~asac.dsc
[15:28] <asac> pitti: https://bugs.edge.launchpad.net/ubuntu/+source/libmbca/+bug/408763
[15:30] <mpt> mat_t, I've taken a photo of the revised Empathy welcome screen with your camera, so if you could connect it up sometime today that would be smashing :-)
[15:34] <pitti> vuntz: hey
[15:36] <vuntz> pitti: ho!
[15:37] <pitti> vuntz: I'm planning to start working on the gnome-menus caching, FYI
[15:37] <mac_v> jpds: bug #407621
[15:37] <mac_v> jpds: i'v sent a mail to the list too , regarding this
[15:38] <pitti> vuntz: I wondered whether you have some advice where to do the cache lookup
[15:38] <pitti> vuntz: would it be sensible to hook it into gmenu_tree_lookup()?
[15:38] <pitti> vuntz: and if you want applications.menu, it'd look into /var/cache/gnome-menu/applications.menu.bin or so?
[15:39] <vuntz> pitti: hrm, I probably would do a general cache, not one that is specific to menus
[15:40] <vuntz> pitti: eg, if you want to find a mime handler, you need to look at the desktop files too
[15:45] <o0spongebob0o_> salut a tous
[15:46] <pitti> vuntz: right, but in order for it to make sense, we need to check for the caches seldomly and load the entire menu in one go; with one cache per desktop file it'd quickly loose its value?
[15:48]  * mclasen points out that gio might be a better place to do general appinfo caching
[15:48] <vuntz> pitti: well, I guess it's up to the caller to know when it needs to look at many desktop files
[15:49] <vuntz> pitti: I just don't think organizing it on a per-menu file is right
[15:49] <pitti> vuntz: okay, I'm open to suggestions; admittedly it's the first time I look into the gnome-menus api
[15:53] <kenvandine> pitti, can you sponsor bug 403575?  it breaks desktopcouch
[15:57] <pitti> kenvandine: done
[15:57] <kenvandine> awesome
[15:57] <kenvandine> thanks!
[16:01] <vuntz> pitti: well, it really shouldn't appear in the API anyway :-)
[16:01] <pitti> vuntz: *nod*
[16:02] <seb128> asac,
[16:02] <seb128> "<hadess> seb128: that code is exported twice to the internal apps, once through the public library, once through the local library
[16:02] <seb128>  seb128: it's supposed to be fine"
[16:02] <seb128> asac, that's the issue for pretty sure
[16:02] <seb128> I think that's something uncorrect
[16:03] <seb128> and our toolchain expose the issue where other distributions' ones don't
[16:03] <seb128> could be a flag we turn on somewhere
[16:05] <pitti> vuntz: so gmenu-tree.c already uses an internal cache (gmenu_tree_cache) which we could pre-populate in gmenu_tree_new() from a fast mmap-based cache
[16:05] <pitti> vuntz: however, would that actually help us so much?
[16:05] <pitti> vuntz: i. e. the bulk of the time is certainly spent reading hte .desktop files, not the .menu files?
[16:08] <vuntz> pitti: what you want to replace is probably something like _entry_directory_list_get_all_desktops()
[16:10] <pitti> vuntz: ah, thanks for the hint
[16:10]  * pitti -> meeting
[16:21] <mat_t> mpt: np
[16:36] <mac_v> bigon: hi , could you take a look at this Bug #408913
[17:56] <djsiegel> rickspencer31: https://wiki.ubuntu.com/DesktopTeam/Specs/KarmicFusa?action=AttachFile&do=get&target=fusa_2.png
[17:57] <djsiegel> rickspencer31: https://wiki.ubuntu.com/DesktopTeam/Specs/KarmicFusa
[17:58] <asac> awe: DEB_DH_INSTALLINIT_ARGS
[18:24] <Ng> tedg: is fusa going to force display of the user face icon (perhaps only if it's actually been set)?
[18:24] <Ng> I take back my hate of the icon dropping change since I realised I can force it on for the two icons in my menu that desparately need it ;)
[18:25] <tedg> Ng: Yes, I believe it'll have icons if they're set.
[18:26] <tedg> Ng: But, since they're in your home directory.  I'm not sure how useful it'll be with encrypted homes...
[18:35] <chrisccoulson> fta - someone else reported the same issue as you now with incorrect space remaining on the low disk space warning
[18:35] <chrisccoulson> are you running 32bit install?
[18:35] <fta> yes
[18:35] <chrisccoulson> that might be why you see it and i cant reproduce it
[18:36] <chrisccoulson> fsblkcnt_t in 64-bits on a 64-bit install isn't it?
[18:36] <chrisccoulson> anyway, i can see where it goes wrong now
[18:39] <fta> chrisccoulson, http://paste.ubuntu.com/247364/
[18:41] <fta> chrisccoulson, and in 64bit mode: http://paste.ubuntu.com/247366/
[18:42] <chrisccoulson> cool, thanks!
[18:44] <fta> (both are from my 32bit box)
[18:47] <fta> chrisccoulson, imho, it's just that at some point, you have f_frsize * f_bavail in a 32bit variable, which is wrong
[19:29] <sebas__> hi all
[19:30] <sebas__> does anybody have a strange wrong webcam zoom effect using compiz ?
[19:33] <sebas__> Hi All
[19:33] <sebas__> does anybody have a strange wrong webcam zoom effect using compiz ?
[21:04] <dobey> hrmm
[21:04] <dobey> any universe sponsors about?
[21:10] <james_w> dobey: yeah, what's up?
[21:11] <dobey> james_w: bug #406413
[21:11] <dobey> james_w: just wondering if we can get that in :)
[22:12] <chrisccoulson> fta - could you test a PPA build of g-s-d shortly?
[22:12] <chrisccoulson> (sorry, just got back from dinner)
[22:13] <fta> sure, direct link?
[22:13] <chrisccoulson> i'll give you it once it's uploaded
[22:13] <chrisccoulson> i should test it quickly here first ;)
[22:31] <chrisccoulson> fta - i've uploaded it to https://edge.launchpad.net/~chrisccoulson/+archive/ppa
[22:31] <chrisccoulson> (but it hasn't built just yet)
[22:38] <chrisccoulson> i386 is built now:)
[23:32] <ccheney> asac: ping, found a patch for OOo for xulrunner 1.9.1
[23:32] <ccheney> asac: emailed you the link to it