[00:05] <ubotu> New bug: #217002 in xserver-xorg-video-via (main) "Xserver crashes with VIA chipset" [Undecided,New] https://launchpad.net/bugs/217002
[05:00] <ubotu> New bug: #217092 in linux-restricted-modules-2.6.24 (restricted) "nvidia-glx-new 169.12+2.6.24.500-500.23~envy fails to start" [Undecided,New] https://launchpad.net/bugs/217092
[05:09] <ubotu> New bug: #216667 in xserver-xorg-input-vmmouse (main) "[hardy] USB mouse does not work on PowerPC live cd (20080413)." [Undecided,Confirmed] https://launchpad.net/bugs/216667
[09:56] <james_w> seb128: does http://paste.ubuntu.com/6973/ correctly preserve translations?
[09:57] <seb128> james_w: hum, was it translatable before? it's not between _()
[09:57] <james_w> oh yeah, I didn't notice that.
[09:57] <seb128> james_w: and I would rather use 2 times the same strings rather than introduce a variable, especially than we will be wanting to change one variant next cycle
[09:57] <james_w> ah, ok
[09:58] <james_w> should I mark them translatable?
[09:58] <seb128> yes please
[09:59] <seb128> the string is already in the translations apparently
[09:59] <seb128> that was the one used by the upstream variant
[10:12] <james_w> seb128: any better?
[10:12] <james_w> http://paste.ubuntu.com/6977/
[10:13] <james_w> the rest of the file uses gettext() rather than _()
[10:13] <james_w> I haven't tested the localisation though.
[10:14] <seb128> hum, using gettext
[10:20] <seb128> james_w: seems to be alright
[11:06] <ubotu> New bug: #217182 in xorg (main) "Rotate Screen in TabletPC stylus and pointer mouse not coincidence" [Undecided,New] https://launchpad.net/bugs/217182
[11:39] <ubotu> New bug: #217189 in xserver-xorg-video-intel (main) "Rotating screen does not flip X/Y dimensions" [Undecided,New] https://launchpad.net/bugs/217189
[11:44] <james_w> I'm not very familiar with debugging this type of segfault, if we have
[11:44] <james_w> rw_mode_get_width (mode=0x3) at randrwrap.c:1104
[11:44] <james_w> where mode is a pointer, and then a valgrind with 
[11:44] <james_w> Invalid read of size 4
[11:44] <james_w> Address 0xf is not stack'd, malloc'd or (recently) free'd
[11:45] <james_w> from that function does that indicate that the pointer is being overwritten somewhere
[11:45] <james_w> following the flow of the code I can't see anything wrong in the logic yet
[11:45] <seb128> james_w: that means the code access a non valid memory address
[11:46] <seb128> james_w: usually that's something used after being freed for example
[11:46] <seb128> james_w: or a pointer being overwritten
[11:47] <james_w> ok, it's not obvious to me where this could be happening.
[11:48] <james_w> the stacktrace omits some functions, would this be due to optimisations?
[11:52] <seb128> james_w: yes, likely
[11:55] <seb128> james_w: looking to the code
[11:58] <james_w> there are a bunch of code paths that call that function, so I'm not sure exactly which is being taken to trigger this, I've tried to follow them all, and haven't seen anything yet
[12:00] <seb128> ==11339== Use of uninitialised value of size 4
[12:00] <seb128> ==11339==    at 0x4073179: rw_mode_get_height (randrwrap.c:1118)
[12:00] <seb128> ==11339==    by 0x804D636: rebuild_gui (xrandr-capplet.c:526)
[12:00] <seb128> ==11339==    by 0x804F1AD: run_application (xrandr-capplet.c:1755)
[12:00] <seb128> ==11339==    by 0x804F83B: main (xrandr-capplet.c:1799)
[12:00] <jcristau> gdb doesn't tell you that?
[12:01] <seb128> jcristau: there is a lot of static functions in this source and I think that the -O2 builds don't list those
[12:01] <jcristau> gdb should be able to handle them
[12:01] <seb128> well, -O2 stacktrace are not accurate for sure, I'm not sure to what it's due
[12:02] <ubotu> New bug: #213295 in ubuntu "Shutdown does not take place (dup-of: 118605)" [Undecided,New] https://launchpad.net/bugs/213295
[12:02] <seb128> optimization makes some call being not listed
[12:02] <jcristau> inlining maybe
[12:02] <seb128> could be yes
[12:02] <seb128> james_w: do you get the issue?
[12:03] <james_w> no, I haven't been able to reproduce
[12:04] <ubotu> New bug: #217004 in xorg (main) "[hardy beta] install failure (regression) with ProSavageDDR graphics chipset" [Undecided,New] https://launchpad.net/bugs/217004
[12:05] <seb128> james_w: I'll copy -O0 deb onlines and ask him to get a new valgrind log
[12:06] <james_w> seb128: great, thanks
[12:06] <james_w> a stacktrace may be useful as well
[12:06] <seb128> james_w: 
[12:06] <seb128> list_clone_modes (Configuration *config, RWScreen *screen)
[12:06] <seb128>     RWMode **modes;
[12:07] <seb128>     for (i = 0; config->outputs[i] != NULL; ++i)
[12:07] <seb128>     {
[12:07] <seb128> 	if (config->outputs[i]->connected)
[12:07] <seb128> ...
[12:07] <seb128>     if (!modes)
[12:07] <seb128> 	return NULL;
[12:07] <seb128>  
[12:07] <seb128> and
[12:07] <seb128> ==11339== Conditional jump or move depends on uninitialised value(s)
[12:07] <seb128> ==11339==11339== Conditional jump or move depends on uninitialised value(s)
[12:07] <seb128> ==11339==    at 0x804CF64: get_current_modes (xrandr-capplet.c:336)
[12:07] <seb128> ==11339==    by 0x804D601: rebuild_gui (xrandr-capplet.c:516)
[12:07] <seb128> ==    at 0x804CF64: get_current_modes (xrandr-capplet.c:336)
[12:07] <seb128> ==11339==    by 0x804D601: rebuild_gui (xrandr-capplet.c:516)
[12:07] <seb128>  
[12:07] <seb128> james_w: that seems to indicate that the if condition in the loop is never true and it uses an uninitialised value
[12:07] <seb128> james_w: using 
[12:07] <seb128> - RWMode **modes;
[12:08] <seb128> + RWMode **modes = NULL;
[12:08] <seb128> might be enough
[12:08] <james_w> yeah, that sounds sensible
[12:09] <seb128> l336 is the "if (!modes)" one
[12:09] <tjaalton> (II) SAVAGE(0): Configured Monitor: Using hsync value of 0.00 kHz
[12:09] <tjaalton> (II) SAVAGE(0): Configured Monitor: Using vrefresh value of 0.00 Hz
[12:09] <tjaalton> great
[12:09] <james_w> and that function calls the one at the top of the stacktrace eventually, with an item from the **modes
[12:09] <tjaalton> quality there, no DDC info -> use 0 by default
[12:10] <james_w> seb128: shall I prepare a debdiff of that change for upload, or would you like me to work with submitter first to test it?
[12:10] <seb128> james_w: I've no clue if that's enough to fix the issue of will just forward the bug to some other place, would be nice to get him testing the change
[12:11] <james_w> sure, I can do that.
[12:11] <seb128> thanks
[12:12] <seb128> james_w: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-control-center/+bug/215396 too btw
[12:12] <ubotu> Launchpad bug 215396 in gnome-control-center "gnome-display-properties crashed with SIGSEGV in _start() [when running xgl]" [Medium,New] 
[12:12] <seb128> james_w: could be the same bug
[12:12] <seb128> james_w: did you try to run the capplet under valgrind using xgl?
[12:15] <james_w> no, I didn't
[12:16] <james_w> that one has "on_screen_changed (scr=0x0", which is probably the cause
[12:24] <seb128> right
[13:17] <seb128> james_w: ok, so your packages work but you built using -O0 right?
[13:17] <james_w> yes, noopt,nostrip
[13:18] <seb128> ok, so it doesn't tell us if the fix is enough
[13:18] <seb128> I've asked for a new valgrind log
[13:18] <seb128> noopt will do -O0 and variables will be initialized
[13:18] <seb128> which will hide the non-initialized issues
[13:18] <james_w> ah, ok, shall I build some packages with the patch but normal build options?
[13:19] <seb128> you have other pending changes right? I would say to just upload the patch from this morning and this init now
[13:19] <seb128> or maybe try to fix the other crasher under xgl
[13:20] <james_w> it sounds like he is suffering from an issue that would trigger this, i.e. (config->outputs[i]->connected) is probably never true for him
[13:20] <seb128> right
[13:20] <james_w> yeah, I'll look in to the other one that you pointed me to and see if we can roll in that fix as well.
[13:20] <seb128> cool, thanks
[13:21] <james_w> I don't think I can't reproduce any of these Xgl bugs anymore though unfortunately, it fails so early for me that it barely covers any of the code.
[13:22] <james_w> this other one looks pretty straightforward though.
[13:24] <seb128> right
[14:31] <tjaalton> soren: please push your fix for mdetect, I'll change the vmmouse-handling.. Of course I should've noticed that the damn package doesn't exist for !{amd64,i386} :P
[14:31] <tjaalton> so no wonder those suckers have no mouse
[14:37] <soren> tjaalton: You run mdetect as root, right_
[14:37] <soren> ?
[14:39] <tjaalton> soren: yes, it's done on xserver-xorg.postinst (dexconf)
[14:41] <soren> tjaalton: Great.
[14:44] <tjaalton> hum, xserver-xorg needs to depend on mdetect then
[14:44] <tjaalton> now it only recommends it
[14:58] <tjaalton> soren: do you have mdetect installed by default on your virtual machines? I wonder if Recommends should suffice
[14:58] <soren> tjaalton: I don't.
[14:58] <tjaalton> ok, so it needs to be bumped
[15:02] <tjaalton> soren: what do you think of bug 216276?
[15:02] <ubotu> Launchpad bug 216276 in kvm "Regression: mouse support stopped working" [Undecided,New] https://launchpad.net/bugs/216276
[15:03] <tjaalton> (EE) xf86OpenSerial: No Device specified.
[15:03] <soren> tjaalton: Er, yeah, vmmouse requires a device to be set.
[15:04]  * soren hasn't read the bug, but from the context, I guess that's the issue.
[15:04]  * soren reads the bug
[15:04] <tjaalton> soren: ah, ok.
[15:04] <soren> Well, just /dev/input/mice works fine.
[15:04] <soren> AFAIR.
[15:04] <soren> Is that so bad?
[15:04] <tjaalton> soren: no, if it doesn't change :)
[15:05] <soren> What? The presence of /dev/input/mice? Why would that change?
[15:05] <tjaalton> it shouldnt
[15:06] <tjaalton> anyway, I'll add a check to add the device if it's a virtual setup
[15:06] <soren> Ok, cool. We should check that it works, though, but I belive it does.
[15:07] <soren> tjaalton: Ok. It should be almost functionally equivalent, but if you're more comfortable that way, that's cool.
[15:09] <soren> "almost" because in case we're converting a physical install to a virtual install (something I intend to work on a bit for intrepid), it'll need config changes.
[15:09] <seb128> james_w: how is the update going?
[15:13] <james_w> I'm hainvg trouble tracking this other one down
[15:13] <james_w> the NULL parameter isn't used.
[15:13] <james_w> it also reports that config is NULL, but there is a check for that in the function
[15:13] <seb128> how used?
[15:13] <seb128> hum
[15:14] <seb128> let me have a look
[15:18] <seb128> james_w: on what line is the check?
[15:19] <james_w> 122 here
[15:19] <james_w>     g_return_val_if_fail (current != NULL, NULL);
[15:19] <seb128> no
[15:19] <seb128> your version has not been uploaded
[15:19] <seb128> current is 0ubuntu5
[15:19] <seb128> and it has 
[15:19] <seb128>     current = configuration_new_current (app->screen);
[15:19] <seb128>     if (app->current_configuration)
[15:19] <seb128> 	configuration_free (app->current_configuration);
[15:19] <james_w> current, not config sorry
[15:19] <seb128> 122 is the if line
[15:19] <james_w> ah, did I add that?
[15:20] <seb128> yes
[15:20] <seb128> is there an update pending upload?
[15:20] <seb128> I'm not sure if your debdiff were work on progress or sponsoring request, maybe there was some misunderstanding and something should have been uploaded but has not been yet?
[15:21] <james_w> no, it's fine, I just didn't remember adding that line
[15:21] <seb128> your check is weird
[15:22] <james_w> it's fine, I was just confused about what was uploaded and what wasn't/
[15:22] <seb128> static void
[15:22] <seb128> on_screen_changed 
[15:22] <seb128> if should return
[15:22] <seb128> and not return value, no?
[15:23] <james_w> yeah, I thought it was odd as I was doing it, but didn't think to check.
[15:23] <james_w> I've been in python land for too long.
[15:23] <seb128> ;-)
[15:23] <seb128> ok, anyway
[15:23] <seb128> let's change that one to just return and get the 3 changes uploaded?
[15:24] <james_w> yeah, I'll do that.
[15:24] <seb128> the xgl error dialog, the init we added this morning and this check?
[15:24] <seb128> ok, good, thanks
[15:24] <seb128> we are getting better at each iteration ;-)
[15:24] <james_w> should I disable the help button as well?
[15:25] <james_w> s/disable/remove/
[15:37] <ubotu> New bug: #216276 in xorg (main) "Regression: mouse support stopped working" [Undecided,Fix committed] https://launchpad.net/bugs/216276
[15:38] <seb128> james_w: yes please
[15:50] <seb128> james_w: other requests came my way meanwhile ;-)
[15:52] <seb128> james_w: could you also change 01_debian_ubuntu.patch (you can rename it) to remove the debian specific choices rather, those are confusing for desktop users apparently
[15:53] <seb128> james_w: and the firefox entry in capplets/default-applications/gnome-default-applications.xml.in needs to be updated for use firefox-3.0 as icon name
[15:58] <james_w> sure, any bug numbers you want closing for these changes?
[16:03] <seb128> let me look
[16:03] <seb128> mpt mentionned those on #ubuntu-desktop, not sure if they are in launchpad
[16:05] <james_w> ok
[16:08] <seb128> james_w: no bugs apparently
[16:13] <james_w> seb128: http://paste.ubuntu.com/7005/
[16:13] <james_w> how's that?
[16:19] <seb128> james_w: looking
[16:31] <seb128> james_w: loosk good to me, I'll sponsor the upload, thanks
[16:34] <james_w> thanks
[16:35] <james_w> and huge thanks for actually finding the bugs :-)
[16:36] <seb128> and thank you for working on those ;-)
[17:13] <Q-FUNK> bryce: ?
[17:34] <Q-FUNK> anyone?
[17:34] <Q-FUNK> any news on sync'ing -geode from debian?
[18:14] <bryce> tjaalton: do you really think we should disable atieventsd?  I noticed a lot of bug reports on it crashing.  What does it do exactly?  Just a manager for multi-head or something?
=== keescook is now known as kees
[19:39] <tjaalton> bryce: yep, something to do with multi-head.. and it seems rather unstable
[19:40] <tjaalton> ..if it crashes when updating some libs for example
[19:43] <bryce> hmm, well if it's not strictly required for basic use of fglrx, then I'd also favor disabling it.
[19:44] <bryce> people will be upset at not being able to configure multiscreen, but hey, only so much crashy proprietary software we can reasonably support ;-)
[19:44] <bryce> fwiw, I raised that issue with ATI and am awaiting their feedback on it.
[19:44] <bryce> I will also let them know we plan to disable that tool due to crashes in it
[19:44] <tjaalton> ok cool. it was enabled in December I think
[19:45] <tjaalton> so it's not a regression to turn it off by default
[20:08] <ubotu> New bug: #213753 in xserver-xorg-video-ati (main) "Cannot get normal graphical session running after install" [High,Incomplete] https://launchpad.net/bugs/213753
[20:19] <bryce> tjaalton: btw, any reservations if I push the xserver patch for the firefox XAA offscreenpixmaps issue?  (bug #182038).  Basically it inverts the logic for that option, setting XAAOffscreenPixmaps False by default
[20:19] <ubotu> Launchpad bug 182038 in xorg-server "Black rectangle instead of image in FF3 [Hardy]" [Medium,Confirmed] https://launchpad.net/bugs/182038
[20:21] <tjaalton> bryce: nope, I guess we'll hear if it causes trouble ;)
[20:21] <bryce> (er, True by default??  Anyway, inverts it.)
[20:21] <tjaalton> but as fedora has done the same, it's probably not that bad
[20:41] <bryce> ...uploading...
[21:17] <bryce> ...awaiting approval... ;-)
[22:23] <ubotu> New bug: #217396 in xorg (main) "Hard lockup in X about once a week" [Undecided,Incomplete] https://launchpad.net/bugs/217396
[22:56] <ubotu> New bug: #99898 in linux-restricted-modules-2.6.24 (restricted) "kdevelop make X crash" [Undecided,Confirmed] https://launchpad.net/bugs/99898
[23:12] <ubotu> New bug: #215689 in xorg (main) "Wacom tablet is not supported anymore" [Undecided,Confirmed] https://launchpad.net/bugs/215689