[06:59] <pitti> Good morning
[07:59] <crevette> hello
[08:00] <crevette> good morning
[08:15] <didrocks> morning o/
[08:20] <seb128> hello everybody
[08:21] <didrocks> hi seb128, did you have a good night?
[08:22] <seb128> lut didrocks
[08:22] <seb128> very good, you?
[08:22] <didrocks> long one. So, yes :)
[08:32] <seb128> pitti: hey there ;-) libical sru got two comment saying that the update works, could you move it to -updates today?
[08:32] <pitti> seb128: yay nice
[08:32] <seb128> it will make easier to sort issues that people are having because they didn't get the update yet and other crashers
[08:33] <seb128> thanks
[08:37]  * chrisccoulson wishes he had more positive feedback on his tracker SRU
[08:53] <robert_ancell> hi all#
[08:53] <pitti> hey robert_ancell
[08:53]  * robert_ancell found totem very hard to merge with debian.  So many changes...
[08:54] <pitti> robert_ancell: what are you looking at, the MoM output?
[08:54] <pitti> robert_ancell: I usually do interdiff -z -p1 debian.diff.gz ubuntu.diff.gz
[08:54] <pitti> and then see which of the delta is important
[08:54] <robert_ancell> pitti: it was more deciphering what the changes were, why they were done, and if they were debian/ubuntu specific
[08:55] <robert_ancell> I files a bug with Debian with the changes in Ubuntu that I think are applicable to them
[08:55] <robert_ancell> And I want to push the BBC changes upstream as there's at least 3 versions of that patch floating around
[08:56] <pitti> oh yes, I guess that caused a lot of delta
[08:56] <pitti> robert_ancell: another major thing might be the codec install stuff?
[08:56] <seb128> hello robert_ancell
[08:57] <seb128> sorry I had to reboot to test changes
[08:57] <robert_ancell> seb128: hey
[08:57] <seb128> pitti: the codec install is upstream gstreamer code
[08:57] <seb128> pitti: we only customize the application called using a configure option
[08:57] <pitti> ah, I thougth we needed debian/ubuntu stuff for calling g-a-i
[08:57] <pitti> I keep mixing that up
[08:57] <seb128> robert_ancell: I'm not sure about BBC plugin in debian, they don't have a good infrastructure for translations
[08:57] <robert_ancell> Hey do you guys know why when I tried to put GDL in BZR I got the following error:
[08:58] <robert_ancell> bob@alchemy2:~/bzr/gdl$ bzr push lp:~ubuntu-desktop/gdl/ubuntu
[08:58] <robert_ancell> bzr: ERROR: Invalid url supplied to transport: "lp:~ubuntu-desktop/gdl/ubuntu": No such project: gdl
[08:58] <seb128> because there is no gdl project registered on launchpad
[08:58] <seb128> that's a stupid limitation if you ask me
[08:58] <pitti> at some time LP will grow package branches
[08:58] <seb128> but it's easy enough to register the project
[08:58] <pitti> but for now we only have branches on projects
[08:59] <seb128> we do it to be able to open upstream tasks anyway
[08:59] <seb128> just nobody came and did this one yet
[08:59] <robert_ancell> ok, cool
[09:00] <robert_ancell> how to register a project?
[09:01] <seb128> https://edge.launchpad.net/projects/+new
[09:01] <seb128> hum, maybe not wait
[09:02] <seb128> I think that's this one
[09:02] <pitti> right, it is
[09:02] <seb128> I've not done that for a while so I'm not sure now, but I think that's this one
[09:03] <robert_ancell> ok, registering now
[09:06] <robert_ancell> that seemed to work, thanks
[09:07] <robert_ancell> I'm heading off soon, anything anyone want to cajole me into doing tomorrow?
[09:08] <seb128> robert_ancell: what did you do today? managed to get the totem updates done?
[09:08] <seb128> robert_ancell: do you still have things on your list to merge or update?
[09:09] <robert_ancell> seb128: yes, I've done all the merges/updates I had listed
[09:09] <seb128> did you get the gdm merge on your list?
[09:09] <seb128> I think I mentioned it the other day to do but I'm not sure if you are interested in that one
[09:10] <robert_ancell> seb128: no, when I asked you yesterday it sounded like we should discuss at UDS first due to the missing features
[09:10] <robert_ancell> I wouldn't say gdm excites me
[09:10] <seb128> that's the new gdm discussion
[09:10] <seb128> we might want to merge the current one with debian, ie rebase our version on their current one
[09:10] <seb128> ok so don't bother, it's a fairly non trivial one and I know the package I will do it
[09:11] <robert_ancell> ok
[09:11] <seb128> robert_ancell: I will drop you an email with some suggestions for tomorrow later
[09:11] <robert_ancell> seb128: ok, thanks.
[09:12] <robert_ancell> see you guys tomorrow! (two days and then I'll catch you all in Barcelona!)
[09:12] <seb128> and we really need to have a team discussion about better workflow at uds
[09:12] <robert_ancell> two work days that is
[09:12] <seb128> yeah
[09:12] <pitti> see you robert_ancell, good night!
[09:12] <seb128> have fun, see you tomorrow
[09:12] <robert_ancell> later pitti!
[09:14]  * seb128 does some sponsoring
[09:15] <seb128> lut crevette
[09:16] <crevette> hi there
[09:20] <crevette> hey seb128, thanks for the kick in the butt on the bluez bug :)
[09:21] <crevette> as I took a hal day off to take care of my son, I could manage to update to 4.39
[09:21] <seb128> you're welcome ;-)
[09:21] <seb128> ah good
[09:24] <crevette> hey new gvfs
[09:26] <seb128> indeed
[09:30] <crevette> seb128: ah btw I had to sleep yesterday evening, did I answer to your questions?
[09:31] <seb128> yes thanks
[09:39] <seb128> didrocks: dunno how busy you will be today but do you think you can add "review bug #375843" to your list?
[09:39] <crevette> okay great
[09:39] <seb128> didrocks: that's a sponsoring request
[09:56] <seb128> hum ok
[09:56]  * seb128 bounced robert_ancell sponsoring requests to "needwork"
[10:32] <seb128> pitti: do we have karmic retracers yet?
[10:32] <pitti> seb128: ah, no, we don't (apport is not enabled yet)
[10:32] <pitti> we need to build a karmic chroot
[10:32] <seb128> right, that's what I though
[10:33]  * pitti adds to TODO list
[10:33] <seb128> I might have a look this afternoon if I'm done with other things on my list
[10:33] <seb128> I will let you know before starting working on that if I do
[10:33] <pitti> cool, thanks
[10:39] <didrocks> seb128: ok. I do it just after lunch (but will be able to upload @home)
[10:39] <seb128> didrocks: don't bother if it depends on the new gdl I didn't check
[10:39] <seb128> that one is not ready for upload
[10:39] <seb128> didrocks: btw I comment on the gnome-python-extras bug
[10:39] <didrocks> seb128: ok
[10:39] <didrocks> ah, looking at it
[11:04] <chrisccoulson> should any application depend on a particular icon theme?
[11:05] <chrisccoulson> i'm looking at bug 375917
[11:05] <chrisccoulson> shouldn't it ship it's own fallback icons?
[11:06] <james_w> I believe so
[11:06] <asac> yeah
[11:08] <asac> so from what i read in bug, it definitly shouldnt behave that badly if there is no specific icon theme imo
[11:08] <chrisccoulson> i can't confirm it yet because i'm, at work, but if what the reporter says is true then it should ship it's own icons then rather than depending on gnome-icon-theme
[11:33] <didrocks> seb128: I answered on gnome-python-extras bug
[11:36] <seb128> didrocks: python-gnome2-extras-dbg has lot of .so in jaunty though for all the components
[11:36] <seb128> didrocks: your merge only has 1
[11:36] <seb128> no?
[11:37] <didrocks> seb128: I checked for gtkhml2. I thought it was related. Let me check the dbg package.
[11:39] <didrocks> so, gtkspell.so
[11:39] <pitti> seb128: looking into retracer chroots now; I'd like to have them anyway for checking some uninstallability bits
[11:39] <didrocks> is on its own package
[11:39] <seb128> pitti: ok
[11:40] <didrocks> the package is not build with gda, gdl either, gksu is on its own package. I must have a look for trayicon
[11:40] <didrocks> also
[11:40] <seb128> hum?
[11:40] <didrocks> seb128: ok, so. I have to find a way to include them in the dbg package
[11:40] <didrocks> and so, reshaping all in one.
[11:40] <seb128> I don't understand what you are saying
[11:40] <seb128> you didn't split all those dbg did you?
[11:41] <didrocks> no, but as thos libs are now in seperated packages and I didn't create one -dbg one for each, they are just not built
[11:41] <didrocks> (the debug version)
[11:42] <seb128> right
[11:42] <seb128> I would expect having all those dbg in -dbg though
[11:42] <didrocks> I have to make a trick in debian/rules so, gathering everything
[11:42] <didrocks> yes
[11:42] <seb128> ok cool
[11:42] <didrocks> I'm working on that right now :)
[11:43] <didrocks> I think it will be easy, regarding debian/rules
[11:44] <Ampelbein> seb128: good day! have you had a chance to look at gnome-utils? I pushed the final change to https://code.edge.launchpad.net/~amoog/gnome-utils/devel and I think it's ok now. I tested multiple times and it works.
[11:45] <seb128> hi Ampelbein, I will do that after lunch
[11:45] <Ampelbein> ok
[11:53] <pitti> seb128: karmic chroots created (i386/amd64), let's see how they perform
[11:54] <pitti> seb128: I expect that the existing karmic crash reports will just be invalidated
[12:19] <seb128> pitti: you rock, yeah it's ok since are moving fast in karmic anyway
[12:27] <didrocks> seb128: I will do the change tonight as there is no hurry. I'm some kind of under fire today :)
[12:27] <seb128> didrocks: ok, good luck with the fire fighting then
[12:27] <didrocks> thanks
[12:33] <lool> asac: Hey, I'm still running jaunty and I wanted to try out firefox-3.5; it segfaults after copying over my profile
[12:33] <lool> asac: Is this of any interest, or should I simply move on to karmic?
[12:42] <lool> same thing without gnome-support
[12:44] <asac> lool: does it work better with a fresh profile?
[12:44] <asac> like moving whole .mozilla away?
[13:25] <seb128> vuntz: so gnome-panel has 6 seconds of busy time on my laptop config
[13:26] <seb128> vuntz: when it's starting I mean, it's 1 second with empty bars, 3 extra seconds for the menu use and almost not difference for the other standard panel applets
[13:26] <seb128> vuntz: then some small bits for other applets
[13:26] <seb128> so half of the startup time is due to the menu applet apparently
[13:27] <vuntz> seb128: can you try something fun?
[13:27] <seb128> yes
[13:27] <vuntz> seb128: sudo mv /usr/share/applications /usr/share/applications.test
[13:27] <vuntz> seb128: hrm. Actually, no
[13:27] <seb128> let's try
[13:27] <seb128> I'm using kvm for testing ;-)
[13:27] <vuntz> this will break gnome-session, I guess
[13:27] <seb128> why?
[13:28] <vuntz> it will look for gnome-panel.desktop and won't find it
[13:28] <seb128> the session components are in /usr/share/gnome/autostart
[13:28] <seb128> hum right
[13:28] <seb128> I can move everything which is not in the session though to try
[13:29] <vuntz> seb128: well, yeah, you get the idea :-)
[13:30] <seb128> hey chrisccoulson
[13:30] <chrisccoulson> hi seb128
[13:39] <pitti> kenvandine: if the applet never stops spinning, but syncdaemon.log is quiet, did you see that before?
[13:41] <mnemo> pitti: that happens right now on my machine as well (for u1), it spun all night and I less less than 1mb of files
[13:42] <mnemo> s/less/have/
[13:43] <pitti> ah, disconnecting and connecting seems to have help
[13:43] <kenvandine> pitti: yes
[13:43] <pitti> ed
[13:43] <pitti> it might have gotten confused because I just switched networks several times
[13:43] <pitti> this needs network-manager integration
[13:43] <kenvandine> pitti: i don't think that is it..  my desktop box tends to do that
[13:43] <kenvandine> pitti: i think it does
[13:44] <kenvandine> pitti: out of 3400 files... right now 2 aren't in sync :)
[13:44] <kenvandine> so not to bad
[13:47] <kenvandine> pitti: yeah, if the network goes down the applet disconnects
[13:47] <kenvandine> and comes back when the network comes back
[13:47] <pitti> that sounds right then
[13:47] <kenvandine> and it rescans
[13:47] <kenvandine> which is slow now
[13:48] <kenvandine> so now when i bounce the network connection on my desktop, my disk churns for a couple minues
[13:48] <kenvandine> minutes even
[13:48] <kenvandine> :)
[13:50] <pitti> seb128: retracer failure is a syntax error, my bad; uploading fix
[13:50] <seb128> pitti: ok
[13:50] <pitti> seb128: I'll restart them once it's in the archive
[13:51] <pitti> well, I'll apply it inline, faster
[13:51] <seb128> vuntz: so moving the applications directory away change the busy pick from 3 seconds to 0.3 seconds
[13:51] <lool> asac: Sorry removed it in the mean time
[13:51] <lool> asac: I'm dist-upgrading
[13:51] <vuntz> seb128: cool
[13:51] <asac> lool: ok
[13:51] <seb128> vuntz: we need a .desktop cache ;-)
[13:51] <vuntz> seb128: yep
[13:52] <asac> lool: if it still fails in karmic let us know
[13:52] <vuntz> seb128: the question is: "do we want a per-system cache, or per-user cache"
[13:52] <seb128> I think I've already ready this question
[13:52] <seb128> ready -> read
[13:52] <vuntz> seb128: I would prefer per-system
[13:52] <seb128> can we get per directory?
[13:52] <seb128> ie the way the gtk icon cache is working
[13:53] <lool> asac: k
[13:53] <vuntz> seb128: oh, that makes sense
[13:54] <vuntz> my main worry is that such caches are no fun for packages
[13:54] <seb128> we do it for icons already
[13:54] <seb128> so having the same logics for desktops is not going to make a real difference
[14:13] <seb128> pitti: I guess changing poppler soname now if the binaries stay in new is not an issue?
[14:13] <seb128> hey rickspencer3
[14:13] <pitti> seb128: that's fine
[14:13] <rickspencer3> hi seb128
[14:13] <pitti> hey rickspencer3, good morning
[14:13] <seb128> pitti: ok, I'm going to upload 0.11 then
[14:13] <rickspencer3> buen dia
[14:14] <lool> vuntz: The main issue with the icon caches are the fact that the cache covers a deep hierarchy of dirs and files, so the mtime of the toplevel dir is not enough to tell whether the cache is newer or not than the latest installed files
[14:15] <vuntz> lool: yeah, but for desktop files, that's not that much of an issue
[14:15] <lool> vuntz: also in deb packaging we now have a facility to run commands when files are installed in specific dirs; if all the .desktop are installed immediately below one dir, it's easy to handle
[14:15] <lool> vuntz: Exactly my point: it was really a pain with icons, but for .desktop files it's probably ok, as long as you don't change the layout
[14:16] <vuntz> lool: (although you can have subdirs; but you generally don't have 10 subdirs... And then we can look at their mtime too)
[14:16] <lool> One thing which would be nice is having the cache in the dir above the .desktop files; that way you can be sure that your cache is up-to-date
[14:16] <vuntz> assuming that listing the content of a directory that's not in the disk cache isn't too slow, of course
[14:16] <lool> vuntz: It's not good if you can have subdirs, because stating all files below a dir takes time (disk seeks)
[14:17] <vuntz> lool: hrm.
[14:17] <vuntz> /usr/share/desktop.cache? beeeeh :-)
[14:17] <lool> stating a single file + single dir is much faster than stating hundreds of files to check whether they are subdirs
[14:17] <vuntz> let's do it in /var in that case
[14:18] <lool> vuntz: I don't have an issue with /usr/share/desktop.cache but you could easily make that /usr/share/desktop-caches/desktop.cache, /applications.cache etc.
[14:18] <lool> or /var if you like
[14:18] <lool> I don't think /var or /usr makes a big difference, unless your cache is arch specific
[14:19] <lool> (/usr is for package data files; the cache will match what's in /usr and only be updated when you install .desktop files to /usr, so usually during package updates; some people argue that this is a FHS violation, but this is IMO wrong)
[14:19] <vuntz> lool: it's likely to be arch-specific, though
[14:19] <vuntz> isn't the icon cache arch-specific?
[14:19] <lool> vuntz: That's to be avoided IMO; think of $HOME .desktop files
[14:20] <lool> vuntz: I think it's not
[14:20] <lool> It's mmap-able and meant to work over NFS homes IIRC
[14:20] <vuntz> oh, then we can probably do it the same way
[14:21] <pitti> seb128: \o/ bug 373007
[14:21] <lool> vuntz: Concerning hierarchies of .desktop files: the full hierarchy is never used directly, right?  I mean by default only the files directly below /usr/share/applications are used
[14:21] <seb128> pitti: excelllent
[14:22] <vuntz> lool: no
[14:22] <lool> vuntz: If you have to explicitely request the inclusion of e.g. /screensavers, then it's ok: we have a way to check the caches freshness with a single stat()
[14:22] <vuntz> lool: if an app requests gnome-blablabla.desktop and /usr/share/applications/gnome-blablabla.desktop doesn't exist, we can look at /usr/share/applications/gnome/blablabla.desktop (iirc)
[14:22] <lool> ah
[14:23] <vuntz> (fun)
[14:23] <vuntz> I'd need to check the spec again to be 100% sure
[14:23] <lool> vuntz: Then you could perhaps consider one cache file per real dir; before scanning a dir you check whether it has a corresponding cache file, if it does you compare the stats before using the cache, otherwise you scan the dir as currently done
[14:23] <lool> That is, if you want to make sure your cache is really fresh; if you go for a single cache, you can't be sure I think
[16:55] <pitti> seb128: I don't see testing feedback on bug 368508?
[16:56] <seb128> pitti: comment #10
[16:56] <seb128> "FIX CONFIRMED here - Clicking onto calendar button no longer crashes evolution."
[16:56] <pitti> oh, I see; thanks
[16:56] <seb128> comment #13
[16:56] <seb128> "If I have the expected version, I can confirm that the 'crash' of calendar updates no longer occurs "
[16:57] <seb128> pitti: you're welcome, sorry for the bug log being confusing
[17:05] <kenvandine> rickspencer3: ping
[17:05] <rickspencer3> kenvandine: 'sup kenvandine
[17:05] <rickspencer3> ?
[17:05] <kenvandine> rickspencer3: still having the evo/indicator problem?
[17:05] <kenvandine> quit evo, and run this
[17:05] <kenvandine> /usr/lib64/indicator-applet/listen-and-print
[17:05] <kenvandine> then start evo
[17:05] <kenvandine> and send me the output of listen-and-print
[17:06] <seb128> did you try in a guest session?
[17:06] <rickspencer3> kenvandine: yes, but haven't had time to look into it
[17:06] <kenvandine> rickspencer3: yeah... and that too
[17:06] <kenvandine> rickspencer3: when you can, please do that
[17:06] <rickspencer3> seb128: yes, it sort of worked
[17:06] <rickspencer3> on call now, will ping back soon
[17:06] <kenvandine> ok
[17:07] <seb128> "sort of worked" ;-)
[17:07]  * kenvandine thinks it is pretty binary :)
[17:07] <kenvandine> there or not...
[17:07] <kenvandine> humm
[17:07]  * kenvandine heads to lunch
[17:08] <rickspencer3> seb128: yeah, indicator-applet crashed on load
[17:08] <rickspencer3> but worked when it reloaded
[17:08] <seb128> the crash might be interesting to ted
[17:08] <seb128> but that means it's correctly installed and capable to work
[17:08] <rickspencer3> seb128: right, need to make time to follow up
[17:08] <seb128> which is already an indication
[17:11] <pitti> bryce: wow, people say good things about -intel 2.7.1
[17:44] <bryce> pitti: sweet
[17:45] <bryce> pitti: btw I've been getting questions about if 2.7.1 could be backported to jaunty
[17:45] <bryce> pitti: I've been telling them "Against SRU team policy"
[17:46] <bryce> pitti: but let me know if I should be thinking otherwise
[17:46] <artir> does it use UXA or EXA
[17:46] <artir> ?
[17:47] <bryce> it should support either
[17:47] <pitti> bryce: nothing wrong with jaunty-backports
[17:47] <bryce> 2.8 is where they're dropping exa
[17:47] <bryce> pitti: not sure
[17:47] <pitti> bryce: wrt. -updates, that sounds inappropriate, even more so at this time when it hasn't been tested widely yet
[17:48] <artir> ok, thanks
[17:50] <bryce> pitti: ok thanks for confirming
[17:56] <darren8808> what is the command to leave a channel?
[17:57] <pitti> darren8808: /quit
[17:58] <chrisccoulson> pitti - would you object to uploading a snapshot of tracker from git master in to karmic? (there will be a proper 0.7.0 release later this cycle)
[17:58] <darren8808> thanks
[18:00] <pitti> chrisccoulson: no, that's fine
[18:01] <chrisccoulson> cool. the only reason i ask is because libtrackerclient is not API stable yet, but there is only 1 package in the archive using that at the moment (totem-plugins), and it may be possible to disable that plugin for now
[18:02] <chrisccoulson> it will need porting to the new API at some point
[18:48] <pitti> I'm off for today, see you tomorrow!
[19:08] <chrisccoulson> does devicekit have an upstream bug tracker?
[19:09] <cj> what's the notification tool called and how do I configure where it pops up the notifications?
[19:13] <mclasen> chriscoulson: http://bugs.freedesktop.org/
[19:33] <chrisccoulson> mclasen - thanks:)
[20:58]  * chrisccoulson wonders if his floppy drive is polled for long enough whether it will die a slow, painful and much needed death
[21:32] <seb128> chrisccoulson: hey
[21:32] <chrisccoulson> hi seb128
[21:32] <seb128> chrisccoulson: is there any reason why we need that vala divergence over debian?
[21:32] <seb128> that seems not a good idea to me
[21:32] <seb128> we have no ubuntu maintainer for it and being in sync is handy
[21:33] <chrisccoulson> seb128 - bug 374151
[21:33] <chrisccoulson> the changes have been sent to debian too
[21:33] <chrisccoulson> i spoke to the debian maintainer and he's committed one of the changes already
[21:39] <seb128> chrisccoulson: I've notice the build-depends bug being fixed, will then change the | true too?
[21:39] <chrisccoulson> seb128 - i spoke to elmarco who committed the build-dep fix, and he suggested to ping slomo about that
[21:39] <chrisccoulson> i don't know where he hangs out though ;)
[21:40] <chrisccoulson> i suppose i could just open another bug report in debian
[21:43] <seb128> slomo joins this chan regularly
[21:44] <ror> slomo?
[21:45] <seb128> ror: is that a question?
[21:46] <ror> sorry it was thinking out loud, wasn't really supposed to type that
[21:46] <ror> I once knew a coder who went by the name of slomo many years ago, but I suppose it's a fairly common name really
[21:47] <chrisccoulson> thanks seb128 - i'll ask him about it when he's about
[21:47] <seb128> chrisccoulson: thanks
[22:42]  * chrisccoulson is annoyed that some people prefer to write insults and criticisms on bug reports rather than actually be helpful
[23:03] <mnemo> chrisccoulson: yea, especially when they _choose_ themselves to install this _free_ thing that _rocks_
[23:04] <ror> just cos something's free it doesn't give it an excuse to be shit! (I think ubuntu has shown this enough)
[23:11] <Ampelbein> seb128: hey, i've got some free time to spare, is there anything urgent you want me to do?
[23:13] <seb128> Ampelbein: do you want to have a go at merging abiword?
[23:13] <Ampelbein> seb128: i can have a look at it, yeah.
[23:13] <seb128> thanks