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