[08:12] <seb128> hello
[08:13] <seb128> pitti: hey, did you look at why the retracers have a lock or should I do that?
[08:13]  * seb128 is reading his emails
[08:13] <pitti> moin seb128
[08:13] <pitti> seb128: I didn't get any lock mail today?
[08:13] <pitti> I got two yesterday, but I fixed that
[08:14] <pitti> (they are actually *working* now, yohoo)
[08:14] <pitti> I mean the mails
[08:14] <pitti> (retracers, too)
[08:14] <seb128> pitti: I got 3 watchdog emails during the night
[08:15] <seb128> weird that you didn't receive those
[08:17] <seb128> pitti: btw do you plan to do srus today? there is a gtk+ and a gedit update waiting for you since friday ;-)
[08:20] <pitti> seb128: already doing
[08:20] <seb128> pitti: you rock!
[08:20] <pitti> eww indeed, three lock files
[08:20] <pitti> seb128: could you have a look, please?
[08:20] <seb128> pitti: will do that
[08:21] <pitti> ah, synced mail again, there it is
[08:39] <pitti> seb128: is bug 287611 really SRU worthy? it doesn't even have a crash report, or a test case, or anythihng
[08:40] <seb128> pitti: that was an implicit declaration so I figured I would do the line change in the sru while I was doing an upload
[08:41] <seb128> pitti: could be causing crashes on some architectures so why not, I would not have uploaded only for that though
[08:41] <pitti> seb128: ah, it's adding that missing #include only? okay
[08:41] <seb128> pitti: right
[08:43] <pitti> seb128: I added tasks to bug 305226, are both fixed in jaunty?
[08:45] <seb128> pitti: no, fixed on my disk but the 2.15 update has some issues so I will only upload the next tarball
[08:45] <seb128> which should be in the next days, new GNOME scheduled for next week
[08:46] <pitti> ah,it's in that; alright
[09:06] <seb128> ok
[09:06] <seb128> so I did some bootcharting for session login speed yesterday
[09:06]  * seb128 looks at mvo
[09:06]  * seb128 looks at pitti
[09:06]  * seb128 looks at vuntz
[09:06] <seb128> I blame you guys for session slowness ;-)
[09:07] <seb128> I managed to cut 15 seconds in my session start btw
[09:07] <seb128> mvo: so compiz doesn't register correctly to the session which makes gnome-session sit there and wait for timeout for several seconds
[09:07] <mvo> seb128: what is it doing incorrectly?
[09:08] <seb128> pitti: jockey is hitting disk quite a lot apparently, you know about it I guess?
[09:08] <seb128> mvo: dunno but .xsession-errors has WARNING: Application 'compiz.desktop' failed to register before timeout
[09:08]  * mvo mubbles something about baroque complexity when registering with the session
[09:09] <seb128> mvo: and bootchart shows it's working for a few second and then doing nothing
[09:09] <seb128> mvo: could be true, vuntz probably have details on how to register correctly if you need those ;-)
[09:09] <seb128> I've to admit I don't know what the clients are supposed to do
[09:09] <seb128> but compiz and seahorse timeout
[09:09] <mvo> ok
[09:09] <seb128> which creates a lot of sitting there and waiting
[09:09] <seb128> I opened a seahorse upstream bug
[09:10] <seb128> and I'm pinging you about compiz ;-)
[09:10] <mvo> seb128: do you know of anything that is equivalent of gdm signal ?
[09:10] <seb128> the compiz upstream might know about that?
[09:10] <mvo> seb128: I want to tell gdm to reboot when I logout
[09:10] <mvo> seb128: I will deal with it after the gdm problem ;)
[09:10] <seb128> mvo: use the dbus api?
[09:10] <mvo> the old gdm speaks that?
[09:10] <mvo> that is excellent
[09:10] <seb128> no
[09:10] <seb128> gnome-session speaks that
[09:10] <seb128> and it uses ck directly nowadays
[09:10] <seb128> no gdm
[09:11] <seb128> that's the complains we get about gnome-session in intrepid
[09:11] <mvo> so g-s logs out and ck knows to reboot instead of returning to gdm?
[09:11] <seb128> it just call reboot or shutdown and doesn't bother about closing the session correctly
[09:11] <mvo> haha
[09:11] <mvo> sounds not quite like what i want then :)
[09:11] <seb128> that's rather ck call reboot
[09:11] <seb128> well, I think that's what you want
[09:11] <seb128> that's what users get when using reboot in gnome-session
[09:11] <mvo> I want session closing first and then reboot .)
[09:12] <seb128> we should fix gnome-session
[09:12] <seb128> right, which is what gnome-session should be doing in any reboot case
[09:12] <seb128> I would rather invest effort making gnome-session do the right thing than workaround to not use it
[09:12] <seb128> since we get the issue when user use the session dialogs
[09:13] <mvo> seb128: right
[09:14] <mvo> seb128: hrm, hrm, the dbus api will be fine for gnome but xfce will stop working (or any other window manager on top of gdm)
[09:15] <mvo> that is really not ideal, I like the current way better in this regard
[09:15] <seb128> hum right
[09:15] <mvo> standardization!
[09:15] <mvo> seb128: but thanks a lot for your help, I will see what I can do
[09:16] <mvo> seb128: and then checkout what compiz is doing, I want to talk to upstream anyway
[09:16] <seb128> mvo: thanks
[09:19] <mvo> just to confirm, gdm-new as man gdm is jaunty+1 ?
[09:19] <mvo> then I can savely switch to dbus because anyone will use it :)
[09:20] <mvo> s/man/main/
[09:20] <seb128> mvo: right, that's the plan, not in jaunty yet anyway for sure
[09:20] <mvo> ok, thanks!
[09:21] <seb128> mvo: depends on good it will work and the new browser thing for jaunty+1
[09:21] <huats> morning everyone
[09:22] <seb128> lut huats
[09:22] <huats> hello seb128
[09:23] <seb128> pitti: I got those errors in .xsession-errors
[09:23] <seb128> "ERROR:dbus.proxies:Introspect error on :1.49:/DeviceDriver: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.48" (uid=1000 pid=7010 comm="/usr/bin/python /usr/bin/jockey-gtk --check 60 ") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination=":1.49" (uid=0 pid=10551 comm="/usr/bin/pyt
[09:23] <seb128> hon /usr/share/jockey/jockey-backend -"))"
[09:24] <pitti> seb128: 15 seconds! wow
[09:24] <pitti> seb128: yes, I'm aware of my share in jockey; I'll fix that next week
[09:24] <seb128> pitti: is that bug #318745 or should I open a new one?
[09:24] <pitti> seb128: that's a curious one
[09:24] <seb128> pitti: do you want a bug for it?
[09:24] <pitti> seb128: yes, it needs to get introspection allowed
[09:25] <pitti> seb128: (sorry, got stuck in SRU stuff)
[09:25] <seb128> pitti: well, as said for login seahorse and compiz trigger timeouts because they don't register correctly that's a good part of the issue
[09:26] <pitti> seb128: I'll fix 318745 ASAP, that's the .xsession-errors issue
[09:26] <seb128> pitti: I also copied over my .gconf directory to limit fragmentation which won some 3 seconds, uninstalled tracker which won some other seconds
[09:26] <seb128> pitti: ok thanks
[09:26] <pitti> 15 seconds *dream* takes 77 for me ATM
[09:26] <pitti> I disabled jockey for a test, that bought me 3
[09:26] <pitti> a lot less than I expected
[09:26] <seb128> 77 is my grub to desktop loaded time on my laptop now
[09:27] <pitti> but I figure if you disable the print applet as well, then you'd get rid of python, and it gets a lot faster
[09:27] <pitti> seb128: do you use an initramfs?
[09:27] <seb128> dunno
[09:27] <pitti> I disabled mine, and grub to gdm is some 40 secs now
[09:27] <seb128> I use whatever jaunty do
[09:27] <pitti> it's still enabled by default
[09:27] <pitti> you have to switch the root= argument from uuid to /dev/sdawhatever
[09:27] <pitti> then you can ditch it (most probably for your laptop)
[09:28] <pitti> jaunty kernel has lots of former modules built in now
[09:28] <seb128> gnome-session starts around 27 seconds on my bootchart
[09:29] <seb128> your laptop has a slow disk
[09:29] <seb128> the main offenders now in session startup on my current chart are 2 python process and jockey
[09:29] <pitti> right
[09:29] <seb128> gnome-panel is doing quite a lot of ios too
[09:29] <pitti> but even with hot cache it takes 28 seconds, shouldn't access the disk much then
[09:30] <seb128> but I don't think we will do anything to this one this cycle
[09:30] <pitti> seb128: is that after fixing the 5-second timeouts?
[09:30] <seb128> pitti: grep timeout .xsession-errors
[09:30] <pitti> x-session-manager[3316]: WARNING: Application 'seahorse-daemon.desktop' failed to register before timeout
[09:30] <pitti> evolution-alarm-notify-Message: Setting timeout for 55602 1233270000 1233214398
[09:30] <pitti> alarevolution-alarm-notify-Message: Setting timeout for 32179 1233246600 1233214421
[09:30] <seb128> pitti: 77 seconds grub to desktop is after uninstalling seahorse for testing, I still have compiz
[09:31] <pitti> right, 77 sec is with compiz for me as well
[09:31] <pitti> but I'm running metacity ATM
[09:31] <seb128> my 77 is grub to desktop
[09:31] <pitti> so if compiz has another timeout, this grep didn't catch it
[09:31] <seb128> right it has
[09:32] <pitti> maybe the composite crash is fixed now; I'll reboot in a bit to boot new kernel, will try it out then
[09:57] <pitti> seb128: yep, compiz works again I now get
[09:57] <pitti> x-session-manager[3328]: WARNING: Application 'gnome-wm.desktop' failed to register before timeout
[09:57] <pitti> as well
[09:57] <seb128> ok
[09:58] <pitti> seb128: do you know why g-s is so insistant on serializing startup?
[09:58] <seb128> pitti: the new gnome-session was designed this way
[09:58] <seb128> starting first gnome-settings-daemon
[09:58] <seb128> then compiz
[09:59] <seb128> then nautilus and gnome-panel
[09:59] <seb128> then everything else
[09:59] <seb128> or roughly something around those lines
[09:59] <seb128> the idea is to have a quick desktop loading
[10:00] <pitti> quick by waiting? :-)
[10:00] <seb128> and not too much flickering
[10:00] <seb128> so you get themes, fonts, etc set first
[10:00] <seb128> then start the basic components
[10:00] <seb128> then everything else
[10:00] <seb128> well if none of the basic component is buggy that works fine
[10:00] <seb128> we just have to make sure g-s-d, seahorse, gnome-panel, nautilus, compiz are not buggy
[10:00] <seb128> then everything else can be started
[10:07] <pitti> okay
[10:07] <pitti> seb128: btw, any luck with the retracers? or shall I look into it?
[10:08] <seb128> pitti: there was no error in the logs that's weird, I delete the log and that seems to be working
[10:08] <seb128> log -> lock
[10:09] <pitti> seb128: anything in /var/mail/ubuntu-archive?
[10:09] <pitti> seb128: btw, if you delete a lock, you should check "ps ux" whether anything is running
[10:09] <seb128> pitti: launchpad error, they took it down for upgrade yesterday though
[10:09] <seb128> pitti: so it could be due to that
[10:09] <pitti> aaah
[10:09] <pitti> I'm fairly sure it's that
[10:10] <pitti> all failed at roughly the same time
[10:10] <pitti> good thing that this is nondestructive now
[10:10] <seb128> pitti: right for checking that no instance is running
[10:10] <pitti> (retagging and all that)
[10:20] <mvo> gnome-session registering ...
[10:26] <tseliot> seb128: https://code.launchpad.net/~albertomilone/gnome-control-center/randr-virtual/+merge/3208
[10:29] <tseliot> this is the link to the C part: http://bazaar.launchpad.net/~albertomilone/gnome-control-center/randr-virtual/annotate/34?file_id=111_add_dontzap_chec-20090128144105-hq323ola4d9u7qpn-1
[10:34] <seb128> tseliot: I read your request yesterday but I prefer to let mvo comment, I didn't have to use policykit yet and I don't know enough about it to review those changes quickly
[10:35] <tseliot> seb128: ok, basically I'm reusing the policykit stuff in screen-resolution-extra which now deals with both the virtual resolution and dontzap
[10:36] <tseliot> seb128: The only relevant changes are in the UI i.e. in the C patch
[10:40] <seb128> tseliot: ok, I'll have a look to that later if mvo is not quicker
[10:40] <tseliot> ok, thanks
[10:41] <mvo> I can have a look too, just doing some compiz stuff
[10:49] <huats> seb128: didrocks just told me that he will spend his day off to improve his mario kart skills instead of packaging... do you think it is serious ?
[10:50] <seb128> huats: isn't he trying to become a motu?
[10:50] <seb128> ;-)
[10:50] <huats> seb128: ;)
[10:50] <huats> (in fact he is home because he is ill...)
[10:51] <seb128> oh ok so in this case he can
[13:09] <mvo> seb128: I have quite frankly no idea why gnome-session is unhappy, from what I can see it does the proper things. I will go and ask upstream about it
[13:11] <seb128> mvo: ok
[13:11] <seb128> vuntz: there? does compiz register correctly to the session on opensuse? did you distro patch something?
[13:12] <vuntz> seb128: don't know, you should ask rodrigo, I guess
[13:12] <seb128> vuntz: do you have a website where I can see the patches you have for each source?
[13:14] <vuntz> seb128: yes, but it requires you to create an account :/
[13:14] <seb128> vuntz: so I get spammed with suse advertissements? no thanks ;-)
[13:14] <vuntz> nah, no spam
[13:15] <seb128> vuntz: there is something in the account page which says that you accept to get mails from suse or novell
[13:15] <vuntz> really?
[13:15] <vuntz> heh
[13:15] <vuntz> that's bad
[13:15] <seb128> or that it's possible that you get mails after subscribing
[13:15] <seb128> that's for a bugzilla account dunno if that's the same there
[13:16] <vuntz> well, it's the same thing
[13:16] <vuntz> if you have an account  for any opensuse thing, then you have an account for everything
[13:17] <seb128> no I didn't due to this email thing
[13:17] <vuntz> seb128: http://tmp.vuntz.net/opensuse-packages/srcpackage.py
[13:17] <seb128> vuntz: https://secure-www.novell.com/selfreg/jsp/createAccount.jsp
[13:17] <seb128> " By completing this form, I am giving Novell and/or Novell's partners permission to contact me regarding Novell products and services."
[13:17] <vuntz> seb128: you can at least see a list of patches for the packages maintained by the gnome team there
[13:18] <seb128> vuntz: thanks
[13:18] <vuntz> seb128: I should probably take more time to finish what I wanted to do and publish the patches too
[13:18] <mvo> hm, compiz is not among them
[13:19] <vuntz> indeed
 yes, we have a few patches, but not sure we patch anything related to the session
[13:19] <seb128> * rodrigo looks
 no, seems we don't
[13:20] <mvo> ok, I try latest git now
[13:22] <seb128> vuntz: how do I get the patches from your vuntz.net summary?
[13:22] <seb128> vuntz: ie http://tmp.vuntz.net/opensuse-packages/srcpackage.py?srcpackage=gnome-session
[13:22] <mvo>   4: gnome-session-gnome-wm-compiz-manager.patch
[13:24] <vuntz> you ping me :-) There's nothing more on this website
[13:24] <vuntz> let me upload it
[13:24] <seb128> thanks
[13:24] <mvo> vuntz: ping :)   4: gnome-session-gnome-wm-compiz-manager.patch please
[13:25] <mvo> and  6: gnome-session-compiz-as-default-wm.patch :)
[13:25] <vuntz> http://tmp.vuntz.net/opensuse-packages/patches/
[13:25] <mvo> thanks
[13:25]  * mvo hugs vuntz
[13:25] <seb128> http://tmp.vuntz.net/opensuse-packages/patches/gnome-session-wm-switch.patch
[13:25] <seb128> ahah!
[13:27] <seb128> not sure that impacts session registration though
[13:27] <mvo> yeah :/
[13:40] <slomo> seb128: hi :) please sync banshee-extension-mirage 0.4.0+r81-1 from debian/experimental :)
[13:54] <vuntz> mvo: do you guys have compiz-manager too?
[13:54]  * vuntz is wondering whether gnome-session-gnome-wm-compiz-manager.patch should be committed upstream
[13:57] <mvo> vuntz: yes
[13:57] <mvo> vuntz: and you use 0.7.8 ?
[13:57] <mvo> eh, no
[13:57] <mvo> you use the nomad branch from davidr
[14:17] <vuntz> mvo, seb128: just added links to http://tmp.vuntz.net/opensuse-packages/srcpackage.py?srcpackage=gnome-session
[14:18] <vuntz> (and others)
[14:18] <vuntz> the mime type is wrong, but at least you can download stuff
[14:18] <seb128> vuntz: thanks!
[14:22] <mvo> thanks vuntz
[14:26] <seb128> vuntz: the change on http://bugzilla.gnome.org/show_bug.cgi?id=544700 seems to make sense no?
[14:26] <pitti> is there something I can call to run a .desktop  file, e. g. in /etc/xdg/autostart/ ?
[14:28] <pitti> ah, nevermind, I can open it in nautilus
[14:31] <vuntz> seb128: the idea makes sense, I think. Need to look at it closer
[14:59] <seb128> vuntz: do you know how session registration works in gnome-session?
[14:59] <seb128> vuntz: could you look at gnome bug #569636
[15:25] <seb128> asac: did you want some extra informations about this xulrunner crash on closing?
[15:26] <seb128> asac: I get apport triggering a zilliion times a day due to it in jaunty
[15:27] <pitti> "ignore crashes of this version" FTW
[15:29] <seb128> pitti: right, still would be better to get xulrunner fixed this cycle, this bug is there since hardy
[15:33] <pitti> seb128: right, just for getting it out of your eyes once you reported it
[15:34] <seb128> right
[15:34] <pitti> seb128: btw, I committed a change to jockey trunk to not start it every time any more (just the first time, i. e. if you don't have /var/cache/jockey/check)
[15:34] <seb128> the annoying part is rather the hang while apport is catching the crash which means you can't reopen it immediatly
[15:34] <seb128> pitti: what do you call first time?
[15:34] <seb128> pitti: what happens if hardware change?
[15:34] <pitti> seb128: if it was never called before
[15:35] <pitti> seb128: you lose, and have to start it manually
[15:35] <seb128> ok
[15:35] <pitti> I still need to find a solution for this
[15:35] <seb128> I guess that's a good trade
[15:35] <pitti> but it should be more dynamic, and not tied to session startup
[15:35] <pitti> I need a kind of "hardware checksum" which is quick to calculate
[15:35] <pitti> lspci | md5sum or something
[15:36] <seb128> I was going to write that ;-)
[15:36]  * pitti puts that into a bug report, for the future
[15:36] <seb128> if the lspci output change slightly between linux versions that's no issue you just get jockey running for the next login
[15:38] <pitti> bug 322776
[15:39] <pitti> seb128: with a new kernel it makes sense to check anyway
[15:45] <asac> seb128: does it go away when disabling a11y ?
[15:46] <seb128> asac: no, I don't have that enable
[15:46] <seb128> that's still this shutdown issue, I got you a valgrind about it some times ago I think
[15:48] <asac> seb128: well. we have a new shutdown issue in firefox ... thats why i am asking.
[15:48] <asac> if you see it a zillion times i would think that its rather that one
[15:49] <asac> then the one you reported month ago
[15:51] <seb128> asac:
[15:52] <seb128> #5  0xb633f69c in nsBaseAppShell::OnProcessNextEvent (this=0xa937d20,
[15:52] <seb128>     thr=0x9f3aba8, mayWait=0, recursionDepth=0) at nsBaseAppShell.cpp:288
[15:52] <seb128> that's where it crash
[15:52] <seb128> #6  0xb63ebd86 in nsThread::ProcessNextEvent (this=0x9f3aba8, mayWait=0,
[15:52] <seb128>     result=0xbf9ff8b8) at nsThread.cpp:497
[15:52] <seb128> etc
[15:52] <seb128> looks similar to the one I'm having since hardy
[15:52] <asac> yes
[15:53] <seb128> anyway if you need debug informations, valgrind log, whatever
[15:53] <seb128> let me know ;-)
[16:11] <asac> seb128: i will get a build on top of a modern xul branch up somewhere ... maybe its gone as there have been substantial fixes on memory management for 1.9.2 and 1.9.1
[16:11] <seb128> ok
[16:11] <asac> the backtrace and the valgrind log didnt have much valid info.
[16:22] <vuntz> seb128, mvo: very crude hack: http://tmp.vuntz.net/opensuse-packages/browse.py
[16:23] <seb128> vuntz: seems to work ;-)
[16:24] <seb128> vuntz: btw did you read my seahorse gnome-session question before?
[16:24] <mvo> seb128: do you have anything pending for gnome-control-center?
[16:24] <mvo> if not, I will upload the changes from tseliot now
[16:24] <seb128> mvo: no
[16:24] <seb128> mvo: wait
[16:24]  * mvo freezes
[16:25] <seb128> just looking if there is something obvious you can fix while you upload ;-)
[16:25] <vuntz> seb128: nope, I was working on that
[16:25] <seb128> vuntz: do you read it in the backlog? I restarted my irc client since
[16:25] <seb128> mvo: you can upload ;-)
[16:27] <vuntz> seb128: replied on the bug
[16:34] <seb128> vuntz: thanks
[17:38] <seb128> vuntz: is seahorse special cased in gnome-session?
[17:39] <seb128> it's started early I'm not sure why
[17:39] <vuntz> seb128: no, it's not
[17:39] <seb128> it is
[17:40] <seb128> oh you mean not special cased
[17:40] <seb128> ah
[17:41] <seb128> that's because it's using initialisation in it's desktop, shouldn't it be application?
[17:41] <seb128> it's started before gnome-panel and nautilus right now
[17:43] <seb128> ok, I've to go, bbl
[17:43] <seb128> really going this time bbl
[20:27] <rickspencer3> asac: ping
[21:03] <chrisccoulson> hey bryce, does bug 314263 only occur for you when you try and open a URL with sudo (like in the duplicate of it)?
[21:03] <bryce> chrisccoulson: never tried it with sudo
[21:04] <chrisccoulson> ah, so it's a slightly different situation
[21:04] <chrisccoulson> the duplicate occurs for people calling gnome-open with sudo, as apport-gtk does
[21:04] <chrisccoulson> and i can recreate that
[21:04] <chrisccoulson> i was going to have a look 2nite and see if i can do some debugging
[21:05] <chrisccoulson> i dont know the code that well so i cant promise anything!
[23:16] <asac> rickspencer3: pong