[00:06] <herbie_> tap tap tap    is thing on?
[09:07] <huats> morning all
[09:54] <seb128> lut huats
[09:54] <seb128> mvo: when you have a moment could you look at the new comments on http://bugzilla.gnome.org/show_bug.cgi?id=545123 and tell me if that makes sense?
[09:55] <huats> hello seb128 and mvo
[10:04] <mvo> seb128: yes, will do
[10:04] <mvo> hey huats
[11:24] <asac> seb128: i think swfdec needs to be newed
[11:24] <seb128> asac: right, will do that in a minute
[11:24] <asac> cool
[11:41] <asac> seb128: what gtk will intrepid final ship?
[11:41] <asac> 2.14?
[11:41] <seb128> asac: 2.14.n
[11:42] <seb128> why?
[11:42] <asac> seb128: swfdec has a problem which appears to be fixed on gtk-trunk
[11:42] <asac> http://bugzilla.gnome.org/show_bug.cgi?id=548993
[11:43] <asac> swfdec author said that it will be fixed in next 2.13.x release. so we probably dont need to do anyhting here and verifying when that gets into intrepid is enough
[11:44] <seb128> right
[11:44] <seb128> the next gtk tarball should come soon
[12:21] <lool> asac: Oh that's actually a gtk bug; I'm glad it's goind to be fixed, it has annoyed me big time
[12:21] <asac> lool: right. i think even some of the windows we see with flash get probably fixed by that
[13:41] <lapo> hi
[13:46] <lapo> heya seb
[13:47] <lapo> seb128: http://xoomer.alice.it/bat/tmp/application-x-debian-package.tar.bz2
[13:47] <seb128> hello lapo
[13:47] <seb128> cool, thanks
[14:21] <seb128> tedg: btw you mailed me about a change which was required for the new gdm, the way to start it I think some time ago
[14:21] <seb128> tedg: any reason you didn't commit that to the bzr so people actually get the fix?
[14:21] <tedg> seb128: I made my own branch and committed it there so that you could look at it before committing it to the main branch.
[14:22] <tedg> seb128: lp:~ted-gould/+junk/gdm-snap
[14:22] <seb128> tedg: it has been week ago, it didn't turn to work as you expected?
[14:22] <seb128> tedg: would be nice to merge such changes quickly
[14:23] <tedg> The change was in the .debs that I made.
[14:23] <tedg> In general, the new GDM didn't work as expected :)
[14:23] <seb128> tedg: the .deb that you made but that nobody knows about, I point users to the team bzr to build a snapshot
[14:25] <tedg> seb128: Okay, so do you think the change is good?  I'd be happy to merge it.
[14:30] <seb128> tedg: looking at the diff, the email change is not required, not sure about all the usplash things you didn't document those
[14:30] <tedg> seb128, Hmm, I only remember changing on line...
[14:31] <seb128> tedg: http://bazaar.launchpad.net/~ted-gould/+junk/gdm-snap/revision/4986
[14:31] <tedg> seb128: Oh, and the e-mail, yeah, that's not required.
[14:32] <seb128> tedg: what was the rational again about the background thing? I don't find your mail now
[14:33] <tedg> seb128: It wasn't starting in the background for me.  It would just block on package upgrade and init.
[14:33] <seb128> what do you mean?
[14:33] <tedg> seb128: I'm not sure about the usplash stuff, is that from a patch that got left applied?
[14:33] <seb128> no idea about that either
[14:34] <seb128> I though you fixed "login doesn't work after boot"
[14:34] <tedg> So when the running "/etc/init.d/gdm start" that would block, forever.
[14:34] <seb128> not package upgrade issues
[14:34] <seb128> oh
[14:34] <seb128> weird, it didn't for the previous gdm
[14:34] <tedg> So I first noticed it on the upgrade, but then I found that it also happened on boot.
[14:40] <seb128> what happened on boot?
[14:41] <tedg> GDM would start, but I think it would block init.  So if you killed it the rest of init would run, and then it would restart.
[14:41] <lapo> seb128: http://brainstorm.ubuntu.com/idea/11844/ you can kill this one once done with patching g-i-t
[14:42] <seb128> tedg: ah ok, so just adding the --background seems to be a good idea, I'll do that later
[14:42] <seb128> lapo: ok thanks
[14:46] <MacSlow> pitti, how much can I bother you with more dbus/ck-related questions?
[14:46] <pitti> MacSlow: on that box where you try gdm: if you boot it normaly and use the standard gdm, does your GNOME session have a CK seat? (ck-list-sessions) and does it complain about errors?
[14:46] <MacSlow> pitti, I still need to get intrepid on the laptop (iwl3945 still refuses to work on it :/ )
[14:47] <pitti> MacSlow: as much as needed to get it working for you to unblock your work :)
[14:47] <pitti> MacSlow: shouldn't be different in hardy
[14:47] <pitti> MacSlow: I'm trying to find out what's broken in your dbus setup
[14:47] <MacSlow> pitti, no normal gdm/gnome-session works on hardy ... e.g. calling echo $XDG_SESSION_COOKIE in my current session in a gnome-terminal yields  a proper value
[14:48] <pitti> MacSlow: ck-list-sessions works, too? and doesn't complain about "cannot lookup session yadayada"?
[14:48] <MacSlow> pitti, yes
[14:48] <MacSlow> that works too
[14:48] <pitti> MacSlow: so if you stop that session and gdm, and start your custom gdm, does ck-list-sessions still work afterwards and gives you a session for the new gdm?
[14:49] <MacSlow> pitti, no ... only when I try my custom installed gdm I've all these problems
[14:49] <pitti> MacSlow: you don't restart dbus or consolekit in between or anything?
[14:49] <MacSlow> no ... but just to be sure I can try exactely that right now once sec
[14:56] <tedg> So, I added some icons to the FUSA applet.  And I got it working with uuencode/decode so that they'd go in the diff.  But since it's my first time doing something like this, could someone review this patch?  http://people.ubuntu.com/~ted/85_5_status_icons.patch
[14:58] <MacSlow> pitti, so I just exited my gnome-session, as root /etc/init.d/gdm stop and started just the upstream gdm
[14:59] <seb128> tedg: doesn't look correct
[14:59] <MacSlow> pitti, starting that upstream gdm failed with the error-message ** (gdm-binary:9272): WARNING** : Couldn't connect to system bus: Failed to connect to socket /opt/gdm-new/var/run/dbus/system_bus_socket: Connection refused
[15:00] <seb128> tedg: either you do upstream change and roll a new tarball and doesn't bother using uuencode
[15:00] <seb128> tedg: or you add those as packaging change and install them in the debian/rules
[15:00] <pitti> MacSlow: right, it's looking for the wrong socket; it needs to use the system one in /var/run/dbus/
[15:01] <MacSlow> pitti, but there is this file/socket
[15:01] <MacSlow> pitti, does that matter?
[15:01] <pitti> MacSlow: you mean /opt/gdm-new/ socket exists?
[15:01] <pitti> MacSlow: that won't work
[15:01] <pitti> you can delete that
[15:02] <tedg> seb128: I guess I'm a little confused.  I thought it was bad to do a new upstream tarball in general as it isn't "upstream" but it seems like if it's done in debian/rules it would be nearly impossible for upstream to accept the patch if they wanted to in the future.
[15:03] <tedg> That's why I did it all inline as a patch, including the uudecode stuff.
[15:06] <MacSlow> pitti, ok I'll delete it and try again? BTW, I have the line "<servicedir>/opt/gdm-new/share/dbus-1/system-services</servicedir>" in /etc/dbus-1/system.conf, which I just commented out. That was a hint from Jon earlier this week.
[15:06] <pitti> MacSlow: you shouldn't attempt to run a second dbus under /opt; everything shuold use the normal system dbus
[15:06] <pitti> otherwise you need a second consolekit, hal, and everything as well; that's totally unnecessary
[15:07] <MacSlow> pitti, I didn't restart dbus at all or tried to start the on in /opt/gdm-new
[15:07] <pitti> MacSlow: but what is weird is that the dbus socket location shuold only be known to libdbus, and you certainly didn't rebuild that in /opt?
[15:07] <MacSlow> that line is just a left-over from earlier attempts
[15:07] <pitti> MacSlow: <servicedir> shuoldn't be necessary
[15:08] <MacSlow> pitti, well I did install dbus, hald, ck with upstream gdm initially because I was told newer version of those were  needed
[15:08] <pitti> MacSlow: we have the latest dbus and hal in intrepid
[15:08] <pitti> oh, wait, hardy
[15:08] <MacSlow> pitti, do you hint that I try to rebuild gdm with the hardy-supplied ones?
[15:09] <MacSlow> I don't have intrepid in a working state yet
[15:09] <pitti> MacSlow: that would be my first shot; if that doesn't work, you could take the intrepid dbus source package and build/install on hardy (that shouldn't cause any problem)
[15:09] <pitti> hardy's hal should be alright
[15:10] <MacSlow> so what should i try next? intrepid dbus on hardy?
[15:13] <pitti> MacSlow: yes, and revert all the dbus config changes you made
[15:13] <MacSlow> changes reverted
[15:15] <pitti> MacSlow: just weird that gdm needs such a new dbus...
[15:15] <pitti> MacSlow: maybe you can just try building against the normal hardy dbus
[15:15] <pitti> that'd certainly be easiest
[15:17] <MacSlow> pitti, hm... gdm's configure didn't complain using hardy's dbus now
[15:17] <MacSlow> odd
[15:17] <pitti> so much the better
[15:18] <MacSlow> pitti, ok "ldd gdm-binary | grep dbus" reports the system-wide dbus library used now
[15:19] <MacSlow> pitti, I'll now repeat the inital test with stopping hardy's gdm, firing up upstream gdm and checking ck-list-sessions
[15:19] <pitti> MacSlow: good luck!
[15:19]  * MacSlow would sell his soul to the devel if it helped
[15:19] <MacSlow> devil rather :)
[15:24] <MacSlow> pitti, that first test yielded a small progress ... this time ck-list-sessions reported the session from the upstream gdm
[15:25] <pitti> yay, so dbus works with the gdm
[15:25] <MacSlow> pitti, but gdm itself was "stuck" and complained about missing gnome-session in the install-prefix where I put it
[15:26] <MacSlow> pitti, so dependency hell is moved a little further ... gnome-session
[15:27] <pitti> MacSlow: ugh; you can't configure it for standard prefix and run gdm out of the built tree?
[15:27] <pitti> MacSlow: well, if not, /opt/gdm-new/usr/bin -> /usr/bin symlink should do (or similar) :)
[15:28] <pitti> MacSlow: back in some 45 minutes
[15:28] <MacSlow> pitti, ok
[16:10] <MacSlow> pitti, just a quick update ... the issue with $XDG_SESSION_COOKIE is now solved ... thanks a lot for the help!
[16:13] <seb128> MacSlow: what was it?
[16:15] <MacSlow> seb128, wrong dbus
[16:16] <MacSlow> seb128, and misleading info reagrding the really required dbus-version for upstream gdm
[16:16] <seb128> ah
[16:16] <seb128> you should really use intrepid for devel work
[16:17] <MacSlow> seb128, initially I wanted something stable ... and not introduce more moving targets than necessary
[16:18] <seb128> well it means that you have to backport all the things you need where you could just dist-upgrade
[16:18] <seb128> and things don't break that much around you
[16:31] <pitti> yay
[16:33] <ember> seb128 is this the right thing to do when libgnomekbd have symbols removed and soname changed to .3 http://paste.ubuntu.com/43372/ ?
[16:33] <seb128> ember: I already packed this update
[16:33] <seb128> and evince
[16:34] <ember> cool, but is correct the diff?
[16:34] <seb128> they are blocked due to CD builds, not the right time to change sonames
[16:35] <seb128> ember: yes, no need to add a shlibs though
[16:35] <seb128> I was just about to go
[16:35] <ember> hmm ok thanks for the info
[16:35] <seb128> I'll set up a new system to claim updates soon, I've discuss that with dholbach, we start duplicating work too much there
[17:01] <mvo> ember: thanks for your updates! I will sponsor them as soon as intrepid is open again :)
[17:01] <ember> np, thanks
[19:21]  * mpt wonders why Nautilus offers an "Open in Text Editor" menu item when his iPod is selected
[19:26] <tedg> mpt: To change the lyrics of the songs!  Duh!
[19:29] <mpt> oh yeah
[19:29] <mpt> In that case it should offer an "Open in Text Editor Backwards" item, so I can read all the subliminal messages
[19:34] <tedg> I think you should submit a feature request. :)