[05:11] <davyboy04> Would anybody know why my desktop effects worked perfectly with the live cd and now they will not enable after installation?
[06:37] <dholbach> good morning
[11:31] <pitti> seb128: can you please reupload gnome-panel with an SRU bug # in the changelog? without one, they are much harder to track, and will most likely be forgotten about
[11:31] <seb128> pitti: ok
[11:31] <pitti> seb128: thanks; rejecting the current one then
[11:31]  * pitti hugs seb128
[11:32]  * seb128 hugs pitti
[11:33] <seb128> pitti: reuploaded
[12:03] <pitti> seb128: I don't understand the test case in bug 211205
[12:03] <pitti> seb128: there's nothing at all in ~/.gvfs after mounting my USB hard disk (with some music on it)
[12:04] <pitti> seb128: why should it mount my HD under ~/.gvfs? it's already in /media/ after all?
[12:29] <seb128> pitti: hum
[12:30] <seb128> pitti: right, I tried using ssh to localhost
[12:31] <seb128> you have a point about the local mount
[12:31] <seb128> using ssh to localhost rather ;-)
[12:37] <seb128> pitti: upstream tested on a mtp devices but it was mounted by the gphoto backend which gives a fuse mount too, I've updated the testcase instructions
[12:40] <pitti> aah
[12:40] <seb128> pitti: about bug #226831, I'm not sure what testcase we can use, it doesn't fix launchpad bugs that I know
[12:41] <pitti> seb128: ok, then we just test 'still works for me'?
[12:41] <seb128> pitti: do we need upstream bug fix versions to fix known bugs in launchpad?
[12:41] <pitti> seb128: I was just interested in the effective diff, since we already had some patches
[12:41] <pitti> (especially for teh clock)
[12:41] <seb128> pitti: yes, basically, we test "no regression in daily use"
[12:41] <seb128> pitti: I can attach that to the bug if you want
[12:42] <seb128> we had 2 of the upstream changes backported
[12:42] <pitti> ah, ok
[12:42] <pitti> so we should concentrate testing to the clock applet
[12:42] <seb128> yes, only the clock changed
[12:42] <seb128> as you can see on the diffstat ;-)
[12:44] <seb128> do you want me to add some instructions? like add some locations, switch between those, verify that /etc/timezone is correctly updated when clicking on set and that the clock is correct?
[12:44] <seb128> I did that on my box before uploading
[12:45] <pitti> hm, WTH?
[12:45] <pitti> seb128: sure, that can't hurt
[12:45] <pitti> seb128: I downgraded gvfs again, for testing the update
[12:45] <pitti> I logged in, and I only have "? ? ? ? ? ? .gvfs"
[12:45] <pitti> and ls .gvfs says "transport endpoint not connected"
[12:45] <pitti> however, on my normal user, ~/.gvfs is a normal directory
[12:46] <seb128> pitti: fusermount -u .gvfs
[12:46] <pitti> gvfsd is still running, though
[12:46] <seb128> pitti: then /usr/lib/gvfs/gvfs-fuse-daemon .gvfs
[12:46] <pitti> ah, now it's back
[12:46] <seb128> pitti: that's bug #212789
[12:47] <seb128> pitti: nothing is unmounting the fuse mount between logins, that's on my 8.04.1 list
[12:48] <seb128> pitti: you don't need to restart the session though to test, just fusermount -u .gvfs && /usr/lib/gvfs/gvfs-fuse-daemon .gvfs
[12:48] <pitti> right
[12:48] <seb128> you can also attach gdb to it to make sure it's crashing
[12:48] <pitti> I did it anyway
[12:48] <seb128> ok
[12:48] <pitti> (gdmflexiserver -l)
[12:48] <pitti> but it wasn't crashing for me
[12:48] <seb128> do you get the crash before update?
[12:48] <seb128> hum
[12:48] <pitti> totem and rhythmbox on .gvfs/.../ worked fine
[12:48] <pitti> I downgraded to the hardy final packages
[12:48] <pitti> all binaries of the gvfs source
[12:49] <seb128> pitti: you have many songs there?
[12:49] <pitti> I tried a dir with 12 songs
[12:49] <seb128> it takes a few seconds to get a crash on my config
[12:49] <seb128> ah, that might not be enough
[12:49] <pitti> I can also try a dir with some 100s
[12:49] <pitti> ok, retrying
[12:49] <seb128> I tried on my collection
[12:49] <seb128> you need to hammer a bit the thing
[12:49] <seb128> 12 songs is not a lot of datas
[12:50] <pitti> aah
[12:51] <pitti> I pointed it to my entire music collection
[12:51] <seb128> good ;-)
[12:51] <pitti> (fresh user)
[12:51] <pitti> it stopped at imoprting the 69th song
[12:51] <pitti> and now I can't play anything
[12:51] <pitti> gvfsd is still running, though
[12:51]  * pitti upgrades and tests again
[12:51] <seb128> did the fuse daemon crashed?
[12:52] <pitti> hm, unsure; should have looked better; but in any case the apps were hanging
[12:52] <seb128> ok
[12:52] <seb128> ls .gvfs
[12:53] <seb128> if it's not connected the daemon crashed
[12:53] <pitti> gvfs-fuse-daemon on /home/joe/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=joe)
[12:54] <seb128> right, the mount is not cleaned when the daemon crash, that's the bug I pointed before
[12:55] <pitti> updated, restarted session, importing again; it's on the 150th song now
[12:55] <pitti> looks good so far
[12:56] <seb128> cool ;-)
[12:58] <pitti> bug updated
[12:59] <seb128> thanks
[12:59] <pitti> seb128, mvo: btw, does any of you have an ATI card where fglrx works? I need someone to verify bug 208026
[12:59] <seb128> pitti: I do
[12:59] <seb128> will try this one
[13:00] <pitti> seb128: merci!
[13:00] <seb128> pitti: btw there is a new evolution-data-server stable update version, it has migration code for the password to the text encoded version to the keyring, do you think it's something suitable for an update?
[13:01] <pitti> oh, nice
[13:01] <pitti> seb128: will that work for people who already 'manually' migrated?
[13:01] <seb128> the code is not too complex, it has been written by one upstream and approved by somebody else from their team and I've verified it works fine for me
[13:01] <pitti> i. e. if the user already set a password in the keyring, the migration code should probably not do anything
[13:02] <pitti> but it would solve the issue nicely for upgrades
[13:02] <seb128> pitti: that's not possible, e-d-s is build without the keyring at the moment
[13:02] <seb128> pitti: because there was no migration
[13:02] <seb128> pitti: and we didn't want users to have to enter their passwords again on upgrade
[13:02] <pitti> seb128: hm, how is that solved in hardy right now then? what saves the passwords?
[13:02] <pitti> seb128: ah, I see; you can configure it to use either keyring or evo-specific password storage?
[13:03] <seb128> right now it's base64 encoded in a text file
[13:03] <seb128> yes
[13:03] <seb128> they added the code which reads the base64 encoded file and copy the password in the keyring
[13:03] <seb128> so if we build using the keyring it'll be transparent for users
[13:04] <pitti> that sounds good
[13:04] <pitti> does it properly clean up the old file afterwards?
[13:05] <seb128> yes
[13:05] <seb128> it does migrate the password when you use it for the first time
[13:06] <seb128> and delete it from the base64 text file when it has been copied in the keyring
[13:06] <pitti> awesome
[13:06]  * pitti -> lunch, bbl
[13:06] <seb128> pitti: enjoy
[13:12] <mvo> pitti: I have one, if seb128 is not faster, I can do it later
[13:15] <seb128> jockey doesn't ask if I want to install fglrx, not sure why
[13:19] <seb128> $ jockey-gtk --check-composite
[13:19] <seb128> There is no available graphics driver for your system which supports the composite extension.
[13:19] <seb128> not sure why it's saying that
[13:26] <huats> lut seb128
[13:26] <seb128> 'lu huats
[13:47] <pitti> seb128: it shouldn't, since radeon already provides composite support
[13:48] <pitti> seb128: the output string is bad, indeed
[13:51] <seb128> pitti: when does it suggest installing fglrx then?
[13:52] <pitti> seb128: hm, good point
[13:52] <pitti> seb128: that was bug 207957, and fixed in hardy final already
[13:53] <pitti> seb128: so I guess this only really works for nvidia cards
[13:53]  * pitti adjusts the bug
[13:53] <seb128> pitti: does it look at the currently used driver?
[13:53] <pitti> seb128: no, jockey doesn't know the current driver; that's compiz' job
[13:53] <seb128> pitti: I can try to switch to vesa
[13:54] <pitti> no, that won't help :(
[13:54] <seb128> pitti: well, the question is "if I use vesa, will it recommend fglrx"?
[13:54] <seb128> ok
[13:54] <pitti> there's a bug against g-c-c to just try and start compiz, and only if that fails, call jockey
[13:54] <pitti> once it does that, we can sanitize the logic in jockey again
[13:54] <pitti> right now it works around the fact that g-c-c *always* calls --check-composite
[13:55] <seb128> ok
[13:55] <pitti> so I had to cripple it a bit to not suggest fglrx over radeon, etc.
[13:55] <seb128> I can try to hack the logic to test the install cancellation if you want
[13:55] <pitti> bug updated
[13:56] <pitti> seb128: that would be good
[13:56] <pitti> seb128: /usr/share/jockey/handlers/fglrx.py
[13:56] <pitti> line 35
[13:56] <pitti>         if len(devices) == 0 or devices[0].driver in ['fglrx', 'ati', 'radeon', None]:
[13:56] <pitti> drop the 'ati' and 'radeon' from the list
[13:56] <pitti> then --check-composite will claim that you need fglrx
[13:57] <pitti> oh, wait
[13:57] <pitti> seb128: indeed, with that 'vesa' should suggest to install fglrx
[13:57] <pitti> seb128: sorry about that
[13:57] <seb128> let me try
[13:57] <pitti> I forgot that I recently added this check of xorg.conf
[13:57] <pitti> seb128: so, just change xorg.conf to vesa (you don't actually need to restart X)
[14:12] <seb128> pitti: confirmed, the upgrade fixes the issue
[14:13] <seb128> pitti: what is the bug number again?
[14:13] <pitti> \o/
[14:13] <pitti> bug 208026
[14:14] <pitti> with that being verified, jockey is three bugs down, one to go
[14:14] <pitti> but 216650 definitively needs an nvidia system
[14:15] <seb128> not for me then, I've ati and intel configurations
[14:16] <seb128> I've commented on the reboot one
[14:17] <ember> i have one nvidia with hardy
[14:18] <pitti> seb128: thanks
[14:18] <pitti> ember: ah; interested in doing the verification for bug 216650?
[14:19] <pitti> seb128: i. e. with the updated version jockey returns saying the driver is disabled instead of triggering the reboot notification?
[14:20] <seb128> pitti: jockey doesn't display anything when cancelling, gnome-appearance-properties displays the "can"t enable desktop effects" dialog
[14:20] <pitti> seb128: ok, I think that can be considered 'correct'
[14:20] <seb128> yes
[14:20] <ember> pitti i have -new and jockey is enable and In use
[14:21] <pitti> ember: right; so if you install e. g. nvidia-glx, then jockey should say disabled/not in use, instead of enabled/not in use
[14:22] <ember> let me install nvidia-glx
[14:28] <ember> pitti i've installed nvidia-glx, and jockey is disable not in use
[14:28] <pitti> ember: great
[14:29] <pitti> ember: with apt-get install jockey-common/hardy jockey-gtk/hardy it should show it as 'enabled'
[14:29] <ember> i'm running jockey-gtk
[14:35] <pitti> ember: no, I mean, above command will downgrade the packages from hardy-proposed to hardy final
[14:35] <ember> oh sorry, enable but not in use
[14:44] <pitti> ember: when it says 'enable but not in use', which version of jockey-common do you have?
[14:45] <ember> Version: 0.3.3-0ubuntu7
[14:46] <pitti> ember: right; now, can you please upgrade to hardy-proposed and try ubuntu8? It should say 'disabled' and 'not in use', since you are using a different driver than the one displayed and proposed by jockey
[14:47] <ember> disable, not in use
[14:47] <pitti> ember: cool; can you please report your tests to the bug?
[14:47] <pitti> ember: thanks a lot for your time!
[14:48] <ember> okidoki
[14:57] <ember> btw anyone is getting problems creating a chroot of pbuilder to intrepid?
[14:57] <ember> W: Failure trying to run: chroot /var/cache/pbuilder/build/25979/. dpkg --force-depends --install var/cache/apt/archives/libc6_2.7-10ubuntu3_i386.deb
[14:57] <ember> i'm getting this on sid too
[15:12] <Hobbsee> seb128: did you tell me that totem-xine or totem-gstreamer had the dvd menu support?
[15:13] <seb128> Hobbsee: no, but totem-xine has it
[15:14] <Hobbsee> seb128: that's what i thought.  ahhh, for some reason, i have both installed now.
[15:23] <Hobbsee> hmmm
[15:23] <Hobbsee> and with totem-xine  now, i get no picture.
[15:24] <Hobbsee> interesting.  i had this all working together at one point.  maybe that was with gutsy.
[15:25] <seb128> Hobbsee: bug #219062?
[15:30] <ember> perhaps this is just an archive thing coz i can create a hardy chroot fine, can anyone confirm this?
[15:37] <Hobbsee> seb128: don't think so
[15:40] <Hobbsee> seb128: no, i'ts not that.
[15:40] <Hobbsee> seb128: i can watch the dvd with -gstreamer fine
[16:58] <pochu_> seb128: hi, could you sync libbeagle from Debian? the only diff was to make it python version independent, and the change is now in Debian too (and we also have the same Python version :)
[16:58] <seb128> pochu_: sync like in intreprid or hardy updates?
[16:59] <pochu_> intrepid
[17:00] <seb128> hum, k
[17:00] <seb128> I have no intrepid box and didn't start looking at it yet but I guess I can do syncs ;-)
[17:05] <seb128> pochu_: synced
[17:05] <pochu_> seb128: thanks :)
[17:05] <pochu_> seb128: how is it going? busy with hardy updates?
[17:06] <pochu_> did GNOME 2.22 end being too buggy or was it good? :)
[17:06] <seb128> yes, really busy trying to keep up with the hardy bug flood and doing srus
[17:06] <seb128> medium
[17:06] <seb128> it's quite good, out of some gvfs smb issues
[17:07] <pochu_> I could help you with vinagre's, if Jonh makes more stable releases ;)
[17:07] <pochu_> anyway I have a patch pending for -proposed... I'll have to check that one
[17:08] <seb128> no need to wait for new version to backport fixes that should be in 8.04.1
[17:12] <pochu_> ok
[17:12] <pochu_> anyway this patch is from the unstable branch, so it won't end up in any stable release ;)
[17:20] <seb128> pochu: what does it do?
[17:21] <pochu> seb128: bug 199116, it adds a menu to send ctrl+alt+del to the guest, the problem is that it adds a couple of new strings
[17:22] <seb128> pochu: somebody was asking about it some days ago and upload to his ppa I think and was working on the sru
[17:22] <pochu> seb128: the guy asking for it said he talked to you about it, see comment 16
[17:22] <pochu> right
[17:22] <pochu> the debdiff is attached
[17:24] <solarion> is anyone else seeing a problem with ssh finding seahorse-agent?
[17:24] <solarion> or not finding, which is the problem.  :)
[17:24] <seb128> the gnome-keyring is used as ssh agent in hardy so I didn't try using seahorse there
[17:25] <solarion> seb128: until this morning, it Just Worked.
[17:25] <seb128> weird, hardy didn't change recently
[17:25] <solarion> seahorse-agent is running; it looks like the env vars just aren't getting set
[17:25] <solarion> SSH_AUTH_SOCK is set
[17:27] <solarion> -rwxr-xr-x 1 root root 40932 2008-04-21 10:41 /usr/bin/seahorse-agent
[17:28] <solarion> what is responsible for setting env vars for seahorse-agent?
[17:28] <solarion> seahorse-agent --execute x-session-manager
[17:29] <seb128> /etc/X11/Xsession.d/60seahorse I would say
[17:29] <solarion> ok, but how to the env vars get set?
[17:31] <solarion> actually, it looks like SSH_AUTH_SOCK is all that's needed
[17:33] <solarion> connect(3, {sa_family=AF_FILE, path="/tmp/keyring-s53Esh/ssh"}, 110) = -1 ECONNREFUSED (Connection refused)
[17:34] <solarion> weirdness
[17:37] <solarion> seahorse isn't the problem; it's gnome-keyring-daemon, but only on this box
[17:43] <solarion> weird.  Logged out, killed gnome-keyring-manager, restarted X, logged back in and now it works
[17:44] <lapo> hey there
[17:44] <solarion> hej
[19:16] <gobbles414> Can anyone here answer and OpenOffice-related question?
[19:22] <pjoul> gobbles414: go to #ubuntu
[19:23] <gobbles414> Went there... Waited a few minutes but no help. Also tried #Openoffice.org... same thing, now help
[19:23] <gobbles414> oops... no help
[19:23] <pjoul> so what's your question then
[19:25] <gobbles414> Thanks pjoul... I need to learn how to delete author/date metadata from "Tracked Changes" that I have made in Writer. I have "Remove personal information on saving" enabled.
[19:26] <gobbles414> I hear that what I want to do is possible in MS Word 2003 and newer. But I haven't been able to find anything regarding OpenOffice Writer
[19:28] <pjoul> hmm, sorry man - I'm not an openoffice expert :-/
[19:28] <pjoul> anyway try some googling
[19:29] <pjoul> http://www.oooforum.org/forum/viewtopic.phtml?t=60461
[19:29] <pjoul> http://www.itbusinessnet.com/articles/viewarticle.jsp?id=42970
[19:29] <pjoul> http://www.google.cz/search?q="Tracked+Changes"+openoffice
[19:29] <pjoul> ﻿http://www.google.cz/search?q="Tracked+Changes"+openoffice"
[19:29] <pjoul> oops
[19:29] <pjoul> the first one
[19:30] <pjoul> ﻿http://www.google.cz/search?q="Tracked+Changes"+openoffice
[19:32] <gobbles414> 1 sec while I try something from your second link
[19:35] <gobbles414> Yeah, all I see is a way to search changes by date. Am I missing something? I actually want to remove the date metadata.
[19:40] <pjoul> sorry man. I cannot help you
[19:41] <pjoul> maybe you could try to post into that oooforum.org
[19:42] <gobbles414> Thanks for trying. I appreciate it!
[20:29] <pochu_> pitti: I see in your debhelper merge you kept support for Dapper... should we do the same for gstreamer? That would mean we can't sync it...
[20:30] <pochu_> err, wait
[20:30] <pochu_> gstreamer is about linking directories
[20:30] <pochu_> nevermind
[20:31] <pitti> pochu: it's just to avoid bad intrepid->dapper backports
[20:32] <pitti> pochu: as long as we have other debhelper changes, that one is cheap to keep
[20:33] <pochu> that makes sense
[23:51] <rooger> hello?