#ubuntu-x 2007-05-21
<ubotu> New bug: #44586 in xserver-xorg-video-ati (main) "screen refresh not consistent, SDL suffers" [Medium,Unconfirmed]  https://launchpad.net/bugs/44586
<ubotu> New bug: #115700 in linux-restricted-modules-2.6.20 (restricted) "Nvidia proprietary drivers for nvidia FX 5500 result in black screen" [Undecided,Needs info]  https://launchpad.net/bugs/115700
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #115968 in xorg (main) "Cannot setup resolution higher than 1024x768 on laptop with ATI Mobility Radeon card" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115968
<ubotu> New bug: #115609 in mesa (main) "glxinfo crashes X with SiS661GX graphics" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115609
<ubotu> New bug: #115220 in xorg (main) "feisty fresh install fails to setup 1440x900 nvidia" [Undecided,Needs info]  https://launchpad.net/bugs/115220
<ubotu> New bug: #115908 in Ubuntu "Nvidia 7600gt and Edubuntu screen resolution (dup-of: 91292)" [Undecided,Rejected]  https://launchpad.net/bugs/115908
<bryce> tepsipakki: do you know if it's possible to have both -intel and -i810 installed at the same time?
<jcristau> -intel has i810_drv.so symlinked from intel_drv.so (and similarly for the manpage), but if you remove those symlinks it should be possible
<bryce> mdz thinks it would be useful if we distributed both -intel and -i810 so users could test -intel
<bryce> what do you think?
<tepsipakki> I'd say just dump -i810 :)
<tepsipakki> jcristau: do you recall what hardware had problems with -intel?
<ubotu> New bug: #116037 in compiz (main) "[apport]  compiz.real crashed with SIGSEGV in savageGetLock() (dup-of: 81889)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116037
<tepsipakki> seems that fedora ships both 1.6.5 and 2.0.0
<bryce> interesting
* Starting logfile irclogs/ubuntu-x.log
<jcristau> tepsipakki: mostly i830 and i855, from what i saw on bugzilla
<jcristau> tepsipakki: part of it is fixed in git
<tepsipakki> ok, I remembered i830. There hasn't been talk about a point-release yet..
<ubotu> New bug: #114941 in xorg (main) "xorg.conf gets (wrongly) overwritten after hardware crash " [Undecided,Unconfirmed]  https://launchpad.net/bugs/114941
<ubotu> New bug: #114880 in xorg (main) "after running normally kubuntu started up on a very low resolution" [Undecided,Needs info]  https://launchpad.net/bugs/114880
<ubotu> New bug: #114762 in xorg (main) "Wrong protocol in xorg.conf for Microsoft Comfort Optical Mouse 3000" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114762
<ubotu> New bug: #114502 in mesa (main) "Simple GLX test program crashes" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114502
<ubotu> New bug: #47464 in xorg (main) "Failed to open device while starting any X program (dup-of: 42553)" [Medium,Needs info]  https://launchpad.net/bugs/47464
#ubuntu-x 2007-05-22
<mvo_> tepsipakki: do you mind if I upload xrandr 1.2?
<mvo_> the cli thing
<tepsipakki> mvo: it would be replaced soon :)
<mvo_> with what?
<tepsipakki> split packages from debian
<mvo_> nice. then we can merge them from debian?
<mvo_> or sync even
<mvo_> how long will this take, what do you think?
<tepsipakki> x11{-apps,-utils,-xfs-utils,-xkb-utils,-xserver-utils}
<tepsipakki> yep
<tepsipakki> that's the plan
<tepsipakki> I've just tested upgrades
<tepsipakki> with feisty
<tepsipakki> oh, they will enter experimental this week
<tepsipakki> I guess we can sync them from there, then adjust xorg a bit
<mvo_> ok, great
<tepsipakki> or wait until they are in unstable
<ubotu> New bug: #116207 in xserver-xorg-video-intel (universe) "Macbook's Tv out doesn't work" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116207
<ubotu> New bug: #67188 in xkeyboard-config (main) ""Error activating XKB configuration." - Requires manual xorg.conf editing" [High,Confirmed]  https://launchpad.net/bugs/67188
<ubotu> New bug: #116250 in xrdb (main) "[apport]  xrdb crashed with SIGFPE" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116250
<ubotu> New bug: #116239 in xorg (main) "X crash at startup with IBM T22/savage s3" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116239
<ubotu> New bug: #116251 in xserver-xorg-input-synaptics (main) "Can not switch off synaptics touchpad" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116251
<ubotu> New bug: #53206 in xkeyboard-config (main) "In xorg.conf the "XkbModel" setting for Japanese jp106 keyboard is wrong" [Medium,Unconfirmed]  https://launchpad.net/bugs/53206
<ubotu> New bug: #53794 in xserver-xorg-input-keyboard (main) "ctrl+shift+(X) combos not working at all" [Undecided,Needs info]  https://launchpad.net/bugs/53794
<ubotu> New bug: #116254 in xorg (main) "Xorg will not use restricted Nvidia driver" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116254
<ubotu> New bug: #116268 in xorg (main) "X.org 7.2 fails to load with fglrx/ati drivers with Radeon 9200" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116268
<kylem> tepsipakki, bryce, i just uploaded -i810 and -intel modified so they can co-exist.
<bryce> kylem: cool thanks
<kylem> will push a new xorg metapackage that installs both with xserver-xorg-video-all once they're in the archive
<bryce> kylem: will it be possible to have both installed at the same time?
<kylem> yeah.
<bryce> awesome
<kylem> then i can crank discover-data and take a nap.
<kylem> :)
<bryce> hehe
* kylem still feels jetlagged.
<bryce> really?  when did you get back?
<kylem> last week.
<kylem>  :\
<bryce> yow
<bryce> I didn't have a problem with jetlag, but I caught a headcold on the flight home.  Sucks to be me.  Sick twice within a week.
<kylem> yow dude.
<ubotu> New bug: #112198 in linux-restricted-modules-2.6.20 (restricted) "Problem when changing user" [Medium,Unconfirmed]  https://launchpad.net/bugs/112198
#ubuntu-x 2007-05-23
<ubotu> New bug: #113754 in xorg (main) "xserver crashes when amarok wants to popup" [Undecided,Needs info]  https://launchpad.net/bugs/113754
<ubotu> New bug: #116345 in xorg-server (main) "[apport]  Xorg crashed with SIGSEGV" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116345
<ubotu> New bug: #115838 in linux-restricted-modules-2.6.20 (restricted) "Change user on nvidia does not work" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115838
<ubotu> New bug: #116054 in xorg (main) "low display resolution" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116054
<crimsun> As the last person who touched libxcb for feisty, shall we simply sync from Debian unstable?  Martin's note for 1.0-1.1ubuntu1 was that we should drop the reversed-logic patch ("Setting LIBXCB_NO_SLOPPY_LOCK will enable the strict behaviour. This should be dropped right at the opening of Feisty+1.")
<tepsipakki> yep, maybe so. Currently though, libx11 isn't built against libxcb
<crimsun> ok, I have filed the sync request and will sub u-a.
<tepsipakki> xcb 1.1 should fix some performance regressions that we found, so when that is released libx11 should be built against xcb, if not earlier
<crimsun> thanks :-)
<ubotu> New bug: #116365 in xorg-server (main) "X SERVER RESTART" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116365
<keescook> bryce_: here's another bug to add to your radar: 78282.  I still haven't figured out how to apply the recommended fix as a patch at compile-time
<bryce_> kees thanks, I've subscribed to this; let me know if there's anything I should do
<keescook> bryce_: if you manage to figure out how to solve it, I'm all ears.  :)
<bryce_> sounds like the users worked out a solution as per Isaac Salsberg  said on 2007-05-08
<keescook> right, but it's an after-install solution.  I'd like to have the package compiled with that by default, so that it "just works" again.
<bryce_> I guess the next question is if any of those fixes interfere with other things
<ubotu> New bug: #116471 in xserver-xorg-video-ati (main) "ATI Radeon 9200 AGP RV280 Feisty Xorg7.2  3D Preformance  Degraded" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116471
<ubotu> New bug: #113904 in xorg (main) "install ubuntu on pc hp dv4000 display problem" [Undecided,Needs info]  https://launchpad.net/bugs/113904
<ubotu> New bug: #116510 in linux-restricted-modules-2.6.20 (restricted) "Display problem" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116510
<ubotu> New bug: #116514 in xserver-xorg-video-intel (main) "Screen extends beyond physical edges of monitor" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116514
#ubuntu-x 2007-05-24
<ubotu> New bug: #116533 in xserver-xorg-video-ati (main) "X green pixel corruption " [Undecided,Unconfirmed]  https://launchpad.net/bugs/116533
<ubotu> New bug: #30969 in xorg (main) "monitor goes to standby when playing a movie in totem fullscreen" [Undecided,Unconfirmed]  https://launchpad.net/bugs/30969
<ubotu> New bug: #116480 in nvidia-settings (restricted) "Can only change resolution through nvidia-settings (dup-of: 92599)" [Undecided,Rejected]  https://launchpad.net/bugs/116480
<ubotu> New bug: #42322 in linux-restricted-modules-2.6.15 (restricted) "VertRefresh is not read in 'xorg.conf" [Medium,Needs info]  https://launchpad.net/bugs/42322
<ubotu> New bug: #116568 in linux-restricted-modules-2.6.17 (restricted) "SD Card Reader does not work" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116568
<ubotu> New bug: #74170 in xserver-xorg-video-intel (main) "Change MAC address locks up Ubuntu after hibernate" [Undecided,Unconfirmed]  https://launchpad.net/bugs/74170
<ubotu> New bug: #116605 in mesa (main) "Have no idea what crashed. Newbie to Linux." [Undecided,Unconfirmed]  https://launchpad.net/bugs/116605
* Starting logfile irclogs/ubuntu-x.log
<bryce> heya guys
<tepsipakki> hey bryce 
<kylem> hey dudes.
<ubotu> New bug: #47552 in xorg (main) "Wrong Screen Resolution for External Monitor" [Medium,Needs info]  https://launchpad.net/bugs/47552
#ubuntu-x 2007-05-25
<ubotu> New bug: #24955 in xorg (main) "xserver-xorg: undefined colors render important apps unusable" [High,Rejected]  https://launchpad.net/bugs/24955
<ubotu> New bug: #116768 in linux-restricted-modules-2.6.20 (restricted) "nvidia-glx should depend on it's kernel version" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116768
<ubotu> New bug: #86142 in xserver-xorg-video-nv (main) "Jerky rendering in Epiphany (herd4)" [Low,Unconfirmed]  https://launchpad.net/bugs/86142
<ubotu> New bug: #116793 in xserver-xorg-video-intel (main) "3d applications with compiz enabled are not usable (Intel 945GM GPU - feisty)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116793
<ubotu> New bug: #106836 in xorg (main) "blinking screen when on launchpad.net" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106836
<kylem> bryce/timo, working on merge of mesa 6.5.3 from experimenta (thank jcristau)
<jcristau> :)
<kylem> then i need to bisect and find which patches fix fullscreen gl on i965 for feisty 6.5.2 *cry*
<ubotu> New bug: #85844 in linux-restricted-modules-2.6.20 (restricted) "fglrx power saving" [Undecided,Rejected]  https://launchpad.net/bugs/85844
<kylem> tepsipakki, why'd we remove lesstif-dev from build-deps in mesa?
<ubotu> New bug: #116808 in xserver-xorg-video-intel (main) "White boxes instead of shadows on Intel 945 (-intel driver)" [Critical,Unconfirmed]  https://launchpad.net/bugs/116808
<bryce> kylem: great
<jcristau> kylem: maybe because you didn't build libGLw?
<kylem> aha.
<kylem> ok. that explains that.
<kylem> jcristau, thanks!
<jcristau> np
<kylem> (i was trying to figure out how a few changelog pieces fit together...)
<ubotu> New bug: #43317 in linux-restricted-modules-2.6.15 (restricted) "xvidtune doesn't work with latest nvidia-glx" [Medium,Needs info]  https://launchpad.net/bugs/43317
<keescook> bryce: appres 1.0.1 sponsored.  :)
<bryce> great thanks
<bryce> I'm almost done with beforelight, just need to test the deb
<keescook> cool.  I'm morbidly curious to know what caused the weird paths...
<bryce> yup, I think I figured it out, but would appreciate your doublechecking on it
<bryce> ok, you got mail
<ubotu> New bug: #24059 in linux-restricted-modules-2.6.15 (restricted) "hyperthreading smp not supported on NVIDA6610XL with kernel 2.6.12-9-686-smp" [Medium,Rejected]  https://launchpad.net/bugs/24059
<ubotu> New bug: #25954 in xserver-xorg-input-keyboard (main) "random extra keys are unsupported" [Medium,Rejected]  https://launchpad.net/bugs/25954
<ubotu> New bug: #26538 in xserver-xorg-video-sis (main) "Screen corruption and crashes with hardware acceleration" [Medium,Rejected]  https://launchpad.net/bugs/26538
<bryce> kylem: do you know if the i810 driver on feisty supports custom modelines?
<keescook> bryce: nice work tracking down that path bug.  :)  did your patch fix it?  (I would have expected a patch to Makefile.in too)
<keescook> you can examine the debian contents with "dpkg-deb -c PKG.deb"
<bryce> it seemed to prevent the creation of the extra subdirs for me, but I wasn't 100% sure
<bryce> I didn't know if Makefile.in needed to be patched, or if that would be autogenerated
<bryce> ok cool, I was wondering how to do that
<ubotu> New bug: #27421 in linux-source-2.6.15 (main) "Logitech RX300 mouse extra-buttons without kernel events" [Medium,Rejected]  https://launchpad.net/bugs/27421
<keescook> "automake" (usually run prior to tarball creation) makes Makefile.in from Makefile.am.  "configure" makes Makefile from Makefile.in, so in this case, looking at the debian/rules, it (correctly) doesn't rerun automake, so I think Makefile.in will need patching too.
<bryce> ok yeah
<bryce> I had initially tested with Makefile.in (and Makefile) corrected.  I tried to back out those changes to be sure
<keescook> cool; I figured the dpkg-deb investigation tool was the missing bit.  also, the build log dumps a similar report (which is where I noticed it)
<bryce> yeah I'm building a checklist to go through for these packages
<bryce> in the future I hope to scriptify some of the steps, so tools that allow for detecting issues like these are handy to know about
<jcristau> 'debdiff old.deb new.deb' is useful too, when you want to check changes in the package contents
<keescook> bryce: also, check for useless whitespace (empty lines in 00list, or ^ +$
<keescook> in changelogs, etc)
<tepsipakki> gah, I didn't have the time to push the x11* changes
<tepsipakki> hey dudes, I'm drunk
<bryce> heh, congrats
<tepsipakki> bryce: whoa
<tepsipakki> anyway, I'll push the changes tomorrow
<bryce> okidokie
<tepsipakki> so, hopefully we all have a syncable apps-suite by Monday :)
<bryce> what will that include?
<bryce> (so I can avoid duplicating efforts)
<tepsipakki> all the numerous apps
<tepsipakki> x*
<tepsipakki> :)
<bryce> ah, ok, I'm working on non-x* ones
<tepsipakki> doing xrandr merge was ok, I understood that there was an alpha release coming soon
<tepsipakki> they should be ok, but I'm wary about it
<bryce> it's good practice for me in any case
<tepsipakki> of course
<jcristau> tepsipakki: the packages will be in NEW for a while
<jcristau> hopefully not too long
<tepsipakki> jcristau: yeah
<tepsipakki> today was too busy for me to commit the changes
<tepsipakki> there could be some patches missing, but packaging itself should be _perfect_ :)
<tepsipakki> (patches from ubuntu
<tepsipakki> +)
<tepsipakki> umm
<tepsipakki> ignore me :)
<bryce> never!
#ubuntu-x 2007-05-26
<tepsipakki> hah!
<tepsipakki> the point being, that the packaging itself should be fine, but some of the ubuntu individual packages _might_ contain useful patches :)
<tepsipakki> but that's hypothetical :)
<tepsipakki> (I have to leave this terminal.... now)
<jcristau> bryce: your appres upload has the xrandr git repo in XS-Vcs-* :)
<bryce> whoops
<bryce> damn cut-n-paste
<keescook> doh.  I missed that totally.  whoops
<bryce> keescook: ok just finished 'bitmap'
<keescook> yay!
<keescook> bryce: I think dch ate your changelog.  take a look at your debdiff: the changelog looks unsaved, and the entire dch tempfile was added.  oops!
<kylem> cool.
<kylem> new mesa fixes graphics on my i965GM.
<keescook> nice!
* kylem wonders why he's still working.
<keescook> you're dedicated?
<kylem> something like that. ;-)
<bryce> hmm, has there been a change to launchpad?  today I'm not able to set status on displayconfig-gtk bugs, whereas the other day I was
<keescook> bryce: I think they killed cookies again.  are you logged in?  (top right corner)
<bryce> no I wasn't logged in
<keescook> bitmap: sponsored
<ubotu> New bug: #116960 in xorg-server (main) "???" [Undecided,Unconfirmed]  https://launchpad.net/bugs/116960
<tepsipakki> brrp, where were we..
<tepsipakki> x11-* changes pushed, I'm off ->
<ubotu> New bug: #108616 in xkeyboard-config (main) "Some keys don't work in gedit with "France" keyboard layout" [Low,Unconfirmed]  https://launchpad.net/bugs/108616
<kylem> ok, mesa is uplaoded.
<jcristau> kylem: 6.5.3?
<kylem> yeah.
<jcristau> you'll have to patch the server then
<kylem> oh?
<kylem> it's working fine for me.
<jcristau> it won't build
<kylem> ah, well, cross that bridge when we come to it.
<jcristau> there's a reason it's in experimental :)
<kylem> i suppose i can fix that first.
<kylem> alright, i think i've got that fixed.
<kylem> jcristau, what's the canonical way to rerun autogen.sh for this package? should it just go in the .diff.gz or is there some way to run it and make a patch?
<kylem> nm, found it.
<jcristau> usually we put the autotools-generated stuff directly in the diff.gz
<jcristau> 'debian/rules patch; autoreconf; fakeroot debian/rules clean' should work
<kylem> ok. i notice there's an xsfbs-autoreconf makefile though.
<jcristau> yeah, we don't use it
<kylem> ok.
<kylem> jcristau, god. this is brutal to fix, is debian interested in mesa 6.5.3 on server 1.3?
<jcristau> not sure... i think suse does that already
<jcristau> or some other distro
<jcristau> ah, found it on xorg@
<jcristau> http://svn.pardus.org.tr/pardus/devel/desktop/freedesktop/xorg/xorg-server/files/support_mesa6.5.3.patch
<kylem> oh. bumer.
<kylem> waste of amorning then.
<kylem> thanks.
<jcristau> the thread starts at http://lists.freedesktop.org/pipermail/xorg/2007-April/024284.html
<kylem> my fault for not being on xorg@ (just xorg-devel)
<kylem> oh wait, i am on that list. wtf.
<kylem> ah, it's just been expired out of my maildir.
<jcristau> a later thread points to http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages?view=rev&revision=22174
<jcristau> but it's probably the same
<kylem> yeah, they're basically where i'd be an hour from now
<kylem> my diffs are identical minus 2 missing additions to a .am
<kylem> bummer
#ubuntu-x 2007-05-27
<kylem> bryce, tepsipakki, ok, got Xserver building & working against mesa 6.5.3, mind if i upload both?
<bryce> kylem: please do
<bryce> kylem: what did you have to change with xserver?
<ubotu> New bug: #113003 in linux-restricted-modules-2.6.20 (restricted) "Playing video in totem causes high I/O wait time" [Low,Unconfirmed]  https://launchpad.net/bugs/113003
<ubotu> New bug: #107189 in xorg (main) "cairo gradient" [Low,Unconfirmed]  https://launchpad.net/bugs/107189
<ubotu> New bug: #37764 in xserver-xorg-video-ati (main) "no tv-out support with this driver" [Wishlist,Confirmed]  https://launchpad.net/bugs/37764
<ubotu> New bug: #108411 in xorg (main) "Totem - fullscreen doesn't work in Feisty" [Low,Rejected]  https://launchpad.net/bugs/108411
<ubotu> New bug: #117220 in xserver-xorg-video-intel (main) "X-Server crashes in Dual-Layout Mode" [Undecided,Unconfirmed]  https://launchpad.net/bugs/117220
<ubotu> New bug: #115275 in linux-source-2.6.20 (main) "Random kernel crash/freeze in Feisty (dup-of: 109643)" [Undecided,Rejected]  https://launchpad.net/bugs/115275
#ubuntu-x 2008-05-19
<jcristau> looks like someone tried to upload a package to ftp-master.d.o instead of a ppa
<tjaalton> jcristau: yes, most likely either bryce or tormod :)
<Q-FUNK> howdy
<Q-FUNK> is everyone already in Prague?
<Q-FUNK> tseliot: is bryce already on-site?
<tseliot> Q-FUNK: I don't know, I haven't seen him yet (I don't know what he looks like)
<tjaalton> yep, we are here :)
<Q-FUNK> tseliot: I was supposed to arrive today, but it looks like our budget only allows for two days abroad and it will have to be Wednesday and Thursday, for me.
<Q-FUNK> ah :)
<Q-FUNK> tjaalton: I just mailed you and bryce
<tseliot> tjaalton where are you???
<tjaalton> Q-FUNK: yes I saw it
<Q-FUNK> tjaalton: do those 2 days make sense to you, or would you recommend that I show up on other days?
<tjaalton> tseliot: platform session, integrating 3G
<tjaalton> Q-FUNK: I guess they work just fine
<tseliot> tjaalton: did you pinpoint your photo?
<tjaalton> tseliot: yes, it's on the wall since Friday :)
<tseliot> ok, great I'll have a look at it
<Q-FUNK> tjaalton: ok, then. see you guys tomorrow evening :)
<Q-FUNK> tjaalton: could you reply with your own mobile number, so that we can sync when I arrive at the hotel?
<tjaalton> Q-FUNK: cool, welcome :)
<Q-FUNK> tjaalton: if you see pitti, ogra and bryce, please tell them I should be there tomorrow evening.
 * Q-FUNK gets around to booking his flight and hotel
<tjaalton> sure, I will
<Q-FUNK> bryce_: :)
<bryce_> heya Q-FUNK
<tseliot> bryce_
<tseliot> hi
<bryce_> Q-FUNK: it looks like the two X sessions you'll be most interested in are tues/wed, but there's also sessions thurs and fri
<Q-FUNK> bryce_: yes, the X configurator gui is on friday
<bryce_> Q-FUNK: yeah I think that won't touch on particular drivers
<Q-FUNK> bryce_: but never mind that. our investor just approved me spending the whole week, in the end.  now, I just have to see if I can come on tonight's flight
<tjaalton> haha
<Q-FUNK> I also have to plan carefully, how many thincans I can stuff in my luggages
<tjaalton> that's the spirit
<Q-FUNK> indeed
<Q-FUNK> well, our CEO tends to be excessively careful on budget issues
<Q-FUNK> but talking to our investors can usually fix things, if there's a good reason
<Q-FUNK> in this case, they made me promise that we'd have a permanent solution to getting X support for the Geode fixed in both configless workstation case and in LTSP case.
<Q-FUNK> and also about getting the right contact info for getting our hardware certified as Ubuntu Inside, since our DBE63 will have mass media and come preinstalled.
<Q-FUNK> tjaalton: I've also been allowed to give you and bryce each a sample.
<tjaalton> Q-FUNK: oh, cool
<Q-FUNK> ogra already has one so, I think that we should be in a position to nail this bug down before 8.04.1 comes out
<bryce_> heya tseliot
<bryce_> Q-FUNK: excellent
<Q-FUNK> bryce_: the only thing is that I don't have any US PSU
<bryce_> my adapter needs something to do between uds's anyway ;-)
<tjaalton> tormod: did you accidentally upload the -ati snapshot to debian instead of your ppa? :)
<tjaalton> +try
<tjaalton> to :)
<tjaalton> ugh
<tjaalton> anyway, it was not accepted, so no harm doen
<tjaalton> damn
<tjaalton> *done
<tormod> tjaalton: when was that?
<tjaalton> tormod: last night
<tormod> hmm didn't notice that :) grepping my .history for dput doesn't indicate something like it...
<tormod> actually I haven't built any -ati since the 15th. someone else uploaded my package??
<tjaalton> must be, and that remains a mystery :)
<tormod> there's no logs, or notice of some kind? ip?
<tormod> someone thought Debian is lagging behind too much :)
<tjaalton> only the mail from the archive admin, and a dsa fingerprint
<rzr> it's me :)
<tjaalton> haha! :)
<rzr> i did that by mistake i think
<tjaalton> most likely so :)
<tormod> rzr: nice try :)
<rzr> well one one day maybe ...
<rzr> so you have snapshot builds into your ppa ?
<rzr> is this official ?
<tormod> non-official but got some fans I think
<tormod> it's not automatically uploaded, but the rest is
<rzr> bryce provided the intel snapshots
<tormod> (automatic)
<tormod> yes, I don't have Intel hw to test on-
<rzr> ati is what i am looking for
<tormod> I usually test before uploading
<tormod> what card?
<rzr> igp320m
<rzr> https://bugs.freedesktop.org/show_bug.cgi?id=12007
<ubottu> Freedesktop bug 12007 in Driver/Radeon "TV output garbled with RV280" [Normal,Assigned] 
<rzr> brb
<tormod> rzr: you can find the scripts on https://launchpad.net/~xorg-edgers
<rzr> the scripts to build snapshots ?
<tormod> rzr: yes, they grab from fd.o and debian git and make debs out of it
#ubuntu-x 2008-05-20
<Q-FUNK> honeeeyyyyyyyyyyy! I'm hooooooooooooooooome!
<Q-FUNK> bryce tjaalton  are you anywhere on the third floor near the stairs?
#ubuntu-x 2008-05-21
<Q-FUNK> ï»¿ok, pitti just approved the geode_pci_id patch
<Q-FUNK> ï»¿for the geode 2.9.0-1, pitti suggests making a 2.9.0-1ubuntu1 that closes the LP bug and to upload it to hardy-proposed
<Q-FUNK> re
<Q-FUNK> for -geode 2.9.0-1ubuntu1 changelog  -> hardy-proposed:  Closes LP 214119.
<ubottu> Launchpad bug 214119 in xserver-xorg-video-geode "[HARDY] Koolu W.E. (ION A603) does not detect higher resolution than 800x600" [High,Confirmed] https://launchpad.net/bugs/214119
<Q-FUNK> was #140051 released in hardy already or only in intrepid?
<tjaalton> bug 140051
<ubottu> Launchpad bug 140051 in xorg-server "xf86-video-amd: fails to autoconfigure" [High,Fix released] https://launchpad.net/bugs/140051
<tjaalton> judging by the changelog, it's fixed in hardy
<tjaalton> at least the server bits
<Q-FUNK> ok
<Q-FUNK> so we probably only need to import -geode 2.9.0 into hardy-proposed and the koolu bug will be history.
<tjaalton> right
<Q-FUNK> Bug 218202
<ubottu> Launchpad bug 218202 in numlockx "[hardy] numlockx does not turn num lock keyboard light on." [Low,Confirmed] https://launchpad.net/bugs/218202
<Q-FUNK> this probably only needs to be binary-NMU'ed to work again.
<Q-FUNK> who should I ask?
<seb128> there is no bin-NMU in ubuntu
<Q-FUNK> hm
<Q-FUNK> seb128: what alternative do we have to rebuild a package against the latest dependencie,s then?
<seb128> new source upload
<Q-FUNK> hmm ok
<Q-FUNK> bryce: where in the hotel is carmen santiago?
<Q-FUNK> seb128: au fait, t'es ou?  ca pourrait etre cool d'enfin se rencontrer :)
#ubuntu-x 2008-05-22
* You're now known as ubuntulog
<tjaalton> bryce: I'll be there before the input-hÃ³tplug session starts ;)
<tjaalton> F9 has a small patch for the server to disable keyboard-hotplug completely
<tjaalton> oh, and they actually have an fdi file for wacom as well
<tjaalton> so it might actually work
<pwnguin> ooh
<tjaalton> same goes to synaptics, but I bet there are those who still want to fiddle with the touchpad options
<pwnguin> that wallstreet journal review guy mentioned synaptics as lacking in 7.10
<tjaalton> hmm, I wonder if only adding the fdi file would make wacom work right OOTB
<tjaalton> pwnguin: link?
<pwnguin> did nobody else see this?
<pwnguin> http://online.wsj.com/public/article/SB118963540721725614-FnJzx_wcNlkRFOef4cgq74PBW3g_20080912.html
<tjaalton> ah
<tjaalton> so some devices are too sensitive with default settings. but SHMConfig will never be turned on ;)
<tjaalton> input properties is the way to go
<pwnguin> i wish i could remember the review where they complained that their midis didnt play
<tjaalton> hardly an xorg issue ;)
<pwnguin> of course, but still hilarious
<tjaalton> right
<tjaalton> I've only got one midi file, and that's the opening theme of Monkey Island :P
<pwnguin> interestingly, 8.,04 seems to have picked up support for .mod files. i just found a CD-R from ten years ago with a few of those and some windows emulators on it
<pwnguin> played just fine in totem
<tjaalton> yep, blame gstreamer
<tjaalton> hum, breakfast and then to corinthia ->
<pwnguin> nearly bedtime here
<tjaalton> west coast?
<pwnguin> central
<pwnguin> its 2am
<tjaalton> hah
<tjaalton> well, pretty normal I guess ;)
<pwnguin> i used to stay up till 5am. silly austrialians at that point on IRC
<tjaalton> heh
<tjaalton> oh god my jeans smell bad.. damn smokers at the bars
<tjaalton> but gotta run while they still server breakfast! ->
<tjaalton> uh, -r
<pwnguin> go!
<tjaalton> bryce_: where are you at?
<tjaalton> ok, see you already :)
<bryce_> tjaalton: http://wiki.archlinux.org/index.php/Xorg_input_hotplugging
<tjaalton> bryce_: thanks, reading..
<tjaalton> tseliot: so, do you have someting ready for split nvidia*?
<tjaalton> disco..
<tjaalton> the theme of the year
<tseliot> tjaalton: are you there?
<Ng> does the kernel modesetting stuff that's in development mean that switching to vt1 won't be necessary on suspend?
<tjaalton> tseliot: back
<jcristau> hrm. why do i get mail from xorg-edgers ppa?
<jcristau> looks like someone's trying to build xorg-server 2:1.4.1~git20080507-1 there
<jcristau> tormod: ^^
#ubuntu-x 2008-05-23
<tormod> jcristau: yes that's me, but I don't know why you get the mail
<tormod> maybe because I just uploaded without changing the changelog
<tormod> I signed it myself though
<jcristau> yeah well
<tormod> it fails to build glxdri.c anyway :(
<jcristau> it's not building against mesa 7.0.x
<jcristau> so yeah, that won't work
<tormod> I have mesa git in that ppa :)
<tormod> I guess my mesa is too new
<jcristau> thankfully it seems that's being sorted out upstream so we won't need mesa source to build the server
<tormod> hey wait you say 1.4.1 does not build with 7.0.x, but that's what you have in unstable, right?
<jcristau> i'm saying the buildds for your ppa are not using mesa 7.0.x
<tormod> ah sorry, I misinterpreted "it's not building" into it will not build :)
<tormod> hmm this is a nightmare. I guess the 1.4.99 would need all kind of deps
<tormod> I guess there is no intermediate version that would build with git mesa and still not need all other things changed :(
<jcristau> 1.4.99 needs rebuilt drivers, mainly
<tormod> all drivers, video input everything I guess?
<jcristau> yes
<tormod> there are not so many input drivers... do you think they just need a rebuild, or updates?
<tormod> well you have all that in experimental, right?
<tormod> no there's no -mouse nor -kbd in experimental, so is 1.4.99 installable?
<jcristau> it's not :)
<jcristau> there are packages at http://pkg-xorg.alioth.debian.org/7.4/ though
<tormod> aha. oh thanks! so that's the real experimental repo...
<tormod> so I could grab all your sources there and stuff them into the ppa...
<tormod> or can I just install them as-is together with git mesa?
<tormod> does the Packages.gz file mean I can use it as a repo?
<jcristau> yes, that should work
<jcristau> the server is built with --disable-glx --disable-dri --disable-dri2, though, because i don't have a snapshot mesa :)
<tormod> so the server doesn't have DRI? that would be pointless for me since my main motivation is the R500 3D in mesa git.
<tormod> but if I rebuild the server in my ppa (with mesa snapshot) can I then just install the rest - I guess the video drivers must be rebuild but that's fine.
<jcristau> that should be ok, yes. i'm uploading 1.4.99.902 now, so you can take that, change debian/rules to enable dri and glx, and build against your mesa snapshot
<jcristau> then rebuild the ati driver against that, and profit
<tormod> cool thanks! I will need to sleep on this, and see if I find time in the weekend. night!
<jcristau> night
<tseliot> tjaalton: if you're in the hotel I would like to have a word with you
#ubuntu-x 2008-05-24
<johanbr> Hi. I'm trying to help someone with a Radeon 7500 card (using the radeon driver). When he tries to use 1440x900, the computer hardlocks, but only if connected via DVI (VGA works fine). Any ideas?
<johanbr> I got him to try the git ati driver from the ppa. No improvement.
<bryce> hey all, just got home
<bryce> johanbr: http://wiki.ubuntu.com/X/Backtracing is probably your next step
<johanbr> bryce: Thanks. Is that likely to work if X locks up hard when running normally?
<johanbr> I.e., when not run under gdb or anything like that.
<bryce> johanbr: if you can ssh into the box, then yes
<bryce> if you cannot login to the box then the lockup may be a kernel issue instead
<bryce> see that page for full discussion (and don't be afraid to add some questions to that page if it is unclear)
<johanbr> Alright, I'll walk him through these steps and we'll see what we find. Thanks.
<bryce> cool, thanks
#ubuntu-x 2008-05-25
<unggnu> hi all
<unggnu> It would be great if there could a ppa or entry for a howto for the latest possible Intel driver on this page https://wiki.ubuntu.com/XorgOnTheEdge .
<unggnu> Or another howto so bug reporters are easily able to test their issues against a newer -intel driver.
<rzr> unggnu: i think bryce is doing that 
<unggnu> cool. There is a bisect page but it hasn't updated afaik.
<Q-FUNK> hey
<Q-FUNK> just tried the proposed packages with the geode
<Q-FUNK> something tells me that the debian/ubuntu packages do something fishy that other distros don't.
#ubuntu-x 2009-05-18
<Sarvatt> bryce: is xorg-needs-kernel-fix what you decided on in the end then? just wanted to be sure before tagging something
<bryce> Sarvatt: that's correct
<bryce> I figure we can always change it later if needs be, but this gives us something unique and searchable
<albert23> Magic: pushing back exa offscreen 32MB below end of aperture fixes the 965 freeze for me. Pushing back 4 kB to keep exa offscreen out of the last page in aperture was not enough.
<Sarvatt> albert23: did you mention that in #intel-gfx by any chance? they're talking about that right now
<albert23> No, I didn't. I think the discussion on -gfx is something else
<Sarvatt> ah good 105_glXWaitX_segfaults.patch went upstream in mesa too
<superm1> it's about time. it's been sitting idle on an open bug for ages
#ubuntu-x 2009-05-19
<tjaalton> sweet, only eight packages non-synced/merged with debian
<tjaalton> I'll merge a couple later today
<Sarvatt> tjaalton: dont suppose xorg-server is in there huh? :D
<Sarvatt> wow nice, I just applied this to xorg-server 2:1.6.0-0ubuntu15 and its amazing how fast VT>X switch is in KMS now. http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=fdbb6fd3d3c0ce7078f8faaf089af51cc36cbcb3
<tjaalton> Sarvatt: sure. I'll add that commit, since there is a noticeable lag when switching back to X
<tjaalton> oh right, it's included in 1.6.1.901
<tjaalton> bryce: there are a bunch of patches against xorg-server by you. plans to send them upstream?
<Sarvatt> xvmc-vld branch of xf86-video-intel is looking good, xvmc's working in UXA now
<Sarvatt> your xorg-server 1.6.2rc1 works great here tjaalton - http://sarvatt.com/downloads/Xorg.0.log.txt
<Sarvatt> nice, UXA hangs in firefox are fixed now, just finished compiling a new kernel/drm/intel driver to test the patches. bad news is it needs updates to all of those to be fixed.. https://bugs.freedesktop.org/show_bug.cgi?id=20152
<ubottu> Freedesktop bug 20152 in Driver/intel "[G45/GM965 UXA] cannot view JPG in firefox when running UXA (lots of errors in dmesg)" [Major,Resolved: fixed]
<albert23> Last exa migration before the 965 freeze occurs: -> 0x5750ec0 (0xffe0a00) (1280x25) (c)
<albert23> assuming size of the pixmap is 4 bpp x 1280 x 25, the pixmap ends at FFFFE00
<albert23> Yesterday I found pushing back exa offscreen from the end of aperture prevented the freeze
<albert23> So that seems to match quite nicely
<albert23> Could there be any reason the gpu reads more then the pixmap size, for example due to tiling?
<albert23> jbarnes maybe^?
<tjaalton> better ask on #intel-gfx
<tjaalton> Sarvatt: ok, good to know
<jbarnes> albert23: yes, that's one reason... it also prefetches data past the end of objects
<albert23> jbarnes: how large would the prefetch be? Pushing back exa offscreen 4 KB didn't help. 1MB seems to be enough
<jbarnes> generally shouldn't got past a page of prefetch
<jbarnes> but tiling can increase the object's size to the next power of two
<jbarnes> or at the very least its width will be increased to the next multiple of the tile size
<jbarnes> which can add a lot
<albert23> jbarnes: note we had the 32MB classic texture buffer until beginning of April
<jbarnes> yeah I saw that add... interesting
<albert23> so this matches also with the beginning of the freeze bug
<albert23> Now we only need a safe value for the push back...
<albert23> The 32 MB classic was causing problems on some older 8xx cards
<albert23> Assuming maximum display height of 4096 lines, 8MB should be safe
<albert23> Well, we can always calculate the required unused memory dynamically, and possibly only if IS_I965G(pI830)
<albert23> This is what I am testing now. Maybe someone else who has the freeze can test this as well? http://paste.ubuntu.com/175953/
#ubuntu-x 2009-05-20
<ion_> Fedora 11 seems to have KMS support for Intel, AMD and nVidia. Whatâs karmicâs KMS status?
<jcristau> only intel kms is upstream
<jcristau> radeon might get in for .31
<hyperair> if only intel support was stellar.
 * hyperair mutters darkly about memory leaks
<jcristau> new code is rarely stellar
<tjaalton> ion_: they're going to discuss it at the UDS. from what I can read between the lines is that theyÃre willing to be on the edge regarding kms for ati and nouveau
<ion_> Cool
<tjaalton> kms works fine on my i965
<tjaalton> tried to find the tree for nvidia today, but couldn't :s
<ion_> Now if my laptop just had something else than an old S3 Savage, which is guaranteed to be on the bottom of the priority list for anything cool and new. :-P
<hyperair> has anyone managed to escape the memory leaks when using compiz, though?
#ubuntu-x 2009-05-21
<Sarvatt> ugh, going to have to do something else with mesa, need to install a dri.pc to build xserver master
<wgrant> tseliot: Are you aware of the -synaptics rename in Debian, and its clobbering of our local changes in Karmic?
<tseliot> ouch, no
<tseliot> wgrant: I'll have a look at it
<tseliot> thanks for reporting
<wgrant> Bug 378391
<ubottu> Launchpad bug 378391 in xserver-xorg-input-synaptics "Source rename clobbered local changes" [High,In progress] https://launchpad.net/bugs/378391
<wgrant> I have a merged version in my PPA.
<wgrant> Should I prepare a proper upload, or do you have other stuff that needs doing to it?
<jcristau> ooi, what are the synaptics changes besides the tapping default?
<wgrant> Mostly defaults changes.
<wgrant> But let's see what else...
<wgrant> The defaults we change are tapping, corner tapping, multifinger tapping, vertical edge scrolling.
<jcristau> ok
<wgrant> We have a newish patch to blacklist from movement some region at the bottom of the touchpad.
<jcristau> vert edge was changed in 1.1.1 so hopefully that'll be fine now
<wgrant> Different defaults for ALPS.
<wgrant> 1.1.1 has been released?
<jcristau> yeah
<jcristau> it's brand new
<wgrant> Ah, 4 hours new. That explains why I hadn't seen it.
<tseliot> wgrant: I'm at All Hands now in Barcelona and I'm dealing with -psb
<tseliot> so I don't have a lot of time now
<jcristau> but the different edge scrolling defaults for alps is already in the snapshot that mattia uploaded to sid a week ago
<wgrant> tseliot: Ew, that can't be much fun.
<tseliot> it's not ;)
 * tseliot has to run
<wgrant> jcristau: It looks like we change a lot more than scrolling defaults for ALPS.
<wgrant> tseliot: I'll prepare an upload. Thanks.
<tseliot> great :-)
<wgrant> jcristau: And the patch doesn't conflict with the latest sid version.
<jcristau> wgrant: was that sent upstream, or not yet?
<wgrant> jcristau: I don't know; I had insufficient time to keep track of these things during Jaunty, when it was added.
<wgrant> It's one of tseliot's patches.
<jcristau> okay. thanks!
 * hyperair wonders if anyone has met with but #367377
<Sarvatt> i've been dropping 108 and 109 in the 1.1.99 git snapshots i use
<hyperair> bug #367377
<ubottu> Launchpad bug 367377 in xserver-xorg-video-intel "High load average, disk read, no apparent reason - 2.6.28-11" [Undecided,Confirmed] https://launchpad.net/bugs/367377
<hyperair> hmm the description should be changed, really. it's basically the stupid memory leak sisue
<hyperair> issue*
<wgrant> Sarvatt: 108 should go, but I've kept 109.
<wgrant> hyperair: Yep. Not so much now as in early Jaunty, but it still happens occasionally.
<wgrant> It used to happen many times a day.
<hyperair> wgrant: only occassionally for you? =(
<hyperair> wgrant: it happens to me every 6 hours or so
<hyperair> and that's after patching drm-snapshot
<hyperair> to disable BO caching, that is
<wgrant> hyperair: I restart X a bit at the moment.
<hyperair> previously, ever 4 hours
<hyperair> yeah, i'm forced to restart X every 6 hours now.
<hyperair> which is very annoying
<wgrant> But the swap is constantly filling up.
<wgrant> Although it seems to be OK now.
<wgrant> Actually, I'm not using KMS today. Maybe that makes a difference.
<hyperair> i'm not using KMS either
<hyperair> what's your X's uptime?
<hyperair> and what are the versions you're using? (kernel, driver, drm, mesa)
<Sarvatt> that patch is straight out of my diff on edgers, its part of a 3 part patch series that fixes the UXA firefox crashes and needs a kernel patch as well thats not upstream yet..
<wgrant> driver/drm/mesa from xorg-edgers.
<hyperair> and your gpu?
<hyperair> is it a 965?
<wgrant> Karmic's Linux 2.6.30-5.6
<wgrant> i915
<hyperair> 915 eh..
<hyperair> i think it doesn't hit the older cards as hard
<hyperair> 965 seems the most badly hit
<hyperair> (and it's still around with xorg-edgers' driver/drm/mesa
<hyperair> so i've taken to watching /proc/dri/0/gem_objects
<wgrant> Yep.
<wgrant> i've currently got about 500MB in there.
<hyperair> i've got 724MB
<hyperair> but it keeps rising until approximately 2G
<hyperair> that's when i have to restart X
<wgrant> Been up for 9 hours, but unused for most of that time.
<hyperair> or it'll begin thrashing
<Sarvatt> its still around with the kernel patch that thats part of too, it didnt happen until about a week and a half ago for me strangely
<hyperair> unused doesn't count =O
<Sarvatt> 908mb here
<hyperair> Sarvatt: and your X uptime?
<hyperair> mine's approx 3h 30m
<Sarvatt> 72 minutes since i zapped it last
<hyperair> then you're definitely experiencing the bug to a certain extent
<hyperair> try stretching it over 6 hours and see
<Sarvatt> wgrant: 109 didnt apply to 1.1.99 I dont think, since they ripped out all the SHMConfig stuff, and I dont have alps so I didnt bother with it is all :D
<jcristau> right, shmconfig is ripped out in master, but not 1.1-branch
<hyperair> shmconfig? the synaptics driver?
<hyperair> won't syndaemon fail then?
<wgrant> No, it uses XI properties now.
<wgrant> Same with synclient.
<wgrant> In master, SHMConfig is only used for monitoring internal stuff, not setting things.
<hyperair> hmm cool.
<wgrant> The horrible beast is finally dead.
<hyperair> indeed
<Sarvatt> its nice being able to disable tap and drag on 1.1.99 :D
<hyperair> ?
<Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=ee265e10c9cc724ad0badcab86a3893667717322
<hyperair> tap and drag meaning ..?
<hyperair> aah
<hyperair> i see
<hyperair> awesome
<hyperair> i've had a lot of my clicks accidentally sticking
<hyperair> heheh
<hyperair> hmm Xorg gets loaded when an application window changes its title rapidly
<hyperair> 974680064 object bytes T_T
<hyperair> surely a driver doesn't need over 1G just to render an empty desktop?!
<wgrant> hyperair: I'm up to 800MB. I just closed Firefox with its several dozen tabs, and the usage went *up*.
<hyperair> and it'll keep going up
 * hyperair grumbles
<hyperair> eventually it'll shove everything into your swap, and free -m will show that you've got around 1G of disk cache
<hyperair> wgrant: ^
<jcristau> i don't see anything like that on debian.  does it only show up with compiz, or newer than 2.6.29 kernels, or?
<hyperair> .28 is enough
<hyperair> only with compiz
<hyperair> or rather...
<hyperair> compositing is required.
<jcristau> ah so that explains it
<hyperair> otherwise the bug doesn't appear
<hyperair> i'm also beginning to believe that most of the #intel-gfx people don't have compositing enabled.
<hyperair> and so they don't notice this bug
<hyperair> and don't give a frigging damn about it
<jcristau> i don't think that's true.  but they have so many bugs some just stay under the radar for a while :)
<wgrant> hyperair: Right, that's what I've been seeing.
<wgrant> It took me a while to work out that the cache was actually mostly GEM data.
<hyperair> yeah that took me a while too
<hyperair> i was blaming ext4 at first
<hyperair> but then i realized that vm.vfs_cache_pressure and vm.swappiness wasn't working
<wgrant> I twigged it wasn't really cache when 'swapoff -a' got OOM-killed while there was still 1GB cached...
<hyperair> heh yeah
<hyperair> exactly
<hyperair> same here
<hyperair> no actually swapoff didn't get OOM-killed for me
<hyperair> it went into super-thrashing mode
<hyperair> and never got out
<hyperair> i left it for an hour or so
<wgrant> hmm.
<wgrant> Maybe you left it too late.
<hyperair> and the hard disk light still didn't stop blinking
<hyperair> maybe
<hyperair> i usually ^C swapoff myself
<hyperair> before it goes into a swapin/out frenzy
<hyperair> i think if you continually use the ring switcher in compiz, you can dramatically raise the GEM usage
<hyperair> for testing purposes of course. i wouldn't actually want something like that to happen =(
<jcristau> does killing compiz reclaim the buffers, or do you need to restart X?
<hyperair> restart X
<hyperair> it's X which owns most of the GEM buffers
<hyperair> you could do something like sudo lsof -n | grep drm | grep Xorg | wc -l
<hyperair> and compare that figure to without grep Xorg
<hyperair> with grep Xorg it's 779 on my system currently
<Sarvatt> 2 :)
<hyperair> and 794 in total.
<hyperair> ..2?!
<jcristau> 1106 here
<hyperair> what do you have running, xterm and xclock?!
<Sarvatt> 0 now
<jcristau> and 1106 total :)
<hyperair> jcristau: what's the second line in /proc/dri/0/gem_objects?
<hyperair> 1133780992 object bytes
<hyperair> that's it for me =(
<jcristau> (note that i'm not running a compositor)
<hyperair> yes, you've mentioned
<jcristau> 39084032 object bytes
<jcristau> a lot more reasonable :)
<hyperair> yes. a lot more reasonable indeed.
<hyperair> during the first hour or so, that's the figure for me
<hyperair> after that it rises
<hyperair> now is... the fifth hour.
<Sarvatt> i dont get the same symptoms as most of these bugs on it though, it was absolutely fine until about a week and a half ago
<hyperair> how very strange.
<hyperair> =(
<hyperair> Sarvatt: what's your hardware again?
<Sarvatt> acer aspire one, 945GME
<hyperair> ah yes
<hyperair> it doesn't affect 945 i reckon
<hyperair> i was bugging some people on #intel-gfx
<hyperair> and they said it doesn't happen for them
<hyperair> and they were using 945
<hyperair> most of the people i know who have issues are using 965.
<hyperair> including me
<hyperair> and since wgrant is having the issue, i suppose it affects 915 as well.
<jcristau> 915 and 945 are basically the same, though..
<hyperair> is it?
<hyperair> =\
<jcristau> so that's weird
<hyperair> weird indeed.
<hyperair> we need more 915 people.
<hyperair> and more 945 people
<Sarvatt> i'm getting the same problem now though with the hdd thrashing and everything though, but i never had it before about a week and a half ago even with weeks of uptime
<hyperair> ah
<Sarvatt> ^ thats some 9 am grammar
<hyperair> but do you know what changed?
<Sarvatt> nope
<hyperair> =(
<nogoodreason> Hi guys.  Forgive the noobish question, but I'm wondering how to download and install this Nvdia driver: https://launchpad.net/~ubuntu-x-swat/+archive/x-updates/+build/958828
<hyperair> go to https://launchpad.net/~ubuntu-x-swat/+archive/x-updates
<hyperair> instructions are there
<hyperair> 189329408 object bytes (restarted X)
<tjaalton> hyperair: he left already ;)
<hyperair> he did?
<hyperair> oh right
<hyperair> he did
<hyperair> bah
<Duke`> there are 915-specific bugs?
 * hyperair doesn't know
<bryce_> likely so
<tjaalton> nice, opening a specific webpage hangs my i965
<tjaalton> same backtrace
<tjaalton> bryce_: did you have the intel merge ready?
<Sarvatt> tjaalton, they fixed that up 2 days ago, need an updated kernel/libdrm/-intel
<tjaalton> Sarvatt: nice
<tjaalton> but how do you know it's the same bug?-)
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=20152
<ubottu> Freedesktop bug 20152 in Driver/intel "[G45/GM965 UXA] cannot view JPG in firefox when running UXA (lots of errors in dmesg)" [Major,Resolved: fixed]
<Sarvatt> i have the libdrm/-intel updated on xorg-edgers already and if you want to test the kernel out i've got one here with the update already applied if you want to try it, its not upstream yet and rc7 isnt far off so it'll probably be a few weeks till it hits a ubuntu kernel
<Sarvatt> http://sarvatt.com/downloads/2.6.30-rc6/
<tjaalton> there's nothing in dmesg
<Sarvatt> yep i got nothing too
<tjaalton> but the backtrace is the same
<tjaalton> the url was about the unix-timeline, and it probably had the picture on the frontpage
<Sarvatt> try going to www.woodtv.com :D
<tjaalton> I'll pass ;)
<tjaalton> now I just need to remove it from the ffox sessionstore.js..
<Sarvatt> can just uncheck that specific page on the crash restore thing cant ya?
<tjaalton> what's that?
<bryce_> tjaalton: no I do not have any merges pending at the moment
<bryce_> Sarvatt, tjaalton: that woodtv.com issue was traced down to a particular image on that page, which apparently has a width exceeding some buffer
<bryce_> tjaalton: the internet here at the hotel is too crappy to maintain an ssh session, so I think I'm not going to be doing any merging before I get home
<bryce_> however, since internet's been down so much, I'm working on a new tool to help with analyzing bugs, that I've been meaning to work on for quite some time
#ubuntu-x 2009-05-22
<Sarvatt> tormod: thats one hell of a changelog huh, need to review alot of patches https://edge.launchpad.net/~sarvatt/+archive/xorg-testing/+sourcepub/636249/+listing-archive-extra
<Sarvatt> oh shoot he isnt in here, sorry
<hyperair> hmm this is interesting. looks like i've got the usual GEM leak, but the symptoms -- unfreeable cache doesn't seem to be there.
<hyperair> at least, not a huge amount of unfreeable cache
<hyperair> uptime ~ 6h.
<hyperair> let's see how long this stays. =D
<tjaalton> bryce_: yeah I got the upstream bug report, and it'll be in karmic before too long. running EXA for now
<tjaalton> bryce_: also, I merged intel 2.7.1 and wacom-tools today, only ~7 packages to go
#ubuntu-x 2009-05-23
<bryce_> tjaalton: awesome
<jordi1983> I have an idea, and I want to know do you all think, wouldn't it be cool to have a PPA containing daily builds for the last ati r6xx/r7xx 3D support in order to be tested on ubuntu, and this way helping to speed up their stabilization and development?
<jordi1983> so, I'm going to re-send the previous message, for you all to be able to read it
<jordi1983> there ( http://www.x.org/wiki/radeonhd%3Aexperimental_3D)  it explains how to build and install the files but I'd like somebody to do the packaging in a PPA I don't know how to do it, I think there is a lot of dependencies and things you need to know to package a video driver in the right way
<ripps> jordi1983: xorg-edgers and tormod do this already
<Sarvatt> the drm is already done  in xorg edgers and tormod builds radeon-rewrite just about every day too..
<ripps> hivemind
<jordi1983> the radeon-rewrite branch applies only for r1xxx-r5xx cards
<Sarvatt> r600-700 drm hasnt even been updated in almost 2 months
<jordi1983> I'm talking about r6xx-r7xx-3d branch, or r6xx-rewrite
<Sarvatt> http://cgit.freedesktop.org/mesa/mesa/log/?h=r6xx-r7xx-support
<Sarvatt> that hardly justifies a daily build there :D
<jordi1983> the code in that branch provides drm support for that cards and therefore EXA and Xvideo, but I'm talking about the experimental 3D support
<jordi1983> I mean DRI (or DRI2 I don't know which one it's been implemented now)
<Sarvatt> (i linked mesa/mesa not mesa/drm)
<jordi1983> oops, sorry
<jordi1983> look at this one: http://cgit.freedesktop.org/~agd5f/drm/log/?h=r6xx-r7xx-3d
<jordi1983> on the xorg wiki says: 3D: experimental, development in two places simultaneously; mesa r6xx-r7xx-support, r6xx-rewrite, both need drm r6xx-r7xx-3d
<jordi1983> looking at the development pace maybe daily builds wouldn't be very useful, maybe weekly builds, but something at least, right there isn't any builds at all
<jordi1983> right now...
<jordi1983> I think you need to have a git version of radeon, mesa and drm to test it
<Sarvatt> tormod might be up for it, but hes on vacation for the weekend. maybe send him a message through launchpad?
<jordi1983> Ok, I'll do it, thank you. Meanwhile, do you (or somebody else) know where can I learn how to do it myself? My knowledge about these technologies is very poor and about packaging too.
<jordi1983> Is there any book or website or wiki...
<jordi1983> no answer, am I writing in the wrong place?
<Sarvatt> i was testing merging everything to see if it'd work for xorg-edgers but no luck, r6xx-rewrite is still based on a really old mesa version. maybe once they start merging with master like radeon-rewrite is we can do it on the mesa end
<Sarvatt> cant think of a single place i learned it outside of google and apt-get source-ing stuff to see how it works in the debian folder, sorry i dont have any links handy..
<Sarvatt> eww r6xx-r7xx support branch is based off of mesa 7.2 even
<Sarvatt> anyone had any experience with radeon-rewrite? thinking about merging it with the karmic mesa 7.6 on xorg-edgers
<maxb> Whoa, weird. The 2.7.1 intel driver has apparently done something weird with the aspect ratio of X elements
<maxb> It now thinks I'm 800x600, when in fact I'm 1024x600
<Sarvatt> tjaalton: you forgot to add 01_gen_pci_ids.diff  to xserver-xorg-video-intel, debian dropped it
<Sarvatt> people are getting fallbacks to vesa because of it
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/379504
<ubottu> Ubuntu bug 379504 in xserver-xorg-video-intel "Xorg falls back to VESA on intel hardware" [Undecided,Confirmed]
<hyperair> 9011 objects
<hyperair> -2062495744 object bytes
<hyperair> how fun.
<hyperair> it's leaked so damn much memory, it even overflowed.
 * hyperair facepalms
<tjaalton> Sarvatt: I didn't forget anything, because I didn't know it was needed anymore
<tjaalton> strange that it has gone unnoticed in debian
<jcristau> hmm.
<tjaalton> so the autoconfiguration logic is flawed, the internal table is only used if there's no config file
<tjaalton> but that was and is well known
<tjaalton> so maybe it was just an oversight?
<jcristau> the internal table is used here..
<tjaalton> let me try it myself
<jcristau> julien@radis:~$ grep intel /etc/X11/xorg.conf
<jcristau> julien@radis:~$ grep intel /var/log/Xorg.0.log|head -n 1
<jcristau> (==) Matched intel for the autoconfigured driver
<tjaalton> just dist-upgraded
<jcristau> might be broken when /usr/share/xserver-xorg/pci/ exists but doesn't have the right entry
<tjaalton> doesn't work here. is the newer xorg-server needed?
<tjaalton> ah
<jcristau> (==) Registering 'vesa' as fallback << where does this message come from?
<jcristau> aha
<jcristau> debian/patches/143_default_to_vesa.patch:+        xf86Msg(X_DEFAULT, "Registerin
<tjaalton> hehe
<jcristau> bad ubuntu patch ;)
<tjaalton> anyway, confirmed
<tjaalton> purging other drivers made it work again
<tjaalton> nice, libaudit-dev is in universe, and needs to be moved to main before the new xorg-server builds
<jcristau> tjaalton: if that's a problem you can build without selinux i guess
<tjaalton> jcristau: yeah, probably will do that for now
<hyperair> huh this is strange. my RAM is being pushed into the swap, but neither cache nor actual RAM usage seems to be high enough to push it into swap
<hyperair> Mem:          1977       1580        397          0         16        516
 * hyperair suspects GEM to be guilty.
<hyperair> oh cool. no longer unfreeable cache, but unswapoffable free memory.
<hyperair> Sarvatt: are there any plans to backport xorg-server to jaunty in the ppa?
#ubuntu-x 2009-05-24
<Sarvatt> yep, was waiting for it to release on karmic first before doing jaunty, it's building now
<Duke`> hum got some picture corruption with i915
<Duke`> font characters, and images with firefox where seriously damaged
<Duke`> kernel 2.6.29.3 ; xorg/mesa stuff from xorg-edgers for jaunty
<Duke`> too bad it's not my computer and I have to setup a fonctionnal system, so can't do a lot of tests and I had to downgrade to jaunty-only packages
<bryce_> heya
<bryce_> jbarnes_BCN: o/
<tjaalton> howdy
<bryce_> heya tjaalton
<tjaalton> bryce_: how's the place so far? :)
<bryce_> tjaalton: it's great, the hotel is swank.  Prices for food and stuff in the hotel is out of sight, but the subway is easy
<bryce_> we spent the last two days strafing the city seeing sights and such
<tjaalton> yeah, I bet there's lot to see
<bryce_> http://www2.bryceharrington.org:8080/Photos/Barcelona/ <-- stuff up until yesterday
<tjaalton> Gaudi's architecture is amazing, I've heard
<tjaalton> and for soccer fans there's camp nou ;)
<bryce_> yeah we heard them chanting in the stadium down the way
<tjaalton> had a look at the map and it's not far from the hotel
<bryce_> yep, we could see the fireworks and the stands from our window
<tjaalton> looks like you spent a fair amount of time around the sagrada familia ;)
<bryce_> :-)
 * bryce_ --> dinner
<jbarnes_BCN> bryce_: were you headed?
 * jbarnes_BCN was out like a light
<bryce_> jbarnes_BCN: dunno, was going to go looking for people first :-)  Interested in finding food?
<jbarnes_BCN> yeah though I might pass out into my plate...
<jbarnes_BCN> I'll risk it though, I need to try to adjust
<bryce_> heh, ok meet you downstairs?
<jbarnes_BCN> yeah I'll be right down
#ubuntu-x 2010-05-24
<fagan> Hey guys im getting this error when I open totem in maverick http://pastebin.ubuntu.com/438744/
<fagan> any ideas what the problem is?
<jcristau> This probably reflects a bug in the program
<fagan> jcristau: it says that but totem hasnt been updated in maverick yet
<fagan> its still running the version in lucid 
<fagan> ah its a client side thing
<RAOF> I thought bratche had fixed that?  Clearly not.
<RAOF> It's ARGB windows fallout.  GDK_NATIVE_WINDOWS=1 totem should work.
<fagan> RAOF: is there a bug report I can update 
<fagan> I remember there was a master bug report for lucid 
<RAOF> Not that I remember offhand; it should be pretty easy to find, though.  It's on the gtk package.
<fagan> ill go look for it after college 
<jg> RAOF: bryceh says you might help me with testing this bug that has bit eDP displays: https://bugs.freedesktop.org/show_bug.cgi?id=28070
<blue_anna> in Lucid, Compose sequences can only consist of two characters, and may only output one character. This makes them exactly equivalent to dead keys. but many useful example ~/.XCompose files online make use of 3 combining characters (in vitro w/ 2) or output multiple keys (digraphs)
<jcristau> that's not true.
<blue_anna> jcristau: what do you mean? I have a .XCompose file .. its not working for me
<blue_anna> jcristau: but like compose+t+m for â¢ .. that does work
<blue_anna> in the same file
<jcristau> i mean that compose sequences can output arbitrary strings, and have as many keys as you want.
<blue_anna> jcristau: I tried setting <Multi_key> <c> <h> to "ch" and it doesnt work. that same compose sequence will work for a single character like "*" asterisk .. I even tried it with dual fields like "ch" "ch" in case both fields were required
<blue_anna> jcristau: what am I doing wrong? I'd love to have that working :)
<jcristau> there's already a sequence for compose c h
<blue_anna> yeah, but I tried it for c+q too
<blue_anna> in case it was that
<blue_anna> jcristau: btw, where is compose c+q defined? it is not in /usr/share/X11/locale/iso8859-1/Compose
<blue_anna> ** I mean c+h
<blue_anna> oo lol, unbelievable, the es_EC.utf-8 doesn't map to one of the latin iso blocks, it maps to en_US.utf8 (*boggle*)
<blue_anna> well now I know where compose c+h and compose c+c come from
<jcristau> why the hell would an utf8 locale map to the latin1 file..
<blue_anna> apparently if you define a .XCompose it does *not* load in place of the system compose file like normal, in ubuntu. (so there's no need for an "include" line at the front of .XCompose files in ubuntu)
<blue_anna> jcristau: well, its the same as the keymap that way
<blue_anna> symbols/es
<blue_anna> jcristau: I admit, it would be *besT* to have an es_EC.UTF-8  and one fo rall the others, but that's a lot of files
<blue_anna> jcristau: where would I suggest a bug fix for that? the compose.dir file even has a comment in it saying that the utf8 stuff is broken
<jcristau> i don't know what bug you're talking about
<blue_anna> in /usr/share/X11/locale/compose.dir , the global compose directory, it says "Note: The UTF-8 locales don't work correctly yet. Work in progress."
<blue_anna> the reason is because right now if you are using utf-8, generally you are asked to use the en_US.UTF-8 locale settings, which are inappropraite for the vast majority of /usr/share/X11/xkb/symbols/* files
<blue_anna> jcristau: maybe its an incomplete feature instead of a bug, who would I talk to about how to fix it a good chunk of that? I've got a simple fix for the better part of all european locales
<blue_anna> jcristau: not that this solves my issue with digraphs not working for .XCompose, but it solves the issue I found documented in the distribution files
<blue_anna> in Lucid, at least in gnome apps Compose sequences can only consist of two characters, and may only output one character. This makes them exactly equivalent to dead keys. but many useful example ~/.XCompose files online make use of 3 combining characters (in vitro w/ 2) or output multiple keys (digraphs)
<blue_anna> I just found out you can get multiple characters in qt though ! :)
<blue_anna> <Multi_key> <b> <t> <w> : "by the way" -- works everywhere but in gnome/gtk. but other composes I set in .XCompose do work. what's going ?
<Bernardo> hi
<blue_anna> hi Bernardo
<blue_anna> sup?
<Bernardo> still fighting psb drivers... 
<blue_anna> that was before I came here
<blue_anna> I'm still fighting gtk and xorg
<blue_anna> :P
<blue_anna> sadly, I want to get along with them .. why can't we all just get along?! :)
<blue_anna> <Multi_key> <b> <t> <w> : "by the way" -- works everywhere but in gnome/gtk. but other composes I set in .XCompose do work. what's going on?
<tjaalton> there is a bug about that somewhere
<tjaalton> gtk bug
<blue_anna> tjaalton:  jesus is there? I saw the one aobut the xcompose file being ignored, but it's not that. the file is read but anything bigger than a dead key doesnt
<blue_anna> or bigger than 1 character of output
<tjaalton> at least it sounds familiar, i'll try to find it when i get home
<blue_anna> thanks - yea this is hard to fid just searching for relavant terms like "gtk bug xcompose" or im-module ..
<tjaalton> did you say it used to work?
<Bernardo> I only wish the moblin/meego developers had done the sensible thing and put the driver as a separate module and not a huge kernel patch
<blue_anna> tjaalton: no. its that it works everywhere -- EXCEPT gtk/gnome
<Bernardo> at least now they are integrating with the Imagination Technologies ddk, so there is a hope that we'll have some decent openGL support
<tjaalton> blue_anna: ok, then it should fit the bug aiui
<blue_anna> tjaalton: alright -- wish I could find that bug myself -- I'm running searches like the wind here, andI can't find it
<Bernardo> hi lucazade
<lucazade> hi!
<Bernardo> Maybe we should start thinking on having a psb optimized kernel, adding the meego driver patch... :)
<lucazade> sounds good.. 
<lucazade> is there a public changelog or a list of bugs fixed with this patch?
<Bernardo> no
<Bernardo> brb
<lucazade> ok
<blue_anna> the gtk people tell me that xim is not the preferred im because it is buggy. I am getting one of those bugs with my particular set up. what is the suggested lucid alternative to xim for custom compose keys ? https://help.ubuntu.com/community/ComposeKey -- this says xim but like I said that's known not to work
<tjaalton> blue_anna: ibus
<tjaalton> and the bug i was referring to was different, and seems fixed (mod4 couldn't be used for shortcuts)
<tjaalton> so i didn't understand the problem the first time ;)
<blue_anna> tjaalton: there's a ton of them, I was just at gnome.bugzilla
<blue_anna> if you don't limit the search to gtk+ and jsut search xim and xcompose, there are hundreds -- maybe thousands -- I dont know how they do it on volunteer manpower at all ;)
<tjaalton> well there are >3000 bugs against the ubuntu X packages, 10000 against the kernel and almost 90000 in total (on ubuntu). I don't know if we are any better ;)
<blue_anna> tjaalton: do you know how to get Xcompose working with ibus? there are some unanswered posts on ubuntuforums about that but no solutions
<tjaalton> blue_anna: NO
<tjaalton> sory
<tjaalton> (caps)
<tjaalton> +r
<tjaalton> :)
<blue_anna> nps
<tjaalton> â¦
<tjaalton> ooh, i found it :)
<tjaalton> that character, that is
<blue_anna> tjaalton: what character?
<tjaalton> blue_anna: â¦
<tjaalton> and 'multi minus minus minus' works here
<tjaalton> â
<tjaalton> so maybe it's just that your .XCompose is not read?
<blue_anna> no well, I thought of that.
<blue_anna> but in .Xcompose I created regular style compose keys and they do work: compose+t+m = â¢
<blue_anna> ** ~/.XCompose
<bjsnider> Sarvatt, did that powermizer tweak work?
<tjaalton> blue_anna: ok
<blue_anna> tjaalton: also in my system, those do work -- that's neat. compose minus minus minus works, didnt even know it had 3-key versions defined.
<blue_anna> that doesn't work in qt apps
<blue_anna> but it does work in xterm .. jeez, why does every possible library have different behavior :S
<blue_anna> if I use ibus tables to emulate compose keys I will have to use only the ibus locale for that table ...
<Bernardo> lucazade: I'm trying to build the xorg driver now, to see if it will work with our module
<lucazade> Bernardo: great.. hope you get it working!
<lucazade> is it difficult to build?
<Bernardo> dependencies... They have a new lib (libwsbm), which needs some more headers we don't have in libdrm-poulsbo
<Bernardo> The interesting part in the moblin kernel driver is that they implemented kms
<Bernardo> so the psb_drv.h has a lot of kms related stuff
<lucazade> nice...
<lucazade> the pvr module?
<Bernardo> no, the moblin one, psb
<lucazade> ok right
<lucazade> too much stuff :)
<Bernardo> the meego version is the one they added the pvr module and made the psb use a lot of the pvr headers
<Bernardo> yes, too much. They should have kept the module out of tree, like in mandriva or ubuntu
<lucazade> i should learn by doing.. so i've to try
<Bernardo> I used to build a lpia kernel two years ago, when I had a aspire one, before the 1101HA
<Bernardo> The tough part was getting the build structure right, but now there are a couple of walkthroughs out there in the web
<lucazade> i can imagine how hard was
<lucazade> if you have some hints on how to get a working build env, tell me
<lucazade> i'll try in a vm
<lucazade> brb
<blue_anna> does anyone here understand /usr/share/X11/xkb well enough to describe how to set up a keyboard layout with two ground of 4 levels instead of the default one grounp of 4 levels?
<blue_anna> * two groups
<lucazade1> Bernardo i've to go
<lucazade1> see you soon
<dupondje> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/562802 => somebody here can check this ? it seems a weird issue, not happening with nouveau
<ubot4> Launchpad bug 562802 in firefox (Ubuntu) "xorg use cpu 100% sometime with firefox (affects: 4) (heat: 24)" [Undecided,Incomplete]
<dupondje> somebody alive here ? :(
#ubuntu-x 2010-05-25
<coz_> hey guys I am not sure about this... which aspect of ubuntu would be responsible for right click drive icons with no unmount available?
<RAOF> coz_: That would be something on the desktop; probably nautilus.
<coz_> RAOF,  ah ok thanks  I was  getting confused about who would be responsible   :)
<RAOF> Hey, asac.  Bouncy network?
<Sarvatt> i think he switched to your old isp :)
<RAOF> Man, anything touching i965g in any way is a one-way ticket to GPU hang.
<Sarvatt> anyone know if anyone has started debianizing mesa/demos? kind of hesitant to update mesa in edgers now with it gone
<Sarvatt> i'm not even putting that in libgl1-mesa-dri-gallium on edgers its so broken :D
<RAOF> Not at this point, no.
<RAOF> There's no release with mesa/demos yet, is there.  I'm not sure if Debian want a snapshot, even in experimental.
<RAOF> However... asking in #debian-x would make that clearer :)
<Sarvatt> i guess it wont remove the old mesa-utils on upgrade and it doesnt really change much so its not that big a deal
<RAOF> Yeah.  It shouldn't use any non-public ABI, which means that it'll survive just fine.
<RAOF> Once there's a release we can split out the demos, and there will be much rejoicing.
<RAOF> Man, why doesn't debian have dbgsym infrastructure yet? :(
<Sarvatt> does debian still require locally built and uploaded binary packages for amd64?
<Sarvatt> or am I crazy and did they never do that? i haven't looked into it as much as I should have
<RAOF> I don't think they ever* required that.
<RAOF> * For values of âeverâ extending multiple years back.
<RAOF> You *are* required to locally build and upload a binary package, from what I can gather.
<RAOF> Sarvatt: Hey, did you ever end up packaging libkms?
<lucazade> hi Bernardo
<alf__> RAOF: Hi!
<alf__> Has there been any progress on the Mesa package with OpenGL ES support?
<maco> bryceh: you declined Bug #563100 a while ago, believing it to be a bug in the proprietary nvidia driver.  upstream, it was declared an X bug, and there is a 1-line patch to fix it. can you give it another look?
<ubot4> Launchpad bug 563100 in xorg-server (Ubuntu) (and 1 other project) "Mouse movement corrupted with Xinerama enabled (affects: 33) (dups: 5) (heat: 232)" [Medium,In progress] https://launchpad.net/bugs/563100
<maco> bryceh: also, others on lp are adamant that there's not really a proper workaround since nouveau can't handle having 2 graphics cards in use at once
<akoya-6805> do you expect ati multi-gpu configurations to work?
<maco> no idea. have they ever?
<maco> oh wait thats not in context of the bug i was just talking about for nvidia users
<maco> (since you just /join'd)
<maco> ignore me :) im not an X person
 * akoya-6805 ignores maco
<coz_> maco,  interesing...not x person either but I have noticed an issue with cursor on both single an dual monitor systems here... not responding well or jumping about the screen particularly on single monitor 
<siriusnova> Howdy
<siriusnova> you guys running the ubuntu-x-swat ppa?
<tseliot> akoya-6805: it should work with fglrx
<akoya-6805> not if one card is "legacy" ;)
<akoya-6805> #radeon guys said i'need the vga arbiter...
<tseliot> akoya-6805: you can't use fglrx and radeon at the same time, therefore, when I said "fglrx", I excluded this use case
<tseliot> if you use Lucid, the arbiter is available. I'm not sure if radeon supports multiple GPUs
<akoya-6805> fair enough
<jcristau> sure it does.
<akoya-6805> with kms it's generally expected to work
<akoya-6805> (accourding to #radeon adamk)
<tseliot> I've never tried myself. I guess it's just RandR that doesn't make use of multiple gpus
<akoya-6805> http://pastebin.ubuntu.com/439310/
<akoya-6805> see for yourself, although that is with ums
<tseliot> ok
<tseliot> akoya-6805: so what's the problem?
<tseliot> or were you just asking?
<akoya-6805> i guess my question had been answered ;) 
<akoya-6805> but:now i have to troubleshoot kms
<akoya-6805> reading on that now...
<dupondje> hi guys. Is there somebody awake here atm ?
<bjsnider> what an amusing article on phoronix about the openchrome driver, or whatever it's being called now
<dupondje> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/562802 => any idea whats causing that ? seems to only happen with nvidia driver, not with nouveau
<ubot4> Launchpad bug 562802 in firefox (Ubuntu) "xorg use cpu 100% sometime with firefox (affects: 4) (heat: 24)" [Undecided,Incomplete]
<Azelphur> Hi, anyone know how I'd hide the mouse pointer permanently?
<Azelphur> It's for a touch screen device, and there's no mouse going to be connected. So the mouse pointer just gets in the way
<Sarvatt> chrisccoulson: have you seen this? http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/xserver-1.7.0-randr-gamma-restore.patch?view=markup
<Sarvatt> regarding the gnome-screensaver failing to restore gamma the second time problem
<chrisccoulson> Sarvatt, that looks like it might fix it
<chrisccoulson> Sarvatt - could you point RAOF to that when he's online?
<Sarvatt> yepyep
<chrisccoulson> thanks
<Sarvatt> mesa dropped 3MB off the tarball size by dropping demos, i was deleting progs/objviewer before making the tarball before too so it's probably closer to 10MB+ :)
<bjsnider> Sarvatt, did that adjustment to powermizer fix your gpu?
<bjsnider> i need closure on that anecdote
<dupondje> somebody has any idea on my issue ?
<dupondje> nobody ? :D
<Sarvatt> bjsnider: i haven't had time to test it, will test it now
<bryceh> mvo, Sarvatt, I've put in a suggestion that the xorg-edgers ppa-purge might be worthwhile to add to python-software-properties:  https://code.edge.launchpad.net/~bryceharrington/software-properties/rm-apt-repository/+merge/25988
<bryceh> mvo, Sarvatt, and rename it to 'rm-apt-repository' so it is matchy to 'add-apt-repository'
<Sarvatt> bryceh: nice, thanks for that!
<Sarvatt> bjsnider: no it didn't fix it unfortunately :(
<bjsnider> that's odd
<bjsnider> what are you saying, that mobile chip users have to use an old blob?
<Sarvatt> i'm trying 173 out now to see if it fixes it, 195 and 256 for sure are screwed up
<Sarvatt> 256 even moreso, metacity is unusable with it
<Sarvatt> with 195 just gl/glx are screwed up
<Sarvatt> http://sarvatt.com/downloads/nvidialol.png
<Sarvatt> thats what 256 looks like
<dupondje> didn't had issues with 256 btw, installed it yesterday
<Sarvatt> are you on a laptop?
<dupondje> yep
<Sarvatt> what GPU?
<dupondje> 01:00.0 VGA compatible controller: nVidia Corporation G71 [GeForce Go 7900 GS] (rev a1)
<bjsnider> it's only the panel that's a bit screwed up
<bjsnider> dupondje, the opengl version you're getting from glxinfo is 2.1 right?
<Sarvatt> bjsnider: yeah, unfortunately theres no way to fix it so it always looks like that, 195 gets that same corruption maybe 1/10 boots
<dupondje> bjsnider: can't check anymore, removed it again, as it didn't fix the issue I had with firefox
<Sarvatt> dupondje: tried unpatching cairo?
<Sarvatt> rebooting into 173 now, lessee if it works
<dupondje> Sarvatt: nope
<Sarvatt> dupondje: does it happen with an upstream firefox build?
<Sarvatt> or just the ubuntu ones
<Sarvatt> i'd try rebuilding firefox without the cairo patches
<Sarvatt> like have you tried firefox 3.6.whatever straight from mozilla?
<dupondje> Sarvatt: tried daily from mozilla ppa, and same issue, gonne try a version directly from mozilla 
<Sarvatt> yeah the daily ones have the same patches
<Sarvatt> compiz looks lovely - http://sarvatt.com/downloads/nvidialolcompiz.png
<Sarvatt> 173 isn't any better :(
<virtuald> sarvatt: http://www.openbsd.org/songs/song39.ogg :p
<bjsnider> Sarvatt, wait a minute now...let's think about this. 173 isn't any better? that code hasn't been touched in a very long time. why couldn't this be a hardware problem?
<Sarvatt> i'm not putting it past being a local problem i'm missing (old libs hanging around or something), setting up a clean lucid liveusb with persistant storage to try the blob out there now
<Sarvatt> and lol virtuald :)
<Sarvatt> i did use to install the drivers from nvidia.com manually for years on this thing
<bjsnider> that's right because you said it doesn't happen on a livecd
<Sarvatt> it didn't start having this problem until the move to alternatives in lucid
<Sarvatt> well more specifically when we moved to 195, it worked fine when it was first moved to alternatives
<bjsnider> this is why i clean install the root partition every 6 months
<Sarvatt> sometime in early feb/late january
<bjsnider> rolling upgrades work in theory but not in practice
<Sarvatt> i dont see *anything* it could be though
<jcristau> bjsnider: tell that to the people who've been upgrading for 10+ years.
<bjsnider> well, they always seem to have problems they're willing to live with
<jcristau> *shrug*
<Sarvatt> i've been using ubuntu as a rolling release switching to the new dev release as soon as it opens since intrepid at least with no problems
<bjsnider> apparently not
<Sarvatt> not sure thats actually the problem here :)
<Sarvatt> hmm what's /usr/lib/nvidia/pre-install
<dupondje> Sarvatt: same issue with firefox straight from mozilla :(
<Sarvatt> dupondje: ah ok so its not the cairo patches..
<dupondje> scrolling on launchpad is a disaster
<dupondje> Xorg going to 100% cpu, and lagging like hell
<Sarvatt> happen in other browsers too?
<Sarvatt> cant even use firefox at the moment to test it since all my machines are on maverick and firefox is broken because of the client side decorations :D
<dupondje> its better in Chromium it seems
<dupondje> max 30% cpu load or so
<Sarvatt> do you have a quad core?
<dupondje> dual
<Sarvatt> is it any better in a newer firefox or anything? 3.7?
<dupondje> same issue it seems
<dupondje> but gonne try to switch to nouveau now, as I didn't had that issue on it before I switched to nvidia
<Sarvatt> or is there any firefox release where you can't reproduce it so you can rule out things besides firefox being borked?
<dupondje> brb
<dupondje> and indeed
<dupondje> nouveau has no single issue
<Sarvatt> oh you just had the problem with the blob? why am I not surprised? :D
<Sarvatt> was it just with compiz enabled too?
<dupondje> no compiz enabled
<dupondje> not on nvidia nor nouvea
<dupondje> u
<dupondje> :)
<dupondje> so fast with nouveau :) its a dream :D
<dupondje> sadly nouveau doesn't have power control, it kills my battery :D
<dupondje> Sarvatt: we can conclude that the nvidia driver is just 'broken' ? :(
<Sarvatt> 32 bit livecd - compiz isn't garbled but causes lots of pauses with the WAIT in xorg.0.log, glxinfo still locks up the system for 10 seconds or so..  argh :(
<Sarvatt> time to try karmic out again
<Sarvatt> throwing another wrench in it - when i deactivated nvidia-current and activated nvidia-173 it left nvidia-current installed and set up, no wonder if wasn't any different :)
<kklimonda> hey, is there a semi-official ppa with updates for X drivers?
<kklimonda> like newer version of nvidia 195 driver for lucid
<Sarvatt> wow, that sucks.. it actually is a hardware problem i'm having. karmic is screwed up too and so is windows
<Sarvatt> kklimonda: x-updates
<Sarvatt> https://launchpad.net/~ubuntu-x-swat/+archive/x-updates
<Sarvatt> i think tseliot put 195.36.24 in -proposed too if you dont want to jump to 256
<kklimonda> Sarvatt: either I'm blind or there is no 195.36.24 there - only a beta driver. I know that 195.36.24 may get uploaded to lucid-proposed at some point but now I don't see it anywhere.
<Sarvatt> i still have the sources around for the 195.36.24 that was in x-updates before if you want it
<Sarvatt> let me find a PPA to throw it in
<Sarvatt> urg, nouveau 3D is working fine, what the heck
<kklimonda> Sarvatt: I don't need them - I'm just writing a small howto on updating sound and graphics drivers for stable Ubuntu releases. Right now on my LoCo forum there are a lot of people suggesting compiling alsa from sources and installing nvidia drivers from nvidia.com
<Sarvatt> well that place is x-updates, I may have jumped the gun updating to 256 early but the same could be said about upgrading to 195.36.24 because I did it while those were beta too :) the 256 ones will probably be branded official instead of beta in a week given the track record for the past year worth of updates
<dupondje> All we need is nouveau ;)
<Sarvatt> yup nouveau 3D actually works \o/
<Sarvatt> cant get 3D working right with the blob in karmic or lucid all the sudden for some reason
<dupondje> Sarvatt: with git version or what ? :)
<Sarvatt> yea xorg-edgers
<dupondje> sweet :)
<dupondje> Power Management would be sweet also but alot of improvement has been done already
<Sarvatt> need to use the 2.6.34 kernel in the ppa on lucid to use it though, not installed automatically
<dupondje> or Maverick ?
<Sarvatt> yea the one in the PPA is the maverick kernel copied over to lucid
<Sarvatt> nouveau hasn't been working in maverick stock for a few weeks now, needs to be rebuilt..
<dupondje> its a dilemma again :) go Maverick with issues, but bleeding edge :) or stay Lucid :p
<Sarvatt> if you use gnome i would just use lucid+ppas for awhile, maverick is all kinds of messed up thanks to the gtk client side decorations stuff being enabled :)
<dupondje> new kernel version is being pushed to the ppa also it seems :)
<Sarvatt> yeah just saw it was uploaded to maverick and copied it over. pcie aspm finally enabled in a ubuntu kernel \o/
<Sarvatt> what the heck is going on there - http://launchpadlibrarian.net/49099476/buildlog_ubuntu-maverick-i386.xserver-xorg-video-ati_1:6.13.99%2Bgit20100525.428125c0-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
<Sarvatt> just happening on lucid..
<Sarvatt> err maverick
<jcristau> Sarvatt: pkg-config bug
<jcristau> bugs.debian.org/583005
<Sarvatt> happening in debian too?
<Sarvatt> ahh
<jcristau> gcc doesn't like -fvisibility\=hidden too much.
<Sarvatt> hah actually reset my 945 successfully while hung,  echo "wedged : 0" | sudo tee /sys/kernel/debug/dri/0/i915_wedged
<Sarvatt> hmm gnome-control-center's appearance preferences gives a warning that the blob isnt installed and needs to be to activate desktop effects even though it works fine on xorg-edgers, wonder if thats in the desktop effects integration patch or jockey
<Sarvatt> looks like its the jockey-gtk --check-composite call
<Sarvatt> RAOF: you were asking if I packaged up libkms?  http://sarvatt.com/downloads/patches/libkms.patch
<Sarvatt> it still doesn't build though
<RAOF> Sarvatt: Thanks.  I thought that while I was futzing about with egl/gles/openvg I might as well get the kms framebuffer drivers working, too.
<Sarvatt> i've got libegl here too - http://sarvatt.com/downloads/patches/egl.patch
<Sarvatt> the egl/gles stuff needs a seperate branch of mesa 7.8 though i think?
#ubuntu-x 2010-05-26
<RAOF> No; I've got it building here on 7.8
<RAOF> It also runs, as long as you don't ask i965g to have anything to do with it :)
<Sarvatt> well theres a ton of new commits for them here - http://cgit.freedesktop.org/mesa/mesa/log/?h=7.8-gles
<Sarvatt> what the heck are you using i965g for? :D
<RAOF> there are no classic gles drivers.
<Sarvatt> are you building gallium egl or something?
<RAOF> Yeah.
<Sarvatt> hmm that might be why, how are you enabling opengles?
<RAOF> Because the egl_dri2 and egl_glx drivers only do opengl, not gles.
<Sarvatt> --enable-gles1 --enable-gles2 --enable-gles-overlay?
<Sarvatt> i think this is whats fixed in that 7.8-gles branch
<Sarvatt> i see classic support here - http://cgit.freedesktop.org/mesa/mesa/commit/?h=7.8-gles&id=136a938559452e2e4966fe4d990ad9183948868d
<RAOF> Ah, right.
<jg> RAOF: have you been watching freedesktop bug [Bug 28070] [Arrandale] No output (black) on eDP ?
<ubot4> Launchpad bug 28070 in ubuntu "DSDT for laptops with smart batteries (dup-of: 30038)" [Wishlist,New] https://launchpad.net/bugs/28070
<ubot4> Launchpad bug 30038 in gnome-applets (Ubuntu) (and 2 other projects) "SmartBattery load level not shown (dups: 5)" [Undecided,Invalid] https://launchpad.net/bugs/30038
<RAOF> jg: I've seen it; at the moment there doesn't seem to be a resolution to the bug, other than âdamnit, why must monitors always lie?â
<jg> RAOF: they seem to be coming down to just one or two short patches, as of the last day or so.  One of them is clearly suboptimal (always tries to run at highest speed).  Either seems to work, so it looks like just the one is what is necessary, at least from my read of the conversation of the last day or so.
<RAOF> Is this linked to a launchpad bug?  I didn't see.
<jg> RAOF: dunno; I'm happy to enter a launchpad bug for you if that will help.
<Sarvatt> if you do file it against linux because it's not an X related problem at all unfortunately :(
<jg> It wasn't clear when I first ran into the problem that it was Ubuntu; I replicated on Fedora, and got Ajax and the Intel folks on the case (along with the other reports on FDO that I have been watching).
<Sarvatt> jg: do you have an installed system yet? I can ask to have a kernel made with the patches but it wont work on a livecd
<jg> Sarvatt: yeah, its a display driver.
<jg> Sarvatt: I ordered another disk; it's backordered; I can dig up a USB stick, I believe, if that will do.
<Sarvatt> the problem is in the kernel though :(
<jg> Sarvatt: yup.  DRM bug.
<Sarvatt> I wish it was in an X component because I could have had packages for you to test forever ago
<jg> Sarvatt: heh; there are (a few) downsides toward fixing the insanity of the XFree86 driver nonesense.  
<jg> among other things, only a kernel driver can ever have a chance of sanity on an oops, for example.
<jg> Sarvatt, RAOF: should I enter a launchpad bug?
<RAOF> jg: It's not a bad idea, particularly if it's linked to the fdo bug.  That'll make it obvious when it's fixed upstream that there's something we should pick up.
<jg> Sarvatt: particularly annoying is that this laptop has a spashtop running fine on it; so I've seen Linux/X running on the beast...
<jg> RAOF: ok, will do.
<Sarvatt> checking if any of those fixes have been commited to drm-intel-next yet, we have daily kernel builds from that git tree
<Sarvatt> nope intel git hasn't been touched in 2 weeks
<Sarvatt> ahh I may  have found a bug about it
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/554569
<ubot4> Launchpad bug 554569 in linux (Fedora) (and 3 other projects) "[lucid] Blank screen with KMS on Thinkpad X201 with Arrandale (i915) (affects: 22) (heat: 150)" [Undecided,Invalid]
<Sarvatt> they bisected it down to   drm/i915: fix pixel color depth setting on eDP
<jg> that sounds very similar.
<jg> but it isn't color depth, in the fdo bug.
<jg> Sarvatt, RAOF: seems like that bug should get linked to the FDO bug, which may be related.
<jg> Sarvatt, RAOF: the x201 and the HP 2540p are very similar machines.
<Sarvatt> yeah, it's hard to say if its the same problem without seeing the dmesg on yours. did you enable persistant storage on the live usb you used? could mount that and check out the logs from when it failed if so
<Sarvatt> guessing not if you used windows to make the livecd a liveusb 
<Sarvatt> btw on your latitude XT you can just install a kernel from here until it's finally fixed in stable to use KMS - http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.34-lucid/
<jg> cool; I'll probably wait until the weekend on the latitude XT, as my daughter uses it at school during the week (and has lots of homework right now).
<jg> Sarvatt: I got Ajax the dmesg file, IIRC, somehow.
<Sarvatt> oh nice, i'll dig through my logs to find it
<jg> I'll attach the dmesg stuff I sent Ajax and the ROM dump to the bug I'm filing.
<Sarvatt> jg: thanks for that
<Sarvatt> i can build you a livecd image containing the patched kernel if we can get ahold of a patched kernel somehow :D
<jg> Sarvatt: Bug #585651 
<ubot4> Launchpad bug 585651 in xserver-xorg-video-intel (Ubuntu) "Cannot install on HP 2540p laptop (affects: 1)" [Undecided,New] https://launchpad.net/bugs/585651
<jg> boy, I managed to get the number into the channel before the bot did.  Then again, launchpad seems terribly slow in my interactions with it.
<jg> Sarvatt: I'm not so hot to trot that we shouldn't wait until we get a response back upstream; though it does look like just one of the patches is all that should be applied (and is quite tiny).
<bjsnider> Sarvatt, are the vaapi intel bits in the lucid kernel?
<jg> Sarvatt: I screwed up; I filed the bug against the X driver, rather than the kernel.  me bad....
<jg> sorry.
<RAOF> bjsnider: No
<jg> brain not engaged...
<RAOF> bjsnider: They're still getting discussed on intel-gfx; they're not in the *Maverick* kernel (or drm-intel-next)
<bjsnider> what's to discuss?
<RAOF> bjsnider: Um, it's a patch, and a very big one.  There's always something to discuss :)
<Sarvatt> jg: no worries, already moved it and linked the fdo bug to it
<Sarvatt> bjsnider: wont ever be in lucid's kernel
<bjsnider> well ain't that a kick in the pants
<Sarvatt> *might* be in maverick's though
<jg> RAOF, Sarvatt: if the bugs are indeed the same (between the x201 and the HP), the bug is bugging quite a lot of people.  I'm surprised, though, that the x201 problem hadn't been noticed upstream, as I know keithp et. al have x201's they use for testing in Intel.
<Sarvatt> they need to merge it here soon to be in maverick's kernel
<RAOF> The 2.6.35 merge window is closing pretty soon, yeah.
<jg> and ajax said he hadn't seen an eDP laptop in captivity; the x201 has been out much longer, so I suspect there may be two bugs here, with the obviously similar symptom of the panel not working....
<jg> I reproduced this bug in Fedora beta as well.
<jg> (in fact, that dmesg output is from Fedora).
<RAOF> Woot!  pbuilder passes DEB_BUILD_OPTIONS through.
<alf__> RAOF: Hi!
<RAOF> alf__: Howdie.
<RAOF> You'd like a libegl / libgles? :)
<alf__> alf__: Just wondering how that is going :)
<RAOF> I can run all the mesa GLESv1, GLESv2, and OpenVG demos locally; the packaging is pretty much done.
<alf__> RAOF: That's great news! Thanks!
<RAOF> While I'm here I'm going to add the raw kms drivers, too, which needs a new libdrm package.
<RAOF> Your hardware-acceleration mileage will vary depending on what hardware you've got, though, with intel being worst.
<alf__> :D
<tjaalton> is it really useful to add a package for libkms? why not just ship it with libdrm?
<tjaalton> since they depend on each other anyway, right?
<RAOF> libkms depends on libdrm, but not visa-versa
<tjaalton> right
<RAOF> It's a different lib with a different SONAME, and as it's new I'd guess it's signifcantly more likely to bump SONAME than libdrm.
<tjaalton> hmm ok
<RAOF> Although, given libdrm-nouveau, it's possible that libdrm doesn't believe in SONAME.
<tjaalton> well, the packaging seems done, so maybe just use it
<RAOF> Yeah.
<RAOF> Now just to patch the buildsystem to make it build!
<tjaalton> heh
<RAOF> And prod upstream to do something about the patch that I've had sitting there for a couple of months.
<alf__> RAOF: So, when do you expect your packaging changes to be available?
<RAOF> I hope to have them done by the end of the day, but they should be done by the end of tomorrow certainly.
<RAOF> What PPA would you like the lucid packages to end up in?
<alf__> RAOF: Hmm, I should ask asac about this (when I find him, as he is traveling).
<RAOF> Let's warm this room up by building mesa 5 times again!
<hyperair> lol
<blue_anna> hey, I'm on lucid -- Xorg runs between 60% and 80% cpu resources on my machine -- with no video or anything going on
<blue_anna> can you help me diagnose it
<blue_anna> is there any way to completely disable compiz? I have video effects on none already but I think it still uses compiz
<blue_anna> oo nvm, it is metacity
<blue_anna> no compiz
<blue_anna> it was firefox
<blue_anna> ok, I have a set of apges open, that with firefox I get load averages close to 3.0 and Xorg at 60-80% and firefox just behind it .. those same pages loaded into opera gives me opera at 20-30% and xorg just under that, and a load average below 2.0 -- that's too big of a difference for it to be just buggy javascript 
<asac> RAOF: hey ... cool. just push them to one of your ppas .... we will copy them somewhere from there
<Sarvatt> jcristau: have you heard anything more about the pkg-config problem? would reverting http://cgit.freedesktop.org/pkg-config/commit/?id=69a7eaa6763bb0920e2b539fffbad51348d94deb be a wrong way to work around it for now?
<Sarvatt> oh yuck it's got another nasty problem too - https://bugs.freedesktop.org/show_bug.cgi?id=28240
<ubot4> Freedesktop bug 28240 in src "pkg-config 0.24 fails to find 'foo' if foo.pc has an empty Cflags field" [Normal,New]
<jcristau> fdo#28240 is only with external popt aiui
<jcristau> so, yeah, reverting 69a7eaa6763 would fix it.  or just excluding : and = (at least) from the escaped chars.
<Sarvatt> ugh dependencies are all kinds of screwed up in xorg-edgers, added the ppa and did a dist-upgrade from a fresh install and it wanted to remove all video/input xserver-xorg-core xserver-xorg and ubuntu-desktop
<Sarvatt> i must have metapackages removed on all my machines making that not happen
<Sarvatt> RAOF: http://meego.gitorious.org/qemu-maemo/gles-libs
<Sarvatt> checking out the meego release stuff and saw that
<Sarvatt> libgles2-qemu is a library which provides the GLES2 and EGL apis for applications to build against. 
<Sarvatt> It is a open source replacement for closed source libraries such as the SGX libraries and has been
<Sarvatt> tested with Qt and DUI. Due to package structure, it is possible to replace with per-device type
<Sarvatt> GLES libraries such as the SGX libraries in deployment.
<Sarvatt> http://repo.meego.com/MeeGo/releases/1.0/core/repos/source/libgles2-qemu-1.3.0-1.1.src.rpm
<Sarvatt> the moorestown/psb meego release isn't out yet, darn
<micahg> is there any trick if xrandr is showing the wrong resolution for an external monitor aside from restarting x/reboot?
<bjsnider> the broken hdmi audio issue that has been around since the nvidia 190 driver is fixed in the 256 driver
<Sarvatt> ricotz: did you see mutter/gnome shell got a version bump in the latest packages you uploaded?
<ricotz> Sarvatt, yes
<ricotz> Sarvatt, i hope you dont mind when i upload your last mesa package to lucid
<Sarvatt> i didnt because it doesnt build
<Sarvatt> on maverick, was waiting for pkg-config to build to upload todays
<ricotz> Sarvatt, it should build on lucid
<Sarvatt> still on the fence on what to do with it, thinking about just reverting the commit that dropped all demos in a patch
<ricotz> yes i saw this problem
<Sarvatt> and leaving mesa-utils in it
<ricotz> do you not want to go with upstream?
<ricotz> i didnt follow this removal
<ricotz> Sarvatt, why do you asked about g-s? i thought you "hate" it ;-)
<Sarvatt> i use mutter from your PPA
<ricotz> ok
<Sarvatt> doesn't mean i dont follow what goes on in git :)
<bjsnider> how can someone hate something as revolutionary as gnome-shell?
<Sarvatt> run it at 1024x600 and you'll hate it too :D
<bjsnider> why would i do that?
<Sarvatt> thats the resolution i'm at 99% of the time and gnome-shell stinks that small
<bjsnider> well, that's not an appropriate resolution
<Sarvatt> ATI Catalystâ¢ 10.3 Proprietary Linux x86 Display Driver Revision Number: 10.5
<Sarvatt> kaay
<Sarvatt> packaging up fglrx-installer 8.732, anyone want to test it?
<Sarvatt> dont want to put it straight into x-updates because i've never packaged this before, not sure i did it right
<Sarvatt> well i uploaded it for maverick and lucid here - https://launchpad.net/~sarvatt/+archive/ppa
<bjsnider> what do the numbers 10.3, 10.5 and 8.732 signify?
<bjsnider> i mean how is there any difference between what it is they signify?
<Sarvatt> they do monthly releases (10.5 is 5th month in 2010) and the 8.732 is the actual version number for it
<bjsnider> what's the 10.3 for?
<bryceh> march 2010?
<Sarvatt> oh wow, can actually see the client side decorations in maverick if you switch to the dark room theme
<Sarvatt> strange having all windows be transparent
<Sarvatt> not too sure i like that, looks like a mess when you  have lots of windows open :D http://sarvatt.com/downloads/csd.png
<Sarvatt> the browser being transparent is the weirdest part, hope we can control transparency level at least at some point
#ubuntu-x 2010-05-27
<RAOF> Technically that's argb windows rather than csd.  I don't expect darkroom is implementing csd at this point.
<Sarvatt> ahhh there we go, needed to enable compiz blur to make this manageable
<Sarvatt> heh and i get a nice 1 FPS while moving a window with that :)
<Sarvatt> and then compiz dies
<RAOF> At least your drivers support the needed extensions; intel doesn't, last I checked :)
<Sarvatt> i'm on intel :)
<Sarvatt> oh wow gnome-color-chooser
<RAOF> Oh, maybe you're using mipmap blur.
<Sarvatt> gaussian alpha blur works at least, slow as heck though
<Sarvatt> didnt try mipmap
<RAOF> Maybe our shiny new mesa enables it.
<Sarvatt> i dont have the fake opengl 2.0 support enabled in driconf either
<Sarvatt> looks like it was fixed here - http://cgit.freedesktop.org/mesa/mesa/commit/?id=0dc700850acb81c7088ab740959441521f8d38d9
<Sarvatt> fixed in karmic i guess - http://macslow.net/?p=386
<RAOF> notify-osd looks significantly better with blur enabled.  I should have turned it on sooner!
<Sarvatt> ack, chromium controls moved over to the left now too, evil! :)
<Sarvatt> is it horribly slow on 965 too?
<Sarvatt> moving rgba windows around is a slideshow on 945
<RAOF> I really like that chromium's over the other side; that makes it consistent.  Enabling gaussian blur is a significant performance hit, but not abysmal.
<Sarvatt> RAOF: so you're saying lucid + a 2.6.34 kernel is working for nouveau for you too?
<Sarvatt> thats what cnd was saying and I was trying to make sure they aren't actually using nv without realizing it
<RAOF> Sarvatt: Yes.
<Sarvatt> what the heck
<RAOF> The libdrm ABI break doesn't really affect the DDX in everyday use.
<Sarvatt> sure it did, i tested the heck out of it when it first went in, libdrm with 0.0.15 + 0.0.16 kernel did not work
<RAOF> Yeah, but the new libdrm has the 0.0.16 interface.
<Sarvatt> in *lucid*?
<Sarvatt> stock lucid?
<Sarvatt> 2.4.18 with the abi reverts
<RAOF> Oh.  Um.
<Sarvatt> they are saying its working in lucid
<RAOF> ECONTEXT
<Sarvatt> *maverick* has the 2.4.20 libdrm with the new abi, but in #ubuntu-kernel and on the kernel team list tgardner and cnd are saying nouveau is working with the maverick backported kernel in lucid
<RAOF> I am equally perplexed; it totally should be dying with a drm mismatch.
<Sarvatt> they are just using -nv without realizing it as far as I can tell, can't get an xorg.0.log out of anyone :)
<RAOF> I thought this was one layer up the stack; with the ABI of the libdrm_nouveau that the DDX is linked to changing underneath it.
<RAOF> I thought nouveau died in a more spectacular way when that happened.
<Sarvatt> apparently it unregisters cleanly now and nv loads if they are saying it works :D
<Sarvatt> i can't for the life of me figure out what else could be happening
<Sarvatt> thats awesome if that works though, backported kernels aren't supposed to be supported on the desktop anyway they were saying so at least they have nv
<RAOF> Given how much I was looking forward to making a godawful libdrm symlink farm hack, that would be awesome, yes.
<Sarvatt> was really hoping to speak to them about building the agp modules into the kernel at UDS :(
<RAOF> Damn, yeah.
<RAOF> That sucked all round.
<Sarvatt> mesa needs libglew-dev to build now and its in universe :(
<RAOF> You mean mesa-demos, right?
<RAOF> I wonder how many people care about 3D graphics under VMWare.
<Sarvatt> nope mesa, think they removed the bundled version when they split demos out
<Sarvatt> no idea what part of the build actually needs it though..
<RAOF> Doesn't mesa *build* libglew, though?
<Sarvatt> bundled version is still there, hmm
<Sarvatt> the dri target fails to build
<Sarvatt> checking for GLW... configure: error: Package requirements (x11 xt) were not met:
<Sarvatt> No package 'xt' found
<Sarvatt> ok where the heck did i get glew from
 * Sarvatt needs to get off the pc :)
<RAOF> Sarvatt: No, that's it checking a bunch of pkg-config files to get what it needs to *build* GLW.
<Sarvatt> yeah needs xt, i had a commit open where it was checking for glew.pc and got mixed up, sheesh
<RAOF> apt-file says that xt.pc does not exist in Maverick.
<Sarvatt> libxt-dev
<Sarvatt> i've got it installed, hmm
<RAOF> So, my apt-file cache is broken.
<Sarvatt> Filename: pool/main/libx/libxt/libxt-dev_1.0.7-1_i386.deb
<Sarvatt> MD5sum: 26737bd9e76f4893d2fe7643c1a95da3
<Sarvatt> Archive: maverick
<Sarvatt> maybe because it was just copied over from lucid?
<RAOF> Your guess is as good as mine.  Maybe it's just baroke.
<Sarvatt> this libgles-qemu is interesting
<RAOF> It's a bit strange.
<Sarvatt> even debianized
<Sarvatt> the headers are all we need really, they still need the blob libs for each platform packaged to actually do anything with them
<RAOF> Which isn't terribly useful if we want to actually, say, test things on our desktop :)
<Sarvatt> they're different on each platform and testing it on the desktop isn't really useful though, powervr has a package where you can test what it'll actually be like on the devices in the sdk
<RAOF> Sure the extensions will be different, but you'll get the same core APIs, right?
<RAOF> And you're not going to be performance testing on the desktop.
<Sarvatt> the extensions look crazy different on the different devices i looked at
<RAOF> But if you're not using the extensions it doesn't matter; and since the extensions are crazy different you can't use them if you want to be portable.
<bryceh> btw, I noticed that versions-current.html has been broken.  Surprised no one noticed, maybe it's not being used anymore?  Anyway, in case it's still useful it's back online - http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/versions-current.html
<Sarvatt> i dunno just having different extensions available can make things take different code paths
<bryceh> problem was that apt was exhausting its cache, I guess due to too many sources.  Odd.
<Sarvatt> bryceh: it was working a few days ago at least
<bryceh> oh ok.  I don't have a way to see how long it's been broken.
<Sarvatt> i go to it a lot, thanks so much for fixing it :)
<Sarvatt> we're pretty much caught up, just waiting for xserver to be uploaded and the dozens of packages to build against it and such, dont think anyones looking forward to that :)
<Sarvatt> most of those green ones in maverick are in dep wait
<RAOF> We need to merge -intel from experimental, but I can do that once mesa is done.
<Sarvatt> RAOF: http://sarvatt.com/downloads/patches/copy-fb.patch
<Sarvatt> (updated copy-fb patch for 2.11)
<Sarvatt> its in x-updates
<RAOF> Ta.
<Sarvatt> been trying to get fedora to upstream it in #intel-gfx since its broken yet again in intel master
<Sarvatt> the bgnr stuff needs to be upstreamed in xserver though first
<Sarvatt> oh duh fglrx needs the 2.6.34 support patch I'm sure for maverick
<RAOF> And then it'll break with the new X server? :)
<Sarvatt> heheee
<bryceh> I've added a hook to look up the nvidia-graphics-drivers version too
<Sarvatt> does it check git repos or ftp or http directories?
<Sarvatt> you could use say ftp://download.nvidia.com/XFree86/Linux-x86/latest.txt for the upstream versions
<Sarvatt> oh you already do :)
<Sarvatt> was going to say if it checked git the nvidia-settings git repo has the newest ones
<Sarvatt> http://people.freedesktop.org/~aplattner/nvidia-versions.txt
<RAOF> Alright.  Time to head out & collect my new glasses.  Also, luncheon.
 * RAOF wonders what decided to eat all his ram _just_ as the build was about to finish.
<hyperair> RAOF: a browser is a likely candidate.
<hyperair> if i leave deluge's web UI on chromium for more than two days, it can drive my machine into OOM-massacre mode
 * hyperair wails at Sarvatt.
<hyperair> it broke again!
<hyperair> x-x-v-i, i mean
 * hyperair downgrades before cautiously re-enabling gdm
<Sarvatt> when did you upgrade
<Sarvatt> i disabled page flipping a few days ago
<Sarvatt> err disabled the disable page flipping patch! lol
<Sarvatt> are you using an old kernel or something?
<hyperair> just did
<hyperair> 2:2.11.0+git20100526.03bbb4c8-0ubuntu0sarvatt~lucid
<Sarvatt> which was the good one?
<Sarvatt> that you had before
<hyperair> no, my kernel is 2.6.34
<Sarvatt> or do you upgrade every day?
<Sarvatt> i just want to be sure its page flipping thats screwed up for you because i'm disabling it for everyone just based on you :)
<Sarvatt> and not that the drivers broken in other ways after the update which it probably is
<hyperair> i upgrade every day.
<hyperair> 2:2.11.0+git20100525.b645ec83-0ubuntu0sarvatt~lucid
<hyperair> this is the one i'm currently using
<Sarvatt> so its not page flipping
<Sarvatt> drivers just busted, ok
<Sarvatt> updating it :)
<Sarvatt> mesa is a mess right now, haven't been able to update it in like a week
<hyperair> well come to think of it, that driver went bust on me and blackscreened, which is why i lost my uptime and had to reboot in the first place.
<hyperair> which is how i ended up using the new driver.
<hyperair> which then proceeded to go bust on me three times in a row with less than half an hour's worth of uptime each round
<Sarvatt> ok ok new one uploading with disable-pageflip.patch :)
<Sarvatt> i keep trying to drop it because they are actually trying to fix it
<hyperair> i dunno really, it could have been a random error that's not related
<hyperair> after all, my uptime was ~3 days
<hyperair> compared to the previous half an hour uptimes
<Sarvatt> i needed to update to todays git checkout anyway, no biggie :)
<hyperair> well if you don't get other complaints you could always enable it and i can just aptitude hold =p
<Sarvatt> i locked up 4 times in the past 3 days that i'm sure was  because of it :)
<hyperair> ahah
<hyperair> lol
<Sarvatt> the freezes when i dont have that disable page flipping patch are always the same, pc hard locks with the image still on the screen, not pingable and sysrq doesnt work
<hyperair> hmm
<hyperair> i see.
<hyperair> oh well.
<hyperair> ....shit. now i've got a corrupted git repository.
<Sarvatt> i lost my /etc  git repo last time :(
<hyperair> ouch =\
<hyperair> well, i blame ext4
<hyperair> nothing on my btrfs volume went missing.
<Sarvatt> RAOF: wow you've been busy with mesa huh? I'm scared to ask how much longer this takes to build now :)
<Sarvatt> hmm, radeong_dri.so stopped being built in the past few days for some reason it looks like, or it wanted to make my life hard and is called r300_dri.so now
<Sarvatt> haha
<Sarvatt> always great when 7 days of headaches are caused by a tiny stupid change you made :)
<Sarvatt> commented out a line in a confflags-dri section  in mesa's debian/rules, everything after it wasn't getting passed :D only reason i needed all these other build deps was because of that
<Sarvatt> llvmpipe is quite annoying to build during development cycles apparently, oprofile is broken every few days when binutils gets updated making llvm-dev uninstallable
<Sarvatt> RAOF: are you sure you want to use the --with-dri-searchpath method? for libgl1-mesa-dri-gallium? I need to build what you've pushed to see how its set up but there are things hardcoded to  use /usr/lib/dri only that dont honor it we've found :(
<tormod> heya sarvatt!
<Sarvatt> heyo tormod! how the heck have ya been man?
<tormod> remember keyboard layout went a bit wild sometime when running xserver 1.7? do you know the reason?
<tormod> I mean, in xorg-edgers on karmic I think
<tormod> there's an upgrade regression that reminds me of that, bug 583037
<ubot4> Launchpad bug 583037 in xorg-server (Ubuntu) "arrow-left maps to ISO_Level3_Shift (affects: 1) (heat: 8)" [Undecided,Incomplete] https://launchpad.net/bugs/583037
<tormod> bryce, btw your bug robot tagged that bug "hardy" without reason AFAICS
<Sarvatt> that looks like a bug that'll go away once he drops the xorg.conf to me :D i have no idea though, i'm really sketchy in the xkb area since I just use english and occasionally japanese and things just work so I haven't had to fix anything to learn more about it :)
<bryceh> tormod, well I'm sure it has a reason, but probably not a good one.  I'll investigate.
<bryceh> btw, if anyone finds other issues with the automated scripts, file against http://bugs.launchpad.net/arsenal/ and that'll help me keep track of them
<bryceh> Current Operating System: Linux nx6125 2.6.34
<bryceh> what is nx6125?
<Sarvatt> wow llvmpipe *stinks* on a CPU with only SSE2
<Sarvatt> compaq laptop model number is my first guess :)
<Sarvatt> yea google agrees
<bryceh> oh that's the machine name, duh
<bryceh> tormod, bug 586547
<ubot4> Launchpad bug 586547 in arsenal "Tagged bug as 'hardy' inappropriately (affects: 1)" [Undecided,New] https://launchpad.net/bugs/586547
<tormod> bryceh, I have also noticed bug status being changed and then back in one go, like in bug 468413 (after comment 31)
<ubot4> Launchpad bug 468413 in xserver-xorg-video-ati (Ubuntu) (and 1 other project) "Radeon module loaded before agpgart (affects: 17) (heat: 108)" [Undecided,Incomplete] https://launchpad.net/bugs/468413
<bryceh> tormod, actually in that particular case I did that manually
<bryceh> but I have the scripts doing it automatically sometimes too
<bryceh> it does this when the bug is in state Incomplete, since once there is a comment it turns into Incomplete (with response), but it needs to be in Incomplete (without response)
<bryceh> I don't know of any way to achieve getting it into that state except by moving it to some other state and then back to Incomplete
<tormod> oh I see
<bryceh> I have a bug about this open against Launchpad
<bryceh> but it got marked Low, which means it'll probably not get attention
<bryceh> it's easy enough to work around in arsenal so dunno that I'll try to fix it in LP myself
<Sarvatt> yay even more headache, nouveau_class.h was removed from libdrm, mesa 7.8.1 needs it still for nouveau, only master works there :D
<Sarvatt> so debian-experimental doesn't build
<Sarvatt> http://sarvatt.com/downloads/mesa_7.8.1-2_amd64.build
<Sarvatt> RAOF must have built it on lucid with libdrm 2.4.18
<bjsnider> what's the git command that downloads the current snapshot but doesn't grab the entire history?
<hyperair> git clone --depth=1
<hyperair> you can change --depth accordingly to control how many levels of history to download
<bjsnider> i thought there was an actual command separate from clone
<hyperair> no, i don't think there was
<hyperair> there's also fetch
<hyperair> but that's after cloning
<bjsnider> like the "export" command in subversion
<hyperair> git archive?
<bjsnider> what does that one do?
<hyperair> makes a tarball or zip
<hyperair> out of the tree
<hyperair> you can git archive --prefix=asdf/ HEAD | tar -x
<hyperair> which is equivalent to svn export
<hyperair> or you could just cd into another directory and GIT_DIR=/path/to/whatever/.git git checkout HEAD -- .
<Sarvatt> argh, my bad, nouveau_class.h was removed post 2.4.20. commits after the nouveau_class.h removal were cherry picked into debian, I thought they did a git checkout 
<RAOF> Sarvatt: No, debian-experimental doesn't build because I made a typo fixing up a trivial bug.
<Sarvatt> well it didn't build for me because I built it against git libdrm, didn't get to whatever the typo was yet :)
<RAOF> Ah, right.
<RAOF> Sarvatt: What's hardcoded to /usr/lib/dri?
<Sarvatt> when X starts it loads whatever's in /usr/lib/dri and would just load swrast if nouveau_dri.so was missing, not sure if you put that into the gallium package or left it in dri
<RAOF> Ah.
<Sarvatt> like if you install libgl1-mesa-dri-gallium a ton of GLX visuals and GLXFBConfigs go missing compared to when the gallium dri is installed to /usr/lib/dri/, and some people on ati say it causes compiz lockups all over the place
<Sarvatt> did you rename all of the gallium drivers btw?
<Sarvatt> still haven't finished building it, got distracted testing out libkms stuff
<RAOF> No.
<Sarvatt> they dont get used without renaming :(
<Sarvatt> radeong_dri.so = r300_dri.so, swrastg_dri.so swrast_dri.so
#ubuntu-x 2010-05-28
<Sarvatt> i dont know what to do about the gallium stuff though, Replaces: wouldn't work because someone removing libgl1-mesa-dri-gallium wouldn't have the files replaced over libgl1-mesa-dri restored. for now I was just shipping nouveau in libgl1-mesa-dri
<RAOF> So, options include: fixing the DDXs to load from the appropriate search paths & names, using the alternatives system, or conflicts/replaces/provides.
<Sarvatt> ugh, alternatives just might be the best option there :(
<RAOF> If intel had a non-sucky gallium driver I'd plump for conflicts/replaces/provides.
<RAOF> Actually, that could still work - just duplicate i*_dri.so into both packages.  What fun!
<Sarvatt> duplicate every other non-gallium driver too? :D
<Sarvatt> it's just swrast and r300, could just divert those two?
<Sarvatt> llvmpipe swrast seems pretty important if we're going to package r300g, swtnl cards can use it for a huge speedup
<Sarvatt> in 7.9 that is
<Sarvatt> i hate diversions but i think that might be a better option since its just the 2, all the rest of the gallium stuff can just go in /usr/lib/dri and we dont need the dri-searchpath hack if we did that
<Sarvatt> i915g isn't bad at all btw, its just i965g that sucks
<Sarvatt> i915g and i965g have the same names as the classic ones so if you --enable-gallium-intel in the confflags-dri section you get gallium instead of classic btw
<ripps> Do I need to install libkms in xorg-edgers? what's if for exactly?
<Sarvatt> if you have libdrm-dev installed yeah
<Sarvatt> otherwise nope
<Sarvatt> it'll probably be used for plymouth in MM
<RAOF> Sarvatt: Only if you take files from the installed directory.  If I remember correctly, they get put under gallium/ in the build directory, which is where I take them from.
<ripps> I was just wondering, because It wasn't pulled with the other libdrm updates and it sounded kinda important
<Sarvatt> RAOF: they dont here, they go in debian/tmp/usr/lib/dri when i build
<RAOF> That's after running make install.  I take them from build/dri/glx/gallium
<Sarvatt> if i build without --with-dri-driverdir=/usr/lib/dri in the confflags-dri target they do go in gallium/ though
<Sarvatt> ah gotcha
<Sarvatt> ripps: nah not important now, not used for anything
<Sarvatt> it's only used for the xorg gallium state tracker now, and plymouth is planning on switching to it
<RAOF> Z
<RAOF> I think that the vmwgfx dri also wants it.
<Sarvatt> that needs the xorg state tracker
<RAOF> Fair 'nuff.
<RAOF> Given that we've got the relevant kernel module I was thinking of enabling that.
<Sarvatt> yeah planning on doing it in xorg-edgers once all this stuff is worked out for sure, thats why i was messing with enabling libkms before
<Sarvatt> mesa is going to take 2 hours to build in a few weeks at this rate :D
<RAOF> Feel like running that by the Debian dudes?  I don't think they'd have a problem with enabling vmwgfx in experimental.
<Sarvatt> would like to see if it even works first
<Sarvatt> i think it's picky about mesa and kernel versions
<RAOF> Fair enough.
<RAOF> Woot!  I've got Chase's xorg log from 2.6.34+lucid.  Nouveau dies as expected, but fbdev picks up the slack.
<RAOF> That's pretty much the best possible outcome.  Hurray!
<Sarvatt> wow, nice!
<Sarvatt> *that* i didn't expect, thats perfect
<Sarvatt> and makes sense, why didnt that work before?
<Sarvatt> i mean you have the framebuffer fine
<Sarvatt> ohhh i know
<RAOF> Did you test it after VESA stopped trying to claim the device?  I'm not sure if I did.
<Sarvatt> it was because we had vesa loading for kms
<RAOF> Hah :)
<Sarvatt> sweetness :)
<RAOF> Hm.  Is xorg-server 1.8.1+x-x-v-intel 2.11 actually faster at moving windows with all the bling, or is it just vsync working?
<RAOF> Ahem.  Note to self: actually install the new -evdev before loading the new xserver.
<RAOF> Gah.  -synaptics is a much better synaptics driver than evdev :)
<bjsnider> that's why they call it synaptics?
<RAOF> Yup.
<Sarvatt> RAOF: did you build it locally and install with dpkg or in a ppa? i'm curious if you are getting nvidia-current and radeonhd force installed if you did ppa
<RAOF> Built locally, installed with dpkg.
<Sarvatt> i did it in a PPA on top of xorg-edgers and was getting nvidia-current and radeonhd installed after an apt-get upgrade for some reason
<RAOF> If you installed from a PPA I presume you also updated xorg-server?
<RAOF> Installing nouveau_dri into /usr/lib/dri-gallium seems to work fine, too.
<Sarvatt> it's not in /usr/lib/dri/ also?
<RAOF> Nope.
<RAOF> Well, AIGLX does complain trying to load it, but compiz swims along happily
<Sarvatt> hmm, and it loaded from /usr/lib/dri-gallium in Xorg.0.log?
<Sarvatt> ah
<Sarvatt> how many GLX fbconfigs/visuals do you have?
<Sarvatt> http://pastebin.com/JsWNk1rs
<RAOF> Many fewer
<RAOF> 24 and 40 respectively.
<Sarvatt> there's something really screwed up with that combination on ATI at least
<Sarvatt> compiz flips out and crashes all over the place unless the gallium one is in /usr/lib/dri/
<RAOF> Well, I don't have an old enough card to test that, sadly.
<Sarvatt> trying to dig through phoronix forums to find the people that had the problem and  see if i can get morei nfo
<Sarvatt> oh yeah, ripps has the problem too
<Sarvatt> http://pastebin.com/gh6uAmfh (in /usr/lib/dri-gallium) vs http://pastebin.com/csr5BUZi (in /usr/lib/dri) with i915g
<RAOF> Yup, it definitely changes things.
<RAOF> Hm.  virt-manager doesn't like Maverick one little bit.
<Sarvatt> hmm all these people having problems are using gpu's with no hardware TNL that are sketchy anyway
<Sarvatt> ripps: what gpu did you have again?
<ripps> Sarvatt: me? radeon 9600 pro - r300
<ripps> I stopped using gallium a while ago, because it had would create a huge lag when rendering subtitles with gl output in mplayer
<bjsnider> Sarvatt, some of the people you're looking for might be in the #phoronix channel
<Sarvatt> https://bugs.freedesktop.org/attachment.cgi?id=35434 -- i pity the foo trying to run piglet on that
<Sarvatt> 192 visuals sheesh
<RAOF> Man, my intel only has 34
<Sarvatt> yeah intel cut back on the worthless ones just for piglet cus they use it for QA testing every day, it takes a year to run through all those visuals for every test..
<Sarvatt> added a 2.6.34 compatibility patch to x-updates fglrx-installer, just in time for xserver 1.8 to land soon and break it again :)
<Sarvatt> bryceh: did you get that xserver update into -proposed?
<Sarvatt> could have sworn you did but i dont see it
<asac> RAOF: hey master ... how are things going?
<Sarvatt> asac: just curious, you guys know you will need to package up the proprietary libgles/egl/etc for each arm platform to even do anything once you get things building right?
<asac> Sarvatt: yeah ... but we dont need to build against the proprietary drivers
<Sarvatt> asac: he's doing the work in debian-experimental it looks like and its almost done - http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=shortlog;h=refs/heads/debian-experimental
<asac> just drop in the drivers and stuff built against that mesa gles stuff should work 
<asac> cooool
<Sarvatt> have you seen how mameo is doing it?
<asac> nope
<asac> what are they doing?
<Sarvatt> they have a libgles-qemu package with the headers and its even debianized
<asac> ah ... yeah
<Sarvatt> meego sorry
<asac> thats a qemu gles emulation
<RAOF> Not quite as useful for us, at least as far as I'm aware.
<asac> we want to do that too
<asac> but its a bit of a pain to package afaiui
 * RAOF wonders if vmwgfx does egl too.
<RAOF> Hm, yes it does.
<RAOF> So, if that *works* then we'd get gles under vmware (and I'm pretty sure that qemu is at least partially supported).
<asac> hmm. no clue about vmware ...
<asac> do they support arm?
<asac> (/me has doubts about that)
<Sarvatt> http://meego.gitorious.org/qemu-maemo/gles-libs and http://repo.meego.com/MeeGo/releases/1.0/core/repos/source/libgles2-qemu-1.3.0-1.1.src.rpm are interesting
<asac> hmm. so we font have the gles-libs?
<asac> dont
<Sarvatt> depends on what you want from gles libs, the mesa stuff isn't going to work on any arm systems
<asac> ah ok ... now i see its a gl to gles wrapper (actually the other way around)
<RAOF> qemu supports arm, and I know that airlied at least has played at passthrough 3d support.
<asac> yes qemu supports arm
<bryceh> Sarvatt, haven't done any xserver updates since before uds so probably wasn't me
<asac> Sarvatt: mesa doesnt support arm? e.g. not even software rendering?
<asac> anyway, as long as we can build stuff and then drop in the proprietary drivers that would be a big win
<RAOF> That should work, assuming sanity.  The proprietary drivers should be providing their own libGLES*, right?
<Sarvatt> I have no idea, gallium has a hard requirement of DRI2/KMS, dont think the gallium swrast it's using will work on anything outside of maybe omap
<asac> RAOF: i guess so ... i talked to vendors here and they said it should be binary compatible (plus some vendor specific extensions)
<asac> RAOF: does mesa provide a libGLES.so with software implementation?
<asac> or dont we have a libGLES.so at all?
<RAOF> In debian-experimental it provides libGLES{v1,v2}, with swrast.
<asac> sounds like that should work
<RAOF> With swrast, radeon and nouveau drivers.
<RAOF> For both x11 and raw kms framebuffers.
<asac> yeah ... swrast should work unless i am mistaken
<asac> RAOF: so we the package is ready for synching and then pushing to lucid ppa?
<RAOF> It still needs some cleanup, but mostly in non-egl parts.
<RAOF> It takes forever to build mesa :(
<asac> heh
<asac> RAOF: you mean it takes forever on arm?
<asac> or even on intelA
<asac> ?
 * RAOF shudders.
<Sarvatt> i'm scared how long it'll take on arm
<RAOF> It takes ~30minutes or so on my box.
<asac> how long is "foregver">
<asac> heh
<RAOF> More if I'm not building on a tmpfs.
<asac> RAOF: thats decent. your CPU is idle most of the times anyway :)
<RAOF> Heh.
<asac> so finally there is somethign to do
<RAOF> You'd probably be happy with something that does egl in a pretty-much final state now, and then get the final package later, I guess?
<asac> RAOF: all i want is someth9ing i can get clutter build against :)
<asac> so yeah ... i dont care if its clean or anything
<asac> as long as its build and exports all the headers etc. in the -dev i am more than happy
<RAOF> Cool.  I'll do that now, then.
<RAOF> The egl bits are pretty much ok.
<asac> you will do what? building clutter:) ?
<asac> j.k.
<RAOF> :)
<asac> let me know when its in mverick... i will push that to some arm ppa then
<RAOF> Build mesa in a PPA for you to copy from.
<asac> waste some build cycles most likely :)
<asac> RAOF: oh ... if you do that i would be3 eve happpier
<asac> e.g. already do the backport
<Sarvatt> RAOF: oh yeah need to hold off upgrading xserver and friends until pkg-config works on maverick also..
<RAOF> I haven't seen any of that breakage.
<Sarvatt> pkg-config --cflags xorg-server
<RAOF> Right, yes.
<RAOF> I just haven't seen it break any of the packages I've been building.
<RAOF> Presumably because they haven't been pkg-configing xorg-server
<Sarvatt> ati nv radeonhd
<RAOF> I'm pretty sure there are some patches we can drop from xorg-server, too.
<Sarvatt> xorg-edgers only has 6 patches
<Sarvatt> not suggesting dropping a lot but a bunch dont make sense there like the arm one
<RAOF> Soâ¦ why does 1.8.1-1ubuntu1 in pkg-xorg git have so many?
<Sarvatt> because none of them were submitted with attribution to push them upstream :D
<RAOF> So most of them are now upstream?
<Sarvatt> I wish! I've emailed 6 of the original authors of them asking for a git formatted patch that I could push upstream but haven't had any responses and stopped, a lot of them are really old
<Sarvatt> ok finally got a chroot set up to play around with this debian-experimental build since it doesn't build against newer libdrm. lets see if i can stay awake long enough to see the results :)
<RAOF> Sarvatt: You don't have a Maverick chroot already?
<Sarvatt> looks like sis, nouveau, nv, dove, and savage are broken by pkg-config 0.24
<Sarvatt> (still grepping though)
<Sarvatt> video-vmware
<Sarvatt> radeonhd
<Sarvatt> i have *many* but none were in a position to build it
<Sarvatt> not exactly going to to build it on this atom for instance :D
<RAOF> Whyever not?
<RAOF> Hmâ¦
<Sarvatt> takes around 1.5 hours
<Sarvatt> and i'm on battery
<RAOF> Only 1.5 hours?  I'm surprised.
<Sarvatt> awwh heck i have the HDD space on my 16 core xeon vps for mesa!
<RAOF> Where do you have a 16 core xeon vps?
<Sarvatt> thenynoc.com
<Sarvatt> i just dont have much hdd space on it, hard to build kernels with 10gb
<Sarvatt> whoa baby, 7 second git clone of mesa from git.debian.org
<RAOF> That be hella fast.
<asac> RAOF: looking at the gles-libs readme it says:
<asac> Firstly, download and extract Mesa-7.6 and build it after applying a patch to
<asac> enable OpenGL ES 2.0 shader features.
<asac> do we apply that patch?
<RAOF> We do not.
<asac> is that a bad idea?
<asac> or could ew just do that so i can play with gles-libs?
<RAOF> Let me check if that's already enabled in mesa 7.8.
<asac> yeah thats what i was thinking ... at best it would already have made its way upstream
<RAOF> That'll also be enabling support in a diffrent codepath; I'm pretty sure the packages wending their merry way into a PPA will have GLES 2.0 shader features enabled via a different codepath.
<Sarvatt> that gles-libs meego uses doesn't actually build everything there, check out the .spec in the srpm
<asac> i am looking at the git clone of gles-libs atm ... not the rpm
<asac> RAOF: not sure what that means:)
<asac> if it means we dont need to apply that patch i am happy ... if i end up having issues i can come back
<RAOF> asac: That, while we might not have that specific patch, the egl packages in mesa 7.8.1-2 should have that feature anyway.
<asac> ah ok. then lets try without it
<asac> RAOF: what ppa will you push this to?
<asac> (mesa that is)
<RAOF> ppa:raof/mesa-egl
<asac> alf__: ^^
<asac> RAOF: cool. i am going to bed soon. if the package arrives today pleas ping alf__ who might want to ry building clutter on that
<asac> RAOF: what timezon are you in btw?
<RAOF> UTC+10
<RAOF> I'm approaching EOD Friday :)
<asac> ah :)
<asac> heh ok.
<asac> so i guess the package wont be there till monday
<asac> unless you are one of those crazy guys that work on sat :)
<asac> thanks again. talk to you soon
<alf__> RAOF: Great! Thanks a 10^6!
<asac> :)
<Sarvatt> RAOF: dh_install -s --list-missing
<Sarvatt> cp: cannot stat `debian/tmp/usr/lib/libGLESv1_CM.so': No such file or directory
<Sarvatt> dh_install: cp -a debian/tmp/usr/lib/libGLESv1_CM.so debian/libgles1-mesa-dev/usr/lib/ returned exit code 1
<RAOF> Sarvatt: Sorry.  Try again now.
<Sarvatt> oh sweet ya merged it to origin/ubuntu too, thanks
<RAOF> Bah!  No pkg-config files in 7.8.1
<Sarvatt> 7.8-gles branch... :D
<RAOF> Or just steal them from master
<Sarvatt> lets see if master builds with origin/ubuntu debian/
<RAOF> Probably not.
<RAOF> We'll need at least to switch to --enable-gles-overlay
<Sarvatt> DEB_BUILD_OPTIONS="parallel=16" is insane
<RAOF> You're running out of parallelism at that point.
<RAOF> Sweet.  There's all the mesa demos built.
<Sarvatt> 4 minutes and its almost done with dri
<Sarvatt> insane, building the debs now
<Sarvatt> symbols are screwed up
<RAOF> Really?
<RAOF> I only have x86-64 and i386 to test build on, but I thought I'd captured all the relevant processor-specific symbols, and the internal symbols.
<Sarvatt> http://sarvatt.com/downloads/patches/7.8-gles.patch
<Sarvatt> one sec i'll give you the build log when its done, still creating the debs
<Sarvatt> that patch is a git diff origin/7.8 origin/7.8-gles
<RAOF> Ah, right.
<Sarvatt> 09:13.02elapsed
<RAOF> I was wondering :)
<Sarvatt> thats setting up the pbuilder and installing all the deps too, sheesh
<RAOF> BAH.
 * RAOF wants
<RAOF> Well, gles v1 & v2 & openvg work.
<Sarvatt> http://paste.ubuntu.com/440744/
<Sarvatt> symbols
<Sarvatt> want to use my vps RAOF?
<RAOF> Oh, yeah.  Those symbols.
<RAOF> Wait.  That's an i386, 16 core xeon builder?
<Sarvatt> resultant packages are here - http://sarvatt.com/downloads/mesa-gles/
<Sarvatt> doesnt look like clutter needs the .pc's anyway
<Sarvatt> http://git.clutter-project.org/cgit.cgi?url=clutter/tree/configure.ac
<apw> RAOF, yo...
<RAOF> Well, they can get some pc files anyway.  mesa-demos need them, and I like having something to test.
<RAOF> apw: Yo!
<apw> are you aware of reports that ati graphics using the kms drivers makes laptops hot and bothered, presume its doing poor power management
<RAOF> Yes.
<RAOF> It's not so much doing poor power management as having power management totally unimplemented.
<RAOF> Fixed in 2.6.35
<apw> RAOF, hrm, thats going to be annoying for lucid, at least maverick may fix it then
<RAOF> At least, I think that got pulled in with the rest of the drm-next stuff.
<RAOF> Users can turn off kms to get power management, at least.
<RAOF> They'll loose dri2 by doing that, so it's not an unqualified win.
<apw> just turning off KMS gets them power management ?
<RAOF> Yup.
<RAOF> The UMS code has power management.
<apw> people are reporting goodness from switching over to prop. drivers
<apw> ahh ok ... will ask them to test that then and confirm awsome
<RAOF> The prop drivers also have power management, surprisingly enough :)
<RAOF> apw: Aaah, Sarvatt reminded me: are we going to be building the agp modules into the maverick kernel?
<apw> RAOF, do we need to be, i forget already, so many discussions at UDS
<jcristau> there doesn't seem to be another way to ensure agp init happens before drm init aiui
<RAOF> apw: It eliminates a class of bugs where the drm module gets loaded before the agp platform driver and breaks.
<RAOF> There's at least one launchpad bug, let me find it.
<Sarvatt> apw: it's only a problem on laptops supported by fglrx at least
<apw> i did think that at least the intel driver had a link to the AGP driver to make it load first as a dependancy
<jcristau> apw: intel is easy, there's only 1 chipset
<jcristau> so you can just load intel-agp and be happy
<jcristau> for non-igp, not so much
<Sarvatt> nouveau has it worse off by far regarding laptops getting hot
<apw> yeah i see i915 depends on intel-agp directly
<apw> Sarvatt, and nouveau is kms only i assume
<RAOF> Right.  If you're lucky the card gets initialised to the lowest power state by the bios; that's what happens on my laptop.
<apw> oh dear, what a disaster kms is in .32 ... "but its pretty"
<RAOF> Well, nouveau has never had power management.  I don't think nv does, either.
<tseliot> I *think* I read that nouveau it's starting to get power management
<RAOF> Man, my bandwidth up to launchpad sucks.
<RAOF> There haven't been any power-management related commits for nouveau yet, and I haven't seen a branch implementing it.
<RAOF> Heh.  Ben Skeggs commits from the future.
 * tseliot has suddenly become a fortune teller :-P
<RAOF> alf__: https://edge.launchpad.net/~raof/+archive/mesa-egl/+packages â they haven't built yet, but I see no reason why they shouldn't.
<Sarvatt> pulled 7.8-gles into origin/ubuntu and installed the gles and egl pc's, lets see if this builds :)
<Sarvatt> i want to play with the demos too
<alf__> RAOF: Thanks!
<Sarvatt> RAOF: you  uploaded to lucid?
<Sarvatt> Requested 'libdrm_intel >= 2.4.19' but version of libdrm is 2.4.18
<Sarvatt> 7.8-gles branch doesn't even build
<RAOF> Balls.  Oh, well.  One lucid libdrm backport coming right up.
<Sarvatt> has rendercheck been debianized?
<RAOF> Oh, curses.  I should really have bumped the dpkg build-depends for mesa.  Oh, well.  That's now Monday.
<Sarvatt> might be better to just --enable-egl --enable-gles1 --enable-gles2 to get the headers and libEGL and drop gallium for now
<RAOF> As long as you're not building from 7.8.1, yeah.  Those options don't exist in mainline.
<Sarvatt> huh?
<Sarvatt> oh I see
<RAOF> They're probably in the 7.8-gles branch, and they're in master.
<RAOF> Anyway, *this* build will probably work :)
<RAOF> And with that, I disappear.  Like a phantom, into the night.
<Sarvatt> 7.8-gles doesn't build, and the openvg lib isn't there in master
<Sarvatt> done like 30 builds now trying to get things working
<Sarvatt> well your original one is working, I just want .pc's for mesa/demos :D
<Sarvatt> see ya RAOF!
<Sarvatt> well, packaged up rendercheck for the heck of it, i'm not sure about the license though (probably why it isn't in debian yet)
<Sarvatt> 2 files are MIT/X11, the rest are - http://pastebin.com/DBkfk3TR
<Sarvatt> is it acceptable to say make get-orig-source targets for some packages that are basically always going to be vcs snapshots because of infrequent releases? packaging up rendercheck and it looks like it hardly ever has releases even though it's been around since 2004, intel-gpu-tools is the same way
<Sarvatt> was thinking about something like this - http://paste.ubuntu.com/440869/
<Sarvatt> not sure if there's more files I should exclude from the newly packed orig.tar.gz though
<Sarvatt> autom4te.cache?
<Sarvatt> oops minus the rm snapshot-date at the end there
<Sarvatt> openchrome could really use a get-orig-source target
<C10uD> hello, i have two similar issues in two different systems
<C10uD> 1) low end machine running 10.04 with vesa driver (s3 card). once X is started i can't switch to VTs or shutdown/reboot because the screen corrupts
<C10uD> 2) high end machine with nvidia-current closed driver, VTs aren't working. the rest is all fine
<C10uD> any clue on this?
<Sarvatt> well debianized that for the heck of it - http://sarvatt.com/git/cgit.cgi/rendercheck/
<Sarvatt> C10uD: how long have you waited for a VT switch to happen with nvidia-current?
<Sarvatt> it's taken me close to a minute before..
<Sarvatt> C10uD: for both cases I'd try doing a echo "blacklist vga16fb" | sudo tee /etc/modprobe.d/blacklist-local.conf && sudo update-initramfs -u to see if its any better
<C10uD> i think almost a minute, i'll try again.. i'm asking because i wanted to see if with the new beta driver i could get any improvement
<C10uD> thanks Sarvatt i'll try
<Sarvatt> C10uD: did you install the new beta driver from nvidia.com?
<C10uD> not yet
<Sarvatt> thats a recipe for disaster and it doesn't work on anything newer than karmic
<Sarvatt> use this PPA instead - https://launchpad.net/~ubuntu-x-swat/+archive/x-updates
<C10uD> oh, thanks for the info then, btw i was more interested in the problem 1) :p
<C10uD> i'll wait for a new nvidia
<Sarvatt> the new nvidia is in the PPA, drivers from nvidia.com aren't compatible with lucid or newer and probably wont be for a long time
<Sarvatt> to downgrade back to the lucid ones when you have x-updates activated if you don't like the newer beta drivers, just sudo apt-get install ppa-purge && sudo ppa-purge -p x-updates ubuntu-x-swat
<C10uD> bad nvidia :) thanks for the link though, i watched the good ol' nvidia-vdpau repo for updates but no luck for lucid..
<Sarvatt> any reason why you are using vesa with s3?
<bjsnider> that's because the driver is in the x-updates ppa
<Sarvatt> the guy working on nvidia-vdpau is helping us do the x-updates :)
 * Sarvatt points at bjsnider
<bjsnider> jerk, not guy. i prefer jerk
<C10uD> Sarvatt, in this system i don't really need a graphics card, so i just moved the xorg failsafe conf
<Sarvatt> well if vesa is causing problems which is does it might be worth using xserver-xorg-video-s3 instead :D
<C10uD> but, is the x driver capable of corrupting the screen after x is killed? (x noob here)
<C10uD> anyway, now i'll try moving back to auto-recognizing of video card
<Sarvatt> pretty sure vesa is capable of that, yeah. vga16fb/plymouth might be adding an additional layer of screwed up on top of that too :)
<C10uD> i'll try asap then
<Sarvatt> just remove /etc/modprobe.d/blacklist-local.conf and sudo update-initramfs -u again after if blacklisting vga16fb doesn't help
<Sarvatt> what GPU do you have thats screwing up with the nvidia driver?
<C10uD> nvidia 9400
<Sarvatt> best bet would be to boot the nvidia machine up and run ubuntu-bug xorg and paste the link after you submit it here so we can see the logs
<Sarvatt> is it a mobile one? one of the hybrid gpu's?
<C10uD> nope, plain 40$ desktop
<Sarvatt> ah
<bjsnider> 9400 was onboard
<C10uD> i am doing some potentially bad stuff in grub though, such as telling acpi_enforce_resources=lax and setting GRUB_GFXMODE=1280x720
<Sarvatt> i've seen people with 9400M in macbooks unable to vt switch is why i asked
<C10uD> bjsnider, thanks for your ppa though, it helped a lot when i wasn't running lucid :P (even if vdpau was (IS) a little screwed though, seems(ed) like it's not vsync'd)
<C10uD>  NVIDIA GPU GeForce 9400 GT (G96) at PCI:1:0:0 (GPU-0)
<Sarvatt> C10uD: its also possible you have some cruft left behind interfering with things, would be able to see that right away if you did a ubuntu-bug xorg and filed one
<Sarvatt> well ubuntu-bug nvidia-graphics-drivers would be more appropriate
<C10uD> mind if i update the drivers first?
<Sarvatt> hopefully it wont reject the bug because of unverified packages if you do :)
<Sarvatt> if it does just do it via ubuntu-bug xorg
<coz_> Amaranth,  do you have a link to the one report on compiz + intel you had reported on a week or so ago?
<C10uD> anyway, i put the GRUB_GFXMODE thing in grub because plymouth broke up (i think i was still in ubuntu beta) and 1080p didn't seem to work
<Sarvatt> C10uD: yeah you arent gonna get a pretty splash with the nvidia binary drivers, i wouldn't even bother
<C10uD> 720p was almost nice :p
<Sarvatt> i think the text mode splash when you blacklist vga16fb looks better personally
<Sarvatt> 720p 16 color splash...
<bjsnider> C10uD, the ppa is stil relevant even with lucid's packages but i spend more time on the cutting-edge multimedia ppa now
<Sarvatt> theres a way to use uvesafb with the plymouth framebuffer renderer but its a pain in the butt to set up just for a 5 second splash
<C10uD> yes, in fact i was tempted to remove all plymouth plugins
<bjsnider> is somebody here using kde?
<Sarvatt> just blacklist vga16fb and remove splash from the boot stanza, removing all the plugins will probably break things :)
<Sarvatt> the text renderer once you blacklist vga16fb aint bad at all though, just a black screen with ubuntu 10.04 in text on it and 4 dots :)
<C10uD> packages installing... thanks for the tip, i'll try it
<Sarvatt> i need to try the blob with acpi=off, odd nouveau 3D works fine but both karmic and lucid are screwed up and i know karmic's nvidia-185 wasn't screwed up before
<C10uD> Sarvatt, the trick worked great here (nvidia), thank you very much :) i'll try the other system asap
<C10uD> Sarvatt, the vga16fb trick worked also in the other system! many thanks!
<Sarvatt> no worries, vga16fb is evil :)
<C10uD> indeed :(
<knome> hey, any ideas how to restrict my wacom tablet to other monitor in lucid? i'm totally stuck...
<Sarvatt> knome: Option "ScreenNo" "n" ?
<Sarvatt> hmm, what is this.. Create a new source package recipe on code.edge.launchpad.net
<bryceh> yeah I noticed that myself
<bryceh> recipe
<bryceh> sounds yummy, I wonder what it is
<Sarvatt> mmm bzr help builder
<Sarvatt> i'm warming up to bzr so friggin much, if only it wasn't so darn slow
<Sarvatt> nice being able to handle git repos in bzr natively, and just bzr pull to git pull and bzr push to push it
<Sarvatt> oh wow, my mesa packaging branch +  lp:~vcs-imports/mesa/master....
<bryceh> yep
<Sarvatt> niiice, you can just use upstream git + merge only packaging from ubuntu in one recipe
<Sarvatt> thought you'd need a packaging only branch but nope
<Sarvatt> hmm guess i would nest a packaging branch inside the other instead of merge packaging since its only packaging
<Sarvatt> need to figure out the recipe to get the version names decent
<Sarvatt> found a good guide, woot https://wiki.kubuntu.org/DailyBuilds/BzrBuilder
<Sarvatt> doesn't look like you can use git sha's in the version, just bzr revno's :(
<bryceh> sweet
<Sarvatt> woot you can use git, i had a year old version installed and not the bzr-builder in the archives
<Sarvatt> git revision numbers i mean
<Sarvatt> oh jeeze you have to basically replace debian/rules in the recipe?
<Sarvatt> giving it a shot - https://code.edge.launchpad.net/~sarvatt/+recipe/mesadailytest
<Sarvatt> mesa over bzr = pain..
<Sarvatt> could be worse, gcc or the kernel..
<Sarvatt> need to dig into the code to see how to use git revisions in the version, its undocumented in man
<Kangarooo> hello https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-freeze-test theres step 1 1.  Add the apt sources.list lines shown below to your /etc/apt/sources.list, but command deb http://ppa.launchpad.net/ubuntu-x-swat/x-freeze-test/ubuntu jaunty main   doesnt add that
<Kangarooo> anybody alive?
<Kangarooo> so maybe step 1 needs to be removed or added comment that its needed for step 2 or that with ver. 10.04 that package is already in universe
<Kangarooo> also this doesnt work.. Â Â 4.  `sudo INTEL_DEBUG=batch /etc/init.d/gdm restart` it gave some erro http://pastebin.com/G4UCuFpS
<Sarvatt> Kangarooo: that PPA isn't meant to be used any more, nothing in that would even be installed in anything newer than jaunty
<Sarvatt> disabling it now
<Kangarooo> but since to that page links page with is linked in page about newest bugs and i filled one bug and wanted to do this test also.
<Kangarooo> then some steps could be modified?
<Kangarooo> that package intel-gpu-something is also in universe so step 1 can be removed and step 4 changed to "sudo service gdm restart"
<Kangarooo> from https://wiki.ubuntu.com/X/Bugs/Lucidi8xxFreezes i used first link Xfreezes that goes to https://wiki.ubuntu.com/X/Troubleshooting/Freeze and and end theres info about this page https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-freeze-test
#ubuntu-x 2010-05-29
<Kangarooo> err.. can maybe somewhere else found thouse commands from that just diasbled https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-freeze-test ? im almost done with bud reporting i need now thouse last commands ive got system freeze.
<stenten> Kangarooo: What's the problem?
<Kangarooo> i wanted to make bug report more complete with commands from https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-freeze-test link to there was from .. see above post with links
<stenten> What bug?
<stenten> Which bug report, rather.
<Sarvatt> Kangarooo: apport-collect bugnumber will have enough info if you've already filed the bug, otherwise just ubuntu-bug xorg after reproducing it and rebooting
<Sarvatt> intel-gpu-tools is only in universe in karmic and older
<Sarvatt> if you can still ssh in you can run sudo intel-gpu-dump > /path/to/file over ssh while it's hung
<Sarvatt> but its not terribly useful at the moment
<Kangarooo> Sarvatt: i filled about xorg but ive found that i should about some kind xorg-intel-video (ive made offline bugreport already on that computer)
<Sarvatt> xorg is the generic target, it'll get moved over automatically
<Kangarooo> w8 ill show bug report. i put there many files. and wanted also make this x-freeze also
<stenten> Kangaroo: I'm triaging your report now.
<Kangarooo> https://bugs.launchpad.net/bugs/586960
<ubot4> Launchpad bug 586960 in xorg (Ubuntu) "X Freeze at random little load since 10.04 (affects: 1) (heat: 6)" [Undecided,New]
<Kangarooo> ah ok
<stenten> I'll let you know when I'm done. It's a duplicate of a couple different bugs; currently aggregating their info into one meta-bug.
<Kangarooo> ouh yeah as u can see i added also thouse more crash reports if someone else is correct one.
<Sarvatt> yeah that generation of GPU is in a rough shape in lucid (and all current distros for that matter)
<Sarvatt> switching to the vesa driver is probably your best bet
<Kangarooo> eh i needed to rename i915_error_state to .txt so it would open in FF and not ask to DL
<Kangarooo> maybe latest kernel rc7 will help no?
<Kangarooo> ok i results of solution changing to vese will post to that bugreport
<Sarvatt> no, older is what you want
<Sarvatt> support for that GPU is only getting worse and worse over time
<RAOF> Sarvatt: You want the .pc files?  They're packaged in my mesa-egl PPA; I just copied some pre-built ones into the appropriate places :)
<Sarvatt> i duped it to the main bug report for that GPU, there are tons of comments in it with different things you can try
 * RAOF â breakfast
<Sarvatt> looks like there's a kernel you can try as well
<Kangarooo> Sarvatt: well since upgrade to 10.04 was also kernel upgrade ok so i take kernel witch was latest in 9.10 ?
<Kangarooo> in 9.10 all was fine 
<Sarvatt> i've only heard good results from that for people on 855, not 845 :(
<Sarvatt> theres a kernel in the main post of the bug i just duped yours to that should help
<RAOF> Yeah, 845 is a different bug.  I'm not sure that's going anywhere.
<Sarvatt> its a newer kernel but it has some really nasty hacks to help out that cant be in the main kernel because they are so nasty :)
<Kangarooo> ah ok. Workaround D: Use a  kernel other than 2.6.32 so ill try first Vesa workaround and post but only in morning soon ill go to sleep :)
<stenten> Kangarooo: Triaged as Bug #582852
<ubot4> Launchpad bug 582852 in xserver-xorg-video-intel (Ubuntu) "[i845G]X freezes - [drm:i915_gem_idle] *ERROR* hardware wedged (affects: 8) (dups: 3) (heat: 48)" [Undecided,Confirmed] https://launchpad.net/bugs/582852
<Sarvatt> i'd try that kernel with intel first
<stenten> Sarvatt: Sorry, I didn't see you working on it; we were triaging at the same time.
<Sarvatt> well darn, it doesnt show what bug i duped it to before..
<Kangarooo> there in my bug was also apport offline collected ubuntu-bug thrue ssh after freeze happened. maybe some of thouse i should post also?
<stenten> Sarvatt: the i845 GPU Crash apport-crash?
<Sarvatt> yeah already duped all of those others to it
<Sarvatt> its all the same thing
<Sarvatt> bug #541492
<ubot4> Launchpad bug 541492 in xserver-xorg-video-intel (Ubuntu Lucid) (and 2 other projects) "MASTER: [i845] GPU lockup (apport-crash) (Should KMS be blacklisted?) (affects: 52) (dups: 26) (heat: 450)" [High,Triaged] https://launchpad.net/bugs/541492
<Sarvatt> hmm bzr: ERROR: no such option: --append-version
<Sarvatt> http://launchpadlibrarian.net/49284034/buildlog.txt.gz bzr recipe blew up
<Sarvatt> need a get-orig-ource line to build mesa git tarballs if i take this further
<Sarvatt> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. -- how the heck do you merge packaging branches then, need the full source in there?
<pwnguin> its been a looong time since i last paid attention to nvidia drivers
<pwnguin> is nvidia-glx still a package?
<stenten> apt-cache says no.
<pwnguin> looks like nvidia-glx-180 is and so on
<pwnguin> however, dpkg claims to /var/lib/dpkg/available is bunk
<bjsnider> nvidia-current is what it's called now
<Sarvatt> hmmm http://git.openpandora.org/cgi-bin/gitweb.cgi?p=openembedded.git;a=blob;f=recipes/mesa/mesa-dri-7.8/glamo.patch;h=cc55c8b91edccb24807f8799c079f4589a95f72c;hb=HEAD
<Sarvatt> glamo dri driver for mesa 7.8
<Sarvatt> I guess canonical is going to pull another -psb with this arm 3D stuff? even openembedded is just pointing people to ti.com to download the libs - http://git.openpandora.org/cgi-bin/gitweb.cgi?p=openembedded.git;a=blob;f=recipes/powervr-drivers/libgles-omap3.inc;h=2562ed62340ad7616328f5bb1158e1de62981961;hb=HEAD
<asac> Sarvatt: not sure what you mean
<asac> rest assured ... all will be fine ;)
<Sarvatt> Imagination Technologies Ltd ('IMGTEC') hereby grant you permission to use, copy and distribute documents, related graphics and software delivered from this SDK (PowerVR(r) Software) provided that you do not decompile, reverse engineer, or disassemble such software.
<Sarvatt> oh thats a good sign :)
<asac> Sarvatt: it might be similar to psb from the observer
<asac> however, we are moving in the right direction
<asac> and we have much better leverage than with the intel desaster
<asac> point is atm there is zero driver, so having crappy drivers helps us start on innovative technologies, while the license and IP issues are resolved in the background
<Guest94747> hello i dont have /etc/X11/xorg.conf i wanted to put from https://wiki.ubuntu.com/X/Bugs/Lucidi8xxFreezes workaround B changing to vesa
<Guest94747> anyone alive? im trying solution from https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/541492 i added ppa and did update but i got W: Cant get http://ppa.launchpad.net/ubuntu-x-swat/x-freeze-test/ubuntu/dists/lucid/main/binary-i386/Packages.gz  404  Not Found
<ubot4> Launchpad bug 541492 in xserver-xorg-video-intel (Ubuntu Lucid) (and 2 other projects) "MASTER: [i845] GPU lockup (apport-crash) (Should KMS be blacklisted?) (affects: 53) (dups: 27) (heat: 462)" [High,Triaged]
<Guest94747> ah sorry i see thats wrong one.
<Guest94747> how to remove that ppa?
<Sarvatt> <ickle> Sarvatt: you need to have a serious talk with the authors netbook-launcher
<Sarvatt> <ickle> "Make the window one pixel wider than the actual screen size, to sidestep any graphics drivers which assume that a gl window the size of the screen is fullscreen and therefore give preference to painting it.
<Sarvatt> huh, that just might explain why a 2048x15whatever monitor can't use compiz on a gpu with a 2048x2048 max texture size
<Sarvatt> http://paste.ubuntu.com/441419/ -- gles1 and gles2 info on softpipe
<Sarvatt> es2gears is all kinds of screwed up
<Kangarooo> Sarvatt: in that bug to witch duped mine is wirten to try another kernel but that kernel didnt even start pc.bug 541492
<ubot4> Launchpad bug 541492 in xserver-xorg-video-intel (Ubuntu Lucid) (and 2 other projects) "MASTER: [i845] GPU lockup (apport-crash) (Should KMS be blacklisted?) (affects: 53) (dups: 27) (heat: 462)" [High,Triaged] https://launchpad.net/bugs/541492
#ubuntu-x 2010-05-30
<Sarvatt> ricotz: I guess your segfault isnt nouveau specific - http://lists.freedesktop.org/archives/mesa-dev/2010-May/000865.html
<ricotz> Sarvatt, oh, thanks, this sounds promising, i will try this patch later
<Sarvatt> i just told airlied about you having it on nouveau too and the good and bad commits and passed along your backtrace in #dri-devel, might want to join there in case they discuss the problem :D
<Sarvatt> i dont see the problem on i915g, seems to be limited to nouveau and radeon
<Sarvatt> ohh i'm wrong
<Sarvatt> texture_from_pixmap in mesa/demos segfaults the same way on i915g
<Sarvatt> http://pastebin.com/Z3UKydSM
<Sarvatt> jcristau: do you have a script for converting things to xtrace .proto's or did you do dri2 by hand?
<jcristau> Sarvatt: did it by hand
<jcristau> from dri2proto.{h,txt}
<Sarvatt> ah ok, wasn't sure if i was missing out on some magic script before looking into updating some of the protos :)
<Dr_Jakob> Sarvatt: yeah all the gallium drivers share the same dri code.
<Sarvatt> hmm, doesn't glproto need to be updated following http://cgit.freedesktop.org/xorg/proto/glproto/commit/?id=f2b9a6a29edf930f30eade7a0abe40a6d3c4962b ?
 * Sarvatt is updating some things in xtrace's glx.proto
<Sarvatt> err sorry I meant http://cgit.freedesktop.org/mesa/mesa/commit/?h=7.8&id=42ea25cb4ecae09b5cc011a95d42ba7f0645dde3
<Sarvatt> GLX_BLIT_COMPLETE_INTEL was changed to GLX_COPY_COMPLETE_INTEL but its still BLIT in glproto
<Sarvatt> what the heck am I talking about, no glxext.h in glproto!
<Sarvatt> #define GLX_BLIT_COMPLETE_INTEL		0x8181 in glxtokens.h though
<Sarvatt> well sent the patch for it to the lists at any rate, it's COPY instead of BLIT on the official spec - http://www.opengl.org/registry/specs/INTEL/swap_event.txt
<Sarvatt> wonder what that screws up
<Sarvatt> clutter is using BLIT...
<Sarvatt> oh hell, need to add 65k placeholders to put all glx opcodes in xtrace?!
<Sarvatt> wanted to put the GLX_EXT_texture_from_pixmap ones in there at least but those are 1k in even :(
<Sarvatt> guess i'll have to add logic to it to recognize something like SKIP 1000 in the lists
<Bernardo> hi
<Sarvatt> heyo Bernardo
<Bernardo> hi Sarvatt
<Sarvatt> how goes psb by the way? an old friend was asking me about it and i'm not sure how far you guys got it
<Sarvatt> might try to convince him to swap his psb netbook for my aspire one that I've used as my main machine for 1.5 years now, dont think i'm right in the head :)
<Bernardo> I got stuck trying to "free" the psb driver from the moblin or meego repositories
<Bernardo> I've swapped my A1 for my 1101HA... :)
<Sarvatt> yeah its gonna need a bunch of work, i'd just wait for the meego release with mrst support
<Sarvatt> hopefully its not too far off, they didnt release it yet.. its the handset variant
<Bernardo> Yes, they dropped psb from the main release
<Bernardo> the interesting part is that they are merging psb with pvr
<Sarvatt> i think it was only in ivi before
<Sarvatt> wasn't in the main netbook one, pretty sure of that
<Bernardo> it was in the test builds in the main core
<Sarvatt> which aa1 did you have?
<Bernardo> the first one, 8GB slow SSD
<Sarvatt> ah yea thats what i have except the hdd model, i love this thing to death
<Bernardo> which I later replaced with a 32GB CF
<Sarvatt> got 2 10 hour batteries for it and it fits in a coat pocket :)
<Bernardo> It is very nice, but the 7 hour battery is huge
<Bernardo> I now get 6h +- on the 1101
<Bernardo> and a lovely 1366x768 screen
<Bernardo> As for meego/psb, my main problem was that the driver is a large kernel patch, and splitting it to build as dkm module is taking a lot of work. I hadn't done any programming in 10+ years, and it shows
<Bernardo> Sarvatt: did you try building the xorg driver?
<Sarvatt> yeah i haven't been able to justify screwing with it without an actual machine to try it on :)
<Sarvatt> Bernardo: if you do use the meego psb x driver be sure to configure it with --disable-dri2
<Sarvatt> (dri2 needs gallium)
<Bernardo> Yes, i tried passing it to the build. But I get a strange error
<Sarvatt> why dont ya try booting that moblin image with psb on it from january and extract all the blobs it needs from there? i couldn't find it in any source packages but its probably named funky
<Sarvatt> what error?
<Sarvatt> shouldn't be hard to fix, look at other drivers in git during the transition to xorg 7.5
<Sarvatt> should just need the xext check and wrapping some headers behind xserer version check ifdefs, can see what to do from the psb patches you have packaged up now
<Bernardo> no, that I did
<Bernardo> wait
<Sarvatt> oh good clutter checking for GLX_BLIT_COMPLETE_INTEL is wrapped in an #if 0 so that doesnt matter
<Bernardo> I'll turn on the netbook to see if I can reproduce the error
<Sarvatt> oh you got an error after it built? thought ya meant compiling it
<Bernardo> no, building it
<Bernardo> in a header
<Bernardo> I'll just try to reproduce and pastebin it
<Sarvatt> oh yea need to build against crap you dont want to install on a non psb system, gotcha :)
<Bernardo> :)
<Bernardo> also this machine is x86-64
<Bernardo> so I'd need a chroot
<Bernardo> ok, I'm building now. Hopefully it won't take much to get to the build error
<Bernardo> http://pastebin.com/1DeAXKx2 is the error, and http://pastebin.com/0iFw3AER is the header it complains of
<Bernardo> and my limited c knowledge doesn't let my find any error in that header
<Sarvatt> oh
<Sarvatt> you dont use libdrm-poulsbo anymore with those packages
<Bernardo> I added line 582 jut to try to find it
<Bernardo> no, but moblin provides its own psb headers
<Sarvatt> you need the psb-kernel-source srpm headers
<Sarvatt> yeah, you're using those?
<Bernardo> yes, I used those
<Bernardo> unless things got corrupted, I'll try reinstalling the deb I did for them
<Bernardo> psb-headers: /usr/include/psb_drm.h
<Bernardo> should be right, but...
<Sarvatt> are the headers from the same release you grabbed the ddx from?
<Sarvatt> the ones out of the srpm i have handy are #define PSB_PACKAGE_VERSION "5.1.0.32L.0120.1"
<Sarvatt> yours is #define PSB_PACKAGE_VERSION "5.1.0.32L.0124"
<Bernardo> yes, they are all from moblin, built from the moblin repository
<Sarvatt> they have at least 10 different repos though
<Sarvatt> its so darn convoluted
<Bernardo> :(
<Bernardo> I know
<Bernardo> the headers were from psb-headers-1.0.13-1.1.moblin2.src.rpm
<Sarvatt> whats the xf86-video-psb version?
<Bernardo> xf86-video-psb-5.1.0.0112-1.3.moblin2.src.rpm
<Sarvatt> argh my headers were 1.0.12 and from the latest meego, wtf
<Sarvatt> forgot i had moblin stuff in another directory
<Bernardo> I looked at meego, but the 0.9 builds had only the kernel and the headers, not the xorg driver
<Sarvatt> did you build libwsbm too?
<Bernardo> yes
<Sarvatt> to prefix /usr?
<Sarvatt> how about if you use --enable-dri2?
<Bernardo> "/usr/lib/libwsbm.so.1.1.0"
<Bernardo> "/usr/lib/libwsbm.so.1"
<Bernardo> did my deb from the libwsbm-1.1.0-3.11.src.rpm
<Bernardo> ok, time to try that
<Sarvatt> have a /usr/lib/pkg-config/libwsbm.pc?
<Sarvatt> err pkgconfig
<Sarvatt> i'd just remove that and install it locally
<Sarvatt> nah it aint libwsbm anyway
<Bernardo> yes, I also created a dev package with that, the header files and /usr/lib/libwsbm.so (from the rpm spec)
<Bernardo> enable-dri2 doesn't change, it fails the same way
<Bernardo> doh
<Bernardo> #define OV_REGRWBITS_OVADD                       (1 << 0)
<Bernardo> then later uint32_t OVADD;
<Bernardo> I wonder if the moblin guys ever tried to compile this driver or checked these headers
<Sarvatt> do you have any psb junk in /usr/include/drm or /usr/include/X11/dri?
<Sarvatt> (i'd uninstall libdrm-poulsbo too)
<Bernardo> no, nothing there
<Bernardo> let me try removing libdrm-poulsbo then
<Sarvatt> hmm your psb-drm.h is different than mine from the same source package?
<Sarvatt> 	struct {
<Sarvatt> 		uint32_t OVADD;
<Sarvatt> 		uint32_t OGAMC0;
<Sarvatt> 		uint32_t OGAMC1;
<Sarvatt> bah nevermind i'm looking at the meego ones still
<Sarvatt> no, i'm not actually
<Bernardo> I still don't know why gcc doesn't like that uint32_t OVADD;
<Bernardo> I added a line before that, to see if it was some non-printing char between { and uint32_t OVADD;
<Sarvatt> you pastebinned this
<Sarvatt>     struct {
<Sarvatt>                 uint32_t maria_amelia;
<Sarvatt>                 uint32_t OVADD;
<Sarvatt>                 uint32_t OGAMC0;
<Sarvatt> different from mine
<Bernardo> the unedited file is http://pastebin.com/gLcKnJV8
<Sarvatt> oh ok
<Bernardo> Still fails the same way, without libdrm-poulsbo
<Bernardo> I need to add a svn or bzr branch with what I've done so far, so that someone competent can look at it
<Sarvatt> think i'll set up a chroot to test, mind is going numb from working on xtrace all morning
<Bernardo> brb
<Bernardo> :)
<Sarvatt> Bernardo: can you send me all your source?
<Bernardo> wife's calling
<Bernardo> Sarvatt: yes, pm me and I'll tar it and send it to you in 30m
<Sarvatt> okie, need to set up a new chroot anyway
<pwnguin> ok, something went dramatically wrong with 10.04 nvidia the other day
<pwnguin> as in glx is busted and causes gdm / X11 to segfault wrong
<pwnguin> i will say, its nice that i network manager works on the command line
<pwnguin> i'm going to blame  195.36.24-0ubuntu1~10.04 0 500 http://archive.ubuntu.com/ubuntu/ lucid-proposed/restricted Packages
<bjsnider> what does glxinfo give you?
<pwnguin> right now?
<pwnguin> mesa because i installed all that crap
<pwnguin> uninstalled
<pwnguin> i mean, i hope it's mesa
<pwnguin> heh
<pwnguin> glxinfo is not installed =P
<pwnguin> server glx vendor string: SGI
<pwnguin> server glx version string: 1.2
<pwnguin> does glxinfo work without X11 running?
<pwnguin> server glx vendor string: SGI
<pwnguin> server glx version string: 1.2
<pwnguin> doh
<pwnguin> http://pastebin.com/zXM8DZSv
<pwnguin> maybe i'll give nouveau another spin
<bjsnider> what card is this?
<pwnguin> 6600gt
<pwnguin> did i get hit by another round of obseletion?
<bjsnider> it's on the backside of the supported cards list
<bjsnider> i heard once that the 6600 series had some issues but that was a long time ago
<bjsnider> you'd get opengl 2.1 probably instead of 3.3 or 4 if you have a newer card
<bjsnider> the thing to do is to install the blob and troubleshoot any issue that arises, not to put nouveau in there because you don't feel like having to do so
<Sarvatt> pwnguin: if glx was busted the alternatives just werent set up right most likely, might want to just try reenabling it in jockey and it'll probably go away :D
<Sarvatt> hah Bernardo, moblin psb doesnt even compile on moblin, same error
<Sarvatt> it makes it one more file before failing with the same error
<Sarvatt> /bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..    -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm   -I/usr/include/drm -I/usr/include/X11/dri   -I/usr/include/wsbm   -Wall -I.. -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -MT psb_ws_driver.lo -MD -MP -MF .deps/psb_ws_driver.Tpo -c -o psb_ws
<Sarvatt> _driver.lo psb_ws_driver.c
<Sarvatt> In file included from psb_dri.h:37,
<Sarvatt>                  from psb_driver.h:70,
<Sarvatt>                  from psb_dga.c:12:
<Sarvatt> /usr/include/psb_drm.h:582: error: expected identifier or '(' before numeric constant
<Sarvatt> /usr/include/psb_drm.h:583: error: expected ';' before 'uint32_t'
<Sarvatt> ok thought that was less lines, sorry :)
<pwnguin> Sarvatt: interesting
<bjsnider> is that just sloppy code?
<bjsnider> they left out a semicolon?
<bjsnider> Sarvatt, http://www.nvnews.net/vbulletin/showthread.php?t=151479
<bjsnider> that's a spicy meat-a-ball
<Sarvatt> rawr!
<Sarvatt> complete file layout overhaul again right? :)
<bjsnider> yeah, i'm sure
<bjsnider> that would be funny
<bjsnider> just run into nvidia's headquarters and yell "is there a psychiatrist in the house?"
<Sarvatt> so whats fixed?
<bjsnider> that powermizer issue
 * Sarvatt is too busy packaging to look
<Sarvatt> ah
<bjsnider> that's all they put in the changelog, but they leave things out of it these days, so there could be more.
<Sarvatt> oh i didnt even notice that was all the put about it, the one line blended in with the rest of the crap
<bjsnider> yeah but they have gotten into the habit of leaving things out
<Sarvatt> hmm they removed the dithering controls from nvidia-settings too
<bjsnider> remember when they used to put 'improved compatibility with recent kernels' in there? that helped us figure out when we could drop the kernel patches
<Sarvatt> lol
<Sarvatt> i think they stopped because they actually keep on top of it now :)
<bjsnider> nope
<Sarvatt> well not as bad as it used to be at any rate, nothing like fglrx :)
<bjsnider> it was never that bad
<bjsnider> they are always compatible with kernels in use in the distros, yes. but they are not always compatible with newly released kernels
<pwnguin> "update-alternatives: warning: skip creation of /usr/lib32/vdpau/libvdpau_nvidia.so.1 because associated file /usr/lib32/nvidia-current/vdpau/libvdpau_nvidia.so.1 (of link group gl_conf) doesn't exist." 
<Sarvatt> yeah thats just a harmless message
<pwnguin> well you mentioned alternatives so i just wanted to make sure
<Sarvatt> bjsnider: for 2.6.29 it took them well into 2.6.30 to catch up if i remember right
<Sarvatt> err 2.6.28 i mean
<pwnguin> well, i'll reload and see if anything magically is fixed
<Sarvatt> pwnguin: sudo update-alternatives --config gl_conf
<Sarvatt> is nvidia-current picked?
<pwnguin> i have two
<pwnguin> one is manual ode and one is auto mode
<Sarvatt> there's another problem with the nvidia packaging that i've seen, all the headers are in /usr/include/nvidia-whatever/ and no alternatives back to /usr/include/
<Sarvatt> is one of them picked?
<Sarvatt> has a*
<pwnguin> yep
<Sarvatt> yea just dont change it then, you're good to go after a reboot
<pwnguin> i hope
<pwnguin> lets find out
<pwnguin> brb
<Sarvatt> unless you did something else like install fglrx...
<Sarvatt> If intel_iommu=off prevents the crash, then this is a bug which should be fixed in the next release.
<Sarvatt> oh boy :)
<Sarvatt> new releases out the wazoo
<pwnguin> im not crazy
<pwnguin> i know its hard to tell right now, but im not generally clueless
<Sarvatt> its not working?
<pwnguin> not yet but i'll get it there. lemme try a few things first
<Sarvatt> or was that in response to the fglrx comment.. I'm slow :)
<pwnguin> fglrx
<pwnguin> this box is going to be a bit quirky
<pwnguin> its been dist-upgraded since warty
<Sarvatt> wow those new nvidia blobs built fast in x-updates
<pwnguin> alright, i gave jockey a chance to configure things as it sees fit, we'll see if its smarter than me
<pwnguin> brb again
<Sarvatt> did you make any changes in /etc.X11/xorg.conf?
<Sarvatt> before when the crashes started
<pwnguin> well here's the deal
<pwnguin> the desktop hardlocked
<pwnguin> so i rebooted
<pwnguin> came back and decided it might be video playback and checked for updates to banshee and nvidia
<pwnguin> low and behold, nvidia had updates
<pwnguin> updated from proposed and when i came back it tanked hard.
<Sarvatt> hmm mesa update in lucid-updates?
<pwnguin> it was all kinds of messed up
<pwnguin> dpkg's available packages file was nicely corrupted or something
<pwnguin> so apt-get wasn't working on install
<pwnguin> then the filesystem crashed and went readonly
<pwnguin> so im not really ready to blame anything at the moment other than me or my old computer
<pwnguin> anyways, i moved my xorg.conf out of the way and removed all the nvidia components, and then gdm stopped crashing
<pwnguin> if i can reproduce the problem then it's just the worlds least fortunate series of events
<pwnguin> ah, sweet relief
<pwnguin> server glx vendor string: NVIDIA Corporation
<pwnguin> server glx version string: 1.4
<pwnguin> fonts look odd though
<pwnguin> maybe it's just an illusion from dealing with crappy resolution
<pwnguin> Sarvatt: thanks for the tips and attention
<pwnguin> worst dist-upgrade evar
<pwnguin> and thats including the time someone uploaded a busted nvidia that spwaned the invention of -proposed
<Sarvatt> looks like i find some other kind of bug with busted nvidia, just spent the past hour fighting that machine while the wife waited to use it.. lol
<Sarvatt> activate nvidia-173, reboot, purge nvidia-173 and upgrade kernel
<Sarvatt> wouldn't let me install nvidia-current again, i was getting those funky nvidia-173 already removed messages in the jockey log some guy had in here the other day
<Sarvatt> like it updated the wrong initramfs and left 173 stuff in the old one
<bjsnider> does your wife prefer linux or some other operating system?
<Sarvatt> shes using one of my laptops now so she doesnt get a choice :D only thing she misses is photoshop though
<bjsnider> photoplop
#ubuntu-x 2011-05-23
<RAOF> While I'm in the neighbourhood, is there any reason we would not want the new xkb-data from experimental?
<tjaalton> RAOF: probably none
<RAOF> I'll finish off this merge, then.
<dantti> hi, I'm running natty and since the upgrade my X + nvidia is really unstable, I tought it was a hardware problem (since the screen got corrupted), but now I have a way to make X uses 100% of my CPU, is there a way to upgrade my X to see if it fixes or downgrade it?
<bryce> 100% cpu bugs are usually client issues
<dantti> I installed openSuse with the same nvidia driver version, and the bug does not occur
<dantti> I've found out that every time I maximize Konsole the screen stops responding
<dantti> on my both laptops GF8400 and GF230
<bryce> sounds like you found your faulty client
<dantti> bryce: don't you think if it was Konsole in openSuse I should have the same problem?
<bryce> not necessarily
<dantti> bryce: what do you suggest so that I can fix this issue?
<dantti> my X also freezes when I put nv-setting to use my vga -> TV works the first time, but when I disable X goes 100%... (which also does not happen in opensuse)
<dantti> tought it might have a different X and it does have a different kernel version...
<bryce> if it's konsole, talk to kubuntu/kde/etc. folks.  https://wiki.ubuntu.com/X/Troubleshooting/HighCPU
<bryce> dantti, or switch to gnome ;-)
<dantti> bryce: :P that's unlikely to happen as I develop K stuff :P
<dantti> bryce: btw I killed kwin, konsole and X still 100%, seems more a nv driver issue with the current X + kernel setup (I think) since the other distro doesn't show the issue :/
<ricotz> bjsnider, hey, is 275.09 available in a ppa for brave testers? ;)
<ricotz> Sarvatt, hey
<Sarvatt> ricotz: heyo! whats up?
<ricotz> Sarvatt, how are you? :)
<ricotz> by any chance, did you upload 275.09 somewhere?
<Sarvatt> ricotz: eh, just eating some lunch while a system reinstalls. no I didn't, haven't worked out what to do with modaliases yet because nvidia_supported doesn't work
<Sarvatt> tseliot did a change to just use the list in the README.txt but thats missing about 240 id's :(
<ricotz> hehe, alright, i just felt brave enough to make my system more cracky than it is already :P
<Sarvatt> there was talk of making jockey pull blob updates from x-updates automatically at UDS and figured it'd be better to go stable in there for now too :)
<Sarvatt> ricotz: i'll get it packaged up today and let ya know
<ricotz> i see, but edgers could include it then ;)
<Sarvatt> yepyep
<ricotz> great, thanks!
<tseliot> Sarvatt: Nvidia don't guarantee that what we extract from the blob is supported. The README is their list of officially supported cards
<tseliot> (i.e. some cards extracted from the blob may be only partially supported)
<tseliot> Sarvatt: BTW mine is only a fallback. If the blob contains something useful, we use that
<tseliot> Sarvatt: at least this is what I remember coding ;)
<bjsnider> i don't understand how nvidia can justify not officially supporting a card
<bjsnider> ricotz, i can't install the gnome-icon-theme-extras package because of a screwy dependency
<bjsnider> the way the dependency is written would make it impossible for anyone to install
<ricotz> bjsnider, let me look, i dont have it installed
<bjsnider> it depends on two mutually exclusive versions of gnome-icon-theme
<ricotz> bjsnider, this looks wrong
<bjsnider> i thought you were going to say you did that on purpose because -extras has a file that would overwrite a file in another package
<ricotz> bjsnider, this is a sync from debian
<bjsnider> the control file is screwed up in debian too?
<ricotz> bjsnider, yes
<ricotz> bjsnider, i hope you can live without them for now ;)
<bjsnider> i get constant x crashes without that package
<bjsnider> i can only keep x going for 3 minutes and 12 seconds
<ricotz> bjsnider, huh? seriously, these are icon themes...
<bjsnider> i'm just kidding you
<ricotz> :P
<bjsnider> Sarvatt, did you see this: http://www.phoronix.com/scan.php?page=article&item=intel_snbsds_compare&num=1
<Sarvatt> bjsnider: Intel's OpenGL stack on windows sucks? color me shocked :)
<bjsnider> he should be testing against direct3d performance
<Sarvatt> got me curious to see current sandybridge vs fglrx HD 5470m since those gpus are pretty much equal on the directx side in windows
<Sarvatt> ugh this E6420 can not handle a i7-2820QM, Core 0:      +63.0Â°C  (high = +86.0Â°C, crit = +100.0Â°C)  idle
#ubuntu-x 2011-05-24
<tjaalton> bryce: hey, you could run bugbot to close all the lrm-2.6.24 bugs, since hardy desktop is EOL'd
<tjaalton> or the arsenal scripts, whatever they are called :)
<bryce> tjaalton, sure
<bryce> will do tomorrow
<tjaalton> bryce: great. another thing, the versions-current.html -page needs oneiric :)
<bryce> tjaalton, ok, I'll update that too
<tjaalton> hmm pixman still not synced
<tjaalton> ah, it is
<tjaalton> of course, i was looking at the natty column duh
<tjaalton> I'll see which drivers could be dropped from *-all
<tjaalton> looks like at least old tridents are better off with vesa, since the native driver is trying to use 24bit depth with 8x6
<tjaalton> i think people with a laptop that has a 460MHz celeron have bigger problems :)
<bryce> tjaalton, tis up:  http://bryceharrington.org/X/Reports/ubuntu-x-swat/versions-current.html
<janimo> Are there any x86/amd64 specific bits that are hardcoded and run on every X start? I am wondering if there are things to omit in an ARM specific config to improve startup speed and maybe footprint
<tjaalton> bryce: ooh, thanks
<gord> hi all, just wondering if you guys have heard of lots of graphical glitches happening with the intel HD 3000 chipset on 11.04 
<RAOF> janimo: Mainly driver probing stuff in xf86Config, but there's already an ARM #ifdef there to make those platforms work (since X is pretty wedded to the idea that probeable graphics cards exist only on a PCI bus).
<janimo> RAOF, so nothing to make ARM start faster than it does now without losing generality and cleanliness
<janimo> we just probably need to not ship x86 specific video drivers on our ARM images
<jcristau> ajax removed a bunch of sleeps on the startup path a few years ago, there shouldn't be much of that left
<janimo> any of the new (KMS and related) things baked in? ARM hw unfortunately have only proprietary drivers ATM which probably don't use this yet
<jcristau> where are you seeing it take time?
<jcristau> and no, none of the kms stuff is in the server itself
<janimo> jcristau, not seeing it taking time, just asking around to see if there are known issues and to see if it is worth looking into further
<janimo> thanks
<janimo> as part of generally making arm boot faster
<Sarvatt> ricotz: sorry about that man, looks like the upload didn't go through last night and I just noticed
<Sarvatt> ricotz: it's uploaded now
<ricotz> Sarvatt, no problem :-), thanks
<Sarvatt> uploaded it to xorg-edgers btw
<Sarvatt> and https://launchpad.net/~sarvatt/+archive/nvidia
<ricotz> i found it :P, hopefully it wont break gnome-shell
<mgariepy> hello, last week i opened 2 bugs concerning xorg on intel hardware on natty. those are lp #785368 and #785280 which make LTSP not usable with natty.
<ubot4> Launchpad bug 785368 in mesa (Ubuntu) "dri not working with ltsp on natty (affects: 2) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/785368
<ubot4> Launchpad bug 785280 in xserver-xorg-video-intel (Ubuntu) "transparency not working with intel driver and LTSP (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/785280
<tjaalton> mgariepy: run 'ubuntu-bug 785368' from a ltsp session to attach logs to the bug
<ubot4> Launchpad bug 785368 in mesa (Ubuntu) "dri not working with ltsp on natty (affects: 2) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/785368
<tjaalton> the other bug depends on the first bug..
<tjaalton> so i'd probably dupe them
<mgariepy> tjaalton, ok i will do this right now you should have the trace in half an hour :) thanks
<jcristau> i thought dri2 had a LocalClient check
<tjaalton> mgariepy: is the laptop a standalone installation?
<mgariepy> i booted the laptop as a thin client
<tjaalton> right, so it's the same bug
<mgariepy> i also have natty on the laptop and it works fine
<tjaalton> which confirms it
<tjaalton> so i duped the other bug
<mgariepy> ok
<mgariepy> i'm updating my chroot i'll have the trace soon :)
<tjaalton> trace?
<mgariepy> ubuntu-bug 785368
<ubot4> Launchpad bug 785368 in mesa (Ubuntu) "dri not working with ltsp on natty (affects: 2) (dups: 1) (heat: 784)" [Undecided,New] https://launchpad.net/bugs/785368
<tjaalton> ah
<mgariepy> tjaalton, ubuntu-bug 785368 doesn't work.
<ubot4> Launchpad bug 785368 in mesa (Ubuntu) "dri not working with ltsp on natty (affects: 2) (dups: 1) (heat: 784)" [Undecided,New] https://launchpad.net/bugs/785368
<mgariepy> it says Error : invalid PID
<tjaalton> uh
<tjaalton> ok, so, apport-collect 785368 might be better?
<tjaalton> hmm, wonder how many times I've told the wrong thing
<mgariepy> tjaalton, it's done, if you need more information, just tell me. :)
<tjaalton> mgariepy: yeah, please attach /var/log/Xorg.0.log
<tjaalton> wonder why apport-collect didnt'
<mgariepy> tjaalton, xorg runs on the thin client :)
<tjaalton> and the problem is there
<tjaalton> where did you run this?
<tjaalton> apport-collect
<mgariepy> on the applications server
<mgariepy> it was working fine on maverick
<tjaalton> right, so I said run it from the session
<tjaalton> might just be something that ltsp fails to set up in natty
<mgariepy> maybe 
<tjaalton> dinner ->
<mgariepy> i also tried a maverick thin client and a natty appserv and compiz/3d is still not working.
<mgariepy> the transparency problem is not present tho.
<mgariepy> have a nice dinner :)
<tjaalton> so please ask the ltsp devs too
<tjaalton> gone for real ->
<mgariepy> tjaalton, i'm a ltsp dev.
<mgariepy> :)
<ricotz> Sarvatt, 275.09 runs without issues :-)
<Sarvatt> i'm worried about agp 6xxx+ cards
<Sarvatt> those report the pci id of the pcie to agp bridge chip on the card instead of the actual GPU and aren't in the modalias list in the README.txt..
<Sarvatt> err pci id list that we make the modalias list from I mean
<ricotz> hmm, i see
<Sarvatt> continuing the list here - https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-s3virge/+bug/787620
<ubot4> Launchpad bug 787620 in xserver-xorg-video-s3virge (Ubuntu) "Sync xserver-xorg-video-s3virge 1:1.10.4-4 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-s3/+bug/787624
<ubot4> Launchpad bug 787624 in xserver-xorg-video-s3 (Ubuntu) "Sync xserver-xorg-video-s3 1:0.6.3-4 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<Sarvatt> siliconmotion needs a merge for 01_siliconmotion_rotate_option_disables_randr.diff, other patch is upstream
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-rendition/+bug/787626
<ubot4> Launchpad bug 787626 in xserver-xorg-video-rendition (Ubuntu) "Sync xserver-xorg-video-rendition 1:4.2.4-2 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-qxl/+bug/787630
<ubot4> Launchpad bug 787630 in xserver-xorg-video-qxl (Ubuntu) "Sync xserver-xorg-video-qxl 0.0.13-1 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<tjaalton> Sarvatt: yeah I got accepted to the sponsors team, so I can unsub it when confirming the bug
<tjaalton> on it now
<Sarvatt> awesome!
<Sarvatt> we had so much delta from xserver 1.9
<tjaalton> Sarvatt: guess that's all for now?
<Sarvatt> got distracted with that compiz bug
<Sarvatt> https://bugs.launchpad.net/bugs/787639
<ubot4> Launchpad bug 787639 in xserver-xorg-video-i740 (Ubuntu) "Sync xserver-xorg-video-i740 1:1.3.2-4 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-i128/+bug/787640
<ubot4> Launchpad bug 787640 in xserver-xorg-video-i128 (Ubuntu) "Sync xserver-xorg-video-i128 1:1.3.4-2 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<tjaalton> ooh build logs too
<tjaalton> mgariepy: from the client xserver POV dri2 should work, so I'm pretty sure it's the ltsp setup that's broken
<Sarvatt> yeah thats why its taking so long for each
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-chips/+bug/787644
<ubot4> Launchpad bug 787644 in xserver-xorg-video-chips (Ubuntu) "Sync xserver-xorg-video-chips 1:1.2.4-1 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<mgariepy> tjaalton, from the client i can run glxgears without any issue but from the applications server it doesn't work
<tjaalton> mgariepy: uh, so why didn't the bug say anything about it?
<tjaalton> all this time I thought it was the _client_ not working
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ark/+bug/787649
<mgariepy> 6) when connected via ssh on the same computer, running the same command works.
<ubot4> Launchpad bug 787649 in xserver-xorg-video-ark (Ubuntu) "Sync xserver-xorg-video-ark 1:0.7.3-2 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<tjaalton> mgariepy: so you're remotely trying to open windows on the client screens?
<mgariepy> that's more or less how ltsp works.
<tjaalton> i thought they just netboot the chroot
<tjaalton> oh well
<mgariepy> i'm able to open a session on the applications server and show it on the thin client but when dri try to render through the network it fails to connect. 
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-apm/+bug/787651
<ubot4> Launchpad bug 787651 in xserver-xorg-video-apm (Ubuntu) "Sync xserver-xorg-video-apm 1:1.2.3-2 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<tjaalton> mgariepy: maybe I could try to reproduce it.. but not today
<jcristau> looks like i can reproduce the DRI2Connect BadRequest here
<tjaalton> ah :)
<jcristau> ($work uses ltsp, on squeeze i think)
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-mouse/+bug/787653
<ubot4> Launchpad bug 787653 in xserver-xorg-input-mouse (Ubuntu) "Sync xserver-xorg-input-mouse 1:1.7.0-2 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<Sarvatt> hrm we're dropping keyboard aren't we? so no point syncing it?
<Sarvatt> tjaalton: yeah I'm done for now, thanks a ton for all the help on those
<tjaalton> Sarvatt: -acecad, -aiptek?-)
<Sarvatt> oh how did I miss those
<tjaalton> did you use versions-current.html?
<Sarvatt> yep was just going up the list, i've got 10 things going on at once verifying the deltas building and requesting a sync at the same time
<tjaalton> hehe
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-acecad/+bug/787658
<ubot4> Launchpad bug 787658 in xserver-xorg-input-acecad (Ubuntu) "Sync xserver-xorg-input-acecad 1:1.5.0-1 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-aiptek/+bug/787663
<ubot4> Launchpad bug 787663 in xserver-xorg-input-aiptek (Ubuntu) "Sync xserver-xorg-input-aiptek 1:1.4.0-1 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<Sarvatt> tjaalton: forgot another, last one I promise :) https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-vesa/+bug/787673
<ubot4> Launchpad bug 787673 in xserver-xorg-video-vesa (Ubuntu) "Sync xserver-xorg-video-vesa 1:2.3.0-5 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
<Sarvatt> so which PPA  should we should use for lucid sandybridge backports? new one under ubuntu-x-swat?
<Sarvatt> a little too invasive for x-updates IMO
<Sarvatt> and do we want whats in natty backported, or more current stuff?
<Sarvatt> it'd be funny to have the lucid sandybridge support better off than natty :)
<Sarvatt> bryce, tjaalton: would one of you guys mind creating a new PPA in the ubuntu-x-swat namespace for this sandybridge backport stuff, something like X Backports
<bryce> Sarvatt, sure
<bryce> Sarvatt, although, could there be any potential value in just putting it into ubuntu-backports rather than a ppa?
<bryce> well, we planned to do a backports ppa and a staging area for the lts
<Sarvatt> bryce: yeah I just want to do libdrm, x-x-v-intel, mesa for now, maybe it would make sense to have this separate
<bryce> ah, like a trial run for our official lts backport ppa?
<tjaalton> yep
<bryce> Sarvatt, how long does this ppa need to exist?  I'm wondering if we can make one ppa and then transition it into the lts backports ppa, or if it does in fact need to be separate?
<tjaalton> we need a staging area anyway
<tjaalton> i guess the packaging changes might take a couple of revisions to mature
<bryce> ok, here is https://launchpad.net/~ubuntu-x-swat/+archive/x-backports
<bryce> I'll work on a description to help distinguish it from x-updates
<achiang> hello, is this the appropriate channel for gdm questions?
<tjaalton> #ubuntu-desktop is better
<achiang> thanks
<Sarvatt> so backport from natty then right?
<Sarvatt> doing libdrm now
<bryce> yep
<bryce> I've drafted a description for the ppa - https://launchpad.net/~ubuntu-x-swat/+archive/x-backports
<tjaalton> Sarvatt: yeah, i'd say keep the moving parts to minimum at least for now
<bryce> Sarvatt, tjaalton, please read it over and make sure it jives with what you guys are having in mind
<Sarvatt> oneiric -> lucid will be fun with multiarch
<bryce> jives? jibes?
<Sarvatt> we should be sure to version this stuff lower than natty
<bryce> anyway, I'll leave the ppa in your guys' capable hands from here on out, but let me know if you need any help
<Sarvatt> looks good to me!
<tjaalton> did we decide not to do major xserver updates in the backports?
<bryce> yeah, you'll want to come up with a versioning pattern
<Sarvatt> ~backport1 ?
<tjaalton> was about to suggest that :)
<Sarvatt> i'd rather skip the server but then we have nouveau :)
<tjaalton> does it dpend on a newer xserver?
<tjaalton> +e
<bryce> mightn't you need it for input driver updates?
<Sarvatt> yep all the time
<Sarvatt> oh boy, good point :)
<bryce> well, you guys can play it by ear
<tjaalton> this deserves a wikipage to hash out the policy for these
<bryce> if you do come up with some good policies, make sure to add to the description
<bryce> yeah
<Sarvatt> so maybe a different PPA would be better for the sandybridge only stuff, we're going to break people horribly while we transition if they keep using it
<tjaalton> yeah, it could be a throwaway ppa, and used for testing how this all works
<bryce> tjaalton, btw I'm down to just wordsmithing of the arsenal script to close out the lrm-2.4.24 bugs; this is what I've got drafted currently:  http://pastebin.ubuntu.com/612395/
<tjaalton> and once we have some first hand exp with it we can start making something more official
<Sarvatt> https://launchpad.net/~xorg-edgers/+archive/backport-testing throwaway PPA
<bryce> sounds good
<bryce> thanks for doing it on xorg-edgers; that'll help minimize confusion later
<bryce> tjaalton, I'm wondering about dropping the third paragraph, although without it I feel like people are being told to GTFO
<tjaalton> bryce: well, maybe point out that the issue is possibly fixed on a newer release
<bryce> ah true
<Sarvatt> libdrm is turning out to be a pretty big diff, forgot it was multiarched
<Sarvatt> http://sarvatt.com/downloads/libdrm_2.4.23-1ubuntu6~backport1.debdiff hope I'm not missing anything there :)
<Sarvatt> xutils-dev should really be in lucid-backports
<jcristau> backports are teh pain :)
<Sarvatt> any opinions on what I should do with xutils-dev? ~backport1 doesn't really work with that versioning
<Sarvatt> 1:7.6+3 > 1:7.6+3~backport1
<Sarvatt> ah i'm changing every package anyway, not a big deal fixing the xutils-dev build deps for anything needing +3 specifically
<jcristau> make the build deps 1:7.6+3~ in trunk if you want?
<mgariepy> tjaalton, i added a patch for mesa to LP: #785368, and the transparency problem in from LP: #785280  still present
<mgariepy> i'll be back in ~15hours 
<tjaalton> mgariepy: nice
<mgariepy> yeah :)
<mgariepy> cya
<mgariepy> do you have any idea what is the problem for the transparency ?
<tjaalton> nope
<tjaalton> works fine on my 965
<mgariepy> if i install maverick package for xserver-xorg-video-intel on natty it works
<mgariepy> it works on a desktop but not on ltsp
<mgariepy> anyway thanks for your help today :)
#ubuntu-x 2011-05-25
<bryce> tjaalton, whew, I ended up having to basically rewrite arsenal's launchpadlib authentication system but finally I wontfixed all those lrm bugs :-)
<RAOF> Yay!
<bryce> was also a good opportunity to do a better way to set scripts to run as bugbot
<bryce> now it can be controlled via a simple config flag in the scripts themselves
<bryce> alright, time to go play with the kiddo, cya
<RAOF> Have fun!
<tjaalton> bryce: whoa..
<tjaalton> btw, could the drm bits be split from the kernel as a dkms package? I'm thinking it's the best way to scale and provide the backported stack for the masses
<tjaalton> maybe it was discussed at uds, but the lts-backport ppa should track kernel security releases, and it's a lot of work
<tjaalton> with a drm-dkms package it could be used with the official kernel (which might be needed for stuff like ksplice)
<tjaalton> hmm, breakfast ->
<RAOF> tjaalton: That would be more appropriate if airlied made good on his threat to go back to a separate drm tree; the benefit and curse of drm being maintained in mainline is that it gets to tie itself in with other code.
<tjaalton> RAOF: hmm i thought it was pretty much self-contained and not tied to the rest of the kernel
<RAOF> There are a (growing?) number of fingers in other pies; acpi an the VM subsystem spring to mind.
<RAOF> s/ an / and /
<tjaalton> ah yes, acpi..
<RAOF> And, going forward, if linaro has anything to do with it there'll be interactions with v4l2, etc.
<tjaalton> do you recall where and when did airlied threat to do that?
<RAOF> On one of the drm pull request pushback threads on dri-devel where Linus (again) complained about drm churn, and Dave in reply complained that the kernel release schedule means that it takes about 6 months for hardware support to hit users.
<RAOF> I can hunt down the thread if you like.
<tjaalton> nah I think I know that one
<tjaalton> duh, took this long to discover uscan(1)
<RAOF>  !!!
<RAOF> Really?  Man, I'm sorry I didn't tell you earlier :)
<tjaalton> yeah, i feel so stupid now, wgetting those tarballs by hand in the past
<tjaalton> aanyway, wacom 0.11.0 ready
<tjaalton> btw, my personal git repo on alioth should be writable by pkg-xorg
<tjaalton> for wacom
<tjaalton> nice, fermi microcode up for testing
<tjaalton> RAOF: -nouveau is in depwait, is libdrm merge ready to go?
<tjaalton> yeah, oneiric looks like arse right now :)
<tjaalton> a hairy one
<tseliot> :D
<tjaalton> bryce: intel merged, but patches 115 and 119 need some work to apply, and I just commented them out from series for now
<mgariepy> hello, i've got an issue with xorg-server-video-intel v 2.14 and 2.15 that makes the transparency black when using a remote Xorg server i commented the bug here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/785280 can someone help about this ?
<ubot4> Launchpad bug 785280 in gentoo (and 1 other project) "transparency not working with intel driver and LTSP (affects: 2) (heat: 12)" [Medium,Unknown]
<RAOF> tjaalton: Yeah, the libdrm merge is ready to go (and in git, right?  I'm pretty sure I pushed it!), I just need to work out precisely what to do with mesa.
<Sarvatt> woohoo libdrm is merged? I got tripped up bringing the multiarch stuff to the new packaging
<RAOF> Yeah, it's merged :)
<RAOF> Sarvatt: I'll merge mesa from debian, too.
#ubuntu-x 2011-05-26
<Sarvatt> ohh, this transition tracking talk on the ubuntu-devel list is interesting, we definitely should be adding X there whenever we do it next
<tjaalton> RAOF: yeah it's in git :)
<tjaalton> Sarvatt: like for tracking which drivers need a rebuild and stuff?
<RAOF> tjaalton: And in the repository, and FTBFS on arm :).
<RAOF> What finishes first?  An armel build of libdrm, or an i386 build of mesa.  Gentlemen, place your bets!
<tjaalton> hehe :)
<tjaalton> looking at the list of video drivers to drop, a promising start :)
<mgariepy> hello, i've got an issue with xorg-server-video-intel v 2.14 and 2.15 that makes the transparency black when using a remote Xorg server i commented the bug here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/785280 can someone help about this problem ?
<ubot4> Launchpad bug 785280 in gentoo (and 1 other project) "transparency not working with intel driver and LTSP (affects: 2) (heat: 12)" [Medium,Unknown]
<tjaalton> best file it upstream
<tjaalton> and not spam several channels about it :/
<czajkowski> wonder are folks awake ?
<czajkowski> I've an Xorg bug and I'm not sure how to proceed as I cant reproduce it as it happens on it's own 
<czajkowski> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/788508
<ubot4> Launchpad bug 788508 in xorg (Ubuntu) "Machine randomly reboots for no reason (affects: 1) (heat: 8)" [Medium,Incomplete]
<tjaalton> that sounds like a hardware problem
<Sarvatt> czajkowski: one sec, i'm digging up the bug yours is a dupe of
<Sarvatt> czajkowski: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/774978
<ubot4> Launchpad bug 774978 in xserver-xorg-input-synaptics (Ubuntu) "xserver crashes in RecordAReply when XRecord is enabled in syndaemon (affects: 32) (dups: 10) (heat: 342)" [High,Triaged]
<Sarvatt> see comment #25 for a temporary fix
<tjaalton> ah, so it doesn't actually reboot
<Sarvatt> it's not actually rebooting just X is crashing and you see plymouth again before GDM comes back up yeah
<tjaalton> now I see there's that backtrace again
<czajkowski> Sarvatt: yes 
<czajkowski> so I'm not going insane and it just happens 
<Sarvatt> czajkowski: you can add this PPA to get the fix that'll be overwritten by the fixed one in the archive when it comes out - https://launchpad.net/~sarvatt/+archive/sru3
<czajkowski> ahh k
<Sarvatt> sudo add-apt-repository ppa:sarvatt/sru3 && sudo apt-get update && sudo apt-get upgrade
<tjaalton> mh, 'sudo -s; <do-stuff>' :)
<czajkowski> Sarvatt: thanks for the help, I didnt know how I was going to do a backtrace as I didn't know what sets it off
<Sarvatt> RAOF, bryce, tjaalton: anything planned for the sprint? like any specific machines I should bring?
<Sarvatt> RAOF: what do we plan to do with dri-experimental? I think I'll move nouveau to dri in edgers now but that package is going to be empty. maybe ship i915g in there in oneiric?
<bryce> Sarvatt, I won't be attending, so no plans on my end.
<Sarvatt> oh shoot I forgot! alrighty
<tjaalton> I'll probably bring the fujitsu sis-crap for llvmpipe testing
<Sarvatt> I thought I remembered something about nouveau testing there, my only working nvidia laptop is a fermi though
<Sarvatt> both 8xxx generation laptops died
<Sarvatt> ok I take back what I said, those looks good to me.
<tjaalton> ah, good
<RAOF> Sarvatt: Yeah.  There'll be a nouveau testing day at the sprint, so bring whatever nvidia you've got that's easily portable :).
<RAOF> Sarvatt: As for -dri-experimentalâ¦ I was thinking of just dropping it entirely, given it's current contents will be folded into -dri.  If you'd like i915g in there I guess that's ok :)
#ubuntu-x 2011-05-27
<RAOF> Surprisingly enough, screaming FASTER! at the computer doesn't actually make it build any fasterâ¦
<jcristau> weird, that.
<RAOF> It's a pitty the âturboâ button didn't evolve into the âimpatienceâ button that you could press at increasing frequency to trigger improved performance.
<tjaalton> RAOF: building mesa?-)
<RAOF> Yup.
<raevol> for fun: http://askubuntu.com/questions/45071/how-do-i-set-the-refresh-rate-used-by-kms-on-the-foss-ati-driver
<RAOF> Easy!  SystemâPreferencesâMonitors!
<RAOF> Get it while it's hot, and while GNOME 3 hasn't removed the refresh rate option!
<raevol> i don't believe that changes the rate used by KMS, just X
<raevol> and just post-login
<raevol> also, i'm using xubuntu
<RAOF> Ah, yes.  Having just *read* the questionâ¦ :)
<raevol> ;)
<raevol> i really want to post this in #radeon but i am afeared
<RAOF> I'll reply on askubuntu.
<RAOF> Done.
<raevol> raof should i add this to grub_comdline)linux_default="quiet splash" ?
<RAOF> Yes.
 * RAOF should clearly update that answer.
<raevol> hehe sorry
<raevol> gonna try it, brb! :)
<tjaalton> and needs to run update-grub too
<raevol> RAOF: this doesn't seemed to have worked :( is /etc/default/grub perhaps not being read by my system?
<tjaalton> run update-grub
<raevol> oh silly me, haven't messed with grub in forever
<raevol> brb :D
<raevol> LIKE A WIZARD
<raevol> thanks so much tjaalton and RAOF
<RAOF> Woot.  We have llvm-enabled mesa without bloating each gallium driver by ~6Mb.
<RAOF> Now, to test whether it actually *works* :)
<tjaalton> great, i want to test it after the weekend
<RAOF> Man, my btrfs system really really hates dpkg.
<RAOF> 20 minutes, and we're only down to libgles2-mesa
<tjaalton> oh, it's syncing like mad?
<RAOF> Yeah.  And, you know, just being godawful slow.
<tjaalton> hehe
<tjaalton> maybe i'll use ext4 on the new system too, then
<RAOF> Yes.  This is likely to be a good idea.
<RAOF> 2 more packages done!  Now up to libglu1-mesa-dev!
<jcristau> eatmydata ftw
<RAOF> Aaaand *now* llvm is installed, and postinsts are runningâ¦
<RAOF> DONE!
<RAOF> A mere hour to install mesa packages.
<RAOF> grumble grumble mutter mutter.
<RAOF> Well, at least mesa seems to work.
<Sarvatt> RAOF: You must note the upstream commit ID in the changelog of your submission. -- that was the problem it looks like
<sithlord48> hi is anyone around to field an xorg question? 
<sithlord48> i have coruption on my display (laptop) only w/ xorg. its an intel GMA945 family card, i'ved tired new ram and live disks , seams to happen w/ xorg. any suggestsions?
<sithlord48> btw it just started yesterday (and no updates to xorg) seamingly randomly while i was using it 
<Teo`> hello
<Teo`> I'm setting up ubuntu in a chroot and I'm trying to get the same version of the nvidia driver lib as my kernel which is another distro, do you know if nvidia-graphics-drivers is going to be bumped to 270.41.19 for maverick any time soon?
<Teo`> it's already at that version in natty
<Teo`> btw talking about the ubuntu-x-swat ppa
<Teo`> dunno if this is even the right channel for that
#ubuntu-x 2011-05-28
<bizzy> Hey, I just installed the PPA, and how do i ago about getting the drivers for my Nvidia Quatro 880M
#ubuntu-x 2012-05-21
<mlankhor1t> morning
<mlankhor1t> RAOF: I've been added to xorg-pkg :)
<RAOF> Good morning!
<RAOF> And has Pete got back to you regarding hardware at all?  âº
<RAOF> That was a bit weekendy, though.
<RAOF> mlankhor1t: If you want review before/after you push to pkg-xorg feel free to ping us!
<mlankhor1t> sure
<mlankhor1t> what about packages that are identical to precise? For example if x11proto never changed
<RAOF> mlankhor1t: I'm not sure what your question is - at the start all the packages from precise are copied into quantal, so what we've currently got is what was in precise, plus anything that we've uploaded to quantal.
<mlankhor1t> RAOF: do they need to be reuploaded with a changelog bump for precise?
<RAOF> Unless there's some reason why we'd want to rebuild them then there's no need.
<RAOF> (Assuming you mean "quantal" there; if that's in regard to the precise-backports work, then we'll only be backporting things which are necessary; if, say, x11proto-xv hasn't changed between precise quantal then we don't need to backport it)
<mlankhor1t> oh indeed I did
<RAOF> I am the master of the semi-colon!
<mlankhor1t> hm, not all x11 packages have ubuntu changes?
<bryceh> most don't
<bryceh> e.g. we don't have any changes for proto libs.
<mlankhor1t> ah k, no point in checking those out then
<bryceh> mainly the things we tend to change are the server, mesa, and a few drivers
<bryceh> and 'xorg' but that's a debian package more than upstream
<mlankhor1t> hm k
<mlankhor1t> has there been a synch to debian then yet for all the updated x packages?
<RAOF> We've got a bunch of updated packages; -ati, -nouveau, and a couple of other drivers that we don't have a delta on got autosyncd over the weekend.
<mlankhor1t> ok :)
<mlankhor1t> RAOF: shall I see if I can rebuild xserver-xorg-core then?
<mlankhor1t> RAOF: actually what was the magic you used to automatically merge conflicts in debian/changelog?
<tjaalton> git mergetool? i use meld
<RAOF> mlankhor1t: dpkg-mergechangelogs in .git/info/attributes
<RAOF> Specifically, âdebian/changelog merge=dpkg-mergechangelogsâ
<tjaalton> huh, never heard of that
<RAOF> That obviously goes for everyone else who doesn't already use it to merge changelogs with git :)
<tjaalton> hmm I seem to have it in ~/.gitattributes
<mlankhor1t> weird
<mlankhorst> RAOF: I'm trying to merge debian/changelog but it filters out the most recent debian changelog entry?
<mlankhorst> automerge*
<mlankhorst> what's the proper way to merge it, looks wrong it's filtered out
<mlankhorst> oh derp, some utf-8 dash was used for the -m, making it fail
<tjaalton> are you using git mergetool?
<tjaalton> ie. what's the next thing you do after git merge?
<mlankhorst> I added the dpkg-mergechangelogs thing, the manpage online converted the dash for the ~/.gitconfig entry into a smart dash
<tjaalton> i've never had conflict-free changelog merges, so have to resort to using meld every time
<mlankhorst> tjaalton: well, it requires an entry in .gitconfig for dpkg-mergechangelogs to work
<tjaalton> wonder why I have it in .gitattributes
<mlankhorst> 'man dpkg-mergechangelogs' had the entry you need in ~/.gitconfig
<tjaalton> if it's supposed to be in $git/info/attributes, then .gitattributes is the proper place and not -config
<tjaalton> ah
<mlankhorst> it auto merges the conflicts properly with that entry :)
<tjaalton> well, doesn't sound like it :)
<tjaalton> oh it needs both
<mlankhorst> tjaalton: that was because I had some weird âm instead of -m
<mlankhorst> i wish there was some global option for $git/info/attributes, though
<mlankhorst> oh
<tjaalton> ok so that's why my ~/.gitattributes doesn't work
<mlankhorst> seems ~/.gitattributes should work
<tjaalton> should?
<mlankhorst>  Attributes that should affect all repositories for a single user should be
<mlankhorst>        placed in a file specified by the core.attributesfile configuration option (see git-config(1)). Attributes for all
<mlankhorst>        users on a system should be placed in the $(prefix)/etc/gitattributes file.
<mlankhorst> I guess if it doesn't work for you globally.. git config --global core.attributesfile ${HOME}/.gitattributes
<tjaalton> ok, need to try it out then :)
<mlankhorst> I guess this shows my knowledge of git is higher than that of packaging
<mlankhorst> RAOF: I'm updating xf86-input-synaptics atm to 1.6.1, style fixes are annoying >:(
<tjaalton> you've pulled in git master to upstream-ubuntu?
<tjaalton> or 1.6-branch
<RAOF> mlankhorst: Are you starting with what's in Debian git?  IIRC one of the Debian guys has started(/finished) that for Debian.
<tjaalton> also, http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/package_status.html
<tjaalton> though it's not showing the quantal versions yet
<tjaalton> the ubuntu specific upstream branches are used only when we need something newer than in debian
<mlankhorst> RAOF: ubuntu has a lot more changes..
<mlankhorst> at least, 01-99 is for debian only right?
<RAOF> Right.
<RAOF> By convention - we'd be in trouble if Debian needed 100 patches :)
<tjaalton> what's upstream/1.6.1+
<tjaalton> ?
<tjaalton> a mistake?
<tjaalton> don't push tags, btw :)
<mlankhorst> woops
<mlankhorst> seems so
<tjaalton> though it's not a tag but some branch
<mlankhorst> just kill it
<mlankhorst> what's the exact name it shows up as ?
<tjaalton> also, join #debian-x on oftc
<tjaalton> you don't get the commit messages? join debian-x@lists.debian.org too
<tjaalton> then you'll also get all the debian bugmail, but you can filter the commit mail separate from that
<mlankhorst> was a wip, but accidentally did git push -a instead of quilt push -a :)
<tjaalton> looks like git pull didn't pull it here
<mlankhorst> i think it rejected it
<tjaalton> maybe
<mlankhorst> could someone look if this is correct? http://pastebin.com/zNp9hSsX
<RAOF> mlankhorst: The debian/changelog entry should be more verbose - check one of the previous merge entries. It'll start with âmerge from Debian unstable, remaining Ubuntu changes:â
<tjaalton> and don't do everything in one commit
<tjaalton> you've dropped a bunch of patches too
<tjaalton> or at least should have I guess :)
<tjaalton> most of which should be upstream now
<mlankhorst> the fixes aren't in 1.6.1 yet
<mlankhorst> 1.6.1 seems to mostly consist of a massive 'indent consistently' commit
<mlankhorst> http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/log/?h=synaptics-1.6-branch
<mlankhorst> hm that might actually screw things up
<tjaalton> so, first merge with debian, mention it in the changelog listing the whole diff, commit that, then start making changes to adapt it to whatever upstream or debian has done in the meantime
<tjaalton> it's easier to sport mistakes then
<tjaalton> spot even
<mlankhorst> hm actually, seems to be diverging after that style fix
<mlankhorst> woops, I guess it's really 1.6.99.900.0~git-20120517 not 1.6.1 :)
<tjaalton> what we have now?
<mlankhorst> i mean what i was working on
<tjaalton> no
<tjaalton> you merged from debian-unstable, so it's based on 1.6.1
<tjaalton> at least that's what the current ubuntu branch has
<tjaalton> and now I see cnd's update to 1.6.0-0u1, dropping the upstream patches
<mlankhorst> hm true
<tjaalton> in any case, it's painful to update to 1.6.1 :)
<tjaalton> since we carry so many patches..
<mlankhorst> tjaalton: I fixed it though
<tjaalton> ok, if it builds and works then it's just a matter of doing the changes piecemeal imo
<mlankhorst> tjaalton: since my changes from the debian merge are only refreshing the patches to apply, what do I have to fix? just a more verbose changelog entry?
<tjaalton> mlankhorst: well, probably leave it UNRELEASED too
<tjaalton> the subject looks wrong too
<mlankhorst> I was just following the previous commit
<tjaalton> the [PATCH] part?-)
<mlankhorst> tjaalton: that's not part of the patch
<mlankhorst> it's because I used git-format-patch to export it
<tjaalton> ahh
<tjaalton> well, like RAOF said the changelog should be more verbose, and there's no need to mention the upstream version since it's already covered in the debian update
<tjaalton> just need to remember to include those to the source.changes when running dpkg-buildpackage/debuild (-v$previous_ubuntu_version)
<mlankhorst> tjaalton: in that case, I just need to add in my changelog from quantal to UNRELEASED, and the fact that I refreshed the patches?
<tjaalton> mlankhorst: yes, that would be fine
<mlankhorst> http://pastebin.com/j9kpabeC ?
<tjaalton> the subject should probably mention the refreshes, not the upstream version, and the changelog should have '* Merged from Debian unstable' on top
<mlankhorst> ok
<mlankhorst> anything else or is that it
<tjaalton> I use debcommit -a -e, meaning that when the changelog entry has multiple lines it'll give me an editor to change the commit msg, so I'll leave the real meat in the subject and rest as details
<mlankhorst> ok that changes git's subject to 'Update to debian unstable' though :P
<tjaalton> drop that line :)
<tjaalton> that would be a commit of it's own though, if you want to split it
<mlankhorst> that was the previous commit
<tjaalton> right
<tjaalton> this would be 'update the changelog'
<tjaalton> then the actual changes to patches etc
<tjaalton> but it's not that critical, just mention the merge
<tjaalton> in the changelog
<mlankhorst> http://pastebin.com/bvZStqLG last attempt I hope
<tjaalton> yes :)
<mlankhorst> I'll see if it runs on my laptop then ask if I can get someone to upload it :)
<mlankhorst> annoyingly, all the commits right on top of that in the upstream 1.6 branch are exactly all the bugfixes we want
<tjaalton> yeah
<tjaalton> you can add them as individual patches though
<tjaalton> guess 1.6.2 isn't that far away either
<mlankhorst> true
<mlankhorst> I'm tempted to just do git-format-patch -o debian/patches xf86-input-synaptics-1.6.1 and commit those unrenamed (git uses 4 numbers)
<tjaalton> you mean s/xf86-input-synaptics-1.6.1/synaptics-1.6-branch/
<tjaalton> ?
<tjaalton> hmm that doesn't work either
<mlankhorst> tjaalton: no, checkout the git, then do a git format-patch relative to that tag
<mlankhorst> :-)
<tjaalton> ah, right
<tjaalton> but you won't have debian/patches there :)
<mlankhorst> hm true
<mlankhorst> might as well
<tjaalton> git format-patch -o debian/patches xf86-input-synaptics-1.6.1..upstream/synaptics-1.6-branch
<tjaalton> and with --start-number 200 :)
<tjaalton> hum no, it'll use four digits anyway
<mlankhorst> exactly :P
<mlankhorst> rename s/000/20/ 000?*
<mlankhorst> do I append it to the existing changelog entry?
<tjaalton> yes, as long as the current one is UNRELEASED
<tjaalton> that's the point :)
<tjaalton> then after it's uploaded a new one needs to be created
<tjaalton> sometimes we pull an unreleased debian version, and add on top of that. then we'll change the version from -1 to -0u1
<mlankhorst> http://pastebin.com/H3Lbefnz ?
<tjaalton> I'd reverse the order of description / patch
<tjaalton> also, it's enough to refer to the bug number, no need for a full url (so, fdo #nnn or such)
<tjaalton> and would be greate if you have lp bug numbers to match
<mlankhorst> ok
<tjaalton> *great
<tjaalton> those would have (LP: #nnn)
<mlankhorst> what about bugs in redhat tracker?
<tjaalton> so it's not on the commit msg?
<tjaalton> if the fdo bug# is linked to rh, then it's enough to just mention the fdo bug imo
<tjaalton> but best would be to find a match from lp and then just mention that
<mlankhorst> true
<mlankhorst> but there are so many resume bugs linked to synaptics hard to find the CORRECT one ;)
<tjaalton> maybe put it in a ppa for precise and ask people to test
<tjaalton> it's not like there's any rush pushing it to quantal yet..
<tjaalton> or push the merge now, and test the fixes separately
<tjaalton> or just skip the part adding lp bug refs
<tjaalton> linux is about choice!
<mlankhorst> k
<tjaalton> plenty of choices here :)
<mlankhorst> I choose not to waste more time, did a best effort search and now pushed it. ;-)
<mlankhorst> hm.. I really need to figure out how to automatically fix all those patches to work with the coding style commit, automatically
<mlankhorst> I have something evil in mind..
<jcristau> coding style commits are evil
<mlankhorst> no easy solution sadly
<mlankhorst> I'm trying to think of ways to automate it
<mlankhorst> best i can come up with is manually moving tree back to before big style commit
<mlankhorst> apply each patch, rerun style change on affected files
<mlankhorst> 29 patches that will probably all need to be restyled :\
<mlankhorst> hm 27 debian excluded
<tjaalton> oh speaking about the xserver now?
<mlankhorst> yeah
<mlankhorst> although I guess other packages are probably affected
<mlankhorst> so I'm going to automate it :)
<bjsnider> tseliot, have you taken a look at the changes in the 302 nvidia-settings?
<tseliot> bjsnider: yes, and I have the relevant packaging changes in a local branch of mine
<bjsnider> local meaning not in the cloud anywhere?
<tseliot> bjsnider: yep, I haven't committed them yet
<bjsnider> tseliot, could you pastebin me your rules?
<tseliot> bjsnider: drop Drop 02_nvidia-settings-format-string.patch and here's the rules file: http://paste.ubuntu.com/999114/
<bjsnider> looks like you pasted it twice or something
<bjsnider> tseliot, the problem i ran into was that a lot of it is now being built into /usr/local
<tseliot> bjsnider: I think I worked around that
<bjsnider> the main makefile is totally different than it used to be
<bjsnider> my solution, which i assumed was too ugly, is this: mv $(CURDIR)/debian/$(PKG_name)/usr/local/* $(CURDIR)/debian/$(PKG_name)$(PKG_libdir)/
<tseliot> bjsnider: what I did in override_dh_auto_install does the right thing
<mlankhorst> ok, created a dumb script to port all the patches
<mlankhorst> bryceh: ping?
<bryceh> hi
<mlankhorst> was refreshing the patch series on x
<mlankhorst> it's annoying, have to refresh literally every patch because of coding style changes
 * bryceh nods
<tseliot> bjsnider: sorry this is the actual debian/rules I was talking about : http://paste.ubuntu.com/999349/
<mlankhorst> i created a script to automate it though
<bryceh> mlankhorst, excellent
<bryceh> mlankhorst, maybe worth adding to xorg-pkg-tools?
<mlankhorst> bryceh: maybe, drivers might be affected too
<mlankhorst> ah might as well
<mlankhorst> the real scary part is that it actually builds except for the pointer barrier thresholds patch
<Sarvatt> mlankhorst: http://kernel.ubuntu.com/~sarvatt/patches/500_pointer_barrier_thresholds.diff
<Sarvatt> might want to run your script over that, thats refreshed for xserver 1.12 and what i use in edgers
<Sarvatt> i didnt fix up coding style, just made it work with xserver 1.12 and made it apply
<mlankhorst> ok
<mlankhorst> Sarvatt: I updated all other patches for 1.12 at least :-)
<mlankhorst> Sarvatt: blegh, I fear running indent twice produces DIFFERENT results..
<mlankhorst> I'll just take that patch raw, easier
<mlankhorst> Sarvatt: actuall.. what happened to the gtest parts of that patch?
<Sarvatt> mlankhorst: oh right
<Sarvatt> forgot i dropped that, sorry :(
<Sarvatt> so not a direct replacement
<mlankhorst> ok that's fine
<mlankhorst> looks like it's just gtest parts and easy to do mself
<tjaalton> so are we merging 1.12 soon?
<bryceh> in quantal?  RAOF had thought we should wait a bit longer
<tjaalton> right
<mlankhorst> bryceh: I'm just practicing on packaging, if we need 1.12 I did a lot of the patches rebasing now. :-)
<bryceh> yep no prob
<tjaalton> yeah
<mlankhorst> would still need a bump for all the input/video drivers before I could push it, though.
<mlankhorst> should I just set up a ppa?
<mlankhorst> hm actually, how do I just rebuild the input/video drivers against my newly built xorg-dev package
<bryceh> yes
<bryceh> actually I seem to recall we had a work item from UDS to do exactly that
<bryceh> let me dig it up
<mlankhorst> I think that was for testing lts stuff
<bryceh> [ubuntu-x-swat] consider PPA per stable release 1.12.x 1.13.x: TODO
<bryceh> nope, unrelated to lts
<bryceh> want to take that work item?
<mlankhorst> sure
<tjaalton> probably wisest to do it once it's in quantal first
<bryceh> there was also a discussion on ubuntu-x@ last week about it.  I was trying to rope in a community member that expressed interest in it.
<mlankhorst> well so far x server succesfully refuses to start because of abi mismatch, but since it's succesful, ship it? :D
<bryceh> the question raised was whether it should go into a ppa under ubuntu-x-swat or xorg-edgers.
<mlankhorst> I vote for x-swat since it's supposed to be slightly more stable than xorg-edgers
<bryceh> mlankhorst, ok, fine with me
<mlankhorst> but yeah done for today, should I push the x 1.12 commit as a form of backup?
<bryceh> pushing to git would be ok, but maybe wait on pushing to the ppa until you actually feel it's ready for people to use
<tjaalton> also, maybe we should write a policy for all the backport ideas flying around?
<bryceh> or push to a personal ppa if you just want to get it built experimentally
<bryceh> tjaalton, probably a good idea, what are you thinking?
<tjaalton> bryceh: well, i'm worried it might otherwise get a bit out of hand :)
<mlankhorst> hopefully the x.org can be left to just a few packages only
<tjaalton> the x.org?
<bryceh> tjaalton, ok, would you like to draft something up?  
<tjaalton> bryceh: i might
<mlankhorst> erm I mean the packages we have to update in the updates pocket so userspace won't suddenly break (x11proto)
<bryceh> tjaalton, if nothing else a naming scheme would be useful
<mlankhorst> also EOD :-)
<bryceh> mlankhorst, enjoy :-)
<bryceh> tjaalton, now that ppa's can be deleted and so on, I'm a lot less concerned about ppa cruft than I used to be
<bryceh> but certainly if we set up PPAs for an LTS, they're likely to be around a long while
<tjaalton> right, we already have a number of ppa's, so defining their function wouldn't hurt I guess, and the way they're supposed to be updated/used
<mlankhorst> true
<tjaalton> speaking as one who has never pushed to any of them :)
<bryceh> hah
<mlankhorst> bleh I'll leave channel, i want to be done so ttyall in morning :P
<bryceh> mlankhorst, ok cya.
<bryceh> tjaalton, there's also the distinction about what belongs with each team.  And even why we have two teams.
<bryceh> like, I wonder if we should make one team a sub-team of the other (now that we can do that)
<tjaalton> bryceh: oh canonical-x vs. ubuntu-x-swat?
<bryceh> ah, three teams then :-)
<bryceh> ubuntu-x-swat, xorg-edgers, and canonical-x
<tjaalton> oh edgers, yeah
<bryceh> but canonical-x is clear enough, it's the other two that feel a bit fuzzy to me
<bryceh> *shrug* not a big deal though
 * bryceh wanders off looking for food
<tjaalton> well, u-x-s gets all the bugmail, which x-o probably doesn't want
<Sarvatt> xorg-edgers is crack from git with as many ubuntu patches dropped as possible, ubuntu-x-swat is everything else, hows that confusing? :P
<Sarvatt> xorg-edgers has always been crack from git, the confusing part is what goes where in ubuntu-x-swat because there never has been any concrete plans for the ppas outside of a "best effort" to update things in x-updates
<Sarvatt> we had to do crack from git for nouveau, so nouveau went there before the distro
<Sarvatt> by concrete plans i mean people interested in uploading, bjsnider has been doing x-updates for the past year and i'm trying to do stable driver releases in there but there are always transitions like an intel driver needing newer libdrm that breaks nouveau until there is a mesa release that works with it in august now..
<bjsnider> more than the past year
<bjsnider> Sarvatt, that reminds me, do we care about putting fglrx in x-updates at this point or is it ok for people to use the amd installer?
<Sarvatt> oh fun, cairo in quantal is already 1.12? sucks for nouveau users :( the fixes to make cairo 1.12 usable need the libdrm-nouveau2 change, and mesa that works with that wont be released until august
<Sarvatt> bjsnider: well the amd.com installer makes debs that work fine, my care level is low personally :)
<Sarvatt> bjsnider: sheesh time flies by
<Prf_Jakob> Sarvatt: Hey I saw the updated on the bug, when will the package be downloadable?
<Sarvatt> Prf_Jakob: takes 7 days from the upload to go from precise-proposed to precise-updates and come in automatically
<Sarvatt> its already in quantal
<Prf_Jakob> ok
<Sarvatt> so ~may 25th
<Prf_Jakob> Thanks
<Prf_Jakob> We are also going to do a release to fix bug 996821, I hoping todo that tomorrow.
<ubottu> Launchpad bug 996821 in xserver-xorg-input-vmmouse (Ubuntu) "vmmouse 12.8 behaves erratically in when running as a VMware guest" [Undecided,Confirmed] https://launchpad.net/bugs/996821
<Prf_Jakob> http://cgit.freedesktop.org/xorg/driver/xf86-input-vmmouse/ <-- there are two other fixes as well in the release but it should be safe to upgrade.
<Prf_Jakob> But I don't know how paraniod you guys are about updating packages.
<RAOF> Bugfix only releases can be SRUd without problems.
<Prf_Jakob> K thanks
<RAOF> It's once you start adding things that aren't clear bugfixes that the SRU process becomes patch cherry-picking :)
#ubuntu-x 2012-05-22
<bandit5432> any ideas on how to get xserver-xorg-video-ivtv to work with xorg egers?
<bandit5432> edgers'
<RAOF> bandit5432: How does it currently fail?
<bandit5432> its depends on Depends: xorg-video-abi-11
<RAOF> So you could rebuild it, and see if it builds against the new server.
<bandit5432> yes i am slow and have never had this issue 
<bandit5432> xorg-core 1.12.1.902 provides xorg-video-abi-12
<bandit5432> and all because i wanted to keep testing new kernels
<RAOF> You don't need xorg-edgers to test new kernels, though.
<bandit5432> if i wanted the nvidia drivers to work i think i did
<RAOF> That's quite possible.
<RAOF> So you want both the nvidia drivers in xorg-edgers and the ivtv driver to work? :)
<RAOF> It would be a simple matter to test if ivtv builds against the 1.12 server - âsudo apt-get build-dep xserver-xorg-video-ivtv && apt-get -b source xserver-xorg-video-ivtvâ should do it.
<bandit5432> face palms
<bandit5432> this is why i still like linux 
<ricotz> bjsnider, thanks for uploading nvidia-settings
<mlankhorst> morning all :-)
<tjaalton> mlankhorst: morning, you forgot the changelog update from the merge, and perhaps pushed one commit too much (the "hack") :)
<mlankhorst> tjaalton: I know, was going to fix it in morning, i pushed old tree accidentally
<mlankhorst> thought i was on ubuntu branch, but had a detached head
<tjaalton> heh, ok
<ricotz> hello all
<ricotz> tjaalton, i hope you noticed there is a new xf86-input-wacom 0.15.0
<tjaalton> ricotz: nope, don't see any announce mail for it
<mlankhorst> is that a jedi mind trick?
<ricotz> tjaalton, http://sourceforge.net/projects/linuxwacom/files/xf86-input-wacom/
<ricotz> tjaalton, unfortunately it doesnt compile with input abi 17
<ricotz> but 16 (1.12) is fine
<tjaalton> there's not much that we don't already have
<ricotz> ok
<mlankhorst> tjaalton: I can't fix the commit description sadly, first it was just disabling debian/patches/series, but this commit just fixes things
<tjaalton> mlankhorst: that's ok
<mlankhorst> bryceh thought for a while I was pushing things to quantal, but I wouldn't do that as last act for a day :P
<tjaalton> a nitpick, the urgency tag got probably copied from debian, but it has basically little meaning for us, so low is used by default
<tjaalton> it does bump the build priority a little, but it's basically never used
<mlankhorst> oh..
<mlankhorst> ok
<mlankhorst> yeah I've used it in the past to get ahead of the queue in launchpad ppa, too many dailies were being built at the time :x
<mlankhorst> ok so what name for the xorg 1.12 ppa?
<tjaalton> what's the rush :)
<tjaalton> or use a personal one for now
<mlankhorst> sure
<mlankhorst> if i upload something to a ppa that hasn't been built yet, and something else that will depend on it at the same time, will the second package wait for the first one to be built or not?
<RAOF> mlankhorst: Yes, ish.  You may need to prod it.
<tjaalton> yes, it'll wait in dep-wait
<tjaalton> or not?
<RAOF> In my experience, which may or may not still apply, things in a PPA may stay in dep-wait indefinitely.
<tjaalton> ok
<mlankhorst> ok :)
<mlankhorst> I'll just try some simple things for now, evdev + synaptics + nouveau
<mlankhorst> RAOF: what happens to packages like xserver-xorg-input-evdev, it has a ubuntu branch but it doesn't look like it needs it currently any more?
<tjaalton> then we sync it
<RAOF> mlankhorst: If it's not current, then you get to complain to the last uploader.  If we don't need the ubuntu branch anymore, then we ignore it until we need it again.
<tjaalton> but for the ppa you can just grab the debian package and push it so that it's updateable
<tjaalton> so if debian has -1, you can push -0ppa1 or such there
<mlankhorst> hm was just checking, seems to be a small delta for broken hardware
<tjaalton> yeah some quirks?
<mlankhorst> tjaalton: yeah although one of them looks like it would belong to kernel
<mlankhorst> RAOF: .. maybe I should spend some time on https://bugs.freedesktop.org/show_bug.cgi?id=47266 ?
<ubottu> Freedesktop bug 47266 in Server/Acceleration/EXA "Graphics corruption using recent Cairo" [Normal,Reopened: ]
<tjaalton> yes, we've got that in quantal now..
<mlankhorst> indeed.. if really necessary i could try to backport the exa things past the abi breakage, but I would be more comfortable with a hack to temporarily disable cairo exa acceleration on nouveau
<tjaalton> it's the same for ati as well
<tjaalton> oh radeon worked around it
<mlankhorst> nouveau too, but after the new abi
<tjaalton> right
<tjaalton> cleaning up the x-updates ppa
<mlankhorst> sure
<mlankhorst> was working on my h262 stream generator :-)
<tjaalton> bjsnider: don't think there's much point in providing updates to maverick anymore, since it's EOL'd
<tjaalton> the repository was at 80% quota, dropping the obsolete ones should bring it below 50%
<mlankhorst> mdeslaur: nice exit code :P
<mdeslaur> mlankhorst: hehe :)
<jcristau> mdeslaur: hi.  have you guys worked on CVE-2012-2118 yet?
<ubottu> Format string vulnerability in the LogVHdrMessageVerb function in os/log.c in X.Org X11 1.11 allows attackers to cause a denial of service or possibly execute arbitrary code via format string specifiers in an input device name. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2118)
<jcristau> trying to avoid double work if possible :)
<mdeslaur> jcristau: no, it's low priority for us, so we haven't started yet
<jcristau> ok
<mlankhorst> X isn't compiled with SSP?
<jcristau> not in squeeze
<mdeslaur> jcristau: in case you didn't see it, there a bug open with a patch: bug 996250
<ubottu> Launchpad bug 996250 in xorg-server (Ubuntu Hardy) "input device names used in logging format strings" [Undecided,New] https://launchpad.net/bugs/996250
<jcristau> ta.  i'll see how that applies to 1.7.
<seb128> cnd, hey
<cnd> seb128, howdy
<seb128> cnd, bug #997630 you removed utouch, but the stracktrace (https://launchpadlibrarian.net/105053932/gdb-evince.txt) shows it's hanging in a select() call from libutouch-geis
<ubottu> Launchpad bug 997630 in evince (Ubuntu) "[precise] evince and eog broken on remote sessions (X, NX, x2go and VNC)" [Undecided,Confirmed] https://launchpad.net/bugs/997630
<cnd> seb128, yeah, I'm trying to figure out who is still on my team and who can be allocated to that (and a few other) bug
<seb128> cnd, ok, I was just wondering why you removed the utouch part
<cnd> I'm cleaning up all the utouch bugs and generating a report so I can start to assign bugs to people
<cnd> seb128, oh, because utouch is a meta project
<cnd> libgrip or utouch-geis are the likely real culprits
<seb128> cnd, can I reassing to utouch-geis then?
<cnd> you might as well leave it at libgrip for now
<cnd> we can switch to utouch-geis if we find that the issue is there
<seb128> cnd, well the ubuntu part is on evince (ubuntu)
<seb128> cnd, I'm pretty sure it's not an evince issue...
<cnd> you can switch the ubuntu part to libgrip (ubuntu) then
<seb128> cnd, thanks
<cnd> actually, yo umight as well switch them to utouch-geis
<cnd> it's most likely a geis issue
<cnd> doesn't matter too much either way right now
<seb128> cnd, I've made it "also affect libgrip" and I'm setting the evince component invalid, that will let visibility on both sides
<cnd> ok
<seb128> cnd, done, thank you!
<cnd> np
<cnd> bryceh, how do I run the arsenal scripts again? it can't find the arsenal lib
<bryceh> cnd, ?
<cnd> cndougla@cndougla:/tmp/arsenal/scripts$ ./get_touch_bugs.py 
<cnd> Traceback (most recent call last):
<cnd>   File "./get_touch_bugs.py", line 25, in <module>
<cnd>     from arsenal.arsenal_lib import ArsenalBug, bugtask_as_dict
<cnd> ImportError: No module named arsenal.arsenal_lib
<bryceh> did you install it or are you running from the bzr tree?
<cnd> I'm running from the bzr tree
<cnd> is it available to be installed from somewhere?
<cnd> I thought it wasn't packaged before
<bryceh> it's packaged as of yesterday :-)
<cnd> heh
<bryceh> however, running from bzr works for me here
<cnd> probably because you have it installed
<bryceh> both running ./scripts/get_touch_bugs.py and from run inside scripts
<bryceh> possibly, yeah
<cnd> so what do I need to do?
<bryceh> ok so  I do have a fix for this
<bryceh> in the script copy in these lines up towards the top before the  import statements
<bryceh> import sys, os
<bryceh> sys.path.insert(0, os.path.realpath(
<bryceh>         os.path.join(os.path.dirname(__file__), "..")))
<bryceh> then you should be able to run it from bzr, without having it installed
<cnd> great
<cnd> thanks
<bryceh> mlankhorst, <tgardner> bryceh, I've uploaded Quantal kernel and meta package backports to https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
<bryceh> mlankhorst, let's chat tomorrow about getting a renamed X stack into the ppa
<mlankhorst> what renamed x stack, we're still on the old precise one :-)
<bryceh> right; we can just rename the existing stack as a "pretend" stack just for the practice to test the upgrade procedure
<mlankhorst> hm true
<bryceh> in fact it'd help isolate problems if we know the actual X code is unchanged; we'd know that issues are likely being caused by the mere rename
<mlankhorst> bryceh: yeah we need to exclude the packages we're not going to rename though
<Sarvatt> Prf_Jakob: that commit message confused me :)
<Sarvatt> thought i merged the wrong tag
<tjaalton> mlankhorst, bryceh: speaking of which http://pastebin.com/wfNE6LTT
<mlankhorst> tjaalton: eod, not looking ;)
<tjaalton> mlankhorst: tl;dr, the drivers having depends on the abi virtual package and a versioned depends on the xserver might make the renames a no-go
<tjaalton> unless the deps are relaxed
<bjsnider> tjaalton, you mean edgers?
<tjaalton> bjsnider: no, x-updates, the nvidia ones for maverick..
<tjaalton> i just went ahead and deleted them, hope you don't mind :P
<bjsnider> i would love to stop adding the old distros
<tjaalton> please do
<tjaalton> at least for the ones that are no longer supported
<bjsnider> as long as someone deals with the angry emails
<tjaalton> hehe
<bjsnider> "i'm still using maverick because my hardware, that nobody's ever heard of, works with it and nothing else!"
<tjaalton> that's the way it goes..
<Sarvatt> bjsnider: all the maverick excuses i get are unity
<bjsnider> in other words, it's unity-free?
<Sarvatt> yeah
<tjaalton> right, natty got the first version
<Sarvatt> natty also had old gnome though :P
<tjaalton> true
<Sarvatt> i want to install crack drivers but dont know how to change my desktop session!
<bjsnider> can we drop lucid too?
<Sarvatt> ya can stop updating it of course, better to keep the packages in there though
<tjaalton> yeah
<Sarvatt> thats gotta be the biggest pain to update :(
<Sarvatt> so much changed in the blob packaging every release after 10.04, that was the first with the gl alternatives
<tjaalton> also kinda the most important one, though we have the new lts now
<Sarvatt> but then again just reusing packaging and throwing the new .run's in it works :P
<bjsnider> doesn't one lts replace another, or how long is llucid supported?
<Sarvatt> another year on the desktop
<Sarvatt> lucid to precise doesnt even start getting offered till june or july
<Sarvatt> all the features getting ripped out of xf86-input-synaptics killed KDE
<tjaalton> it got pushed to august
<tjaalton> .1
<tjaalton> Sarvatt: hah
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/synaptiks/+bug/1002736
<ubottu> Launchpad bug 1002736 in synaptiks (Ubuntu) "[xorg-edgers] Synaptics driver crashes KDE touchpad control module" [Undecided,New]
<Prf_Jakob> Sarvatt: which one?
<Prf_Jakob> Or do you mean the announce message?
<Sarvatt> Prf_Jakob: http://cgit.freedesktop.org/xorg/driver/xf86-input-vmmouse/commit/?id=3a828d876772d05577b9372e8f6dc068794f4704 :)
<Prf_Jakob> Sarvatt: -ECOPYPASTE
<Sarvatt> 12.8.0
<cnd> RAOF, would you be able to help with some SRU stuff?
<cnd> I've done verification testing on utouch-geis in precise-proposed, so it can be copied to precise-updates
<cnd> it also needs to be copied to quantal, since it was uploaded after the archive branch but before quantal was open
<cnd> also, there's an SRU for xserver-xorg-input-evdev that needs to be approved for precise-updates
<kees> mdeslaur: jcristau: hrm? I ported the fix to precise and added it to the bug during uds
<kees> mdeslaur, jcristau: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/996250
<ubottu> Launchpad bug 996250 in xorg-server (Ubuntu Hardy) "input device names used in logging format strings" [Undecided,New]
<RAOF> cnd: Yup. I'm going to sweep the SRU queue today.
<cnd> RAOF, thanks :)
<cnd> RAOF, for the -evdev upload, that will need to be pocket copied to quantal too
<RAOF> Ok.
<cnd> should that happen when it is approved for precise-proposed?
<cnd> or when it is copied to precise-updates?
<mdeslaur> kees: yes, I mentioned the bug having a patch
<kees> mdeslaur: ah-ha, cool
#ubuntu-x 2012-05-23
<bandit5432> RAOF, thanks for the help last night
<RAOF> No problem.
<bandit5432> I wish #gnome was as responsive
<RAOF> mlankhorst: How hard would it be to fix nouveau EXA in quantal? Text poping in and out of corruption is getting slightly annoying. :)
<bandit5432> dunno but nvidia 302.11 is not doing the best on text corruption for me
<bandit5432> i might need to change the font smoothing or something
<bandit5432> nope just have to stop watching flash videos which now blead through every window i have open
<bjsnider> bandit5432, what hardware is this?
<bandit5432> 9800gtx
<bandit5432> trying to replicate
<bjsnider> oh
<bjsnider> senior citizen
<bandit5432> :|
<bandit5432> i have gtx 560 coming tommorow
<bandit5432> still old but better
<bandit5432> oh i hate flash!
<bandit5432> at least when i turn of hd accl i can watch a full video
<bandit5432> replicated flash videos bleed through kind of cool
<bandit5432> it appears to only bleed through the fonts
<bjsnider> led-bandit, i'll bet the fermi card is a lot more bug-free
<led-bandit> i am hoping 
<led-bandit> 3 year old build and its time for a upgrade
<RAOF> Man, the xserver build has ALL THE WARNINGS.
<bandit5432> is that why i am getting flooded with info?
<RAOF> No. Unless you're actually building the xserver :)
<bandit5432> i dont want to build anything
<bandit5432> just reminded me to look and see why plymouth is flooding my screen with info at shutdown and start
<tjaalton> RAOF: we should just update nouveau past the api change, they've worked around it already
<RAOF> tjaalton: Does there exist a useful mesa past the api change?
<tjaalton> RAOF: ah, not that I know of.. so it would need 8.1git :/
<RAOF> Which does or does not build currently? âº
<tjaalton> hum ho
<RAOF> It's not *that* annoying :)
<tjaalton> ok :)
<mlankhorst> morning
<mlankhorst> RAOF: Depends, do you want to backport the exa fixes?
<mlankhorst> Actually I might have to if cairo 1.12 is going to be backported for lts..
<Sarvatt> mlankhorst: if theres ANY way at all you could possibly work out the nouveau exa solid acceleration to the old libdrm-nouveau it would be so much appreciated in both ubuntu and debian
<mlankhorst> yeah.. I guess it depends if cairo 1.12 will be used in lts
<Sarvatt> debian wheezy is shipping cairo 1.12, but libdrm-nouveau2 needs mesa 8.1 that wont ship until august at least...
<Sarvatt> its a really screwed up situation
<mlankhorst> I know
<mlankhorst> it's not that hard to backport, it's hard to SUPPORT it afterwards :P
<Sarvatt> really? i had all kinds of problems just trying to backport it, its a huge change, i wouldn't worry about supporting it after :)
<mlankhorst> depends if you have experience with the previous api or not ;-)
<RAOF> mlankhorst: I don't believe we'll be backporting cairo 1.12 to the lts.
<RAOF> It's got a *lot* of rdepends, and we don't need it for hardware support
<mlankhorst> in either case, seems my beautiful hack works
<tjaalton> great
<Sarvatt> beautiful hack sounds promising :)
<mlankhorst> seems to work here at least
<mlankhorst> http://people.canonical.com/~mlankhorst/xserver-xorg-video-nouveau_0.0.16+git20120523+5815644-1_amd64.deb
<mlankhorst> using a private copy of drm/nouveau
<mlankhorst> RAOF: http://www.phoronix.com/scan.php?page=news_item&px=MTEwNTc :D
<mlankhorst> hahahaha
<jcristau> he's good at writing crap about nothing
<mlankhorst> jcristau: yes but its great amusement to see what he writes
<aquarius> hey, all. My machine is repeatedly locking up hard with coloured static. Details at https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1003333 -- so far it's happened 15 times today, so I'm not getting anything done. It started on monday; before that, there was no problem. Help? :)
<ubottu> Launchpad bug 1003333 in xorg (Ubuntu) "Ubuntu snowcrashes frequently but with no obvious cause" [Undecided,New]
<cnd> bryceh, where did you merge my utouch arsenal branch to?
<cnd> it doesn't appear to be merged into lp:arsenal
<bryceh> cnd, hang on
<bryceh> cnd, 'tis up
<cnd> ok, thanks
<aquarius> bryceh, is there any moe useful debugging information I can provide tomorrow in  https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1003333 ?
<ubottu> Launchpad bug 1003333 in xorg (Ubuntu) "Ubuntu snowcrashes frequently but with no obvious cause" [Undecided,New]
<bryceh> aquarius, no response through ssh over ethernet?
<bryceh> aquarius, ello?
<bryceh> > bug
<aquarius> bryceh, sorry. No response over ssh, indeed
<aquarius> er, that's over wireless
<aquarius> I haven't tried over wired
<aquarius> 'cos the laptop doesn't have a wired ethernet port :)
<aquarius> I don't *believe* the problem is the kernel, since I was running the same kernel two weeks ago and didn't have the problem
<aquarius> of course, something may have changed on Monday which tickles a previously-existing-but-untickled bug in the kernel I'm running
<aquarius> I can try booting from a 12.04 usb image
<aquarius> would hardware borkedness only show up when using 3d? (that is: the hardware might be borked in such a way that it doesn't fail when being used by the vesa driver)?
<bryceh> aquarius, 3d does tend to exercise the hardware a bit more than 2d.  hard to say without more testing
<aquarius> bryceh, kk. I am happy to test more (I'm happy *now*, anyway, now that I know that vesa works so that I can get work done -- 17 crashes today before I made that switch!), but I don't know what to test. :)
<bryceh> aquarius, do you know exactly what day the problem started?
<aquarius> Monday.
<aquarius> HOwever, I hadn't upgraded for a few days, i don't think.
<aquarius> so the actual change may have hit one of the repos I'm subscribed to at some point before that.
<aquarius> I *can* confirm that the change was not a new kernel.
<bryceh> aquarius, well these are the things you upgraded on monday:  http://paste.ubuntu.com/1003605/
<aquarius> ha!
<aquarius> clever. :)
<aquarius> upgrade  linux                          2012-05-22   08:46:49     3.2.0-24.37                    3.2.0-24.38                   
<aquarius> but I'm not *running* that.
<aquarius> confused, now.
<bryceh> I still think it's the kernel, but I see there were also some unity package updates there
<bryceh> (the kernel update was tuesday actually)
<aquarius> $ uname -a
<aquarius> Linux faith 3.2.0-24.37-u300acpifix1-generic #u300acpifix1 SMP Mon Apr 30 11:39:33 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
<bryceh> http://paste.ubuntu.com/1003612/
<aquarius> (that's a custom kernel built by cking, but it's a stock kernel with one patch to do with usb, and I've been running it for about two weeks)
<bryceh> watch, it'll be accomplishment-viewer
 * aquarius laughs
<aquarius> much as i would like to blame jono for this, I don't think it's him this time :)
<aquarius> is it reasonable to say that by definition any bug which hangs the whole box is a kernel bug?
<bryceh> well, if it doesn't respond on the ethernet port... if you HAD an ethernet port...
<bryceh> but actually there's a few ways to hang a box that aren't *caused* by the kernel.
<aquarius> yeah, if I had an ethernet port I'd try that. :)
<bryceh> you could try configuring your wireless to system-wide 
<bryceh> https://wiki.ubuntu.com/X/Debugging/WirelessWithoutX
<aquarius> oh, in case the problem is that my *session* is being closed rather than the box hung?
<aquarius> I never thought of that.
<aquarius> schneaky.
<aquarius> I shall give that a try!
<aquarius> (tomorrow, though.)
<aquarius> thanks, pal; that gives me some places to start!
<bryceh> aquarius, sure thing.
<mlankhorst> bryceh: also fun, firefox corruptions that are probably not ddx related, but mesa instead
<bryceh> mlankhorst, I think ubuntu should stop shipping X.org.  Too many bugs.
<bryceh> the console works fine.
<mlankhorst> :>
<mlankhorst> 25868 mlankhor  20   0 3750m 2.7g  43m R   98 17.0 101:12.29 thunderbird-bin
<mlankhorst> sure thunderbird, use all the memory you need
<RAOF> bryceh, mlankhorst: Good after
<RAOF> bryceh, mlankhorst: Good afternoon/evening.
<mlankhorst> meow
 * bryceh waves
<RAOF> Were we doing something at 2200UTC?
<mlankhorst> think now
 * bryceh nods
<mlankhorst> so lets get those blueprints sorted out
<bryceh> the kernel team has their kernel in our lts point release ppa now
<bryceh> so the question is, can we get a renamed X stack in there too, for people to start testing upgrades
<mlankhorst> i think so
<bryceh> where "renamed X stack" just means same packages as currently in precise, just with new names
<bryceh> so we can demonstrate feasibility (or infeasibility) of the rename strategy
<mlankhorst> thats just creating a dummy package for enablement that depends on most/all packages right?
<RAOF> That should work, yes. It should be able to safely depend on less than all the packages, but for a first cut that's not a bad plan.
<bryceh> (Sarvatt and tjaalton if interested and around)
<bryceh> RAOF, I think you posted a list of what you thought the bare minimum set of packages were?
<mlankhorst> what about rest, still need to approve our blueprints
<mlankhorst> I'm trying to see if I can get some work done upstream for hybrid graphics too
<mlankhorst> It wouldn't surprise me if we could get things at least upstreamed this cycle
<RAOF> bryceh: Yeah, let me grab that email
<bryceh> who wants to do the renames and posting packages to the PPA?  shall I, or would you prefer to handle it mlankhorst?
<mlankhorst> bryceh: considering i have to support things I'll probably try some of it tomorrow at least
<bryceh> heh, couple birds going crazy in my backyard.  think one of them is a hawk
<RAOF> Well, that should be short-lived :)
<tjaalton> do we have an oem approved rename postfix already?-)
<tjaalton> probably doesn't matter for the ppa though
<RAOF> Huh.  I don't have a minimal list; I've got a list of things in lts-pkg-mapping that I don't need to be there.
<bryceh> mlankhorst, sounds good.  I think Rick would like seeing the ppa available by the end of the week (barring any problems)
<RAOF> Why don't I just commit that bit.
<mlankhorst> yeah but we should also discuss things we wouldn't rename
<tjaalton> it can't be an either-or
<mlankhorst> tjaalton: I mean some x11proto headers
<bryceh> feel free to leave #'d comments in the lts-pkg-mapping file for future reference.  Fairly sure the script skips hashed lines (and if not, easy to add).
<mlankhorst> also fallout from driver rewrite is fun :S
<tjaalton> mlankhorst: ok, that's sounds scary though :)
<tjaalton> also, we probably don't want to backport the xserver from every release
<tjaalton> unless there's something of use
<RAOF> I thought the plan was to backport the full stack, including the xserver, at least in part because that combination will be the one that we've tested in the devel release.
<mlankhorst> i thought so too
<tjaalton> true
<mlankhorst> some synaptics commit refer to X.org changes for example
<tjaalton> but are we backporting the full stack, even with xserver included?
<mlankhorst> tjaalton: that was the idea
<tjaalton> libs and all?
<mlankhorst> no just the server parts
<RAOF> DDXen, mesa, xserver. That's pretty much the full stack.
<tjaalton> or where do we draw the line then?
<tjaalton> ok
<mlankhorst> tjaalton: I think all userspace stuff is skipped
<bryceh> line is at client-facing stuff
<mlankhorst> apart from mesa
<mlankhorst> and libdrm
<bryceh> heh
<mlankhorst> although technically libdrm isn't client-facing
<mlankhorst> hm guess it depends on the parts
<bryceh> I'd consider it (and mesa handwavily) "part" of the server
<RAOF> There shouldn't be any reason to backport the libs, unless mesa picks up a versioned dependency that we can't easily turn off.
<tjaalton> so any news from slangasek if this is changes anything? http://pastebin.com/wfNE6LTThttp://pastebin.com/wfNE6LTT
<mlankhorst> RAOF: well need new libdrm_nouveau at least
<tjaalton> or do we just relax the deps
<bryceh> tjaalton, haven't heard anything from him about it
<tjaalton> what about the apps? xrandr/xinput comes to mind
<RAOF> Neither have I, and I don't think it makes a huge difference; we were assuming we needed to backport & rename all the DDXes anyway.
<mlankhorst> tjaalton: they stay compatible
<mlankhorst> until hybrid graphics, at least..
<mlankhorst> blegh
<mlankhorst> not for this cycle
<RAOF> As far as I can tell the set of backport-and-renamed packages can grow whenever we want it to. With the corollory that we should at least start with a minimal set :)
<bryceh> seems sensible
<tjaalton> x11-xserver-utils has versioned depends on some libs, and assuming xrandr et al will get support for whatever new stuff the server gains, those would need to be backported as well
 * bryceh ponders
<mlankhorst> tjaalton: but that could go into backports
<tjaalton> so we have a list of packages that'll get renamed, and a list of packages we'll likely backport as-is, to the main repo?
<mlankhorst> tjaalton: we don't even know yet what will be needed. Most likely just the X server and no userspace tools
<tjaalton> mlankhorst: think ahead :)
<bryceh> I'm not terribly worried about the tools
<tjaalton> we'll get randr-1.4 & 1.5 at some point
<mlankhorst> but since newer tools will work on older servers its fine
<RAOF> Barring the protocol headers I don't think there's anything we could backport as-is to the main repo.
<tjaalton> we just need to make it clear where to put them
<bryceh> tjaalton, we'll get randr-1.4, but since the gnome utility isn't going to be updated to use it with all of this, that's going to be kind of extraneous
<mlankhorst> tjaalton: but I think if we really had to backport tools the effects would snowball because you'd want to update gnome etc too
<bryceh> mlankhorst, right
<RAOF> Oh. Do we care about backporting non-xfree86-DDXes? (ie: xdmx, xnest, etc)?
<bryceh> RAOF, I think they're important but not super critical
<mlankhorst> RAOF: can they be made to be installed next to the new X?
<mlankhorst> im inclined to see them as userspace programs
<RAOF> Actually, I'm probably overthinking that. Those things haven't changed in a while, we won't need to do anything special for them.
<bryceh> I don't think we need to have newer versions backported, but I do think it's important that they continue working
<mlankhorst> RAOF: what i mean is, it might be better to not backport those since they're more userspace programs than part of the X stack we really care about
<RAOF> mlankhorst: Yeah. They're X11 clients, anyway, so a newer xfree86 will still run them.
<mlankhorst> yeah
<mlankhorst> it will probably save us some headaches
<bryceh> hmm, I should add those to the testing list
<mlankhorst> where do you keep those docs?
<tjaalton> hmm, xdms, xnest etc are built from the same source, xorg-server? why would they need special treatment?
<bryceh> https://wiki.ubuntu.com/QATeam/AutomatedTesting/UpToDateKernel
<tjaalton> *xdmx
<mlankhorst> tjaalton: because userspace can depend on it, so probably better not to build renamed ones..
<tjaalton> mlankhorst: the old ones work still?
<mlankhorst> they should
<mlankhorst> they're normal programs
<tjaalton> ok so I don't see a problem then :)
<tjaalton> every special-casing either makes the script a monster, or means more manual labor and things to remember
<mlankhorst> also it's going to be fun with regressions from nouveau ddx fallout..
<RAOF> That does mean that the lts-backports script will need to munge the debian/control for the xserver to not build those packages.
<mlankhorst> RAOF: that's just the X server though, shouldn't matter
<RAOF> Yeah, but tjaalton's point that it either makes the script more complicated or requires manual work is salient.
<RAOF> Not a lot more complicated, though.
<mlankhorst> could just create a bunch of hooks for each package, see if a special file exists for them
<RAOF> That's not a terrible plan, if we need that power âº
<mlankhorst> lol
<bryceh> RAOF, so like have the script comment out those packages?  shouldn't be too hard to do
<RAOF> Right.
<mlankhorst> one sed call later..
 * RAOF has pushed the revised lts-pkg-mapping to xorg-pkg-tools
<bryceh> got it
<bryceh> I'll add in the hashing functionality.  So xdmx, xdmx-tools, xnest, xvfb.  What about xserver-xephyr and xserver-xfbdev, those too?
<tjaalton> occurred to me that all the packages that are rename-backported automatically become unsyncable from debian, since we carry at least the provides/breaks delta in d/control
<tjaalton> but..
<tjaalton> the price we pay
<mlankhorst> tjaalton: we dont auto synch after a release right?
<tjaalton> mlankhorst: no
<mlankhorst> bryceh/raof: is renaming x11 common really a good idea?
<bryceh> if raof's list is correct it's only a handful of packages that would usually be sync'd anyway
<tjaalton> but in order to allow upgrades from the backported packages the "real" packages need the delta
<tjaalton> all the ddx's?
<tjaalton> um, drivers i mean
<RAOF> Stupid overloaded terminology :)
<bryceh> oho right, raof's list is a bit too short :-)
<tjaalton> where is it?
<bryceh> xorg-pkg-tools:lts-pkg-mapping.txt
<RAOF> What was our 12.04.2 to 12.10 upgrade support again?
<RAOF> Do we not need to care about that until 14.04?
<mlankhorst> those probably also need to be removed: xdmx, xauth (xfonts-* ?? discuss)
<tjaalton> RAOF: if there is no upgrade path then it's not an issue
<RAOF> That's something that I remember discussing in the session, but can't remember the outcome.
<mlankhorst> and libpixman-1 is scary since cairo uses it..
<bjsnider> RAOF, it's big news on phoronix that you pushed some xorg patches
<mlankhorst> bjsnider: ofc
<RAOF> Anything that a Canonical employee does is immediately more important becase they're a Canonical employee âº
<RAOF> mlankhorst: Pixman might be a bit of trouble, then. New xserver releases have depended on a new pixman in the past.
<mlankhorst> RAOF: does pixman bump soname?
<mlankhorst> we could just provide a renamed package that could coexist
<RAOF> That was my thought.
<RAOF> Pixman didn't bump the soname, because it was just new API that the xserver was depending on.
<RAOF> That doesn't mean that *we* couldn't bump pixman-lts-backport's SONAME, though.
<RAOF> And then it would be parallel-installable.
<mlankhorst> or static link
<RAOF> Also possible, I guess.
<mlankhorst> seems to be only for Xorg
<mlankhorst> hm might be a pita though
<RAOF> I think we can cross that bridge when we come to it.
<RAOF> Leave pixman out of the list for now, and then deal with it should xserver start depending on new features.
<mlankhorst> yeah
<bryceh> xcb-proto?
<bryceh> sufficiently client-side?
<mlankhorst> if x builds without updating it, probably
<RAOF> Yup.
<mlankhorst> xtrans/xutils client side too?
<mlankhorst> oh and regardless we still need to get the blueprints approved..
<bryceh> suppose we can leave xkeyboard-config out too
<bryceh> mlankhorst, which ones, I can take a look
<mlankhorst> hybrid, xorg general, backports
<mlankhorst> bryceh: fallout from ddx update is fun
<mlankhorst> should probably have that as action point
<bryceh> mlankhorst, the lts one is already approved
<mlankhorst> ok :)
<mlankhorst> i mean for desktop-q-xorg-general
<RAOF> Yeah.
<bryceh> RAOF, think seb's wanting you to write it up before marking it accepted?
<mlankhorst> I added nouveau ddx item real quick
<RAOF> Yes, he is.
<RAOF> That and two others.
<mlankhorst> are we wrapping up in next 30 minutes? need sleep..
<bryceh> mlankhorst, do you have any questions you need to know before you can put the stuff in the ppa?
<bryceh> I'm in the process of updating the package mapping list with the ddx's and other random bits, should have that within an hour
<bryceh> I'll have raof do another pruning on it, then that should be an actionable list
<bryceh> RAOF, also I'll try and do some cleanup on the work items.  I just piled everything in from all the other blueprints but I think some items lost context and aren't sensible (and maybe not relevant anyway)
<bryceh> er, on the work items for the general xorg blueprint.
<mlankhorst> isn't the final goal that we rebuild the packages? I only see a rename
<bryceh> mlankhorst, how do you mean?
<mlankhorst> bryceh: do we just rename the quantal packages or do we rebuild them
<bryceh> mlankhorst, all the renamed packages will need rebuilt but that'll happen in the PPA
<RAOF> It should be renaming the source packages, and then you'll build those renamed packages in the PPA.
<mlankhorst> k
<bryceh> packages not being renamed don't need rebuilt
<bryceh> RAOF, although that makes me wonder about ddx's we don't maintain
<RAOF> We need to pull those in, too.
<RAOF> If they're in the archive.
<bryceh> alright, well I'm adding in the packages we do maintain to this list.  maybe when you review you can pull in any other ddx's you know of.
<mlankhorst> all the world is intel/nouveau/ati right? ;-)
<RAOF> bryceh: I'll do so.
<RAOF> And add some of the craaaaaaazy arm DDXen, too :)
<tjaalton> if the point of the backports is hw enablement, there's no reason to include drivers that never get any new hw support
<mlankhorst> tjaalton: abi breakage..
<tjaalton> mlankhorst: no need to update..
<RAOF> That's a fair point.
<RAOF> Oh, no. Did we end up deciding whether or not 12.04.2 will use the new stack by default or not?
<tjaalton> boo :)
<mlankhorst> RAOF: I think we let leann handle that
<RAOF> I think it's probably easier to just rebuild *all* the DDXen. They're totally self-contained, so not building them is basically just saving some buildd time.
<mlankhorst> [leannogasawara] Drive decision pre UDS-R whether or not the 12.10 stack is the only supported stack on 12.04.2 media, and if both are supported, which is the default boot option or end users: TODO
<mlankhorst> anyhow i cant stay up much longer
<RAOF> Feel free to sleep :)
<mlankhorst> thanks for meeting and gnight )
<bryceh> night mlankhorst 
<bryceh> jeez, "xserver-xorg-video-siliconmotion-dev-lts-backport-quantal"
<mlankhorst> -dev ?
<bryceh> binary package
<bryceh> mlankhorst, sleep. :-)
<bryceh> RAOF, pushed up new list
<RAOF> bryceh, mlankhorst: I've divvied out some xorg-general work items to you guys; feel free to complain if you don't want to do them âº
<bryceh> ok
<RAOF> bryceh, mlankhorst, tjaalton: There's also the WIs for testing plans; I haven't assigned them anywhere. If you want them, pipe up!
<bryceh> RAOF, mlankhorst I've sketched in the basics of a master script to iteratively grab and rename all the packages.
<bryceh> RAOF, mlankhorst oh and btw still need to shake out all the bugs of the lts rename script; I've really only run it on xserver and -intel; everything else is unexplored territory
<RAOF> :)
<bryceh> so... patch with impunity as you find bugs :-)
#ubuntu-x 2012-05-24
<bryceh> RAOF, did you mean to drop the work item mlankhorst just added?
<bryceh> - [mlankhorst] Deal with fallout from nouveau ddx update: TODO
<bryceh> guessing was just a race condition :-)
<RAOF> bryceh: No, I did not.  Race condition :)
<bryceh> sweet, and now dpkg-control has package hashing support
<bryceh>  dpkg-control --source-suffix foo --binary-suffix foo -k xdmx,xdmx-tools,xnest
<RAOF> Iiiinteresting.
<RAOF> Intel has just decided that it doesn't particularly want to render text.
<RAOF> Ah, right.
<RAOF> I've hit that UXA bug.
<RAOF> Score
<bjsnider> that will be the lead story on phoronix tomorrow
<bjsnider> "chris halse rogers discovers intel bug"
<RAOF> My every utterance *does* have a weight that attracts others' notice :)
<bjsnider> yeah, sort of like jesus
<eric_> i'm getting some tearing with 3.4 final on sandy bridge
<eric_> is this normal?
<mlankhorst> RAOF: race condition of 90 minutes ;o
<RAOF> Heh.
<RAOF> Race condition of not refreshing the page :)
<meho> hi, i need an driver for my ati radeon express x1100, ubuntu 12.04
<meho> what package shoult i take?
<mlankhorst> meho: r600 if it works? :)
<mlankhorst> which you should already be using btw
<meho> mlankhorst, its a fresh installation, i think this is a universal driver by unbutu?
<mlankhorst> meho: yeah r600 is the open source driver, should already be there on fresh installs
<mlankhorst> if it works no need to install drivers :)
<meho> mlankhorst, in systeminformation der card is known as: unknown? how can i activate the 3d acceleration?
<mlankhorst> meho: how do you know you're not getting 3d acceleration atm?
<meho> i think so :), cause the card is unknown. and no effects like on my pc.
<meho> mlankhorst, you`r right! the acceleration is allready on. ich tested it with cairo-dock.
<mlankhorst> :-)
<mlankhorst> meho: yeah the open source drivers are better than fglrx if they work, so i dont recommend installing drivers in most cases
<meho> mlankhorst, i dont understand why is the card in unity-system-info unknown?
<meho> mlankhorst, but with "sudo lspci | grep -i vga" it shows:01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RC410 [Radeon Xpress 200M]
<meho> mlankhorst, thank you for helping!
<mlankhorst> RAOF: I guess the lts-stack thing isn't completely tested?
<mlankhorst> Processing the control file...
<mlankhorst> Traceback (most recent call last):
<mlankhorst>   File "../../dpkg-control", line 142, in <module>
<mlankhorst>     killings = options.kill_binaries.split(',')
<mlankhorst> AttributeError: 'NoneType' object has no attribute 'split'
<tjaalton> hmm, can't we sru mesa 8.0.3 now with the relaxed policy?
<mlankhorst> tbh we should sru synaptics-1.6.3 when its released
<tjaalton> there's no 1.6.2 yet :)
<mlankhorst> synaptics-1.6-branch.version()
<tjaalton> need to get the new mesa in quantal first though
<mlankhorst> yeah was looking at some stuff, small errors in each of the scripts that made them not work
<mlankhorst> RAOF: script works after a few fixes
<mlankhorst> RAOF: pushed them :)
<mlankhorst> RAOF: hmm.. do we need to rename binary drivers? Aren't we already updating them in backports when they become available?
<tjaalton> you mean blobs?
<tjaalton> no need to
<tjaalton> since they have -updates
<tjaalton> though, -updates is changed at will
<tjaalton> so maybe they do need renames after all
<mlankhorst> im just commenting them out for now, too much work in fglrx
<mlankhorst> ok fun, script's still broken :)
<mlankhorst> RAOF: ping if still awake
<mlankhorst> now to figure out how to mimmic launchpad locally
<mlankhorst> build packages with the other packages I built
<tjaalton> set up a chroot, build them there
<mlankhorst> suppose
<tjaalton> or if using sbuild, teach it to use a local package cache, but i've never done that..
<tjaalton> should have a local repo though, still haven't configured reprepro for it tho
<mlankhorst> ill just build in tmpfs chroot
<mlankhorst> hm interesting
<mlankhorst> bryceh/RAOF: I've been trying to build the renamed things, but all the debian/rules modifications are the biggest bottleneck atm. I'm trying to automate those modifications as much as I can. :-)
<bdmurray> bryceh: I've made https://wiki.ubuntu.com/X/Bugs/UpdateManagerWarningForI8xx which had moved a redirect to X/i8xxUnsupported.  Its important to keep the redirect as update-manager contains that url in it.
<bryceh> bdmurray, ok sounds good
<bryceh> bdmurray, I'd reaped that in a wiki spring cleaning  a few weeks back
<mlankhorst> bryceh: oh i posted my findings so far on the mailing list, tldr version: undecided :)
<bryceh> mlankhorst, ok reading
<mlankhorst> but reply there, im going to bike to a friend now and back for the next few hours
<mlankhorst> bb :)
<mlankhorst> ok that was fun
<cnd> RAOF, we need utouch-geis pocket copied from precise-proposed to quantal
<cnd> is there a way for me to do that?
<cnd> or does an archive admin like yourself need to do it?
<RAOF> cnd: I don't know off the top of my head how to do that. I *think* you could requestsync.
<RAOF> Or you could just upload to quantal, of course.
<cnd> RAOF, isn't there an issue if it has the same version?
<cnd> it would be rebuilt
<cnd> and thus there would be two different packages with the same version
<RAOF> Right, you'd need to bump the version.
<RAOF> We're actually well past the time where you should be uploading to quantal first, anyway.
<cnd> RAOF, this is for a package before quantal was opn
<cnd> open
<RAOF> Not the one that I accepted on Wednesday?
<cnd> yes, the one you accepted into precise-updates
<cnd> it was uploaded to precise-proposed before that though
<cnd> while quantal wasn't yet open
<RAOF> Oh, right. And I forgot to copy it to quantal.
<cnd> so is this something you need to take care of?
<RAOF> Yes.
<cnd> ok
<cnd> thanks :)
#ubuntu-x 2012-05-25
<mlankhorst> morning!
<tjaalton> howdy
 * bryceh waves
 * mlankhorst waves back
<mlankhorst> still awake?
<bryceh> me? not really
<mlankhorst> yeah I'm just fighting debian/rules for rename atm
 * bryceh nods
<mlankhorst> It's really awful to run sed over it though, but no other way afaict
<mlankhorst> also special-casing dbg, keeping it pkg-suffix-dbg instead of pkg-dbg-suffix
<bryceh> "no other way" -:: python :-)
<mlankhorst> also fixed dev packages hopefully now. I'm adding each package in control to mapping array
<mlankhorst> because of -dbg and -dev packages
<mlankhorst> also made dpkg-control respect the mapping file for its own packages. :-)
<mvo> is it known that apparently fglrx does work differently for offscreen windows than (most?) other drivers, i.e. showing a white border, context is bug #999178
<ubottu> Launchpad bug 999178 in software-center (Ubuntu) "Banners in Software Center do not work as intended and fglrx driver shows white right border" [Medium,Confirmed] https://launchpad.net/bugs/999178
<mlankhorst> oh plymouth is fun
<mlankhorst> RAOF: well can't say it was unadventurous..
<mlankhorst> I managed to replace libdrm now, but it requires reuploading plymouth to kill its shlibs:Depends
<mlankhorst> oh fun
<tjaalton> what now?-)
<mlankhorst> xfonts-utils won't be renameable
<mlankhorst> took some digging, but dh_installxfonts will pull in a versioned depends
<tjaalton> drop it from the list
<tjaalton> no need to backport that one
<mlankhorst> yeah
<mlankhorst> i already did
<mlankhorst> but debugging where the hell it came from is annoying
<tjaalton> :)
<tjaalton> you mean which package pulled it? xorg depends on it, probably other packages too
<mlankhorst> I don't install xorg package renamed yet
<mlankhorst> was too big a mess, probably needs to be done by hand, which is fine since it's a virtual package
<tjaalton> virtual package? no it isnt'
<tjaalton> metapackage, yes
<mlankhorst> ugh meta then :P
<mlankhorst> virtual only exists in provides: ?
<tjaalton> right
<mlankhorst> on a positive note, I almost managed to build xorg-server now, renamed  xkeyboard-config-2.5  xfonts-base-1.0.3 xauth-1.0.6 x11-xkb-utils-7.6+4 libdrm-2.4.32 and testing mesa scripts now
<jcristau> xauth?
<mlankhorst> dno, it was in the list
<mlankhorst> and it hasn't gotten in the way, so shrug
<mlankhorst> if it did, I would probably drop it, but for now I'm just investigating the way of rename, so it's nice for testing what happens.
<mlankhorst> I did find a flaw in the script though, the exact matching of breaks allows me to install xfonts-base and renamed version at the same time, with the files being replaced by the named version
<mlankhorst> I keep finding new interesting things that break :-)
<mlankhorst> bryceh: Amazingly that rename hack now seems to run through most x drivers
<mlankhorst> and uploaded to q-lts-backport, hopefully it will pick up the new plymouth version before trying to build libdrm
<mlankhorst> bryceh: ping?
<mlankhorst> I uploaded the whole stack, but it seems launchpad can only find plymouth which i uploaded an hour before that :S
#ubuntu-x 2012-05-27
<mlankhorst> oh hey the packages I uploaded work..
<mlankhorst> RAOF: spammer :P
<Milos_SD> Hello guys
<Milos_SD> is there some way I can make Firefox nightly icon to work with newest Unity in 12.04 proposed ? 
<Milos_SD> I have it locked, but when I exit program and try to start it again from launcher, nothing happends, and when I start it from dash, it opens in another icon instance :S
<Milos_SD> oh yea... that was the issue with tvtime too, and they fixed it after my bug report, but now it is back again :(
<mlankhorst> really really the wrong channel
<mlankhorst> RAOF: if awake, i uploaded the renamed X stack
<mlankhorst> only geode was failing to build since I tested amd64 only, but probably the arm drivers as well
<mlankhorst> https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport nn
<RAOF> mlankhorst: Awesome.
#ubuntu-x 2013-05-21
<zzippy> tseliot: Hi! is it possibl that Nvidia 319 installs differently on optimus machines, means that /usr/lib/x86_64-linux-gnu/xorg/extra-modules sometimes is a link to  /etc/alternatives/aso and sometimes not?
<zzippy> ubuntu. btw
<tseliot> zzippy: where did you get that package from?
<zzippy> tseliot: xorgedgers
<tseliot> zzippy: I doubt they're doing anything different from the official packages. Why do you ask?
<tseliot> are you experiencing any problems?
<zzippy> Wait a minute, I will try to explain.
<zzippy> A guy from our forum created a script, which makes it possible to switch from "whole desktop on nvidia" to  "Desktop on Intel" using bbswitch module from bumblebee. Works great, powersaving on demand. unfortunately /usr/lib/x86_64-linux-gnu/xorg/extra-modules, which has to be deleted to make this work, on some machines not is just a link to  /etc/alternatives/aso 
<tseliot> zzippy: I'm not familiar with the /etc/alternatives/aso file
<tseliot> ricotz: ^^
<zzippy> tseliot:  /etc/alternatives/x86_64-linux-gnu_xorg_extra_modules contains libglx.so (link), libglx.so.319.17 and nvidia_drv.so
<tseliot> zzippy: I know what /etc/alternatives/x86_64-linux-gnu_xorg_extra_modules is (I worked on it) but I don't know about that link you were talking about
<zzippy> tseliot: /usr/lib/x86_64-linux-gnu/xorg/extra-modules on some machines links to /etc/alternatives/x86_64-linux-gnu_xorg_extra_modules, but sometimes not.
<zzippy> We ddo not understand why nvidia driver seems to install differently, thats all
<zzippy> Well, we make further investigations on this.
<tseliot> zzippy: I wouldn't know. Does this also happen with the packages in the ubuntu repository?
<zzippy> tseliot: we use x-staging ppa and only nvidia-319 from xorgedgers, not their whole ppa
<tseliot> zzippy: yes, I meant the nvidia packages in the ubuntu repository
<zzippy> 319 arrived in ubuntu repository? Sorry, did not know.
<zzippy> ..cannot find any nvidia-319 in ubuntu repos.
<ricotz> zzippy, nvidia-319 is not available in ubuntu yet -- i have never seen "/etc/alternatives/aso", but since you said you played with several version and scripts you should outrule it isnt generated/caused by them
<ricotz> the edgers 319 package is plainly based on "nvidia-graphics-drivers-313-updates (313.26-0ubuntu3)"
<ricotz> zzippy, so i guess tseliot meant to try to confirm problems with 313.26-0ubuntu3
<tseliot> yes, they haven't approved my 319 package yet...
<ricotz> tseliot, feel free to push them to the saucy pocket only in xorg-edgers
<zzippy> ricotz: sorry, with "aso" I meant "and so on", was too lazy to type "x86_64-linux-gnu_xorg_extra_modules"  ;)
<tseliot> ricotz: ok
#ubuntu-x 2013-05-22
<mlankhorst> morning
<tjaalton> looks like nautilus fails to start on login here, leaving the login screen as desktop
<tjaalton> raring
<mlankhorst> tjaalton: anything in .xsession-errors?
<tjaalton> (nautilus:3270): GLib-GObject-CRITICAL **: g_object_set: assertion `G_IS_OBJECT (object)' failed
<tjaalton> four times
<mlankhorst> nothing else?
<tjaalton> not about nautilus
<mlankhorst> not out of disk space are you?
<tjaalton> no, 31G left
<tjaalton> aww dumb stupid schroot/sbuild
<tjaalton> failed builds can leave lingering mounts, and they are remounted after a reboot
<mlankhorst> ahg
<tjaalton> not related to nautilus though
<mlankhorst> what if you simply start nautilus in a debugger?
<tjaalton> oh nautilus starts fine when running manually
<tjaalton> restores the background too
<mlankhorst> what if you log in as guest or something, to rule out something in home being messed up
<tjaalton> mlankhorst: same
<mlankhorst> so.. what changed
<tjaalton> I remember seeing some bugs with the same description filed against xorg
<tjaalton> nautilus hasn't changed
<seb128> what's the issue? (I just joined)
<tjaalton> seb128: nautilus fails to start on login
<tjaalton> happens with guest login as well
<tjaalton> raring
<tjaalton> works when started manually
<mlankhorst> tjaalton: still an issue? I need a break from kernel stuff :)
<tjaalton> heh
<tjaalton> I've moved on.. :)
 * mlankhorst noticed unity-webapps landing in saucy, hopes unity and xserver is next
<mlankhorst> tjaalton: oops, we were missing an update to savage. x-staging now installs correctly on saucy :)
<tjaalton> mlankhorst: oh
<tjaalton> how's that possible
<tjaalton> oh it got bumped in saucy?
<mlankhorst> yeah
<tjaalton> bad tormod :)
<mlankhorst> actually good tormod for caring
<tjaalton> sure, just kidding
<mlankhorst> that's only fun when he's in the channel ;)
<ricotz> tseliot, hi, i pushed your 319.17 package to edgers and added a kernel 3.10 patch -- https://launchpad.net/~xorg-edgers/+archive/ppa/+sourcepub/3213524/+listing-archive-extra
<tseliot> ricotz: oh, nice, a 3.10 patch :)
<ricotz> tseliot, yeah since tim already pushed a 3.10rc2 build to the kernel ppa it seems reasonable to be prepared
<tseliot> good
#ubuntu-x 2013-05-23
<jcristau> heh, good thing for ubuntu 3 releases went out of support earlier this month
<mlankhorst> indeed!
<bjsnider> 2 on teh same day
<jcristau> oh, only desktop for lucid, so i guess it still gets this round
<mlankhorst> probably
<mlankhorst> jcristau: it's going to be worse when you have to update the various xservers in precise too, around the time development for next lts starts
<jcristau> yeah but i already knew that's madness :)
<bjsnider> ain't no xorg packages on the server side, right?
<jcristau> ?
<bjsnider> yeah, there's no graphical stuff in the base server install cd image, so i don't think it's too worrisome that the lucid server hasn't been retired yet
<Sarvatt> well that was confusing
<Sarvatt> saw that debian was blocked on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708677
<ubottu> Debian bug 708677 in llvm-3.2 "llvm-3.2: llvm-config-3.2 --libdir reports wrong directory for shared libs" [Important,Open]
<Sarvatt> checked out the llvm packaging svn, they had the right fix in it
<Sarvatt> but its all moved into a single llvm-toolchain package now and that doesn't have the fix
<Sarvatt> its missing a usr/lib/@DEB_HOST_MULTIARCH@/libLLVM-3.2.so.1           usr/lib/llvm-3.2/lib/libLLVM-3.2.so in http://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/trunk/debian/llvm-3.2-dev.links.in?view=markup
<jcristau> i think sylvestre is away this week
<Sarvatt> http://anonscm.debian.org/viewvc/pkg-llvm/llvm/branches/3.2/debian/llvm-3.2-dev.links.in?view=markup
<jcristau> hopefully he can fix it up soon...
#ubuntu-x 2013-05-24
<tjaalton> hmm, dragging a pdf image with evince crashes compiz
<soren> tjaalton: Don't do that then.
<soren> tjaalton: Troublemaker.
<tjaalton> soren: :P
#ubuntu-x 2014-05-19
<Prf_Jakob> Just checking, none of you guys who have help me/VMware in the past are in the London office?
<mlankhorst> no
<Prf_Jakob> shame, no beer for you :) well some other time
<gQuigs> I'm trying to figure out if this is a packaging bug or not in xorg-edgers.. I'm on 14.04 w/ edgers and a geforce 750 ti
<gQuigs> I can't get BOINC to detect CUDA
<gQuigs> It detected perfectly fine when I installed the nvidia drivers manaully
<gQuigs> well... reported as: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1320990  still not sure how to figure out where it's breaking.. happy to debug more
<ubottu> Launchpad bug 1320990 in xorg (Ubuntu) "[xorg-edgers] BOINC can't find CUDA driver with xorg-edgers packages" [Undecided,New]
#ubuntu-x 2014-05-20
<tjaalton> mlankhorst: ooh, [PATCH] mi: don't process events from disabled devices (#77884)
<mlankhorst> goodie
<mlankhorst> seems like that would fix one of the crashes I've had. :-)
<tjaalton> probably also some of those where the server crashes on shutdown
<mlankhorst> ok try #2 for that bug
<tjaalton> mlankhorst: didn't you have a generic bug for the mesa update, or using the bdw specific one for the sru?
<mlankhorst> tjaalton: just using the bdw one
<tjaalton> ok then, good to know ;)
<mlankhorst> I'll probably have to do a second upload to fix that <explicit> radeon regression
<mlankhorst> then again it seems less borked than before
<mlankhorst> or not..
#ubuntu-x 2014-05-23
<icest0rm> hi all, someone can assist me on x-config?
<icest0rm> i have some problems with my setup..
#ubuntu-x 2014-05-24
<Applesouce> Hello Ubuntu Fans, I have installed 14.04 lately and updatet the nVidia driver with current-nvidia from the x-swat ppa. The problem is, when I boot my Ubuntu now, the screen just stays black, but if I choose secure boot in grub and then go to resume, it boots to the desktop. Please help me.
#ubuntu-x 2015-05-22
<tjaalton> 4t/win 23
<tjaalton> uh
#ubuntu-x 2016-05-25
<ricotz> tseliot, hi
<ricotz> tseliot, I assume you already prepared 361.45.11?
<tseliot> ricotz: not yet, but I can have a look
<ricotz> tseliot, I have a tarball and ppa packages for x and y
<ricotz> so I could just push those
<ricotz> tseliot, I assumed you left 361 out on purpose while this release was coming
<tseliot> ricotz: if you haven't pushed them yet, I can upload the tarball from here, as soon as I'm done with the patching (which should be very quick)
<tseliot> 361 in the archive is patched
<ricotz> I dont think so
<ricotz> 361.42-0ubuntu2
<tseliot> so I didn't push 361... err...
<ricotz> 361.45.11 should be ready for 4.6 already
<tseliot> well, I've just pushed the old 361
<tseliot> since I did the work for it
<tseliot> now I'll have a look at the new 361
<tseliot> I can test quickly here
<ricotz> tseliot, ok, so I will wait for your tarball
<tseliot> ok
<ricotz> as usual don't push it to the ppa with transitionals
<ricotz> regarding the armhf failure of 367.18 I have ignored it on purpose since it seems like a mistake by nvidia to drop vulkan support files
<ricotz> tseliot, ^
<tseliot> ricotz: I'm going to push that to the archive first, then I'll get rid of the transitional packages
<tseliot> as for 367, I haven't checked it yet but yes, it's ok to ignore armhf for now. I can report the problem to NVIDIA
<ricotz> ok, pushing it to the archive is enough from your side
<tseliot> all right
<ricotz> basically "nvidia_icd.json" is missing in armhf
<tseliot> ok, thanks
<tseliot> ricotz: the new nvidia builds fine against 4.6. I'm going to upload it now
 * tseliot -> lunch
#ubuntu-x 2017-05-27
<necktwi> E: The repository 'http://ppa.launchpad.net/canonical-x/vulkan/ubuntu zesty Release' does not have a Release file.
<tjaalton> necktwi: read the description
<necktwi> @tjaalton no packages for zest release?
<necktwi> yeah i should have read it in first but its nice meeting you all!
<tjaalton> there are no packages for any release
<tjaalton> I'll just purge the ppa
<tjaalton> done
#ubuntu-x 2018-05-22
<tjaalton> RAOF: I'm prepping xserver 1.20 for a ppa upload, and dropped xmir as IIRC we discussed
<RAOF> tjaalton: Rad. Make it so!
<tjaalton> :)
<tjaalton> I also need to worry about 16.04.5 and 18.04.1, and wondering if mesa 18.0.x can be backported but so that upgrades to 18.04 with glvnd still works.. safest would be not to backport
<RAOF> The glvnd transition seems a pretty risky backport :)
<tjaalton> well I'd just merge 18.0.x with the old packaging and not backport glvnd, but right now things depend on package Breaks/Replaces to work on upgrade, and those would need to be bumped in lockstep
<tjaalton> hum, maybe get last 18.0.x in bionic and bump B/R on libglvnd, then push new mesa with slightly older pkg version to xenial.. could work
<tjaalton> RAOF: btw, is mir from bionic getting backported to xenial? if not, I wouldn't be able to drop the mir bits from mesa for a backport
<tjaalton> hmm looks like they were there still when 18.0.0 was started, should probably still work
<tjaalton> tseliot: can you think of issues if the bionic xserver is backported to xenial as-is?
<tjaalton> for .5 hwe refresh
<tseliot> tjaalton: I think you dropped some patches in bionic
<tjaalton> because they became obsolete
<tjaalton> so maybe revert the patch changes, including adding outputclass support?
<tseliot> outputclass would actually help
<tjaalton> would you need to change all the drivers then?
<tjaalton> nvidia-*
<tseliot> I am going to either way, but things aren't that clear yet
<tjaalton> ok, I'll push stuff to the staging ppa first anyway
<tseliot> sounds good
<RAOF> tjaalton: We continue to use Mir-trunk on xenial, but we don't use the hwe stack there anyway!
<tjaalton> RAOF: ah.. well mesa isn't renamed so you'd get the backport anyway ;)
<tjaalton> but that's fine, once this is ready on a ppa I'll give you a shout to give it a go
<tjaalton> should work
<tseliot> tjaalton: are we getting mesa with or without GLVND in xenial?
<tjaalton> tseliot: without
<tseliot> ok
#ubuntu-x 2019-05-23
<alkisg> Hi, so far 3 schools reported black screen+hang after upgrading from 4.15.0-47 to -48+: http://alkisg.mysch.gr/steki/index.php?action=dlattach;topic=7771.0;attach=5029;image
<alkisg> But when they installed linux-generic-hwe, the problem was gone, so I'm not sure it's worth it to pinpoint the regression;
<alkisg> so I'm just mentioning it in case it becomes more frequent...
<tjaalton> alkisg: ancient hw?
<tjaalton> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1819486
<ubottu> Launchpad bug 1819486 in linux (Ubuntu) "Crash from :i915 module with 4.15.0-46-generic using multi-display" [Undecided,Confirmed]
<tjaalton> assuming it's i915
<alkisg> dimitris@HPEliteDesk:~$ lspci -nn -k | grep -A 2 VGA
<alkisg> 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06)	Subsystem: Hewlett-Packard Company Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [103c:18e5]	Kernel driver in use: i915
<alkisg> tjaalton: that's the only info I have, from one of those schools
<alkisg> They didn't have any issues up to -48 though; this issue mentions that -46 had a problem...
<tjaalton> that's something else then and not related to graphics
<alkisg> Thank you tjaalton; if it becomes more frequent I'll have a deeper look
<tjaalton> file a bug
<alkisg> I don't feel well to file bugs when it's not easy to provide feedback; if I can reproduce in the office that's easy;
<alkisg> if not, I VNC to the school, but e.g. now that they had that easy workaround with -hwe, they wouldn't want the downtime involved to send a lot of debug information, as it usually means teachers can't give lessons then
<alkisg> So they are only very happy to give debug info when they don't have workarounds :D
<tjaalton> k
#ubuntu-x 2020-05-18
<tseliot> ricotz, 440.82 is in groovy now (just uploaded)
<ricotz> tseliot, thanks!
<tseliot> np
