[03:39] <Karger1978> hello
[03:39] <Karger1978> anyone here
[03:39] <jayman> i am
[05:18] <e-uoaphys> is this the gnome/xfce/kde desktop team, or just the gnome team?
[05:18] <Amaranth> e-uoaphys: gnome
[05:18] <Amaranth> seeing how the ubuntu desktop is gnome :)
[05:19] <e-uoaphys> oh
[05:19] <e-uoaphys> there is no kubuntu-desktop chan tho :(
[05:19] <Amaranth> try #kubuntu-devel
[05:19] <Amaranth> the only thing kubuntu has to deal with is the desktop :P
[05:19] <Amaranth> well, almost the only thing
[05:20] <e-uoaphys> right on
[05:20] <e-uoaphys> thx
[07:20] <dholbach> good morning
[07:25] <crevette> hello dholbach
[07:27] <dholbach> hi crevette
[08:08] <ajmitch> hi dholbach
[08:08] <dholbach> hi ajmitch - how are you doing?
[08:08] <ajmitch> good, how are you?
[08:09] <dholbach> good too - thanks
[08:09]  * ajmitch is just here due to hitting an annoying bug after a hardy upgrade :)
[08:09] <dholbach> what happened?
[08:09] <ajmitch> when I login, the desktop background & icons frequently don't appear
[08:10] <dholbach> ugh
[08:10] <ajmitch> I haven't seen anything in ~/.xsession-errors that's useful yet
[08:10] <dholbach> anything in .xsession-errors?
[08:10] <dholbach> hm
[08:10] <ajmitch> just starting up the laptop now to see if it happens again
[08:11] <ajmitch> however, if I start nautilus, then go to gconf-editor & toggle its 'show desktop' off & then on, it'll appear
[08:11] <dholbach> sounds like seb128 will be interested to hear it
[08:11] <ajmitch> haven't filed a bug yet due ot lack of useful info
[08:12] <ajmitch> and of course, it didn't happen this time...
[08:12] <crevette> salut les telepathistes
[08:12]  * ajmitch hates bugs that randomly aren't reproducable
[08:12] <dholbach> hi Zdra, hi cassidy
[08:12] <dholbach> hi crevette
[08:12] <crevette> :)
[08:12] <dholbach> ajmitch: I know what you mean :/
[08:13] <ajmitch> and there he is... :)
[08:13] <crevette> hey
[08:13] <Zdra> hi dholbach
[08:13] <cassidy> morning dholbach
[08:13] <seb128> hello everybody
[08:14] <ajmitch> hi seb128
[08:16] <ajmitch> bah, logout, come back in, and it's working fine still
[08:16] <ajmitch> it's only because I'm trying to reproduce it that it does this to me...
[08:17] <seb128> what bug?
[08:17] <ajmitch> 03:09 < ajmitch> when I login, the desktop background & icons frequently don't appear
[08:18] <ajmitch> 03:11 < ajmitch> however, if I start nautilus, then go to gconf-editor & toggle its 'show desktop' off & then on, it'll appear
[08:18] <ajmitch> trying to get useful info before I file a bug
[08:19] <ajmitch> from a gutsy->hardy upgrade
[08:19] <seb128_> ups, being disconnected
[08:19] <seb128_> what is the bug?
[08:19] <ajmitch> 03:17 < ajmitch> 03:09 < ajmitch> when I login, the desktop background & icons frequently don't appear
[08:19] <ajmitch> 03:17 < ajmitch> 03:11 < ajmitch> however, if I start nautilus, then go to gconf-editor & toggle its 'show desktop' off & then on, it'll appear
[08:19] <ajmitch> 03:18 < ajmitch> trying to get useful info before I file a bug
[08:19] <ajmitch> :)
[08:20] <seb128_> ah
[08:20] <seb128_> is nautilus running when you don't get the icons?
[08:20] <ajmitch> I'm trying to reproduce it now so that I can tell you
[08:21] <ajmitch> but it's misbehaving & giving me a desktop each time, unlike this morning
[08:22] <seb128_> ok
[08:23] <seb128_> slomo_: your fix for the crash at exit thing didn't work
[08:25] <ajmitch> alright, I think I've got it now :)
[08:25]  * ajmitch put the audio cd back in the drive...
[08:26] <ajmitch> and yes, nautilus is running
[08:27] <seb128_> do you get the context menu on the desktop etc?
[08:27] <ajmitch> no
[08:27] <seb128_> can you get a nautilus stracktrace?
[08:27] <ajmitch> no icons, context menu, or desktop wallpaper
[08:27] <seb128_> and do you have anything about nautilus in .xsession-errors,
[08:27] <seb128_> ?
[08:28] <ajmitch> ** (nautilus:13298): WARNING **: Unable to add monitor: Not supported
[08:28] <ajmitch> is the only thing there
[08:28] <seb128_> that's normal
[08:28] <seb128_> hum, k
[08:28] <ajmitch> I figured as much
[08:29] <ajmitch> a stacktrace, although nautilus hasn't crashed?
[08:31] <seb128_> yes
[08:31] <seb128_> just to know if some thread is stucked on something
[08:31] <ajmitch> would you like me to kill -11 the running process then?
[08:32] <seb128_> or attach gdb to it and "thread apply all bt full" and attach that to paste.ubuntu.com
[08:33] <ajmitch> FWIW, nautilus  13298    ajmitch    3u     unix 0xeebe5380            56278 socket
[08:33] <ajmitch> stat64("/home/ajmitch/.recently-used.xbel", {st_mode=S_IFREG|0644, st_size=118622, ...}) = 0
[08:33] <ajmitch> read(3, 0x819489c, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
[08:33] <ajmitch> gettimeofday({1208331188, 315370}, NULL) = 0
[08:33] <ajmitch> poll( <unfinished ...>
[08:33] <ajmitch> constantly trying to read from a socket
[08:33] <seb128_> that is weird
[08:34] <ajmitch> I noticed that the only time it happened this evening was when I put the audio cd back in
[08:34]  * ajmitch took it out because rhythmbox was loading every time I logged in
[08:35] <seb128_> right, known bug
[08:35] <ajmitch> argh, hit the data cap, downloading -dbg packages at 64kbps is painful
[08:44] <ajmitch> I've used apport-cli to put in a bug for now, though it didn't appear to attach anything useful :)
[08:45]  * ajmitch is forced to download at 1% of the usual ADSL speed, so it'll take awhile to get information
[08:49] <seb128> ajmitch: I think there is some other bug about the same issue
[08:49] <ajmitch> oh that's good
[08:49] <seb128> not really
[08:50] <seb128> those are likely incomplete or already closed
[08:50] <ajmitch> good that I may be able to shed some light on someone else's problem then?
[08:50] <seb128> not sure what we can do without a way to trigger the issue, or somebody having the issue debugging the code
[08:50] <seb128> right
[08:50] <seb128> though I'm not sure what information would be useful
[08:51] <ajmitch> knowing what socket it's trying to read may be a help, I guess
[08:51] <ajmitch> if that's related to the issue
[08:52] <seb128> the socket reading is normal I think
[08:52] <seb128> it does that too here
[08:52] <seb128> what is weird is that it's trying to read the recently-used
[08:52] <seb128> does it do that in loop too?
[08:53] <ajmitch> yes
[08:53] <ajmitch> but I'm not sure if that's just normal behaviour, it's not doing stat on it very often
[08:58] <ajmitch> http://paste.ubuntu.com/7178/ isn't useful, is it?
[08:58] <slomo_> seb128: hm? works for me, at least for the crashes i got... are there any current bugreports with backtrace?
[08:58] <seb128> is that the only thread?
[08:58] <seb128> and no, you need libglib2.0-0-dbgsym
[08:58] <slomo_> maybe there's more than one crash
[08:59] <ajmitch> gdb didn't show any more info, and I'm grabbing libglib2.0-0-dbgsym now
[08:59] <seb128> slomo_: I still have the bug on my box, what information do you need?
[08:59] <slomo_> seb128: you have new libgtk2.0-cil and new libgnome2.0-cil? can you reproduce it easily?
[09:00] <seb128> slomo_: yes, I've the current versions and it happens every time I close f-spot or tomboy
[09:00] <slomo_> hm hmm
[09:00] <seb128> dpkg -l libgtk2.0-cil libgnome2.0-cil
[09:00] <seb128> ii  libgnome2.0-cil      2.20.0-2ubuntu2      CLI binding for GNOME 2.20
[09:00] <seb128> ii  libgtk2.0-cil        2.12.0-2ubuntu2      CLI binding for the GTK+ toolkit 2.12
[09:00] <slomo_> let me install f-spot, one moment
[09:00] <slomo_> yes these are the correct versions
[09:02] <seb128> slomo_: what is useful for such crashes? the gdb stracktrace from the interpreter?
[09:03] <slomo_> yes, i can reproduce it with f-spot here
[09:03] <seb128> ok
[09:03] <slomo_> so there's more than one crasher on exit *sigh*
[09:03] <seb128> :-(
[09:03] <slomo_> i'll care for that
[09:04] <seb128> thanks
[09:04] <seb128> do you have any idea about the issue?
[09:04] <slomo_> not yet
[09:04] <seb128> you might want to try tomboy too and see if that's the same bug
[09:04] <slomo_> yes
[09:04] <ajmitch> seb128: new gdb paste at http://paste.ubuntu.com/7179/
[09:05] <seb128> ajmitch: ok, it seems to not be stucked on anything then
[09:05] <slomo_> seb128: looks like the same crash that i fixed
[09:05] <slomo_> seb128: might be that f-spot does stuff different from my test cases
[09:05]  * ajmitch is logging out to see if it'll happen again
[09:06] <ajmitch> or not, I hit logout & it's just not happening...
[09:07] <ajmitch> hm
[09:07] <slomo_> seb128: yeah, problem is that f-spot does "exit()" instead of stopping the main loop first
[09:08] <seb128_> slomo_: ah, so application bug now?
[09:08] <slomo_> seb128: only f-spot and tomboy?
[09:09] <seb128_> slomo_: that I noticed, I'm not using other mono applications
[09:09] <slomo_> seb128: no, the fix in gtk# was not enough... but i see no solution for f-spot's behaviour in gtk#
[09:09] <slomo_> seb128: it's just that libgnome is very unfriendly to bindings :)
[09:09] <seb128_> bug #217091
[09:09] <ubotu> Launchpad bug 217091 in gnome-subtitles "gnome-subtitles.exe crashed on exit (dup-of: 199496)" [Undecided,Invalid] https://launchpad.net/bugs/217091
[09:09] <ubotu> Launchpad bug 199496 in gtk-sharp2 "Tomboy.exe crashed with SIGSEGV in exit()" [High,Fix released] https://launchpad.net/bugs/199496
[09:09] <seb128_> slomo_: that one is about gnome-subtitles
[09:09] <slomo_> is there a pygtk irc channel somewhere?
[09:10] <slomo_> would be nice to know how they handle that
[09:10] <seb128_> #pygtk on gimpnet
[09:10] <slomo_> or maybe no python appliction uses GnomeProgram :)
[09:11] <slomo_> seb128: tomboy does the same as f-spot *sigh*
[09:12] <slomo_> might be possible to fix for those two though
[09:12] <slomo_> yep, f-spot fix is a one-liner
[09:13] <slomo_> seb128: i'll give you a diff, can you care for the upload? i'm busy with other stuff atm
[09:13] <slomo_> seb128: http://pastebin.ca/987149
[09:14] <seb128_> slomo_: ok
[09:14] <seb128_> slomo_: thanks
[09:14] <slomo_> that's not the only place where f-spot does things wrong but should be the only one giving that behaviour
[09:15] <seb128_> bah, pastebin.ca is sloooow
[09:15] <dholbach> paste.ubuntu.com? :)
[09:16] <slomo_> hmm
[09:16] <seb128_> slomo_: the website doesn't want to show your change
[09:16] <slomo_> i might have a better fix
[09:16] <seb128_> ok
[09:17] <slomo_> http://paste.ubuntu.com/7180/
[09:17] <slomo_> that's the old one
[09:17] <seb128_> thanks
[09:18] <seb128_> slomo_: the comment before seems to indicate they didn't use this call for a reason
[09:18] <slomo_> seb128: just the call alone wouldn't exit the application because there are still other threads running, quitting the main loop and exit works in every case
[09:18] <slomo_> (unless something blocks the main loop which would be a bug)
[09:21] <seb128_> ok
[09:21] <slomo_> whatever, i might find a better solution
[09:24] <ajmitch> argh
[09:24] <ajmitch> screen #0: dimensions:    1280x800 pixels (289x21 millimeters) resolution:    112x968 dots per inch
[09:25] <ajmitch> no wonder gdm has 3 inch fonts
[10:14] <mvo> seb128_: have  you seen reports aobut scrollkeeper crashing with double-linked lists failures?
[10:15] <seb128_> mvo: look at the scrollkeeper list of bugs, plenty of those
[10:15] <mvo> I wonder if #218049 might be something like bad memory or so
[10:15]  * mvo nods
[10:15] <YokoZar> ajmitch: it seems like there was a regression in the last gdm update
[10:15] <YokoZar> since that's also when it started being the wrong resolution for me
[10:15] <seb128_> mvo: I've had no luck to trigger the issue or get an error when running it under valgrind though, I tried again some days ago
[10:16] <ajmitch> YokoZar: it's an intel driver thing
[10:16] <ajmitch> bug 107320
[10:16] <ubotu> Launchpad bug 107320 in xorg-server "Large font in the GDM login text field after installing xserver-xorg-video-intel which report monitor having 289x21 millimiters (dup-of: 151311)" [High,Confirmed] https://launchpad.net/bugs/107320
[10:16] <ubotu> Launchpad bug 151311 in xserver-xorg-video-intel "DDC report some ridiculous physical screen size (Mostly on Intel driver, and some ATI)" [High,In progress] https://launchpad.net/bugs/151311
[10:26] <YokoZar> ajmitch: that's odd, I don't have intel video...
[10:27] <YokoZar> Though I do have the package installed
[10:27] <ajmitch> yeah, I misspoke, it's really hardware at fault, and newer drivers believing the dimensions passed to it
[10:27] <mvo> seb128_: ok, thanks
[10:27] <ajmitch> (from what I've read so far about buggy EDID values)
[10:33] <dholbach> mvo, seb128_: shall we change the breaks of evolution-data-server on evolution-scalix to a conflicts for hardy? this will fix upgrades and slangasek just removed evo-scalix from hardy
[10:33] <dholbach> bug 193764
[10:33] <ubotu> Launchpad bug 193764 in evolution-scalix "evolution-scalix FTBFS with current evolution" [High,Fix released] https://launchpad.net/bugs/193764
[10:33] <seb128_> dholbach: why is the breaks not correct?
[10:34] <dholbach> see comment 5 on that bug
[10:34] <dholbach> mvo is the best person to answer
[10:34] <seb128_> ok
[10:35] <seb128_> I've no opinion about that, did you try asking gicmo about fixing the build?
[10:35] <dholbach> seb128_: yes, he was in the bug conversation
[10:35] <seb128_> anyway feel free to do the change but ask mvo, I think there is a replaces which is required too
[10:35] <seb128_> not sure if he still has a pending upload for this one
[10:36] <dholbach> yes, best if mvo does it
[10:37] <dholbach> thanks guys
[10:37] <mvo> dholbach: yes
[10:37] <seb128_> brb, trying gvfs changes
[10:38] <mvo> seb128_: the breaks implementation is not that great in the resolver, its mostly designed around the case when it can upgrade a package, if it can't it easily falls flat on its face
[12:00] <lool> seb128: Will you continue sponsoring the cheese upload?
[12:00] <crevette> hello lool
[12:04] <lool> Hi crevette
[12:14] <pcjc2> Hi, I guess people are busy getting last minute fixes for Hardy... I've prepared a couple of patches (epiphany and nautilus) for some annoying usability issues
[12:14] <seb128> lool: you are welcome to do the upload if you want
[12:14] <seb128> hey pcjc2
[12:14] <pcjc2> I'm not a developer
[12:14] <seb128> pcjc2: what issues do those fix?
[12:15] <pcjc2> Bug #181128 (marked as fix-comitted, but isn't fixed)
[12:15] <ubotu> Launchpad bug 181128 in epiphany-browser "clicking on a link to a document does not open it" [Medium,Fix committed] https://launchpad.net/bugs/181128
[12:15] <pcjc2> The patch backports changes from epiphany's SVN repository, and "works nicely for me"
[12:16] <pcjc2> This requires more thought, but I have a fix which works for me... ﻿bug #217997
[12:16] <ubotu> Launchpad bug 217997 in nautilus "Incorrect icons displayed for mimetypes installed in hicolor theme only" [Undecided,New] https://launchpad.net/bugs/217997
[12:17] <seb128> pcjc2: are you sure all those changes are required? only one of the commit mention the issue
[12:18] <pcjc2> The first one mentions that it is part of the right bug#
[12:18] <pcjc2>  Add a kung fu death grip to keep us alive. Part of bug #513837
[12:18] <seb128> I doubt we will spend efforts now to fix this issue, that's not the default browser and we got only one bug about that
[12:19] <seb128> we will likely update to the new bug fix version in hardy-updates rather
[12:19] <pcjc2> The second (committed right after), adds another, the third is the bugfix. The fourth labeled "Cleanup" was comitted right after, in the same file
[12:19] <pcjc2> that last one might not be necessary
[12:20] <pcjc2> sure, the debdiff is there when it is needed. I just wasn't sure how much extra pain was required for hardy-updates CF. getting the fix in before the release
[12:21] <seb128> it's late now to get changes accepted
[12:21] <seb128> and I don't think this one is worth going through freeze exception, testing, etc
[12:21] <pcjc2> The nautilus bug took a little bit of tracking down, there are various similar, but not quite the same bug reports - mostly relating to incomplete icon themes
[12:21] <seb128> as said it's not the default browser and we got only one bug about it
[12:21] <pcjc2> seb128: I think I agree with you, given that its not default - I forget that, since its always one of the first apps I install
[12:22] <seb128> and I don't think many people use the autoopen thing
[12:22] <seb128> but thanks for your work, we will consider the change
[12:24] <pcjc2> the symptom is that clicking on a .pdf (something I do regularly as an Engineer surfing for datasheets), the pdf downloads somewhere anonymous, probably with a name like 328784.pdf (whatever it was called on RS / Farnell's server), and you get no notification. It used to just open in evince
[12:25] <seb128> right, I understand the bug
[12:25] <seb128> when clicking on a pdf I get the "download or open" dialog
[12:25] <seb128> not sure what option is the default one
[12:25] <pcjc2> in Epiphany?
[12:25] <seb128> anyway as said we will get it to hardy or hardy-updates
[12:25] <seb128> yes
[12:25] <pcjc2> Until applying that patch, I got silence from it!
[12:26] <seb128> that's because you use the preferences option to automatically download and open
[12:26] <pcjc2> After the patch, I got the download or open dialog
[12:26] <pcjc2> Ah - its buried somewhere, I'll look for it, thanks
[12:26] <seb128> it's not, it's on the first tab in the preferences dialog
[12:27]  * pcjc2 hides
[12:28] <pcjc2> it would appear that the patch just makes it show the SaveAs / Open dialog and isn't a full fix then.
[12:29] <seb128> ok, don't bother too much
[12:29] <seb128> upstream said he would roll a new tarball soon to fix issues
[12:29] <seb128> and we will get it in hardy or hardy-updates
[12:30] <pcjc2> thats good to know. I see they dropped Mozillla support in trunk anyway
[12:35] <seb128> pcjc2: can you send the nautilus patch on the upstream mailing list? I'm not sure it's correct, gtk should be doing the right thing there
[12:37] <pcjc2> I sent it already
[12:38] <seb128> ok, I'll read comments there then
[12:38] <seb128> thanks
[12:38] <pcjc2> none-so far, I think the majority of bugs I opened on bugzilla.gnome.org are still unconfirmed ;) (Perhaps that says something about me - not sure!)
[12:39] <seb128> depends of the product, but the nautilus upstream hackers get too many bugs to really read bugzilla
[12:39] <seb128> they reply on the list usually though
[12:39] <pcjc2> ok, perhaps I'll take it up there
[12:40] <seb128> you just say you already did?
[12:40] <pcjc2> maiiling list
[12:40] <pcjc2> http://bugzilla.gnome.org/show_bug.cgi?id=528320
[12:40] <ubotu> Gnome bug 528320 in View as (Icons or List) "Incorrect icons displayed for apps installing icons in hicolor theme" [Normal,Unconfirmed]
[12:40] <seb128> right
[12:41] <pcjc2> sorry, I'm tired... I see you suggested mailing list above, not bugzilla
[12:41] <seb128> I specifically asked if you can send it on the mailing list
[12:41] <seb128> and you said you already did?
[12:41] <pcjc2> I misread, I will do it now
[12:41] <seb128> ok, that's alright
[12:41] <seb128> just send it on the list if you want to get a reply ;-)
[12:42] <kwwii> seb128: I have a fix for the screensaver (the filename was wrong in the desktop file)
[12:52] <seb128> kwwii: url?
[13:02] <kwwii> seb128: http://sinecera.de/human-theme_0.17.dsc
[13:04] <seb128> kwwii: ok
[13:04] <seb128> hey pedro_
[13:04]  * seb128 looks at mvo
[13:04] <seb128> bug #215839
[13:04] <ubotu> Launchpad bug 215839 in python-central "hardy upgrade fails with python-central crash and gedit segfault" [High,Confirmed] https://launchpad.net/bugs/215839
[13:04] <pedro_> hello seb128
[13:04] <seb128> mvo: something in the gedit postinst crash, but there is no gedit specific calls there
[13:09] <seb128> ok, doing some cd testing again
[13:09] <seb128> could somebody sponsor the human-theme update listed before? dholbach? I'll do it otherwise after this round of testing
[13:10] <dholbach> kwwii: are all the changes in bzr already?
[13:15] <kwwii> dholbach: yes
[13:15] <kwwii> all I did was add "-screensaver" to a file name in the dekstop file for the screensaver
[13:16] <dholbach> kwwii: OK, uploaded
[13:16] <dholbach> kwwii: might be sitting in the archive admin's queue now
[13:18]  * mvo looks back at seb128
[13:25] <kwwii> dholbach: cool, thanks
[14:00] <seb128> re
[14:00] <seb128> did anybody do the sponsoring?
[14:01] <seb128> pitti: any opinion on http://bugzilla.gnome.org/show_bug.cgi?id=526308?
[14:01] <ubotu> Gnome bug 526308 in programs "nautilus cannot eject ipod while eject(1) does" [Major,New]
[14:02] <pitti> seb128: icky
[14:02] <pitti> seb128: I think our eject(1) still has the 'unmount all partitions before' patch, which would make that work
[14:03] <seb128> pitti: well, I've opened the bug because I've the issue on hardy, I can't eject my ipod from nautilus
[14:03] <pitti> seb128: I think when I had my father's ipod here, I only ejected from RB
[14:03] <seb128> pitti: the icon is removed but the ipod is still displaying the "do not unplug" screen
[14:04] <seb128> right, from rhythmbox works
[14:04] <pitti> does that make a difference for you?
[14:04] <pitti> ah
[14:04] <seb128> gnome-mount -e /dev/sdn doesn't
[14:04] <pitti> Odd, I had expected RB to use the same call
[14:05] <seb128> lemme check
[14:06] <seb128> pitti: execve("/usr/bin/gnome-eject", ["/usr/bin/gnome-eject", "--hal-udi", "/org/freedesktop/Hal/devices/vol"...], [/* 26 vars */]) = 0
[14:06] <seb128> that's what rhythmbox does
[14:07] <seb128> pitti: execve("/usr/bin/gnome-mount", ["gnome-mount", "-e", "-b", "-d", "/dev/sdc"], [/* 25 vars */]) = 0
[14:07] <pitti> hm, gnome-mount -e just calls eject, too
[14:07] <seb128> that's nautilus
[14:08] <pitti> so RB calls it on a volume, and nautilus on a drive
[14:08] <seb128> right
[14:10] <pitti> seb128: do you get the same when using eject /dev/sdc1 vs. sdc?
[14:11] <seb128> no
[14:11] <seb128> sudo eject /dev/sdc works correctly
[14:12] <seb128> as do sudo eject /dev/sdc<n>
[14:17] <pitti> seb128: can you strace -e execve -f what RB and nautilus call eject with?
[14:17] <seb128> that's what I did before
[14:18] <seb128> ah, eject
[14:18] <seb128> not gnome-mount
[14:18] <seb128> ok
[14:18] <seb128> is gnome-mount calling eject? I though it was using hal for those
[14:19] <pitti> oh, sorry, misread the code
[14:19] <pitti> it's only called if the device is in fstab
[14:19] <seb128> which is not the case
[14:19] <pitti> right
[14:20] <seb128> the fstab parsing code seems broken btw
[14:20] <seb128> strace shows it tries to stat UUID=numbers
[14:20] <seb128> but that's an another issue
[14:21] <pitti> argh, I wish dbus-monitor wouldn't be so terribly useless
[14:21] <pitti> seb128: hal --verbose=yes --daemon=no should display which kind of eject call is done; maybe that gives some enlightenment?
[14:23] <seb128> trying
[14:24] <seb128> brb, I managed to put my system in a state where the ipod is no detected, I hope the database didn't get corrupted because I unplugged it incorrectly after the failed eject
[15:58] <jcastro> seb128: need those desktop topics for openweek rsn!
[15:59] <seb128> jcastro: I'm pondering passing for this one, just too much to do
[15:59] <jcastro> seb128: no one else on the -desktop team?
[16:00] <seb128> well, you asked on the change and nobody stepped so apparently not ;-)
[16:00] <jcastro> heh
[16:38] <mvo> pitti: could you have a quick look at #63450 ? my comment 21? it looks like hal restart fails, I wonder if you have a idea about it
[16:38]  * mvo needs to leave now for ~1h but will read backlog
[16:47] <pitti> mvo: ok, will have a look at it
[17:10] <lool> seb128: Do you recall that pygtk python wakeupfd thing?
[17:10] <lool> http://bugzilla.gnome.org/show_bug.cgi?id=481569
[17:10] <ubotu> Gnome bug 481569 in gtk "Calling gobject.threads_init() causes a lot of wakeups" [Normal,Reopened]
[17:10] <lool> seb128: The patch is now ready, just replace the read(..., 1) with , 0
[17:10] <lool> seb128: What do you think?
[17:14] <seb128> lool: it's late for hardy
[17:15] <seb128> it took us several day to notice the issue previous time
[17:15] <lool> seb128: It's useful to save power though
[17:15] <seb128> rather for hardy-updates
[17:17] <lool> Hmm ok I thought it was safer to have in hardy than in hardy-updates
[17:17] <seb128> there is very few room for hardy now, every change means new CD builds and do the entire test grid again
[17:18] <seb128> maybe ask to slangasek if he's ok to get that between the rc and hardy images
[17:18] <lool> Ok
[17:18] <seb128> uploads go to hardy-proposed, get testing there and are moved to hardy-updates
[17:19] <seb128> so it's usually ok to upload such changes to proposed and to give them enough testing before moving to updates
[17:19] <seb128> we will do that for GNOME 2.22.n updates too
[19:19] <mvo> pitti: thanks for your thoughts on the acpid thing, I have no idea why hald is hanging with it though, so I'm I can not currently sposnor it
[21:44] <seb128_> slomo: did you figure a patch for the crash on closing issue?
[21:45] <slomo> seb128_: not yet, talking with upstream now... the one i gave to you is correct though
[21:46] <bhale> hi slomo
[21:46] <slomo> hi bhale
[22:07] <kwwii> seb128_: have you seen bug #99508
[22:07] <ubotu> Launchpad bug 99508 in compiz "Window titlebar displayed not right with compiz enabled" [Medium,Confirmed] https://launchpad.net/bugs/99508
[22:08] <kwwii> seb128_: it seems there is an easy fix but it seems so simple I wonder
[22:09] <seb128_> kwwii: that's rather a question for amaranth or mvo, I don't really know about compiz
[22:09] <Amaranth> kwwii: please fix it :)
[22:09] <Amaranth> no more <tint> :)
[22:09] <kwwii> seb128_: is it too late to add such a fix?
[22:10] <kwwii> Amaranth: no, it is simpler than that it seems
[22:10] <Amaranth> oh, change that 0 to a 1 for left_width or whatever
[22:10] <seb128_> kwwii: there is some room between rc and hardy for easy changes
[22:10] <kwwii> exactly
[22:10] <seb128_> but that seems a compiz bug, not a theme one
[22:11] <Amaranth> seems to fix it here
[22:11] <Amaranth> seb128_: it's a "wtf is going on here?" bug
[22:12] <kwwii> seb128_: I'll test the change on my system without the error and if it does not change anything radically I can submit it...I was worried about submitting it and then b0rking everyone's system which works now
[22:12] <Amaranth> it seems to be a bad interaction between gtk-window-decorator, libmetacity, and the theme
[22:12] <Amaranth> and no one knows how to fix it anywhere except in the theme
[22:13] <kwwii> lol, the best reason to get a new theme...otherwise I will end up having to support ubuntulooks
[22:14] <kwwii> I'll fix it, but not until tomorrow, just got home tonight, need a few hours of private time :-)
[22:14] <seb128__> re
 but that seems a compiz bug, not a theme one
[22:15] <kwwii> right, but if this fixes it, so be it
 it seems to be a bad interaction between gtk-window-decorator, libmetacity, and the theme
 and no one knows how to fix it anywhere except in the theme
[22:17] <seb128> changing the theme should be no issue
[22:17] <seb128> bug having compiz guys fixing the bug would be better ;-)
[22:19] <Amaranth> if there is an easier way to workaround the problem i have no interest in wasting my time
[22:19] <Amaranth> i could be using that time to read slashdot :P
[22:19] <kwwii> :-)
[22:49] <seb128> slomo: your gnome-user-share update in debian is still not good
[22:49] <seb128> "Syntax error on line 17 of /usr/share/gnome-user-share/dav_user.conf:
[22:49] <seb128> Invalid command 'TypesConfig', perhaps misspelled or defined by a module not included in the server configuration
[22:49] <seb128> spawning httpd failed
[22:49] <seb128> "
[22:50] <seb128> slomo: and you need to clean the old debian specific autostart on upgrade since that's a conffile
[23:27] <mvo> seb128: still here?
[23:27] <seb128> mvo: yes
[23:27] <mvo> seb128: could you please have a look at the last comment in bug #63450 ?
[23:27] <ubotu> Launchpad bug 63450 in acpid "acpid install fails (because of hal running)" [High,In progress] https://launchpad.net/bugs/63450
[23:28] <mvo> looks like something funny with policykit
[23:30] <seb128> mvo: no idea, is that still the old dbus version running? maybe it doesn't support some new format or something
[23:31] <mvo> hm, maybe pitti has a idea about #63450 (last comment)
[23:31] <mvo> seb128: yeah, could be. I wonder if some dependencies needs fixing
[23:31] <seb128> mvo: I think he's away for the night
[23:32] <seb128> mvo: well, the issue is not dependencies if that's the case but dbus needing to be restarted and not reloaded
[23:32] <seb128> but restarting dbus on upgrades is not a good idea usually
[23:32] <seb128> maybe walters has an idea about the warning ;-)
[23:33] <mvo> seb128: ok, yeah - if its the dbus restart problem, then there is nothing we can do and we can not apply the patch as it is
[23:33] <mvo> (nothing we can do for now :)
[23:35] <mvo> seb128: but thanks for your help, I updated the bug, I think I should leave for bed now
[23:35] <seb128> mvo: yeah, me too, you are welcome
[23:36] <pochu> seb128: do you think we will have WebKit in main for Intrepid?
[23:37] <seb128> pochu: depends on what in GNOME is using it, but that's likely yes
[23:37] <pochu> seb128: because Liferea has a WebKit backend for some time, and I'll look at it to see if it's feasible a switch to it
[23:38] <pochu> slomo: ^-- what would you think about that?
[23:39] <seb128> what does it bring over the current version?
[23:39] <walters> launchpad is not responding for me
[23:39] <seb128> walters: weird
[23:40] <seb128> walters: "Error org.freedesktop.DBus.Error.Failed: Element <standard_system_servicedirs> not allowed inside <busconfig> in configuration file^M" is the warning
[23:40] <seb128> rather error
[23:41] <seb128> while reloading the system message bus config
[23:42] <walters> is this on a major distro upgrade?
[23:42] <walters> dist-upgrade?
[23:42] <seb128> yes
[23:42] <seb128> that's a dapper to hardy upgrade
[23:42] <walters> yeah, not much we can do about that...the new config file is on disk, the old daemon doesn't grok it
[23:42] <seb128> oh, no, the error is gutsy to hardy apparently
[23:43] <walters> you guys might want to look at what fedora is doing with preupgrade, it's generally a much more reliable way of upgrading the OS
[23:43] <seb128> ok, that's what I though
[23:44] <seb128> this "doesn't restart dbus" is somewhat annoying
[23:44] <seb128> walters: right, we are not likely to do major changes before hardy now though ;-)
[23:44] <walters> yep, i understand
[23:46] <walters> i'm not sure what the best approach would be; if there is a way to suppress the postinst script on dist-upgrade that might be a workaround
[23:46] <walters> does the daemon die after that?
[23:47] <seb128> well, mvo left now, but reading the bug they try to restart hal apparently and hal hangs after this error
[23:49] <seb128> the easy workaround is to not do the restart in the postinst
[23:50] <seb128> we should probably just recommend people to restart the box after the upgrade to get everything running correctly anyway
[23:50] <walters> hm, new hal may need some feature from the newer dbus
[23:50] <walters> yeah, you've always had to restart anyways though
[23:50] <walters> glibc