[07:56] <pitti> Good morning
[07:58] <didrocks> morning pitti o/
[08:13] <pitti> hey didrocks
[08:28] <didrocks> hello seb128, did you have a nice week-end?
[08:29] <seb128> hey didrocks
[08:29] <seb128> yes, too short as usual but good, you?
[08:29] <didrocks> seb128: yes, very restful :)
[08:36] <pitti> hey seb128
[08:44] <seb128> hello pitti
[08:44] <seb128> lut huats
[08:45] <huats> hello seb128 and pitti
[08:45] <seb128> huats: how are you this week?
[08:45]  * pitti hugs seb128 and huats
[08:45] <huats> seb128: I am feeling better !
[08:45] <huats> thanks !
[08:45]  * seb128 hugs pitti
[08:45] <huats> how are you ?
[08:46]  * huats hugs pitti and seb128 too !
[08:46] <seb128> huats: good thank you
[08:46]  * huats even hugs the mighty didrocks
[08:50] <seb128> pitti: the indicate-applet needs an handle, how would you remove it from the configuration or move it otherwise?
[08:50] <pitti> seb128: if you see it, you can move it; if you don't see it, what does its position matter?
[08:50] <pitti> update-notifier is exactly the same
[08:50] <seb128> pitti: how can you move it when you see it without using the handle?
[08:50] <pitti> seb128: do you really like that handle? I find it awful
[08:51] <seb128> pitti: no, update-notifier is a notification area icon, not an applet
[08:51] <pitti> seb128: well, just like any other thing there? middle-click and drag, or right click -> move
[08:51] <seb128> pitti: I don't like the handle, I ask how you move or remove the applet without using it
[08:51] <pitti> seb128: that's a technical detail that an user doesn't need to understand
[08:51] <seb128> pitti: they choiced by design to open the same menu on any click
[08:51] <pitti> it's all just little pictures in my panel
[08:51]  * pitti thinks in user terms right now
[08:51] <seb128> pitti: try to middle or right click on it
[08:52] <pitti> seb128: I know that it doesn't have a menu
[08:52] <pitti> but it should
[08:52] <pitti> every other applet has one
[08:52] <seb128> they think every other applet is wrong
[08:52] <seb128> and that's one of the things they want to fix
[08:52] <pitti> well, it might very well be
[08:52] <pitti> but jaunty isn't the time to fix them all
[08:52] <seb128> good luck, I tried to fight this battle at distro sprint ;-)
[08:53] <pitti> for the jaunty version we should aim for consistency
[08:53] <seb128> +1
[08:53] <pitti> right now it's just plain ugly and inconsistent
[08:53] <seb128> as said I tried to convince them during the sprint but maybe they will listen to extra opinions
[08:53] <pitti> seb128: asked the other way round, how do I remove it right now?
[08:53] <pitti> I just have the handle, but it doesn't have a menu either
[08:54] <seb128> it has move and delete items there
[08:54] <seb128> when right clicking on it
[08:54] <seb128> that's similar to the task list
[08:54] <seb128> or the notification area applet
[08:54] <pitti> right-click doesn't do anything for me
[08:54] <seb128> they are both empty when there is no entry and have an handle
[08:54] <seb128> weird
[08:54] <pitti> ah, after then 10th click or so I hit it
[08:55] <pitti> bah
[08:55] <pitti> seb128: I filed bug 339818 for the record
[08:55] <seb128> pitti: my comment was in reaction to the bug ;-)
[08:55]  * didrocks hugs huats back ;)
[08:55] <seb128> I'm just reading my weekend bug emails
[08:55] <seb128> didrocks: you can do the pidgin update if you want
[08:55] <pitti> oh, right
[08:56] <didrocks> seb128: ok, I am on it :)
[08:58] <pitti> seb128: would you pind pinging me on jabber?
[09:24] <mvo> seb128: btw, gksu/libgksu are in my ppa, I guess its enough part of gnome to be part of the freeze exception for it?
[09:25] <seb128> mvo: I'm not sure, it doesn't follow upstream freezes, etc, better to ask pitti or slangasek for an exception
[09:25] <seb128> mvo: hello btw, nice to see you back, do you feel better?
[09:28] <mvo> seb128: hello :) better, but not well :( I felt pretty good saturday and was happy that its over and sunday was bad again. today is ok, I'm a bit slow on everything (and feel weak), but otherwise ok
[09:29]  * seb128 hugs mvo
[09:29]  * mvo hugs seb128
[09:39] <didrocks> hey mvo :)
[09:39] <mvo> hey didrocks
[09:39] <didrocks> mvo: the section "quilt + bzr + autotools = <3" in https://wiki.ubuntu.com/DesktopTeam/Bzr is dedicated to you :)
[09:44] <mvo> didrocks: that is a clever way of doing it
[09:48] <didrocks> mvo: just long to proceed when you have to do it (gnome-games, I hate you ^^) :)
[09:48] <didrocks> but with the checklist, you can avoid to forget something (like quilt add :/) in the pbuilder chroot and have to begin again (yes, I did it :p)
[09:57] <seb128> pitti: do I need any exception if I want to sync gtkmm-documentation which is a new package in debian?
[09:58] <pitti> seb128: in theory that's an FFE, but that was meant to ease work for archive admins
[09:58] <pitti> seb128: so go ahead
[09:58] <seb128> pitti: and I've delegated to grant desktopish universe exceptions ;-)
[09:58] <pitti> seb128: and if you feel better, hereby I grant it :)
[09:58] <seb128> pitti: thanks
[09:58] <pitti> ah, indeed :)
[10:12] <seb128> vuntz: hey, can join #nautilus when you have a minute?
[10:59] <pitti> seb128: hm, didn't we use to have fuse file systems from gvfs mounts, such as ssh?
[10:59] <seb128> pitti: ls .gvfs?
[10:59] <pitti> empty
[11:00] <seb128> ps ax | grep fuse
[11:00] <pitti> mount | grep fuse -> nothing for gvfs
[11:00] <pitti> seb128: ps> nothing
[11:00] <seb128> $ ps ax | grep fuse
[11:00] <seb128> 16677 ?        Ssl    0:00 /usr/lib/gvfs//gvfs-fuse-daemon /home/seb128/.gvfs
[11:00] <pitti> hmm
[11:00] <seb128> is your user in the fuse group? do you have fuse-utils installed?
[11:00] <pitti> hah
[11:00] <pitti> $ /usr/lib/gvfs//gvfs-fuse-daemon /home/martin/.gvfs/
[11:00] <pitti> fusermount: failed to open /etc/fuse.conf: Permission denied
[11:00] <pitti> fusermount: user has no write access to mountpoint /home/martin/.gvfs
[11:01] <pitti> seb128: seems I'm not
[11:01] <seb128> there you go
[11:01] <pitti> but I thought we obsoleted the fuse group in intrepid..
[11:01] <pitti> -rw-r----- 1 root fuse 216 2009-01-14 14:35 /etc/fuse.conf
[11:01] <pitti> BWAH!
[11:01] <pitti> that wasn't so in intrepid
[11:01] <seb128> you did IIRC yes
[11:01] <pitti> getfacl /dev/fuse looks good
[11:02] <pitti> and /bin/fusermount is 4755, as it should be
[11:02] <pitti> seb128: okay, I'll look into that
[11:02] <seb128> thanks
[11:02] <seb128> pitti: would it be easy to make apport ignore the totem-video-thumbnailer crashes?
[11:03] <pitti> seb128: yes, but they shouldn't really crash..
[11:03] <seb128> pitti: well, we get quite some crashers about totem trying to thumbnails video being downloaded
[11:04] <pitti> oh, I understand
[11:04] <pitti> so, incomplete files
[11:04] <seb128> crashes in ffmpeg libs and siretart said those are basically pointless because without a video example to get the crash they can't really be worked
[11:04] <seb128> right
[11:04] <pitti> . o O { can we please stop thumbnailing videos at all? it's a horrible cpu/IO/battery sink }
[11:04] <pitti> *cough*
[11:05] <seb128> there is a gconf key you can change if you want to do that ;-)
[11:05] <seb128> I like having thumbnails and they are done once only
[11:05] <seb128> so that's okish
[11:05] <pitti> seb128: the cleanest method is to install a signal handler in the thumbnailer, to catch segv and exit(1)
[11:05] <pitti> the next method is to install a generic apport hook to ignore the crashes
[11:06] <pitti> but I don't recommend that here
[11:06] <pitti> since that will bring the overhead of generating .crash files for no good
[11:06] <seb128> ok
[11:06] <pitti> and it'd present the 'cannot report problem' dialog to an user
[11:06] <seb128> thanks
[11:06] <pitti> so I think catchign the signal is the only sane option here
[11:06] <seb128> right
[11:07] <seb128> it's not so much an issue on stable versions
[11:07] <pitti> right
[11:07] <seb128> that's just to not flood ffmpeg-debian guys ;-)
[11:15] <seb128> mpt: any reason you open notify-osd on the ubuntu package rather than on the upstream component?
[11:15] <seb128> +bugs
[11:17]  * seb128 opens upstream tasks for those bugs now
[11:20] <mpt> seb128, MacSlow is concentrating on the package list, for much the same reason as the Ubiquity and Update Manager devs do
[11:21] <mpt> (or that's what he just told me)
[11:21] <seb128> mpt: ok, my experience until now has been that I've to ping him for a week to have him having a look over the list but if you says he looks at bugs regularly there now
[11:21] <seb128> all good
[11:22] <mpt> seb128, he also says that if other distributions adopt Notify OSD, it will become more important to distinguish between project-general bugs and Ubuntu-packaging-specific bugs
[11:23] <seb128> ok, no problem, if the dx guys look at those bugs that's all good
[11:24] <mpt> seb128, the ubuntu-docs team have similarly just been discussing migrating from bugtracking on the ubuntu-docs project to the Ubuntu ubuntu-doc package
[11:25] <seb128> mpt: as said if they read those bugs that's fine, they were not subscribed to the package until recentlu
[11:25] <seb128> recently
[11:28] <mpt> seb128, this is another example of bug 76416, so maybe nag the Launchpad developers about it :-)
[11:28] <seb128> right :-)
[11:36] <seb128> pedro_: hi, the i386 retracer was stucked for some days I just restarted it so let it some time to catch up before cleaning recent crashers
[11:37] <pedro_> seb128: ok! thanks for letting me know about it
[11:37] <seb128> you're welcome
[11:41] <seb128> pedro_: btw there is no need to set milestone for bugs fixed to GNOME svn since GNOME 2.26 is due before jaunty beta
[11:42] <pedro_> seb128: alright, just don't want to forget about that f-spot issue (cannot find the svn commit)
[11:43] <pedro_> btw it seems the gvfs auto mount is causing issues again
[11:43] <seb128> pedro_: I was commenting about a nautilus bug you just changed
[11:43] <pedro_> bug 338466
[11:43] <pedro_> seb128: ah that one, alright no problem
[11:43] <seb128> pedro_: hum
[11:44] <seb128> pedro_: https://edge.launchpad.net/ubuntu/+source/f-spot/0.5.0.2-0ubuntu3
[11:44] <pedro_> seb128: it's the same behavior of the bug you fixed las cycle
[11:44] <seb128> pedro_: that's a f-spot issue and not a gvfs one
[11:44] <seb128> "f-spot (0.5.0.2-0ubuntu3) intrepid; urgency=low
[11:44] <seb128>   * Add f-spot-import-gphoto.dpatch: Fix f-spot-import to understand GIO
[11:44] <seb128>     gphoto:// URLs, which fixes (i. e. gets rid of) the device dialog on
[11:44] <seb128>     import. Also speculatively gvfs-umount the camera, otherwise F-Spot cannot
[11:44] <seb128>     communicate with it.
[11:44] <seb128> "
[11:44]  * pedro_ looking
[11:44] <seb128> was the upload to fix the locking issue
[11:45] <pedro_> seb128: i'll try that right away and comment on the report then, thanks!
[11:45] <seb128> the patch is still there
[11:45] <seb128> do you use f-spot-import or an another command?
[11:48] <pedro_> seb128: yep, i use the f-spot-import command
[11:50] <pedro_> workaround on bug 196757 makes the import to work again
[11:53] <seb128> pedro_: could be a side effect of bug #570888
[11:54] <seb128> gnome bug #570888
[11:55]  * pedro_ tests
[12:00] <pedro_> seb128: seems so, I'm getting two camera devices, I'll follow up with the reporter for confirmation on that
[12:03] <davmor2> pitti: I ran ps aux straight after the log up it's on bug 338340 let me know if it is of any use or not :)
[12:03] <seb128> pedro_: the upstream bug is confirmed, right the current version has only 2 icons displayed
[12:33] <davmor2> pitti: was the info I added to the bug of any use as I need the system for further testing?
[12:49] <davmor2> guys the new restart dialogue looks strange in grey with the rest of the notifications being black is there any plan to change this?
[12:49] <seb128_> why should those dialogs be different of any dialog?
[12:50] <seb128_> they are not notifications but standard dialogs
[12:52] <davmor2> seb128_: It just looks strange.  It's grey and slightly transparent and looks wrong with the rest of the messages seemingly black and slightly transparent if that makes sense?
[13:00] <seb128> re
[13:00] <seb128> is anybody running intrepid there?
[13:01] <seb128> mvo: ?
[13:02] <mvo> seb128: I have a intrepid box
[13:02] <seb128> mvo: box or vmbox is fine, can you boot it for me? ;-)
[13:04] <mvo> seb128: sure. what then?
[13:04] <seb128> mvo: python-dbg -c 'import gnomecanvas'
[13:05] <mvo> ImportError: /usr/lib/python2.5/site-packages/apt_pkg.so: undefined symbol: Py_InitModule4
[13:05] <seb128> grrr
[13:05] <seb128> why do we keep having those changes, it's broken, obviously nobody use that since nobody ever noticed and it's extra work
[13:06] <seb128> I was looking at why it's broken in jaunty and it didn't change much since intrepid
[13:06] <seb128> that was broken in intrepid already...
[13:06] <mvo> seb128: I have a different system and there it seems to be ok
[13:06] <mvo> hmmm
[13:06] <seb128> system = intrepid or hardy?
[13:06] <mvo> both intrepid
[13:07] <seb128> weird
[13:11] <seb128> mvo: hum ok, seems to work now, I was lacking some depends apparently
[13:11] <seb128> mvo: thanks anyway ;-)
[13:24] <crevette> hey
[13:25] <seb128> lut crevette
[13:26] <crevette> salut seb128
[13:35] <crevette> pitti, for bug 284994, vuntz has some patch to fix this problem, I think he pushed in opensuse
[13:35] <seb128> crevette: can you attach the patch to the bug?
[13:36] <crevette> pitti, or we can investigate in gnome-bluetooth 2.27.x?
[13:37] <crevette> seb128, it is in upstream bug
[13:37] <seb128> crevette: he's away for lunch and it's too late to switch to a complete new technology for jaunty now
[13:37] <crevette> seb128, the code base it almost the same than bluez-gnome
[13:38] <seb128> crevette: it's versionned 2.27 for a reason and bastien said he could still be quite buggy and it didn't get testing it
[13:38] <crevette> actually I updated the packaging of gnome-bluetooth for myself to replace bluez-gnome
[13:38] <seb128> it -> yet
[13:38] <seb128> you can do the update in universe as a first step but it needs testing
[13:39] <crevette> the only thing I need to see is how to do for people using gnome-bluetooth =<0.11
[14:10] <pitti> crevette: yes, upstream accepted the initial patch, and then did a better one
[14:10] <pitti> crevette: but I'd like to backport it, since I heard lots of complaints about the current bug
[14:14] <pitti> davmor2: thanks; replied in the bug
[14:16] <rickspencer3> tkamppeter: welcome back
[14:19] <pitti> hey rickspencer3
[14:27] <davmor2> pitti: the latter log shows the initial problem the first log was the one with the restarted backend with debugging enabled.  Initial problem was that it displays 0% downloading and then just stops and goes back to the original jockey window.  Hopefully fully explained in report
[14:30] <tkamppeter> hi rickspencer3, I have solved most issues now which were coming up during my vacation ...
[14:30] <pitti> tkamppeter: isn't it nice to come back and stare at an exploding mail box? :-/
[14:30] <pitti> tkamppeter: enjoyed Brazil?
[14:31] <tkamppeter> It is not so exploding, as IO read mail from time to time from Brazil, but I did not do bigger stuff, mainly organizational stuff on the OpenPrinting Summit, to get sponsors for community people.
[14:38] <tkamppeter> Now I have caught up somewhat, fixed all but one bug for foomatic-filters 4.0.1, discussed s-c-p changes, uploaded collected upstream patches, solved HPLIP FFE, ...
[14:42] <pitti> tkamppeter: great work
[14:45] <rickspencer3> pitti: should bug #336420 be assigned to seb128 ?
[14:46] <seb128> no please
[14:46] <seb128> I've no clue about compiz and lot to do already
[14:46] <pitti> rickspencer3: I think I assigned it to me, didn't know a better assignee; if kenvandine_wk has time for it, I'd be grateful, otherwise I'll squeeze it in
[14:48] <rickspencer3> it's assigned to canonical-desktop-team, I'll assign to kenvandine_wk, who can always reassign to seb128 if needed ;) (j/k seb128)
[14:49] <seb128> ;-)
[14:51] <kenvandine_wk> pitti: assign that to me
[14:51] <kenvandine_wk> sorry... my box froze when i started a build in pbuilder
[14:51] <pitti> rickspencer3: ah, thanks
[14:51] <kenvandine_wk> second time that has happened, need to figure out what is up with that
[14:51] <pitti> kenvandine_wk: dmesg?
[14:51] <kenvandine_wk> will look
[14:52] <seb128> usually my laptop freezes after doing use switching in jaunty
[14:52] <pitti> kenvandine_wk: or perhaps something weird like having udev running in the pbuilder or so?
[14:53] <kenvandine_wk> pitti: what are all these --MARK-- lines in my messages log?
[14:54] <geser> kenvandine_wk: that your syslog didn't die
[14:54] <pitti> kenvandine_wk: they appear every 20 minutes
[14:54] <kenvandine_wk> ah... never seen that before :)
[14:55] <geser> they only appear it there was no activity in syslog for a certain period of time
[14:56] <pitti> seb128: I'll upload ekiga, gnome-utils, and gnome-vfs in the next minutes, FYI
[14:56] <pitti> (strip gconf translations)
[14:56] <seb128> pitti: ok thanks, you did check gnome-utils, a rebuild will not likely be enough there
[14:56] <pitti> should buy us perhaps 800 KB on the desktop CD
[14:56] <pitti> seb128: no, these aren't rebuilds
[14:57] <seb128> ok good then
[14:57] <pitti> seb128: ekiga doesn't use cdbs (I copied the rules)
[14:57] <seb128> because I uploaded gnome-utils recently
[14:57] <pitti> seb128: gnome-utils didn't use gnome.mk before; testing with that now
[14:57] <pitti> and gnome-vfs is just old
[14:57] <seb128> that was just to let you know in case you wanted to just do no change uploads
[14:57] <seb128> ok good
[14:57] <pitti> no, they wouldn't work
[14:57]  * pitti hugs seb128, thanks
[14:57]  * seb128 hugs pitti
[14:57] <seb128> mvo: any idea about that one?
[14:57] <seb128> $ apt-cache rdepends python-glade2-dbg<python-glade2-dbg>
[14:58] <seb128> "apt-cache rdepends python-glade2-dbg" returns nothing
[14:58] <seb128> where deskbar-applet-dbg depends on it
[14:58] <seb128> that's current jaunty
[14:59] <geser> seb128: does rdepends work on non-existing packages?
[15:00] <seb128> geser: that's part of the question ;-)
[15:02] <mvo> seb128: I think its because there is no python-glade2-dbg, so apt has a stub of it in the database because its refered via a dep
[15:02] <mvo> but nothing more
[15:02] <mvo> (but to be 100% sure I would have to look into the source)
[15:03] <seb128> mvo: ok, do you have a workaround to list those which still depends on this one and should be transitioned?
[15:04] <geser> seb128: filter the output of apt-cache unmet (perhaps also add -i)
[15:04] <seb128> geser: thanks
[15:04] <seb128> $ apt-cache unmet | wc -l
[15:04] <seb128> 2226
[15:04] <seb128> urg
[15:06] <mvo> seb128: give me a sec
[15:06] <seb128> mvo: that's ok, unmet will do, thanks
[15:07] <pitti> seb128: gnome-utils b-deps on cdbs, but doesn't actually use it in debian/rules; would you mind if I change debian/rules to do so?
[15:07] <seb128> pitti: no
[15:07] <pitti> okay, doing
[15:07] <seb128> pitti: please put it in bzr too if you have a minute while doing the changes ;-)
[15:08] <pitti> oh, ok
[15:09] <pitti> seb128: how come that you ask for bzrifying things? :-)
[15:09] <mvo> bzr!
[15:09]  * mvo hugs seb128
[15:10] <seb128> pitti: because if you look to https://code.edge.launchpad.net/~ubuntu-desktop you will see we use bzr in most modules now so there is little point stopping the changes, better to switch everything and have a consistant workflow
[15:10] <seb128> and I'm getting used to it now anyway so that's ok ;-)
[15:10] <pitti> heh
[15:10]  * seb128 hugs mvo
[15:10] <pitti> over the weekend I learned bzr-builddeb
[15:10] <pitti> and bugged james_w with two bugs, which he promptly fixed
[15:10]  * pitti hugs james_w
[15:10] <seb128> I like the "bzr get && bzr-buildpackage" for sponsoring
[15:10] <seb128> it does orig download and everything
[15:11] <pitti> right, and bd even checks out the branch for you
[15:11] <geser> seb128: apt-cache unmet lists also suggests and recommends, if you want only depends use apt-cache unmet -i (it's much less output)
[15:11] <seb128> patch editing is one command away with bzr bd-do so that's ok too
[15:11] <seb128> geser: ah right
[15:11] <pitti> seb128: I like it to tell kwwii to just do "bzr bd lp:usplash" to fetch and build the latest usplash stuff :)
[15:12]  * pitti pushes lp:~ubuntu-desktop/gnome-utils/ubuntu
[15:14] <pitti> didrocks: btw, I made some corrections to https://wiki.ubuntu.com/DesktopTeam/Bzr
[15:16] <seb128> pitti: why did you change bzr commit to debcommit?
[15:16] <pitti> seb128: I find it much better to have debian/changelog and bzr changelog to be consistent; you don't?
[15:17] <pitti> also, it spares you to create a sensible bzr message; you should rather write good debian/changelog
[15:17] <seb128> pitti: bzr commit uses the debian changelog for me on jaunty
[15:17] <pitti> right, that's what it does?
[15:17] <seb128> well, since the recent version yes
[15:17] <seb128> I'm just wondering what else debcommit does ;-)
[15:17] <pitti> (for ages, really)
[15:18] <pitti> it just parses the changes in debian/changelog and mangles it to look good in a bzr changelog (indentation, etc.)
[15:20] <seb128> ok
[15:20] <seb128> yeah for good workflows now ;-)
[15:20] <seb128> the only annoying thing is how to handle packages which are sometimes in sync with debian
[15:20] <seb128> and then not because we package unstable versions first
[15:22] <crevette> debcommit is wonderful
[15:23] <asac> debcommit is handy indeed
[15:23] <asac> i even use that for upstream ChangeLogs sometimes ;)
[15:23] <pitti> seb128: I usually import the debian svn into a bzr branch
[15:23] <asac> but i guess bzr has a similar feature build in for such cases
[15:23] <pitti> seb128: and merge from that (instead using MoM)
[15:24] <pitti> seb128: if we sync, we could just do the same with bzr (bzr pull --overwrite ../debian)
[15:24] <pitti> seb128: that would kill our Vcs-Bzr:, though
[15:24] <pitti> seb128: but all in all, if we are mostly in sync for some packages, we shouldn't maybe put them into bzr
[15:25] <seb128> pitti: right, that's what I've told didrocks to do right now
[15:25] <seb128> ie not put those in bzr
[15:26] <asac> mvo: i am wainting for retracers to process that bug
[15:26] <asac> not sure if it will happen though.
[15:27] <asac> it has the need-i386-retrace tag
[15:29] <asac> whast the status of retracers. are they broken?
[15:29] <asac> (i remember that seb said something about backlog)
[15:33] <mvo> asac: I don't know, seb128 is the retracer working curretnly?
[15:41] <didrocks> seb128: you are speaking about libgtkmm for instance, right?
[15:41] <didrocks> pitti: ok, let me have a look
[15:42] <seb128> asac, mvo: the retracer was stucked for 6 days I restarted it around lunch
[15:42] <seb128> didrocks: yes
[15:45] <seb128> asac: what bug is that about?
[15:45] <didrocks> pitti: just a question of debcommit. I make a change A, so, my debian/changelog will be: http://paste.ubuntu.com/128809/ and I debcommit. Then, I make a change B an my changelog is: http://paste.ubuntu.com/128811/. debommit will "bzr commit -m *A\n*B"
[15:46] <didrocks> pitti: commiting manually would enables us to just write "* B"
[15:47] <mvo> thanks seb128
[15:47] <pitti> didrocks: no, debcommit usually figures that out
[15:47] <pitti> didrocks: that only happens if you change the A changelog
[15:47] <pitti> don't do that
[15:47] <didrocks> pitti: ok. I have to take a test :)
[15:47] <pitti> if you fix a previous changelog, bzr commit manually
[15:47] <pitti> and commit the other change separately
[15:48] <didrocks> great, never experienced that. thought that debcommit was not so clever :)
[15:48] <pitti> didrocks: in technical terms, debcommit looks at all the added lines (bzr diff | grep ^+
[15:48] <seb128> didrocks: when you are done with the pidgin update can you look at updating evolution-mapi in universe?
[15:49] <didrocks> pitti: thanks for the infos. I will do that in my next update :)
[15:49] <didrocks> seb128: there is an update to make? no problem :)
[15:49] <seb128> didrocks: yes 2.25.91 to 2.25.92
[15:49] <didrocks> ok
[15:49] <didrocks> seb128: for piding, I merge from debian, right?
[15:49] <seb128> didrocks: yes
[15:50] <seb128> didrocks: or just update, as you want
[15:50] <seb128> didrocks: they just added an update since you merged so it might be easier to just add their debian dir diff to that
[15:50] <didrocks> seb128: i have to figure out an easy workflow to merge with bzr :)
[15:50] <didrocks> seb128: i was thinking about that, seems easy :)
[15:51]  * pitti radiates hate at gnome-utils' broken debian/rules
[15:51] <pitti> using both dh_movefiles and dh_instal
[15:52] <didrocks> pitti: strange, seems that it hasn't been fully migrated :/
[15:53] <pitti> didrocks: I'm on it..
[16:02] <pitti> seb128: next bug failed; I'll have a look, this isn't normal
[16:02] <seb128> pitti: ok thanks, a firefox bug again?
[16:02] <pitti>     assert os.path.exists(self.get('InterpreterPath', self['ExecutablePath']))
[16:02] <pitti> ah
[16:02] <pitti> seb128: yes, with ffox that's very common
[16:02] <pitti> bug reports filed against 3.0.6
[16:02] <pitti> but now we have 3.0.7
[16:03] <pitti> so the /usr/lib/firefox/3.0.6/ thing doesn't exist any more
[16:03] <pitti> that's it
[16:03] <seb128> right
[16:03] <pitti> I'll untag
[16:04]  * kenvandine_wk -> lunch
[16:21]  * pitti pats his new gnome-utils debian/rules; yay sanity
[16:21] <seb128> pitti: retracer crasher again, can we make it ignore those errors?
[16:22] <pitti> seb128: we can, but that'll take a bit of work
[16:22] <seb128> pitti: ok, let's untag then
[16:22]  * seb128 untags this one
[16:22] <pitti> seb128: how do you untag?
[16:23] <pitti> seb128: I usually log into launchpad as apport and do it there
[16:23] <pitti> or do you have a clever script for it?
[16:23] <seb128> pitti: ssh ronne; log into a retracer environment, use the mass tagging script there
[16:23] <pitti> seb128: I keep the next cron mail as a reminder to fix it
[16:23] <pitti> ah
[16:23] <seb128> subscribing rather
[16:25] <seb128> pitti: would be nice to give some team the right to browse those bugs by default though
[16:25] <seb128> ubuntu-archive or something
[16:25] <seb128> so we have some people who could clean such issues
[16:25] <pitti> right
[16:25] <pitti> would make sense, given that the retracers run as ubuntu-archive
[16:27] <asac> ~/msg -freenode rickspencer3 so unless we get overwhelming feedback we do that properly as a karmic spec
[16:28] <seb128> asac: ECHANNEL? ;-)
[16:28] <asac> seb128: ETYPO ;)
[16:28] <asac> +
[16:28] <asac> ~
[16:28] <pitti> /msg asac I sent you the s3kr1t world domination plan
[16:28] <asac> lol
[16:29] <asac> i really should review how i do /msgs in irssi
[16:29] <asac> ;)
[16:29] <pitti> well, with "/msg"?
[16:29] <asac> pitti: thats what i am currently doing. but thats error prone on long conversations
[16:29] <asac> pitti: e.g. i dont open a new window for each conversation
[16:29] <asac> so i have to type /msg all the time ;)
[16:30] <pitti> seb128: I won't bother bzrifying gnome-vfs; it should just die..
[16:30] <seb128> pitti: right don't bother, it's going to be around for a while but maybe quickly in universe or something
[16:30] <pitti> seb128: at least that one looks like a no-change upload :-)
[16:42] <pitti> nice; libgnomevfs2-common shrinks from 233848 to 36786 bytes
[16:56] <calc> seb128: is the issue where you enter a url in nautilus and it pops up a error box "Could not display "URL". Unable to mount location." a known issue?
[16:57] <calc> eg nautilus window ctrl-l sftp://127.0.0.1/
[16:57] <seb128> what url?
[16:57] <seb128> works for me
[16:57] <calc> hmm ok
[16:57] <calc> maybe my system is somehow messed up
[16:57]  * calc checks his other jaunty system
[16:58] <calc> hmm it says it on both machines
[16:58] <calc> my desktop doesn't have the patched gvfs (from alexl) so is stock
[16:59] <seb128> do you get the issue on ftp.gnome.org too for example?
[16:59] <calc> all i did to reproduce it was ctrl-l in a nautilus window type "sftp://127.0.0.1" and tell it to forget password
[16:59] <calc> it actually mounts the sftp but doesn't display it for some reason
[16:59] <calc> if i then click on the mount on the desktop it shows up
[16:59] <crevette> does ssh 127.0.0.1 works ? (/me asks dumb question)
[17:00] <calc> works for ftp anonymous to ftp.gnome.org
[17:00] <calc> crevette: yes and clicking on the mount it just created but refused to display works as well
[17:01] <calc> crevette: meaning when i create the mount by typing ctrl-l "sftp://127.0.0.1" it doesn't show it and complains but does actually mount it and it shows up on the desktop, when i then immediately click on that icon on the desktop it shows the contents in nautilus
[17:01] <calc> it just fails to open it immediately like it should when you first type in the url
[17:01] <crevette> I would get a gvfsd log
[17:02] <crevette> pkill gvfs* && /usr/lib/gvfs/gvfd -r
[17:02] <calc> ok will do
[17:02] <crevette> and I'd perform the same action to see what appear in the log file
[17:02] <calc> ok
[17:03] <calc> does it just log to console or some other location?
[17:03] <calc> there wasn't much output to console
[17:03] <seb128> well, if the mount success no reason to display too much informations
[17:04] <calc> ok it did show some failure info i'll pastebin it
[17:04] <seb128> it displays the login password dialog for me
[17:04] <calc> http://paste.ubuntu.com/128856/
[17:05] <calc> not sure what that output means, but it did actually mount the sftp on my system, it just didn't show up immediately like it should in the current nautilus window but gave an error message instead
[17:06] <seb128> it gives the same error when trying to connect to localhost too there
[17:07] <calc> so you see the error message as well?
[17:07] <lool> asac: Around?
[17:07] <lool> asac: Completely forgot to test browser.jar for you -- sorry!
[17:07] <seb128> calc: on localhost yes
[17:07] <lool> asac: I just did and it works like a charm; thanks a lot!
[17:08] <calc> seb128: ok, should i file a bug somewhere or do you know if this issue is already documented?
[17:08] <seb128> I don't care
[17:08] <seb128> ETOOMANYBUGS ;-)
[17:08] <lool> asac: I'm happy to comment to this effect in $bug BTW
[17:08] <calc> heh ok
[17:08] <seb128> if you open a bug please do it upstream directly
[17:09] <seb128> I don't think we have a bug about that yet
[17:09] <calc> seb128: ok
[17:09] <seb128> but I could be wrong
[17:11] <calc> fsck turning off gvfs doesn't actually solve the saving problem like i thought it did :\
[17:12] <calc> er turning off gvfs in OOo
[17:12] <calc> if i try to then save to the fileshare in the gnome dialog it still tries to use gio/gvfs instead of gvfs-fuse
[17:13]  * calc is so screwed, no file saving to gio/gvfs mounts currently work in OOo due to some bug that I can't determine how to track down
[17:22] <asac> lool: thanks for testing. what was the problem again ;)?
[17:24] <seb128> mvo: bug #327465 has been updated since you ask for an update
[17:26] <mvo> seb128: thanks, I had it on my list but then the sickness stroke
[17:29] <asac> lool: ah ... the alt+paste issue ;)
[17:30] <lool> asac: yes
[17:31] <asac> lool: plesae comment on moz bug 480290 ... i requested review
[17:32] <asac> mozilla bug 480290
[17:32] <asac> here we go
[17:48] <seb128> ok everybody
[17:49] <seb128> I've cleaned https://wiki.ubuntu.com/DesktopTeam/TODO, feel free to add tasks for contributors to pick there
[17:49] <seb128> and contributors feel free to pick tasks
[17:49] <seb128> we have also 18 desktop-bugs milestoned bugs on https://launchpad.net/~desktop-bugs/+bugs?field.milestone%3Alist=2202&field.milestone%3Alist=2203
[17:49] <seb128> which is a good list of bugs to work on if you want to tackle something useful
[18:01] <kenvandine_wk> seb128: thx
[18:01] <travisthepirate> hey my desktop hangs on "starting bluetooth" on boot and "stopping bluetooth" on shutdown.  any ideas?
[18:03] <chrisccoulson> travisthepirate - for support, you should go to #ubuntu
[18:08] <seb128> does somebody with fast download want to backport the one liner change on gnome bug #572403?
[18:09] <seb128> I would do it but I've to run in a few minutes and the gimp tarball is 23 megas to download and I'm using my download already
[18:13] <mvo> seb128: I can do that
[18:13] <seb128> mvo: danke
[18:16] <ember> mvo are you on it right now? i already have a diff
[18:16] <ember> just testing the build
[18:16] <mvo> ember: thanks, even better :)
[18:16] <mvo> ember: when you have the debdiff, just let me know (unless seb128 wants to sposnor it)
[18:17] <ember> ok
[18:17] <seb128> mvo: no, I've to run now and I don't want to download the orig to build the source upload
[18:18] <mvo> seb128: sure thing, I do it :)
[18:18] <seb128> thanks
[18:54] <crevette> pitti: the patch that Bastien did for gnome-bluetooth is not usable for bluez-gnome
[18:54] <crevette> at least it doesn't apply
[18:56] <ember> mvo diff added in bug #331306
[19:16] <calc> anyone know gvfs well enough to know what a uri i should passing to this program should look like?
[19:16] <calc> https://code.launchpad.net/~ccheney/+junk/gvfs-test
[19:16] <calc> its the example from the api docs
[19:16] <calc> i passed sftp://127.0.0.1/home/ccheney/Desktop/foo.txt and it claimed internal error
[19:20] <crevette> when I retrieve code source for a VCS, what should I do to make the code usable for packaging (make dist? ...)
[19:20] <crevette> I want to do a package from a snapshot
[19:32] <kenvandine_wk> how can i tell a package it won't work with python 2.4?
[19:33] <kenvandine_wk> at install time it is trying to byte-compile for python2.4
[19:34] <cj> calc: try sftp://user@host:port/path ?
[19:35] <cj> crevette: autoreconf && ./configure && make dist
[19:35] <crevette> cj: thanks
[19:35] <calc> cj: ok looking :)
[19:35] <cj> kenvandine_wk: if there's a .pc file for python, I think you can use the PKG_* m4 macros to say which versions it should not use
[19:36] <cj> calc: I haven't looked, myself, but I know the uri format includes user & port :)
[19:36] <cj> maybe gvfs is not smrt enough to put in sane defaults...
[19:36] <kenvandine_wk> cj: it is building for 2.5 and 2.6
[19:36] <kenvandine_wk> but at install time it tries to byte-compile for 2.4
[19:37] <kenvandine_wk> and the code just won't work in 2.4
[19:37] <cj> kenvandine_wk: hurm... I'm not familiar enough with python to say for certain.  I bet #python would know the answer...
[19:38] <kenvandine_wk> it isn't really a python issue
[19:38] <cj> crevette: oh, if it's a gnome module, you will want to run ./autogen.sh instead of autoreconf
[19:38] <kenvandine_wk> it is the way we handle installing python  stuff
[19:38] <kenvandine_wk> it's seems weird :)
[19:38] <crevette> cj: okay tx a lot
[19:38] <cj> do you mean the debian package byte compilation stuff?
[19:38] <cj> crevette: :)
[19:39] <cj> kenvandine_wk: you'll need to modify debian/rules to tell it the specifics of the install script, I think.  but you'll need to ask the python people how to byte-compile for only a subset of installed versions
[19:39] <kenvandine_wk> ok
[19:39] <kenvandine_wk> thx
[19:39] <cj> hurm, actually, it's a different file in debian/
[19:39] <cj> I don't recall what it's called, but probably something like postinst
[19:39] <mvo> thanks a lot ember
[19:40] <cj> the folks on #debian-devel on oftc are the people who know the nitty-gritty on that topic
[19:40] <kenvandine_wk> cj: ok, that should be enough to help lead me further than i am
[19:42] <calc> well i got it to mostly work but now it segfaults, heh
[19:48] <cj> calc: try fuse?  http://fuse.sourceforge.net/sshfs.html
[19:48]  * cj < lunch &
[19:48] <calc> i'm testing things to see why OOo is breaking
[20:40] <cj> calc: did you build gvfs from jhbuild?
[20:41] <cj> more directly: do you have debugging symbols for gvfs?
[20:42] <calc> cj: not at the moment but i can get them through ddebs repo in a bit
[20:42] <calc> cj: for the OOo issue i am testing the new OOo on intrepid in a few minutes to see if it is a OOo or gvfs regression
[20:42] <calc> s/minutes/hours/ really since it takes about 2hr to recompile
[20:42] <cj> ltrace might be enough for that
[20:43] <cj> gvfs shouldn't take long to compile by itself, I wouldn't think
[20:43] <calc> yea
[20:43] <calc> well there were some issues in gvfs fuse that i had fixed for 2.26.0 release next week
[20:44] <calc> but those are fixed now i need to determine what the problem is with regular gvfs saving in OOo, not sure what is at fault at the moment
[20:44] <cj> what gave you the core dump?
[20:44] <calc> really if i could get the gnome file dialog in OOo to spit out a fuse path for it to use that would fix my problems but it seems to give it the uri instead
[20:45] <calc> the test app cored but that appears to be due to seeking a sftp mount
[20:45] <calc> OOo doesn't core but just doesn't save
[20:45] <cj> did you run your test app with ltrace to see what it was doing?
[20:45] <calc> not yet
[20:45] <cj> that might point you in the right direction
[20:45] <calc> gnome_vfs_seek(0x1288550, 2, 0, 0x7fb37d095a60, 0x1286d20 <unfinished ...>
[20:45] <calc> --- SIGSEGV (Segmentation fault) ---
[20:46] <calc> i suppose that is where i need the gvfs debug packages
[20:46] <calc> to show any detail below my app
[20:47] <cj> if gnome_vfs_seek isn't that complicated, you may be able to figure out what is going on, but yeah, I'd get that -g compile going
[20:47] <cj> I assume this is jaunty?
[20:47] <calc> yes
[20:47] <cj> oh, you said intrepid, didn't you?
[20:48] <cj> amd64 or x86?
[20:48] <cj> or... something entirely different? :)
[20:48] <calc> oh i am going to test OOo 3.0.1 on intrepid to see if it works there with gvfs since it doesn't on jaunty
[20:48] <calc> amd64
[20:48] <cj> ah, all my amd64 machines are offline or I'd kick something off for you
[20:48] <calc> if it doesn't work on jaunty either then i can guess it is a problem with OOo, otherwise if it does work then something in gvfs is likely broken
[20:48] <calc> i can get the debug build from the ddebs repo in a little while
[20:49] <cj> colo moved facilities and I put 'em all in my basement.  my build box disk is even changing chassis :)
[20:49] <calc> deb http://ddebs.ubuntu.com jaunty main restricted universe multiverse
[20:49] <calc> that has all the debug build info
[20:49] <cj> ah, nice to know.  thanks.
[20:49] <calc> well for any package packaged correctly
[20:49] <calc> aiui it doesn't work so well for my package, OOo, since the debian maintainer didn't want to build OOo in -g mode due to code size
[20:50] <calc> something about many hundreds MB or gigabyte of files at that point
[20:50] <cj> yuck.  hard to fit it into memory, I'd wager
[20:50] <calc> yea
[20:51] <cj> novell may have one available, but I'm sure it's not the same config as debian/ubuntu
[20:51] <calc> yea i am not sure
[20:51] <cj> asking ajorg...
[20:52] <cj> I don't know if he builds anything outside of mono, though...
[21:10] <didrocks> hey seb128 :)
[21:11] <seb128> good evening didrocks
[21:11] <didrocks> I was wondering before pushing pidgin, if you think we must include this in the merge: https://lists.ubuntu.com/archives/ubuntu-devel/2009-March/027703.html
[21:11] <didrocks> and then, as I was leaving, I pushed it, but this can be quickly changed :)
[21:22] <seb128> didrocks: ups, sorry didn't read your line, you should better highlight me when you have a question
[21:23] <seb128> didrocks: no don't, the consensus seems to be that ubuntu-desktop should Recommends it rather no?
[21:27] <calc> tedg: how's south africa? :)
[21:29] <tedg> calc: Good, sunny.  I'm running out of battery though -- brought the wrong power adapter :-/
[21:36] <didrocks> seb128: sorry, I was reading some blogs. And yes, it seams that it's ubuntu-desktop which recommends it
[21:37] <didrocks> seb128: so, I have nothing to change to the branch. It shoudl be ok
[21:37] <didrocks> seb128: FYI, I managed evolution-mapi too
[21:38] <seb128> didrocks: you rock!
[21:38]  * didrocks hugs seb128 
[21:38]  * seb128 hugs didrocks
[21:42] <seb128> vuntz: there?
[22:13] <seb128> didrocks:
[22:13] <seb128> $ diffstat debian/patches/70_autoconf.patch
[22:13] <seb128>  autom4te.cache/output.0 |41866 ++++++++++++++++++++++++++++++++++++++++++++++++
[22:13] <seb128> ...
[22:13] <seb128> didrocks: !!!
[22:14]  * didrocks runs :/
[22:14] <didrocks> cdbs-edit-patch caught me
[22:14] <didrocks> I was used to quilt :/
[22:14] <seb128> didrocks: no no, come back and fix it!
[22:14] <seb128> lol
[22:14] <didrocks> seb128: ok, I come back :)
[22:15] <Nafallo> lol
[22:17] <didrocks> seb128: better now? :) I have to write somewhere « check for cache files to not make seb128 angry »
[22:18] <Nafallo> didrocks: please dont. the angry frenchmen is awesome! :-D
[22:18] <Nafallo> frenchman even
[22:18] <didrocks> Nafallo: do you have something to say against French people? :)
[22:18] <Nafallo> didrocks: nope. mostly for them.
[22:18] <Nafallo> (rather than against, that is)
[22:19] <Laney> seb128: Dude, if you apply patches to f-spot can you get them forwarded back to Debian?
[22:19] <Laney> I still dream of the mythical sync
[22:19] <didrocks> Nafallo: ^^
[22:19] <seb128> Laney: I pinged you about those patches some weeks ago ...
[22:19] <didrocks> seb128: I promess I will not forget it at the next merge :)
[22:19] <Laney> you sure?
[22:19] <Laney> seb128: Please subscribe me to bugs or something
[22:20] <Laney> or submittodebian makes it easy to forward these things
[22:20] <seb128> Laney: yes, I said there was 2 patches waiting for sponsoring if could have a look
[22:20] <seb128> Laney: ok
[22:21] <seb128> didrocks: hum
[22:22] <seb128> didrocks: you list 1 1024x600 changes in the remaining changes list but there was 3 of those uploaded in the previous revision
[22:22] <seb128> didrocks: what happened to the other 2?
[22:22] <didrocks> seb128: look at the description :)
[22:22] <didrocks> yeah, it seems like a game of "7 differences" :)
[22:22] <seb128> didrocks: I did read it, not very obvious to me though, is that a merge of the 3 changes?
[22:23] <didrocks> seb128: exactly, there is only on word change in the 3 descriptions
[22:23] <didrocks> so, I "merged" them in one line
[22:23] <didrocks> "account dialog, pounce windows and preference window
[22:23] <didrocks> instead of one line for account dialog
[22:23] <seb128> didrocks: well there is still 3 patches in the debian directory
[22:23] <didrocks> one for pounce windows…
[22:24] <seb128> didrocks: that's misleading
[22:24] <seb128> you could have listed the 3 names and one description
[22:24] <didrocks> seb128: oh, I should have use a *
[22:24] <seb128> I'm wondering if the next to do the update will forgot the ones not listed
[22:24] <seb128> forget
[22:24] <seb128> I tend to use those summary to know what to keep over
[22:24] <didrocks> I think you're right. With a star, it will be better?
[22:24] <seb128> if you list one names instead of 3 that's confusing
[22:24] <didrocks> ok, so, one by line?
[22:24] <seb128> yes
[22:24] <seb128> either way
[22:25] <seb128> * or all the names
[22:25] <seb128> just make it clear that's several patches
[22:25] <didrocks> I prefer the star, let me change it
[22:25] <seb128> ok
[22:25] <seb128> thanks
[22:25] <seb128> sorry for being picky on details ;-)
[22:25] <didrocks> of course, didn't think it was not obvious at a first glance
[22:25] <didrocks> no no, you're right, I prefer to do better packaging stuff next time :)
[22:27] <didrocks> seb128: you can pull it again :)
[22:27]  * didrocks is sure that now seb128 likes bzr pull ;)
[22:27] <seb128> indeed ;-)
[22:27] <seb128> much easier than lp upload and download rounds
[22:27] <didrocks> for sure :-)
[22:28] <seb128> ok, good know
[22:28] <seb128> ls
[22:28] <seb128> ups
[22:28] <seb128> didrocks: thanks for your patience and good work :-)
[22:28] <didrocks> seb128: you're welcome :)
[22:28] <didrocks> time to go to bed now.
[22:29] <seb128> 'night didrocks
[22:29] <Nafallo> didrocks: meeh. you made him happy again damnit :-P
[22:29] <didrocks> seb128: thanks, you too. See you tomorrow!
[22:29] <seb128> thanks
[22:29]  * Nafallo tickles seb128 
[22:29] <didrocks> Nafallo: hehe ;)
[22:58] <rickspencer3> ArneGoetje: good morning