[06:38] <efrem_> hello
[06:39] <efrem_> I can't login anymore... how do I disable compiz?
=== xclaesse is now known as Zdra
[10:34] <seb128> mvo: hey
[10:35] <seb128> mvo: could update-manager call apt in a C locale so the installation bug log would be in english?
[10:35] <seb128> mvo: or would that have sideeffect on some strings displayed to the user somewhere in the gui?
[10:40] <mvo> seb128: that would have the side-effect that all prompts (debconf etc) will be english too
[10:40] <seb128> bah
[10:40] <seb128> did I already say that I hate those update bugs?
[10:40] <seb128> bug #300064 bug #298758
[10:40] <ubottu> Launchpad bug 300064 in gedit "package gedit 2.24.1-0ubuntu1 failed to install/upgrade: sub-processo post-installation script retornou estado de saída de erro 245" [Undecided,New] https://launchpad.net/bugs/300064
[10:40] <ubottu> Launchpad bug 298758 in gedit "package gedit 2.24.0-0ubuntu1 failed to install/upgrade: subprocess new pre-removal script returned error exit status 139" [Undecided,New] https://launchpad.net/bugs/298758
[10:41] <seb128> new example of random upgrade cracks on the wrong component and having not enough informations to be useful
[10:41] <mvo> seb128: I asked the dpkg guys about it if we could have a log hanlder that gives english output but it never went anywhere
[10:41] <mvo> yes
[10:41] <mvo> multiple times
[10:41] <mvo> hm, 245? 139->segfault
[10:41] <seb128> will you be angry if I switch those to user questions rather than bug?
[10:41] <fta2> seb128, i'm done with cairo.
[10:41] <seb128> mvo: I expect those are gconf registration or scrollkeeper update issues
[10:42] <fta2> seb128, it's in my ppa since  yesterday, looks fine to me and noone complained so far. looks good
[10:42] <seb128> fta2: ah, good, could you open a sponsoring bug? I'll sponsor the upload after the jaunty cd today
[10:42] <seb128> fta2: ok, ppa is fine no need to open a bug
[10:42] <fta2> seb128, ok
[10:42] <seb128> you can open one but don't bother if you are busy
[10:42] <mvo> seb128: no, go ahead. I personally thing they are bugs (or incidents) and sometimes have pretty servere consequences for the user. so it would be good to have better means to collect them and figuring out what is happening. but we don't have this currently :/
[10:43] <mvo> I wonder why apport does not pick up the crashes though (if its exit status 139)
[10:43] <seb128> mvo: 139 is a crash for sure?
[10:43] <seb128> mvo: apport doesn't run on stable
[10:43] <seb128> not by default
[10:46] <seb128> mvo_: re, got my comment?
[10:47] <seb128> <seb128> mvo: 139 is a crash for sure?
[10:47] <seb128>  mvo: apport doesn't run on stable
[10:47] <seb128>  not by default
[10:47] <mvo_> sorry, network hates me
[10:47] <mvo_> seb128: exit code 128+signal 11
[10:47] <mvo_>  pretty sure (not 100% but pretty sure)
[10:47] <seb128> ok
[10:47] <seb128> and what is 145 then?
[10:47] <seb128> ups
[10:47] <seb128> 245
[10:48] <mvo_> hm, not sure, give me a sec
[10:50] <mvo_> >>> print os.WIFSIGNALED(245)
[10:50] <mvo_> True
[10:50] <mvo_> >>> print os.WTERMSIG(245)
[10:50] <mvo_> 117
[10:50] <mvo_> ^--- that does not look right
[10:50] <seb128> mvo_: I guess we can't get a sh -x log by default either?
[10:50] <mvo_> I was wondering about that
[10:50] <seb128> or something which tell you what line is crashing?
[10:51] <mvo_> I think it would be a good idea
[10:51] <mvo_> maybe we can start some initiative on it?
[10:51] <seb128> having the command which is crashing or the buggy line would really be useful
[10:51] <mvo_> we could of course just add it to our own scripts ;)
[10:51] <mvo_> agreed, I find that most friustrating too
[10:51] <mvo_> I see there are errors (sometimes bad ones) but there is not enough information what to do about them
[10:52] <seb128> that's what I hate about those bugs, in desktop packages cases they are often whatever standard command which didn't work but we have no information on which one and the users will not get the bug again usully
[10:52] <seb128> those bugs are clearly useful in lot of buggy packages cases
[10:52] <seb128> ie, conflicts, buggy code, etc
[10:52] <mvo_> >>> print os.WCOREDUMP(245)
[10:52] <mvo_> True
[10:52] <seb128> but desktop packages just call the gtk, scrollkeeper, etc updates
[10:53] <seb128> mvo_: what does that true mean exactly?
[10:53] <mvo_> uds topic?
[10:53] <seb128> mvo_: good idea yes
[10:54] <seb128> I'm wondering how easy it would be to detect what is crashing
[10:54] <mvo_> maybe something like "if it looks like a crash, try to collect a crashfile that roughly mathes the timestamp
[10:54] <seb128> apport does know about crashes, it could include in the bug summary whatever crashes happened during the installation timeframe
[10:54] <mvo_> if it crashes, offer the user to re-run the script that crashed with sh -x (*hard*)
[10:54] <seb128> and not working in most case
[10:54] <mvo_> that could in theory make everything worse, but in practise I think it will not
[10:54] <seb128> like those scrollkeeper-update bugs
[10:55] <mvo_> you think the second run will just work?
[10:55] <seb128> they happen often but not enough to get anything useful if you run it again
[10:55] <seb128> I never managed to get one of the crash when I tried to valgrind the command
[10:55] <pitti> seb128: is it possible to build evo against the external libical? (bug 299465)
[10:55] <ubottu> Launchpad bug 299465 in libical "libical main inclusion review" [Undecided,New] https://launchpad.net/bugs/299465
[10:55] <seb128> and I did try quite a lot
[10:55] <mvo_> yeah, I tried as well (in the auto-ugpraer) without results
[10:57]  * mvo_ goes back to weep over the compiz / g-s-s mess
[10:57] <seb128> pitti: that's only code changes ;-) I don't know if they modify libical and how much though and how much they rely on the current version though
[10:57] <seb128> mvo_: good luck and sorry for bothering you about those upgrade bugs again ;-)
[10:57] <mvo_> no problem
[10:57] <mvo_> I think its a serious problem
[10:58] <mvo_> I just don't have a good solution
[10:58] <pitti> seb128: no idea, just asking if there's a configure test for it, and a --with-external-ical or so; I haven't checked if evo bundles it ATM
[10:58] <seb128> pitti: no there isn't
[10:58] <seb128> pitti: they have a copy and no option to use something else
[10:58] <pitti> bah
[11:03] <seb128> pitti: http://bugzilla.gnome.org/show_bug.cgi?id=541209
[11:03] <ubottu> Gnome bug 541209 in libical "Merge libical changes upstream and make it as a external dependency for GNOME modules" [Major,Assigned]
[11:05] <pitti> seb128: :) thanks
[11:06] <seb128> pitti: they suggested it as something to do for GNOME 2.26, ie jaunty on the bug
=== pedro__ is now known as pedro_
[11:06] <seb128> but that has not been worked yet I think
[11:15] <pedro_> pitti: hi!, i'm verifying bug 287689, photos are imported into the import dialog but i'm getting a message saying that the contents of the folders cannot be displayed, however they are, do you get the same there?
[11:15] <ubottu> Launchpad bug 287689 in gthumb "gthumb --import-photos doesn't work in intrepid without intervention" [Undecided,Fix committed] https://launchpad.net/bugs/287689
[11:16] <pedro_> salut seb128
[11:16] <pitti> hey pedro_
[11:16] <pitti> pedro_: no, I don't; does the target folder actually exists?
[11:16] <pitti> pedro_: maybe it was your selection the last time you used gthumb, and now it got moved/removed?
[11:16] <pedro_> yup target is my ~/
[11:16] <pedro_> mm let me try to delete the old preferences
[11:17] <pitti> hm, that *should* exist :)
[12:27] <seb128> pedro_: hello!
[12:53] <seb128> mvo_: could you have a look to bug #300271
[12:53] <ubottu> Launchpad bug 300271 in ubuntu "Setting the network proxy doesn't change the synaptic proxy settings (gnome-network-preferences)" [Undecided,New] https://launchpad.net/bugs/300271
[13:09] <mvo_> seb128: looking
[13:09] <seb128> mvo_: thanks
[13:09] <ember> hey
[15:15] <tedg> seb128, pitti: So I talked to Richard about DevKit-power and GPM.  He's kinda thinking that he would like to have them linked for 2.26.
[15:16] <pitti> tedg: ah, so gpm will fully move away from hal to dk-power?
[15:16] <tedg> It seems like that in general is a good thing, but I'm a little worried about how we should go with packages in Jaunty.
[15:16] <tedg> Should we start with that enabled and then change it if it doesn't make it?
[15:16] <pitti> well, eventually we'll need to package DK and DK-power anyway
[15:16] <seb128> dunno about those, I've read nothing on the topic yet
[15:16] <pitti> I'm more worried about how long we have to run both in parallel, which wastes disk space, memory, etc.
[15:17] <pitti> DK itself should be fairly small
[15:17] <seb128> but I tend to not trust the redhat guys to be on schedule for rewrites
[15:17] <tedg> Well, if you tell GPM to do "dkp mode" it #ifdefs out half the codebase.
[15:17] <pitti> it's more or less just a d-bus interface to udev, so that doesn't worry me too much
[15:17] <seb128> they screwed several of those in the recent cycles
[15:17] <tedg> Well, this one is different.  Basically it's moving a bunch of the GPM code into a lower system level.
[15:17] <pitti> I hope that DK-power is compatible with hal-info
[15:18] <seb128> the lower system being stable yet?
[15:18] <tedg> All of the logging and the intelligence in mapping out the batteries will be in the lower level.
[15:18] <seb128> does the current version bring anything over what we are using?
[15:18] <tedg> Oh, stable is probably a strong word...
[15:18] <tedg> :)
[15:18] <seb128> you are the one working on those but no need to hurry if the switch doesn't bring anything useful
[15:19] <tedg> The big advantage of going this route is that power management becomes less "user based" and more "system based."  So you can have power handled properly for things like GDM.
[15:20] <tedg> Okay, so I'm going to see if I can get everything connected in my PPA and see if there is any "my computer will catch on fire" regressions.  Otherwise, I think it probably makes sense to atleast try dkp for the alphas.
[15:20] <seb128> that's your call
[15:21] <seb128> there is enough to do so there is no need to hurry testing things not ready yet
[15:21] <seb128> but if you think that will be ready to be used in jaunty good to have early testing
[15:22] <pitti> tedg: fun to see PM being something inherently system specific in the old days, then throwing polkit, hal, and dbus at it to  make it user centric, and now back :-P
[15:22] <tedg> pitti: The more things change, the more they stay the same :)
[15:23] <pitti> tedg: in the end we'll decide anyway that nothing beats an 80x25 text VT
[15:24]  * tedg thinks pitti is stuck in the past.  He's on a VT100!
[15:24] <tedg> :)
[15:24] <pitti> hey, 80x25 was a great advancement over the 40x25 I got used to on my C64
[15:25] <tedg> I wish I could double my screen resolution with every upgrade...
[15:29] <dobey> i don't, but a 4x increase would be nice
[15:30] <tedg> I'm willing to upgrade twice ;)
[15:30] <dobey> heh
[15:30] <dobey> i prefer maintaining aspect :)
[15:31] <tedg> What you don't want to support non-square pixels in the icon spec?  That's no fun.
[15:32] <dobey> no
[15:34] <tedg> {theme name}/{size}/{pixel aspect ratio}/{category}/{icon}
[15:34] <dobey> but i don't want to go from 1600x1024 to 3200x1024 for my display resolution
[15:34] <tedg> You have to add another level just because someone could actually use 32x16 icons somewhere else :)
[15:35] <dobey> people do use 32x16 icons :(
[15:36] <tedg> Heh, I honestly haven't seen that.  And no, that isn't a challenge to show me.  I'd prefer not to know. :)
[15:43] <mvo_> tedg: do you have good gnome-screensaver upstream contact? it would be kind of nice to get feedback on https://bugzilla.gnome.org/show_bug.cgi?id=561567
[15:43] <ubottu> Error: Could not parse XML returned by Gnome: timed out (http://bugzilla.gnome.org/xml.cgi?id=561567)
[15:45] <tedg> mvo_: I seem to be having the same problems as ubottu_ ...
[15:45] <mvo_> https://bugs.edge.launchpad.net/ubuntu/+source/compiz-fusion-plugins-main/+bug/247088
[15:45] <ubottu> Launchpad bug 247088 in compiz-fusion-plugins-main "expo allows bypass of screensaver" [High,Confirmed]
[15:45] <seb128> mvo_: you can try to ping him on #gnome-hackers when he's around
[15:46] <seb128> doesn't seem to be the case right now
[17:57] <atrawog> #ubuntu
[20:10] <FMK> hi
[20:11] <FMK> is anyone here?
[21:55] <anthony> Hi, I asked a while back about anti-tremor stuff, and supposedly mousetweaks was going to do that. Does anyone know the current status?