[00:26] <mdeslaur> have there been any reports of spurious mouse clicks?
[00:28] <bryce_> mdeslaur, synaptics or evdev?
[00:28] <mdeslaur> evdev...it's a usb mouse
[00:29] <bryce_> I've not seen reports of spurious mouse clicks recently
[00:29] <bryce_> there seem to be none open on my natty list - http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/workqueue-natty.html
[00:30] <mdeslaur> ok, am just wondering if it's my hardware...I'll try another mouse
[00:30] <mdeslaur> thanks bryce_ 
[00:30] <bryce_> there were a couple weird bugs with erratic pointers but those were synaptics-specific
[00:34] <RAOF> And now would be the time for crazy pointer-based bugs.
[00:34] <bryce_> oh yeah, new input stack
[00:34] <bryce_> mdeslaur, just updated today and noticed it for the first time?
[00:35] <mdeslaur> bryce_: I noticed it maybe a day or two ago, after an update
[00:35] <mdeslaur> but, as I said, it maybe hardware
[00:35] <mdeslaur> I just plugged in another mouse, we'll see
[00:36] <bryce_> mdeslaur, ok, then that gets cnd and raof off the hook ;-)
[00:36] <mdeslaur> hehe
[00:36] <mdeslaur> although if it is hardware, I'll be sure to bring the broken mouse to UDS for a practical joke :P
[01:06] <cnd> RAOF, bryce_: changing the tls type to local-dynamic didn't help any...
[01:06] <cnd> so I don't really know what a good resolution is
[01:08] <cnd> and it seems to have just made things worse all around
[01:09] <cnd> RAOF, unless these variables are used in other libs?
[01:11] <RAOF> Does it interact with the split-glapi stuff?  You're testing against natty's mesa, right?
[01:12] <cnd> RAOF, I took natty's mesa package and replaced any occurrences of the initial-exec model with local-dynamic
[01:12] <cnd> rebuilt
[01:12] <cnd> and installed
[01:14] <cnd> it doesn't look like the two headers with the occurrences are installed in any packages
[01:14] <cnd> so they are confined to the library
[01:14] <RAOF> Yeah, that'd be right.
[01:14] <cnd> I'm going to try to make them generic
[01:14] <cnd> just to see if that works
[01:14] <RAOF> Is there any raw asm that's getting used?
[01:16] <cnd> yeah
[01:17] <cnd> do you think that means it might require rebuilding other packages, or that the variables need to be generic since they may be referenced by other libraries?
[01:17] <cnd> I can't imagine the latter, since if you can't find them in a header file you can't access them
[01:18] <RAOF> I'm not sure.
[01:18] <cnd> I should just make a test.c to try to load the libs in different orders
[01:18] <cnd> and see what happens
[01:19]  * RAOF goes to find drepper's tls paper
[01:31] <cnd> RAOF, well, I can't seem to trigger the bug with a simple test case
[01:31] <cnd> and if I can't fix this kind of bug quickly, it moves down my priority list :)
[01:31] <cnd> I gave the libavg devs a two line python workaround
[01:31] <RAOF> Heh.
[01:31] <RAOF> Ok.
[01:31] <cnd> it just loads libstdc++ before anything else :)
[01:31] <RAOF> I'll look into it.
[01:31] <cnd> cheeky
[01:32] <cnd> so it's not a high priority
[01:36] <RAOF> Hey!  Now that I think of it, doesn't libGL *link* to libstdc++?
[01:36] <RAOF> But the dri drivers do.
[01:41] <RAOF> So libstdc++ is *already* being loaded by dlopen after libgl.
[01:43] <cnd> RAOF, does it?
[01:43] <cnd> that seems odd
[01:43] <cnd> to use opengl you have to load all the c++ stuff?
[01:43] <RAOF> Yup.
[01:44] <RAOF> Because the glsl compiler is written in C++, so needs libstdc++
[01:44] <cnd> hmm, then I have no clue :)
[01:44] <RAOF> And the glsl compiler is built into the dri drivers, which are dlopened by the non-C++-using libgl
[01:45] <RAOF> What's the actual problem again? :)
[01:45] <cnd> RAOF, then you're beyond my comprehension now :)
[01:46] <cnd> I just know that libavg dlopens libGL
[01:46] <cnd> and if you don't preload libstdc++, you get a segfault
[01:46] <cnd> and it's claimed that this is due to tls stuff
[01:46] <RAOF> Maybe it's passing incorrect flags to dlopen?
[01:46] <cnd> RTLD_NOW?
[01:47] <cnd> that's all it's passing
[01:47] <RAOF> Let's ask someone who understands the dynamic linker!
[01:47]  * RAOF nominates Colin Watson.
[01:47] <cnd> :)
[01:47] <cnd> good luck finding him at this hour
[01:49] <RAOF> I don't.  I plan to read about TLS circa 2001 and eat toast.
[06:05] <bryce_> humber:~/ubuntu/linux/linux-2.6$ sudo lsinput
[06:05] <bryce_> [sudo] password for bryce: 
[06:05] <bryce_> /dev/input/event0
[06:05] <bryce_> protocol version mismatch (expected 65536, got 65537)
[06:05] <bryce_> wth?
[06:08] <RAOF> Oh, does it need a rebuild again?
[06:08] <bryce_> possibly I just haven't rebooted since updating
[06:09] <bryce_> (although I'm not being prompted to reboot)
[06:09] <RAOF> I think it needs to be rebuilt against newer kernel headers.
[06:10] <bryce_> I'll do a upgrade and reboot and see if it still repros
[06:11] <RAOF> Looks like this might be bug #723944
[06:11] <ubot4> Launchpad bug 723944 in xorg (Ubuntu) "Synaptics touchpad no more working after disribution upgrade (affects: 2) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/723944
[06:38] <RAOF> bryce_: A quick rebuild fixes input-utils.
[06:38] <RAOF> cnd: You wouldn't happen to be awake, would you?
[06:41] <bryce_> we should phone him (tee hee)
[06:42] <RAOF> So, those logs on the bugs don't seem to be particularly informative.
[06:42] <RAOF> Except that the X driver is loading, and thinks it's driving the devices.
[06:44] <bryce_> yeah
[06:45] <bryce_> nothing remarkable in dmesg either
[06:46] <bryce_> RAOF, I'm dist-upgrading 3 laptops now, will try reproducing on each
[06:46] <bryce_> RAOF, have you had luck reproducing it on your hw?
[06:47] <RAOF> Not so far.
[06:47] <RAOF> But I'll upgrade my other laptop and see.
[06:50] <bryce_> the protocol mismatch thingee seems to pre-date the xserver update today
[06:50] <bryce_> kernel bug maybe?
[06:51] <tjaalton> the synaptics-thing?
[06:52]  * bryce_ points tjaalton at #canonical
[06:52] <RAOF> bryce_: That's a regular occurrence - input-utils needs to be kept in sync with the kernel evdev header, and I guess it hasn't had a rebuild recently enough.
[06:52] <bryce_> ok, so that's item #1.  guessing we need a kernel guy to twiddle something?
[06:52] <tjaalton> those spurious mouseclicks.. think I'm seeing those sometimes
[06:52] <bryce_> can we get the same info from proc or sysfs?
[06:52] <tjaalton> with thunderbird. clicking on emails open in new tabs
[06:53] <tjaalton> but not always
[06:53] <RAOF> bryce_: No; we just need a no-change rebuild of input-utils.
[06:53] <bryce_> RAOF, ok
[06:53] <RAOF> And I don't think we can get that info anywhere else; it reads the raw event stream out of the evdev nozzle.
[06:53] <bryce_> RAOF, looks like input device info can be gotten at /proc/bus/input/devices
[06:54] <RAOF> Yeah, that gets some.
[06:55] <RAOF> Hm.  My laptop says “failed to open grail, no gesture support”, and I didn't notice that in any of the other xorg.0.logs
[07:01] <RAOF> Yeah.  All the affected systems seem to have utouch support.
[07:02] <bryce_> interesting
[07:03] <bryce_> yeah I have two laptops using synaptics, neither seems affected
[07:03] <RAOF> What are the buttons reported in Xorg.0.log?
[07:04] <RAOF> My unaffected laptop has “left right”, my other laptop (which I predict will be affected once it's finished upgrading) has “left right double triple”
[07:04] <bryce_> http://paste.ubuntu.com/571563/
[07:05] <RAOF> Ok.  You *also* fail to open grail.
[07:05] <bryce_> http://paste.ubuntu.com/571565/
[07:06] <bryce_> I installed utouch on that second one, still no repro
[07:07] <RAOF> Oh, the driver links to libutouch-grail1; the “failed to open grail” is from the failure of grail_open(device)
[07:08] <bryce_> ok, guess we can call that issue #2.  I take it it's innocuous?
[07:09] <RAOF> I presume it'll happen when the touchpad doesn't support enough for grail to be all gesturiffic.
[07:09] <RAOF> But given that second Xorg.0.log of yours is for a *non* reproducer, it's clearly not the (sole) issue.
[07:10] <RAOF> Although we do apply some quirks to your second Xorg.0.log.
[07:11] <bryce_> second box is a dell mini, I think if that had busted mouse we'd get LOTS of bug reports today
[07:11] <bryce_> third box:  http://paste.ubuntu.com/571566/
[07:12] <bryce_> also verified using synaptics but no repro
[07:14] <RAOF> That one also has a bonus PS/2 mouse :)
[07:14] <bryce_> fwiw that one's in a docking station
[07:15] <bryce_> it's got a touchscreen lvds and a touchscreen external monitor and touchpad
[07:15] <tjaalton> huh, we still have -input-fpit in the archive, provides -input-4 :P
[07:15] <bryce_> but no ps/2 mouse
[07:16] <RAOF> dev/input/event6 would care to differ :)
[07:17] <bryce_> it can think what it wants
[07:18] <bryce_> actually the external touchscreen functionality isn't hooked up
[07:18] <bryce_> but anyway
[07:18] <bryce_> well I'm running out of ideas
[07:18] <bryce_> it seems not to be abi breakage else it would be universally broken
[07:19] <RAOF> Right.
[07:19] <RAOF> I'd like to see the raw event stream from “xinput test”, or at least know that such a stream exists or doesn't.
[07:19] <bryce_> the mouse0 / mouse1 bit seems not particularly unusual (I have that same bit my xorg log)
[07:20] <RAOF> Yeah.  We don't match anything against mouse*
[07:20] <RAOF> It's a symlink to somethnig more interesting, so we'll already have covered it earlier.
[07:20] <bryce_> RAOF, maybe you could forward one or both of those bug reports to peter (and cnd when he comes on)?
[07:20] <RAOF> I shall.
[07:20] <RAOF> Well, peter?
[07:21] <bryce_> hutterer
[07:21] <tjaalton> this isn't upstream, if it's due to the multitouch patches
[07:21] <RAOF> Yeah, I know who you meant, but it's going to be multitouch releated.
[07:21] <bryce_> ok, just thought if he and cnd were in communication about this
[07:22] <tjaalton> daniels and cnd are
[07:22] <bryce_> ahh
[08:36] <tjaalton> hmm pbuilder didn't fail on x11-utils without the old changes, so it should be sync'able
[09:05] <geser> Hello, anyone an idea why my mouse scrollwheel doesn't work anymore in my natty installation?
[09:06] <tjaalton> geser: does xev list any events for it? or evtest?
[09:16] <tjaalton> RAOF: heh, so keithp is asking if removing randr-1.4 from 1.10 would be something people want
[09:17] <RAOF> Well, I guess he could; no one's using it yet.
[09:17] <RAOF> At least, I don't *think* anyone's using it yet :)
[09:17] <tjaalton> it'd revert the abi as well aiui
[09:17] <RAOF> Yeah, it would.
[09:18] <RAOF> But that wasn't an ABI that drivers *needed* to care about IIUC
[09:18] <tjaalton> right, it's just another round of rebuilds :)
[09:18] <geser> tjaalton: no, xev doesn't show any events when I scroll (but pressing the scroll wheel is shown as button 2 as expected)
[09:18] <RAOF> tjaalton: I'm not sure it'd even require a round of rebuilds.
[09:18] <tjaalton> geser: then check if you get events from evtest on the console
[09:19] <tjaalton> lunch->
[09:25] <geser> tjaalton: evtest doesn't list any events either :(
[09:30] <cdbs> Looks like something's broken with the Synaptics touchpad driver
[09:32] <geser> trying out my other mouse (a Logitech Wireless M305) everything works as expected
[09:34] <geser> hmm, re-pluging my mouse seems to work too
[09:38] <tjaalton> geser: so if evtest doesn't show anything it's because of the kernel
[09:39] <RAOF> cdbs: Aha!  You've got a piece of affected hardware?
[09:40] <cdbs> RAOF: yes, its an old Synaptics touchpad that doesn't support multitouch
[09:40] <cdbs> RAOF: Should I post evtest output to bug?
[09:40]  * cdbs got the bug
[09:41] <RAOF> It wouldn't hurt.  Also, working out whether “xinput test” shows events when you do things with the touchpad would be nice.
[09:44] <cdbs> RAOF: My thing doesn't have /dev/input/event7 . It has only upto 5
[09:44] <cdbs> Which one should I use?
[09:44] <tjaalton> xinput list
[09:44] <tjaalton> pick the id for the device
[09:53] <cdbs> RAOF: xinput test doesn't help
[09:54] <cdbs> RAOF: no output, except when I clicked the buttons (which are working fine)
[10:00] <cdbs> okay, I downgraded using the downgrade scrip
[10:00] <cdbs> t
[10:14] <cdbs> Hi, I did downgrade the packages, but after that I got a far less usable system
[10:15] <cdbs> Every application I would open, would crash
[10:15] <cdbs> EVERY
[10:15] <cdbs> from nautilus, to even gnome-terminal
[10:17] <tjaalton> that's not X's fault
[10:19] <cdbs> well, not
[10:19] <cdbs> but that opens up a possibility:
[10:19] <cdbs> Why not just upload a 'revert' package of xserver-xorg-input-synaptic?
[10:20] <cdbs> It appears that these applications and GTK bindings are built against the new ABI, while the downgrade script as given by RAOF takes us back to the old one
[10:20] <tjaalton> lets give cnd a chance to fix it
[10:25] <tjaalton> seb128: there's a new(ish) libgnomekbd (2.30.2), are there plans to update?
[10:26] <seb128> tjaalton, we are on 2.32 which is a newer serie
[10:26] <seb128> tjaalton, or do you mean a sru for some stable version?
[10:26] <seb128> tjaalton, 2.30 is used in lucid
[10:26] <tjaalton> seb128: there's 2.30.2 in debian
[10:26] <seb128> but it has 2.30.2?
[10:26] <seb128> tjaalton, well lucid has that
[10:26] <tjaalton> grah, sorry
[10:26] <seb128> tjaalton, natty has 2.32
[10:26] <tjaalton> mixed up the versions
[10:27] <tjaalton> debian has 2.30.2, we have 2.32.0 :)
[10:27] <seb128> right
[10:27] <seb128> just curious how did you run into that?
[10:27] <seb128> is there any bug in natty?
[10:27] <tjaalton> no, it's just listed on the versions_current.html list
[10:27] <tjaalton> dunno why
[10:27] <tjaalton> since it's not maintained by the x team
[11:07] <tjaalton> hm, -fpit is still maintained upstream it seems..
[11:07] <tjaalton> for abi changes at least
[11:15] <tjaalton> and it seems to still have users..
[13:08] <cnd> RAOF, if you're still up, I'm now up too :)
[13:08] <cnd> I read the backscroll here and in ubuntu-devel
[13:08] <cnd> taking a look at the bug now
[13:24] <cnd> if I had to guess, it looks like grail is opening on non-multitouch hardware and this is throwing things off
[14:53] <soreau> Hey guys I have a reproduceable crash I want to get a bt from and I install debug packages but gdb tells that /usr/bin/X has no debugging symbols
[14:54] <soreau> What is the problem?
[14:56] <jcristau> soreau: the real binary is /usr/bin/Xorg
[14:56] <soreau> Well &%*
[15:00] <cnd> soreau, it's not a big problem
[15:00] <cnd> do you have a core dump?
[15:01] <cnd> or are you wanting to attach to X?
[15:01] <soreau> Yes I got the dump now 
[15:01] <soreau> thanks jcristau 
[15:01] <cnd> ok
[15:01] <cnd> soreau, by any chance are you using multitouch hardware?
[15:02] <cnd> :)
[15:02] <soreau> nope
[15:02] <soreau> It happens when trying to vncviewer into the machine
[15:02] <soreau> It worked until a couple weeks ago
[15:02] <cnd> ok, cool
[15:02] <cnd> not my problem :)
[15:03] <jcristau> fdo#30032 is a crash when using x11vnc, could be the same thing?
[15:09] <cnd> tjaalton: got a few mins to upload a fix for the synaptics issue?
[15:11] <cnd> or bryce_, if you happen to be up already
[15:33] <tjaalton> cnd: i'm at the hw store, back home in 30min
[15:33] <tjaalton> comp hw :)
[15:33] <cnd> tjaalton: ok, thanks!
[16:00] <bigon_> any idea what's going on https://bugs.launchpad.net/bugs/714280 (my last messages)
[16:00] <ubot4> Launchpad bug 714280 in xorg-server (Ubuntu) (and 3 other projects) "The error was 'BadLength (poly request too large or internal Xlib length erro'. (affects: 5) (dups: 1) (heat: 233)" [High,Confirmed]
[16:03] <jcristau> what's going on is you're mixing different bugs.
[16:05] <bigon> my 2 last messages are still refering to BadLength (poly request too large or internal Xlib length error)
[16:05] <jcristau> for a different request
[16:05] <jcristau> changedrawableattributes is fixed in 4324d6fdfbba17e66b476cf008713d26cac83ad1
[16:06] <bigon> should I open a different bug for this one?
[16:06] <jcristau> dunno
[16:06] <jcristau> you could just upgrade your X server
[16:06] <jcristau> or your mesa.
[16:07] <bigon> both machine are uptodate (with natty)
[16:07] <jcristau> then natty doesn't yet have the fixes
[16:07] <bigon> indeed
[16:08] <jcristau> so upgrade your X server or mesa, or live with the bug until natty bumps either of them.
[16:10] <jcristau> actually, natty's X server has that fixed.
[16:12] <tjaalton> cnd: ok, finally home
[16:13] <cnd> tjaalton, great
[16:13] <cnd> tjaalton, I suppose you'll probably want a source package
[16:13] <cnd> didn't think to create one...
[16:13] <tjaalton> cnd: yep
[16:13] <tjaalton> heh
[16:13] <cnd> I'll do that right now
[16:21] <tjaalton> cnd: I'll have dinner in the meantime
[16:21] <tjaalton> won't take long
[16:21] <cnd> tjaalton: I just uploaded
[16:21] <cnd> ok
[16:21] <tjaalton> oh
[16:21] <tjaalton> where?
[16:21] <cnd> it's at people.canonical.com/~cndougla/utouch/
[16:22] <tjaalton> Checksum doesn't match for /tmp/people.canonical.com/~cndougla/utouch/utouch-frame_1.1.1-0ubuntu1.debian.tar.gz
[16:22] <cnd> hmm...
[16:23] <cnd> that's odd
[16:23] <cnd> I'll try to reupload it
[16:24] <cnd> tjaalton, try once mre
[16:24] <cnd> if that doesn't work, I'll try things locally to figure out what's wrong
[16:24] <tjaalton> still the same
[16:24] <cnd> hmmm
[16:24] <cnd> ok
[16:24] <tjaalton> 4cf85322570b8ad7ce800212c582e655
[16:25] <tjaalton> is the md5sum
[16:25] <tjaalton> when source.changes says it should be e113aa341f8e3b4e784fdf374f4d1c02
[16:25] <cnd> ummm... my version locally doesn't match either!
[16:25] <cnd> https://wiki.ubuntu.com/ChaseDouglas/DeveloperApplication-uTouch
[16:25] <cnd> oops
[16:25] <cnd> dc9a4f63e84871a89984b1fd839d9236
[16:26] <tjaalton> that's the tarball
[16:26] <cnd> oh, I was looking at the wrong file
[16:27] <cnd> I'll recreate the source package and see what's wrong
[16:27] <cnd> I did a test build after the source package build
[16:27] <cnd> maybe the test build overwrote it
[16:27] <tjaalton> could be
[16:28] <tjaalton> i'll eat now :)
[16:29] <cnd> ok, it's reuploaded when you are ready
[16:34] <tjaalton> cnd: yep, didn't complain this time
[16:35] <cnd> great
[16:44] <bigon> jcristau: I will open an other bug I've 1.10 rc2 installed and still have the issue X_GLXChangeDrawableAttributes request
[16:56] <jcristau> installed or running?
[17:27] <cnd> bryce_, RAOF, tjaalton: I'm applying for package upload rights for the utouch packages
[17:27] <cnd> if you'd like to sponsor me, please do so at https://wiki.ubuntu.com/ChaseDouglas/DeveloperApplication-uTouch
[17:27] <cnd> thanks!
[17:32] <bigon> 17:56 < jcristau> installed or running? << running I've rebooted to be sure
[18:06] <bryce_> morning
[18:06] <bryce_> synaptics issue get sorted out?
[18:11] <cnd> bryce_, we think so
[18:11] <cnd> new utouch-frame should fix it
[18:12] <cnd> the package should be synced to the mirrors by now I believe
[18:13] <cnd> it is for amd64 at least
[18:13] <cnd> it affected multi-finger, non-mt trackpads :)
[18:15] <bryce_> cnd, excellent
[18:16] <cnd> bryce_, in case you didn't see above, I'm trolling for package upload rights sponsors
[18:16] <cnd> so we can fix these issues faster :)
[18:16] <cnd> we waited around for about an hour before tjaalton became available
[18:16] <cnd> and didrocks is our normal uploader, but he's swamped
[18:17] <bryce_> cnd, right!  hitting the page now
[18:17] <cnd> bryce_, thanks!
[18:18] <tjaalton> i'll add my comments after bryce :)
[18:18] <cnd> cool
[18:22] <Sarvatt> hmmm, so I can reproduce this on my netbook by just attempting to "install ubuntu" https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/714829
[18:22] <ubot4> Launchpad bug 714829 in xserver-xorg-video-intel (Ubuntu) "Xorg segfaults during LiveCD installation using preseed file (affects: 1) (heat: 201)" [High,Incomplete]
[18:22] <Sarvatt> only, X never crashes
[18:23] <tjaalton> nice
[18:23] <Sarvatt> i get tons of the [ 194.542] (WW) intel(0): intel_uxa_prepare_access: bo map failed: Cannot allocate memory though and X is still alive and kicking but unresponsive
[18:23] <tjaalton> can you get to the machine somehow?
[18:24] <Sarvatt> yeah i'm using it now
[18:24] <Sarvatt> gem objects look fine http://sarvatt.com/downloads/i915_gem_objects.txt
[18:24] <tjaalton> hmm I bought an ssd, could pyt it in my x61
[18:24] <tjaalton> put even
[18:25] <Sarvatt> dont have to actually wipe anything even, just booting the livecd, going to install ubuntu then hitting next kills things
[18:25] <tjaalton> hm ok
[18:27] <tjaalton> so something is eating the memory, and it's not x/intel
[18:27] <Sarvatt> its right when it'd be starting up partman to do all the disk partitioning that things die
[18:28] <tjaalton> hm, have you checked it's logs?
[18:28] <Sarvatt> i cant even see the panel at the top in unity on a 1024x600 screen
[18:30] <Sarvatt> now i'm getting some aufs error spam, aufs au_new_inode:412:dbus-launch[2578]: Warning: Un-notified UDBA or repeatedly renamed dir, b0, tmpfs, ubuntu, hi1965, i273.
[18:31] <Sarvatt> oh got a crash that time, went to VT immediately after hitting install ubuntu
[18:33] <Sarvatt> try ubuntu is fine, looks like installing it from inside the live session works fine too..
[18:34] <Sarvatt> better let it finish before I say that I guess :)
[18:43] <soreau> I have an Xorg crash http://pastebin.com/Etjjzue8 when trying to vncviewer into it from another machine :)
[18:54] <cnd> bryce_, btw, I'm going to ask at the DMB meeting for motu rights too, so we'll see
[18:54] <cnd> thanks for the endorsement :)
[19:03] <bryce_> cnd, yep, good luck!
[19:08] <cnd> bryce_, because I'm not sure the best route for me, I asked cody on the dmb
[19:08] <cnd> he said he'd be happy to review an application of mine before going to the dmb for core dev rights
[19:08] <cnd> I just don't want to waste the dmb time
[19:08] <cnd> their meetings get long and slow enough as it is
[19:09] <cnd> so I'm going to create a new application page for core dev
[19:09] <cnd> and ask for some endorsements
[19:12] <bryce_> cnd, sounds good
[19:13] <bryce_> cnd, yeah it would not be a bad idea to shoot for utouch rights in the coming meeting, then apply for motu the meeting after that, and core dev the one after that, in sequence
[19:13] <cnd> something like that
[19:13] <bryce_> cnd, however you do it, you got my endorsement :-)
[19:14] <cnd> heh
[19:14] <bryce_> Sarvatt, aha you have a lead on our elusive memory leak bug
[19:15] <Sarvatt> bryce_: i'm drawing up blanks on why this is happening only when "install ubuntu" is picked, installing from inside "try ubuntu" just hangs before the disk partitioning tool comes up but X is still here and i'm still able to quit the install fine even
[19:15] <bryce_> Sarvatt, yeah we've suspected it was something like the installer.  I've seen the bug reports only against use in the livecd environment
[19:15] <bryce_> Sarvatt, have you found a way to view memory usage that shows what process is gobbling mem?
[19:16] <Sarvatt> nothing is using an abnormally large amount of memory
[19:16] <bryce_> Sarvatt, i.e. does top, cat /proc/meminfo, xrestop, or the like show something?
[19:16] <bryce_> I've also wondered if it might be just video memory getting exhausted
[19:17] <bryce_> but I don't know if we have a tool for measuring that... is it shown in one of the gem files in sysfs?
[19:17] <Sarvatt> was playing around in the try ubuntu option there, rebooting into install ubuntu to see
[19:17] <Sarvatt> it looks fine http://sarvatt.com/downloads/i915_gem_objects.txt
[19:17] <Sarvatt> (thats from right before an X crash while it was spamming the bo map failed errors)
[19:18] <bryce_> I wonder if the Install Ubuntu functionality can be run independently of the livecd
[19:18] <Sarvatt> i can't see the menu bar on the selection screen where you pick try or install either, its above the screen so the window will fit
[19:19] <Sarvatt> yeah trying to figure out how the heck to do just that at the moment
[19:19] <bryce_> Sarvatt, have you talked with evand or cjwatson yet?
[19:20] <bryce_> if not, maybe we should spin them up, they might have some suggestions that'd save us some time
[19:24] <bryce_> I'll poke through their bug tracker and then see if I can grab evan
[19:26] <bryce_> fwiw, on radeon since updating to latest stuff yesterday I've been noticing with popup menus that sometimes in the fraction of a second before the menu is displayed where what I suppose is supposed to be a black rectangle, I catch a momentary glimpse of what looks like uninitialized video memory
[19:26] <cnd> bryce_, I have copied my utouch endorsement to my coredev application: https://wiki.ubuntu.com/ChaseDouglas/DeveloperApplication-CoreDev
[19:26] <cnd> it has some utouch rights specific phrasing
[19:27] <cnd> would you like to edit it, or do you want me to fix it up for you?
[19:27] <bryce_> but it only displays for a few milliseconds so can't see it properly, and seems hard to reproduce on demand
[19:27] <bryce_> cnd, I can edit it up, thanks
[19:28] <cnd> ok
[19:33] <bryce_> done
[19:48] <bryce_> Sarvatt, ok I pinged ev on #ubuntu-devel.  guessing he's EOD'd
[19:48] <bryce_> Sarvatt, gave him a rundown maybe he can help
[19:53] <bryce_> Sarvatt, hrm, finding nothing interesting amongst the ubiquity bug reports
[19:55] <bryce_> Sarvatt, reviewing our own bug report history with this issue, the first report (from mario) was Jan 19th, so I would guess the issue first entered the archive around Jan 17/18
[19:55] <bryce_> ubiquity 2.5.6 is dated Jan 17 
[20:07] <cnd> bryce_, RAOF, btw, I forgot to mention that I had been planning to fix up lsinput
[20:07] <cnd> in fact, I think I'll sit down right now to do so :)
[20:14] <Sarvatt> bryce_: apparently just sitting on the welcome screen is enough to trigger the bo map failed errors
[20:16]  * Sarvatt is going to try reverting this force background redrawing commit from jan 17th
[20:17] <bryce_> Sarvatt, quite unexpectedly just following random hunches I found some leaky C code
[20:18] <bryce_> Sarvatt, going on the assumption that it was ubiquity, and that it must have happened shortly before feb 19th, I looked at the diff
[20:18] <bryce_> ubiquity 2.5.6 is a huge diff but 99.9% is just python and translations stuff
[20:18] <bryce_> however there is one change to one C file
[20:18] <bryce_> and wouldn't you know it, that change involves adding a pointer, strduping to it, and there is no matching free
[20:19] <bryce_> it's in d-i/source/netcfg/netcfg-common.c routine netcfg_write_common
[20:22] <bryce_> Sarvatt, anyway I can do up a patch at this point.  need food first
[20:22] <bryce_> I'm 70% certain this could be our culprit.
[20:23] <bryce_> no idea how we'd test it though
[20:26] <Sarvatt> bryce_: awesome
[20:54] <cnd> is it just me, or are all lp related functions really slow today?
[21:10] <bryce_> I've had a few timeouts but nothing out of the ordinary
[21:11] <Sarvatt> bryce_: so uh.. http://sarvatt.com/downloads/patches/wtf.diff has lasted 10 minutes on the welcome screen with no bo map errors
[21:12] <Sarvatt> bryce_: 204 seconds was my record before
[21:12] <bryce_> Sarvatt, aha, where'd you find that?
[21:12] <Sarvatt> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/ubiquity/natty/revision/380#src/panel/panel.c
[21:14] <Sarvatt> something tells me it might have been queuing a redraw way more often than they wanted? :D going to attempt an install now and see what happens
[21:14] <bryce_> ok
[21:15] <Sarvatt> of course it wont go past the preparing to install screen because partman wont load up but still not crashing
[21:17] <bryce_> rev 380 was on 2011-01-14
[21:17] <Sarvatt> bryce_:  you should be able to reproduce this by just loading a liveusb on your dell mini and sitting at the welcome screen for a minute or two
[21:18] <Sarvatt> can switch straight over to a vt and watch Xorg.0.log
[21:18] <bryce_> patch looks like it goes with https://bugs.launchpad.net/ubuntu/+bug/693300
[21:18] <ubot4> Launchpad bug 693300 in ubiquity (Ubuntu) "Top white bar in oem-config (ubiquity) when choosing CJK. (affects: 1) (heat: 64)" [Undecided,Fix released]
[21:18] <bryce_> ok lemme give that a go
[21:18] <bdmurray> bryce_: the package hook for X uses compiz-0.9.2 while I've been tagging everything just compiz-0.9 or compiz-0.8 - I think it'd be best if we stuck with the same convention
[21:22] <bryce_> bdmurray, want to send a patch?  I'm aware of the problem but have a lot of stuff higher up in priority on my todo list at the moment
[21:23] <bryce_> bdmurray, there is code that is supposed to split the string and extract just the 0.9 there, which worked when I tested, but there must be a bug in the logic
[21:23] <bdmurray> bryce_: just a patch? no bzr branch or debdiff or other magic? ;-)
[21:23] <bryce_> just a patch would be fine
[21:24] <bdmurray> cool, I can do that
[21:26] <Sarvatt> bryce_: fixed up debs are here in case you use persistent storage and want to see if it fixes it for you too, just need these 3 http://sarvatt.com/downloads/ubiquity/
[21:26] <Sarvatt> bryce_: this really looks to have fixed it here
[21:29] <bryce_> Sarvatt, ok, still 15 min or so left on my iso download
[21:33] <bdmurray> bryce_: I also added a patch to bug 723624
[21:33] <ubot4> Launchpad bug 723624 in xserver-xorg-video-intel (Ubuntu Natty) (and 1 other project) "apport-gpu-error-intel.py keep crashing after login (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/723624
[21:35] <bryce_> bdmurray, excellent, thanks
[21:36] <bryce_> that's another I was wondering about, I'll get those fixes in today
[21:47] <RAOF> cnd: Rocking.  Thanks for fixing that.
[21:47] <cnd> RAOF, sure, np!
[21:47] <cnd> RAOF, in return, please consider endorsing my applications for upload rights :)
[21:48] <RAOF> Certainly!
[21:48] <RAOF> Does the bug have an analysis of the situation, so I can be more informed for future breakage?
[21:49] <cnd> RAOF, the bug is basically: our stack just doesn't work for multi-finger, non-mt devices
[21:49] <cnd> but we let them through anyways
[21:49] <cnd> so our "fix" for now is to not let them through
[21:49] <cnd> RAOF, bryce_: however, you may find some helpful debugging stuff in there for the future
[21:49] <cnd> the use of evemu for recording and replaying devices
[21:49] <RAOF> And this manifested by grail eating all the events and not posting any to the X queue?
[21:50] <cnd> RAOF, something like that
[21:50] <cnd> I haven't actually worked on the underlying bug
[21:51] <RAOF> Heh.  'sok.
[21:52] <bryce_> cnd, looks like there was a .deb posted, it would be educational to have the patches attached (or branches linked to, or commit ids) so those of us curious could follow along at home :-)
[21:53] <cnd> bryce_, branches are linked
[21:53] <bryce_> ah, didn't notice
[21:53] <cnd> both upstream and packaging
[21:53] <cnd> :)
[21:54] <bryce_> cnd, one thing we could think about, if some of those debugging tools/output are going to be always worth having with -evdev reports, or utouch, or whatnot, then we should create an apport hook
[21:54] <bryce_> otoh maybe we'll never have more than a handful of bug reports so won't be worth the bother?  ;-)
[21:54] <cnd> bryce_, I've thought about making it part of the standard bug template
[21:54] <cnd> but not about apport hook...
[21:54] <cnd> that's an interesting idea
[21:54] <bryce_> bug template?
[21:55] <cnd> one that would require a bit of dev work
[21:55] <cnd> bryce_, isn't there something that you can set on each project/package to request certain info when you file a bug?
[21:55] <cnd> I don't know if it works when you run ubuntubug
[21:55] <bryce_> anyway, we got apport skillz in surplus we can throw at it if it seems like it'd help
[21:55] <cnd> heh
[21:55] <bryce_> cnd, yeah not really a template but some boilerplate text
[21:56] <cnd> bryce_, that's probably what I'm thinking of
[21:56] <bryce_> I don't know how well read that info is; seems kind of hit or miss whether users follow it
[21:56] <cnd> I think it would need to be something that would prompt for a the device that is causing issues
[21:56] <bryce_> at least for X...
[21:56] <cnd> and then record for that device
[21:56] <cnd> heh
[21:56] <bryce_> apport scripts can pop up dialogs to prompt for user selection
[21:57] <cnd> yeah
[21:57] <bryce_> cnd, in fact it can even walk them through, like "Okay, now click the button three times and wiggle the mouse..." (sleep 10) "... ok thanks"
[21:57] <cnd> yeah, that sounds good
[21:59] <cnd> bryce_, so what do I need to do to make this happen?
[21:59] <bdmurray> bryce_: bug 724598
[21:59] <ubot4> Launchpad bug 724598 in xorg (Ubuntu) "apport package hook is too verbose with compiz version (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/724598
[21:59] <cnd> assuming I don't have the bandwidth to do it myself
[22:00] <cnd> I would like to do it of course, but I have too many things on my plate already...
[22:00] <bryce_> cnd, well, for starters lets keep it simple, can you just make like a list of commands that would gather useful files?
[22:00] <bryce_> from that, I think I can craft a basic apport hook once I've dug myself out from under my current set of tasks
[22:01] <cnd> I can give that to you right now: lsinput to get a list of devices, and evemu-tools to record the one the user picks
[22:01] <bryce_> fancy interactive bits can be done later as needed
[22:01] <cnd> though lsinput doesn't work yet in natty
[22:01] <cnd> I'm trying to get to that line on my todo list :)
[22:02] <RAOF> bryce_ could just dch --rebuild "Rebuild against new kernel" and upload.
[22:02] <cnd> RAOF, no, it needs to be fixed proper style
[22:02] <cnd> I just need to get the package
[22:02] <cnd> sync to the latest upstream
[22:02] <RAOF> Oh, there's a proper style?  Ok :)
[22:02] <cnd> upstream has fixed the issue once and for all :)
[22:03] <cnd> and then I should push it to debian
[22:03] <RAOF> Hurray!
[22:03] <cnd> and sync it to ubuntu
[22:03] <cnd> my biggest problem was not being able to reach lp for an hour or so...
[22:25] <Sarvatt> hrm, where wer tseliot's nvidia/fglrx packaging git trees at?
[22:26] <bjsnider> http://github.com/tseliot/nvidia-graphics-drivers
[22:26] <Sarvatt> sweet, thanks
[22:28] <bjsnider> it's in the control files
[22:30] <cnd> Sarvatt, that sounds like good news :)
[22:30] <Sarvatt> ;)
[23:13] <Sarvatt> RAOF: unity's broken? why do I have to read you say that right after I upgrade? :D
[23:14] <RAOF> Sarvatt: If the upgrade didn't offer to remove unity, maybe it's fixed? :)
[23:14] <Sarvatt> oh yeah must be
[23:14] <Sarvatt> it was just the compiz plugin rename that took an apt-get -f install to fix
[23:15] <RAOF> Unity's still uninstallable on amd64, but that's much of a muchness.
[23:32] <Sarvatt> RAOF: thanks for the heads up about isc-dhcp-client, forgot to downgrade and that would have been a head scratcher :)
[23:43] <Sarvatt> http://www.nvnews.net/vbulletin/showthread.php?t=159990
[23:49] <cnd> Sarvatt, what's up with isc-dhcp-client?
[23:50] <cnd> I'm chatting with rydberg, and he's having dhcp problems right now
[23:50] <cnd> I'm chatting with rydberg, and he's having dhcp problems right now
[23:50] <cnd> I'm chatting with rydberg, and he's having dhcp problems right now
[23:50] <cnd> argh
[23:50] <cnd> sorry
[23:50] <Sarvatt> kills your net, need to downgrade to the ubuntu3 version :)
[23:50] <Sarvatt> dog fooding your input stuff there? :)
 https://bugs.launchpad.net/bugs/724556
[23:51] <ubot4> Launchpad bug 724556 in isc-dhcp (Ubuntu Natty) (and 1 other project) "[Natty] isc-dhcp update breaks network connection (affects: 10) (dups: 1) (heat: 56)" [Critical,Fix released]