[07:03] jcristau: prevents upgrades, says slangasek [07:04] jcristau: sorry for not mentioning that in the first place :) [07:05] so what should i do to get the package manager to remove the obsolete package? [07:09] Replaces should do according to him [07:10] hrm. i thought replaces was about replacing files. /me goes read policy. [07:11] I've missed the first part of this, but Conflicts+Replaces sounds like what you want, I think. [07:12] oh. 7.6.2. [07:17] Replaces: libxcb-xlib0 is enough, or do i add the -dev? [07:20] if libxcb1-dev replaces libxcb-xlib0-dev, then perhaps [07:21] installing the new libxcb1 breaks libxcb-xlib0, and thus also libxcb-xlib0-dev [07:23] so i'm not sure explicitly replacing is needed. and if it is where it should be. [07:23] (also fwiw 'apt-get -t experimental dist-upgrade' does remove libxcb-xlib0) [07:24] gah, s/explicitly replacing/& libxcb-xlib0-dev/ above. [07:27] works here too, but I'm just the middle-man :) [07:28] bad vorlon. [07:28] maybe prod him on #debian-x :) [07:53] that worked :) [07:54] yeah :) [08:26] turns out to be quite hard to debug a crashing xserver on acpi resume [08:27] last time that turned up, screen came to the rescue [08:27] maybe I didn't use the correct options for gdb [08:28] you told it to not stop on sigusr1? [08:29] I did now, let's see [08:31] hey, I've got a backtrace [08:31] let's try with -dbg [08:36] http://bugs.freedesktop.org/attachment.cgi?id=22303 [13:34] tjaalton, seems ouchscreens with the new evdev infrastructure dont work at all ... (just got some user feedback, didnt look myself yet) [13:38] ogra: that's unfortunate [13:39] tseliot: new nvidia*.. but you probably knew that already :) [13:39] yes, StevenK tested it today and he sees no motion at all tapping or touching the screen [13:39] does evdev pick the device? [13:39] it should at least show some miscalibrated movement [13:40] logs etc in a bug report would be nice :) [13:40] and evtest output probably [13:40] yes [13:41] tseliot: oh, they still don't support the current ABI [13:42] seems that aaron didn't get his message through [13:42] (or the got problems) [13:42] *they [13:43] hmm, legacy drivers apparently do support the new ABI [13:48] tjaalton: maybe he forgot to add a note about the new ABI in the changelog [13:48] I'll test them [13:48] could be [13:49] Maple v12 crashed my jaunty today.. after I resized the window. I blame nvidia :) [13:49] well, running drivers with IgnoreABI is not recommended ;) [13:50] yeah.. [13:50] but I do it [13:50] I'd like to listen to my music though [13:50] no sound on the desktop or the laptop.. [13:50] don't resize the window then [13:51] or is it pulseaudio? [13:51] of course it works now, can't reproduce it :) [13:51] hehe [13:51] I've had issues with sound since pa 0.9.14 was uploaded [13:51] well, no sound [13:52] audio is choppy here e.g. when I switch between windows [13:53] for instance the playing doesn't even start, it just hangs there [13:53] +in rhythmbox [13:53] and if I kill pa, no sound [13:54] :-/ [13:54] did you talk to theMuso about it? [13:55] yes [13:55] no solution? [13:55] he could reproduce some of the issues, but no solution [13:55] ok, then [13:55] for instance alsamixer fails to start [13:55] pulse_haters++ [13:55] but isn't that a bug in alsa? [13:56] that too [13:57] but I'm hopeful that the commits he requested for the kernel might help [14:01] keep your fingers crossed then [14:12] I will.. [14:15] tjaalton, hrm [14:16] so i'm trying out the samsung Q1 with the new ubuntu-netbook-remix image ... it still includes evtouch ... lshal shows me though that "synaptics" is forcefully used for the touchscreen [14:16] while the evtouch initscript seems to have run and all calibration data is applied [14:16] shouldnt it use evdev ? [14:17] instead of synaptics [14:17] yes [14:17] but that depends what the new image holds [14:17] sounds like it shouldn't be reported as a touchpad.. [14:17] +on [14:17] right [14:18] well, lshal shows capabilities input and input.touchpad ... where does touchpad get set ? [14:18] is there an fdi i can mangle ? [14:18] probably hal source [14:19] ogra: what version of hal? [14:19] and probably based on what the kernel reports about the device [14:19] I bet it's too old [14:19] its todays image build [14:19] so whatever is in the archive atm [14:19] ok, maybe hal is still missing something.. bug pitti :) [14:20] git20090120-0ubuntu1 [14:43] seb128, mvo: can you merge from my branch, please? https://code.launchpad.net/~albertomilone/gnome-control-center/randr-virtual [15:02] seb128, mvo: this adds the DontZap checkbox to enable users to decide whether Ctrl+Alt+Backspace can restart X or not [15:44] tseliot, while you are getting the upload ready for the new drivers, did you have a fix queued for https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/309116 ? [15:44] Launchpad bug 309116 in nvidia-graphics-drivers-96 "when removing nvidia-glx-177 /usr/lib/libGL.so is gone" [Medium,In progress] [15:45] superm1: I won't upload the new drivers without fixing that first [15:45] ;) [15:45] tseliot, okay :) [17:29] morning [17:43] I spoke with amd this morning and asked them for a date on when they expect to provide a 1.6/.28 compatible fglrx [17:44] they didn't have that info currently but will try to get it by the end of the week [17:47] ok [17:47] nvidia released new versions of the legacy drivers [17:47] sweet [17:48] yeah amd seemed a bit surprised that we were planning on 1.6 for 9.04. I had to remind them I emailed them a month and a half ago that this was our plan [17:49] heh [18:02] bryce, any indications from them if a driver will be coming more than 1 month prior to release this time around? [18:04] superm1: I pressed them on giving us a date. they said they'll get back to us after they've "scrubbed their schedule" [18:06] I would be feeling frustrated if the deja vu feelings weren't keeping me in such mirth [18:13] mister bryce [18:13] superm1: anyway, so I sense we're going to be in about the same situation as last time, despite our efforts. [18:13] I resurrected the 10-second confirmation dialog for the RANDR tools and committed it to gnome svn [18:13] federico1: oh interesting [18:14] bryce, oh that's too bad :( [18:14] bryce: http://bugzilla.gnome.org/show_bug.cgi?id=545115 [18:14] Gnome bug 545115 in Screen resolution "should ask for confirmation before writting the changes" [Normal,Resolved: fixed] [18:14] bryce, well at least this time, all the packaging is ready and it's at least easy to update new drops etc [18:15] bryce: are you or anyone here in distributor-list? [18:15] I'll post an evil patch to deal with wacom tablets and RANDR [18:15] federico1: "distributor-list"? first I've heard of that; what is it? [18:16] federico1: thanks for committing that revert dialog patch; I'd been disappointed that it hadn't been taken previously [18:16] federico1: what's the plan on wacom tablets? [18:17] superm1: yep. [18:17] bryce: distributor-list@gnome.org [18:18] federico1: ah, I bet seb128 is on that list, he usually handles the gnome interfacing [18:19] ah, ok [18:19] tseliot: one sec, meeting [21:28] fun [21:28] [ 6009.433242] mtrr: no MTRR for f0000000,100000 found [21:28] [ 6009.604066] Xorg[12735] general protection ip:4961b6 sp:7ffff1fccde0 error:0 in Xorg[400000+1c2000] [21:28] 64bit jaunty under kvm [21:31] kees, i've been seeing mtrr: no MTRR for e0000000,10000000 on real systems, is there any significance to what that's representing? [21:41] superm1: not sure. :( [21:41] kees, oh okay. just wasn't sure what MTRR was an abbreviation for. [21:44] I've seen reports about that [21:45] btw speaking of acronyms I finally learned what fglrx stands for... "FireGL and Radeon for X" [21:45] MTRR == Memory Type Range Registers maybe? [21:45] http://www.mjmwired.net/kernel/Documentation/mtrr.txt [21:57] bryce: ah! I've always wondered wtf fglrx stood for. :) [21:58] well we always knew it was an f-word [22:00] bryce: landslide in radeon git today - what are your plans for updating jaunty? There's some agp quirks etc that otherwise could be cherrypicked [22:01] bryce: got a patch from jesse for the interrupt loss when using vblank, will try it out tomorrow [22:03] against the kernel(drm) though, so a bit harder to get through if it works [22:17] tjaalton, ok [22:17] tormod: I anticipate updating -ati at least once more before we're done with jaunty [22:18] even if that might mean shipping a git snapshot. A release would be nice of course, but we've shipped git snapshots before [22:25] bryce: good [22:26] tormod: at some point post-beta I also will be pulling any outstanding quirks for both -ati and -intel