#ubuntu-x 2007-05-28
<ubotu> New bug: #117311 in xorg (main) "SIS300/3005" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117311
<ubotu> New bug: #117312 in xorg (main) "Runing graphic on SIS300/3005" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117312
<ubotu> New bug: #117313 in xorg (main) "Running graphic gnome on SIS300/3005" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117313
<ubotu> New bug: #117319 in xserver-xorg-video-intel (main) "xorg intel driver: chosing too high frequency" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117319
<ubotu> New bug: #35724 in xserver-xorg-video-ati (main) "[PPC/r200]  X11 color corruption on a radeon 9000 mac edition" [Medium,Unconfirmed]  https://launchpad.net/bugs/35724
<ubotu> New bug: #117056 in gdm (main) "GDM doesn't load after choose 'close session' or 'swich user' (dup-of: 112198)" [Low,Rejected]  https://launchpad.net/bugs/117056
<ubotu> New bug: #117411 in linux-restricted-modules-2.6.20 (restricted) "nVidia 680i Ethernet is not working / Forcedeth Module" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117411
<ubotu> New bug: #117440 in xserver-xorg-video-ati (main) "AGP Radeon 7000 Black/Blank screen before GDM" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117440
#ubuntu-x 2007-05-29
<ubotu> New bug: #117461 in xfs (universe) "Please sync xfs 1:1.0.4-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed]  https://launchpad.net/bugs/117461
<ubotu> New bug: #117573 in xserver-xorg-video-i810 (main) "glFog implementation is broken on i810 driver (i915 video card)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117573
<ubotu> New bug: #116456 in linux-restricted-modules-2.6.20 (restricted) "[feisty]  lockups - "ipw2200: Firmware error detected.  Restarting."" [Medium,Confirmed]  https://launchpad.net/bugs/116456
<bryce> seb128, tepsipakki: I'm curious about the numbering for libice - in ubuntu it has a 2: epoch number, but debian uses 1:.  Any idea why this is?
<bryce> same with libxaw, libxext, etc.
<seb128> bryce: new xorg has been packaged for Ubuntu first
<seb128> and it has extra iteration
<bryce> seb128: hmm, now that debian has the new xorg, how do we straighten this out?
<bryce> (or do we need to?)
<seb128> convince them to update the epoch number
<jcristau> our next upload could bump the epoch, we've done that for a few libs already
<seb128> would be nice ;)
<bryce> jcristau: that'd be a big help; when is the next upload scheduled?
<jcristau> "not", at this point :)
<bryce> when was the last upload?
<seb128> bryce: if the only change is the epoch number that's only getting the Debian source, running dch, uploading
<seb128> not a lot of work but that would nicer to be in sync
* bryce nods
<jcristau> the epoch bump is already in git, btw (at least for libice)
<bryce> ok cool
<bryce> libxfontcache is a bit different; we have it as epoch 2:, but debian appears to not have any epoch on it
<bryce> gutsy is on 2:1.0.2-0ubuntu1, whereas debian is at 1.0.4-1
<keescook> bryce: beforelight> hm, not sure -- double checking
<bryce> ok
<bryce> bbl (lunch)
<keescook> beforelight> it didn't actually fix it.  (there is no patch system in the beforelight package, so your patch did not get applied)
<keescook> be sure to double-check your build logs for the patch happening, and then verify your resulting .deb files for the fix (I still see the bad paths)
<keescook> if you want to add the "dpatch" patch system, you can add "dpatch" to the Build-Deps, and change the debian/rules to include the dpatch make file.  also the "build" and "clean" rules need to be updated.  "man dpatch" talks about this near the end, but fails to mention the "include /usr/share/dpatch/dpatch.make" bit.
<keescook> build-stamp: -> build-stamp: patch     and  clean: -> clean: clean-patched unpatch\nclean-patched:
<bryce> ok, I'll give all that a try
#ubuntu-x 2007-05-30
<bryce> hmm, I'm getting odd errors attempting to reach archive.ubuntu.com:
<bryce> Err http://archive.ubuntu.com gutsy/main dpatch 2.0.22
<bryce>   404 Not Found [IP: 91.189.89.8 80] 
<bryce> nevermind, figured it out
<ubotu> New bug: #117638 in xorg (main) "Graphics problem when users have different screen resolutions" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117638
<tepsipakki> every epoch has been committed to git.d.o
<keescook> tepsipakki: very cool!
<tepsipakki> there are 24 packages with different orig.tar.gz, 45 packages with changes committed and waiting for upload, and 16 that otherwise can be synced after an upload
<tepsipakki> maybe I should put all of this in the wiki..
<tepsipakki> its just easier to edit a text file which is always open on my screen session :)
<keescook> bryce: okidoky.  evil evil beforelight
<bryce> yup
<keescook> I think we're very close -- I suspect there are just some patch thingies missing from the rules
<bryce> I'd checked dpkg -c on the deb before I sent it in, and didn't see the recursive paths
<keescook> which other package uses the x patch stuff?
<bryce> appres, xorg-docs, bitmap, xorg-server, etc. etc.
<bryce> basically all the ones I've touched have used this system
<keescook> bryce: weird.  I wonder why we're seeing different results.  does your build log show it as having applied the patch?
<bryce> I seem to recall it did, yes
<keescook> appres and bitmap don't seem to have it
<keescook> do you still have the log?  Something must be wrong with my build environment
<keescook> ah, yeah, xorg-docs has it
<keescook> okay, so, comparing the build and clean rules between xorg-docs and beforelight.  xorg-docs has:
<keescook> build: patch build-stamp
<keescook> build-stamp:
<keescook> where as beforelight is just:
<keescook> build: build-stamp
<keescook> build-stamp:
<bryce> no, don't have the log
<keescook> go ahead and build it again (it's quick).  I'd like to track down the source of the problem.
<bryce> ok building
<bryce> hmm, there's nothing indicating the patch applied
<keescook> can you paste-bin the results of dpkg -c ?
<bryce> http://pastebin.ca/522850
<ubotu> New bug: #117222 in xorg (main) "Dell Latitude X1 Screen Resolution" [Undecided,Needs info]  https://launchpad.net/bugs/117222
<keescook> bryce: drwxr-xr-x root/root         0 2007-05-30 08:37 ./tmp/buildd/beforelight-1.0.2/debian/beforelight/
<keescook> so there are bad paths in your .deb too.  Okay, I'm not going crazy.  :)
<ubotu> New bug: #117782 in linux-restricted-modules-2.6.20 (restricted) "Upgrade of linux-restricted-modules-2.6.20-16-generic failed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117782
<keescook> bryce: alright, so, to hook up xsf fully.
<keescook> do you still have the xorg-docs source tree to look at?
<bryce> yeah
<keescook> in xorg-docs's debian/rules, take a look at the "build" rule.
<keescook> before it can run the "build" rule, it has to do the pre-reqs, so it performs "patch" and then "build-stamp".
<keescook> "build-stamp" is immediately below the "build:" rule, and "patch" is defined in the xsf included makefile
<keescook> if you look at beforelight's debian/rules, you'll see that "patch" is missing.  go ahead and add it (order is important: it needs to do "patch" before "build-stamp" -- gotta build the patched source)
<bryce> ah, I thought "patch" was leftover from dpatch, so removed it
<keescook> it tends to be a general rule for invoking whatever patch system has been included in the packaging.
<keescook> no matter what the patch system, it always has to happen before the build and after the clean, etc.  :)
<keescook> bryce: any luck with rebuilding beforelight with the fixed rules file?
<bryce> nope, it complained I didn't have quilt
<bryce> (installing)
<bryce> er wait, it's already installed
<keescook> ??
<bryce> hrm
<keescook> that's a build-dep
<keescook> so you'll need to update your control file too (adding the xsf stuff, I guess, requires quilt)
<bryce> however quilt is already listed in the Build-Depends 
<bryce> wait
<bryce> clearly I need stronger coffee
<keescook> heh.  :)
<bryce> man what a pita for such a irrelevant bit of x ;-)
<bryce> ah well, you learn the most on things that *don't* go smoothly, eh?
<keescook> :) but it's all for the learning.  right.  :)
<bryce> hrm
<bryce> No patches in series
<bryce> No patches to apply
<bryce> oh!
<bryce> mv 00list series
<bryce> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
<bryce> is that normal?
<keescook> I think that's normal, but I honestly don't know what it means.
<bryce> ahh
<bryce> 100_appdefaultdir_prefix.patch
<bryce> Applying patches...successful.
<keescook> yay!
<keescook> have you used quilt before?  I hadn't before doing debian packaging.  I find it... weird.
<keescook> if you use quilt directly, don't forget to set  QUILT_PATCH=debian/patches  otherwise it'll write them to just "patches"  :)
<bryce> there was a brief period when I started on nfsv4 where they were using quilt, before they switched to git
<bryce> so I used it like once or twice, but I found I just needed to deal with their patches in aggregate anyway, so didn't really learn it
<bryce> yup, got it in my .bashrc
<keescook> cool.
<bryce> http://pastebin.ca/522957
<keescook> oh! sorry, it's QUILT_PATCHES  (I missed the "ES" before)
<keescook> what do you think of the dpkg -c output?
<bryce> hmm, well it looks the same to me as the last one
<keescook> I would agree.  :(
<bryce> so I'm not sure that the patch works correctly
<keescook> what you see there is what would be installed from the deb, and nothing should ever go in /tmp or /home, etc
<keescook> so, here's another thing, your patch only changes Makefile.am; this file is not used by the build.  (Makefile.in is used)
<keescook> so you'll like need to add Makefile.in's changes too.
<bryce> ah, that could be it
<keescook> (and send the Makefile.am patch upstream, since that seems to be a legit bug)
<bryce> 100_appdefaultdir_prefix.patch
<bryce> Applying patches...successful.
<keescook> :)
<bryce> looks clean http://pastebin.4programmers.net/2319
<keescook> eeexcellent!
<bryce> that xorg-docs patch got accepted and applied upstream :-)
<keescook> nice.  :)
<keescook> okay, go ahead and upload beforelight, and I'll sponsor it in.
<jcristau> is that patch the same as http://git.debian.org/?p=pkg-xorg/app/xbase-clients.git;a=blob;f=debian/patches/16_beforelight_install_app-defaults.diff;hb=HEAD ?
<bryce> the xorg-docs patch was Debian's 023_specs_doc_fixes.diff
<jcristau> yes, i saw that, thanks for forwarding it!
<keescook> jcristau: yeah, that looks like the same beforelight patch
<bryce> ah yes, the beforelight patch is that one
<jcristau> ok
<bryce> ok, posted upstream
<jcristau> \o/
<jcristau> i should have done that when i added the patch in the first place...
<bryce> no prob; made for a good learning opportunity for me
<bryce> jcristau: which brings up a question...  why does debian-x use this xsfbs system for handling patches, rather than dpatch?
<jcristau> the primary reason would be that dpatch sucks :)
<jcristau> but the xsfbs stuff was basically imported from the monolith, and most of it is unused now...
<jcristau> we should work on integrating the rest in quilt proper
<bryce> well I do have to admit I could never get dpatch working, whereas xsfbs was reasonably straightforward (all the problems I ran into were my own doing)
<jcristau> (the fact that dpatches aren't proper patches isn't exactly helpful, e.g.)
<bryce> yeah
<bryce> jcristau: btw, I don't remember if I showed this to you already - http://people.ubuntu.com/~bryce/Xorg/versions_current.html
<bryce> just for my own sanity to check what still needs merged/updated
<jcristau> nice
<bryce> most of what's left is just epoch number variances, or stuff that will come from the apps split out
<jcristau> ok
<johanbr> Hi. Has it been decided which version of Mesa will land in Gutsy? The reason I ask is that 3D support for my card was added very recently, and it'd be nice to able to ditch the fglrx driver.
<bryce> 6.5.3 is in gutsy now
<bryce> but the plan is for 7.0.0
<bryce> we're just waiting for the 7.0.0 release, which I understand should be any day now (tm)
<johanbr> I see, thank you. Will Mesa 7.0.0 include current git, or is that a different branch?
<jcristau> it's mesa_7_0_branch
<bryce> johanbr: any testing you could do of that branch for the mesa guys could be a big help
<keescook> bryce: the resulting patch in debian/patches looks a little funny -- I've dropped the duplication of itself, and will upload this once it finishes building
<keescook> the final results look fine, though.  \o/
<bryce> ah ok
<bryce> oh, I see, I had an extra/different copy of the patch hanging around that got tucked in.  hrm
<keescook> yeah, before each upload, I review any patches I've touched, and then the debdiff itself between the current and older package.
<keescook> (and I look at the diff.gz to make sure there weren't any out-of-debian/ changes
<bryce> I think I was just being impatient, I usually check that
<keescook> okay, uploaded!  :)
<bryce> kewl!  thanks!
<keescook> np :)
<bryce> keescook: I figured out debian's naming scheme for X *proto packages.  Filled in a ton of blanks:  http://people.ubuntu.com/~bryce/Xorg/versions_current.html
<bryce> still haven't figured out where the font-* packages go though
<keescook> check the debian/copyright files, they should mention where they were downloaded from
<keescook> oh, you mean the reverse, sorry
<bryce> no, the issue... yeah
<jcristau> xfonts-base has font-arabic-misc font-cursor-misc font-daewoo-misc font-dec-misc font-isas-misc font-jis-misc font-micro-misc font-misc-misc font-mutt-misc font-schumacher-misc font-sony-misc font-sun-misc
<keescook> check xfonts-base, ah jcristau is too fast for me.  :)
<bryce> ahh
<bryce> jcristau: any plans on ever breaking those out, or will that package stay as is for a while?
<jcristau> that'll stay as is
<bryce> cool
<jcristau> xfonts-100dpi: font-adobe-100dpi font-bh-100dpi font-bh-lucidatypewriter-100dpi font-bitstream-100dpi
<jcristau> xfonts-75dpi: font-adobe-75dpi font-bh-75dpi font-bh-lucidatypewriter-75dpi font-bitstream-75dpi
<bryce> what's the command to list what is contained in them?
<johanbr> bryce: I tried building Mesa git a week ago, but the compile failed, apparently because it found the (old) system libdrm and I wasn't able to get it to work right. I'll see if I have time one of these days...
<bryce> johanbr: cool, let us know if you get it working
<jcristau> bryce: i'm using "ls" in the source tree :)
<bryce> ahh heh
<jcristau> xfonts-cyrillic has font-*-cyrillic
<johanbr> bryce: Sure, will do. The Mesa 7.0.0 branch does appear to contain the support for my chipset (rs480), so it looks like I'll be able to use free drivers in Gutsy.
<jcristau> and it looks like xfonts-scalable is actually font-bitstream-type1
<bryce> ok /me hacks in some translation tables
<jcristau> xfonts-encodings is called "encodings" upstream
<jcristau> bryce: "xproto" upstream is "x11proto-core" in debian
<ubotu> New bug: #117828 in xorg (main) "switch user" [Undecided,Needs info]  https://launchpad.net/bugs/117828
#ubuntu-x 2007-05-31
<ubotu> New bug: #24966 in xserver-xorg-video-via (main) "ubuntu 5-10 crashes within minutes after succesfull installation" [Medium,Rejected]  https://launchpad.net/bugs/24966
<bryce> jcristau: cool, got the font package translation table working properly:  http://people.ubuntu.com/~bryce/Xorg/versions_current.html
<jcristau> bryce: cool
<jcristau> bryce: the proto source package names don't end with -dev btw
<bryce> ah, ok
<bryce> hmm:
<bryce> regenerating...
<bryce> cool, that looks better
<jcristau> that means the links to the pts (and launchpad?) actually work :)
<jcristau> still needs s/x11proto-x/x11proto-core/
<bryce> ah, the *proto rule is eating that one
<bryce> there we go
<jcristau> also the link to gitweb seems broken when the debian/ubuntu package name differs from the upstream name
<bryce> yeah, still working on those fiddly bits
<ubotu> New bug: #117875 in xserver-xorg-video-ati (main) "ATI Radeon 9200 AGP bus Non-Functional in Feisty Fawn 7.04 Xorg Driver ATI" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117875
<tepsipakki> bryce: the split xbase-clients/xutils are now in Debian experimental (waiting in NEW)
<tepsipakki> ..and some upstream sources were dropped in the process, including beforelight :)
<bryce> tepsipakki: ok, thanks for the update
<bryce> tepsipakki: is there a list of what sources were included?
<tepsipakki> yep, http://users.tkk.fi/~tjaalton/dpkg/xorg/xbase-clients-split.txt
<tepsipakki> and http://users.tkk.fi/~tjaalton/dpkg/xorg/merges.txt is a list that I made a while back to see where we stand (no version numbers though)
<bryce> ah yes
<tepsipakki> at least the list of packages having different orig.tar.gz
<tepsipakki> ..should be useful
<bryce> tepsipakki: I think I showed this before, but I've done some updates:  http://people.ubuntu.com/~bryce/Xorg/versions_current.html
<bryce> notice the lib's are differing between debian and ubuntu just in epoch number in several cases
<bryce> I think if you fixed the epochs, they might sync cleanly
<tepsipakki> they are fixed in git
<bryce> ah good; think they'll be released soon?
<tepsipakki> that's what the "changes committed in git" means (epochs and Conflicts/Replaces etc)
<tepsipakki> if we ask nicely, sure
<tepsipakki> :)
<bryce> :-)
<ubotu> New bug: #117892 in xserver-xorg-video-i810 (main) "i810/intel xorg drivers hang Inspiron 1100" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117892
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #17593 in xorg (main) "Mouse button press delayed" [Medium,Fix released]  https://launchpad.net/bugs/17593
<iwj> bryce: Would you care to comment on https://wiki.ubuntu.com/UnifiedLoginUnlock ?
<bryce> iwj, sure I'll look at it today
<iwj> Ta.
<ubotu> New bug: #42880 in Baltix (main) "xorg.conf VertRefresh and/or monitor not easily configurable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/42880
<ubotu> New bug: #114354 in xorg (main) "Feisty X - Dell P1110 exhibits weird behavior when making windows bigger" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114354
<ubotu> New bug: #98945 in xkeyboard-config (main) "can't compose all characters" [Low,Unconfirmed]  https://launchpad.net/bugs/98945
<ubotu> New bug: #118110 in linux-restricted-modules-2.6.20 (restricted) "ipw3945: Microcode SW error detected. " [Undecided,Unconfirmed]  https://launchpad.net/bugs/118110
<ubotu> New bug: #117029 in linux-restricted-modules-2.6.20 (restricted) "Atheros 5005 permanently disappears all of a sudden " [Undecided,Unconfirmed]  https://launchpad.net/bugs/117029
#ubuntu-x 2007-06-01
<ubotu> New bug: #118163 in mesa (main) "Freezes with VIA KM400/VT8378 (regression)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118163
<ubotu> New bug: #118196 in xserver-xorg-video-i810 (main) "[regression]  latest kernel 2.6.20.28.1 breaks DRI" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118196
<ubotu> New bug: #50269 in linux-restricted-modules-2.6.15 (restricted) "Mouse loses sync, Virtual terminals & killing X lock the screen" [Undecided,Needs info]  https://launchpad.net/bugs/50269
<ubotu> New bug: #49842 in linux-restricted-modules-2.6.15 (restricted) "Startup scripts delete files in /usr/lib/tls" [Undecided,Needs info]  https://launchpad.net/bugs/49842
<ubotu> New bug: #49955 in linux-restricted-modules-2.6.15 (restricted) "depmod -ae isn't run on user built install" [Undecided,Needs info]  https://launchpad.net/bugs/49955
<ubotu> New bug: #49322 in linux-restricted-modules-2.6.15 (restricted) "Usability Bug: NVidia header files are not copied over to /usr/include/GL" [Undecided,Needs info]  https://launchpad.net/bugs/49322
<ubotu> New bug: #118225 in xorg (main) "ATI FireGL V5200 not working at all" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118225
<kylem> bryce, awake?
<bryce> yup
<kylem> would doing an upload of -i810 conflict with anything you're up today?
<bryce> kylem: nope, that'd be fine
<kylem> ok, thanks.
<bryce> I'm mostly focusing on spec-ish stuff today, plus another pass through the bug trackers
<ubotu> New bug: #110778 in xorg (main) "kde won't launch after gamma adjustment" [Undecided,Needs info]  https://launchpad.net/bugs/110778
<ubotu> New bug: #44627 in xserver-xorg-video-sis (main) "3d support for Sis 760" [Medium,Confirmed]  https://launchpad.net/bugs/44627
<bryce> iwj: I took a look at the unified login unlock spec, I didn't have any real profound comments, but I added a couple q's relating to xgl, and xinerama
<bryce> iwj: I haven't quite wrapped my brain around how exactly this will affect things generally, as it seems to be a pretty significant architecture change for how X works.  
<ubotu> New bug: #39954 in Baltix (restricted) "Lucent winmodem driver missing." [Undecided,Unconfirmed]  https://launchpad.net/bugs/39954
<ubotu> New bug: #22392 in linux-restricted-modules-2.6.12 (restricted) "[madwifi]  System Freezes on me randomly" [Medium,Rejected]  https://launchpad.net/bugs/22392
<ubotu> New bug: #45315 in linux-restricted-modules-2.6.15 "madwifi makes the system crash" [Medium,Unconfirmed]  https://launchpad.net/bugs/45315
#ubuntu-x 2007-06-02
<bryce> I wonder if there's a way to configure ubotu to not tell us about wifi driver bugs?
<ubotu> New bug: #118325 in mesa (main) "sis dri DDX interface outdated" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118325
<ubotu> New bug: #51882 in xorg (main) "X windows crash (restarts) in dapper" [Undecided,Rejected]  https://launchpad.net/bugs/51882
<ubotu> New bug: #56184 in xorg (main) "Xorg crashes on various occasions" [Undecided,Unconfirmed]  https://launchpad.net/bugs/56184
<ubotu> New bug: #57862 in xorg (main) "Display is unusable with default settings" [Undecided,Unconfirmed]  https://launchpad.net/bugs/57862
<ubotu> New bug: #44620 in xorg (main) "system crashes when the screen resolution is changed and dual head is enabled" [Medium,Rejected]  https://launchpad.net/bugs/44620
<ubotu> New bug: #47542 in xorg (main) "Fast scrolling causes X hang" [Medium,Unconfirmed]  https://launchpad.net/bugs/47542
<ubotu> New bug: #23691 in xorg (main) "Latin Keyboard Layout wrongly recognized as 'Laos'" [Medium,Unconfirmed]  https://launchpad.net/bugs/23691
<ubotu> New bug: #40148 in xorg (main) "Key (Code 94) does not work anymore" [Medium,Rejected]  https://launchpad.net/bugs/40148
<tepsipakki> bryce: x-swat is subscribed to linux-restricted-* bugs
<tepsipakki> don't think there is a way to narrow it down
<ubotu> New bug: #116977 in xserver-xorg-input-joystick (universe) "Driver not correctly identifying the number of buttons on a Namtai Buzz! Controller" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116977
<ubotu> New bug: #50897 in linux-restricted-modules-2.6.15 (restricted) "wireless driver hangs for a bit missing data packets (ex: during ping)" [Undecided,Needs info]  https://launchpad.net/bugs/50897
<ubotu> New bug: #118417 in xorg (main) "Ubuntu hangs/crashes when switching between 2 xsessions" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118417
<ubotu> New bug: #118423 in xorg (main) "Xorg doesn't detect synaptics input device without specification in xorg.conf" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118423
#ubuntu-x 2007-06-03
<ubotu> New bug: #95695 in compiz (main) "Desktop effects (dup-of: 89189)" [Medium,Needs info]  https://launchpad.net/bugs/95695
<ubotu> New bug: #93916 in compiz (main) "Screen loses right-hand side and gnome title bar.  Colour depth restricted (dup-of: 91850)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93916
<ubotu> New bug: #94581 in compiz (main) "Visible area of the screen becomes less (dup-of: 91850)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94581
<ubotu> New bug: #118476 in xorg (main) "[Gutsy]  xorg Intel 810 video driver hangs due to displayinfo " [Undecided,Unconfirmed]  https://launchpad.net/bugs/118476
<ubotu> New bug: #6549 in linux-restricted-modules-2.6.15 (restricted) "fwlanusb module inclusion" [Medium,Needs info]  https://launchpad.net/bugs/6549
<ubotu> New bug: #54880 in xorg-server (main) "Does not support Linux PCI domains" [High,Confirmed]  https://launchpad.net/bugs/54880
<ubotu> New bug: #89467 in xorg "[feisty]  f-spot and system inputs freeze when using xorg via-/unichrome-driver" [Undecided,Confirmed]  https://launchpad.net/bugs/89467
<ubotu> New bug: #52321 in xserver-xorg-video-trident (main) "Displayed Image on TFT is 2 pixels off, of what it normally should be" [Undecided,Confirmed]  https://launchpad.net/bugs/52321
<ubotu> New bug: #118536 in xserver-xorg-video-trident (main) "Controller: Cyberblade i1 doesn't support direct rendering" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118536
<ubotu> New bug: #118565 in linux-restricted-modules-2.6.20 (restricted) "nvidia-glx-config help text shows wrong path" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118565
#ubuntu-x 2008-05-26
<Q-FUNK> howdy!
<pwnguin> baAhi
<pwnguin> doof
<pwnguin> hello
#ubuntu-x 2008-05-27
<johanbr> bryce: About the Radeon lockup I asked you about a few days ago, there's a bug filed now (bug #234811). Hardy locks up completely when running 1440x900. Gutsy works fine.
<ubottu> Launchpad bug 234811 in xorg "[Hardy] system freezes after setting resolution to 1440 x 900 with Radeon 7500 graphics card, when using DVI output, Acer AL1916W monitor" [Undecided,New] https://launchpad.net/bugs/234811
<bryce> johanbr: ok thanks, looking
<tseliot> tjaalton: the drivers are ready however I would like to know which versioning scheme we should adopt. For example shall we put something like this in the changelog? nvidia-graphics-drivers-2.6.24 (2.6.24.500-500.30) intrepid; urgency=low
<tseliot> I have adopted Debian's name schemes
<tjaalton> tseliot: no need for the kernel version being there..
<tjaalton> better use the nvidia versions like debian
<johanbr> bryce: Is it really possible to do anything (apart from maybe SysReq traces) when the machine locks up completely?
<tseliot> ï»¿tjaalton: one of the packages will be named nvidia-glx and should replace nvidia-glx-new. We have to make sure that we don't break dist-upgrades from Hardy to Intrepid therefore
<tseliot> we should be careful about the version and about the control file
<tseliot> maybe adding something like this to nvidia-glx would solve part of the problem:
<tjaalton> tseliot: of course, but the version number is irrelevant if it Replaces another package
<tseliot> Conflicts: nvidia-glx-src, nvidia-xconfig, nvidia-glx
<tseliot> Replaces: nvidia-glx-src, nvidia-glx (<< 170.12+2.6.24.500-500.24)
<tseliot> Provides: nvidia-glx, xserver-xorg-video-2
<tseliot> tjaalton: yes, of course
<tseliot> ï»¿tjaalton: this wouldn't automatically replace nvidia-glx-new with nvidia-glx in case of upgrade though
<tjaalton> missing -new
<tjaalton> oh
<tjaalton> I thought it would make sense to rename current nvidia-glx as -legacy-96xx like in debian
<tseliot> and I did it. I'm talking about nvidia-glx-new
<tseliot> all the three flavours provide ï»¿nvidia-glx
<tseliot> maybe this is confusing you?
<tjaalton> why?-)
<tjaalton> why do they provide nvidia-glx
<tseliot> so that they conflict with each other
<tjaalton> and it should replace nvidia-glx-new, not nvidia-glx
<tseliot> ï»¿nvidia-glx-new becomes nvidia-glx
<tseliot> ï»¿nvidia-glx becomes nvidia-glx-legacy-96xx
<tjaalton> right
<tseliot> ï»¿nvidia-glx-legacy becomes nvidia-glx-legacy-71xx
<tjaalton> but the lines from control are wrong
<tseliot> those lines, which I haven't changed yet, belong to what used to be the nvidia-glx-new-envy package
<tseliot> any suggestions for the new control file?
<tjaalton> make it ready first and I'll review it then
<bryce> johanbr: yeah ssh in from another box and attach to the process
<bryce> johanbr: see wiki.ubuntu.com/X/Backtracing for directions
<johanbr> bryce: The network dies too.
<bryce> hmm, then the issue  may be in the kernel
<johanbr> An all-Gutsy installation works, but Hardy with the Gutsy kernel hangs, so it doesn't appear to be in the kernel.
<bryce> in any case, without a backtrace there is not more troubleshooting that can be done on it
<bryce> make sure you're using a wired connection
<johanbr> Is there a way of installing the Gutsy version of the radeon driver on Hardy, or has the X server changed too much?
<bryce> well, you could apt-get the source and rebuild it against your xserver.  It ought to work ok I should think.
<johanbr> Alright, I'll walk him through that and we'll see what happens. Thanks for the help.
<bryce> sure, good luck
<bryce> mesa 7.1 rc1 was announced :-)
<tjaalton> yep, finally :)
<bryce> tjaalton: have you ever tried device Option "DRI2" ?
<tjaalton> bryce: no.. haven't built snapshots in a while
<tjaalton> seems that DRI2 is not happening until the TTM/GEM mess is settled
<bryce> :-/
<bryce> I was afraid of that
<kushal1> jedimind, looking back, I don't know what I was thinking trying to add everything by hand. I cannot even believe I added over 60 of those by hand. I wish I could drag and drop using default settings 
<kushal1> Hello, I am making a home DVD with about 200 short clips using Devede. I have already added about 60 files one at a time but my hand is starting to hurt. It is also really boring. Is there a way for me to add a bunch of mpg files on to the devede list like a batch or drag and drop? please let me know. thanks  (please answer) 
<bryce> kushal1: I think you may be asking on the wrong channel
<bryce> kushal1: this channel is only for discussing X11
<kushal1> sorry, bryce 
#ubuntu-x 2008-05-28
<tjaalton> bryce: I've filed a bug to remove fonttosfnt from the archive, bug 235411. you could confirm that if you agree ;)
<ubottu> Launchpad bug 235411 in fonttosfnt "Please remove from the archive" [Undecided,New] https://launchpad.net/bugs/235411
<bryce> tjaalton: okies
<tjaalton> hmm, a couple of pending sync requests.. guess they'll be processed soon
<tjaalton> so, there'll be libdrm 2.3.1 without any memory-manager goodness
<tseliot> ï»¿tjaalton: I'm uploading the source code of my packages to my website. NOTE: I haven't touched the control files (as regards dependencies) and haven't carefully checked the diversions, however I would like you to review what I have done so far.
<tjaalton> tseliot: ok, cool
<tseliot> ï»¿tjaalton: I haven't removed the dependency on linux-restricted-modules-common yet since we are not sure about its removal and I had to add a "-modaliases" package so that we don't screw up jockey
<tjaalton> wow, Wolfram answered to bug 197163
<ubottu> Launchpad bug 197163 in xorg "Mathematica renders fonts incorrectly in Hardy" [Undecided,Won't fix] https://launchpad.net/bugs/197163
<tjaalton> so we are buggy at least in some respect, because there are no usable Courier and Times fonts (msttcorefonts not helping here)
<tjaalton> hm, though it should help
<tjaalton> fedora seems to have urw-fonts which is a free bundle of tt-fonts
<bryce> tjaalton: true
<tjaalton> I'll see what it takes to package that
<tseliot> tjaalton: here is a txt file which contains all the links to the source code: http://www.albertomilone.com/ubuntu/newlrm/lrm-links.txt
<tjaalton> apparently gsfonts should have the fonts..
<tjaalton> tseliot: thanks
<tjaalton> I'll just grab the directory
<tseliot> in the meantime I'll work on the xorg parser for bryce 
<tjaalton> uh, forbidden
<tseliot> yes, I know
<tseliot> you should wget the links in that txt file
<tjaalton> works
<tjaalton> ok, the version number is wrong :) -1 is reserved for debian, this should be -0ubuntu1
<tseliot> yes, I (temporarily) used exactly the same version as the debian package
<tjaalton> ok, that just makes no sense :)
<unggnu> hi all
<tjaalton> hi unggnu 
<unggnu> According to mail [ubuntu-x] Xorg Triaging Projects it is not possible for non developers to set Wont' fix
<unggnu> hi tjaalton
<unggnu> Only solution is to set to invalid I guess or get the permission to use Wontfix.
<tjaalton> or join ubuntu-bugcontrol
<unggnu> Do you have a link?
<tjaalton> https://edge.launchpad.net/~ubuntu-bugcontrol
<unggnu> thx
<unggnu> Btw. isn't it possible with a script to mark all displayconfig-gtk bug reports which have only one package association with Wontfix and add the description?
<tjaalton> should be, but I'm not familiar with the mail-interface
<unggnu> Ok
<unggnu> Is something planned for people with hardware which send wrong data or something like that? Some can't even fixed with a quirk afaik. It is possible to change xorg.conf manually but it isn't so easy I guess for most people.
<unggnu> e.g. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/191000
<ubottu> Launchpad bug 191000 in xserver-xorg-video-intel "[Hardy] X Server fails to start [845g] (dup-of: 194760)" [Unknown,Fix released] 
<ubottu> Launchpad bug 194760 in xorg-server "EDID fail" [High,Triaged] 
<unggnu> I guess a tool with a "problem monitor" db would be great or the ability to import windows monitor drivers and change the xorg.conf settings with this information. Afaik displayconfig-gtk had the second ability. Maybe only the monitor part can be extracted.
<unggnu> Another problem are CRT displays afaik. It is possible to change the user resolution with the screen resolution tool but not the login one and afaik X uses the highes possible one which doesn't look so well on CRTs.
<unggnu> Are there any plans for this problems?
<unggnu> bbl
<tjaalton> CRT's are dying anyway ;)
<jcristau> unggnu: X uses the mode that your monitor reports as preferred
<jcristau> unggnu: if that doesn't work then it can be quirked
<tjaalton> yeah the first problem seemed like it should be able to be quirked, since it tries to use a wrong mode
<tjaalton> maybe the inted engineer meant that it's not possible to quirk the driver
<tjaalton> *intel
<jcristau> the initial mode selection code has changed a lot recently though
<jcristau> so maybe the server from git does a better job
<jcristau> in any case this looks like a bug in the server, not xf86-video-intel?
<tjaalton> yeah
<unggnu> re
<unggnu> jcristau: so a CRT sends the data that he supports resolutions up to 1600x1200 but prefers 1280x1024?
<unggnu> sorry, it supports :)
<jcristau> yes
<unggnu> But why are so many people with CRT complaining about it?
<unggnu> Anyway, if xserver uses this preferred mode it is Ok I guess. I can't test it since I haven't any CRT anymore. Yes, they are dying :)
<unggnu> I guess in future the biggest part of the driver are quirks ;)
<jcristau> no
<unggnu> bbl
<bryce> tjaalton: do you know of any reasons we should put a newer fglrx into 8.04.1 (deadline's coming up)
<tjaalton> tjaalton: I'll read the relnotes to see if there's anything
<tjaalton> I didn't realize there was a deadline :/
<bryce> yeah sunday is the cutoff for getting things into 8.04.1
<tseliot> tjaalton: https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/catalyst_85_linux.html
<tseliot> BTW they broke the API
<bryce> tseliot: erf
<tjaalton> tseliot: meaning?
<tjaalton> eh, the list of known issues keeps getting longer..
<tseliot> ï»¿tjaalton: it means that you will have a lot of fun packaging it
<tseliot> furthermore the ati installer doesn't include Mario's latest scripts
<tseliot> therefore I suggest you to get such scripts from git and see what's changed
<tseliot> I'm planning to make this driver available through EnvyNG too (sooner or later)
<tseliot> ï»¿bryce: have a look at my email when you have the time
<bryce> tseliot: ok just replied
<tseliot> bryce: thanks
<bryce> heya unggnu
<unggnu> hi bryce
<bryce> tseliot, tjaalton: so sounds like the new fglrx is too sketchy to think about including for 8.04.1?
<unggnu> Can't someone ask an Launchpad expert or maintainer if this is possible to close all displayconfig-gtk bugs since they don't seem to need user interaction.
<unggnu> I thought updating fglrx or nvidia isn't possible or at least feasible? At least I have read it somewhere.
<tseliot> ï»¿bryce: yes, I guess so
<bryce> unggnu: normally yes, but I got a dispensation for it for 8.04.1 -- but it makes sense to do it only if we know it will fix issues and we're confident it won't bring regressions
<unggnu> ok
<bryce> unggnu: I was going to just close the dcg bugs manually, so I could check that they're actually dcg bugs, and give additional answers where appropriate
<unggnu> Ok, that's a point. I could be minimize through closing simply the displayconfig-gtk only bugs but the risk is still there.
<unggnu> So kde-guidance should be closed too?
<bryce> I believe so, but check with scottk
<tjaalton> bryce: yep
<johanbr> bryce: About the Radeon lockup bug (bug #234811), "xrandr -s 1440x900" works (in contrast to doing it with the GUI, which causes a hard lockup).
<ubottu> Launchpad bug 234811 in xserver-xorg-video-ati "[Hardy] system freezes after setting resolution to 1440 x 900 with Radeon 7500 graphics card, when using DVI output, Acer AL1916W monitor" [Undecided,Incomplete] https://launchpad.net/bugs/234811
<bryce> johanbr: *nod* that's too bad, since if it could be reproduced with xrandr we could forward the report upstream
<bryce> johanbr: as it is, it may be some issue with gnome-display-properties' randrwrap code
<unggnu> What happens with Bullet-Proof-X in Intrepid?
<bryce> unggnu: timo and I discussed it and are thinking we'll drop it
<johanbr> Even so, there's an X server or driver bug in there somewhere, right? I'd think the GUI shouldn't be able to bring everything down.
<bryce> right
<bryce> it's definitely a legit X bug, just not clear yet how to troubleshoot it
<unggnu> I liked the idea very much but was never lucky with displayconfig-gtk.
<johanbr> bryce: I haven't yet tried asking him to rebuild the Gutsy version of the driver. I'll do that.
<unggnu> Theoretically it isn't needed if the Vesa fallback of Xorg works fine.
<bryce> johanbr: basically what needs to happen is to dig through the code and identify which Xrandr protocol calls are generating the problem, make a test case that reproduces the issue, and forward that upstream
<bryce> johanbr: but I think requesting a user code up a test case in C for us is probably asking much ;-)
<bryce> possibly there is a way we could gather more detailed logs or something from g-d-p, but I don't recall offhand
<johanbr> I guess running g-d-p under gdb and putting in some carefully chosen breakpoints would do the trick.
<bryce> johanbr: possibly
<bryce> johanbr: although I suspect it probably just happens during the protocol call
<bryce> might be able to dig out some state info and such, although it would be difficult to talk a user through all that in gdb
<bryce> but perhaps breaking on that call and getting a full backtrace would be doable
<bryce> it would be good to have a documented procedure on this, as there's been a few other such reports and I daresay we may be getting more in the future
<johanbr> He's new to linux, but interested in helping to resolve the bug and not afraid of reading man pages and such. I'll see what I can do.
<unggnu> I guess it is Ok to drop bulletproof. X still is very picky about things in xorg.conf but it could be easily repaired through Recovery Mode. Maybe it would be great to start X without an xorg.conf instead of Bulletproof if X couldn't start.
<unggnu> Maybe with a question after login for the admin users if the xorg.conf should be recreated like xfix does.
<unggnu> Ok, could be a loop but a simple check could prevent it. I don't know. People like their GUIs :)
<bdmurray> tjaalton: is bug 113679 specific to nvidia hardware?
<ubottu> Launchpad bug 113679 in xorg-server "xorg freezes when running openoffice" [High,Fix committed] https://launchpad.net/bugs/113679
<bryce> unggnu: yeah... ideally I'd like to replace displayconfig-gtk with something, but there's not really anything viable at the moment
<unggnu> bryce: Xfix would do the job I guess if there is not a general Xorg/vesa problem.
<bryce> unggnu: yeah that's what I'm thinking too
<bryce> another option would be to strip down displayconfig to remove the multi-screen stuff and other bits that could cause confusion
<bryce> we really don't have a good solution for the corner case of edid failures or where edid is not being provided by the monitor
<bryce> i.e., http://bugs.launchpad.net/ubuntu/+bug/edidfail
<unggnu> Would be great too for wrong edid data but afaik the conventions have changed. Modelines are ignored at lest for the intel driver. Mainly it would be a rewrite I guess.
 * bryce nods
<bryce> wow I didn't know they're ignoring modelines now
<unggnu> Afaik of course :)
<unggnu> something with PreferredMode
<unggnu> http://www.intellinuxgraphics.org/dualhead.html
<unggnu> also described here in the latest comment https://bugs.freedesktop.org/show_bug.cgi?id=14726
<ubottu> Freedesktop bug 14726 in Driver/intel "[845G] X Server fails to start with "intel" driver, works with "i810"." [Major,Resolved: fixed] 
<unggnu> bbl
<tjaalton> bdmurray: shouldn't be AFAIK
<bdmurray> tjaalton: Okay, I saw a couple of references to nvidia in it.  Is there a test case at all?
<tjaalton> bdmurray: I don't think there is an easy way to reproduce it.. we have a couple of hundred desktops (all nvidia) and don't remember anyone reporting issues with OO.o :)
<tjaalton> even with dapper
<bdmurray> hrm, that'll be interesting then
<tjaalton> apparently the fix works, since the google guys haven't seen the problem since upgrading to the version on my ppa
<bryce> unggnu: hmm I read that as meaning that the order of the resolutions is ignored, but the resolutions themselves are accepted, and I read that as modelines are still accepted
<bryce> unggnu: the issue seemed to be that the user added a mode, but couldn't get it to be taken as the default resolution in the new x server by simply listing it first in the list - he had to add it as the preferred mode
<bryce> (I could be wrong though, but that was my interpretation)
<bryce> good gem vs. ttm article:  http://lwn.net/Articles/283793/
<bryce> copy of it here:  http://pastebin.com/m1a80b77b
<tjaalton> wow, the topic suggested by Mirv :)
<unggnu> bryce: I never got Modelines working with the -intel driver but I am not sure.
<unggnu> Maybe it only accepts the modeline if preferredmode is used.
<unggnu> It seems so http://lists.freedesktop.org/archives/xorg/2008-February/032791.html but I don't understand why they use a new option for an old feature?
<tjaalton> it's randr-1.2, same thing with radeon AFAIK
<tseliot> unggnu: something like this would work:
<tseliot> Modeline "1280x1024_75.00"  138.54  1280 1368 1504 1728  1024 1025 1028 1069  -HSync +Vsync
<tseliot> ï»¿Option "PreferredMode" "1280x1024_75.00" 
<unggnu> I think so. So the tool have to add a Modeline and PreferredMode.
<bryce> unggnu: probably the xrandr changes altered how things worked internally
<unggnu> Yeah, Xorg devs are very fast forward :)
<tseliot> ï»¿bryce: thinking of the special case which you suggested in the email, we can test such case with my program, which I will keep separate from the parser, and decide which approach we should adopt.
<bryce> I think there didn't used to be the idea of a PreferredMode so adding that feature broke old behavior
<bryce> tseliot: good to hear.  it could help prevent xorg.conf's from getting chugged up with extraneous cruft (which tends to exacerbate troubleshooting issues)
<tseliot> ï»¿bryce: I would like to make both parts maintainable and easy to use so that at least the parser can be shared between different applications. We'll see how it goes...
<tseliot> tjaalton: quoting from Phoronix "NVIDIA this morning has released the 173.14.05 driver,  which marks the return to their old naming convention"
<bryce> tseliot: heh
<tseliot> tjaalton: this release supports kernel 2.6.25 therefore I will have to update the driver and drop the patch for 2.6.25 for driver 169.12
<tjaalton> tseliot: cool, it only took them a couple of months..
<unggnu> Btw. I have asked this some time ago. Is there any doc how to compile svn Intel driver for normal users without messing up their system?
<bryce> there's a few such documents but from my experience users just whine when asked to build from git
<bryce> (not that I blame them, I probably would too)
<unggnu> But upstream often asks for it.
<bryce> right
<unggnu> This time the debian sid driver works but it is not often the case afaik.
<unggnu> e.g. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/207881
<ubottu> Launchpad bug 207881 in xserver-xorg-video-intel "[Gutsy, Hardy] Black screen with mouse pointer on i830, intel driver" [Unknown,Confirmed] 
<unggnu> this one wanted a patched driver
<unggnu> I have tried it but there is one hunk.
<unggnu> +failed
<bryce> often with patches from upstream I have to recode them a little to make them patch cleanly against the driver we carry
<bryce> unggnu: tell you what, I'll take care of 207881
<unggnu> thx :)
<bryce> unggnu: btw, fyi we have the 8.04.1 cut off date coming up sunday, so what I'm working on now is looking for patches that are complete, verified, and ready for backporting to hardy
<bryce> unggnu: so if you could search around for good looking patches that look like they could be put to hardy, please assign them to me
<unggnu> Ok, what is the best way? Searching for bug reports with an upstream report and fix released?
<unggnu> Or just patches which are already in Intrepid?
<bryce> sure both
<unggnu> ok
<bryce> actually there are probably going to be exceptionally few in the latter category
<bryce> so focus on the first
<tjaalton> bryce: what was the firefox addon that allows you to open files in firefox instead of it proposing to save it first?
<bryce> my notes say "Open In Browser"
<bryce> howdy tormod
<tormod> heya bryce
<bryce> wow, don't think I've seen this many people on #ubuntu-x.  :-)
<tjaalton> bryce: hm, either I'm blind or can't find it
<bryce> maybe this?  http://www.spasche.net/mozilla/
<bryce> looks like it's only for ff2
<bryce> (I finally gave up on ff3 yesterday and reverted back to 2)
<tjaalton> damn :)
<tormod> bryce, due to the disk activity?
<bryce> tormod: yeah the periodic freeze-ups that are reportedly due to sql-lite size limits
<bryce> tormod: plus a scattering of crash issues (less common now than they used to be though)
<tormod> they need a full RDBS in there I guess
<unggnu> bryce: What should I do if there is already an assignee?
<bryce> tjaalton: hrm, didn't install onto ff2 for me
<bryce> unggnu: if it's already assigned to me, then I've already looked at it and it may already be in my queue
<unggnu> bryce: no, not you :)
<bryce> if it's assigned to the ubuntu-x swat team, you can consider those unassigned
<unggnu> bryce: bryce: this one looks good https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/211759
<ubottu> Launchpad bug 211759 in xserver-xorg-video-ati "Live-CD (7.10, 8.04) fails to start X server (ATI Xpress 1250)" [High,In progress] 
<bryce> assigned to anyone else, just mention the bug id to me here and I'll review.
<unggnu> cannonical-xorg
<tormod> when is launchpad getting per-package bug filing instructions, like attach your Xorg.log...
<bryce> ok, treat canonical-xorg to be unassigned as well; that's just a generic team assignment
<unggnu> ok
<bryce> I'm the only person in canonical-xorg anyway, so all those can just be re-assigned to me.  I don't know who added that team or why, but I don't use it
<bryce> tormod: in fact I mentioned exactly that to kiko last week at UDS during one of the "improving launchpad to improve bug reporting" sessions
<bryce> tormod: I didn't get a solid commitment to implement such a thing, but favorable noises were made, so we'll see
<tormod> bryce: excellent. but it's not like a new idea... it has been requested before I think. hope it helps this time.
<tormod> has it been decided that intrepid gets xserver 1.5 and mesa 7.1?
<bryce> tormod: this was in particular related with how to improve being able to get bugs upstreamed, which kiko is very passionate about.  I said that if launchpad could be set to require attaching Xorg.0.log to every package managed by the xorg team, it'd probably double our triaging effectiveness
<bryce> tormod: yes
<tormod> yay for that 
<tormod> can someone look at my workaround patch for bug 87661, before I ask upstream?
<ubottu> Launchpad bug 87661 in mesa "[apport] polytopes crashed with SIGILL in _mesa_x86_64_transform_points4_perspective()" [Medium,Confirmed] https://launchpad.net/bugs/87661
<bryce> tormod: looks roughly sane to me (although I didn't read the whole bug report)
<tormod> bryce: I don't know so well how 64-bit processors work with different code and kernels etc
<unggnu> bryce: I am not sure with this one. It only seems to be a dependency issue so easy fixable but I don't know ... https://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/44115
<ubottu> Launchpad bug 44115 in mesa "xserver-xorg-video-tdfx must depend of libglide3 to get 3d aceleration in 3dfx cards" [Wishlist,Confirmed] 
<tjaalton> would mean installing libglide3 on every machine
<tjaalton> not something to be done on a stable release
<tjaalton> or ever
<bryce> tjaalton: can it be closed as wontfix then
<bryce> ?
<tjaalton> imho yes
<unggnu> Or put it to suggest like in Debian
<tjaalton> it is?
<tjaalton> yes
<jibel> hi
<tjaalton> so it's the same in ubuntu too -> closing the bug
<unggnu> hi jibel
<jibel> bryce: bug 229043 is fixed in v2.3 of the intel driver. Do you known if it will be fixed in 8.04.1 or earlier ?
<ubottu> Launchpad bug 229043 in xserver-xorg-video-intel "System freezes when login out" [Undecided,Fix committed] https://launchpad.net/bugs/229043
<bryce> jibel: I'll take a look
<jibel> bryce: Thanks. I'll keep informed the reporter.
<unggnu> bryce: I guess huge patches should be integrated?
<unggnu> *shouldn't
<bryce> right
<bryce> (generally)
<unggnu> so no need for assigning?
<bryce> unggnu: right
<unggnu> hm, haven't found so much
<bryce> ok good.  I did a patrol for quirks and found only one
<unggnu> four and one seems to be dirty but was confirmed several times https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/133060
<ubottu> Launchpad bug 133060 in xserver-xorg-input-synaptics "Synaptic touchpad fails to register some of the taps for tap-to-click" [Undecided,Confirmed] 
<tormod> actually update-manager uses more memory than firefox, lol
<tormod> can I trust System Monitor - firefox only 43MB?
<tormod> I wonder if I add up those numbers and compare with "free"
<unggnu> bryce: another quirk possibility https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/201032 
<ubottu> Launchpad bug 201032 in xorg-server "[hardy][regression]xorg gets wrong screen dpi" [Unknown,Confirmed] 
<unggnu> and another one https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/200805
<ubottu> Launchpad bug 200805 in xorg-server "xorg uses laptop video BIOS 'Panel Size' for external monitors, so apps end up confined to small space in top left of screen" [Undecided,Incomplete] 
<tormod> oops that was wrong channel - time for bed QED
<unggnu> :)
<unggnu> I am not sure with them so I haven't assigned you.
<unggnu> I am off too, ciao
<bryce> excellent
#ubuntu-x 2008-05-29
<bryce> anyone know if/when debian will be packaging mesa 7.1rc1?
<bryce> aha, deb Bug#465554
<bryce> "The mesa master branch is
<bryce> probably still too much of a moving target now for us to spend too much
<bryce> time on it."
<tjaalton> hmm, tseliot not here
<tjaalton> I think it would be wise to base the split nvidia* on the debian versions, and just maintain a diff with DKMS and stuff
<tjaalton> and scrap the old LRM baggage completely
<bryce> wow
<tjaalton> hm?
<bryce> oh just that this would be a pretty profound change
<tjaalton> well, it's split anyway
<tjaalton> and the original version is from debian
<tjaalton> and diverged _a_lot_ since :)
<bryce> ah
<bryce> hey, it's sounding like gem won't be ready for intrepid, according to yong
<tjaalton> surprise
<tjaalton> hm, if we could persuade the debian nvidia maintainers to accept our patches, then debian could use jockey too
<tjaalton> currently it's not there
<tjaalton> i mean jockey not in debian
<tjaalton> tseliot: hi, I've looked at your packages and I have a suggestion :)
<tseliot> tjaalton: shoot
<tjaalton> tseliot: scrap everything, and build our diff on top of the debian packages
<tjaalton> for various reasons
<tseliot> ï»¿tjaalton: ok but they use the nvidia-kernel package
<tjaalton> we can comment that out
<tjaalton> non-issue
<tjaalton> they might be interested in DKMS btw
<tseliot> tjaalton: are we going to keep the nvidia-glx-ia32 for 64bit?
<tjaalton> and jockey, although it would have to be installed by default to be useful
<tjaalton> don't know yet
<tseliot> so you're suggesting that we try to contribute upstream
<tjaalton> we can filter whatever doesn't suit us
<tjaalton> yes
<tjaalton> they have the same bugs :)
<tseliot> not a bad idea ;)
<tjaalton> upstream being debian
<tseliot> of course
<tjaalton> they have a group on alioth, and a mailing list
<tseliot> I will keep the nvidia-modaliases packages though
<tjaalton> sure
<tjaalton> also, it might be nice to include the old changelog as changelog.Ubuntu.old or something
<tseliot> this wouldn't be a problem
<tjaalton> I don't understand what the -ia32 packages are for
<tseliot> we'll have to deal with the diversions created by both the Ubuntu lrm and the lrm-envy
<tseliot> tjaalton: the 32bit compatibility libraries for 64bit systems
<tjaalton> well, I don't see a /emul dir on my system
<tseliot> we don't have that package in Ubuntu
<tseliot> we package those libraries differently
<tjaalton> right, in /usr/lib32
<tseliot> exactly
<tseliot> the only problem which I see with taking the packages from debian (other than the effort itself) is that I don't know if they miss some library, etc. with respect to the packages which I made for envy
<tjaalton> dpkg -c will tell
<tseliot> mmm...
<tjaalton> at least they include cuda
<tseliot> and so do I
<tjaalton> lrm doesn't
<tjaalton> trust me, it'll pay off :)
<tseliot> I added the support for CUDA to my packages and a number of people depend on me for CUDA.
<tjaalton> funny that there are no bugs about adding that to lrm
<tseliot> the packages which I gave to you are in fact based on my lrm-envy
<tjaalton> since I didn't notice there was such a beast
<tjaalton> so lrm not having cuda was not intentional
<tseliot> tjaalton: it was reported in some other bug. I should have reported the problem myself
<tseliot> with a patch
<tseliot> but I have bad memory
<tjaalton> bygones
<bryce> ahhh internet back
<tseliot> bryce: congrats :-P
<tseliot> tjaalton: did you have a look at the nvidia/debian.binary of the debian package?
<tjaalton> tseliot: yes, it's newer
<tseliot> devfs.devices?
<tjaalton> as you see, the lrm version is based on an old debian version
<tjaalton> doesn't seem to be used at all
<tjaalton> so it doesn't matter
<tseliot> did  you see the nvidia-glx.init?
<tseliot> porting it to Ubuntu and adding DKMS might not be a problem but I'm not sure about the effort to maintain something which I don't know
<tseliot> enough
<tseliot> (which I don't know enough)
<tseliot> tjaalton: do you see my point?
<tjaalton> just don't use what doesn't concern us
<tjaalton> the initscript seems like a good example.. messing with the links
<tjaalton> er, no?
<tseliot> and how do I know what doesn't concern us ;) ?
<tjaalton> by auditing the package and testing things :)
<tseliot> that's what worries me most...
<tseliot> :-/
<tjaalton> bah, it's a walk in the park
<tjaalton> +like
<tseliot> a park filled with serial-killers... :-P
<tjaalton> heh
<tjaalton> I'll do a preliminary merge with 169.12
<tseliot> to tell the truth I used to deal with the debian nvidia-glx packages for envy legacy but they have changed so much...
<tseliot> wait will this replace the nvidia-glx and break Intrepid?
<tjaalton> break?
<tseliot> if a user is running Intrepid and uses nvidia-glx
<tjaalton> that would have to be solved anyway
<tseliot> oh, I forgot that the driver doesn't work if Intrepid uses kernel 2.6.25 anyway
<tjaalton> the debian version has a patch for it
<tseliot> we'll have to remove the patch and put the latest NVIDIA driver instead
<tjaalton> why?
<tseliot> because it doesn't need that patch and the output in the log doesn't look like a hacky patch was applied
<tjaalton> uh
<tseliot> I tried 2.6.25 and 169.12 with the patch on Hardy
<tjaalton> first priority is to get a package ready
<tjaalton> then maybe make it work
<tseliot> you're the expert on merges
<tseliot> I have never done any
<tjaalton> we have a version that is known, so mixing things up with a new version doesn't seem like a good idea at this point :)
<tseliot> of course, one step at a time
<tseliot> getting the package to work on Hardy would have the highest priority
<tjaalton> this is not going to get int hardy
<tjaalton> -t
<tjaalton> so why should it?
<tseliot> s/Hardy/Intrepid/
<tjaalton> after we know the contents look good
<tseliot> we definitely don't want it in Hardy
<tseliot> since a lot will change
<tjaalton> well that's a no-brainer
<tseliot> what's the deadline for merges?
<bryce> for intrepid we have months
<tseliot> I would like to make sure that I can adapt the packages for Ubuntu before we introduce a package for which I could be blamed
<tseliot> this is my concern
<tjaalton> I don't understand
<tjaalton> who else would upload these?
<tseliot> but if we have months, can you wait for me to adapt the package before you do the merge?
<tjaalton> what do you mean by "adapting"
<tseliot> removing the crap and making sense of it
<tjaalton> I'm doing that?
<tjaalton> when it's ready I'll do a debdiff so you can have a look if the DKMS stuff is ok
<tjaalton> merging your package from yesterday with the debian on
<tjaalton> *one
<tseliot> ok, now I'm lost. Are you going to do all the work?
<tjaalton> for one package, then it should be copying only
<tseliot> maybe I didn't understand what you're trying to tell me
<tjaalton> what else is there to merge :)(
<tjaalton> -(
<bryce> http://www.ubuntu-trading.com/
<tjaalton> no sound for flash -> no flash :)
<tseliot> tjaalton: let's see if I got it right. You will try to merge the package which I gave you with the one in debian and I will have to review the result. Is this correct?
<tjaalton> tseliot: correctomundo :)
<tseliot> ï»¿tjaalton: I thought you were telling me to throw away what I did and start from scratch with the debian package.
<tjaalton> tseliot: exactly :)
<tjaalton> still confused? :)
<tjaalton> ie. I'm porting our changes on top of the debian package
<tjaalton> which means throwing away all the lrm baggage
<tjaalton> and just maintain a (hopefully) small diff on top of the debian package
<tseliot> ok, let's see if it's doable. I'm curious about the result
<tseliot> doable = sensible to do so
<tseliot> now it's a bit clearer to me ;)
 * tseliot wants an Ubuntu cola
 * tjaalton wants working flash
<tjaalton> tseliot: nvidia-glx (<< 170.12+2.6.24.500-500.24), shouldn't that be nvidia-glx-new?
<tseliot> it's not necessary
<tseliot> since it provides nvidia-glx
<tjaalton> ok, I'll sort them later
<tseliot> it = nvidia-glx-new
<tjaalton> Package: nvidia-glx
<tjaalton> Conflicts: nvidia-glx-src, nvidia-xconfig, nvidia-glx
<tjaalton> :)
<tjaalton> how can a package conflict itself, hmm
<bryce> eww
<tjaalton> that's from tseliot's preliminary package, don't worry :)
<jcristau> tjaalton: policy 7.3, see "A special exception"
<bryce> *yawn*  ok, bedtime for me.  cya all tmrrw
<tjaalton> bryce: night
<tseliot> ï»¿bryce: night
<tjaalton> jcristau: oh, so it _is_ useful
<jcristau> yes
<tjaalton> hmm I should print the policy
<tjaalton> devel reference is printed already
<tseliot> tjaalton: I have to do work for the parser now. If you have questions, just ping me.
<tjaalton> k
<tjaalton> hm, the debian nvidia package is full of duplication
<tjaalton> not that it matters much, but still
<tjaalton> and the -dev package doesn't divert anything, instead conflicts with the mesa version
<tjaalton> which makes sense
<tseliot> ï»¿tjaalton: conflicts and replaces or just conflicts?
<tjaalton> conflicts
<tjaalton> no, replaces too
<tseliot> this makes sense
<tjaalton> also provides libgl-dev
<tseliot> otherwise it would just refuse to install the package
<tjaalton> so, C/R/P: libgl-dev
 * tseliot goes to have lunch
<tseliot> later
<tjaalton> seeya
<tseliot> ï»¿tjaalton: ok, so the package will replace mesa. Wouldn't this make it harder to go back to an open source driver?
<tseliot> it is also true that currently we have to reinstall mesa after we uninstall, say, the nvidia driver
<tjaalton> no, just the -dev packaeg
<tjaalton> package
<tjaalton> that's not true
<tseliot> yes, that's what I meant
<tjaalton> huh?
<tjaalton> I don't follow :)
<tjaalton> removing the diversion moves the mesa library back
<tjaalton> the dev-package does not divert, instead it conflicts with libgl-dev
<tseliot> currently we have to do something like this: sudo apt-get install --reinstall  libgl1-mesa-glx libglu1-mesa  libgl1-mesa-dri
<tjaalton> nope
<tseliot> but yes, you are referring to the -dev package
<tjaalton> at least that shouldn't be necessary
<tjaalton> no..
<tseliot> trust me, it is necessary
<tjaalton> trust me it's not
<tjaalton> libgl1-mesa-dev (which provides libgl-dev) ships only headers
<tseliot> ok, it's not but if you want mesa to work properly it is necessary
<tjaalton> no :)
<tseliot> as I said "ï»¿you are referring to the -dev package"
<tseliot> therefore it's ok
<tjaalton> it's not possible to have a mixed environment
<tjaalton> ie. mesa headers and nvidia libs
<tjaalton> or vice versa
<tseliot> we're talking about different things I guess. Let's just go ahead and pretend that nothing happened ;)
<tjaalton> ok..
<tjaalton> sigh, I'll fix the debian packaging bugs while at it
<tjaalton> duplication and some wrong paths in non-critical places
<tseliot> in my package or in the debian one?
<tjaalton> debian
<tjaalton> why would I beat the dead horse? :)
<tjaalton> (sorry)
<tseliot> :-D
<tseliot> keep in mind that now I know what you look like... be careful :-P
<tjaalton> noo.. my pretty face
<tseliot> hehehe
<jcristau> fwiw i just updated our xcompmgr package. don't know who would handle the merge on the ubuntu side.
<tjaalton> I believe it's ripe for a sync
<jcristau> ok cool
<jcristau> experimental had a very old version, so i got 1.1.4 to sid (and redid all the packaging so i wouldn't have to try to understand cdbs...)
<tjaalton> :)
<tjaalton> tseliot: ok, got halfway through, have to continue tomorrow ->
<tseliot> ï»¿tjaalton: are you trying to say that, unlike myself, you have a life and therefore you can't keep working on the package today? :-P
<tseliot> ï»¿tjaalton: seriously, no hurry here. I'm still working on the parser ;)
<tjaalton> tseliot: correct, wife and two kids waiting.. and a brother-in-law who has issues with his XP machine (duh..)
<tseliot> have a lot of fun with XP then ;) (i.e. just reinstall it)
<tjaalton> i guess it's infected by malware or something which makes it "slow"
<tjaalton> joy
<tjaalton> at least it has a linux installation too
<tseliot> if you install Norton you can make the computer slow without the malware. Yay!
<tjaalton> well, it has that too
<tseliot> LOL
<tjaalton> should be smaller than f*ck-secure
<tseliot> malware is a feature
<tjaalton> it's a brand new machine, so it only took a month to get hosed
<tseliot> heck
<maks_> where do i find current backported ati drivers for hardy?
<maks_> have a collegue with a r600 that "works" under flgrx but is only semi happy with the 6.8.0 radeon that got included in hardy
<Q-FUNK> anybody available to grab geode 2.9.0-1ubuntu3 from my PPA and push it into hardy-proposed ?
<bryce> what does this mean?
<bryce>  dpkg-genchanges  >../xserver-xorg-video-geode_2.9.0-1ubuntu2.1_amd64.changes
<bryce> dpkg-genchanges: failure: cannot read files list file: No such file or directory
<jcristau> debian/files doesn't exist?
 * bryce touches
<bryce> nope...  maybe something needs to be inside it
<bryce> no, that can't be
<jcristau> what are you trying to do?
<bryce> oh Q-FUNK posted a -geode update for hardy-proposed, so am just trying to pbuilder it
<bryce> odd; if I touch debian/files and then do dpkg-genchanges manually it works
<bryce> ah wait
<jcristau> shouldn't it be dpkg-genchanges -S then?
<bryce> hrm
<bryce> I get the same results
<bryce> what usually goes into debian/files?
<bryce> hmm interesting; after running debuild -S, debian/files gets removed
<tjaalton> it's cleaned
<jcristau> it's created by dpkg-gencontrol when you build binary packages
<bryce> here's the full output http://pastebin.com/m64214c06
<bryce> maybe the "real" error is that it's not doing anything for 'build' and 'binary'
<jcristau> heh, yeah, that looks pretty broken
<bryce> source taken from http://ppa.launchpad.net/q-funk/ubuntu/pool/main/x/xserver-xorg-video-geode/
<bryce> I get the same thing if I pbuilder the .dsc file from that url
<james_w> does it have binary-arch and binary-theotherone the wrong way around?
<bryce> not sure; it's using cdbs so it's a bit different than I'm used to
<jcristau> cdbs is black magic
<jcristau> often broken black magic, at that
 * bryce diffs against what's already in the archive
<bryce> ah, differences
<bryce> http://pastebin.com/m7a3575bf
<james_w> uh
<james_w> I don't know what problem he was having, but that's not the fix.
<bryce> hmm, something is just odd with the .dsc provided
<bryce> I'll redo from scratch; the debdiff against hardy is just a one liner
<bryce> tjaalton: can you build the .dsc at http://ppa.launchpad.net/q-funk/ubuntu/pool/main/x/xserver-xorg-video-geode/ ?
<tjaalton> bryce: heh, no
<bryce> tjaalton: ok so not just me
<bryce> tjaalton: I am also unable to build the -geode that is currently in hardy-proposed
<bryce> I've bumped it back to Q-FUNK
<bryce> tjaalton: hmm, I can't build the -geode in intrepid that's sync'd from debian either
<bryce> I suspect jcristau's last comment is correct
<tjaalton> yep, they are all hosed
<jcristau> the one on ppa seems to build fine on sid
<tjaalton> jcristau: 1u3?
<jcristau> yeah
<tjaalton> hmmh
<tjaalton> not on my hardy
<tjaalton> and why am I debugging this :)
<bryce> I've tried against both hardy and intrepid
<tjaalton> oh, I'm building on amd64
<tjaalton> don't know if that should matter
<bryce> me too
<bryce> I'll try i386
<tjaalton> yep, works there
<tjaalton> heh, control only lists i386 :)
<tjaalton> so it's fine
<bryce> ahh
<jcristau> heh
<bryce> silly me, setting up this new multi-platform multi-distro build system and then using it to confuse myself ;-)
<bryce> ok it all builds fine, I'll upload
<tjaalton> col
<tjaalton> +o
<tjaalton> I guess there's no distribution for a 486SXÂ @25MHz and "a few" MB of memory :)
<tjaalton> with some graphical UI
<jcristau> one from 10 years ago
<jcristau> ;)
<tjaalton> heh
<tjaalton> yeah I've got this ancient laptop that has W95 on it.. and my daughter somehow likes it better than my thinkpad
<tjaalton> but it feels a bit sluggish, so..
<bryce> xubuntu?
<tjaalton> no chance :)
<tjaalton> even damnsmalllinux needs at least a 486DX with 16MB
<tjaalton> and it only has a floppy drive plus "a small" HD
<bryce> tjaalton: maybe let her drink juice next to the computer?  not sure
<jcristau> or milk
<tjaalton> haha
<tjaalton> http://users.tkk.fi/~tjaalton/foo/_DSC4922_web.jpg
<tjaalton> there it is
<bryce> hehe
<bryce> lotta pink
<bryce> hey, paint your thinkpad pink
<tjaalton> the current installation has star wars in it
<tjaalton> I actually have a couple of old T2x series
<tjaalton> and pink paint!
<bryce> there you go, problem solved!
<tjaalton> indeed, need to grab one from work and start decorating
<jcristau> haha. the jamstudio driver is utterly broken
<tjaalton> and sooo popular
<tormod> tjaalton: there was this RT OS demo on a floppy, incl web browser. qix or something like that. but it's not linux.
<tjaalton> tormod: hmm that might be fun
<jcristau> #if XORG_VERSION_CURRENT >= XF86_VERSION_NUMERIC(3,9,0,0,0)
<jcristau> #define XFREE86_V4 1
<jcristau> #endif
<tormod> I think it can run on anything. but the name, anyone?
<jcristau> and then all the code is under #ifdef XFREE86_V4
<tjaalton> tormod: qnx?
<tormod> tjaalton: I guess that's right
<tormod> I been trying to build xserver 1.5 on git mesa... oh dear.
#ubuntu-x 2008-05-30
<bryce> tormod, bless you.  painful?
<tjaalton> tormod: http://www.usv.ro/ftp/pub/os/dos/browser/QNXDEMO.ZIP
<tjaalton> need to try that out some day
<tjaalton> tormod: you need the swrast stuff from xserver master
<tormod> it's the glx files moving around that kills me. actually it built fine on mesa r500-support branch, but now back on mesa trunk many things changed.
<tormod> I have to backport the swrast stuff? oh great. another day.
<tjaalton> with that you don't need to have mesa around, but I'm not sure if the problem lies there
<tormod> I am not coming that far I think. now configure complains "No package 'gl' found"
<tormod> some package should have provided gl.pc I guess
<tjaalton> hmm, getting late.. night ->
<tormod> good idea :) night
<bryce> cya tjaalton
<tjaalton> x11proto-xf86dri, libpciaccess and libfs synced
<tjaalton> and xutils-dev
<bryce> excellent
<tjaalton> filed a sync request for xcompmgr
<Ng> bryce: is the EDID info returned by our projects bogus?
<Ng> err, projectors
<bryce> Ng: nope it's good
<Ng> hmm ok, nijaba's laptop only seems to see 640x480 for it, but then it is Mac hardware ;)
<Ng> ta
<bryce> what video card?
<bryce> if it's an -nv, try rebooting with the projector attached
 * tseliot wonders why support for RandR 1.2 was added to nv only for geforce 8xxx or higher
<tjaalton> tseliot: because nvidia says proper modesetting cannot be implemented in the free driver for older chips. at least not the way they want
<tjaalton> there are some bugs marked wontfix because of this
<tjaalton> upstream
<tjaalton> I guess it would be hard to obfuscate :)
<tseliot> ï»¿tjaalton: ok but isn't it supposed to work with nouveau (whatever it's spelled)?
<tjaalton> yes
 * tseliot wonders why NVIDIA doesn't open the specs as AMD did
<tjaalton> ok, nvidia package built, now audit
<Ng> bryce: not sure, but I'll mention it
<tseliot> ï»¿tjaalton: let me know how it goes ;)
<tjaalton> tseliot: btw, you seem to add a space on your msgs quite frequently, and my irssi doesn't like that for some reason (doesn't highlight the comment)
<tjaalton> *in front of
<tseliot> tjaalton: a space???
<tjaalton> " "
<tjaalton> "space character"
<jcristau> there's a U+FEFF
<tjaalton> jcristau: what's that?
<jcristau> ZERO WIDTH NO-BREAK SPACE
<jcristau> no idea why that comes in front of tseliot's messages
<tjaalton> oh..
<Ng> annoyingly irssi doesn't understand characters not being 1 character wide
<tjaalton> I've broken my config somehow since it doesn't highlight msgs which don't have my nick as the first word
<tjaalton> jcristau: xcompmgr synced, but failed to build :)
<tjaalton> checking for XCOMPMGR... configure: error: Package requirements (xcomposite xfixes xdamage xrender) were not met:
<jcristau> hrm
<tjaalton> xext missing from build-deps?
<tjaalton> http://launchpadlibrarian.net/14818641/buildlog_ubuntu-intrepid-i386.xcompmgr_1.1.4-0.1_FAILEDTOBUILD.txt.gz
<jcristau> looks rather like a bug in libxcomposite-dev
<tjaalton> ah, ok
<jcristau> not sure why it didn't fail here
<tseliot> tjaalton: how did it go with the nvidia package?
<tseliot> I'm curious
<jcristau> tjaalton: there, fixed in 1:0.4.0-3. thanks for the notice
<tjaalton> jcristau: cool, thanks :)
<tjaalton> tseliot: still working on it
<tjaalton> was away for a couple of hours
<jcristau> aha. our libx11-dev depends on libxext-dev
<tjaalton> so it was unnecessary to add libxext-dev build-dep for libxcomposite-dev?
<jcristau> s/build-//
<tjaalton> ah, right ;)
<jcristau> and yes, that dependency was hiding the libxcomposite-dev bug
<tjaalton> bryce: you can drop fonttosfnt from the merge-page, it's not in the archive anymore :)
<jcristau> oh, you had a standalone fonttosfnt package
<tjaalton> yeah..
<jcristau> xfonts-utils ought to Replace it, then, i guess
<tjaalton> does it have that?
<tjaalton> doesn't seem like it, but it could
<tjaalton> oh!
<tjaalton> the version in ubuntu is ancient
<tjaalton> damn, how did I miss that
<tjaalton> xfonts-utils that is
<jcristau> i just added the Replaces in git
<tjaalton> ah well, the version number is deceiving, 7.4+1 is only a couple of weeks old :
<tjaalton> :)
<jcristau> yes :)
<tjaalton> I need to check that out later if it still needs a merge
<mario_limonciell> hey bryce you around?
<tjaalton> tseliot: http://users.tkk.fi/~tjaalton/dpkg/nvidia-split.debdiff
<tjaalton> gotta run, have fun :)
<tjaalton> ooh, it rhymes
<tjaalton> tseliot: it's not ready yet, but you should be able to add the missing dkms bits
<tjaalton> ->
<tseliot> ï»¿tjaalton: ok, thanks, I'll have a look at it
<tjaalton> tseliot: I didn't touch any Conflicts/Replaces stuff, so that's most likely broken atm
<tjaalton> also, that package needs an epoch, since the current nvidia-glx has one
<tjaalton> but the first goal is to get the contents right, and it's close
<tjaalton> tseliot: I assume the other modalias-packages would be named 'nvidia-modaliases-legacy-{71xx,96xx}'?
<tjaalton> mm, more beer & food. I'm so happy that the uni finally decided to use netapp filers as fileservers for everything, and not windows. it only took five years..
<tjaalton> actually the funding was already agreed upon five years ago, but fierce lobbying from the ms lovers blew the deal
<tjaalton> </offtopic> :)
<tjaalton> ->
<tseliot> ï»¿tjaalton: yes, I noticed the ï»¿Conflicts/Replaces and yes, the modaliases will have different names. There are still directories and files which we'll have to remove
<tseliot> I will wait and see the result before I touch the source package so that we don't duplicate efforts
<bryce> tjaalton: I think it'll drop automatically when we switch to Intrepid+1
<bryce> (where it == fonttosfnt)
<rom> hi
<rom> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/235982 I posted this bug report this morning with a patch
<ubottu> Launchpad bug 235982 in compiz "/usr/bin/compiz : 1 bug and 1 missing setting" [Undecided,New] 
<rom> but in fact, nvidia-settings -l should not be added in compiz launcher
<rom> a person on #ubuntu-devel said it affects nvidia-settings
<rom> package
<rom> and nvidia-settings -l may be added to /etc/X11/Xsession.d
<rom> what do you think?
<rom> hi
<bryce> heya
<bryce> tjaalton: I think I've done all the 8.04.1 sru's I'm going to do, most of the rest of the stuff I see needs more testing anyway, and a lot probably isn't appropriate for sru'ing
<bryce> tjaalton: I'm turning focus now to getting blueprints written up which I think will just take a few days.  Then full speed ahead with intrepid
<bryce> I figure we should start with getting driver merges done (I need to do -intel...  -ati probably could also benefit from being done soonish)
<bryce> it'd be nice to have some of the big pieces done before june/july since you'll be gone (and I'll be out much of that time too)
<tseliot> ï»¿bryce: where's tjaalton going?
<bryce> tseliot: vacation
<tseliot> ah, ok
<tseliot> ï»¿bryce: by the way, the xorg parser is almost complete
<bryce> awesome
<tseliot> and seems to work well
<tseliot> I hope it can replace guidance ;)
<bryce> tseliot: cool, we'll need a blueprint on that too.  I'll have some time next week for it.  Meanwhile I put in an empty one on blueprints.launchpad.net.
<rom> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/235982 I reported this bug, with a patch, but actually, nvidia-settings -l should be done elsewhere
<ubottu> Launchpad bug 235982 in compiz "/usr/bin/compiz : 1 bug and 1 missing setting" [Undecided,New] 
<rom> maybe /etc/X11/Xsession.d
<rom> what do you think?
<tseliot> ï»¿bryce: ok, great
<tseliot> ï»¿rom: try asking in #ubuntu-devel . Maybe ask Amaranth about it
<rom> I asked in #ubuntu-devel, someone tell me to ask in ubuntu-
<rom> x
<rom> :)
<tseliot> rom: that affects compiz
<rom> in fact, no
<rom> all the opengl applications
<tseliot> your patch does
<rom> yes my patch does
<rom> but nvidia-settings -l should not be done in compiz
<rom> but should be independant
<rom> (even if of course, it works if I put it in compiz)
<rom> where do you think it's possible to launch nvidia-settings -l
<rom> "the right place"?
<tseliot> as a temporary fix you might add it to your gnome-session, kde-session, etc.
<tseliot> In GNOME you can do it by selecting System -> Preferences -> Sessions -> Startup Programs 
<tseliot> just add this command:
<rom> yes... but... as a not temporary fix (my temporary fix is to do it in compiz)
<tseliot> nvidia-settings --load-config-only
<rom> :)
<rom> to correct the problem in ubuntu repositories
<tseliot> I'll think about it. I must leave now.
<rom> ok good night :)
#ubuntu-x 2008-05-31
<superm1> bryce, i had to duck out earlier before i caught you.  are you around now by chance?
<bryce> yup
<superm1> i was gonna let you know that i talked to AMD about how to get proprietary drivers to take precedence in X auto detection
<superm1> they indicated that simply shipping a /usr/share/xserver-xorg/pci/00fglrx.ids (and similar for nvidia) should do the trick
<superm1> so long as those are shipped in the appropriate driver packages (since you only want them in those cases), should work
<bryce> ah ok
<superm1> i'm at a bit of a loss how exactly the name gets put into it, but i'll do some experimenting with it next week
<superm1> so long as it works right (and you're cool with the idea of putting that in the packages), i'll add it in
<bryce> I'm not really sure, I'd need to consider it more closely.  I'd especially like to get timo's opinion on it.
<superm1> ok, then its good i brought it up before just "doing that".  i'll touch bases with you after i get a chance to make sure it works properly
<bryce> ok great
<tjaalton> bryce: cool, I should've done something for mesa, but didn't..
<tjaalton> but there's life beyond .1
<jcristau> superm1: that won't work i think, it'll load the '00fglrx' driver
<superm1> jcristau, yeah that's what i was thinking too.  perhaps it will have to be diverting the ati driver and using fglrx.ids then
<superm1> i'll see what happens for me when i start to try it
<jcristau> ewww diversions
#ubuntu-x 2008-06-01
<Q-FUNK> seems that I was loaned an OLPC to check that the geode driver would eventually work correctly on their hardware.
#ubuntu-x 2009-05-25
<Guest21892> hi, guys.  i upgraded to jaunty and enabled the proprietary ati driver and now my x is borked.  can you help me fix it, please?
<crevette> Guest21892: trying booting the safe mode
<crevette> there is a menu to fix the X configuration
<Guest21892> crevette: there is no safe mode in jaunty.  it gives an option to fix x but that didint' do it.
<Guest21892> crevette: i meant there's no safe mode for x.
<crevette> ah
<Guest21892> i'm in irssi now.  how do i switch between rooms?
<crevette> humm, I didn't used irssi for years ...
<jcristau> Guest21892: ^n ^p, /window, alt-N, ...
<Guest21892> jcristau: that worked.  thank you.
<Guest21892> does anyone have any ideas about disabling the ati driver?
<tjaalton> dpkg --purge xorg-driver-fglrx
<Guest21892> tjaalton: that will disable the proprietary driver enabled?
<tjaalton> Guest21892: it will purge it from your system
<Guest21892> tjaalton: thanks!!!  i'll try it.
<Guest21892> tjaalton: ok.  i purged the ati driver.  now when i startx i get a message saying 'no screens found'.
<tjaalton> put the logfile somewhere
<tjaalton> but first make sure /etc/X11/xorg.conf is sane.. move it aside and try without one
<Guest21892> tjaalton: ok:  pastebin.com/f267af216
<tjaalton> how did you end up with the radeonhd driver?
<Guest21892> tjaalton: i don't know what you mean by move it aside.
<tjaalton> rename it, but it doesn't matter here
<tjaalton> it's probably empty anyway
<Guest21892> someone in #ubuntu told me to try it.
<tjaalton> right
<tjaalton> so dpkg --purge xserver-xorg-video-radeonhd then
<tjaalton> I guess that'll make it work again, if you managed to install it in the first place..
<tjaalton> jaunty on your system, that is
<Guest21892> i upgraded to jaunty, everything was ok, then i enabled the ati driver, that's when things went bad. 
<Guest21892> after i purge do i have to change my xorg.conf?
<tjaalton> I don't think it supports that device
<tjaalton> anymore
<tjaalton> no
<Guest21892> ok.  i'll try.  thanks.
<tjaalton> neither does radeonhd for that matter
<tjaalton> but -radeon does
<Guest21892> should i install radeon?
<tjaalton> it should be installed
<tjaalton> by default
<Guest21892> ok.  i'll try startx.  wish me luck.
<binMonkey> tjaalton: ok.  i did what you said and now x comes up but my keyboard, mouse, and touchpad don't work.
<tjaalton> binMonkey: same deal, logfile thanks
<binMonkey> i am jazzed that at least i get a gui up.
<binMonkey> ok.  thanks.
<binMonkey> tjaalton: ok, here it is:  pastebin.com/f457e6482
<binMonkey> tjaalton: if it matters, i tried dpkg-reconfigure xserver-xorg.
<tjaalton> it does nothing of interest
<tjaalton> try rebooting
<tjaalton> or restart HAL and try again
<tjaalton> and remove the fglrx module (rmmod fglrx)
<binMonkey> how do i restart hal?
<tjaalton> just reboot ;)
<binMonkey> ok.  wish me luck.
<binMonkey> WOOOOOTTT!!!!!!!!
<binMonkey> tjaalton: it's working.
<binMonkey> THANKS A MILLION FOR YOUR HELP!
<tjaalton> np
<tjaalton> don't break it again
<binMonkey> i won't.  i hate to be a pest, but is there a driver for the 200m that i can use in jaunty?
<tjaalton> you already have it
<binMonkey> the radeon?
<tjaalton> yes
<tjaalton> what more do you want?
<tjaalton> it's the only one supporting your device
<binMonkey> ok.  i guess i should be thankful.
<binMonkey> and i am.
<tjaalton> I'm pretty sure that the restricted manager didn't suggest to install fglrx and you forced the install, am I right?
<binMonkey> i'm not sure.  i used 'hardware drivers' in the main menu.
<tjaalton> what does it say now?
<binMonkey> hold on.
<binMonkey> i see what you're saying.  i did ignore the warning.
<binMonkey> but it did work really well in 8.10.
<jcristau> but you're not using 8.10 anymore
<tjaalton> I don't think it should even offer it
<binMonkey> yeah.  i just didn't know that jaunty didn't support it.  had i known...
<tjaalton> what does the warning say?
<binMonkey> this is my old laptop that i'm using.  can i change a video card without having to worry about other hardware?
<tjaalton> umm, laptop?
<tjaalton> no
<tjaalton> it's built-in
<binMonkey> i closed it but it was something like 'these drivers have no public source code. they represent a risk, ubuntu cannot fix them, etc.'
<tjaalton> that's a generic warning
<binMonkey> dang.  i guess the only game i'll play for a while is nethack.
<tjaalton> file a bug, by running 'ubuntu-bug restricted-manager'
<tjaalton> it shouldn't offer the driver at all
<tjaalton> the free driver should support 3D just fine
<binMonkey> i think i agree.  especially if it's not supported.
<binMonkey> i tried googleearth.  it's a little jerky but i can live with it.
<binMonkey> youtube looks ok.
<binMonkey> i got two good things out of this:  i learned about pastebinit and i learned a little bit about screen.
<binMonkey> thanks again for the help.  have a good night.
 * bryce_ waves
<tjaalton> o/
<bryce_> tjaalton: btw pitti said that 2.7.1 caused some freeze issues and a kernel panic on his laptop; he'll file a bug this evening and we'll chat with jbarnes_BCN when we see him
<tjaalton> bryce_: ah, ok..
<tjaalton> has worked fine here, but IIRC he has a 945
<bryce_> tjaalton: looking at the changelogs, seems most likely to be something in the upstream code; the debian and ubuntu packaging sounds pretty sane, so guessing it's one of keith's patches, but really hard to say
<tjaalton> bryce_: btw, in case you missed it.. debian dropped the pci-ids patch, and it pointed out a flaw in the xserver patch 143_default_to_vesa. I've disabled that one for now
<bryce_> yep, saw that
<tjaalton> ok, good
<bryce_> tjaalton: there was one person who said his hardware got misdetected as -vesa with that change
<bryce_> encouraged him to file a bug
<tjaalton> also, there are a bunch of upstreamable patches in the xserver, have you planned to push those?
<bryce_> probably should go upstream
<bryce_> you mean the little segfault fixes?
<bryce_> generally all of those that I did at least have a bug reported upstream
<tjaalton> yeah, those ones. at least they weren't in 1.6.1.901, might be in master
<bryce_> well, I'd found that upstream (i.e. whot) didn't like the approach I was using to solve them
<bryce_> usptream would rather leave the crash in until the root cause was solved, and not just paper over the issue
<tjaalton> oh, right..
<bryce_> in the distro though, I was happy to paper over the issue since crashing is bad ;-)
<bryce_> so... I made sure the bugs were registered upstream but didn't bother putting in the patch if I thought upstream would rather figure out the root cause than paper over.
<tjaalton> yeah
<bryce_> in one or two cases they did that, and the better patches are already upstream
<bryce_> I chatted with pitti about this approach, and he agreed it was better for us to stop the crashing than to wait for the final solution
<tjaalton> yep, makes sense
<bryce_> I hope to have more time this release to do more of these.  We've got a ton of crash reports that could probably be solved this way
<tjaalton> I haven't done much bug triaging for a while, but I've seen the bug count getting higher again..
<bryce_> tjaalton: indeed, I'm worried it's going to get out of control again
<CShadowRun> Is it possible to run 2 seperate X servers (not screens) on 2 heads, on 2 graphics cards?
<jcristau> in theory, yes
<CShadowRun> any more information i can gleam on that?
<jcristau> google for multiseat
<CShadowRun> i currently use seperate X screens and the bugs make me want to hurt people, i figure completely seperate X screens might be better
<CShadowRun> ah, i don't exactly want multiseat though, but i admit its close
<CShadowRun> i only want one mouse/keyboard
<CShadowRun> i guess that's a good starting point though, thanks
<jcristau> err. with only one mouse/kbd, how do you think this can work?
<CShadowRun> hopefully by moving my mouse across (similar to multiple X screens)
<CShadowRun> but obviously not moving windows across
<jcristau> well. no.
<CShadowRun> why not?
<CShadowRun> there must be some way of switching what seat your on
<tjaalton> the seats have their own mouse/keyboard..
<CShadowRun> what happens if you try when you only have 1 keyboard/mouse?
<tjaalton> then you have no mouse/keyboard on the other head
<CShadowRun> and theres no way to switch which keyboard/mouse controls which head?
<CShadowRun> even if there is no way to switch, i can still do it
<CShadowRun> could use synergy (It's like a KVM switch, but software, and without the video switch)
<CShadowRun> and just tell it that the networked computer is localhost \o/
<CShadowRun> any other ideas/suggestions about it?
<tjaalton> not that I know of
<CShadowRun> hehe
<CShadowRun> the reason is because i actually want to run the DE (in my case gnome) twice, completely seperately
<CShadowRun> because the way gnome handles multi X screens is appauling and nobodys going to fix it, and i'm fed up with waiting :)
<CShadowRun> most DE's suffer from the same issues, though
<jcristau> you could fix it yourself...
<CShadowRun> i had a look at the code, but not being a C programmer i couldn't even figure out what file i was supposed to look in
<CShadowRun> and the bug report is 3 years old, and the developer is "too busy" so, this seems like the next best bet really
<tjaalton> bryce_: you seem to have something left to push to xorg.git
<tjaalton> the changes in 5ubuntu20
<bryce_> tjaalton: nope
<tjaalton> oh
<tjaalton> something is wrong on my end
<tjaalton> ah, there it is
<bryce_> tjaalton: ideas on if removing x's hal dependency is feasible in karmic's timeframe?
<tjaalton> bryce_: are you on the "improving boot speed" session?-)
<tjaalton> just lost the stream
<bryce_> yes
<tjaalton> I haven't looked at how to use dbus directly, the xserver supports that
<tjaalton> don't know if there are limitations
<bryce_> scott was suggesting keith was looking at using udev in place of hal
<tjaalton> oh, even lower
<bryce_> he had also mentioned that kms would help move a chunk of startup time out
<tjaalton> yes
<bryce_> that'd run earlier on during kernel startup, in parallel with module startup
<bryce_> guess we ought to resurrect the timing patch (and fix the hang bugs that were in it)
<bryce_> end of session
<tjaalton> yeah, got the stream back just in time for that
<jcristau> using udev directly means losing solaris and bsds, so i'm not sure how that can fly upstream..
<tjaalton> true
<crevette> hal is going to be deprecated anyway ....
<jcristau> crevette: well if there's no sensible replacement..
<jcristau> http://lists.freedesktop.org/pipermail/xorg/2009-May/045590.html
<crevette> jcristau: the deal is to use libudev apparently and others have to find their solutions
<jcristau> crevette: and i'm saying that 'use libudev' is not a sensible replacement
<crevette> adn DeviceKit is a daed-end too :)
<bryce_> jcristau, #ifdef __LINUX ?
<jcristau> bryce_: that's where an abstraction layer comes in
<binMonkey> hi, guys.  after some drama last night that tjaalton helped me fix, i've become obsessed with my ati 200m card.  if i post my xorg.conf can you guys tell me what to do to speed it up a little?
#ubuntu-x 2009-05-26
 * bryce_ waves
<tjaalton> hey bryce_, I'll be around during the "karmic plans" and "nvidia driver" sessions
<bryce_> ok, hopefully audio|video will work
<tjaalton> audio has worked this morning, there doesn't seem to be a videostream available
<tjaalton> so, fingers crossed
<bryce_> tjaalton: do you have any items that should be brought up for "karmic plans"?
<bryce_> brb
<tjaalton> well, do we plan to include xserver 1.7 (with XI2/XKB2), what about r6/7xx DRI if it arrives "early enough" ..
<bryce_> ok
<tjaalton> I hear pitti talking
<tjaalton> about KMS
<mnem0> tjaalton: is that bryce now?
<tjaalton> yep :)
<mnem0> heh cool :)
<tjaalton> bryce_: is there a gobby document?
<bryce_> tjaalton: ah right.  gobby has been inconsistent
<tjaalton> tell me about it...
<bryce_> are you getting audio okay?
<tjaalton> yep
<tjaalton> four listeners, spot #1 ;)
<tjaalton> bryce_: ttm is the other way around AIUI, gem is geared towards integrated chips like intel and via ;)
<mnem0> tjaalton, bryce: what was the "answer" someone mentioned for knowing the most common hardware out there? is there a good way for ubuntu to know that?
<tjaalton> I missed that
<bryce_> jbarnes: http://people.ubuntu.com/~bryce/dri.pc
#ubuntu-x 2009-05-27
<bryce_> heya jbarnes_BCN
<jbarnes_BCN> bryce_: morning
<jbarnes_BCN> where are you?
<bryce_> jbarnes_BCN: in the business center room
<bryce_> jbarnes_BCN: will be there this next session too
<bryce_> https://bugs.edge.launchpad.net/ubuntu/+source/libxcb/+bug/277069
<ubottu> Ubuntu bug 277069 in libx11 "Slow performance with remote X applications (java, firefox/xul, etc.)" [Unknown,In progress]
<bryce_> jbarnes_BCN: http://kernel.ubuntu.com/~kernel-ppa/mainline
<bryce_> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bugs?field.searchtext=&orderby=-importance&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.status_upstream=open_upstream&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=&field.tags_combin
<bryce_> ator=ANY&search=Search
<bryce_> http://tinyurl.com/pdg8jj
<jbarnes_BCN> dc12c4b3eb297b2f225409eacf1f3cd521453ab6 has the dri1 sarea fix
<bryce_> jbarnes: quirk https://bugs.freedesktop.org/show_bug.cgi?id=21960
<ubottu> Freedesktop bug 21960 in Driver/intel "HP Mini needs lid-close quirk" [Major,New]
<tjaalton> bryce_: I overheard the discussion after the nvidia session yesterday ;)
<bryce_> tjaalton: yeah...
<jbarnes_BCN> bryce_: I guess that issue can't be reproduced with vt switch?
<tjaalton> bryce_: there was some discussion on #xorg-devel about hal/libudev
<tjaalton> ..this morning
<tjaalton> apparently krh had plans to port it to libudev, but it's unknown when that might happen
<bryce_> tjaalton: it == xinput?
<tjaalton> xserver
<bryce_> tjaalton: gotcha
<tjaalton> might not make it before the feature freeze of 1.7
<bryce_> tjaalton: in the discussions about boot time improvements, there is already the assumption going around that hal is going away.  you probably already heard that
<tjaalton> which is now 22nd of June
<tjaalton> yeah
<bryce_> hmm
<bryce_> I'm sketchy on the idea of backporting that if it doesn't make it into 1.7, but I guess that is within the realm of sanity
<bryce_> assuming it's not too terribly buggy
<tjaalton> we'll see
<superm1> well there is another missing piece that will prevent hal from going away yet
<superm1> killswitch stuff lives in hal too and doesn't have a new home
<crevette> hey superm1 
<superm1> hi crevette 
<crevette> superm1, as you seem to manage bluez bits I wanted to talk to you.
<superm1> crevette, what abouts?
<crevette> superm1, would you be interested to start bluetoothd daemon only on demand
<superm1> crevette, that's a question you should ask upstream
<superm1> crevette, i dont think that is the kind of delta ubuntu should add/carry
<crevette> redhat has a feature to start bluetoothd only when a device is plugged/present
<superm1> how is that detected though?
<crevette> superm1, this is really simple, an udev rule to start init.d script
<superm1> crevette, what if hci0 shows up, issue a start command?
<crevette> http://cvs.fedoraproject.org/viewvc/devel/bluez/97-bluetooth-ondemand.rules?revision=1.1&view=markup
<superm1> yeah that sounds like a good patch
<superm1> can you submit it upstream?
<crevette> I think Bastien should do it as the patch was developped by RedHat
<superm1> can you ping him then to do so?
<crevette> the delta is the init.d scripts
<superm1> just to make sure upstream agrees, then we can pull it in
<crevette> the one shipped by bluez is not used by ubuntu or rh
<crevette> it is really too simple
<crevette> I made a patch, but I'm not sure the initd script is right or not
<crevette> superm1, woudl you be interested to test it ?
<crevette> I can attach to a bug tonight once I'm at home
<crevette> and perhaps create a ppa package
<superm1> crevette, sure i can take a look after UDS, i just would rather that we get upstream to pick this up this early in the cycle
<crevette> ah you're at UDS
<bryce_> heya andresmujica
<andresmujica> heya bryce!!  jar jar jar 
<bryce_> andresmujica: I'm in the room behind you :-)
<andresmujica> what's up
<bryce_> nada
<andresmujica> what room is that? what kind of bussiness!?
<bryce_> Ubuntu business :-)
<tseliot1> jbarnes_BCN: are you around?
<tseliot1> I'm in room D6
<jbarnes_BCN> tseliot1: ok I'll come over
<tseliot1> thanks
<bryce_> jbarnes: btw don't forget 6:30 in hotel lobby for time with kernel team
#ubuntu-x 2009-05-28
<bryce_> apw: posted email on kms to ubuntu-devel@
<tjaalton> bryce_: has jbarnes left UDS already?
 * hyperair thinks KMS is the best thing that ever happened to the intel driver =D
<bryce_> tjaalton: no, he leaves tomorrow
<bryce_> tjaalton: however I've not seen him so far this morning.  Maybe he's sleeping in.
<tjaalton> bryce_: heh, could be
<tjaalton> there was just a question I had
<jcristau> lp 377875 is weird. would be nice to have the guy's dmesg
<bryce_> I'll direct him here if/when I see him
<ubottu> Launchpad bug 377875 in xserver-xorg-video-intel "[945G/GZ] Kubuntu: no direct rendering (KMS bug)" [High,Incomplete] https://launchpad.net/bugs/377875
<bryce_> we have a session after lunch for doing more bug triage
<bryce_> jcristau: yeah; it's the one bug so far reported against KMS, however sounds like maybe just a futzed up config
<jcristau> bryce_: yeah i was following the links from your kms mail :)
<jcristau> i need to get a .30-rc kernel..
<bryce_> yep
<bryce_> fwiw, .30 seems to be a kickass improvement over .28 all around
<bryce_> well, for -intel I mean
<jcristau> .30 got the bugfixes from f11 testing :)
<bryce_> there he is
<bryce_> jbarnes_BCN: tjaalton had a question for you
<jbarnes_BCN> tjaalton: hi
<tjaalton> jbarnes_BCN: hi, I'll finish this ice cream first ;)
<bryce_> tjaalton: hurry, almost lunch time :-)
<Sarvatt> i have a feeling that guy is just not adding intel_agp and drm before i915 in his /etc/initramfs-tools/modules like you need to do when you go that route..
<tjaalton> bryce_: just had mine :)
<tjaalton> jbarnes_BCN: we have a bunch of new fujitsu desktops with built-in G33/35, and some of them blank every now and then for a second or two
<tjaalton> running 9.04
<tjaalton> and I've had that same on my laptop a couple of times with karmic
<jcristau> Sarvatt: update-initramfs should do that for him though
<tjaalton> jbarnes_BCN: on the fujitsus it happens even on the gdm login screen, and sometimes very frequently. Is it due to failing hardware or something in the driver? going back 2.6.3 -> 2.4 didn't help
<jbarnes_BCN> tjaalton: probably driver...
<jbarnes_BCN> tjaalton: lemme dig up a bug # and patch for you to test
<Sarvatt> it doesn't for me on ubuntu, maybe a change in initramfs-tools in debian?
<Sarvatt> 0.92bubuntu30
<tjaalton> jcristau: cool, thanks
<jcristau> Sarvatt: let me check
<jcristau> tjaalton: itym jbarnes ;)
<tjaalton> uh
<tjaalton> lazy tab-complete
<jcristau> Sarvatt: looks like 0.93.2 added agp modules to the initramfs. and the next upload will add i915 (and thus drm)
<jbarnes_BCN> https://bugs.freedesktop.org/show_bug.cgi?id=19304 has a test patch to address some fifo underruns
<ubottu> Freedesktop bug 19304 in Driver/intel "[i945 FBC] spontaneous black screen (major pipe-A underrun)" [Major,Assigned]
<jbarnes_BCN> it'll also print some output to the log if an underrun occurs
<tjaalton> hmm, AIUI it doesn't log anything
<jbarnes_BCN> only the old driver would log anything
<jbarnes_BCN> if 2.4 doesn't show pipe underruns, then it could be something else
<tjaalton> ah, ok
<tjaalton> right, I'll add the patch and try
<jcristau> Sarvatt: also i think the driver was fixed for some kms failure when i915 wasn't loaded before X startup, so that may help too
<Sarvatt> yep I'm 100% convinced that is his problem in lp 377875\
<ubottu> Launchpad bug 377875 in xserver-xorg-video-intel "[945G/GZ] Kubuntu: no direct rendering (KMS bug)" [High,Incomplete] https://launchpad.net/bugs/377875
<Sarvatt> I just added only i915 to my /etc/initramfs-tools/modules and I get the exact same error
<jcristau> Sarvatt: good :)
<Sarvatt> http://sarvatt.com/downloads/Xorg.txt
<Sarvatt> cant open drm, falls back to swrast
<jcristau> so that should be fixed with either new initramfs-tools or new driver
<Sarvatt> we're both using the latest driver, need initramfs-tools for sure
<Sarvatt> [    4.469436] [drm:drm_fill_in_dev] *ERROR* Cannot initialize the agpgart module.
<Sarvatt> then it loads intel_agp after that
<jcristau> using kms on .30-rc7 with ddx 2.7.99.1 now. looks pretty good.
<Sarvatt> there's a update drm-intel that fixes the font corruption/swap problem now too
<jcristau> yeah i know
<Ng> bryce_: kms is tempting me to upgrade my laptop to karmic, really quite horribly much ;)
<bryce_> Ng: do it :-)
<Ng> I wonder if I can do it from archive.conference, but still use update-manager
<Ng> I think I'll start with the jaunty test option
<Ng> mmm, high res consoles
<Ng> there's still some flickering when starting X though!
<Ng> weirdly, the i915.modeset=1 option on the kernel cmdline whined about it being unknown. I thought ordering there didn't matter? (I just put it on the end after quiet splash)
<Sarvatt> bryce: just a note for the wiki that i've edited a few times, you never need to manually enable UXA in xorg.conf on any driver, KMS always only uses UXA
 * Ng tries a suspend/resume cycle
<Sarvatt> even if you have EXA picked in xorg.conf it'll ignore it and use UXA instead, no need for the extra step
<Ng> I was promised faster resume! It's the same ;)
<jcristau> Ng: the kernel complains about the option (because at that time i915 isn't loaded yet), but it works anyway
<Ng> ah
<Ng> will we want to move i915 really early in the initramfs so the kernel modes are there for the majority of the boot?
<tjaalton> probably not
<tjaalton> AIUI
<Ng> doesn't that mean the usplash screen will resize?
<tjaalton> because the boot will be fast enough anyway
<tjaalton> don't know
<Sarvatt> breaks the usplash progress bar doing that or building it in the kernel right now
<jcristau> can usplash die kthx
<tjaalton> could be that even plymouth is "too heavy"
<Ng> ok I take it back, usplash appears to be unaffected
<Ng> tjaalton: our target boot time on a Dell mini9 for 10.04 is 10 seconds. Barely seems worth showing more than a spinny thing ;)
<Ng> so chvt X->Console is instant, but going Console->X has a couple of flickers
<Ng> (on jaunty with a karmic KMS kernel)
<Sarvatt> thats fixed in xorg-server 1.6.1.901
<Ng> \o/
<Sarvatt> its in xorg-edgers
<Sarvatt> or karmic :D
<Ng> I'm off work next week and I was going to re-install my laptop with 64bit anyway, so I can do karmic then
<Ng> seems a bit silly to risk nuking my OS on the penultimate day of UDS ;)
<tjaalton> sounds like a plan to me ;)
<Ng> hehe
<jcristau> Sarvatt: or sid ;)
<Ng> sid schmid! ;)
 * Ng wanders off to his next session
<andresmujica> ping bryce
<andresmujica> ping again bryce
<mdz> bryce_: WELCOME BACK
<bryce_> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.status_upstream=hide_upstream&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_pa
<bryce_> tch.used=&field.has_cve.used=&field.tag=&field.tags_combinator=ANY&search=Search
<jcristau> wow. that's like a gitweb url, except worse
<bryce_> indeed :-)
<andresmujica> http://launchpadlibrarian.net/22029875/Screenshot.png
<andresmujica> http://launchpadlibrarian.net/26349077/Evince-garbled.png
<andresmujica> bug #326008
<ubottu> Launchpad bug 326008 in xserver-xorg-video-intel "screen does not redraw properly" [Undecided,Confirmed] https://launchpad.net/bugs/326008
<andresmujica> 1st one
<tjaalton> jbarnes_BCN: the patch didn't help :/
<tjaalton> jbarnes_BCN: next we'll try another display card to rule out a broken monitor or such
<bryce_> heya tjaalton, we're doing X bug triaging for a couple sessions
<Sarvatt> if anyone wants a kernel to test out the swap related font/glyph corruption fix for intel/UXA -- http://sarvatt.com/downloads/2.6.30-rc7-sarvatt2/
<bryce_> slangasek: https://wiki.ubuntu.com/X/Triaging
<Sarvatt> need xorg-edgers to go with it
<tjaalton> bryce_: have fun :)
<tjaalton> karmic didn't provide audio for my laptop, so I can't listen to you ;)
<tjaalton> Sarvatt: is it the "funny characters in firefox" -bug?
<Sarvatt> yup!
<tjaalton> ok..
<tjaalton> affects only lwn.net and linuxtoday.com here
<tjaalton> wonder why
<bryce_> tjaalton: don't think we have mikes anyway
<bryce_> https://launchpad.net/~ubuntu-x-swat/+archive/x-freeze-test
<Sarvatt> Question for later when people aren't busy: do you guys have any plans regarding xserver-xorg-video-intel 2.7.99.1 in karmic? I would just like to suggest not just syncing debian-experimental because there have been so many fixes past that release from when they first dropped EXA/XAA. the fixes from 2.7.0 to 2.7.1 aren't even in it.
<bryce_> Sarvatt: yeah I was planning on merging it in after UDS, next week
<bryce_> Sarvatt: I was thinking using a git snapshot - maybe what you stuck in edgers, if you think that's sane
<Sarvatt> for sure, I would muuuuuch rather use 2.7.1 than the tagged 2.7.99.1 release thats in debian-experimental right now, the desktop didn't stabilize in UXA for me until around may 2nd (about a week after 2.7.99.1 tag) and there have been so many fixes since then like the firefox hangs that 100% of people using UXA hit on specific websites and all the "random crash" stability fixes that went into 2.7.1. of course libdrm needs to be updated
<Sarvatt>  too, part of the firefox hang fix is post 2.4.11 so a git version of that would be needed too
<Sarvatt> oh, a fix so that nouveau compiles on 2.6.30 just went into mesa/drm too
<jbarnes_BCN> http://www.gossamer-threads.com/lists/linux/kernel/1081109?page=last
<jbarnes_BCN> PAE patch ^^
<Sarvatt> jbarnes: gotten any feedback on that cursor flicker patch?
<Sarvatt> talked to a few people using xorg-edgers since i started adding to it right after you posted it, on my 945GME and 3 people on 965 it does get rid of the constant flicker that was there without it, but it makes the animated cursor corruption that's always happened more prominant. every few seconds randomly it'll break the animation and the cursor disappears, sometimes theres green colored garbage in a box around the cursor. it's there w
<Sarvatt> ithout the patch too only less noticable because its constantly flickering on and off without anyway
<Sarvatt> don't think theres any 32 bit PAE kernels shipped by ubuntu anymore since 2.6.28
<jbarnes_BCN> http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=07f4f3e8a24138ca2f3650723d670df25687cd05
<jbarnes_BCN> apw: can we get a kernel with that patch (actually a drm-intel based kernel would be even better)
<bryce_> Sarvatt: huh
<bryce_> Sarvatt: so sounds like a newer git of 2.7.99.1 would make sense to pull in?  Any plans to update the snapshot in xorg-edgers?
<jcristau> do you know who's handling the 2.8 release process?
<Sarvatt> i update it almost every commit, so depends on what gets pushed there :) you'd probably want to add the quirk patches from the current one and drop the 101_kms_cursor_flicker.patch I add to it though
<jbarnes_BCN> jcristau: cworth is doing it again
<jcristau> jbarnes_BCN: ok
<Sarvatt> bryce: I think it'd make *alot* of sense, would have to update libdrm too though newer than the tagged 2.4.11 because part of the firefox crash fix is in there and that affected everyone using UXA as far as I know. didn't talk to a single person that could go to the websites in the bug report without it hanging them (happens in 2.7.1 UXA too)
<bryce_> Sarvatt: yeah that sounds like something we'd want to pull
<Sarvatt> jbarnes: it's not 100% to the ubuntu config, but if you need a deb to test real quick I've got one here http://sarvatt.com/downloads/2.6.30-rc7-sarvatt2
<Sarvatt> changes from the config were enabling pcie aspm and memory stick, anticipatory default, core2 arch generic tune, KMS built in and default instead of a module, git log of what i pulled on top of linux-2.6 last night here - http://sarvatt.com/git/cgit.cgi/linux/log/?h=2.6.30-rc7-sarvatt2
<bryce_> l8r
<Ng> so with KMS can the resume scripts not have to do the chvt dancing?
<jcristau> yes
<Ng> I guess that's why my resume isn't any quicker, it doesn't know that :)
<jcristau> does here.
<Ng> (I'm running jaunty still, just with the newer kernel and driver)
<tjaalton> it's quicker in karmic
<Sarvatt> Ng, does your  /usr/lib/pm-utils/sleep.d/98smart-kernel-video have the have_kms() section around line 40?
<jcristau> Sarvatt: that was added recently i'd be surprised if jaunty had that
<Ng> line 40 here is in smart_kernel_fglrx
<Ng> my intel section has nothing about kms
<tjaalton> yeah, karmic has that
<Sarvatt> ah yeah that checks for kms and does add_parameters --quirk-no-chvt on karmic
<Sarvatt> Ng, put an updated pm-utils up here since i didnt have any other jaunty packages in the PPA. https://edge.launchpad.net/~sarvatt/+archive/xorg-testing working fine with no flicker on resume and its back up in 2 seconds in KMS on a jaunty machine I just tested it on just incase you want it :)
<Sarvatt> its just karmic's renumbered 0ubuntu0 so it'll get overwritten when you upgrade
<Ng> Sarvatt: aha :)
<Ng> I'm reading terminfo man pages, but when I get done with that, I'll go back to playing ;)
<Sarvatt> ahh yeah, about that 2.6.30-rc7-sarvatt2 kernel, i also enabled mtrr cleanup with 1 spare reg because its required for my aspire one to have an open mtrr for video.. these darn things have all 8 full with junk by default
<jbarnes_BCN> bryce_: coming for vino tinto?
<jbarnes_BCN> I've got a bunch of free wine in 1205, invitation is open
<bryce_> jbarnes_BCN: no answer at the door; everyone passed out?  :-)
<bryce_> jbarnes_BCN: team dinner went late; the place we had reservations at, after seating us, said their kitchen had a problem and there was no food.  (??)  So we ended up wandering around and finding another place.
<jbarnes_BCN> bryce_: we were downstairs
<jbarnes_BCN> you walked right past me
<jbarnes_BCN> even after I called your name :)
<bryce_> oh!
<jcristau> heh
<jbarnes_BCN> we're back in the room now
<bryce_> heh, I was intent on getting upstairs and to room 1205 :-)
<jbarnes_BCN> apw: room 1205
<jbarnes_BCN> apw: gotta catch up on your drinking
#ubuntu-x 2009-05-29
<superm1> apw, if you get that kernel that jbarnes was looking for yesterday built some time this morning, can you ping me?  I'd like to see that it fixes the problems that we found yesterday
<apw> superm1, eep.  remind me what he was looking for
<apw> i am building so many things for so many people ...
<superm1> <jbarnes_BCN> 10:44:46> -http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=07f4f3e8a24138ca2f3650723d670df25687cd05
<superm1> <jbarnes_BCN> 10:45:06> -apw: can we get a kernel with that patch (actually a drm-intel based kernel would be even better)
<apw> jbarnes, about?
 * Ng shakes fist at X. Stop crashing!
<Ng> I don't sem to get any log indication that it's doing it though, I would have expected a segfault syslog
<apw> superm1, 32 or 64 better for you?
<superm1> apw, 32 
<superm1> apw, i dont think atom's do 64..
<bryce_> jbarnes_BCN: http://tinyurl.com/l7zw8u
<apw> jbarnes_BCN, superm1, latest karmic kernel with the patch you requested up: http://people.ubuntu.com/~apw/jbarnes-karmic/
<superm1> thanks apw, grabbing right now
<superm1> jbarnes, apw unfortunately that kernel still does have the resume problem wrg to random corruption when KMS is enabled
<superm1> adding on xorg-edgers right now to pair with it
<jbarnes_BCN> commit 13f4c435ebf2a7c150ffa714f3b23b8e4e8cb42f
<jbarnes_BCN> Author: Eric Anholt <eric@anholt.net>
<jbarnes_BCN> Date:   Tue May 12 15:27:36 2009 -0700
<jbarnes_BCN>     drm/i915: Don't allow binding objects into the last page of the aperture.
<superm1> jbarnes_BCN, did you see my ping before, I sent it to jbarnes. not sure if that's a local session back in californida
<superm1> california even
<jbarnes_BCN> heh
<jbarnes_BCN> no I missed it
<superm1> 29-05-2009 05:55:37 > superm1: jbarnes, apw unfortunately that kernel still does have the resume problem wrg to random corruption when KMS is enabled
<superm1> 29-05-2009 05:58:22 > superm1: adding on xorg-edgers right now to pair with it
<jbarnes_BCN> been off & on... had to completely reschedule my travel for the next couple of weeks
<superm1> ah
<jbarnes_BCN> superm1: arg ok
<superm1> i added xorg-edgers as well, same thing
<superm1> so i'm on a fully updated karmic + whatever is currently on edgers for karmic's ppa
<jbarnes_BCN> I think we need a gpu dump (did we get one yet?) and a copy of the rest of the contents of debug/dri/0
<superm1> i dont think we got a gpu dump yet
<superm1> can you grab it from wifi again since i've not got console access while it's in crazy state?
<superm1> although i wonder if my wifi comes up at that point post resume
<jbarnes_BCN> yeah we can get it from ssh
<superm1> where ya at?  i'll come to you
<jbarnes_BCN> the couch by sala b3
<jbarnes_BCN> at the end of the hall
<superm1> k, ill come in a few min, just need to send an email
<bryce__> jbarnes_BCN: http://tinyurl.com/l3netq
<bryce__> 100 papercuts:  https://wiki.ubuntu.com/LittleDetails
<seb128> bryce__: isn't that session starting in 16 minutes ?
<tseliot2> jbarnes: ping
<tseliot2> or bryce
<Spec> Heya...if I want to rebuild (with pbuilder) the xserver-xorg-core package without a specific patch, can I just apt-get source the package, delete the patch, and build it?
<Sarvatt> comment it out from debian/patches/series
<Spec> i hope i'm not shooting myself in the foot :), thanks.
<Sarvatt> which patch?
<Spec> Sarvatt: 169_mipointer_nullptr_checks.patch
<Spec> I'm wondering if the patch caused an issue I'm seeing now, or if it's just logging the issue and the "workaround" implemented with it doesn't actually solve the problem
<Spec> (but it does solve a moar important problem....i just wanna test.)
<Spec> I might also remove 166_nullptr_xinerama_keyrepeat.patch
<jcristau> what's the problem?
<Spec> BUG #324465
<Spec> err, no bot?
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/324465/+text)
<Spec> wait, sorry, that's a different bug that got fixed
<Spec> current bug is BUG #363375
<ubottu> Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/363375/+text)
<Spec> the mouse "loops" on my fourth monitor sometimes, and I get a lot of error messages in X.org's logfile
<Spec> so...the results of the pbuilder are a bunch of .deb files (xdmx, xdmx-tools, xnest, xserver-stuff, xvfb, etc), should I install all of them?
<Spec> and to revert dpkg --purge/reinstall w/ apt-get?
<jcristau> Spec: just xserver-xorg-core (and -dbg if you want to debug)
<Spec> don't know how to debug ;)
<Spec> i'll do this later tough, thanks for the help.
<Sarvatt> Spec easiest way is to add all your debs to a folder, cd to it and run sudo dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz  and add deb file:/opt/debs/ / to your /etc/apt/sources/list replacing /opt/debs/ with what you picked
<Sarvatt> err sorry ignore the >/dev/null, i pasted from my crontab :D
<maxb> That is overkill for a single source-package build
<maxb> Merely use "sudo debi --upgrade"
<Spec> what's wrong with dpkg -i? :p
<Ng> hrm, starting to see some rendering corruption after a day or so of the KMS kernel on jaunty with 2.7.1
<Ng> now starting to see quite a lot of corruption on widgets
<bryce_> hrm
<bryce_> Spec: dpkg -i is fine, that's what I always use :-)
<bryce_> Ng: hrm
<bryce_> Ng: well, 2.7.99.1* is in xorg-edgers and a lot of people are having success running that
<bryce_> Ng: is this with compiz?
<Ng> yeah
<Ng> I'll switch up to edgers I guess :)
<Sarvatt> need a kernel upgrade Ng :)
<Sarvatt> http://people.ubuntu.com/~apw/jbarnes-karmic/
<Sarvatt> was just merged today but that fixes the swap related corruption
<Sarvatt> http://anholt.livejournal.com/41132.html
<hyperair> ooh cool
<Ng> nice
<Sarvatt> didnt help theres a big memory leak with 3d compositing enabled making you swap more either
<Ng> I have 3GB, I didn't notice any swapping
<hyperair> Sarvatt: i noticed that it reduced when i turned on KMS
<hyperair> strange eh..
<hyperair> i've been able to last up to ~12 hours now without having to restart X
<Sarvatt> oh  ya couldn't before? i havent done UXA without KMS in a long time, it was taking about 24 hours before i had to restart when i had compiz on with 1.5gb ram but I guess it all depends on how much you actually do during that time :D
<Sarvatt> i just switched to metacity compositing for now till its fixed
<hyperair> Sarvatt: not that i couldn't, more like i didn't know how to.
<hyperair> then  the email came in the other day to -devel
<Sarvatt> 241MB gem obect bytes 241MB gtt bytes right now after 3 days uptime
<hyperair> eh that's pretty awesome.
<hyperair> so metacity's compositing is better than compiz's huh
<hyperair> as in it doesn't leak like crazy
<Sarvatt> anholt was saying it was GL compositing doing it in that blog post i linked
<hyperair> 833M gem object bytes here, 794M gtt bytes
<hyperair> no wait
<hyperair> 79M gtt bytes
<Sarvatt> your aperture is that big?!
<hyperair> 1323610112 object bytes
<Sarvatt> ahh
<hyperair> 79474688 gtt bytes
 * Ng reboots into the new kernel and the various -edgers bits
<Sarvatt> hyperair, did you try earlier drivers out to see if theres a problem there too? to  be honest i didn't notice the leak until around may 15th (i have 1.5gb ram and dont use swap so it hit hard) and i havent tried earlier drivers out yet since its easier to disable compiz instead of losing all of the bug fixes in the newer drivers
<Sarvatt> hyperair: by oh ya couldnt before I meant I didnt know it was worse without KMS, sorry
<hyperair> Sarvatt: -2.4 doesn't have it.
<hyperair> Sarvatt: i'm pretty sure i didn't see it with 2.5
<Sarvatt> wonder if i should up mesa on jaunty in xorg-edgers to 7.6, the fix for 3d rendering on 8xx is only in master
<hyperair> though i may be wrong
<Sarvatt> oh i meant 2.7 or newer
<hyperair> i used that very briefly
<hyperair> oh
<Sarvatt> 2.7 or 2.7.1
<hyperair> everything 2.7 and up has it
<hyperair> 2.7.0 had it
<hyperair> definitely
<hyperair> and 2.7.1
<hyperair> and the current master
<hyperair> all without KMS
<Sarvatt> gotcha, i only used EXA on 2.7.0 and 2.7.1 because its so much faster
<hyperair> by current master i meant xorg-edgers' one
<hyperair> EXA is faster?
<hyperair> O_o
<Sarvatt> http://global.phoronix-test-suite.com/index.php?k=profile&u=robert-15508-6884-16319
<hyperair> i didn't really experiment with EXA on those, but i'm pretty sure that EXA had the memory leak too
<Sarvatt> the 05-09 ones are with driver 2.7.1 even though it says 2.7.0
<hyperair> i see.
<hyperair> anholt seemed willing to fix it, but only if we can find a minimal test case
<hyperair> =\
<Sarvatt> someone posted one that works for me, the loop opening and killing firefox
<hyperair> is it?
<hyperair> hmm
<Sarvatt> on the bug report, he saw it
<hyperair> i see
<hyperair> i actually have a patched drm which disables BO caching
<hyperair> took the one from your PPA and patched the figure from 14 to 0
<hyperair> some #define there
<hyperair> that one lets the memory drop a little if you close firefox
#ubuntu-x 2009-05-30
<hyperair> can anyone here with an intel gpu change the panel brightness using the panel brightness keys after turning on KMS?
<jcristau> yes
<Sarvatt> no problems here either
<jbarnes_LHR> make sure you have acpi video loaded
<jcristau> i have no randr properties on lvds though
<jbarnes_LHR> yeah I think the panel fitting stuff is still pending
<jbarnes_LHR> I had wanted to avoid adding brightness props to lvds in the kms case
<jbarnes_LHR> since we already have /sys/class/backlight I was hoping it would be the main interface going forward
<jcristau> but what if i use xdmcp on my laptop? :)
<Sarvatt> hyperair: are you on karmic? gnome-power-manager is going through huge changes right now if so
<jbarnes_LHR> jcristau: heh, life is hard
<hyperair> Sarvatt: yeah i'm on karmic. and i noticed it's going through huge changes.
<Sarvatt> using devicekit-power and xbacklight instead of HAL now
<hyperair> cool
<hyperair> wait, if that's so then xbacklight needs to be installed, right?
<Sarvatt> oh looks like it falls back to hal if xbacklight isnt available
<jcristau> xbacklight goes through randr props afaik
<jcristau> jbarnes_LHR: more seriously using randr to set the backlight was a nice way to do that without being root i think
<hyperair> hmm
<jbarnes_LHR> jcristau: /sys/class/backlight doesn't have to be root only
<jbarnes_LHR> could be console owned for example
<Sarvatt> yeah i dont get notifications about backlight level changes anymore and i never got acpi events. no clue how it all works but i guess its handled in the EC directly? I can see the ec registers changing when I watch it while doing it. would having something else mapped to the keys stop that from working maybe?
<marcosRz> Hello, are you the guys who interfered on X to disable completely the ctrl-alt-backspace?
<jcristau> jbarnes_LHR: fair enough
<jcristau> marcosRz: no.
<Sarvatt> marcosRz: it's disabled by default upstream too :) is adding Option "DontZap" "false" to your ServerFlags in xorg.conf to reenable that big a deal?
<marcosRz> Sarvatt, Actually X currently has disabled the DontZap feature
<marcosRz> =(
<jcristau> no
<marcosRz> http://bbs.archlinux.org/viewtopic.php?id=73064&p=2
<jcristau> marcosRz: and you believe what you read on random web forums? good for you.
<marcosRz> jcristau, is it fake?
<Sarvatt> but you can still turn  it on
<Sarvatt> (**) Option "DontZap" "false"
<Sarvatt> xorg-server 2:1.6.99.1+git20090524.12e725d0-0ubuntu0sarvatt (buildd@rothera.buildd)
<jcristau> marcosRz: killing the server with ctrl-alt-backspace was made an option..
<marcosRz> Sarvatt, I cant, they disabled completely
<jcristau> marcosRz: no, they did not.
<marcosRz> I'm running the last X here
<marcosRz> they did it
<marcosRz> =/
<Sarvatt> what jcristau said :)
<jcristau> sigh
<jcristau> i wrote the xkeyboard-config patch to make that a layout option, so i should know..
<marcosRz> xkeyboard-config (1.6.1 - latest) is preventing ctrl-alt-backspace from killing X
<jcristau> marcosRz: ... and you can set the appropriate option, and you can kill X again.
<marcosRz> why did they disabled?
<jcristau> http://who-t.blogspot.com/2009/04/zapping-server.html
<marcosRz> jcristau, http://bbs.archlinux.org/viewtopic.php?id=73064&p=1
<Sarvatt> they only disabled enabling it by default, you can still turn it on manually in xorg.conf
<jcristau> Sarvatt: actually not in xorg.conf anymore :)
<Sarvatt> ah really? it's working on git master of xserver here, what changed it away from xorg.conf?
<marcosRz> So its not on xorg.conf anymore...
<jcristau> Sarvatt: read that url i pasted..
<Sarvatt> alrighty, thanks for the link :)
<marcosRz> I think that they are destroying X
<jcristau> marcosRz: that's ok, you can fork it
<marcosRz> for the benefits of ubuntu newbies, not even fedora users whant this
<jcristau> marcosRz: i think you should take your trolling elsewhere
<jcristau> it was nice talking to you
<marcosRz> I  actually not trolling, but questioning the change...
<Sarvatt> this isnt even a ubuntu specific issue or problem though, #xorg would be the appropriate place to complain :D
<marcosRz> Just by curiosity
<Sarvatt> have you tried setxkbmap -option "terminate:ctrl_alt_bksp" marcosRz?
<marcosRz> Do you guys agree with this change
<marcosRz> Sarvatt, I alread fix it
<marcosRz> I patched X
<marcosRz> ?
<Sarvatt> its even easier enabled now than having to change xorg.conf, I like it :)
<marcosRz> I liked so much when It was enabled by default :3
<marcosRz> But at least this way will prevent newbies to kill X accidently
<marcosRz> It was a good choice, but I hate the convergence that open source projects are taking towards newbies users
<Sarvatt> plus you can remap the key combo to whatever you want now
<marcosRz> thats cool :)
<marcosRz> thanks for the patience
<marcosRz> I need to learn to live with newbiews users...
<marcosRz> I did this patch
<marcosRz> Sarvatt, http://pastebin.com/m4ad0ee81
<marcosRz> Sarvatt, sorry for the trouble :)
<johanbr> Hmm... after the latest Karmic update, my touchpad now has tapping disabled when my laptop wakes up from suspend.
<johanbr> Also, any keymap changes I've made with xmodmap are gone.
<Sarvatt> what brand touchpad?
<johanbr> alps
<Sarvatt> how'd i know you'd say that? :D
<johanbr> well, it used to work just fine :)
<johanbr> now, after resuming, "synclient -l" says "TapButton1              = 0"
<Sarvatt> yeah there was some changes in alps in the main driver and a ubuntu patch on top of that
<Sarvatt> have you tried gpointing-device-settings?
<Sarvatt> its only a recommends so it doesnt install by default but its great
<johanbr> Well, I used gsynaptics (which apparently is the predecessor).
<johanbr> With that, I can re-enable tapping. But I'd rather not do it manually every time.
<jcristau> i think gpointing-device-settings can remember your settings
<Sarvatt> yeah it works great in that regard for me, also lets you enable multiple finger stuff
<Sarvatt> oh dang, they dropped almost all patches in the latest xserver-xorg-input-synaptics in karmic, was synced from debian
<Sarvatt> surprised you had tapping enabled at all before the resume johanbr :D
<johanbr> oh, that's the problem :)
<johanbr> there was a similar bug in Intrepid that was fixed by patching gnome-settings-daemon: https://bugs.launchpad.net/gnome-settings-daemon/+bug/280148
<ubottu> Ubuntu bug 280148 in gnome-settings-daemon "g-s-d needs to set mouse properties when a new device appears" [Medium,Fix released]
<Sarvatt> you can grab this one thats the same but with the patches enabled, https://edge.launchpad.net/%7Ewgrant/+archive/ppa/+sourcepub/639179/+listing-archive-extra or this one if you want to try something newer for some reason https://edge.launchpad.net/~sarvatt/+archive/ppa/+sourcepub/634362/+listing-archive-extra
<Sarvatt> johanbr: it's a change in the driver upstream, they disabled tapping completely in the driver by default now and ubuntu has a patch that reenable it
<johanbr> oh :)
<johanbr> I just installed the wgrant package.
<johanbr> I probably need to restart X, right?
<Sarvatt> but debian doesn't use that patch and it was automatically synced from debian so the patches were lost
<jcristau> less patches == good :)
<johanbr> I'll reboot and test
<johanbr> brb...
<Sarvatt> could just restart hal and rmmod/modprobe psmouse i think
<Sarvatt> actually think it restarted hal after the install
<johanbr> it did
<johanbr> I'll reboot just to be sure...
<Sarvatt> wonder why they disabled tapping anyway, i'll have to dig through the logs
<Sarvatt> oh i guess it was always off by default and ubuntu just enabled it :D
<johanbr> Sarvatt: yep, that works!
<johanbr> thanks a lot
<Sarvatt> no worries, you're like the 50th person thats said something about that in the past few weeks :D that 1.1.99 driver i linked is pretty nice too, it lets you disable the tap and drag feature that was forced enabled always on synaptics before
<johanbr> I like tap and drag :)
<Sarvatt> i set up a keybinding to turn it on and off, i've accidentally moved way too many things in nautilus with it on :D
<Sarvatt> got a bad habit of highlighting things as i read it moving text around alot too :)
#ubuntu-x 2009-05-31
<Sarvatt> well at least there's a pretty consistant performance increase in -intel and mesa lately - http://global.phoronix-test-suite.com/index.php?k=profile&u=robert-11148-16739-5615
#ubuntu-x 2010-05-31
<Bernardo> hi
<RAOF> Howdie
<RAOF> tseliot: Do you want to merge synaptics, or shall I?
<RAOF> Hm.  r700+mesa 7.8.1 really doesn't like compiz blur.  Unless you like smoothly shaded black/red/yellow/green cornered rectangles for windows, of course.
<tseliot> RAOF: I'm quite busy hacking on radeon's drm code (for different reasons) right now. I'd appreciate if you could do the merge for me. Of course if a patch doesn't apply I'm available to adapt it
<RAOF> tseliot: Cool.  Thanks.
<Sarvatt> RAOF: I already merged synaptics locally, did you already do it or do you want me to push?
<RAOF> Sarvatt: I've done some preliminaries, but not fully.  Go for a push.
<Sarvatt> ok will do in a minute, just updating the changelog
<Sarvatt> evdev can just be synced, we dont need that patch anymore
<jcristau> did xserver get updated in m?
<jcristau> many drivers have a build dep on 1.7.6.901 which wasn't in lucid
<Sarvatt> not yet, just preparing for when it is
<jcristau> k
<RAOF> Sarvatt:  There's an evdev sync bug already.
<Sarvatt> and yeah thats caused no end of headaches in xorg-edgers, been having to use experimental and hoping it doesnt get updated :)
<Sarvatt> RAOF: why universe for this?  [raof] Fork a pre-2.10 -intel driver and package it in universe.
<RAOF> Because I 'ain't supportin in.
<RAOF> s/in/it.
<Sarvatt> having it installed side by side with intel would be nice, so it automatically falls back to it with no KMS
<Sarvatt> ah
<Sarvatt> btw SUSE has already done this if you haven't seen
<RAOF> I have not, no.
<Sarvatt> darn lost my bookmark to it last crash
<RAOF> Eh, finding the SuSE packaging can't be _that_ hard :)
<Sarvatt> https://build.opensuse.org/package/show?package=xorg-x11-driver-video-intel-legacy&project=openSUSE:Factory
<Sarvatt> i've been poking at 2.7.1 for newer servers since that was the last one with EXA, 2.8.0 was easy but doesn't seem to be an improvement for anyone
<RAOF> That's probably a better idea; my understanding of the i845 & i855 problems is in the buffer manager, which would disappear without UXA/DRI2
<hyperair> Sarvatt: weird. my Xorg.0.log says that page flipping was forcibly disabled, yet i'm seeing the same kinds of hangs that page flipping brought about for you =\
<hyperair> image frozen on screen, and everything else stalled.
 * Sarvatt makes sure he actually forcibly disabled it..
<Sarvatt> wouldn't put it past me to have just updated the  message and not actually disabled it :)
<hyperair> heh
<Sarvatt> same patch
<Sarvatt> just the message updated, should be working still..
<Sarvatt> anything change in your setup? did you install the gallium package or anything?
<RAOF> Why does everyone else see the crazy bugs?  I've been using xserver 1.8.1 and -intel 2.11, and *I* don't get these hangs :)
<Sarvatt> on your primary machine?
<Sarvatt> i think thats the big difference :)
<Sarvatt> i dont tend to do the things that really break things on other machines
<RAOF> On (one of) my primary machine(s)
<Sarvatt> ricotz: the gallium dri2 tfp problem fixed in mesa and its build in edgers already btw
<ricotz> Sarvatt, nice! so i can upgrade again ;-)
<Sarvatt> yep :) thinking about uploading compiz without the parts in the ubuntu patch forcing it to not start with swrast now that that has tfp support too
<Sarvatt> hyperair: you crashed twice in an hour earlier? or were you just switching drivers?
<Kangarooo> unbelievable. ssh -x user@ip rocks. i opened other comps google chrome with all its tabs in this comp 
<Sarvatt> and then you load a page with flash by mistake? :)
 * Sarvatt is lusting over this sharp netwalker PC-Z1
<Sarvatt> eww, a whole bunch of poulsbo based tablet announcements today.. :(
<Sarvatt> which means people are going to want to run ubuntu on them and have it work. great :)
<hyperair> Sarvatt: no, i went offline due to the rain, then it crashed.
<hyperair> Sarvatt: right now i'm trying to coax my btrfs balancing thing to actually complete, since it crashed twice in 24h, interrupting the balancing preocedure twice.
<hyperair> so i'm not starting X until it completes =p
<Kangarooo> Sarvatt: opening ssh -X  in browser page in flash does something bad?
<Kangarooo> Sarvatt: im now on pc1 opened vnc pc2 and in there opened ssh -X to pc1 and google-chrome from it :)
<Sarvatt> its just really slow
<Sarvatt> you may want to -XC
<Sarvatt> does gnome-shell really need to depend on xserver-xephyr? does anyone actually use gnome-shell in xephyr? (hint: it doesnt work with glx 1.4..)
<jcristau> depend on Xephyr?  what kind of silliness is that?
<Sarvatt> a looong time ago that was the recommended way of testing it
<Sarvatt> like a year before it was packaged
<Sarvatt> ok exaggeration, more like 6 months or so
<Sarvatt> ahhh Recommends: xserver-xephyr
<Kangarooo> if i have FF crashing Xorg when opened a lot gif tabs in FF then can i also replicate it using ssh -X or -XC ? -XC means faster yes? right now i have opened crashed pcs FF in last week debugged pc :) and its not crashin. if ill open otherwise will then it crash?
<Sarvatt> wonder where xserver 1.8.2 (or 1.8.1.901 even) is, has had quite a lot of important fixes in it
<Kangarooo> what is SysRq in Alt+SysRq+1 ?
<Sarvatt> the sysrq key :)
<Sarvatt> ripps: --target=i586-linux in your configure flags for mplayer on maverick?
<Sarvatt> maverick's i686 default now
<ripps> Sarvatt: --cpu='i686'
<ripps> been using it for a while
<Sarvatt> thats in ffmpeg options not mplayer?
<ripps> Sarvatt: yeah, --target=i586-linux is in my i386 arch rules
<Kangarooo> i was making xorg dbg and when in dbg i entered pid nr then all computer froze. mouse and keyb not moving. all screen stopped
<Kangarooo> i can thrue ssh do something
<Sarvatt> attach gdb over ssh and type continue when it happens
<Sarvatt> handle SIGUSR1 nostop (in gdb)
<Sarvatt> darn, I wish nouveau/xf86-video-nouveau was on the xorg-commit list, i always miss updates
<Kangarooo> ah sick of this comp not working. ill sell it. but before if u want i can make it clean and vnc acces to it and if u want u can make all crash and reporting
<Kangarooo> wiki.ubuntu.com/X/Backtracing and wiki.ubuntu.com/DebuggingXorg is the same info
<Kangarooo> (gdb) attach 764 Attaching to program: /usr/bin/Xorg, process 764 ptrace: Operation not permitted.
<Kangarooo> (gdb) cont The program is not being run. (maybe becouse i cant move mouse and keyb on it and screen is showing but not moving anything)
<Bernardo> hi
<Kangarooo> Sarvatt: when i do whats in https://wiki.ubuntu.com/X/Backtracing then my comp crashes. even if i do it thrue ssh. on command (gdb) attach (pidnr) it crashes and nothing moves anymore
<Sarvatt> type cont
<Kangarooo> Sarvatt: so i do again sudo gdb /usr/bin/Xorg 2>&1 | tee gdb-Xorg.txt and then dont do attach but just cont?
<Sarvatt> ahh I give up, nouveau needs newer xserver now too. guess I'll just build xserver from origin/ubuntu instead of using the old one and rebuild the world again in the PPA
<Sarvatt> Kangarooo: no do whats set in the ssh section further down
<Sarvatt> it really says to do that?
<Sarvatt> that'd never work unless you were handling signals in .gdbinit..
<Kangarooo> ah yes. it was not so easy couse both computers are not in same room. i was with crashing pc vnc to working pc and in there ssh so when in ssh i do that attach that comp crashed. now im at working pc :)
<Sarvatt> you could just gdb -p $(pidof X) -batch -ex 'handle all nostop' -ex 'handle all pass' -ex 'handle 11 stop' -ex 'cont' -ex 'bt full' -ex 'cont' from a VT if you just wanted the backtrace from a segfault, not sure what you're doing
<Kangarooo> Sarvatt: im just following https://wiki.ubuntu.com/X/Backtracing and its the same as https://wiki.ubuntu.com/DebuggingXorg
<Sarvatt> i dont know why you're doing it is what I meant, sorry
<Sarvatt> i'm having a hard time wrapping my head around what you just said you were doing :)
<Kangarooo> ok so now i was able to do next step (gdb) cont but now since comp i want to inwestigate why FF makes it crash Xorg cant be  backtraced since it crashed on attach (pid)
<Sarvatt> Kangarooo: are you on radeon or nouveau?
<Sarvatt> because if so i can tell you why its crashing
<Kangarooo> Xorg crashing computer has nvidia
<Kangarooo> geforce fx5500 and i couldnt find gdb for nvidia
<Sarvatt> using the binary nvidia drivers?
<Sarvatt> installed through hardware drivers?
<Sarvatt> or just the default stuff?
<Sarvatt> because if its the default stuff it's the same exa bug
<Kangarooo> system->hardware drivers
<Kangarooo> nvidia somthing airc 173
<Sarvatt> which ones does that use? nvidia-96? have you filed a bug on launchpad?
<Sarvatt> ah
<Kangarooo> airc = as i recall corretly :D
<bjsnider> the 5500 should be using the nvidia-173 driver
<Kangarooo> i was able to choose somekind 96 and 173 and 173 was working faster
<Sarvatt> did you do anything like upgrade to a 2.6.34 kernel by any chance?
<Sarvatt> because nvidia-96/nvidia-173 dont work on those, just ruling things out
<Kangarooo> i have latest kernel there witch can be updated from default ubuntu universes
<Kangarooo> w8 ill thrue ssh check
<Sarvatt> alrighty
<Sarvatt> its ok you'd know if you installed it
<Kangarooo> 2.6.32-22-generic
<Sarvatt> have you filed a bug on launchpad about it so I can look through your logs?
<Kangarooo> i think i installed that what u named in this comp im at now. couse at what im now has i845 and at bug report i wrote that that solution with kernel .34 didnt work even starting pc. but the realy latest witch 4 days ago was rc7 that worked a little better (loading logo was better resolution) but crash still happened.
<Kangarooo> Sarvatt: w8 3 min.. ill chek ihave a lot bug :)
<Sarvatt> i've never even been to the nvida-graphics-drivers-173 bug list
 * Sarvatt hides
<Kangarooo> bug 587710 this is bug i made ubuntu-bug and to add more info i was checking https://wiki.ubuntu.com/X/Debugging but since on (gdb) attach (pid) my system crashes i cant backtrace this reported bug.
<ubot4> Launchpad bug 587710 in nvidia-graphics-drivers (Ubuntu) "if FF wit lot Gif & overloading CPU then X-boom to login (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/587710
<Sarvatt> thanks, you have a backtrace there in one of the logs too :)
<Kangarooo> oh i dont know how to know :)
<Sarvatt> the xorglogold has it, i put it in the bug description
<Sarvatt> there's another problem, the -dbg packages for xserver-xorg-core that you need in lucid are useless
<Sarvatt> what sucks is I remember the nvidia 170 series having that same problem like 2 years ago and they fixed it in the 180 series
<Sarvatt> not sure if I should move that over to xorg-server or leave it there, the backtrace is all in X
<Kangarooo> ok so a new bug asking about nvidia 180 put to universe is needed? or it has some other bugs?
<Sarvatt> no you cant use it on that GPU, they dropped support for the older cards
<Kangarooo> so now this card is also one of restriced ?
<Sarvatt> does this only happen with compiz enabled?
<Kangarooo> when doing compiz check i got error that this card is restricted. but actually i dont want compiz and dont use it. just tryd that check.
<Kangarooo> ah but actually i tryd compiz installing on xubuntu 1 week ago and it worked. very fast
<Kangarooo> ouh wait. sorry no my card for comp witch that bug is was not compiz check showing as restriceted. compiz check showed ok.
<Kangarooo> so compiz check showed ok for all checks.
<Kangarooo> for other comp witch has i845 compiz check showd restricted card/driver
<Sarvatt> so its enabled then because it defaults to enabled
<Sarvatt> can you try disabling visual effects in system - preferences - appearance to see if you can crash it that way too?
<Kangarooo> Sarvatt: no compiz is removed now.
<Sarvatt> oh the nvidia machine?
<Sarvatt> err on
<Kangarooo> ye :)
<Kangarooo> i put compiz on nvidia 5500 machine and it workd and i dont need fx so i removed. and nvidia 173 is activated
<Sarvatt> oh you're on xubuntu ok
<Kangarooo> ye
<Sarvatt> using any kind of compositing?
<Sarvatt> xcompmgr or anything, no idea what xubuntu uses
<Kangarooo> searching google whats that. so theres Xfce 
<Sarvatt> it'd be great if you could get a core dump i could poke around on :)
<Kangarooo> default xubuntu installation nothing then programms added. fx not added. w8 ill ask on #xubuntu
<Kangarooo> Sarvatt: ok thrue ssh ill get it where only?
<Sarvatt> wonder why http://cgit.freedesktop.org/xorg/xserver/commit/?id=4151a13c80f3afa43f88afcf19a7aeb16dace93a didn't make it to 1.7 branch
<Kangarooo> Sarvatt: compositing in xubuntu not by default. so i dont have it also. where is that core dump? ill cp and post to that LP bug
<Sarvatt> have you enabled apport? anything in /var/crash/?
<Kangarooo> Sarvatt: yes apport ive enabled on all comps. about that bug when FF with a lot gifs crashes Xorg apport didnt gave crash. thats why i made ubuntu-bug to post that bug and to get more info i wanted to do today that backtracing
<Kangarooo> now theres noting new in /var/cras
<Kangarooo> theres xfce4-systemload crash and update-apt-xapian crash . when i post crash i delete them so i dont get confused couse i dont post them immidiatly but later all.
<Kangarooo> thouse has nothing to do with nvidia and i got them when FF Xorg crash wanst happening
<Sarvatt> you have to manually enable apport for it to catch things now, but apport is only catching a small number of X crashes anyway
<Sarvatt> change the enabled=0 line to enabled=1 in /etc/default/apport then sudo service apport start and reproduce the crash, hopefully it shows up in /var/crash/
<Kangarooo> Sarvatt: yes ive done that to all comps
<Kangarooo> no it doens show
<Kangarooo> Sarvatt: interesting news. im now back at crashing comp and now all is moving. GDB still active
<Kangarooo> i went to other comp couse this crashed. and im in pidgin in working comp true vnc from crashing comp
<Kangarooo> so ill now make it make backtace?
<Kangarooo> um reproduce bug while backtracing gdb is working thrue ssh ok? 
<Kangarooo> and what about that core dump? where i can get it?
<Kangarooo> ah core dump is a crash file?
<Kangarooo> so apport is started and made to start on comp start enabled=1
<Kangarooo> it was already 3 weeks ago
<Sarvatt> Kangarooo: I'm building an xserver package in a PPA for you that might fix it, but even if it doesn't fix it it will have a correct -dbg package that'll actually work unlike the one in the archives
<Sarvatt> https://edge.launchpad.net/~sarvatt/+archive/bugsbugsbugs
<Kangarooo> so manually also i have to make? from working comp thrue ssh on crashing comp?
<Sarvatt> make what?
<Sarvatt> oh that means apport isnt catching it, yeah
<Kangarooo> another apport ?
<Sarvatt> sorry was packaging it up and not reading it
<Sarvatt> no
<Kangarooo> yea isnt catching
<Sarvatt> nevermind about that, didnt know you already turned it on
<Sarvatt> yeah have to start X with -core
<Sarvatt> and set the ulimit right first
<Kangarooo> apport i made 3 weeks ago to be  starting on comp start
<Kangarooo> w8. im now at comp thats crashing. i went to other comp couse this one stopped again working when put command attach (pid) now im back at it and keyb is working and gdb is working
<Kangarooo> so i can make that backtrace reproducing bug finally if needed
<Kangarooo> ill make backtrace now and then lets try next steps/options
<Kangarooo> ill still be in chanell since im in vnc and chanel is open in working pc
<Sarvatt> try this PPA when it finishes building, it might fix your problem - https://edge.launchpad.net/~sarvatt/+archive/bugsbugsbugs
<Sarvatt> okie, what i was saying is the backtrace in gdb will probably not be very useful because the -dbg packages for xserver-xorg-core in lucid don't work
<Sarvatt> the ones in the PPA will though so you'll be able to get a good backtrace if the patch I added doesn't fix it
<Sarvatt> be sure to get a bt full and not just a bt, you have the bt output already
<Sarvatt> now I see you have another crash in one of the other logs too - *** glibc detected *** /usr/bin/X: corrupted double-linked list: 0x09048e90 ***
<Sarvatt> http://cgit.freedesktop.org/xorg/xserver/commit/?id=4151a13c80f3afa43f88afcf19a7aeb16dace93a is the commit I added to lucid's xserver in that PPA, I think it might fix it
<Sarvatt> its done building
<Kangarooo> this comp was restarted while all finally was working :)
<Kangarooo> ill try again
<Sarvatt> Kangarooo: try with the PPA so even if it doesnt fix things the backtrace you get will actually be useful
<Kangarooo> ah Sarvatt i found out that when i write in (dgb) cont then the crashing comp unfreezes to continue Xorg backtracing
<Sarvatt> yeah
<Sarvatt> Kangarooo: run this then it wont do that anymore -
<Sarvatt> handle all nostop
<Sarvatt> handle all pass
<Sarvatt> handle 11 stop
<Sarvatt> then continue
<Sarvatt> and you wont have to run between rooms anymore until that crashes :)
<Kangarooo> even now? i did cont and now im wainting for crash to happen. or for future do thouse commands?
<Sarvatt> you wont have to cont anymore, it'll keep going until it crashes
<Sarvatt> if it freezes that means it crashed
<Sarvatt> then you can get your bt full
<Kangarooo> no now crash i want to reproduce is making all closed and login open. so no freeze will now happen
<Kangarooo> wow 100 tabs open 600mb ram used swap 0 still not crashing
<bjsnider> if this was windows, i could cause a crash in less than 5 clicks
<Sarvatt> is that with the PPA xserver Kangarooo?
<Kangarooo> no still the same way i was tryng to do today. ill do all backtraces. first this one ill complete
<Sarvatt> ah, ok
<Sarvatt> did you do anything different? you said you enabled compiz now?
<Kangarooo> now already 850mb ram used swap now only first 2 mb. no nothing different. no compiz not installed. this crash was able to reproduce without compiz. i installed compiz 4 days ago only for 10 min and purged it.
<Kangarooo> ill close all tabs and start again opening all gifs
<Kangarooo> Sarvatt: All again froze and in terminal from ssh Program received signal SIGSEGV, Segmentation fault. 0x08087041 in dixChangeGC () . should i cont again? and all other commands u wrote so no stopping happens yes?
<Sarvatt> nope cant continue,thats your crash
<Sarvatt> bt full now
<Kangarooo> no this crash is not the one i wanted to bacrtrace. crash i wanted to reproduce make login screen popup
<Sarvatt> Kangarooo: thats the same crash, it stopped there because you are in GDB
<Sarvatt> set logging file ~/xcrash.txt
<Kangarooo> ok so when ill go out of gdb then crashing comp will be in login promt?
<Sarvatt> set logging on
<Sarvatt> bt full
<Kangarooo> loggin is with | tee filename
<Kangarooo> ok i did bt full. now do i have to quit gdb somehow?
<Sarvatt> yep, just quit
<Kangarooo> and then that comp will respond?
<Kangarooo> quit with quit ?
<Kangarooo> (gdb) quit A debugging session is active. 	Inferior 1 [process 2562] will be detached.
<Kangarooo> Sarvatt: ?
<Sarvatt> yep
<Sarvatt> you're done, you have your backtrace..
<Kangarooo> yeah login poped up. where can u see that? so ill upload backtrace to the same bug?
<Kangarooo1> Sarvatt: so i make sudo add-apt-repository ppa:sarvatt/bugsbugsbugs/ubuntu ? and then install that package ?
<Sarvatt> yep!
 * hyperair is quite sure it doesn't need an extra /ubuntu at the back
<Sarvatt> i dont use that so i assumed he just pasted it from the ppa page and said yeah lol
<Kangarooo> ok after realod i got 3 package updates. xserver-xorg-core-dgb xserver-common xserver-xorg-core . all install Sarvatt ? and then restart pc? and this crash will not happen? or then make test reproducing?
<Sarvatt> sudo apt-get update && sudo apt-get dist-upgrade, it'll grab everything
<Sarvatt> dont know what you have installed to tell you what needs to be upgraded
#ubuntu-x 2010-06-01
<Sarvatt> Kangarooo: crashed with the PPA one yet? :)
<Kangarooo> Sarvatt: no not jet. im tryng. i havent restarted pc jet. and had FF open with 100 gif tabs and i just came back and FF crashed but crash didnt had ram enough (that was the apport error). so if it crashes ill tell. also im tryng to make crash and not working crash.
<KaNGaR> Sarvatt: just happened crash again :) so i make backtrace again? or just ubuntu-bug ? i also restarted pc maybe patch didnt made effect until restarted?
<Kangarooo> Sarvatt: cant i in (gdb) make command with && ? like attach (pid) && cont ? so system doesnt freeze?
<Kangarooo> no not && and not & working (gdb) attach 769 && cont Illegal process-id: 769 && cont. (gdb) attach 769 & cont Illegal process-id: 769 & cont.
<RAOF> Kangarooo: You're not running gdb from a VT?  Your X will still stop, but you won't be trying to interact with it, so it should be ok.
<Kangarooo> whats VT? im was running gdb from pc witch is not so close thrue ssh conecting to crashed comp. and so that i dont need to run to working comp im in VNC to working comp :)
<Kangarooo> RAOF: ive just tryd running this in TTY and when freezing happens (where i need to continue running with command cont) then TTY still works. But then i Ctrl+alt+f7 and again all froze.
<RAOF> There are a couple of signals you need to not stop on.  If you change the keyboard to raw mode (alt+sysrq+r) you should be able to switch back to your original TTY and continue.
<Kangarooo> it would be very good if on (gdb) attach (pid) xorg doesnt stop
<RAOF> Those signals should be on the X debugging wiki.
<Kangarooo> whts sysrq? yesterday i was asking and nobody knew
<maco> its a key on your keyboard
<RAOF> The sysrq button; generally found on the same key as prtsc
<Kangarooo> hehe no?
<maco> usually on prtsc or ins or del
<maco> mine's on the del key
<Kangarooo> whata.. alt+del removed one of my workspaces
<Kangarooo> that actually deleted a workspace
<Kangarooo> wow. yes i have Sysrq on Prt Scr. wow never used so never noticed :)
<Kangarooo> im only getting a screenshot. so when a freezing happens then (alt+sysrq+r) will work?
<RAOF> To trigger sysrq you probably need to hit shift, too.
<Kangarooo> ok and last buton is key "r" ?
<RAOF> Yup.
<Kangarooo> ok so that all will help me only to get to TTY ? but not to xmode ?
<Kangarooo> couse it will still be frozen until in gdb continue
<RAOF> Right
<RAOF> That will allow you to switch terminals, because it makes the kernel handle the ctrl+alt+f keys itself without letting X trap them in its frozen jaws.
<Kangarooo> ok so in TTY6 i made gdb and when made attach (pid) TTY6 still responding and keyb also. but then i changed to Xorg mode and keyb not responding and nothing moves. so i got in raw mode and that made only keyboard raw mode but not screen. keyboard responded to Numlock and to Scroll Lock but not caps lock.
<Kangarooo> and ctrl+alt+f6 i could get back to tty6
<Kangarooo> not to any tty1-6
<Kangarooo> RAOF: so raw mode doesnt give me possibility for me to get back to TTY1-6
<Kangarooo1> is gdb still running or it stopped? http://pastebin.com/8Scimr30 what command should i do now? again attach (pid) or cont ?
<RAOF> That hasn't worked because X is already running.  gdb is running, but the X process you tried to start isn't.
<RAOF> Ok.  Git question: how do I take uncommitted changes over to a different branch?
<Kangarooo> no i cant get in TTY back. i even did whats in subsection of https://wiki.ubuntu.com/X/Backtracing#Backtrace%20with%20gdb section gdb problems. theres writen inside gdm, start up Xorg: (gdb) run -keeptty -dumbSched. so i did start with attach (pid) and then that run -blabla -bla and thats the log i got. couse after that command it asked to restart? on yes x restarted to login screen. on no it crashed when going to tty7 and still cant get bac
<Kangarooo> also the link for gdb problems has nothing to do with the command posted in that section
<Bernardo> good morning
<RAOF> Hm.  DisplayLink doesn't really work.
<Sarvatt> is it bad i'm starting to actually look forward to intel being broken in git? i swear i learn so much each time trying to figure it out :)
<Sarvatt> RAOF: drivers in the archive?
<RAOF> Sarvatt: Yeah.
<Sarvatt> werent those really old?
<RAOF> kernel fb module in the kernel, xserver-xorg-video-displaylink as the DDX.
<RAOF> I'm not sure whether there's anything newer.
<Sarvatt> dont think i've even seen any displaylink stuff since... xserver 1.6 just came out
<Sarvatt> on the lists
<Sarvatt> where's upstream?
<RAOF> Well, bryceh gave me a displaylink box at UDS.  It's easy enough to get a framebuffer up, once you manage to switch it from USB mass storage mode.
<Sarvatt> needs a udev rule?
<RAOF> Upstream? http://libdlo.freedesktop.org/wiki/
<RAOF> Yeah.  A udev rule would do it.
<RAOF> At least for _this_ hardware.  No guarantees that other hardware isn't crazy in different ways :)
<Sarvatt> nothing like spending 8 hours or so bisecting and having the fix already commited :D
<Sarvatt> why is it called libdlo?
 * Sarvatt is confused
<Sarvatt> ah i see it talks to libusb, where's the X driver?
<Sarvatt> oh you linked a wiki too! ugh, sorry, i've been going through xtrace logs all night and text is kind of blurring together
<Sarvatt> oh so basically you just use fbdev?
<Sarvatt> Now i will focus on patching the intel driver to add a virtual crtc for every displaylink device in the system. This will allow to use the GPU to draw (maybe accelerated) contents and send the output via the usb,and to use a single big screen (the old Xinerama/MergedFB way).
<Sarvatt> (then releases stop a year ago) :)
<RAOF> Right.
<RAOF> It did seem to be fairly dead.
<RAOF> I can get a screen with a movable cursor up, but there's not a lot of rendering happening.
<Sarvatt> no real point signing up for things on blueprints if you're not canonical right?
<RAOF> Hm.  Kinda.
<Sarvatt> i haven't touched anything on them because i'd rather one of you guys get marks on your performance reviews :)
<RAOF> I'm not entirely sure why you'd want to sign up for work items; I guess it's a nice tracker.
<Sarvatt> because i'm doing or have done the work, i wasn't sure if they really were just canonical or ubuntu too
<RAOF> Hm.  You might want to ask Rick.  I don't see any particular reason why you couldn't put work items on the list if you wanted to track things.  Or, rather, the only reason I can think of is that one of us needs to be ultimately responsible for ensuring it's delivered.
<Sarvatt> you a core-dev yet? :)
<RAOF> Not yet :)
<Sarvatt> I'm not sure, seems like a lot of the problem is on the AGP side
<apw> RAOF, got a link to the bug from which that attachment attaches?
<RAOF> apw: http://bugs.freedesktop.org/show_bug.cgi?id=27187
<ubot4> Freedesktop bug 27187 in Driver/intel "[i855GM] gtt chipset flush is not cache coherent" [Normal,New]
<RAOF> Linked from this memorable launchpad bug: https://bugs.edge.launchpad.net/ubuntu/lucid/+source/xserver-xorg-video-intel/+bug/541511?comments=all
<apw> bug #541511
 * apw notes ubot4 is useless
<RAOF> I'm off to the movies now; it's 8pm.
<ubot4> RAOF: Error: Bug #541511 is private.
<ubot4> Launchpad bug 541511 in xserver-xorg-video-intel (Ubuntu Lucid) (and 3 other projects) "MASTER: [i855] GPU lockup (apport-crash) (affects: 118) (dups: 29) (heat: 814)" [High,Triaged] https://launchpad.net/bugs/541511
<RAOF> Hah.
<Sarvatt> there's been a surprising amount of 8xx stuff done post 2.11 though and one person mentioned they were 100% stable on 855 earlier
<RAOF> I wouldn't get my hopes up about _that_.  A subset of users have always reported they were 100% stable on 855.
<Sarvatt> true!
 * RAOF really off.
<Sarvatt> apw: do you know if there are there any plans to enable DMAR?
<apw> Sarvatt, DMAR ?
<Sarvatt> just a heads up you can expect a large amount of bug reports about broken graphics if you do :)
<Sarvatt> yeah some people want it on for virtualization but we've avoided all of the problems because we dont have it enabled :)
<Kangarooo> hello Sarvatt did u read all i wrote after u asked Sarvatt: Kangarooo: crashed with the  PPA one yet? :)
<Kangarooo> i was tryng to get somehow so Xdoesnt stops with attach (pid) handle all nostop handle all pass cont but still xorg was stopped when crash happened. ouh and yeah crash still happened. ill make a new dbg now thrue ssh again
<mvo> superm1: hey! I merged xserver-xorg-video-nv in lp:ubuntu/maverick/xserver-xorg-video-nv but I ran into the issue that nv_list.csv seems to need updating. is there a automatic way of doing this?
<mvo> superm1: all the other bits are in bzr, but that part is currently missing
<Kangarooo> Sarvatt: i got again crash but crashed all comp not just screen. also ssh wasnt responding. but also i could quit ssh and also couldnt open new ssh
<Sarvatt> Kangarooo: did you attach that backtrace you got to the bug? I looked last night but didnt see it
<Sarvatt> mvo: can't merge X drivers from debian at the moment until xserver is updated..
<Sarvatt> well  you can but they wont build :D
<mvo> Sarvatt: can merge, just can't build :)
<Kangarooo> no couse didnt get response is it needed. ill post it up now. and then im again tryng to make crash with backtrace with your ppa
<mvo> Sarvatt: its just the depends generation that will not work, so it can be tested to a certain extend :)
<Sarvatt> ohhh interesting, never saw superm1's patch before
<lucazade> Bernardo: http://meego.gitorious.org/~xinyunliu/meego-os-base/xylius-kernel-source
<lucazade> Initial PowerVR core gfx driver support for IVI based on build 1616
<Sarvatt> it shouldn't really be needed anymore, should it?
<mvo> Sarvatt: hints welcome (feel free to take over if you want, my stuff is in bzr)
<mvo> Sarvatt: no? what did change that makes it no longer needed?
<Sarvatt> nv no longer loads if KMS is in use so it'd never claim it, KMS is in use unless forced off for nouveau
<Sarvatt> i think there was more, looking
<Sarvatt> what i'm thinking of might not have made an official release yet
<Sarvatt> yeah that csv generation would be a PITA to maintain lol
<Sarvatt> well then again nv is abandoned
<mvo> PITA> my feeling as well
<Sarvatt> not like they're going to make GPU's that work with nv anymore to update it after this last one
<Sarvatt> i'll fix it up
<mvo> cool, thanks :)
<lucazade> Sarvatt: hi! seems there is a new IVI driver with poulsbo support
<lucazade> in meego git repo
<Kangarooo> ok Sarvatt added. now with your ppa doing the same commands made system and ssh unresponsive.. :(
<Kangarooo> *tryng backtracing with same commands.
<Sarvatt> lucazade: found any images yet?
<Sarvatt> i've got a meego chroot but theres still nothing as of this morning
<lucazade> not yet
<Kangarooo> Sarvatt: bug 587710
<ubot4> Launchpad bug 587710 in nvidia-graphics-drivers (Ubuntu) "if FF wit lot Gif & overloading CPU then X-boom to login (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/587710
<lucazade> Sarvatt: found this repo reading meego forum http://forum.meego.com/showthread.php?t=38
<Sarvatt> i'm in the middle of doing 3 things at once right now, will look in a bit
<Kangarooo> Sarvatt: iim tryng to get system not lock up so i dont need to cont on other comp. (gdb) attach 787 -keeptty -dumbSched gives Illegal process-id: 787 -keeptty -dumbSched. also tryd just handle all nostop and handle all pass then cont (without handle 11 stop) and still system froze
<Sarvatt> what the heck, superm1 made this -nv change last september? no clue how I didnt see it all this time
<bjsnider> i can't make sense of that bug report subject line
<Kangarooo> bjsnider: mine bug report?
<Sarvatt> superm1: ah theres a little problem with this patch
<Sarvatt> superm1: nvidia GPU's that are natively PCIE but have an AGP bridge are not in the list
<Sarvatt> so you blocked out all of those users with this change
<Sarvatt> the GPU has the pci id of the agp bridge and not the actual GPU
<Sarvatt> and adding the agp bridge pci ids to the list would screw it up too, i went through this with aplattner a year ago
<Sarvatt> it was a problem when we had the pci.id's files, that wasn't picking up those GPU's either
<Sarvatt> dont tell me i dont have the patch i used to get around that anymore.. :( I added all of the bridge devices in an #if 0 block so they didn't do anything but they still got parsed
<Sarvatt> there it is - http://launchpadlibrarian.net/27885379/101_agp_bridge_pci_id.patch
<Sarvatt> almost done updating the csv with the new chips so the script can be run
<superm1> mvo, there is a script in there yes to do it that came with the patch
<superm1> Sarvatt, the patch was supposed to be something to get us by until upstream X got support to find the devices sooner
<superm1> Sarvatt, er not find them sooner, i think it was so that it could fail earlier and not fail so hard
<superm1> Sarvatt, since we're nouveau by default, i'd say the patch is pretty moot now though
<Sarvatt> yeah but some devices relied on that broken behavior and the maintainer didnt want to have anything to do with changing it, we had a lot of bugs about non working AGP cards :(
<superm1> if i remember right slangasek raised something like that
<superm1> but since they were kicked to vesa (and were probably going to install -nvidia anyway) this patch made most sense
<superm1> it certainly fixed a bunch of hardware I had that *didn't* work with nv, but worked with vesa (and thankfully works with nouveau now)
<Sarvatt> I stopped messing with it mvo, I really agree dropping the 2 patches is the way to go :)
<Sarvatt> Kangarooo: hmm your backtrace is completely different now
<mvo> Sarvatt, superm1: so what is the best way forward? dropping -nv entirely ? or just dropping the patch and upload the merged -nv?
<Sarvatt> dropping the 2 patches yeah, not sure that the panel fitting is worth merging over just syncing it either. we could just special case the ion board that had a problem, the problem superm1 was having with multiple gpu's where one wasnt supported by nv but the other was shouldnt be around anymore either
<lucazade> Sarvatt: MeeGo 1.0 In-Vehicule Preview ntel eMenlow (US15W) http://vimeo.com/11779730    
<Sarvatt> lucazade: got an img? :)
<Sarvatt> or a .ks?
<lucazade> http://repo.meego.com/MeeGo/builds/0.9/0.9.80.2.20100512.1/ivi/images/meego-preview-ivi-noemgd-ia32/
<lucazade> maybe..
<lucazade> bingo?
<lucazade> :)
<Sarvatt> nope thats not it
<Sarvatt> i have that one
<lucazade> in the vimeo description says us15w
<Sarvatt> This image will boot to XFCE utilizing the Linux VESA graphics driver and has been tested on Intel eMenlow (US15W) and Tunnel Creek platforms. A Beta release of the Intel EMGD 3D graphics driver for MeeGo on these platforms is expected in June 2010.
<Sarvatt> there's nothing psb/img/mrst related in the repos either besides psb-kernel-headers, just checked
<lucazade> ok thanks
<Sarvatt> none of the kernel patches on there, no modules for it
<Sarvatt> none of the stuff in the kernel-headers package either :(
<lucazade> on #meego vgrade said: "no the its not the same patch as the moorsetown one, it looks quite similar to a traditional SGX driver."
<Sarvatt> yeah they have a straight up powervr binary image, i've seem them talking about it in bug reports
<lucazade> http://bugs.meego.com/show_bug.cgi?id=2205
<ubot4> bugs.meego.com bug 2205 in Graphics subsystem "request integration of EMGD into ivi/embedded distribution" [Major,Reopened]
<Sarvatt> so far i've seen 4 different ones, pvr mrst img and psb
<Sarvatt> +            } else if ((dev->device_id == 0x8108) || (dev->device_id == 0x8109) || (dev->device_id == 0x4102)) {
<Sarvatt> +		driverList[0] = "psb";
<Sarvatt> +		driverList[1] = "pvr";
<Sarvatt> pvr supporting psb!
<lucazade> :)
<Sarvatt> unless they are just lazy/sloppy :)
<lucazade> unbelievable
<Sarvatt> oh
<Sarvatt> yeah, i remember now, one of the bug reports was saying there were graphics problems with the pvr internal images,
<Sarvatt> they patched around the problems in mesa and i found the bug number from one of the patches, let me find it
<lucazade> ok
<Sarvatt> Kangarooo: try sudo nvidia-xconfig --no-composite
<Sarvatt> http://bugs.meego.com/show_bug.cgi?id=352
<ubot4> bugs.meego.com bug 352 in Graphics subsystem "[Qt demos] opengl/Pixel Buffers failed due to not support pbuffers" [Normal,Verified: fixed]
<Sarvatt> Pvr driver: 5.3.0.0002-1.1
<lucazade> yes
<Sarvatt> the mrst kernel module has a similar version
<Sarvatt> hmm should events and such from include/GL/glxext.h be included in xserver's dix/protocol.txt and xtrace?
<Sarvatt> i noticed some events from there is in xtrace that aren't defined in glproto
<lucazade> i don't know, sincerly.. i know just a bit of xorg
<Sarvatt> CONFIG_IMG_DOES_NOT_SUPPORT_MENLOW=y
<Sarvatt> in the menlow kernel config
<Sarvatt> ahh ok theres img the pvr one, then theres mrst the poulsbo one
<lucazade> i trust you!
<Sarvatt> err, ok, i'll shut up. the poulsbo kernel config has all the pvr stuff enabled
<Sarvatt> need to look at the source and see whats up, darn gitorious doesnt let you browse large stuff
<Sarvatt> http://sarvatt.com/git/cgit.cgi/xylius-kernel-source/
<Sarvatt> so the mrst one is the open source one and thats the closed source one
<lucazade> ok
<Sarvatt> man trying to load that latest commit on this atom cpu is insane
<Sarvatt> going on 3 minutes now and i still cant scroll down
<lucazade> :) everything related to psb look insane to me
<Sarvatt> yeah mrst the one they had before has that its going to try to go upstream, this one says upstream: never
<Sarvatt> perfect timing though i got a psb netbook coming to me in a few days :)
<lucazade> great.. i can test if you need
<lucazade> if i'm able
<Sarvatt> i guess iged changed names to emgd
<Sarvatt> or something..
<lucazade> ah ok...
<Dr_Jakob> oh so they have released that driver as well.
 * Sarvatt waits to find Dr_Jakob's name in a copyright :)
<Dr_Jakob> Probably not
<Dr_Jakob> I only touched the modesetting code and stuff inside the 3D driver.
<Dr_Jakob> Oh and one or two things inside the 2D driver..
<Dr_Jakob> but that was for the none iged driver.
<Dr_Jakob> Sarvatt: what parts of the new vmwgfx svga driver is in the gallium ppa?
<Dr_Jakob> vmware 10.0.1, mesa master?
<Sarvatt> 1:11.0.1+git20100423.423d8a06-0ubuntu0sarvatt but no svga in mesa yet, hit a snag because the arm people need opengles headers to build stuff and there's a lot of packaging things to work out
<Sarvatt> not to mention its completely different on master than 7.8.1 where RAOF is packaging the stuff up at
<Sarvatt> the gallium stuff not being in /usr/lib/dri really stinks, --with-dri-searchpath isnt really an option outside of testing
<bryceh> Sarvatt, RAOF, there is a -displaylink X driver package that's in universe
<Sarvatt> it'd be nice if all the gallium drivers had different names and it would check the g suffix one if KMS was in use or something :)
<Sarvatt> err try to load the r300g_dri.so first and fall back to r300 if it can't I mean, I don't know
<Sarvatt> heck, i can just enable svga and it'll be installed with /usr/lib/dri until its packaged up, lets try that :)
<Sarvatt> oh yeah the _drv.. need to build and see where it goes
<Sarvatt> still can't download IEGD from intel in any browser, just downloads the windows version no matter what I pick
<Dr_Jakob> Sarvatt: what about kernel drivers? Does the ppa include new kernel drivers as well?
<lucazade> if i remember well inside iegd windows executable there is linux stuff
<Sarvatt> yeah its got maverick's kernel in it but you have to install it manually, its linux-image-2.6.34-5-generic right now
<Sarvatt> linux-libc-dev which has the drm headers in it from the kernel automatically upgrades though
<Sarvatt> libdrm has libkms built as well and the vmwgfx header
<Dr_Jakob> ok
<Dr_Jakob> have you tested it all in a VM?
<Dr_Jakob> I don't know if the driver still barfs at QEMU/KVM.
<Sarvatt> yeah it works, didnt test 3D or anything though
<Sarvatt> (dont know if thats what you meant)
<Dr_Jakob> Ok cool
<Dr_Jakob> you sure you didn't get the old driver?
<Sarvatt> i'm sure I did
<Dr_Jakob> ok
<Sarvatt> never build mesa with svga enabled, doing that now
<Dr_Jakob> ok
<Dr_Jakob> as long as you install vmware 10.0.1 it should auto pick the correct driver.
<Dr_Jakob> err
<Dr_Jakob> 11.0.1
<Dr_Jakob> but yeah you had that.
<Sarvatt> all i need to know is where the _drv is when adding xorg to the state trackers list and building it and i'll upload it to edgers
<Sarvatt> just because of the weird places debianized mesa puts things
<Kangarooo> Sarvatt: that backtrace i added is still without your PPA. icant get backtrace with your ppa since comp not only freezes desktop but also freezes ssh
<Sarvatt> well at least thats different :)
<Sarvatt> did you try sudo nvidia-xconfig --no-composite ?
<Kangarooo> should i try that sudo nvidia-xconfig --no-composite with your ppa installed or remove them and then with original files try that?
<Sarvatt> yeah get rid of the PPA one
<Sarvatt> your backtraces look different every time
<Sarvatt> http://launchpadlibrarian.net/49499123/gdb-Xorgwithtail-fXorg.c.txt  http://launchpadlibrarian.net/49412494/GdmLog1.txt http://launchpadlibrarian.net/49412495/GdmLog2.txt
<Sarvatt> doh, mesa didn't check for xorg-server.pc before starting the compile with xorg state tracker?
<Sarvatt> silly me forgot it in the chroot
<Kangarooo> so ppa i can remove from synaptic only? so when i uncheck and use aptitude reload && dist-upgrade yes?
<Sarvatt> ok easy enough - dh_install: usr/lib/glx/pkgconfig/gl.pc exists in debian/tmp but is not installed to anywhere
<Sarvatt> dh_install: usr/lib/glx/xorg/modules/drivers/radeong_drv.so exists in debian/tmp but is not installed to anywhere
<Sarvatt> dh_install: usr/lib/glx/xorg/modules/drivers/modesetting_drv.so exists in debian/tmp but is not installed to anywhere
<Sarvatt> dh_install: usr/lib/glx/xorg/modules/drivers/vmwgfx_drv.so exists in debian/tmp but is not installed to anywhere
<Sarvatt> dh_install: usr/lib/glx/xorg/modules/drivers/i965g_drv.so exists in debian/tmp but is not installed to anywhere
<Sarvatt> Kangarooo: wget https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+files/ppa-purge_0.2.6_all.deb && sudo dpkg -i ppa-purge_0.2.6_all.deb && sudo ppa-purge -p bugsbugsbugs sarvatt
<Sarvatt> its a little script that removes a ppa and downgrades everything back to the archives
<Kangarooo> ok that is done. also some upgrades i put. so now i without restart can sudo nvidia-xconfig --no-composite ?
<Kangarooo> so now ill also try reproducint with backtrace gdb runnin yes?
<Sarvatt> yeah without restart, it just adds a line to your xorg.conf
<Sarvatt> nah
<Sarvatt> just see if you can crash it
<Sarvatt> Dr_Jakob: i'll probably have it up on xorg-edgers in the next hour, almost done with it
<Sarvatt> is there anything else in mesa that would be worth packaging up?
<Sarvatt> i really want to wrap my head around all of this EGL stuff but it's crazy complicated in mesa
<Kangarooo> Sarvatt: nope that didnt help. again boom goes the x
<Sarvatt> is there anything special about your machine?
<Sarvatt> you seem to be having problems with that one in a ton of different packages, just seems like it might be a bigger problem but thats reaching for straws :)
<Kangarooo> Sarvatt: nothing special. i tink lspci can be seen in bug report no? just that hardware and clean xubuntu 10.04 (of course with latest updates) but with ur ppa it wasnt crashing. ill maybe try again your ppa and without dbg try to crash it. couse with gdb tryng crash all froze (even ssh)
<Kangarooo> Sarvatt: u removed ur ppa? i get an error when using update after adding ur ppa again
<Kangarooo> ah now its working- i added ppa without /ubuntu and got error. rm thoyuse sources and added ppa again with /ubuntu now its working
<Sarvatt> sorry, trying to get this vmwgfx packaged up because it finally finished building. why are you activating the ppa again?
<Kangarooo> couse maybe that will be working? couse ppa i tryd crashing with gdb working also. maybe without gdb system wont freeze totaly?
<Sarvatt> naah that patch I added really was a longshot and probably did make things worse, it sounds like its a bigger problem and its over my head
<Kangarooo> ah ok. Sarvatt so i should undo that nvidia command also? ill buy a replacement for this pc after 2 weeks if for somebody it can be needed i can put vnc and leave everything open in it.
<Kangarooo> in this crashing pc
<Sarvatt> i'd try with all 3 options disabled
<Sarvatt> no-composite no-render and  no-render-accel? (not sure on the last one)
<Sarvatt> those might not be right, check nvidia-xconfig --help
<Sarvatt> Dr_Jakob: sorry it took so long, uploading it now :)
<Sarvatt> now to find a vmware release to play with this on :)
<Sarvatt> i dont think the vmwgfx kernel module works with qemu vmware graphics mode? remember airlied having a hacked up patch for it
<Sarvatt> that guys post about harvest the other day on planet ubuntu really made me want to automate xorg-edgers more via something like that :)
<bryceh> totally, go for it
<bryceh> it was always my hope too that more of xorg-edgers could be automated
<bryceh> well you know how much of an automation geek I am ;-)
<Sarvatt> darn, its java! yuck
<Sarvatt> i guess i could just use ppa-update, never actually tried it
<Sarvatt> still lots of little hidden env variables i dont know about in auto-xorg-git, i just do things like make the package for other releases manually every time
#ubuntu-x 2010-06-02
<Sarvatt> eww, so yeah, think I see what else might be causing some of the problems with vga16fb.. its making the agp modules load early and nvidia's agp module doesnt get used and causes problems
<Sarvatt> just gonna get worse when agp is built into the kernel :)
<RAOF> Sarvatt: Fortunately, we're going to be dropping the vga16fb patch that binds it to *
<Sarvatt> i think tomorrow is gonna be transitioning edgers to the new xsfbs day after maintenance
 * Sarvatt signed his life away for a vmware workstation trial to try this darn driver
<RAOF> Thanks for giving that a whirl!
<Sarvatt> i just went the and installed the 2D gallium component in libgl1-mesa-dri-gallium, the 3D side is in dri because i'm not using the same build setup you're working on
<Sarvatt> the egl/gles stuff is all wacky and different in 7.9, debian/ from origin/ubuntu doesnt work
<Sarvatt> plan on enabling everything and seeing whats installed in a few minutes when this is done downloading though, will probably finish compiling before i can even boot anything virtualized on this atom :)
<Sarvatt> when is the 10.04.1 freeze? that xserver SRU really needs to go in
<Sarvatt> guess I better build vmmouse in edgers first huh
<Sarvatt> failed because of the xsfbs stuff forever ago and i forgot to fix it :D
<Sarvatt> lol vmware no likey RGBA windows
<Sarvatt> http://sarvatt.com/downloads/rgba.png
<Sarvatt> at least i can watch irc while it loads
<Sarvatt> heh i have to take screenshots of it to see whats going on
<RAOF> Heh.
<Sarvatt> saved by vnc
<Sarvatt> well, an hour to fully install it
<Sarvatt> i wouldnt have booted the livecd in qemu by now
<RAOF> Lunch!
<Sarvatt> need to make libgl1-mesa-dri-gallium depend on libkms1
<Sarvatt> i'm doing it all over remote desktop to another machine running it in a VM since I cant use this one because of gtk in maverick.. plymouth segfaulted :)
<Sarvatt> not sure if i'll even get 3D over RDP
<Sarvatt> nice, it works! outside of plymouth :)
<Bernardo> good morning
<RAOF> Hoo.  Looks like there's a reasonable chance I'll get h264 decode acceleration on my intel chip in Maverick.
<Bernardo> RAOF: which is your intel chip?
<RAOF> GM45
<Bernardo> nice. Too bad I've lost h264 decoding for now on my poulsbo, or I could brag on having it since hardy... ;)
<Bernardo> But I do hope we get more and more hw decoding features supported
<Dr_Jakob> Sarvatt: I'm guessing that you are not running XChat in the VM? :)
 * Bernardo tried to get ahead on https://bugs.freedesktop.org/show_bug.cgi?id=28077, but got quickly lost in exa calls
<ubot4> Freedesktop bug 28077 in Acceleration/EXA "X segfault in miCopyRegion / fbCopyNtoN" [Normal,New]
<Dr_Jakob> Sarvatt: plymouth doesn't support vmwgfx?
<alf__> RAOF: Hi!
<RAOF> alf__: Ho!  How are those packages for you?
<alf__> RAOF: Great, thanks!
<alf__> RAOF: I notice that the gallium intel driver is not built by default. Is that on purpose?
<alf__> RAOF: I built it my self and it was a bit unstable to be honest (at least as far as gles2 is concerned).
<jcristau> considering that it doesn't work, not building it seems sane.
<alf__> jcristau: It worked more or less for gles 1.1 examples that I tried, but segfaulted with gles2 progs.
<alf__> jcristau: and the software rasterizer sucks :)
<jcristau> *shrug*
<RAOF> alf__: What intel card do you have.  I understand that i915g is less liable to instantly hang your GPU than i965g, which is what I was testing.
<RAOF> Imagine a question mark in the first sentence :)
<alf__> RAOF: i915. The driver actually segfaults with gles2 in userspace. Valgrind catches the invalid write.
<RAOF> Well, that's one up on i965, which hung my GPU as soon as I tried anything - gles1, gles2, openvg.
<alf__> :D
<RAOF> It's possible this is better in git master, but I don't think so - Intel gallium looks pretty unloved.
<alf__> RAOF: No problem, we actually needed the build mainly for -dev packages so others can build against mesa egl/gles*
<RAOF> Yeah, that was what I was thinking.
<alf__> RAOF: Is radeon support better? I am planning on buying a new desktop with an ATI/AMD card and it would be great if I could try gles* things out
<RAOF> If you can aquire an r300-r500 card, absolutely.  There's a good chance that Maverick will ship with that gallium driver as DRI driver for those cards.
<RAOF> r600+ is less good; the current gallium driver doesn't actually submit commands to the card yet :)
 * alf__ goes to check what chip is in the card he is planning to buy
<RAOF> (The current generation cards are Radeon 4xxx, which is r700, and Radeon 5xxx, which is r800/greenhorn or some other such codename)
<RAOF> Possibly marmaduke.
<alf__> So I am doomed :)
<RAOF> ebay should set you up with a perfectly servicable r300-r500 for about $30
<jcristau> i thought you could use egl_dri2 and classic dri drivers
<RAOF> Only for opengl; they don't support gles
<RAOF> egl_dri2 gets you OpenGL on a EGL context, as far as I understand it.
<jcristau> k
<alf__> RAOF: thanks for all the info!
<lucazade> hi! new IVI xorg-x11-drv-emgd released... http://bugs.meego.com/show_bug.cgi?id=2205#c7
<ubot4> bugs.meego.com bug 2205 in Graphics subsystem "request integration of EMGD into ivi/embedded distribution" [Major,Reopened]
<Bernardo> hi lucazade
<lucazade> hi Bernardo
<Bernardo> Those are good news - if the driver at least builds. :)
<lucazade> if it works could be a record
<Bernardo> for now, I'd be glad if it builds. The moblin driver won't even build...
<lucazade> Bernardo: don't know if useful, this repo contains moblin drivers for karmic http://fit-pc2.com/download/ubuntu/dists/karmic/source/
<Bernardo> Weren't those using our drivers?
<Bernardo> I'll check, but that seems suspiciously like our karmic drivers
<Bernardo> bbl, time to enjoy the sun
<trelayne> hi all, when in twinview using nvidia, when I maximize a window, it maximized between both monitors.. Anyone know how to make it maximize only on one?
<Sarvatt> Dr_Jakob: yeah, VMware workstation doesn't like a maverick host with all of the gtk2 wackiness :)
<Sarvatt> 7.1
<Dr_Jakob> Sarvatt: hmm weird, have anybody filed a bug with vmware?
 * Dr_Jakob checks the internal bugzilla...
<Sarvatt> haven't looked yet, still messing around with it on a windows host remotely. turns out that first upload i did failed to build because it also needed xineramaproto
<Sarvatt> and i just woke up, updating things now to see if it works
<Sarvatt> (in the VM)
<Dr_Jakob> ok
<Dr_Jakob> you might need to blacklist vga16... I had problem with that whem I played around with 10.04.
<Dr_Jakob> Hmm nope can't say anybody has filed a bug for that..
<Dr_Jakob> but then again my bugzilla-fu is weak.
<Sarvatt> seems to be working - http://sarvatt.com/downloads/vmwgfx.txt
<Sarvatt> using swrast though, hmm
<Sarvatt> ah acceleration disabled
<Sarvatt> maybe i have to reinstall the tools or something, its enabled in the vmware settings
<Sarvatt> -rw-r--r-- 1 root root 9768624 2010-06-01 23:51 /usr/lib/dri/vmwgfx_dri.so
<Sarvatt> ah maybe because i'm logged into the host over remote desktop :)
<Sarvatt> ah when it tries to use it it just dies with setting up EXA in the log
<Sarvatt> [  114.333800] [drm:vmw_fb_setcolreg] *ERROR* Bad regno 16.
<Sarvatt> [  114.333806] [drm:vmw_fb_setcolreg] *ERROR* Bad regno 17.
<Sarvatt> [  114.333808] [drm:vmw_fb_setcolreg] *ERROR* Bad regno 18.
<Sarvatt> repeated up to 255 in dmesg
<Sarvatt> so it only works when i start it when logged into the host over RDP so the 3D isn't used, bummer
<Sarvatt> ok gonna start transitioning xorg-edgers to the new xsfbs stuff so upgrades will probably be broken for a few hours :)
<bryceh> Sarvatt, wishing luck
<Sarvatt> last time i tried it in another PPA it forced nvidia-current and radeonhd to  be installed
<Sarvatt> hmm the breaks: on  xserver-xorg-input-synaptics (<= 1.2.2-1), needs to be adjusted I think, ubuntu is at 1.2.2-1ubuntu4 thats broken by the new xserver
<cwillu_at_work> -novtswitch is disabled these days?
<Sarvatt> will push it just need to check the other breaks first
<Sarvatt> "these days"?
<cwillu_at_work> is that scare quoted because it should still work, or because it hasn't worked in forever?
<Sarvatt> it's quoted because i dont think it was ever enabled
<Sarvatt> don't know if you meant it was before
<cwillu_at_work> let me restart
<cwillu_at_work> the -novtswitch doesn't do anything;  is this recent, or has it been a noop for a while?
<cwillu_at_work> I'm specifically looking at arm / omap
<Sarvatt> how are you starting X?
<Sarvatt> if its gdm you have to patch the source to change starting options afaik..
<cwillu_at_work> Sarvatt, I'm starting x from a serial terminal:  Xorg vt2 -novtswitch
<cwillu_at_work> looking at the source, there's a check on serverGeneration;  one way it checks VTSwitch, the other way it doesn't
<cwillu_at_work> hw/xfree86/os-support/linux/lnx_init.c:229 is what I'm looking at (compare to :291)
 * cwillu_at_work patiently waits for xorg to compile in a qemu-static chroot
<Sarvatt> The following packages will be REMOVED:
<Sarvatt>   xserver-xorg-input-all xserver-xorg-input-vmmouse xserver-xorg-video-all xserver-xorg-video-nv
<Sarvatt> The following NEW packages will be installed:
<Sarvatt>   dkms nvidia-current nvidia-settings xserver-xorg-video-radeonhd
<Sarvatt> The following packages have been kept back:
<Sarvatt>   xserver-xorg-core
<Sarvatt> thats what i get with just xorg-server updated
<Sarvatt> cant figure out why nvidia-current is in there
<Sarvatt> ah thats just a dist-upgrade, upgrade is fine.. what the heck :)
<Sarvatt> yeah i'll just do all this on maverick first and upload the lucid stuff once i work it out :)
<Sarvatt> luckily xorg-server failed on lucid because of libpciaccess
<cwillu_at_work> how long does a typical clean -j1 build of xorg take?
<Sarvatt> already built?
<cwillu_at_work> no
<Sarvatt> xorg the metapackage?
<cwillu_at_work> no, the big one
<cwillu_at_work> fresh checkout, on a slow computer, but with lots and lots of memory and the build-tree on a ramdisk
<Sarvatt> real	0m5.028s user	0m3.384s sys	0m0.872s
<cwillu_at_work> liar
<Sarvatt> you mean a fakeroot debian/rules clean?
<cwillu_at_work> yes
<Sarvatt> of xserver?
<Sarvatt> thats my time..
<Sarvatt> time fakeroot debian/rules clean
<cwillu_at_work> no, I meant, building the package, _after_ a debian/rules clean :p
<Sarvatt> oh lol
<Sarvatt> about 20 minutes on my atom cpu
<cwillu_at_work> trying to decide if it's worth it to cancel the build and rerun it with j4
<cwillu_at_work> hmm
<Sarvatt> 14 on a PPA
<Sarvatt> probably 5 of that spent installing deps
<cwillu_at_work> 2 hours and counting on a quad-core building it in an arm qemu
<Sarvatt> lol yeah that sounds normal
<Sarvatt> its about 3-4 hours for me in a arm chroot
<cwillu_at_work> okay
<cwillu_at_work> oooo, dh_install!  I must be nearly done
<Sarvatt> merged xorg 7.5+6 in git. should I bump things for xserver 1.8 abi's?
<cwillu_at_work> ding
<Sarvatt> what xserver were you building?
<cwillu_at_work> all of them? :p
<cwillu_at_work> xorg-server-1.7.6; dpkg-buildpackage on armel
<Sarvatt> ah I see why nvidia-current is getting pulled in, Provides: xserver-xorg-video-6
<Sarvatt> and xserver-xorg depends on xserver-xorg-video-all | xserver-xorg-video-6, xserver-xorg-input-all | xserver-xorg-input-7 when the -all's were getting removed
<Sarvatt> ah didn't know if you were building 1.8.1 from git
<Sarvatt> -nv was build against xserver 1.7.x in edgers so its no wonder
<Sarvatt> darn wacom and tslib not being in pkg-xorg, cant use auto-xorg-git
<Sarvatt> doh yeah and this..
<Sarvatt>   xserver-xorg-core: Breaks: xserver-xorg-input-7
<Sarvatt>                      Breaks: xserver-xorg-video-6
<Sarvatt> guess i'll downgrade the breaks some more
<jcristau> that would be bad.
<jcristau> unless i'm misunderstanding..
<Sarvatt> oh what the heck, nvidia-current Provides: xserver-xorg-video-7 so that doesn't explain it
<Sarvatt> i must have -vv and looked at the maverick one..
<Sarvatt> just gotta update everything providing xserver-xorg-video-6 still I guess
<Sarvatt> i should have prepared all drivers for upload before uploading the server, next time i'll remember that
<Sarvatt> call me lazy but as often as I update stuff I like to just say all irrelevant drivers are broken and leave it at that :) but the vast majority of those crappy ones are just easy syncs from debian-unstable so i can just script all these
<Sarvatt> heyo tormod, you around?
<Sarvatt> how do I set options to pass to auto-xorg-git with ppa-update?
<tormod> hi Sarvatt, for a short while :)
<tormod> you can in a hacky way include them in the hooks argument
<Sarvatt> need to pass update crap drivers noone cares about that provide xserver-xorg-video-6 still :(
<Sarvatt> mass update rather
<Sarvatt> might as well do it now because when i move to xserver 1.9 soon i'll have the sources handy to just rebuild with 
<tormod> I sent you my "master" ppa update script once, can you find it?
<tormod> it had some examples of passing options thru ppa-update
<Sarvatt> oh?
<Sarvatt> i have like 30k files in the xorg-pkg-tools directory so i probably missed it :)
<Sarvatt> (tab completion takes awhile to say the least)
<tormod> the script was "go-update.sh" sent Fri, Sep 18, 2009
<Sarvatt>  AOPS=?
<Sarvatt> AOPTS rather
<Sarvatt> ah thanks
<Sarvatt> guess I could just drop the packages from video-all/input-all in the meta, that'd be easier :)
<tormod> wouldn't be the first time we do that in xorg-edgers :)
<Sarvatt> goodbye apm, ark, chips, cirrus, geode, i128, i740, neomagic, siliconmotion, tdfx, openchrome and voodoo!
<Sarvatt> well it still doesnt stop things from being broken actually
<Sarvatt> xserver-xorg-core actually breaks anything with the old abi's :(
<Sarvatt> its too much to work around from what I can see, going to just drop the breaks..  can't account for people that installed things not in the meta and not planning on updating things like virtualbox and crap
<Sarvatt> virtualbox-ose-guest-x11 provides xserver-xorg-video-6
<Sarvatt> The following packages have unmet dependencies:
<Sarvatt>   xserver-xorg-video-nv: Depends: xorg-video-abi-7.0
<Sarvatt> ahh i rebuilt one i hacked up at a bad point trying to revert the xsfbs changes, oops
<Sarvatt> i hate to upload all drivers like this, using this numbering scheme stops debian updates from coming automatically later unless the version gets bumped upstream and i dont watch changes in most of these
#ubuntu-x 2010-06-03
<Sarvatt> hope noone needed to use a PPA :)
<Sarvatt> builder rather
<Sarvatt> https://edge.launchpad.net/builders
<Sarvatt> lol
<Sarvatt> ugh, touchpad is SUPER slow after the latest synaptics upgrade. can't adjust it in the mouse capplet
<Sarvatt> think i'm going to revert http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=a489ec15eb489a3528f6fee99716f7f4ae35f9ee for now, none of the synclient options change the speed either
<Sarvatt> ok tested xorg-edgers on 7 machines and they all upgraded from stock fine and work, phew that took all day
<Sarvatt> now to do it all again in a week when 1.9 branches
<bjsnider> Sarvatt, is there going to be a mesa update for 10.04.1? fedora's performance is much better
<Sarvatt> no, 7.7 branch is dead :(
<RAOF> Define âmuch betterâ in such a way that an update fixing performance is sufficiently important :)
<Sarvatt> RAOF: check the phoronix ubuntu vs fedora article
<Sarvatt> http://www.phoronix.com/data/img/results/fedora13_vs_ubuntu1004/2.png  -- that one especially
<RAOF> I'm looking at bug #531069, and I'm _sure_ I've seen a relevant commit somewhere, but I can't seem to find it now.  Do you have any ideas?
<ubot4> Launchpad bug 531069 in xserver-xorg-video-intel (Ubuntu) "Display error when returning from sleep after docking (affects: 1) (heat: 12)" [Low,Triaged] https://launchpad.net/bugs/531069
<Sarvatt> yeah that should be already fixed raof
<RAOF> In Lucid?
<Sarvatt> one sec i'll dig up the kernel patch, it was the one they dropped in the 2.6.33 drm backport  by mistake and readded just before release
<Sarvatt> if you ask if they're still experiencing it i'm sure they'll say no
<Sarvatt> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=0d2907f4bead56cff60f91068b3a3efa7149e702
<Sarvatt> readded not long after they submitted the bug
<RAOF> I've also got someone with a similar symptom with what should be an up-to-date lucid; certainly they're using 2.6.32-22
<ripps> woo lot of xorg-edgers updates tonight
<Sarvatt> hah, it'd help if I actually read planet.freedesktop.org this week before complaining about synaptics! http://who-t.blogspot.com/2010/06/new-synaptics-acceleration-mechanism.html
<Sarvatt> ripps: yeah today was a "fun" day.. lol
 * RAOF should subscribe to planet.freedesktop.org, really.
<bryceh> me too
<Sarvatt> theres hardly ever any updates on it
<Sarvatt> that blob post makes it sound like the slowness is at an acceptable level
<Sarvatt> but we're talking 6 or so swipes full from left to right to move the pointer  to the other side of the screen slow
<Sarvatt> good to know gnome will get updated to adjust it at least, i couldnt figure out the synclient options to make it any faster and the mouse capplet acceleration bar did nothing
<ripps> There should be some kind of changelog that explains what features xorg-edger has over the default ubuntu version.
<Sarvatt> its at the top of the ppa description
<Sarvatt> broken down by release, when i add new things i put it there
<Sarvatt> it could be a lot better than my disjointed ramblings though :)
<RAOF> âNew stuffâ
<Sarvatt> ripps: i reverted the pointer acceleration stuff he's talking about in that blog post if thats what you meant :D
<Sarvatt> it was unusably slow on 3 different laptops
<RAOF> Oh, look at that â displaylink updates!
<Sarvatt> i guess you could use phoronix as an xorg-edgers changelog
<Sarvatt> just have to take it with a *big* grain of salt :)
<Sarvatt> RAOF: where at?
<RAOF> planet.freedesktop.org
<RAOF> Specifically: dropping the DDX component in favour of making fbdev slightly better.
<Sarvatt> yay probably not compatible with what tiago is trying to do to fbdevhw and wont be updated for another year :)
<Sarvatt> i wish i could pass messages to the package manager letting people choose if they want to uninstall a PPA or keep getting updates if they are using something thats really broken from the updates :)
<Sarvatt> like say the blobs when i put xserver 1.9 in there
<RAOF> There was a thread on ubuntu-devel-discuss about roughtly that.
<RAOF> It could be useful, yeah.
<Sarvatt> sucks that ricotz's gnome-shell ppa is probably going to be useless for all of maverick, I liked having newer clutter and mutter
<Sarvatt> glxgears crashes mutter the same way it did metacity, doubt it'd be fixed upstream
<RAOF> glxgears crashes mutter?
<RAOF> Who's to blame there?
<Sarvatt> gtk
 * RAOF re-reads the above, and find that it makes sense.
<RAOF> On the other hand, there's a patch for metacity to make it work, so it's probably pretty easy to make mutter work, too.
<stenten> If someone boots into a black screen, and then recovers in a tty with 'startx' but not 'sudo service gdm start', should I reassign it to gdm?
<stenten> Bug #586173
<ubot4> Launchpad bug 586173 in xserver-xorg-video-intel (Ubuntu) "[i945] intel gma 82945G xorg does not work at boot (affects: 2) (heat: 14)" [Undecided,Confirmed] https://launchpad.net/bugs/586173
 * RAOF has a look-see
<RAOF> stenten: That looks a bit strange.  It could well be a gdm bug, but I think it's more likely to be X related.
<RAOF> stenten: Strange compents include: why is vga16fb being loaded?  Is there any difference in X log files between running startx and running âsudo start gdmâ?
<stenten> RAOF: Hmm, I never thought of either of those, thanks.
<RAOF> vga16fb caused problems early in Lucid; booting with âvideo=vga16fb:disableâ might be an interesting data point.
<stenten> Never heard of it. I'll have to read up on it some.... In the meantime, I'll make sure to ask for those, thanks.
<Dr_Jakob> Hmm the dmesg errors are not related to X, something is trying to use 8bit color mode on the framebuffer
<Dr_Jakob> Sarvatt: ^^
<Dr_Jakob> Which we don't support..
<cwillu_at_work> isn't plymouth running in 8bit on non-kms drivers?
<cwillu_at_work> can we enable -nr for omap?  works fine if I add pScrn->canDoBGNoneRoot  = 1; to omapfb-driver.c
 * cwillu_at_work pokes at Sarvatt
<lucazade> hi
<lucazade> Bernardo http://www.phoronix.com/scan.php?page=news_item&px=ODMxNw
<lucazade> and http://www.advogato.org/person/mjg59/diary.html?start=250
<lucazade> about Poulsbo
<Sarvatt> jcristau: dont know if you saw on the lists but 1.7-branch is free for all now and whot said not to use nominations in his stepping down thread
<jcristau> yeah saw that
<jcristau> but i was too lazy to move stuff over to 1.7-branch so i pushed one more to -nominations :)
<jcristau> Sarvatt: i had missed the end of 1.7 in the 1.7.7 announcement though
<Sarvatt> ricotz: can you apply this patch for mutter in maverick in your PPA? http://sarvatt.com/downloads/patches/0001-Use-gdk_screen_get_system_colormap-instead-of-gdk_sc.patch
<bryceh> RAOF, https://wiki.ubuntu.com/X/Blueprints/ will need to be brought up to date at some point when you have some time
<Sarvatt> XLIB_SKIP_ARGB_VISUALS=1 vmware is the magic to make it work under maverick if anyone  else goes to try those vmwgfx drivers:)
#ubuntu-x 2010-06-04
<ripps> Hmm... the launchpad kernel ppa now supplies maverick kernel backports for lucid
<Sarvatt> not supported on the desktop though unfortunately
<Sarvatt> but thats not saying not to use it :)
<Sarvatt> nouveau wont work though
<RAOF> Unless you like fbdev
<Sarvatt> i went 3 days once using fbdev on top of kms without realizing it :)
 * Sarvatt is running xts against xorg-edgers, woohoo
<Sarvatt> bah, For Linux hosts, make sure the host has a video card that can run accelerated OpenGL 2.0.
<Sarvatt> no wonder i couldn't get vmware 3D running on this netbook
<RAOF> That's going to cut down significantly on who can use it.
<Sarvatt> enabled the fake opengl 2.0 support on i915, now it fails the same way it does with a windows host..
<Sarvatt> gdm spawns it like 20 times and gives up, falls back to failsafe
<Sarvatt> http://pastebin.com/j16SVuG1
<Sarvatt> the drm:vmw_fb_setcolreg crap in dmesg is just from when it gives up trying to start a real X and launches failsafe fbdev on top of vmwgfx
<Sarvatt> maybe the 2.6.35-rc2 vmwgfx will work
<Sarvatt> we cant exactly ship vmwgfx/svga with mesa, I mean it needs X to build, and X needs mesa to build.. lol
<Sarvatt> Dr_Jakob: any ideas what I'm doing wrong? do things only work with specific versions or something?
<Kangarooo> Sarvatt: ? i finally got xcrash with ppa bugsbugs should i add it to that bug or send on irc? for me it looks like theres nothing but i dont know about gdb anything
<Sarvatt> oh wow I totally screwed up the fglrx 10.5 packaging in x-updates, needed another patch and i messed up the patch rules for the one i added even :)
<Sarvatt> all fixed up now
<Sarvatt> does nvidia need patches to build on 2.6.34?
<RAOF> We really need to reduce the number of patches we apply to X.
<RAOF> I don't think it does; last I checked everything worked swimmingly.
<Sarvatt> anyone around to accept this sync request? https://bugs.edge.launchpad.net/ubuntu/+source/libxprintutil/+bug/589528
<ubot4> Launchpad bug 589528 in libxprintutil (Ubuntu) "Sync libxprintutil 1:1.0.1.xsf1-3 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<Sarvatt> going through bryce's versions-current
<Sarvatt> also https://edge.launchpad.net/bugs/589530
<ubot4> Launchpad bug 589530 in xserver-xorg-video-vesa (Ubuntu) "Sync xserver-xorg-video-vesa 1:2.3.0-3 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<Sarvatt> is there any way I can request syncs using my ubuntu email address? they show up as my main email address since I can't put the @ubuntu.com first because it breaks forwarding
<Sarvatt> syncpackage rocks, wish I had upload rights :)
<Sarvatt> ok https://edge.launchpad.net/bugs/589531 was the lastthat are straight syncs
<ubot4> Launchpad bug 589531 in xserver-xorg-video-mga (Ubuntu) "Sync xserver-xorg-video-mga 1:1.4.11.dfsg-4 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<Sarvatt> updated the wiki with notes on what needs merged still, probably should have them ready before xorg-server is uploaded
<RAOF> did I not already request a vesa sync?
<Sarvatt> ah found some more
<Sarvatt> yea
<Sarvatt> https://edge.launchpad.net/bugs/589535
<ubot4> Launchpad bug 589535 in xf86-input-evtouch (Ubuntu) "Sync xf86-input-evtouch 0.8.8-4 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<RAOF> That doesn't need a sync bug?  0.8.8-3build1 should be a candidate for autosync
<Sarvatt> ah maybe autosync hasn't been run since the 15th?
<RAOF> That seems a long time.
<Sarvatt> hmm vmmouse in debian doesn't have the fixes in it
<Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-input-vmmouse/
<Sarvatt> this can be dropped right? xserver-xorg-video-r128 (6.8.1-2ubuntu1) lucid; urgency=low  * Bump xserver-xorg-video-r128 conflicts/replaces xserver-xorg-video-ati    version to match the version in Hardy for Hardy -> Lucid upgrades
<RAOF> Yes.
<Sarvatt> filing that one too then
<Sarvatt> oopsed 6 times now :)
<Sarvatt> pain in the butt cus it gets the changelog wrong and i have to delete the huge history
<Sarvatt> OOPS-1616ED613
<ubot4> https://lp-oops.canonical.com/oops.py/?oopsid=1616ED613
<RAOF> Leaving -intel (merged, not uploaded), -ati (merged, not uploaded, build-depends on new xserver), -nouveau (updated, not uploaded, b-d on new xserver), synaptics (merged?, not uploaded).
<Sarvatt> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/versions-current.html  https://wiki.ubuntu.com/X/PackageNotes
<Sarvatt> versions-current grabs it off the package notes wiki
<Sarvatt> i think
<Sarvatt> ah there we go https://edge.launchpad.net/bugs/589540
<ubot4> Launchpad bug 589540 in xserver-xorg-video-r128 (Ubuntu) "Sync xserver-xorg-video-r128 6.8.1-3 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<Sarvatt> jcristau: do you guys want the vmmouse fixes that arent in a released version yet or should we just add patches in ubuntu?
<Sarvatt> can't sync that because you guys dont have the fix for https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-vmmouse/+bug/545298 but its in upstream git
<ubot4> Launchpad bug 545298 in xserver-xorg-input-vmmouse (Ubuntu Lucid) (and 1 other project) "left mouse button unresponsive when running as VMware server guest (affects: 4)" [High,Fix released]
<Sarvatt> bryceh: hmm some packages missing from versions-current? tslib, omapfb?
<Sarvatt> tslib one is nasty because xserver specifically breaks the version we have
<Sarvatt> oh nevermind its synced already, just  in dep wait
<Sarvatt> xinput we can just hold off till the next one which has the fix, 1.5.2 that was just released
<Sarvatt> it's important that we have evdev ready ASAP after xserver goes in, is it really a good idea to redo the whole sync process for it again after? just lookedat your evdev sync request
<RAOF> Sarvatt: What do you mean?  If we sync evdev now it'll sit nicely in depwait until xserver is built, then work.
<Sarvatt> yeah but they just unscribed and asked you to resubscribe after xserver goes in, have to wait for all that to go through :)
 * Sarvatt is glad he didnt mention it would be in depwait in all those other syncs
<RAOF> Not all of those syncs will depwait.
<Sarvatt> well all the drivers will
<Sarvatt> *everything* is xserver >= 1.7.6.901 for the xsfbs changes, thats why i had to upload 100+ packages to edgers to update crap
<RAOF> Ok.  When I was checking, some didn't dep on that, because they hadn't had the xsfbs change.
<Sarvatt> even if you had xserver 1.8.1 before xsfbs still gives you an error saying needs >= 1.7.6.901 if you dont have the new xsfbs
<Sarvatt> looks like theres going to be a big round  of lib updates soon for all those locking fixes
<RAOF> Hooray!
<RAOF> And the dropping of non-xcb, apparently.
<Sarvatt> not sure if its frowned upon to update things in unstable at the moment
<Sarvatt> a git checkout of vmmouse in unstable would be nice because they are hit by that bug too
<Sarvatt> also xproto
<Sarvatt> needed for xserver 1.9
<Sarvatt> i updated macros xutils-dev, hope I don't get beaten for that :)
<RAOF> You could probably pop up in debian-x.  Debian probably don't care about xserver 1.9 in unstable (but would for experimental)
<jcristau> what vmmouse fixes?
<Sarvatt> only matching event devices
<Sarvatt> it was also matching /dev/input/mouse as well and was screwed up in the released one
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-vmmouse/+bug/545298 and http://cgit.freedesktop.org/xorg/driver/xf86-input-vmmouse/commit/?id=1d1c0514158abb66388ee4eb44764d201203a863
<ubot4> Launchpad bug 545298 in xserver-xorg-input-vmmouse (Ubuntu Lucid) (and 1 other project) "left mouse button unresponsive when running as VMware server guest (affects: 4)" [High,Fix released]
<jcristau> k
<jcristau> then yeah we'll probably want that
<Sarvatt> would it be better to just cherry pick that commit, add it as a patch, or just pull from upstream?
<Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-input-vmmouse/
<Sarvatt> your two commits + a .gitignore update on top of that fix
<jcristau> whichever you prefer
<Sarvatt> just test building it before i push it to be sure
<Sarvatt> okie :) thanks, starting to get the hang of working on the debian branches
<Dr_Jakob> Sarvatt: hmm that looks weird, is that all in the ppa so I can try it out?
<Sarvatt> yeah it's all in the ppa, I installed a fresh lucid, added the PPA, did a sudo apt-get update && sudo apt-get dist-upgrade, installed linux-image-2.6-34-5-generic libkms1 and libgl1-mesa-dri-gallium, echo "blacklist vga16fb" | sudo tee /etc/modprobe.d/blacklist-framebuffer.conf && sudo update-initramfs -u -k 'all' and then rebooted and installed the vmware tools and rebooted again
<Sarvatt> reinstalled the vmware tools I mean at the end there
<Sarvatt> they were already installed from the easy installer, but messed up from the new kernel
<Sarvatt> i could send an image if you want too :)
<Dr_Jakob> Hmmm
<Dr_Jakob> Does it work without the tools?
<Sarvatt> didn't try that, lets see
<Dr_Jakob> Also does it work without 3D?
<Dr_Jakob> That is if you disable 3D in the host?
<Sarvatt> yeah it works fine without 3D
<Sarvatt> the vmctl message in xorg.0.log says no 2D or 3D or fallback debug but everything else enabled in that situation
<Dr_Jakob> Does it say "Using libkms backend"?
<Sarvatt> yup
<Dr_Jakob> Right thats good
<Sarvatt> and dirty and whatever the other one was
<Dr_Jakob> Also 2D acceleration will never be enabled even with 3D...
<Dr_Jakob> Its more like deacceleration currently :-/
<Sarvatt> uninstalling tools didnt make a difference, still like 20 attempts to start hanging right after EXA until it gives up and loads failsafe fbdev
<Dr_Jakob> I will take a look sometime next week
<Dr_Jakob> At least 2D works, so that we don't complete break things for users...
<Sarvatt> hopefully its just a packaging problem or something
<Sarvatt> RAOF: merge xserver on monday sound like a plan?
<RAOF> I'm already half way there.
<Sarvatt> doing it today sounds like a recipe for disaster and probably better to wait for debian and do 1.8.1.901, i'm testing out the experimental build right now
<RAOF> Just looking at actually fixing bug #519019 - the patch half-reviewed on xorg-devel (appears to) work.
<ubot4> Launchpad bug 519019 in libdbusmenu (Ubuntu) "indicator-applet crashed with SIGSEGV after initial evolution setup (affects: 1) (heat: 10)" [Medium,Fix released] https://launchpad.net/bugs/519019
<Sarvatt> just because this *will* break things for many people on a weekend :)
<RAOF> Heh. 519049
<RAOF> Right.
<RAOF> I'd also merged 1.8.1.901
<Sarvatt> hmm synaptics needs a few more fixups
<RAOF> Works for meâ¢
<RAOF> :)
<Sarvatt> forgot to add the udev dependency back after the merge :)
<Sarvatt> err, crap, sorry! didn't mean to change the changelog that way.
<Sarvatt> ah well you gotta change it again to release anyway :)
<Sarvatt> so what's your workflow with gbp?
<RAOF> git-buildpackage -S; sbuild -d maverick ../whatever
<RAOF> It just annoys me when I do that and gbp fails with âwhy aren't you on master, fool!â
<Sarvatt> can't you just export the default?
<Sarvatt> (or put it in a local .conf or something)
<RAOF> You can, but if you export the default, then when you try building on the debian branch it complains.
<RAOF> It's really a per-branch configuration; you can't have it anywhere else and have gbp do the right thing.
<Sarvatt> debuild -S instead? :D
<RAOF> Well, debuild -S -i, I guess.
<Sarvatt> or DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i" in ~/.devscripts
<RAOF> Right.
<RAOF> I guess since xsf doesn't generally use the interesting parts of git-buildpackage that would work fine.
<Sarvatt> yeah thats what threw me off, didn't understand why the gbp outside of nouveau
<jcristau> Sarvatt: that and -I for xorg and the app bundles
<Sarvatt> well I have DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I.bzr -I.svn -I.git" in mine
<jcristau> you could make that -i -I :)
<RAOF> Incidentally, why *doesn't* the xsf tend to use the interesting bits of git-buildpackage?  I find it nice and convenient to have everything in the one place.  When it works, of course.
<Sarvatt> yeah set that back before I knew that :)
<Sarvatt> it looks like it used to
<jcristau> RAOF: because it didn't exist when we started using git, and i haven't gotten around to looking at it
<RAOF> Fair crack o' the whip
<Sarvatt> what features do you want RAOF? i can look into it, was doing that as we speak actually :)
<RAOF> Basically, using the upstream-branch + pristine-tar features makes it easier to pick up and work on (or to send to sponsors).  Then you just need to clone the repo and git-buildpackage.
<RAOF> No hunting around for the right .orig.tar.gz :)
<hyperair> RAOF: there's a per-branch debian/gbp.conf which i've been using for maintaining my crapton of ppas
<RAOF> hyperair: Indeed there is - that's what Sarvatt's been asking me about: why I've been adding them when I touch a package :)
<hyperair> RAOF: aaah i see.
<hyperair> RAOF: but it's only within the VCS isn't it?
<RAOF> What do you mean?  It ends up in the source package, because it's in the debian/ directory.  Also, it ends up in everyone's checkouts.
<hyperair> RAOF: ah, you didn't add the extra -i =p
<hyperair> to builder, i mean
<hyperair> if debuild gets -i gbp.conf it'll get rid of gbp.conf for you
<RAOF> Well, I guess you could do that.
<jcristau> hyperair: it's one more manual step for everyone, for what seems to be a pretty small gain
<noobish> came across a build problem while installing x-swat's fglrx package. The dkms make operation fails with 2 errors: 1. include/linux/utsrelease.h does not exist and kernel includes do not match current kernel (they are versioned as "" instead of "2.6.34-020634-generic).
<RAOF> I don't think there's any particular reason not to have it in the source package.
<noobish> I did not reboot after upgrading the kernel
<noobish> is that an easy kill?
<RAOF> Last time I tried fglrx didn't build against the more recent kernel.
<hyperair> jcristau: it's in the conf. what's manual about it?
<RAOF> Which is, I guess, what you're seeing.
<noobish> RAOF: I already had to manually edit 2 patch files just to get this far
<hyperair> jcristau: but i get what you mean about the small gain part. i think gbp should have it on by default
<noobish> and as I recall I had the same error with 2.6.32
<noobish> oh, I did reboot after the kernel upgrade. So why would /lib/modules/{kernel}/build/include "not match current kernel"?
<RAOF> Black magic.
<noobish> this is what I suspected
<RAOF> :)
<noobish> I will put more garlic strands around the cpu
<noobish> well there's a new fglrx build being minted in 6 hours anyway that specifically mentions the arch patch for 2.6.34, so I'll try again in the morning
<Sarvatt> so yeah, if anyone wants to clone all of the pkg-xorg stuff - http://sarvatt.com/downloads/graball.sh
<Sarvatt> adds the upstream remotes to everything but apps too
<Sarvatt> just change USERNAME at the top :D
<lucazade> Sarvatt is this correct? http://www.phoronix.com/forums/showpost.php?p=131953&postcount=9
<jcristau> it's on phoronix, so probably not
<lucazade> lol
<Sarvatt> what he said :)
<Sarvatt> looks right
<Sarvatt> emgd looks to  be iegd
<Sarvatt> i've never been able to download iegd but it looks like its called emgd in iegd going by google
<lucazade> emgd + gallium3D or + xpsb3D blob?
<Sarvatt> no its totally seperate
<Sarvatt> iegd/emgd has nothing to do with xpsb
<lucazade> ok 
<Sarvatt> the 2 branches of psb are xpsb and gallium supporting
<lucazade> perfect
<lucazade> now is clear
<lucazade> emgd will have his 3D support
<jcristau> clear is not the word i would have used
<lucazade> me too, but my english is poor
<Sarvatt> emgd looks like its iegd, just the iegd parts are called iegd for PC devices and emgd for embedded devices not meant to be in netbooks and crap that they ended up getting put in making people suffer :)
<lucazade> i'll wait for these marvelous drivers!
<Sarvatt> i'm sure they'll be out some day but will need a bunch of reworking for ubuntu's libgl mess
<Sarvatt> cus they have to support xserver 1.7 if they are going to support RHEL6 :)
<Sarvatt> the IEGD release is supposed to be out this month
<Sarvatt> but it might skip xserver 1.7 and go to 1.8 and have 1.7 support later for RHEL, I dunno
<Sarvatt> i doubt very much they are gonna make it work with the alternatives crap
<Sarvatt> but that'll be easy enough to work around as long as the drivers are out
<lucazade> thanks Sarvatt for the info
<Sarvatt> the second number in the release version for the "open source" version of the psb driver tells what line its for, 0 for dri1/xpsb 1 for dri2/gallium
<Sarvatt> the mrst ones are 3
<Sarvatt> like 5.0.xxxxx.x 5.1.xxxxx.x 5.3.xxxxxx.x
<lucazade> yep
<Sarvatt> man this script takes a *year* to finish :)
<Sarvatt> doh, how'd I forget xserver!
<Sarvatt> ...and xorg meta
<Sarvatt> anyway now to make one to package and upload everything to xorg-edgers
<Sarvatt> woo baby, got the monster of all ppa update scripts almost done, updating to 1.9 will be a breeze
<Sarvatt> ugh, I'm going to feel like the mozilla/chromium ppa's if i run this regularily :) all protos for 2 distros took about 10 minutes to package and upload in a script
<jcristau> bug 496817 should be closed
<ubot4> Launchpad bug 496817 in xinput (Ubuntu) "xinput no longer works to set-ptr-feedback after the latest Xserver upgrade in Lucid (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/496817
<jcristau> bug 507305 should be moved to the server or evdev
<ubot4> Launchpad bug 507305 in xinput (Ubuntu) "Unable to slow mouse sufficiently (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/507305
<jcristau> bug 523890 is likely invalid, if the events come from the same kernel device then there's nothing X can do
<ubot4> Launchpad bug 523890 in xinput (Ubuntu) "XInput2 not separating Synaptics touchkey events from trackpad & trackpoint (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/523890
<jcristau> and bug 529745 should be moved to synaptics
<ubot4> Launchpad bug 529745 in xinput (Ubuntu) "[Suggestion] Enable TrackPoint middle scroll by default (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/529745
<Sarvatt> do you upload to debian with dput too?
<Sarvatt> err, guess thats a silly question, nothing from this script would go anywhere in debian
<Sarvatt> almost done making this automatic X packaging script and have it abstract enough that it'll work for debian as well, maybe I'll add a build option and make it do the same as X.Org's build.sh only packaging/installing each thing as it goes
<hyperair> Sarvatt: you dput to debian, but your .changes file must be a _<arch>.changes, rather than a _source.changes
<hyperair> Sarvatt: because debian sucks and doesn't support source-only uploads.
<Sarvatt> I was being a bonehead and thinking debian had other places they could dput :)
<hyperair> hey it's entirely possible =p
<Sarvatt> (to reuse the PPA upload code)
<hyperair> i've heard of some people who have set up mini-buildds
<Sarvatt> i woulda been done with this hours ago if i didn't  keep abstracting things away to make it more genericlol
<hyperair> which are uploaded to using dput, of course.
<hyperair> abstraction is the way to go \o/
 * hyperair struggles with his 2.6.35 kernel
<hyperair> i've been attempting to compile this for 5 days now.
<Sarvatt> https://edge.launchpad.net/~sarvatt/+archive/dumping that was about 3 minutes worth, the code to upload ~dist-1 versions wasn't working but those take like 1/10th the time as the main ones
<hyperair> first i run into all kinds of merge conflicts, then compilation errors, then panics.
<Sarvatt> hah, whatcha merging?
<hyperair> bfs, phc, aufs2, apparmor
<hyperair> er what else was there..
<Sarvatt> i spent 8 hours compiling a 2.6.35-pre rc1 with gcc-4.5 and -march=atom just to have it have that damn udev bug
<hyperair> lol
<Sarvatt> and i was stupid and symlinked all the examples from kernel-package so i got all these weird grub entries now
<hyperair> lol!
<hyperair> i symlinked initramfs and grub
<Sarvatt> that worked?
<Sarvatt> grub_conf?
<hyperair> grub_conf?
<hyperair> O-o
<Sarvatt> thats what its called here
<Sarvatt> what version kernel-package?
<hyperair> i called it zz-grub
<Sarvatt> 12.033 here
<hyperair> eh i copied it not linked it
<Sarvatt> was the example called grub_conf I mean?
<hyperair> oh i got rid of that
<hyperair> i made my own
<hyperair> it just has two lines
<hyperair> #!/bin/sh
<hyperair> exec update-grub
<hyperair> =D
<hyperair> ah the initramfs one is linked.
<Sarvatt> hah
<Sarvatt> ok
<Sarvatt> thanks for the tips, i never have time to sit down and read that labrynth man page
<hyperair> lol
<hyperair> i don't even remember what manpage anymore
<hyperair> wait, there was a manpage?
<Sarvatt> man kernel-package
<hyperair> i just took a look at the examples and made my own
<hyperair> ah that
<Sarvatt> and man kernel-pkg.conf and man kernel-img.conf
<hyperair> for some reason, i can't seem to get it to stop poking git when it begins to compile though. results in a crapload of I/O =_=
<Sarvatt> lol you compile with ccache on an encrypted home directory dont you?
<vish> hmm , how to avoid the udevd bug from the mainline kernel?
<hyperair> Sarvatt: on top of btrfs.
<Sarvatt> vish: its gone now
<hyperair> Sarvatt: which sucks grandly on dm-crypt
<vish> Sarvatt: the .35 doesnt have it?
<hyperair> Sarvatt: which is why i'm so desperate to get my hands on the new kernel (i've added a patch which gives dm-crypt multicpu capabilities)
<Sarvatt> i think it went away mid 2.6.35-rc1?
<vish> ah , i was on .34.. yay
<hyperair> what udevd bug?
<Sarvatt> really though ccache on an encrypted home totally kills the benefits of ccache, probably makes it even worse lol
<hyperair> pfft
<Sarvatt> it was respawning udev constantly using 100% cpu
<hyperair> ccache is still faster when recompiling
<Sarvatt> vish: check phoronix i'm sure he posted when it was fixed :)
<hyperair> especially since git likes to screw up my time stamps
 * vish checks phoronix :)
<Sarvatt> what version kernel-package hyperair?
<Sarvatt> i dunno if you know but the later 12.xxx ones you dont have to make-kpkg clean
<hyperair> Sarvatt: er the one in lucid.
<Sarvatt> if it fails or something
<hyperair> Sarvatt: and i haven't used make-kpkg clean in a looooooooooooooooooong time.
<Sarvatt> ah lol
<hyperair> it still generates a crapload of I/O when rebuilding though
<hyperair> with the older make-kpkg i used to do rm -rf debian conf.vars
<hyperair> that was good enough, and left my .o files in place
<hyperair> unfortunately, bumping up the kernel revision that i appended to my kernel version caused make and ccache to go berserk and recompile everything.
 * hyperair wonders if Sarvatt is also getting frequent hard-locks with image frozen on screen
<Sarvatt> nope
<Sarvatt> not frequent at any rate, maybe 2 in a week?
<Sarvatt> both times when installing a kernel lol
<hyperair> Sarvatt: i'm getting it several times a day >_>
<hyperair> maybe i'll downgrade..
<Sarvatt> hyperair: hanging with the same image on the screen and the system hard locked up and unresponsive?
<hyperair> Sarvatt: yeah, and ping fails too.
<Sarvatt> yup same crash i get randomly then :(
<hyperair> heh
<hyperair> Sarvatt: what's it caused by?
<hyperair> Sarvatt: you disabled page flipping, didn't you?
<Sarvatt> dang ickle is trying to figure out the reason why intel couldn't start compiz at == max texture size and our silly patch screwed him up :D
<Sarvatt> yeah I did but its still happening sometimes too, a crapload less than without the patch
<hyperair> hmm i see.
<hyperair> finally! my kernel finished compiling!
 * hyperair installs
<Sarvatt> hyperair: i think i saw a bug about it but i'm really busy at the moment, will try to dig it up in a few
<Sarvatt> oh man this is awesome
<hyperair> ?
<Sarvatt> http://sarvatt.com/downloads/update-ppa.sh
<Sarvatt> updates every pkg-xorg package just about, keeps track if theres anything new upstream after the first run and doesn't upload if theres not, builds packages for 2 dists at a time
<hyperair> heheh
<hyperair> that's cool stuff =p
<hyperair> shell scripts win =p
<Sarvatt> gotta upload my hooks because they're really different than whats in xorg-pkg-tools
<Sarvatt> incoming 100+ updates to xorg-edgers while theres already a huge queue :)
<Sarvatt> holyyy crap, that was some amazing timing
<Sarvatt> battery died not a minute after i uploaded the script to my server there, it and the backup got zeroed out
<hyperair> lol
<hyperair> that's nice
<hyperair> xD
<Sarvatt> RAOF: so can you find anyone to help with the merge fest on monday? we're going to have a ton of people accepting broken upgrades and complaining and none of my sync requests are going through because they want to wait until the server is uploaded...
<Sarvatt> took almost an hour to update all video drivers with the script, atom is sloooow
<Sarvatt> hmm, stopped updating lucid ones about halfway through
#ubuntu-x 2010-06-05
<bryceh> Sarvatt, what kind of help do you need exactly?
<Sarvatt> core-dev :P
<Sarvatt> https://wiki.ubuntu.com/X/PackageNotes
<bryceh> are there debdiffs prepared for the merges?
<Sarvatt> nope but I can come up with that before server goes in on monday, been doing what I can asking debian to update things and merging things in git
<bryceh> that would be great
<Sarvatt> but even things like nvidia-current need rebuilding now since xserver-xorg-core breaks every package providing the old abi
<Sarvatt> and virtualbox
<bryceh> if it's just down to package sponsoring I can probably carve out a couple hours monday to lend a hand
<Sarvatt> yeah its just sponsoring really
<bryceh> don't worry about the proprietary drivers at this point
<Sarvatt> i do because xserver wont upgrade and will remove input/video-all if they have the prop drivers installed :)
<bryceh> it's traditional that they all break once xserver is updated, and stay broken until we receive compatible versions
<bryceh> won't upgrade?
<Sarvatt> if it was just the drivers broken it'd be one thing but xserver wont even install now
<bryceh> hmm
<bryceh> but that affects only users with proprietary drivers installed?
<Sarvatt> upgrading the safe upgrade stuff which didn't include -core made nvidia-current get installed on  my netbook
<bryceh> I would be highly doubtful that there are many people running proprietary drivers on maverick right now, but if there are some, then they can clean up manually
<Sarvatt> maybe we should just not have nvidia-current provide an abi, it doesn't make sense thinking about it because the ones in maverick are compatable wth multiple video abi's
<bryceh> if you want to be nice, maybe include some hints in an email
<bryceh> historically, we've always had a broken period from when the new xserver appeared until the drivers built, which could last a couple days
<bryceh> a good goal would be to minimize that by getting xserver and the main foss drivers in as close to each other as possible
<bryceh> the outlier drivers, including proprietary drivers, probably can wait for the second round after that
<Sarvatt> i'll start gathering up debdiffs :)
<bryceh> excellent
<Kangarooo> Sarvatt: ive got 3 more crashes different with Xorg. should it post to the same bug?
<Sarvatt> https://edge.launchpad.net/ubuntu/+ppas -- must beat language pack builders! :D
<Kangarooo> Sarvatt: I added more dgb to bug 587710
<ubot4> Launchpad bug 587710 in nvidia-graphics-drivers (Ubuntu) "if FF wit lot Gif & overloading CPU then X-boom to login (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/587710
<ripps> *sigh* I remember when gmpc-trunk used be in the Most Active list. That was before the developer went on hiatus.
<ripps> When is dri2 sync + swap coming?
<ripps> what is this? Do I see a 2.6.35 kernel building for maverick? Only a matter of time til one is backported to either xorg-edgers or kernel-ppa
 * hyperair growls at x-x-v-i
<ricotz> Sarvatt, i am building 2.6.35-1.1 for lucid in my ppa and will copy it over to edgers if it works
<lucazade> adding XAANoOffscreenPixmaps to poulsbo xorg.conf fix 3D but icons/pixmaps are broken.... grrr
<lucazade> any hint?
<lucazade> adding also RENDER "disable" fix both 3D and icons.. but not optimal workaround
<Sarvatt> heads up if you are using the dynpm module option for radeon its gone in that .35 kenel so it wont load
<ricotz> Sarvatt, :( i said it is building in my ppa, so there wasnt a need to jam more builders
<Sarvatt> i  didnt look at irc when i woke up, sorry
<ricotz> Sarvatt, alright
<Sarvatt> ricotz: are you patching mutter? it's pretty much useless in maverick without http://sarvatt.com/downloads/patches/0001-Use-gdk_screen_get_system_colormap-instead-of-gdk_sc.patch
<Sarvatt> i need to figure out how to get collab-maint packages working with auto-xorg-git..
<ripps> geez, everybody and their sister is building 2.6.35 in launchpad
<Sarvatt> theres the 2048x2048 compiz fix for intel \o/ - http://cgit.freedesktop.org/mesa/mesa/commit/?id=add3260157368458501709d08a3f913ed448234f
<Sarvatt> hmm randrproto installs docs to /usr/share/doc/randrproto instead of /usr/share/doc/x11-proto-randr-dev now
<ricotz> Sarvatt, yes, i am patching mutter with it
<ricotz> Sarvatt, yesterday you mentioned a shell script for updating edgers ppa, could i have a look at it?
<jcristau> Sarvatt: it does?
<Sarvatt> yeah
<Sarvatt> in git
<Sarvatt> i just made a script that build the world automatically in debian packages and that and libxt were the failures, fixed libxt in unstable
<ricotz> ok
<Sarvatt> http://cgit.freedesktop.org/xorg/proto/randrproto/commit/?id=68f8fbe50792e0525ba767d854b18db4acda07ff
<jcristau> i guess i never test built libxt
<jcristau> ah right
<jcristau> hmm but dh_installdocs randrproto.txt should still put it in the right place
<Sarvatt> digging up the build logs
<Sarvatt> ricotz: will upload it to xorg-pkg-tools soon, working out some kinks
<Sarvatt> https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+build/1774308/+files/buildlog_ubuntu-lucid-i386.x11proto-randr_1.3.1+git20100604.6ecbca5e-0ubuntu0sarvatt~lucid_FAILEDTOBUILD.txt.gz
<ricotz> Sarvatt, thanks
<Sarvatt> dh_install: x11proto-randr-dev missing files (usr/share/doc/x11proto-randr-dev/*), aborting
<jcristau> wtf
<jcristau> yeah.  wonder what's going on there
<jcristau> hum
<jcristau> ../configure: line 4078: PKG_PROG_PKG_CONFIG: command not found
<jcristau> this is also broken :)
<jcristau> pkg-config not installed?
<Sarvatt> oh sheesh i fixed that in the upload before it and forgot, need to make a hook too add it to build depends
<Sarvatt> or should it be that way in git in the first place? :)
<Sarvatt> Build-Depends:
<Sarvatt>  debhelper (>= 5.0.0),
<Sarvatt>  automake,
<Sarvatt>  xutils-dev (>= 1:7.5~1)
<jcristau> may be easier to just give up and add it to xutils-dev Depends
<jcristau> but yeah, adding it to randrproto build-deps in git sounds good
<Sarvatt> okie pushing it
<Sarvatt> and depends of xutils-dev sounds good to me :)
<Sarvatt> oh noes, input-citron doesnt build against 1.8 either http://launchpadlibrarian.net/49692666/buildlog_ubuntu-lucid-amd64.xserver-xorg-input-citron_1:2.2.2%2Bgit20100604.6341ecaa-0ubuntu0sarvatt~lucid_FAILEDTOBUILD.txt.gz
<jcristau> surprise..
<Sarvatt> big old list here if you ever want to see build logs for anything - https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+builds?build_text=&build_state=all
<Sarvatt> ricotz: http://sarvatt.com/sarvatt-update-ppa.sh --  just dont run it on edgers anytime because it relies on only one person running it stores the latest commit in .lastcommit so it knows to only update the package if its been update :)
<Sarvatt> if you change the ppa to an undefined one it'll make source packages for the world
<ricotz> thanks, will have a look
<ricotz> Sarvatt, i would be nice if the date in version-string is actually the date of git-commit
<ricotz> LASTCOMMITDATE=$(git log ${LASTCOMMIT:7} --pretty=%ci | head -1 | awk '{ print $1 }' | sed 's/-//g')
<Sarvatt> ricotz: oh but its ok to use for mesa, thats the CUSTOM_ONE target
<Sarvatt> i put the hacky hook that replaces debian/ in hooks-sarvatt
<Sarvatt> argh found yet another problem in fglrx-installer, patch pointing at the wrong file. i'm not getting any feedback on it and cant test it so i asked people to come here if they have a problem with it :)
<Sarvatt> i hate uploading things i cant test :)
<Bernardo> Sarvatt: did you manage to advance in the psb drivers?
<jcristau> Sarvatt: do you remember when/how the 'Failed to submit batchbuffer: Input/output error' intel errors got fixed?
<Sarvatt> jcristau: there were so many different bugs causing that, it depends.. most were the "dont release *something* at load detect time" commit in the kernel that i dont think ever made it upstream
<Sarvatt> looking for the commit, i know debian had it though
<Sarvatt> i remember bgoglin pinging it on intel-gfx saying you were carrying it
<Sarvatt> ah crap, script moved mesa to a +
<Sarvatt> libgl1-mesa-dri-gallium_7.9.0+git20100605.6d741627-0ubuntu0sarvatt_i386.deb
<Sarvatt>  :(
<Sarvatt> jcristau: if it was happening at suspend/resume or when idle and doing a dpms off this is the commit - https://patchwork.kernel.org/patch/80474/
<Sarvatt> that one had really specific triggers
<Sarvatt> but there are so many bugs that cause that error message
 * hyperair gapes at the amount of upgrades from the xorg-edgers ppa
<jcristau> Sarvatt: okay, thanks
<ripps> dammit, the new 2.6.35 is incompatible with linuxwacom. I have Bamboo CTL-460, and it requires building a new wacom module, but I'm unable to build a module for this kernel.
<Sarvatt> it's not in 2.6.35?
<Sarvatt> is it just the kernel side that doesnt support it or xf86-input-wacom? wacom module load?
<Sarvatt> yeah i dont see the pci ids in the kernel :(
<Sarvatt> why haven't they pushed that to the mainline kernel yet
<Sarvatt> i mean i see it in here over a year ago
<Sarvatt> oh ok here's where they added support for your d4 device in linuxwacom, not as old as i thought - http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/linuxwacom;a=commit;h=2683f4f52f4e43f4bbabb168d1a31e78200d9d8c
<ripps> Sarvatt: I fixed the wacom issue. The module didn't work, and the code in linuxwacom-0.8.6-2/0.8.7-2 was out of date. I had to change the name of a few functions in order for the the module to build
<ripps> in wacom_sys.c
<ripps> yeah, but this crap should be in mainline already. No reason I should be rebuilding wacom modules at this point.
<ripps> if this doesn't go in, they better make a dkms or something
#ubuntu-x 2010-06-06
<MrGreencastle> is this the channel for the maintainers of the x-swat ppa?
<hyperair> yes it is.
<hyperair> not that i'm one.
<hyperair> Sarvatt maintains it afaik.
<MrGreencastle> Oh ok
<MrGreencastle> I'm just wondering if there is an issue currently with the latest nvidia driver in lucid, from the stable ppa
<MrGreencastle> I was experiencing poor-ish performance with the shipped version of the nvidia driver, so I grabbed this ppa, and updated the nvidia-current package, yet it doesn't seem to worked :S
<MrGreencastle> Perhaps I'll try the beta release
 * hyperair has given up on nvidia and ati.
<hyperair> intel ftw!
<MrGreencastle> lol
<hyperair> besides, my nvidia-based desktop doesn't work with drivers newer than 96.xx
<hyperair> stupid nvidia, deprecating my card just like that
<hyperair> it's only a few years old..
<MrGreencastle> I just recently got back into the *nix game from windows
<MrGreencastle> It's been awhile
<hyperair> hrmm why did you even switch back to Windows in the first place?
<MrGreencastle> Haven't used ubuntu since 6.XX
<hyperair> haha.
<MrGreencastle> Work reasons
<hyperair> that was the first Ubuntu I used =p
<hyperair> 6.06
<MrGreencastle> I found that I spent way too much time playing with the OS
<hyperair> i screwed my xorg.conf, couldn't figure out hwo to fix it, and purged the system thrice before i got it working.
<MrGreencastle> Can't exactly do that as easily in windows
<hyperair> oh
<hyperair> heh
<hyperair> that sounds familiar =p
<hyperair> you need to let the novelty wear off
<MrGreencastle> I think it was dapper
<MrGreencastle> I then used arch for a few years
<hyperair> but then again, from time to time, i still end up playing too much with the OS.. like how i spent a week trying to get my kernel compiling....
<hyperair> oh Archlinux eh..
<hyperair> i used that for a grand total of 4 months.
<hyperair> at the end of 4 months, the only difference between my Arch and Ubuntu installations were the package manager.
<MrGreencastle> I liked it, it was fun knowing I built it from the ground up...ish
<hyperair> so i just gave up using Arch and went back to Ubuntu.
<hyperair> go LFS ;-)
<hyperair> Linux From Scratch
<MrGreencastle> Heh, I just installed 10.04, and I'm extremely impressed...
<MrGreencastle> It's nicer than my mac!
<hyperair> \o/
<hyperair> yes, 10.04 is a very impressive release.
<MrGreencastle> unfortunately my nvidia drivers are being poo
<hyperair> unfortunately.
<hyperair> what card is that anyway?
<MrGreencastle> 130m in an hp notebook
<MrGreencastle> geforce*
<MrGreencastle> works fine in mac and windows for me, I was just getting a few oddities with Lucid's standard driver
<MrGreencastle> which is odd, considering it's LTS
<hyperair> not at all.
<hyperair> there are limits to how much QA we can do
<MrGreencastle> haha
<hyperair> and nvidia is a great shining example of that.
<hyperair> it's a closed source blob, nobody knows wtf's going on in there
<MrGreencastle> I know, I know, I'm just giving people a hard time :)
<hyperair> hmm, giving who a hard time? ;-)
<hyperair> i'm enjoying myself putting down nvidia here.
<MrGreencastle> It's probably my fault anyway
<MrGreencastle> I'll try the beta drivers and let you know
<hyperair> good luck
<MrGreencastle> *sigh
<MrGreencastle> I must have found a bug
<MrGreencastle> or whatever it is that the hardware drivers app does, I couldn't figure out. 
<MrGreencastle> I got the beta drivers working, and performance is much smoother
<hyperair> well that's nice =)
<MrGreencastle> yeah, its just irritating how I couldn't get it to work by just installing it. I had to install the old ones via hardware drivers, then add the ppa for the beta ones, then restart, then upgrade, then restart :S
<hyperair> yay nvidia
 * hyperair eyes the new x-x-v-i upload suspiciously
<Sarvatt> I'm confused, the ones in the ppa *are* the beta drivers, he must have been installing from nvidia.com?
<Sarvatt> crashing hyperair?
<Sarvatt> is it any worse than before?
 * bryceh waves
<hyperair> Sarvatt: page flipping support is enabled =O
<hyperair> Sarvatt: which explains why i keep getting hangs within 10 minutes of each other >_>
<hyperair> Sarvatt: oh hey i managed to switch TTYs
<Sarvatt> hyperair: new one uploaded without it
<Sarvatt> sorry :(
<Sarvatt> i will warn you before i do it again, i passed out last night after uploading it
<Sarvatt> heyo bryceh!
<hyperair> Sarvatt: no problem.
<hyperair> i think i'll write a script that greps the current Xorg log and checks if page-flipping is enabled
<hyperair> and warn me
<hyperair> =p
<Sarvatt> lol
<Sarvatt> #!/bin/bash
<Sarvatt> if [ -z "$(grep forcibly /var/log/Xorg.0.log)" ]; then
<Sarvatt>         notify-send -t 30000 -u critical -i gtk-dialog-info "Page flipping is enabled." "YOUR X IS BUSTED!"
<Sarvatt> fi
<hyperair> Sarvatt: thanks. =p
<Sarvatt> i call it lolintel.sh :)
<hyperair> hehehe
<Sarvatt> maybe a zenity warning in the notification area would be better :)
<Sarvatt> so its persistant
<jcristau> Sarvatt: if ! grep -q forcibly /var/log/Xorg.0.log; then
<hyperair> Sarvatt: grep forcibly /var/log/Xorg.$(echo ${DISPLAY} | grep -o '[0-9]' | head -n1).log)" &> /dev/null && notify-send -t 30000 -u critical -i gtk-dialog-info "Page flipping is enabled. "YOUR X IS BUSTED!"
<Sarvatt> hah, I wasn't crazy!
<Sarvatt> 3.6.35-rc1 is nasty
<Sarvatt> my machine no longer goes into C3 states
<Sarvatt> battery life sucked yesterday, guess thats why
<hyperair> lol
<hyperair> rc1 is nasty indeed.
<hyperair> i spent a whole week attempting to compile it
<Sarvatt> C0 (cpu running)        (80.6%)         1.60 Ghz     1.7%
<Sarvatt> polling           1.5ms ( 0.0%)         1333 Mhz     0.0%
<Sarvatt> C1 halt           2.6ms ( 3.3%)         1066 Mhz     0.7%
<Sarvatt> C2                0.6ms (16.0%)          800 Mhz    97.7%
<Sarvatt> C3                0.0ms ( 0.0%)
<hyperair> aha.
<hyperair> that makes sense.
<Sarvatt> nasty! 13 watts idle power usage vs 7
<hyperair> i was wondering why my temperature was hovering 10 degrees celcius higher than usual
<Sarvatt> its fixed in -rc2
<hyperair> cool
<Sarvatt> saw the commit then looked at powertop lol
<hyperair> i'll compile rc2 as soon as i get my btrfs fixes
<hyperair> Sarvatt: do you know of this patch: http://lists.freedesktop.org/archives/intel-gfx/2010-April/006463.html ?
<Sarvatt> well whenever rc2 comes out i mean, fixed in git though
<hyperair> Sarvatt: rc2's out.
<hyperair> commit e44a21b7268a022c7749f521c06214145bd161e4
<hyperair> Author: Linus Torvalds <torvalds@linux-foundation.org>
<hyperair> Date:   Sat Jun 5 20:43:24 2010 -0700
<hyperair> Linux 2.6.35-rc2
<Sarvatt> oh dang, i opened the log last night and didnt refresh it :)
<Sarvatt> that patch doesnt affect you though?
<hyperair> Sarvatt: http://www.pubbs.net/201005/fedora/1529-page-flipping-on-intel-211-driver.html <-- this says that the patch i linked above fixes the hangs with page flipping.
<Sarvatt> for gen3 yeah you have gen4 though
<hyperair> oh isit?
<hyperair> =\
<hyperair> how do you tell?
<Sarvatt> 965+ = gen4, 915-945 is gen3
<hyperair> weird.
<hyperair> it said GMA3100
<hyperair> 3100 is the one i have..
<Sarvatt> whats the pci id?
<Sarvatt> those 3xxx ones are oddballs
<Sarvatt> you use 965_dri so though i'm sure yours is gen4
<Sarvatt> drivers/gpu/drm/i915/i915_drv.h has the list of what each pci id is
<hyperair> Sarvatt: 2a02
<hyperair> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 03)
<Sarvatt> yep thats gen4
<hyperair> heh oh well.
<Sarvatt> #define IS_GEN4(dev)	((dev)->pci_device == 0x2972 ||		\
<Sarvatt> ..snip..
<Sarvatt> 			 (dev)->pci_device == 0x2A02 ||		\
<hyperair> ah
<Sarvatt> thats an X3100, different beast than a 3100
<Sarvatt> 3100 is a desktop G31/G33
<hyperair> @_@
<hyperair> damn them, can't they just stick to one numbering scheme?
<Sarvatt> http://en.wikipedia.org/wiki/Intel_GMA
<jcristau> hyperair: that's called marketing
<Sarvatt> yeah make people think its a better gpu than it really is :)
<Sarvatt> Amaranth, RAOF: compiz works again on intel when resolution == max texture size in mesa 7.9
<Sarvatt> so we can drop that nasty hack that made it so everyone cant use it in MM eventually
<hyperair> jcristau: bah.
<Sarvatt> Depends:
<Sarvatt>  xserver-xorg-core (>= 2:1.8),
<Sarvatt>  xserver-xorg-video-all | xserver-xorg-video-7,
<Sarvatt>  xserver-xorg-input-all | xserver-xorg-input-9,
<Sarvatt> that look right for xserver-xorg?
<Sarvatt> hyperair: btw I figured out how to get vblank_mode in drirc to be honored - http://pastebin.com/C37kfXkr
<hyperair> ah.
<Sarvatt> why that took me like 6 hours stepping through gdb i'll never know, at least it was a learning experience :)
<hyperair> lol
<hyperair> why did you need it disabled again?
<Sarvatt> because it's crap on 945, makes the mouse really laggy in mutter when its on even
<Sarvatt> vblank_mode=1 isn't bad either, just 2 and 3 suck
<Sarvatt> couldn't figure out how to fix mesa so it worked when you set it for i915 like its advertised though
<hyperair> i see.
<Sarvatt> i guess if we do go r300g by default for ati in MM we can just add a check for if KMS is in use to the DDX to use the gallium dri driver name otherwise use the classic one, the names are different so they wont interfere
<Sarvatt> heck, i'm going to just do that now in edgers so I can ship radeong_dri in /usr/lib/dri
<Sarvatt> oh wait, it's even easier than I thought, radeon dri2 is only used in KMS so just modifying the dri2 path is guaranteed to be gallium compatible
<Sarvatt> hmm, need to figure out how to check for gallium support in configure.ac
<Sarvatt> hmm after doing all that it seems like it'd be better as an xorg.conf option that only enables by default if you build with --enable-gallium so people could still use classic
<Sarvatt> http://sarvatt.com/downloads/patches/0001-Add-a-configure-option-at-build-time-to-use-the-gall.patch
<Sarvatt> at this point, i'm not seeing much reason to even have a /usr/lib/dri-gallium 
<Sarvatt> working on a patch to the ati ddx that adds a gallium xorg.conf option that defaults to enabled that picks radeong instead of r300 so its possible to use both instead of that hacky rename. intel is the only one where the gallium versions are the same as the classic ones and we arent gonna be building that anyway
<Sarvatt> (and the xorg.conf option is only available with KMS, wont affect UMS)
<Sarvatt> ahh forgot about swrastg
<Sarvatt> this dri2 stuff is confusing.. can we specifiy more than one driver name in the driverNames array in DRI2InfoRec or is it hardcoded to use one name for each type?
<Sarvatt> i guess that doesn't make sense because it wouldnt need to use both at the same time, dont mind me just figuring crap out :)
<jcristau> it's one of each type.  dri2 at offset DRI2DriverDRI, vdpau at offset DRI2DriverVDPAU, iirc
<RAOF> Sarvatt: Yeah, I ended up deciding against dri-gallium too.
<RAOF> Sarvatt: I've talked with airlied - it seems there's a good chance that radeong_dri.so will become r300_dri.so in 7.9
<Sarvatt> doh
<Sarvatt> well crap
<RAOF> Doesn't make that patch less useful, though.
<RAOF> Just means you'd need to update the mesa packaging to copy r300_dri from glx/gallium to radeong_dri
<Sarvatt> was almost done making one that adds gallium as a xorg.conf option defaulted on to info->ChipFamily >= CHIP_FAMILY_R300 && info->ChipFamily < CHIP_FAMILY_R600
<Sarvatt> but i cant for the life of me figure out a way to have a fallback
<Sarvatt> like if you have it enabled in xorg.conf with that option and it doesnt exist have it try the other
<RAOF> stat radeong in the setup codepath?
<jcristau> not sure the ddx driver knows the dri driver path
<RAOF> Well, if it's just a edgers hack patch, that's not too much of an issue :)
<jcristau> hehe, yeah
<RAOF> I don't _think_ upstream's likely to be interested in it - airlied seemed very much of the opinion that making it easy for the user to choose between the dri modules wasn't useful.
#ubuntu-x 2011-05-30
<YoBoY> hi
<YoBoY> My laptop on natty is making fun of me. The desktop freeze very too often, sometimes I can go to a tty and restart gdm, sometines I only can use the power button. Can you guys give me some advices or help me report or find help on this bug ?
<tjaalton> YoBoY: install the kernel from -proposed
<YoBoY> hum... normally I'm already on proposed, I check
<tjaalton> should be abi version 9
<YoBoY> I'm on 2.6.38-9-generic
<tjaalton> ok then
<YoBoY> (i'm on the 64bit edition btw)
<tjaalton> doesn't matter
<RAOF> tjaalton: You wanted to test llvm support on your r300-r500 chips?
<tjaalton> RAOF: no, sis :P
<tjaalton> i have some firegl card, but don't know which generation it is
<RAOF> tjaalton: Oooh, the ultimate in software-fallbacks!
<RAOF> Anyway, it's in git.  Or, if you prefer, I'm sure I've got some prebuilt packages I could throw at you :)
<tjaalton> YoBoY: looks like that kernel doesn't have the fix I was after..
<tjaalton> RAOF: yeah, 32bit ones would be nice
<tjaalton> RAOF: you wrote the patch for i915 that fixes a sh*tload of these natty crashers?
<RAOF> tjaalton: By âcrashesâ you meen freezes?  Yes, and I finally aligned all the knobs to get it into stable-queue.
<tjaalton> RAOF: yeah that, cool
<YoBoY> tjaalton: the fix will be available soon ?
<tjaalton> YoBoY: well it's not even in -proposed yet
<tjaalton> as it seems
<RAOF> It's in the 2.6.39 kernel, but not yet in any natty kernel.
<tjaalton> right
<YoBoY> there is a bug I can subscribe to follow the progress ?
<tjaalton> yes
<tjaalton> but I don't have it handy :P
<tjaalton> there's also a ppa with a test kernel
<RAOF> bug #740126
<ubot4`> Launchpad bug 740126 in unity (Ubuntu Natty) (and 6 other projects) "Disabling an output can cause vblank events to be missed (affects: 76) (dups: 10) (heat: 380)" [High,Triaged] https://launchpad.net/bugs/740126
<soreau> I'm having trouble in natty where after coming out of a fullscreen window, compiz is completely b0rked. There are major issues flickering and it bounces between front and back buffers that are remnants of previous frames
<soreau> on rv350 with xorg-edgers installed
<soreau> restarting compiz or even X does not help, it's like the driver is stuck in b0rken mode
<soreau> I'm thinking it's a kernel/radeon module bug or mesa but not sure which
<RAOF> soreau: It's not inconceivable that it's an X bug, either.
<RAOF> tjaalton: Hm.  It seems I don't have an i386 build handy; I'll build one now.
<soreau> RAOF: Right but how do I know where to file a report?
<tjaalton> RAOF: got beefy hw for it? I have a dualcore here, so could build it myself too
<RAOF> tjaalton: No beefy hardware here; just a dualcore.
<tjaalton> ok, so maybe I'll just pull from git and build it here
<RAOF> soreau: I'm *pretty
<RAOF> sure* it's reported on xorg-devel.
<RAOF> Also, I'm pretty ;)
<soreau> Alrighty then :)
<soreau> RAOF: You mean it's a known issue?
<soreau> I saw mareko say something on dri-devel that might be the issue
<RAOF> I think it might be.
<soreau> apparently it only affects r3xx and not r5xx
<RAOF> tjaalton: I'll leave you to build it then.
<soreau> RAOF: Possibly OT: Do you know if ubuntu will run X in wayland or even package wayland in the next cycle (or two)?
<tjaalton> it's packaged
<RAOF> Run X in wayland by default in the next two cycles?  That's a big N O.
<RAOF> Wayland is, however, packaged, and should be runnable under X and on the console for O.  We'll get a new snapshot that doesn't require cairo-gl, so nvidia users won't be shafted.
<soreau> RAOF: I'm kinda thinking that wayland would make it's debut in ubuntu by just running X inside it but perhaps next year, there will be enough stable toolkits that it will be able to run native stuffs
<soreau> but I'm merely speculating
<RAOF> Well, that's the plan.
<RAOF> However, 12.04 is an LTS; we're not going to throw Wayland under X in the LTS :)
<soreau> ah ok
<soreau> Also I'm curious what nvidia is planning to do WRT wayland. AFAIK, they have no plans to provide support for it in their driver
<soreau> Will they ever cough up hw specs you think?
<RAOF> All this is discussed in one of the Wayland sessions at UDS; the notes are on the etherpad.
<soreau> RAOF: Link me?
<RAOF> (Well, not the nvidia discussion; that's a whole different kettle of awkward)
<soreau> I'm more curious to know than anything
 * soreau doesn't even use nvidia
<RAOF> http://summit.ubuntu.com/uds-o/meeting/desktop-o-xorg-wayland-something-or-other/
<soreau> heh, wayland-something-or-other
<soreau> RAOF: thanks
<soreau> cool
<soreau> I'm surprised how quickly wayland is taking off and gaining a large amount of support by everyone (except nvidia)
<soreau> I wonder how compiz will fare ;)
<RAOF> Compiz is surprisingly X-agnostic.
<soreau> Yea I know. And porting to gles is probably only a quarter of the work
<soreau> Porting to EGL might require an entire rewrite
<tjaalton> RAOF: hum, building this on natty is more work it seems, need to backport llvm and libdrm
<RAOF> tjaalton: Yeah, of course :).  I thought you were oneiricing :)
<tjaalton> not on the desktop, though I could build it on my laptop which is dualcore as well
<tjaalton> booted it up
<tjaalton> and I'll upgrade the other laptop too, no point in keeping it on natty
<tjaalton> RAOF: ok, finally got it built, but I have a hook that tries to install them and that phase fails
<tjaalton> RAOF: http://pastebin.com/7n1LDKez
<tjaalton> probably nothing, just a symptom of how the hook installs stuff
<tjaalton> it just runs 'dpkg -i $tmpdir/*.deb'
<tjaalton> hmm right, since libgl1-mesa-swx11 conflicts with libgl1, which is provided by libgl1-mesa-glx
<tjaalton> so nothing to worry about, I just need to disable the hook because the failure makes the pbuilder run fail, and so the debs are gone :)
<RAOF> tjaalton: Oh, ouwch!
<tjaalton> so the thinkpad fan control doesn't work, and the kernel is reporting near-critical temperature..
<tjaalton> while building mesa
 * RAOF fires off an i386 mesa build.
<tjaalton> it should finish soon though :)
<tjaalton> my build
<RAOF> If your laptop doesn't melt first! :)
<RAOF> llvm takes a surprising amount of time to build.
<tjaalton> placed a frozen bottle of water under the machine :)
<RAOF> Or, rather, there's an annoying delta between build_time(on launchpad buildd) and  build_time(on laptop)
<soren> For the longest time, stuff was quicker to build locally than on the buildd's.
<tjaalton> ooh, dpkg-shlibdeps.. soon finished
<tjaalton> CPU temp down to 81
<tjaalton> if i'm reading /proc/acpi/ibm/thermal right
<tjaalton> ok, so how do I determine if llvmpipe is used or not?
<tjaalton> swrast_dri.so is loaded
<Prf_Jakob> glxinfo | grep render
<tjaalton> http://paste.ubuntu.com/614934
<Prf_Jakob> you are not running llvmpie.
<tjaalton> right
<Prf_Jakob> it should say "Gallium 0.4 on llvmpipe" or something like that
<tjaalton> does it build a dri driver of its own?
<tjaalton> maybe the packaging change wasn't complete
<Prf_Jakob> dunno, upstream it was/is called swrastg_dri.so
<tjaalton> yeah, probably just needs to be included in the package then :)
<seb128> is #ubuntu-x tracking glew?
<seb128> is there any plan to update to 1.6?
<seb128> does anybody know if bug #711401 got investigated after the version revert to figure if the issue was a nux or glew one?
<ubot4`> Launchpad bug 711401 in unity (Ubuntu) (and 3 other projects) "update to glew 1.5.7 broke unity (dup-of: 711396)" [Undecided,Confirmed] https://launchpad.net/bugs/711401
<ubot4`> Launchpad bug 711396 in nux (Ubuntu Natty) (and 4 other projects) "segfault in nux::IOpenGLFrameBufferObject::Deactivate (affects: 42) (dups: 13) (heat: 178)" [Undecided,Fix released] https://launchpad.net/bugs/711396
#ubuntu-x 2011-05-31
<tjaalton> RAOF: so, the mesa packaging doesn't include swrastg_dri.so, maybe just replace swrast_dri.so with it?
<RAOF> tjaalton: I was thinking of shipping it in -dri-experimental.
<tjaalton> ah
<RAOF> Apparently llvmpipe is great as long as you're doing POT textures, and may fall over horribly outside thatâ¦
<tjaalton> but how would it get used? the fallback is swrast_dri
<RAOF> I'd rename it to swrast_dri instead of swrastg, and ship it in dri-alternates/
<RAOF> Then you get to set LIBGL_DRIVERS_PATH if you want to play with llvmpipe.
<RAOF> But it's pretty easy.
<tjaalton> ok
<RAOF> I don't think we need to spend too much time making it easier to test an alternative software rasteriser unless we plan to use it as a fallback for Unity.
<tjaalton> sure
<tjaalton> i mean 'right'
<tjaalton> gnome doesn't start even with stock oneiric on this machine
<tjaalton> hmm no, unity/compiz is running, but it just gives a purple screen
<RAOF> A nice purple? :)
<tjaalton> yes, single colour and not some mess :)
<tjaalton> actually nicer looking that what the desktop becomes on the intel machine
<tjaalton> just that I can't do anything here
<tjaalton> classic session works, and can start compiz there
<tjaalton> though it says that tfp is missing
<tjaalton> maybe I should try a snapshot instead
<tjaalton> maybe just commit 2b64886c would do
<tjaalton> *pulling
<RAOF> Mmm.  Loadavg 8.4.  I *may* be building too many things right now.
<tjaalton> just 2.19 here
<seb128> hey there!
<RAOF> Oop, 10.5
<seb128> did anyone read my question about glew yesterday?
<tjaalton> seb128: re glew; nothing new has happened aiui
<seb128> is there any plan to get 1.6? is #ubuntu-x taking care of that package or is unmaintained?
<seb128> (desktop is not working on it)
<tjaalton> and we don't generally track it, it's not maintained by pkg-xorg in debian
<RAOF> If you'd like us to take it we could; it's not unreasonable to lump it in the graphics stack.
<seb128> hey RAOF, that would be nice indeed
<tjaalton> the changelog is strange
<tjaalton> taken from 1.5.2 it seems
<tjaalton> debian has 1.5.8
<seb128> we downgraded in natty because the update broken unity on some intel cards and it was late in the cycle to figure who was at fault
<seb128> but would be nice to update to 1.6 now early in oneiric and fix the issue where it is if there is still one
<tjaalton> could it be tested with 1.5.8 in debian first?
<seb128> in debian?
<tjaalton> from debian
<seb128> or do you mean "can some people try installing the debian version on oneiric and see if it breaks"?
<tjaalton> right
<seb128> we can do that
<tjaalton> we could sync it
<seb128> the issue is I guess dx is not going to work on it until they have a good reason to
<seb128> well there was a .pc fix
<seb128> though upstream apparently argued that it's wrong so maybe nux needs an update
<seb128> but ok, I will get some desktop people to check with the current debian version then we can try syncing
<tjaalton> good
<RAOF> tjaalton: Are you planning on merging xserver 1.10.2 from Debian?
<tjaalton> RAOF: I could do that, yes
<RAOF> I wasn't fishing for that :).  But if you were, it would be nice to coordinate with an upload of a multiarch'd mesa.
<tjaalton> they need to be done in sync?
<RAOF> AIGLX ties them together; the multiarch mesa installs the dri drivers into a different place, so needs a rebuild of X to pick that up.
<tjaalton> ah, of course
<tjaalton> post-a1 i believe?
<RAOF> That would be the case, now, yes.
<tjaalton> sigh, network manager broken
<tjaalton> this is going to be an amazing a1 release :)
<RAOF> Mine works :)
<tjaalton> wired seems to work, wireless no
<tjaalton> and the desktop still looks rather funky
<RAOF> Heh.  It seems that loadavg 15 is the threshold beyond which the music will start to occasionally skip.
<tjaalton> heavy i/o does that
<tjaalton> meh, tfp still missing after building with that single commit
<RAOF> And the laptop hits loadavg 30.  Time to set this mesa build off and let it digest the tasks I've given it.
<tjaalton> so you've multiarch'ed mesa?
<RAOF> Well, merged vorlon's multiarch branch, yes.
<tjaalton> ah right, there was a branch already
<tjaalton> ok, XI2.1 patch applies without fuzzies
<tjaalton> RAOF: patch 201_report-real-dpi.patch has been commented out for some time? or all the time, couldn't find a reference in the changelog
<tjaalton> ok got it from git log
<ach1m> hi, I am using xorg-edgers ppa in Natty, glxgears does exit with a segmentation fault, I mean it doesn't really start at all.  Should I fill a bug-report somewhere?
<YoBoY> hi
<YoBoY> another freeze :]
<YoBoY> tjaalton: you told me yesterday there is a ppa with a test kernel, where I can find it ? I can't work anymore with so many freezes Â¬_Â¬
<tjaalton> YoBoY: bug 740126
<ubot4`> Launchpad bug 740126 in unity (Ubuntu Natty) (and 6 other projects) "Disabling an output can cause vblank events to be missed (affects: 78) (dups: 10) (heat: 392)" [High,Triaged] https://launchpad.net/bugs/740126
<tjaalton> comment #46 has a link to a ppa
<tjaalton> just wget the deb you need
<YoBoY> crap ... why the search on "ppa" don't work xD
<tjaalton> the comments are numbered..
<tjaalton> and it's not a ppa to be precise
<tjaalton> http://kernel.ubuntu.com/~sarvatt/lp740126/
<YoBoY> ha ok, it's not really an "ubuntu ppa" like one we can add to the sources.list, misunderstanding ... my bad
<YoBoY> thanks I'll try
<Sarvatt> argh, libxcb-util0-dev | libxcb-aux0-dev  build depends would have been a lot friendlier for x-x-v-intel :P
#ubuntu-x 2011-06-01
<tjaalton> RAOF: I've pulled the pointer barrier patch from fedora, should I add it to git too?
<tjaalton> applies fine, so lets ship it
<RAOF> Yeah.
<RAOF> We'll also need the accompanying xext(?) library patch.
<tjaalton> libxfixes 5.0 has it
<tjaalton> ..which was already uploaded
<RAOF> Huzzah!
<tjaalton> though not by us, but cdbs
<RAOF> Well, ISTR that gnome-shell requires it.
<tjaalton> probably should just delete the git branch, since the next upload is probably a sync request :)
<tjaalton> yeah gnome-shell was the reason to rush it
<RAOF> Mmm.  Maybe I've got my head around the copy-fb patch now!
<tjaalton> where's this?
<RAOF> The magical confluence of xf86-video-intel 2.15.0 and our copy-fb patch.
<tjaalton> ah that
<RAOF> Because 2.15.0 has changed the semantics of intel_buffer_submit() to mark the screen pixmap's bo as busy and let the kernel do the synchronisation, which means the screen pixmap needs to exist before calling intel_buffer_submit(): )
<bryce> tjaalton, RAOF, plans for merging in xserver 1.10.2?
<bryce> I've looked through the changelog from 1.10.1 -> 1.10.2 and the changes look ok, although too many don't really describe the problem they fix
<tjaalton> bryce: 'git pull', merged already :)
<bryce> tjaalton, alrighty
<bryce> tjaalton, is that going in for A1 or post-A1?
<ScottK> There's a possible regression from the recent xserver SRU in natty being discussed on #ubuntu-devel
<ScottK> I think anything that's not in now is post-A1.
<tjaalton> bryce: post a1
<tjaalton> together with multiarched mesa
<LLStarks> bryce, i have a rather simple recommendation touchpad defaults in oneiric: untick the "disable touchpad while typing" option.
<LLStarks> the delay is far too long
<LLStarks> it takes 2 seconds after typing for the touchpad to become responsive again
<bryce> LLStarks, nah that'd just reshuffle who sees bugs
<bryce> be better to get a real fix
<LLStarks> upstream or packaging patch?
<bryce> well, fix upstream, then patch in packaging if appropriate
<LLStarks> i'll go with whatever cnd recommends before going upstream. he may have some insight on the changes.
<JanC> the only way to fix that is to reliable recognize "accidental touchpad touches" from "intentional touchpad touches"
<JanC> good luck with that   :P
#ubuntu-x 2011-06-02
<cnd> I agree with JanC, I'm not sure if we can do much better than the defaults
<bryce> RAOF, I'm looking at https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions with the thought of one day potentially being able to do mesa point release updates.  It sounds like one of the prerequisites to achieving that is to have a test suite hooked in and running as part of the build process.
<bryce> RAOF, do you think it is at all feasible to have piglit run as part of the mesa build process?  I know not all the tests will pass, so am guessing it'd prevent us from doing this.  But what do you think?
<RAOF> That's not really something that's appropriate for mesa.
<RAOF> Although I guess we *could* test the software rasteriser it's not actually something that we care about.
<RAOF> Having automated piglit runs would be useful, but we can't do them on the buildds.
<RAOF> It's reasonably easy to determine whether there's been a regression on a piglit test; that's what we'd want to hook up to.
<RAOF> Or, rather, have a set of machines in the QA lab hook up to :)
<bryce> yeah, true
<bryce> well, I gather the intent is to have a way to force the tests to always run and prevent a build going through if failed, and not sure even if we had machines in the QA lab if we could construct something like that
 * bryce crosses "post-release mesa point release updates" off the list
<RAOF> We *could* test the software rasteriser (now that ajax has basically fixed the X side of itÂ âº); I guess that would pick up a seriously bad build.
<RAOF> bryce: Actually, how does the kernel team do it?  They've got a shiny process for testing the proposed kernel somewhere, I know.
<bryce> RAOF, well, they don't have it hooked into their build process but they do have a lot of testing tools like the usb key boot testing stuff that'd be nice to tie into
<RAOF> They've essentially got blanket SRU, too, right?
<bryce> RAOF, sort of; they're not part of the MicroReleaseExceptions stuff though
<RAOF> And mesa is very much in the same boat (although with less historical capacity for non-deadly stable updates).
<bryce> the SRUs they put out are like SRU bugfix collections
<RAOF> They're on a bi-weekly stable kernel release cadence, aren't they?
<bryce> right
<bryce> we'd be in the same boat were we doing bunches of mesa cherrypicks wrapped up together
<RAOF> Yeah.
<bryce> but figuring out what changes from the mesa tree are worth cherrypicking is non-trivial
<RAOF> So I think we should be modelling the mesa stable updates on the kernel, because mesa's much more like the kernel than any other package on the MicroReleaseExceptions page.
<bryce> I tend to agree
<RAOF> Well, *if* mesa started with a serious really-only-bugfixes stable branch then cherrypicking would be much more obvious; we'd just pull the most recent stable branch.
<bryce> I'm not sure that'd make it more obvious
<bryce> some of the patches are pretty tersely described, and few have bug refs
<RAOF> Ah, I'm thinking of a different problem.
<RAOF> You're thinking of âhow do I match up these commits with LP bugs to fixâ, I'm thinking of âhow do I avoid patches we shouldn't pullâ.
<bryce> but if they did have a really-only-bugfixes stable branch, where we're confident it's going to be regression free, then it does start to look more like firefox and the other packages, where we could just check that piglit passes and roll the whole thing out, without needing to individually sign off on each patch in the set
<bryce> right; the former is what we have to do for SRUs right now
<RAOF> Which would be like what I understand the kernel's stable kernel update process is; pull in the latest stable release, plus any cherry-picks/patches to fix specific bugs.
<RAOF> Where only the extra cherry-picks need much individual scrutiny.
<bryce> in any case, sort of moot until mesa does proper stable point release updates
<RAOF> Yeah :)
<bryce> btw, speaking of the mesa stable branch, there's a bunch of interesting patches that went in post 7.10.2; a git snapshot might be nice...
<bryce> at least up thru a8032483ecc8750ad58d89c4d96af6ef82a475e2 would get the new radon chip id's
<bryce> radeon
<bryce> up to that release would also include some of the sandybridge work
<bryce> (possibly the stuff people are complaining that fedora has but we lack?)
<RAOF> I'll fold that into the next mesa upload.
<Sarvatt> for a second there I thought you meant a mesa master snapshot, that's going to be a huge beast with the tls fix not working and the new libglapi1-mesa package :P
<RAOF> Damnit, I don't think I can make -intel's copy_fb patch nice enough to upstream.
<bryce> https://wiki.ubuntu.com/KernelTeam/KernelUpdates
<bryce> Sarvatt, no, there's plenty enough on the 7.10 branch to be scared of ;-)
<bryce> problem is there's lots of mesa changes that look sane and good, but linking them to a reported bug or reproducible test case is pretty non-obvious
<RAOF> git hate xserver-xorg-video-intel
<tjaalton> there, there..
<RAOF> Combining the two favourite hate targets!  git and -intel!
<bryce> heh
<RAOF> Hm.  That was rather stupid.
<RAOF> So, it's difficult to tell in oneiric if copy_fb is actually working.  It is, however, now plausible *and* X actually starts!
<RAOF> bryce: Can I hand bug #791596 off to you when you get up?  I'm off to sleep, but it looks like we should revert 503_fix_masked_valuators from the natty-updates X server.
<ubot4`> Launchpad bug 791596 in xorg-server (Ubuntu Oneiric) (and 2 other projects) "Odd Pointer Behavior After Recent Xserver SRU in Natty (affects: 2) (heat: 14)" [Critical,Incomplete] https://launchpad.net/bugs/791596
#ubuntu-x 2011-06-03
<cdbs> I installed X from xorg-edgers on oneiric, got errors and wasn't able to launch Unity because it couldn't find the GLX extension. PPA-purge didn't help. Reinstalling all related packages didn't help
<cdbs> Its the i915 driver which takes care of sandybridge, right?
<cnd> RAOF, still up?
<cnd> actually, nm
<Sarvatt> bryceh: https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/792576
<ubot4`> Launchpad bug 792576 in nvidia-common (Ubuntu) "nvidia-common in debian is different than nvidia-common in ubuntu (affects: 1) (heat: 6)" [Undecided,New]
#ubuntu-x 2011-06-04
<horstle> hi
<horstle> i get system crashes with 270.29-0ubuntu1~lucid~xup2 
<horstle> log says  NVRM: os_schedule: Attempted to yield the CPU while in atomic or interrupt context
<horstle> will there be an update to 275?
#ubuntu-x 2011-06-05
<Sarvatt> that's been a problem for a long time and not specific to 270.29.. i'm not planning on putting 275 in there until its a stable release
<Sarvatt> you can use https://launchpad.net/~sarvatt/+archive/nvidia if you want but you'll still have that problem
<Sarvatt> never seen anything on how to work around it or what actually triggers it, but i've seen bugs with that happening randomly since the 195 series
<hyperair> Sarvatt: is sna coming to xorg-edgers sometime soon? =D
<bjsnider> i'm surprised someone hasn't asked before now
<jcristau> it's been merged what, 24 hours ago?
<jcristau> Sarvatt is totally slacking
<bjsnider> i think the news report is a couple of days old isn't it?
<jcristau> *shrug*
<horstle> Sarvatt: well, for me it didnt happen randomly, it was reproducable
<horstle> wait, it was random, but reproducable
<horstle> ill check if i can hang up my system again
<horstle> so maybe we can trace it
<horstle> it still happens
<horstle> according to the ubuntu-definitions of crash and freeze, i have a freeze
<horstle> thats my xorg.0.log http://paste.debian.net/hidden/f03f8a18/
<Sarvatt> hyperair: no
<Sarvatt> hyperair: i've had it in another PPA for a few weeks
<Sarvatt> its pretty useless without an ABI breaking xserver patch that isn't in 1.11 even
<Sarvatt> hyperair: i've been building it here if you want to try it, will update it to the one that got commited to master when i'm not busy being nagged by the wife to clean :)
<Sarvatt> https://launchpad.net/~sarvatt/+archive/intel-sna
<Sarvatt> its too broken without the xserver patch though
<Sarvatt> ( http://lists.x.org/archives/xorg-devel/2011-April/021356.html )
<Sarvatt> if you want to build it yourself just add this to the beginning of debian/rules in the edgers package
<Sarvatt> override_dh_auto_configure:
<Sarvatt>         dh_auto_configure -- --enable-sna=yes
<Sarvatt> override_dh_auto_test:
<Sarvatt>         dh_auto_test || echo "Test suite failure, but building anyway"
<Sarvatt> thats a new one
<Sarvatt> Fatal server error:
<Sarvatt> [ 70691.812] Wrong event type 0.
<Sarvatt> hyperair: check out how pretty sna looks without the xserver patch - http://sarvatt.com/downloads/sna1.png
<Sarvatt> but its fast!
<Sarvatt> hyperair: ok updated the intel-sna PPA if you want to try it. I put a note on the xorg-edgers PPA page about it too
<horstle> is there anything i can do about my 'atomic or interrupt context'?
#ubuntu-x 2012-05-28
<mlankhorst> RAOF: yeah needs testing though
<mlankhorst> plymouth was really annoying, had to rebuild that one first without shlib depends before I could install renamed libdrm
<RAOF> Yeah, essential: yes packages make the baby Jesus cry.
<mlankhorst> RAOF: I had to disable the binary driver packages because I wasn't sure it would be needed to rename those. Newer versions will probably work with new abi too.
<tjaalton> right
<tjaalton> although, probably the 'stable' version needs to be renamed
<RAOF> That's a fair point; we'd need to ship {nvidia-current,fglrx}-updates, though.
<mlankhorst> indeed
<mlankhorst> but since this was meant to  be a proof of concept for testing mechanics I felt just using open source drivers was enough for now :)
<tjaalton> sure
<mlankhorst> the part that scares me is the versioned replaces, I could install xfonts-base on top of the renamed package because it was newer
<tjaalton> why would you need a renamed xfonts-base?
<mlankhorst> tjaalton: this is just testing mechanics
<mlankhorst> so why not
<tjaalton> guess there are plenty of packages to test with already :)
<mlankhorst> xfonts-base was special because of its dependency on xfonts-utils
<tjaalton> ok
<mlankhorst> I learned from that renaming xfonts-utils is non-trivial and an update would probably be better in that case
<tjaalton> likely no need for either
<mlankhorst> true, but good to test regardless
<mlankhorst> and maybe not for quantal, but there are some other stacks to test too :)
<tjaalton> core fonts, who uses them anymore anyway :)
<tjaalton> no great new features to be seen there
<RAOF> Are you sure we shouldn't backport xfs? :P
<tjaalton> i'm sure we should drop it :)
<mlankhorst> tjaalton: yeah but if xshiny-new-bright-fonts comse along that requires a new xfonts-utils
<tjaalton> well maybe not drop it, low maintenance
<RAOF> You mean: drop it as soon as someone files a bug against it. ?
<tjaalton> hehe
<mlankhorst> well duh D:
<mlankhorst> dont drop it, just replace by empty package, see who complains, bahah
<mlankhorst> lets see if the renamed stack installs on the cd
<mlankhorst> im not going to let it anywhere near my dummy pc's hard drive
<mlankhorst> hm console-setup gets annoyed too
<mlankhorst> I guess now the goal is to get it installed without causing ubuntu-desktop and ubuntu-minimal to be removed :)
<RAOF> :)
<tjaalton> that would mean the provides are broken
<mlankhorst> tjaalton: yeah can't do versioned provides
<tjaalton> do they actually need those?
<mlankhorst> that's the reason they're broken..
<tjaalton> huh
<RAOF> What's depending on explicit versions of the stack?
<mlankhorst> usually because of a Depends ${shlib:Depends}
<mlankhorst> which means basically anything that links to any library in our stack
<RAOF> Oh, right.
<RAOF> I thought we weren't updating libraries, though.
<tjaalton> libdrm..
<tjaalton> at least
<tjaalton> probably not due to that though
<RAOF> Right. But there's nothing outside the stack that depends on libdrm (?).
<tjaalton> yeah
<mlankhorst> RAOF: yeah but plymouth/intel-gpu-tools have versioned depends
<mlankhorst> and console-setup had a versioned depends on xkb or something
<RAOF> Yeah, but I was counting those as a part of the stack.
<RAOF> Ah, console-setup?  Hmm.
<mlankhorst> atm im just trying to get to 0 removes, so by pushing new packages im keeping track of which packages break
<tjaalton> console-setup could drop the versioned depend
<tjaalton> >= 0.9..
<mlankhorst> thats what my rebuild does
<tjaalton> we're at 2.5 now
<mlankhorst> get it in for quantal, then :D
<mlankhorst> i dont have the rights to push anything
<tjaalton> it should go as an SRU for precise as well
<tjaalton> preferably before 12.04.1..
<mlankhorst> tjaalton: we're not sure yet what packages we would need, this is just a test of the mechanics
<tjaalton> so it's not blocking anything?
<tjaalton> i'm confused
<mlankhorst> erm, it depends if we decide we need a new xkeyboard-config and x11-xkb-utils or not
<tjaalton> it's a nice-to-have, not something hw enablement needs
<mlankhorst> if you want it drop version in console-setup and sru it, if not just dont ship those 2 renamed :-)
<tjaalton> dropping the version is easier
<mlankhorst> oh right, need to rebuild the xorg package too
<mlankhorst> RAOF: any objections if the xorg source package will be treated specially? makes things a lot easier
<RAOF> None at all.
<mlankhorst> perfect :-)
<tjaalton> yeah, big thumbs up from me
<tjaalton> most of the metapackages it builds make no sense
<tjaalton> for the backports
<mlankhorst> tjaalton: those metapackages need to be tweaked to depend on the oldname | newname
<tjaalton> right
<mlankhorst> hm, how can I see why apt-get install .*lts-backport-quantal decides to remove some packages?
<RAOF> mlankhorst: I find that aptitude's resolver is sometimes more usefully verbose.
<mlankhorst> yeah but it doesn't allow regexp install
<RAOF> ~nlts-backport-quantal
<mlankhorst> ty :)
<RAOF> You can also play around with the debug options (pass -o to apt-get, check out "man apt.conf" for the things you can actually *pass* to apt-get)
<mlankhorst> oh libxklavier16 was going to be removed it seems
<mlankhorst> xkb-data >= 0.8, sigh
<tjaalton> uh
<mlankhorst> klavier is flemish for keyboard :)
<mlankhorst> oh fun, it keeps adding the versioned depend on xkb-data back
<tjaalton> check if there's a control.in
<tjaalton> since it's a gnome package..
<mlankhorst> yeah it has ;s
<mlankhorst> just independently noticed it 
<tjaalton> so modify that instead
<mlankhorst> yeah i did, i keep running into weird new ways of packaging :-)
<mlankhorst> almost all packages seem to have their own silly way to break
<mlankhorst> success! It only replaces the X stack itself now
<tjaalton> nice
<mlankhorst> still some package failure it seems
<mlankhorst> oh right.. cant install libgl1-mesa-swx11 at the same time as the normal version
 * RAOF wonders why we even build that package
<mlankhorst> no idea :-)
<mlankhorst> probably carried over from debian and removing was more work
<tjaalton> just that it's become somewhat obsolete on the hw we support
<tjaalton> due to llvmpipe
<tjaalton> i'd like to drop the 8 & 16bit osmesa packages..
<mlankhorst> oh woops, probably broken due to rename
<mlankhorst> looks like mesa packaging needs more love
<mlankhorst> hm, how do the bug scripts work?
<mlankhorst> seems they're path dependent on package name, but with renamed package it looks like it would break
<tjaalton> do we want bugs for them?-)
<tjaalton> besides, you can just use the original names/links
<tjaalton> we don't really want bugreports against the renamed source packages..
<mlankhorst> i have no idea how the mechanism is supposed to work for that
<mlankhorst> but ok I'll trust you on that one. :s
<tjaalton> well, it's just pointing to the xorg bug script
<tjaalton> but not sure if apport will use the package source name anyway
<mlankhorst> ill just keep it broken for now
<mlankhorst> I don't think it's a source package, but the binary package being used
<tjaalton> hm, apport isn't that useful.. my gpu hung and apport offered to report a bug, but after clicking 'continue' the window just closed and didn't open lp for finishing the submission
<mlankhorst> oh seems we DO need all open source drivers including the ugly ones for testing, else xserver-xorg-video-all fails
<tjaalton> or you create xserver-xorg-{input,video}-some
<tjaalton> probably not a good idea..
<mlankhorst> well i can replace the X stack now at least
<mlankhorst> I think the upgrade is breaking because of the last missing ones to satisfy the xserver-xorg-video-all install
<mlankhorst> my goal for today is simply being able to install the renamed stack without removing any packages that haven't been renamed.
<tjaalton> hmm, does kernel 3.4 require something special for intel? it's not using intel kms here..
<tjaalton> but vesa, which probably makes the kernel hang hard after maybe 10s
<mlankhorst> anything in xorg log?
<tjaalton> just that it falls back using vesa
<tjaalton> in fact it doesn't initialize drm at all
<tjaalton> ..
<mlankhorst> o.o
<tjaalton> revealed by dmesg
<mlankhorst> well there you go, then
<mlankhorst> the pae kernel should work on non-pae hardware right?
<tjaalton> not sure
<tjaalton> actually no, it doesn't work
<tjaalton> 3.4 works on an old i965 based machine
<bjsnider> is there still a non-pae i386 kernel?
<tjaalton> it's getting removed from quantal
<tjaalton> or not built anymore, dunno
<tjaalton> the problem I had was missing dri modules from the drm-next build
<tjaalton> ..
<mlankhorst> hm during upgrading it removes ubuntu-desktop, but i can install it again afterwards, sigh
<mlankhorst> I guess I'll need to specify ALL the packages to apt-get in 1 go :)
<tjaalton> check with aptitude why it removes u-d
<mlankhorst> i know why, i missed some packages causing xorg to be removed
<mlankhorst> so I'm just going to create a dummy package in xorg that has a dependency on the whole renamed stack
<tjaalton> ok
<mlankhorst> hm, how do I sed variables in a makefile?
<mlankhorst> nm I think ill split it off to its own package
<mlankhorst> bryceh/raof: I can install the updated stack from q-lts-backport now, see the mail I sent on the ubuntu-x mailing list :-)
<bryceh> mlankhorst, sweet
#ubuntu-x 2012-05-29
<mlankhorst> bryceh/raof: Any luck in breaking things? It was meant for testing the renamed stack so no point in keeping it up publicly if it's not being broken ;)
<tjaalton> yesterday was the memorial day in the US, so bryce at least was doing something more fun I hope :)
<mlankhorst> ah kk
<RAOF> Ah, that's why no one was around?
<mlankhorst> i guess so, it was some holiday in netherlands too but it was too warm so i just worked and will probably work less for the rest of the week to compensate :P
<tjaalton> getting chilly up here :/
<mlankhorst> i wanted to bike 45 km, but it was too hot so some other time this week I will :)
<tjaalton> i'm looking for a new bike, but can't decide between a cyclocross or a roadrace model :)
<tjaalton> should probably just go and try them out
<bryceh> yes, this weekend went to the Oregon beach near Astoria with bdmurray, kees, slangasek & families and drank whiskey, played House on Haunted Hill, Small World, other assorted games.  Oh and built a Star Wars puzzle.  And watched bdmurray's boys fish and row around on the lake.
<bryceh> whatever work that got done was accidental :-)
<tjaalton> i saw some emails by slangasek ;)
<bryceh> he did sneak off with his laptop a few times
<bryceh> fun weekend though in any case.  I think I won 80% of the games.  :-)
<bryceh> tjaalton, btw I did chat with slangasek a bit about the debian versioning on the xorg packages for the lts
<mlankhorst> bryceh: what games
<tjaalton> bryceh: re games; you're a pro ;)
<tjaalton> cullaby lake?
<bryceh> he agreed that while the minor versioning issue by debian seems valid, since we've not needed to use it so far, it's something we can probably safely ignore for our purposes.
<tjaalton> yeah
<tjaalton> we'll cut corners anyway
<tjaalton> also, we can minimize the backported list of drivers to the ones we care, and which get new hw support (video; ati, intel, nouveau, maybe openchrome. input; evdev, synaptics, wacom..)
<mlankhorst> is this for lts backports?
<tjaalton> although, if the .2 install media will have only the backported set it won't work
<mlankhorst> tjaalton: It's less work to do all the drivers than only some specific drivers
<tjaalton> mlankhorst: ok then :)
<tjaalton> and it's probably true
<mlankhorst> it is true, most drivers run flawlessly through the rename script
<mlankhorst> special casing in xserver-xorg-video-all and input-all is more complex
<tjaalton> bryceh: btw, are you into scifi strategy games? there's a new (finnish) game called Eclipse.. I know the artist :)
<mlankhorst> if you've seen the rules of most drivers, they're so simple it incurs no extra cost
<tjaalton> yep
<RAOF> tjaalton: Has it won the Kennerspiel des Jahres yet? :)
<RAOF> This is basically my threshold for consideration.
<tjaalton> RAOF: hehe, don't think it has done that yet
<tjaalton> but the ratings are good http://www.boardgamegeek.com/boardgame/72125/eclipse
<mlankhorst> anyhow, i guess ill try to see if i can break the stack one more time then get some work done :)
<tjaalton> (looks like it's in stock now.. should probably get it though I've noone to play it with :)
<bryceh> "cullaby lake" - yes, our house had a boat landing on it, the kids went out in canoes and paddle boats on it fishing
<bryceh> scifi strategy games - totally into that.  will have to check out eclipse
<tjaalton> http://www.youtube.com/watch?v=H4LevjuhYqc&feature=player_embedded
<tjaalton> "thematic rank: 1"
<bryceh> http://boardgamegeek.com/boardgame/72125/eclipse
<tjaalton> yep
<bryceh> what games - small world (awesome! highly recommended).  Betrayal at House on the Hill - fun.  Impossible Machine, Word on the Street, Ticket to Ride: Europe, Bohnanza, Gardens of Alhambra.  Others also played Apples to Apples, Settlers of Catan, Guillotine, Ricochet Robots.
<bryceh> 900 pieces!!
<tjaalton> yeah it has a few components
<mlankhorst> bryceh/raof: Seems I can install xserver-xorg-dev or xserver-xorg-dev-lts-backport-quantal with the renamed stack, is this a feature or a bug? :P
<RAOF> mlankhorst: I think that's indicative of a bug? Those two packages should have file conflicts?
<mlankhorst> RAOF: i cant install it at the same time
<RAOF> Oh, no. You can install one or the other? Yeah, that should be ok.
<mlankhorst> i can just install the old one atop the new stack
<RAOF> I don't think that's a problem.
<RAOF> It's possibly even a feature.
<mlankhorst> probably
<mlankhorst> but makes it annoying if anything depends on xorg-dev since it will prefer to pick the unrenamed one by default
<mlankhorst> oh, seems libxatracker and libglu are not pulled in by default..
<RAOF> By what?
<RAOF> Only the vmware DDX depends on xatracker, right?
<mlankhorst> if i switch stacks they're happy to stay unrenamed
<jcristau> libGLU hasn't changed in like 10 years
<RAOF> Has that been split out of mesa yet?
<mlankhorst> not sure
<jcristau> i think not
<mlankhorst> glw was
<mlankhorst> but if vmware depends on xatracker, hmm..
<mlankhorst> yeah libxatracker1
<mlankhorst> do we care enough to force it to depend on the renamed version?
<RAOF> libxatracker is built from mesa, right?
<RAOF> I think we do care.
<mlankhorst> ok
<mlankhorst> in that case I'll update the mapping file :)
<mlankhorst> hopefully that will fix shlibs depends automatically, else I'll add a vmware specific hack
<mlankhorst> oh right, it would fix things
<mlankhorst> ok xserver-xorg-lts-backport-quantal seems to work, it pulls in everything except libglu-mesa1, which we may or may not care about :)
 * RAOF is firmly in the "not care" group
<mlankhorst> RAOF: yeah, but it might be useful for the cd, shrug.
<mlankhorst> should I try to see if I can make an image with all the non-renamed packages removed?
<RAOF> That'd be a good test.
<mlankhorst> hm how is the livecd usually mastered? the documentation i find only mentions modify existing images
<RAOF> mlankhorst: I have no idea; cjwatson or pitti would be the best candidates, I think.
<mlankhorst> Otherwise I won't bother, seems it ought to work because I can install the renamed x stack and restart lightdm with it. I bet it's just copying root to a new place
<mlankhorst> which would mean a boot test would be just as much validation :)
<mlankhorst> do we care about the downgrade path? eg remove quantal after install
<mlankhorst> the replaces make those fun
<mlankhorst> cant really think of an easy way to do it safely, even
<RAOF> We generally do not support package downgrades; I don't think it's tremendously important to support it here.
<mlankhorst> ok good
<mlankhorst> else you can very easily end up with a broken system due to replaces
<Azelphur> I'm having an issue with wine, nvidia and 64bit, I spoke to the wine people and they say I don't have the 32bit compatibility libs for my driver, which is causing wine to fall back to using an ancient OpenGL version,  yet I have ia32-libs installed. Any ideas?
<RAOF> Azelphur: Which driver? nouveau or nvidia-current?
<Azelphur> nvidia-current (x-swat)
<Azelphur> I found a wine forum post on the subject, http://forum.winehq.org/viewtopic.php?t=15537
<RAOF> That ships the 32bit libs itself; ia32-libs is not necessary.
<RAOF> (for libGL; the rest of ia32-libs is needed, unless you're on Precise, where multiarch works)
<Azelphur> I'm on precise
<RAOF> As you see on the bug, it's not actually a driver problem.
<Azelphur> ah, I'm still reading through it all trying to figure it out
<RAOF> Looks like it's common-or-garden wine bug.
<Azelphur> haha, the wine thread says it's a ubuntu bug xD
<RAOF> It also applies to intel (I see it, although it doesn't affect anything I actually use).
<Azelphur> \o/
<Azelphur> YAY, Bug report on launchpad workaround works
<Azelphur> echo 0|sudo tee /proc/sys/kernel/yama/ptrace_scope <-- this is what fixes my issues \o/
<Azelphur> looks like scott richie is working on that issue, so all good, :)
<RAOF> Seriously, that's it?
<Azelphur> yes, it causes CS:GO to crash on startup for me
<Azelphur> wine is still complaining about GL_VERSION stuff not working, but at least my game works now :D
<RAOF> What crazy reason does wine have to ptrace a non-child to determine GL capabilities?
<Azelphur> no, I apparently have two separate issues that I thought were connected
<RAOF> Ah.
<Azelphur> CS:GO wouldn't start, I assumed because of wine complaining about OpenGL issues
<Azelphur> but CS:GO turned out to not start because of that
<Azelphur> I still have the opengl issue, but at least my game works now :)
<RAOF> In which case I exclaim: what crazy reason do they have for ptracing a non-child process :)
<Azelphur> *shrug*
<Azelphur> http://pastebin.com/36P7d3KU is wines complaints about my OpenGL, should you be interested :)
<mlankhorst> sforshee: it arrived :)
<sforshee> mlankhorst, that was fast
<sforshee> enjoy :)
<bryceh> mlankhorst, lts upgrade successful (although found a couple typos(?) in your directions
<mlankhorst> ..Â¿
<bryceh> mlankhorst, posted to list
<mlankhorst> oh woops typo :P
#ubuntu-x 2012-05-30
<mlankhorst> morning
<Sarvatt> mlankhorst: morning!
<Sarvatt> amazing work on the lts backports renaming btw, cant believe you got it working
<mlankhorst> all the stuff was already in place, I just refined it a little :)
<mlankhorst> but thanks :)
<Sarvatt> i cant believe you got nouveau working outside for cairo 1.12 too outside of the libdrm-nouveau2 change too, really awesome :)
<Sarvatt> and that wasnt english but yeah
<mlankhorst> debian needs some more fixes to kernel drm, i have them but untested
<mlankhorst> tiling's fun
<mlankhorst> bryceh: awake yet?
<bryceh> mlankhorst, what's up?
<mlankhorst> oh the renamed stack thing. We can't support it because it's impossible to remove properly atm afterwards.
<mlankhorst> And the binary drivers will be uninstallable although that would be trivial to fix
<tjaalton> wasn't the plan to offer a script a'la ppa-purge to allow downgrades
<tjaalton> or what do you mean by "impossible to remove afterwards"?
<mlankhorst> tjaalton: Because of the Replaces: unrenamed if you install the older version it won't install right.
<tjaalton> use the force
<mlankhorst> I'm going to try another version with Conflicts instead of Breaks
<bryceh> where there's a will there's a way :-)
<tjaalton> or just don't support downgrades
<tjaalton> no, conflicts is wrong
<bryceh> anyone know if we formally support downgrading from a .2 lts back to the .0?
<tjaalton> no
<mlankhorst> also fun will be if you try to upgrade from renamed stack to quantal
<tjaalton> nothing new :
<tjaalton> :)
<tjaalton> wasn't it decided as "unsupported"?
<mlankhorst> yeah but if we want to do an announcement we might want to emphasise those things..
<tjaalton> it's not coming before january..
<tjaalton> but yeah, of course
<tjaalton> it wouldn't be that hard to allow upgrades though, if the version number would be less than in quantal (-XubuntuX~lbq) and the package replaced the renamed one
<tjaalton> uh
<tjaalton> the version of the renamed package was lower, and the proper quantal package had provides/replaces: renamed.. but it would be fun to script the build of the renamed package from that :)
<tjaalton> so, just don't allow upgrades to non-lts releases..
<tjaalton> the stack on T will have butt-ugly control files..
<tjaalton> and then that stack will be the last backported one, so you get to do the above at least once
<mlankhorst> tjaalton: I think I'm just going to create a real metapackage by then that defines every possible renamed package from quantal onward..
<tjaalton> that won't help
<Sarvatt> it's using replaces? yeah that totally wont downgrade right, you would have to purge then reinstall the unrenamed packages :(
<mlankhorst> Yeah..
<mlankhorst> tjaalton: Why not?
<tjaalton> mlankhorst: the new real packages need to replace the old renamed ones
<tjaalton> new unrenamed packages
<tjaalton> let me stop my head spinning..
<mlankhorst> tjaalton: I know, but I mean if it upgrades to that fake package first I could make those depend on the unrenamed package.
<tjaalton> mlankhorst: it will update the metapackage but leave the old renamed packages installed
<tjaalton> uh, maybe this is too abstract to handle
<tjaalton> in my little brain anyway
<mlankhorst> tjaalton: Could we at least add a Conflicts: package >> currentversion to renamed stack?
<mlankhorst> or would that break too
<tjaalton> what would that solve?
<mlankhorst> so upgrading to unrenamed will remove those renamed packages first..
<mlankhorst> between lts releases
<tjaalton> that's not how dpkg works
<tjaalton> if you need details you can read the policy, the way the pre/postinst scripts are run etc, it's a nice diagram :)
<tjaalton> debian policy that is
<mlankhorst> can you add a version to replaces: ?
<tjaalton> yes
<mlankhorst> We definitely should add a version to our control files for replaces then, so in future upgrades we could bump version and do a replaces for all the possible renamed versions to upgrade back to next lts. :)
<mlankhorst> Fortunately it's automated enough now to simply add it, bump version number, upload it to launchpad and check next day.
<tjaalton> added to which control file, the renamed or unrenamed package?
<mlankhorst> renamed
<tjaalton> so 'renamed; Replaces: unrenamed (<< version)
<tjaalton> '?
<mlankhorst> yes
<tjaalton> ok, I don't understand the rest of the sentence then :)
<mlankhorst> and for r Replaces: unrenamed (<< lts), renamed1
<mlankhorst> and for next lts the package will have: Replaces: all renamed versions
<tjaalton> well, the releases can have real updates too, so versioned replaces need manual thinking
<tjaalton> would be great if you could write these cases in a wiki or so, a lot easier to review than trying to read between the lines here :)
<mlankhorst> I'm still not entirely sure yet and experimenting
<tjaalton> doesn't matter, wiki can be edited :)
<bryceh> fwiw I directed them not to mention X stack in the announce they're prepping.  Don't think widespread usage right now is going to buy us anything (except support questions)
<bryceh> tjaalton, mlankhorst if someone adds the ppa and does just a regular dist-upgrade, it won't actually upgrade the X stack will it?  they have to specifically install the metapackage right?
<mlankhorst> indeed
<mlankhorst> but it might be better to remove anyhow
<bryceh> no, I think leave it in the ppa.  Removing it would sort of be defeating the purpose...
#ubuntu-x 2012-05-31
<RAOF> You know, it's probably time to push intel 2.19.
<mlankhorst> do ittt
<RAOF> Occasionally losing all text rendering is getting annoying.
<RAOF> (Which ahs the corollary: don't expect me to reply to anything untill I've rebooted ?)
<tjaalton> on what hw do you get that?
<tjaalton> or is in on quantal only?
<tjaalton> btw, should we try to get mesa 8.0.3 as SRU?
<tjaalton> i know proposed has one patch backported
<bryceh> would be nice, although pitti would typically reject it unless each change had an associated ubuntu bug #.  But now that RAOF is on SRUs maybe he'll be more allowing?
<mlankhorst> sure lets sru full synaptics too :D
<tjaalton> bryceh: there was a session about a more sane sru policy
<tjaalton> that would allow bugfix releases
<tjaalton> having a lp# for every change is insane
<tjaalton> anyway, it should get in quantal first..
<tjaalton> Sarvatt: what's the status of mesa 8.0.3?
<tjaalton> i promised to sponsor it once it's ready
<tjaalton> anyway, I'll 'test' the sru process with libwacom first :)
<mlankhorst> bryceh/raof: Should we push synaptics-1.6 branch to quantal?
<mlankhorst> so we can sru that
<tjaalton> ask cnd what to do
<mlankhorst> cnd: ^
<tjaalton> there :)
<mlankhorst> well i believe we should push it to quantal regardless
<mlankhorst> i don't know if it gets picked up though
<tjaalton> bryceh: btw, the status page still doesn't show quantal versions
<bryceh> tjaalton, yes I was at the sane sru policy session; it did not address bugfix releases, that policy is unchanged afaict.
<tjaalton> we'll see about that
<tjaalton> :)
<bryceh> tjaalton, hmm, it should be showing that by now.  on my todo list.
<tjaalton> ok, thanks
<tjaalton> lunch ->
<bryceh> mlankhorst, seriously I've never been able to get a point release of any X package through the SRU police in the past, without itemized bug #'s per change.  I'm highly skeptical that this has changed, but you're welcome to try.
<bryceh> (and if it has changed finally, well that's nice, but I'll be quite chagrined)
<mlankhorst> bryceh: yeah it's just annoying that all the ones in that point release are bugfixes we want
<mlankhorst> But I don't know if there are even bugs open for some of them, and the corruption one is so annoying that it has to be sru'd as soon as possible, I don't care how. :P
<bryceh> mlankhorst, if there's any we can reproduce ourselves, those can be done.  We'd need to file bug reports ourselves and then "fix" them, and sru that.
<mlankhorst> bryceh: yeah its annoying people file bugs and don't even bother verifying
<bryceh> or, if there are upstream bug reports opened which we know should also affect ubuntu, those are sometimes acceptable
<bryceh> mlankhorst, welcome to ubuntu-x :-)
<mlankhorst> bryceh: oh and also fun some are not in upstream tracker but in redhat tracker O_O
<bryceh> if there's changes that are obviously correct by code inspection, *sometimes* those are acceptable, but usually not by themselves; I've had luck sending them in with another fix that is more demonstrable
<RAOF> We'd *really* like to reduce the number of SRUs that sit in -proposed indefinitely, languishing without testing.
<mlankhorst> RAOF: Seems I can help airlied with his upstream work in some way after all. Helping him get some hacks removed. :-)
<RAOF> :)
<RAOF> One way we're attacking that is that we're enforcing the requirement for a test case; that makes it easier for someone to ensure it's tested.
<bryceh> RAOF, can you confirm or deny that the SRU team has changed policies regarding bug fix releases (ala allowing mesa 8.0.3 without having bug# breakouts?)
<mlankhorst> RAOF: I wonder how you want to do that with things like nouveau
<RAOF> bryceh: There's been no policy change there, but a 8.0.3 SRU *may* be appropriate; GNOME apps get SRUd for their bugfix point releases.
<RAOF> bryceh: They still need at least one tracking bug, though.
<RAOF> mlankhorst: Obviously X SRUs have some testing problems - like the kernel, we've got fixes that can only be tested in very specific circumstances.
<bryceh> RAOF, as I understand it, GNOME has a standing exception with regards to that; do you mean we could get a similar exception for X.org packages?
<seb128> bryceh, there is no "wave bug fixes versions in" rules without going through the technical board to get an exception for the said source
<seb128> bryceh, no we don't, the exception is for the feature freeze pre release
<RAOF> bryceh: We could get such a standing exception, yes.
<seb128> bryceh, SRUs need to be carefully checked and they are for GNOME, we need the rational, testcase, bugs attached, week in proposed, verification-done for all bugs, etc
<mlankhorst> seb128: yeah but the problem with synaptics is there are currently a lot of different bugs that are all roughly the same..
<mlankhorst> eg weird behavior after suspend fixes
<mlankhorst> or different thing that can go wrong after disabling and re-enabling
<seb128> mlankhorst, SRU team is not that strict, when it's hard to test (i.e random segfaults is a case for GNOME stuff), you write a "run that version for a week and make sure you don't notice a regression"
<seb128> mlankhorst, if you get some users doing that and confirming there are no regression they let the SRU in on the basis it might fix the issue or not but in any case it doesn't make things worth
<seb128> mlankhorst, we just need to know that people have been running the version and that it's behaving correctly to avoid breakages in -updates
<RAOF> And if you think it'll fix a bunch of bugs you can upload an SRU with all those bugs in there; as long a reasonable proportion of them are verified fixed we can accept the whole SRU in.
<mlankhorst> ah k :)
<RAOF> I think we're also going to be getting some better stats via errors.ubuntu.com for SRUs, which might make things easier to justify.
<RAOF> At least for crashes.
<mlankhorst> we should ship 12.10 then, it reports no crashes :-)
<seb128> RAOF, they stopped doing the "proportion is verified" it seems
<seb128> RAOF, they want all green, where all green might just be the "no visible regression" for the ones that can't be verified
<RAOF> seb128: I, at least, don't promote to -updates unless there's some verified fixes.
<seb128> RAOF, others don't promote unless there is *all* verified fixes (or with a rational of why they are ok even if not verified)
<bryceh> RAOF, so if we did an upload of a point release which has 20 git changes, and link to 2-3 bugs confirmed as fixed by it, that'd be sufficient?
<seb128> bryceh, that's what we basically do for GNOME
<seb128> i.e the recent gtk update
<RAOF> bryceh: As long as the point release changes aren't OMGSCARY, yeah.
<bryceh> seb128, and you say you don't need any special exception for that?
<seb128> bryceh, no
<bryceh> seb128, no you don't say that, or no you don't need an exception?
<seb128> it just needs to be looking with it on a risk,benefit perspective
<seb128> bryceh, sorry, we don't need any special exception
<seb128> they just review things in the queue and evaluate if it's appropriate for a SRU based on the diff and the rational, regression potential etc
<bryceh> hmm, interesting.  The times I've attempted it I always got push back that each and every change needed a bug # and separate verification
<seb128> was that a long ago?
<bryceh> to the point it was ridiculous to try to get bug fix point releases in
<seb128> there was some pendulum swings there from too strict to not enough
<bryceh> easier to just make a ppa with the new version and point bug reporters there.  (thus the x-updates ppa)
<bryceh> ok, well maybe I experienced it during the too strict phase and gave up at that point
<seb128> I think they are reasonable nowadays
<seb128> you should try one again and see how it goes
<mlankhorst> bryceh: oh it's going to be fun to get xrandr in, I think the lib and bin will need to be sru'd if parts of hybrid graphics land this cycle.
<bryceh> seb128, yeah like I mentioned above, usually pitti was the only one reviewing my sru requests, and he seemed pretty consistently strict about it.  But now that others are participating in SRU review, perhaps its more reasonable in cases like these.
<mlankhorst> but in any case I think synaptics could qualify as being pre-release. :P
<mlankhorst> bryceh: Can you upload xserver-xorg-input-synaptics to quantal at least?
<bryceh> mlankhorst, I am able to do that; are the necessary changes staged in git?
<mlankhorst> Yes :)
<bryceh> ok great
<bryceh> mlankhorst, why are patches numbered from 201, rather than from 131?
<bryceh> oh I see, they're to differentiate patches included in 1.6.2
<bryceh> mlankhorst, upload sponsored for quantal.
<mlankhorst> Thanks!
<aquarius> bryceh, my bug of xorg snowcrashing (#1003333) seems to have resolved itself, but I don't know *what* resolved it. I don't really want to say "hey, it doesn't happen any more, lucky eh!" and that's it on the bug report, but I don't know what information to provide that would actually be useful to you.
<tjaalton> heh, there was a post about the new sru process to u-d-a@ earlier today
<tjaalton> no mention of stable point-releases
<jussi> hrm, my xorg is eating cpu atm - any ways I could tell why? 
<jussi> (its at about 50-60 %)
<jussi> guess you are all asleep today.
<tjaalton> it's some app doing that
<Sarvatt> best humble bundle ever http://www.humblebundle.com/
<Sarvatt> woohoo for linux bastion!
<Sarvatt> whoa its redeemable in the ubuntu software center
<bryceh> aquarius, well, as there's not enough info to do diagnostics, if it's no longer reproducible just close the bug out.  you can always reopen if it comes back
<aquarius> bryceh, ok, I shall do. Sorry I can't provide more useful info!
<jussi> tjaalton: how do I find outh which app?
<tjaalton> jussi: you could try xrestop
<jussi> tjaalton: thanks, I found the culprit - a popup flash based advert that I hadnt noticed was open on another desktop...
<jussi> flasah is evil, no doubt about it
<jussi> flash even
<tjaalton> yeah I could've guessed it was the browser.. :)
<bryceh> tjaalton, package_status is pulling quantal info now
<tjaalton> bryceh: cool, thanks
#ubuntu-x 2012-06-01
<mlankhorst> morning
<RAOF> Morning mlankhorst!
<mlankhorst> RAOF: seems I get to debug firmware:x
<RAOF> Woot! What could be more enjoyable!
<mlankhorst> a lot of things
<mlankhorst> :P
<mlankhorst> RAOF: I can has tiling now :D
<Prf_Jakob> RAOF, bryceh: Do you guys have any automatic builds of the latest mesa git?
<tjaalton> Prf_Jakob: there's xorg-edgers, but I doubt it's tracking master atm
<tjaalton> hmm looks like it is
<tjaalton> https://launchpad.net/~xorg-edgers/+archive/ppa
<tjaalton> ah, didn't build
<tjaalton> ../../../../../src/mesa/libdricore/../main/api_arrayelt.c:45:27: fatal error: main/dispatch.h: No such file or directory
<tjaalton> compilation terminated
<Prf_Jakob> Hmm
<tjaalton> it's not fully automated, mesa has been a special case for edgers aiui
<Prf_Jakob> Ok
<tjaalton> too fragile i guess :)
<Prf_Jakob> Heh
<jcristau> are you calling mesa's build system crazy?
<Prf_Jakob> Never!
<Prf_Jakob> jcristau: the problems only happens because people are poking at it.
#ubuntu-x 2012-06-02
<tjaalton> triaging intel gpu hang bugs "for fun"
<tjaalton> looks like a lot of dupes, and at least one clear candidate kernel commit for precise identified
<tjaalton> 3a69ddd6f872180b6f61fda87152b37202118fbc drm/i915: Set the Stencil Cache eviction policy to non-LRA mode.
<tjaalton> haha, bug 1007477
<ubottu> Launchpad bug 1007477 in xorg (Ubuntu) "PÃ¤ivitys ongelma" [Undecided,New] https://launchpad.net/bugs/1007477
<tjaalton> I'll educate him..
<jussi> tjaalton: hehe...
#ubuntu-x 2013-05-27
<mlankhorst> morning
<tjaalton> yeah
<aissen> what you guys are doing with LTS HWE is crazy. Crazy and awesome
<aissen> was everything done by hand, or did you have scripts automating the creation of those packages: http://packages.ubuntu.com/precise-updates/xserver-xorg-video-all-lts-quantal ?
<mlankhorst> nope, I'm fairly sure it's just crazy
<mlankhorst> https://bazaar.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools/files lts-stack and lts-pkg-rename
<aissen> mlankhorst: thanks.
<aissen> it seems libxrandr has a different naming scheme: http://packages.ubuntu.com/precise-updates/libxrandr-ltsq2. Is to have it parallel installable ?
<aissen> Is it* 
<mlankhorst> yeah
<mlankhorst> source package still follows same
#ubuntu-x 2013-05-29
<tjaalton> how annoying.. text selection from a terminal doesn't stay 'on'
<tjaalton> same with terminator, gnome-terminal & xterm
<tjaalton> huh, gitk to blame
<tjaalton> sanity resumed
 * mlankhorst testing the version scripts
<Sarvatt> http://bazaar.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools/revision/516 whee
<mlankhorst> Sarvatt: medium is enough, as long as it's not low
<Sarvatt> it wasn't for < current dev release last i tried :(
<Sarvatt> i'll try it again
<mlankhorst> rebuilding mozilla for every supported arch is evil, though
<mlankhorst> and release :/
<Sarvatt> man the mesa-demos git repo (ubuntu branch) is embarassing, not sure if i should git push -f a clean version or leave it.. :P
<mlankhorst> pretend the ubuntu branch doesn't exist, copy the package from experimental
<mlankhorst> wipe evidence next time debian freezes
<mlankhorst> >:D
#ubuntu-x 2013-05-30
<tseliot> seb128: can you please approve nvidia-prime in saucy? (if you're an archive admin)
<seb128> tseliot, I can try to have a look, but maybe just ask on #ubuntu-release in case somebody else feels like picking it up
<seb128> I'm busy atm but will try to squeeze that later today if nobody else grab it there
<tseliot> seb128: ok, thanks
<Prf_Jakob> So how can I get the changelog of a package between two versions?
<Prf_Jakob> say linux-image-3.5.0-30-generic and linux-image-3.5.0-31-generic
<mlankhorst> apt-listchanges perhaps
<mlankhorst> but all changelogs are installed in /usr/share/doc/$(package)/changelog.gz
<Prf_Jakob> sigh that wasn't very informative :-/
<Prf_Jakob> not that you said, but was in the change log.
<tseliot> Prf_Jakob: maybe have a look at the git branch and see what's changed?
<Prf_Jakob> where is that located?
<Prf_Jakob> the problem is that you guys backported a function which messes up our standalone driver build, the problem is that the function is a C function and not a macro so I can't just #ifndef it away.
<tseliot> Prf_Jakob: git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git or change it to whatever ubuntu release you need
<Prf_Jakob> thanks
<Prf_Jakob> oh thats the entire kernel tree right?
<tseliot> yep
<Prf_Jakob> any web page for that repo?
<Prf_Jakob> while I wait for it to download?
<Prf_Jakob> ah got it
<tseliot> Prf_Jakob: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=summary
<Prf_Jakob> thanks
<hyperair> besides logging, what does Xorg do that involves the disk?
<hyperair> okay, interesting. latencytop says compiz blocks marking inode dirty, and i find it constantly logging crap to xsession-errors
<hyperair> Thu May 30 23:12:18 SGT 2013 compiz (opengl) - Error: FBO is incomplete: GL::FRAMEBUFFER_INCOMPLETE_ATTACHMENT (0x8cd6)
<hyperair> disabling the framebuffer object option in the opengl option solved thing.s. \o/
#ubuntu-x 2013-05-31
<brendand> mlankhorst, tseliot suggested i ask you about xinput stuff, is that okay?
<Sarvatt> urg, really shouldn't have updated precise to mesa 9.2 since it requires a 3.6 to use i965 
#ubuntu-x 2013-06-01
<jcristau> Sarvatt: what's that about requiring 3.6?
#ubuntu-x 2013-06-02
<Dandel> the piglit builders are broken ( again)... the template patch needs updating for piglit-summary-html.py
<Dandel> Sarvatt, you around?
#ubuntu-x 2014-05-27
<cwillu> Question:  the xorg-edgers ppa doesn't have packages for lucid anymore, does that sound about right?
<cwillu> I ask, because the non-existence of a packages list for that release makes ppa-purge fail to function
<mlankhorst> possibly, do you still have a lucid ppa somewhere?
<cwillu> I still have several machines running lucid, which have had edgers on them
<cwillu> on this latest one, it appears that addng the ppa, changing it to point to precise, doing an apt-get update, and then ppa-purging'ing it works
<cwillu> at which point, do-release-update stop failing to calculate an upgrade :)_
<cwillu> mlankhorst, ^
<cwillu> it appears that all that's actually needed is the Packages list
<cwillu> (the last time I tried this, I just ended up doing a fresh install and manually moving pieces from the old /etc and similar into place, but that was an ordeal that I'd imagine most people in my situation (including myself today, and myself in the future :p) would like to avoid
<cwillu> I'm heading to bed, but I'll read pm
<cwillu> ...
<cwillu> read pm's sent to cwillu_at_work, which is online, but not in this channel
<mlankhorst> no idea
<mlankhorst> I never tried lucid before, tbh
<cwillu> I'm mostly just reporting that the removal of the ppa packages for lucid breaks do-release-upgrade, which is still supported for server installs, and is getting close to retirement, so I'd expect this to start cropping up more
<tjaalton> edgers isn't supposed to be used on servers..
<cwillu> sometimes you just need to bring up the display
<tjaalton> and you need edgers for that? doubtful
<cwillu> it's not core to the function, and so an xorg breakage isn't terribly risky
<cwillu> um
<cwillu> yes, rather often you do
<cwillu> or did
<mlankhorst> yes lucid is still supported, but that ppa is not supported :p
<cwillu> sure
<cwillu> I'm not saying that it should be supported
<cwillu> I'm just saying that, having used it, do-release-upgrade fails, and ppa-purge also fails, so getting back to a supported environment is tricky
<tjaalton> manual purge or a reinstall
<cwillu> if you don't care, that's fine
<cwillu> (if a little surprising)
<tjaalton> eh
<tjaalton> there's nothing to do
<cwillu> "on this latest one, it appears that addng the ppa, changing it to point to precise, doing an apt-get update, and then ppa-purging'ing it works"
<cwillu> ppa-purge just needs a package list
<cwillu> doesn't need an actual working ppa
<tjaalton> so you're asking someone to provide that, by guessing what it might have had at the time?
<tjaalton> lucid desktop was EOL a year ago, that's probably when the ppa got cleaned up
<cwillu> I'm mentioning that a Packages file that approximately matches what was there is all that's necessary to get it to work, in case anyone else runs into this
<cwillu> yes, a guess
<tjaalton> no edgers maintainers present atm anyway
<cwillu> anyways, g'night
<mlankhorst>  launchpad is RAOF's happy place
<tseliot> :)
<tjaalton> que?
<jcristau> i don't suppose there's a way to get http://lists.x.org/archives/xorg-devel/2013-February/035349.html into precise-updates?
<jcristau> mlankhorst: ^
<mlankhorst> what xorg-server exactly ? :p
<mlankhorst> and if it's in newer, can't you grab xserver-xorg-lts-saucy or something?
<mlankhorst> jcristau: /\
<jcristau> mlankhorst: well
<jcristau> i suppose i could, but that's a rather bigger upgrade for a single fix
<jcristau> so at that point i'd just upgrade to a newer release altogether
<mlankhorst> there's trusty :-)
<mlankhorst> jcristau: the xorg-server in precise is a mess, especially in input
#ubuntu-x 2014-05-29
<bdmurray> fyi - bug 1324589
<ubottu> bug 1324589 in xdiagnose (Ubuntu) "crashes reported by apport-gpu-error-intel.py are missing the package version" [Undecided,New] https://launchpad.net/bugs/1324589
<mlankhorst> bdmurray: do we even report them for stable versions? I thought we disabled that script right before release
<bdmurray> mlankhorst: disabled which script?
#ubuntu-x 2014-05-30
<mlankhorst> bdmurray: the udev handler is not installed
<bdmurray> mlankhorst: I see that it is not installed for Trusty. Why is that?
<mlankhorst> always disabled on release, to prevent data from being leaked
<bdmurray> there is sensitive data here? https://errors.ubuntu.com/oops/b65606bc-e4a2-11e3-a166-fa163e707a72
<mlankhorst> in practice, probably not, but in theory..
<bdmurray> mlankhorst: well crashes are reported from supported (not development) releases to errors and I thought the same thing would be useful for the gpu errors. if not then close the bug as invalid or won't fix.
<tjaalton> maybe the handler could be split to put the trigger-happy "sensitive" part in a separate thing that's removed before release
<tjaalton> hmm wait
<bdmurray> what are the sensitive parts? whoopsie doesn't include all the data from apport
<tjaalton> it still reports these gpu lockups?
<bdmurray> no, they are not reported from "supported" / released releases
<tjaalton> right this was from utopic
<bdmurray> I'm suggesting that it might be useful to send them to errors
<bdmurray> for Trusty
<bdmurray> Well, I mean errors is for collecting information from development and supported releases so you might want to send the gpu errors there for the LTS
<tjaalton> well, most of these tend to come from "hangs" the user doesn't notice at all, the gpu recovers itself
<bdmurray> If it isn't interesting data for fixing them for the LTS then don't send them.
<tjaalton> it shouldn't send anything for the lts, since the handler is disabled
<tjaalton> the fixes will arrive in point-releases, we don't do much driver sru's anyway
<tjaalton> since it's tedious, can't update versions
<tjaalton> not that -intel has had a stable release since some time last year
<tjaalton> guess it'll be replaced with -modesetting & xserver glamor anyway
<bdmurray> I understand the handler is disabled, I'm suggesting that you might enable it and if you do then should include the fix I made to xdiagnose.
<tjaalton> right
<mlankhorst> sure
#ubuntu-x 2015-05-28
<ricotz> Sarvatt, i hope you don't care while I am playing it safe with pulling mesa from 10.6 branch
<ricotz> care/mind
<Sarvatt> ricotz: not at all, prefer that actually :D
<ricotz> it somehow made sense since wily should target it
#ubuntu-x 2016-06-03
<achiang> hello, i was trying to fix my trackpad in 14.04 and it seems i broke it worse
<achiang> i dropped in a 50-synaptics.conf into /usr/share/X11/xorg.conf.d/
<achiang> it didn't have the effect that i wanted, namely it killed my trackpad
<achiang> so I removed the file and rebooted
<achiang> but now the trackpad still refuses to boot
<achiang> question is: does X cache settings somewhere?
<achiang> sorry, trackpad refuses to work, not boot
<tjaalton> no
<achiang> hm, then my only other theory is that i flipped some hw register or something, and now it's persisten?
<achiang> the attempted changes, that is
<achiang> does that sound plausible?
<tjaalton> not to me
<achiang> hm
<achiang> fwiw, i was experiencing the symptoms here, and dropped in the linked conf file -- http://askubuntu.com/questions/657258/chrome-two-finger-scroll-then-right-clicks
<achiang> any ideas on how to recover would be greatly appreciated...
<achiang> clickpad still responds to clicks, but can't move the cursor around
<tjaalton> shutdown, remove battery and wait for a bit?
<achiang> ha. well, it's an xps13 so battery seems not removable
<achiang> this is interesting... output from xinput list
<achiang> achiang@twiga:~$ xinput list
<achiang> â¡ Virtual core pointer                    	id=2	[master pointer  (3)]
<achiang> â   â³ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
<achiang> â   â³ ELAN Touchscreen                        	id=10	[slave  pointer  (2)]
<achiang> â   â³ DLL0665:01 06CB:76AD                    	id=12	[slave  pointer  (2)]
<achiang> â   â³ SynPS/2 Synaptics TouchPad              	id=14	[slave  pointer  (2)]
<achiang> â£ Virtual core keyboard                   	id=3	[master keyboard (2)]
<achiang> looks like i have 2 touchpads configured? 
<achiang> maybe the 06CB:76AD device is conflicting with the TouchPad device?
<tjaalton> i don't know
<tseliot> isn't one a touchscreen?
<achiang> tseliot: the ELAN device is a touchscreen
<achiang> the other two devices are both touchpads, I think
<tseliot> messed up udev rules?
<tseliot> if you change a property on one touchpad, what happens to the other one?
<tseliot> (assuming they are the same device)
<tjaalton> did you muck with bios settings?
<tjaalton> or change the kernel
<Sarvatt> achiang: did you install x-x-i-libinput at any point in time?
<tjaalton> the only proper driver ;)
<Sarvatt> unless you want to adjust settings in a gui
<Sarvatt> that isnt gnome not in ubuntu yet :D
<tjaalton> it's perfect, no need for that
<jcastro> tseliot: those fixes for getting the krita snap to work, will those also make their way into the ppa drivers?
<tseliot> jcastro: good point, mamarley, ricotz, the fix for LP: ##1588192 is in both yakkety and xenial-proposed. 361 and 340 are available. I haven't finished my work on 304 yet.
<mamarley> I guess it also needs to be forward-ported to 367 then.
<mamarley> Ooh, reported by SABDFL himself.
<ricotz> tseliot, I see
<mamarley> ricotz: I am on lunch break so I can go ahead and do 367 now.
<mamarley> Did you want 364 done too?
<ricotz> mamarley, go ahead :), I am busy currently
<mamarley> OK
<tseliot> thanks
<mamarley> Argh, lots of failed hunks and fuzz.
 * mamarley loves fixing patches.
<mamarley> tseliot: I notice that the patch does not appear to have any support for i386 on amd64 systems.  Is that intentional?
<mamarley> (Can 32-bit snaps even be installed on 64-bit systems?)
<tseliot> mamarley: I'm not really sure, as I'm not familiar with snaps. mvo wrote the code
<ricotz> of course this only applies to xenial/yakkety
<mamarley> Correct.
<tseliot> yep
<tseliot> snaps are only for >= xenial
<mamarley> tseliot: I get all sorts of "Could not find "var-lib-snapd-lib-gl.mount" in the /lib/systemd/system directory of nvidia-367-dev" when building.  Is that to be expected?
<tseliot> mamarley: can I see the full output, please?
<tseliot> 361 built fine here. I haven't tried 367 yet
<mamarley> tseliot: It build fine, but displays a bunch of new warnings.  http://paste.ubuntu.com/16952010/
<tseliot> mamarley: I think dh_systemd is calling the same thing on all the packages, whereas it should only be nvidia-367
<tseliot> no -dev, etc.
<mamarley> tseliot: Did it not display the same warning on 361?
<tseliot> mamarley: yes, it did it even for transitional packages
<tseliot> that should be easily fixed
<mamarley> OK, so it isn't my refresh of the patch causing the problem.
<tseliot> nope
<mamarley> I don't know how to fix it though.
<mamarley> tseliot: Should I just leave it for now since the same patch has already been uploaded into the main respository?
<tseliot> mamarley: yes, go with what we have right now. I'll fix it myself next week
<mamarley> OK
<mamarley> ricotz: I have compiled and tested 367.18 with the snappy patch.  Any objection to me copying that to the main PPA?  I also have nvidia-settings 367 that I never copied.
<mamarley> I got 364 patched too, but there is some old orig.tar.gz junk in my staging PPA that is preventing it from compiling unless I do a full source upload, so I propose to upload that directly to the main PPA.
<mamarley> Nevermind, it was a dummy mistake on my part.  The 364 build should work this time.
<mamarley> ricotz: OK, everything is published now.
<ricotz> mamarley, checked and copied :)
#ubuntu-x 2016-06-04
<soee> mamarley: what has changes in 367.18-0ubuntu0~gpu16.04.2 ?
<mamarley> soee: https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa/+sourcepub/6485543/+listing-archive-extra
<soee> i see :) but not my level of knowledge to know what it does exactly :D
<mamarley> It fixes a bug that causes OpenGL not to work when using snappy packages.
<mamarley> If you aren't using Snappy, it is functionally no different from ~gpu16.04.1.
<soee> mamarley: ok, thank you
#ubuntu-x 2016-06-05
<mamarley> ricotz: Because of https://bugs.launchpad.net/bugs/1589006, I reverted the snappy patch in the nvidia-364 and nvidia-367 packages.  (It was breaking X for a number of people.)  I will answer all the emails from people complaining about the bug when attempting to upgrade.
<ubottu> Launchpad bug 1589006 in snapd (Ubuntu) "Failed unmounting Mount unit for nvidia support in snappy" [Critical,Confirmed]
<mamarley> OK, I have responded to everyone who emailed the team so far.
<ricotz> mamarley, hi, I see :\
<ricotz> mamarley, any reports for 361?
<mamarley> ricotz: Yes, but those are going to the bug report for the official archive package.  That was what I linked above.
<mamarley> Those are from people who are using the -proposed repository, which they aren't really supposed to be doing.
<ricotz> mamarley, ah alright, I don't have snap installed here
<ricotz> I was wondering why I am not seeing problems
<mamarley> ricotz: Yeah, it doesn't always happen, which is weird.  I don't have snapd installed on any of my systems and it didn't affect my desktop, but it did affect my laptop.
<mamarley> (At least the uninstall problem.  It didn't prevent X from starting on any of my systems.)
<ricotz> ok
<ricotz> mamarley, reverting the change doesnt solve the upgrade problem though which was reported
<mamarley> Correct, which is why I am responding to user emails and telling them how to work around the problem.
<ricotz> good
<mamarley> There is actually a secondary problem that seems to be occurring in a number of cases as well.  The command to start or stop the service is getting executed from the pre/post inst/rm scripts from a different package from the one that actually has the file, so they are getting errors about the unit not being loaded.
#ubuntu-x 2018-05-28
<tjaalton> xserver 1.20 uploaded to cosmic
<ricotz> nice :)
<tjaalton> although now I realized nvidia-340 doesn't support it yet
<tjaalton> iirc
<ricotz> tjaalton, correct, still there is no eta for it afaik, so imo for cosmic it should be fine
<tjaalton> well, it'll stay in proposed then
<mamarley> 1.20 is unusable on one of my systems with Intel graphics due to https://bugs.freedesktop.org/show_bug.cgi?id=105812.
<tjaalton> good to konw
<tjaalton> know
<ubottu> Freedesktop bug 105812 in Driver/modesetting "Multimonitor does not work correctly with Modesetting driver on Intel hardware with xorg-server 1.19.99.902" [Major,New]
#ubuntu-x 2018-05-30
<tseliot> ricotz, mamarley: I downloaded the tarballs for 390.59, but I get a warning when extracting, and the amd64 installer is extracted in the main directory, not in "amd64" https://paste.ubuntu.com/p/39q9DBytcH/
<tseliot> I'm going to create a new tarball
<tseliot> Note: you can download and create the tarballs with "debian/rules get-orig-source"
<mamarley> tseliot: Cool, where does that get the .run files for the tarball?
<tseliot> mamarley: yep, it downloads the installers, creates the directories and the tarballs. You only have to move the tarballs out of the main directory, when you're done.
<mamarley> tseliot: Is there any way to do that for drivers not downloaded from the main download site, such as Vulkan development drivers or drivers extracted from the CUDA installer?
<tseliot> mamarley: if you change the urls and the names in debian/rules.defs, I think things will work
<mamarley> OK, thanks!  That is definitely easier than manually creating the tarballs, which is what I had been doing.
<tseliot> :)
<mamarley> And less error-prone too, because I somehow screwed up the 390.59 one apparently.  I'm still not sure how it could build if it was extracted to the wrong directory though.
<ricotz> tseliot, sorry for missing that, but the tarball is not wrong, having a subfolder in them is what is confusing since they are dropped on extracting by dpkg
<ricotz> the suffix e.g. -amd64 defines the resulting destination directory inside the source-folder
<ricotz> ... if there is only one file in the archive
<tseliot> ricotz: I know it's kind of confusing
<ricotz> tseliot, better don't "prepend" the subfolder while creating the tarball
<ricotz> those warnings has nothing to do with it, I assume the archives are generated by e.g. file-roller and not plain tar
<tseliot> ricotz: I think I took the get-orig-source functions from Debian, and I tweaked them a bit
#ubuntu-x 2020-05-27
<ricotz> tjaalton, hi :), did you ran into something like that https://www.reddit.com/r/pop_os/comments/g6vvac/dell_xps_and_intel_iris_plus_graphics_640_slow_ui/
<ricotz> looks like I am seeing this on "XPS 13 9350" with Iris 540
<tjaalton> I don't have that hw
<ricotz> and you didn't came across recent reports?
<tjaalton> not that I remember
<ricotz> not sure if this is some incarnation https://gitlab.freedesktop.org/mesa/mesa/-/issues/2891
<tjaalton> force i965 and you'll see
#ubuntu-x 2020-05-28
<ricotz> tjaalton, I decided to reinstall the system, the cpu didn't reclock properly, it might be some mess up of powertop
<tjaalton> okay
