#ubuntu-x 2007-01-08
<Ubugtu> New bug: #78449 in xserver-xorg-driver-i810 (main) "Xorg+gdm goes into restart loop after crash caused by running some OpenGL applications" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78449
#ubuntu-x 2007-01-09
<Ubugtu> New bug: #78536 in xorg (main) "man pages not installed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78536
<Ubugtu> New bug: #78594 in xserver-xorg-input-synaptics (main) "touchpad disabling button requires workaround" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78594
<Ubugtu> New bug: #78617 in xorg (main) "edgy and feisty after update i get 640x480 only" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78617
#ubuntu-x 2007-01-10
<Ubugtu> New bug: #78632 in xorg-server (main) "autodetection of Xinerama when creating xorg.conf" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78632
<Ubugtu> New bug: #78671 in mesa (main) "Old version, upgrade needed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78671
<Ubugtu> New bug: #78718 in xserver-kdrive (universe) "Xephyr don't handle the "alt car" key in ca_FR keymap" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78718
<Ubugtu> New bug: #78734 in xserver-xorg-video-ati (main) "[rv280]  strange behaviour of xv and gl windows under aiglx (beryl)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78734
#ubuntu-x 2007-01-11
<Ubugtu> New bug: #78740 in linux-restricted-modules-2.6.17 (restricted) "nvidia twinview garbage second monitor" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78740
<Ubugtu> New bug: #78755 in xorg (main) "X Does Not Start From Installation CD" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78755
<Ubugtu> New bug: #78772 in xorg-server (main) "memory leak in xorg i810 of 6.06?" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78772
<Ubugtu> New bug: #70269 in gok (universe) "gok not starting with vnc, but starting with nx (dup-of: 58600)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/70269
<Ubugtu> New bug: #72771 in gok (universe) "fails to launch (dup-of: 58600)" [Undecided,Rejected]  https://launchpad.net/bugs/72771
<Ubugtu> New bug: #78783 in xorg (main) "Disabling and re-enabling DPMS doesn't work" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78783
<Ubugtu> New bug: #77984 in xorg (main) "Changing display brightness kills GDM" [Undecided,Unconfirmed]  https://launchpad.net/bugs/77984
<Ubugtu> New bug: #77565 in Ubuntu "xserver doesn't start (Feisty, 6.06 and 5.10) (dup-of: 28925)" [Undecided,Needs info]  https://launchpad.net/bugs/77565
<Ubugtu> New bug: #78842 in xorg (main) "Kubuntu Feisty Fawn don't find my screen" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78842
#ubuntu-x 2007-01-12
<Ubugtu> New bug: #78878 in xorg (main) "xserver hang running gl screensaver" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78878
<Ubug2> New bug: #78982 in xorg-server (main) "starting xawtv crashes Xorg server" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78982
#ubuntu-x 2007-01-13
<Ubugtu> New bug: #79016 in xserver-xorg-video-nv (main) "Wrong resolution with an nvidia GeForceGo 7300" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79016
<Ubugtu> New bug: #79017 in xserver-xorg-video-nv (main) "Wrong resolution with an nvidia GeForceGo 7300" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79017
<Ubugtu> New bug: #79032 in libx11 (main) "OpenOffice can't open files with russian characters in a name" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79032
* netjoined: irc.freenode.net -> brown.freenode.net
<Ubugtu> New bug: #79071 in xorg-server (main) "xserver-xorg-core update breaks Nvidia glx" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79071
#ubuntu-x 2007-01-14
<Ubugtu> New bug: #79166 in xserver-xorg-input-synaptics (main) "Erratic cursor after vt-switching in Feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79166
<Ubugtu> New bug: #79196 in xorg-server (main) "xserver-xorg-core_1.1.1-0ubuntu12_i386 brakes compiz (white screen)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79196
<Ubugtu> New bug: #79236 in Ubuntu "AMD64 Feisty: xserver freezes at startup (not Mach64) (dup-of: 44981)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79236
#ubuntu-x 2008-01-07
<joumetal> tjaalton: your suggestion gave working X in bug 178837 :)
<ubotu> Launchpad bug 178837 in xserver-xorg-video-intel "X Server fails to start. -- Intel i815" [High,Confirmed] https://launchpad.net/bugs/178837
<tjaalton> joumetal: great, I just noticed your reply
<tjaalton> joumetal: so you still don't have any "Depth" setting in the xorg.conf and it works?
<tjaalton> "Defaultdepth" I mean
<joumetal> yep. no Defaultdepth.
<tjaalton> great
<tjaalton> could you attach your Xorg.0.log to the bug so I can have a final look?
<joumetal> tjaalton: done
<tjaalton> yep, looks correct
<ubotu> New bug: #180960 in xorg "X aborts w/ backtrace: 'Mode pool is empty' and 'No valid modes found'" [Undecided,New] https://launchpad.net/bugs/180960
<ubotu> New bug: #180968 in xserver-xorg-input-vmmouse (universe) "vmmouse clicks are all reported as being the bottom left corner." [Undecided,New] https://launchpad.net/bugs/180968
<ubotu> New bug: #180979 in xorg (main) "no graphical output without extensive manual configuration" [Undecided,New] https://launchpad.net/bugs/180979
<ubotu> New bug: #122083 in linux-restricted-modules-2.6.22 "Desktop Effects return to X fails" [Undecided,New] https://launchpad.net/bugs/122083
<joumetal> bug 134370 Is confirmed in hardy daily 5. January. I would like to provide more information.
<ubotu> Launchpad bug 134370 in xserver-xorg-video-ati "Video dosen't play correctly in Totem" [Low,Incomplete] https://launchpad.net/bugs/134370
<tjaalton> joumetal: on what version?
<joumetal> on hardy.
<tjaalton> check the latest driver from https://wiki.ubuntu.com/XorgOnTheEdge
<tjaalton> otherwise just reply to the bug, tormod is more uptodate with ati, and not here atm
<bryce> tjaalton: I've not seen tormod in a while, have you?
<ubotu> New bug: #174941 in xserver-xorg-video-intel (main) "Xorg crashed with SIGSEGV in i830_free_memory()" [Medium,New] https://launchpad.net/bugs/174941
<tjaalton> bryce: he's been here, but silent
<bryce> ok
<bryce> I'm devoting today to try to catch up on -intel bug triage
<tjaalton> cool, I'll merge xserver, and add the patch that'll make it use openchrome by default instead of via
<tjaalton> bug 180960 is also something that's worth patching, imstt defaults to fbdev currently
<tjaalton> well, all those that aren't mapped to a specific driver default to fbdev
<ubotu> Launchpad bug 180960 in xorg-server "X aborts w/ backtrace: 'Mode pool is empty' and 'No valid modes found'" [Unknown,Confirmed] https://launchpad.net/bugs/180960
<bryce> what is imstt?
<tjaalton> "IMS TwinTurbo"
<bryce> I've created a new tag 'forward-upstream' to mark bugs that look like they should be re-summarized and posted to xorg bug tracker
<bryce> I'll plan on doing bug forwarding another day,maybe tomorrow
<tjaalton> a graphics card apparently :)
<tjaalton> cool
<bryce> huh
<tjaalton> x-x-v-imstt is the driver
<tjaalton> very rare, I think
<tjaalton> the bug was reported on some old ppc mac
<bryce> btw, for inkscape we did a contest to draw the 0.46 about screen - here are the entries: http://inkscapers.deviantart.com/journal/16298574/
<tjaalton> yep, ~10y old machine..
<bryce> wow
<bryce> it boggles the mind
<bryce> I'd quip that if they're content to use a 10y old piece of hardware, ought they not be content to stick with an older distro too?  ;-)
<tjaalton> numbers 1 and 6 are my favorites from the list
<bryce> looks like #7 is doing best in the voting.  It's a good one.
<Q-FUNK> bryce: that reminds me:  did you say that inkscape had migrated to libgtkprint?
<bryce> yup
<tjaalton> oh right, it's nice
<bryce> keescook did the integration on that
<Q-FUNK> lovely :)
<bryce> yeah the print dialog has been a major wart for a long time.  Kees banged it out at UDS/AllHands a few months back and got it finished up over the holidays
<tjaalton> oh right.. the old dialog is/was horrid :)
<tjaalton> hmm, interesting bug, bug 30969
<ubotu> Launchpad bug 30969 in xorg "xorg suspends monitor regardless of gnome-power-manager timeouts" [Medium,Confirmed] https://launchpad.net/bugs/30969
<tjaalton> the server defaults to DPMS being turned on
<tjaalton> so maybe it shouldn't do that
<tjaalton> the bug I mentioned is in gnome-power-manager after all
<tjaalton> xserver is right, but g-p-m just ignores gnome-screensaver settings if it's disabled
#ubuntu-x 2008-01-08
<ubotu> New bug: #181167 in xserver-xorg-driver-vesa (main) "ATI x1400 xserver fails to start" [Undecided,New] https://launchpad.net/bugs/181167
<ubotu> New bug: #181169 in linux-restricted-modules-2.6.24 (restricted) "package nvidia-glx-new 169.07+2.6.24.3-2.9 failed to install/upgrade: dependencies" [Undecided,New] https://launchpad.net/bugs/181169
<ubotu> New bug: #181171 in linux-restricted-modules-2.6.24 (restricted) "package linux-restricted-modules-2.6.24-2-386 2.6.24.3-2.9 failed to install/upgrade: dependencies" [Undecided,New] https://launchpad.net/bugs/181171
<ubotu> New bug: #181176 in xorg-server (main) "xserver-xorg-core /usr/bin/X goes into infinate loop on Toshiba Satellite 1800" [Undecided,New] https://launchpad.net/bugs/181176
<pwnguin> i'm filing a bug in the upstream bugzilla for #180884
<pwnguin> is the product and version xorg/7.3?
<pwnguin> bug #180884
<ubotu> Launchpad bug 180884 in xorg-server "xkbLEDs causes segfault on login" [Undecided,New] https://launchpad.net/bugs/180884
<tjaalton> pwnguin: xserver is better
<pwnguin> doesnt exist
<pwnguin> freedesktop bugzilla
<pwnguin> well, i should probably apply today's updates and double check it's still broken
<tjaalton> the server was not updated
<tjaalton> pick Server/general as a Component
<tjaalton> the search page shows xserver..
<tjaalton> that's where I got it :)
<pwnguin> https://bugs.freedesktop.org/enter_bug.cgi
<pwnguin> it's not on the list =(
<tjaalton> pick xorg
<pwnguin> thats what ive done
<tjaalton> the next page lets you specify the component
<pwnguin> yes yes
<pwnguin> should i mention the LP bug or will LP make announce itself upstream when I link the bug in LP
<tjaalton> mention it
<tjaalton> it won't do anything automatically
<pwnguin> thanks
<pwnguin> ok. that tags sidebar is getting out of hand on LP
<tjaalton> ignore it :)
<tjaalton> known issue
<ubotu> New bug: #181181 in linux-restricted-modules-2.6.24 (restricted) "linux-restricted-modules -rt flavour required for UbuntuStudio alpha." [Undecided,New] https://launchpad.net/bugs/181181
<ubotu> New bug: #181203 in xorg (main) "[hardy] The following packages have been kept back: xserver-xorg-video-all " [Undecided,New] https://launchpad.net/bugs/181203
<ubotu> New bug: #21799 in xfonts-core (main) "Fonts in this package only show in "0" and "17" pixels size" [Medium,Invalid] https://launchpad.net/bugs/21799
<ubotu> New bug: #181243 in linux-restricted-modules-2.6.24 (restricted) "new legacy drivers cause X to crash" [Undecided,New] https://launchpad.net/bugs/181243
<shaya> who else is having issues w/ xcb and java?
<seb128> shaya: a quick google query gave bug #86103
<ubotu> Launchpad bug 86103 in sun-java5 "azureus-> java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." [High,Confirmed] https://launchpad.net/bugs/86103
<jcristau> that's fixed in java7 and icedtea
<tjaalton> shaya: just use LIBXCB_ALLOW_SLOPPY_LOCK=true ./java-app
<shaya> that worked
<tjaalton> more permanent workaround: less /usr/share/doc/libx11-6/NEWS.Debian.gz
<shaya> so is icedtea-java7 going to be the real java7?
<tjaalton> no
<tjaalton> icedtea is the redhat-packaged version
<tjaalton> sun-java7 is different
<shaya> hmm
<tjaalton> but they should both work with xcb
<shaya> no sun-java7 right now
<shaya> just icedtea
<tjaalton> right
<tjaalton> sun-java7 is in beta
<shaya> hmm, dont need xinerama
<shaya> dont have multimonitor
<shaya> is it possible to prevent the xserver from loading the xinerama extension?
<shaya> also, the sed line should be /usr/lib/jvm/java-6-sun/... not /usr/lib/jvm/java-6-sun-1.6.0.00/
<shaya> as the no version is a symlink the version
<shaya> and the version is currently wrong
<shaya> and can become more wrong in future
<tjaalton> whatever you have installed
<shaya> I have /usr/lib/jvm/java-6-sun -> java-6-sun-1.6.0.03
<tjaalton> there you go
<shaya> right
<shaya> I knew what to do
<shaya> what I'm saying is that if the instructions in NEWS said to use the non versioned one, it should always work
<tjaalton> people probably understand what to do when the command fails
<shaya> shrug.  ok, just was making a comment to make it clearer, but no biggy
<tjaalton> not worth it to make a new NEWS entry just for that
<shaya> news entries can't be edited?
<shaya> ok then
<tjaalton> silly to carry a diff just for that
<tjaalton> unless it's changed in debian
<shaya> ok
<shaya> so poke the debian people then
<ubotu> New bug: #181268 in xorg (main) "Xorg does not detect the correct settings for old monitors at Ubuntu install" [Undecided,New] https://launchpad.net/bugs/181268
<tjaalton> bryce: I've done a bunch of uploads today, and the intel update should fix a whole bunch of bugs
<tjaalton> +especially
<bryce> awesome
<bryce> yeah I got distracted from my triaging yesterday :-/
<bryce> http://bryceharrington.org/drupal/node/25
<bryce> good news is I have a nifty new tool
<tjaalton> great, I'll check it out
<tjaalton> your blog is not on planet.u.c btw
<bryce> yeah
<bryce> not really sure what's required to get on it
<tjaalton> pretty simple, just bzr pull the config, add yourself and push
<tjaalton> there's a link to the instructions on p.u.c
<bryce> ah ok
<bryce> well I probably ought to find how to categorize blog posts in drupal first, since I post a lot of inkscape and other stuff on my blog most ubuntuer's wouldn't care about
<tedg> bryce: Honestly, planets are about learning about the people and all their interests, not just news that people care about.
<bryce> yeah I'm pretty sure the ubuntu planet doesn't want to see my sasquatch ramblings
<tedg> I wouldn't go as far to say that.
<tedg> If nothing else the GNOME logo is very related to sasquatches (sp?) sasquatchi?
<tjaalton> hmm, the gnome logo.. doesn't it look surprisingly similar as this one (poor picture, but I guess the outlines are visible) http://www.polyteekkarimuseo.fi/6.html
<tjaalton> that's from the "polytechnic museum"
<tjaalton> and tigert is a finn, so I bet he has seen that "footprint of an ancient student" before :)
<ubotu> New bug: #178199 in ubuntu "[Hardy Alpha 2] Scroll Wheel problems (dup-of: 177492)" [Undecided,New] https://launchpad.net/bugs/178199
<tjaalton> bryce: hmm, did you add the same tags to every -intel bug?-)
<bryce> tjaalton: no, why?
<tjaalton> they all seem to have the same set of tags :)
<tjaalton> well, "all"
<tjaalton> " bitesize  packaging  likely-dupe  forward-upstream  needs-improvement  verification-needed"
<tjaalton> same for xorg
<bryce> hmm
<tjaalton> maybe a bug in the greasmonkey script?
<tjaalton> +e
<bryce> can you show me a screenshot?
<tjaalton> aaah
<tjaalton> "Add tag: ..." :)
<tjaalton> so it's enabled for me :)
<tjaalton> I'm blind, and it's getting late
<bryce> hehe
<tjaalton> hmm, I just realized.. the openchrome driver does not have the patch to extract pciids in a text file, so alpha3 will not work with it
<tjaalton> need to make a new upload tomorrow :/
#ubuntu-x 2008-01-09
<tjaalton> sigh.. the openchrome uses CDBS, and the documentation is offline
<tjaalton> ah, the package has some
<tjaalton> ffs.. the openchrome package is crap.. I can't build the source after test building the binary
<tjaalton> "unrepresentable changes to source"
<bryce> erf
<tjaalton> finally
<tjaalton> now to bed, bye! ->
<bryce> cya
<ubotu> New bug: #162740 in xserver-xorg-video-intel (universe) "blender-bin crashed with SIGSEGV when starting it (DRI related)" [Undecided,Incomplete] https://launchpad.net/bugs/162740
<ubotu> New bug: #42990 in xkbutils "XGL breaks setxkbmap (kde)" [Medium,Triaged] https://launchpad.net/bugs/42990
<bryce> tjaalton: hmm, I added my blog to planet-ubuntu a while ago, yet my past posts did not show up.  Perhaps it only pulls new ones?  I'll have to mess with it
<tjaalton> bryce: yes, new ones only
<tjaalton> and maybe if you modify an older post
<bryce> nope; I tried modifying the bug tool post (added a screenshot) but it didn't show up
<bryce> I'll do another post and check that it shows up
<bryce> wow, all my inkscape bug work over the holidays bumped my karma up quite a bit
<tjaalton> heh
<tjaalton> there's an upstream intel branch about which should fix EXA slowness, and I tried to build it, but failed. I'll try again today
<tjaalton> "intel-batchbuffer"
<bryce> oh btw, brian murray found a bug in the greasemonkey tag script where if there is a + or & in the description, the tool may change the description inappropriately
<tjaalton> ok, I'll update it
<bryce> tjaalton: has -intel fixed the issue that prevents DRI for virtual displays larger than 2048x2048?
<bryce> (bug #164049)
<ubotu> Launchpad bug 164049 in xserver-xorg-video-intel "intel xorg driver disables direct rendering for virtual display larger than 2048" [Low,Confirmed] https://launchpad.net/bugs/164049
<bryce> I ask because in bug 174745, they report the crash was caused by having a virtual size over 2048x2048
<ubotu> Launchpad bug 174745 in xserver-xorg-video-intel "xorg lockup when screen is rotated" [Undecided,Confirmed] https://launchpad.net/bugs/174745
<tjaalton> no, it requires TTM
<tjaalton> AIUI
<bryce> ahh
<bryce> yay!  all -intel bug triaging is caught up :-)
<tjaalton> heh, I noticed that my "launchpad-x" mailbox filled up :)
<bryce> :=)
<bryce> I got a couple new widescreen monitors today, but vowed to get -intel triaging done before I even opened the boxes
<tjaalton> hehe, what models?
<bryce> BenQ
<tjaalton> sweet, I bought a BenQ last month
<bryce> I've never bought benq before, but I did some pretty thorough research and they came out on top for my requirements
<bryce> they also were quite highly rated on newegg, so I'm very optimistic
<bryce> but...  if I'm offline all day tomorrow you'll know why ;-)
<tjaalton> heh, ok!
<tjaalton> mine is a 24" with hdmi input
<bryce> oh maybe I've got the same
<tjaalton> so even if we won't get a new telly anytime soon, I'm still able to get a PS3 and use the full resolution
<bryce> MNTR BENQ|24" LCD 16MS HDMI FP241W
<tjaalton> yep, same model
<tjaalton> you've certainly done your research :)
<bryce> 8-)
<tjaalton> I could've bought a 24" model half the price, but I knew this one had a higher quality panle
<tjaalton> -el
<bryce> how's HDMI work?  dell was asking me about if we've done testing of that
<bryce> yeah
<tjaalton> I don't have a gfx card with HDMI
<bryce> ah
<tjaalton> apparently there are still issues
<bryce> me either
<bryce> have you played with s-video?
<tjaalton> at least alsa lacks some support for transporting audio over it, but I guess it's almost ready
<tjaalton> my old laptop (T23) has an s-video port
<bryce> here's what you need for your TV:  http://blog.wired.com/gadgets/2008/01/ces-2008-keynot.html
<tjaalton> hmm, let me recover the firefox sesssion
<tjaalton> -s
<tjaalton> ah, that one.. a bit pricey, but otherwise seems quite nice :)
<tjaalton> I wonder how much power that monster will suck
<bryce> yeah no kidding
<bryce> but it sounds like it'd play youtube videos really well, so hey
<tjaalton> yep, 400x300 (?) clips on a 4096x2160 screen :)
<bryce> awwsome
<bryce> oh btw, I learned a mechanism for marking bugs as "needs forwarded upstream" and started marking -intel bugs that look ready to report upstream
<bryce> I wanted to focus on getting through the preliminary triage so put off reporting them upstream for now, but plan to spend a day or so in the next week or two pushing bugs upstream
<tjaalton> ok, cool
<tjaalton> the newest version should fix quite a fex bugs
<bryce> excellent
<bryce> the way to mark bugs as needs forwarded is to go Affects +Project, then submit without entering a bug url.  Easy
<bryce> if you run across other bugs that look ready to go upstream, mark 'em
<tjaalton> ok, good to know
<ubotu> New bug: #181437 in linux-restricted-modules-2.6.24 (restricted) "Segmenation fault when executing aticonfig" [Undecided,New] https://launchpad.net/bugs/181437
<ubotu> New bug: #181434 in xorg (main) "Blue screen with videos with Hardy Xorg 7.3" [Undecided,New] https://launchpad.net/bugs/181434
<bryce> tjaalton: is the new version 2.2.1?
<bryce> sounds like it'll fix VT switching and some startup issues
<tjaalton> it's from the stable branch, so it'll become 2.2.1
<tjaalton> not released yet though
<bryce> gotcha
<bryce> sounds like 2.2.1 is scheduled to be released within the month
<bryce> 2.3 is planned for early March and will focus on modesetting bugs
<tjaalton> it was supposed to be out before christmas
<tjaalton> but yeah
<bryce> heh
<tjaalton> sigh, pretty annoying bugs in the xserver.. keys are stuck when you press then long enough
<tjaalton> like, when playing with compiz settings like fire :)
<ubotu> New bug: #179164 in xorg (main) "Xorg failsafe mode throws out Xorg.log" [Undecided,New] https://launchpad.net/bugs/179164
<ubotu> New bug: #181485 in xserver-xorg-video-ati (main) "ati driver blocks the system" [Undecided,New] https://launchpad.net/bugs/181485
<ubotu> New bug: #178935 in xserver-xorg-driver-ati (main) "screen stays off when opening laptop lid with screensaver on" [Undecided,New] https://launchpad.net/bugs/178935
<ubotu> New bug: #181526 in xserver-xorg-input-evdev (main) "[hardy] [evdev with X Input hotplug] changes keymap to greek regularly" [Undecided,New] https://launchpad.net/bugs/181526
<ubotu> New bug: #181568 in linux-restricted-modules-2.6.24 (restricted) "aticonfig --enable-monitor=lvds crashes X" [Undecided,New] https://launchpad.net/bugs/181568
<ubotu> New bug: #181573 in xserver-xorg-driver-ati (main) "[Hardy]Radeon Xpress 1100 IGP: screen gets partly black for a while" [Undecided,New] https://launchpad.net/bugs/181573
<ubotu> New bug: #181334 in newt (main) "Default console font unsuitable for debconf / whiptail" [Undecided,New] https://launchpad.net/bugs/181334
<ubotu> New bug: #181595 in xkeyboard-config (main) "unable to type <, > and | while using Finnish layout on a 101-key keyboard" [Undecided,New] https://launchpad.net/bugs/181595
<ubotu> New bug: #181602 in xserver-xorg-video-ati (main) "ATI driver update causes Display Corruption on ATI Radeon 9500 AGP" [Undecided,New] https://launchpad.net/bugs/181602
<ubotu> New bug: #181121 in linux-restricted-modules-2.6.24 (restricted) "glplanet crashed with SIGSEGV" [Undecided,Incomplete] https://launchpad.net/bugs/181121
<ubotu> New bug: #181638 in linux-restricted-modules-2.6.24 (restricted) "ipw3945 fails to load" [Undecided,New] https://launchpad.net/bugs/181638
#ubuntu-x 2008-01-10
<bryce> tjaalton: these BenQ's are sweeeeeet :-)
<tjaalton> bryce: yep :)
<tjaalton> bryce: I don't know if you noticed airlied's reply to my question about intel, but it seems that we won't get a fixed intel EXA in time for hardy :/
<tjaalton> so the performance will continue to suck, unless we switch back to XAA
<tjaalton> aha, Zhenyu Wang from intel confirmed that it will require TTM, so it's a no-go then :(
<tjaalton> freedesktop bug 13389
<tjaalton> bah, no ubotu
<tjaalton> http://bugs.freedesktop.org/show_bug.cgi?id=13389
<bryce> hrm
<bryce> E_TOOMUCHSUCKAGE
<bryce> sorry, I'm fussing with my viewsonic monitor and it's acting screwy
<tjaalton> bryce: I reopened the "no compiz on 965" bug..
<tjaalton> since there is no viable option to switching back to XAA
<mvo> tjaalton: what bugnumber is that?
<tjaalton> mvo: https://bugs.launchpad.net/bugs/148247
<tjaalton> no ubotu here :)
<bryce> tjaalton: yeah...
<tjaalton> mvo: to make EXA performance better it would need the new memory manager
<bryce> tjaalton: so sounds like we're going to have to leave compiz disabled for 965 again?
<bryce> heh, there's an entire HOWTO devoted to this combination of ViewSonic monitor and nvidia hardware.  sheesh
<bryce> (http://ubuntuforums.org/archive/index.php/t-274291.html)
<tjaalton> bryce: maybe so yep..
<mvo> meh, ok. when is the upload going to happen that switches again?
<tjaalton> after alpha3
<mvo> ok, thanks
<tjaalton> bryce: I so love all these "howtos" that do silly things to the xorg.conf..
<bryce> yeah no kidding
<tjaalton> like having six different subsections for Display
<bryce> I'm having this weird blanking problem with this viewsonic monitor
<bryce> like, for a few minutes after booting up it's fine, but then it blinks off black for a second
<bryce> and then a minute later, it does it again
<tjaalton> it happens with my benq too, so it's probably nvidia problem..
<tjaalton> although it's not that frequent
<bryce> it keeps periodically blinking like this, until it finally goes completely black
<tjaalton> maybe once a day
<tjaalton> heh, ok
<bryce> no this is with my viewsonic, not the benq's.  The benq's are great
<bryce> yeah I'm a glutton; now that I have two widescreen monitors set up, I want a third.  8-)
<tjaalton> hehe
<bryce> I think it might be the nv card.  I should just get an ati to put in there
 * tjaalton runs for the bus ->
<bryce> tjaalton: I've passed word along about the EXA issue
<tjaalton> bryce: nice
<tjaalton> 3G rocks, btw :)
<bryce> 3G?
<tjaalton> "3rd generation" of mobile modems :)
<bryce> ahh
<tjaalton> "umts" is probably the technical term
<bryce> I'm finding that perhaps the viewsonic issue I'm having is that it has a flaky DVI implementation.  bugger.
<tjaalton> try with the ati
<bryce> I'll have to buy one; I don't have a spare that's the right interface type
<tjaalton> heh, ok
<bryce> heya seb128
<seb128> hey bryce
<mvo> good morning seb128
<seb128> hello mvo
<bryce> timo, yeah it is looking like it's an nvidia problem...  it puts the monitor into EDID sleep mode, but can't wake it
<bryce> aha, think I fixed it
<tjaalton> bryce: how?
<bryce> I found a post that suggested this funky approach of plugging and unplugging things in a particular order.  I did it, and haven't had a blank yet.
<bryce> http://www.munky.net/hardware/viewsonic-dvi/
<bryce> sounds like the procedure results in resetting the hardware edid
<bryce> tjaalton: do the usb ports on your monitor's work?  (next on my todo list is to play with them...)
<tjaalton> I'm not sure i've tried them yet
<tjaalton> it's just a hub, so should work
<tjaalton> remember to connect the cable first :)
<bryce> oh crap, I spoke too soon; there goes the viewsonic
<bryce> weird.
<bryce> eh, problem for another day.
<tjaalton> heh
<bryce> I had it working fine with one of my test machines - I'll have to check if that was ATI based
<bryce> oh wait, that was VGA
<bryce> ok... so probably I'll just need to find a longer vga cable or something
<bryce> maybe it's a heat issue.  hmm
<bryce> nice, the usb on the monitors appears to "just work"
<tjaalton> yep, it's handy
<bryce> kinda dark, but... http://bryceharrington.org/Photos/my_desk.jpg
<tjaalton> ffs, I'm fed up with the nvidia "out-of-pixmem" bug.. I need to upgrade my work machine! :)
<tjaalton> sheesh, quite a desk you've got there
<tjaalton> mythtv!
<tjaalton> hold on, I took a picture of mine
<tjaalton> http://users.tkk.fi/~tjaalton/foo/10012008044.jpg
<tjaalton> oh wait
<tjaalton> now
<bryce> niice
<tjaalton> this is from the uni
<bryce> yeah, I made the desk myself...  http://bryceharrington.org/Photos/Woodworking/Desk/
<tjaalton> oh cool, I've done loudspeakers myself :)
<tjaalton> quite a nice finish
<bryce> ugh, that took forever
<tjaalton> heh, I bet
<bryce> hmm, I wonder if you have a different model BENQ; you've got a sticker or something top center, but mine's on the top right.
<tjaalton> mine too
<bryce> night timo.  http://bryceharrington.org/drupal/node/26
<tjaalton> night!
<ubotu> New bug: #181732 in xorg (main) "[hardy][livecd] xorg configuration problems on qemu-kvm" [Undecided,New] https://launchpad.net/bugs/181732
<ubotu> New bug: #159750 in ubuntu "screen resolution change ignored (dup-of: 154380)" [Undecided,New] https://launchpad.net/bugs/159750
<ubotu> New bug: #181478 in xorg (main) "Hardy Heron Alpha 2 - GDM login screen restarts to infinitum if some process crashes" [Undecided,New] https://launchpad.net/bugs/181478
<soren> tjaalton: If you're looking at 181732, the kvm (and kernel bits) in hardy should be sufficient.
<tjaalton> soren: ok thanks, I'll reinstall my workstation today, and since vmware doesn't work I might just as well try kvm :)
<tjaalton> on top of it
<soren> tjaalton: Be sure to let me know if there are any problems with kvm.
<tjaalton> soren: sure, thanks
<ubotu> New bug: #181781 in xorg (main) "Visualizations crasches X" [Undecided,New] https://launchpad.net/bugs/181781
<reynaldo> hi folks, I was wondering if maybe i could use your wisdom to setup my Radeon Xpress 200M card to work in a good way with xorg's ati driver
<reynaldo> the fos driver
<reynaldo> I'm on hardy, tryied it already, problem is it ends up been _so_ slow is barely usable
<reynaldo> even 2D performance is unbearable
<reynaldo> maybe this is not a bug and there is some tweaking that should be done ?
<reynaldo> some tweaking I might be not aware of?
<reynaldo> this is a cheap gateway laptop with 2G ram and a 1.73 core duo proc
<reynaldo> I'd expect the fos driver to behave a lot better
<reynaldo> no need to be blaze speed or anything like it, but at least usable
<tjaalton> post the log somewhere
<reynaldo> xorg log ?
<reynaldo> ok
<tjaalton> yes
<tjaalton> pastebin etc
<reynaldo> tjaalton: http://www2.udec.cl/~rverdejo/Xorg.0.log
<tjaalton> (WW) RADEON(0): Direct rendering disabled
<tjaalton> wonder why that is
<reynaldo> can I force it to be enable ?
<reynaldo> I'm not to good at my xorg kunfu
<reynaldo> too
<tjaalton> Option "DRI" "true" perhaps
<tjaalton> I need to jump off the bus soon :)
<reynaldo> http://paste.lisp.org/display/53967
<reynaldo> tjaalton: please give me a few minutes of help :-)
<reynaldo> it shouldn't take long
<tjaalton> yeah, but I need to get off in a minute
<reynaldo> okie
<tjaalton> so 30min offline ->
<reynaldo> turning on DRI then
<reynaldo> amazing
<reynaldo> complete freeze at restarting gdm
<reynaldo> let me try restarting
<reynaldo> tjaalton: http://www.udec.cl/~rverdejo/Xorg.0.log
<reynaldo> now i get a garbled screen, mouse works and I can swithc to a vt
<reynaldo> other than that I cant login through gdm because I can't even see its loing dialog box
<reynaldo> login
<reynaldo> tjaalton: http://www2.udec.cl/~rverdejo/screen_garbled_with_dri_enabled_radeonXpress200M.png
<reynaldo> thats how it looks like
<reynaldo> tjaalton: you still with me ?
<reynaldo> tjaalton: now the computer freezed, didn't do anything other than wait
<reynaldo> _weird_
<reynaldo> got it, the switch back to vt7 to take the picture was what freezed the laptop
<reynaldo> so, with dri enable xorg garbles the screen, i can switch to a vt to take a log for instance, but the minute I switch back to vt7 the laptop freezed entirely
<reynaldo> that would be all
<reynaldo> you got pictures of the garbled screen and a full log of xorg with dri enable
<reynaldo> im uploading the original log with dri disabled under a different name
<reynaldo> http://www2.udec.cl/~rverdejo/Xorg.0.log-withoutDRI
<reynaldo> ok, that's the original log, the one with DRI disabled, works uterly _slow_
<reynaldo> almost undearable, you can almost see the redrawing
<tjaalton> so it's disabled for a reason :)
<tjaalton> try changing the driver to vesa then
<jcristau> vesa probably won't be any faster
<tjaalton> could be true
<reynaldo> I seem to recall i already tryied vesa with no better results but I will try it again see what happens
<reynaldo> propietary ati driver isn't working neither, session gets inmediately terminated
<tjaalton> reynaldo: did it use to be any faster with an earlier release?
<reynaldo> gutsy, but i had no splash screen, the whole story is that this is a brother's laptop, he wanted to try out ubuntu so while he is in town he lended it to me for me to install ubuntu on it
<reynaldo> gutsy worked bad.
<reynaldo> so.. i went hardy's way
<reynaldo> I have had his machine for like a week, with no pleasant results
<reynaldo> totally pita been honest
<bryce> tjaalton: some questions about dexconf in #ubuntu-devel when you have a chance
<tjaalton> bryce: ok
<reynaldo> tjaalton: i kind of forgot in gutsy the laptop didn't had sound working neithe
<reynaldo> r
<reynaldo> so going to hardy was somewhat of a given
<tjaalton> ok
 * tjaalton goes on the couch
<reynaldo> :/
<reynaldo> tjaalton: vesa doesn't work in the 'xserver doesn't start' sence
<reynaldo> I'm uploading a log
<reynaldo> tjaalton: http://www.udec.cl/~rverdejo/Xorg.0.log-withVESA
<reynaldo> just wondering, wasn't xorg with ati propietary drivers supposed to be able to use compiz and 3d stuff without xorg-xgl ?
<reynaldo> I recall reading something about them using aixgl
<bryce> tjaalton: work back from Rolla about the EXA issue:
<bryce> s/work/word/
<bryce> Hey Bryce,
<bryce> Not sure what you mean specifically by "it seems that we won't get a
<bryce> fixed intel EXA in time for hardy".  I just talked to Keith, and he said
<bryce> that EXA works fine with the old memory manager.
<bryce> He did say, however, that'll all change after Cantiga ships and we start
<bryce> tearing the driver apart, but that won't be 'till after Hardy.
<bryce> rs
<tjaalton> yes EXA works, but the performance sucks..
<bryce> I'll send her the bug
<tjaalton> #177492
<tjaalton> Bug #177492
<ubotu> Launchpad bug 177492 in xserver-xorg-video-intel "EXA is balls-achingly slow" [High,Confirmed] https://launchpad.net/bugs/177492
<bryce> hehe
<bryce> also bug 148247 you mentioned yesterday
<ubotu> Launchpad bug 148247 in xserver-xorg-video-intel "Compiz not supported for G965" [High,Confirmed] https://launchpad.net/bugs/148247
<ubotu> New bug: #181885 in xserver-xorg-input-synaptics (main) "Two-finger scroll and two-finger middle click together handled poorly" [Undecided,New] https://launchpad.net/bugs/181885
<tjaalton> yep, she's already commented that one
<tjaalton> earlier
<tjaalton> maybe I've misunderstood, I really hope so :)
<bryce> tjaalton: btw, when you build packages, you don't use pbuilder, right?  are you just doing debuild -i -uc -us -S ?
<bryce> tjaalton: btw, I've got a newer libdrm based off a git snapshot built (for UME)
<bryce> I wasn't planning on incorporating it for Ubuntu, but if a newer libdrm would help, we've got the newer package available
<tjaalton> for binaries I normally use pbuilder, unless it's just one file that's needed, then it's 'fakeroot debian/rules install' or similar :)
<bryce> I've been having trouble using pbuilder when building a package and a new version of its dependency
<bryce> in particular, libdrm for -psb
<tjaalton> oh right, it won't work
<bryce> I'm not sure how to build -psb using the new libdrm with pbuilder 
<tjaalton> it would be hard
<bryce> so is debuild -i -uc -us the best approach in this case?
<bryce> heh
<bryce> yeah no kidding
<tjaalton> yes, if you don't need to sign them
<tjaalton> but what's the '-i' for?
<jcristau> you can do lots of stuff using pbuilder hooks, i think (don't use it though, i use a plain chroot)
<tjaalton> it's still icky
<jcristau> tjaalton: dpkg-source -i ignores VCS files when generating the diff
<bryce> jcristau: I did give a shot at using pbuilder hooks, but could never git it to actually notice the deps and use them
<tjaalton> jcristau: oh, so just having -i is enough for the most uses..
<bryce> hrm, ok sounds like at least I'm not missing anything... 
<tjaalton> hmm, now to think of it I've used -i".git" for xorg/xorg-server :P
<tjaalton> or -I".git"
<tjaalton> so the regex is probably not needed
<jcristau> it was before dpkg-dev knew about git :)
<tjaalton> heh, seems that it was done long ago :)
<bryce> tjaalton: for this bug, aside from the performance issue, did we get rid of that dvd playback issue by going to EXA?
<tjaalton> bryce: hmm, I don't remember that one..
<bryce> "XV does not play with XAA under compiz, only with EXA" - http://wiki.compiz-fusion.org/Hardware/Blacklist
<bryce> it's mentioned in the OP of 148247 so I'm curious if going to XAA would reopen that issue
<tjaalton> I guess so, yes
<tjaalton> I'll test on my laptop..
<tjaalton> not that it has a dvd-drive.. or any drive for that matter :)
<tjaalton> (besides hd)
<tjaalton> right, Xv doesn't work
<bryce> rats
<tjaalton> but you can disable it
<tjaalton> from gstreamer-properties
<bryce> is that with EXA or XAA?
<tjaalton> XAA
<bryce> right, are you able to confirm that it does work with EXA?
<tjaalton> in a minute
<tjaalton> yep, works
<bryce> ok thanks
<bryce> I finally got libdrm and -psb built for Hardy...  now to try getting them built on Gutsy... hrm
<tjaalton> heh
<bryce> for some reason in -psb it's refusing to build some of its files
<bryce> ah my bad; unclean build tree.
#ubuntu-x 2008-01-11
<tedg> So, the synaptics driver has this feature where it's supposed to read changes do the xorg.conf file.
<tedg> How does that work?  Can all the drivers work that way?  Do they?
<tedg> Does xorg.conf get parsed for every driver?
<bryce> tjaalton: apparently bdmurray was planning on scheduling a bug hug day for xorg next week, but between our efforts, our untriaged bug count dropped too low.  heh.
<bryce> tedg: that might be a Q for mjg
<bryce> that may be the hack he did during Gutsy to get the touchpad configuration stuff working nicely
<tedg> I was more curious from the perspective of, can I put it on the TODO list to have the wacom driver do it ;)
<tedg> I'd really like plug'n'play tablet support.
<bryce> tedg: I believe that's in the pipeline, if it's not available already in hardy
<tedg> It didn't work for me in Hardy if it's supposed to.
<tedg> The only thing I had to do is comment some xorg.conf options though.
<tedg> Now it works really well.  I unplugged my mouse.
<bryce> ohh, I think I recall seeing a bug about interference between mouse and synaptics
<ubotu> New bug: #181914 in xorg (main) "default X configuration assumes wacom hardware" [Undecided,New] https://launchpad.net/bugs/181914
<pwnguin> ^ doesn't hardy drop xorg.conf by default?
<ubotu> New bug: #181935 in linux-restricted-modules-2.6.24 (restricted) "package xorg-driver-fglrx 8.443.1-1 failed to install/upgrade: intentando sobreescribir `/usr/bin/amdcccle', que estÃ¡ tambiÃ©n en el paquete fglrx-amdcccle" [Undecided,New] https://launchpad.net/bugs/181935
<ubotu> New bug: #181943 in xorg (main) "[Gutsy] X11 random crash," [Undecided,New] https://launchpad.net/bugs/181943
<tjaalton> bryce: hehe
<tjaalton> pwnguin: no
<tjaalton> oh I love those "random crash" bugs
<pwnguin> well my crash is clearly repeatable
<bryce> "Hey, I'm having a random crash, can you fix? kthxbye"
<pwnguin> well, at least you're paying attention
<pwnguin> i havent been able to get any results from filing a bug upstream
<tjaalton> pwnguin: ah the xkbLeds bug?
<tjaalton> *LED
<pwnguin> yea
<pwnguin> im not sure how to fix the code, as where it appears is dead simple, but i have no idea where all the code that produced the null pointer is called from
<tjaalton> pwnguin: you might have better luck with #xorg-devel :)
<tjaalton> mvo: there was this strange upgrade failure where xserver-xorg-core.list got strangely corrupted (with data which looks like from Packages file).. is it something that warrants further investigation?
<tjaalton> bug 181530
<ubotu> Launchpad bug 181530 in xkbset "package xkbset None [modified: /var/lib/dpkg/info/xkbset.list] failed to install/upgrade: il file con la lista dei file del pacchetto `xserver-xorg-core' contiene un filename vuoto" [Undecided,Incomplete] https://launchpad.net/bugs/181530
<ubotu> New bug: #182003 in linux-restricted-modules-2.6.24 (restricted) "nvidia driver unable to load on clean 7.10 install" [Undecided,New] https://launchpad.net/bugs/182003
<tjaalton> reinstalling xserver-xorg-core helped there
<mvo> tjaalton: if its a isolated thing, then its likely that its some HW issue on the machine, most corruptions on the dpkg level seems to be caused by bad ram 
<mvo> tjaalton: (this is the dpkg level)
<tjaalton> ok, I'll close it then, and ask the reporter to run memtest
<mvo> thanks
<tjaalton> thanks
<tjaalton> :)
<mvo> tjaalton: just to confirm, we will not get a new xserver for hardy that support redirected direct rendering? that means under compiz we have all the nice glx artifacts ?
<tjaalton> right
<tjaalton> it would touch too many pkaces
<mvo> meh, ok. thanks. that means the compiz team needs to think about some stragegy to deal with it
<tjaalton> places
<tjaalton> I think this was discussed at UDS
<Ng> I just upgraded my gutsy laptop to hardy and I've noticed X is using EXA by default now (intel driver, 855gm chipset), but some things feel a lot slower
<Ng> scrolling specifically
<tjaalton> yep'
<tjaalton> see bug 177492 :)
<ubotu> Launchpad bug 177492 in xserver-xorg-video-intel "EXA is balls-achingly slow" [High,Confirmed] https://launchpad.net/bugs/177492
<Ng> haha, nice subject
<tjaalton> so, put 'Option "AccelMethod" "XAA"' to the driver section for now
<Ng> now I have to write a driver section! ;)
<Ng> but ta. shame that the fix won't be able to be in hardy, but nevermind
<Ng> I noticed a comment on that bug about losing video with XAA - do they mean Xv?
<Ng> that used to work ok in gutsy with XAA
<jcristau> with compiz?
<Ng> well ;)
<tjaalton> it's the other way around, and only with 965 I think
<Ng> actually it did kind of work with compiz, but it was entirely black&white for some reason
<Ng> I never really dug into that one
<jcristau> (i guess compiz on i855 would probably be balls-achingly slow anyway)
<tjaalton> oh, I don't know what keybuk refers to
<tjaalton> ah
<Ng> jcristau: not so much
<Ng> jcristau: sure the thing isn't going to be playing quake3 any time soon, but a sane selection of compiz plugins is actually pretty speedy, mostly because it's only doing 1024x768 I suspect
<jcristau> ok, cool
<Ng> yeah much faster back in XAA, but Xv is entirely broken now
<tjaalton> ok, so it's not just 965 :/
<Ng> gstreamer-properties died from a BadAlloc error when I ran the test
<tjaalton> nice..
<Ng> much as I like xv, I have a tiny screen that I almost never use for video anyway, and I scroll an awful lot
<Ng> so scrolling wins ;)
<tjaalton> does video work without Xv
<tjaalton> ?
<Ng> yep
<tjaalton> cool
<Ng> I'll try and remember to flip back to EXA quickly to make sure that video works there too
<tjaalton> right, at least cirrus doesn't start in the new world order
<tjaalton> "Mode pool is empty"
<ubotu> New bug: #182062 in xmodmap "IBM Thinkpad T61 key slash/question doenst works in Gutsy" [Undecided,New] https://launchpad.net/bugs/182062
<tjaalton> it needs modelines, which seems a bit odd
<tjaalton> modelines, defaultdepth and Modes, duh
<pwnguin> well crap, xorg-devel is like half ubuntu devs
<bryce> heh
<bryce> you say that like it's a bad thing...?  ;-)
<pwnguin> also bryce, i read your blog
<pwnguin> on the subject of library versions and fixes, why not use branches?
<pwnguin> you've already migrated to bzr
<pwnguin> for inkscape
<bryce> no we still use svn
<bryce> we only migrated the bug tracker
<pwnguin> oh
<bryce> we have used branches in the past, but find they grow stale and don't get adequate testing.
<pwnguin> well, it still has "very cheap branching"
<pwnguin> ;)
<pwnguin> well, that'd sorta be the point
<bryce> to not get adequate testing?
<pwnguin> dev branch updates the libraries
<pwnguin> the other branches would attempt to pull in fixes without touching version dependencies
<pwnguin> the other branches would naturally die off as people prefer to simply update lib dependencies
<pwnguin> it'd be easier to do with bazaar, if it lets you track distro patches
<bryce> could be
<bryce> I suspect it's more likely we'd move to git than bzr, but currently it sounds like most developers favor staying with the status quo,
<bryce> we've set up svn->bzr and svn->git interfaces, so those passionate about git and bzr are fairly happy, and those who wish to stick with svn are happy
<bryce> I would expect changing at this point would result in some becoming unhappy, and few becoming more happy than they already are
<monkee_of_evil> Allo
<monkee_of_evil> Has anyone had any luck here getting a triple monitor setup working with Ubuntu?
<bryce> I'd like to see us move to bzr, but don't really have a strong preference; I've not gathered sufficient convincing arguments to make me want to push for it yet
<bryce> monkee_of_evil: I have had some limited successes
<monkee_of_evil> I've got these 2 widescreen acer monitors and a single Sceptre monitor ( none-widescreen )
<pwnguin> i suppose it just makes more sense in the general perspective; if you have bzr/git and binary distros using your stuff -- you can keep lib version ifdefs out of the tree
<bryce> monkee_of_evil: If you're using Feisty or earlier Ubuntu, you can use Xinerama to do it
<monkee_of_evil> I'm on Gutsy
<bryce> monkee_of_evil: however from Gutsy forward, most drivers have switched to xrandr, which does not handle multiple graphics cards so well
<monkee_of_evil> damn
<bryce> it won't be 'til Hardy+1 that the issue is straightened out
<pwnguin> i havent really used either bzr or git
<tjaalton> well, ati and intel
<tjaalton> and experimental mga
<pwnguin> matrox?
<tjaalton> rigt
<tjaalton> +h
<bryce> tjaalton: and nv since g80
<tjaalton> yep
<monkee_of_evil> Yeah... I've got an older ATI dualy & an onboard intel chipset
<tjaalton> but nvidia binary can do silly stuff
<bryce> monkee_of_evil: I have gotten triple screen working with non-merged displays
<bryce> so like you have :0.0 and :0.1
<bryce> that was on -ati, and I found it too buggy to actually use (mouse would get stuck, etc.)
<monkee_of_evil> hmm
<bryce> that was on Gutsy with -ati 195 iirc; it might have gotten better since
<tjaalton> ati upstream supports zaphod mode again
<monkee_of_evil> It will automatically do it's thing and clone my desktop to the two widescreens in Gutsy
<tjaalton> so it should work on current hardy
<monkee_of_evil> What sucks for me is that I've got that RV700 or some crap for my ATI card, so the official binaries don't work
<bryce> http://bryceharrington.org/Photos/X/
<monkee_of_evil> I tried configuring X to get it going and the only thing i can make it do is show a black screen for 2/3 of the screen on my center monitor ( the one plugged into the intel card ) then for the rest of the screen you see these multi-color stripes
<monkee_of_evil> and you can see this blurr where the mouse moves
<monkee_of_evil> then on the wide screens both of them are blank except for the top left where it shows the part numbers of the monitor
<monkee_of_evil> It's the weirdest thing
<monkee_of_evil> can't wait for better monitor support
<monkee_of_evil> Bryce: nice screenshots
<monkee_of_evil> err
<monkee_of_evil> pictures actually
<monkee_of_evil> but w/e
<bryce> w/e ?
<pwnguin> w/e is often "whatever"
 * bryce shrugs
<monkee_of_evil> pwnguin got it
<pwnguin> more importantly, that's gnome+konsole
<pwnguin> and.. xmms?
<bryce> pwnguin: if you're trying to give me a hard time, won't work ;-)
<monkee_of_evil> I like xmms
<pwnguin> i think if you try harder, you could put in an enlightenment app too ;)
<monkee_of_evil> Fluxbox ftw
<monkee_of_evil> :)
<pwnguin> xmms is like the worst of all worlds. terrible UI that mimics winamp. horrible playlist UI, weak playlist tools...
<tjaalton> and yet something that actually worked all these years :)
<pwnguin> thats about all it has =(
<tjaalton> heh
<bryce> if you must know, I used to use KDE, and wrote scripts to automate konsole placement using dcop.  I've since rewritten the code for gnome-term, but those photos were taken before that.
<pwnguin> interesting. is the placemnt script a matter of which screen?
<bryce> I've tried both KDE and GNOME music apps and generally find them inadequate
<monkee_of_evil> yeah.. I fucking hate Rythmbox
<monkee_of_evil> Listen isn't much better
<bryce> I put in a bunch of bugs on rhythmbox before giving up on it
<monkee_of_evil> Too bad foobar doesn't run natively
<monkee_of_evil> although it runs decently under wine
<tjaalton> I used KDE in -98 when I installed linux (SuSE 5.3) for the first time
<bryce> pwnguin: no, my set up has a virtual screen so I just specify the x,y coordinates that'd put them on the right screen
<bryce> it's pretty trial-and-error, and different for KDE and GNOME
<pwnguin> anyways, i didnt mean to start an involved flamewar, just poking some fun ;)
<bryce> :-P
<tjaalton> I use rb happily at work, but it's far from perfect
<bryce> I'm just irritable due to all the UME stuff at the moment, don't mind me
<tjaalton> hehe
<pwnguin> tjaalton: i wish it would let me choose a different playlist to default to on startup
<pwnguin> i filed a wishlist bug in LP and someone appears to have run with it, we'll see where that goes
<tjaalton> ah, I just plug in my iPod and let it play random
<pwnguin> i dont own one of those
<pwnguin> but its nice to be able to filter by rating etc
<tjaalton> I got it just because it's the only brand that has any sort of gadgets for cars
<tjaalton> http://www.last.fm/user/tepsipakki
<pwnguin> i actually used rhythmbox to come up with a playlist for my crappy car stereo to put on CD
<pwnguin> 700 megs of mp3s at bitrate 300 or less sorted by rating
<tjaalton> now I use banshee to sync the iPod, and the next version should finally fix the UI so I can choose by genre
<bryce> dah, LP is going offline
<jcristau> tjaalton: will you report the bug about i810preinit not setting depth to 16 to bugzilla, or shall i?
<tjaalton> jcristau: you can do it, it was your idea anyway :)
<tjaalton> jbarnes knows about it already though
<jcristau> yeah i've read that
<tjaalton> right, he'd prefer to have the patch on b.fd.o
<jcristau> a bz report is safer than a mention on irc :)
<tjaalton> of course, and you can't track bugs outside bz
<tjaalton> er, patches
<tjaalton> or both actually
<tjaalton> ffs, launchpad maintenance break
<jcristau> tjaalton: what's your bz email again?
<tjaalton> tjaalton+freedeskto at cc.hut.fi
<tjaalton> freedesktoP
<jcristau> thx
<jcristau> there. #14032
<tjaalton> thanks
<jcristau> np
<tjaalton> so you tried it as well?
<jcristau> didn't have time to test the patch yet, no
<tjaalton> well, it works
<jcristau> but i don't see why it wouldn't work when X -depth 16 does
<jcristau> pretty busy at work this week, plus my debian time was taken by other stuff...
<tjaalton> don't worry, a couple of guys already proved it working :)
<jcristau> cool
<tjaalton> woohoo, at least one bug fixed by switching to openchrome, bug 180841
<ubotu> Launchpad bug 180841 in mesa "glXDestroyContext causes segmentation fault with Via Unichrome graphics" [Undecided,Incomplete] https://launchpad.net/bugs/180841
<bryce> nice
<tjaalton> although it was quite unclear which version he was using before, and I think via/openchrome both share the same mesa driver
<ubotu> New bug: #182100 in linux-restricted-modules-2.6.24 (restricted) "ATI Catalyst 7.12 conflict with Screen Resolution" [Undecided,Incomplete] https://launchpad.net/bugs/182100
<tjaalton> sigh
#ubuntu-x 2008-01-12
<ubotu> New bug: #139505 in ubuntu "dell E1705 will not boot into X from liveCD. (dup-of: 174434)" [Undecided,New] https://launchpad.net/bugs/139505
<bdmurray> bryce: I got a weird pending post to the bugsquad mailing list regarding /usr/share/doc/x11-common/copyright
<bryce> what about it?
<bdmurray>  The                                                    
<bdmurray> first part covers changes and additions made in Ubuntu package, the second                                                 
<bdmurray> one is for Debian. But the warranty disclaimers in both parts are identical
<bdmurray> There is more but that's the relevant bit
<bdmurray> bryce: does that mean anything to you?
<bryce> well I'd need to see the specific complaint
<bryce> the copyright file is just a summary of licensing for the package
<bdmurray> okay, I'll just let the post through to the mailing list if that works for you
<bryce> fine.  I don't know if I'm on bugsquad though
<bryce> probably they should be posting it to the ubuntu-x list.
<bdmurray> Do you know why ubuntu-x isn't under the development lists?
<bryce> nope
<bdmurray> Is it more development related?
<bryce> yes
<bdmurray> You could submit an RT to get it reorganized at lists.ubuntu.com
<bryce> I don't care
<ubotu> New bug: #182181 in xserver-xorg-input-mouse (main) "bluetooth mouse does not work" [Undecided,New] https://launchpad.net/bugs/182181
<pcjc2> hi
<pcjc2> Bryce, people.. does anyone happen to know if the Intel driver crash with something about "repaint cursors" in the backtrace still occurs in Hardy?
<bryce> heya pcjc2
<pcjc2> I'm not on Hardy yet (and dreading it if EXA can't be sorted really)
<pcjc2> But I can mostly reproduce that repaint cursors crash pretty easily
<bryce> I had been looking at that bug report earlier today; it's not closed
<bryce> I've not tried reproducing it on hardy yet though
<pcjc2> No one was able to reliably reproduce it though
<bryce> ah
<pcjc2> I can get it to fire pretty much about 20% of the time I launch a windows GTK app under wine
<pcjc2> not your ideal test case unfortunately, but a start
<bryce> pcjc2: which bug# is it?
<pcjc2> it sucks muchly.. given I'm trying to use Wine to debug a windows port of some software ;)
<pcjc2> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/153466
<ubotu> Launchpad bug 153466 in xserver-xorg-video-intel "[gutsy] X crashes randomly - something with cursors? (945GM)" [High,Confirmed] 
<pcjc2> launchpad edge is broken though.. had to disable redirect to get it
<bryce> ah yeah right
<bryce> I was looking at forwarding it upstream, but the bug report doesn't look ripe enough yet
<bryce> steps to reproduce, or a more detailed definition would help
<pcjc2> Some way to log what wine does to X to kill it might be handy
<bryce> the last post put some links in that would be worth investigating (I looked at the first two links, but didn't understand how they were related)
<pcjc2> I get http://launchpadlibrarian.net/11305508/100_1241.JPG too
<pcjc2> and some full screen apps (eog ?) get very upset running in full screen mode with compiz
<pcjc2> but I'm not on Hardy, so I guess this isn't too interesting
<bryce> I'm about to post that one upstream; just need to check if it's already reported on fdo
<pcjc2> Can I show my ignorance... how do I clone this cvs repo?
<pcjc2> http://keithp.com/cvs/xscope/
<pcjc2> Can't seem to find any official upstream
<pcjc2> no debian package etc..
<pcjc2> never mind.. found out.. xmon is the way forward
<pcjc2> Bryce.. seems all you have to do is hook up an X11 protocol debugger, and the crash reproducibility will go away ;)
<pwnguin> hah
<pwnguin> what about gdb?
<pcjc2> haven't got my other box on at the moment to try it
<pcjc2> But I guess that is another way to attack the problem
<bryce> oh yeah I love bugs that go away once instrumentation's attached ^_^
<pcjc2> there are backtraces for this crash already...
 * pcjc2 wonders if an entire X server can be run under valgrind...
<pcjc2> anyway... I should get some sleep.. will debug this more if it bites again
<bryce> night
<pwnguin> i think you can valgrind x
<pwnguin> the debugging x wiki suggested it under advanced
<pwnguin> not sure what you'd do
<tjaalton> pcjc2: hey, we are still carrying a couple of patches (01_fix_compiz_video.diff, 05_fix_xv_reset.diff) on intel. Are they going to be upstream or not?
<tjaalton> https://edge.launchpad.net/obsolete-junk/
<tjaalton> haha
<tjaalton> I wan't to contribute!
<tjaalton> uh, -'
<tjaalton> xorg bug count getting close to 200
<bryce> heya tjaalton
<tjaalton> hi bryce
<tjaalton> still up :)
<bryce> yeah, it's barely after midnight!
<tjaalton> oh right.. I stayed until 3AM
<tjaalton> +up
<tjaalton> last night that is
<bryce> today I worked a good bit on getting the moblin box reinstalled to test the new -psb, but no luck.  Maybe monday
<bryce> after that I made good progress getting several -intel bugs upstream
<tjaalton> the "3D artifacts" is actually known upstream..
<bryce> I suspected it must be
<bryce> couldn't locate a bug report for it though
<tjaalton> it'll get fixed once cworth get's his stuff finished
<bryce> yeah, hmm
<tjaalton> and that needs all the flashy stuff that upstream is working on atm
<bryce> sounds like it'll end up hardy+1-ish
<tjaalton> yep
<tjaalton> hopefully!
<tjaalton> and not +2
<tjaalton> I'm cleaning up the xorg bugs again, goal to get the count closer to 150
<bryce> ok, well next task is getting my bug plot tool working with FF3.0.  *sigh*
<tjaalton> hehe
<bryce> huh, that was easy
<tjaalton> bdmurray: the launchpad-janitor is not cleaning up bugs automatically, is it only done periodically and not automatically?
<bryce> bdmurray's probably asleep
<tjaalton> heh, ok
<bryce> here's the ff3 bug - http://bryceharrington.org/drupal/node/28
<tjaalton> yeah, I noticed the post
<ubotu> New bug: #182237 in linux-restricted-modules-2.6.24 (restricted) "restricted manager does not recognize nvidia 8600M GT on hardy" [Undecided,New] https://launchpad.net/bugs/182237
<tjaalton> whoops that's a valid bug, for a change
<ubotu> New bug: #182242 in linux-restricted-modules-2.6.24 (restricted) "fglrx driver missing" [Undecided,New] https://launchpad.net/bugs/182242
<ubotu> New bug: #182245 in xserver-xorg-video-openchrome (main) "moving cursor over 3D image causes distortion" [Undecided,New] https://launchpad.net/bugs/182245
<ubotu> New bug: #182246 in xserver-xorg-video-openchrome (main) "Strange message about drmWaitVBlank openchrome driver" [Undecided,New] https://launchpad.net/bugs/182246
<tjaalton> xorg bugs down to 184, need a break ->
<tjaalton> whee, less than 1700 bugs in the team packages
<ubotu> New bug: #17904 in xserver-xorg-video-s3 (main) "cannot configure X for graphics card with 1MB ram" [Low,Confirmed] https://launchpad.net/bugs/17904
<ubotu> New bug: #182301 in xorg (main) "xnest manual page fails to document authentication" [Undecided,New] https://launchpad.net/bugs/182301
<jcristau> 182301 should be closed as invalid imo
<tjaalton> just did :)
<tjaalton> jcristau: thanks for checking the manpage
<jcristau> np
<tjaalton> heh, at least two old bugs against ati where the reporter was so upset that he bought a nvidia card :P
<pcjc2> I'd consider that when buying a new laptop... not impressed with the Intel drivers at the moment!
<bdmurray> tjaalton: It is not enabled for the Ubuntu project
<tjaalton> bdmurray: ah ok
<tjaalton> pcjc2: did you see my question about the patches?
<pcjc2> where was that?
<pcjc2> ok, I see 01_fix_compiz_video.diff, 05_fix_xv_reset.diff
<pcjc2> It wasn't clear... if it was a fix for XXA, they weren't particularly interested
<pcjc2> 01_fix_compiz_video.diff forces the texture extension disabled, doesn't it... wasn't one of mine.
<pcjc2> Its basically a wontfix since they want eveyone on EXA
<pcjc2> it might be worth testing without 05 on Hardy, to see if it has been fixed  more appropriately
<tjaalton> ok
<Q-FUNK> re
<tjaalton> what was the bug #'s for those?
<tjaalton> were
<Q-FUNK> bryce: would it be possible to merge Bartman's patch to X server and to release to gutsy proposed updates, to allow broader testing?
<tjaalton> Q-FUNK: put it in a ppa?
<Q-FUNK> tjaalton: that could work too, but won't result in as wide of a testing as needed
<tjaalton> well, who uses -proposed?
<bdmurray> tjaalton: however there are reports show what would expire and I have some workflows for finding them if you are interested
<tjaalton> bdmurray: that would be cool
<tjaalton> I find it very confusing, that only sorting the bugs by some other metric than importance shows _less_ bugs
<tjaalton> for instance bugs on xorg goes down from 166 to 123
<bdmurray> tjaalton: I use bugnumbers from bughelper a lot for querying for bugs.  I'm headed out at the moment but will e-mail you.
<tjaalton> bdmurray: excellent, thanks
<pcjc2> 05 was #141063
<pcjc2> I don't see a bug # for 01_...
<pcjc2> it seems this info has been lost in the Debian changelog for the intel 2.2.0 driver
<tjaalton> ah, true
<tjaalton> but it's not on the changelog of 2:2.1.1-0ubuntu9 either, where it was introduced :)
<pcjc2> 05_... had a closes line
<pcjc2> 01_... didn't
<tjaalton> yep, but if it's carried on the merge diff, those bugs would get another post when the new version is uploaded
<tjaalton> although the closes line could be changed to prevent that
<tjaalton> s/merge diff/changelog of the new merge/
<pcjc2> ok
<pcjc2> I think there was a better fix for 05_... which Keith P pointed out
<tjaalton> looking at the upstream bug it was committed too
<pcjc2> I'm trying to find it... but my various mailboxes are somewhat full. Its likely on a fd.o bug
<tjaalton> https://bugs.freedesktop.org/show_bug.cgi?id=12437
<ubotu> Freedesktop bug 12437 in Driver/intel "Server  and computer lockup  when trying to play Xv" [Normal,Resolved: fixed] 
<tjaalton> at least that's linked from that bug
<pcjc2> https://bugs.freedesktop.org/show_bug.cgi?id=12356
<pcjc2> https://bugs.freedesktop.org/attachment.cgi?id=12307
<ubotu> Freedesktop bug 12356 in Driver/intel "[845] hang after VT switch (was xvideo crashes)" [Normal,Resolved: duplicate] 
<pcjc2> Seems that the bug this was a dup of has a better fix, which should be included already
<pcjc2> http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-intel.git;a=commit;h=a2a0821e74a61f53cc7f0c41ce629644ad712114
<pcjc2> made it in before 2.2.0
<pcjc2> Also..  some of the 855 crash on lid close bugs were addressed here
<pcjc2> (Quirk added for Inspiron 510m)
<pcjc2> http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-intel.git;a=commit;h=3c22ed633be2ac96eea7bc533839e956f1f31b84
<pcjc2> this is also relevant
<pcjc2> http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-intel.git;a=commit;h=f69b48fe24ef94dac44b8123884ca71df675be4b
<ubotu> New bug: #144092 in linux-restricted-modules-2.6.22 "googleearth does not start on gutsy amd64." [Undecided,Invalid] https://launchpad.net/bugs/144092
<bryce> tjaalton: wow nice!  xorg New bugs down to 45!!
<bryce> open bugs down by half!  niice
<bryce> Q-FUNK: I'd like to look at the patch, but if you'd like to upload it to -proposed, that's probably fine
<tjaalton> bryce: yeah, it's going pretty well :)
<bryce> you were right about that 3D artifacts bug - it got duped up over night
<bryce> it suddenly clicked - this is one that the compiz folks were talking to me about at the last conference I think
<bryce> you know, in a way I kind of grimace at the fix...  I suspect that yeah, maybe the indirect direct rendering will fix it for -intel, but is this going to be yet another thing that ends up breaking half the other drivers?  :-/
<tjaalton> I'm not sure yet..
<bryce> maybe I'm just still bitter over needing ttm for fixing the 965 EXA performance stuff ;-)
<tjaalton> my problem is that I should probably draw a mind map about all of this, since there's just too much scattered information for my little brain to handle :)
<bryce> yeah
<bryce> inkscape ftw :-)
<tjaalton> I wonder if kernel modesetting is also required, so then we'd need to touch kernel too (and that was turned down at UDS)
<bryce> at my last job, my CTO used inkscape for doing his mind maps, which was really awkward, because he'd always come over for bug fixes and tech help, and I'd be thinking, "Er, this is a hobby project... but if you assigned me to work on it I'd love to look at those..."
<tjaalton> hehe
<tjaalton> I haven't used inkscape for that yet, but "dia" a little
<bryce> dia is still good for doing UML diagrams, but at this stage I think inkscape generally is better for most other kinds of technical drawings
<tjaalton> yep
<tjaalton> hm, I can only save one stock reply with the greasemonkey script
<tjaalton> the others aren't saved
<bryce> tjaalton: yeah I have problems with it not saving mine either
<bryce> tjaalton: in testing it out a bit, I think it saves them permanently only if you exit firefox; if it crashes or gets killed, it definitely doesn't save them
<tjaalton> bryce: could be that I haven't restarted firefox in the meantime
<bryce> to be honest, I don't use the canned responses script too much since it seems to always forget my settings unexpectedly :-/
<bryce> I tried debugging it, but the issue seems to be something inside firefox and/or greasemonkey
<tjaalton> ok..
<pwnguin> dont take this the wrong way, but i thought inkscape would be usable with a wacom tablet
<pwnguin> but i dont think vector art and tablets really work together
<bryce> hmm, I've heard inkscapers using it with wacom.  But I know there's some quirks and bugs
<bryce> I've not tried it myself though
<pwnguin> well, from the name, you'd think it's perfect
<pwnguin> but don't worry, just about everything doesn't work optimally with tablets
<bryce> as we say, "send in a patch" ;-)
<pwnguin> mostly, it's just that it isnt artRage
<bryce> artRage?
<bryce> dang you've been doing a lot Timo...  I'm just now going through my LP emails and it's like 50% of them are from you!  ;-)
<tjaalton> you know the key, it's just beside enter ;)
<tjaalton> I need another beer, that wasn't even funny..
<bryce> hehe
<tjaalton> hmm, I'll try Glenlivet instead
<tjaalton> the xorg bugs are getting harder all the time
<tjaalton> it's just too tempting to say "whatever.. <invalid>"
<tjaalton> or maybe just leave them be for now
<bryce> hehe
<bryce> I'm starting to assign milestone "Later" for ones I know we can't do anything about and don't expect to see fixed for a while
<tjaalton> that's good
<bryce> I went through all the milestones yesterday to see if there's any we're on the hook for
<bryce> there was only one that I recall, but it was just a sync or merge request
<bryce> maybe it's already been closed
<tjaalton> maybe the -amd sync, which is done now
<bryce> yeah I'm pretty sure it was -amd.
<bryce> I saw that Travis also seems convinced we will need to go back to XAA for Hardy
<bryce> guess I need to just accept it...  when do you think we'll flip that back?
<bryce> I've let Dell and Intel know about the issue, but haven't heard a response from them yet.  Maybe monday.
<tjaalton> next week is early enough
<tjaalton> I mean there is no rush or anything
<bryce> right
<tjaalton> before next alpha of course
<bryce> will we need to reactivate that XAA patch that was making it impossible for people to turn EXA on?
<bryce> maybe if we can avoid that patch, we can at least say that people can choose to opt-in to EXA, and at least that will be a step forward from gutsy
<tjaalton> actually, there was one bug that left me wondering.. the server is using i810 by default, and our i810 is the old driver and not a symlink.. so maybe all those who've installed alpha3 are using i810 instead of intel :)
<tjaalton> hmm, I don't recall that patch.. was if for the driver or server?
<tjaalton> oh you mean the fedora patch for the server?
<tjaalton> it's been there since early november
<tjaalton> the latest (and possibly final) version of it
<bryce> right, that fedora patch for the xserver
<tjaalton> yeah people noticed that EXA sucks, so turned XAA on, which had it's own issues without the patch
<bryce> yeah I've wondered about the i810 thing too...  I'm also wondering if it would be reasonable for us to find a way to push people over to -intel that are using -i810, without actually going so far as to turn -i810 into a symlink
<tjaalton> well, patching the server to use intel by default would be enough
<tjaalton> then all new installations would use intel, but people could change back to i810
<tjaalton> well, gutsy used intel by default
<tjaalton> maybe there's still time for upstream to fix the issues with the older chips
<bryce> right, I think we've done that.  I'm thinking more about for people upgrading, who have -i810 listed in their xorg.conf
<tjaalton> yep, keeping -i810 would let them keep using it
<tjaalton> hmm, I don't have mouse on failsafe
<bryce> erf
<tjaalton> noticed it yesterday on kvm
<tjaalton> and now on real hw
<bryce> I need to spend some time working on bulletproof X
<bryce> I know we have a pile of bugs reported on it, and I've just been procrastinating 
<tjaalton> there are some valid bugs about it
<bryce> most should be simple
<tjaalton> most hardy ones should be fixed already (debconf keys being dropped etc)
<tjaalton> hmm, my 965GM used intel by default, nice
<tjaalton> bryce: also, it seems that failsafe defaults to vesa on all archs.. sparc needs sunffb and ppc uses fbdev
<bryce> oh interesting
<bryce> do we have bugs in about that?
<tjaalton> there was a bug about mac mini
<bryce> I'll add to my todo list
<tjaalton> it's on x-x-v-ati now, since the real bug is why it dropped to failsafe :)
<bryce> I think after the developer sprint, in Feb I'll try to set aside 3-5 days to focus on bpx
<ubotu> New bug: #182416 in linux-restricted-modules-2.6.24 "bugs in fglrx - blank screen - artifacts" [Undecided,New] https://launchpad.net/bugs/182416
<ubotu> New bug: #180409 in linux-restricted-modules-2.6.24 "bugs in fglrx - blank screen - artifacts" [Undecided,New] https://launchpad.net/bugs/180409
#ubuntu-x 2008-01-13
<ubotu> New bug: #182430 in xorg (main) "hard crash when switching from xorg to VT and back (gutsy)" [Undecided,New] https://launchpad.net/bugs/182430
<Q-FUNK> bryce: I forwarded you the two patches
<bryce> got 'em; I'll take a look next week
<bryce> with these two patches in place, will this take care of the issues folks have been having with -amd?
<Q-FUNK> bryce: and other drivers with similar bugs.
<Q-FUNK> bryce: the main issue is that x86emu was doing nasty things with the BIOS. these two patches plug the issue in two ways:  1. prevent x86emu from even trying to ever access specific ports. 2. fix the way the BIOS was accessed in the first place (it was truncating some values).
<bryce> what's the risk of regressions for other users?
<Q-FUNK> none, as far as I can tell.  it simply prevents X core from doing stupid things.
<Q-FUNK> but again, a test package must be built and tested.
<Q-FUNK> if this works, it will be needed on all subsequent X core versions until upstream has merged it.
<Q-FUNK> bartman on #xorg-devel could tell you more about how he came to those two.
<Q-FUNK> it's largely the result of a thread between him and alan cox.
<Q-FUNK> it basically, prevents x86emu from doing first things in the first place and lets the exception handler kill X if it still tries to, rather than freeze the whole system.
<Q-FUNK> Ã¶Ã¶.. from doing stupid things
<Q-FUNK> bryce: anyhow, bartman pretty much has the last say over which parts of his patch set will make sense in context.
<Q-FUNK> what I remember from the thread (I am just reading the backlog, as I'm coming home), is that he's at least fixed X enough to turn freezes into simple segfaults that can be caught by the exception handler.
<Q-FUNK> for the specific -amd issue, he reports in another post that he finally gets something on his display, after fixing x86emu.
<ubotu> New bug: #35794 in xserver-xorg-video-trident "TV out is broken with VT1621 chip" [Medium,Confirmed] https://launchpad.net/bugs/35794
<ubotu> New bug: #47614 in xserver-xorg-video-ati (main) "xserver-xorg does not automatically set supported options for ati (slow desktop/gui)" [Medium,Won't fix] https://launchpad.net/bugs/47614
<ubotu> New bug: #182547 in linux-restricted-modules-2.6.22 "Failure to load nvidia kernel module into 2.6.22-14-generic" [Undecided,New] https://launchpad.net/bugs/182547
<ubotu> New bug: #182309 in linux-restricted-modules-2.6.24 (restricted) "[fglrx] no Visual Effects on a Radeon Xpress 1150 (Dell inspiron 1501)" [Undecided,New] https://launchpad.net/bugs/182309
<ubotu> New bug: #182594 in xserver-xorg-driver-ati (main) "[radeon] no Visual Effects on a Radeon Xpress 1150 (Dell inspiron 1501, hardy alpha 3)" [Undecided,New] https://launchpad.net/bugs/182594
<ubotu> New bug: #26090 in linux-restricted-modules-2.6.15 (restricted) "updated fglrx driver breaks dual-head setup" [Medium,Invalid] https://launchpad.net/bugs/26090
<bryce> heya Q-FUNK
<Q-FUNK> hey! :)
<ubotu> New bug: #182691 in xorg (main) "X doesn't write settings in xorg.conf when booting Xubuntu live CD" [Undecided,New] https://launchpad.net/bugs/182691
<Q-FUNK> bryce: anything new?
<ubotu> New bug: #182252 in x11-xserver-utils (main) "xhost +localhost does not work" [Undecided,New] https://launchpad.net/bugs/182252
<bryce> Q-FUNK: the usual, you?
<Q-FUNK> bryce: wondering if Bart's patches will be merged in.
<bryce> yeah I'll take a look monday
<Q-FUNK> I just asked the Debian X list.
<Q-FUNK> if they accept his two x86emu patches and merge to both the 1.3 in Testing and the 1.4 in Unstable, it might make your job easier.
<bryce> yup, that'd be nice
<Q-FUNK> I'm a bit more worried about the lack of reaction on the upstream X list, though.
<bryce> I don't foresee any issue accepting it, just need to package it and make sure it builds, and so on
<Q-FUNK> is there a big amount of Ubuntu delta left with the Debian packages?
<tjaalton> 13 patches
<tjaalton> oh, 15
<Q-FUNK> wow
<Q-FUNK> that's a lot
<Q-FUNK> any of it that could be integrated by Debian?
<tjaalton> we can drop the DPI patch after next revision
<tjaalton> perhaps
<Q-FUNK> jcristau: ? :)
<tjaalton> gravity promised to take a look at them when he has time for it :)
<Q-FUNK> aye.  I just saw bgoglin's reply too.
<Q-FUNK> looks good
<jcristau> Q-FUNK: i'd rather see it upstream first...
<jcristau> and i don't want to keep maintaining 1.3, but it should be fine for 1.4
<Q-FUNK> well, for as long as 1.4 isn't in a releasable state, we really need that backported to 1.3 too
#ubuntu-x 2009-01-05
<crevette> heya
<bryce> heya
<tjaalton> howdy
<crevette> good morning and happy new year
<crevette> it seems X became crashy in jaunty after intel was updated
<tjaalton> bryce: should we sync libxcb/libx11 prereleases, they have the lockless stuff merged in
<crevette> I didn't had time to report a bug though
<bryce> tjaalton: if you think it's all reasonably stable
<tjaalton> bryce: maybe I should try it myself then :)
<bryce> the lockless stuff would be nice to have but not if we're going to risk incurring new bugs for jaunty
<bryce> crevette: what version are you on?
<tjaalton> no new bugs in debian, but I doubt that many use it
<bryce> crevette: and also what video card model is it?
<bryce> crevette: anyway, gather a full backtrace from the crash and file a bug both in launchpad and upstream
<bryce> crevette: make sure to include your Xorg.0.log and output from lspci -vvnn
<crevette> I have the latest available updates but I'll gather all necessary information and I'll produce a bug report if it happen again
<crevette> ah same idea :)
<bryce> crevette: what's the video card model?  (lspci | grep VGA)
<crevette> intel X3100
<crevette> I'll provide you that once back to home
<tjaalton> crashy after which update? the intel has been the same version for weeks
<bryce> ah, 965.  I've got a jaunty system on 965 and haven't seen crashes so far
<bryce> but maybe not exactly the same chipset
<bryce> tjaalton: I'm assuming crevette's using 2.5.1-1ubuntu7
<crevette> yep
<crevette> tjaalton, it seems I saw an update yesterday, but it is true I cannot find one in the jaunty-changes
<crevette> okay
<crevette> don't loose your time on me
<crevette> I'll do some investigation tonight
<bryce> tjaalton: being on -ati with no XAA or EXA kind of sucks
<bryce> thinking about trying out alex's r6xx/r7xx acceleration branch...
<tjaalton> bryce: that's a long road.. you need to start by patching the kernel
<tjaalton> :)
<bryce> ouch yikes
<bryce> maybe I ought to just buy a r5xx card...
<bryce> hmm actually I could do all that...
<tjaalton> buy a new card or..? :)
<bryce> patch kernel, etc.
<bryce> however a new card is only like $50
<tjaalton> you also need to use radeonhd, -ati doesn't have support for it
<tjaalton> at least not yet
<bryce> hrm
<bryce> well, I guess I'll get a 5xx card for now and can always play with the 6xx card once -ati has acceleration support
<bryce> yow, nearly up to 250 -intel bug reports
<tjaalton> I've been cleaning up xorg
<bryce> it's been growing for a while
<tjaalton> yep
<bryce> nice seeing xorg back down to 200
<tjaalton> there are still ~150 bugs that should be assigned to another package
<tjaalton> xorg should only have packaging bugs or maybe some MASTER bugs for stuff that can't be fixed anytime soon
<bryce> agreed
<tjaalton> and if the header even hints at nvidia/fglrx then those should be cleaned up immediately :)
<bryce> tjaalton: yeah it'd be sweet to get xorg down to the 50 or so that are actually xorg bugs.  I think we'd be able to get those bugs sorted out easier without all the other stuff to distract
<bryce> plus I bet that'd help in finding dupes to other bugs already filed against the driver packages
#ubuntu-x 2009-01-06
<tjaalton> bryce: exactly my point. it's just too easy to let xorg get filled up
<bryce> tjaalton: yep I agree
<bryce> tjaalton: today I've been really taking advantage of my busted up jaunty desktop
<tjaalton> "advantage" :)
<bryce> I had this weird mouse cursor flickering in firefox, found a patch for it that solved it, and uploaded :-)
<tjaalton> oh taht
<tjaalton> that
<tjaalton> so you didn't use git then, because it has the tip of 1.6 branch ;)
<tjaalton> which fails to build a source package because of change xquartz stuff
<tjaalton> changeD
<bryce> nah, I looked at the real patch but it looked pretty involved, so just put in the much simpler workaround patch for the time being
<tjaalton> don't think 1.6-branch has it yet
<bryce> yeah, doesn't sound like it.  So when it does, we can drop this patch.
<tjaalton> just wondering what to do in git
<bryce> the workaround patch has been working perfectly so far for me
<bryce> also sorted out a bug where right clicking on urls in gnome apps wasn't loading right in firefox
<bryce> that turned out to be a glib bug.  I made a workaround patch but didn't root-cause it
<tjaalton> ok, has worked for me
<bryce> it seems to have something to do with gvfs
<bryce> maybe something isn't quite kosher with my setup
<bryce> anyway, whatever, another annoyance eliminated :-)
<tjaalton> good :)
<tjaalton> afk, to the skating rink ->
 * bryce chuckles
<bryce> sounds fun
<tjaalton> yep, it was
<tjaalton> it's across the street, so easy to go to :)
<tjaalton> bryce: ati dithering stuff regression on intrepid, bug 314326
<ubottu> Launchpad bug 314326 in xserver-xorg-video-ati "new radeon and ati libraries dont work with my X1300 " [Undecided,New] https://launchpad.net/bugs/314326
<superm1> bryce, is AMD aware of any ABI problems that will be happening for jaunty so that they have time to plan appropriately?
<seb128> tseliot: could you look to bug #314406? it's g-s-d crashing in jaunty due to your change
<ubottu> Launchpad bug 314406 in gnome-desktop "xrandr plugin of g-s-d crashes on startup" [Medium,Confirmed] https://launchpad.net/bugs/314406
 * tseliot has a look at the report
<tseliot> seb128: ok, I think I know how to fix it. When do you need the fix?
<seb128> tseliot: no hurry there is not so many jaunty users yet
<tseliot> seb128: ok, I'll add it to my todo list. Thanks for reporting
<tjaalton> superm1: AIUI yes they are
<bryce> tjaalton: I've modified the colorization and accounting on http://bryceharrington.org/X/PkgList/versions_current.html a bit, to better distinguish better when we're in sync with debian, but they're behind upstream (since there's so many packages in that state currently)
<bryce> (gets rid of a lot of red for us :-) )
<andersk> Is it intentional that xft 2.1.13-2 was synced rather than merged into Jaunty?  The sync dropped two patches that I believe are still needed (bug 305399). 
<ubottu> Launchpad bug 305399 in xft "xft 2.1.13-2 sync dropped libXft-2.1.10-lcd-filter-3.patch" [Undecided,New] https://launchpad.net/bugs/305399
<bryce> andersk: thanks, I'll upload
<tjaalton> bryce: so lime means that we are in sync with debian but not upstream, and blue means we are not in sync?
<tjaalton> with either
<bryce> (still tinkering with colors a bit)
<bryce> tjaalton: correct
<bryce> I'm adding another color to distinguish between needing merges vs. syncs to experimental
<bryce> also I corrected needs-merge vs. needs-sync; for some reason I'd not gotten the logic right for ubuntu packages
<bryce> while I'm at it, any other change requests for this page?
<tjaalton> nothing I can think of
<bryce> actually, blue means we're not in sync with experimental
<bryce> dark blue means we need to merge with experimental, light blue means we just need to sync
<bryce> red/orange means we need a merge/sync with unstable
<tjaalton> yeah, didn't notice it was explained at the bottom
#ubuntu-x 2009-01-07
<bryce> whoohoo  [ANNOUNCE] xf86-video-ati 6.10.0
<seb128> hey there
<seb128> we did try to drop the forced 96 dpi settings in gutsy but that didn't work that great, do you think we should try again this cycle?
<tjaalton> what happened then?
<tjaalton> I mean what problems came up?
<seb128> tjaalton: sort of bug flood about users having incorrect values being used
<seb128> their font not looking right, that sort of things
<seb128> ie, too many case where xorg doesn't get it right
<jcristau> (or where monitors lie)
<tjaalton> was just going to say that..
<seb128> bug #118745)
<ubottu> Launchpad bug 118745 in xorg-server "Font sizes in Gutsy are affected by bad X.org DPI detection" [Medium,Fix released] https://launchpad.net/bugs/118745
<seb128> that's the bug we got back then
<seb128> there is one guy on #ubuntu-desktop arguing that nowadays it's better to let xorg does its job rather than force 96dpi because the number of case where 96 dpi is wrong is higher than the number of cases where xorg is wrong
<seb128> do you have any opinion on the topic?
<seb128> I guess we could just try for a while in jaunty and see the users reactions
<tjaalton> where is it forced?
<jcristau> tjaalton: gdm starts X with -dpi 96
<jcristau> iirc
<tjaalton> grep doesn't show any results here, on hardy
<tjaalton> ah, libgnome
<jcristau> oh.
<tjaalton> /desktop/gnome/font_rendering/dpi       96.0
<tjaalton> seb128: I'd be ok with it, but maybe ask bryce too :)
<seb128> tjaalton: right, libgnome, see the bug I listed before, we decided to change gnome-settings-daemon to set it to 96 by default
<seb128> or rather to change the gconf key used by gnome-settings-daemon
<tjaalton> right
<Ng> seb128: I'm quite keen to see the DPI thing looked at, mainly because GDM is entirely unusable on my TV at home - 1920x1080 and the fonts render so small that they can't even be read if you're 10cm from the TV ;)
<seb128> Ng: gdm doesn't use gconf so you get the xorg dpi used there
 * mvo almost wanted to say something about glasses but he does not
<Ng> seb128: ah, damn
<Ng> mvo: I have perfect vision! there literally aren't enough pixels in the fonts to be able to read them
<Ng> it makes the failsafe X thing impossible to use too, which is a shame since I regularly break my X config on that machine ;)
<mvo> haha
<superm1> tseliot, i'm going to need to upload nvidia 180 again because vdpau stuff needs to be pulled out of the regular -dev package and regular glx package for stuff to build depend against it properly.  did you have any other pending changes to get in it?  I also need to rev it to the new version so that mythtv can build against it
<superm1> also is there any particular reason that the modaliases is arch dependent?
<tseliot> superm1: feel free to update it. I would like to have a look at the new source if you don't mind.
<tseliot> superm1: a user suggested this patch as he said that the modaliases are broken in the latest release: http://launchpadlibrarian.net/20917045/nvidia-180-modaliases-fix.patch
<superm1> tseliot, well there are a variety of ppa's that people have made changes with, so i'll probably base it off of one of those.
<superm1> yeah that's the one i was grabbing
<superm1> i need to make sure that the mythtv build actually works before i do any of this, but just checking if you had any other stuff in the pipe on this upload
<tseliot> superm1: as regards modaliases, they have to be arch-specific
<superm1> tseliot, why is that?
<tseliot> otherwise they will break a few things (as cjwatson reported)
<superm1> hum interesting. is there a bug on this?
<superm1> or just side chatter that was reported in irc at some point?
<tseliot> let me check
<jcristau> so they're not available on !x86, i guess?
<superm1> oh that would probably make sense - which would also mean i can't let the nvidia-180-libvdpau-dev package i was going to make be arch all can i..
<tseliot> superm1: maybe I confused it with nvidia-common. But anyway it makes sense to have them arch specific since they really support only x86 x86_64
<superm1> hmm.  ok..
<tseliot> superm1: let me know when the package is ready
<superm1> i've got it readyish right now, but i'll show you after i verify the test builds with mythtv in case i need to touch anything else in it
<tseliot> ok
<superm1> tseliot, still there?
<superm1> tseliot, here's the diff i'm planning to upload if you'd like to take a look: http://pastebin.com/f6e8ce16f
<superm1> main thing i'm concerned about is the way i named those vdpau packages, i'm thinking ahead to try to prevent conflicts with the next series of drivers (188 or what not)
<superm1> but otherwise this diff works to build myth against vdpau
<superm1> in tseliot's absence, can I get another set of eyes on those packaging changes before I upload?  bryce or tjaalton ?
<bryce_> superm1: hmm
<bryce_> superm1: you could more explicitly reference the nvidia_supported change in the changelog; it's not obvious which changelog entry belongs to that change
<superm1> bryce, ok will do.  
<superm1> bryce, i'm particularly referring to the vdpau packaging changes - those package names in the control file seem appropriate?
<bryce_> otherwise looks like it's mostly doing a s/180.11/180.18/g, which all looks fine
<bryce_> superm1: I don't have a problem with them, but I'd defer to others opinions
<tseliot> superm1: here I am
<superm1> tseliot, hi
<bryce_> superm1: libvdpau-180 could be another alternative for naming, however I like how it puts this into the nvidia namespace
<superm1> bryce, i thought about that, but in theory another vendor could put together a vdpau api compatible package, which is why i didn't want to hardcode it
 * tseliot has a look at the diff
<bryce_> superm1: ah true
<tseliot> superm1: nvidia-180-libvdpau-dev can't be arch = all as it depends on nvidia-180-libvdpau (which is i386 or amd64)
<superm1> is that against debian policy though?
<superm1> usually -dev packages with headers only are arch all
<tseliot> superm1: I was worried about having broken dependencies on architectures other than i386 and amd64
<superm1> bryce, what do you think on that?
<bryce> -nvidia is only relevant on i386 and amd64 anyway, right?
<bryce> but yeah I thought most -dev packages were arch all, since they're usually just headers and stuff
<tseliot> superm1: the diff looks good but keep in mind that I'm tired and so are my eyes ;)
<superm1> well if anything when an archive admin NEW's this, they'll make the final call on it
<tseliot> right
<superm1> tseliot, okay well if anything comes up, i'll be glad to help get another upload to take care of it. thanks!
<tseliot> superm1: thank you ;)
 * tseliot > off for a bit
<superm1> cya
<bryce> anyone else seeing PrintScreen breakage?  (305695)
<superm1> bug 305695
<ubottu> Launchpad bug 305695 in metacity "Jaunty doesnt allow screenshots getting "No command 33 has been defined" error with printscreen " [High,Triaged] https://launchpad.net/bugs/305695
<superm1> yeah i saw that yesterday and filed a duplicate
<crevette> bryce this is fixed by latest metacity
<crevette> 2.25.89 afaik
<crevette> s/afaik/IIRC/ :)
<bryce> crevette: interesting; where did you learn that?
<crevette> https://bugs.edge.launchpad.net/ubuntu/+source/metacity/+bug/312522
<crevette> I packaged it
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/312522/+text)
<crevette> waiting to be sponsored
<bryce> ahh ok
<crevette> and in my ppa if you want
<bryce> ok
<bryce> link?  https://edge.launchpad.net/~crevette/+archive doesn't work
<crevette> but https://edge.launchpad.net/~bmillemathias/+archive/ will :)
<crevette> I should change my nick
<crevette> don't pick all my updates
<bryce> mm, maybe I should hold off updating this system since I'm using it for day to day testing
<crevette> ah :)
<crevette> sure
<bryce> but thanks, I'll add all this info to the bug for other testers (seems we have plenty)
<crevette> perhaps I should update the changelog to include one bug and duplicate all others ?
<bryce> no, should leave the bugs separate, unless they literally are exactly the same bug
<bryce> superm1: hey do you know anything about color depth issues with the new -nvidia?
<superm1> bryce, no i haven't heard anything of the sort
<superm1> bryce, encountering them?
<bryce> superm1: rickspencer is, although he's fiddling with nvidia-xconfig to correct it (he's ran into some configuration troubles)
<superm1> on jaunty?
<bryce> yep
<bryce> I'll help him file a bug if he's still having problems tomorrow.
<superm1> is ignoreabi still necessary for 180 drivers with the upload i put in?  I was only testing it with intrepid (no ignoreabi necessary still)
<bryce> dunno
<superm1> ill take a look tomorrow and see
<bryce> ok
<andersk> Iâve been running 180.18 for a while, and it still needs IgnoreABI, unless the new package does something really magical. 
<superm1> andersk, no it doesn't.  it was based on a variety of the PPA packages.  it's mostly uploaded to get the vdpau libraries and headers in the right places
<andersk> dpkg: dependency problems prevent configuration of nvidia-glx-180:  nvidia-glx-180 depends on nvidia-180-libvdpau (= 180.18); however:   Version of nvidia-180-libvdpau on system is 180.18-0ubuntu1. 
<andersk> Yeah, the Depends: nvidia-180-libvdpau (= #VERSION#) in control.in is wrong. 
<andersk> It should be (>= #VERSION#) or (= ${binary:Version}) or something. 
#ubuntu-x 2009-01-08
<superm1> andersk, yikes, i'll take care of that right now
<superm1> andersk, thanks for catching that
<Ng> would I be mad for expecting video playback to be not significantly different among cards with proper drivers? Since there's basically no video decoding acceleration these days and 2d performance is much of a muchness?
<Ng> I only ask because in my endless swapping of hardware I tried an nv 7600GT last night and it was completely unable to play a 1080p h.264 video from nasa, but the onboard G45 while not perfect did a much better job of it
<bryce> Ng: with -nv or -nvidia?
<bryce> I could imagine -nv being especially sucky
<Ng> bryce: -nvidia
<Ng> I was a little surprised to be honest. it's a weedy CPU, but I figured that would be the same amount of a bottleneck on any card since there's no hardware acceleration involved
<bryce> I could imagine -nv being especially sucky
<bryce> oops
<bryce> yeah, -nvidia ought to be fine.  But who knows, -nvidia is a world unto itself
<bryce> really, comparing any experiences with -nvidia to any other linux driver is as good as comparing windows behaviors to linux
<tseliot> Ng: nvidia driver 180.11 + vdpau-enabled mplayer + one of the gpus supported by vdpau should help: http://www.nvnews.net/vbulletin/showthread.php?s=28f416fa08063af2fdd8490233da8291&t=123091
<tseliot> too bad geforce 7xxx are not supported
<Ng> tseliot: sure, I'm probably going to order a 9xxx today, but I was just surprised that it seemed to be worse
<Ng> the reality is that I will go mad if I have to use mplayer all the time ;)
<Ng> but I'm going to stick with nvidia because they seem to do an infinitely better job of talking to a big TV than anyone else
<Ng> even the bios is scaled automagically to 1080p so my TV doesn't have to confuse itself trying to display rubbishy old DOS video modes
<tseliot> Ng: you can use totem with ffmpeg (again it has to be vdpau enabled)
<Ng> (I'm entirely happy to patch ffmpeg/mplayer/xine)
<Ng> but totem with ffmpeg.... I would have thought not?
<Ng> the only backends are gstreamer and xine?
<tseliot> gst-ffmpeg
<tseliot> http://projects.gnome.org/totem/
<Ng> I could be very wrong here, but my understanding is that gst can use ffmpeg for (de|en)coders, but not as a video sink
<tseliot> I don't know
<tseliot> therefore I can be wrong
 * dennda waves
<dennda> I just figured that the problem with my graphics card is already reported in this bugreport: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/252094
<ubottu> Launchpad bug 252094 in xserver-xorg-video-intel "[i965] Poor graphics performance and rendering errors on Intel GM965 system, Ubuntu 8.10" [Medium,Confirmed]
<dennda> What I want to know: Whom may I blame for it not working properly? Is it intels fault? Will it get better in jaunty? How can I help? :-)
<Ng> dennda: there are a lot of changes going on with the intel driver in the next couple of ubuntu releases, so it's likely that things will change :)
<dennda> Ng: "next couple of ubuntu releases" means I have to wait X * 6 months, where X is unknown? :-)
<Ng> dennda: probably 2
<Ng> dennda: to some extent it's dependent on things getting into the upstream kernel
<dennda> hm ok, sad
<superm1> bryce, there was a new nv driver release today that addresses color issues...
<superm1> http://www.nvidia.com/object/linux_display_ia32_180.22.html
<bryce> superm1: ah cool
<superm1> no mentions of the new X abi however, so i'm not sure it's that useful yet
<bryce> superm1: it turned out rick just had his monitor contrast/etc. controls set wrong
<superm1> haha
<Rocket2DMn> hey guys, ive been talking with Brian in #ubuntu-bugs, he thinks that bug 313567 is probably an X bug instead of kernel
<ubottu> Launchpad bug 313567 in linux "[Jaunty] Suspend/resume restarts X session" [Undecided,New] https://launchpad.net/bugs/313567
<Rocket2DMn> Is there somebody who would help me get it triaged?
<bdmurray> bryce: Rocket2DMn is saying that X restarts after resuming from suspend
<bdmurray> on jaunty with the ati driver
<bdmurray> bryce_: ?
<bryce> Rocket2DMn: interesting, loading your url crashed xchat. lemme try that again
<bdmurray> whoops
<Rocket2DMn> lol!
<bryce> what fun
<Rocket2DMn> ok, i'm gonna run afk for about 20 minutes.  please let me know either here or on my bug report what else you need to complete the bug triage.  Thanks guys.
<bryce> sorry, distracted by this xchat crash bug, trying to convince upstream it really is a bug
<bryce> ah the joys of running a development distro on your desktop...
<bryce> Rocket2DMn: if it is an X crash then there will be a backtrace printed to /var/log/Xorg.0.log or errors to a file in /var/log/gdm/.  
<bryce> Rocket2DMn: if that's the case, then the next step is to collect a full backtrace via http://wiki.ubuntu.com/X/Backtracing
<Ng> hmm interesting, the nvidia card is only running a PCI-E 4x
<Ng> maybe the G45 is stealing 16X and that's why it was doing the video better
<Rocket2DMn> back.
<Rocket2DMn> bryce, i'll go ahead and attach the log file.  i need to restart the laptop becuase the screen died and wont come back up
<Rocket2DMn> i did see a file in /var/log/gdm with some stuff in it as well
<Rocket2DMn> bryce, should i change the bug package to xorg?
#ubuntu-x 2009-01-09
<Rocket2DMn> bryce, changed package to xorg and attached 2 files.  it looks like a backtrace of some sort was included in the error log from the gdm folder, do you still need a full backtrace?
<Rocket2DMn> ill go ahead and start one, but feel free to interrupt if its not needed
<jcristau> a full backtrace from gdb is a lot more useful for debugging than what's in the log
<Rocket2DMn> righto, getting the packages now
<jcristau> the log mostly helps narrow down the issue somewhat, and link multiple reports of the same bug together
<bryce> you'll need the dbg or dbgsym packages for each of the things mentioned in the X backtrace - xserver, hal, dbus
<bryce> so far is looking like something input device related
<Rocket2DMn> ok, but how do i get the laptop to suspend when in gdb
<Rocket2DMn> i have a remote connection over ssh open
<Rocket2DMn> should i then go back to the laptop and suspend it?
<jcristau> that should work
<Rocket2DMn> hmm i froze up the box
<bryce> look at gdb
<Rocket2DMn> yeah it broke
<jcristau> hrm. keeping an ssh connection over suspend/resume isn't going to be easy..
<Rocket2DMn> the machine wont go to sleep while my ssh session is open
<jcristau> in that case getting X to dump core will probably be easier than getting the trace in gdb
<Rocket2DMn> this is locking up the system
<bryce> eh, I wish libc provided a full-backtrace printing capability
<bryce> Rocket2DMn: by chance does anything get saved to /var/crash/ ?
<Rocket2DMn> im about to check there actually
<jcristau> bryce: you want a libgdb? :)
<Rocket2DMn> do i really need to do this gdb remotely?
<bryce> jcristau: that would be sweet :-)
<bryce> Rocket2DMn: not necessarily; sometimes you can do it from a console
<jcristau> Rocket2DMn: not if you get X to dump core when it crashes
<Rocket2DMn> nothing in /var/crash, let me try from tty1
<bryce> you may need to load the X binary and pass in X's args by hand (actually for debugging purposes you probably can skip most or all of the args)
<jcristau> if you try it from tty1, type 'handle SIGUSR1 nostop' at the gdb prompt, otherwise you won't be able to vt switch
<Rocket2DMn> ok well i guess i cant do anything when i have gdb running, im stack at the blank screen again
<Rocket2DMn> lol no you tell me
<Rocket2DMn> now*
<Rocket2DMn> jcristau, do i type that before cont
<jcristau> yeah
<jcristau> i think running 'X -core', getting it to crash, and then looking into the core dump would be easier tho
<Rocket2DMn> we'll try that next
<Rocket2DMn> ok well i got it to suspend, but its not pulling out of standby, the power came back but the screen is black and i cant switch back to tty1
<Rocket2DMn> i can ssh in, is my tty1 session recoverable?
<Rocket2DMn> maybe i should retry the whole thing in screen?
<bryce> don't think you can recover tty's from ssh sessions afaik
<jcristau> try 'chvt 1' in the ssh session then
<Rocket2DMn> didnt think so, should i restart, do it all over, but from tty start screen, run gdb, detach, then trigger suspend? then pull out of standby and ssh and attach to screen?
<jcristau> although, if X is crashed, gdb probably stopped it, so you can't vt switch..
<Rocket2DMn> jcristau, no go on that, sorry
<jcristau> hmm. the screen trick could work.
<Rocket2DMn> alright, i gotta reboot the box again, give me a few
<bryce> I've never seen that done before, but it's a slick idea
<bryce> (if it works)
<bryce> at this point I usually end up just slapping in print statements around where I think the crash is happening
<Rocket2DMn> if this works, im getting a beer
<bryce> brb (booting with new glib)
<bryce> yay
<Rocket2DMn> oh man im in
<Rocket2DMn> we have a segfault kids
<bryce> sweet
<Rocket2DMn> how do i pull all this out now is the question
<Rocket2DMn> i think it's going to take up more than the screen
<jcristau> set logging, in gdb
<bryce> you can dump it to a log 
<Rocket2DMn> how
<jcristau> or use screen logging, or whatever.
<Rocket2DMn> ok, well im already in a screen session with gdb open, x crashed, i ran "backtrace full" and there were about 3 screens of text
<Rocket2DMn> how do i grab all that and dump it to a file
<bryce> set logging -- Set logging options
<bryce> set logging file -- Set the current logfile
<bryce> set logging off -- Disable logging
<bryce> set logging on -- Enable logging
<bryce> set logging overwrite -- Set whether logging overwrites or appends to the log file
<bryce> set logging redirect -- Set the logging output mode
<jcristau> 'set logging on; bt full'
<Rocket2DMn> so set a file first, right?
<jcristau> will log everything to gdb.txt
<Rocket2DMn> ah ok
<Rocket2DMn> ok guys, here is what we have - http://paste.ubuntu.com/102471/
<bryce> hot damn
<Rocket2DMn> is that what we need?
<bryce> yep, that's exactly it
<bryce> I think I'm going to document your screen trick and name it the Imes Technique ;-)
<Rocket2DMn> ill attach it to the report
<Rocket2DMn> bryce, =D.  ill explain on the bug report how i obtained the trace, in case anybody runs across it and needs to do something similar
<bryce> that'd be wonderful, I'll copy it into our backtracing docs
<jcristau>     prevSpriteWin = pSprite->win;
<jcristau> pSprite is NULL, boom.
<bryce> bingo
<jcristau> bryce: fdo#19176
<jcristau> looks like the same issue. fixed by e1a3a1a0d85c9971aea65c2228b5fd4dbf3bf57a
<bryce> jcristau: cool
<bryce> heh, what difference a bracket makes
<Rocket2DMn> almost done with my explanation, lol
<Rocket2DMn> this bug has already been fixed upstream? is that what im gathering?
<jcristau> Rocket2DMn: correct
<bryce> yep
<jcristau> with a one-liner
<bryce> worse, just a set of brackets ;-)
<jcristau> yeah.
<Rocket2DMn> ah, ive made worse errors in coding
<bryce> great, I'll pull that patch in once I'm done with this gnome bug
<Rocket2DMn> ok, i attached my backtrace to the bug report, i guess it can be marked as Fix Committed.  It would be cool if you can add the upstream report
<bryce> Rocket2DMn: sure I'll take care of doing that, thanks for doing such a thorough job on triaging this!
<Rocket2DMn> no prob, learned a bit in the process
<bryce> and of course thanks jcristau for locating the patch
<Rocket2DMn> indeed, thanks for helping out jcristau , and bryce :)
<bryce> Rocket2DMn: then I hope you run into more X bugs :-) (ducks)
<Rocket2DMn> haha, i used to be able to troubleshoot X decently from xorg.conf, then all this autodetection took over
<bryce> Rocket2DMn: yeah, sometimes it can be a pain for troubleshooting issues, however on the other hand it eliminated having to help people figure out their h/v sync ranges, which was sort of a PITA (glad I mostly missed those days)
<bryce> Rocket2DMn: btw if you're interested in helping in triaging X crash issues and walking people through the steps you've done, I think you could help us sort out a lot of X problems.  
<Rocket2DMn> sure bryce , holding down a real job limits my time to evenings
<Rocket2DMn> wish i could do Ubuntu stuff all day though
<Rocket2DMn> and i think youd all be glad to know, my beer glass here says "#include <beer.h>" on the side
<bryce> :-)
<bryce> cool, even sorting out just one or two of these crashes a week can make a big difference in stabilizing X
<Rocket2DMn> yeah ill keep it in mind when i make my way through the new bug listings when i get to them a couple of times a week
<Rocket2DMn> most of my time ends up going to the forums, and some wiki documentation ocassionally
 * bryce nods
<bryce> just explaining to people how to get full backtraces can make a huge difference, whether in the bug tracker, forums, or whereever
<bryce> as you saw, once we get a full backtrace, figuring out a solution often takes an X dev a few minutes
<Rocket2DMn> yeah, people on the forums dont deal with bugs very much, except for the Development Testing area
<Rocket2DMn> some of us are working to integrate bugs better into that part of the community, but tbh they are mostly beginners who want nothing to do with them
 * bryce nods
<Rocket2DMn> i'm going to update my bug filing guide to include ubuntu-bug program at brian's request, http://ubuntuforums.org/showthread.php?t=1011078
<Rocket2DMn> forums were down a lot today, so i ended up doing the X thing instead of that
<bryce> yeah even just reporting a bug requires some basic level of technical aptitude that not all users are ready to undergo
<bryce> hehe
<Rocket2DMn> X is even worse for beginners to handle because they don't ever want to see a terminal or tty, esp with no GUI behind it
<Rocket2DMn> unfortunately the restricted drivers continue to be one of the major issues with new users, even almost 2 years now after i started with Ubuntu
<Rocket2DMn> I have a silly question for you, what's the difference between xorg and xorg-server?  should most bugs be against xorg-server?
<jcristau> xorg is a set of metapackages, mostly
<Rocket2DMn> thought that might be the case
<jcristau> so yeah, most bugs should be against the server or one of the drivers
<Rocket2DMn> i'll keep that in mind, thank you
<bryce> it's okay to file against xorg; we routinely thumb through those and refile them to the appropriate product, but yeah nearly all bugs actually go against xorg-server or one of the drivers
 * Rocket2DMn takes notes
<bryce> most people won't know what product to file against, so we don't make a big deal about it if someone just files against xorg (in fact we encourage doing so if there's ever any doubt), but it does add some delay to getting your bug reviewed
<Rocket2DMn> i was looking at the bugs for ubuntu-x-swat, they are almost all being handled
<Rocket2DMn> that's pretty impressive
<bryce> well, actually we don't assign or subscribe bugs to ubuntu-x-swat anymore, so anything still there is going to be a fairly old bug
<Rocket2DMn> yeah i noticed that, too
<Rocket2DMn> is there another team that gets alerted of X bugs?
<bryce> not really
<bryce> joining ubuntu-x-swat gains you a feed of all the bugs
<bryce> I've got several automated scripts that filter through new bugs, and bubble up ones ready for analysis (basically bugs set to Confirmed are ready to be investigated)
<Rocket2DMn> bug 314838 looks pretty ripe for a backtrace
<ubottu> Launchpad bug 314838 in xorg "crash of xorg after vlc starts to play some movie" [Undecided,New] https://launchpad.net/bugs/314838
<Rocket2DMn> ill bookmark it for later though, i'm really tired
<Rocket2DMn> I'll see you guys later, thanks for your help tonight with my bug, glad to know a fix is already on the way!
<bryce> cya! thanks again
<bryce> tjaalton: help!
<bryce> $ git add 155_no_checkmotion_for_disabled_devices.patch
<bryce> The following paths are ignored by one of your .gitignore files:
<bryce> debian/patches/155_no_checkmotion_for_disabled_devices.patch
<bryce> Use -f if you really want to add them.
<bryce> fatal: no files added
<bryce> *.patch is listed in .gitignore ?
<jcristau> likely.
<jcristau> that makes sense upstream. not so much for us :)
<bryce> hrm
<bryce> jcristau: so should I -f it, or remove the *.patch from .gitignore in the ubuntu branch?
<jcristau> i'd use -f
<bryce> dpkg-source: error: cannot represent change to xorg-server-ubuntu-git/hw/xquartz/bundle/Resources/English.lproj/main.nib/keyedobjects.nib: binary file contents changed
<bryce> hrm, seems ubuntu git maybe isn't in a buildable state at the moment
<jcristau> yeah. timo mentioned that, apparently some binary files have been modified upstream, so they're not the same as in the tarball
<bryce> okay
<bryce> well, patch applies fine and I'd be surprised if there were any build issues; I've pushed it up
<bryce> can't build locally either...
<bryce> dpkg-checkbuilddeps: Unmet build dependencies: x11proto-dri2-dev (>= 1.99.3) libxv-dev
<jcristau> that's just a matter of installing them, no?
<bryce> ah, right
<bryce> sweet, we're below 1900 bugs :-)
<bryce> and that doesn't include about 100 -intel bugs with no response that probably could be expired but that I'll give another week or two for responses
<tjaalton> bryce: yes, that's why we are still stuck with beta3
<bryce> heya tjaalton
<tjaalton> bryce: howdy
<bryce> ok no prob, I stuck a little cherrypick patch in there for when it's ready
<tjaalton> hmm redhat hired a nouveau developer.. interesting
<tjaalton> wonder if there'll be a release sometime :)
<crevette> hello, good morning
<bryce> heya crevette
<superm1> bryce, i've got some hardware that I just got that again won't boot in vesa for intrepid, but does for hardy. NV doesn't yet support it yet. I can still make recommendations to that platform team for any enhancements necessary in the hardware, BIOS, or VBIOS to make it work, so can you look at the errors starting up with vesa to see if you had any suggestions that I could tell them? bug 315588
<ubottu> Launchpad bug 315588 in xserver-xorg-video-vesa "Hardware w/ 1600x900 LCD does not boot up using vesa" [Undecided,New] https://launchpad.net/bugs/315588
<superm1> (also doesn't boot vesa in jaunty)
<bryce> superm1: looking
<bryce> superm1: will comment on the bug
<superm1> bryce, thanks, i'll pass it on to the ODM then
<bryce> (WW) VESA(0): Unknown vendor-specific block 0
<bryce> mm haven't seen that before
<bryce> superm1: can you also post the xorg.conf you used for those logs?
<bryce> (basically, I want to know if you specified any h/v sync ranges for either case)
<superm1> bryce, it's basic live cd xorg log
<superm1> bryce, so nothing special in terms of anything i specified 
<tjaalton> http://ubuntuforums.org/showthread.php?t=1034377
<tjaalton> an excellent thread, great fun :)
<tjaalton> well, at least the sixth post
<tjaalton> oh, gets better on the third page
<bryce> he's complaining that the X api changed in the development release of jaunty??
<tjaalton> yep
<superm1> what happens in the event that the new API isn't stable by the time jaunty goes out though?  I've got a bad feeling these vendors won't want to rev their drivers on an unstable api..
<tjaalton> what do you mean unstable? it hasn't changed in months
<superm1> well is there a formal X release with the new API though, or is it all operating off git snapshots right now?
<tjaalton> 1.6 should be out soon, it should be finalized by then at least
<tjaalton> xserver is all you need, not the whole stack
<superm1> right... but i'm saying in the hypothetical situation that 1.6 isn't released soon, and get delayed until say a month after jaunty releases
<superm1> you know release dates slip etc
<tjaalton> in that case yes, they lose
<tjaalton> but it's not likely
<tjaalton> ..that the release is delayed that much
<superm1> ;)
<bryce> I've a call with nVidia next week, I'll raise the issue
<tjaalton> today there has been 34 commits to the 1.6-branch
<tjaalton> so a new rc could be out next week
<bryce> however I already notified them of the pending X version before christmas and encouraged adding support for it, and gave dates and such
<tjaalton> nvidia should be well aware of the ABI changes, since aplattner is quite active in the community
<superm1> from my experience with them (at least the guys i've worked with), it's good to stay on top of things and ask for updates so they dont fall through the cracks
<tjaalton> wonder why they had support for 1.5 for months before the release
<tjaalton> superm1: did you notice bug 315632?
<ubottu> Launchpad bug 315632 in nvidia-graphics-drivers-180 "upgrade from 180.11 broken (trying to overwrite `/usr/lib32/libvdpau.so.1', which is also in package nvidia-glx-180)" [Undecided,New] https://launchpad.net/bugs/315632
<superm1> tjaalton, <shrug> no, but i think that means it needs replaces then doesn't it?
<superm1> not necessarily conflicts though
<superm1> it's still in NEW, which is probably why no other reports have been made of it yet
<tjaalton> ah, that's good so it can be fixed
<tjaalton> yes, replaces should be enough I guess
<superm1> okay i'll do a quick tweak to it then
<tjaalton> great, thanks
<bryce> too bad  users can't mark their own bugs as Wishlist
<bryce> most of the bugs where people are unhappy about the automated triaging tools are because they're wishlist things
<bryce> which obviously don't require Xorg.0.log and the like, but hard to distinguish those from regular bugs mechanically
<tjaalton> heh
<bryce> however, out of 250 bugs or so changed last night, so far I've only seen 4 complaints of wrong triaging
<bryce> "currently i don't have this problem except i think mesa, drm, and the
<bryce> intel driver need some more work in general."
<bryce> heh
<tjaalton> clearly warrants a bug ;)
#ubuntu-x 2009-01-10
<bryce> ok up to 5 now - #307609
<bryce> tjaalton: you might want to peek at that bug 307609
<ubottu> Launchpad bug 307609 in pixman "libpixman is built with Altivec on ppc" [Undecided,Incomplete] https://launchpad.net/bugs/307609
<tjaalton> bryce: the configure script doesn't have an option to turn it off
<tjaalton> so upstream should provide one
<bryce> ok, so this should go upstream then.  thanks
<bryce> hum
<bryce> dnl Check for VMX/Altivec
<bryce> if test -n "`$CC -v 2>&1 | grep version | grep Apple`"; then
<bryce>     VMX_CFLAGS="-faltivec"
<bryce> else
<bryce>     VMX_CFLAGS="-maltivec -mabi=altivec"
<bryce> fi
<bryce> configure.ac does seem to have stuff for altivec support
<tjaalton> yes, but it only checks the arch
<bryce> --disable-vmx seems to be the switch associated with it
<bryce> ok, I guess I don't understand exactly what we require... if you can jot a few notes I can upstream it right now
<bryce> oh, it needs to have a check of some sort to not use altivec support with ppc?
<tjaalton> oh, right
<tjaalton> vmx/altivec
<bryce> do you think appending --disable-vmx to the configure line should be sufficient?  maybe I should ask the original reporter
<bryce> ...asked.
<tjaalton> should be enough
<bryce> huh, `xkbcomp -C :0` busted
<bryce> thanks kees
<bryce> ;-)
<tjaalton> what did he do this time?-)
<bryce> ah, remember that presentation he gave at UDS about new compiler security checking stuff?  seems xkbcomp is being naughty
<tjaalton> ah ok
<tjaalton> 02:36 < Atomo64> lp should be designed to cope with the kind of users it has; one should be  able to split, remove, merge, clone, and more (all forms editing, IOW)
<tjaalton> from #debian-x
<tjaalton> makes sense..
<bryce> completely agreed
<bryce> I think I've filed wishlist bugs for at least a couple of those capabiltiies :-)
<tjaalton> hehe
<tjaalton> anyway, night ->
<bryce> night
<kees> i've got it fixed
<bryce> https://bugs.freedesktop.org/show_bug.cgi?id=19490
<ubottu> Freedesktop bug 19490 in App/xkbcomp "Buffer overflow in WriteCHdrKeyTypes running 'xkbcomp -C :0'" [Normal,New]
<kees> ah, cool
<bryce> kees, are you going to package and upload the patch, or shall I?
<kees> bryce: well, I wanted to test it first, but the patch system hates me
<bryce> ah
<bryce> yeah looks like there isn't a patch system
<kees> debian/xsfbs/xsfbs.mk says "quilt"
<bryce> dpatch:
<bryce>   - Add "dpatch" to debian/control Build-Depends
<bryce>   - Change debian/rules to include dpatch makefile
<bryce>     "include /usr/share/dpatch/dpatch.make"
<bryce>   - Update the "build" and "clean" rules
<bryce>     "build-stamp: -> build-stamp: patch"
<bryce>     "clean: -> clean: clean-patched unpatch"
<bryce>     "clean-patched:"
<bryce> er
<bryce> nevermind that
<bryce> quilt:
<bryce>   - Copy xsfbs dir into debian/ if needed
<bryce>   - In debian/control add quilt as a Build-Depends
<bryce>   - In debian/rules, add these lines:
<bryce> PACKAGE = <packagename>
<bryce> include debian/xsfbs/xsfbs.mk
<kees> OH! it _missing_ quilt as a build-dep
<bryce> ...
<bryce> build: patch build-stamp
<kees> it's got all the support for it, it's just not actually pulling quilt in
<bryce> aha
<bryce> ok, feel free to upload that once you've confirmed it 
<kees> Could not load keyboard geometry for :0.0 ... 
<kees> should it be able to run?
<bryce> hmm
<bryce> I think that might be an acceptable response
<bryce> yep
<bryce> I get the same thing if I run just 'xkbcomp :0'
<bryce> in any case if that's wrong, it's unrelated to the buffer overflow I think
<kees> cool.  I fixed 2 more overflows before it'd give me a normal exit.  :P
<kees> updated the upstream bug patch and am uploading to jaunty now
<bryce> I'm not certain that 'xkbcomp -C :0' is correct usage
<bryce> oh, yeah I guess it is
<bryce> but I just get error messages, strange
<bryce> bryce@chideok:~/src/xorg/xorg-ubuntu-git/debian/apport$ xkbcomp :0
<bryce> Warning:          Could not load keyboard geometry for :0
<bryce>                   BadAlloc (insufficient resources for operation)
<bryce>                   Resulting keymap file will not describe geometry
<Rocket2DMn> Hey guys, I ran across a few X related bugs this evening, I kept my eyes open for them at your request.  I need help triaging them though since I'm not an X pro.
<Rocket2DMn> I'll be chilling here for awhile, so just ping me if/when you're ready
<bryce> sure
<bryce> I'm just going through bugs
<bryce> heh  "lspci -vvnn ? what things are these and can it be done on desktop, no command line to me."
<bryce> (272814)
<Rocket2DMn> lol, nice
<Rocket2DMn> alright, let's start with bug 315603
<ubottu> Bug 315603 on http://launchpad.net/bugs/315603 is private
<Rocket2DMn> looks like the retrace failed, thought idk how useful those are to you guys.  There is no backtrace but there is a CoreDump
<Rocket2DMn> i haven't a clue how to access a coredump or if there is anything useful there for the humna eye anyway if it does get interpreted from its binary format
<bryce> yeah the retracer often fails
<bryce> but the backtraces it gathers are hardly ever sufficient.  we almost always end up asking the user to collect a full backtrace and reference them to wiki.ubuntu.com/X/Backtracing for directions
<Rocket2DMn> yesterday you guys suggested getting a dump rather since getting that backtrace was such a pain, is there enough info in a dump to do a triage?
<bryce> maybe
<Rocket2DMn> seems like the guy who filed that report doesnt know much either, and may not be able to reproduce the crash at will
<bryce> I've never actually tried that myself.  in theory though it should work (that's what the retracer is doing)
<bryce> quite true
<Rocket2DMn> so i guess the question is - what do we do with that report? mark it as triaged?  how do i know if there is enough in the coredump (and how would i even check)?
<bryce> hmm
<bryce> try this
<bryce> sudo gdb /usr/bin/Xorg /whatever/core
<bryce> Then run the "backtrace full" command inside gdb. 
<Rocket2DMn> you mean me download the coredump and do that?
<Rocket2DMn> how i wish intrepid ran in a vbox
<bryce> that's right
<bryce> I'll try it too
<Rocket2DMn> i need to install the necessary packages on my intrepid laptop first
<bryce> hrm
<bryce> well looks fairly useless to me so far...
<bryce> (gdb) bt full
<bryce> #0  0x0000000000000000 in ?? () from /lib64/ld-linux-x86-64.so.2
<bryce> No symbol table info available.
<bryce> Cannot access memory at address 0xbfd7250800000001
<Rocket2DMn> yeah thats not good
<Rocket2DMn> does that dump need to be extraced first?
<Rocket2DMn> bryce, i got the same error you did (different address)
<bryce> yeah I'm not sure what to do from here
<bryce> normally I'd ask the user to reproduce the crash and collect a backtrace manually
<bryce> like you said, most of the time that's way over their head so we kind of get collectively stuck at that point
<Rocket2DMn> well we still can, but we're likely to get a no response or a "duh what?"
<Rocket2DMn> i guess it's worth setting to incomplete and asking, if they dont get back in 60 days, close it as an expired bug
<Rocket2DMn> is there a reason you keep 2 copies of that X/Backtracing page? the one on the wiki and https://wiki.ubuntu.com/DebuggingXorg
<bryce> nope, that latter one can probably be removed.  Thought I'd already done that.
<Rocket2DMn> yeah not so quick though
<Rocket2DMn> https://wiki.ubuntu.com/Bugs/Responses#Missing%20a%20back%20trace
<bryce> yeah I've just finished looking through gdb help to see if there's any commands that'd be useful, but am not seeing something obvious
<Rocket2DMn> wait hold wrong link
<bryce> My stock backtrace-needed reply is "Are you able to reproduce this issue? If so, please collect a full backtrace - see http://wiki.ubuntu.com/X/Backtracing for directions."
<Rocket2DMn> nvm
<Rocket2DMn> ok that second page is linked from https://wiki.ubuntu.com/DebuggingProgramCrash
<bryce> often I also ask for steps to reproduce the problem if not given already
<Rocket2DMn> lol that page is just and include of X/Backtracing
<bryce> heh
<bryce> that's probably fine then; there are probably old forum posts and bugs and stuff referencing that old link
<bryce> I've been trying to consolidate all the X info under the X/ namespace
<Rocket2DMn> yeah probably just leave the wiki page
<Rocket2DMn> ill post back to that bug
<bryce> ok cool
<Rocket2DMn> alright done.
<Rocket2DMn> next one, bug 315542
<ubottu> Launchpad bug 315542 in xserver-xorg-video-intel "X hangs on ubuntu 8.1 intrepid laptop" [Undecided,New] https://launchpad.net/bugs/315542
<Rocket2DMn> the gal is using unofficial drivers to try and get it working
<Rocket2DMn> and there is possibly an infinite loop - can a backtrace actually catch that?
<bryce> usually not
<Rocket2DMn> didnt expect so
<bryce> these infinite loop bugs are a bit harder to debug.  I spent some time with jesse (from Intel) asking about tricks for debugging these
<bryce> in this case the problem looks like this:
<bryce> (EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error
<bryce> usually whatever gets printed out before it starts with the mieqEnequeue gobbltigook is what's relevant for the issue
<bryce> here's my notes...
<bryce> Lockups
<bryce> * Black screen, with stuff otherwise still functional - mode issues, so collect intel_reg_dumper output.
<bryce> * hard hangs - pipe quirks, could be modesetting related
<bryce> * wait lp ring soft hangs - render accel or 3d bugs.  Try turning off DRI or EXANoComposite to try isolating where they occur.  I\
<bryce> f it occurs with a specific application with/without DRI.
<bryce> * Screen corruption.  Having a photo helps.  Short lines 8px wide, will be GPU related.  Long lines will be tiling issues.
<bryce> Screensaver just pulls from the framebuffer
<bryce> sysprof can help with high cpu issues
<bryce> ltrace sometimes useful
<bryce>  
<bryce> In general, with these kinds of bugs triaging is going to be limited to making sure they have the usual files, and a good precise set of steps to reproduce, and the conditions under which the bug occurs
<bryce> e.g., with or without compiz, with certain programs loaded, etc.
<Rocket2DMn> the usual files? you mean xorg.conf, Xorg.0.log, dmesg?
<bryce> Xorg.0.log, lspci -vvnn, xorg.conf, yeah.  Sometimes photos if there's screen corruption.
<Rocket2DMn> alright ill get as much as i can from this person
<Rocket2DMn> should i have them remove that testing driver?
<bryce> nah, that's not a big deal
<Rocket2DMn> ok, in that case the bug is filed against the intel driver, not xorg-server, should i switch it
<bryce> yep
<Rocket2DMn> ok, but the error above is from the driver still: (EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error
<Rocket2DMn> ill put it on xorg-server
<bryce> oops wait, I read your comment backwards (sorry, wife just came home so I'm distracted)
<bryce> yes leave it against the -intel drivers
<Rocket2DMn> hehe oops, ok i changed it back
<bryce> as a general rule, if in question, default to filing against the driver, because there are more active engineers focusing on drivers than there are on the xserver
<Rocket2DMn> bugmail spam heading your way
<Rocket2DMn> ok, noted.
<Rocket2DMn> and on the topic of drivers, bug 315274
<ubottu> Launchpad bug 315274 in patch "Updating of ATI drivers crashes" [Undecided,New] https://launchpad.net/bugs/315274
<Rocket2DMn> i assume that should be filed against fglrx-driver and not patch
<bryce> hehe
<bryce> yep, that's right
<Rocket2DMn> i guess that is just an update failure, not an X crash
<bryce> also fwiw oftentimes these problems with crashes from upgrades with fglrx are due to them having mixed up -ati and -fglrx installs
<bryce> each of them provide certain glx files, so having both installed end up causing toe-stepping
<bryce> the solution is to do a complete purge of the driver they don't want, and a full reinstall of the driver they do want
<bryce> not enough info in this bug report to know for certain that's the problem here, but that'd be my gut guess
<bryce> also, most flgrx bugs are not going to be going anywhere
<Rocket2DMn> yeah ive noticed restricted driver bugs dont get a lot of love
<bryce> I am an contact with the ATI guys and able to pass a >few< bugs up to them, but really only ones that are pervasive, easily reproduced, and/or very well reported go up
<bryce> imho it's barely worth the trouble to triage fglrx bugs
<Rocket2DMn> alright ill leave this one alone, it looks like a bad download or something anyway
<bryce> yup
<bryce> ok, sorry wife wants me to take her out to dinner so I gotta run.
<Rocket2DMn> ok, we're done, thanks bryce , have fun
 * bryce waves to tseliot
<tseliot> hey bryce
<pwnguin> what else is needed for triage on bug #315882?
<ubottu> Launchpad bug 315882 in xserver-xorg-input-synaptics "[Jaunty] synaptics fdi file does not contain entry for touchpads know as "ETPS/2 Elantech Touchpad" starting with 2.6.28 series kernels" [Undecided,New] https://launchpad.net/bugs/315882
<jcristau> just needs a new upstream, afaict
#ubuntu-x 2009-01-11
<tseliot> tjaalton, bryce: how come IgnoreABI is no longer in hw/xfree86/parser/Flags.c ?
<tjaalton> tseliot: isn't it a driver option?
<Alexia_Death> nope. server option
<Alexia_Death> works too...
<tjaalton> ok
<tseliot> I have noticed that if I start X with startx -- -ignoreABI the driver starts
<tseliot> while if I set Option "IgnoreABI" "True" in the xorg.conf
<tseliot> it doesn't work
<Alexia_Death> Mine works
<Alexia_Death> In section server flags
<tseliot> yes, I put it there
<Alexia_Death> hmm. interesting.
<tseliot> Alexia_Death: how is it going with your work on (sane) tablet hotplugging with dbus?
<Alexia_Death> tseliot: it somewhat works
<Alexia_Death> tseliot: but you cant test it with current x...
<Alexia_Death> not withiout some serious patching
<tseliot> Alexia_Death: why?
<tseliot> like rebuilding it with dbus support?
<Alexia_Death> 1.6 input is baadly broken
<Alexia_Death> no
<tseliot> oh, right, you said "serious" patching
<tseliot> does it segfault or what?
<Alexia_Death> There are at least 4 separate patches to X(one of hem is a hack because fix isnt made for 1.6 branch yet) and one patch to wacom driver
<Alexia_Death> but you can test it with intrepid and x 1.5
<Alexia_Death> I even have the packages in my ppa
<Alexia_Death> Theres one crash in X and one crash maker in wacom driver
<Alexia_Death> to get buttons to work right on tablet theres the hack
<Alexia_Death> and to fix event history theres 2 distinct patches or GIMP wil act weird
<tseliot> does it affect GTK at large or only GIMP?
<Alexia_Death> it affects anything that uses XGetHistorybufer
<Alexia_Death> err... or something like that.
<Alexia_Death> Gimp does.
<Alexia_Death> I havent seen anything else that does.
<Alexia_Death> xournal does not
<tseliot> ok
<Alexia_Death> I traced them and posted bugs at sorg bugzilla. history buffer fixes have patches and Ive tested them. Buttons issue has patc but does not apply to 1.6 obly to master, wacom issue is reported and hopefully will be fixed...
<tseliot> ok, I have to postpone my configuration app anyway. Hopefully the missing bits will be ready for Jaunty+1
<Alexia_Death> tseliot: dont
<Alexia_Death> tseliot: configuration app has a place in the hoplug trick
<Alexia_Death> currently it runs wacomcp
<Alexia_Death> l
<tseliot> Alexia_Death: I have to because there's not enough time until feature freeze
<Alexia_Death> tseliot: make it a standalone using xsetwacom?
<Alexia_Death> when is feature freeze anyway?
<tseliot> yes, it will use xsetwacom too
<Alexia_Death> I have settings dunping/loading implemented in my daemon
<tseliot> February 19th
<tseliot> which may not be enough for me to design and implement something that doesn't suck ;)
<Alexia_Death> tseliot: think positive
<Alexia_Death> IT jsut has to do better than wacomcpl
<tseliot> hehe
<Alexia_Death> tseliot: I can give you my X packages if you want
<Alexia_Death> 32 bit tho
<tseliot> the ones in your PPA? https://launchpad.net/~alexiade/+archive
<Alexia_Death> those a re for intrepid
<Alexia_Death> I dont have jauntys there because I dont have signing set up here.
<Alexia_Death> but I can just give you a deb set
<tseliot> can you give me a link to the source?
<Alexia_Death> better plan
<tseliot> or to the patches
<Alexia_Death> Im going to give you the patch set;)
<tseliot> good idea
<Alexia_Death> tseliot: http://a.death.pri.ee/series.tar.gz
<Alexia_Death> but you need to isntall patched wacom driver too
<Alexia_Death> or the X will die in unplug
<Alexia_Death> that pach is a hack too because I could not get the fix to work
<tseliot> Alexia_Death: any links to the patch for the wacom driver?
<Alexia_Death> tseliot: I dont have that in patch form, but i can pack and post an already patched version
 * tseliot would rather not see X die when tablets are unplugged
<tseliot> Alexia_Death: if you give me the source, I'll make a diff
<Alexia_Death> Ok.
<Alexia_Death> I can give you just one file then
<tseliot> good
<Alexia_Death> its ftom 0.8.2
<Alexia_Death> http://a.death.pri.ee/wcmConfig.c
<Alexia_Death> tseliot: it has a bit of noise, but the two lines commented out are the catch
<Alexia_Death> x tries to free the priv struct even tho wacom has freed it already and aborts. Not freeing it lets it slip
 * tseliot has a look at the code
<Alexia_Death> theres a null check in X side but it does not work if I set priv=NULL
<tseliot> hmm
<tseliot> what is priv set to? Or where does it point to?
<tseliot> anyway
 * tseliot > dinner
<tseliot> thanks for your patches
<bryce_> tjaalton: bug #316136 - offscreen pixmaps problem is baack
<ubottu> Launchpad bug 316136 in xorg-server "Xaa Offscreen Pixmaps regression" [High,Triaged] https://launchpad.net/bugs/316136
<tjaalton> bryce_: yes, tormod already commented that it's fixed upstream
<tjaalton> it wasn't merged to master the last time, because there was supposed to be a more correct fix on the way, but wasn't
<bryce_> tjaalton: ahh
<bryce_> is that something we should backport, or does it come automatically with the xserver now in our git tree?
<tormod> I just posted what Timo said to the bug report :)
<tjaalton> heh, so it seems
<tormod> bryce: it's in the 1.6 branch, one commit after the last jaunty merge
<bryce_> ok kewl
<tormod> bryce, have you considered maintaining -ati on git.d.o?
<bryce_> tjaalton: btw, I've posted a few little xserver patches to lp
<bryce_> they're the ones marked In Progress
<bryce_> tormod: I've had some fairly mixed experiences using git to maintain X stuff so far
<bryce_> tormod: it's probably my own just lack of git-specific know-how, but it seems like it always takes me more time to do something when git's involved
<tjaalton> bryce_: ok cool
<tjaalton> bryce_: we never went through it at UDS :)
<bryce_> but I will say I've had good experiences maintaining xorg in git so far
<tormod> bryce_: I see. there's a certain overhead, true. but sometimes it can be very efficient.
<bryce_> xorg-server I've had such frustrating problems with that I am scared to commit anything to it now ;-)
<tjaalton> we could also have other branches there..
<tjaalton> if we wanted to backport some stuff
<bryce_> tormod: mostly I post my patches back upstream.  We've pulled new -ati git snapshots regularly enough that it's worked adequately
<tormod> do you think they will take your "exa by default" soon?
<bryce_> when I proposed it to alex it sounded like he was thinking that it was about time to switch
<bryce_> one thing I'm thinking is we may need to build in some structure for quirking certain cards back to XAA; I've seen at least one bug report on that so far
<tormod> asac's bug I guess :)
<bryce_> yep
#ubuntu-x 2010-01-11
<ripps> oh man, it is so nice to have my wacom tablet working again.
<tseliot> ara: the nvidia packages and the new mesa in Lucid should work correctly now
<ara> tseliot, ppa or ubuntu?
<tseliot> ara: ubuntu
<ara> tseliot, OK, thanks. jockey as well?
<tseliot> ara: note: the nvidia drivers were recently published therefore they may not be available on the server that you use yet
<tseliot> ara: not yet
<jcristau> tseliot: mesa's still broken afaik?
<tseliot> jcristau: no, they fixed it
<jcristau> again?
<tseliot> they = tjaalton and sispoty
<tseliot> well, define what you mean by broken
<jcristau> you can't build anything against libGL
<tseliot> yes, that was fixed
<jcristau> because libGL.so is hidden in /usr/lib/mesa
<jcristau> there's something newer than -0ubuntu3?
<tseliot> jcristau: no, that's the latest. Is that still broken???
<jcristau> see the irc logs from the week end
<tseliot> the config files provided by mesa should point to that path and ldconfig should know where to get the libraries
<tseliot> ok
<tseliot> yesterday, I assume
<jcristau> ldconfig and the ld.so.conf allow apps to find libGL.so.1
<jcristau> but, ld still needs to find libGL.so
<jcristau> and you moved that away
<tseliot> jcristau: ah, do you mean that there's no libGL.so in /usr/lib/mesa ?
<jcristau> no, i mean that there's no libGL.so in /usr/lib
<tseliot> ok
<geser> i.e. currently every package linking against -lGL needs to also specify -L/usr/lib/mesa
<tseliot> yes, I picked that up. I'm thinking of the best solution to fix that with alternatives
<tseliot> jcristau: is mesa installed before or after X? 
<jcristau> what does that mean?
<tseliot> jcristau: does one depend on the other
<tseliot> ?
<jcristau> no
<tseliot> is there a use-case for this?
<jcristau> for what?
<tseliot> for not having them depend on each other
<jcristau> yes
<tseliot> development?
<jcristau> just like there's a use case for apache not depending on firefox
<tseliot> :-)
<geser> which package does contain the config file for ld? because: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
<geser> (from a build inside a pbuilder)
<jcristau> geser: the X server (sigh)
<tseliot> jcristau: a simple link to the file in /usr/lib/mesa should do it
<tseliot> then if people want to compile against the nvidia gl library they will have to include the new path
<ScottK> tseliot: What's the plan for fixing mesa?
<tseliot> I'll put a link in /usr/lib/ that points to the right file. libgl1-mesa-dev.links would be the right place to add that link
<jcristau> tseliot: still won't help find libGL.so.1 without the x server installed though.  so that needs a different fix.
<ScottK> https://launchpad.net/ubuntu/+source/kdebase-workspace/4:4.3.90-0ubuntu1/+build/1436135/+files/buildlog_ubuntu-lucid-i386.kdebase-workspace_4:4.3.90-0ubuntu1_FAILEDTOBUILD.txt.gz says it's still broken.
<tseliot> ScottK: bug #505359
<ubottu> Launchpad bug 505359 in mesa "libgl1-mesa-dev installs a broken link in /usr/lib" [Undecided,New] https://launchpad.net/bugs/505359
<tseliot> jcristau: because of the missing ld.so.conf.d file?
<jcristau> yes
<ScottK> tseliot: I'm well aware of it being broken.  My question is about getting it fixed.
<jcristau> you could also revert to a sane state...
<tseliot> ScottK: right
<ScottK> tseliot: For Kubuntu this is an issue that has to be fixed soon enough for KDE 4.4 RC1 to finish building or we don't have an Alpha 2.  It's a big problem.
<tseliot> ScottK: I know. I thought it was fixed on Saturday and this morning I found out that it wasn't. Therefore I'm working on it right now. I understand the problem and I want this to be fixed ASAP too
<ScottK> tseliot: OK.  Good to hear.
<tseliot> jcristau: what if mesa installed its own file in ld.so.conf? Something that comes after (in alphabetical order) GL.conf?
<tseliot> ldconfig would preserve that order
<tseliot> and things should work
<jcristau> such a pile of hacks..
<tseliot> I'll take it as a yes ;)
<jcristau> *shrug*
<tseliot> jcristau: I have a solution which is actually saner. I can remove the alternative from X and put it in mesa so that the links will always point to the /usr/lib/GL directory. I will only have to apply this patch to X to make sure it picks up the right modules http://pastebin.ubuntu.com/354984/
<tseliot> i.e. less things to keep track of with alternatives
<tseliot> jcristau, tjaalton: my solution: http://pastebin.ubuntu.com/355022/ and http://pastebin.ubuntu.com/355023/
<tseliot> hey, I didn't notice that .patch files are ignored (as in .gitignore)
<tseliot> shall I add the patch manually with -f?
<Sarvatt> going to need a libGLU.so link too since that was moved to /usr/lib/mesa too?
<Sarvatt> /usr/bin/ld: cannot find -lGLU
<Sarvatt> dpkg-shlibdeps: error: couldn't find library libGLU.so.1 needed by debian/compiz-plugins/usr/lib/compiz/libblur.so (ELF format: 'elf64-x86-64'; RPATH: '').
<jcristau> i suspect moving libGLU was not the intended result
<Sarvatt> compiz built fine after making the links up till there
<tseliot> right, the change wasn't intended
<tseliot> but I can fix that too
<tseliot> Sarvatt: ok, fixed in git. Thanks for reporting
 * tseliot is building X and mesa for testing
<ripps> I think I'm going to disable ati kms. I think that my video playback might be faster with the old ums video overlay.
<tseliot> heh, very nice. I was building in pbuilder and my filesystem became read-only
<tseliot> fsck doesn't even want to show a progress bar
<Sarvatt> that fix doesn't work here is what I was trying to say earlier tseliot :(
<Sarvatt> dpkg-shlibdeps: error: couldn't find library libGLU.so.1 needed by debian/compiz-plugins/usr/lib/compiz/libblur.so (ELF format: 'elf64-x86-64'; RPATH: '').
<Sarvatt> sarvatt@sarvatt-hp:~/temp2/compiz-0.8.4$ ll /usr/lib/libGLU.so 
<Sarvatt> lrwxrwxrwx 1 root root 23 2010-01-11 10:16 /usr/lib/libGLU.so -> /usr/lib/mesa/libGLU.so
<tseliot> Sarvatt: and ls -l  /usr/lib/mesa/libGLU*
<tseliot> ?
<Sarvatt> -rw-r--r-- 1 root root 931510 2010-01-09 19:33 /usr/lib/mesa/libGLU.a
<Sarvatt> lrwxrwxrwx 1 root root     11 2010-01-09 23:19 /usr/lib/mesa/libGLU.so -> libGLU.so.1
<Sarvatt> lrwxrwxrwx 1 root root     20 2010-01-09 23:19 /usr/lib/mesa/libGLU.so.1 -> libGLU.so.1.3.070700
<Sarvatt> -rw-r--r-- 1 root root 461376 2010-01-09 19:33 /usr/lib/mesa/libGLU.so.1.3.070700
 * tseliot is locked out of his main computer until fsck finishes...
<Sarvatt> adding -l/usr/lib/mesa to every packages dh_shlibdeps doesn't seem like its going to be fun
<tseliot> Sarvatt: that would be wrong
<baptistemm> hello
<baptistemm> in my lucid install, I after KMS activation (I can see some boot message in full resolution) most of the time, the display becomes blank, and I can't switch to any VT
<baptistemm> it is a know bug which could looks like my problem (I have a Intel chipset)
<baptistemm> however I can have the gdm greeter if I start using the "failsafe" mode, I choose netroot and then I do a "start gdm"
<tseliot> Sarvatt: can you paste the error, once again, please?
<tseliot> Sarvatt: also, did you do an ldconfig?
<ripps> Okay, so did they make it impossible to use non-kms ati now? When I boot with modeset=0 I can't load compiz because my opengl now uses Software Raserizer
<tseliot> ripps: booting with nomodeset works for me
<ripps> hmm... maybe it's not related to kms, because I just reload the radeon driver w/ kms and restarted X, and opengl is still not working... maybe something else is going on. Is it because plymouth was just installed?
<tseliot> ripps: did you update your system
<tseliot> ?
<ripps> yeah, I plymouth was just installed fromt he repo right before I tried rebooting w/o kms. So I might of had the two confused
<ripps> Now I have no opengl with or without kms
<tseliot> ripps: please make sure to have the latest mesa
<ripps> libgl1-mesa-glx=7.7-0ubuntu3
<tseliot> what does the X log say?
<ripps> tseliot: well, as far as I can tell everything seems to be loading, so it might be isolated to mesa
<ripps> http://pastebin.com/f2918e09f
<tseliot> yes, that's fine
<tseliot> I'll see if I can reproduce it here
<ScottK> tseliot: Do you have an estimate of how long until we have a mesa fix in the archive?  People over on #kubuntu-devel are starting to get nervous.
<ripps> argh... reinstalled mesa, and rebooted. Opengl still stuck in software
<jcristau> LIBGL_DEBUG=verbose glxinfo?
<tseliot> ScottK: I skipped breakfast and ate my lunch in 5 minutes. I'm working full time on this and I'm almost there. I'm testing things right now
<tseliot> speaking of which
<ripps> tseliot: http://pastebin.com/f560a2652
<tseliot> Sarvatt: compiz builds here. I had to make links to /usr/libGLU.so and libGLU.a
<ScottK> tseliot: I know you're working hard.  I don't mean to sound critical, just want to give people an idea.  As long as it's fixed today, Kubuntu Alpha 2 isn't at risk (probalby not much risk if it's tomorrow).
<tseliot> ScottK: ok
<ripps> jcristau: ^
<jcristau> ripps: that's with the debug variable set?
<jcristau> doesn't look like it's trying to load the driver
<ripps> *shrugs* this is the way it is after I upgraded from karmic
<ripps> I have kms disabled at the moment
<ripps> hmmm... after running glxinfo, a couple lines were printed that pastebinit didn't capture:
<ripps> libGL error: XF86DRIQueryDirectRenderingCapable returned false
<ripps> libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so
<ripps> libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so
<tseliot> ripps: I've just updated the system and rebooted with an ati card (r600) and compiz works fine here
<ripps> tseliot: so, wth did I do to my system?
<jcristau> what does xdriinfo say btw?
<tseliot> ripps: what's the output of "update-alternatives --display gl_conf" ?
<ripps> tseliot: http://pastebin.com/f59d0b9ea
<ripps> jcristau: Screen 0: not direct rendering capable.
<tseliot> ripps: hmm... that's correct too
<jcristau> ripps: sounds like your issue then
<tseliot> lol, I found this in the mandriva packaging scripts for nvidia: 
<tseliot> # I love OpenSource :-(
<knittl> hi, there seems to be a bug in /var/lib/dpkg/info/nvidia-common.config
<knittl> line 11 should read: if [ "${LATEST}" != "none" ]; then 
<knittl> (the quotes around ${LATEST} are missing
<ripps> okay, I removed all the modeset=0 and nomodeset stuff. And I still can't get opengl, and now it seems that KMS isn't working either. My Xorg.0.log seems to say that modesetting isn't supported. WTH! Everything was working until plymouth was installed
<ripps> hmmm.... I wonder if the libdrm-nouveau that was installed might be to blame?
<jcristau> no
<tseliot> knittl: right. Bug #505855
<ubottu> Launchpad bug 505855 in nvidia-common "/var/lib/dpkg/info/nvidia-common.config: line 11: [: too many arguments " [Undecided,New] https://launchpad.net/bugs/505855
<knittl> tseliot: i see :)
<ripps> oop, I think I found it. The xorg.0.log now says that agpgart wasn't load, but I can see with lsmod that it was.
<ripps> Okay, so it seems that after I installed plymouth the agpgart in linux-image-2.6.32-10 went to hell. I would get get a string of debug errors whenever I tried to reload my radeon module. And I it would cause my X to crash. So I tried reinstalling that kernel, and then I couldn't boot from it anymore. I managed to boot back up with 2.6.32-9, but X would crash when I boot with nomodeset, so I'm stuck with KMS at the moment.
<tseliot> jcristau: mesa seems to ignore my libgl1-mesa-dev.links
<tseliot> actually all .links files
<ScottK> Is it .links or .link?
<tseliot> .links
<superm1> tseliot, check the dh_link invokation in debian/rules
<tseliot> and the debian/rules calls dh_link -s
<superm1> perhaps it's only running on the architecture dependent packages
<superm1> what's libgl1-mesa-dev marked as in debian/control?
<tseliot> superm1: good point. That's it
<geser> superm1: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/mesa/lucid/annotate/head%3A/debian/rules if you are to lazy to grab the source package (and if it didn't got changed much since the last upload)
<jcristau> superm1: arch:any
<superm1> geser, it wasn't lazyness, it was lack of a way to bounce  through proxies where i'm at right now :)
<geser> tseliot: next step would be to set DH_VERBOSE and check if it gives you any hints
<tseliot> right
<geser> or pastebin the .links file
<tseliot> I've added dh_link -s to binary-indep
<tseliot> and I'm rebuilding
<jcristau> this doesn't make sense
<jcristau> both because libgl1-mesa-dev is arch:any, and because -s in -indep.
<tseliot> jcristau: no. Here this is all I have binary-indep: install
<jcristau> which is correct
<jcristau> mesa doesn't build any arch:all package so there's nothing to do in binary-indep
<tseliot> oh, I misread things
 * tseliot rebuilds with DH_VERBOSE
<tseliot> jcristau, geser, superm1: http://pastebin.ubuntu.com/355118/
<tseliot> so, it doesn't ignore those files
<jcristau> your .links file is all broken
<geser> tseliot: pastebin the .links file please
<tseliot> geser: http://pastebin.ubuntu.com/355121/ and http://pastebin.ubuntu.com/355123/
<jcristau> the syntax is source destination
<tseliot> debian/libgl1-mesa-dev.links  debian/libglu1-mesa-dev.links respectively
<jcristau> not destination source
<tseliot> this is what happens when I'm tired
<tseliot> thanks
<Sarvatt> adding links for libGL.so libGLU.so and libGLU.so still hasn't fixed things here, things are looking for .so.1 in /usr/lib..
<jcristau> i still don't understand why you're moving libGLU
<Sarvatt> dpkg-shlibdeps: error: couldn't find library libGLU.so.1 needed by debian/compiz-plugins/usr/lib/compiz/libblur.so (ELF format: 'elf64-x86-64'; RPATH: '').
<Sarvatt> same problem with kdebase-workspace
<tseliot> Sarvatt: at run-time, after using ldconfig, things should work as it will find .so.1 in /usrlib/mesa
<Sarvatt> ah didn't run ldconfig, whoops
<tseliot> at build-time it should get both libGLU.so and libGLU.a
<tseliot> in /usr/lib
<tseliot> and compiz will build
<tseliot> (I tried creating the links manually)
<tseliot> and I'm now rebuilding mesa
<tseliot> jcristau: I think it was tjaalton who did that
<jcristau> that's not an answer
<tseliot> :-)
<Sarvatt> yeah not sure he meant to commit the libGLU changes
<Sarvatt> http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=commit;h=eebc3ccbcf22ac57ee3c34fe9af0bae46e0aeb85
<Sarvatt> commit message saying its fixing the swx11 targets
<jcristau> timo tried to work around stuff that was previously broken, afaict
<tseliot> right but I didn't change that
<tseliot> not that I'm blaming him (just to be clear)
<tseliot> he passed this configuration flag: --libdir=/usr/lib/mesa
 * tseliot tries mesa again
<bjsnider> ok, i'm curious. why is alternatives better than diversions?
<tseliot> bjsnider: there's a blueprint about that
<bjsnider> i'd like to read it
<Sarvatt> manually creating libGL.so libGL.so.1 libGLU.a libGLU.so and libGLU.so.1 symlinks in /usr/lib *works*
<tseliot> bjsnider: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-proprietary-drivers
<bjsnider> thanks
<tseliot> Sarvatt: ok, so this should fix the problem for us and for the kubuntu guys
<tseliot> I have modified the nvidia drivers accordingly
<tseliot> I only need to see if X builds with the new mesa now
<Sarvatt> i haven't used your mesa with all the further moving the alternatives to it yet.. using 7.7.0-0ubuntu3 with the symlinks to test things
<slangasek> tseliot: where can I pull your current version from to look at and test against the kde failures?
<jcristau> Sarvatt: aiui there won't be a libGLU.so.1 or libGL.so.1 in /usr/lib
<tseliot> slangasek: mesa: http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=shortlog;h=refs/heads/ubuntu
<Sarvatt> without the .so.1 symlinks in /usr/lib dpkg-shlibdeps fails
<slangasek> eh, how do I turn that into something I can download from?
<jcristau> slangasek: git clone git://git.debian.org/git/pkg-xorg/lib/mesa; cd mesa; git checkout origin/ubuntu
<slangasek> thanks
<tseliot> Sarvatt: what fails? compiz?
<tseliot> the .so files should suffice and ldconfig should do the rest
<tseliot> i.e. ldconfig would know where to find .so.1
<bryyce> alternatives is looking like it's being fun.  how's it looking?
<Sarvatt> do you have a .so.1 after your newest one tseliot?
<Sarvatt> all i know is i cant build things right without the .so.1's being in /usr/lib
<jcristau> bryyce: it's looking like it doesn't work
<tseliot> Sarvatt: .so.1 is in /usr/lib/mesa
<tseliot> bryyce: there have a been a few problems
<Sarvatt> yeah thats not enough here
<bryyce> mm
<tseliot> but I've been working on it
<bryyce> ok, we gonna back it out for a2 or push through the issues?
<Sarvatt> things cant build against it, and its holding up KDE and some other things like openoffice by proxy right before alpha, real fun :D
<tseliot> bryyce: I would like to fix things today
<bryyce> tseliot, what time of day is it for you?
<tseliot> bryyce: 20:17
<jcristau> dpkg-shlibdeps won't look in /usr/lib/mesa i think
<bryyce> hm
<tseliot> bryyce: there's still time until 1:30 ;)
<jcristau> so you can link against mesa, but then you can't build packages
<bryyce> :-)
<Sarvatt> yeah thats why I was saying adding -l/usr/lib/mesa to every packaging needing to build against mesa wouldn't be fun, but adding the .so.1 symlink works fine
<slangasek> why not include /usr/lib/libGL.so.1 as a symlink in the -dev package?
<slangasek> ah, perahps Sarvatt is already recommending this
<tseliot> slangasek: because that would break the alternatives system
<Sarvatt> <tseliot> Sarvatt: .so.1 is in /usr/lib/mesa
<Sarvatt> <tseliot> bryyce: there have a been a few problems
<Sarvatt> <Sarvatt> yeah thats not enough here
<Sarvatt> <bryyce> mm
<Sarvatt> <tseliot> but I've been working on it
<Sarvatt> <bryyce> ok, we gonna back it out for a2 or push through the issues?
<Sarvatt> <Sarvatt> things cant build against it, and its holding up KDE and some other things like openoffice by proxy right before alpha, real fun :D
<Sarvatt> <tseliot> bryyce: I would like to fix things today
<Sarvatt> <bryyce> tseliot, what time of day is it for you?
<Sarvatt> <tseliot> bryyce: 20:17
<bryyce> Sarvatt, heh
<Sarvatt> <jcristau> dpkg-shlibdeps won't look in /usr/lib/mesa i think
<Sarvatt> <bryyce> hm
<Sarvatt> <tseliot> bryyce: there's still time until 1:30 ;)
<Sarvatt> <jcristau> so you can link against mesa, but then you can't build packages
<Sarvatt> <bryyce> :-)
<slangasek> tseliot: you're providing /usr/lib/libGL.so.1 as an alternative?
<Sarvatt> <Sarvatt> yeah thats why I was saying adding -l/usr/lib/mesa to every packaging needing to build against mesa wouldn't be fun, but adding the .so.1 symlink works fine
<Sarvatt> oh crap I'm sorry
<Sarvatt> meant to paste one line but I highlighted the text in here, sorry about htat!
<bryyce> tseliot, anyway just remember to also allocate some contingency time for backing out the changes if you decide to take that route
<tseliot> slangasek: no but the directory that contains libGL* is provided as an alternative
<jcristau> slangasek: he's messing with ld.so.conf
<jcristau> iirc
<slangasek> arrrrrgh
<jcristau> yes
<tseliot> ld.so.conf.d/GL.conf
<slangasek> can we just revert this whole thing? :P
<tseliot> which is an alternative
<tseliot> as planned
<tseliot> well, a master link
<tseliot> compiz built correctly
<tseliot> building X
<tseliot> Sarvatt: what is it that fails? kdebase-runtime?
 * tseliot 's X built correctly too
<jcristau> X doesn't link against libGL
<tseliot> Xephyr had some problems
<bryyce> I would imagine it's kde's compositing stuff that is depending on it.  is compiz broken as well?
<jcristau> bryyce: any package depending on libGL...
<tseliot> building compiz was broken
<bryyce> ok
<tseliot> ScottK: what kde package was it that failed?
<slangasek> tseliot: frankly, I don't care if shipping /usr/lib/libGL.so.1 as a symlink in the -dev package breaks the alternatives handling; anything linking against /usr/lib/libGL.so should resolve symbols against the .so.1 from the *corresponding* libGL implementation, regardless of how the alternative is set
<bryyce> tseliot, kwin maybe?
<ScottK> https://launchpad.net/ubuntu/+source/kdebase-workspace/4:4.3.90-0ubuntu1/+build/1436135
<ScottK> bryyce: kwin is in kdebase-workspace, so good call.
<tjaalton> howdy
<bryyce> heya tjaalton
<slangasek> and if having one of the (conflicting) -dev packages installed means that the alternative doesn't work as intended at runtime, well, this just goes to show that the binary libGLs suck
<tjaalton> so I didn't have DNS yesterday, would've done something about the mess, and today has been busy otherwise
<tseliot> ScottK: ok, I'll try to build it here
<tjaalton> am I right that it's not necessary to use --libdir at all, and just let libGL.so point to /usr/lib/mesa/libGL.so.1 ?
<jcristau> tjaalton: dpkg-shlibdeps still doesn't know to look in usr/lib/mesa. so you need a libGL.so.1 in /usr/lib somehow
<slangasek> tjaalton: no, because unless you're using rpath (which defeats the purpose of an alternative), dpkg-shlibdeps will fail to locate the runtime dependency at the end of the package build and you'll get misbuilt packages
<tjaalton> jcristau: hmm right, and that would then break things
<tjaalton> oh well :)
<slangasek> (or a FTBFS - depending on how the package has configured dpkg-shlibdeps)
<tjaalton> tseliot: btw, please use UNRELEASED in the future :)
<tjaalton> hard to track what's inside a release
<tseliot> tjaalton: right
<jcristau> echo DEBCHANGE_RELEASE_HEURISTIC=changelog >> ~/.devscripts
<tjaalton> cool, didn't know about that one
<jcristau> tjaalton: it might not break things, if you put it in the -dev package.  and it's just one more hack on top of a big pile so maybe it would work.
<tjaalton> oh yeah, -dev
<jcristau> not sure you end up with something better than what you had before, but hey.
<slangasek> are the ld.so.conf.d entries prepended or appended to the path?
<slangasek> if they're prepended, then having the symlink in the -dev package should break nothing
<slangasek> if they're appended, then it breaks one specific thing (runtime resolution when the -dev package is installed, which is not really worse than before)
<tseliot> slangasek: prepended AFAIK
<slangasek> then indeed, nothing should break by adding those symlinks
<jcristau> if they were prepended, then your first hack of keeping mesa's libGL.so.1 in /usr/lib would have worked, no?
<tseliot> slangasek: thanks to the not-abi tag, which is only in the mesa libGL and not in Nvidia's, mesa's version always wins
<slangasek> ah
<tseliot> note-abi
<slangasek> well, it will only win if you have the -dev package installed
<slangasek> (did you rule out editing the binary .sos to add a note-abi?)
<tseliot> slangasek: right, so it's an acceptable compromise for now
<tseliot> slangasek: for nvidia? I'm not sure if the license allows that
 * slangasek nods
<jcristau> i suppose you could build without glx-tls
<slangasek> tseliot: however, the license allows linking to it... so you could create a shim that does nothing except set the note, claim the name, and link to the real implementation (with rpath)
<tjaalton> but then someone would scream it kills performance
<tjaalton> +the
<tseliot> jcristau: yes, I could. Which what (by chance) allows the system to work well on Mandriva
<tseliot> ;)
<slangasek> however, please don't attempt the above shim for alpha-2, we're already rather in jeopardy at this point
<tseliot> slangasek: no, of course not. I would lack the energy for that
 * slangasek grins
<tseliot> let's see how the build goes here. If it fails then we'll add that link in the -dev package and upload the rest
<tseliot> the kdebase-workspace build, that is
<geser> is build-depending on libgl1-mesa-dev (with the next upload of mesa) enough to run (freshly built) binaries linked to libGL? or does it still need the ld.conf.d file (and therefore X or did it move)?
<tseliot> geser: no, they ld.so.conf file will be in mesa now. Which makes more sense
<geser> good
<tseliot> hmm... it looks like it's building kwin now
<jcristau> you won't get a failure until the very end of the package build
<tseliot> right, the shlibdeps
<geser> if you want an other test-case: try if 'mutter' builds now
<tseliot> ah, ok
<tseliot> geser: does it take long to build mutter?
<tjaalton> afk, studying ->
<jcristau> one thing to check might be whether your Xephyr build gets a rpath
<tseliot> geser: never mind. The package was built correctly :-)
<slangasek> kdebase did?
<tseliot> slangasek: no, mutter. kdebase is still building
<ScottK> kdebase-workspace, right?
<ScottK> kdebase is a different package.
<tseliot> right
 * slangasek nods
<tseliot> kdebase-workspace-4.3.90
<slangasek> tseliot: does the resulting mutter binary have a dependency on libgl1-mesa-glx?
<tseliot> slangasek: yes, libgl1-mesa-glx | libgl1
<slangasek> ok
<tseliot> and it was not hardcoded in the control file
<ScottK> Conveniently, amd64 buildd's just got caught up.
<tseliot> oh, and I didn't switch to the mesa alternative, therefore knowledge it has about where libGL* is is taken from the symlinks
<tseliot> (in /usr/lib)
<tseliot> I'll rebuild mutter after switching to another alternative, just to be sure
<jcristau> mutter uses pkg-config --libs clutter-1.0, or something like that
<jcristau> and clutter-1.0.pc requires gl
<jcristau> which would give it -L/usr/lib/mesa -lGL
<jcristau> not sure what libtool does there, but i wouldn't rule out a rpath
<slangasek> mm, ys
<tseliot> oh
<jcristau> (which would also explain why Xephyr built fine)
<slangasek> and if you've got rpath, then your alternatives will fail to be effective, too
<tseliot> it shouldn't be the same for kdebase-workspace though, right?
<slangasek> I don't know
<tseliot> ScottK: do you know the answer to my question?
<ScottK> I don't.
<tseliot> ok
<tseliot> jcristau: so you're saying that the rpath would make shlibdeps just work?
<jcristau> yes
<tseliot> ok
<slangasek> "work"
<slangasek> well, it would make dpkg-shlibdeps work
<jcristau> and misbuild your package
<slangasek> and then it would entirely bypass your alternatives implementation
<slangasek> tseliot: you can check this by unpacking the libmutter0 binary and running 'objdump -p usr/lib/libmutter-private.so.0 | grep RPATH'
<jcristau> or run lintian maybe
<tseliot> slangasek: the exit status is 1
<tseliot> so, no
<tseliot> it's doing shlibdeps in kdebase-workspace now
<jcristau> oh.  i was wrong.  dpkg-shlibdeps does parse ld.so.conf.
<tseliot> good
<tseliot> ScottK, slangasek, jcristau: kdebase-workspace built :-)
<ScottK> \o/
<slangasek> with a proper dep / no rpath?
<tseliot> slangasek: what binary should I check?
<slangasek> kdebase-workspace-bin
<tseliot> slangasek: ok, I meant what library?
<slangasek> tseliot: I haven't looked; I think jcristau is right that lintian will warn about rpath, though
<tseliot> ok, I'll run lintian on that package then
<tseliot> http://pastebin.ubuntu.com/355155/
<tseliot> slangasek, jcristau ^^
<jcristau> heh
<tseliot> I don't see any references to mesa though
<slangasek> er... yes, because it aborted before it could run any binary checks :/
<slangasek> hmm - or something
<slangasek> not sure
<ScottK> The build failure before was in shlibdebs for kwin, so I'd suggest using that in any case.
<ScottK> Which is actually kde-window-manager
<tseliot> ok, I've tested the alternative and it's correctly installed.
<ScottK> Normally it depends libgl1-mesa-glx | libgl1
<tseliot> ScottK: are you suggesting that I upload mesa now?
<ScottK> tseliot: No, I'm suggesting that instead of checking kdebase-workspace-bin, you should check kde-window-manager
<tseliot> that's why I was asking
<tseliot> ok
<tseliot> s/why/what/
<tseliot> http://pastebin.ubuntu.com/355163/
<tseliot> ScottK, slangasek, jcristau
<tseliot> nothing new
<tseliot> let me build nvidia now just to see if alternatives work well
<jcristau> well if your lintian is broken, that won't help..
<tseliot> it's the one in lucid
<slangasek> tseliot: objdump -p usr/bin/kwin |grep RPATH should be enough to confirm
<slangasek> if that checks out, I think you should go ahead with a mesa upload
<tseliot> alright, let me try
<tseliot> slangasek: nothing
<tseliot> ok
 * tseliot is uploading mesa
<tseliot> slangasek: ok, uploaded. I'll wait for that to build (please rescore its build) before I upload X and the nvidia packages again
<slangasek> I don't have rescore powers
<tseliot> ScottK: ^^
<ScottK> tseliot: Thanks.
<tseliot> slangasek: who does?
<ScottK> NCommander or lamont are your best bets
<tseliot> ok
 * ScottK is heading out for a while.  Please hit retry on kdebase-workspace when mesa is published.
<tseliot> ok
<tseliot> bryyce: just FYI ^^
 * tseliot hasn't had dinner yet
<bryyce> tseliot, go eat ;-)
<tseliot> ok
<tseliot> ok, mesa built
<BUGabundo> hi guys
<BUGabundo> I updated to last stuff in +1
<BUGabundo> then tried to used jockey to install nvidia blob
<BUGabundo> and replace -current
<BUGabundo> and got this 
<BUGabundo> $ pastebinit  /var/log/jockey.log http://paste.ubuntu.com/355196/
<BUGabundo> any help is apreciated
<tseliot> jockey won't work with nvidia
<tseliot> not yet, at least
<sebner> tseliot: I installed nvidia updates from the official repo ... is this supposed to not break my current working 3D (from your repo)?
<tseliot> sebner: I have just uploaded new nvidia packages which work with the new mesa and X
<tseliot> I think you should wait
<BUGabundo> tseliot: thanks
<sebner> tseliot: to your repo? 
<BUGabundo> so what should I do?
<BUGabundo> wait? 
<BUGabundo> remove -current
<tseliot> sebner: to lucid
<BUGabundo> and manually install the new one?
<sebner> tseliot: pfff, installed long ago :P
<tseliot> BUGabundo: install -current then type sudo nvidia-xconfig
<BUGabundo> I already have -current
<BUGabundo> from your PPA I think
<tseliot> sebner: no, I uploaded that a minute ago
<sebner> ohhhhhhhh
<tseliot> and it hasn't built yet
<sebner> hola hola hola
<sebner> tseliot: ok, no bed for me now then :D
<tseliot> BUGabundo: ok, then just use nvidia-xconfig. As I said, it's better if you don't update your system today
<BUGabundo> done
<yofel> tseliot: was the renaming of the kernel module intentional or not? just curious
<tseliot> yofel: yep
<yofel> ok
<tseliot> now they can all be installed at the same time
<tseliot> -current, -173 and -96
<yofel> :D
<yofel> niiiice 
<tseliot> jcristau, slangasek: it looks like X failed to build:
<tseliot> dpkg-shlibdeps: error: couldn't find library libGL.so.1 needed by debian/xserver-xephyr/usr/bin/Xephyr (ELF format: 'elf32-i386'; RPATH: ''). Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file.
<tseliot> http://launchpadlibrarian.net/37745022/buildlog_ubuntu-lucid-i386.xorg-server_2:1.7.3.902-1ubuntu4_FAILEDTOBUILD.txt.gz
<tseliot> oh, it's not using the new mesa
<tseliot> from .../libgl1-mesa-glx_7.7-0ubuntu3_i386.deb
<geser> the build started 4 min too early and missed the -0ubuntu4 publication: https://edge.launchpad.net/ubuntu/lucid/i386/libgl1-mesa-glx
<tseliot> yes, right
<slangasek> so a retry is all that's needed, yes?
<tseliot> yep
<chrisccoulson> does anyone know if calling XResetScreenSaver() should reset the IDLETIME counter used in GNOME for activating the screensaver and setting session idle-ness?
<chrisccoulson> it seems like it does in karmic, but doesn't in lucid now
<jcristau> chrisccoulson: http://bugs.freedesktop.org/show_bug.cgi?id=25855
<ubottu> Freedesktop bug 25855 in Server/general "Screensaver not disabled because of a XResetScreenSaver() regression" [Normal,New]
<chrisccoulson> i'm assuming this is because there is no update of lastDeviceEventTime in dixSaveScreens
<chrisccoulson> ah
<chrisccoulson> jcristau - thanks :)
<jcristau> patch posted on xorg-devel, somebody needs to rewrite the patch according to review
<chrisccoulson> jcristau - awesome. so, it is meant to work, at least
<jcristau> apparently
<jbarnes> superm1: ping
 * geser congrats tseliot on fixing mesa
 * sebner ^5 geser :D
<bryyce> geser, you can confirm the fix?
<geser> as far as building a package is concerned: yes, I could now successfully build "mutter" in my lucid pbuilder again (which failed with the previous mesa 7.7 uploads)
<sebner> bryyce: gnome-shell builds again too 
<tseliot> geser: thanks
<tseliot> bryyce: kdemultimedia built on amd64 with the new mesa and the old X
<bryyce> great
<bryyce> tseliot, any remaining issues to be tracked?
<tseliot> bryyce: we're waiting for kdebase-workspace
<tseliot> but it should build
<chrisccoulson> jcristau - it seems that issue with XResetScreenSaver also exists in karmic too :(
<jcristau> yes probably
<chrisccoulson> do you know if any sane way to reset the IDLETIME counter
<chrisccoulson> s/if/of
<jcristau> from a client?
<chrisccoulson> jcristau - yes
<tseliot> bryyce: and alternatives should work too (they already did, apart from the errors with builds). I didn't have the time to test and upload jockey but that will have to wait
<bryyce> ok
<bryyce> tseliot, can you let pitti know the status on the jockey stuff?
<jcristau> chrisccoulson: maybe XSyncSetCounter()?  i'm not familiar with that part of X though
<bryyce> tseliot, also at some point (maybe tomorrow) please send a status summary to the ubuntu-x@ list 
<tseliot> bryyce: my changes are already in his branch but I couldn't build jockey because of some old dependency problems with kde
<tseliot> bryyce: sure, I'll write that email tomorrow
<chrisccoulson> jcristau - i tried that a while ago, and it generated a BadAccess AFAIR
<jcristau> damn, ok
<tseliot> slangasek: there are a few things that we'll have to add to the release notes for alpha 2, most of which should be in my email ^^
<chrisccoulson> jcristau - i've noticed that some applications seem to fake keypresses using XTEST
<chrisccoulson> but this has other issues :-/
 * tseliot -> off for a bit
<jcristau> get XResetScreenSaver fixed, then? :)
<chrisccoulson> jcristau - i think that's the best way
<chrisccoulson> bryyce - would there be any chance of having http://bugs.freedesktop.org/show_bug.cgi?id=25855 fixed in a karmic SRU?
<ubottu> Freedesktop bug 25855 in Server/general "Screensaver not disabled because of a XResetScreenSaver() regression" [Normal,New]
<slangasek> tseliot: can you give me a rough summary of the sort of thing you're looking at release noting?
<bryyce> chrisccoulson, get a bug report set up in launchpad and assign to me and I'll take a look when I get a chance (sooner if you can include a debdiff and/or put in the SRU formatting)
<chrisccoulson> bryyce - thanks, i will look at that
#ubuntu-x 2010-01-12
<tseliot> slangasek: sure, I'll do it tomorrow in the morning
<slangasek> ok
<superm1> jbarnes, pong
<dhillon-v10> hi all, I am looking at some bugs in the xserver-xorg-video-intel section, and since I have similar drivers I can triage some bugs there, and set their importance, can anyone add me to the team so I can change the importance
<bryyce> dhillon-v10, don't worry about setting the importance
<dhillon-v10> bryyce, oh okay then :) that makes things easier for me
<bryyce> dhillon-v10, help is always appreciated with the bug triaging.  I find I have a lot less time for doing it myself these days but it still needs done
<dhillon-v10> bryyce, can you have a look at this: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/498287 should I ask the user to test against the latest version (2.6.3)
<ubottu> Launchpad bug 498287 in xserver-xorg-video-intel "session active, not inhibited, screen idle" [Undecided,New]
<bryyce> dhillon-v10, because a lot of functionality that used to be in xserver-xorg-video-intel has moved to the kernel, it is often not sufficient to just have them test a newer version of that package
<dhillon-v10> bryyce, so what do you advice in this case
<bryyce> I mean, it couldn't hurt, but it's not likely to give them a fix
<dhillon-v10> bryyce, okay :)
<bryyce> dhillon-v10, well, first the patches he mentions are already in ubuntu.  So if they didn't fix it for him, then it's something else
<bryyce> second, often these bugs are not due to something in the intel driver but due to something elsewhere in the system (the kernel maybe, or gnome-power-manager)
<dhillon-v10> bryyce, I think it could be the kernel, because like you said a lot of functionality moved into the kernel so a commit must have broken something
<bryyce> it would be interesting to know if it is a regression, and if so, if they can identify which piece of software solves it if downgraded
<bryyce> so like booting to an older kernel if they have any in /boot might be interesting.
<dhillon-v10> bryyce, ahh it could be a regression introduced by a newer kernel nice :) 
<dhillon-v10> bryyce, is this comment enough atm: This could be a regression caused by the kernel so can you try to boot into an older kernel (if you have one present on your system) and see if that solves your problem. Thanks.
<bryyce> dhillon-v10, yes; if it does solve it then reassign to linux
<dhillon-v10> bryyce, okay
<hyperair> can someone help me debug an issue regarding my brightness keys?
<BUGabundo_work> morning
<bryyce> morning
<BUGabundo_work> wb sebner 
<BUGabundo_work> wb seb128 
<hyperair> is there some kind of libgl breakage?
<hyperair> http://pastebin.com/m789c79a6 <-- some guy with a 32-bit mesa-utils on a 64-bit comp
<tseliot> hyperair: reinstalling xserver-xorg-core (or simply installing ubuntu5) should do it
<tjaalton> ia32-libs isn't updated
<tseliot> oh, I didn't read
<tseliot> yes, that's broken anyway
<hyperair> ah.
<hyperair> i see
<tseliot> it should be updated as tjaalton said and I should make sure that its libGL* libraries are put in /usr/lib32/mesa
<hyperair> i think i provided a patch for that sometime back
<hyperair> a very long time back.
<tseliot> what kind of patch?
<hyperair> one to the upstream, one as a debdiff
<hyperair> the upstream went in, the debdiff...
<hyperair> kinda died a natural death
<tseliot> hyperair: ok but what did the patch do?
<hyperair> changed a configure flag
<hyperair> the upstream one added a configure flag that changed the DRI drivers' location
<hyperair> the debdiff changed the configure flag so that it would install the DRI drivers' location to a place that could be symlinked to /usr/lib32/dri
<hyperair> oh wait
<hyperair> this is /usr/lib32/dri not /usr/lib32/mesa
<hyperair> bug #248392
<ubottu> Launchpad bug 248392 in ia32-libs "32bit libgl search for dri at wrong place on 64bit system" [Low,Confirmed] https://launchpad.net/bugs/248392
<tseliot> right
<tseliot> which is why I asked ;)
<hyperair> heh
<hyperair> wait, why are stuff being installed to /usr/lib32/mesa?
<hyperair> not /usr/lib32?
<tseliot> hyperair: because of the new alternatives system. Don't worry, ldconfig will know where to find those libraries
<hyperair> ah
<hyperair> i see
<hyperair> not using rpath i suppose?
<hyperair> i remember the ruling about rpath was dropped in one of the more recent debian policies
<tseliot> yes, without rpath
<jcristau> are you sure the 32bit ld.so can find stuff in /usr/lib32/mesa?
<jcristau> when ld.so.conf only says usr/lib/mesa
<tseliot> sure, it's patched to work with 32bit libraries
<tseliot> jcristau: have a look at my changes to mesa (debian/rules)
<jcristau> ok
<siretart`> I noticed that with kms, a simple 'xrandr --query' now auto-enables the external monitor on my laptop. is this a known issue?
<tseliot> hyperair: can you file a bug report about that, please?
<tseliot> hyperair: feel free to assign it to me
<hyperair> tseliot: what bug report?
<tseliot> hyperair: about the fact that ia32-libs should install libGL* in /usr/lib32/mesa
<hyperair> tseliot: i'm not on lucid and am not really sure what's going on at the moment really =\
<tseliot> hyperair: ah, ok. Never mind
<hyperair> sorry
<tseliot> np
<Sarvatt> anyone know whats up with libxcb? 2 sync requests closed a fixed for the 1.5 version but we're still at 1.4-1
<tjaalton> it's on binary NEw queue
<tjaalton> most likely
<Sarvatt> thats what i thought because of the libxcb-dri2-0 but i never even saw it on https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=0&queue_text=
<Sarvatt> not sure if thats even the place to look though
 * BUGabundo_work waves to Sarvatt 
<geser> Sarvatt: grab an archive admin and let him look why the sync fails
<afv> hi
<afv> i'm getting the message "program: error while loading shared libraries: libGLU.so.1: cannot open shared object file: No such file or directory" when trying to run some apps
<afv> locate libGLU: /usr/lib/mesa/libGLU.so.1 and /usr/lib/mesa/libGLU.so.1.3.070700
<afv> hmm.. should i symlink that do /usr/lib/libGLU.so.1?
<tseliot> afv: please make sure that your system has the latest mesa package
<afv> 7.7-0ubuntu4
<afv> i'm not using the edgers ppa
<tseliot> afv: maybe try to reinstall it and do sudo ldconfig
<afv> nop.. :s
<tseliot> ?
<afv> same problem
<afv> dpkg --get-selections | grep mesa: libgl1-mesa-dri, libgl1-mesa-glx, libglu1-mesa, mesa-utils
<afv> do i need something else than this?
<tseliot> what does this command say? ldconfig -p | grep GL
<afv> http://pastebin.com/d773782b6
<tseliot> afv: can you file a bug report about it and assign it to me, please?
<tseliot> as a quick fix a link to /usr/lib/mesa/libGLU.so.1 in /usr/lib/ should work
<tjaalton> yeah the libdir change should be reverted, and install libGLU in /usr/lib again
 * tseliot nods
<afv> thanks. report it here? https://launchpad.net/ubuntu/+source/mesa/+filebug
<tjaalton> though it changes the pkgconfig files then, but I don't know if those are used anyway
<tseliot> afv: yes, please
<afv> ok. no problem
<tseliot> tjaalton: I'll take care of that. After alpha 2, that is
<tseliot> afv: BTW what program gave you that problem?
<tseliot> (just curious)
<afv> blender, mixxx, yofrankie-bge
<tseliot> ok
<tseliot> just to have some test case
<tseliot> cases
<tjaalton> tseliot: ok
<BUGabundo_work> tseliot: is nvidia better today? can i upgrade, or should i still hold on on it ?
<tseliot> BUGabundo_work: sure, it should be safe to upgrade. Note: after the upgrade (just to be safe) reinstall xserver-xorg-core
<BUGabundo_work> ok
<BUGabundo_work> thanks
<tseliot> np
<afv> tseliot, https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/506547
<ubottu> Launchpad bug 506547 in mesa "Some GL apps won't run: libGLU.so.1: No such file or directory" [Undecided,Confirmed]
<tseliot> afv: thanks a lot
<afv> no problem. :)
<Sarvatt> hmm those work fine here afv
<Sarvatt> are you on amd64? using the nvidia blob maybe?
<afv> using the nvidia blob
<afv> 32bits
<afv> they work fine after a ln -s /usr/lib/mesa/libGLU.so.1 /usr/lib
<Sarvatt> i think it might be blob specific, not getting any errors on any of my machines not using the blob
<tseliot> Sarvatt: that makes sense because the library is in the directory with the stuff installed by mesa
<tseliot> but when you switch to nvidia
<tseliot> ldconfig point to the directory with the nvidia libraries
<afv> hmm.. what's your ls -l /usr/lib/libGLU.so.1 output?
<tseliot> points
<Sarvatt> ah yeah, so moving libGLU back would fix it there at least
<tseliot> I doubt he has any
 * tseliot nods
<afv> maybe he has one that is there since an older update? :s
<afv> i did an ubuntu fresh install yesterday (didn't fresh install since karmic alpha 2.. May last year :p) and maybe that's why i didn't have the file..
<Sarvatt> btw we were going to add the drisearchpatch configure flag to mesa now that we're on 7.7 to fix ia32-libs? been fixing it in edgers for a few months now
<Sarvatt>         --with-dri-searchpath=/usr/lib/dri:/usr/lib/dri/$(DEB_HOST_GNU_TYPE) \
<Sarvatt> (adding that to confflags-dri after         --with-dri-driverdir=/usr/lib/dri \
<jcristau> that would need a server change too?
<tseliot> for bug #248392 ?
<ubottu> Launchpad bug 248392 in ia32-libs "32bit libgl search for dri at wrong place on 64bit system" [Low,Confirmed] https://launchpad.net/bugs/248392
<Sarvatt> yeah thats the bug, dont think it needs any server change
<Sarvatt> http://old.nabble.com/-Bug-24766--New:-32-bit-libGL.so-searches-for-DRI-modules-in--usr-lib-dri-instead-of--usr-lib32-dri-td26082908.html
<tseliot> ok, it seems a good candidate for alpha 3
<tseliot> Sarvatt: with that configuration flag, do we still need the symlinks in ia32-libs?
<tseliot> http://launchpadlibrarian.net/34815911/debdiff
<jcristau> slangasek: so ia32-libs is still not going away? :(
<Sarvatt> i dont think so.. hyperair?
<tseliot> I guess it's either one way or the other
<hyperair> Sarvatt: ?
<tseliot> jcristau: how is it going away?
<Sarvatt> are the symlinks needed in ia32-libs if we add this --with-dri-searchpath you added to mesa upstream?
<hyperair> yes, they're needed.
<hyperair> i think.
<hyperair> well i could perhaps do --with-dri-searchpath=/usr/lib/dri:/usr/lib32/dri
<jcristau> tseliot: how?  by someone removing it from the archive
<tseliot> jcristau: interesting implementation ;)
<hyperair> Sarvatt: coem to think of it maybe --with-dri-driverdir=/usr/lib32/dri might be the right solution?
<tseliot> jcristau: I was asking what the alternative solution was
<jcristau> tseliot: same as 5 years ago.  multiarch.
<tseliot> jcristau: no doubt on that. Are we going to get that in dpkg?
<jcristau> why do you ask me?
<tjaalton> it's being worked on, but it was deferred to lucid+1
<tseliot> aah, ok
<hyperair> and when lucid+1 arrives, it'll be deferreed to lucid+2
<tseliot> it's good to read that they're working on it :-)
<tjaalton> mvo knows how hard it is to implement ;)
<hyperair> and so on.
<jcristau> it was deferred to etch+1 :)
<tseliot> tjaalton: I bet he does ;)
<jcristau> or was it sarge+1
<tjaalton> jcristau: heh
<tseliot> heh
<Sarvatt> oops, need glproto 2.4.11 and dri2proto 2.2 already for mesa master now
<hyperair> Sarvatt: ah right i just remembered. the symlinks are required, because the mesa things aren't rebuilt, and we needed some way to standardize the search path even for x64 builds.
<tseliot> hyperair: good to know. I would like to fix this after alpha 2
 * tseliot > dinner
<hyperair> cool
<Sarvatt> oh wow, moving the old 40-xserver-xorg-input-wacom.rules down below 65-xorg-evdev.rules was all that was needed to get it working? wasted all that time without knowing how things work and it was so simple :D
<ripps> Okay, I think it's final. Plymouth was responsible from keeping my 2.6.32-10 kernel from booting
 * hyperair will wait at least until then before upgrading
<hyperair> plymouth?
<jcristau> Sarvatt: i think it was all ron was missing for a while.  so he was (unknowingly) getting evdev and thought it didn't work quite well enough :)
<ripps> I also know that something is wrong with the radeon drivers w/ dri1. Because my X keeps crashing when I try to boot with nomodeset. I can get into xterm and I can see through glxinfo that the right mesa glx is loaded, but once I try to boot into Gnome or Failsafe Gnome, black bars appear and suddenly X restarts.
<Sarvatt> hmm [ 3999.496717] (II) intel(0): No memory allocations [ 3999.496901] (EE) intel(0): Couldn't create pixmap for fbcon [ 3074.601783] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id on the latest daily kernel after resume
<Duke`> :/
<tseliot> Sarvatt: maybe plymouth triggered that
<tseliot> i.e. its drm plugin for intel
<hyperair> we're using plymouth in lucid now?
<BUGabundo> evening
<BUGabundo> looks like nvidia aint still ready :(
<BUGabundo> can't activate it via jokey
<hyperair> nvidia's never ready before the release candidates anyway >_>
<hyperair> those slowcoaches
 * hyperair sighs
<BUGabundo> $ pastebinit /var/log/jockey.log
<BUGabundo> http://paste.ubuntu.com/355687/
<hyperair> it probably wouldn't build
<hyperair> speaking from past bad experiences with nvidia's driver, but then again mine's the 96xx legacy one
<BUGabundo> I asked tseliot before coming home if it was fine
<BUGabundo> he said so
 * hyperair shrugs
<hyperair> anyway, it looks like you'er missing the kernel module
<hyperair> try poking dkms
<BUGabundo> how?
<hyperair> umm
<hyperair> not sure..
<hyperair> dpkg-reconfigure nvidia-<whichdriver>-kernel-source perhaps?
<BUGabundo> lets try
<BUGabundo> no such package
<hyperair> huh
<hyperair> you sure?
<BUGabundo> $ sudo dpkg-reconfigure nvidia-
<BUGabundo> nvidia-173-modaliases      nvidia-185-modaliases      nvidia-common              nvidia-current-modaliases  nvidia-settings
<BUGabundo> nvidia-185-libvdpau        nvidia-96-modaliases       nvidia-current             nvidia-glx-185             
<hyperair> oho weird.
<BUGabundo> $ dpkg -l | grep nvidia | pastebinit  http://paste.ubuntu.com/355696/
<hyperair> nvidia-glx-185 depends on nvidia-185-kernel-source
<hyperair> er
<BUGabundo> there's no such thing in my apt db
<hyperair> you don't even have nvidia-glx-185.
<hyperair> okay
<hyperair> try installing nvidia-glx-185?
<BUGabundo> lucid, right?
<hyperair> er
<hyperair> actually i haven't done this for ages so i don't even remember how the process is supposed to go
<hyperair> maybe you should just wait until someone moer familiar turns up =D
<BUGabundo> it changed a lot
<hyperair> since karmic?
<BUGabundo> yep
<hyperair> =x
<bjsnider> BUGabundo, from tseliot: Jockey is not ready yet (because of a broken dependency on kdebindings).
<BUGabundo> BAH
<BUGabundo> bjsnider: so what's the manual approch?
<bjsnider> the command is in the rues file
<bjsnider> i don't have access to it at the moment
<bjsnider> everything but glx should be working though
<bjsnider> bug 494166
<ubottu> Launchpad bug 494166 in nvidia-graphics-drivers-180 "[lucid] nvidia-glx can't work with new xorg 7.5" [Medium,In progress] https://launchpad.net/bugs/494166
<bjsnider> there might be info in there about it
<slangasek> jcristau: I don't have time to work on multiarch this cycle; braindmg said he was going to work on the deep structure changes needed in dpkg, but I haven't seen any movement there lately (and haven't had time to check either)
<jcristau> ok :/
<maxb> Does anyone know if there's a bug filed for the current X doesn't work at all on Intel GPU woes in lucid?
<RAOF> I don't know one offhand.  Also, my Intel X works fine; I've clearly dodged the bad upgrade.
#ubuntu-x 2010-01-13
<vish> aw... i can switch user or get into a guest session :( > Bug 506510
<ubottu> Bug 506510 on http://launchpad.net/bugs/506510 is private
<vish> cant*
<tseliot> bdmurray: I can't find the button to make this report ^^ public
<tseliot> or ara ^^ ?
<ara> tseliot, I'll review it and make it public
<tseliot> ara: thanks
<ara> tseliot, are you part of the bugcontrol team?
<tseliot> ara: yes, I think so
<tseliot> yep
<tseliot> https://launchpad.net/~albertomilone
<ara> tseliot, then, you should see an "edit" icon right of the message "This bug is private"
<ara> tseliot, can't you see it?
<tseliot> ara: no icon to the right of that message
<ara> tseliot, weird 
<vish> tseliot: made it public
<tseliot> ara: I guess it's some bug in google chrome
<ara> tseliot, it might be :)
<ara> tseliot, I am making it public now
<tseliot> ara: thanks
<tseliot> it works well in opera
<vish> ara: just did it :)
<tseliot> so it was definitely a bug in chrome
<tseliot> sorry for the noise
<ara> tseliot, np :)
<ara> tseliot, I have to double check later (right now I am working on something else), but Xorg crashes (and doesn't come up) after resume
<tseliot> ara: with what driver? Nvidia?
<ara> tseliot, yes, Nvidia (although I've only tested it with Nvidia)
<tseliot> ara: BTW I don't know if you've experienced bug #506547. I you did, I'm working on it
<ubottu> Launchpad bug 506547 in mesa "Some GL apps won't run: libGLU.so.1: No such file or directory" [High,In progress] https://launchpad.net/bugs/506547
<ara> tseliot, no, I haven't seen that one, but I'll subscribe to it, just in case :)
<tseliot> good
<ara> tseliot, if you see any bugs you might be interested in me to test them or you feel I should know, feel free to subscribe me
<tseliot> ara: ok, thanks a lot
<ara> tseliot, thanks to you!
<tseliot> :-)
 * ara hugs tseliot
 * tseliot hugs back ara
<alkisg> This will sound totally crazy, but there's a valid reason for wanting to do it (fat client chroots on LTSP):
<alkisg> Is it possible to install ALL proprietary drivers (e.g. nvidia, ati) on a system, and for an initscript to look up the pci id and write the appropriate xorg.conf, if needed?
<alkisg> The goal is to have an image (imagine something like a live cd) that can boot on most systems and include 3d acceleration out of the box.
<alkisg> The image will be build locally on each site by a script, so I'm not concerned about redistribution problems. I'm mostly worried about dependencies / library conflicts etc.
<alkisg> Do you think that it's possible to create such an image?
<alkisg> Thanks in advance for any input.
<hyperair> don't we go without a xorg.conf nowadays?
<hyperair> install all the drivers, have a blank xorg.conf and then start the server?
<hyperair> won't that work?
<alkisg> I think that for proprietary drivers, a minimal xorg.conf is needed, that contains the driver name
<alkisg> Otherwise the open source version will be used.
<hyperair> oh isit?
<alkisg> I *think* so :)
<alkisg> Also, I'm not sure if the opengl libs will work. E.g. nvidia installs its own opengl libs versions, and then the client has an ati.
<coz_> alkisg,  I know that if y ou have intel drivers and nvidia drivers installed at the same time...the usual outcome is that the system works but the desktop is upside down and in reverse....
<hyperair> er
<hyperair> upside down?
<alkisg> coz_: right, I've seen that. I can work around it by globally disabling compiz.
<coz_> hyperair,  yep 
<coz_> alkisg,  ah cool
<hyperair> coz_: like literally?
<coz_> alkisg,  it has always interes
<coz_> interested me that issue
<coz_> hyperair,  very litterally
<coz_> literally
 * hyperair gapes
<alkisg> coz_: do you think there would be conflicts in other libraries?
<alkisg> E.g. nvidia-96 would conflict with nvidia-185?
<coz_> alkisg,   not sure   but considering the outcome of that senario  I wouldnt doubt it
<coz_> alkisg,  oh
<coz_> alkisg,  mm
<coz_> alkisg,  not sure
<hyperair> oh yeah nvidia-96 would definitely conflict
<alkisg> Ouch
<coz_> alkisg,  I think we have seen issues even with nvidia an ati drivers installed
<coz_> alkisg,  why are you thinking this by the way?
<alkisg> coz_: it's a fat client scenario
<coz_> alkisg,   oh!
<alkisg> Something like a live cd is served over the network
<hyperair> ah i see
<alkisg> So the clients only use that "cd" as a disk, but they use their own CPU/RAM etc
<coz_> alkisg,  sounds interesting...  I dont envy what you are trying to do though
<hyperair> something like nfs root?
<alkisg> hyperair, yup. 
<alkisg> coz_: it currently works FINE :D
<hyperair> heh
<coz_> alkisg,  oh  cool :)
 * alkisg loves the new LTSP fat client plugin :)
<tseliot> alkisg: do you want to install all proprietary drivers or do you want to use them all at the same time?
<alkisg> tseliot: I want each client to use only the appropriate driver
<coz_> so not installed but avilable
<alkisg> So if an initscript can somehow handle it, I'm fine!
<coz_> available
<tseliot> with the new alternatives system in lucid you'll be able to install them all. Then set the alternative to whatever you want to use, change xorg.conf and reboot
<coz_> very cool
<hyperair> tseliot: what about nvidia-96 and nvidia-185?
<tseliot> ideally this should just work (without any xorg.conf) if I fix the nvidia and fglrx autoloading patches
<tseliot> hyperair: nvidia-185?
<tseliot> nvidia-current = 190
<alkisg> (nvidia-current, I just said 185 to make a contradiction with -96...)
<hyperair> oh whoops
<hyperair> tseliot: sorry, i'm outdated.
<tseliot> nvidia-current, nvidia-173 and nvidia-96 (and soon also fglrx) can all be installed at the same time
<alkisg> Yey!!! /me hugs tseliot!!! :)
<hyperair> eh that's interesting
<tseliot> which is one of the reasons why I implemented the alternatives system ;)
<hyperair> tseliot: out of curiosity, have you seen any reports of flickering screens with nvidia-96?
<tseliot> I should document how all of this works
 * hyperair is pretty annoyed with his -96 desktop
 * alkisg has flickering screens since karmic
<alkisg> (with nvidia)
<hyperair> heh
<hyperair> i've had flickering screens since...
<tseliot> hyperair: I'm been too busy with mesa in the last few days ;)
<hyperair> jaunty?
<hyperair> intrepid?
<hyperair> tseliot: no i meant, further back.
<hyperair> tseliot: reports from a few releases back
 * hyperair kicks his desktop
<tseliot> hmm... I wouldn't know. I think I remember something about that
<hyperair> i'm this close to scrapping GNOME and nvidia on that desktop, and just going nouveau or nv and one of those minimalist WMs
<coz_> hyperair,  have you tried gnome-shell?
 * hyperair runs that desktop headless most of the time.
<hyperair> coz_: yes. and i hate it.
<coz_> hyperair,  right now it is a little resource intensive with video
<coz_> hyperair,  :)
<hyperair> coz_: that's not the point.
<hyperair> coz_: metacity has flickers with the nvidia driver.
<coz_> o0
<hyperair> coz_: gnome-shell won't work at all without 3d.
<coz_> mm
<hyperair> gnome-shell, pah. should be gnome's-hell or something >_>
<hyperair> i want my compiz.
<coz_> :)
<coz_> hyperair,  wait for 0.9.x compiz to release
<hyperair> hell yeah, i'm waiting.
<coz_> hyperair,  although that video about gnome shell and  clever windows  was real appealing
<hyperair> clever windows?
<coz_> I have no idea if clever windows will be implimented or even considered 
<coz_> hyperair,  yeah google ...... clever windows video >>>>>>
<hyperair> oh yeah i  think i've seen this before
<coz_> hyperair,  although compiz has most of those features  except that litte tab on the left and right for minimizing etc
<hyperair> righ
<hyperair> t
<knittl> what do i have to do to install the current version of nvidia? all methods i tried so far did not work
<knittl> i tried: apt-get install nvidia-current and installing via jockey
<knittl> then i ran nvidia-xconfig
<tseliot> knittl: jockey doesn't work with nvidia yet
<knittl> tseliot: ok, i see. what about apt-get?
<tseliot> apt-get install nvidia-current and then nvidia-xconfig and reboot
<tseliot> and that's it
<knittl> do i have to install the modaliases (the common package)?
<tseliot> knittl: that's only for jockey
<tseliot> you might need it in the future
<knittl> ok, but right now it's enough to install nvidia-current without anything else?
<tseliot> yes, that and nvidia-xconfig
<knittl> yep, for creating the xorg.conf of course
<knittl> good, i'll give it another try
<gnomefreak> is it known that nvidia is broken on latest xorg updates?
<tseliot> gnomefreak: define "broken" please?
<knittl> tseliot: still no luck, looks like X is crashing
<tseliot> knittl: what happens exactly?
<knittl> here is what i did this time: purged everything related to nvidia (apt-get purge nvidia*), searched in aptitude for nvidia, removed libvdpau, removed all xorg.conf* files, rebooted. service stop gdm, apt-get install nvidia-current, nvidia-xconfig, checking the successful creation of xorg.conf (yep, it's there, with driver = nvidia), rebooting. screen flickers early on (plymouth?), gdm gives warning that graphics driver is broken -> start in low resolution 
<tseliot> describe the symptoms please
<tseliot> knittl: can I see your /var/log/Xorg.0.log and /var/log/Xorg.0.log.old, please?
<knittl> i see text on the console (fsck, ureadahead terminating), then screen goes black, screen flickers, gdm error message appears
<knittl> sure, just a second
<knittl> http://knittl.is-a-geek.net/public/Xorg.0.log{,.old}
<tseliot> knittl: maybe the kernel module wasn't built. What does this command say? dkms status
<knittl> nvidia-current, 190.53, 2.6.32-10-generic, i686: installed
<Sarvatt> did the kernel module build ok when you reinstalled? if so, try sudo update-initramfs -u and reboot again? I need to do that pretty much every time I purge/reinstall nvidia, the first boot after is always failsafe
<knittl> hrm
<tseliot> knittl: also make sure that no other nvidia drivers (especially the ones from unofficial PPAs) are installed
<knittl> tseliot: no, i purged nvidia before, and i deaktivated all ppas. i also run several updates
<Sarvatt> apt-get purge nvidia* should have taken care of that, have to reinstall nvidia-common manually after that though
<tseliot> dmesg might have something interesting
<knittl> that's only needed for jockey and jockey does not work yet with the new nvidia. that's what i was told before
 * tseliot nods
<tseliot> dmesg ^^
<knittl> same url, file dmesg
<tseliot> ara, slangasek: I have worked on #506547. I have uploaded my fix for mesa to my PPA: https://edge.launchpad.net/~albertomilone/+archive/proprietary-video-improvements
<tseliot> can you test it please?
<tseliot> the tests that I've run here so far i.e. building mutter and testing blender went well: http://pastebin.ubuntu.com/356082/
<tseliot> oh, it's 7.7-0ubuntu5~proprietaryppa1
<tseliot> and it's still building
<ara> tseliot, I will test it when it's done
<tseliot> ara: Â¡Muchas gracias!
<jcristau> err. "invalid "install -d" command"
<jcristau> ?
<jcristau> ah.  because $(INSTALL) isn't set anywhere, i guess
<tseliot> yep
<tseliot> and it was useless anyway
<jcristau> ack
<tseliot> thanks for reviewing my commit
<tseliot> ara: the packages are ready (just FYI)
<ara> tseliot, OK, I will test them as soon as I have time (ISO testing takes lots of time)
<tseliot> ara: sounds good, thanks
<tseliot> slangasek: in addition to fixing #506547 ^^ I also sent you something to put in the release notes (which, of course, you can modify as you like)
<slangasek> tseliot: feel free to edit https://wiki.ubuntu.com/LucidLynx/TechnicalOverview directly (I won't be able to look at this for several more hours)
<tseliot> slangasek: ah, good. Just to be clear, I fixed the bug but haven't uploaded anything yet (see above)
<slangasek> any reason not to upload, if it's fixed?
<tseliot> slangasek: I was waiting on QA to test it (in addition to my tests). If you want me to upload it now, I'll do it though
<slangasek> tseliot: ok - more testing is good :)
 * tseliot nods
<tseliot> slangasek: BTW I have evidence that things go well with the fix: http://pastebin.ubuntu.com/356082/
<siretart`> I noticed that a simple 'xrandr' auto-activates the external monitor on my laptop. prior to kms this was not the case. Is this behavior intended or a bug?
<slangasek> tseliot: goody!
<tseliot> :-)
<jcristau> siretart`: my guess would be, xrandr tells the kernel to probe the connector, it then detects that the external monitor is connected, sends an event to tell userspace that, and something (gnome?) enables it
<siretart`> jcristau: well, a friend confirmed that the same behavior appears in debian/unstable as well, and that it occurs since switching to kms
<tseliot> siretart`: what jcristau says is correct, at least if you're using gnome
<tseliot> because gnome-settings-daemon gets the hotplug event
<siretart`> tseliot: what part of gnome is responsible for that?
<tseliot> ^^
<jcristau> xrandr --current wouldn't do that, fwiw
<siretart`> I noticed another bug as well: if you open an opengl application (like glxgears) and enlarge the window to more than 2048 (roundabout) pixels, the intel inkernel gem locks up and requires a reboot
<tseliot> ideally cable hotplug events are useful but in some cases (e.g. VGA cables) they are triggered only after running xrandr manually
<tseliot> or probing in any other way
<siretart`> this is particularily painful when connecting a 1920x1200 display and typing 'xrandr' in a shell: instant lockup
<jcristau> fun...
<jcristau> jbarnes: ^^
<tseliot> siretart`: the bug about going beyond 2048 was fixed in mesa 7.7 and the latest intel
<siretart`> tseliot: I guess gnome-settings-daemon shouldn't call xrandr without --current then, right?
<tseliot> let me find the bug
<jcristau> gnome-settings-daemon doesn't call xrandr at all..
<tseliot> siretart`: no, it doesn't call xrandr at all. When you call that, it cause a reprobe and you get that event
<tseliot> and then g-s-d enables the external screen
<siretart`> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/503255 is the bug I filed
<ubottu> Launchpad bug 503255 in xserver-xorg-video-intel "[i945] querying information on external monitor with xrandr hangs gpu when compiz is active" [Medium,Triaged]
<siretart`> tseliot: I'd consider g-s-d auto-enabling the external screen a bug. can this behavior be disabled by a configuration change?
<tseliot> siretart`: I'm not sure if it's the same bug but this one looks similar: https://bugs.freedesktop.org/show_bug.cgi?id=23718
<ubottu> Freedesktop bug 23718 in Driver/intel "[945GME] attaching external monitor causes black screen, with Compiz Fusion in Karmic" [Critical,Resolved: fixed]
<tseliot> siretart`: you can always disable g-s-d's randr plugin from gconf
<tseliot> and it's not a bug, it a feature ;)
<tseliot> a feature that bugs you but still a feature :-P
<siretart`> I'd prefer to have the behavior consistent to earlier releases of ubuntu, TBH
<jcristau> bug the gnome people then, maybe?
<siretart`> with this explanation, I think the defect report is "g-s-d's xrandr manager changes display configuration on probing monitors"
<siretart`> thanks for clearing this up!
<tseliot> siretart`: auto-enables would be more appropriate than "changes", I guess
<siretart`> ok
<tseliot> and it's an upstream decision
<tseliot> siretart`: you can discuss it with federico1
<tseliot> who happens to be upstream ;)
<siretart`> tseliot: you wrote earlier that the bug with gl frames beyond 2048 was fixed in "latest intel". is lucid's 2.9.1-1ubuntu1 recent enough?
<siretart`> federico1: around? see ^^
<tseliot> siretart`: good question. If it's not, we'll pull it
<siretart`> hm. I think I'll just dist-upgrade my laptop and test it
<tseliot> ok, good
<siretart`> tseliot: the freedesktop bug 23718 is not related to this issue. the kernel oops trace looks different
<ubottu> Freedesktop bug 23718 in Driver/intel "[945GME] attaching external monitor causes black screen, with Compiz Fusion in Karmic" [Critical,Resolved: fixed] http://bugzilla.freedesktop.org/show_bug.cgi?id=23718
<siretart`> in fact, I don't get any trace at all
<siretart`> well, maybe related, but not the same
<tseliot> siretart`: can you upstream your bug report (on freedesktop), please? Intel should know whether it's the same problem or not
<tseliot> but yes, dmesg looks different in your bug report
<siretart`> probably not today, will need to defer that to tomorrow
<tseliot> ok
<federico1> siretart`: hmm, what was the problem_
<federico1> ?
<tseliot> federico1: g-s-d auto-enabling the external screen on hotplug events
<federico1> tseliot: oh, yeah, I intend to do something about that
<tseliot> which he gets after using the "xrandr" command (which causes a reprobe)
<federico1> I want to just bring up gnome-display-properties so that you can setup the monitors, or ask you "you have a new monitor - what do you want?  [clone] [extend] [custom]"
<federico1> tseliot: BTW, I'm reworking the handling of the XF86Display hotkey, so that we bring up an OSD window with options instead of having you guess what the program did...
<tseliot> federico1: that feature is more than welcome
<tseliot> actually both features are
<tseliot> federico1: I think a small dialog would work for the hotplug event case, as you suggested
<federico1> tseliot: yeah, maybe the same OSD window with an extra label, "you just plugged a monitor; please pick one of the following options"
<federico1> tseliot: when I'm done with that OSD, I want to merge the moblin patches for transformations
<tseliot> federico1: either way you might want to have this in the hotplug case: [clone] [extend] [custom] [no action]
<federico1> yeah
<federico1> sounds good!
<tseliot> federico1: that would be great. What would be even better is if transformations were implemented directly in mutter
<tseliot> so as not to get a performance hit when scaling
<tseliot> slangasek: BTW when I get the ok from QA shall I ask you before I upload? (because of the freeze)
<slangasek> tseliot: no, just go ahead with uploading then
<tseliot> slangasek: ok, thanks
<federico1> tseliot: you mean, have the compositing manager transform stuff instead of doing it with xrandr transformations?
<tseliot> federico1: yes, exactly
<federico1> interesting
<federico1> hmm
<tseliot> that should be faster
<federico1> so
<federico1> tseliot: regardless of the speed (which *is* an important concern), the CM would indeed give us more flexibility.  I'm not sure that you can have xrandr transformations just do "I have a 1024x600 netbook; make it show on my 1024x768 projector with two black bars at the top and bottom"
<federico1> maybe you can; I'm not sure
<tseliot> federico1: I'm not sure about the bars. What I know for sure is that you can make clone screen work using different resolutions by scaling the content of one of the 2 screens. If they aspect ratio is different, things will look slightly deformed but still good IMO
<apw> bryyce, hey ... we have a bunch of people not being able to boot to X with modesetting turned on, it seems to have occcured with an x/mesa update today ... ringa bell?
<apw> (on i915)
<apw> tseliot, ^^
<tseliot> apw: ls -l /usr/lib/xorg/modules/extensions/
<apw> tseliot, what am i looking for?
<tseliot> apw: libdri.so and libglx.so
<apw> they are both 2010-01-12 11:12
<tseliot> apw: ok, it must be something else then. Can I see your /var/log/Xorg.0.log, please?
<tseliot> apw: err, the one with KMS
<cking>  ls -al /usr/lib/xorg/modules/extensions/
<cking> total 148
<cking> drwxr-xr-x 2 root root  4096 2010-01-13 09:50 .
<cking> drwxr-xr-x 7 root root  4096 2010-01-13 09:50 ..
<federico1> tseliot: yeah, maybe a bit of distortion is acceptable (like 4:3 NTSC on widescreen TVs)
<cking> -rw-r--r-- 1 root root 17920 2010-01-12 11:12 libdbe.so
<cking> -rw-r--r-- 1 root root 13784 2010-01-12 11:12 libdri2.so
<cking> -rw-r--r-- 1 root root 92336 2010-01-12 11:12 libextmod.so
<cking> -rw-r--r-- 1 root root  9708 2010-01-12 11:12 librecord.so
<cking> king@hpmini:~$ 
<tseliot> cking: that's wrong, you're missing those 2 modules. sudo apt-get install --reinstall xserver-xorg-core and it should be ok
<cking> tseliot, will try that - hold on
<apw> tseliot, we have a three machines in this one room with this symptom
<tseliot> apw: ubuntu5 of xserver-xorg-core should have fixed that
<apw> tseliot, ok checking :)
<apw> tseliot, pgraner has ubuntu5
<apw> and its not working for him, cking reports a --reinstall fixing it
<tseliot> apw: weird, the preinst should have taken care of that
<tseliot> slangasek: ^^
<apw> pgraner, has ubuntu5 and 4 files in /extensions
<apw> tseliot, an upgrade from ubuntu4 to ubuntu5 of that package did work for smb on another machine
<apw> ie we went from 4 to 6 files in /extensions
<tseliot> that's interesting
<apw> cking, went ubuntu5 without it, and reinstall made it work#
<apw> s/went/was on
<apw> we have one box on u5 with out those files, need anything from it?
<tseliot> apw: what version of the same package was installed before ubuntu5?
<tseliot> see /var/log/apt/term.log
<apw> tseliot, cking he did just the apt-get --reinstall xserver-xorg-core and after that he had ubuntu5 so i assume he had u5 before that
<apw> and he confirms the logs show u5 as installing this AM
<apw> and pgraner is in the same place, but before the reinstall, ie with u5 and not working with 4 files in /extensions
<tseliot> apw: right. And what did he have before installing u5? Was it u4?
<tseliot> or u3?
<apw> checking
<apw> cking was on u2 -> u5
<apw> pgraner, reports from u2 -> u5 also ... and he says he has been updating daily
<tseliot> apw: what does this command say? update-alternatives --display gl_conf
<apw> tseliot, on a good or bad one
<cking> tseliot, update-alternatives --display gl_conf
<cking> gl_conf - auto mode
<cking>  link currently points to /usr/lib/mesa/ld.so.conf
<cking> /usr/lib/mesa/ld.so.conf - priority 500
<cking>  slave gl_libraries: /usr/lib/mesa
<cking>  slave xorg_extra_modules: /usr/lib/xorg/x11-extra-modules
<cking> Current `best' version is /usr/lib/mesa/ld.so.conf.
<tseliot> cking: on a bad one
<tseliot> i.e. one that doesn't have those 2 modules yet
<apw> tseliot, coming
<pgraner> pgraner@zorak:~$ update-alternatives --display gl_conf
<pgraner> gl_conf - auto mode
<pgraner>  link currently points to /usr/lib/mesa/ld.so.conf
<pgraner> /usr/lib/mesa/ld.so.conf - priority 500
<pgraner>  slave gl_libraries: /usr/lib/mesa
<pgraner>  slave xorg_extra_modules: /usr/lib/xorg/x11-extra-modules
<pgraner> Current `best' version is /usr/lib/mesa/ld.so.conf.
<tseliot> slangasek: ok, so the alternative was removed and our fix (in the preinst script) worked but the modules were not installed
<apw> smb has an installation on ubuntu2 level, in case we want to test the update
<tseliot> apw, pgraner, cking: thanks
<tseliot> apw: oh, good
 * tseliot -> off for a bit
<apw> tseliot, we note that these files were links in u2, but in u5 fixed they are real files
<tseliot> apw: yes, as I had to move the alternatives from the xserver to mesa. However xserver-xorg-core ubuntu4, when removed, failed to remove its alternative thus preventing the new xserver-xorg-core from installing the real files
<apw> tseliot, presaumably as we never has u4 in there all <u5 fail to remove them
<tseliot> apw: well anything <= ubuntu4 failed to remove the alternative
<tseliot> and the output that you gave me, shows that the alternative was removed by u5
<apw> its seems odd that we ended up with nothing
 * tseliot nods
<Sarvatt> i think we really  need powersave=0 to be the default i915 module parameter in lucid over 1 it is now
<jcristau> +1
<Sarvatt> dont have any hope this is going to be fixed on 2.6.32 ever, its really experimental and even with the remove render reclock support added it's still need it to fix flickering
<Sarvatt> can't enable it globally because it breaks 2.6.31 kernels because it wasnt a module parameter then
<sebner> tseliot: are there still known issues with mesa?
<Sarvatt> on line 46 of drivers/gpu/drm/i915/i915_drv.c just change unsigned int i915_powersave = 1; to unsigned int i915_powersave = 0; -- would be easy to fix at least
<bryyce> Sarvatt, can you file a bug against linux requesting this, and sub me and steve conklin?
<Sarvatt> sure, i'm on my phone now but will when I get home, theres probably hundreds of bugs it'll fix
<Sarvatt> fedora and debian are both doing it
<jcristau> fedora too?  didn't see that.
<Sarvatt> yeah dave airlie was complaining about how everyone has to do it on dri-devel/lkms
<bryyce> hundreds of bugs?  nice
<Sarvatt> [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS thread
<jcristau> Sarvatt: yeah i read that.  i just can't find that in fedora cvs
<jcristau> might be me being blind
<jcristau> or not looking in the right place
<tseliot> sebner: bug #506547, which is fixed in my PPA and in git: https://edge.launchpad.net/~albertomilone/+archive/proprietary-video-improvements
<ubottu> Launchpad bug 506547 in mesa "Some GL apps won't run: libGLU.so.1: No such file or directory" [High,In progress] https://launchpad.net/bugs/506547
<sebner> tseliot: exactly. thanks :)
<tseliot> sebner: if you want to try it and give feedback (no reboot is required) that would be very welcome
<wind-rider> hi
<sebner> tseliot: done already + fixing the issue (at least for me)
<wind-rider> i have a 3dconnexion spacenavigator, and it is detected as a mouse by X.org
<wind-rider> but i would like to prevent that, because it needs a special driver
<wind-rider> i tried to do that using a fdi file in the hal policy directory, but that doesn't help
<wind-rider> can i do something about that?
<tseliot> sebner: great news. Thanks for testing
<sebner> tseliot: thanks for fixing ;)
<wind-rider> or is there another channel i can ask better?
<jcristau> wind-rider: lucid?
<wind-rider> jcristau: indeed
<jcristau> then X doesn't use hal
<jcristau> you can run xinput float <device> to stop it from moving the mouse
<wind-rider> jcristau: oh, you're right
<wind-rider> jcristau: i'll try that
<jcristau> where <device> is the id you get from xinput list
<baptistemm_> Hi gentlemen
<baptistemm_> Apparently on lucid, i915 + kms makes your screen corrupted, and eventually frozes totally the display, is it known ?
<baptistemm_> if I start with i95.modeset=0 I have no issue
<jcristau> what hw?
<wind-rider> jcristau: that works, thanks! i'll put it on the launchpad page for the new spacenavd package
<jcristau> wind-rider: 'xinput set-prop <device> "Device Enabled" 0' should also work.  i'm not sure which one is more correct.
<wind-rider> jcristau: the first thing you said was good enough, at least :) thx!
<jcristau> np
<baptistemm_> jcristau, GM965/GL960 (8086:2a02)
<baptistemm_> should I report, and against which component (intel, xserver)?
<tseliot> baptistemm_: probably unrelated but what does this say? ls -l /usr/lib/xorg/modules/extensions/
<baptistemm_> -rw-r--r-- 1 root root 17920 2010-01-12 12:12 libdbe.so
<baptistemm_> -rw-r--r-- 1 root root 13784 2010-01-12 12:12 libdri2.so
<baptistemm_> -rw-r--r-- 1 root root 92336 2010-01-12 12:12 libextmod.so
<baptistemm_> -rw-r--r-- 1 root root  9708 2010-01-12 12:12 librecord.so
<baptistemm_> I hope 4 lines is not too much to paste
<jcristau> tseliot: not unrelated then ;)
 * tseliot nods
<tseliot> baptistemm_: what does "dpkg -L xserver-xorg-core" say?
<tseliot> maybe I should send an email to the mailing list about it
<baptistemm_> http://pastebin.org/75688
<tseliot> baptistemm_: and of course "update-alternatives --display gl_conf | grep glx" doesn't return anything, does it?
<baptistemm_> nothing
<tseliot> baptistemm_: reinstalling xserver-xorg-core will solve your problem
<baptistemm_> so I guess I don't have to report a bug then :)
<baptistemm_> ah libglx.so whan missing ?
<baptistemm_> was
<baptistemm_> sO I'll reboot and see if it fixed, thanks
<bryyce> tseliot, you might want to post an email to ubuntu-devel@ about the mesa issue and that rebooting solves it.  might help spread the word faster.
<tseliot> bryyce: yes, I'm almost done writing it
<sebner> tseliot: update-alternatives --display gl_conf | grep glx doesn't return anything here either or am I missunderstanding and is this the prefered thing?
<tseliot> sebner: yes, that's the way it should be
<tseliot> i.e. no output
<sebner> fine then :)
<baptistemm_> tseliot, thanks it works fine now, what happend?
<tseliot> I had to move the alternatives from the xserver to mesa. However xserver-xorg-core ubuntu4, when removed, failed to remove its alternative thus preventing the new xserver-xorg-core from installing the real files
<siretart`> tseliot: I've just done a very quick test with my external monitor, you're right, current lucid does not show that behavior. windows with width >2048 pixels no longer crash gem, they 'just' have display corruptions
<tseliot> siretart`: better than nothing, I guess
<tseliot> thanks for reporting
<siretart`> tseliot: I could also confirm that disabling the xrandr plugin avoids autoenabling the external monitor. though this also prevents the gnome randr applet from working. but I guess that's expected
<tseliot> yep
<siretart`> federico1: your suggestion for a pop up that asks the user what to do sounds exactly right to me! thanks a lot!
<tseliot> bryyce: email sent
<bryyce> great
<siretart`> the only thing that I unexpected issue I've noticed now is that g-s-d's randr manager somehow managed to cause compiz to quit and start metacity instead
<siretart`> while 'autoenabling' the external monitor
<tseliot> bryyce: if you want to test my fix for mesa with nvidia in my PPA: https://edge.launchpad.net/~albertomilone/+archive/proprietary-video-improvements
<siretart`> not sure why, might be just flying bogons or something
<tseliot> bryyce: launching blender should be enough
<jcristau> siretart`: because compiz is broken, i suspect :)
<siretart`> jcristau: wouldn't be the only issue in compiz, true :-)
<bryyce> tseliot, ok thanks.
<siretart`> I'm really happy that I can now close bug #503255 now. thanks for explaining this stuff to me!
<ubottu> Launchpad bug 503255 in xserver-xorg-video-intel "[i945] querying information on external monitor with xrandr hangs gpu when compiz is active" [Medium,Triaged] https://launchpad.net/bugs/503255
<bjsnider> siretart`, how's the ffmpeg fix coming along?
<federico1> siretart`: :)  I hope to have it ready soon
<tseliot> siretart`: that's because it switched to software rendering
<tseliot> no wonder compiz stopped working
<siretart`> bjsnider: implemented, submitted upstream and I wait for it to be accepted
<bjsnider> cool
<coz_> tseliot,  I noticed on lucid that some of the compiz plugins are not working   is this the mesa issue and you ppa fixes that temporarily??  sorry if I am repeating I just arrived here :)
<siretart`> tseliot: oh, that's interesting. so you suggest that compiz is able to detect at runtime that the driver decides to disable hw rendering and therefore silently exits?
<tseliot> coz_: with what driver?
<coz_> tseliot, 190.53
<siretart`> sounds plausible. need to think a bit about that on my way home. cu around!
<tseliot> siretart`: I don't know how advanced compiz is but I seem to remember that, when it dies, it uses metacity as a fallback
<coz_> tseliot,  this was a manual install of the driver also
<tseliot> coz_: it could be. Maybe try the fix in my PPA and restart X?
<siretart`> tseliot: the 'appearance' system applet (or however it is called) doesn't notice that and leaves the bullet on 'active desktop effects'
<coz_> tseliot,  ok I will try that now ...
<siretart`> but thats fortunately a rather cosmetic issue
<coz_> to coz because he is on another machine :)    https://edge.launchpad.net/~albertomilone/+archive/proprietary-video-improvements
<tseliot> siretart`: yes, I doubt there's a way constantly check if compiz is still alive (other than polling)
<tseliot> :-)
<coz_> successo !
<coz_> tseliot,  your fix worked at least for now :)
<coz_> looks like keyserver.ubuntu.com is down  however... I couldnt get the key
<tseliot> coz_: great! Thanks for testing
<coz_> tseliot,  no problem testing...lucid is on another machine  so if anything goes wrong I can always fix or reinstall :)
<knittl> update-initramfs didn't help either with the drivers
<tseliot> knittl: what does dmesg say?
<tseliot> oh, you put a link before
<knittl> i piped the output again to http://knittl.is-a-geek.net/public/dmesg
<tseliot> knittl: can you reproduce the problem and get the output of "lsmod" and "grep nvidia /etc/modprobe.d/*" please?
<knittl> lsmod where? console or failsafe mode?
<knittl> there's no nvidia module in lsmod
<knittl> hu, it's blacklisted? o.O
<knittl> http://paste2.org/p/609332
<tseliot> knittl: this is wrong /etc/modprobe.d/blacklist-local.conf
<tseliot> type: "dpkg --search blacklist-local.conf" to see what installed it
<knittl> i thought so. how did it come in there?
<tseliot> that command should tell you
<knittl> dpkg: *blacklist-local.conf* not found.
<knittl> i know i haven't done it manually ... why would i
<Sarvatt> disabling it in jockey maybe?
<tseliot> oh
<tseliot> but it would be weird
<tseliot> (not unlikely though)
<knittl> sounds possible
<tseliot> knittl: removing that file and rebooting should do it then
<knittl> removing the file or its contents?
<tseliot> slangasek: I guess no feedback from QA today (and I can't blame them). Some uses tested my package with good results
<tseliot> users
<tseliot> I think I can safely upload the package
<tseliot> (and save us a few bug reports)
<knittl> /rebooting
<knittl> wheeeeeeee, it booted without giving this stupid error message :)
<tseliot> :-)
<knittl> thank you, i wouldn't have managed it myself :)
<tseliot> np
<slangasek> pgraner, apw: can I get a /var/log/dpkg.log from a system that needed the --reinstall of ubuntu5?
<tseliot> slangasek: shall I proceed with the upload anyway?
<slangasek> tseliot: the mesa upload? I would say so, yes
<tseliot> slangasek: yes. Ok
<tseliot> uploaded
<tseliot> \o/
<apw> slangasek, i don't have one here, i'll ask smb to get you one if you still need it
<slangasek> apw: yes, still need it
<slangasek> I don't understand why the fix that was already applied isn't reliable
<apw> slangasek, yeah its pretty perplexing
<tseliot> the preinst works (i.e. the alternative is remved) but the 2 modules are not installed :-/
<apw> slangasek, smb and cking had the broken ones, cking was fixed by reinstall i believe
<tseliot> slangasek: this is from my machine: http://pastebin.ubuntu.com/356270/
<slangasek> tseliot: you had the problem of missing files after upgrade?
<tseliot> slangasek: yes, on one of my testing boxes
<tseliot> well, the only physical testing box
<slangasek> hmm
<slangasek> and this log hasn't been filtered in any way?
<tseliot> no
<tseliot> I can upload the full file if you like
<slangasek> my only concern is whether there are other package maintainer scripts firing in between what you've shown
<tseliot> mesa shouldn't touch that, as its alternatives didn't involve doing anythin with those 2 modules
<tseliot> maybe nvidia?
<tseliot> apw: those computers had intel or ati, right?
<tseliot> no nvidia?
<apw> tseliot, they were all intel ones i saw
<slangasek> they were all touching the gl_conf alternative, which the others were slaves of
<tseliot> right
<slangasek> this could be a side effect of only one of the alternatives having the slaves
<slangasek> can I see the full log?
<tseliot> sure
<tseliot> it's in a PM
#ubuntu-x 2010-01-14
<Sarvatt> ugh our older kernel-package doesn't work with the newer kernels anymore, this package is such a nightmare to follow and has changed so much since the 11.015 we're using
<Sarvatt> utsrelease.h moved to include/generated it looks like, think it might still work if you dont specific any -append-to-version.. hope so because I need to test a kernel with an extra debugging info patch for this intel execbuff while wedged bug
<mtc> Hello - I am using the "radeon" module with Ubuntu 9.10 - and any time an application uses SDL to go full screen, the monitor turns off
<mtc> what is a way to start troubleshooting this issue?
<mtc> thanks for your continued work with incorporating the open drivers from AMD into Ubuntu 10.04
<vish> are the libgl1-mesa-*  7.7-0ubuntu5 updates stable?  i dont see any accompanying xserver updates
<vish> on Lucid^
<vish> ATI
<slangasek> tseliot: hi, what's your reference for saying that alternatives don't need to have the same set of slaves?
<slangasek> if you're basing this on mandriva, then all bets are off, they don't use the dpkg implementation of update-alternatives...
<tseliot> slangasek: I'll find it. BTW I remember than they patched their update-alternatives
<tseliot> I'll ask them about those patches
<tseliot> they told me that they patched it so that it could deal better with links to files that don't exist
 * slangasek nods
<tseliot> slangasek: if the patches are reasonable we might include them
<slangasek> yes, but that doesn't help users who are still running the dpkg from the old Ubuntu release at time of upgrade; I would prefer a solution on the libglx side that's robust wrt known package manager bugs...
<slangasek> anyway, this is still all speculative on my part, I haven't shown that this is related to the missing files problem yet :)
<tseliot> right
<tseliot> if I see what their patches do, maybe I can reproduce their behaviour in our preinst scripts
<tseliot> it would still be nice to find the cause of our problem though
<tseliot> slangasek: just another note: I think we can safely exclude nvidia from this as the problem took place on systems that use only intel and that didn't have any kind of nvidia driver installed
<tseliot> the kernel devs, pitti and other people used only -intel
 * slangasek nods
<apw> tseliot, are we expecting an upload to fix this lost files thing?  i only see u5 still
<tseliot> apw: u5 was supposed to fix this (which in part explains why some installations have the problem while other don't). We can't fix this weird upgrade issue for good if we don't know why our fix doesn't work reliably
<tseliot> apw: quoting the message that I sent to ubuntu-devel@:
<tseliot> This shouldn't happen in dist-upgrades from Karmic to Lucid or in new installations but only in some cases after updating a Lucid system.
<apw> tseliot, so is there anything more you need from us, or should i tell those affected '--reinstall'
<tseliot> slangasek: ^^
 * tseliot ran out of ideas
<slangasek> apw: if anyone has a system they haven't yet --reinstalled to fix, /var/lib/dpkg/alternatives/gl_conf would be nice
<apw> slangasek, will see who's left
<slangasek> tseliot: oh... just found it
<tseliot> what is it?
<slangasek> $ sudo update-alternatives --install /etc/ld.so.conf.d/GL.conf gl_conf /usr/lib/mesa/ld.so.conf 500 --slave /usr/lib/GL gl_libraries /usr/lib/mesa --slave /usr/lib/xorg/extra-modules xorg_extra_modules /usr/lib/xorg/x11-extra-modules
<slangasek> update-alternatives: warning: alternative /usr/lib/standard-x11/ld.so.conf (part of link group gl_conf) doesn't exist. Removing from list of alternatives.
<slangasek> /usr/lib/standard-x11/ld.so.conf vs. /usr/lib/standard-x11/standard.conf
<tseliot> are you trying to tell me that I'm removing the wrong alternative?
<tseliot> let me check
<tseliot> d'oh
<tseliot> slangasek: that's the cause
<tseliot> I should have removed /usr/lib/standard-x11/ld.so.conf
<tseliot> let me fix it
 * tseliot blushes
<slangasek> we both missed it :)
<slangasek> go ahead and upload when you have it fixed
<tseliot> ok
<tseliot> slangasek: shall I bump the revision we're checking? dpkg --compare-versions "$2" lt-nl 2:1.7.3.902-1ubuntu5
<tseliot> to dpkg --compare-versions "$2" lt-nl 2:1.7.3.902-1ubuntu6
<tseliot> as some systems might still have that alternative installed
<slangasek> yes, should be bumped
<tseliot> if they don't have one then the following command shouldn't cause the preinst to fail:
<tseliot> update-alternatives --remove gl_conf /usr/lib/standard-x11/ld.so.conf || true
<slangasek> correct
<tseliot> ok
<tseliot> slangasek: here's the diff: http://pastebin.ubuntu.com/356525/
<slangasek> tseliot: ack, looks right to me
<tseliot> perfet
<tseliot> perfect
<tseliot> slangasek, apw: uploaded
<tseliot> apw: it would be nice if you could try xserver-xorg-core 2:1.7.3.902-1ubuntu6 when it's available
<tseliot> apw: did the fix work?
<mnemo> lucid worked fine last few weeks for me, but after installing updates yesterday + reboot: now I get blackscreen instead of GDM ... dmesg/xorglog contains intel GPU hang errors --> http://pastebin.com/m19852642
<mnemo> is this a known bug? if so, what is the LP bug number?
<Duke`> Sarvatt, any news about the execbuf error?
<mnemo> Duke`: what is the LP bug number for the execbuf error?
<Duke`> LP I don't know, but I have the freedesktop bug I think
<Duke`> https://bugs.freedesktop.org/show_bug.cgi?id=25475
<ubottu> Freedesktop bug 25475 in Driver/intel "[i915] Xorg crash / Execbuf while wedged" [Critical,New]
<mnemo> okay that looks like what I have using lucid right now
<lokad> Hi
<lokad> I have serious problems with the latest versions of the xserver in ubuntu lucid
<lokad> with kms enabled i get a black screen and the system hangs
<lokad> without no screens are found and Xorg segfaults
<lokad> but this does not match the latest bug reports (xorg segfaults) on bugs.ubuntu.com
<lokad> xserver-xorg: 7.5+1ubuntu1, xserver-xorg-vido-intel: 2.9.1-1ubuntu1
<RAOF> âsudo aptitude reinstall xserver-xorg-coreâ should fix it.
<lokad> sounds easy enough to try *g* thx
<lokad> it did indeed ... my i ask why?
<lokad> thanks anyway ... good night utc+1
#ubuntu-x 2010-01-15
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0e253fdb3b5739fd8514f617ec582762bcfaea48
<Sarvatt> :/
<Sarvatt> pasted that in the wrong place, sorry
<persia> Good day.  I was pointed at the plymouth FTBFS, and it dies in ./configure with "configure:11953: error: Package requirements (libdrm libdrm_intel libdrm_radeon libdrm_nouveau) were not met" for powerpc and armel (the only architectures from the FTBFS list I can test).
<persia> Does anyone know what modules should replace that, or am I in the wrong place (drm and X are linked in my head for some reason)
<Sarvatt> it's the libdrm_intel thats the problem for sure, only builds on amd64/i386 for obvious reasons. libdrm-nouveau/radeon build on all arches. it was added here http://cgit.freedesktop.org/plymouth/commit/?id=f2048af97dcc862dbbb587a0cc2546ddbdbd2b0c
<persia> Sarvatt: So basically either libdrm-intel needs to be ported to other architectures, or ./configure needs to know not to look for it on those architectures?
<Sarvatt> would have to conditionalize the intel drm renderer build in the plymouth build system I think?
<persia> That avoids porting :)
<persia> And if I wanted to use plymouth with SiS, I'd need to do something like the patch you pasted to enable that?
<Sarvatt> it needs a KMS driver to work that way :( you could use a vesa FB though
<persia> Hrm, that's probably beyond me then :)  I do have a powerpc with radeon, so maybe I can test with that to cover just the don't-use-intel-for-sparc/powerpc/armel/ia64 patch.
<persia> Thanks a lot for the guidance.
<Sarvatt> redhat might have done the work already, might be worth poking around their CVS
<Sarvatt> KMS isnt enabled in the ubuntu powerpc kernel last I checked, I build my own for my ibook
<persia> heh.  First google result on "RedHat CVS" is an article entitled "CVS is out, Subversion is in"
<Sarvatt> fedora cvs sorry :)
<persia> Sarvatt: It's probably not enabled due to lack of testing.  If it works, submit a patch to the ubuntu-kernel team.
<Sarvatt> poking around there now too
<Sarvatt> no luck, they must just not use it on powerpc
<Sarvatt> or they build libdrm_intel on other arches
<persia> Yeah.  	BuildRequires: pkgconfig(libdrm_intel)
<Sarvatt> i dont think it would really hurt anything to just build libdrm-intel1 on linux-any?
<persia> Let me see if it works on powerpc
<Sarvatt> i mean, libdrm-nouveau and libdrm-radeon are linux-any and would never be used on most other arches
<persia> Why linux-any rather than any?  The current list is "amd64 i386 kfreebsd-amd64 kfreebsd-i386"
<persia> Why wouldn't nouveau or radeon be used on other arches?  I have a radeon in my powerpc box, and I know several were sold with nVidia cards.
<Sarvatt> oh, whoops :) really though it doesnt make sense for it to build other places since its limited to integrated graphics, at least the others can come in pci/agp form
<persia> My powerpc radeon certainly looks like integrated graphics (older MacMini)
<persia> Sarvatt: Good call.  libdrm-intel indeed seems to compile cleanly for at least powerpc.  That seems the easiest way forward (and those people who have intel graphics cards in their sparc/powerpc/armel/ia64 boxes can file bugs if they encounter issues)
<Sarvatt> fedora does build libdrm-intel on powerpc, just looked in their packages
<persia> Excellent: there's precedence, which always helps in convincing someone to upload.
<persia> I have a suspicion that it's a completely untested codepath, due to lack of hardware, but I don't imagine that it matters because of the same lack of hardware.
<Sarvatt> they cant ever have intel graphics in their powerpc/sparc/arm/ia64 is the problem
<Sarvatt> well ia64 maybe but it wouldnt use libdrm-intel
<persia> Well, that just happens to be true today.  I do have an ARM box with an Intel processor (but intel suggested an ATI video adaptor back then).
<bjsnider> since when does ubuntu support powerpc?
<persia> bjsnider: Since warty or hoary or something.
<bjsnider> not officially
<bjsnider> it was dropped
<persia> Um, only kinda.  Not like hppa was dropped.
<persia> So packages still build, and it still shows up on all the QA reports, and there are still images on cdimage.ubuntu.com and thousands of users.
<Sarvatt> I still use it and appreciate it working still at least on powerpc :D
<persia> And a bunch of people fix powerpc-specific bugs.
<persia> It's not unless a port gets really unpopular or is just broken that it gets dropped.
<persia> For instance, hppa had 3 users left when it went away, and all of them agreed.
<Sarvatt> granted hardy was the last release I could ever install from disk on my ibook because of the ide-cd changes
<persia> Sarvatt: Is that a general hardware support issue, or something that could be fixed?
<Sarvatt> nothing 6 hours of dist-upgrades doesn't fix though :D
<Sarvatt> it was over my head when I looked into it last so I'm not sure, was just a problem with the cd installers because the drive works fine after its installed
<Sarvatt> http://ucho.ignum.cz/fedora/linux/development/ppc/os/Packages/libdrm-2.4.6-6.fc11.ppc.rpm is the fedora libdrm I looked at to see libdrm-intel1 was being built on powerpc there though
<persia> Well, on the bright side, once 10.04 is out, it should be a one-step dist-upgrade.
<persia> Anyway, bug #507765 filed to port libdrm & ideally fix plymouth ftbfs.
<ubottu> Launchpad bug 507765 in libdrm "Please build libdrm-intel for ports architectures" [Undecided,New] https://launchpad.net/bugs/507765
<superm1> bjsnider, would you mind adding a conflicts on your nvidia karmic 190 and later packages to the mythtv version in the karmic archives or less?  the mythbuntu autobuilds PPA is compatible with your stuff, but the stuff karmic launched with isn't and we get people popping into #ubuntu-mythtv with some weird stuff that keeps coming up and is leading to that
<akaihola> The page https://wiki.ubuntu.com/X/Troubleshooting/Freeze contradicts itself. It claims that a backtrace is a non-symptom, but lists "[mi] EQ overflowing" and X freeze as a relevant problem. A backtrace is included with such log messages.
<akaihola> Also, there are no instructions about what to do in case of a "crash, not freeze" under the subheading "Non-Symptoms".
<akaihola> Otherwise the page is fantastic! I'd like to help improve it further, but I have insufficient knowledge to decide what information is correct.
<akaihola> Alternatively, what is a good place besides IRC to discuss Wiki pages, if I don't want to join the mailing lists? File a bug in Launchpad?
<Ng> so I had a weird thing last night where I plugged my phone into my laptop and something about USB went a little bit mental and started flapping, and X segfaulted
<Ng> going by the kernel messages it seems like all USB devices were appearing and disappearing
<Ng> very fast I mean
<Ng> but whatever the problem with my USB is, that shouldn't make X crash :)
<Ng> apport doesn't seem to have caught anything though, which is a bit weird
<Ng> hmm I wonder if it's https://bugs.freedesktop.org/show_bug.cgi?id=25640
<ubottu> Freedesktop bug 25640 in Server/general "Reattaching USB keyboard causes double free" [Critical,Assigned]
<Ng> that one sounds a whole bunch more reproucible though
<tseliot> Ng: did you try this patch? http://lists.freedesktop.org/archives/xorg-devel/2010-January/004908.html
<Ng> tseliot: not yet, I don't have as predictable a reproduction scenario as the fedora bug, but the circumstances are similar
<Ng> (something about my USB went a bit strange when I plugged my phone into my USB hub and all the USB devices started flapping)
<Ng> I really hate USB, maybe I should switch to bluetooth keyboards/mice ;)
<seb128> bug #507239
<ubottu> Launchpad bug 507239 in xorg-server "Xorg crashed with SIGSEGV in FatalError()" [Medium,New] https://launchpad.net/bugs/507239
<seb128> is that something being worked?
<sebner> seb128: heya, can I ask you something (little bit offtopic)? I'm wondering if the split between in the indicator session makes sense (again, 1 icon more) + what's the plan for the future. Isn't that useless afford since Ubuntu 10.10 will ship with Gnome3 and gnome-shell with it's own indicator system?
<seb128> sebner, who said we will ship gnome-shell?
<sebner> seb128: wondering as it's in the archive anyways and will be part(?) of GNOME3?
<seb128> nothing decided
<seb128> it's far to be ready
<seb128> and we need something which works on non accelerated videos
<seb128> netbooks
<seb128> old computer
<seb128> remote display
<seb128> etc
<sebner> sure but I'm pretty sure the old (current look) will be outdated or not maintained at some point at the future and gnome-shell is the future imho
<seb128> the indicator are new technologies and use dbus
<tseliot> seb128: I'm not sure about that bug. Maybe I can reproduce it here. I think I've experienced something similar
<seb128> they can be used in gnome-shell if upstream wants
<seb128> tseliot, it crashes this way when trying to open a guest session there on lucid
<seb128> intel i965
<jcristau> seb128: the backtraces on that bug seem fairly useless
<jcristau> like there are symbols for libc but not the server
<sebner> seb128: I never said that the indicator stuff is bad but as you said it's really something like "pushing our stuff into upstream and hoping they'll accept"
<seb128> sebner, you think doing work and suggesting people try it then is the wrong way?
<seb128> what would be the right one?
<seb128> coming with random ideas and waiting for others to do the work?
<sebner> seb128: nah, doing discussion with upstream beforehand
<seb128> jcristau, do you know what debug package is required for VAuditF?
<sebner> and/or with other distributions so more can benefit
<sebner> Intercompatible ftw! ...
<seb128> sebner, those were discussed with upstream at boston summit hackfest 2 years ago
<jcristau> seb128: xserver-xorg-core-dbg
<seb128> jcristau, thanks
<tseliot> I think -dbg packages should interfere with apport
<sebner> seb128: so only a matter of time, you said "if upstream wants" though so I doesn't really seem that fix
<seb128> sebner, sometime people disagree on the way
<seb128> sebner, it doesn't we shouldn't experiment
<seb128> to be honest I'm not convinced by gnome-shell yet
<sebner> seb128: me neither but I have the feeling that sooner or later it will be default so I was just wondering about the ubuntu self-development stuff :)
<seb128> re
<seb128> jcristau, 
<seb128> #0  0x080ac9b4 in _XSERVTransClose (ciptr=0x8be8aa8)
<seb128>     at /usr/include/X11/Xtrans/Xtrans.c:930
<seb128> #1  0x080a6be4 in CloseWellKnownConnections () at ../../os/connection.c:492
<seb128> #2  0x080b0caf in SigAbortServer (signo=11) at ../../os/log.c:426
<seb128> #3  0x080b10d1 in FatalSignal (signo=11) at ../../os/log.c:560
<seb128> #4  0x080a9aa2 in OsSigHandler (signo=11, sip=0xbfb0f21c, unused=0xbfb0f29c)
<seb128>     at ../../os/osinit.c:157
<seb128> #5  <signal handler called>
<seb128> #6  0x00000000 in ?? ()
<seb128> is that useful in some way?
<jcristau> sort of.  it starts at the sigsegv signal handler though, so it doesn't catch the first crash
<seb128> #6  0x00000000 in ?? ()
<seb128> #7  0x080b13de in FatalError (f=0x81c5206 "no screens found")
<seb128>     at ../../os/log.c:585
<seb128> #8  0x08067044 in main (argc=9, argv=0xbfb0f6c4, envp=0xbfb0f6ec)
<seb128>     at ../../dix/main.c:206
<seb128> jcristau, ups, forgot to copy that
<seb128> the 0x00000000 is weird
<jcristau> indeed
<jcristau> tseliot: so, hum, patch 191 is not in git
<jcristau> seb128: os/log.c:585 seems to be AbortServer(); which is defined 100 lines earlier...
<tseliot> jcristau: no, it's not. Shall I add it with -f? .patch files are in .gitignore
<jcristau> tseliot: yes
<tseliot> ok
<jcristau> (or use .diff)
<jcristau> (or kill .gitignore from the debian or ubuntu branch)
<tseliot> ok, pushed
<tseliot> next time I'll use .diff
<jcristau> thanks
<seb128> jcristau, any suggestion to get extra informations?
<seb128> or to turn the bug about this crash about something useful
<jcristau> seb128: is it reproducible?  can you try without the ubuntu patches?
<seb128> I get it every time I try to open a guest session
<seb128> but I guess it's nothing specific to the guest session
<seb128> it's probably when trying to open a second xsession
<jcristau> sounds likely
<seb128> ubuntu patches for which source?
<jcristau> xorg-server
<seb128> ok, will try
<seb128> I guess that takes a bit to build
<jcristau> there's a couple that touch os/log.c
<jcristau> something like 15min on my laptop
<seb128> I will do a noopt nostrip build
<seb128> jcristau, which patches do you recommend to comment, all the patches directory or just the one added in ubuntu compared to debian?
<jcristau> seb128: 100 and 160 in particular
<seb128> ok, that's the one I turned off since they were touching log.c, it's building
<seb128> also other issue
<seb128> on the mini10v and lucid the screen flickers every few seconds after suspend
<seb128> what is useful to debug such issues?
<jcristau> try i915.powersave=0 on the kernel cmdline
<seb128> ok, no luck getting a debug stacktrace
<seb128> it's not crashing now
<seb128> I got the xorg mouse pointer over all vts
<seb128> and vt7 displaying text
<seb128> instead of my session
<seb128> but things are still running 
<seb128> weird...
<tseliot> seb128: as I said, -dbg packages shouldn't work particularly well with apport (if that's your problem)
<seb128> no it's not
<tseliot> ok
<seb128> I did use gdb to get the stacktrace I copied before
<tseliot> yes, that should work
<seb128> and did load the symbol by hand using "symbol file"
<seb128> the automatic loading is broken for some reason
<seb128> now I tried a build without the patch which touch log.c
<seb128> but it doesn't crash without those, it just destroy the graphical view and display a vt
<seb128> but desktop proccess are still running
<tseliot> patches 100 and 160?
<seb128> yes
<tseliot> seb128: what does the Xorg.0.log say if you ssh into that computer?
<seb128> I don't need to ssh, vts are still working
<seb128> there is nothing in the xorg logs
<seb128> no error
<tseliot> I'm a bit concerned about this: FatalError (f=0x81c5206 "no screens found")
<tseliot> which, I must admit, is a bit vague
<tseliot> seb128: does dmesg say anything interesting?
<seb128> tseliot, no
<seb128> does opening a guest session is working?
<seb128> does opening a guest session is working for you?
<seb128> does opening a guest session is working for you?
<seb128> ups
<tseliot> seb128: can you reproduce the problem if you disable KMS?
<seb128> tseliot, I will try later
<seb128> I'm using this computer now
<tseliot> ok
<tseliot> apw: did you try my fix for X?
<seb128> tseliot, did you try the guest session? 
<tseliot> seb128: no, I didn't
<Sarvatt> do these guest session bugs that we're getting hit with really look like xserver? it just looks like it might be a GDM problem to me, guest sessions trying to spawn a new xserver instance with the old one still active for some reason?
<jcristau> Sarvatt: if the server is segfaulting, that sounds like a server bug :)
<Sarvatt> I get eerily similar gdm logs when I have to start in failsafeX, x segfaults and I get [    0.000000] (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor
<Sarvatt> [    0.000099] (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor
<Sarvatt> [    0.000132] (WW) xf86OpenConsole: VT_GETSTATE failed: Bad file descriptor
<Sarvatt> (when I dont have failsafeX set to use fbdev instead of vesa and am using KMS)
<jcristau> so X can't get a fd to the console?
<Sarvatt> Fatal server error:
<Sarvatt> Server is already active for display 0
<Sarvatt>         If this server is no longer running, remove /tmp/.X0-lock
<Sarvatt>         and start again.
<jcristau> hmm
<Sarvatt> and it tries to spawn the new one on tty2 when tty7 is still active
<jcristau> why does it try to start the new server as :0?
<Sarvatt> just looked over my logs again, that was happening when fsck on boot was kicking me to failsafe 100% of the time, and i think it was because gdm would start, crash because something (dbus?) wasn't ready and relaunch itself before the other cleanly ended? failsafe ended up on :1 and tty2 when it finally worked. i really can't follow this gdm startup maze
<Sarvatt> it's over my head and i'm just adding noise, it seems to be happening with guest sessions for everyone now though. seen bugs from people with ati intel and s3 getting it. lets see if it crashes here :)
<Sarvatt> yep it kicks me to a VT with the mouse still working when I do a guest session
<Sarvatt> :0-slave.log says gdm-session-worker[3500]: pam_unix(gdm-autologin:session): session opened for user robert by (uid=0)
<Sarvatt> /etc/gdm/PreSession/Default: 16: initctl: not found
<Sarvatt> seb128: I fixed guest sessions here by changing /etc/gdm/PreSession/Default to call /sbin/initctl -q emit desktop-session-start DISPLAY_MANAGER=gdm instead of just initctl -q emit desktop-session-start DISPLAY_MANAGER=gdm
<Sarvatt> there was just a bunch of changes to the paths being exported around in the sessions, guessing it needed changing after that since /sbin isnt in the path for it anymore
<Sarvatt> of course I cant get back into my logged in session after trying to switch back though, its stuck with the gdm background on the screen. but switching to a guest session works :D
<Sarvatt> this is the commit I was talking about messing with the paths http://git.gnome.org/browse/gdm/commit/?id=e33ee9d9b23c103ac25b6fdb53fe8c074de0de53
<bryyce> hi Sarvatt
<Sarvatt> heyo!
<bryyce> Sarvatt, think we need that patch added to gdm?
<bryyce> maybe we should point it out to seb128
<Sarvatt> yeah pinged him there, doubt hardcoding /sbin/ is the right thing to do, just know it works here
<bryyce> Sarvatt, is there a launchpad bug open about this issue?
<Sarvatt> loooots, looks like some people are getting X crashes also thats probably a different issue (vish?)
<Sarvatt> bug #506510
<ubottu> Launchpad bug 506510 in xorg-server "Xorg crashed with SIGSEGV in FatalError()" [Medium,New] https://launchpad.net/bugs/506510
<Sarvatt> bug #507239
<ubottu> Launchpad bug 507239 in xorg-server "Xorg crashed with SIGSEGV in FatalError()" [Medium,New] https://launchpad.net/bugs/507239
<vish> i tried with >   /sbin/initctl -q emit desktop-session-start DISPLAY_MANAGER=gdm  
<vish> but it kept kicking me out ;)
<Sarvatt> oh I changed the path to have /sbin in it too
<Sarvatt> PATH="/usr/bin:/sbin:$PATH"
 * vish tires again ;)
<vish> tries*
<Sarvatt> http://paste.ubuntu.com/357210/
<vish> \o/
<vish> Sarvatt: works
<Sarvatt> sorry about that
<vish> np :)
<vish> Sarvatt: thanks ...
<bryyce> Sarvatt, so I guess the question for us is if X should not be crashing in this situation but should exit with a friendly error message?
<Sarvatt> I have no idea what magic gdm is doing to segfault X like that, it was doing it sometimes before we waited for dbus to have started and when fsck's were going when it tried to start before too.. I only noticed the error in :0-slave.log because of the timestamp, thats not getting attached to the bugs
<bryyce> hrm
<bryyce> yeah the stack traces on 506510 are fairly useless
<Sarvatt> trying to respawn a second server with DISPLAY=:0 when its already taken I guess?
<bryyce> Sarvatt, you are able to reproduce this bug?
<Sarvatt> yeah you can too, just try to log in a guest session on lucid
<Sarvatt> (an up to date one)
<Sarvatt> not machine specific as far as I can see, seen it on ati intel nvidia and s3
<Sarvatt> and SIS
<vish> bryyce: thanks , was just about to comment on the bug about Sarvatt's fix :)
<Sarvatt> launchpad + tethered EDGE connection dont go well together :D
<bryyce> Sarvatt, ok sounds like the next step would be to get a gdb attached to xorg-server and figure out where it is crashing
<Sarvatt> seb128 did that earlier, have the scrollback handy?
<bryyce> ah
 * bryyce looks
<Sarvatt> around 6:40AM EST
<bryyce> mm
<bryyce> jcristau suspects patch 100 or 160
<jcristau> bryyce: it's the 2 patches that touched the code that seemed to crash.  might still be something else.
<jcristau> but i thought it was worth testing without that
<bryyce> 160 has been in for a while
<bryyce> 100 is a few weeks old, it might be worth a more detailed review
<Sarvatt> yeah would be nice to find why it happens because it seems easy to make gdm do it :D time to build a server with no ubuntu patches and see if it happens since its so easily reproducable right now
<seb128> I don't get a crash on a debug build without those
<seb128> debug build = noopt nostrip
<bryyce> however, the os/log.c stuff is normal to pass through on crashes so could be something higher up
<seb128> it doesn't segfault but it still bugs
<seb128> vt7 goes away and get the xorg mouse pointer over any vt
<Sarvatt> thats what happens here with the stock packages
<seb128> vt7 goes away = it's in text mode with some fsck lines which seems to come from boot
<Sarvatt> puts me to vt8 and i have a mouse over my vt's
<seb128> but ps still lists the GNOME processes running
<seb128> I get no backtrace in Xorg.0.log though
<seb128> nor error
<Sarvatt> weird that i dont get any errors outside of the segfault message in dmesg, nothing in Xorg.0.log or /var/log/gdm/:0.log (which is just a copy of /var/log/Xorg.0.log)
<bryyce> Sarvatt, is that with or without patch 100?
<Sarvatt> the stock packages in lucid
<bryyce> patch 100 changes how the crash is reported
<Sarvatt> with
<bryyce> hm
<seb128> without the patch I don't get apport triggering which is expected
<bryyce> with patch 100 should give *more* info not less
<seb128> but it's not written in Xorg.0.log either
<seb128> with the patch I get apport triggering
<bryyce> ok, 
<seb128> that's the stacktrace I copied on the chan earlier if you read backlog
<seb128> earlier being some 9 hours ago
<bryyce> well I do know there are situations where X can crash but no backtrace goes into Xorg.0.log so that's not too unusual
<bryyce> seb128, yeah going through it now
<Sarvatt> maybe its a second xserver trying to start thats actually crashing for me and the first stays up
<bryyce> seb128, you're right that line #6 looks weird.  #6 0x00000000 in ?? ()
<bryyce> line 585 in log.c is         AbortServer();
<bryyce> my guess there is that AbortServer() calls AbortDDX(), which is a virtual function called differently for different hw's
 * bryyce ponders
<jcristau> yeah so there was two issues.  first is why was it calling FatalError in the first place, and then why FatalError was calling a null function pointer
<bryyce> could in the guest mode case, it's using some hw thingee with no defined AbortDDX()?
<jcristau> it's all Xorg afaik..
<bryyce> ok well as to the question of why it's calling FatalError in the first place, it's this code:
<bryyce>         if (screenInfo.numScreens < 1)
<bryyce>             FatalError("no screens found");
<bryyce> so that *should* be just our nice friendly neighborhood "No screens available" error
<bryyce> maybe it's a miscommunication between X and gdm about what screen number to use
<bryyce> next step for that probably would be to examine what args X is getting called with (ps should say)
<bryyce> and compare with what gdm is actually doing
<jcristau> one reason i'm sort of uncomfortable with the os/log.c patches is that this is touching signal handlers, and there's not a lot of stuff you can do safely in signal handlers
<bryyce> Sarvatt / seb128, in the case where you aren't using patch 100, can you confirm whether you are seeing "No screens found" listed in one of the gdm log files?
<Sarvatt> going to take about 30 minutes to build here, speedy atom cpu :)
<jcristau> but we wouldn't get in these signal handlers if stuff worked fine in the first place so that doesn't explain why it fails InitOutput..
<bryyce> jcristau, well I can certainly say I don't like how much code patch 100 touches.  The old patch was a lot more concise.  But due to the way signal handling stuff has changed it was not as easy to keep all the code in one place
<bryyce> jcristau, I know messing with the signal handlers is bad but we have to get apport hooked in somehow, and the X signal handling stuff eats the signals by default, which prevents apport from working
<jcristau> ack
<bryyce> jcristau, I would *love* it if we could render this into something worth upstreaming, I hate having to maintain this patch as ubuntu-only
<Sarvatt> would the sudo DISPLAY=:0 xinit& output be useful at all? because thats what I see in gdm's log and what the s3 guy's gdm log showed
<bryyce> Sarvatt, couldn't hurt
<jcristau> gdm is calling xinit?
<Sarvatt> http://paste.ubuntu.com/357228/
<Sarvatt> http://paste.ubuntu.com/357230/
<Sarvatt> second one was the GdmLog attached to the savage bug
 * bryyce ews lines 15-17
<bryyce> Sarvatt, ok what we need is what the X command line was, to see if it was indeed trying to start two X's on :0
<bryyce> Sarvatt, and if so, instrument gdm to show its work
<bryyce> jcristau, hmm, looking at seb128's backtrace, it is crasing on this bit of code in CloseWellKnownConnections():
<bryyce>     for (i = 0; i < ListenTransCount; i++)
<bryyce>         _XSERVTransClose (ListenTransConns[i]);
<bryyce> any ideas on what this does?
<Sarvatt> hmm cant get gdb to load the symbols for xserver-xorg-core-dbg or -dbgsym
<bryyce> hmm, looking at Xtrans.c, it doesn't have null pointer checking, so if ListenTransConns[i] is NULL, it'd crash.  Perhaps that bit of code needs to do some nullptr checking?
<seb128> Sarvatt, symbol /usr/lib/debug/usr/bin/Xorg
<seb128> (I'm not really around, just passing in front of computer)
<Sarvatt> thanks seb128, used to load that automatically
<seb128> right, it's buggy for some reason
<Sarvatt> guess it just plain wont load the dbgsym symbols at all
<Sarvatt> -dbg worked though
<bryyce> Sarvatt, ok I think I understand the crash
<Sarvatt> fix = disable xace/xselinux? :D
 * Sarvatt hides
<bryyce> Sarvatt, main() notices theres no screens so issues a FatalError(), which is fine
<bryyce> now in FatalError(), it calls AbortServer() (which is just a pass-through to SigAbortServer(0))
<bryyce> here's where it gets fun
<bryyce> SigAbortServer calls CloseWellKnownConnections() to do some sort of cleanup I don't understand
<bryyce> it continues on with cleanup work
<Sarvatt> ending secure connections thanks to selinux support?
<bryyce> somewhere this triggers signal 11
<jcristau> Sarvatt: xselinux is disabled in ubuntu..
<bryyce> so now we find ourselves in OsSigHandler()
<bryyce> so now it hits FatalSignal(11) (fine), and here we get to SigAbortServer(11)
<bryyce> again, it calls CloseWellKnownConnections()
<bryyce> but this time through, the stuff has already been cleared, so a null pointer gets called
<bryyce> *boom*
<bryyce> so... we have three bugs
<bryyce> a) why is X getting called by gdm with :0 twice 
<bryyce> b) why is the signal 11 being thrown during an ordinary FatalError() call?
<bryyce> c) why is CloseWellKnownConnections() brittle at being called twice?
<bryyce> c could be fixed by just adding a nullptr check in the Xtrans stuff.  dunno if that's warranted
<Sarvatt> just starting /usr/bin/Xorg I get the same segfault, dont even have to specify :0
<jcristau> Sarvatt: :0 is the default
<bryyce> or actually we could probably handle the nullptr check in CloseWellKnownConnections()
<jcristau> Sarvatt: so if you don't give a display it uses that
<bryyce> anyway, wife says I must eat, so bbiab
<Sarvatt> whats with the trash after ddxSigGiveUp: Closing log? http://paste.ubuntu.com/357244/
<Sarvatt> yeah same here, wife's waiting for me to make dinner :D
<bryyce> o_O
<bryyce> Sarvatt, aha.  Looks like there are some error messages logged after the log is closed.
<bryyce> that can't be good
<bryyce> Sarvatt, boy I bet that's the explanation for the sig 11 throw
<bryyce> totally
<bryyce> ok easy fix
<Sarvatt> woohoo!
<bryyce> hmm, I wonder if this is the same root cause for bugs like lp #508035
<ubottu> Launchpad bug 508035 in xorg-server "Xorg crashed with SIGSEGV in <signal handler called>()" [Medium,New] https://launchpad.net/bugs/508035
#ubuntu-x 2010-01-16
<Sarvatt> bryyce: changing line 308 in platform/gtk-x11/setup.py to             return "%s-mt-py26" % s seems to have worked for me
<Sarvatt> wrong channel :D
<Sarvatt> dont think that patch is working right yet
<Sarvatt> http://pastebin.ubuntu.com/357346/
<Sarvatt> hmm xserver build is screwy, configure: DRI2 AIGLX disabled, __DRI_DRI2 not defined in dri_interface.h.
<Sarvatt> guess its my build environment thats screwy, not doing that on a PPA
<bryyce> crashing at a different spot
<Sarvatt> well disabling 100 works
<Sarvatt> un-fixing gdm to try guest session with a non-segfault-on-fatal-error xserver and see what interesting things happen
<Sarvatt> it works with the current GDM
<bryyce> Sarvatt, with the updated patch from -1ubuntu7?
<Sarvatt> no with 100 dropped completely
<Sarvatt> 1ubuntu7 still segfaults :(
<bryyce> ??
<bryyce> *sigh*
<Sarvatt> just run X from gnome-terminal, you'll get the same segfault
<Sarvatt> thats what i pasted up there, looks like that with 1ubuntu7 :(
<Sarvatt> you changed PY to P9 now though (the 2 letters that always appear in the junk :)
<Sarvatt> http://paste.ubuntu.com/357364/
<Sarvatt> without 100 I get that, and guest session works without any changes
<Sarvatt> well I shouldn't say just without 100, I disabled most ubuntu patches that time including 160 too
<bryyce> hrm, well there's a couple ErrorF()'s in FatalSignal
<bryyce> I *think* those go before the log gets closed but would be easy to test disabling them
<bryyce> or maybe this bit of the patch needs to be more elaborate:
<bryyce> +        if (signo != 0) {                                                                                            
<bryyce> +            raise(signo);    
<bryyce> like maybe only raise on specific signals
<bryyce> ok, wife is telling me to get off the computer
<bryyce> lemme know if you sort it out, else maybe we should just chuck the patch and not have apport giving us crash bugs ;-)
<vish> huh.. the guest session X crash also arises with "switch user"
#ubuntu-x 2010-01-17
<superm1> bryyce, or tjaalton can you guys subscribe https://edge.launchpad.net/ubuntu/+source/libvdpau/+subscribe to ubuntu-x?  There shouldn't be too much ever in the bug mail, but I think that's the most appropriate goto subscriber
<bryyce> superm1, sure done
#ubuntu-x 2011-01-10
<alex_mayorga1> Amaranth: I got 1405 from that command
<alex_mayorga> bryceh: ping
<alex_mayorga> yofel: ping
<afiestas> Hi, do you think that is possible to add this patch: https://bugs.freedesktop.org/show_bug.cgi?id=32828 in the current kernel?
<ubot4> Freedesktop bug 32828 in Driver/intel "HDMI detected as DVI some times" [Normal,New]
<afiestas> https://bugs.freedesktop.org/attachment.cgi?id=41755 <--direct link to the patch
<afiestas> all Dell computer that once were sold with Ubuntu are affected (afaik)
<afiestas> inspiron, xps, etc
<afiestas> all with I965 of course
<bryceh_> Sarvatt, you here in spirit?
<tjaalton> spirit!=sprint?-)
<tjaalton> heh, so it's just as cold down there as it is here next to the polar circle
<tjaalton> but you get more sunlight, i bet
<bryceh_> heya tjaalton
<bryceh_> tjaalton, yeah cjwatson said he was expecting it to be warm and hadn't planned on bringing warm clothes, but happened to bring them by accident
<tjaalton> heh, good for him :)
<bryceh_> just had a Unity / Desktop review meeting.  unloaded all our unity gripes onto the Dx team.
<cnd> bryceh: the x gestures bug requires an upload of xserver-xorg-input-evdev too
<cnd> do you know where that stands?
#ubuntu-x 2011-01-11
<mpoirier> phononlogger: good morning
#ubuntu-x 2011-01-12
<bryceh_> http://www.linux.com/news/hardware/desktops/166625-blaming-intel-for-how-the-world-is
<JanC> bryceh_: so basically, Intel tries to sell PC hardware to embedded device makers and is surprised PC makers use it?   :P
<bryceh_> JanC, or that users might want to upgrade it
<bjsnider> i don't see why intel doesn't just buy the company that makes the poulsbo chip and then open-source the driver
<JanC> bjsnider: because Intel, Apple, and maybe also ARM all need ImgTec, and none of them want the others to buy it
<bjsnider> why am i being spammed with build failures?
<RAOF> bjsnider: Because you're subscribed to xorg-edgers and Robert's just uploaded the universe?
<bjsnider> yeah but the build failed
#ubuntu-x 2011-01-13
<cnd> bryceh, the branch on bug 670016 for evdev looks correct
<ubot4> Launchpad bug 670016 in xserver-xorg-input-evdev (Ubuntu Maverick) (and 3 other projects) "[SRU] Xorg crashes when performing gesture (affects: 2) (dups: 1) (heat: 20)" [Undecided,Fix committed] https://launchpad.net/bugs/670016
<cnd> please doublecheck the xorg-server requirements version for me
#ubuntu-x 2011-01-14
<seidos> i'm trying to download the source code for intel_agp driver.  i tried searching apt-cache for intel_agp but there were no hits.  any other ideas?
<gymeleou> I'm having instability problems with Lucid / intel 845G. I don't see any workarounds for 845 in https://wiki.ubuntu.com/X/Bugs/Lucidi8xxFreezes, is there anything else I can try?
<ricotz> RAOF, hello :), is the current xserver 1.10 pre-release in xedgers working with the latest nvidia blob?
<RAOF> ricotz: I don't believe so.  It might not even be the final 1.10 video ABI.
<RAOF> ricotz: I didn't test it because I didn't expect it to work.
<ricotz> RAOF, ok, then i need to stay at the current snapshot then until a usable 2.6.38rc is available
<ricotz> RAOF, but intel should be fine?
<RAOF> ricotz: Works on this very laptop, yes.
<bjsnider> nvidia might work with the ignoreabi option
<ricotz> RAOF, nice are you looking into rebuilding the missing drivers?
<ricotz> bjsnider, hmm, could you try it first? :P
<RAOF> bjsnider: Possibly, but I think it's likely to crash this time around :)
<bjsnider> no, but you could
<ricotz> i think i wont risk it, yet
<RAOF> ricotz: There's only wacom (and a bunch of other less useful drivers) to rebuild.  I was going to wait for one of Sarvatt's upload-the-world to do that for me :)
<ricotz> RAOF, i am thinking of synaptics
<RAOF> ricotz: Done, like a jimmyhack.
<ricotz> RAOF, hmm, right
<ricotz> RAOF, the last synaptics version had an epoch
<ricotz> s/the/my
<ricotz> RAOF, works on my 965gm :)
<bryceh_> http://pastebin.com/jjap8mbg
<bryceh_> RAOF, ^^
<RAOF> Ta.
<bryceh_> This includes snapshots for the upcoming xserver 1.10 and mesa
<bryceh_> 7.10, along with some new driver bits. 
<mdeslaur> bryceh: did the portland mafia reserve a bus to the airport tomorrow?
<bryceh_> mdeslaur, they're discussing it currently
<bryceh_> mdeslaur, looks like you, me, and brian at least are going at the same time
<mdeslaur> bryceh_: zul also
<bryceh_> mdeslaur, so probably safe to assume we'll have a bus or something.  brian will know details
<mdeslaur> bryceh_: thanks
<alex_mayorga> bryceh: ping
<bryceh_> alex_mayorga, yep
<alex_mayorga> bryceh_: can you take a peek at bug 696104
<bryceh_> alex_mayorga, we're in the desktop team room, Lonestar II on 4th floor if you want to do higher bandwidth
<ubot4> Launchpad bug 696104 in xserver-xorg-video-nouveau (Ubuntu) "nvidia 320m locks up (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/696104
<bryceh_> alex_mayorga, ok looking
<alex_mayorga> I've uploaded the dmesg on the 3 most recent lock ups there
<bryceh_> [   26.112364] [drm] nouveau 0000:01:00.0: PFIFO_BAR_FAULT - VM: Trapped write at 000109f080 status 01040206 channel 0 (0x00000040)
<bryceh_> wonder what that means
<RAOF> Hm.  Writing to invalid memory?
<alex_mayorga> by mesa-dri-experimental you mean libgl1-mesa-dri-experimental
<bryceh_> also in one of the dmesg's
<bryceh_> [ 4169.510090] ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20101013/evregion-474)
<bryceh_> [ 4169.510110] ACPI Error: Method parse/execution failed [\_SB_.LID0._LID] (Node ffff88013763caa0), AE_TIME (20101013/psparse-537)
<bryceh_> alex_mayorga, yeah
<alex_mayorga> bryceh_: so I remove that and hope the lockups go away?
<bryceh_> alex_mayorga, yeah
<RAOF> IIUC PFIFO is the command FIFO, BAR_FAULT indicates that the command is attempting to access the BAR in an inappropriate way.
<bryceh_> alex_mayorga, for the lock up associated with the first dmesg.txt, do you recall about how long the system was up before it locked?
<alex_mayorga> I boothes at around 7:30 and the dmesg I captured at 11:44
<alex_mayorga> so around 4 hours
<bryceh_> ok, that ACPI error was after about +1 hrs so is probably unrelated
<bryceh_> that BAR_FAULT bit occurred during boot so is probably unrelated too
<bryceh_> looks like none of these have error messages corresponding to the freezes
<bryceh_> alex_mayorga, so yeah, next step is reproduce without 3D.  Then after that the bug can be forwarded upstream
<RAOF> Strange.  Nouveau generally will spew an incomprehensible PFIFO_$SOMETHING.
<bryceh_> alex_mayorga, or if you can't reproduce it, then !3D is going to have to be the workaround for you for now
<alex_mayorga> bryceh_: don't quite get the last message, can you dumb it down a notch, please?
<bryceh_> alex_mayorga, ah sorry.  The next step is to remove libgl1-mesa-dri-experimental and see if the issue goes away.  If it does not go away, then we can report it upstream for further investigation.
<alex_mayorga> bryceh_: anything I should be aware of prior to removing the package or would apt take care of me?
<bryceh_> alex_mayorga, if it does go away, well upstream is not accepting bug reports for 3D so there isn't anything we can do, so you'll just have to run without that package installed (and thus no 3D functionality for now)
<bryceh_> alex_mayorga, I think apt should take care of it.  You'll want to restart X (or reboot), for the changes to take effect.
<alex_mayorga> OK, thanks again bryceh_
<alex_mayorga> that GeForce with CUDA is certainly just a sticker to me
<alex_mayorga> :(
#ubuntu-x 2011-01-15
<bjsnider> that frigin' wagom driver just won't build, will it?
<bjsnider> er, wacom
<bjsnider> quilt needs to be added to the build-deps
<Takyoji> Since Wacom devices operate under X; would anyone be of assistance for a Wacom BambooFun tablet?
<Takyoji> The device is powered and everything, just no input is shown (such as manipulating the cursor, clicking, etc)
<ripps> Takyoji: my bamboo did that too, try install linux-backports-modules-input-maverick-generic
<Takyoji> a PPA, package, or?
<ripps> Takyoji: that's in the maverick repos for maverick kernels
<watermains> hello, can't see if anyone is in here: I need help
<watermains> I installed the nvidia drivers under the X updates repository but now when I load up "Hardware Drivers" it tells me "This driver is activated but not currently in use".  I try to run xconfig but get this error: sudo: nvidia-xconfig: command not found" Should I install fglrx-installer?
<llstarks> stupid power converter
<llstarks> i'm glad i brought my mouse to israel
<DanaG> Say, how the heck do you get xorg to reload the input rules, without entirely restarting X?
<DanaG> You used to be able to do it with HAL... and with udev... but I can't figure out how to do it now.
<DanaG> And if the answer is, "you can't", it's a regression.
<ryrych> good evening
<ryrych> is anybody out there? I've got a few questions
<ryrych> hi kklimonda!
<evilvish> !ask | ryrych 
<ubot4> ryrych: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<ryrych> I've been using radeon driver from Ubuntu-X on Kubuntu 10.10. When kWin effects are turn on after some time X crashes. I'd like to make sure what package I have to fill bug report against? The same error I get on radeon version from 10.10 (without Ubuntu-X). But it is important because version from Ubuntu-X will be used in Natty.
<ryrych> evilvish: OK, here you go :)
<evilvish> ryrych: what do you mean "radeon driver from Ubuntu-X" ?  you mean the x-edgers ppa?  or which ppa are you referring to?
<ryrych> evilvish: oh, sorry it should be x-updates: ppa:ubuntu-x-swat/x-updates
<evilvish> ryrych: https://launchpad.net/~xorg-edgers has info on the top, mentions how to file bug reports.. you could do the same for x-updates
<evilvish> ryrych: btw, x-updates has all old packages, which version are you using it for?
<evilvish> well, not very old.. just old as in 'last month' ;p
<ryrych> evilvish: for xserver-xorg-video-radeon: 1:6.13.2-0ubuntu1~xup1
<evilvish> ryrych: in maverick?
<ryrych> evilvish: yes, in maverick
<evilvish> ryrych: well, that is older ..(2010-09-28) â¦ while edgers has 1:6.13.99 .. not sure which is landing in natty  â¦ are you sure that the package from x-updates is the one landing in natty?
<evilvish> ryrych: anyway.. to file a bug just use "ubuntu-bug xorg" and mark the description with "[x-updates]"
<ryrych> evilvish: don't fill it in freedesktop?
<evilvish> ryrych: not sure about that.. 
<ryrych> evilvish: I think this bug is similar to mine: https://bugs.freedesktop.org//show_bug.cgi?id=29148
<ubot4> Freedesktop bug 29148 in GLX "KWin segfaults when OpenGL desktop effects are enabled" [Normal,New]
<ryrych> evilvish: and 1:6.13.2-1ubuntu2 will make it into Natty
<evilvish> ryrych: well, if that fdo bug is the same issue you are facing, edgers aint going to fix it either(there is a comment from someone using edgers).. ;)
<ryrych> evilvish: it was a half year ago, maybe something changed? ;)
<evilvish> ryrych: there seems to be a patch which hasnt been applied in main, anyway.. you should try during weekdays when the main X folk are around..
<evilvish> oh wait, it is in main..
<ryrych> evilvish: suppose I'd like to try out xorg-edgers. Can I install only a driver?
<evilvish> ryrych: from the usptream bug it looks like you need to update mesa , the xserver-xorg-video-radeon seems not the issue
<evilvish> upstream*
<evilvish> ryrych: and x-updates doesnt have a mesa newer than the maverick stock, might be the reason why you saw no improvement with the ppa
<ryrych> evilvish: so what do you suggest? Fill a report in launchpad, fill a report in freedesktop, or install some pkgs (which?) from a ppa?
<evilvish> ryrych: well, you can try edgers first before filing the bug.. you'd have to test the latest at some point ;)   [but from the comments on the bug the proposed commit does not fix for the reporter, (but if you are having different hardware, might work?)]
<evilvish> edgers sounds all scary, but we can purge it if it does not solve anything...
<evilvish> ryrych: curious though, why the two reporters have not mentioned any issues after 7-21..
<ryrych> evilvish: OK, I'll give edgers a spin but please tell me which package install first to get the rest of the dependencies?
<evilvish> ryrych: use synaptic.. add the ppa and select 'mesa' to update, it will say what else needs to be updated 
<evilvish> just the packages you get when you search 'mesa', like libgl1-mesa , -glx , -dri
<ryrych> evilvish: thanks and bye for now :)
<evilvish> np..
<ripps> Takyoji: did you get your wacom working?
#ubuntu-x 2011-01-16
<penguin42> I was told there was a new X build going onto edgers over the next few days; has it landed yet or is it still worth waiting?
<hyperair> hi. is there some Cool New Featureâ¢ in xorg-edgers these days that suddenly makes VGA cable autodetection work awesomely?
<bryceh> hyperair, how do you mean?
<hyperair> bryceh: i connect my monitor to my laptop via VGA cable. ubuntu automagically detects the new monitor, figures out that i want the monitor on the left of the LVDS (i've configured it this way before via gnome-display-properties), and automatically sets it up as such
<hyperair> bryceh: i pull out the VGA cable from my laptop, and it detects that the monitor is gone, and switches back to single monitor mode using LVDS
<hyperair> bryceh: in addition, pressing that special fn+f3 combo (for switching outputs) toggles between cloned, monitor-only, monitor-on-left, monitor-on-right, and lvds-only
<hyperair> bryceh: the surprising thing is that super+p seems to do the same thing. now, i'm wondering what exactly handles all this magic, and whether super+p is configurable somewhere
<bjsnider> hyperair, so, you're fairly happy with this state of affairs, yeah?
<hyperair> bjsnider: i'm fairly happy with this state of affairs, yes.
<hyperair> bjsnider: it's just that i keep accidentally hitting super+p
<bryceh> hyperair, ah, yeah I think that's not particular to xorg-edgers, I've noticed it doing that behavior throughout natty
<bryceh> hyperair, guessing its the new gnome-display-properties able to more smartly respond to monitor hotplug events
<bjsnider> that would mean gnome is now superior to xp int hat regard, although maybe just on par with vista and beyond
#ubuntu-x 2012-01-09
<tjaalton> morning folks
<Sarvatt> <Sarvatt> bryce, RAOF: been updating to precise and all that fun stuff all morning, looks like i'm going to have to recompile unity too before the ppa is usable
<Sarvatt> <Sarvatt> tjaalton: oh wait, chase put unity in the staging ppa!
<Sarvatt> <Sarvatt> tjaalton: so are you saying even with that unity its still broken?
<Sarvatt> guess those didn't go through the first time :)
<RAOF> Yup, that's right.
<RAOF> Oh, actually?
<RAOF> Does unity in the staging PPA work against the staging X server?  It didn't last time I tried.
<tjaalton> hmm, i might have tried it at some point too
<Sarvatt> so that means chase's fix didn't really fix it?
<tjaalton> strange but i really miss unity by now
<tjaalton> g-s feels just weird after using it for nearly three weeks..
<tjaalton> right, doesn't work
<Sarvatt> well crap
<Sarvatt> there goes any chance of us even getting it in this week
<Sarvatt> there hasn't even been a unity update yet in precise has there?
<RAOF> No.
<RAOF> That's planned for this week, though.
<Sarvatt> synaptics doesn't work at all with x-staging on this macbook air, using evdev kills all touchpad/keyboard input. whee :)
<Sarvatt> not to mention, qt being in the ppa makes it a major PITA to revert
<Sarvatt> because of all the :i386 qt libs
<RAOF> git clone git://anongit.freedesktop.org/mesa/mesa
<RAOF> sudo apt-get build-dep mesa
<RAOF> LLVM_CONFIG=/usr/bin/llvm-config-2.9 ./autogen.sh --with-dri-drivers= --with-gallium-drivers=swrast
<tjaalton> what are you trying?-)
<RAOF> Unity-on-llvmpipe.
<tjaalton> btw, kibi has packages for mesa master
<RAOF> Woot!
<tjaalton> which has llvmpipe replacing the old swrast
<tjaalton> well, a branch somewhere, not actual packages
<RAOF> Near enough :)
<tjaalton> so there's further work needed for libxatracker or what was it
<RAOF> :)
<tjaalton> hmmh, there really should be a way to get people test a newer kernel right after filing a bug
<tjaalton> from the mainline ppa
<ricotz> RAOF, hi, a rebuild of virtualbox would be reasonable for the x-staging ppa
<RAOF> Hm.  Did I miss that?
<jcristau> hm.  virtualbox and reasonable in the same sentence.
<ricotz> RAOF, it isnt in there and the guest x-drivers would need a rebuild
<ricotz> jcristau, heh
<RAOF> I wonder why I didn't pick that up in the mass rebuild.
<FernandoMiguel> evening
#ubuntu-x 2012-01-10
<Sarvatt> RAOF: so the spinning at 100% cpu usage bug with the newer X is utouch-geis, downgrading to the oneiric one fixes that
<RAOF> Whee!
<tjaalton> great
<Sarvatt> RAOF: apparently cnd's unity in the PPA also works after downgrading utouch geis with x-staging, woohoo
<tjaalton> confirmed!
<RAOF> Wooo!
<Sarvatt> now who to bug about utouch-geis
<tjaalton> chase?? :)
<tjaalton> -?
<ricotz> https://bugs.launchpad.net/ubuntu/+source/utouch-geis/+bug/879348
<ubot4> Launchpad bug 879348 in utouch-geis (Ubuntu) (and 1 other project) "evince segfaults (affects: 9) (dups: 2) (heat: 36)" [Undecided,Incomplete]
<ricotz> so i guess https://launchpad.net/~bregma
<ricotz> hello
<tjaalton> yeah
<ricotz> https://bugs.launchpad.net/ubuntu/+source/utouch-geis/+bug/898175
<ubot4> Launchpad bug 898175 in utouch-geis (Ubuntu) "uTouch hangs using XCB back end if X server does not support gesture protocol (affects: 6) (heat: 28)" [Undecided,Confirmed]
<Sarvatt> yep thats the one
<Sarvatt> ricotz: i see what you mean about acceleration being different in newer synaptics :)
<tjaalton> .xsessionrc isn't read on startup, meh
<Sarvatt> ricotz: heh that was close, almost uploaded git xserver when there's abi breaks that are going to get reverted
<ricotz> Sarvatt, oh, 1.11 branch or master?
<Sarvatt> ricotz: master http://www.mail-archive.com/xorg-devel@lists.x.org/msg27845.html
<ricotz> oh
<ricotz> i was hoping to push an update too
<ricotz> Sarvatt, so 1.12 for edgers ;)
<Sarvatt> yeah was about to upload it when timo pointed that out :)
<ricotz> i guess you need to push some deps first
<Sarvatt> got them locally
<ricotz> like x11proto-input 2.1.99.5
<ricotz> ok
<Sarvatt> guess i'll just push the proto and copy your xserver actually
<Sarvatt> and reupload all drivers
<ricotz> you can copy the proto too
<Sarvatt> oh thought you had 2.1.99.3, even easier
<ricotz> jammed ppa builders doesnt make it easy
<Sarvatt> wow hardly any builders atm
<Sarvatt> yeah better off waiting
<ricotz> tjaalton, hi, could you update libwacom and maybe upload, they released 0.1
<ricotz> tjaalton, to debian
<tjaalton> ricotz: upload to debian? no
<tjaalton> oh libwacom
<ricotz> tjaalton, yes, is this possible?
<tjaalton> i can update git, but not upload there
<ricotz> and to ubuntu?
<tjaalton> ubuntu yes
<ricotz> this would be nice!
<ricotz> g2g, bye
<seb128> ricotz, tjaalton: you guys packages libwacom?
<tjaalton> seb128: it's not uploaded yet, but packaged yes
<seb128> grrr
<seb128> http://launchpadlibrarian.net/89491492/libwacom_0.1-0ubuntu1_source.changes
<tjaalton> oh it was :)
<seb128> robert_ancell did package it today
<tjaalton> ah
<seb128> tjaalton, no, it's work duplication
<seb128> <- bit annoyed
<tjaalton> why not ask before? :)
<seb128> we asked bryce and RAOF here at the platform rally before starting on it
<tjaalton> ok
<seb128> they didn't know that you were working on it apparently
<seb128> well anyway, it's done
<tjaalton> yeah ok
<tjaalton> it was discussed here mid-december'ish
<seb128> it's just annoying that people get stuff in ppas and other redo the same work in the archive
<tjaalton> forgot about it due to the holidays
<seb128> no worry
<tjaalton> we've forked all of wacom by now, since it's not maintained in the xsf git on debian
<tjaalton> so I pulled ricotz's package and pushed it to my personal git space (writable by pkg-xorg)
<tjaalton> (like -wacom)
<tjaalton> seb128: do you want to maintain it? there was some confusion about what the consumers were, since the driver didn't need it at that point
<tjaalton> and probably still doesn't
<tjaalton> but will
<seb128> tjaalton, we don't especially want to maintain it ;-)
<seb128> robert_ancell wanted to build g-c-c from git
<seb128> which requires it
<tjaalton> yeah
<seb128> so it was a "scratch an itch"
<jcristau> gnome requires wacom?
<jcristau> wow...
<tjaalton> jcristau: the capplet does, libwacom
<seb128> jcristau, they are a wacom configuration capplet
<tjaalton> it's the source of all the model->feature mappings, and the driver will end up using it too
<jcristau> you'd think the driver would expose what features are there, so the clients wouldn't need to guess
<jcristau> or, well, s/you/i/
<tjaalton> hmm, maybe I should adjust the packaging to match the libwacom upload then
<tjaalton> libwacom0 vs libwacom-0 for instance
<Sarvatt> ricotz: mind copying mesa from edgers to your unstable ppa?
<Sarvatt> tempted to binary copy the proto and 2 libs and xserver from your ppa but that'd still mean edgers would be broken for 5 hours before i could upload drivers then another 5 hours waiting for those to build
<Sarvatt> also yay OpenGL version string: 3.0 Mesa 7.12-devel
<tjaalton> seb128: would robert mind if I merged some of the changes and reuploaded that instead?
<seb128> tjaalton, go for it
<tjaalton> seb128: ok thanks
<seb128> tjaalton, he just wanted to see that in so we can build g-c-c easily
<tjaalton> seb128: well, I'm going to revert the libwacom-0 package name to just libwacom0, seems more "correct" to me, and multiarchify it too
<seb128> ok
<seb128> tjaalton, what's the lib name on disk?
<tjaalton> not sure :)
<tjaalton> I need to build it first to see
<tjaalton> but I think it's libwacom.so.0
<tjaalton> good that he added the symbols file
<tjaalton> seb128: can you drop the package from NEW?
<tjaalton> I'll get it done before lunch
<seb128> tjaalton, done
<tjaalton> seb128: nice thanks
<seb128> yw
<tjaalton> ./usr/lib/libwacom.so.0.0.0
<seb128> I wonder why he added a "-" then, seems wrong
<tjaalton> yeah, but in any case it wasn't all for nothing, I'll merge the good bits :)
<seb128> good
<tjaalton> seb128: meh, some issues with the git repo having stuff the tarball doesn't, so I need to look at that before uploading, after lunch for sure :)
<seb128> tjaalton, ok
<Sarvatt> tseliot: nvidia is defaulting to nvidia-173 in precise?
<tseliot> Sarvatt: no, I don't think so, unless someone else changed its priority to something bigger than nvidia-current's. update-alternatives --display x86_64-linux-gnu_gl_conf should show what's going on
<tseliot> or -display i386-linux-gnu_gl_conf if your system is i386
<Sarvatt> bryce was saying there is a flood of bug reports where jockey is defaulting to nvidia-173 instead of nvidia-current
<Sarvatt> in precise
<tseliot> Sarvatt: maybe the card is not marked as supported? What bug reports are you referring to?
<tseliot> oh boy, I forgot to patch the drivers to build against linux 3.2...
<tjaalton> :)
<bryceh> yeah, 2 bugs
<bryceh> a.  nvidia-173 doesn't build against the new kernel
<bryceh> b.  for some reason jockey defaults to nvidia-173 a lot when it shouldn't
<bryceh> a. is lp #576648
<ubot4> Launchpad bug 576648 in nvidia-graphics-drivers-updates (Ubuntu) (and 4 other projects) "package nvidia-* failed to install/upgrade: nvidia-* kernel module failed to build (Unable to determine the target kernel version.) (affects: 213) (dups: 195) (heat: 1502)" [Undecided,Triaged] https://launchpad.net/bugs/576648
<bryceh> b. is lp #876499
<ubot4> Launchpad bug 876499 in jockey (Ubuntu Precise) (and 2 other projects) "Incorrect Nvidia driver installed by checking 3rd party box (affects: 8) (dups: 6) (heat: 60)" [High,Triaged] https://launchpad.net/bugs/876499
<tseliot> bryce: oh, there's a merge request for a) already. I wasn't notified though...
<tseliot> bryceh: I'll take care of both bugs. Thanks
<bryceh> tseliot, great
<bryceh> tseliot, I suspect b. is something wrong in jockey's nvidia internal selection logic.
<bryceh> tseliot, comment #17 describes as far as I got analyzing it
<tseliot> bryceh: the weird thing is that, according to the bug report, nvidia-common makes the right choice, so I'm wondering what's going on in Jockey...
<bryceh> tseliot, I wonder if it is something peculiar with the installation environment
<tseliot> bryceh: maybe something else is pulling nvidia-173 in?
<tseliot> so yes, it could be the environment
<bryceh> tseliot, don't think so; it seems to be jockey specifically deciding it's the driver it wants
<tseliot> bryceh: but it's designed to pick whatever nvidia-common says it's best for the card
<bryceh> ironically, one of the community folks has been dutifully duping all these bugs together, but since he's duping against a really old bug report, that has kept it off my radar
<tseliot> too bad
<tjaalton> seb128: uploaded libwacom to the queue, btw
<seb128> tjaalton, thanks
<FernandoMiguel> evening
<Sarvatt> bryce: funny because I was digging through 9xxxxx bugs trying to find it and didn't, no wonder :)
#ubuntu-x 2012-01-11
<FernandoMiguel> nite
<FernandoMiguel> oias
<Sarvatt> bryce: xdiagnose failed to install..
<Sarvatt> doh
<Sarvatt> bryce: oh nevermind, fixed in 2.1
<Sarvatt> so THATS what you were talking about after dinner
#ubuntu-x 2012-01-12
<bjsnider> if i send a control file with multiarch in it to lucid/mav/natty ppa will the build system reject it?
<bjsnider> or ignore it?
<Prf_Jakob> bryce, Sarvatt, RAOF: Branch made
<RAOF> Prf_Jakob: Sweet!
<RAOF> Sarvatt: Hey dude.  Is there a nice package of the new dri2 protocol anywhere?
<RAOF> Sarvatt: Oh, presumably it's in edgers.  Sorry :)
<Sarvatt> RAOF: what exactly are you looking for?
<Sarvatt> dri2proto is up to date in the distro
<RAOF> I'm looking to build libxcb against the newer xcb-proto
<Sarvatt> oh no havent done xcb-proto yet
<RAOF> Oh, *I've* done xcb-proto.
<RAOF> But it's failing to build, and I thought that would be the problem.  Maybe not.  Boo.
<RAOF> (And by "done", I mean "have uupdated the package")
<Sarvatt> so you probably need xcb-util updated
<Sarvatt> oh nope
<Sarvatt> how's it failing? is_switch failure?
<RAOF> http://paste2.org/p/1863662
<RAOF> Any ideas?
<Sarvatt> nope haven't seen that one, going to grab it all and check it out
<Sarvatt> thats building libxcb 1.8?
<RAOF> That's building libxcb 1.7.
<jcristau> with the new xcb-proto installed?
<RAOF> With the new xcb-proto installed, yes.
<RAOF> Is there tight coupling between libxcb and xcb-proto?
<RAOF> Heh.  libxcb1.8 *does* die in is_switch :)
<jcristau> new xcb-proto isn't supposed to break old libxcb afaik
<jcristau> but, maybe it does...
<RAOF> jcristau: Incidentally, why does xcb-proto declare a VCS-Git on freedesktop.org?  That's not where the packaging is.
<jcristau> initially it was there
<RAOF> Yeah; it's got the packaging for up to 1.1.
<RAOF> It's no longer maintained in git?
<RAOF> Bah.  I missed installing python-xcbgen.  Now it's breaking in my stuff :)
<jcristau> should be in collab-maint
<jcristau> i thought i'd fixed the vcs-* stuff
<jcristau> apparently not.
<RAOF> Unless the Ubuntu packages are behind, no :)
<jcristau> ah, libxcb has updated vcs-*, xcb-proto not.
<jcristau> fail
<RAOF> :)
<tjaalton> soo happy to see new xcb releases.. hope they fix the nasty threading issues that cause all sorts of crashes for some people
<tjaalton> can't link the bug since lp will timeout..
<Sarvatt> yeep AttributeError: 'Struct' object has no attribute 'is_switch', wish i could remember how we worked around that
 * Sarvatt digs through old PPAs
<RAOF> Sarvatt: I think the new python-xcbgen fixes that.
<tjaalton> oh, bug 905686 is a newer one with less dupes
<ubot4> Launchpad bug 905686 in nautilus (Ubuntu) (and 1 other project) "nautilus assert failure: nautilus: ../../src/xcb_io.c:528: _XAllocID: Assertion `ret != inval_id' failed. (affects: 19) (dups: 16) (heat: 140)" [Medium,Triaged] https://launchpad.net/bugs/905686
<tjaalton> this was apparently fixed upstream over a year ago, but near impossible to backport
<tjaalton> think i looked into that, could be wrong..
<Sarvatt> oh helps if i install that deb
<RAOF> :)
<jcristau> tjaalton: this stuff is nasty, each fix breaks something else
<tjaalton> jcristau: yeah, hoping it's sorted out by now..
<jcristau> RAOF: so, http://anonscm.debian.org/gitweb/?p=collab-maint/xcb-proto.git and http://anonscm.debian.org/gitweb/?p=collab-maint/libxcb.git are where the packaging lives now, if you want to update that
<RAOF> Why not!
<Sarvatt> libxcb symbol updates are always fun
 * RAOF has just passed -C0 for the moment.
<jcristau> if you don't have write access to collab-maint you can push the update somewhere else and let me/kibi/jd_ know where we can pull from
<RAOF> I think I've got collab-maint access.
<tjaalton> and me
<Sarvatt> http://sarvatt.com/downloads/patches/libxcb-1.8-symbols.patch thats what i've got so far on to build #9
<RAOF> Yeah, well, I'm adding protocol so it's changing for me anyway.
<RAOF> Clearly there are no pointer-barriers clients using XCB. :)
<Sarvatt> phew finally http://sarvatt.com/downloads/patches/libxcb-1.8-symbols.patch
<jcristau> are these sizeof things really meant to be exported?
<tjaalton> also, what does one lose if the symbols file just had "*@Base 0\n*@Base 1.8"?
<tjaalton> i've seen wildcards used like that
<tjaalton> like nss & nspr
<tjaalton> at least it would be much easier to maintain the file..
<jcristau> that works if you version your symbols
<jcristau> xcb doesn't do that
<tjaalton> right, nss does
<tjaalton> i'll get me coat :)
<inetpro> hi
<inetpro> has anyone had a chance to look at bug 897436 yet? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/897436
<ubot4> Launchpad bug 897436 in xserver-xorg-video-nouveau (Ubuntu) "Screen corrupted without nomodeset on nVidia Corporation GT215 [GeForce GTS 360M] (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/897436
<ubot4> inetpro: Error: Bug #897436 is private.
 * inetpro wonders what that means
<tjaalton> inetpro: just try with a newer kernel http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-precise/
<inetpro> tjaalton: I'll try again asap, thanks
<inetpro> but how do I know when to try?
<tjaalton> hm?
<tjaalton> nouveau is a kms-only driver, if it doesn't work you need to test a newer kernel
<tjaalton> that's the first step before wasting time on anything else
<tjaalton> now, I hope lp had a way to tell the bugreporter about that..
<inetpro> how often is the kernel updated in the daily builds?
<tjaalton> what daily builds?
<tjaalton> you can test a daily livecd, yes
<tjaalton> precise
<inetpro> I mean the daily livecd
<tjaalton> it has whatever kernel is the current one on the archive
<tjaalton> so precise has 3.2, while oneiric had 3.0
<tjaalton> which means there's a chance it's fixed in precise..
<inetpro> the last time I tried the daily livecd was on 2011-12-14 and there were no changes
<tjaalton> oh, missed that part of the bug
<tjaalton> ah, there's a kernel with drm-next
<inetpro> when do I know whether it is worth testing a livecd again?
<tjaalton> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/current/
<tjaalton> try that on oneiric
<tjaalton> precise has what it will ship with, there won't be big changes to the kernel anymore
<tjaalton> unless a fix ends up in 3.2.x
<inetpro> hmm
<tjaalton> but could be that you need to poke upstream devs about this..
<inetpro> I got it working perfectly as it is on oneiric but I just want to make sure that things will work out of the box on the next release
<tjaalton> right, so test that kernel to see if it's broken on current upstream code..
<tjaalton> if it works with it, we can bisect the fix
<inetpro> tjaalton: I'm not sure I get what you mean with test that kernel, how do I go about testing it
<inetpro> ?
<tjaalton> install it
<tjaalton> ?
<tjaalton> pick the image deb for your arch, dpkg -i $foo.deb
<inetpro> tjaalton: I do this after installing the livecd with nomodeset?
<tjaalton> inetpro: no, you have oneiric installed, right? just remove nvidia-current, install the deb and boot your machine...
<tjaalton> well, whatever is easiest for you..
<inetpro> ahh, I'll try that asap
<Sarvatt> ricotz: anything "special" about wayland updates before i do a new one in edgers? mesa needs latest git wayland again
<ricotz> Sarvatt, i think wayland should be fine
<ricotz> weston/wayland-demos might make problem if there were further renames and movings
<ricotz> Sarvatt, let me push wayland
<ricotz> Sarvatt, uploaded
<cnd> RAOF, bryce: new synaptics uploaded to x-staging and pushed to git branch ubuntu+1
<tormod> is cnd's utouch-geis fix in a PPA somewhere? I am getting used to using gnome-terminal as "Launcher" but I miss evince!
<tormod> I tried to  hand-apply and build myself, but building breaks in xcb dir. missing build dep?
<tormod> Had to remove -Werror in configure.ac to get past some unused variable complaints. Now there's a libtool 2.4.2 vs 2.4.2ubuntu1 mismatch... 
<tormod> "rm aclocal.m4 configure; autoreconf -vi" helped. finally built.
<tormod> (all this compiling while an eog was stuck on the CPU). Now with the geis patches, eog and evince segfault instead of looping.
#ubuntu-x 2012-01-13
<Prf_Jakob> Hey
<Prf_Jakob> bryce, Sarvatt, RAOF: Two questions.
<Prf_Jakob> Is feb 16th the date where you wont take any fixes from Mesa? Or just the date where you wont accept any new "feature" packages?
<Prf_Jakob> Secondly when will all this new mesa stuff hit the daily ISO images?
<tjaalton> Prf_Jakob: means that bugfix releases are still fine after that date
<tjaalton> Prf_Jakob: so for instance 8.0.x is still acceptable
<Prf_Jakob> tjaalton: ta
<tjaalton> ..until the archive is frozen
<tjaalton> since we'll get 8.0-rc before that, it shouldn't be an issue to get further fixes to it
<Prf_Jakob> Ok good
<Prf_Jakob> I'm planning on doing the rc tomorrow/today.
<tjaalton> great
<tjaalton> kibi from debian has done some work on the mesa master packaging
<Prf_Jakob> when is the last date for 8.0.x pickup?
<tjaalton> Prf_Jakob: april 12th
<tjaalton> final final freeze :)
<Sarvatt> yep!
<tjaalton> so bugfix releases are generally good until that
<Sarvatt> as long as we have something from 8.x in before feb 16th\ we can update up until the release
<tjaalton> right
<tjaalton> with some amount of paperwork
<Prf_Jakob> ok
<Prf_Jakob> We are planning on doing the 8.0 on feb 2.
<tjaalton> like a walk in the park then :)
<RAOF> Sarvatt: Yo dude, where you at?  I've got a laptop to palm off to a Lexingtonite and your huey :)
<apw> RAOF, bryceh, http://people.canonical.com/~apw/edid-precise/
<bryceh> apw, excellent
<RAOF> Let's see if the queen boots that one! :)
<bryceh> apw, seems to be disliking my bcmwl
<bryceh> wish me luck
<tjaalton> so, is the necessary fix for unity included in the 5.0 upload or not?
<tjaalton> to use with the frankenserver
<RAOF> I believe so, yes.
<tjaalton> ooh, will dist-upgrade then
<RAOF> You still need a fixed geis, but that's building.
<tjaalton> right
<tjaalton> noticed the upload
<tjaalton> "Start in 37 minutes", and i386 built it already, meh
<Sarvatt> tjaalton: yeah i'm using 5.0 now
<ricotz> hi, finally ;)
<tjaalton> Sarvatt: oh cool
<cnd> RAOF, on second thought, I'd rather just use ppa:ubuntu-x-swat/x-staging
<cnd> I've got a bunch of random stuff in dx-touch/unstable
<cnd> and I'd rather leave it as-is with some daily build recipes set up
<cnd> although x-staging doesn't build armel and powerpc, I think people on those archs can handle held back packages
<cnd> what do you think?
<tjaalton> dist-upgrade it is..
<RAOF> cnd: https://launchpad.net/~canonical-x/+archive/x-staging is available for your delectation.
<tjaalton> oh look, compiz spinning on cpu again :)
<tjaalton> unity from the unity-team ppa, utouch-geis 2.2.2
<bryceh> RAOF, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/814895
<ubot4> Launchpad bug 814895 in xserver-xorg-video-intel (Ubuntu) "[snb-m-gt2] Booting with external monitor fails with *ERROR* Couldn't find PLL settings for mode! (affects: 4) (heat: 22)" [High,Confirmed]
<tjaalton> Sarvatt: which versions did you have again?
<tjaalton> ok, so I _don't_ have the new utouch-geis update
<tjaalton> wonder why it's taking so long to get published..
<tjaalton> ok, got it updated, works again
<tjaalton> and on that bombshell, it's time to call it a week
<FernandoMiguel> evening
<Hanmac> hay i tryed to make fglrx to an multiarch package (to avoid lib32) but i have problems to get glx working ... someone there that probably could help me?
#ubuntu-x 2012-01-14
<FernandoMiguel> evening
#ubuntu-x 2012-01-15
<FernandoMiguel> hey
#ubuntu-x 2013-01-07
<mlankhorst> ok so wine testbot is on life support :(
<Chipaca> hi guys. intel arrandale in R here reporting ânot direct rendering capable.â, falling back to llvm :(
<jcristau> x log and dmesg?
<Chipaca> http://paste.ubuntu.com/1506381/
<Chipaca> http://paste.ubuntu.com/1506383/
<Chipaca> jcristau: that's /var/log/Xorg.0.log and /var/log/dmesg respectively
<jcristau> [144099.016] (WW) intel(0): cannot enable DRI2 whilst forcing software fallbacks
<Chipaca> jcristau: yeah, I think I understand what it means, but not how it got there 
<Chipaca> (i.e., why is it forcing software fallbacks?)
<Chipaca> ("well don't do that then!" :) )
<jcristau> yeah, dunno
<Chipaca> new kernel in today's updates, am going to reboot and retest. This is something that starts happening after a while of uptime (maybe after suspend?), so it'll be a little bit before I can re-report
<Chipaca> o/
<jcristau> i'd start with removing the i915 and drm options from the kernel cmdline
<mlankhorst> it sounds more like a xorg option though
<jcristau>         intel->force_fallback =
<jcristau>                 drmCommandNone(intel->drmSubFD, DRM_I915_GEM_THROTTLE) != 0;
<mlankhorst> ah right
<jcristau> also:
<jcristau>         if (!can_accelerate_blt(intel)) {
<jcristau>                 intel->force_fallback = TRUE;
<mlankhorst> prerelease hardware crap, probably
<jwi1> i915_enable_rc6 is out to to kill you...
<jcristau> dunno which of those it can be, having a note in the log would be helpful
<mlankhorst> Chipaca: lspci -vvv, graphics card listing?
<mlankhorst> jcristau: well after I had a similar problem they added a message to dmesg :-)
<tjaalton> arrandale is old, don't think it's meant to be used with rc6 anyway.. silly to force it
<Chipaca> fwiw, with X freshly restarted I again have drm. Do you want the lspci after it stops working?
<mlankhorst> hm just try without all the kernel options first
<Chipaca> mlankhorst: how do i list the graphic card?
<Chipaca> mlankhorst: http://paste.ubuntu.com/1506405/ of it now
<Chipaca> to repeat, it works fresh after a reboot, then suddenly unity crashes and doesn't come back up again (restarting X fixes it, sometimes)
<Chipaca> I have not yet pinpointed the bug, as you see; was hoping it was something known :)
<mlankhorst> I would try without the kernel options first, if it's not enabled by default either the intel devs are evil, or they think it's not ready yet for your card :/
<tjaalton> yeah, probably the gpu gets in a "state" due to the driver not really supporting those options, because of instability or whatever
<jwi1> the lack of any hangcheck vomit in dmesg is a little surprising.
<jwi1> picking up the fix for https://bugs.freedesktop.org/show_bug.cgi?id=55984 probably wouldn't hurt (raring still has uxa by default, right?)
<ubottu> Freedesktop bug 55984 in DRM/Intel "[ilk regression] gpu hangs on ironlake with 3.6 + -next + -fixes code" [Normal,Needinfo]
<jcristau> ah, so it's just a regular hang, and reset not working, then.
<mlankhorst> ok so erm new xserver-xorg-video-nouveau
<shadeslayer> not exactly sure what happened but for some reason I've lost compositing on raring
<shadeslayer> /var/log/Xorg.0.log
<shadeslayer> erm
<shadeslayer> http://paste.ubuntu.com/1506621/
<shadeslayer> http://paste.ubuntu.com/1506622/ < dmesg
<jcristau> uh that backlight spam in xorg.log is insane
<jcristau> shadeslayer: define 'lost compositing'
<jcristau> also what's with people setting random module options in kernel cmdline today?
<tjaalton> hehe
<shadeslayer> jcristau: earlier, with those options, kwin was using opengl
<shadeslayer> but now it falls back to xrender
 * jcristau blames kwin.
<shadeslayer> ( not to mention no backlight control )
<shadeslayer> somehow I doubt that
<mlankhorst> erm sometimes it happens
<mlankhorst> grep OpenGL ~/.kde/share/config/kwinrc
<shadeslayer> OpenGLIsUnsafe=false
<shadeslayer> it worked perfectly before I rebooted into the new kernel
<mlankhorst> should also say Backend=OpenGL, but it doesn't :P
<shadeslayer> Backend=XRender
<shadeslayer> like I said
<mlankhorst> but can change that in systemsettings
<shadeslayer> I tried
<shadeslayer> but it falls back to XRender
<mlankhorst> does it say anything?
<shadeslayer> not really no
<shadeslayer> "Failed to activate desktop effects using the given configuration options. Settings will be reverted to their previous values.
<shadeslayer> Check your X configuration. You may also consider changing advanced options, especially changing the compositing type."
<mlankhorst> what if you start kwin manually from command line after setting that backend line with kwin --replace  ?
<jcristau> also, glxinfo
<shadeslayer> need a couple of minutes
<shadeslayer> hah, kwin crashed
<shadeslayer> libGL error: failed to load driver: i965
<shadeslayer> what
<mlankhorst> LIBGL_DEBUG=verbose glxinfo ?
<shadeslayer> http://paste.kde.org/639572/
<jcristau> sounds like you don't have access to /dev/dri/card0
<tjaalton> issues with policykit then?
<jcristau> no
<jcristau> would be consolekit if anything afaik
<tjaalton> ah
<tjaalton> well, probably the same reason as for the acpi spam
<shadeslayer> okay, how about this, there are quite some upgrades that I need to do, I'll do those and get back to you?
<shadeslayer> I pinged because I thought maybe it was a known issue 
<tjaalton> works fine here
<jcristau> tjaalton: do you guys have some random wiki or forum or doc advising to set i915 module options?
<shadeslayer> hrh
<shadeslayer> heh
<shadeslayer> regarding i915 module options
<shadeslayer> I got those from a blog that I saw a couple of weeks ago
<shadeslayer> because I have dual graphics cards and I disable the ATi card
<tjaalton> jcristau: no :)
<tjaalton> forum users maybe get silly ideas
<mlankhorst> tjaalton: well if you google it you find some of those..
<jcristau> s/maybe/definitely/
<jcristau> "if somebody said so on the intarwebs it must be a good idea"
<tjaalton> and macbooks suck
<mlankhorst> indeed :(
<mlankhorst> need to finish up on my quirking for it
<mlankhorst> sent \o/
<tjaalton> mlankhorst: oh you got a macbook now?-)
<mlankhorst> tjaalton: for testing prime stuff
<mlankhorst> debugging that it lost interrupts after a switcheroo cycle was fun :/
<mlankhorst> bryce: hm what would be useful to have is one of those versions check, but then for all precise  .*-lts-quantal package versions compared against what's available in quantal
<shadeslayer> seems like a minor issue
<shadeslayer> erm
<shadeslayer> s/minor/temporary/
<shadeslayer> gone after fully upgrading and rebooting
<mlankhorst> ok started uploading the raring stack to my ppa as well, hopefully I was right and upgrading between stacks will work succesfully too :-)
#ubuntu-x 2013-01-08
<mlankhorst> tjaalton: shall I push newer pixman + inputproto to raring? allows me to build xserver git
<tjaalton> mlankhorst: how crazy is the new pixman? if it doesn't regress badly, go for it
<mlankhorst> well the inputproto is rc1, but xserver 1.14 already released rc1 too, new video abi yay
<tjaalton> yeah
<tjaalton> pixman seems to improve some cairo-perf tests
<mlankhorst> we want x1.14 in raring right?
<tjaalton> that's what we decided
<mlankhorst> ah k
<mlankhorst> I could handle all the video driver bumps then
<tjaalton> don't push that just yet :)
<mlankhorst> nah
<mlankhorst> still gathering courage to do that
<tjaalton> we could prepare the branch though
<mlankhorst> I wanted to do some testing against airlied's reverse prime stuff, that's why I was starting on testing x1.14 in the first place
<tjaalton> there's ubuntu+1 branch for playing with that
<tjaalton> but first maybe push 1.13.1 to raring
<mlankhorst> I'll upload some recent pixman/inputproto which would allow me to test
<tjaalton> or what's the current rc for 1.13.2
<tjaalton> sure
<tjaalton> you'll also get rid of patch 500_* :)
<mlankhorst> pointer barriers?
<tjaalton> yeah
<mlankhorst> the sad part is that I didn't even have to look that one up, just from memory :P
<tjaalton> or a subset of it? not sure
<tjaalton> dunno if it could regress unity.. I can test that though
<mlankhorst> yeah should be easy to test
<tjaalton> i'll update the ubuntu branch to 1.13.1.901 and push to raring
<mlankhorst> ok
<tjaalton> mlankhorst: installing libqt4-dev with the backport stack installed reverts to the old one, since there's no renamed libglu1-mesa-dev?
<mlankhorst> very sure mesa9 dumped libglu1 out of the repository
<tjaalton> libqt4-opengl-dev
<tjaalton> oh right
<mlankhorst> old libglu1 should still install though
<tjaalton> it does, and reverts to the old version
<tjaalton> or something like that
<mlankhorst> hm waitoh right, the libglu1-mesa-lts-quantal was from 8.0.4
<mlankhorst> try this
<mlankhorst> # apt-get install libglu1-mesa-dev libgl1-mesa-dev-lts-quantal
<tjaalton> that works
<tjaalton> but should libglu get renamed as well? it's a separate package now
<mlankhorst> old libglu1 works and barely got updated, didn't see the point
<tjaalton> because of dependencies..
<tjaalton> libqt4-opengl-dev depends on it
<tjaalton> trying to install it removes the backport stack :/
<mlankhorst> yeah that's a bug in mesa, need to fix that there
<tjaalton> how is it a bug in mesa?
<mlankhorst> actually it's just a conflict resolution fail
<mlankhorst> Depends: libglu1-mesa (= 8.0.2-0ubuntu3), libgl1-mesa-dev | libgl-dev
<tjaalton> in mesa?
<tjaalton> ah, I see now
<tjaalton> or I think so :)
<mlankhorst> but installing libgl1-mesa-dev wipes out everything, I was considering changing mesa so the old -dev packages will work on the new stack
<mlankhorst> so what you describe will not happen then
<tjaalton> ok
<tjaalton> mlankhorst: gimme a debdiff for review when ready :)
<mlankhorst> still testing x11proto/pixman :P
<tjaalton> sure
<mlankhorst> ok inputproto done
<mlankhorst> ricotz: did you do the symbols for pixman?
<ricotz> mlankhorst, you mean in edgers? yes
<ricotz> as the changelog indicates
<mlankhorst> argh why not simply track down the correct versions :P
<mlankhorst> now i had to do it
<ricotz> i guess you are bored?
<mlankhorst> nah pushing to debian, they'd probably get annoyed if I didn't
<ricotz> i see, please sort the symbols correctly, irc they werent
<mlankhorst> I just added the new ones to the correct place and moved the pixman_format ones
<ricotz> there were some put at the end where they werent suppose to be
<mlankhorst> yeah got those
#ubuntu-x 2013-01-09
<mlankhorst> morning
<tjaalton> https://launchpadlibrarian.net/127916308/HookError_source_xorg.txt
<tjaalton> wth?
<mlankhorst> o.0
<tjaalton> guess we could switch to sna once 3.8 hits raring
<tjaalton> and I'm preparing mesa master now
<mlankhorst> sure, makes the intel devs happy
<tjaalton> you think?
<mlankhorst> I'm not sure it makes anyone else happy though!
<tjaalton> asked ickle about it a month ago or so, he thought it was maybe 80% ready back then. they've fixed some issues since then, might be 9/10 by now :)
<tjaalton> er, 90%
<mlankhorst> going to do 1 more testbuild of pixman, then push the thing
<tjaalton> always fun merging new mesa upstream..
<mlankhorst> :>
<mlankhorst> it's becoming more and more boring though
<mlankhorst> but hey tf2 fps increase, count me in
<mlankhorst> I'm hipster and knew about that before phoronix reported it
<tjaalton> a ton of conflicts that need to be manually resolved
<tjaalton> easy though, always take what's the new
<mlankhorst> when doing syncs of pre-release git, new maintainer entry should be Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> right?
<tjaalton> i'd prefer ubuntu-x
<tjaalton> dpkg-source is happy as long as the address has *ubuntu.com on it
<mlankhorst> i thought pre-release like that was special when there were no ubuntu specific changes
<tjaalton> it's not a big deal
<mlankhorst> ok incoming pixman then
<tjaalton> meh, robert hasn't kept up with wayland updates..
<tjaalton> or my mirror.. wtf again
<tjaalton> right, mirror cleanup & sbuild-update fail, duh :)
<tjaalton> builds, with an additional uncommitted build fix..
<tjaalton> apw: so, were you going to upload 3.8 to raring soon?
<ricotz> tjaalton, hi, i there a nvidia 313.09 patch for 3.8 available? (i guess, i havent looked hard enough yet)
<tjaalton> ricotz: tseliot is on them
<ricotz> great, thanks
<tseliot> :)
<mlankhorst> can someone sponsor pixman? it doesn't appear to be part of xorg package set
<bdrung> hi, i like to ask about a possible MIR of libxkbcommon. we will need libxkbcommon in main if we enable the wayland backend in gtk (bug #954352)
<ubottu> bug 954352 in gtk+3.0 (Ubuntu Raring) "Enable wayland backend" [Wishlist,Triaged] https://launchpad.net/bugs/954352
<tjaalton> bdrung: go for it
<bdrung> tjaalton: the description says that this library is experimental
<tjaalton> ah
<bdrung> the current version of this package is a git snapshot
<bdrung> there is a 0.2.0 of it
<tjaalton> ok, I'll update it
<bdrung> http://cgit.freedesktop.org/xorg/lib/libxkbcommon/log/
<bdrung> tjaalton: the warning in the description came from bryce. bryce, did you add the warning, because the package was a git snapshot?
<tjaalton> it was at some point
<tjaalton> things have changed since
<tjaalton> bryce: the versions-current page doesn't seem to track libxkbcommon upstream?
<tjaalton> mesa snapshot builds properly now, doing libxkbcommon & weston next
<mlankhorst> ok first attempt at mesa done
<tjaalton> what's the diff like?
<tjaalton> bdrung: libxkbcommon 0.2.0 uploaded
<mlankhorst> few lines
<tjaalton> show it :)
<tjaalton> oh, it's in git already
<tjaalton> not quite :)
<tjaalton> it was the security update
<mlankhorst> http://paste.ubuntu.com/1512694/
<bdrung> tjaalton: thanks
<tjaalton> mlankhorst: so basically, mesa-common-dev should be backwards compatible?
<mlankhorst> pretty much
<tjaalton> unless a package depends on glu_*.h :)
<tjaalton> which got removed in 9.0
<tjaalton> but it shouldn't matter
<ricotz> bdrung, hi, is it possible to enable broadway too which doesnt need further depends and won't interfere either?
<bdrung> ricotz: what is broadway?
<ricotz> bdrung, the html5 backend of gtk
<bdrung> how much will the package size increase?
<ricotz> hmm, quite a question
<bdrung> ricotz: broadway will not need any new build dependencies?
<ricotz> no
<bdrung> ricotz: do we have an open bug report for it?
<ricotz> no
<ricotz> i was asked to do so in my ppa, and did for some time now
<bdrung> ricotz: and there were no regression?
<ricotz> it is a separate backend like wayland
<bdrung> ricotz: can you evaluate the size change?
<ricotz> i'll try
<mlankhorst> tjaalton: that should be pulled to libglu.*-dev then
<tjaalton> mlankhorst: it's not in precise
<bdrung> weston needs to be updated in raring - see bug #1097685
<ubottu> bug 1097685 in weston (Ubuntu) "libwayland and weston package versions in raring are incompatible" [Undecided,Confirmed] https://launchpad.net/bugs/1097685
<tjaalton> updating as we speak
<jcristau> bdrung: of course libxkbcommon is experimental.  so's wayland...
<tjaalton> just not api-wise, not anymore
<bdrung> jcristau: i was referring to the API (not how often the API will be extended)
<mlankhorst> erm afaict libglu1-mesa-dev from precise includes GL/glu.h and GL/glu_mangle.h, so installing it will work even on renamed stack
<tjaalton> mlankhorst: of course, dunno what I was looking at..
<tjaalton> sigh, why on earth doesn't the ubuntu cairo package build the egl backend?
<ricotz> bdrung, the stipped gdk lib would grow by ca. 90kb
<bdrung> ricotz: and in percentage?
<ricotz> 20
<ricotz> 550 to 640
<bdrung> 90 kb is not that big if there are user wanting that backend
<bdrung> ricotz: feel free to extend the debdiff and state the dependency/size impact of the change in the bug report
<ricotz> it is getting in shape in 3.7.x, while staying on 3.6 it might be not the great to use
<tjaalton> looks like an ancient cairo merge left the egl backend disabled, nice
<ricotz> tjaalton, it is intended to be disabled due nvidia blob memory problem
<tjaalton> ricotz: ah, meh
<tjaalton> ricotz: that was on oneiric?
<ricotz> tjaalton, still valid afaik :(
<tjaalton> ok tehn
<tjaalton> then
<ricotz> tjaalton, feel free to check
<tjaalton> nah
<ricotz> the nvidia kernel module will massivly increase in size
<tjaalton> yeah i remember now
<bdrung> ricotz: then a bug report with the current findings would be nice as reminder once we get >= 3.7.x into the archive
<ricotz> it isnt likely it will land in raring
<ricotz> 3.7.x i mean
<bdrung> therefore the bug report
<bdrung> tjaalton: have you seen http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691699 ?
<ubottu> Debian bug 691699 in src:libxkbcommon "libxkbcommon: [PATCH] upgrade to 0.2.0" [Wishlist,Open]
<tjaalton> bdrung: no
<bdrung> tjaalton: it would be nice to review that and reduce the lintian output
<bdrung> http://paste.debian.net/223110/
<mlankhorst> ah great, pixman 1-0 and input update is enough for new xserver :)
<tjaalton> bdrung: huh, I only got one warning
<tjaalton> about out-of-date-standards-version
<jcristau> tjaalton: he runs lintian with the pedantic option
<bdrung> tjaalton: are you using lintian 2.5.11ubuntu1?
<jcristau> which outputs lots of irrelevant stuff
<tjaalton> bdrung: whatever is in raring
<tjaalton> jcristau: ah
<bdrung> tjaalton: i use --pedantic -IE
<tjaalton> duh, I wasn't aware it didn't use debhelper 9
<ricotz> bdrung, ah there is a bug https://bugs.launchpad.net/precise-backports/+bug/933641
<ubottu> Ubuntu bug 933641 in gtk+3.0 (Ubuntu) "Please backport/enable HTML5 (broadway) gdk backend for gtk+3.0" [Wishlist,Confirmed]
<tjaalton> who uses that backend anyway?
<tjaalton> the latest I heard was that it's still very much WIP
<ricotz> some kind of webapps
<ricotz> yeah, that is why i said 3.8 will be more appropriate to have it in a usable stat
<ricotz> e
<bdrung> ricotz: can you comment that bug report?
<ricotz> done
<ricotz> bdrung, is it possible to remove the "Precise Backports" reference completely?
<ricotz> from the mentioned bug
<bdrung> ricotz: it doesn't seem to be possible
<bdrung> tjaalton: will you apply the libxkbcommon patches?
<tjaalton> bdrung: ones that matter
<bdrung> tjaalton: the patches 004 - 008 makes sense to me
<bdrung> the patches 002 and 003 were already covered by you
<tjaalton> not 5 & 6
<ricotz> mlankhorst, hi, btw, what is holding back wine getting into raring?
<mlankhorst> no idea?
<bdrung> tjaalton: why not? what speaks against using 3.0 (quilt)? why is the tarball generation still needed?
<ricotz> mlankhorst, hmm, so scott is not comfortable with 1.5 yet?
<mlankhorst> I don't upload wine to distro, just maintaining ubuntu-wine ppa :-)
<ricotz> i know, i am just hoping you would know why it isnt there yet ;)
<mlankhorst> so you use the ubuntu-wine ppa, of course!
<ricotz> i do, yes
<mlankhorst> been maintaining audio there mostly, the ubuntu official release is probably lacking all these changes
<ricotz> ok, keep that up! :)
<mlankhorst> the bug about supporting pulseaudio is >5 years old at this point. :P
<mlankhorst> ok guess I'll do a 'proper' rework of all patches to xserver 1.14 now, botched up when testing airlied's stuff
<tjaalton> use ubuntu+1, and reset --hard it to the current branch
<mlankhorst> was thinking of a debian-experimental+1 first
<tjaalton> or just bump d-e there
<tjaalton> jcristau: opinions?
<jcristau> about?
<tjaalton> whether to bump xorg-server debian-experimental branch to git master
<jcristau> shouldn't be an issue, i don't think we need to go through 1.13
<tjaalton> yeah
<mlankhorst> ah k, x1.14 it is then
<jcristau> branch history will be a mess, but oh well :(
<tjaalton> because of xi2.3?
<mlankhorst> it's git, it will resolve the conflicts ;-)
 * ogra_ wonders why nobody had the idea to send git to syria tzhen
<ogra_> :P
<mlankhorst> they don't use version control there
<jcristau> mlankhorst: that's not what i'm worried about
<jcristau> just having lots of merges of stuff that was never used/uploaded
<tjaalton> on the d-e branch?
<mlankhorst> it was used, just not on debian :)
<mlankhorst> wow, that was easy, just needs inputproto / pixman version bump
<mlankhorst> and removal of input barrier patch
<mlankhorst> bit suspicious that all other patches just apply, though
<tjaalton> heh
<tjaalton> not much has changed though
<tjaalton> feature wise anyway
<mlankhorst> true
<mlankhorst> and I guess the 1.13 rc's grabbed most patches we cared about anyway
<mlankhorst> sdksyms.o:(.data.rel+0x3578): undefined reference to `PanoramiXSaveXFixesVector'
<mlankhorst> weee
<jcristau> â¥ sdksyms
<mlankhorst> well fine, wonder if a hack is enough, if it's a configure option not like that stuff should be exported anyway..
<bryce> bdrung, yeah the warning can be removed from the description.  Back when I packaged it, it was pre-release experimental, but not anymore.
<tjaalton> bryce: yep, done
<tjaalton> 0.2.0 is in raring now
<bdrung> bryce: thanks
<tjaalton> and pushed a further description update to debian-unstable branch
<bryce> tjaalton, yeah there's several upstreams it doesn't track.  It's on my todo list.
<tjaalton> cool
<tjaalton> weston update nearly there
<mlankhorst> bryce: fwiw x1.14 compiles, don't know about pointer barriers yet, seems to have been upstreamed?
<bryce> mlankhorst, great
<bryce> mlankhorst, yeah I saw peter put in some of those changes for 1.14.  Enough for us to drop our patch?
<mlankhorst> well it fails to apply now
<bryce> maybe raof can illuminate us
 * bryce throws in the towel on #1056039.  WFM.
<tjaalton> the upstreamed version of p-b is functionally equivalent to the old one, aiui
<bryce> tjaalton, ah good.  So perhaps just a matter of testing.
<tjaalton> but it was a rh/gnome guy who made it happen there
<tjaalton> yeah, needs testing to be sure
<tjaalton> maybe unity/compiz needs to adjust
<tjaalton> no idea
<bryce> sounds like a job for the TODO page
<tjaalton> btw, I think that for bugs just assigning them to people/the team should be sufficient :)
<bryce> tjaalton, how do you mean?
<tjaalton> bryce: meaning that maintaining a list on a wikipage takes effort :)
<mlankhorst> I so how would I upload xserver-xorg, without it immediately getting pushed to raring directly?
<tjaalton> mlankhorst: why?
<mlankhorst> was curious
<tjaalton> there is no -proposed for -proposed ;)
<bryce> tjaalton, certainly does, but I'm fine to do that, it's helping me keep track.  Some people have a *lot* of assigned bugs, so just looking at the raw list would have  a lot of noise.
<tjaalton> bryce: right, I don't mind you looking after them :)
<tjaalton> and it's true that trying to find a decent bug to work on from a list of 500 is "hard"
<tjaalton> without getting burned out
<jcristau> tjaalton: the wheezy rc bug list is only 300!
 * jcristau hides
<tjaalton> jcristau: hehe :)
<bryce> tjaalton, maybe some day I'll write a web tool that pulls assignments from launchpad.  
<tjaalton> bryce: yeah that might be handy
<RAOF> bryce, tjaalton: The upstream pointer barrier code is now sufficient, but the API's changed; unity will need to be ported.
<bryce> RAOF, happen to know if there is a bug # or WI for that work?
<RAOF> bryce: Let me check my filed bugs; if I haven't filed it, I don't think there's one.
<mlankhorst> I had a feeling it would be something like that
<RAOF> bryce: No; it looks like I haven't filed that.
<bryce> RAOF, ok, subscribe me to it once it's filed if you don't mind
<RAOF> bryce: Done.
#ubuntu-x 2013-01-10
<bryce> RAOF, got it, thanks.
<tjaalton> bryce: I'm thinking about defaulting to sna now, ickle recommended it too
<tjaalton> so robert ancell uploaded weston 1.0.3 already..
<tjaalton> double work
<bryce> tjaalton, do we have sna on in edgers?
<tjaalton> bryce: dunno
<tjaalton> but people have tested it with good results
<tjaalton> doesn't look like it's enabled there
<bryce> one lesson I learned with exa and uxa is that before we switch to a new tech you only hear from people for whom the tech works great.  Those who have problems with it will just ignore it...
<tjaalton> sure
<bryce> tjaalton, I suppose we could switch it on for a week and evaluate the fallback via bug reports
<tjaalton> yeah
<bryce> (assuming apport is still catching crashes and freezes for us)
<tjaalton> it's been rather quiet :)
<bryce> suspiciously
<tjaalton> 10 bugs on raring..
<tjaalton> against our packages
<tjaalton> which is like 1/4 of the bugs against quantal at this point
<bryce> yeah.  of course we haven't updated many packages...
<bryce> anyway, I have raring systems at hand, I'll do some sleuthing tomorrow and make sure it's still working.
<tjaalton> I've tried it on sandybridge, heard good results on i915 & i945
<bryce> for sna...  even if we go ahead and do a 1 week eval, I think I'd still like to see it guinea pigged on edgers for a bit, maybe even a call for testing
<tjaalton> edgers pulls all kinds of crap
<tjaalton> rather do it on another ppa
<bryce> yeah that'd be fine.
<bryce> or even just have folks manually switch it on in their xorg.conf?
<bryce> "Copy this file to /etc/X11/xorg.conf.  If that leads to any graphics problems, delete the file and let us know."
<bryce> give it a week... if we hear nothing serious then flip it on for everyone for a week
<tjaalton> alright
<tjaalton> huh, reading the forums really makes you sad :)
<bryce> phoronix?
<tjaalton> ubuntuforums this time
<bryce> sheesh: http://www.phoronix.com/scan.php?page=news_item&px=MTI3MTI
<tjaalton> yeah
<tjaalton> that was amusing to read, again
<tjaalton> tseliot: hey, wanted to ask if nvidia-current will go away and instead just use -NNN in the future?
<tseliot> tjaalton: yes, it's exactly as you say
<tjaalton> tseliot: right, what I had suspected :)
<tseliot> I'll work on transitional packages today
<tjaalton> pinged #ubuntu-release about the -173 update to quantal, noticed it's been on the queue since nov 22nd :/
<tseliot> ah, thanks
<tjaalton> tseliot: also, during your holidays I uploaded the nvidia-96 update, it's now verification-done so should hit precise soon
<tseliot> tjaalton: ah, good, I'll sync my git repository then
<tjaalton> hope it's the last upload ;)
<tseliot> hehe, right
<tjaalton> will the nvidia-experimental-* packages stay?
<tjaalton> guess they're obsoleted by this change
<tseliot> tjaalton: they should be there only in precise
<tjaalton> right
<mlankhorst> bryce: oh my ;P
<mlankhorst> my personal favorite is the tf2 post currently, he didn't even try and copied that verbatim
<Sarvatt> tjaalton: June 29th, 2012: SNA is now on by default on intel. 
<Sarvatt> its been on by default for a long time now and the only complaints since have been when I accidentally made UXA the default one upload :P
<tjaalton> Sarvatt: --enable-sna is not the same as --with-default-accel=sna
<tjaalton> oh you mean edgers?
<tjaalton> the changelog lies about it then
<Sarvatt> override_dh_auto_configure:
<Sarvatt> 	dh_auto_configure -- --enable-sna --enable-uxa --with-default-accel=sna --with-builderstring="$(SOURCE_NAME) $(SOURCE_VERSION) ($(BUILDER))"
<tjaalton> basically doesn't mention that
<tjaalton> and I trusted the changelog, boo :)
<Sarvatt> oh the hook got screwed up
<tjaalton> anyway, I'll create a wikipage for people to report success on
<Sarvatt> changelog part, i updated the man page last upload and screwed it up :)
<tjaalton> hehe
<tjaalton> 16:21 < cjwatson> This will be painful
<tjaalton> 16:22 < cjwatson> hate you all
<tjaalton> :)
<tjaalton> colin doesn't like the pain the renamed stack causes on the installer
<mlankhorst> wait a minute
<tjaalton> relax
<Sarvatt> everyone hates the renamed stack, not like we had a choice :)
<tjaalton> right
<mlankhorst> true
<mlankhorst> guess I'll file a bug for the mesa -dev issue and get it sru'd
<tjaalton> yeah
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1098215 ?
<ubottu> Ubuntu bug 1098215 in mesa (Ubuntu Precise) "installing libqt4-opengl-dev uninstalls renamed stack" [Critical,In progress]
<mlankhorst> will do some more testing before I upload the fix
<tjaalton> yep, looks good
<tjaalton> don't forget to subscribe ubuntu-sru once done uploading
<mlankhorst> hm I think I'll leave out libgbm-dev, I think the api on that one might change and nothing rdepends on it anyway
<tjaalton> ok
<tjaalton> https://wiki.ubuntu.com/X/Testing/IntelSNA
<tjaalton> comments welcome
<tjaalton> or edits :)
<tjaalton> dinner ->
<mlankhorst> sounds good
<tjaalton> updated the wiki-page again
<tjaalton> I'd like to send the email to ubuntu-devel@ today
<tjaalton> then again, the wiki can be edited later :)
<tjaalton> Sarvatt: mind proofreading the page?
<tjaalton> actually, I'll wait and let bryce comment on it too
<tjaalton> bryce: so I wrote the wiki page, and email ready to be sent
<Sarvatt> tjaalton: sure thing, one sec, testing this bcmwl package out
<Sarvatt> tjaalton: looks good to me, is SNA backend needed?
<Sarvatt> in the results column
<Sarvatt> I guess thats one way to make sure people verify they are actually using SNA
<tjaalton> yeah :)
<bjsnider> wouldn't xorg.0.log say so?
<tjaalton> although it comes from the same output, so..
<tjaalton> that's where it's from
<tjaalton> dropped the backend bit
<bryce> tjaalton, reading
<bryce> tjaalton, looks good!  I made a few minor copy edits.  Also, I put the xorg.conf as an actual attached file.
<bryce> I suspect people are going to be more comfortable copying an entire file into place, than with editing xorg.conf's.  And most Intel users won't have a file to conflict.
<tjaalton> bryce: ah, good point. and thanks!
<tjaalton> the first version just cat'd the file in place, but that seemed a bit risky :)
<bryce> right, now to retest on my own hw.  :-)
<tjaalton> Sarvatt: fix your lp id there :)
<bryce> tjaalton, ah, I assumed those were yours!  sorry
<tjaalton> oh, hehe
<tjaalton> yeah I'll test it on X61 too once I'm done with vag-com & XP..
<tjaalton> (i965GM)
<tjaalton> bryce: i'm reformatting it a bit, done editing?
<bryce> yep, go for it
<tjaalton> added example output for uname/lspci
<tjaalton> ok, I'll send the email and post to the forum
<bryce> tjaalton, awesome
<tjaalton> just happened to read this earlier too :) http://ubuntuforums.org/showthread.php?t=2103414
<tjaalton> there
<tjaalton> let's see how long until it's on phoronix frontpage
<bryce> heh
<jcristau> tjaalton: 'lspci -nn -s 0:2.0'
<jcristau> (all intel hw has the gfx at that slot afaik)
<tjaalton> jcristau: ahh..
<jcristau> saves some grepping
<tjaalton> and the chance of running it on a hybrid laptop
<tjaalton> didn't know how to best handle such case
<tjaalton> if it's always on 0:2:0 then that would solve it
<bryce> tjaalton, there's also xpci, although I can't guarantee it's going to work properly on the newest gfx cards
<tjaalton> ImportError: No module named taskhelm
<tjaalton> :)
<tjaalton> on quantal
<bryce> tjaalton, yeah, need to fix that.  should already work on raring though
<tjaalton> ok
<shadeslayer> tjaalton: silly question, but could this http://wstaw.org/m/2013/01/10/plasma-desktopS17003.png be caused by enabling SNA?
 * shadeslayer didn't see this earlier
<shadeslayer> ( 2 arrows in the taskbar, the one at the bottom is bogus )
<tjaalton> shadeslayer: no idea, try without to be sure
<shadeslayer> yeah will do that to be 100% sure
<tjaalton> raring has a new pixman too
<shadeslayer> no idea what that is
<shadeslayer> I also don't have proper instructions to reproduce the bug, so will get back if I notice it with UXA
<shadeslayer> ah okay
<shadeslayer> can reproduce it in UXA as well
<tjaalton> ok, check what version of libpixman-1-0 you have
<shadeslayer> 0.26.0-3
<tjaalton> not that then
<tjaalton> same in quantal
<shadeslayer> yep, haven't upgraded in a bit
<tjaalton> there's a new intel driver too, uploaded earlier this week
<shadeslayer> yeah, I guess I'll leave it to upgrade tonight
<tjaalton> added a new first step to the page, upgrade to current raring
<shadeslayer> :D
<tjaalton> details..
<tjaalton> first corruption bug with sna :)
 * bryce installs chromium
<bryce> huh, repro'd
<tjaalton> what hw?
<bryce> 2a42, same gfx as echidnaman
<bryce> Dell Latitude 13
<tjaalton> ok, I'll try on snb
<Sarvatt> not happening on snb or ivb here
<tjaalton> not here eitehr
<tjaalton> either
<tjaalton> shadeslayer: which hw did you have?
<shadeslayer> 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0116] (rev 09)
<tjaalton> ah, so it's not the same bug
<bryce> posted my screenshot @ #1098334
<RAOF> To Phoronix's great surprise, sna isn't a flawless beacon of speed and stability? âº
<tjaalton> well, not on every hw incarnation ;)
<tjaalton> it seems
<bryce> RAOF, I'm sure after we switch to it, they'll post an article lambasting us
<shadeslayer> oh oh
<bryce> hmm, seems to be peculiar to reddit; other sites don't exhibit the behavior.  doesn't seem to affect firefox
<shadeslayer> tjaalton: bug 1098334 has been reproduced by JT
<shadeslayer> one sec
<ubottu> bug 1098334 in xserver-xorg-video-intel (Ubuntu) "Font corruption in Chromium tab bar using Intel SNA" [Undecided,New] https://launchpad.net/bugs/1098334
<shadeslayer> ah he reported it @_@
<tjaalton> right :)
<shadeslayer> cannot reproduce on gooogle-chrome btw
<shadeslayer> the proprietary one
<shadeslayer> but could easily be because of hw differences
<tjaalton> ok, so this one is not a critical one then
<tjaalton> probably happens only on gen4
<tjaalton> or the ones using "Broadwater/Crestline" backend
<bryce> yeah I set it to medium
<bryce> it's a pretty common chipset, although a tad old
<jcristau> hey don't call my laptop old.  it's just 4 years old. :)
<tjaalton> ah, gm45 is actually newer than 965
<jcristau> yes
<tjaalton> somehow mixed it with 945
<tjaalton> http://en.wikipedia.org/wiki/Intel_Extreme_Graphics#Early_graphics
<mlankhorst> is it just me or is https://launchpad.net/builders private now?
#ubuntu-x 2013-01-11
<mlankhorst> anyhow uploaded fix for bug 1098215, time to bug the sru team tomorrow :)
<ubottu> bug 1098215 in mesa (Ubuntu Precise) "installing libqt4-opengl-dev uninstalls renamed stack" [Critical,In progress] https://launchpad.net/bugs/1098215
<mlankhorst> night!
 * bryce waves
<shadeslayer> aha
<shadeslayer> tjaalton: http://wstaw.org/m/2013/01/11/plasma-desktopa11049.png < somewhat similar bug 
<tjaalton> looks perfectly fine to me
<shadeslayer> erm
<shadeslayer> first suggestion, favicon 
<shadeslayer> rendering issue
<tjaalton> ah
<shadeslayer> should I just comment on bug 1098334 ?
<ubottu> bug 1098334 in xserver-xorg-video-intel (Ubuntu) "Font corruption in Chromium tab bar using Intel SNA" [Medium,Confirmed] https://launchpad.net/bugs/1098334
<shadeslayer> or file a new one
<tjaalton> you have sandybridge?
<tjaalton> it's not the same bug then
<tjaalton> best file a new one
<shadeslayer> yep
<shadeslayer> tjaalton: there's also the issue where I lock the screen with steam running and unlock it, steam does not update itself
<shadeslayer> so the lockscreen is visible where steam is
<tjaalton> steam hangs?
<shadeslayer> maybe
<shadeslayer> it was consuming 100 % of my CPU
<shadeslayer> had to kill it
<shadeslayer> but can't reproduce now
<tjaalton> probably not related to sna
<shadeslayer> okay
<shadeslayer> anyway, kwin seems to be working without any regressions
<tjaalton> what was the one you mentioned earlier?
<shadeslayer> huh?
<shadeslayer> bug 1098489 is the one I'm facing
<ubottu> bug 1098489 in xorg (Ubuntu) "Corruption in Chrome omni bar results using Intel SNA " [Undecided,New] https://launchpad.net/bugs/1098489
<tjaalton> shadeslayer: http://wstaw.org/m/2013/01/10/plasma-desktopS17003.png ?
<shadeslayer> ah that one
<shadeslayer> yeah that's still present but hard to reproduce
<tjaalton> ok, might be the same
<tjaalton> hard to tell
<shadeslayer> it usually happens when something new enters and exits the taskbar in quick succession
<shadeslayer> I'll try and find a way to do that programatically
<tjaalton> shadeslayer: btw, since you're using kubuntu, please install xdiagnose and run 'apport-collect 1098489' to attach debug logs there
<shadeslayer> sure
<shadeslayer> btw I switched rendering methods to Native and I couldn't reproduce it, and then I changed back to Native and then can't reproduce it 
<shadeslayer> erm
<shadeslayer> that second native should be raster
<shadeslayer> but I'll do it anyway
<tjaalton> from where?
<tjaalton> add that to the bug
<shadeslayer> there's a KWin setting for that
<tjaalton> upstream is looking at it
<shadeslayer> tjaalton: http://wstaw.org/m/2013/01/11/plasma-desktopeo2259.png
<tjaalton> btw, your launchpad id isn't 'shadeslayer' :)
<shadeslayer> heh
<shadeslayer> sorry about that, I'm looking at so many things
<shadeslayer> lost track of that field
<shadeslayer> fixing
<tjaalton> and googling around suggests it's not a driver bug then
<tjaalton> https://bbs.archlinux.org/viewtopic.php?id=99673
 * shadeslayer looks
<tjaalton> and old thread, but still
<shadeslayer> hm
<tjaalton> anyway, think I'll close it as invalid then, native is the default anyway
<shadeslayer> alright
<shadeslayer> It can easily be a chrome issue as well, just happened to show up when I switched methods
<tjaalton> actually, raster should be the default since jun '11
<tjaalton> or qt 4.8
<tjaalton> so I'll leave it open
<shadeslayer> hm, can't say, kwin defaults to native
<tjaalton> oh, has it been reverted since?
<shadeslayer> dunno, It's not like I actively track X :P
<tjaalton> it's not X
<shadeslayer> but it's one of the 2 settings I customize when I do a fresh install
<tjaalton> but kde
<tjaalton> and I know nothing about it
 * shadeslayer asks the kwin maintainer
<tjaalton> good
<shadeslayer> tjaalton: okay, I was mistaken, it does default to raster
<tjaalton> ok
<shadeslayer> tjaalton: btw I'm using some specific parameters for the intel driver, would it be possible to ask upstream if those can be automagically detected for MacbookPro's ?
<mlankhorst> ask in intel-gfx?
<shadeslayer> thanks, will do :)
<shadeslayer> with raring there are only some customizations I need to do to switch off the ATi card and just enable the intel card
<mlankhorst> more lucky than me, upstream kernel had some issues
<mlankhorst> :P
<shadeslayer> hehe
<mlankhorst> or maybe you had as well, but haven't noticed yet
<mlankhorst> when switching radeon on again through switcheroo, I lost all interrupts
<shadeslayer> lol
<shadeslayer> I've poorly documented my steps here : https://help.ubuntu.com/community/MacBookPro8-2/Raring
<mlankhorst> oh I pulled some random git trees, applied patch, made things work without extra things in grub
<shadeslayer> xD
<mlankhorst> shadeslayer: if you want you can try
<shadeslayer> try what?
<mlankhorst> my kernel, see if it works for you
<shadeslayer> will it enable graphics switching?
<mlankhorst> should work at least
<mlankhorst> not while x server is running though, I'm using it to test i915 + radeon optimus support
<shadeslayer> hmm
<shadeslayer> that's fine
<shadeslayer> mlankhorst: can you suspend/resume?
<shadeslayer> that's one of the most important things for me
<mlankhorst> afaict it works
<mlankhorst> http://cgit.freedesktop.org/~mlankhorst/linux/
<shadeslayer> other one being backlight control
<shadeslayer> I'll have a look when I have some free time :)
 * shadeslayer has to make a release early next week
<tjaalton> ricotz: bug 1093517 for you I guess
<ubottu> bug 1093517 in libdrm (Ubuntu) "libdrm-nouveau conflicts between versions" [Undecided,Confirmed] https://launchpad.net/bugs/1093517
<tjaalton> " nouveau hangs during boot of life system, prevents installation"
<tjaalton> someone had a heart-attack?
<mlankhorst> :(
<mlankhorst> sounds like someone had a libdrm fail..
<tjaalton> well I moved it to -nouveau
<mlankhorst> it's a failure in someone's ppa, libdrm_nouveau1a should not have libdrm_nouveau.so.2.0.0 in it
<ricotz> sounds like oibaf ppa
<mlankhorst> closed invalid
<tjaalton> ah
<tjaalton> good
<tjaalton> there's also many bugs of installation failures where libdrm-radeon/intel1:i386 complains about the changelog
<tjaalton> but that might've been a buildd bug
<mlankhorst> or some ppa interaction messing up
<mlankhorst> at one point I did mess that up in a ppa, too :P
<tjaalton> yeah could ber
<tjaalton> -r
<ogra_> huh ?
<ogra_> +e
<mlankhorst> aw no libdrm nouveau update yet
<ogra_> not -r 
<ogra_> :)
 * mlankhorst tempted to write it himself
<tjaalton> ogra_: oh, true :P
<tjaalton> getting close..
<mlankhorst> oh apparently I already started on it
<shadeslayer> oh my
<shadeslayer> tjaalton: I'm getting more issues in chrome now http://wstaw.org/m/2013/01/11/plasma-desktopQq2259.png
<tjaalton> ok
<tjaalton> keep the bug posted
<shadeslayer> and idk why but performance is now down to 35 FPS
<shadeslayer> window switching is fairly choppy
<shadeslayer> http://wstaw.org/m/2013/01/11/plasma-desktopmj2259.png
<tjaalton> check dmesg for drm errors
<shadeslayer> *blink*
<shadeslayer> [14469.814051] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
<shadeslayer> [14469.814056] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
<tjaalton> there you go
<shadeslayer> http://paste.kde.org/643790/
<tjaalton> attach the error_state there
<shadeslayer> I don't see a /debug/dri/0/i915_error_state
<shadeslayer> or a /debug even
<tjaalton> /sys/kernel/..
<tjaalton> as root
<shadeslayer> what should I say? My GPU hung up? P
<shadeslayer> :P
<tjaalton> attach the file
<shadeslayer> okay
<tjaalton> do you have 3.8 btw?
<tjaalton> kernel
<shadeslayer> nope
<tjaalton> upgrade
<shadeslayer> is 3.8 in the repos? or from the mainline PPA?
<tjaalton> in the repo since yesterday
<shadeslayer> has it migrated from -proposed? :P
<shadeslayer> ah it has
<shadeslayer> my apt cache was probably outdated
<tjaalton> it's a technicality, takes 30min or so
<tjaalton> or the mirror
<mlankhorst> yay vdpau merger time then
<tjaalton> yay beer & dinner time
<shadeslayer> alrighty, time to reboot to 3.8
<bladernr_> I'm sure I know the answer to this, but does anyone know of a way to reliably determine how much memory a video card gets from the system? (shared ram w/ integrated graphics)
<bladernr_> that also works more "universally" :D <-- there's the rub... 
<bryce> bladernr_, saw my email?
<bladernr_> I did, thanks.  
<bladernr_> In reality, it's not even an X/Graphics related issue, its that we have a script that compares the memory BIOS claims is there vs what the OS claims to have, and wanted to add code to factor in actual shared video RAM 
<bladernr_> that way we could account for large discrepancies...
<bladernr_> and I don't really want to try writing something that has a different subroutine for each and every type of card or driver out there :(
<bladernr_> at the basest level is it safe to assume that any memory descrepancy up to about 512MB can be attributed to video usage on a system with embedded graphics?
<bryce> bladernr_, proprietary drivers and foss drivers hardly ever do things the same way, so you're destined for disappointment if you want a universal tool...
<bladernr_> yeah, I know... that was me being hopeful
<bladernr_> bryce: but thanks for the information though, I do appreciate that and your expertise with this stuff
<bryce> bladernr_, lshw shows memory resources under the VGA controller, so there should be an interface to get that.  DMI maybe?
<bryce> as to memory in use, the sysfs dri debug interface is the only one I know of, and that's different on every driver
<bryce> mlankhorst likely knows more about this.
<bladernr_> Interesting, on my S10, lshw shows two display devices ... heh. 
<mlankhorst> really depends on card
<bladernr_> bryce: yeah, even lshw is not reliable :) on my S10, it shows a total of 265MB for the video card. That's reasonable, but the OS is also showing the full 1.5GB of RAM available... sigh... where on my x201, the OS shows me short by 496MB, but only 200MB for video in use, which I suspect is not correct.(but can't confirm either way(
<bladernr_> oh well, like I said, I was being hopeful... it's not a critical thing by any means anyway.
<bladernr_> more exploratory
 * bryce nods
#ubuntu-x 2013-01-12
<Sarvatt> bladernr_: theres no magic way to tell, nvidia and amd both have their own exclusive gl extensions to check total video ram :(
<mlankhorst> well iirc libdrm could export that information too
#ubuntu-x 2014-01-06
<Mez> Hi all, looking for suggestions for gfx cards, as my current card refuses to play with my new machine (can't boot to live cd with it).  Any suggestions ?
<Mez> (hoping for 4 monitors)
<ogra_> mlankhorst, tjaalton,  ... i'm seeing something like this on my dell xps 13 in trusty (ivy-bridge model) http://askubuntu.com/questions/313190/random-black-dot-on-the-screen do you know of any workaround/fix ?
<tjaalton> ogra_: i occasionally see similar corruption on a focused terminator window, but it's very random
<tjaalton> file a bug and i guess ickle will have something to try
<ogra_> yeah, it isnt costant ... i see it probably twice a day flashing by 
<mlankhorst> ogra_: maybe #intel-gfx knows?
<tjaalton> i'm still on saucy though
<ogra_> intrestingly it doesnt seem to affect the panel and launcher 
<mlankhorst> file a bug in any case, maybe they have an idea
<ogra_> yeah, will do, it isnt urgent anyway 
<tjaalton> it's sna related
<ogra_> (not actually disturbing or some such, but would be good to have it fixed by release)
<tjaalton> we're behind a few releases
<ogra_> ah
<tjaalton> but the latest one has some gen4 regression
<tjaalton> iirc
<mlankhorst> funfun
<tjaalton> some font issue, not a huge regression
<mlankhorst> I think we should upload something newer though for intel
<mlankhorst> maybe 907 napshot + gen7 regression fix?
<mlankhorst> tjaalton: you ok with that?
<Mez> Ok, I've managed to get X to a point where it crashes, I think (system beep, can't change VT, etc)
<Mez> where would I find the logs for this ?
<mlankhorst> dmesg?
<tjaalton> mlankhorst: ah, upstream doesn't have more than that.. then yeah I guess that's ok
<tjaalton> I could test it on my gen4 tho
<tjaalton> ..tomorrow, public holiday today :)
<mlankhorst> odd, xorg-server 1.15 build times out on i386
<jcristau_> worked here: https://buildd.debian.org/status/fetch.php?pkg=xorg-server&arch=i386&ver=2%3A1.15.0-1&stamp=1389010723
<mlankhorst> https://launchpad.net/~canonical-x/+archive/x-staging/+build/5415802 ppa times out
<Mez> mlankhorst: dmesg shows a normal boot - nothing new after starting X
<mlankhorst> anything in xorg.0.log?
<Mez> doesn't seem to be any errors or anything :(
<Mez> http://pastebin.com/YsZu3GTW
<mlankhorst> then obviously there is nothing wrong
<mlankhorst> except why are you using vesa? o.O
<Mez> mlankhorst: well, the machine boots to a black screen, so I have nomodeset set
<mlankhorst> don't set nomodeset and try again
<Mez> mlankhorst: give me a sec, but I *believe* that that makes for an unresponsive system...
<Mez> ok, now I'm getting some interesting errors
<Mez> http://paste.ubuntu.com/6703344/
<Mez> I'm getting a black screen though
<Mez> I understand I'm a pain in the ass asking all these questions... but does anyone have the time to help me? I really would love to get my new machine working 
<tjaalton> Mez: upgrade your kernel
<tjaalton> saucy is clearly too ld
<tjaalton> +o
<tjaalton> you could also just try blacklisting nouveau
<Mez> tjaalton: I've actually tracked it down to gdm now
<Mez> gdm doesnt like not being 3d
<tjaalton> right, so blacklist nouveau..
<tjaalton> I bet the intel part can still do 3d
<Mez> tjaalton: I want 4 screens... that's not going to run using 3d...
<Mez> or... would it...
<Mez> hmm...
<tjaalton> Mez: you're not going to get any hybrid with it
<Mez> ?
<tjaalton> this is a hybrid machine right?
<Mez> nope
<Mez> Desktop machine.  Onboard Intel
<tjaalton> so disable the integrated chip
<Mez> with a seperate nvidia
<Mez> there's no option to
<tjaalton> sure there is
<Mez> tjaalton: I can take photos of my BIOS if you wish, but I went through EVERY option and there wasn't one
<Mez> the only option was to make the onboard bitch at boot if you had a monitor connected to it.
<tjaalton> don't attach a monitor to the mobo?
<Mez> That's enabled, but the device is still there
<Mez> Anyway, I don't think it's an issue with X anymore.  I can get it happily working with X - but not with a full gnome session
<tjaalton> well, I'd say it's a bit too much to expect X to work correctly in this scenario
<tjaalton> blacklist i915.ko then and see what happens
<Sarvatt> ricotz: hmm, libgl1-mesa-dev in the ppa needs to depend on libxcb-dri3-dev, libxcb-present-dev, libxcb-sync-dev, libxshmfence-dev it looks like
<Sarvatt> updating it now
<Sarvatt> uploaded a new bumblebee too, got a ton of emails over the weekend about it being busted
#ubuntu-x 2014-01-07
<RAOF> mlankhorst, tjaalton: When were you thinking of being all xserver 1.15-y?
<tjaalton_> RAOF: guess it depends on fglrx, they know of the ppa already since a month ago or such
<mlankhorst>  RAOF that
<tseliot> mlankhorst: is that patch of yours to start X with a specific GPU (on hybrid systems) in 14.04?
<mlankhorst> tseliot: well I think so
<mlankhorst> that's what the inactive screens were for
<tseliot> mlankhorst: do you mean xf86-inactive-gpuscreen.patch ?
<mlankhorst> yeah
<tseliot> mlankhorst: shouldn't we just use the discrete GPU with nvidia on desktop systems?
<mlankhorst> indeed, but that requires setting intel as gpu screen
<mlankhorst> which is why inactive is mapped to gpu screen, nvidia used a bug to do that
<tseliot> aren't both intel and nvidia gpu screens?
<tseliot> or does the first gpu become master screen?
<tseliot> mlankhorst: or maybe I misunderstood what you said
<mlankhorst> there's 1 master screen and 1 gpu screen
<tseliot> oh
<tseliot> mlankhorst: in your patch I only see that set the PLATFORM_PROBE_GPU_SCREEN flag but I don't see anything else. Maybe there's an additional patch?
<mlankhorst> no that's all you need
<tseliot> mlankhorst: but I remember that you could pass X the pci id
<tseliot> you wrote that patch
<mlankhorst> tseliot: correct, but still need to specify what pci-id belongs to primary, and which one to the gpu screen
<tseliot> mlankhorst: ok but what I don't understand is if we already have code to do that
<mlankhorst> tseliot: well nvidia used a bug in xorg-server to specify that intel is a gpu screen, I turned it into a feature :P
<tseliot> right
<tseliot> mlankhorst: but I also remember that you told me about some code to launch X with something like: /usr/bin/X :0 -auth... -primary=0:1:0 or something like that to select the card
<mlankhorst> oh that
<tseliot> I don't see it among our patches
<mlankhorst> I don't think I ever made a patch to set it on the command line
<mlankhorst> only in xorg.conf
<mlankhorst> oh the -gpu switch
<mlankhorst> I think I dropped that patch
<tseliot> yes, that was it
<tseliot> do you still have that patch somewhere?
<mlankhorst> no idea, why?
<mlankhorst> can't find it in the ubuntu tree at least
<tseliot> I don't want users to install nvidia and fail on desktop systems where crappy bioses which do not disable the integrated GPU when you plug in a discrete card
<tseliot> and you don't want to offload rendering in that case
<tseliot> as in bug #1126234
<ubottu> bug 1126234 in ubuntu-drivers-common (Ubuntu) "Does not show nvidia driver if intel card is active" [High,Triaged] https://launchpad.net/bugs/1126234
<mlankhorst> oh that
<mlankhorst> my system has that too
<mlankhorst> but what do you want to do in that case?
<tseliot> mlankhorst: I think we can simply detect that we're not dealing with a laptop, and, if that is the case, use the discrete card by default
<tseliot> mlankhorst: or add an option to do that, and my nvidia-prime package will set it in some configuration file
<mlankhorst> how do you know it's not a laptop, then?
<tseliot> mlankhorst: well, you can check if you have anything in /sys/class/power_supply/ or if you have /proc/acpi/button/lid
<mlankhorst> tseliot: I would like something more definitive :P
<mlankhorst> tseliot: anyway by default the primary gpu is used
<mlankhorst> which is set in the bios
<mlankhorst> graphics card initialization order or something
<tseliot> right now I do:    if [ -n "`ls -A /sys/class/power_supply/`" ] && [ -d "/proc/acpi/button/lid" ]; then echo "Laptop detected"; fi
<tseliot> mlankhorst: right, and I want to be able to ignore that
<tjaalton> i have an ups, wonder if it shows as a power supply..
<tseliot> we cannot rely on the BIOS in some cases
<tjaalton> not connected via usb currently
<mlankhorst> it should
<mlankhorst> in those cases you can use nvidia-prime
<tseliot> tjaalton: does it also show a lid? ;)
<tjaalton> no :)
<tseliot> mlankhorst: a user would plug the monitor into the nvidia card and, surprise, he wouldn't see anything
 * tseliot -> lunch
<mlankhorst> tseliot: yeah it's terrible, I know
<tjaalton> so Mez's use case from yesterday
<tjaalton> pretty much
<tjaalton> hum, time to go trusty
<tjaalton> on desktop too
<mlankhorst> I'm still on precise :p
<tjaalton> well, you get to test the backports :)
<mlankhorst> true
<tjaalton> I have precise on another machine
<mlankhorst> I will move after verifying lts-trusty
<tjaalton> and latest dev release dualboot
<mlankhorst> I'm on lts-raring atm, will move to lts-saucy soon :P
<tjaalton> good boy
<mlankhorst> hm seems to all be in precise-proposed now
<tjaalton> oh cool
<tjaalton> finally
<mlankhorst> # Xorg -version
<mlankhorst> X.Org X Server 1.14.5
<mlankhorst> should probably log in again to use it ;-)
<mlankhorst> yay works
<tjaalton> ship it
<mlankhorst> definitely
<mlankhorst> I didn't even mess up versions this time, I think
<mlankhorst> I deleted all lts-saucy packages from s-lts-backport and x-staging. only thing left in x-staging is xorg-server 1.15 for now
<mlankhorst> tseliot: any word from fglrx?
<tjaalton> ->#private ;)
<tjaalton> we have a call on thursday
<mlankhorst> ah k
<tseliot> mlankhorst: I think we can fix that use case
<tjaalton> tseliot: should nvidia-173 dkms build on saucy?
<tjaalton> what's the deal with libxcb, is it mergeable by now?
<mlankhorst> should be
<tseliot> tjaalton: does it fail?
<tjaalton> tseliot: there's https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1257392 where it's missing the kernel module, dunno why
<ubottu> Ubuntu bug 1257392 in xorg (Ubuntu) "Xorg crash" [Low,Incomplete]
<tseliot> tjaalton: maybe the kernel headers are not installed?
<tjaalton> yeah thought about that
#ubuntu-x 2014-01-08
<tjaalton> still see the stipple patterns with ivb on trusty
<tjaalton> from time to time
<tjaalton> will file a bug
#ubuntu-x 2014-01-11
<tjaalton> hrm, so xorg.git is at 1:7.7+1ubuntu6 and UNRELEASED, while trusty has -1u7
<tjaalton> oh.. because of doko
<mlankhorst> yeah
<mlankhorst> doko really needs to use xsf.git :(
<Dandel> ricotz, did you ever fix the nvidia package from the xorg edgers ppa?
<tjaalton> mlankhorst: well, there's no obligation to
<tjaalton> just that we didn't spot these earlier
<tjaalton> i've merged from debian but it's WIP still, will push next week
<mlankhorst> ah
<tjaalton> we can at least demote some drivers to universe, like -sis which is broken with exa
<tjaalton> anyway ->
<mlankhorst> would be nice
<mlankhorst> means having to backport less next time
<tjaalton> actually
<tjaalton> once glamor is "ready", we could backport just -modesetting :)
<tjaalton> also, I'll propose to TB that mesa would be allowed to roll..
<mlankhorst> trololol
<tjaalton> like, the first bugfix release would be pushed to $lts-proposed
<tjaalton> :P
<tjaalton> yeah I'll wear asbestos
<mlankhorst> can't joke about asbestos
<mlankhorst> except when suggesting  'asbestos-free' as label :>
<mlankhorst> like asbestos-free flour
#ubuntu-x 2015-01-06
<mlankhorst> ricotz: waffle in xorg-edgers is out of date
<ricotz> mlankhorst, i guess you mean the piglit ppa?
<ricotz> although i think waffle is up2date in vivid
<mlankhorst> yeah
<mlankhorst> probably, debian has 1.5.0
<ricotz> pushed some rebuilds
<mlankhorst> thanks
#ubuntu-x 2015-01-08
<tjaalton> ricotz: hi, is there a history of edgers changes to mesa? guess openvg needs to be dropped but i'd check the other changes too
<ricotz> tjaalton, the bzr branch contains the mesa packaging patches
<tjaalton> where?
<tjaalton> branches under edgers were old
<tjaalton> other than piglit
<ricotz> xorg-pkg-tools
<ricotz> ah sorry i have pending local changes
<ricotz> tjaalton, pushed
<tjaalton> k
<tjaalton> thx
<tjaalton> so libegl1-mesa-drivers is essentially empty now and can be dropped?
<ricotz> tjaalton, it is empty yes, but dropping it breaks some rdepends, so a transitioning package might be useful
<mlankhorst> yeah
<tjaalton> righty-o
#ubuntu-x 2015-01-09
<tjaalton> working on mesa 10.4.1, I'll test it over the weekend and upload next week if nothing broke
<mlankhorst> oke
#ubuntu-x 2016-01-14
<soee> oh, im here :)
<mamarley> soee: Thanks, I will start packaging the new driver now.
<soee> mamarley: thanks, i can always test them when they are packaged
<mamarley> OK, I will post here once I have them in staging.
<mamarley> The KDE problem from the last beta could actually be worked around by self-compiling a specific commit of libglvnd and copying the compiled libraries over the ones shipped with the driver.
<mamarley> But it should be fixed in this release.
<soee> ok
<mamarley> Hmm, the changelog doesn't actually mention fixing the KDE issue.  NVIDIA's changelogs haven't always been complete though.
<tseliot> mamarley, ricotz: did you add code to support libglvnd? I haven't looked into it yet but I plan to do it soon
<mamarley> tseliot: I modified the .install and .links files to support the new files that they ship, but that is all.
<tseliot> mamarley: ok, good
<ricotz> tseliot, mamarley, might be better to build it from source and drop the prebuilt binary?
<ricotz> like vdpau
<tseliot> ricotz: libglvnd is not in the archive though
<mamarley> I speculate that someday the glvnd lib might be packaged separately, but aaronp indicated that the ABI isn't stable yet, so it is probably a good idea to wait until that happens.
<ricotz> then it should be added?
<tseliot> unless we have any specific needs, it's probably best if we rely on the binaries for now
<ricotz> ok, as you can see with the KDE problem having it separately would be beneficial, but yeah, seems more reasonable now to use the binary
<tseliot> if that's a beta, chances are the fix will get into the final release
<tjaalton> upstream version for libglvnd is still at 0.0.0... :)
<tseliot> heh
<mamarley> tseliot: aaronp said the fix would be in the next beta, but the changelog doesn't say anything about it.  I will see in a minute.
<tseliot> ok
<mamarley> ricotz: tseliot: soee: 361.18 does fix the KDE crashing issue and is ready in my staging PPA: https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages
<soee> mamarley: will test it now
<soee> brb
<soee> mamarley: http://wstaw.org/m/2016/01/14/snapshot59.png
<soee> mamarley: no crashes, CS:GO works fine on Steam
<mamarley> Yay!
<tseliot> mamarley: excellent :)
<ricotz> nice :)
<mamarley> tjaalton: How is xorg-server 1.18 coming along?
<tjaalton> mamarley: haven't even started yet
#ubuntu-x 2016-01-15
<tjaalton> mesa 11.1.1 is on ppa:canonical-x/x-staging btw
<tjaalton> ..and now with the tarball too
#ubuntu-x 2016-01-16
<mamarley> ricotz: Is there any reason not to go ahead and copy 361.18 to the main PPA?
<ricotz> mamarley, it should be fine if you kept an eye on the packaging differences e.g. trusty
<mamarley> ricotz: Yep, I created the package for each distro version by updating the previous driver version from that distro, so all changes are preserved.  The packaging for Vivid, Wily, and Xenial is exactly the same though.
<mamarley> Darn, looks like the armhf builds are still failing because of the file path differences between the amd64/i386 drivers and the armhf ones.
#ubuntu-x 2017-01-14
<JanC> I'm having lots of issues with "black windows" in 16.10  :-/
<JanC> on a system with Intel HD Graphics 530
#ubuntu-x 2018-01-10
<ricotz> tjaalton, hi :), I hoping you will update vulkan again, afaics there is 1.0.65.2
<tjaalton> yes, stil need to bikeshed how to package glslang and spirv
<tjaalton> *still
<ricotz> ah those are not fun I assume
<tjaalton> already in the tarball and built, just not packaged
#ubuntu-x 2018-01-11
<tjaalton> RAOF: hi, did you have a chance to look at the mesa mir patches yet?
<RAOF> tjaalton: I started looking, then got distracted.
<RAOF> Since this bug that I'm working on is driving me crazy, maybe a change of pace back there would be niceâ¦
<tjaalton> btw, the pkg-xorg repos migrated to salsa.debian.org
<tjaalton> hehe
<RAOF> tjaalton: Entirely unrelatedly, Xorg reproducibly dies when logging in for me: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1742612
<ubottu> Error: launchpad bug 1742612 not found
<RAOF> This makes using my desktop somewhat less fun :)
<tjaalton> which release?
<tjaalton> there is a mesa regression in xenial, caused by a backported patch which broke gen4/gen5 intel if not using -intel
<tjaalton> but guess it's not that
<RAOF> Bionic.
<tjaalton> ah
<RAOF> Intel is also the only mainstream GPU vendor not being driven by that X server :)
<tjaalton> alright then :)
<tjaalton> launchpad says that page doesn't exist
<RAOF> 'twas private, although you should be able to see anyway?
<RAOF> Try again
<tjaalton> I should yeah
<tjaalton> haha, apport closed it as invalid
<tjaalton> the stack should be mostly the same as on artful though
<RAOF> Oh, yeah.
<RAOF> The stack will be broken because it's the stack from my -O0 nostrip build.
<tjaalton> ah :)
<RAOF> Hm. How do I get my salsa login, I wonder...
<tjaalton> use https://signup.salsa.debian.org/ 
<tjaalton> iirc you're not a dd?
<RAOF> Correct.
<RAOF> Always meant to apply, never quite get around to it :)
<tjaalton> find -name .git | while read d; do sed -i 's,= 
<tjaalton>                   .*\(git\|anonscm\)\.debian\.org.*pkg-xorg/,= git@salsa.debian.org:xorg-team/,' $d/config; 
<tjaalton>                   done
<tjaalton> to migrate cloned repos
<tjaalton> nice paste
<tjaalton> tseliot is almost done with nvidia repackaging to work with glvnd, so I'll merge that too for bionic
<tjaalton> within the next month or so
<RAOF> Woot!
<RAOF> The X-side of that is not quite done yet, right?
<tjaalton> right, serverside-glvnd isn't merged yet
<RAOF> My amazing desktop is not going to get to try NVIDIA binary + Radeon :)
<tjaalton> could be we get both at the same time
<tjaalton> 1.20 should get it though, and the plan was to release it this month :P
<tjaalton> more likely february
<tjaalton> RAOF: once you have the accound, apply for xorg-team
<tjaalton> account
<RAOF> Cool, done.
<tjaalton> accepted
<RAOF> Ta
#ubuntu-x 2018-01-12
<RAOF> tjaalton: Aaand that's the Mir EGL patches refreshed and working.
<tjaalton> RAOF: great, thanks!
<mamarley> ricotz: The 340 and 390 drivers I had in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages have all built successfully on i386 and amd64 (armhf still hasn't been re-enabled).
<ricotz> mamarley, did you encounter any problems with 390?
 * ricotz copied 384.111 from the archive to silence people not seeing it in the ppa
<mamarley> ricotz: Nope, it runs fine for me.  I tested OpenGL, OpenGL ES, and Vulkan.
<ricotz> copied them all, thanks!
<mamarley> No problem
<soee> finally have 390 driver installed from ppa
<soee> and works with kernel 4.15 RC :)
<mamarley> soee: Yeah, sorry about that.  The buildds were turned off until Meltdown was patched.
#ubuntu-x 2018-01-13
<mamarley> ricotz: Someone let me know that nvidia-390 was missing Provides/Breaks/Replaces for libcuda-9.0-1, so I added it and uploaded again.
<mamarley> ricotz: I also got a bug report from a user about a failure to install the 340 package on a system with Linux 4.10.  I realized I had screwed up the regex, so I have fixed that too.
<mamarley> I had tested it with 4.14 to make sure that the 4.15 patches didn't apply, but I didn't go that far back.  I'm not the best at regexes, sorry.
#ubuntu-x 2019-01-10
<ricotz> mamarley, hi, do you want to update 410.93?
<mamarley> ricotz: To be honest, not really.  I'm a bit busy right now and I don't have any systems running that series.
<ricotz> mamarley, ack, that is fine
