#ubuntu-x 2006-07-06
* Starting logfile irclogs/ubuntu-x.log
<fabbione> papppappapapapa
<fabbione> ok everything works
<fabbione> Kamion: they just finished
<Kamion> yeah
<rodarvus> our libxt package has patches applied directly on the source code
<rodarvus> (for man page location)
<rodarvus> changing things like:
<rodarvus> +XtOwnSelection(3Xt)
<rodarvus> -XtOwnSelection(__libmansuffix__)
<Kamion> (it's pretty common practice to apply patches that way, no matter what some folks will tell you)
<rodarvus> (actually, s/3Xt/__libmansuffix__/)
<Kamion> although if it's gained quilt or whatever in Debian then the patches should be moved to that
<rodarvus> Kamion, but that will get lost on the next upstream release
<Mithrandir> no, it won't
<fabbione> rodarvus: no the patches are stored in the diff.gz
<fabbione> rodarvus: these man pages patches can be left alone for now
<fabbione> rodarvus: they are cosmetic and only to avoid one warning on some retarded kubuntu X man app
<Mithrandir> fabbione: I'm dropping your man page section fixes for now, we should just get them fixed in Debian.
<rodarvus> ok
<fabbione> we will do it properly later on...
<fabbione> Mithrandir: exactly
<fabbione> rodarvus: all that stuff was done one day in a hurry with sed
<fabbione> rodarvus: i am not even sure all of it is done as it should be
<Kamion> rodarvus: sounds like you've been attacked by the everything-must-have-a-patch-system freaks ;)
<rodarvus> Kamion, haha :)
<Mithrandir> they're quite common, but they're wrong.  Most packages don't need a patch system.
<fabbione> Kamion: the disease affects all developers in the early stage of their life. It can be cured submitting a moderate amount of clubat larting.
<fabbione> (from the X maintainer god medical guide)
<rodarvus> indeed a patch system is not necessary when applying only small patches such as this one - but is quite helpful when you have more patches, and new upstream versions
<Mithrandir> rodarvus: new upstream versions is really irrelevant, and a patch system is a workaround for a real fix which is using an RCS.
<rodarvus> agreed - best solution is really a RCS
<rodarvus> are we just dropping fabbione's man page section fixes from all packages, then?
<rodarvus> (just need a nod to do the same here)
<Mithrandir> rodarvus: yes
<fabbione> YES JUST DO IT
<fabbione> ps
<fabbione> sorry for the caps
<rodarvus> fabbione, daniels dropped a CFLAGS hack to fix the search path, but Debian still uses it -> "CFLAGS +=  -DXFILESEARCHPATHDEFAULT=\\\"/usr/lib/X11/%L/%T/%N%S:/usr/lib/X11/%l/%T/%N%S:/usr/lib/X11/%T/%N%S:/etc/X11/%L/%T/%N%S:/etc/X11/%l/%T/%N%S:/etc/X11/%T/%N%S\\\" -include X11/XlibConf.h -D_REENTRANT"
<rodarvus> sincerely, I don't know X build internals enough to judge if this is necessary
<fabbione> rodarvus: in what package is that?
<rodarvus> libxt
<fabbione>   * Comment out awful CFLAGS hack to fix the search path, and add
<fabbione>     --with-appdefaultdir=/etc/X11/app-defaults.
<fabbione> the merge would be still in debian/rules
<fabbione> so i suggest you drop the hack and add that
<rodarvus> fabbione, thing is, debian added that too (later), but didn't dropped the hack
<rodarvus> (but it might be only that they just didn't knew if it was still necessary)
<fabbione>   * Include customization expansion in the default XFILESEARCHPATH. Thanks to
<fabbione>     several people for the report, and to Brendan O'Dea and Ian Wienand for
<fabbione>     the diagnosis and fix respectively. (closes: #365612)
<fabbione> did you read the bug?
<rodarvus> nope, doing that now
<fabbione> ok we do have bugs reporting the same issue in dapper
<fabbione> so daniels might have done something crappy there
<fabbione> i suggest to use what Debian is doing for edgy
<rodarvus> *nods*
<fabbione> then take dapper install and check got these bugs
<fabbione> change libxt to match this new setup and see if it fixes the issue
<fabbione> if it does we will consider backporting it to dapper
<rodarvus> I will
<rodarvus> thanks!
<Mithrandir> has the publisher been fixed?
* rodarvus takes notes to test this later
<Kamion> Mithrandir: they know the problem now but there's still a bit of faffery to do - it looks like drescher may have been going mad last night in which case we have to be very very careful
<Mithrandir> uh, ok.
<Kamion> cp -a of dists was taking an hour - now it looks like it put some files in the wrong place too
<fabbione> W T F
* Hobbsee waves to all
<ogra> Hobbsee, http://people.ubuntu.com/~fabbione/x-pkgs has also some nice trivial apps to merge ... xeyes xclock etc :)
<Kamion> not yet
<Kamion> leave the apps until the libs are done
<ogra> yep
<Hobbsee> okay
<Mithrandir> also, most of them will just be in one source package in Debian.
<fabbione> Kamion: but why do they cp -a the dist in the first place?
* fabbione isn't sure he wants to know
<Mithrandir> it appears we can't really merge anything usefully until libx11 is done.
<Kamion> so that soyuz can publish to dists.new without the mirrors accidentally mirroring it in the middle of publication
<fabbione> Mithrandir: x11 is done.. it's just being choaked by soyuz atm
<Mithrandir> fabbione: so it's not done.  It's blocked on soyuz.
<Mithrandir> Kamion: and cp -al wouldn't work then?
<Kamion> *shrug*
<fabbione> Mithrandir: well i did my part.. ain't our fault if soyuz did blow up
<Mithrandir> at least -l for pool/ should make it quick enough..
<Kamion> then you'd have to audit soyuz to ensure it broke hardlinks when it should
<Kamion> anyway, that isn't important here
<Kamion> it should never have been taking an hour anyway - that was only because the machine was sick
<fabbione> rodarvus: can you please update the x-pkgs file with what you are doing?
<fabbione> rodarvus: it's a 666 file so you can just edit it yourself
<fabbione> otherwise we will end up with a duplicate mess
<rodarvus> sure, I'll do that
<rodarvus> I'm finishing libxt (in 5 minutes most), btw
<rodarvus> fabbione, should I mark packages as "done" even if they are not uploaded yet?
<fabbione> rodarvus: no, done is when the package is in the archive
<fabbione> otherwise it stays with your name between ()
<rodarvus> ok
<rodarvus> libxt is ready to be uploaded
<rodarvus> LOCK on libxmu
<rodarvus> (x-pkgs updated)
<fabbione> ehhe
<rodarvus> I've just finished libxmu_1.0.1-3ubuntu1
<rodarvus> I got a question: this package is version 1.0.1, but we had 1.0.0, before
<Kamion> do we need to carry patches forward?
<rodarvus> Kamion, only two small changes
<rodarvus> (extra requirements to libxmu-dev and libxmuu-dev)
<rodarvus> if these can be dropped
<rodarvus> we can safely merge from debian
<rodarvus> (extra libx11-dev requirements to libxmu-dev and libxmuu-dev)
<Kamion> what's the diff?
<rodarvus> Kamion, I pasted it on a query window
<Kamion> I don't really see a need to carry that diff since libxmu-headers depends on libx11-dev
<Kamion> what was your question regarding the new upstream version?
<rodarvus> Kamion, its irrelevant now, but I was wondering if it was ok to force the .changes file to carry orig.tar.gz (via -sa build option), or if this would be blocked during upload checs
<rodarvus> checks even
<Kamion> it's both OK and required
<rodarvus> good, thanks :)
<Kamion> just make sure the .orig.tar.gz is the same as Debian's when you do so
<rodarvus> *nods*
<rodarvus> (after talking with Kamion in a /query window) we found out our changes to debian/control are not a strong enough reason to manually merge instead of syncing
<rodarvus> so, I'll just ask ubuntu-archive to sync libxmu from debian unstable
<rodarvus> anyone feel free to /query me if you have any questions
<rodarvus> Kamion, thanks again
<rodarvus> libxmu sync requested (bug 52109)
<rodarvus> lunch time
<rodarvus> i'll be back in 45minutes
<Kamion> libfs uploaded
<Kamion> rodarvus: in future please wait to request a sync until all the build-dependencies are available
<rodarvus> oh, sure
<rodarvus> should I note this in the bug?
<Kamion> please
<Kamion> fabbione: please subscribe ubuntu-archive rather than assigning - it doesn't show up in the list we normally use if you just assign
<fabbione> Kamion: whops.. sorry :(
<rodarvus> Kamion, done, thanks
* rodarvus locks x11proto-evie (sync of yesterday failed due to different orig.tar.gz)
<rodarvus> x11proto-evie uploaded
<rodarvus> LOCK on libdmx
<crimsun> libice uploaded
<crimsun> LOCK libxkbfile
<crimsun> libxkbfile ready to go
<rodarvus> libdmx is ready to be uploaded
<rodarvus> just for reference: libxdamage & libdmx could be synced from Debian, but as on both cases their orig.tar.gz is different from ours, we'll have to manually merge
<rodarvus> btw
<rodarvus> LOCK libxdamage
<rodarvus> and also libxcomposite
<rodarvus> LOCK libxcomposite
<rodarvus> x-pkgs is updated
<rodarvus> libxdamage is ready to be uploaded
<crimsun> LOCK libxrender
#ubuntu-x 2006-07-07
<crimsun> libxrender ready to be uploaded (when libx11 is NEWed)
<Kamion> I did that not long ago
<Kamion> (oh, about five minutes after you said that)
<crimsun> yep, noted :)
<Kamion> go ahead and upload it now
<Kamion> syncing libxkbfile now too
<Kamion> did anyone upload anything that depended on libx11 already?
<Kamion> er build-depended
<crimsun> doesn't appear so.
<Mithrandir> fabbione: libx11-data needs to replace libx11-6 <= 2:1.0.0-0ubuntu9
<fabbione> Mithrandir: hem no
<fabbione> when i did it, dpkg did send me to hell
<fabbione> and couldn't update properly
<fabbione> without the Replace it was doing fine
<Mithrandir> uh, that's crackful.
<fabbione> don't ask me.. i did test with and without because i had the same opinion as your
<Mithrandir> there's a file conflict there so it really needs to conflict. :-P
<Mithrandir> what error message did you get?
<fabbione> i can't remember now
<crimsun> Mithrandir: (libxrender is done)
<fabbione> Mithrandir: if you want to add it go ahead
<fabbione> Mithrandir: i am not jalous at all
<fabbione> Mithrandir: but i need to get a couple of packages into shape before UVF
<Mithrandir> anyway, we can add that later, I'll just put it on a sticky note here.
<fabbione> Mithrandir: but did you actually have problems upgrading?=
<fabbione> because i didn't
<Mithrandir> fabbione: yes, file conflict.
<crimsun> LOCK libxrandr
<fabbione> Mithrandir: ok then it's probably best to fix it now
<Mithrandir> fabbione: nah, it'll just break people's upgrades and I'm more worried about getting the stack bootstrapped, TBH.
<Mithrandir> it won't trip the buildds
<fabbione> yeah i know that
<Mithrandir> we'll probably get a bunch of bug reports, though.
<Mithrandir> libxext uploaded
<fabbione> ok i am dojng libx11
<fabbione> but i am not going to test it :)
<Mithrandir> do you know if rodarvus has his packages somewhere so they can be uploaded?
<fabbione> nope
<Mithrandir> you don't know or you know he doesn't?
<ogra> hmm, http://people.ubuntu.com/~rodarvus/ is pretty empty
<fabbione> libx11 uploaded
<Mithrandir> crimsun: oh, you did libice, excellent.
<crimsun> libxrandr uploaded
<seb128> hey
<crimsun> re seb
<Mithrandir> grr, I fucked up libxext. :-/  New upload on its way.
<seb128> don't ban me from that chan but :p
<seb128> dpkg: erreur de traitement de /var/cache/apt/archives/libx11-data_2%3a1.0.0-7ub untu1_all.deb (--unpack):
<seb128>  tentative de remplacement de /usr/share/X11/locale/armscii-8/XI18N_OBJS, qu i appartient aussi au paquet libx11-6
<Mithrandir> seb128: fix in incoming.
<seb128> cool
<seb128> any ETA to get a libxft-dev installable again?
<seb128> it makes impossible to work on anything on top of pango
* fabbione larts seb128 
<seb128> like block completly any GNOME work
<fabbione> we don't care about GNOME
<fabbione> go away
<fabbione> :P
<seb128> ok, fine with me
* seb128 goes watching some TV
<crimsun> it'll take NEW love due to src:libxft -> src:xft
<Mithrandir> crimsun: NEW isn't a problem, though.
<crimsun> true
<Mithrandir> apart from that, it should be doable once libxrender is built.
<seb128> so I go cool
<crimsun> LOCK libxres
<seb128> ups
<seb128> cool
<Mithrandir> crimsun: note you need to wait for a while before uploading that.
<crimsun> Mithrandir: for libx11-dev and/or libxext-dev?
<Mithrandir> the latter.
<Mithrandir> libx11 is fine, the fix fabbione uploaded is just for upgrades.
<crimsun> right, noted.
<crimsun> this epoch business is madness.
<Mithrandir> it is, but I think I'll be able to get gravity to take our changes there.
<Mithrandir> STEAL libxt
<Kamion> oh good somebody's doing that
<crimsun> hmm, libxres is going to be messy, since our orig.tar.gz is named libxres_1.0.2+1.0.0.orig.tar.gz whereas Debian's is libxres_1.0.0.orig.tar.gz
<Kamion> crimsun: sounds like an upstream version downgrade
<Kamion> LOCK libxcursor
<Kamion> I suspect that libxres .orig == 1.0.0 really
<crimsun> Kamion: yeah, it is 1.0.0 in both cases, but I'm wondering how to work around the versioning in the orig.tar.gz
<fabbione> seb128: ping?
<seb128> fabbione: pong
<Mithrandir> crimsun: bump the version in the changelog to 1.0.2?
<fabbione> seb128: #52034 is absolutely not xterm
<Kamion>    libxres | 1:1.0.2+1.0.0-0ubuntu3 |          edgy | source
<Kamion> it's already bumped
<fabbione> seb128: X in general does not provide ANY kind of session save facility
<Kamion> crimsun: you'll have to continue the current versioning scheme
<crimsun> ok, fun stuff. Thanks.
<seb128> fabbione: ok, so that's NOTABUG, expected behaviour
<Kamion> so Debian [1:] 1.0.0-N => 1:1.0.2+1.0.0-N
<Kamion> er -Nubuntu1
<Kamion> and we can sort it out when Debian bumps to > 1.0.2
<crimsun> except Debian's using 2:1.0.0
<Kamion> oh, then you can resolve it
<Mithrandir> then it should just be a sync, shouldn't it?
<Kamion> take their .orig.tar.gz and use the epoch
<Kamion> yes, can be a sync if there are no other changes
<Mithrandir> (unless we have changes we want to keep, that is)
<crimsun> shipping man pages, but that's not vital at this stage
<crimsun> a sync sounds best
<crimsun> ok, in that case libxres is ready to be synced from Debian Sid once libxext is available
<Mithrandir> libxt uploaded
<Mithrandir> nobody locked xft?
<fabbione> it's all your
<Mithrandir> hooray!
<Mithrandir> :-P
<Kamion> libxcursor ready to go once the ia64/powerpc/sparc buildds wake up w.r.t. libxfixes
<Mithrandir> LOCK xft
<Kamion> somebody remind me how I see the buildd queue?
<Kamion> ah https://launchpad.net/distros/ubuntu/edgy/+builds
<Mithrandir> https://launchpad.net/distros/ubuntu/edgy/+builds?build_state=pending&build_text= ?
<Kamion> yeah
<Mithrandir> oh, in building.  I was wondering why it was neither built nor pending.
<Kamion> yeah, found it eventually
<Kamion> libxcursor uploaded
<Kamion> LOCK libxevie
<crimsun> LOCK libxv
<Mithrandir> afk for a little bit.
<Mithrandir> ok, seems like xft can be synced.
<crimsun> libxv ready to go once libxext is available
<Kamion> libxext should start building RSN
* Kamion wills the publisher onward
<Kamion> libxevie similarly ready to go
<Mithrandir> Kamion: if you can do the sync in https://launchpad.net/distros/ubuntu/+source/libxft/+bug/52197, it'd be great for seb, etc.
* seb128 hugs Mithrandir
* fabbione needs to stop soon
<fabbione> it's too damn warm here
<Kamion> ok, I'll do a sync pass now
<Mithrandir> excellent, thanks.
<Kamion> crimsun: if you can say in the sync request when something comes from non-main, it'd be appreciated
<Kamion> needs a different sync-source invocation in that case
<crimsun> Kamion: sorry, noted, thanks
<Kamion> (er, and which component it comes from ...)
<Mithrandir> Kamion: will xft end up in main automatically?  (If not, can you make it?)
<Kamion> Mithrandir: sort-of-yes and yes
<Kamion> it'll end up in NEW, the default there is main although *normally* we override to universe
<Kamion> but we do apply some intelligence :)
<fabbione> Kamion: when you can and you have time (!= NOW) could you please NEW openais? it will be soon a redhat-cluster-suite B-D and Depends: so you can spare yourself the trouble to move it to universe and back later
<fabbione> (up to you for the latter)
<Kamion> fabbione: ok
<fabbione> Kamion: thanks a lot
<Kamion> fabbione: er but for new main source can you please get pitti to look over it?
<fabbione> Kamion: well yes of course i can..
<Kamion> not necessarily because he might want to veto, but because he might find stuff to fix
<Kamion> anyway this is OT here
<fabbione> yup..
<crimsun> LOCK libxss
<Kamion> Mithrandir: erm - do we not need libfreetype6-dev 2.2.1?
<Kamion> or was the ABI breakage between Dapper and 2.2.1?
<Kamion> (it's a bit late, I've already newed it, but there)
<Mithrandir> Kamion: *sigh*, sorry.  We might need a rebuild, then.
<Mithrandir> oh joy, dapper has the broken freetype.
<Kamion> right
<Kamion> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314385 for the record
<Kamion> we might need to rebuild world - but fortunately we're doing that anyway :P
<Mithrandir> yeah. :-/
<Kamion> yum, and freetype/dapper-security > freetype/edgy
<Mithrandir> yeah, I whined at pitti about that a few hours ago
<crimsun> libxss ready to go pending libxext (which appears to have built on 4/5 arches)
<Mithrandir> rodarvus: it would have been useful if you'd left your packages somewhere the rest of us could have gotten at them last night. :-P
<rodarvus> Mithrandir, indeed, sorry
<rodarvus> I was waiting for build-deps to be uploaded by yesterday end of the day, but ended sleeping before all was ok
<Mithrandir> libx11 went in around midnight UTC, iirc.
<rodarvus> Mithrandir, there was at least libxext missing for me to proceed with my packages
<Mithrandir> anyway, you should have some packages which are uploadable now, like dmx
<Mithrandir> xext is built now, but not published so hold off anything needing that for a little bit.
<rodarvus> Mithrandir, most (all?) of my packages need libxext
<Kamion> we're also dealing with HORRIBLE FREETYPE MADNESS
<rodarvus> I'll check
<rodarvus> oh
* Mithrandir looks at apt-cache rdepends libfreetype6 and screams.
<Kamion> Mithrandir: it's safe to upload xext-dependent source now
<crimsun> yay
<rodarvus> great!
<Mithrandir> Kamion: oh, since they binaries are accepted?
<Kamion> the binaries are in accepted
<Kamion> https://launchpad.net/distros/ubuntu/edgy/+queue?queue_state=2&queue_text=xext
<Kamion> libxevie uploaded
<crimsun> libxss, libxv uploaded
<rodarvus> how long usually it takes for binaries to be in accepted (after the upload) - 3 hours? (looked to be something like that, when builder/publisher is ok)
<Mithrandir> best case is about 2.5 hours, worst case is about 3.5 hours.
<Kamion> rodarvus: upload source -> next :03 source publish -> publisher finishes about :40-something, buildds start -> sometimes manage to upload by next :03 -> binaries publish -> publisher finishes about :40-something, mirrors trigger
<Kamion> the "sometimes manage to upload by" is about when they land in accepted
<Kamion> uploads get processed into accepted at */5 * * * *
<Kamion> LOCK libxi
<rodarvus> Mithrandir, Kamion, nice, thanks for the explanation
<Mithrandir> LOCK libxinerama
<rodarvus> you are moving stuff to DONE only when the binary is moved into accepted, right?
<Mithrandir> no, when the source is uploaded is what we've done so far.
<Kamion> look at launchpad.net/distro/ubuntu/+source/NAME/VERSION to see build states
<Kamion> if they're all "Successfully built" then you're generally safe to upload source build-depending on them
<tseng> i find launchpad.net/people/YOURNAME/+packages more useful
<tseng> as it gives you a list of all your recent uploads and state
<Kamion> tseng: utterly hopeless here, they're not all our packages
<Kamion> you need to know the state of stuff you're build-depending on not just stuff you uploaded
<tseng> right, sorry
<Kamion> good for spotting build failures though
<crimsun> LOCK libxkbui
<crimsun> oh, UNLOCK, that's a sync
<Mithrandir> crimsun: care to file the sync request, then?
<crimsun> Mithrandir: just filed it :)
<crimsun> Mithrandir: (same for libxres)
<Mithrandir> crimsun: noted on x-pkgs
<crimsun> thanks
<Mithrandir> crimsun: please tell when they're attended to so they can be moved to done.
<rodarvus> libdmx uploaded
<crimsun> Mithrandir: will do
<crimsun> LOCK libxtrap
<rodarvus> whoever moved libdmx to done, thanks :)
<Mithrandir> np
<Mithrandir> rodarvus: I stole libxt from you this morning and uploaded it, but I see now that libsm wasn't done, so it'll require a rebuild :-/
<rodarvus> Mithrandir, libsm was uploaded just now
<Kamion> I've found a few packages that have been relibtoolised with Debian's libtool, but the patches seriously don't apply
<rodarvus> I've done all packages marked as "mine"
<rodarvus> I'm just uploading them now (after double checking)
<Mithrandir> rodarvus: ok, libsm moved to done
<rodarvus> libxdamage uploaded
<rodarvus> libxmu sync requested
<Kamion> libtool> doesn't seem to make any difference at least for libxevie though
<rodarvus> (actually, a new comment on yesterdays request, as agreed with Kamion)
<rodarvus> btw, I have libxaw done here, but it depends on libxt (which is uploaded but needs a rebuild) and libxmu (which will be synced from Debian unstable)
<crimsun> libxtrap ready to go pending libxt rebuild
<Mithrandir> libxinerama uploaded
<rodarvus> I also have libxcomposite ready to go, but pending on libxdamage build
<Mithrandir> LOCK libxtst
<crimsun> ok, off to work, libtrap at http://sh.nu/~crimsun/xorg-transition/  if I'm dead in action.
<crimsun> libxtrap^
<Kamion> libxi uploaded
<Kamion> rodarvus: libxmu also build-deps on libxt ...
<rodarvus> Kamion, right, indeed
<rodarvus> Mithrandir, you'll send libxt to rebuild after libsm is published?
<rodarvus> (I mean, it can only happens in ~3h, or can it be done before?)
<Mithrandir> rodarvus: I'll do that, sure.
<rodarvus> LOCK libxvmc
<rodarvus> Kamion, syncs for packages with same version for orig.tar.gz, but with different md5sum fail, right?
<Kamion> yes
<Kamion> the archive only ever accepts one file with a given name
<rodarvus> *nods*
<Kamion> which is partly for general sanity, partly because it would be a lot harder on mirrors if they had to check the contents of every file rather than just whether they had it or not, and partly because a different release might still be using the older file
<rodarvus> sure, its a very sane thing to do
<Kamion> libxres synced
<Mithrandir> libxtst uploaded
<Mithrandir> LOCK libxxf86dga
<rodarvus> libxvmc is ready to be uploaded (waiting for libxv to be built)
<Mithrandir> oh, ffs, Debian has epoched libxxf86dga and we now have mismatching orig.tar.gz again.  Grr.  More fakesyncing.
<Kamion> we should follow the epoch though, right?
<Mithrandir> yeah.
<Mithrandir> (I can't see a reason not to, at least)
<rodarvus> I guess most X libraries with same orig.tar.gz have mismatched md5sum, currently
<Kamion> there have been a few exceptions, but yeah
<Mithrandir> libxxf86dga uploaded.
<Kamion> ok, I'm going to do other stuff for a while - feel free to ping me for urgent archive admin though
<rodarvus> in a little while I guess we'll be mostly stuck, anyway
<Kamion> ?
<rodarvus> well, not really
<rodarvus> we'll be able to merge/sync apps,but only locally
<rodarvus> at least until libraries are all published and built
<Mithrandir> hmm, why isn't libsm listed as successfully built, building, pending or failed?
<Kamion> it's pending now
<Kamion> you might have caught the build sequencer (or queue builder?) mid-operation or something
<rodarvus> I'll be right back
<Mithrandir> Kamion: can you rescore builds?
<Mithrandir> if so, can you bump libsm?
<Mithrandir> libsm i386 build started now.
<Kamion> unfortunately not
<Kamion> Keybuk can
<Mithrandir> he's not around, though.
<Kamion> voip him?
<Kamion> he usually says to phone him if he's not on IRC?
<Kamion> s/\?//
<Kamion> oh, need to get freetype rescored as well - I'll phone him
<Kamion> gosh, voip works
<Kamion> he'll be here in a moment
<Kamion> as predicted he was just offline to get some work done
<ogra> did you use the new canonical voip ?
<Kamion> I have two accounts, no idea which ekiga used - I called Scott's personal one though
<Kamion> hiya
<Mithrandir> Keybuk: care to rescore libsm, please?
<Kamion> can we get libsm (two arches) and freetype rescored up?
<Keybuk> Kamion: neither -- it would have just contacted my server direct
<Kamion> ah
<Kamion> neither's caught by the magic *x* hack
<Kamion> we're having, er, fun with freetype ;)
<Keybuk> why fun? :p
<Kamion> ABI breakage that got into dapper
<Keybuk> freetype rescored (i386 is already "buildin")
<Keybuk> in fact, looks like i386 is about to get picked up
<Kamion> I think at present we're hoping that if we sing LALALA really loudly (and rebuild the world) the problem will go away
<Kamion> cool, thanks
<Keybuk> sounds like fun
<Kamion> gave me an excuse to try out voip in anger, anyway
<Mithrandir> Kamion: in Debian it seemed like it only affected gnustep though.
<Mithrandir> which limits the damage quite a bit
<Keybuk> what was the change?
<Kamion> I think we've already synced gnustep, but we can see how it goes ...
<Keybuk> which is the second libsm arch?
<Kamion> Keybuk: one that had already started building by the time you looked
<Keybuk> ah
<Keybuk> has finished now already
<Kamion> Keybuk: freetype upstream had added a load of new symbols and dropped others in 2.1.10 - then in 2.2 they said "ok, no more use of freetype internal symbols for YOU" and ditched a load of stuff from the API/ABI
<Kamion> but some apps and libraries were using the internal symbols, and they didn't bump soname
<Keybuk> heh
<Keybuk> nice of them
<Mithrandir> if glibc can get away with it, so should freetype be able to. :-P
<Kamion> vorlon tried to convince them to bump soname but they basically went "nah, too hard due to all the libraries using freetype"
<Keybuk> a drive-by dreppering of the library?
<Kamion> basically, via Owen Taylor
<Keybuk> heh
<Keybuk> isn't he stuck on mugshot now?
<Mithrandir> LOCK libxxf86misc
<Kamion> it was a while back, this has been going on for months
<Kamion> the annoying thing is that it was fixed in Debian in March, and we could have grabbed it for dapper if we'd noticed
<Keybuk> yeah, it's tricky to notice stuff in Debian like that without someone reaading their -changes every day
<Mithrandir> libxxf86misc uploaded
<Keybuk> Kamion: (on why the archive only accepts one orig.tar.gz ...
<Keybuk> and the bitch is, that you can't just epoch it either <g>)
<Mithrandir> new libxt uploaded too
<Mithrandir> LOCK libxxf86vm
<Kamion> Keybuk: right :-/
<Kamion> yay for tar
<Mithrandir> Keybuk: does patches.ubuntu.com carry patches for XbuildY versions too or just XubuntuY?
<Mithrandir> libxxf86vm uploaded
<Keybuk> Mithrandir: both
<Keybuk> anything where ubuntu > debian
<Mithrandir> Keybuk: excellent.
<Keybuk> I don't think there are any patches for XbuildY though
<Mithrandir> there will be soon.
<Keybuk> http://patches.ubuntu.com/x/xprobe/
<Keybuk> ah, there is
<Keybuk> several, in fact
<fabbione> hey Keybuk
<Keybuk> hey
<fabbione> Keybuk: sometimes i will need to suck your asterisk foo out of your head for a crash course
<fabbione> Keybuk: when do you think would that be possible for you?
<fabbione> actually.. -ECHAN
<rodarvus> libxvmc uploaded
<rodarvus> Kamion, do you know the status of the sync for libxmu? it was waiting on libxt, which is already built by now
<Kamion> still waiting on the ia64 rebuild of libxt
<Kamion> https://launchpad.net/distros/ubuntu/+source/libxt/1:1.0.0-5build2
<rodarvus> oh, I didn't saw ia64 was still needing build, sorry
<Kamion> floe's down, which doesn't help
<Kamion> hooker on its own kinda struggles to keep up
<Kamion> libxt should build next
<Kamion> rodarvus: ok, you can upload libxt-dependent source now
<rodarvus> Kamion, I will, thanks!
<Kamion> rodarvus: see #52109 - after all that, libxmu's unsyncable
<Kamion> needs to be uploaded by hand as 2:...build1 or so
<rodarvus> damn. you right, of course.
<rodarvus> I'll upload it manually in a minute
<rodarvus> libxmu uploaded
<rodarvus> (I had the package ready here, even with the bumped Epoch, just had to remove the extra Dependencies on libx11-dev)
<Kamion> libxkbui synced
<Kamion> looks like you can upload libxcomposite now
<Kamion> (don't understand why that needed libxt first though)
<Kamion> libxfont can be done safely by somebody now
<rodarvus> Kamion, it didn't depend o libxt, but libxdamage
<rodarvus> I'll adjust status on x-pkgs
<Kamion> ok - libxdamage is done now
<rodarvus> indeed, thanks!
<rodarvus> libxcomposite uploaded
<rodarvus> Kamion, my libxmu uploaded of earlier today was rejected, but it doesn't says the reason for the rejection
<rodarvus> are you able to look at librarian and check what went wrong?
<rodarvus> libxmu_1.0.1-3build1
<Kamion> interestingly the log doesn't say
<Kamion> I've asked ##soyuz1.0 to help
<Kamion> you might want to hop on there
<rodarvus> sure
<rodarvus> libxmu re-uploaded
<rodarvus> I see no sign of crimsun - do you think we should upload libxtrap for him?
<Kamion> possibly, but I'm off ASAP :)
<rodarvus> I will :)
<rodarvus> anyone has lock on libxfont ?
<rodarvus> Mithrandir, ping
<rodarvus> Mithrandir, is libxpm locked on any other package?
<rodarvus> libxmu accepted this time
<rodarvus> libxtrap is uploaded
<rodarvus> LOCK libxfont
<rodarvus> libxfont was uploaded
<rodarvus> Mithrandir, ping
<crimsun> rodarvus: thanks, been in meeting hell all day
<rodarvus> I know the feeling :)
<rodarvus> lixtrap & libxmu are built in all platforms but sparc
<Mithrandir> rodarvus: it's locked on it being weekend here, but otherwise, no.  Feel free to steal the lock.
<rodarvus> Mithrandir, I will, thanks!
<rodarvus> doing it now
<rodarvus> hopefully in a few hours, all libs will be built/published
<fabbione> rodarvus: are they building or did they fail?
<rodarvus> all building
<fabbione> sorry i meant the sparc bits
<rodarvus> fabbione, do you know where I can find the build queue for each machine or arch?
<rodarvus> fabbione, no, still waiting
<fabbione> rodarvus: eh no.. i wish i did
<fabbione> but ask the soyuz guys
<rodarvus> :)
<fabbione> i am sure they can tell you
<rodarvus> I'll do, thanks!
<rodarvus> libxaw uploaded
<crimsun> ohshi
<crimsun> argh, ECHANNEL
<rodarvus> :)
<rodarvus> libxpm is uploaded
<rodarvus> all LIBS are done, hooray!
<crimsun> \o/
<rodarvus> I'll start with apps that have sane build-deps now
<rodarvus> merging apps should be *much* quicker now :)
#ubuntu-x 2006-07-08
<crimsun> hmm, are we actually keeping the apps? Debian doesn't seem to have broken them out quite (or nearly, rather) to the extent that we have
<fabbione> actually you want to do the server and the drivers first
<fabbione> server as very first
<fabbione> then drivers
<fabbione> once that's done go to fix the fonts mess
<fabbione> and as last the apps
<fabbione> there is also the issue of xorg 7.1
<fabbione> UVF is in 5 days?
<fabbione> if we can't get it from Debian we will need to do it ourself
<fabbione> that's about 141 pkgs to update
<fabbione> all of X (as hosted on freedesktop) is 288
<fabbione> but we know there is more like mesa that comes from outside
<ogra_> still doable if there is a UVF exception for X :)
<ogra_> and edgy should be bleeding edge, shouldnt it ;)
#ubuntu-x 2006-07-09
!alindeman:*! Main rotation server having routing trouble.  We're looking into it and taking it out of rotation
#ubuntu-x 2007-07-02
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #22479 in linux-restricted-modules-2.6.15 (restricted) "Clicking "New Login" starts a new X session with corrupt/unreadable display" [Medium,New]  https://launchpad.net/bugs/22479
<ubotu> New bug: #123535 in linux-restricted-modules-2.6.20 (restricted) "After clean install of feisty, followed by nvidia-glx-new, xserver crashes with "no screens found"." [Undecided,New]  https://launchpad.net/bugs/123535
<ubotu> New bug: #30395 in xserver-xorg-video-i810 (main) "X-Server Crashes when switch back from terminal tty" [Medium,Confirmed]  https://launchpad.net/bugs/30395
<ubotu> New bug: #123577 in xorg-server (main) "Xephyr crashed with SIGSEGV" [Undecided,New]  https://launchpad.net/bugs/123577
<ubotu> New bug: #123604 in xorg-server (main) "Xorg crashed with SIGSEGV" [Undecided,New]  https://launchpad.net/bugs/123604
<kylem> bryce, got time today to do -nv 2.1.1?
<bryce> kylem: sure
<bryce> kylem: just working on xorg-server and xrandr at the moment
<bryce> kylem: also, do you know if benc is working on new nvidia for l-r-m?
<bryce> ooh, awesome, includes 8400M support.  yeah that's top priority
<ubotu> New bug: #123621 in xserver-xorg-driver-via (main) "via video driver freeze" [Undecided,New]  https://launchpad.net/bugs/123621
#ubuntu-x 2007-07-03
<bryce> kylem: done
<kylem> thanks.
<bryce> kylem: would you be able to sponsor an upload of the gutsy deb?
<kylem> yeah, sure
<bryce> much appreciated
<ubotu> New bug: #122958 in xorg-driver-synaptics (main) "Trackpad quite sluggish with default acceleration settings (dup-of: 37234)" [Undecided,New]  https://launchpad.net/bugs/122958
<ubotu> New bug: #122964 in xorg-driver-synaptics (main) "Enable two-finger scrolling by default (dup-of: 37234)" [Undecided,New]  https://launchpad.net/bugs/122964
<ubotu> New bug: #37234 in xserver-xorg-input-synaptics (main) "synaptics should allow runtime configuration (eg. Option SHMConfig on)" [Wishlist,Confirmed]  https://launchpad.net/bugs/37234
<tepsipakki> bryce: hey, I'm back to work this and the next week :)
<bryce> heya tepsipakki welcome back!  :-)
<bryce> tepsipakki: I've got this coming week (except wed which is a holiday), but then next week is the gutsy sprint in London
<tepsipakki> it's 25C outside, so a bit hard staying inside pretending to be working
<bryce> I have been focusing on packaging lately, but hope to focus this week on bulletproof-x
<bryce> heh, nice
<bryce> tepsipakki: btw, I did some research into a common error message received on -intel, and have been trying to collect them + workarounds into a table:  https://wiki.ubuntu.com/X/IntelDriverBugs
<tepsipakki> I've got a lot of stuff piled up, and don't know where to start :P
<tepsipakki> bryce: ok, I'll have a look
<bryce> also, I am going to try to get some more folks from ubuntuforum.org involved in testing:  http://ubuntuforums.org/forumdisplay.php?f=238.  I hope people will post on that thread.  Guess we'll see
<tepsipakki> hmm, you use -1 for ubuntu packages?
<bryce> how do you mean?
<tepsipakki> like xrandr (1:1.2.1-1)
<bryce> no, I use -0ubuntu1
<bryce> if I used -1, it's an error
<tepsipakki> right :)
<bryce> aw rats
<tepsipakki> and nv
<tepsipakki> :)
<bryce> thanks, I missed that, damn
<bryce> I'll fix tomorrow
<bryce> also, while you were gone I decided to start a page https://wiki.ubuntu.com/X.  It's pretty ugly so far, but it's a start.  I want to make it into a one-stop-shop for xorg packagers and testers
<tepsipakki> ah, cool
<bryce> I've also made progress on the testing stuff I mentioned before.  Still not quite to a point to show things off, but it's proving handy here locally.
<tepsipakki> I have gutsy on my old laptop (T23), but should get a new one hopefully before gutsy is frozen (a T61 or X61s)
<bryce> cool
<bryce> I have a T30 for testing, but currently it's busted (doing bulletproof-x devel stuff on it)
<tepsipakki> X61s has intel graphics, but T61 has nvidia too
<tepsipakki> and I can't decide which one is more useful
<bryce> mm
<bryce> both seem to have many interesting issues
<tepsipakki> I bet
<tepsipakki> nvidia has more oomph, but..
<bryce> guess it depends on how you intend to use it
<tepsipakki> guess it'll be broken most of the time :)
<bryce> performance vs. compatibility
<bryce> hehe :-)
<tepsipakki> like the current one
<tepsipakki> there's fglrx installation instructions under nvidia on the wiki-page :)
<bryce> oops
<tepsipakki> I'll fix
<bryce> cool thx
<bryce> night
<tepsipakki> yep, see you
<ubotu> New bug: #123712 in xserver-xorg-video-amd (universe) "[gutsy tribe 2]  Live CD fails to initialite AGP on ATI Mobility 9600" [Undecided,New]  https://launchpad.net/bugs/123712
<ubotu> New bug: #43267 in linux-restricted-modules-2.6.20 (restricted) "Redraw problems when scrolling in GNOME" [Medium,New]  https://launchpad.net/bugs/43267
<mvo> bryce: please let me know if -video-nv needs sponsoring
<mvo> bryce: ohn, nevermind :)
<tepsipakki> sweet, intel-2.1.0
<tepsipakki> which should have fixed support for i830
<jcristau> yup, it does
<tepsipakki> I wonder if ubuntu could then dump i810 in favor of intel, the current situation is a bit messy imho
<kylem> tepsipakki, no. there's still issues on i855 and i915
<tepsipakki> duh
<kylem> :\
<ubotu> New bug: #123751 in xserver-xorg-input-evdev (main) "removing grab support is wrong" [Undecided,New]  https://launchpad.net/bugs/123751
<ubotu> New bug: #120811 in firefox (main) "firefox displays fonts smaller than it should have (dup-of: 118745)" [Undecided,Invalid]  https://launchpad.net/bugs/120811
<ubotu> New bug: #123775 in xorg (main) "Synaptics touchpad is incorrectly recogonised as a "ImPS/2 Logitech Wheel Mouse"" [Undecided,Incomplete]  https://launchpad.net/bugs/123775
<ubotu> New bug: #45685 in Ubuntu "Keyboard and mouse stop working in Gnome after typing break" [Medium,Incomplete]  https://launchpad.net/bugs/45685
<kylem> tepsipakki, bryce, fwiw, just uploaded -intel 2.1.0 merged from Debian
<bryce> kylem: awesome
<kylem> did someone sponsor the -nv upload?
<jcristau> hmm, i should upload nv in debian :)
<bryce> kylem: nope
<bryce> should be ready to go though; not sure if anyone besides me has tested it yet, but I had no troubles with it
* bryce digs up dell's bug id...
<tepsipakki> nv should be syncable once jcristau uploads it in debian ;)
<jcristau> my uploads for anything other than intel are utterly untested
<bryce> kylem: oh one thing that reminds me, I forgot to change -1 to -0ubuntu1
<kylem> ah, that's easily fixed.
<kylem> tepsipakki, i dunno if we can sync out of incoming. i'm new to archive powahz.
<jcristau> you can. don't ask me how, though :)
<tepsipakki> bryce: it's been done, but I don't know either
<tepsipakki> ..how
<jcristau> i know it has been done when i was uploading 7.2 stuff
<tepsipakki> yes, seb128 was doing that then
<kylem> ok cool
<tepsipakki> ah, nv has patches, so no sync
<jcristau> i guess i could have a look at your patches... would be easier if they were in git though (hint hint)
<jcristau> ;)
<tepsipakki> hehe
<jcristau> anyway, nv should hit incoming in 5 minutes or so
<kylem> groovy.
<tepsipakki> there are only two of them, one upstream and the other from fedora I think
* kylem needs to hack up his router to http proxy over his two internet connections
<tepsipakki> jcristau: http://bugs.freedesktop.org/show_bug.cgi?id=4686
<ubotu> Freedesktop bug 4686 in Driver/nVidia (open) "comb effect with nv driver (GeForce Fx 5200)" [Normal,New]  
<kylem> bryce, ping me if youw ant me to upload -nv
<kylem> bryce, ben just acked it
<bryce> cool
<bryce> yes if you could upload it, that'd be great
<bryce> (or sync jcristau's - I'm assuming they're the same)
<kylem> ah, want to post yours, i'll debdiff and take a look
<tepsipakki> bryce: no, there are two patches that we have
<bryce> kylem:  sure one sec
<bryce> there is one thing that will differ from debian
<kylem> jcristau, can you add me to the XSF, or should i bug gravit ylater?
<bryce> I reduced the build-dependency for xorg-server-dev back to 1.2.0 so we could build this on Feisty
<jcristau> kylem: i'll do it
<kylem> jcristau, thanks.
<bryce> jcristau, I wanted to ask about this - the changelog says this was done for xsfbs, but I was wondering how critical that was?
<kylem> seems like we'll be backporting most of gutsy to feisty.
* kylem whinges.
<bryce> :-/
<jcristau> bryce: it's needed to generate the dependency on xserver-xorg-core and the xserver-xorg-video-1.0 Provides
<bryce> certain companies need to learn to time their product releases to ours ;-)
<jcristau> but you can hardcode that in debian/control instead in your backports
<bryce> ok
<kylem> bryce, no kidding.
<kylem> i will be ranting about this in london.
<bryce> nice
<jcristau> kylem: you should be in pkg-xorg now (when nscd decides to let you in, that is)
<kylem> ok, thanks.
<ubotu> New bug: #123820 in linux-restricted-modules-2.6.20 (restricted) "nvidia driver useEDID work-around causes worse problems" [Undecided,New]  https://launchpad.net/bugs/123820
<kylem> sigh.
<kylem> bryce, you have any pending changes to mesa? i need to do an upload to get my q33 working. :/
<bryce> nope, you're good
<jcristau> what did you do about the libosmesa soname change btw?
<kylem> i didn't know anything linked to it.
<jcristau> libOSMesa.so.6 used to be in libgl1-mesa-swx11, so packages linked to it might still depend on that package
<jcristau> (in debian, that's the case for tlprender and sppc)
<jcristau> which means i broke them when i moved libOSMesa.so.6 in libosmesa6 in 6.5.2 (oops)
<kylem> hm.
<jcristau> so you might want to rebuild these packages, at least :)
<kylem> sigh.
<kylem> mesa is such a mess.
<kylem> (upstream)
<kylem> -ECHAN
<jcristau> (that said, it's possible the soname change will be reverted upstream, which would be good)
<kylem> someday i will fork mesa.
<kylem> and remove vms support.
<jcristau> heh
<kylem> srsly.
<bryce> heh
<jcristau> it was a lot of fun when it also had an mia debian maintainer
<kylem> heh
<kylem> Subject: Accepted mesa 7.0.0-0ubuntu2 (source)
<kylem> groovtastic.
<bryce> cool
<kylem> seems to be working.
<kylem> 00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 02)
#ubuntu-x 2007-07-04
<ubotu> New bug: #123879 in mesa (main) "[SRU]  feisty missing support for intel graphics hardware" [High,Confirmed]  https://launchpad.net/bugs/123879
<ubotu> New bug: #121966 in xorg (main) "PS3 Fiesty: Running X Windows on a system with huge tables enabled causes massive disc thrashing" [Undecided,New]  https://launchpad.net/bugs/121966
<ubotu> New bug: #61248 in xserver-xorg-input-evdev (main) "Logitech LX-700 Mouse Buttons Scrambled" [Undecided,Incomplete]  https://launchpad.net/bugs/61248
<ubotu> New bug: #123990 in xrandr (main) "xrandr reports wrong version" [Undecided,New]  https://launchpad.net/bugs/123990
<ubotu> New bug: #124023 in xserver-xorg-video-intel (main) "X server I830WaitLpRing crash with PyMOL and direct rendering on Intel 965Q" [Undecided,New]  https://launchpad.net/bugs/124023
<ubotu> New bug: #123813 in Ubuntu "(Gutsy) mplayer crashing x and restarting into GDM login screen (dup-of: 121574)" [Undecided,New]  https://launchpad.net/bugs/123813
#ubuntu-x 2007-07-05
<ubotu> New bug: #124123 in xserver-xorg-video-nv (main) "Please upgrade to 2.1.1 for support of 8400M in Gutsy" [Undecided,New]  https://launchpad.net/bugs/124123
<ubotu> New bug: #53234 in xserver-xorg-input-keyboard (main) "Barcode scanner PSC QS6500 input results in random characters" [Undecided,Incomplete]  https://launchpad.net/bugs/53234
<ubotu> New bug: #124202 in xserver-xorg-video-ati (main) "the driver does not support xrandr" [Undecided,New]  https://launchpad.net/bugs/124202
<ubotu> New bug: #124216 in xorg-server (main) "Xorg crashed with SIGSEGV after logout" [Undecided,New]  https://launchpad.net/bugs/124216
<bryce> kylem: if you have a moment could you upload the 2.1.1 -nv?  http://people.ubuntu.com/~bryce/Uploads/
<kylem> yeah
<ubotu> New bug: #124242 in xserver-xorg-video-i810 (main) "Enabling "compiz" or "beryl" hangs Inspiron 1420n" [Undecided,New]  https://launchpad.net/bugs/124242
<ubotu> New bug: #124254 in xterm (main) "Xterm in gutsy default install's menu" [Undecided,New]  https://launchpad.net/bugs/124254
<kylem> bryce, you have "feisty" in the package changelog.
<bryce> whoops
<kylem> i'll fix it in the upload.
<kylem> Subject: Accepted xserver-xorg-video-nv 1:2.1.1-1 (source)
<bryce> version is wrong too - that should be 1:2.1.1-0ubuntu1
<jcristau> -1?
<jcristau> heh, ok :)
<kylem> ah well, it'll all work out in the end.
<bryce> I'll have a new upload hopefully today
<ubotu> New bug: #47121 in xorg (main) "Graphics and Mouse display problems on AMD Athlon64 X2" [Medium,Incomplete]  https://launchpad.net/bugs/47121
<ubotu> New bug: #47082 in xresprobe (main) "Regression: Screen hangs during text-install" [Medium,Fix released]  https://launchpad.net/bugs/47082
<ubotu> New bug: #124267 in xorg-server (main) "Xorg crashed with SIGSEGV in ShadowWait() after logout (dup-of: 123134)" [Undecided,New]  https://launchpad.net/bugs/124267
<ubotu> New bug: #47234 in xorg (main) "No way to manually set refresh rates" [Medium,Confirmed]  https://launchpad.net/bugs/47234
<ubotu> New bug: #47357 in xine-lib (main) "Installation does not create a symlink to /usr/lib/libX11.so.6" [Medium,Fix released]  https://launchpad.net/bugs/47357
<ubotu> New bug: #122516 in xorg (main) "Display broken when changing resolution in gnome" [Undecided,Incomplete]  https://launchpad.net/bugs/122516
<ubotu> New bug: #121443 in xorg "onboard intel g33 graphics not working in feisty/gutsy" [Undecided,New]  https://launchpad.net/bugs/121443
#ubuntu-x 2007-07-06
<ubotu> New bug: #124353 in linux-restricted-modules-2.6.17 (restricted) "fglrx driver, enable monitor failed in feisty" [Undecided,New]  https://launchpad.net/bugs/124353
<ubotu> New bug: #123749 in Ubuntu "FGLRX black screen with Feisty (dup-of: 96279)" [Undecided,New]  https://launchpad.net/bugs/123749
<ubotu> New bug: #118605 in xorg (main) "Feisty freezes upon Logout or Switch user" [Medium,New]  https://launchpad.net/bugs/118605
#ubuntu-x 2007-07-07
<ubotu> New bug: #59109 in linux-restricted-modules-2.6.15 (restricted) "ath0  ERRORS on dapper drake" [Undecided,Incomplete]  https://launchpad.net/bugs/59109
* Starting logfile irclogs/ubuntu-x.log
<ubotu> New bug: #39315 in linux-source-2.6.17 (restricted) "Keyboard random repeat and dropped key presses" [High,Fix released]  https://launchpad.net/bugs/39315
<ubotu> New bug: #45542 in linux-source-2.6.15 (restricted) "linux-image-2.6.15-23-686 freezes when using irda" [Critical,Fix released]  https://launchpad.net/bugs/45542
<ubotu> New bug: #48263 in linux-source-2.6.15 "[regression]  Wired ethernet (VIA VT6102 Rhine II) and Wireless (RaLink 2500) no longer work under 6.06 (needs acpi=noirq blacklisting)" [High,Fix released]  https://launchpad.net/bugs/48263
<ubotu> New bug: #48287 in linux-source-2.6.15 (restricted) "no network access after ugrade breezy -> dapper" [Medium,Fix released]  https://launchpad.net/bugs/48287
<ubotu> New bug: #38865 in linux-source-2.6.17 (restricted) "sky2 driver freezing system after ifdown and ifup" [High,Fix released]  https://launchpad.net/bugs/38865
<ubotu> New bug: #44782 in linux-source-2.6.15 (restricted) "32 bit overflow in mm/page_alloc.c" [Medium,Fix released]  https://launchpad.net/bugs/44782
<ubotu> New bug: #44783 in linux-source-2.6.15 (restricted) "Patch needed for symlink handling" [Medium,Fix released]  https://launchpad.net/bugs/44783
<ubotu> New bug: #45257 in linux-source-2.6.15 (restricted) "forcedeth not working after dapper upgrade" [Medium,Fix released]  https://launchpad.net/bugs/45257
<ubotu> New bug: #53910 in linux-source-2.6.17 (restricted) "Can't boot: mp-bios bug timer not connected to io-acp" [Undecided,Fix released]  https://launchpad.net/bugs/53910
<ubotu> New bug: #57265 in linux-source-2.6.15 (restricted) "Return value of slave_configure in scsi_scan.c is ignored" [Undecided,Fix released]  https://launchpad.net/bugs/57265
<ubotu> New bug: #25634 in linux-source-2.6.15 (restricted) "Sound on ibook only works after (un)plugging headphones" [Medium,Fix released]  https://launchpad.net/bugs/25634
<ubotu> New bug: #42600 in linux-source-2.6.15 (restricted) "Microphone does not work on Dell Inspiron 630m" [Medium,Fix released]  https://launchpad.net/bugs/42600
<ubotu> New bug: #42919 in linux-source-2.6.17 (restricted) "Only weak sound thrue jack, speakers no sound" [Undecided,Fix committed]  https://launchpad.net/bugs/42919
<ubotu> New bug: #56885 in linux-source-2.6.17 (restricted) "e1000 driver not working properly on x86_64?" [Undecided,Fix committed]  https://launchpad.net/bugs/56885
<ubotu> New bug: #59715 in linux-source-2.6.15 (restricted) "alsa snd-hda-intel hp laptops" [Medium,Fix released]  https://launchpad.net/bugs/59715
<ubotu> New bug: #68659 in linux-source-2.6.17 (restricted) "Certain VIA-based chipsets erroneously enable DXS support" [Low,Fix released]  https://launchpad.net/bugs/68659
<ubotu> New bug: #56939 in glib2.0 (main) "libsdl1.2-dev has trouble installing (dapper) because of libarts-dev dependancy" [Medium,Confirmed]  https://launchpad.net/bugs/56939
<ubotu> New bug: #53705 in xserver-xorg-input-synaptics (main) "Touchpad input support needs bolstering." [Undecided,Confirmed]  https://launchpad.net/bugs/53705
#ubuntu-x 2007-07-08
<ubotu> New bug: #124658 in xorg (main) "xserver-xorg-video-intel should be used on cards that support it" [Undecided,New]  https://launchpad.net/bugs/124658
<ubotu> New bug: #124776 in xserver-xorg-driver-s3virge (main) "[gutsy alternate tribe2 cd]  S3 driver: missing symbol RamDacInit" [Undecided,New]  https://launchpad.net/bugs/124776
<ubotu> New bug: #45878 in xorg (main) "screen freezes when being updated on mouse clicks" [Medium,Invalid]  https://launchpad.net/bugs/45878
<ubotu> New bug: #46690 in xorg (main) "keyboard preference canadian french mac_powerbook_ppc_g3_333mhz" [Medium,Incomplete]  https://launchpad.net/bugs/46690
<ubotu> New bug: #46823 in xorg (main) "Dapper Live-CD starts in 1024x768 only with nvidia ti4200" [Medium,Incomplete]  https://launchpad.net/bugs/46823
<ubotu> New bug: #47033 in xorg (main) "Cannot connect to X server when screen is detached, then reattached" [Medium,Incomplete]  https://launchpad.net/bugs/47033
#ubuntu-x 2008-06-30
<bryce> tjaalton: welcome back!
<bryce> tjaalton: we should get the new xserver and input-hotplug stuff hooked in the next couple weeks (I'm out the 2nd half of July as well)
<tjaalton> bryce: thanks!
<tjaalton> bryce: yep, should be doable
<tjaalton> I'll upgrade my laptop to see how it goes
<bryce> btw, don't know if you saw  the libx11/xcb discussions on the list
<tjaalton> I did, briefly
<bryce> looks like xcb is causing issues, but they can be worked around.  Doing a non-xcb libx11 doesn't look feasible to me due to compiz dependencies on xcb
<tjaalton> right.. it would be ugly
<bryce> but I think we are going to need to pull in some xcb updates from that upstream in intrepid
<tjaalton> upstream should merge the handoff patches, which would make it never to use locking anymore
<tjaalton> IIRC
<bryce> I suspect that's the plan, although I don't have details
<tjaalton> the patches became public in March, but then nothing happened
<tjaalton> I'll probably mail the pkg-nvidia-dev list (debian) about the nvidia mess
<bryce> cool
<tjaalton> and ask if they've noticed that the latest driver dropped support for gf5
<tjaalton> I kinda like the new theme
<bryce> I upgraded my main test box, but now I can't log in (some sort of Xinput error)
<tjaalton> hum, mine works
<tjaalton> this is my old laptop, but tomorrow(ish) I'll upgrade the X60s (intel)
<bryce> yeah no idea.  I abuse the system by putting on lots of experimental stuff, so maybe it just needs a fresh reinstall
<tjaalton> k, need to get some sleep before getting back to work :)
<bryce> night
<tjaalton> night ->
<bryce> wow, phoronix knows a lot about our X plans for intrepid - http://www.phoronix.com/scan.php?page=article&item=ubuntu_810_alpha1&num=2
<pwnguin> public mailing lists, public UDS, public forums, public irclogs
<bryce> yes, but for a tech journalist to actually do research is still a thing of amazement
<tjaalton> actually, the article only shows what upstream is up to, and those naturally end up in intrepid ;)
<tjaalton> xserver 1.5 requires mesa 7.1 etc
<superm1> tjaalton, where are you guys at so far on the nvidia stuff for intrepid?  
<superm1> anything that i can help with to get it rolling?
<tjaalton> superm1: I just got back from vacation, but I guess the problem now is that the latest driver dropped support for GF5 series.. so upgrades are "problematic"
<superm1> tjaalton, ugh, that's fairly ugly
<superm1> so nvidia-new nvidia-new-new nvidia and nvidia-legacy now?
<tjaalton> there were options on how to proseed, but none of them are painless
<superm1> what were the proposed options for proceeding then?
<tjaalton> probably not, the versioning in debian is more sane ;)
<tjaalton> nvidia-...-legacy-96xx etc
<tjaalton> let me dig up the post
<superm1> the first thing that comes to mind for me is a meta package that depends on all of them 
<superm1> or recommends all of them
<superm1> that has a debconf question that sets up symlinks 
<superm1> but that can get rather messy
<tjaalton> tseliot: hi! what is the outcome of the discussion about the nvidia packages?
<tseliot> tjaalton: we can use metapackages for different graphics card series which depend on the real packages
<tjaalton> tseliot: but the real package names remain the same as in debian?
<tjaalton> I'm about to mail them about the issue
<tjaalton> ..that the latest driver dropped support for gf5
<tseliot> we can use driver 96xx for GF5
<tseliot> ï»¿pitti wanted to see something like nvidia-glx-96
<tseliot> ï»¿nvidia-glx-177, etc.
<tjaalton> that's basically what debian has
<tjaalton> maybe he just wasn't aware of it
<tjaalton> mvo: does a dist-upgrade to intrepid still require some hand-holding?
<tjaalton> there was some package that needed to be installed before that..
<mvo> tjaalton: yes and no, we fndutils needs to be upgraded before glibc, but we added a depeneds for this
<mvo> so that should work
<tjaalton> mvo: ok, cool
<mvo> other than that I know currently of no extra hand holding requireed
<mvo> fixed early last week IIRC (glibc is a bit of a beast :)
<tjaalton> heh, I can imagine
<tjaalton> laptop upgrading.. then on to flashy X stuff
<mvo> tjaalton: did you had a chance to make package for the latest -ati and mesa for ati? with the r500 3d stuff :-D ?
<tjaalton> mvo: -ati should be recent enough, mesa needs an upgrade for xserver 1.5 anyway, so when that lands it should work
<mvo> tjaalton: let me know how it works for you (the uprade) I did some tests that looked ok, but gnome is in a lot of flux so sometimes it just refuses to upgrade because ubuntu-desktop is not installable
<tjaalton> maybe this week, next week at the latest
<mvo> rock!
 * mvo hugs tjaalton
<tjaalton> we'll run off to vacation, both bryce and I, after next week :)
<tjaalton> so hopefully there's enough time to iron out the most critical issues that could pop up
<tjaalton> mvo: the dist-upgrade went fine
<mvo> great
<tjaalton> bryce: I'm thinking of putting mesa changes to git.d.o on a branch like xorg/xorg-server
<Q-FUNK> hm
<bryce> tjaalton: do we have that many changes against mesa?
<tjaalton> bryce: no, but it would be easier to pull stuff from upstream now that we need unreleased stuff
<tjaalton> bryce: but it's not a matter of life or death, I can play with stuff on my own branch locally, and when it's ready I'll wrap up a package
<tjaalton> bryce: looks like there'll be a new libdrm today :P
<bryce> ooh!
<tjaalton> which should help a lot
 * bryce nods
<bryce> wonder if the psb guys got their stuff into it
<tjaalton> I think it's basically master without the ttm stuff
<tjaalton> but could be wrong
<bryce> once we get it in, I'll diff against the UME libdrm and see what remains
#ubuntu-x 2008-07-01
<tjaalton> bryce: ok, libdrm 2.3.1 is now released, so I can start :)
<tjaalton> (without having to figure out if builds would break)
<bryce> sweer
<bryce> s/r/t/
<bryce> tjaalton: there's a hug day for Xorg coming up on the 3rd
<tjaalton> bryce: yeah I noticed.. we now have ~1900 bugs :/
<tjaalton> although a lot of those have been originally misfiled and probably fixed already
<bryce> could be
<tjaalton> like "the input hungs" bug
<bryce> I noticed some people have gone through and done a lot of "Ubuntu" -> "xorg" filings
<tjaalton> yeah that's what I meant
<Q-FUNK> some inputs are well-hung indeed.
<tjaalton> hehe
<bryce> tjaalton: with libdrm out, does this mean xserver 1.5 (or 1.4.99999?) is soon to come too?  :-)
<tjaalton> bryce: should be. a couple of new RC's were released yesterday
<bryce> sweet
<bryce> mm, 2:1.4.99.902-1 is in experimental already, with 1.4.99.905 released upstream
<tjaalton> yes, the merge was done against 902
<bryce> cool
<bryce> ok, well bedtime for me.  looking forward to the new xserver :-)
<Q-FUNK> good night! :)
<tjaalton> bryce: night"!
<tjaalton> -"
<seb128> is ati supposed to use xaa by default on intrepid?
<jcristau> yes
<tjaalton> only intel uses exa by default
<seb128> bah
<tjaalton> seb128: exa works better?-)
<seb128> I get warnings in the logs about XAA being unsupported on radeon 9500 and newer
<seb128> and compiz is unusably slow
<tjaalton> that shouldn't be
<seb128> hardy works great on the same box
<seb128> I've a dual boot
<tjaalton> only the driver has changed
<tjaalton> server is the same
<seb128> let me downgrade to the hardy version
<seb128> bah, it takes several seconds to do the opening dialog animation
<seb128> and xorg is using 100% cpu 
<seb128> (still using the intrepid version)
<seb128> no difference using the hardy version
<tjaalton> hmmh
<seb128> the hardy log shows xaa is used too
<seb128> but there is line about it being unsupport and suggesting to use EXA
<seb128> s/is line/is no line
<seb128> in fact the warning is there too, just worded differentlu
<seb128> differently
<tjaalton> can you post the logs somewhere?
<seb128> tjaalton: http://people.ubuntu.com/~seb128/Xorg.0.log
<seb128> that's the intrepid log
<seb128> and http://people.ubuntu.com/~seb128/Xorg.0.log.hardy
<seb128> the log is using the hardy driver on intrepid
<seb128> and the intrepid install is an amd64 one
<tjaalton> hmm
<tjaalton> somehow the intrepid log shows more supported chips than the hardy one
<tjaalton> wonder how that's possible if the driver is the same version
<tjaalton> and the log shows that it should be (6.8.0)
<seb128> that's i386 against amd64 installs
<tjaalton> I don't think it should matter..
<tjaalton> hard to tell what could be wrong
<tjaalton> bryce: all the poulsbo hunks failed to apply on libdrm, so I'd say that the changes are in 2.3.1 ;)
<jcristau> tjaalton: doesn't poulsbo use ttm?
<bryce> tjaalton: if that's the psb stuff in main, you can discard all that
<tjaalton> hmm, actually seems like it's not there after all
<bryce> tjaalton: as they continued updating libdrm their changes got bigger and bigger, and I ended up having to fork a UME-only libdrm 
<tjaalton> bryce: ok, so it can be synced then
<tjaalton> ..when 2.3.1 is in experimental ;)
<bryce> I think jcristau is right that it contains TTM but I haven't gotten a reply from Intel when I enquire about that
<bryce> yup
<tjaalton> maybe they'll GEMify it too
<bryce> I've run a request up the flag pole for them to switch to "a standard libdrm" going forward.  We'll see how that goes.
<bryce> Dave Airlie:
<bryce>         Stuff changed - you need this for Mesa 7.1, and Xorg 1.5
<bryce>         Deal with it.
<bryce> heh
<tjaalton> :)
<tjaalton> btw, libdrm/mesa/xserver/xorg/evdev are close to being ready
<bryce> excellent, I was just wondering that
<tjaalton> bryce: xorg merged.. maybe I should head home :)
<tjaalton> before it's too chilly to cycle
<tjaalton> bbl ->
<tjaalton> bryce: ok, things should be ready now.. libdrm/mesa/xserver/xorg all merged and packages tested on my laptop (not run yet though, since I left it at work)
<tjaalton> so after those are uploaded, all the drivers need to be rebuilt since both input and video ABI has changed
<bryce> ok
<bryce> awesome
<bryce> how do we put in to request those rebuilds?
<tjaalton> reupload as build1
<tjaalton> or ubuntuX if there are changes
<tjaalton> since the packages Provide xserver-xorg-{video,input}-ABIVER
<tjaalton> should we hold the input-hotplug stuff until everything is built with the current versions?
<tjaalton> or add the fdi-files to the drivers? (wacom, synaptics..)
<tjaalton> I mean that it might we wise to get everything updated first, and then start figuring out when to push input-hotplug
<bryce> yeah I think I agree
<bryce> get a reference point in place first, then push input-hotplug in
<tjaalton> right
<tormod> tjaalton: are those packages in the ubunt branches of git.d.o?
<tjaalton> tormod: xorg and xorg-server are, libdrm and mesa from debian-experimental
<tjaalton> build order; libdrm - mesa - xorg-server
<tjaalton> and xorg..
<tormod> you're building xorg without dri then?
<tjaalton> nope
<tjaalton> hmm, did I not push everything..
<tjaalton>     Re-enable dri & glx.
<tjaalton> seems to be there
<tormod> am I looking at the  right place: http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=shortlog;h=refs/heads/debian-experimental
<tormod> no, got it
<tormod> uhm not. this is 13days old: http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=shortlog;h=refs/heads/ubuntu
<tjaalton> ok hold on
<tormod> tjaalton: I basically wonder what you did to the dri/gl.pc stuff that xorg-server looks for
<tjaalton> nothing really
<tormod> xorg-server:configure looks for gl.pc which is not shipped by mesa AFAICS. I used to add them to the libgl1-mesa-dev.install in my xorg-edgers packages but I thought maybe I wouldn't need to any longer.
<tjaalton> grepping doesn't find gl.pc from configure*
<tjaalton> ok, xorg-server changes pushed
<tormod> thanks. configure.ac: 827         PKG_CHECK_MODULES([GL], [glproto >= 1.4.9 gl >= 7.1.0])
<tormod> but not in configure... hmm
<tjaalton> glproto ships glproto.pc
<tormod> no it's the "gl"
<tormod> that I mean
<tormod> it's in configure as well.
<tjaalton> well..
<tjaalton> checking for GL... yes
<tjaalton> so.. :)
<tormod> you have gl.pc on your machine maybe?
<tormod> from which package?
<tjaalton> mesa seems to have it, but it's not in any package
<tormod> "seems to" ? :)
<tjaalton> the source package
<tormod> right. I know, that's why I added it to libgl1-mesa-dev.install for the moment
<tormod> are you building in a pbuilder?
<tjaalton> no
<tjaalton> could pbuilder be taught to use it's own cache?
#ubuntu-x 2008-07-02
<tjaalton> bah, bedtime ->
<tjaalton> ok, the moment of truth.. restarting X
<tjaalton> no drama, things just work
<tjaalton> except compiz, hmm :)
<tjaalton> huh, "Failed to load module "glx" (module does not exist, 0)"
<tjaalton> ah, the path of the object has changed
<tjaalton> mvo: soon you'll be able to test your r5xx ;)
<mvo> hey tjaalton! that is great, looking forward to it :)
<tjaalton> mvo: need to fix the xserver build first, seems that tormod was right after all. gl.pc needs to find a home or no glx
 * mvo nods
<tjaalton> er, mesa & xserver build
<tjaalton> everything else seems to be working though
<tjaalton> mvo: glx works now, but compiz gives me a white screen. Any ideas how to debug?
<tjaalton> (intel)
<mvo> tjaalton: white screen may mean that compiz is confused about direct vs. indirect rendering
<mvo> what does it print on the terminal when it starts? or what got captured in ~/.xsession-errors?
<mvo> it may have other causes too
<tjaalton> "failed to create drawable"
<tjaalton> a number of times
<tjaalton> mvo: with LIBGL_ALWAYS_INDIRECT=1 I can get something, but mostly some corrupt window borders and the rest is black
<tjaalton> mvo: apparently it's a known bug
<mvo> aha, a driver bug?
<tjaalton> 12:08 < MrCooper> the white screen is another reported bug, GLX_EXT_texture_from_pixmap being  incorrectly advertised with direct rendering with DRI1
<tjaalton> 12:09 < MrCooper> sadly those bugs seem to be getting ignored
<tjaalton> in mesa, yes
<tjaalton> so, since we really need to get these uploaded within the next week, compiz might need to blacklist intel for now
<seb128> so anybody has an idea of what changed between hardy and intrepid which makes compiz unusably slow? 
<tjaalton> seb128: have you tried the older kernel?
<tjaalton> hardy kernel..
<seb128> tjaalton: no, why would that makes a difference? just curious
<tjaalton> drm
<seb128> I tried to downgrade the xorg server, compiz and libx11
<seb128> ok, will try that next then
<tjaalton> mesa could also be the culprit, but since it's the stable branch now in intrepid I find it hard to believe it would break like this
<tjaalton> ok, the intel bugs are https://bugs.freedesktop.org/show_bug.cgi?id=14441 and https://bugs.freedesktop.org/show_bug.cgi?id=15477
<ubottu> Freedesktop bug 14441 in Drivers/DRI/i965 "Compiz shows only black screen on i965" [Normal,Assigned] 
<seb128> tjaalton: ok, that's neither linux nor mesa, any other candidate? ;-)
<tjaalton> seb128: nothing comes to mind :/
<tjaalton> tormod might have an idea since playing alot with ati AIUI
<seb128> I'm installing sysprof to see where it's spending cpu
<seb128> 59.68% ressources use in r300_dri.so
<tjaalton> try the 32bit alpha1 livecd
<tjaalton> if the hardy installation was 32bit?
<seb128> it is
<tjaalton> so to rule that out try a 32bit intrepid...
<seb128> but the new installation was hardy amd64 which worked fine
<tjaalton> ah
<seb128> and I upgraded to intrepid
<seb128> and the trouble started
<seb128> ok, tried again without ia32-libs which has a r300_dri.so
<seb128> still as slow
<seb128> sysprofing a dialog resize shows it's spending 95.71 time in X
<tjaalton> strange...
<tjaalton> all I can say ;(
<tjaalton> but, you'll get new mesa/xserver soon anyway :)
<seb128> I downgraded those to the hardy version and still the same issue so I doubt it's due to those
<seb128> trying to install some dbgsym to get details in the sysprof logs now
<tjaalton> sigh, my laptop doesn't stay suspended.. when I close the lid it resumes
<tjaalton> at least hibernate works :)
<tjaalton> gone ->
<pwnguin> my laptop has an annoying habit of having the display come back on after five minutes or so
<pwnguin> close the lid, leave, come back to a closed lid with a display on =(
<bryce> tjaalton: great news on the xserver front
<tjaalton> bryce: well, the intel dri driver is buggy so compiz doesn't work
<tjaalton> maybe you can try to make intel do something about it. the bugs are well known for some time now
<tjaalton> I'm also making mesa to use the new autotoolized build system.. it's getting better but still some work to be done
<bryce> tjaalton: for now maybe just list the known issues on the X/Drivers page that we note as new with xserver 1.5
<tjaalton> bryce: yep, and probably blacklist intel from compiz until the bugs are fixed
<bryce> tjaalton: how long until all the new components will be in the archive?
<tjaalton> I need to finish mesa, which might take a day..
#ubuntu-x 2008-07-03
<tjaalton> yeah, mesa looking good
<tjaalton> duh, not quite
<tjaalton> bryce: libdrm uploaded, but can't build mesa source since master has diverged too much from rc1
<tjaalton> so have to wait for rc2 which should happen RSN
<tjaalton> and I did put all the changes in a git branch but it's only local for now
<tjaalton> patch 101 seems to be of no use, since the code is ifdef'd away (we don't use GLX_TLS)
<tjaalton> so there are no patches left
<tjaalton> I'll be gone for the evening, so hope that rc2 is released by tomorrow :)
<seb128> mvo, tjaalton: I fixed the compiz slowness
<seb128> I had a xorg-driver-fglrx installed which was diverting libgl
<mvo> seb128: how?
<mvo> aha
<mvo> that makes sense!
<tjaalton> seb128: heh, didn't think of that :)
<seb128> what is weird is that I tried to install fglrx for a while
<seb128> but the package is not installable
<seb128> I didn't think I had a buggy old version
<bryce> today is a HugDay for Xorg bugs
<bryce> http://wiki.ubuntu.com/UbuntuBugDay/20080703
<bryce> sweet, cworth is working on GEMifying the 965 code
<tjaalton> I thought it already was
<bryce> heya tjaalton
<bryce> tjaalton: btw there's some hefty Xorg HugDay action over on #ubuntu-bugs
<bryce> https://wiki.ubuntu.com/UbuntuBugDay/20080703
<tjaalton> just got back from the bar :P
<tjaalton> ie. perfect time to abuse some bugs
<bryce> fun :-)
<tormod> tjaalton: hi, building mesa: should the swx confs enable glut? I think they didn't before your autoconf build changes...
<tjaalton> it's friday here already
<tjaalton> tormod: dunno, maybe some other target built them but AFAIK they should be identical
<tjaalton> tormod: btw, you were right about gl.pc
<tormod> "configure" fails on missing glut dependencies. The old build log has nothing about glut.
<tormod> did you run it through pbuilder btw?
<tjaalton> bryce: yeah, played some french tarot, and won ~10e. too bad that all the beers cost at least three times more
<tjaalton> tormod: not yet
<tjaalton> since I can't build a source package out of it
<tormod> I am building on a hardy ppa so I might miss something also.
<tormod> why not?
<tjaalton> deb-exp is basically master, which has diverged from rc1. some files are now symlinks
<tjaalton> so dpkg-source barfs
<tjaalton> I could just copy the debian dir on top of the tarball though
<tjaalton> since the changes in configs/ are irrelevant now
<tormod> well it works here, I merge debian-experimental with f.do git
<tjaalton> you have generated the tarball from rc1?
<tormod> "works" is probably a bit optimistic
<tormod> no, I use git. now I understand, you're using the rc1 tarball?
<tjaalton> tormod: both. I made the tarball from upstream tarballs, and used that with current git to generate the source package -> fail
<tjaalton> some intel files are now symlinks
<tormod> yes, you mean you made the tarball from upstream rc1 tarballs, and used that with current deb-exp git?
<tormod> if you make an orig.tar.gz from upstrean git, it should work, right?
<tormod> tjaalton: see mesa on https://edge.launchpad.net/~xorg-edgers/+archive it failed on amd64 but built lpia and i386
<tjaalton> tormod: yes maybe that should work
<tjaalton> ok checking the build log
<tormod> tjaalton: it says "recompile with -fPIC" but -fPIC was indeed used
<tjaalton> tormod: it might be due to the default flags used
<tjaalton> seen that with vdr
<tjaalton> I have amd64 here, could try to build it locally
<tjaalton> ..but it's hardy
<tjaalton> oh, so is the ppa
<tormod> yes, but with a few updated libraries
<tjaalton> only libdrm should matter
#ubuntu-x 2008-07-04
<tormod> I am uploading an xorg-server to build against that mesa build now - reality check
<pwnguin> does X autodetect work with only USB?
<tjaalton> pwnguin: AIUI yes
<pwnguin> tabletPCs commonly connect via tty, I had thought perhaps the X autodetect stuff might do away with the need for tabletPC =(
<pwnguin> err
<pwnguin> do away with xorg.conf for tabletPC
<pwnguin> well, its good to know that at least it works for usb tablets
<tjaalton> X only knows what hal knows
<tjaalton> so if it can be set up so that hal knows about it before the server is started, it should work?
<pwnguin> ok, so x does talk with hal
<pwnguin> it's never worked for me =(
<pwnguin> i'll bring it up with toshiba-tablet
<tjaalton> it talks with hal to see if there are devices that match some keys
<tjaalton> or something like that..
<tjaalton> so you need to have fdi files to set up the values
<pwnguin> right
<pwnguin> one of the HAL maintainers works with suse
<pwnguin> and tablets
<pwnguin> I need to find some good resources on HAL -- nothing I've found quite hits everything I need to know
<tormod> tjaalton: so mesa seemed to build fine once I added --disable-glut to the swx11 confs in debian/rules.
<tjaalton> tormod: but that would mean that glut is not built at all
<tormod> was it build before?
<tjaalton> it builds here.. maybe it needs something else. or do you mean amd64
<tormod> what builds? my ppa source which already had --disable-glut?
<tormod> no I am not talking about the amd64 failure, I am clueless there
<tjaalton> tormod: no the one from git, builds locally
<tjaalton> what's the error wit glut?
<tormod> first it needed libxmu-dev and libxi-dev to satisfy configure
<tormod> then http://launchpadlibrarian.net/15797046/buildlog_ubuntu-hardy-i386.mesa_7.1.0~git20080703.b3e1f9bd-0ubuntu0tormod2_FAILEDTOBUILD.txt.gz - seems like missing XInput.h etc
<tormod> all this was not needed before the autotools change
<tormod> now xorg-server build fails because dri2 needs GL/internal/dri_sarea.h (wonder what "internal" means)
<tjaalton> use --disable-dri2
<tjaalton> no point in building that
<tjaalton> since libdrm does not support ttm
<tjaalton> 2.3.1 that is
<tormod> libdrm git?
<tormod> or I need a special branch
<tjaalton> modesetting
<tjaalton> yes
<tormod> it built fine before (although it probably was useless)
<tjaalton> don't know if the gem-branch would do
<tjaalton> there should be checks now to disable dri2 if libdrm was too old
<tormod> thanks, I'll wait for that to land on trunk
<tjaalton> heh
<tormod> yes I saw that xorg-server commit, didn't seem to kick in here
<tjaalton> right, GLUT seems to need xmu and xi
<tjaalton> and it was not built before
<tormod> re that libdrm check, maybe my git libdrm declares itself as 2.3.2?
<tjaalton> or 2.4.0
<tormod> looking at the source (configure.ac) it's 2.3.1. strange
<tormod> it's 2.3.1 in libdrm.pc
<tjaalton> ok
<tormod> I see that 2.3.2 check in both configure{,.ac} but the build log shows it passed
<tormod> night
<tjaalton> sigh, too tired to do anything useful.. night
<bryce> night
<pwnguin> is wacom-tools installed by default now?
<pwnguin> im not sure how to query apt to figure this out
<bryce> I'm not sure either
<pwnguin> i'd rather not set up a chroot just to figure out whether ubuntu-desktop draws it in
<tjaalton> the wacom driver is installed by input-all
<tjaalton> ouch, alpha2 next thursday..
<tjaalton> mesa uploaded to my ppa to make sure it builds
<tjaalton> locally it does
<tseliot> tjaalton: why is libgl1-mesa-dev automatically installed in Intrepid?
<tseliot> ï»¿tjaalton: I'm asking because nvidia-glx-<version>-dev will need to remove "ï»¿libgl1-mesa-dev", together with "ï»¿mesa-common-dev"
<tjaalton> tseliot: it shouldn't be automatically installed
<tjaalton> at least the reverse-depends don't show anything suspicious
<tseliot> tjaalton: sorry, I meant the "Automatically installed: yes" when you do aptitude show package
<tjaalton> tseliot: some package that you installed pulled it in
<tseliot> Yes, I had figured that out, no problem then
<tjaalton> funny that in hardy nvidia*dev _depend_ on libgl1-mesa-dev
<tjaalton> are the packages going to be named nvidia-glx-VER?
<tjaalton> I'm just confused about where we are at the moment :)
<tjaalton> right, mesa build failed on amd64
<tseliot> ï»¿tjaalton: honestly I don't know why it depends on ï»¿libgl1-mesa-dev in Hardy
<tseliot> as regards the names, they will be nvidia-glx-177, nvidia-glx-173, etc.
<tjaalton> ok
<tseliot> I will show you the source as soon as the packages are finished
<tjaalton> I don't think I have anything to add :)
<tjaalton> since I've been away for a couple of weeks etc
<tjaalton> you are so much ahead on this
<tjaalton> I almost sent an email to the debian folks about how they are planning on resolving the issues, but didn't
<tseliot> honestly, I don't know if we'll ever manage to have our changes integrated in debian
<tjaalton> right
<tjaalton> so it doesn't matter if we diverge
<tjaalton> even further
<tseliot> yes
<tseliot> shall I still keep the unused files and folders?
<tseliot> the ones from the merge, I mean
<tjaalton> nah, feel free to clean it up as you see fit
<tseliot> ok :-)
<tjaalton> when do you expect to have them ready for upload?
<tjaalton> for alpha2?
<tseliot> Driver 177 is ready i.e. it installs, uninstalls, replaces the old packages with no problems. I'll have to install Intrepid (32 and 64bit) on a real machine so as to see if the driver loads. Currently I'm testing the packages in virtualbox
<tseliot> I have to apply a few changes to driver 173, 96, 71
<tseliot> and test them all
<tseliot> when is alpha 2 due?
<tjaalton> next thursday
<tjaalton> so the packages should be ready by tuesday..
<tseliot> even if the packages were ready by tuesday, the rest wouldn't be ready
<tseliot> i.e. the kernel postinst.d hook, etc.
<tseliot> I'm working on it ;)
<tjaalton> ok, take your time
<tjaalton> unexporting LDFLAGS seems to do the trick for mesa amd64 build
<tjaalton> ok, will upload mesa no
<tjaalton> *now
<tjaalton> bryce: xorg-server uploaded too. when it's built we can start uploading drivers as -Xbuild1
#ubuntu-x 2008-07-05
<alex-weej> pain pain pain
<alex-weej> trying to configure settings for synaptic touchpad (two-fingered scroll) whilst leaving a working device for a bluetooth mightymouse intact
<alex-weej> pretty common use case i'd say, but impossible to do without diving into xorg.conf ?
<alex-weej> hey bryce, do you think you could mentor me on https://wiki.ubuntu.com/Specs/ColourProfilesForDisplays ?
<alex-weej> i think it's within reach of me this summer...
#ubuntu-x 2008-07-06
<bryce> tjaalton: ok cool
<bryce> tjaalton: maybe I can do up a script to automate all those requests
<tjaalton> tseliot: btw, you need to bump the abiver to 2.9 from the nvidia packages
<tjaalton> or drop the Provides..
<tjaalton> or add xserver-xorg-dev build-dep and get the abiver on build time
#ubuntu-x 2009-06-29
<superm1> Sarvatt, if just dropping the .id's should fix it, i'll test without it in place. bryce: canonical should have this hardware available already to debug with.
<tjaalton> Sarvatt: do we still have to change the defaults if those are going to be easily configurable?
<Sarvatt> it should just work with no nv.ids, the primary video device in his xorg.0.log is the 9400M G which isnt supported and is getting matched to -nv because the first card's id matches.. its just whats going to happen with a generic xorg.conf i'm not sure of
<Sarvatt> no xorg.conf -nv is just going to say no so vesa uses it since it'll go through the list of nv vesa then fbdev 
<Sarvatt> i guess it probably will still need the server patch with a generic xorg.conf, nv is going to match from the 10DE catchall and it looks like it only gets 1 try with it there? luckily its just 084x and 086x nvidia device id's that need special handling unless we go nouveau, then we'd need to add those early nvidia cards too
<tjaalton> Sarvatt: was one of those replies for me?-) I was talking about synaptics :)
<Sarvatt> oh!
<tjaalton> whee, mesa 7.5~rc4-1 in experimental
<Sarvatt> sorry, i was confused by what you meant by easily configurable :D
<Sarvatt> should have figured you didnt mean the -nv problem
<tjaalton> heh
<Sarvatt> well, i imagine so because xubuntu and kubuntu arent going to have g-s-d to configure it?
<tjaalton> I'd have thought kde at least had something similar
<tjaalton> since you can configure *everything* there
<tjaalton> :)
<Sarvatt> they do, its called konsole but typing synclient TapButton1=1 is too tough ;D
<tjaalton> lunch->
<Sarvatt> oo, did it get released or still unreleased? regarding mesa 7.5
<Sarvatt> nevermind, i can look :D
<tjaalton> Sarvatt: the package is now in experimental, and available for merging
<tseliot> Sarvatt, tjaalton: my daemon will handle touchpads. I only need to write a UI
<tseliot> s/will handle/handles/
<Sarvatt> whats the daemon for?
<tseliot> Sarvatt: it can load your settings at startup (with a configuration file), it allows to set touchpad (and other input) properties from any language which has dbus bindings. It also allows you to disable the touchpad while you're typing, etc.
<tseliot> I'll blog about it soon
<tjaalton> tseliot: isn't it duplicating effort with g-s-d?
<tseliot> tjaalton: I don't think so. g-s-d is just for GNOME while my daemon can be used in KDE or in any other DE
<tjaalton> but if g-s-d will have the same functionality?
<tjaalton> or mostly the same
<tjaalton> and it's already running on every gnome desktop
<tseliot> from what I have seen, it doesn't
<Sarvatt> it does, just needs to be updated to 2.27.4
<tseliot> Sarvatt: do you have a link to this?
<Sarvatt> http://git.gnome.org/cgit/gnome-settings-daemon/commit/?id=4eb9bd09219afbb56f114a2d10bc585e24db803e
<tseliot> from what I can see they need a function for each property
<tseliot> while my daemon doesn't. You simply pass it the property and a list of values and that's it
<tseliot> g-s-d deal with a limited set of properties
<tseliot> deals
<tseliot> thanks to my daemon we can have access to any property
<Sarvatt> have you seen that things dont use SHMConfig anymore and everything is runtime configurable with synclient or input device properties now?
<tjaalton> how do you determine if it should be running or not?
<tseliot> Sarvatt: I use XInput. No shared memory is involved
<tseliot> tjaalton: ?
<tseliot> it won't be installed by default
<tjaalton> ah
<tjaalton> iow it will be temporary until the native configuration tools do the same :)
<tseliot> they would have to rewrite their current system. But yes, it could happen. What I want is a unified system which we can use in any DE. Each DE should have its own frontend but rely on the same backend
<tjaalton> it's still yet-another-daemon for a single type of hardware
<tseliot> wrong. The frontend will be specific to touchpads while the daemon can deal with any kind of input device which supports XInput
<tjaalton> ok, better :)
<tjaalton> so the ui could be the *DE:s native capplet
<tjaalton> which then would start the daemon if the defaults have been changed
<Sarvatt> ahh ok, i was having problems wrapping my head around why you might want to daemonize something that could be done just once at startup and directly at runtime if something needed to be changed
<tseliot> yes, native applets could be written
<Sarvatt> (synclient, syndaemon)
<tseliot> the daemon does all the work while other applications (or even scripts) can connect to it through dbus to do, for example, what synclient and syndaemon do
<tseliot> it catches events
<tseliot> so that when you unplug a device you can get a signal and, for example, refresh the list of devices in a UI, etc.
<tseliot> or applies the saved settings to the new device
<tseliot> nothing's set in stone yet though.
<Sarvatt> are there any drawbacks to using the secondary slots allocated for driver detection in xserver? i just made a patch making the first slot default to vesa for 084x and 086x (unsupported 8xxx and 9xxx IGP chipsets) and nv otherwise, but i was thinking that maybe we could add nouveau in the first slot and move the vesa/nv choice down to the second since nouveau isnt installed by default. i know it wouldnt be a problem with no xorg.conf bu
<Sarvatt> t i'm unsure with the default xorg.conf what would happen
<Sarvatt> it'll just fail to load nouveau that doesnt exist with no xorg.conf, thats what happens for me with no i810 driver on intel
<Sarvatt> we dont have openchrome autodetection support in karmic's xserver but we have the driver, that'd be useful to add
<Sarvatt> thats the next pci id in line after nvidia and before rendition in xf86AutoConfig.c from git master
<Sarvatt> guess i should try building it with nouveau in the first slot and see what happens with the default xorg.conf since i cant follow the source well enough
<tjaalton> is it the fedora nouveau patch?
<tjaalton> http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/xserver-1.6.1-nouveau.patch?revision=1.1&view=markup
<Sarvatt> kind of, i ripped it out of that since we dont need the detection for the early cards since -nv supports it
<tjaalton> but AIUI we are going to change to nouveau..
<Sarvatt> i was thinking about having driverList[0] = "nouveau"; and driverList[1] = "nv";
<Sarvatt> with no xorg.conf it'll just skip nouveau if it isnt installed
<Sarvatt> but it'd open up the option of having nouveau without explicitly setting it in xorg.conf
<tjaalton> that's the way it's supposed to be done
<tjaalton> patching the server
<tjaalton> because once the xorg merge is uploaded, new installations don't have xorg.conf anymore
 * Sarvatt cant wait for that
<tjaalton> I should probably open a bug about defaulting to nouveau, if there isn't one already
<Sarvatt> so much easier to patch it in here than hunt down how every driver pulls ids
<tjaalton> it concerns xorg, xserver and the kernel
<tjaalton> yeah, forget the ids files
<Sarvatt> if it was up to me i'd make all 10DE default to vesa and opt in ranges for -nv, who doesnt use nvidia binary drivers? :D
<tjaalton> livecd users :)
<Sarvatt> i'm guessing the default device in the default xorg.conf precludes it from using anything but driverList[0], doesnt seem like it tries the rest of the list like it does with no xorg.conf
<tjaalton> it's a completely different codepath
<tjaalton> it doesn't even generate the list
<tjaalton> see the file where the functions are called from
<Sarvatt> wow, no wonder xorg.conf needs to go looking at this
<Sarvatt> guess a patch for superm1's bug wont be so easy after all unless it does
<tjaalton> the ids patch should be dropped, and xorg.conf removed
 * Sarvatt wonders how many little hidden places are making sure theres an xorg.conf like the livecd-rootfs thing
<tjaalton> that's enough
<Sarvatt> well he'd still need a patch making it drop 086x to vesa instead of nv still after that
<tjaalton> yeah, that
<Sarvatt> silly hybrids
<Sarvatt> at least there arent many nvidia/nvidia ones out there and all are using 086x, it shouldnt have his problem if its intel/nvidia or intel/ati because of the 170_primary_pci_device.patch forcing it to use the card on the bus the system is using at boot time as the primary one
<Sarvatt> if i were him i would just make it use the dedicated video always in bios or something instead of being stuck on the IGP always like he is now
<Sarvatt> and it would solve that problem because it would hook the video bios up to the 9400M so it would use the -nv supported driver
<Sarvatt> if linux didnt report being vista to acpi i would say it'd probably be a good idea for them to add a check on which card to use to the dsdt if osvendor matches linux
<Sarvatt> cant imagine many people want to buy a laptop with a fast GPU and be stuck only using the crappier IGP if they use linux because its not going to support switching in userland anytime soon
<Sarvatt> lol that is exactly what some other vendors do
<Sarvatt> sony ones default to the dedicated video if acpi_osi doesnt match vista
<Sarvatt> of course you have to boot with acpi_osi="!Windows 2006" for that to kick in..
<Sarvatt> those are intel/nvidia hybrids though
<tjaalton> according to the spec we are not going to change to nouveau without kms, and since it's not stable yet it's deferred
<tjaalton> and our nouveau version is still over two months old
<tjaalton> wonder if a newer version would've helpe
<tjaalton> d
<Sarvatt> theres a kms enabled nouveau-kernel-source and xserver-xorg-video-nouveau on edgers and nouveau edgers thanks to RAOF
<tjaalton> it's newer than the one in karmic?
<tjaalton> hmm, the latest mesa change added dri.pc, but in the wrong package
<tjaalton> the changelog entry would suggest that it was meant for libgl1-mesa-dev as in debian, but it was added to mesa-common-dev
<jcristau> mesa-common-dev is possibly more appropriate
<tjaalton> o
<tjaalton> k
<tjaalton> I'll leave it there then :)
<jcristau> feel free to move it in the debian branch
<tjaalton> sure
<tjaalton> wait, debian ships it in libgl1-mesa-dev, ubuntu in mesa-common-dev, but it's not guaranteed to be the same on every arch since it's generated during build?
<tjaalton> so isn't libgl1-mesa-dev the best place then?
<jcristau> hrm.
<tjaalton> if it's going to be made arch specific
<jcristau> i guess that was the reason i put it there
<jcristau> but i can't think of a reason it would be arch specific
<tjaalton> true
<tjaalton> all the variables should be the same on every arch
<tjaalton> it'll need a Replaces too?
<jcristau> yup
<tjaalton> done
<tjaalton> and pushed
<jcristau> thanks
<tjaalton> thanks for doing the upload to experimental, it's now ready for karmic
<Sarvatt> tjaalton: hopefully it wont fail building on amd64 90% of the time like it does on PPAs in karmic :D
<Sarvatt> heres a log of a failed one, it'll build right on a retry usually though.. never fails locally or built under a jaunty PPA https://edge.launchpad.net/~sarvatt/+archive/xorg-testing/+build/1095892/+files/buildlog_ubuntu-karmic-amd64.mesa_7.6.0~git20090626.f57280cc-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
<tjaalton> so it's the glu_mangle.h error
<jcristau> looks like it gets installed from both swx11+glu and swx11+glu-static
<Sarvatt> the file it fails on changes every time, that and gl.pc are where it fails more often than not though
<jcristau> easiest way to fix it is disable parallel builds
<Sarvatt> seems like the builds are fine parallel but the installs are racy, but i dont know how to disable the parallel installs without seperating each packages install in rules
<Sarvatt> heyo tormod!
<tormod> hi Sarvatt!
<jcristau> Sarvatt: something like http://paste.debian.net/40563/?
<jcristau> need to make sure it fails if one of the targets fails, but.
<Sarvatt> i will try that right now and upload it to 4 PPAs to see if it fails on any, thanks jcristau
<Sarvatt> ack tjaalton updated origin/ubuntu, need to refresh hooks again
<Sarvatt> nice, no hooks needed now actually
<Sarvatt> hmm tormod, auto-xorg-git doesnt work with the mesa version in origin/ubuntu now :D
<Sarvatt> oh he left
<Sarvatt> ah its because of the package name
<Sarvatt> has a space in front of it by mistake
<popey> I just got a friend of mine to file bug 393510 which is a quite spectacular xorg crash when he touches the mouse touchpad. Any suggestions on where to look for more info would be appreciated.
<ubottu> Launchpad bug 393510 in xorg "X crashes when I touch the mouse pad" [Undecided,New] https://launchpad.net/bugs/393510
<jcristau> Sarvatt: fixed
<Sarvatt> wow, thanks again jcristau!
<Sarvatt> uploaded it to 4 PPAs, it really is a 90%+ FTBS on amd64 so for sure i'll see if its fixed by the install rules change
<Sarvatt> jcristau: the server in sid is exposing dri2 extension version 1.1.0 and the intel 2.7.1 release version doesnt understand that so its still trying to use the old i830DRI2CreateBuffers and i830DestroyBuffers which have been replaced from what I can see? -- http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?h=2.7&id=5ea315944ada3097fe33a14e0c1bdf1268be0308
 * Sarvatt installs 2.7.1 release to see if i get the same problem
<Sarvatt> i cant even get 2.7.1 release version to work at all on xserver master/dri2proto 2.1
<tjaalton> Sarvatt: heh, the changelog bug was a copypaste error.. damn meld doesn't show the arrows anymore, some gtk bug I guess
<Sarvatt> Duke`: did you see idr's reply on dri-devel? got some code you want me to test on 7.6?
<Duke`> yes I've seen
<Duke`> I'll fill a bug report
<Duke`> but now I'm eating :p
<Duke`> Sarvatt: I posted my bug report: https://bugs.freedesktop.org/show_bug.cgi?id=22540
<ubottu> Freedesktop bug 22540 in Drivers/DRI/i915 "VBO is still mapped after drawing, therefore glMapBuffer fails" [Normal,New]
<Sarvatt> what the heck is going on with this fglrx-installer in x-updates.. i think bryce might have ended up binary copying it because the orig.tar.gz's dont match 
<Sarvatt> okie, i'll check it out Duke`
<Sarvatt> yep same error for me on mesa 7.6
<Sarvatt> Before copying data, buffer is mapped
<Sarvatt> Mapping frame 2
<Sarvatt> Mesa: User error: GL_INVALID_OPERATION in glMapBufferARB(already mapped)
<Sarvatt> Segmentation fault
<bryce> erf, sorry yeah I did just binary copy it
<bryce> I built it in my own ppa and then copied it over; I assumed that'd be equivalent to posting it there directly
<bryce> what might be a problem is that I had packaged fglrx-installer myself and posted it for people to test, but meanwhile superm1 also packaged it, and uploaded to ubuntu directly
<bryce> so the packages I did conflict with superm1's due to differing orig.tar.gz's
<superm1> bryce, oh what i put into the archive actually had support for 2.6.30
<bryce> really, my packages should be dropped in favor of new backports of superm1's package
<superm1> bunch of hacked up patches that I gathered on the internets to make it work
<bryce> cool
<bryce> superm1, I never did figure out how to order the 10v with ubuntu with EPP. I ended up just ordering the 10v without the discount.
<superm1> bryce, oh well.  I sent a website bug about the fact that it wasn't showing up on the normal 10 and 10v pages, and it's been assigned, so it should be sorted out somehow
<superm1> you might be able to call and get your discount still
<bryce> it's only $28 so hardly worth the effort, but I might raise it with our program rep on our end; seems weird that it's harder to get the employee discount on stuff running our own software.
<bryce> maybe there's some switch they can flip or something
<superm1> hopefully
<Sarvatt> Duke`: well your gl demo runs fine on i915simple gallium at least
<tormod> I am trying stock karmic (believe me) and glxgears is transparent (on radeon RV410), anyone seen this?
<Duke`> Sarvatt: maybe, but it's totally different code I think
<Sarvatt> yep it is, just trying other things out :)
<Duke`> :)
<Duke`> I wonder if it is related to bug f.d.o #22428
<Sarvatt> phew everything is fugly under gallium, textures missing even on the simplest of demos
<Sarvatt> thats the commit i linked isnt it
<Duke`> yeah I think
<Sarvatt> xdemos/glxcontexts runs fine for me
<Sarvatt> i'm on an aspire one like the original report person is too
<tjaalton> bryce: so, xorg and mesa.. could those be uploaded soonish?
<bryce> sure, do you want to upload or would you prefer me to do it?
<Sarvatt> it actually requires dri2proto 2.1 now btw, wont even be able to build it until you bring that over
<bryce> yeah I'll file a sync request for that
<Sarvatt> https://bugs.edge.launchpad.net/bugs/391005
<ubottu> Ubuntu bug 391005 in x11proto-dri2 "[Sync Request] Please sync x11proto-dri2 (2.1-1) from Debian [unstable] (main)" [Wishlist,Confirmed]
<tjaalton> bryce: I can do those tomorrow
<bryce> tjaalton, sounds good
<bryce> Sarvatt, huh, wonder why that hasn't gone in
<Sarvatt> intels the only driver that will need a rebuild after updating x11proto-dri2 at least
<bryce> Sarvatt, but only after also updating xorg-server, right?
<Sarvatt> yeah
<bryce> yeah so it's pretty traditional to do a mass-rebuild of drivers following the xserver update
<bryce> in fact I think tjaalton has a handy dandy script for doing it
<Sarvatt> only other thing that uses it is ati KMS
<bryce> Sarvatt, I bumped the dri2proto syncreq and subbed pitti, so hopefully that should accelerate it a bit
<tjaalton> yeah I have a crude script to do that
<Sarvatt> jcristau: thanks again for the help, breaking up the install in debian/rules for mesa did fix it
<Sarvatt> forgot a ; though, i was slow and uploaded it without that and it took 4 hours for it to build for me to notice :D http://pastebin.com/m433e64d5
<Sarvatt> it built on 4 PPAs without any problems vs the 90% failure rate on karmic amd64 normally
<lesshaste> I was about to upgrade from intrepid to jaunty when it told me there is no fglrx driver for jaunty... what is the situation there?
<Sarvatt> fglrx doesnt support anything under hd 2xxx anymore
<lesshaste> Sarvatt: sorry what is hd 2xxx?
<lesshaste> and does this mean no accelerated 3d in jaunty for my graphics chip?
<Sarvatt> ati HD 2000 series
<lesshaste> oh so mine is just the rs480 onboard graphics chipset
<Sarvatt> you use xserver-xorg-video-ati now combined with mesa for 3d
<Sarvatt> the binary driver doesnt support your card anymore
<lesshaste> is this the same as the radeon open source driver?
<Sarvatt> yep
<lesshaste> ok.. that's not as bad as it was right?  The specs got released.. or something like that :)
<Sarvatt> it has come a long way since intrepid
<lesshaste> ah.. radeonhd is not the same as radeon :)
<lesshaste> I am slowly catching up
<Sarvatt> i put a patch here with proper whitespace incase you guys want to use it, its from jcristau and fixes the ftbs with mesa in karmic on PPAs (and probably in the archive) http://sarvatt.com/downloads/mesa_build.patch
#ubuntu-x 2009-06-30
<maxb> It's weird how some people say ftbs and some say ftbfs
 * maxb is in the ftbfs camp
<Sarvatt> that was fast, x11proto-dri2 synced :)
 * bryce grins
<bryce> actually, slangasek said it was already autosync'd?
<Sarvatt> it wasnt when i looked at aptitude show x11proto-dri2-dev this morning! odd
<Sarvatt> -vv rather
<Sarvatt> theres xserver 1.6.2 rc2
<RAOF> Do we want to pull in the couple of libdrm-nouveau patches needed to libdrm to pull in a new nouveau snapshot into Karmic?  I can pull them into libdrm git on alioth if so.
<bryce> RAOF, sure as long as it doesn't conflict with -ati's
<bryce> Sarvatt, yeah dunno, was it only in debian experimental before?  (which wouldn't get autosync'd... however I didn't mention that in my sync request)
<RAOF> bryce: What part would conflict with -ati's?  ATI doesn't yet ship a libdrm-radeon (at least in any libdrm release) as far as I can see?
<RAOF> I guess the ttm & drm modules from nouveau-kernel-source *would* conflict with ATi's stuff in 2.6.31, but that'll only be pulled in by x-x-v-nouveau.
<jcristau> Sarvatt: dri2 1.1 ought to be compatible with 1.0
<jcristau> it's not, but that's a bug.
<tjaalton> jcristau: does it concern mesa too? I mean, would something break if mesa was built against it?
<jcristau> tjaalton: the issue seems to be in the server/driver interface, so no
<tjaalton> ah, great
<tjaalton> mesa and xorg uploaded
<tjaalton> huh, seems I didn't fix the mesa build properly
<tjaalton> since lpia failed already
<tjaalton> Sarvatt: did you apply the exact same patch from jcristau, or modified?
<tjaalton> anyway, need to do some shopping and then head back home.. I'll sort this out once there
<jcristau> heh, missing ;
<tormod> dpkg: error processing /var/cache/apt/archives/xserver-xorg_1%3a7.4+3ubuntu1_i386.deb (--unpack):
<tormod>  trying to overwrite `/usr/lib/hal/debian-setup-keyboard', which is also in package hal
<tormod> sorry that was fixed 15 minutes ago I see
<tjaalton> yep :)
<tjaalton> and looks like the mesa build went fine too
<bryce> tjaalton, thanks for the mesa and xorg uploads!
<tormod> finally mesa 7.5 in karmic \o/
<tormod> well failed to build all over the place though
<tormod> tjaalton: jcristau	heh, missing ;
<tjaalton> tormod: yes, uploading a new one right now
<Sarvatt> tjaalton: i modified it because of the missing ; and linked a fixed up one last night but it looks like you already worked it out, sorry about that
<tjaalton> Sarvatt: yeah, it's good now
<A|i> since upgrading to 9.04, my ubuntu freezez randomly
 * Sarvatt cheers at all the uploads today
<A|i> when it freezes, nothing works, i have to force the machine to restart
<tormod> is it normal that I have xlibmesa-gl-dev installed? can't see what depends on it
<tormod> A|i, what card do you have?
<A|i> tormod, radeon 9600
<A|i> yes, it's unsupported in jaunty
<tormod> A|i, unsupported, why? is it agp?
<A|i> tor, i mean the  amd/ati driver cannot be used as jaunty uses the new xorg
<A|i> this is really frustrating
<tormod> A|i, you don't need fglrx
<A|i> tormod, i'm using the free driver (which sucks)
<A|i> it's very slow
<tjaalton> tormod: nope, I don't have it here and I have a lot of headers installed
<A|i> tormod, the worst part is that, when it freezes, i lose data on my ntfs drives
<tormod> tjaalton, thanks. this was a recent, clean install of karmic but I have been through xorg-edgers packages etc
<tormod> A|i, it can be a bit slower than fglrx but should be useable. and definitely not lock up. is it AGP?
<A|i> tormod, yes
<Sarvatt> thats installed by a metapackage tormod, are you sure you didnt come from hardy or something? :D
<A|i> tormod, any idea how to avoid the freezing? googling shows many people have this problem in jaunty, but no solution
<tormod> Sarvatt, as I said, clean karmic install - from your kms cd :D
<Sarvatt> apt-get build-dep anything?
<tormod> A|i, link to bug report?
<tormod> Sarvatt, good idea. I guess those do not show up in apt-cache (r)depends
<A|i> tormod, here is one: http://ubuntuforums.org/showthread.php?t=1141320
<tormod> A|i, that is not a bug report
<A|i> tormod, but it's very difficult to trace this problem
<A|i> i know, i don't know if anyone has submitted one
<tormod> A|i, I know, but you can't expect developers to search the forums for bugs to fix
<A|i> tormod, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/364828
<ubottu> Ubuntu bug 364828 in linux "Ubuntu 9.04 freezing" [Undecided,Invalid]
<tormod> A|i, there is not much harm in filing a new bug and attaching info
<tormod> A|i, that bug was closed because it was fixed.
<A|i> it wasnt
<tormod> A|i, the reporter could not reproduce it any longer -> closed. anyway it was nvidia cards
<tormod> A|i, those bugs are highly specific to each driver and often a family of cards
<A|i> tormod, yes, but re-constructing this bug is impossible
<A|i> i dont really have much to report
<A|i> it doesn't get logged too
<tormod> A|i, I know but please file a bug using "ubuntu-bug xserver-xorg-video-ati"
<tormod> this will attach relevant information
<tormod> A|i, let me ask for the 3rd time: is it an AGP card?
<A|i> tormod, yes, i answered yes, how can i verify this? is there a command?
<tjaalton> probably needs an AGP quirk?
<tormod> the log that will be attached to your bug report will confirm this
<tormod> yes very probably an AGPMode issue
<tormod> A|i, sorry I missed your "yes" in all the talk
<A|i> what should agpmode be set to?
<tormod> A|i, trial and error, your choices are 1,2,4 or 4,8 depending on your card
<tormod> A|i, please see https://wiki.ubuntu.com/X/Quirks#ATI%20AGP%20Mode%20Quirk
<tormod> A|i, if you follow up (on launchpad) with this info we can easily fix it
<A|i> tormod, i think my agp goes up to 16x, and in bios i set it to 8x, does ubuntu overwrite this again?
<tormod> I don't think AGP x16 exists...
<A|i> tormod, it is similar to this bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/349229
<ubottu> Ubuntu bug 349229 in xserver-xorg-video-ati "[RV350] system freeze randomly, need hard reset" [Undecided,Confirmed]
<A|i> but they dont talk about agp?
<A|i> tormod, how can i find out my current agp mode?
<tormod> A|i, well they should if the reporter has an agp card :) but anyway file your own bug. different cards - different bugs and quirks
<tormod> A|i, grep "agp..Mode" /var/log/Xorg.0.log
<A|i> (II) RADEON(0): [agp] Mode 0x1f000a0a [AGP 0x1106/0x0282; Card 0x1002/0x4152 0x174b/0x7c19]
<A|i> tormod, the above is not 1,2,4,8?
<tormod> A|i, it's bit encrypted: the last "a" in the Mode says this is an 4/8 card.
<A|i> tormod, but does it say if it is currently on 4 or 8?
<tormod> and the mode is 4 IIRC. try setting 8
<A|i> ok, thanks
<tormod> well try both and you'll see
<A|i> ok,.. i'm going to restart x and wait for it to (not) to happen!
 * tormod looks for his agp mode parsing script
 * hyperair is annoyed that the key repeat settings seem to not get set correctly for newly plugged in keyboards
<tormod> for radeon hangs new in Jaunty there is also http://bugs.freedesktop.org/show_bug.cgi?id=21849
<ubottu> Freedesktop bug 21849 in DRM/Radeon "many lockups since 2.6.30-rc1" [Critical,Resolved: fixed]
<tormod> (since the 2.6.30-rc1 stuff in question was backported to the Jaunty kernel)
<bryce> how things going tormod?
<tormod> bryce, fine thanks, but too much nice weather for any serious hacking
<bryce> tormod, is it time for us to update -ati?  I think we've done updates to all the other drivers so far, I haven't checked where -ati is at tho
<bryce> hehe, quite true
<tormod> it is always time to update -ati :) at least the 6.12 branch is a no-brainer
<tormod> there has been many card-specific fixed, PCI ids and such
<tormod> now is a good time to snapshot master, before they put kms in there
<bryce> tormod, ok we can pull in a new snapshot; is the current one in xorg-edgers good, or is there a different commit id that is more stable?
<tormod> I haven't heard about any regressions
<tormod> I would pull up to bb04... just before the kms preparation
<tormod> which I have in my PPA I think
<bryce> bug tracker seems reasonably quiescent
<Sarvatt> 	Check if the composite op is supported in R200CheckComposite. isnt in the one on edgers
<tormod> yeah that's bb04
<Sarvatt> the got commited like 10 minutes after i uploaded the package lol
<bryce> mm, that change is listing as e1a582fd in my tree; maybe I'm on a branch
<bryce> # On branch 6.12-branch
<bryce> aha
<tormod> the 6.12-branch is for SRU and old ladies, I think master is pretty safe at this point
<bryce> hehe
<bryce> ok sonny
<Sarvatt> maybe we should clean up .gitignore and lastcommit files in auto-xorg-git? noticed some stuff hanging around in orig.tar.gz while making debdiffs
<bryce> good idea
<Sarvatt> could the lastcommit, delete it before creating the orig then make it again after if we need it to hang around?
<Sarvatt> could delete rather
<Sarvatt> wow, i cant speak today!
<tormod> I'd say leave it in, but do not add it to the orig.tar.gz
<Sarvatt> oh that too, could add --exclude=.gitignore --excluse=.lastcommit right?
<tormod> yes
<bryce> so... you guys have a preference, should I pull tormod's package from his ppa, or pull sarvatt's and apply bb04 as a patch?
<tormod> mine is using experimental, sarvatt's is from debian-unstable
<tormod> I am not sure if there is a difference
<Sarvatt> unstable was newer when i looked
<Sarvatt> http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-ati.git;a=summary
<bryce> ok, sounds like sarvatts+patch is the way to go
<tormod> might be some pci id changes in debian/
<tormod> or you use auto-xorg-git to roll your own :)
<bryce> in debian/patches ?
<Sarvatt> i dont know, you probably want to remove the hooks for ati anyhow so i would use another
<tormod> I just checked http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-ati.git;a=history;f=debian;hb=refs/heads/debian-unstable
<tormod> there is a pci id difference from experimental
<Sarvatt> yeah unstable doesnt install them
<tormod> yes, maybe you don't want that git commit ID patch we add through the hooks
<bryce> hmm
<tormod> doesn't hurt though
<bryce> btw, I nuked the karmic fglrx and nvidia packages from edgers; they're in karmic already.  I saw we were up to 99% full on the ppa
<tormod> I've asked for more space, maybe you can kick your colleagues :)
<bryce> I'd like to keep the jaunty versions a bit longer since I'd asked folks to test those, but we can drop them later since they're in x-updates
<tormod> yes, I won't miss the blobs in xorg-edgers
<bryce> tormod, ok is there a bug# or person I can reference?
<tormod> bryce, I asked on soyuz answers.lp.net
<bryce> yeah in the future I think I should post them to x-updates myself rather than going through xorg-edgers to avoid clashing with other libs in edgers
<Sarvatt> we could move hardy and intrepid to another PPA via binary copies and clean it up :D
<tormod> well there is not much for intrepid and some people are using it for hardy (LTS and all that)
<tormod> would be nice if they fix launchpad to filter releases by default, or as a ppa setting
<Sarvatt> desktop support ended though (excuse excuse!) :D
<Sarvatt> bryce actually gave me a link that lets you filter it, you can do it manually screwing with the url lol
<bryce> tormod, ah I notice you requested on the original space request, but it seems to have scrolled off the list so maybe they've not noticed; I'll file a new request
<tormod> oh is that true? isn't it until 9.10 or something?
<tormod> bryce: it's there if you filter on Open
<tormod> I hope the soyuz people filter on open, another thing that could have been default :)
<Sarvatt> https://edge.launchpad.net/~xorg-edgers/+archive/ppa?field.series_filter=jaunty
<tormod> isn't LTS supported on the desktop until next LTS?
<tormod> maybe we can add those links in the header of the page?
<Sarvatt> trying to find where i read it, i think it was like 18 months desktop and the rest is just security updates so that would put it at 9.10 then
<tormod> oh for lock-ups in jaunty there is also https://bugs.edge.launchpad.net/bugs/355155
<ubottu> Ubuntu bug 355155 in linux "Clocksource tsc unstable leads to lockups in Ubuntu Jaunty" [High,Triaged]
<bryce> tormod, LTS's are supported for longer than just the next LTS
<bryce> aiui, dapper is just now going away
 * tormod actually runs hardy on some lab computers
<Sarvatt> clocksource tsc unstable is just a harmless error message with how it checks it on bootup though...
<bryce> https://answers.edge.launchpad.net/soyuz/+question/75728
<tormod> Sarvatt, the bug has importance=high ?
<Sarvatt> i havent looked at that bug yet but i'm just going to go out on a limb and guess they have vbox or  kvm modules loaded
<Sarvatt> i get clocksource tsc unstabled on every pc that is able to change its frequency dynamically
<tormod> Leann triaged it to High so there must be something to it
<Sarvatt> oh tormod, I'm sorry, i was thinking of 6.06 desktop support. sheesh :)
<tormod> omg the 355155 bug mentioned has become a metoo black hole
<Sarvatt> because of the title!!!
<Sarvatt> everyone with multiple cpus or cpus that can change frequency get that in dmesg!
<Sarvatt> its not a bug, it just means it cant use TSC as the clock source which is intentional, it falls back to acpi_pm
<Sarvatt> sudo cat /sys/devices/system/clocksource/clocksource0/available_clocksource
<Sarvatt> sudo cat /sys/devices/system/clocksource/clocksource0/current_clocksource
<bryce> 231 comments, not bad
<tormod> tjaalton, seems like the new xorg (?) broke X via gdm. startx works
 * bryce adds comment, "This bug affects me too!  But I have different hardware.  When will it be fixed???"
<tormod> Warning:  Could not generate /etc/X11/xorg.conf.failsafe for vesa driver
<tormod> bryce, go back to windows :)
<tormod> and my keyboard layout is lost
 * Sarvatt makes a note to not reboot anytime soon :D
<Sarvatt> oh man, right as I said that i noticed my battery had .5% power left
<Sarvatt> g-p-m wont stay open longer than 30 minutes or so lately for me so i've been checking it manually
 * Sarvatt makes a new bug saying Cannot allocate resource for EISA slot 1 error in dmesg causes lockups in Jaunty
<tormod> did anyone else try restarting X after the last updates, or find out something_
<Sarvatt> how did you even install all of the updates?
<Sarvatt> or did you not notice the error?
<Sarvatt> oh now its published, sweet
<tormod> from the general silence I suppose everybody is staring at their text consoles :)
<Sarvatt> i'll try now
<rick_h_> tormod: well I stopped gdm on boot
<rick_h_> and setup an .xinitrc
<rick_h_> and so have things 'working'
<rick_h_> but I was a moron and updated when I shouldn't have so taking my licks
<rick_h_> although booting my WM this way is causing issues with my fun .Xresources/.Xmodmap stuff
<tormod> rick_h_, you can just run startx instead of making an .xinitrc right?
<rick_h_> tormod: yea, but to get awesomeWM started as my default WM I exec awesome in my .xinitrc to get the right WM
<jbarnes> bryce: you'll want cec9fc6f6cffce186606f39982d0d78ff7c63bbf from the 2d driver
<jbarnes> should fix the dpi differences people have been seeing, along with the display properties applet in the kms case
<tormod> if awesomeWM has a desktop file you can choose it in a gconf setting somewhere
<rick_h_> yea, I have it setup as a default in gdm and it works ok there. 
<tormod> rick_h_, I see
<rick_h_> but since gdm is blowing up on me and locking up my X and all this way is working
<rick_h_> and once I get my blown up screen from GDM, ctrl-alt-1-6 won't give me a terminal either
<tormod> rick_h_, intel?
<rick_h_> yea
<rick_h_> T61
<tormod> the joy of kms I suppose
<rick_h_> well I knew better. I am heading out of town and figured I'd do updates before I left
<rick_h_> then boom :)
<tjaalton> tormod: how could that be?
<tormod> tjaalton, did you not experience it?
<tjaalton> I should probably try :)
<tormod> dog food :)
<tjaalton> testing ftw
<tormod> I guess gdm fails to start x then failsafeX fails because it tries to run dexconf (which it should not any longer, right?)
<tjaalton> which kernel?
<tormod> 2.6.30-10-generic
<tjaalton> .31 fails here, intel claims no modes
<tjaalton> ok
<tormod> 2.6.30-10.12-generic to be precise
<tjaalton> I'm still running -8, because of the dpms hanger
<tjaalton> anyway, upgrading now..
<jbarnes> Sarvatt: just fixed the bug where in KMS mode outputs didn't have the EDID blob
<Sarvatt> yes, very broken and I couldnt figure out why. its forcing failsafe mode no matter what for some reason
<jbarnes> which makes the display applet easier to use and will probably fix the dpi differences between kms and ums
<Sarvatt> actually had to boot up windows here so i can look through the changes to try to figure it out
<Sarvatt> oh nice!
<Sarvatt> it might be a bit until i can update edgers, in windows atm because of problems in karmic :D
<jbarnes> ouch
<bryce> jbarnes, thanks
<tormod> this looks messed up:
<tormod> gdm[14980]: DEBUG: Loading locale string: Welcome (null) 
<tormod> gdm[14980]: DEBUG: Key file does not have key 'Welcome'
<tormod> or maybe not
<bryce> heh, guess xorg should have been staged on xorg-edgers first
<tjaalton> I'll debug it goddammit :)
<tormod> heh this is messed up:
<tormod> DEBUG: gdm_server_spawn: '/usr/X11R6/bin/X 
<tormod> X11R6 ?
<bryce> well, the good news is half the desktop team was just complaining a few hours ago that are using xorg-edgers too much and not putting stuff in ubuntu quickly enough for people to test ;-)
<tjaalton> tormod: good catch
<tjaalton> so gdm needs fixing.. seb128? :)
<seb128> tjaalton, what is broken?
<tormod> been too long without any X breakage, about time we get some fun
<Sarvatt> are we not creating the symlink to X in the postinst now?
<tjaalton> seb128: gdm.conf still references /usr/X11R6/bin/X which is finally gone
<tjaalton> seb128: it should use /usr/bin/X instead
<seb128> tjaalton, and you uploaded that?
<seb128> tjaalton, without testing?
<tjaalton> seb128: why yes :/
<seb128> bah
<seb128> great
<tjaalton> the package has a Breaks for it, but the debian version
<tjaalton> I could fix that
<seb128> well that will be as quick to fix gdm now
<tjaalton> ok..
<seb128> but that means anybody upgrading between now and some publisher run later will have broken xorg
<tjaalton> right
<seb128> we should not give upload rights for base components to people not testing before upgrading
<tormod> they can still use "startx"
<seb128> sorry for the rant looking at fixing gdm now
<tjaalton> np, deserve it
<tjaalton> too much vac :P
<tjaalton> well, say I didn't use gnome or gdm, this bug would have gone unnoticed anyway ;)
<tjaalton> I'll let the forums know
<Sarvatt> ahh yeah * Don't ship the /usr/X11R6/bin symlink in x11-common.  Break gdm <<
<Sarvatt>     2.20.7-5.
<seb128> tjaalton, gdm change uploaded, you might still want to update the break to gdm <= 2.20.10-0ubuntu3 in the next upload
<tjaalton> seb128: yeah, will do
<tjaalton> seb128: thanks for the quick update, and sorry for the trouble at this hour!
<seb128> no problem, happens to everybody
<tjaalton> uploaded
<tjaalton> Sarvatt: fixed livecd-rootfs to not touch xorg.conf anymore
<tjaalton> pushed to bzr
<Sarvatt> phew, editing the links to use /usr/bin/X instead in gdm.conf did fix it for me, there were multiple places it was calling it in there so it threw me off since i only edited the first :D
<bryce> hey sarvatt, I've a handy script you might find useful... I'll post to ubuntu-x@
<Sarvatt> gotta love etckeeper :) http://sarvatt.com/downloads/0001-saving-uncommitted-changes-in-etc-prior-to-apt-run.patch.txt
<Sarvatt> oo, what about bryce?
<bryce> changelog merges
<Sarvatt> oh nice!
<Sarvatt> holy heck g-p-m output is rediculious
<Sarvatt> 200k of output into .xsession-errors in 5 minutes :D
<bryce> -ati snapshot uploaded to karmic
<bryce> Sarvatt, I also stuck it in xorg-edgers, although that probably wasn't necessary
<bryce> Sarvatt, tormod: xorg-edgers can move on to focus on -ati+KMS work now :-)
<Sarvatt> jbarnes: very nice! just looked over the changes, new one is uploading right now
<tormod> bryce, can you ping apw about a newer kernel again? :)
<bryce> sure
<Sarvatt> yeah we need a linux-libc-dev that has all the radeon KMS stuff that doesnt get built if its not enabled in staging as far as i can see
<bryce> ah, Sarvatt, could you write up what's needed in an email to ubuntu-x@?  Then I'll forward that along
<bryce> I need to get re-caughtup on kms stuff, I've been focused just on bug stuff exclusively this last week
<bryce> ok, time to go do DEQ/DMV stuff...  bbiab
<tjaalton> jcristau: the fdi file change probably makes sense for debian too
<tormod> bryce, I would link to bug_1734 on your blog, but it requires a login.
<apw> bryce, i keep forgetting, how is radeon kms in stock karmic userspace
<tormod> apw?
<Sarvatt> not working, they are *just* getting it up at least with kms and no libdrm-radeon1 as of a few hours ago in -ati 
<Sarvatt> funny, it requires libdrm-radeon1 to build kms support, but says "It won't build against libdrm radeon yet either"
<Sarvatt> oh nevermind, the check in configure.ac is just there to check further if it should build dri2 support if DRM_MODE is yes and that part isnt working
<Sarvatt> yeah that mesa rules change for sure fixed things, 16 builds with no failures now.. that was annoying me for a month having to babysit the retry button every day :D
#ubuntu-x 2009-07-01
<A|i> when i enable compiz, i don't see: Option "Composite" "Enable", in my xorg.conf?
<A|i> (ati radeon 9600, ubuntu 9.04, xorg driver)
<Duke`> check in Xorg.0.log for COMPOSITE
<A|i> Duke`, maybe zorg 7.4 doesn't need that?
<Duke`> this option is probably automatically enabled, look in your Xorg.0.log
<A|i> Duke`, thanks, it is
<Duke`> it's the case for intel
<A|i> Duke`, i have very slow scrolling in firefox though
<tjaalton> hasn't been needed for a long time
<A|i> i tried Option "MigrationHeuristic" "greedy", but scroll is not smooth at all
<tjaalton> A|i: dunno, maybe the upcoming xserver 1.6.2 might help with exa performance
<A|i> tjaalton, any idea when is it due to?
<tjaalton> this week, but not coming to 9.04
<A|i> tjaalton, so we have to wait for 9.10?
<tjaalton> although it'll likely end up in a ppa where you can install it from
<tjaalton> bryce: what do you think if failsafe would be reworked to just move the conffile out of the way if it causes trouble? the server handles fallbacks in that case anyway
<jcristau> tjaalton: can you file a debian bug for this fdi thing?
<tjaalton> jcristau: I can "forward" the ubuntu bug, there's the proper explanation about it
<tjaalton> jcristau: also, if xserver-xorg postinst for some reason fails to restart hal, the configuration fails.. maybe it should continue regardless?
<jcristau> why would hal restart fail?
<seb128> does it makes a difference?
<tjaalton> I don't know, but for instance in bug 393948 it happened to someone
<ubottu> Launchpad bug 393948 in xorg "Error in update [Karmic]" [Undecided,Fix released] https://launchpad.net/bugs/393948
<seb128> it happened on the buildds yesterday too, sysfs was used or something
<seb128> +not
<jcristau> on buildds invoke-rc.d should be a nop
<seb128> in any case package installs should be robust, there is no reason an upgrade should break if a service doesn't start
<tjaalton> jcristau: bug sent
<tjaalton> now tennis ->
<jcristau> tjaalton: btw i sent a [vac] message to d-private, as i'll be busy with rl stuff for the next months
<tjaalton> jcristau: oh, I guess congrats are in order then ;)
<jcristau> hmm?
<jcristau> if you're thinking child, then no.  just need to write my phd thesis, and i can't do that and maintain X in debian at the same time :)
<tjaalton> no I mean taking some time off, for whatever the reason :)
<jcristau> hah
<jcristau> tjaalton: it's not really time off :)
<tjaalton> jcristau: 
<tjaalton> uh
<tjaalton> jcristau: I know.. I need to get cracking with my master's next month
<bryce> tjaalton, with failsafe x, maybe we ought to re-analyze what situations it is actually useful for
<bryce> tjaalton, like, if it is to get around driver bugs, then moving xorg.conf aside would not help much, but if it is mainly for goofed up xorg.conf syntax, then yeah
<tjaalton> bryce: right
<tjaalton> I don't know if the fallbacks work in the first scenario
<tjaalton> although I believe they should
<tjaalton> and in that case failsafe would be suited for the second scenario
<Ng> how much do we care about 2.6.31 producing an i915 related oops immediately on booting?
<tjaalton> not much
<tjaalton> :)
<tjaalton> happens here too
<tjaalton> probably best wait for rc2
<Ng> yeah I figured a first upload would be a bit rough :)
<tjaalton> also, once X tries to start, the driver says "no modes"
<tjaalton> and fails there
<tjaalton> kms works though
<Ng> mine didn't even get as far as kms, it was just right after grub it exploded
<tjaalton> did you wait long enough?
<tjaalton> my boot takes several minutes
<Sarvatt> hmm i've been getting alot of these errors during boot since somewhere around 2.6.30-git11 and it makes my touchpad get detected as a generic mouse until i rmmod psmouse/modprobe psmouse atkbd.c: Spurious NAK on isa0060/serio0. Some program might be trying access hardware directly.
<Sarvatt> happens like every third boot
<maxb> Sarvatt: I'm getting occasional misdetection of my touchpad too, but I don't think I've seen those errors, do I need to turn up some debugging level somewhere?
<maxb> oh, no, I'm just unobservant - I *do* get that error
<Sarvatt> time to dig through kernel.org bugzilla to see if theres anything about it
<maxb> Don't know if this helps at all, but I've seen two different failure modes: sometimes detected as "PS/2 Generic Mouse", other times detected as "PS/2 Synaptics TouchPad" NB not "SynPS/2" which is what it's supposed to be, and is on a good boot
<maxb> For me it's happening only 1 in 10 boots or so
<Sarvatt> ah hah
<Sarvatt> are you on a netbook too maxb?
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/dtor/input.git;a=blobdiff;f=drivers/input/serio/i8042-x86ia64io.h;h=924e8ed7f2cf777f5d48767c18d5618027c031e6;hp=fb8a3cd3ffd0ab4685e8e68f5f14b07068266b94;hb=9230ccb1071d2d7e4ecb6314e67203b9f7f08140;hpb=eef3e4cab72eaf5345e3c73b2975c194a714f6cd
<Sarvatt> crap, that is matching Acer as well as AOA150 DMI's
<Sarvatt> I'm using the gateway bios so mine shows as Gateway AOA150
<Sarvatt> going to send him an email
<maxb> Mine's an Acer AOA150
<Sarvatt> that explains it
<Sarvatt> it'll be fixed by that commit
<Sarvatt> not in linus' tree yet though
<maxb> Weird thing is that I only ever noticed this problem starting from 2.6.30-10
<Sarvatt> i dont know what i8042_dmi_reset_table does yet, might be an option we can add to /etc/modprobe.d/ to do the equivalent of what its doing in that commit
<Sarvatt> ah boot with i8042.reset=1 on the grub command line maxb
<bryce> any opinions on whether we should just expire out the xfree86-driver-synaptics bugs, or transfer them to xserver-xorg-input-synaptics?
<Sarvatt> my grub additional options stanza is getting rediculious here, quiet enable_mtrr_cleanup mtrr_spare_reg_nr=1 pcie_aspm=force i8042.reset=1
<bryce> there are 19 bugs
<Sarvatt> enable_mtrr_cleanup mtrr_spare_reg_nr=1 is required on AOA150 to have mtrrs for video if you arent using it btw maxb
<tjaalton> bryce: it's the same driver, just renamed, so maybe best to transfer them
<jbarnes> hm latest bits won't let me enable compiz
<jbarnes> even though compiz --replace works fine from a terminal
<bryce> okie
<maxb> Sarvatt: I only get the PS/2 issue on 1 in 10 boots anyway, so it's a bit hard to test for me
<maxb> Sarvatt: erm, what's a MTRR and how would I know if I wanted one? :-)
<Sarvatt> well just add i8042.reset=1 to /etc/default/grub, it'll fix it up and will happen automatically here soon anyhow
<bryce> maxb, https://wiki.ubuntu.com/X/Glossary
<Sarvatt> cat /proc/mtrr
<Sarvatt> when you boot with enable_mtrr_cleanup it tells you mtrr 7 is filled with bogus data and you've got a buggy bios
<maxb> ok.... so what practical effect should I be looking for when adding these options? Is it simply a matter of enabling a faster way of talking to the GPU ?
<Sarvatt> [    0.000000] WARNING: BIOS bug: VAR MTRR 7 contains strange UC entry under 1M, check with your system vendor!
<maxb> I don't see that in my dmesg
<maxb> [    0.000000]   7 base 000000000 mask 0FFFE0000 uncachable
<Sarvatt> yeah enable_mtrr_cleanup shows that
<Sarvatt> mtrr_spare_reg_nr=1 makes it clean things up so theres a spare one available for the GPU to open a WC one for X
<Sarvatt> you dont notice like, slow scrolling speed for firefox and stuff?
<maxb> So essentially "make it possible to turn write-combining on" ?
<Sarvatt> yep
<maxb> my scrolling seems fine
 * maxb fiddles with grub cfg
<Sarvatt> you do it in /etc/default/grub now then update-grub2 after if you dont want to lose it next time you update-grub :D
<Sarvatt> GRUB_CMDLINE_LINUX_DEFAULT="x" line in there
<maxb> !
<maxb> New to me
<maxb> Though on the netbook I'm manually maintaining the menu.lst since it's triple-boot intrepid/jaunty/karmic
<Sarvatt> ah yeah goes in the # defoptions= line in there
<tjaalton> uh, so .31 is now the default kernel
<Sarvatt> glxgears fps will double, not that thats indicative of anything :D
<Sarvatt> yeah, and nvidia doesnt compile under it, fun stuff
<bryce> wee
<Sarvatt> and a large number of systems cant even boot it because of the null dereference in acpi_get_pci_dev() that was fixed right after
<bryce> have the -intel pci quirks been ported into the kernel yet?
<maxb> Sarvatt: well, I get the WARNING you mention, but I don't observe subjectively any performance difference.
<Sarvatt> do you see a write-combining mtrr covering your video ram when you cat /proc/mtrr now?
<maxb> There's a write-combining one base=1G size=256M - sounds likely?
<maxb> though it's reg4 not reg7
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=412af97838828bc6d035a1902c8974f944663da6 -- those systems cant even boot 31-rc1
<maxb> Sarvatt: In conclusion I see about a 25% improvement in glxgears fps with the mtrr cleanup. Apparently that's not enough to be perceptible in my usual workloads
<maxb> but thanks for the tip regardless :-)
<maxb> ooh, my keyboard doesn't work in 31-rc1
<Sarvatt> it was really noticible on jaunty's 2.6.28 kernel, firefox scrolling speed and video playback were horrible. not so noticible now for some reason but at least that way its working as intended :D
<maxb> Very timely advice Sarvatt, I seem to need i8042.reset=1 to make my keyboard work in 31-rc1
<maxb> :-)
<Sarvatt> :D
<Sarvatt> that'll be fixed by rc2 hopefully if linus pulls dtor's input tree by then
<Sarvatt> it'll force i8042.reset=1 for Acer AOA150's
<maxb> ah, keyboard sometimes works without. I guess it's a new manifestation of the same issue affecting the synaptics
<Sarvatt> i'm using evdev 2.2.99 and dont have any problems with the keyboard not starting up, wonder if its some change in there in that case
<Sarvatt> we have the same system after all
<proti> morning
 * bryce waves
 * proti waves too :-)
<proti> Need some help with intel kms...
<proti> At boot I get black screen immediately.
<tjaalton> problem in the current kernel
<tjaalton> .31 ftw
<proti> Problem since 2.6.29-10.
<tjaalton> ok..
<proti> X fails to start.
<proti> Says (EE) intel(0): Incorrect KMS mode.
<proti> On karmic koala of course.
<proti> The funniest thing is that the machines boots ok, and shuting down the laptop shows the splash screen.
<proti> X.0.log is there http://pastebin.ubuntu.com/207743/
<proti> And kern.log is here http://pastebin.ubuntu.com/207745/
<bryce> Sarvatt, your -synaptics debdiff is uploaded
<proti> Hum, seems that the kernel sets is wrong. '[drm] LVDS-8: set mode 0x0 19'
<jbarnes> pitti made my day... then rained on it :p
#ubuntu-x 2009-07-02
<kees> 2.6.31 totally fails mode detection for me.  :( 
<kees> well, where "totally" is "doesn't see the non-VESA modes"
<bryce> jbarnes, :-/
<tormod> interesting: the new karmic kernel has radeon kms by default
<tormod> don't know if it was intentional but certainly brave
<bryce> oh wow, really?
<tormod> yeah I could not believe it myself and double-checked a couple of times :)
<RAOF> I didn't think that our userspace knew how to interact with radeon kms?
<tormod> RAOF, it doesn't really so X does its own thing and runs DRI1 etc
<RAOF> And X tries it's own modesetting?  That's got to be a recipe for fun!
<tormod> it actually works fine here
<bryce> man, the .31 upload has borked a lot of X stuff for a lot of people  8-/
<tormod> I get old-time slow VT switching to a brand-new hi-res text console
<tormod> maybe we need a kernel-edgers team :)
<tormod> anyway, I am refreshing the radeon-kms ppa with the corresponding user space
<tormod> the good thing about a broken, new-version kernel is that you still have the old kernel intact
<bryce> yep
<bryce> hmm, good point
<tormod> ok radeon-kms ppa is updated, will test (full) kms
<tormod> ok radeon-kms ppa works fine, DRI2 and everything. gotta reboot a bit more though now that restarting X means restarting kernel...
<bryce> jbarnes, if you're around, could you give me some background on cec9fc6f ("Make KMS set_resource function return TRUE") - I'm trying to understand the scope of bugs it will fix
<jbarnes> it allows the edid to be exported in kms mode
<bryce> if EDID is not being provided with KMS, that could explain a range of various bugs people have been reporting lately
<jbarnes> as a randr property
<jbarnes> it was being provided but the server was ignoring it because set_resource was returning an error
<bryce> jbarnes, so like, if xrandr is unable to show/set non-vesa resolutions when booted in KMS?
<jbarnes> no that's a separate bug
<jbarnes> also fixed in git
<bryce> ok
<jbarnes> that was due to our kernel code not populating a full mode list for panels
<jbarnes> like the 2d driver did
<jbarnes> ok dinner time :)
<bryce> probably I should just pull a new git snapshot... but it'd be interesting to know what bugs are fixed so I don't bother y'all with already-fixed ones
<kees> jbarnes: do you have to have the commit handy for the "zomg, where did my mode go?" bug you mentioned with "< jbarnes> no that's a separate bug".
<Craigy90> hi everyone
<Craigy90> how should I report a bug that affects xorg only when compiz is running?
 * hyperair grumbles about usb-storage malfunctioning on 2.6.31
<crevette> I didn't manage to have my machine booting with 2.6.31, it kept stuck in the boot process
<hyperair> crevette: rc1's broken with 965 machines. you'll need rc2 (when it arrives) or git
<crevette> hyperair, thanks for information
<hyperair> crevette: np.
 * Ng wonders how 2.6.31 is doing on G45s. just ordered a new laptop ;)
<hyperair> i wonder =\
<hyperair> i'm very interested to see usb-storage actually *work* on .31 though
<seb128> I'm interested to see xorg work on .31 ;-)
<crevette> seb128, i965 like me IIRC :)
<seb128> crevette, indeed
<hyperair> seb128: wait until rc2 drops by =)
<Sarvatt> so should we just start putting all the radeon kms stuff directly in xorg-edgers now since the kernel has radeon KMS enabled by default? :D
<bryce> Sarvatt, yep I think so
<bryce> btw I had a phone conversation with AMD this morning about fglrx
<bryce> among other things, we need to be cognizant that if the radeon drm module is there, and the user installs fglrx, then something needs to cause that radeon module to not get loaded
<bryce> similar problem will exist with -nvidia and -nouveau
<superm1> like adding a blacklist file in modprobe.d?
<bryce> maybe yeah
<bryce> or some flag in initrd?
<Sarvatt> yeah i see a problem with drm getting loaded for combined intel/radeon boards and drm needs to be unloaded for fglrx to work too, at least i think that was the problem
<superm1> well bcmwl has to do something similar because of b43/ssb
<superm1> ssb has a tendency to load from the initrd too, so the  blacklist file is sufficient for it
<superm1> with someone with onboard intel and add-in fglrx that's probably a problem Sarvatt 
<Sarvatt> i think it was just intel/radeon hybrids with the problem because onboard intel shouldnt get initalized if theres an addon card, but i would have to dig through the bug reports to verify that
<Sarvatt> oookay pushing radeon KMS to edgers, just built the new libdrm for radeon-kms and it builds right locally but theres 4 hour queues on the PPAs
<Sarvatt> i'm still unsure if master works correctly with KMS now though so going to just copy tormods kms-support branch ati for now
<Sarvatt> looks like master works correctly with kms now though..
<Sarvatt> asking over in #radeon
<bryce> I've emailed apw and pgraner with amd's q's on this.  Also brought up the hybrid intel/ati case we should keep in mind
<Sarvatt> <agd5f> Sarvatt: xf96-video-ati master should support kms now
 * Sarvatt cheers
<Sarvatt> now to wait 4 hours for libdrm to build so i can upgrade mesa and the ddx to support it
<bryce> nice
 * bryce wonders what to work on today
<bryce> oh btw, one other thing amd mentioned, they've noticed how many installation-related bugs get filed and are (finally) interested in ideas for making the procedure more robust.  We're planning on talking about it in more depth in a couple weeks, meanwhile if anyone has good ideas or suggestions, lemme know
<bryce> I'm going to mention the glx incompatibilities with -ati and -fglrx, that we've written up in our wiki
<superm1> well definitely if tjaalton can come up with a patch that sets fglrx/nvidia as default when it's installed, i think a lot of the "problems" would go away
<superm1> (or at least i'd like to think so)
<bryce> you mean in xserver?
<bryce> I think I own that task actually
<Sarvatt> something like http://pastebin.com/m1a4a8ab9 ?
<tjaalton> yep
<tjaalton> very easy
<bryce> does that cover both the with-xorg.conf and no-xorg.conf cases though?
<tjaalton> no
<tjaalton> only without
<superm1> so for the "with" case, can just have the plan for jockey to enable
<superm1> so jockey should test if it's there, and modify if so, otherwise plan on doing nothing
<bryce> ok
<bryce> so unless there's any other tweaks needed, I can pop Sarvatt's patch into the xserver today
<bryce> (just working on getting new inkscape merged in at the moment; will do after)
<superm1> Sarvatt's patch, meaning what tjaalton was referring to, or something different?
<tjaalton> better squeeze nouveau there too
<bryce> http://pastebin.com/m1a4a8ab9
<Sarvatt> http://pastebin.com/d359ad54
<tjaalton> after nvidia
<Sarvatt> (had to update it)
<Sarvatt> its just fedoras nouveau patch and i added nvidia in, feel free to edit more stuff in :D
<tjaalton> Sarvatt: you replaced nouveau with nvidia, add it back :)
<Sarvatt> wait a second, forgot some ; :D
<Sarvatt> http://pastebin.com/md76e64e
<Sarvatt> ?
<tjaalton> yep, better
<tjaalton> now the same for ati chips
<Sarvatt> wait, still wrong lol
<Sarvatt> http://pastebin.com/m248b9ae1
<tjaalton> heh, right
<Sarvatt> added nouveau for 0860 0840 devices
<tjaalton> fix the index too :)
<Sarvatt> oops
<Sarvatt> ok last one http://pastebin.com/m280b5611 you can fix it up from there :D
<Sarvatt> i dont even know if that'll work
<superm1> so the same thing - does that work for fglrx?
<tjaalton> sure
<superm1> I thought it needed some extra line to declare depth or something
<superm1> some deficiency in fglrx
<tjaalton> ah
<tjaalton> does it still hold true?
<superm1> well throw the fglrx in there, and then we can have a bug for bryce to feed AMD if necessary
<bryce> yep
<superm1> and hopefully they can sort it out by release
<bryce> packaging up sarvatt's patch
<bryce> definitely want to stage this one in xorg-edgers for a bit first ;-)
<bryce> do we have a lp# open about this?  *browse*
<tjaalton> not on the wishlist bugs
<bryce> huh, surprising, would have thought there'd be one
<tjaalton> there probably was at some point
<bryce> I see we have a newer xorg-server in edgers already, so I stuck this into my own ppa for now
<bryce> ...and committed to git
<bryce> ah apw is on holiday this week, that's why he's not responded to our pings lately ;-)
<Sarvatt> it doesnt apply, did you clean it up? some characters got lost cut and pasting it to pastebin
<Sarvatt> needs to be @@ -181,7 +181,34 @@ videoPtrToDriverList(struct pci_device *dev,
<Sarvatt> @@ got lost
<tjaalton> bryce: he released .31-1.14 though ;)
<Sarvatt> even if i add it removes it on pastebin, eww
<Sarvatt> http://sarvatt.com/downloads/178_nvidia.patch
<Sarvatt> added it on edgers too
<bryce> Now at patch 178_nvidia_autodetect.patch
<bryce> successful.
<bryce> great thanks
<bryce> I'll update xorg-edgers with this too
<Sarvatt> already did :D
<Sarvatt> wont apply to master, they added openchrome autodetection after nvidia
<tjaalton> 1.6 has it too
<Sarvatt> does it?
<Sarvatt>         case 0x10de: case 0x12d2:   driverList[0] = "nv";       break;
<Sarvatt>         case 0x1106:                driverList[0] = "openchrome"; break;
<Sarvatt>         case 0x1163:                driverList[0] = "rendition"; break;
<Sarvatt> (on master)
<Sarvatt>         case 0x10de: case 0x12d2:   driverList[0] = "nv";       break;
<Sarvatt>         case 0x1163:                driverList[0] = "rendition"; break;
<Sarvatt> on server 1.6 branch
<tjaalton> yes but openchrome is there too
<Sarvatt> ah its just moved around
<tjaalton> maybe it should be numbered as 104, since I guess it'll be around some time..
<tjaalton> hmm, the patch looks weird on cgit: http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commitdiff;h=399677d1582d4c6f1c5f4546d31ba7cb1acae746
<tjaalton> make that gitweb
<Sarvatt> its got an offset applying because of 103_psb adjusting the lines
<Sarvatt> yeah silly pastebin mangles it
<Sarvatt> http://sarvatt.com/downloads/178_nvidia.patch  is right though
<tjaalton> no I mean the characters after every line
<tjaalton> end of line
<tjaalton> open it with vi :)
<tjaalton> bryce: did you release the xserver already?
<bryce> not yet
<tjaalton> s/karmic/UNRELEASED/ :)
<tjaalton> and the patch is the broken one
<tjaalton> but I can fix those
<bryce> ok updated in git now
<tjaalton> heh, quick
<bryce> will let Sarvatt update xorg-edgers
<bryce> I'm going to hold off on pushing this out live until we've got a couple independent tests done on the patch on xorg-edgers first
<tjaalton> sure
<Sarvatt> did awhile go and built it locally already too
<tjaalton> Sarvatt: how did you come up with this patch?
<tjaalton> I mean, how did you do it
<tjaalton> I'm just curious why the newline characters are ^M
<Sarvatt> its because of  pastebin switching to windows encoding
<tjaalton> can't remember what that was called..
<tjaalton> ok
<tjaalton> but the one on your webpage has those too
<bryce> I'm pbuilding the git tree locally as well
<Sarvatt> really? what the heck?
<tjaalton> yep
<Sarvatt> you're right, they're there in vi, i use nano
<Sarvatt> just grab the fedora patch, add the 3 lines and adjust the offset :D i was just giving an example asking if thats what you meant to do, assumed you guys wanted to add fglrx to it too
<Sarvatt> sorry for the trouble
<tjaalton> np
<Sarvatt> it still applies and works fine with ^M's there oddly
<tjaalton> yep, and diff doesn't show them
<Sarvatt> and i dont see the ^M's in nano 
<bryce> I've got a dos2unix script that might strip them out
<bryce> okay, new inkscape uploaded
<Sarvatt> ah i saved the patch from pastebin to debian/patches then fixed the @@ it left out manually
<bryce> hmm, not seeing any ^M's in my copy of the patch
<tjaalton> dos2unix fixed it
<tjaalton> bryce: which editor?
<bryce> vim emacs gedit nano
<tjaalton> vim shows it here
<tjaalton> actually it doesn't, but invoked as vi does
<tjaalton> vim tells you it has dos formatting
<tjaalton> bryce: I'll renumber it too as 104 because I think it'll be there for a while?
<bryce> ok
<tjaalton> done
<RAOF> Cool!  A new kernel that hopefully won't panic while loading drm.
<lesshaste> hi.. do people know about this bug? https://bugs.launchpad.net/ubuntu/+bug/394691
<ubottu> Ubuntu bug 394691 in ubuntu "[9.04 amd64 + nvidia = FAIL] security hole in screensaver" [Undecided,New]
<Sarvatt> ok uploading mesa now, as soon as that builds the main xorg-edgers fully supports radeon KMS on karmic with the ubuntu 2.6.31-1 kernel
<bryce> what do you think of this approach for adding fglrx support?  http://pastebin.ubuntu.com/208587/
<Sarvatt> is there a way to get glxgears to output fps even with the disable patch? i use it as a way to tell if i'm in mutter compiz or metacity so I like it there :D
<bryce> divide by 5 in your head?  ;-)
<bryce> no, I removed the code entirely, there's no option to reenable it
<Sarvatt> true :) or just start using ps to tell like i should, i just like the pretties :)
<Sarvatt> i've got a problem enabling compiz in karmic though, for some reason its loading metacity too and that takes up 100% cpu silently
<Sarvatt> i have to killall metacity to get the cpu usage back down
<bryce> I'm a bit ambiguous on what pci id's specifically that fglrx supports... guess I could email them
<Sarvatt> the highest thing in htop is gconf2 taking up around 10% cpu load but my cpus are fully loaded until i kill metacity
<bryce> oh I guess it isn't too ambiguous... 0x791E and up
<Sarvatt> 793F isnt it?
<Sarvatt> looks like 791E is RS690, isnt that r500 based?
<Sarvatt> might even be the 9400+ like you put, im not sure
<bryce> ok so it is a tad ambiguous ;-)
<Sarvatt> (looking at http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tree/src/ati_pciids_gen.h)
<Sarvatt> looking up the fglrx source now, should be in fglrxko_pci_ids.h
<apw> bryce just for thur and fri ....
<Sarvatt> yeah its 9400+ bryce
<apw> but if you need something ... let me know
<Sarvatt> lib/modules/fglrx/build_mod/fglrxko_pci_ids.h in the fglrx-installer package
<bryce> apw, great thanks, nothing that can't wait until next week.
<bryce> aha.  I poked around in the fgrlx-installer source but didn't spot that file
<bryce> from that it sounds like 0x9400 and up
<Sarvatt> http://sarvatt.com/downloads/fglrxko_pci_ids.h.txt
<Sarvatt> they sure are nice to use device id's in order like that unlike nvidia :D i guess rs740 is r500 based as well too
<bryce> yeah
<bryce> guess they must be renaming them to new generations to clear out the warehouses of the old stock ;-)
<Sarvatt> my htpc mobo just died and i'm going to replace it with one with ati integrated so i can play with this stuff too
<Sarvatt> looks like i want something with rs690 or rs740 to mess with KMS, i have a pci-e hd2400 to play with otherwise
<bryce> ok, fglrx autodetect stuff pushed to git
<bryce> tjaalton, named it 105
<Sarvatt> will be nice to move away from mediaportal/vista on that thing, i've been running ubuntu in vbox on it for my irc bouncer and other things so i can go linux directly now.
<Sarvatt> i'll push that to edgers too
<bryce> ok
<bryce> same thing; will wait on upload until we get a few positive test results
<Sarvatt> there might be a little problem with the nvidia side, at least on git master xorg its not loading the nvidia glx doing it this way
<Sarvatt> but i dont think thats a problem on 1.6 branch
<Sarvatt> whats wrong with -nvidia creating an xorg.conf like it does when you manually install it from nvidia binary packages?
<Sarvatt> yeah looks like the glx problem is git master xserver specific so no worries there
<Sarvatt> whats the deal with radeonhd also?
<Sarvatt> would someone with a 9400+ ati device id want radeonhd instead of ati?
<Sarvatt> as the secondary if fglrx fails in your patch
<Sarvatt> or maybe fglrx - radeonhd - ati
<Sarvatt> since radeonhd wouldnt always be there and just fail and move on to ati if its not
<Sarvatt> also is the driver called ati or radeon?
<RAOF> Um... where is libdrm being maintained in Ubuntu now?
<Sarvatt> like this for example http://pastebin.ubuntu.com/208624/
<RAOF> When I pull libdrm from alioth, the ubuntu branch only seems to go up to 2.4.9-2ubuntu1
<Sarvatt> (dont use that diff because i didnt refresh the add/subtract lines)
<Sarvatt> it just hasnt been updated on alioth RAOF
<bryce> yeah I thought about radeonhd
<bryce> nouveau we have plans to move to, but radeonhd not so much
<RAOF> Sarvatt: Yes... so what git repository do I pull to get our current branch? :)
<bryce> otoh I guess it doesn't hurt to have it in there
<RAOF> Or is our current package not in git at all?
<Sarvatt> yeah its just not in git at all
<RAOF> Oh.
<jbarnes> wow fairly hard failure in karmic today
<jbarnes> did an update... my machine eventually crashed, and now gconfd won't start so my desktop fails massively
<Sarvatt> hmm i havent rebooted since the GDM 2.26 update, you're scaring me about doing it now :D
<jbarnes> might be the crash
<RAOF> Sarvatt: Eh, gdm works.  Although it did accidentally change my VT to the new gdm screen.
<jbarnes> yeah looks like gconf just lost its mind
<jbarnes> the update is probably ok
<bryce> heya jbarnes, yeah development seems to have suddenly kicked up a notch, lots of breakages getting found
<RAOF> So, what are we doing about libdrm?  Shall I just throw another patch onto the the not-in-git package?
<Sarvatt> theres a huge bug where starting compiz on my machine makes gconf2 use a ton of cpu (well  only 10% but I get 100% cpu usage until i killall -9 metacity)
<bryce> RAOF, sure
<Sarvatt> metacity is getting started starting compiz for some reason and it makes things go wonky unless i kill it
<Sarvatt> killing it has no affect on the machine so i dont know what purpose it serves starting it is all, but its causing 100% cpu usage running at the same time
<Sarvatt> shoot, its restarting automatically too after some time of being killed
<Sarvatt> no wonder my battery keeps dying so fast
#ubuntu-x 2009-07-03
<jbarnes> bryce: yeah lots of bug fixing
<Sarvatt> time to go back to not using compiz again, was only enabling it to test memory leak fixes
<bryce> Sarvatt, ok -radeonhd added too... in git
<superm1> bryce, in that -fglrx patch you were proposing, wouldn't the IDs that don't work, fail anyway even with -ati because of fglrx's libGL being installed?
<bryce> yeah but I don't think that's something we can fix in this chunk of code
<bryce> superm1, or are you thinking we should let them go ahead and try against -fglrx even if they're using an unsupported chip, just in case it does randomly work?
<Sarvatt> yeah at least it will make fglrx be the default in any case, if they have fglrx installed they cant use ati/radeonhd but it has to be there incase they dont have fglrx installed
<superm1> bryce, yeah, there is still a chance it would at least start up with very slow 2D due to the failed kernel module load
<superm1> (i think)
<bryce> *shrug* fine by me, if there are random working cases out there, no point  to force them to fail
<bryce> I'll update git, one sec
<Sarvatt> right as i was starting to upload it, phew :D
<Sarvatt> is there no way to make the fglrx package refuse to install if its not supported?
<RAOF> I think the best you could do would be prevent it from configuring, but that'll leave the dpkg in an error state.
<Sarvatt> wonder if you can match pci ids in preinst somewhere
<jbarnes> ouch
<jbarnes> another random crash
<bryce> pushed
<bryce> er, pushed to git
<Sarvatt> putting that on edgers
<Sarvatt> going to reboot to see if i have any problems like jbarnes is
<Sarvatt> oops guess i better build the new intel ddx first
<jbarnes> I think my problems were just a bad config saved_state file
<jbarnes> once I removed that things worked again
<RAOF> Stupid damn quilt.
<Sarvatt> still cant enable compiz via appearance preferences :(
<Sarvatt> turned on metacity compositing via gconf-editor, gconf2 using the highest CPU and the old metacity process is still hanging around and cpu load shot up to 100% again
<Sarvatt> robert@ubuntu-9{~}:ps aux | grep metacity
<Sarvatt> robert    3813  2.9  0.7  21488 11092 ?        S    19:59   0:03 metacity --replace
<Sarvatt> robert    4563  0.0  0.4  18868  6640 ?        R    20:01   0:00 metacity
<jbarnes> Sarvatt: I had a similar problem the other day
<jbarnes> seems to have fixed itself though
<Sarvatt> which, multiple window managers running causing 100% cpu load, or not being able to start compiz from appearance preferences?
<jbarnes> not starting compiz
<bryce> running compiz from the command line sometimes provides useful error messages
<Sarvatt> ahh good hope i can figure out why thats happening.. DISPLAY=:0 compiz --replace works
<Sarvatt> it works fine from the command line so i cant figure out how to find what it is
<Sarvatt> ~/.xsession-errors fills in under a minute from the gnome-power-manager spam
<Sarvatt> i think its related to this main metacity process thats hanging around not reliquenshing control to compiz somehow, gotta dig through metacity git to see if there were any fixes in that regard just incase.. even if i do enable compiz (or even just metacity -c --replace) having that old metacity process around is causing 100% cpu load over time, i've seen alot of people getting that problem
<Sarvatt> highest visible process using the cpu when its in that state and killing the plain metacity process fixes it is gconf2
<Sarvatt> yeah tons of bugs about this https://bugs.edge.launchpad.net/ubuntu/+source/gconf2/+bug/390733
<ubottu> Ubuntu bug 390733 in gconf2 "Process gconfd-2 causes cpu overuse and overheat" [Low,Invalid]
<Sarvatt> i bet i can start compiz fine after killing that strangling metacity process, lets see
<Sarvatt> yep!
<Sarvatt> thats the problem
<Sarvatt> i cant wait until mutter is packaged, never had good experiences with compiz and installing mutter via jhbuild loses gconf settings options. clutter 3d compositing is great
<bryce> ooh just noticed we're upped to 5G now in xorg-edgers :-)
<Sarvatt> woohoo!
<Sarvatt> eww, tormods getting a segfault starting x with xorg-edgers on ati now
<Sarvatt> he has to force vesa
<Sarvatt> asking him to try deleting his xorg.conf to see what happens with the new changes but he went to bed
<Sarvatt> to be sure the fglrx - radeonhd - ati ordering change even works
<Sarvatt> going to need to be babysitting xf86-video-ati and uploading every commit to keep up with it no doubt
<Sarvatt> cleaned up and put a new -intel on https://launchpad.net/~ubuntu-x-swat/+archive/x-updates too and am asking people to test it since its a drop in replacement on karmic and edgers uproots all of x, still getting lots of bugs about the resume from dpms off problems in the current karmic intel
<RAOF> Sarvatt: Oooh.  And is that likely to _fix_ resume?  That'd be cool :)
<RAOF> One nouveau-kernel-source uploaded to edgers that'll build against 2.6.31.
<Sarvatt> nah thats a kernel fix that was added *right after* 2.6.31-rc1 most likely, this one was people not able to bring the screen back on when it goes into dpms off mode via screensaver timeout or lid close
<RAOF> Let's switch to my nvidia-laptop, and see if the libdrm patches take.
<Sarvatt> cheers RAOF! will test that in a bit, been neglecting my nvidia laptop since the blob stopped building post .30
<RAOF> Oh.  So it's likely that resume will be fixed sometime in the near kernel updates.
<Sarvatt> yep!
<Sarvatt> fixed for *alot* of people by the suspend/resume ordering fix right after rc1
<RAOF> Should I bother adding a 2.6.30 compat patch?  It'll either build against .30 or .31, but not both without a kver dependant patch.
<RAOF> It's probably worth doing, I guess.
<Sarvatt> some people with 965+ are still having problems with suspend/resume when compiz is enabled though
 * RAOF is having problem with suspend/resume with metacity, too.
<Sarvatt> ehh as long as it isnt there for jaunty i wouldnt bother, everyone will be on .31 here soon
<RAOF> Right.  That was my thinking.
<Sarvatt> not planning on updating jaunty in there to .31 anytime soon since so many things are broken by it
<Sarvatt> maybe note in the changelog that its .31 only?
<RAOF> Lots of nouveau drm fixes recently.  And maybe soon my nv4B will start X with kms enabled, too :)
<Sarvatt> (if you upload again)
<RAOF> Possibly.
<RAOF> But the .30 compat patch really wouldn't be that hard, I think.  It might be worth it just for completeness.
<Sarvatt> oh really? my main problem with it is the complete lack of power savings
<Sarvatt> i only get ~1 hour on my 4 hour battery using nouveau kms.. lol
<RAOF> Hm.  That's no good!
<Sarvatt> does nouveau-kernel-source build on x64? i saw it was i386 only on the ppa but not sure if its just a generic thing that will pull it and build on x64
<Sarvatt> guessing it is just generic since its just packaged source that gets built locally but wanted to be sure
<RAOF> It's arch:all, so it only gets built on i386.
<RAOF> For what are essentially hysterical rasins.
<RAOF> But it's installable everywhere, even PPC!  Although it'll fail to build against our ppc headers, of course.
<Sarvatt> building a new nouveau ddx now unless you already started on it
<Sarvatt> uploaded
<RAOF> Be my guest.  There's not much new there ;)
<Sarvatt> well shoot, doesnt look like there are any mobos with builtin ati that would run KMS unless I pay more to get older tech, so much for that idea :D rs780 and rs880 run under fglrx
<Sarvatt> hmm my ibook g4 early 2004 model has a mobility radeon 9200 that should work
<Sarvatt> if only PPAs supported powerpc it'd be alot easier :D
<Sarvatt> looks like we need to add an EXPORT_SYMBOL(find_task_by_vpid); to pid.c in fglrx-installer to work on 2.6.31
<Sarvatt> but thats in the actual kernel source and i have no idea if its even possible to patch into fglrx-installer
<Sarvatt> https://bugs.edge.launchpad.net/bugs/394985  -- its exported in 2.6.30 at least, taking a look at .31 source to see whats changed
<ubottu> Ubuntu bug 394985 in fglrx-installer "fglrx: Unknown symbol find_task_by_vpid" [Undecided,New]
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=17f98dcf6010a1cfd25d179fd0ce77d3dc2685c3
<superm1> lovely
<Sarvatt> way over my head, maybe bryce might want to bring it up with amd :D just adding the export works for people though apparently even with the change to it
<tjaalton> hrm, no RAOF
<tjaalton> Sarvatt: you need to apply for pkg-xorg on alioth.debian.org, so you could push the patches yourself ;)
<tjaalton> or other changes
<tjaalton> libdrm is syncable, but if RAOF had some patch to add, I'd add it on top of the debian version
<tjaalton> libdrm now merged in git
<Kano> hi, what was the url of the xorg-edgers iso, i dont find it
<Sarvatt> eww, so I'm installing ubuntu on an old ibook g4 with a mobility radedon 9200 to play with KMS... then i find out hardy is the last release thats actually installable on an ibook because they stopped including ide-scsi modules for the cdrom to be detected :D waste of 4 cd's working down from karmic to find that out
<Sarvatt> wow, i never noticed you guys had mutter already packaged until i just saw gnome-shell get uploaded
 * Sarvatt cheers seb128 on!
<Sarvatt> woohoo, works wonderfully and i can access the gconf settings unlike under jhbuild :D
<Sarvatt> need to figure out how to get the gnome-shell window list up in the top panel, takes a bit too much space on a netbook screen and the top panel isnt hardly used for anything
<Sarvatt> kind of sad this 12" ibook thats been in a closet for 5 years is trashing my aspire one in benchmarks :D going to take all day getting it up from 8.04 to karmic and then recompiling everything for KMS. mesa will be fun :)
 * joumetal already had fun with blank screen in X and in virtual terminals (r100) :)
<Sarvatt> did you try booting with nomodeset added to grub?
<Sarvatt> maybe that should be a default option until userspace catches up like it was on intel instead of being all or nothing on :D
<joumetal> radeon.modeset=1 gave working X.
<Sarvatt> yeah it'd probably be a good idea to make that the default module option for now
<Sarvatt> oh wait, modeset=1?
<Sarvatt> and it didnt work without that?
<joumetal> both using xorg-edgers. err modeset=0
<Sarvatt> oh any chance you updated edgers between trying 0 and 1? i updated edgers to radeon KMS support yesterday but it took a few hours for it all to get there
<Sarvatt> ahh ok
<Sarvatt> the module should definitely default to 0 instead of 1 though 
<Sarvatt> have you tried without modeset=0 today? updated stuff again, curious what error you got with edgers with kms enabled
<Sarvatt> they told me the ddx master branch should support KMS fully now in #radeon, i dont have anything to test it on yet so i cant see where the errors are
<joumetal> yes. default should be 0 now. do i put backtrace or xorg.0.log to pastebin?
<Sarvatt> there was a problem with it enabling overlays in KMS stopping it from working that i updated with the fix last night
<Sarvatt> xorg.0.log.old from the failed boot should be enough if you have it still
<joumetal> http://paste.ubuntu.com/209284
<Sarvatt> in drivers/gpu/drm/radeon/radeon_drv.c changing line  85 int radeon_modeset = -1; to int radeon_modeset = 0; should be enough i think?
<Sarvatt> yeah joumetal try updating to the new stuff on edgers
<Sarvatt> RADEONInitVideo is where the overlay setup was causing problems with KMS in the ddx
<Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=8d2f712eaf1e569fd92bbe2db5aceb43b7b367d1
<Sarvatt> suggesting changing the default behavior for the radeon module to be modeset=0 in #ubuntu-kernel
<Sarvatt> if they disable it completely from staging then we dont get the headers we need in linux-libc-dev to build KMS support stuff
<Sarvatt> if you have any luck with the update let me know, tormod was also having a problem with the same backtrace in the log so it'll be good to know thats fixed :)
<Sarvatt> if not i'll switch the ddx over to the kms-support branch so it at least works cus we know that works fine
<Sarvatt> eww, 1.5 hours to upgrade from 8.04 - 8.10, this really is going to take all day :D i hope the powerpc kernel is the same as the x86 kernel, thought i read somewhere that they combined them
<Sarvatt> joumetal: if you get a chance, let me know if the new DDX fixes things for you and I will revert -ati back to the older kms-support branch that at least works if not
<Ng> sweet, 2.6.31-1 KMS works on i965
<Sarvatt> wasnt working for you before?
<Sarvatt> darn, looks like i'm going to have to compile my own .31 for powerpc to test kms out, none of the karmic ones compiled
<Sarvatt> hmm, vinagre is screwing with touchpad sensitivity even after its closed
<Sarvatt> probably an xi2 problem
#ubuntu-x 2009-07-04
<Ng> Sarvatt: the first upload just oopsed right after the kernel started up
<Sarvatt> wasnt any change in i915 between them, guessing you're on one of those pcs affected by the acpi_video thing like a x61?
<Ng> X300, but the guts are very similar to an X61
<Sarvatt> ah yeah that was nasty :(
<Sarvatt> the autodetection logic patches interfere with normal detection for me. with a default xorg.conf its only trying the first thing from the list and failing when fglrx isnt found
<Sarvatt> if i dont define a driver it only tries driverList[0] from those tables
<RAOF> While we're having fun patching the autodetection, can we get one for using nouveau over nv?
<Sarvatt> did that, but theres a problem doing it this way
<Sarvatt> if theres an xorg.conf without the device defined it's only trying the first device in the table...
<Sarvatt> without the driver defined rather
<Sarvatt> i have an xorg.conf with just exa accelmethod defined in it and its giving a failsafe boot saying it cant load fglrx
<Sarvatt> (with our patches)
<Sarvatt> ping tjaalton whenever you come around :)
<albert23> Sarvatt: nice timing for you comments above. Just had a user in xorg with that problem
<Sarvatt> its a good thing we put those patches on edgers first, thats for sure :D
 * albert23 nods
<Sarvatt> already uploaded a new xserver with them dropped since that method is flawed
<Sarvatt> albert23: did you have that guy delete his xorg.conf? i dont see any problems with his log there?
<albert23> Sarvatt: yes he moved xorg.conf, then x started fine. That log is for a crash he had after that
<Sarvatt> its a shame, because it solves so many problems being able to do things that way but its going to mess up alot of older installs
<Sarvatt> wonder what would happen if you expanded an existing default xorg.conf to have 5 seperate device and screen sections with just generic info
<Sarvatt> will try that when this kernel is done compiling
<ogra> tjaalton, are you around by chance ? 
<Sarvatt>     if dpkg --compare-versions "$2" lt "1:7.4"; then
<Sarvatt>       invoke-rc.d hal restart >/dev/null
<Sarvatt>     fi
<Sarvatt> so thats failing on arm?
<ogra> yes
<ogra> its intresting though that it doesnt on other arches, but i think hal's initscript needs to grow the chroot check it uses on start for reload as well 
<ogra> (seem my ping to pitti in -devel)
<ogra> alternatively xserver-xorg could add something to this line to not commit suicide if the restart fails, not sure that such a good idea leaving you without inut devs though 
<ogra> *input
<Sarvatt> they did just add a db_stop call right after that that fixed the 10+ minute hangs from the postinst in a chroot i was getting
<Sarvatt> did it build right on arm recently?
<Sarvatt> (can look at the differences between when it did and didnt)
<ogra> xserver-xorg did build
<ogra> xscreensaver doesnt though due to the restart of hal failing
<ogra> (which is moot inside a chroot where you dont acually need hal running)
<Sarvatt> http://git.debian.org/?p=pkg-xorg/debian/xorg.git;a=commit;h=8bf2f1ee374e4d4fe231633a55502914623a4dd6
<Sarvatt> just looking at what changed in it since the last one
<ogra> well, that still makes the postinst fail if hal is not restarting 
<ogra> invoke-rc.d hal restart >/dev/null || true 
<ogra> that would be a quick fix
<ogra> but the more proper way is to fix hal's initscript
<Sarvatt> ah yeah it wasnt calling hal restart at all on 6-29 for the 0ubuntu1 version's xorg, i didnt know the version we had before was that old..  and of course hal isnt running so the restart is failing and making it stop there
<Sarvatt> that isnt the first time ive heard someone mention a problem caused by that hal restart too since it was updated
<albert23> ogra: doesn't the buildd have a /usr/sbin/policy-rc.d to prevent restart of daemons?
<albert23> in a pbuilder invoke-rc.d hal restart nicely returns 0
<ogra> i'm not sure its the same on soyuz' sbuild
<Sarvatt>  * Reloading GNOME Display Manager configuration...       [80G  * Changes will take effect when all current X sessions have ended.
<Sarvatt> invoke-rc.d: initscript gdm, action "reload" failed.
<Sarvatt> Setting up pm-utils (1.2.5-2ubuntu4) ...
<Sarvatt> thats fine with the error status
<ogra> right, gdms postinst has a prevention mechnism to not die
<Sarvatt> ahh hal didnt start in the first place but gdm was already started, sorry
<ogra> "Changes will take effect when all current X sessions have ended." ...
<Sarvatt> sorry for the noise, i'm blindly trying to help even though i'm new to all of this and havent had my coffee yet :D
<Sarvatt> got me curious whats different on arm to make it react differently in that circumstance
<ogra> it could very well be a difference in the chroot but that only a buildd admin can answer .... its weekend, so there might be none around ...
<Le-Chuck_ITA> Hi, I reported the following bug https://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/395522
<ubottu> Ubuntu bug 395522 in mesa "mesa xdemo/glxcontexts run aborted with assertion error" [Undecided,New]
<Le-Chuck_ITA> which is tracking an upstream bug in mesa http://bugs.freedesktop.org/show_bug.cgi?id=22428
<ubottu> Freedesktop bug 22428 in Drivers/DRI/i915 "[bisected 945GME]mesa xdemo/glxcontexts run aborted with error: Assertion `!obj->Pointer'" [Major,Verified: fixed]
<Le-Chuck_ITA> which is fix-released
<Le-Chuck_ITA> now the bug is there to help the fix get to karmic (if it's not automatic, I don't know) but is "mesa" a correct package in ubuntu? Launchpad can't find it
<ogra> https://bugs.launchpad.net/ubuntu/+source/mesa
<ogra> https://launchpad.net/ubuntu/+source/mesa
<ogra> its correct
<Le-Chuck_ITA> thanks
<Sarvatt> iLe-Chuck_ITA: it'll be in karmic not long after mesa 7.5 gets released, should be any day now
<Sarvatt> or when the next -rc comes out if there ends up being a -rc5 for some strange reason
<Sarvatt> thats like the 5th big bug i've seen directly caused by i915: Don't put VBOs in graphics memory unless required for an operation.
<Le-Chuck_ITA> Sarvatt: thanks a lot. The intel drivers are often in bad shape, hope the love of the ubuntu developers will help a bit :)
<Sarvatt> are you sure thats your issue if compiz is unstartable? you might even be able to get around it disabling buffer object reuse in driconf 
<Sarvatt> ah go figure he left
<Sarvatt> darn, got radeon KMS working on powerpc and everything but it turns out it needs fixes for big endian systems so the colors are off. mesa 7.6 is about 20% faster than 7.5 on my mobility 9200 though
#ubuntu-x 2009-07-05
<Sarvatt> hmm thats new
<Sarvatt> (EE) intel(0): [drm] drmAddMap(batchbuffer_handle) failed!
<Sarvatt> (WW) intel(0): [XvMC] fail to init batch buffer
<Sarvatt> XvMC driver initialize failed.
<RAOF> I've attached a libdrm debdiff on bug #395700.  It'd be nice if this got applied sometime.
<ubottu> Launchpad bug 395700 in libdrm "Update libdrm-nouveau for 0.0.14 drm interface" [Undecided,New] https://launchpad.net/bugs/395700
<tjaalton> RAOF: git is updated, you can push it there?
<RAOF> I certainly can.
<tjaalton> great
<RAOF> So, we're going to continue in git then? :)
<tjaalton> I guess so :)
<lesshaste> something has gone horribly wrong and when X starts it comes up with the log in screen but neither the mouse nor keyboard do anything, this is in jaunty ubuntu with the radeon driver. the X log doesn't look that bad to me.. here are the EE lines I see.  "open /dev/fb0: no such file or directory", "config/hal: couldn't initialised context: (null) (null)"
<lesshaste> the X log is at http://pastebin.com/f6b56a8c7
<jcristau> why is hal not running?
<lesshaste> I don't know... something broke after I installed qemu it seems.. 
<lesshaste> can I reinstall it?
<lesshaste> jcristau, I could just do sudo apt-get install hal..
<lesshaste> what do you think?
<jcristau> i don't know.  i asked you a question.
<lesshaste> jcristau, the answer to your question is that I don't know.. the only thing I did was install qemu and kqemu
<lesshaste> this seems to have killed hal I suppose
<lesshaste> hal is installed
<lesshaste> I would need to reinstall it I suppose
<lesshaste> sudo apt-get install --reinstall hal
<lesshaste> seems to have fixed it for the time being.. weird
#ubuntu-x 2010-07-05
<Sarvatt> phew, 5 day PPA build queue is almost flushed, perfect timing because I just uploaded about 150 packages :)
<Sarvatt> taking forever to get exposed to the launchpad api though, been uploading for over an hour and still nothing new on http://sarvatt.com/xorg-edgers/
<RAOF> Howdie Sarvatt!  How's tricks?
<Sarvatt> heyo! finally got net in the new house and making up for lost time updating everything :)
<Sarvatt> ah the publisher is running once an hour it looks like, updated on the hour
<tjaalton> hee-haw!
<jcristau> heya timo
<tjaalton> hi jcristau 
<tjaalton> now I'm back to stay ;)
<tjaalton> i guess it's safe-ish to update to maverick...
<Sarvatt> darnit, last try to resend these messages :)
<Sarvatt> <Sarvatt> heyo tjaalton! all done with college stuff?
<Sarvatt> <Sarvatt> jcristau: hmm any idea what to do with 13_debian_add_xkbpath_env_variable.diff on xserver 1.9 where InitGlobals is gone?
<jcristau> Sarvatt: that patch hasn't been applied since 1.6 or so
<jcristau> feel free to nuke it
<Sarvatt> doh, alrighty, that was the last major one i needed to refresh for 1.8.99.904 and saves me a bunch of trouble :) i had it disabled automatically in a hook and didn't notice it was already disabled
<Sarvatt> down to 8 patches \o/
<Sarvatt> i sent a bunch of patches to xorg-devel in the past few months that are pretty trivial and didn't get any responses, should i resend the patches or is it ok to just reply to them to bump them back up?
<Sarvatt> http://patchwork.freedesktop.org/patch/1048/ http://patchwork.freedesktop.org/patch/854/ http://patchwork.freedesktop.org/patch/853/ 
<jcristau> i think either would be ok
<Sarvatt> thanks, dont have git send-email setup on the machine i'm on at the moment and wasn't sure if it was wrong to just reply
<Sarvatt> doh forgot i needed to update libxfont for 1.8.99.904 and it failed to build
 * Sarvatt tries to figure out all this new util-macros 1.10 docbook junk to fix it
<Sarvatt> ah the rules are hardcoding the doc_files that have changed
<Kangarooo> Sarvatt: ive uploaded even more dbg files. to bug 587710
<ubot4> Launchpad bug 587710 in nvidia-graphics-drivers (Ubuntu) "if FF wit lot Gif & overloading CPU then X-boom to login (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/587710
<Sarvatt> jcristau: do you have any problems with me merging things without trying to release it? would it be better to just not do it than keep things up to date in git without releasing?
<Sarvatt> like xutils-dev and stuff
<jcristau> nah that's fine
<jcristau> at least until squeeze is frozen, for low-risk stuff like that you can keep putting new releases in git
<Kangarooo> brb restart
<Sarvatt> i'm doing xorg-sgml-doctools and xorg-docs in edgers for instance and since i have to fix up the installs and junk i'd rather just do it in debian since it'd have to be done there eventually and is easier than just making hook scripts to update things locally every time to boot
<Sarvatt> ah squeeze isn't frozen yet?
<Sarvatt> that was going to be my next question :)
<jcristau> nope.  last word was sometime in august
<Sarvatt> is auto importing from unstable disabled now or is that part of the freeze process?
<jcristau> you mean unstable->testing transitions?
<Sarvatt> yeah
<jcristau> the freeze is when that's stopped, so from that point every package gets reviewed by an RM before it can transition
<Sarvatt> gotcha, thanks
<jcristau> Sarvatt: where did that intel mbp backlight patch come from?  i can't seem to find it on intel-gfx
<Sarvatt> lp bug, fdo bug and fedora picked it up too, i emailed the author asking him to put his attribution and send it to #intel-gfx but got no response. digging up the info now
<jcristau> ok found http://bugs.freedesktop.org/show_bug.cgi?id=27484
<ubot4> Freedesktop bug 27484 in Driver/intel "kernel backlight control method missing for macbooks" [Major,Resolved: duplicate]
<Sarvatt> https://edge.launchpad.net/ubuntu/+bug/417770
<ubot4> Launchpad bug 417770 in xserver-xorg-video-intel (Ubuntu Lucid) (and 2 other projects) "[i965gm] kernel backlight control method missing for macbooks (affects: 8) (dups: 1) (heat: 48)" [Medium,Confirmed]
<Sarvatt> yeah
<jcristau> pondering just pushing http://bugs.freedesktop.org/attachment.cgi?id=33550
<Sarvatt> the kernel side support for it is pretty darn recent, ubuntu was carrying it as a patch before it went upstream for a few months
<jcristau> the bug says .34
<jcristau> Sarvatt: now it's there :)
<Sarvatt> woohoo :)
<Sarvatt> would you believe i've brought it up at least 4 times in intel-gfx when people were around over the months :)
<jcristau> sadly i can easily believe that
<Sarvatt> well xorg-sgml-doctools looks safe enough to update so i pushed that, dont think i'll touch xorg-docs though :)
<Sarvatt> that darn xorg-sgml-doctools 1.3 was causing me all kinds of problems building random stuff, things couldn't find that xorg.css
<Sarvatt> oh yeah, libX11 has a few symbols that are X_HIDDEN now that were listed as (optional) in the .symbols before, is it ok to leave the (optional) lines there? -c4 didn't error out now that they were missing but i'm not sure
<jcristau> the optional means it's ok if they disappear
<jcristau> so yeah
<Sarvatt> figured as much but wanted to be sure :)
<Sarvatt> hmm all this util-macros 1.10 stuff needs fop installed to work, xmlto only recommends libpaper-utils, dblatex | fop and i dont have it installed
<Sarvatt> checking for fop... no
<Sarvatt> configure: WARNING: fop not found - documentation targets will be skipped
<Sarvatt> libxfont has --enable-devel-docs..
<Sarvatt> this might explain all the doc warnings i had building libxcb
<Sarvatt> ah i ramble too much, fop's just used for the pdf and ps docs and the warning was vague
<jcristau> we don't really care about the libxfont devel docs i'd say
<bjsnider> Sarvatt, we've got a problem with the fact that nvidia-current install two separate modprobe.conf files, and in some cases only one is used by the system
<bjsnider> what about putting the one combined file in /etc/nvidia-current/ ?
<Sarvatt> bjsnider: it's installing 2? you sure you arent just looking at the one and the link to it?
<bjsnider> it explicitly install two. the /usr on a separate partition issue is why
<bjsnider> /usr/lib/nvidia-current/ contains the blacklists, and /lib contains the alias
<bjsnider> without the alias, the xorg.conf file points to a nonexistent driver
<bjsnider> there are also a bunch of empty directories and a holy mess off extra stuff going into the 32-bit compat section, but those are different problems
<bjsnider> !find /lib/nvidia-current/modprobe.conf maverick
<ubot4> bjsnider: Please use http://packages.ubuntu.com/ to search for files
<Sarvatt> yeah I was saying the glob for the 32 bit install stuff was screwed up but guess tseliot missed that :(
<Sarvatt> the one in /usr/lib/nvidia-current isn't even getting used is it?
<Sarvatt> that ones the alias nvidia nvidia-current
<bjsnider> right
<bjsnider> the blacklist one is getting used
<Sarvatt> i was wondering how it was getting aliased now, remember seeing that before
<Sarvatt> oh it doesn't need to be aliased
<Sarvatt> dkms is building it as nvidia-current
<bjsnider> it needs to be aliased because otherwise the xorg.conf file is wrong
<Sarvatt> it builds nvidia.ko and installs it to nvidia-current.ko in the right place, the module says what devices it supports after the depmod and it's auto loaded by udev, the x driver doesn't load the kernel module unless it's not already loaded and i can see that being a problem for some people that boot fast doing it that way?
<bjsnider> the alias could be dropped if the module was installed as nvidia.ko
<Sarvatt> its not so it can be parallel installable with the others, but i dunno why he didnt just add the alias to the modprobe.conf with the blacklists
<bjsnider> neither do i
<bjsnider> i mentioned it to him a couple days ago and he said we should only have one file
<bjsnider> in other words he acknowledged it as a problem
<Sarvatt> i still dont get why its desirable to have multiple nvidia packages and/or fglrx installed at the same time if you cant even switch with jockey without uninstalling (not to mention fglrx+nvidia installed at the same time doesn't even work)
<bjsnider> that is indefensible in my view as well
<bjsnider> isn't the packaging essentially copied over from mandriva? what was their rationale?
<Sarvatt> they do it different, ours got even more convoluted
<Sarvatt> they keep mesa libgl in /usr/lib. they dont build with TLS so just using ldconfig pointing at the different directory for the proprietary drivers works
<Sarvatt> we couldn't do that because of a tag on the lib making the TLS one in /usr/lib always the priority but i patched mesa a few months ago to fix that
<Sarvatt> we could just have nvidia installing it to /usr/lib/nvidia-foo with an ld.so.conf.d snippet pointing to the new directory and not need any diversions or alternatives from what I can tell..
<bjsnider> insttalling what?
<Sarvatt> the nvidia libgl
<Sarvatt> or we could make the /usr/lib/libGL.so.1 symlink an alternative
<Sarvatt> and throw everything in /usr/lib
<bjsnider> that would make things too easy
<Sarvatt> nothing else conflicts between nvidia-current, nvidia-173 and mesa besides /usr/lib/libGL.so.1
<bjsnider> i thought nvidia changed hte name of that
<Sarvatt> everything but that one, they cant change that one
<Sarvatt> its just a symlink..
<bjsnider> no, that was glcore
<Sarvatt> thats a nvidia only thing
<Sarvatt> the ones in nvidia-current wont ever interfere with each other, they used to but nvidia-current wont interfere with 173 or 96
<Sarvatt> 173 has other files that interfere with 96 though
<tjaalton> hi Sarvatt! uni, but yeah, pretty much :)
<Sarvatt> you missed all of the fun of transitioning to xserver 1.8 with no core-dev a few weeks ago! :D
<tjaalton> ah right :)
<tjaalton> I actually did read some irclogs when I was bored, but it was too late anyway
#ubuntu-x 2010-07-06
<Sarvatt> might just throw this all in maverick edgers depending on how much it screws up upgrading, will see after everything builds
<RAOF> :)
<Sarvatt> leaving lucid on 1.8.x for sure though
<Sarvatt> got a refreshed bgnr patch that doesn't break the video abi finally so everything's fine, thats what was holding me back before because gdm was all kinds of screwed up without -nr support
<RAOF> Sweet!
<Sarvatt> felt like i've been in australia for the past week, had to tiptoe around a 5GB bandwidth cap on my cell phone until I got net here :D
<RAOF> Heh.
<RAOF> I've chewed through 70% of my cap already this month; rollover date is the 27th.
<RAOF> That steam sale was a bit of a killer :)
<bjsnider> luckily i'm uncapped
<johanbr> RAOF, did you lose a bet?
<Sarvatt> i dont think i'm capped either because i used about 20gb last week on the phone but i coulda swore it was 5gb
<RAOF> johanbr: ?
<johanbr> RAOF,  "I've chewed through 70% of my cap already"
<Sarvatt> so warewolf, got some logs for me to dig through to see about your touchscreen? :)
<johanbr> sounds like you promised to eat your hat if...
<warewolf> Sarvatt: you're the third person I have involved in this now actually
<warewolf> Sarvatt: and each of you seem to be chiming in when the rest are idle :)
<Sarvatt> /var/log/Xorg.0.log, dmesg would help
<warewolf> Sarvatt: in the mean time, enjoy my fireworks photos from yesterday: http://picasaweb.google.com/richard.harman/WashingtonDCFireworks20100704#
<RAOF> johanbr: :P
<warewolf> Sarvatt: actually I'm certain it isn't an X problem, it's a kernel problem.
<warewolf> Sarvatt: the hid-mosart driver isn't "attaching" to the hardware, and making a /dev/input device.
<warewolf> Sarvatt: want me to give you an account on the EeePC so you can mess with it directly or are you preoccupied
<Sarvatt> that'd be perfect if you dont mind
<RAOF> Woot!  One Q965 motherboard received.  Let's play âhunt that bugâ!
<warewolf> ok just a sec
<warewolf> lemme find a crossover cable so I can stick this bad boy in a DMZ
<Sarvatt> RAOF: Q965 is just a gma 950 derivative isn't it? you want a real 965!
<Sarvatt> yeah its a GMA 3000, just a souped up gen 3
<warewolf> GMA--
<warewolf> poulsbo--
<warewolf> crossover acquired
<Sarvatt> \o/
<RAOF> No, I want me a Q965.
<Sarvatt> thanks richard, a lot faster if i can poke around on it :)
<RAOF> So I can unbreak resolution changing.
<warewolf> Sarvatt: I thought as much
<warewolf> yaay
<RAOF> Aww, man.  Everyone with Q965 should totally run checkbox and do the randr cycle test.
<maco> do what now?
<maco> is Q965 the same as i965?
<RAOF> Nope.
<RAOF> It's a GMA3000, not an X3000
<RAOF> Important difference :)
<Sarvatt> ugh what the heck, almost all drivers failed to build because of missing dependencies against xserver 1.8.99.904
<Sarvatt> i guess xserver-xorg-dev needs to pull in libxext-dev now?
<Sarvatt> well its a lot more widespread than that, acecad just needed libxext but everything else is failing at compile time - https://edge.launchpad.net/~sarvatt/+archive/xorg-testing/+packages?field.name_filter=&field.status_filter=published&field.series_filter=maverick
<Sarvatt> thats a nasty looking list
<Sarvatt> RAOF: want me to run it on 945 or do ya know its q965 specific?
<Sarvatt> these packages all build fine locally, now i'm stumped..
<RAOF> Sarvatt: You're welcome to try, but I'm pretty sure it's 965-specific.
<RAOF> Looks like CFLAGS isn't getting set correctly?
<Sarvatt> yeah none of the packages can find /usr/include/xorg
<Sarvatt> xorg-server.pc is fine, doesn't happen locally with the same packages, hmm
<Sarvatt> of course i dont have pbuilder set up or the space to set one up at the moment :(
<warewolf> Sarvatt: I thought you were going to bed :P
<Sarvatt> yeah then i saw like 50+ build failures i could upload and have ready when i wake up if i figure it out :)
 * warewolf is having fun helping a friend figure out WTF happened and how his box got hacked into
<warewolf> haha
<warewolf> this is the life of a geek
<Sarvatt> i'm stumped.. anyone have any idea why all of these packages aren't getting proper CFLAG's now when they build fine locally with the same packages? https://edge.launchpad.net/~sarvatt/+archive/xorg-testing/+packages?field.name_filter=&field.status_filter=published&field.series_filter=maverick
<Sarvatt> everything builds fine against xserver 1.8.2, did that a few hours before trying against 1.8.99.904
<Sarvatt> guess i should compare the build deps on the ones that actually built right and see if its one of those
<RAOF> Mayhap.
<RAOF> Hm.  Is it a change in xorg-macros that's breaking it?
<Sarvatt> hmm
<RAOF> x-x-v-intel, for example, doesn't ever explicitly AC_SUBST(XORG_CFLAGS) anywhere, but that's what it uses to pick up the include directories.
<Sarvatt> i built the server against 1.10 then built all those drivers against 1.8.99.904, and for 1.8.2 i already had the server built and just built the libs and drivers
<Sarvatt> so could be that
<Sarvatt> lessee what changed between 1.8.0 and 1.10.0
<Sarvatt> just doc stuff
<Sarvatt> xorg-server.pc added this in 1.8.99.904 - Requires.private: xproto >= 7.0.17 randrproto >= 1.2.99.3 renderproto >= 0.11 xextproto >= 7.0.99.3 inputproto >= 1.9.99.902 kbproto >= 1.0.3 fontsproto videoproto dri2proto >= 2.3 xineramaproto
<Sarvatt> its gotta be some build dep needing to be added because it builds fine locally just not on a ppa or pbuilder
<Sarvatt> hmm
<Sarvatt> everything that built right has sdkdir=`$PKG_CONFIG --variable=sdkdir xorg-server` in configure.ac
<Sarvatt> darn nope, just hadn't finished grepping yet
<RAOF> Sarvatt: xserver-xorg-dev is missing a depends on xineramaproto
<RAOF> At least, as of my reading of the package and the xorg-server.pc file.
<Sarvatt> ahhhhhhhh i ran into that problem a few weeks ago too, lets see if that fixes it
<Sarvatt> thanks so much RAOF 
<RAOF> No problem whatsoever.  I'd like to update to 1.8.99.904 in Maverick/experimental soon, so you're helping tremendously.
<Sarvatt> bingo!
<Sarvatt> that's all it was
<Sarvatt> sheesh, can't thank you enough, i should have been asleep 4 hours ago :)
<Sarvatt> now to hit rebuild 100 times after the new server builds
 * Sarvatt ponders jumping to japan and just reuploading everything again instead
<RAOF> Sarvatt: Would you like *me* to hit those rebuild buttons?
<Sarvatt> could just copy it all to edgers :)
<Sarvatt> cant hit rebuild until the server is closer to building, was 4 hours last i looked
<Sarvatt> and its in a personal ppa so ya cant hit rebuild
<Sarvatt> tormod didn't want a crackier ppa on edgers team than edgers and would rather me put the crack in there but i get 100+ emails when favicons go transparent because of cairo so i'm a little conservative in there and build big things in my ppa first... :D
<Sarvatt> its good to go for edgers maverick though, just need a few drivers not in pkg-xorg like tslib
<Sarvatt> sheesh, i386 queue time goes up every time i look.. amd64 is all rebuilding now though
<seb128> Sarvatt, it's a queue of langpack builds but it seems to have lower priority than uploads so should not be an issue
<Sarvatt> so wacom needs updating, and acecad/citron don't build against 1.8.99.904 but otherwise everything is good
<Sarvatt> of course this is with everything from git, will probably run into problems using released versions of things
<Sarvatt> ah hell, binary copied xserver and it hadn't been published yet when the drivers started building
<bryceh> heya Sarvatt, welcome back!
<Sarvatt> heyo bryceh! sorry had to run out for a bit
<Sarvatt> darnit, can't copy nvidia-graphics-drivers from maverick to x-updates because maverick's is using a different orig.tar.gz
<Sarvatt> deleted it from x-updates a day ago and its still saying the orig.tar.gz exists in the ppa even though it doesnt
<Sarvatt> looks like the package makes its own orig.tar.gz now too so i cant just make a debian native without one to get around it, and changing the version to something like 256.35+xup1 makes it try to look for .run's with that name
<Sarvatt> maybe it'll let me upload just not copy
<bryceh> could be
<bryceh> if it's totally stuck, put a request in via Answers for someone to take a loo
<bryceh> +k
<bjsnider> Sarvatt, just repackage it
<Sarvatt> i've been trying
<Sarvatt> its all screwed up now
<Sarvatt> Rejected:
<Sarvatt> File nvidia-graphics-drivers_256.35.orig.tar.gz already exists in Primary Archive for Ubuntu, but uploaded version has different contents
<Sarvatt> primary archive for ubuntu?
<bjsnider> for that series
<Sarvatt> lucid
<bjsnider> so install the source package, then do debuild -S -sd and upload
<Sarvatt> it got rejected, i did that as well
<Sarvatt> oh maybe i packaged that for maverick by mistake that time
<Sarvatt> nope
<Sarvatt> Version: 256.35-0ubuntu0sarvatt2~lucid
<Sarvatt> Distribution: lucid
<bjsnider> i didn't know hte 256 driver had been officially packaged for lucid
<Sarvatt> i think its just screwed because I tried copying it and it failed
<Sarvatt> checking changes
<bjsnider> you tried copying it from maverick to lucid?
<Sarvatt> yeah
<Sarvatt> rebuild copying
<bjsnider> from official maverick to ppa lucid?
<Sarvatt> yeah i do it all the time
<bjsnider> so why did it fail?
<Sarvatt> https://edge.launchpad.net/ubuntu/+archive/primary/+copy-packages?field.name_filter=nvidia&field.status_filter=published&field.series_filter=maverick
<Sarvatt> it says the orig.tar.gz is already exists in the PPA
<bjsnider> it does
<Sarvatt> but it doesn't, and its not on any of the sources lists
<bjsnider> you put it there
<Sarvatt> i deleted it 24 hours ago
<Sarvatt> so i could copy the official one since its different
<bjsnider> it takes a week for the deleted stuff to actually be deleted
<Sarvatt> since when?
<bjsnider> i dunno, ever i guess
<Sarvatt> its not on the ppa or in any of the sources when i look at the lists directly
<Sarvatt> it only took about 2 hours a few weeks ago
<bigjools> Hi - you can't overwrite file versions with different contents - ever.
<bjsnider> yeah, it's removed from the list
<bjsnider> that's right too
<bjsnider> there can only every be one source package with that unique name
<bjsnider> you can never replace it
 * bigjools is the lead dev for Soyuz
<Sarvatt> it's worked in the past, but i've never done it while copying, but i am positive i have done it in the past many times with strictly uploaded sources
<bjsnider> bigjools, so what does he do, upload the one he deleted again?
<bigjools> it's impossible to overwrite a file with different contents, you've never done it I can assure you :)
<bigjools> the easiest thing is to bump the version if you can and upload it again
<bjsnider> he cannot bump the version and keep it accurate
<bigjools> I've never tried uploading a deleted one again, it might work
<bjsnider> he'd have to change the resulting package name by adding a dash somewhere after the .35
<Sarvatt> thats what I mean I've done in the past before many times
<Sarvatt> but yeah I can't alter the version on this package in a way that it'll accept, crap :(
<bigjools> darn
<bjsnider> Sarvatt, try uploading the source package you originally created for the ppa
<bjsnider> not the maverick one
<Sarvatt> i did :(
<bjsnider> it rejected it?
<Sarvatt> it's stuck saying it exists in primary archive for ubuntu
<bjsnider> ok, when is nvidia releasing a new driver?
<Sarvatt> and contents different
<bjsnider> now would be a good time
<Sarvatt> yeah tell me about it, won't be doing that again :)
<bigjools> Sarvatt: that means you're uploading to Ubuntu, not a PPA
<Sarvatt> bigjools: I copied it from primary archive for ubuntu and it's screwed up where it thinks the file is, i'm positive it's going to the PPA
<Sarvatt> Uploading to x-updates (via ftp to ppa.launchpad.net):
<bigjools> what upload path?
<Sarvatt> fqdn = ppa.launchpad.net
<Sarvatt> method = ftp
<Sarvatt> incoming = ~ubuntu-x-swat/x-updates/ubuntu
<bigjools> ok
<bigjools> the error is misleading because the file was copied from  Ubuntu
<bigjools> bleh
<Sarvatt> yeah only it wasn't really copied because it had an error so it's kinda stuck in limbo
<bigjools> so, how long ago did you delete the package?
<bjsnider> but the point remains it's still complaining about the source package name
<Sarvatt> 24 hours or so
<Sarvatt> aha!
<Sarvatt> [PPA ubuntu-x-swat-x-updates] [ubuntu/lucid] nvidia-graphics-drivers 256.35-0ubuntu2~xup (Accepted)
<bigjools> ok you can resurrect it by copying it within the PPA I think
<Sarvatt> woot
<bigjools> FWIW you can refer to .orig files in Ubuntu from your PPA as well
<Sarvatt> i tried that but the .orig isn't really available and it got rejected
<Sarvatt> thanks for the help bigjools, got it worked out :)
<bigjools> this is why the UI to copy files from Ubuntu is not linked anywhere :)
<bigjools> it's got issues
<Sarvatt> yeah definitely going to be more careful with it in the future :)
<bigjools> anyway, you're welcome
<bjsnider> it should have stopped him from trying to do this in the first place
<bigjools> why should it have done that?
<Sarvatt> i dont see how it could, this is a really fringe problem
<bjsnider> he was trying to overwrite an already-existing source package with another of the same name but different contents
<bigjools> hmmm
<bjsnider> it shoul dhave looked at the ppa contents and said "you don't wanna do that, sparky"
<bigjools> can you file a bug please?  I can take a look.
 * Sarvatt tries to figure out how to explain the situation in a bug
<bigjools> bugs.launchpad.net/soyuz
<bigjools> just say what you did, exactly
<bjsnider> there's something it stops you from doing, which is rebuilding a package in a new series but keeping the same package name. that is a good policy, to just say "no" when someone tries to do something that would violate the rules
<Sarvatt> writing up the bug I'm not really sure it's a bug outside of it saying the orig.tar.gz existed in the primary archive for ubuntu, in the end it did accept a package with my original orig.tar.gz
<Sarvatt> (saying it existed already in the rejected mail)
<Sarvatt> man, I'm even more confused now, the orig.tar.gz it accepted was actually the one copied from the archive!
<bjsnider> was there any difference between that one and your original orig fie in terms of contents?
<Sarvatt> the one in the archive uses the nocompat32 .run
<Sarvatt> for x64
<bjsnider> what? why?
<Sarvatt> it uses the 32 bit .run contents directly
<bjsnider> i see
<Sarvatt> it had to  have actually deleted my orig.tar.gz with the same name and copied the one from the archive over because this one it accepted really is the archive one
<Sarvatt> dpkg-source: info: building nvidia-graphics-drivers using existing nvidia-graphics-drivers_256.35.orig.tar.gz
<Sarvatt> i opened up that orig.tar.gz and it's got the nocompat32.run in it
<bjsnider> then the original error doesn't make sense
<Sarvatt> yeah for sure.. i'm totally lost
<bjsnider> bigjools, it takes a week for files to actually disappear from a ppa once they are deleted, right?
<Sarvatt>  871f54c6c8e0b30fcb5fec40fe3eed7b7081203c 49082614 nvidia-graphics-drivers_256.35.orig.tar.gz << the uploaded one it accepted  f8ec98f1d0deef487e60f8435ce8ccc7e3f30bd4 65596688 nvidia-graphics-drivers_256.35.orig.tar.gz << my original one i deleted
<bigjools> from the repo. 15 minutes or so, from inside Launchpad it takes a week
<bjsnider> bigjools, in other words, launchpad still thinks they're there for a week?
<Sarvatt> http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu/pool/main/n/nvidia-graphics-drivers/
<bigjools> no, it just keeps a copy in the librarian in case you want to keep it
<bigjools> for downloading later
<Sarvatt> definitely the one from the maverick archive in there, i only uploaded the diff
<bjsnider> that error message would happen if you had tried to copy a maverick package into the ppa into the maverick series. i don't see why it would happen if copying into the lucid series
<warewolf> Sarvatt: hey, I figured out how to get dhcpd working on two interfaces, so it should be easier to into my EeePC now.
#ubuntu-x 2010-07-07
<ripps> woo, new ati driver. how long until it gets into Maverick?
<RAOF> Probably pretty soon.
 * bryceh waves
<RAOF> bryceh: Good $TIME_OF_DAY!
<RAOF> if(party_like_its_1989) { â¦ }
<RAOF> I love the X server.
 * warewolf waves
<RAOF> I WIN!
<tjaalton> RAOF: what did you do this time? :)
<RAOF> I won the âwhy is Q965 going mad on modesettingâ award.
<RAOF> Answer: the cursor.
<tjaalton> ah
<ara> RAOF, hi!
<RAOF> ara: Hi!
<ara> RAOF, how is it going?
<RAOF> Pretty well.
<RAOF> Rounding up a marvelous 965 bug which has provided _hours_ of entertainment!
<ara> RAOF, nice :-)
<RAOF> How about your fine self?
<ara> RAOF, good, thanks, wondering if anyone has reported animations to be extremely slow in maverick with nVidia (either proprietary or free drivers)
<RAOF> Which particular animations?
<RAOF> And to answer your actual question: no, I haven't run across reports of that kind.
<ara> i.e. creating a new bubble of conversation in empathy with the ubuntu theme
<ara> minimizing windows, or maximizing them
<RAOF> No.
<RAOF> The best I can do you is âFullscreen flash is really jerky with nouveau or nvâ
<RAOF> I guess you're reporting this now? :)
<ara> OK, I will report it. Right now I am with the nouveau driver
<ara> if it keeps being this slow in the following weeks, maybe we can have a look in Prague
<RAOF> Absolutely.
<RAOF> I expect to be doing a certain amount of âhey my machine $DOES_CRAZY_THING_Xâing there :)
<ara> :)
<ara> great, thanks!
 * ara ubuntu-bugs xorg
<ara> RAOF, https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/602582
<ubot4> Launchpad bug 602582 in xorg (Ubuntu) "Desktop animations are very slow using either nouveau or nvidia drivers (affects: 1) (heat: 6)" [Undecided,New]
<bryceh> hi ara
<ara> hey bryceh, nice to see you around :)
<tjaalton> so it's a new feature that the mouse cursor disappears after a few seconds when it's still?
<tseliot> tjaalton: yep, you can remove "unclutter" to get rid of it
<tseliot> I did
<tjaalton> tseliot: ah, okay
<tjaalton> well, it's ok as is, just good to know :)
<xelister> hi
<xelister> around 5 computers, 4 monitors
<xelister> most of them suck on ubuntu - hangs, freezes, crashes,  bad resolutions
<xelister> is there any hope to find here someone to really look into such cases if I report them and to solve this?
<Sarvatt> RAOF: the fullscreen flash being jerky with nouveau or nv seems like it might be a kernel problem to me, ondemand + flash no workie right on my amd boxes :)
<Sarvatt> if its windowed fullscreen its fine but once it goes to real fullscreen it stays at 800mhz and is choppy unless i switch governers or manually pick any other speed
<Sarvatt> i'm putting (Needs 6.13.1) in the title of ati bugs fixed in the new version
<Sarvatt> like xv on r100
<Sarvatt> hmm nvidia-current-dev is kind of sketchy
<jcristau> Sarvatt: with xproto and libXfont out of the way server 1.9 is good to go, right?
<Sarvatt> i'm not sure actually, I updated all protos and libs from git and haven't tried with just xproto and libXfont
<jcristau> seems to build here anyway
<Sarvatt> it should be fine
<jcristau> 0 testing though :)
<Sarvatt> its going to need macros 1.10 soon though
<Sarvatt> a ton of drivers need updating too
<Sarvatt> they all have releases now though at least outside of wacom
<Sarvatt> hmm not sure evdev or synaptics have releases yet actually
#ubuntu-x 2010-07-08
<warewolf> hey Sarvatt 
<warewolf> maco: hey! I know you! :)
<maco> hi
<warewolf> I'm the guy w/ the camera at the last reverse space meeting :)
<Sarvatt> heyo richard
<warewolf> Sarvatt: I'm embarking on a new adventure
<warewolf> Sarvatt: I'm gonna figure out what it is under karmic the touchscreen uses for a driver
<warewolf> looks like it's hiddev
<warewolf> http://nopaste.snit.ch/21864
<warewolf> aha
<warewolf> I think I figured this out
<freeflying> anyone know how to configure thinkpad's trackpoint in maverick?
<warewolf> ARGH so close yet so far way
<freeflying> the udev/xorg.conf.d doesn't work
 * warewolf gives up for the night
<warewolf> Sarvatt: I have tapping working w/ hiddev, but the cursor won't move out of 0,0 
<ernstp> Hi, if I install xorg-edgers on lucid gdm hangs
<ernstp> I get a black background and I can move the mouse cursor, but nothing is drawn
<ernstp> not sure which package is causing it, nothing in dmsg
<ernstp> xorg-edgers is working for anyone with lucid and radeon?
<Sarvatt> jcristau: any idea what the heck is going on here? http://packages.debian.org/source/sid/xserver-xorg-video-ati
<jcristau> Sarvatt: packages.d.o is confused by the stale source kept around because of hurd-i386, would be my guess
<Sarvatt> ah makes sense looking at the binary packages
<Sarvatt> hmm x-x-v-ati seems to be a little messed up in git? no src/modes/* for instance
<jcristau> what's wrong with that?
<jcristau> modes/* is from the xserver source
<Sarvatt> ah ok, was just merging it and looking at the errors
<warewolf> oh weird
<warewolf> now I have to figure out how to reassign axises for this touchscreen
<warewolf> it appears to be reporting correctly, but on the wrong axises
<warewolf> Sarvatt: so I hacked up the hid driver under Lucid to stop ignoring the T91MT's touchscreen, so now it shows up
<warewolf> Sarvatt: but the X axis is being reported on the Y axis, and the Y axis is being reported on the Z axis.
<warewolf> Sarvatt: man, your interwebs are sure crashy
#ubuntu-x 2010-07-09
<warewolf> YES. I WIN.
<warewolf> quirks=0x0486:0x0185:0x40
 * RAOF considers opening up his laptop so he can help it push the bits around faster by hand.  Less slow, more speed, damnit!
<warewolf> nooooooooooo! the cursor doesn't track correctly when xrandr rotated! noooooooooo!
<RAOF> Fixed in xserver 1.9
<warewolf> RAOF: was that directed at me?
<RAOF> (Although I think you'll need to manually set the input transformation matrix)
<RAOF> Yup.
<warewolf> I'm on a roll tonight, tell me what to do
 * RAOF tries to rememberâ¦
<RAOF> So, if you're using Xserver 1.9 you can set an input transformation on your input device.
<RAOF> It's a 3x3 perspective matrix, so you basically just want the last column to be 1s, the last row to be 0s, and the top-left 2x2 submatrix to be a rotation matrix for your xrandr transform.
<warewolf> X.Org X Server 1.7.6
<warewolf> so I preusme I'm not running 1.9
<RAOF> No.
<warewolf> so close!
<warewolf> man I have been fighting with this t91mt and the touchscreen under lucid
<warewolf> RAOF: so wait, how come xrandr under Karmic worked fine?
<RAOF> As in: it rotated your input device, too?
<warewolf> yep.
<warewolf> infact, I have a live usb stick I can test that on too. 1 sec
<warewolf> yep works fine
<RAOF> Ah.  So the basic rotation case should still be handled.
<warewolf> I'm not sure what the difference is
<RAOF> I'm not familiar with what you've had to do to make it work in Lucid â in an ideal world, it should work as well as karmic (hah!)
<warewolf> hah
<warewolf> well, the kernel in lucid blacklisted the touchscreen from hiddev
<warewolf> so I unblacklisted it
<warewolf> then I had to quirk it with the multitouch quirk
<warewolf> now it works and reports correct axises, except when xrandr rotated.
<bryceh> RAOF, do you have a few minutes to chat?
<RAOF> bryceh: Yeah.
<bryceh> RAOF, I want to talk a bit about handling X bug reports that are filed against lucid
<bryceh> I was going through the -ati bug reports looking for ones to test my new upstreamer tools on, and it struck me that the vast majority of bug reports are against lucid
<bryceh> in fact nearly all of these were reported post-release
<bryceh> as usual most are kinda low quality, but not all of them
<bryceh> in the past before we tagged releases, bugs reported against prior releases were always kind of a nuisance to me, but when I started tagging them and was able to filter them out, I found it quite helpful
<bryceh> as I could just ignore anything not tagged with the current development release
<RAOF> So we've got a bit of a decision tree here, right?
<RAOF> Does the lucid bug probably have enough information to fix it? No: ask for retesting against Maverick, Yes: go to part 2
<bryceh> RAOF, I guess I've gotten kinda bigoted against bug reports against non-development versions, and consider them to basically not much more than technical support requires
<bryceh> RAOF, yeah that's true we have a tree
<RAOF> Part 2: If this bug were fixed, would it be SRUable?  No: Ask to retest against Maverick.  Yes: â¦ um?
<bryceh> but what I want to talk about is if we could just lop the entire limb off?
<bryceh> IOW, when someone files a bug report against a released version, have a script close the bug with a kindly message, or convert it to a question, or similar
<RAOF> That's pretty tempting.  On the other hand, there may well be bugs reported post-release that we do want to fix *in that release*, particularly LTS releases.
<bryceh> so my question to you really is, to what degree do you care about bugs reported against released versions of ubuntu?  Do you think having them open helps you in some way?
<bryceh> right
<bryceh> however I get the sense that we defer from closing 99 bugs so as to keep 1 open that we want to fix
<RAOF> Yes.
<bryceh> but then, reading through 99 bugs gets tedious, so I'm not sure how often we actually find that 1 bug ;-)
<bryceh> RAOF, what's been your experience so far with SRU'ing X bugs to lucid?
<RAOF> Perhaps what we want is to (a) auto close, with a nice message but (b) send them somewhere where we can periodically review them and re-open?
<RAOF> bryceh: Mostly my experience has been: poke the kernel team to fix it.
<bryceh> *nod* yeah that's exactly what I was mulling over myself
<bryceh> RAOF, ok yeah I think I've done a few SRUs but of those they were all either bugs that had been reported prior to the release which I had been working on, or ones I'd noticed myself
<RAOF> That matches my experience.
<bryceh> ok cool
<RAOF> How would auto-close interact with regressions introduced in an SRU, though?
<bryceh> alright, well my time is going to be pretty chopped up this next month, so dunno if I'll ever get a chance to work on it, but I've got an idea on how to render this into a script
<bryceh> that's a good question
<RAOF> That could possibly be incorporated into the script.
<RAOF> Actually, that would be useful regardless of auto-close or not:
<RAOF> Highlight bugs reported in the 10 days after an update goes from -proposed to -updates. 
<bryceh> yep
<bryceh> and it could verify that the user had the requisite version installed, so it still filters out unrelated bug reports
<bryceh> ok cool
<bryceh> hey I have something cool for you :-)
<RAOF> That would be pretty handy.
<RAOF> Oh?
<bryceh> http://www2.bryceharrington.org:8080/cgi-bin/send_upstream.cgi
<bryceh> RAOF, this is the bug upstreamer I demoed at UDS
<RAOF> OOooooooooh
<bryceh> it's now been generalized sufficiently that others can use it
<bryceh> once I get a few people test driving it successfully (and have a couple other features added in) I'll publish it for general use
<bryceh> RAOF, mostly I've tested it with -ati and -intel bugs
<RAOF> I'll give it a whirlygig.
<bryceh> there may be some problems using it against source packages that don't have upstream bug tracker info set... but these should be rare (tell me if you run into one)
<bryceh> RAOF, thanks
<bryceh> one of the upcoming features (which is ultra cool) is sending attachments as well.  We've got the code to do it, but it needs some integration work
<bryceh> Kamran, my GSoC student, put it together
<bryceh> here's the evidence that it works:  https://bugs.freedesktop.org/show_bug.cgi?id=28969
<ubot4> Freedesktop bug 28969 in Driver/intel "[Intel Arrandale] Screen flickers" [Normal,New]
<bryceh> RAOF, I don't know if you've been upstreaming many bugs so far, but if so this'll majorly save time
<RAOF> I haven't been upstreaming too many bugs at this point.
<bryceh> RAOF, also if while using it you have ideas on improving it let me know
<RAOF> I most assuredly shall!
<RAOF> Incidentally, pitti's new add_drm_info hook is a bit of a winner.
<bryceh> oh?
<bryceh> I've landed that change I was talking about to make launchpad show the first/last 40  comments on highly commented bugs.  Went in earlier this afternoon
<RAOF> In some respects its duplicates the xrandr output, but it's got the edid in an easier to use form, and is right there on the bug info.
<bryceh> should show up on edge in a day or so
<bryceh> oh nice
<RAOF> Cool.  That'll be *substantially* more useful than just the first 80 :)
<bryceh> yeah that was on my todo list to get that edid info parsed better
<bryceh> yeah I hope so
<bryceh> aaaand I happened to make it 1.5% faster at rendering the bug page :-)
<RAOF> :)
<RAOF> Yay!  Kernel's finished building.
<bryceh> RAOF, http://pastebin.ubuntu.com/460901/
<bryceh> copyediting appreciated (especially anything we could leave *out* to shorten the message)
<RAOF> bryceh: Maybe http://pastebin.ubuntu.com/460905/ ?
<bryceh> RAOF, yeah that's better
<RAOF> Bah.  Die, cursor, die!
<Sarvatt> RAOF: regarding the slowness, are they all on maverick? i'm hitting some really strange problems making my machines really slow too
<Sarvatt> I/O problems with 2.6.35 after a few hours it looks like, goes away after a reboot
<Sarvatt> i can't get more than 1MB/second out of my HDD when it happens, haven't had it with 2.6.35-7 yet knock on wood
<RAOF> Sarvatt: Yeah, they are.
<tseliot> only I/O slowness?
<RAOF> I suspect something might be leaking video memory again?  1.6GiB of gem objects, and although there was only ~200MiB of the 2GiB RAM used it seemed to be paging out to swap.
<Sarvatt> there's ureadahead causing an extra 500MB memory load on all my systems too :D
<Sarvatt> oh boy things are leaking again?
<Sarvatt> 58MB here so its not a problem on edgers it looks like
<RAOF> After restarting X it dropped back to 70ish.
<Sarvatt> sure it wasn't 160MB?
<RAOF> Pretty sure.
<scar_> is there any incompatibilities with llvmpipe via xorg-edgers ppa on lucid?
<Sarvatt> what do you mean incompatibilities?
<RAOF> I counted the triplets.
<seb128> bug #603507, does anybody has seen similar issues?
<ubot4> Launchpad bug 603507 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[intel] clutter views not updated correctly with the new clutter (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/603507
<Sarvatt> i compare it to GTT total, if its got an extra digit it's gigs :D
<seb128> not sure if that's a driver issue or a clutter one...
<scar_> Sarvatt: I want to test llvmpipe but was wondering if lucid is supported, in other words if I should have to upgrade to mavrick to test llvmpipe
<Sarvatt> scar_: nope its on lucid too
<Sarvatt> seb128: any quick ways to test that bug?
<scar_> ok great, then also is it necessary for me to use the xorg-edgers ppa or can I use x-updates? 
<seb128> Sarvatt, run unity on maverick if you have intel
<seb128> or unity --popup
<RAOF> I'm running unity right now on Intel.
<seb128> Sarvatt, or some of the gnome-games using clutter
<seb128> the worms one has the issue as well
<seb128> RAOF, under GNOME or an unity session?K
<RAOF> In a unity session - it needs to be run under GNOME?
<Sarvatt> nibbles isn't working
<seb128> Sarvatt, working as displayed content?
<Sarvatt> quadrapassel is fine
<seb128> displaying
<seb128> RAOF, right, I'm unclear what the issue is exactly
<seb128> unity session works fine
<seb128> but running unity --popup under GNOME doesn't
<seb128> nor does the worm game, it never displays the board
<RAOF> Hm.
<seb128> it works fine with clutter 1.2.4
<seb128> or it works fine on clutter 1.2.10 and nvidia
<RAOF> There is a known problem with fullscreen flash, which could possibly be related.
<RAOF> That'll be resolved when we move to intel 2.12.
<RAOF> Which should be soon!
<Sarvatt> i would say its a mesa or clutter bug
<seb128> hey njpatel
<njpatel> hey hey
<seb128> njpatel added a comment to the bug 
<RAOF> That does sound like a very similar behaviour to the flash problem.
<seb128> could you add a reference to that flash bug on launchpad?
<RAOF> I'll hunt it down.
<seb128> thanks
<RAOF> https://bugs.freedesktop.org/show_bug.cgi?id=28573 is what I was thinking of.
<ubot4> Freedesktop bug 28573 in Driver/intel "[i965] Fullscreen flash and windowed SDL games fail to update the screen" [Normal,Reopened]
<Sarvatt> dont suppose http://git.clutter-project.org/clutter-gtk/commit/?id=d50240f524870fd80b2cc5bb96a7bf9b8e10c754 might be related?
<seb128> njpatel, ^ what do you think?
<seb128> Sarvatt, it seems worth trying
<seb128> let me try
<Sarvatt> CLUTTER_VBLANK=none fixes it seb128
<Sarvatt> so it might be
<seb128> indeed
<njpatel> seb128, that clutter bug sounds like it could be the issue
<seb128> thanks for the CLUTTER_VBLANK=none workaround
<Sarvatt> i cant remember the clutter debug option to only disable INTEL_swap_events, argh
<Sarvatt> it would make sense that it only affects maverick though even though lucid had 1.2.x because INTEL_swap_events are in xserver 1.8+ only
<Sarvatt> yep its stuck in event processing without CLUTTER_VBLANK=none 
<seb128> ok, that patches to clutter-gtk fixes the issue
<seb128> I'm uploading that to maverick, thanks guys
<seb128> njpatel, ^
<Sarvatt> \o/ good to hear
<njpatel> seb128, awesome
<njpatel> Sarvatt, thanks!
<Sarvatt> scar_: sorry, missed your question, xorg-edgers is required
<scar_> Sarvatt: no problem, just finished updating. If I break my x-server and can't get up back up after trying a few xorg.conf changes... do you suppose i can just remove the ppa and do update & upgrade to try and revert?
<jcristau> upgrade won't downgrade
<Sarvatt> scar_: sudo apt-get install ppa-purge then just run sudo ppa-purge xorg-edgers
<scar_> ok thanks, hopefully I won't need to use that
<Sarvatt> i'd install it anyway now while you can and if things are broken you can just run it in a recovery console :)
 * scar_ sighs and holds down the shift button
<ricotz> Sarvatt, hi
<Sarvatt> heyo
<ricotz> is the disappearing mouse cursor normal or is it a bug
<jcristau> it's normal
<Sarvatt> its the unclutter package
<ricotz> jcristau, so it is a feature?
<Sarvatt> "feature" yeah
<ricotz> ok ;-)
<scar_> can I remove nvidia proprietary via apt-get purge nvidia-glx ?
<Sarvatt> nvidia-current
<jcristau> apt-get has no purge command, it has remove
<Sarvatt> yeah it does!
<Sarvatt> has for years, i haven't been using debian distros that long but i've used apt-get purge the whole time i have
<scar_> any idea how I can pipe Xorg -configure to more? or even a file...
<Sarvatt> why are you running Xorg -configure?
<Sarvatt> if its for the blob you want nvidia-xconfig, if you're moving away from the blob you want to just remove it completely
<Sarvatt> xorg.conf I mean
<scar_> before and after the xorg-edgers i had to use xorg.conf other wise my pc hangs on startup
<scar_> my geforce 2 doesn't like nouveau
<ricotz> scar_, you can use "COMMAND 2>1& | tee OUTPUTFILE"
<jcristau> Sarvatt: really? heh.
<scar_> the famous stdout stderr redirections :)
<jcristau> Sarvatt: ooh
<jcristau>   * cmdline/apt-get.cc: really applies Julien Danjou <acid@debian.org> patch to add 'purge' command line argument (closes: #133421).
<jcristau> 2007.  it's brand new!
<jcristau> no wonder i didn't know about it
<scar_> Kernel driver in use: nouveau, which is awesome, but still getting Xlib:  extension "GLX" missing on display ":0.0". Should I try creating xorg.conf again to force GLX to load?
<scar_> also xrandr only shows 640x480 and 800x600, I think I need to change my monitor's verical and horisontal sync
<Sarvatt> scar_: you still have nvidia installed
<Sarvatt> sorry, since you have a geforce 2 its not nvidia-current that you have to purge
<scar_> I think so tried to purge nvidia-current but it did nothing
<scar_> I also did rmmod nvidia
<Sarvatt> its sudo apt-get purge nvidia-96 i believe?
<Sarvatt> also what distro are you using?
<Sarvatt> if its lucid you want to sudo apt-get install linux-image-2.6.35-7-generic
<scar_> ubuntu i368 lucid'
<Sarvatt> you need the newer kernel to actually use nouveau otherwise you are using the fbdev X driver
<scar_> I did aptitude search nvidia, it shows A next to nvidia-96-modaliases, nvidia-common, nvidia-current-modaliases and nvidia-settings
<Sarvatt> oh maybe it got removed on upgrade then, just installing the kernel might fix it
<Sarvatt> no i dont think it did if you're getting the glx missing error, hmm..
<Sarvatt> does purging nvidia-96 do anything?
<Sarvatt> i've got to run, about to pass out here. hope ya can get it going, removing nvidia installing the new kernel and installing libgl1-mesa-dri-gallium should do it though
<scar_> I'm going to try that now, the other option is llvmpipe which i initially wanted to try out, but have no idea how to use/configure it, but yeah first going to remove all this proprietary borked drivers
<Sarvatt> llvmpipe is just swrast
<Sarvatt> if you get nouveau working you dont need it, but you can use it by using LIBGL_ALWAYS_SOFTWARE=1 yourapp 
<scar_> after purging nvidia-96 I've now got 2d and 3d rendering via 2.1 Mesa 7.9-devel (still not nouveau)
 * scar_ rases his hands in the air and screams no more lag when scrolling !!! :D
<Sarvatt> whats the OpenGL renderer string?
<Sarvatt> because that vendor string is the same as nouveau's
<Sarvatt> err version string
<Sarvatt> software rasterizer?
<scar_> yes, Software Rasterizer
<Sarvatt> you installed and rebooted into the new kernel too right?
<scar_> I guess that's clasic mesa
<scar_> I'm using 2.6.32-23-generic-pae
<Sarvatt> ah no nouveau 3D because you are using fbdev and not nouveau
<Sarvatt> nouveau in that ppa requires a 2.6.34 or newer kernel
<Sarvatt> thats why you're using swrast too
<Sarvatt> yeah software rasterizer is classic mesa
<Sarvatt> OpenGL vendor string: VMware, Inc.
<Sarvatt> OpenGL renderer string: Gallium 0.4 on llvmpipe
<Sarvatt> OpenGL version string: 2.1 Mesa 7.9-devel
<Sarvatt> OpenGL shading language version string: 1.20
<Sarvatt> thats what gallium swrast looks like
<scar_> I see, so obtaining the new kernel would you recommend using mavrick or is there a ppa i can use for that too?
<Sarvatt> linux-image-2.6.35-7-generic is in the PPA
<Sarvatt> the maverick kernel
<Sarvatt> its in xorg-edgers just not installed automatically
<scar_> w0w that's quite a change
<scar_> 32 to 35
<Sarvatt> the lucid kernel is a frankenstein of 2.6.32 and 2.6.33 parts :)
<scar_> backports++
<Sarvatt> you can use this PPA if you want automatic updates https://edge.launchpad.net/~kernel-ppa/+archive/ppa
<Sarvatt> when maverick releases that ppa will be directly in lucid too
<scar_> deb http://edge.launchpad.net/~kernel-ppa/+archive/ppa lucid main <- does that look good to you or should I use mavrick?
<Sarvatt> yep thats right
<Sarvatt> i'm not sure what you install for the automatic updates though..
<Sarvatt> linux-image-generic-lts-backport-maverick i think
<Sarvatt> or linux-image-lts-backport-maverick
<scar_> I will try it soon..
<Sarvatt> oh yeah, forgot the copy-fb patch was broken pretty horribly in intel 2.12 :(
<tseliot> how so?
<tseliot> broken as in buggy or as in "doesn't apply any more"
<tseliot> ?
<Sarvatt> needs major refreshing
<tseliot> aah
<Sarvatt> doesn't apply
<tseliot> that's better
 * tseliot -> lunch
<Sarvatt> just merged ati and was going to do intel and remembered that I had a heck of a time trying to refresh it when it broke in git
<Sarvatt> don't suppose I could bug you to sponsor ati 6.13.1 sometime tseliot? :) http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-ati.git;a=shortlog;h=refs/heads/ubuntu          http://sarvatt.com/downloads/merges/ati/ 
<Sarvatt> RAOF: about to submit sync requests for the updates needed for xserver 1.9, any idea if that really is going to be an option? i don't see fglrx updating in time since the abi bump is pretty significant this time around and they *just* introduced their new XA
<Sarvatt> ricotz: some people reporting that your last ia32libs today broke flash?
<ricotz> Sarvatt, lucid or maverick?
<ricotz> mhh, i am using the native 64bit flash plugin
<Sarvatt> they didn't say
<Sarvatt> http://ubuntuforums.org/archive/index.php/t-1476691.html
<jcristau> 'screw fglrx' not an option i guess? :)
<Sarvatt> probably not since theres people paying canonical to make ubuntu work on hardware that only works with fglrx i'm guessing :)
<Sarvatt> but i have no idea
<jcristau> i would have thought those people would use an lts
<jcristau> but maybe not
<Sarvatt> don't suppose you know an easy way to get a list of symbols that changed between abi's in the server by any chance? :)
<Sarvatt> like nvidia fails to load because WindowTable is undefined in 1.9, just want to look over what the blob drivers are using thats gone
<jcristau> a diff on /usr/include/xorg/* would give an idea
<jcristau> or diff of objdump -T Xorg | grep Base, but that won't tell you if prototypes or structures changed
<Sarvatt> http://cgit.freedesktop.org/xorg/xserver/log/include?qt=grep&q=abi looks like its good enough since the commits are obvious, i just wasn't sure if there was an easier way
<jcristau> anyway, uploading 1.9rc4 to experimental now.
<warewolf> morning Sarvatt 
<warewolf> Sarvatt: btw, ty for the help w/ the touchscreen
<warewolf> Sarvatt: the xinput axis stuff you linked me was the final bit I needed, I'm 100% set now
<Sarvatt> sweet, glad to hear it, thats the part i couldn't do remotely :)
<scar_> my computer hangs in 2.6.35-7 even in recovery mode, it looks like it's trying to startx in recovery mode though...
<tseliot> Sarvatt: yes, of course I can sponsor the upload. I'm also using radeon and Maverick on my main machine :-)
<tseliot> as regards fglrx, it will remain broken until they support xserver 1.9. I guess that's acceptable
<tseliot> oh, nvidia would break too though, ouch
<jcristau> meh nvidia is fast at picking up new abis
<tseliot> faster than amd for sure
<tseliot> fast enough? well..
<jcristau> <20100702171226.GA8867@soprano.nvidia.com>
<tseliot> what is it?
<jcristau> a mail
<bjsnider> at one point nvidia released two drivers per year. then in more recent times they were releaseing two per week. now it's more conservative again. puzzling
<tseliot> yes, I picked that up
<jcristau> http://mid.gmane.org/20100702171226.GA8867@soprano.nvidia.com
<jcristau> better? :)
<tseliot> definitely
<jcristau> mid.gmane.org is â¥
<tseliot> :-)
<Sarvatt> jcristau: ack, did you already upload xserver?
<jcristau> Sarvatt: yeah
<Sarvatt> oh ok you added x11proto-xinerama-dev to xserver-xorg-dev, phew
<tseliot> Sarvatt: I assume you tested -radeon
<Sarvatt> I have no machines to test it on but I compile tested it
<tseliot> Sarvatt: ok, let me test the package with my card here, then , if all goes well, I'll upload it
<Sarvatt> https://edge.launchpad.net/~sarvatt/+archive/ppa/+sourcepub/1228102/+listing-archive-extra
<tseliot> ah, good, I won't have to build the package
<tseliot> Sarvatt: also, I think I'll move the nvidia headers back where they used to be and remove the Conflicts with mesa-common-dev
<warewolf> Sarvatt: http://ubuntuforums.org/showpost.php?p=9526140&postcount=5
 * tseliot tries the new radeon
<tseliot> the new radeon driver seems to work well here
<Sarvatt> tseliot: yeah I got a complaint email about that header move
<Sarvatt> silly people thinking they needed nvidia-current-dev for GL headers :)
<tseliot> hehe
<Dr_Jakob> Sarvatt: did you ever manage to get vmwgfx running?
<Sarvatt> Dr_Jakob: without 3D yeah, my vmware trial ran out though :)
<bjsnider> Sarvatt, who was the email from?
<Dr_Jakob> Heh, just use player it should work just as fine.
<Sarvatt> Paulo Dias
<bjsnider> did it have to do with mythtv?
<Dr_Jakob> Sarvatt: I can see if I can't get you a ws key tho.
<Sarvatt> The following packages are BROKEN:
<Sarvatt>   libgl1-mesa-dev 
<Sarvatt> The following packages will be REMOVED:
<Sarvatt>   mesa-common-dev{a} 
<Sarvatt> The following packages will be upgraded:
<Sarvatt>   nvidia-current-dev 
<Sarvatt> noooo I deleted my VM, I thought player didn't work with the gallium stuff!
<tseliot> I'll simply revert my change and everything should be back to normal(ish)
<tseliot> changes
<Dr_Jakob> Sarvatt: :-/
<Dr_Jakob> Sarvatt: so all I need to do is install the xorg edgers and it should work?
<Sarvatt> depends, lucid or maverick host? :)
<Sarvatt> actually that doesn't matter, its the guest i'm thinking of
<Dr_Jakob> lucid guest.
<Sarvatt> if its a lucid guest you need to update the kernel manually, its in the PPA though
<Sarvatt> linux-image-2.6.35-7-generic at the moment
<Dr_Jakob> ok whats that ppa called?
<Sarvatt> and all the normal decrapification of vga16fb and stuff :)
<Sarvatt> https://launchpad.net/~xorg-edgers/+archive/ppa
<Dr_Jakob> kernel ppa?
<Sarvatt> its in xorg-edgers I meant
<Dr_Jakob> ah
<Sarvatt> just have to manually update the kernel
<Dr_Jakob> ah cool
<Sarvatt> oh yeah you need to install libgl1-mesa-dri-gallium as well
<Sarvatt> sorry if it all changes soon, I need to rebase all of my mesa packaging on what actually went into debian one of these days and its called libgl1-mesa-dri-experimental there
<Dr_Jakob> heh
<Sarvatt> i cant use the mesa 7.8 packaging from debian/ubuntu as a base because the egl/gles stuff changed so much in 7.9
<Dr_Jakob> yeah sorry about that, it might change again.
<Dr_Jakob> and there is no ABI rules between libEGL and the drivers so that might explode at anytime as well.
<Dr_Jakob> But that probably isn't so much of a problem for you guyys.
<Sarvatt> yeah it's only really shipped for headers and testing stuff anyway at the moment
<Dr_Jakob> ok
<Dr_Jakob> Sarvatt: do you know Andy from VMware?
<Sarvatt> nope, sure don't
<Dr_Jakob> Ok, nm then.
<Sarvatt> jcristau: do you guys not see weird bugs where the breaks: oldabi on xserver-xorg-core forces drivers not in xserver-xorg-{video,input}-all to be installed on a dist-upgrade in debian?
<Sarvatt> if i dont drop the breaks on the previous abi then xserver-xorg-core always gets held back and it installs stuff it shouldn't like nvidia and radeonhd here every time :(
 * tseliot uploads radeon
<jcristau> Sarvatt: what i've seen is dist-upgrade removing all of X
<Sarvatt> yeah that happens too
<Sarvatt> i think that was when i didnt have input and video all installed
<jcristau> guess why i'm getting rid of the breaks entirely..
<Sarvatt> i can't figure it out though, some voodoo in apt ordering
<Sarvatt> right now on one box i have no packages providing video 6 installed, and i uploaded xserver with the breaks intact, the next dist-upgrade tried to install nvidia-current and radeonhd which had video-6 and that put xserver-xorg-core on hold
<Sarvatt> and if i apt-get upgrade first which removes input/video-all the next dist-upgrade removes all of X
<Sarvatt> i gave up trying to understand whats going on and just started dropping the breaks, driving me bonkers :)
<jcristau> Sarvatt: see the 'Xorg dist upgrade troubles' thread i started on the debian-x and deity lists.  maybe you can follow up there.
<Sarvatt> thanks tseliot!
<tseliot> Sarvatt: thanks to you. Videos seem smoother now here :-)
<Sarvatt> tseliot: did you see that fglrx 10.6 works with xserver 1.8?
<tseliot> Sarvatt: yes, the latest fglrx should do that
<Sarvatt> it just has a problem where BusID *has* to be specified in xorg.conf..
<jcristau> ah i've seen something about that
<Sarvatt> not sure if they fixed that or plan to fix that but it didn't sound hopeful when i was following it
<jcristau> had to laugh.
<tseliot> I wanted to wait for the new release and to apply some changes I've been working on, so as to allow delayed build of the kernel module (the module is built on next boot if the user wishes so)
<Sarvatt> way to make it impossible to package ati! :)
<tseliot> that BusID thing is weird. I doesn't sound new to me though
<jcristau> before there was something about depth
<Sarvatt> that's nvidia, ugh
<tseliot> the defaultdepth problem should affect both fglrx and nvidia
<tseliot> as they don't support 8 bits depth
<tseliot> which is why we set that in xorg.conf through Jockey
<jcristau> these things sound like they would be one liners to fix (not the 8bit thing).  good thing we don't have source.
<Sarvatt> is it? i got nvidia auto loading without an xorg.conf fine outside of that depth being required, it wouldn't be that hard i dont think to make the autoconfig logic just add that section for those two drivers
<bjsnider> jcristau, you do have the kernel module's source
<scar_> thanks for the help earlier
<jcristau> bjsnider: no i don't
<bjsnider> just not the pre-built libs
<Sarvatt> no we dont
<tseliot> Sarvatt: yes, it should be easy to do that
<jcristau> and the kernel module is irrelevant anyway
<Sarvatt> they just have an open source shim interface to the actual kernel module blob
<tseliot> that's the wrapper
<jcristau> Sarvatt: adding hacks in autoconfig to work around trivial bugs in drivers considered harmful
<jcristau> but maybe that's just me
<tseliot> I think we all agree that certain things should be fixed in the driver
<Sarvatt> will all be moot with 1.10 where there's hopefully video xorg.conf.d support :)
<tseliot> however, if you want to get autoloading right with proprietary drivers, it's likely that hacks are needed
<tseliot> yes, that would definitely help
<jcristau> i guess that's why i couldn't care less about binary drivers
<Sarvatt> well the BusID thing is nasty, jockey is going to need to grow some logic to determine that
<Sarvatt> aticonfig --initial sets it up but it has to be run outside of X
<tseliot> Sarvatt: do you have a bug report about that? I'd like to report it to AMD
<Sarvatt> oh they know, its on the amd bug tracker
<Sarvatt> will try to dig it up
<jcristau> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587708
<ubot4> Debian bug 587708 in fglrx-driver "[fglrx-driver] Driver crash after upgrade from 10-5 to 10-6" [Important,Open]
<Sarvatt> one of those 40+ page catalyst 10.6 threads on phoronix has bridgeman saying its intended that its required to run aticonfig after installing the driver always
<jcristau> haha
<Sarvatt> and we should be lucky it worked without it before :)
<jcristau> way to go there.
<tseliot> ouch
<jcristau> or should i say way to make radeon more attractive by the minute
<Sarvatt> http://ati.cchtml.com/buglist.cgi?quicksearch=busid
<jcristau> the debian bug points at http://ati.cchtml.com/show_bug.cgi?id=1848
<ubot4> ati.cchtml.com bug 1848 in X Server "Without BusID fglrx crashes" [Critical,New]
<Sarvatt> oh yeah 10.6 is also broken with nforce chipsets
<Sarvatt> darn i dont see the main busid one on that list, guess i have to dig through phoronix
<Sarvatt> http://ati.cchtml.com/show_bug.cgi?id=1836
<ubot4> ati.cchtml.com bug 1836 in X Server "xserver crash at startup with catalyst 10.6 on openSUSE 11.2/x86_64" [Critical,Resolved: fixed]
<Sarvatt> well theres another but nothing really in it
<tseliot> ok, I've sent them an email, hopefully we'll see what the current status is
<jcristau> resolved as fixed, really?
<Sarvatt> http://sarvatt.com/downloads/xserver.gdb.txt -- thats the backtrace I get without a BusID
<Sarvatt> looked like something i could fix on the server side to work around it but then i sold that box and stopped caring :)
<Sarvatt> bug status Opinion?
<Sarvatt> whee, that bug status closes all of the synaptics bugs just about then :)
<tseliot> Sarvatt: I'll take care of that fglrx bug. I'm not allowed to say more
<Sarvatt> woohoo!
<tseliot> :-)
<warewolf> haah not allowed to say more
<bryceh> :-)
<bryceh> Sarvatt, yeah I think there's quite a few bugs in xserver that could be closed with that
<bryceh> Sarvatt, the status is experimental and might go away in a few months if they find it doesn't do the job it's intended for
<Sarvatt> bryceh: remember the monster intel bug that led us to turn off automatic reporting? :)
<bryceh> heh
<Sarvatt> guess whats back because its not upstream and the patch was dropped?
<bryceh> oh no
<Sarvatt> ya upstreamed one that had an exact same hang dump as the monster one did :D
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/603064
<ubot4> Launchpad bug 603064 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[i965gm] GPU lockup 77c6dfe5 (affects: 1) (heat: 8)" [High,Triaged]
<Sarvatt> i'm guessing g-p-m put his monitor to sleep while watching a movie in totem like what was happening before
<bryceh> mm, yeah good theory
<bryceh> oh hey btw Sarvatt, I got my upstreamer tool posted publically
<Sarvatt> upstreamer tool?
<Sarvatt> ooo!
<bryceh> Sarvatt, http://bryceharrington.org/cgi-bin/send_upstream.cgi
<bryceh> that's the tool I've been using all along to help me upstream bug reports, it's pretty handy.  I've made it so it doesn't require my creds to run, so anyone can use it now
<Sarvatt> do you get to preview before it works its magic?
<bryceh> Sarvatt, I'd appreciate it if you would give it a test on one or two X bugs today or early next week; I'm hoping to get it more public once I've had a few people kick the tires with it
<bryceh> yep, it populates the bugzilla page so you can see what it'll do before committing anything
<Sarvatt> sure thing! cautious about doing it because i dont know what it does :)
<Sarvatt> ahh ok, nice
 * bryceh nods
<bryceh> I'm interested to hear of any parts of it that cause fright, so I can de-fright them :-)
<bryceh> if you like it a lot, I also have a greasemonkey script which will automatically insert a link into bug pages, so it's really easy to launch into
<Sarvatt> bookmarked it and will give it a shot as soon as I get back, gotta run and powerwash a deck now though
 * bryceh waves
<jbarnes> superm1: ping
<superm1> jbarnes, pong
<Sarvatt> scared him away? :)
<Sarvatt> i guess intel-gpu-tools is a good candidate for a get-orig-source rule making a git checkout since its never going to have releases
<bryceh> drive-by jbarnesing
<bryceh> jbarnestorming
<bryceh> Sarvatt, never going to have releases?
<bryceh> that sounds dire
<Sarvatt> well they add new stuff to it all the time and anholt said he had no plans to release :)
<bryceh> O_o
<jcristau> Sarvatt: well you could bump it and call that a release
<Sarvatt> git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools && \
<Sarvatt> 	cd intel-gpu-tools && autoreconf -v --install && \
<Sarvatt> 	REVISION=$(git show --pretty=format:"%h" HEAD | head -n1) && cd .. && \
<Sarvatt> 	PREFIX=intel-gpu-tools_1.0.2+git$(date +%Y%m%d)+$REVISION && \
<Sarvatt> 	tar --exclude=.git --exclude=autom4te.cache -cf - intel-gpu-tools | gzip -9 >$PREFIX.orig.tar.gz && \
<Sarvatt> 	rm -rf intel-gpu-tools
<Sarvatt> ^ that works for now for ppa updates at any rate
<Sarvatt> had to do the same thing for rendercheck packaging since that never has releases either
#ubuntu-x 2010-07-10
<Duke`> latest ia32-libs in xorg-edgers/lucid (july 9th) is broken (adobe flash is broken)
<ricotz> Duke`, can you post the output of "ldd /usr/lib/nspluginwrapper/i386/linux/npviewer.bin"
<Duke`> http://pastebin.com/64zFb5b3
<ricotz> ok, there will be an update soon
<Duke`> what's wrong?
<ricotz> libxcb-shm0 is missing, it is pulled in by some update in edgers lately
<Duke`> ok
<Duke`> also, I see that in the previous version there were libdirectfb-1.2.so.0, libfusion-1.2.so.0, libdirect-1.2.so.0 and libxcb-render-util.so.0 that are no longer listed, and the libxcb-shm.so.0 is new.
<ricotz> Duke`, there were quite some library changes between lucid and maverick
<ricotz> if you spot more missing dependencies feel free to report them here
<Duke`> ok
<coz_> hey guys...has any progress been made for installing official nvidia drivers in ubuntu lucid or maverick?  
<jcristau> way to make sure you don't get an answer.
<Duke`> is it so hard to install nvidia drivers? (real question)
<Sarvatt> bryceh: might want to exclude bugs with sync in the title? :) https://bugs.launchpad.net/bugs/603572 https://bugs.launchpad.net/bugs/603572
<ubot4> Launchpad bug 603572 in x11proto-core (Ubuntu) "Sync x11proto-core 7.0.17-1 (main) from Debian experimental (main) (affects: 1) (heat: 8)" [Wishlist,Incomplete]
<bryceh> Sarvatt, ok
<bryceh> Sarvatt, I do exclude ones with 'Please' in the titles already
<bryceh> usually people write "Please [sync|merge|include]..."
<bryceh> self.regex_subj_workflow  = re.compile('(Please sync|Please merge|debian/control|depends|requires|translation|\.pot)', re.IGNORECASE)
<Sarvatt> oh
<Sarvatt> maybe its a new change in requestsync
<bryceh> I'll change it to self.regex_subj_workflow  = re.compile('(Sync|Merge|Please sync|Please merge|debian/control|depends|requi\
<bryceh> res|translation|\.pot)')
<bryceh> this is process-new-bugs.py in arsenal if you need to tweak its rules in the future
<Sarvatt> i spent a few hours looking for a bug to upstream last night, it's surprisingly hard at the moment :)
<bryceh> it's true, I had a time of it as well
#ubuntu-x 2010-07-11
<BlackZ> bryceh: ping
<jcristau> Sarvatt: you mentioned an issue about libX11 1.3.4 at some point?  i don't remember if it was just the removed symbols, or some other bug?
<Sarvatt> jcristau: i got an email from someone saying they noticed a huge performance hit sometimes (when it doesn't hang completely) without http://cgit.freedesktop.org/xcb/libxcb/commit/?id=b0525e242368fffbc77ebb45293f34e80847e65a only with libx11 1.3.4. he said it goes away downgrading to 1.3.3 or adding that commit to libxcb
<Sarvatt> of course he didn't pass along a bug number or a way to reproduce so he could be full of crap for all I know, I never noticed it
<Sarvatt> but i updated anyway just incase :)
<jcristau> Sarvatt: ok, noted.
#ubuntu-x 2011-07-04
<seif> hey guys
<seif> on my thinkpad x201 
<seif> the touchpad is not working on oneirick
<tjaalton> seif: logfile please
<tjaalton> not that..
<seif> guys
<seif> ?
<tjaalton> 16:22 < tjaalton> seif: logfile please
<seif> tjaalton, how do i get that
<seif> ?
<tjaalton> apt-get install pastebinit; pastebinit /var/log/Xorg.0.log
<tjaalton> and paste the link here
<seif> http://paste.ubuntu.com/637934/
<tjaalton> ok, so how is it "broken"
<seif> the touchpad is not responding
<seif> only the nipple thingie
<seif> :)
<tjaalton> at least the driver loaded just fine
<tjaalton> can you see the touchpad from the output of 'xinput list'?
<seif> yep its there
<seif> â¡ Virtual core pointer                    	id=2	[master pointer  (3)]
<seif> â   â³ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
<seif> â   â³ TPPS/2 IBM TrackPoint                   	id=13	[slave  pointer  (2)]
<seif> â   â³ SynPS/2 Synaptics TouchPad   
<tjaalton> um, it doesn't have an id= ?
<seif> â   â³ SynPS/2 Synaptics TouchPad              	id=11	[slave  pointer  (2)]
<seif> sorry
<seif> :)
<seif> it does
<tjaalton> xinput list-props 11 |grep -i enabled ?
<seif> 	Device Enabled (132):	0
<tjaalton> there you go
<tjaalton> something has disabled it
<seif> :(
<seif> how do i enable it 
<tjaalton> which desktop?
<seif> unity
<tseliot> maybe a gconf key disabled it?
<tjaalton> maybe
<tseliot> launch the "mouse" app and try to enable it from there
<tseliot> you should see a tab about "touchpads"
<seif> i did
<seif> should i restart the session
<seif> ?
<tjaalton> no
<seif> well its not working
<tseliot> can you put the full output of "xinput list-props 11" on pastebin, please?
<tjaalton> xinput set-int-prop 11 "Device Enabled" 1 8
<jcristau> xinput set-prop 11 'Device Enabled' 1
<jcristau> :)
<tjaalton> is the last bit still needed?
<tseliot> right, we have that now
<tjaalton> I'm not sure
<tjaalton> ah, set-prop
<tjaalton> shorter
<jcristau> i wrote that code :)
<seif> invalid format
<tseliot> :)
<tjaalton> seif: try what jcristau gave
<seif> yeah both did not work
<seif> but 
<seif> 8 1 worked
<jcristau> wtf.
<seif> yet still no mouse
<tjaalton> something is actively disabling it then?
<tjaalton> anyway, user config issue :)
<jcristau> seif: and list-props still says it's 0?
<seif> http://pastebin.com/10hwUiJd
<seif> jcristau, ^
<tseliot> it's still 0
<tseliot> it's not supposed to work...
<seif> how can we make it work
<jcristau> turn off whatever's disabling it
<tseliot> and I think we can rule out gnome-settings-daemon if setting values manually doesn't change the value
<seif> seif@Wumbo:~/Projects/gnome-tweak-tool$ xinput set-int-prop 11 "Device Enabled" 1 8
<seif> Invalid format 1
<tseliot> unless you have a crazy daemon which sets things back to 0...
<tseliot> seif: format should be 8
<tseliot> the value should be 1
<tseliot> swap the numbers
<seif> i did
<seif> hmmmmmmm
<seif> something is disabling it
<tseliot> and what did you get with 1 8?
<seif> tseliot, nothing
<tjaalton> apt-get install dconf-tools
<tseliot> seif: try this and see if it still happens: killall gnome-settings-daemon
<tseliot> then use the command again
<tseliot> and see if the touchpad remains enabled
<tjaalton> open dconf-editor, then check /org/gnome/settings-daemon/peripherals/touchpad/touchpad-enabled
<seif> afdasf
<seif> fsa
<seif> f
<seif> a
<seif> ok now its working
<seb128> speaking of trackpad, what could make one not being listed in xinput list?
<seif> it works
<seif> restarted session and it works like charm
<tjaalton> what did you do?
<seif> what you todl me to
<seif> changed it from dconf-editor
<tjaalton> and?
<tjaalton> changed what?
<tjaalton> that setting?
<seif> clicked the enabled thingie
<seif> also i killed the gnome-settings-daemon
<tjaalton> seb128: if no input driver is loaded for it
<seb128> tjaalton, said differently "why is my touchpad not listed there and how do I turn it off" ;-)
<tjaalton> seb128: if xinput list doesn't show it, it means X doesn't know it exists
<tjaalton> so it's "off"
<tjaalton> but maybe you meant to turn it on
<seb128> it's for sure no "off", I keep clicking on it by touching it with my palms
<tjaalton> but then xinput surely has it?
<jcristau> pastebin xinput list and X log?
<seb128> â¡ Virtual core pointer                    	id=2	[master pointer  (3)]
<seb128> â   â³ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
<seb128> â   â³ Logitech Optical USB Mouse              	id=10	[slave  pointer  (2)]
<seb128> â   â³ ImPS/2 ALPS GlidePoint                  	id=14	[slave  pointer  (2)]
<tjaalton> ah, lovely alphs
<tjaalton> alps
<jcristau> seb128: well, it's there...
<seb128> isn't glidepoint the trackpad?
<seb128> I've both a small round bit in the middle of the keyboard and a touchpad
<seb128> I've an USB mouse as well
<tjaalton> aiui there's no "disable while typing" for that, since it's using the evdev driver and not synaptics
<seb128> hum
<tjaalton> seb128: the round thing is trackpoint
<tjaalton> aka the nipple :)
<seb128> that's why it's not in the gnome-control-center tab I guess
<seb128> ok
<seb128> so I've a trackpoint and a touchpad
<tjaalton> yes
<seb128> and I want to turn the touchpad off
<seb128> how do I do that?
<tjaalton> but the trackpoint is not listed and doesn't work?
<seb128> they both work
<tjaalton> ok
<seb128> I want to turn the touchpad off
<tjaalton> just not on the list above, but ok
<seb128> since I don't use it but keep palm clicking it
<tjaalton> xinput set-prop 14 "Device Enabled" 0
<tjaalton> for the running session
<tjaalton> then a config snippet in /etc/X11/xorg.conf.d/ to disable it permanently
<seb128> thanks
<tjaalton> see man xorg.conf, Section "InputClass", and Option "Ignore" "boolean"
<seb128> so the reason why it's not seen as a touchpad in GNOME is because it uses evdev?
<tjaalton> right
<seb128> that will work for me I guess but is not really user friendly :-(
<tjaalton> I don't know if it could be made to work
<tjaalton> actually, I have such a machine here.. but I think it needs kernel work
<tjaalton> or maybe not, should just try it out
<tjaalton> right, the kernel doesn't list alps as a touchpad, just as a ps/2 mouse
<tjaalton> and forcing synaptics doesn't work
#ubuntu-x 2011-07-05
<tjaalton> argh, soft-freeze.. must get packages in today
<tjaalton> btw, no tfp in swrastg_dri even in 7.11, which seems weird
<RAOF> Yeah, I noticed that when something was broken in intel.
<tjaalton> uploading libdrm
<tjaalton> meh, synaptics merge.. halfway done
<tjaalton> noticed that a couple of revisions from early natty are not in
<tjaalton> fully anyway
<tjaalton> will fix in a bit
<tjaalton> RAOF: still around? I'd like to push the xserver for alpha2..
<tjaalton> just bugfixes anyway, and running fine here since last week
<tjaalton> synaptics and xserver uploaded
<tjaalton> bryceh: are you planning on upstreaming the patch from bug 327428?
<ubot4> Launchpad bug 327428 in xserver-xorg-input-synaptics (Ubuntu) "mouse pointer no longer has 1 pixel precision (affects: 5) (heat: 24)" [Low,Fix released] https://launchpad.net/bugs/327428
<hyperair> is there a workaround for a quivering synaptics touchpad? =\
<hyperair> when my finger touches the touchpad, the cursor quivers
<hyperair> like it keeps moving a few pixels around the same spot
<apw> is there a simple way to configure a specific monitor to be configured non-standard ... i have a kvm which is saying a very low resolution compared to the actual monitor
<bryceh> apw, right, that's where if we could have a loadable EDID, that'd be the best way to fix it
<bryceh> apw, for now you can provide custom modelines via xrandr.
<RAOF> Woah.  Does mesa not have an apport hook?
<bryceh> RAOF, yes, although not for every binary package
<bryceh> why?
<RAOF> bug #804655 looks like it's been reported with apport, but doesn't contain useful information.
<ubot4> Launchpad bug 804655 in mesa (Ubuntu) "r300 loading instead of r300g (affects: 3) (heat: 16)" [Undecided,Incomplete] https://launchpad.net/bugs/804655
<bryceh> hmm, 'ubuntu-bug mesa' gives me a 'Package mesa does not exist' error
<bryceh> ubuntu-bug libgl1-mesa-dri worked
<RAOF> Hm.  That's odd.  ubuntu-bug libgl1-mesa-dri looks like it should attach a I wnt, but thta bug doesn't have it.
<bryceh> nothing illustrative from the activity history
<bryceh> I've seen bugs filed against unity and reassigned to mesa that lack anything of use, but that doesn't seem to be the case here
<bryceh> hmm, usually if it files bugs like this with no info except dependencies, it means the apport hook is busted
<RAOF> Right.  It looks like the user ran âubuntu-bug libgl1-mesa-driâ and got a useless report.
<Sarvatt> r300g isnt working because KMS is disabled by default on powerpc
<RAOF> Sarvatt: But that bug has Architecture: i386
<Sarvatt> oh weird saw someone mention the same bug on powerpc earlier in IRC
<Sarvatt> sorry
#ubuntu-x 2011-07-06
<bryceh> tjaalton, pst push xserver to git
<tjaalton> bryceh: can't, need to rebase first.. and please don't push such changelog entries if you know I might have the commit :/
<tjaalton> but, sorry for not pushing it anyway! :)
<tjaalton> it was an easy merge anyway, pushed now
<tjaalton> bryceh: sorry, let me try another entrÃ© _after_ the breakfast..
<bryceh> something's up with vmware - 805777 and 798830.  needs rebuild?
<tjaalton> abi hasn't changed, probably just unity fail
<tjaalton> note that if it's using lightdm, it doesn't actually restart the xserver
<RAOF> Hm.  It sounds not totally unlike Robert's ânothing draws after I log out on radeonâ bug that I'm trying to reproduce once the box finally finishes updating.
<tjaalton> i should have vmware workstation licenses somewhere..
<bryceh> I'm seriously weirded out at how few -intel bug reports there are against oneiric right now
<bryceh> the apport hook has to be  broken or something
<tjaalton> 3.0 is working ok, it seems.. after the catastrophic .38 that is :)
<bryceh> yeah most reports being filed against xorg are ending up being bugs in something else
<tjaalton> "unable to initialize module building library", so much for trying out vmware workstation
<tjaalton> probably multiarch related
<_asdf_> someone there?
<_asdf_> i installed the driver but i think im kinda not useing it :S
<Sarvatt> RAOF: so wait, we dont ship pipe_*.so in libegl1-mesa-drivers anymore?
<Sarvatt> also started getting a new build failure in the past few days with 7.12, do we want to ship these files? http://paste.ubuntu.com/638909/
<Sarvatt> so is adding foreign-architecture i386, doing a apt-get update and installing wine:i386 supposed to be the way to go now for amd64?
<Sarvatt> err adding that to /etc/dpkg/dpkg.conf
<Prf_Jakob> I know its kinda of a long shot to ask here, but does anybody know how to make dkms packages that also installs a udev rule?
<Sarvatt> Prf_Jakob: it totally depends on how the packaging is done, for most things these days just throwing packagename.udev in debian/ is enough and you can add an override_dh_installudev line in debian/rules to adjust the priority it installs to if need be. man dh_installudev might help or looking at another package doing the same thing (virtualbox maybe?)
<Prf_Jakob> Sarvatt: thanks!
<RAOF> Sarvatt: Correct.  We don't ship pipe_*.so in libegl1-mesa-drivers because they're not built :).  egl_gallium now contains *everything*
<Sarvatt> RAOF: well now gbm ships them :P
<RAOF>  /o\
<Sarvatt> had to add a echo "dri/usr/lib/${DEB_HOST_MULTIARCH}/gbm/*.so usr/lib/${DEB_HOST_MULTIARCH}/gbm" >> debian/libgbm1.install.in hook to the edgers packaging
<RAOF> Have you enabled gbm's gallium support?
<Sarvatt> i'm using origin/ubuntu packaging at the moment, trying not to have to maintain a packaging fork this time around
<Sarvatt> i'll give it 2 more weeks before it's changed enough that I have to at this rate :P
<Sarvatt> the build system has changed in fun new ways breaking the packaging at least once a week every week since UDS, been a pain in the butt :)
<RAOF> Fiddling 'round with configure flags is *much* more fun than trying to automake/autoconf the buildsystem :/
<Sarvatt> RAOF: oh http://cgit.freedesktop.org/mesa/mesa/commit/?id=b18b2994eff2f51588abe29c7a2209220c9ee9c5
<Sarvatt> guess disabling gallium would have been the better option
<Sarvatt> coming soon to a 7.11 near you :)
<RAOF> Heh.
<Sarvatt> thank you so much for working on the 7.11 packaging, massive amounts of changes in the span of 2 weeks right before branching made me not want to even look at it. fix it, broken next day, repeat
<Sarvatt> Physical id 0: +98.0Â°C  (high = +86.0Â°C, crit = +100.0Â°C)  
<RAOF> Mmmm, sweet!
<Sarvatt> shoving a 45w quad in a chassis designed for 35w dual cores makes for some sketchy mesa building :)
<RAOF> Although my 7.11 packaging has included a bunch of crazy mistakes :(
<Sarvatt> you saying i should look at the contents of the debs and not just blindly accept its right because it builds? :P
<RAOF> NO!  I didn't mean to git clean -xdf!  My beautiful build objects!
<RAOF> Ok, new plan.
<RAOF> Scrounge a power cable from the netbook, and use the shiny dell.
<Sarvatt> oh right I gave you a US lead, whoops
<bryceh> RAOF, one day I'll swap you that US lead for an aussie one
<RAOF> Ta :)
<RAOF> The US lead wouldn't be such an issue if it didn't have a ground pin.  My universal connector doesn't do grounding :)
<Sarvatt> RAOF: bend it off? :P
<Prf_Jakob> Sarvatt: still around?
<RAOF> Hm, ok.  The dell seems a little hardlock happy.
<Sarvatt> Prf_Jakob: kinda, it's well past beer o'clock so you'll have to forgive me if I'm not too helpful :)
<Sarvatt> RAOF: http://kernel.ubuntu.com/~sarvatt/lp761065/
<Sarvatt> RAOF: absolutely essential on sandybridge :(
<RAOF> That's in the oneiric kernel, right?
<Sarvatt> there's a natty one in there
<Sarvatt> its the 2 patches that are desperately needed
<Sarvatt> they'll be in 2.6.38-11
<Sarvatt> http://kernel.ubuntu.com/~sarvatt/lp761065/natty/
<RAOF> Well, I upgraded to oneiric at the sprint.
<Sarvatt> oh crash happy on the oneiric kernel?!
<RAOF> Yeah.  On whatever kernel I happen to be running.
<Sarvatt> you must be looking at desktop crashy, i'm using the same machine
<Sarvatt> (and haven't upgraded in a week and half)
<Sarvatt> btw if you swap a SSD in you'll probably need to pin natty's udev, oneiric udev doesn't work on this machine for me
<Sarvatt> something tells me it would if i was using a slow hdd
<Prf_Jakob> Sarvatt: okay, are you up for some noob packaging questions?
<Prf_Jakob> debian packaging*
<RAOF> Always :)
<Prf_Jakob> if not I'll go and bother somebody else.
<Sarvatt> of course, whats up? I'm a noob packager myself but other people might be able to help if I can't :)
<Prf_Jakob> Cool, well I just created a vmwgfx package with dkms mkdeb which was suprisingly painless, but I need to get a udev rule in there.
<Prf_Jakob> (udev rule is because the drm rules doesn't work for the standalone vmwgfx driver).
<Prf_Jakob> (which includes drm & ttm in some sort of unholy combination).
<Sarvatt> did you dkms-ify drm too?
<Sarvatt> oh that's going to be fun
<Sarvatt> we tried that for nouveau in lucid, had to patch udev and plymouth too
<Prf_Jakob> it just builds it into one binary so it works okay.
<Prf_Jakob> Oooh, hmm plymouth might be a problem, if its not running ontop of fbdev.
<Prf_Jakob> except for the udev rules
#ubuntu-x 2011-07-07
<Prf_Jakob> So the basic noob question is how do I edit the package? Or can I magically make the dkms tool add it for me?
<RAOF> Why don't you add the udev rule in the package which installs the dkms source?
<Prf_Jakob> Yeah that was my plan, but I do know how to edit the .deb file?
<Prf_Jakob> do not know*
<RAOF> Why would you want to edit the .deb file?  Which .deb file?
<Prf_Jakob> Right noob
<Sarvatt> the packaging is all contained in the debian/ directory and you want to edit stuff there to alter how the package is built, debian/rules is what builds the package from source and if you want to add a udev rule that you have already you should be able to just add it as debian/vmwgfx.udev (replacing vmwgfx with whatever your source package name is)
<Prf_Jakob> okay
<Prf_Jakob> right the problem is that I used dkms to generate the package for me, it did all the debian magic.
<Sarvatt> nice, i've never even heard of dkms mkdeb before
<Sarvatt> it generated a source package for you?
<Prf_Jakob> yeah
<Sarvatt> you should be able to dpkg-source -x foo.dsc to extract it
<Prf_Jakob> I don't have a *.dsc file, only a .deb
<Sarvatt> ah looks like you need mkdsc instead of mkdeb to make a source package that you can go in and edit after
<Prf_Jakob> Ah..
<Prf_Jakob> Sarvatt: okay edited
<Sarvatt> you'll probably need to name it foo-dkms.udev since it looks like it defaults to that package name
<Sarvatt> debian/foo-dkms.udev rather
<Sarvatt> after you edit the packaging you want to debuild -S -sa to make a new source package to do something with, or debuild -uc -us -b to make a .deb again (not sure what you're doing with it)
<Prf_Jakob> oh yay a mail server!
<Sarvatt> sudo apt-get purge postfix bsd-mailx :P
<Sarvatt> hate that devscripts pulls that crap in
<Sarvatt> or sudo apt-get --no-install-recommends install devscripts
<Prf_Jakob> hmm okay..
<Prf_Jakob> so I made a package, but I can't install it because it says I already have the package installed.
<Prf_Jakob> But I purged it before
<Prf_Jakob> After it fails I can purge it again.
<Prf_Jakob> Ah there we go
<Sarvatt> sudo apt-get purge foo fails to remove it? sudo dpkg -i foo.deb fails to install it? can you share the source package? I'd be more than happy to take a look at it and see whats going on and help clean it up some
<Prf_Jakob> It didn't remove the /var/lib/dkms/vmwgfx/1.4.1 directory because it forgot about the dsc directory in there
<Prf_Jakob> ah I probably need to add a dh_installudev to debian/rules as well?
<RAOF> Depending on what sort of rules file dkms generates, yes.
<Prf_Jakob> not one containing dh_installudev :)
<RAOF> If it uses the âdhâ tool then you wouldn't need it, but it's probably not that new :)
<Sarvatt> RAOF: where would the dh_installudev go in /etc/dkms/template-dkms-mkdsc/debian/rules? just before dh_link in binari-indep?
<RAOF> I'd put it next to the dh_install call, which I presume is in there somewhere.
<Prf_Jakob> I only see dh_installdeb and dh_installdirs
<Prf_Jakob> /lib/udev/rules.d/40-vmwgfx-dkms.rules
<Prf_Jakob> \o/
<RAOF> Woot!
<Prf_Jakob> I added dh_installudev under the install target in rules
<RAOF> Yeah, that'd fly :)
<Prf_Jakob> do how do you guys manage packages like this?
<Prf_Jakob> do you do a git-init in the package dir and just "git add debian && git commit" and thats it?
<RAOF> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
<RAOF> Generally something like that.
<Prf_Jakob> errr
<RAOF> That's the full toolchain thingy.  git add debian && git commit is what often happens on a day to day level :)
<Prf_Jakob> ok
<Sarvatt> if you git init in debian/ you need to pass -i -I to debuild when you build packages so the .git crap doesn't end up in the package
<Sarvatt> or just add DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I" to ~/.devscripts
<Sarvatt> (sorry popped out there, glad it worked!)
<Sarvatt> there's no right way to do it, just whatever you prefer
<Sarvatt> causes lots of headaches adopting other peoples workflows to update packages, thats for sure :)
<Prf_Jakob> I'm just glad I have a package that I can use
<Prf_Jakob> So where do specify the package version?
<Prf_Jakob> debian/rules?
<RAOF> debian/changelog
<RAOF> The version of the most recent changelog entry is the version of the package.
<Prf_Jakob> ah
<RAOF> (dch is a useful tool for manipulating the changelog; I use emacs' debian-changelog mode for my stuff, though)
<Prf_Jakob> hmm okay
<Prf_Jakob> dch uses envar EDITOR?
<RAOF> Yes.
<Prf_Jakob> Yes it does
<Sarvatt> yeah dch -i to make a new changelog entry and automatically bump the package version (although it almost always does it wrong)
<Prf_Jakob> hehe so I noticed
<Sarvatt> Prf_Jakob: there's probably a 50 page document somewhere on the debian policy regarding the version string, but basically x.y.z is the upstream version, the part after - is the debian revision of the package, and if that debian version is modified in ubuntu it gets a ubuntuX version added
<Prf_Jakob> And if its vmw?
<Prf_Jakob> VMware*
<Prf_Jakob> do I add vmwX?
<Prf_Jakob> I just went with rX
<Prf_Jakob> for some reason
<RAOF> Sarvatt: It's actually not very complicated :P http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
<Sarvatt> RAOF: that totally omits things like x.y.z-2 being higher than x.y.z-2~vmw1 though, hmm
<Sarvatt> oh no it doesnt
<RAOF> Prf_Jakob: If you're not expecting to distribute it, or if it's not going to conflict with a package name in the Ubuntu archives then the only real constraint on versioning is that you want it to be strictly monotone increasing, and the tools will raise warnings if you have a native package (one without a -$SOMETHING component).
<Prf_Jakob> RAOF: down the line I would like to make a ppa for it, now its just a internall thing.
<RAOF> Sarvatt: It doesn't say it in so many words, but it *does* say that â~â sorts before everything, including the empty string.
<RAOF> Prf_Jakob: Then you can go nuts with whatever versioning scheme you want :)
<tjaalton> Sarvatt: and having 'DEBCHANGE_RELEASE_HEURISTIC="changelog"' in .devscripts makes dch a bit better when handling dvcs repos
<tjaalton> no need to use -i
<tjaalton> RAOF: do you know if *DM has been updated to the new '-background none' so patch 209 could be dropped from the server?
<RAOF> tjaalton: No, they haven't.
<tjaalton> is there a bug about it?
<RAOF> I'm not sure.
<tjaalton> ok
<RAOF> Looking.
<tjaalton> i'm bisecting our patches to see which one causes wacom button clicks to move the cursor around
<tjaalton> not happening on upstream code
<tjaalton> so I came across that one
<tjaalton> sure it doesn't cause it :)
<tjaalton> at least gdm hasn't changed
<RAOF> :)
<tjaalton> ubuntu_plymouth.patch still uses -nr
<RAOF> tjaalton: Now filed as bug #806857
<ubot4> Launchpad bug 806857 in lightdm (Ubuntu) (and 1 other project) "Plymouth integration should use upstream â-background noneâ option (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/806857
<tjaalton> RAOF: thanks
<tjaalton> I think kdm is not using -nr anymore
<tjaalton> ScottK: can you verify ^
<tjaalton> the changelog of kdebase-workspace is confusing, it's talking about 07_kdmrc_defaults_kubuntu.diff, but there is no such patch but kdmrc_defaults.diff which is commented out :)
<tjaalton> and I guess lightdm hasn't used -nr
<tjaalton> ok, disabling patches 200-> fixed the cursor jumping, but only a fraction of the tablet surface was usable. bisecting some more
<tjaalton> yep, it's the multitouch patches that cause the cursor jumping
<RAOF> Hurray! :/
<RAOF> mikey_: So, what's broken? :)
<mikey_> Well, I was hoping to sort out a strategy to do a second session in X that plays nice with ubuntu, at the moment it's a bit of a hack based on my outsider readings on X.
<RAOF> mikey_: As in: run a second X server?
<RAOF> And then the game in that second server?
<mikey_> So basically all I do is utilise xinit to start a second X session along side the first and open openbox (I just chose this as something lightweight that didn't use Compiz) 
<mikey_> And then it waits and opens a game on that
<mikey_> It's pretty simple but avoids a lot of the problems you get with compiz
<mikey_> There (just acording to poles of people using this strategy) is a slight performance boost over running it in one session
<mikey_> Also the game is slightly sandboxed so any major crashes don't effect the first x session
<RAOF> Right.
<mikey_> The problem is that it has become increasingly opaque in ubuntu how to deal with the security and x session management features.
<mikey_> So at the moment a commmand I use looks something like this:
<mikey_> xinit '/tmp/tmp-xinitrc'  -- :1
<mikey_> Where the tmp-xinitrc  has a session command like:
<mikey_> exec ck-launch-session openbox-session
<RAOF> Ah, right, yes.  ConsoleKit.
<mikey_> I had to introduce that to deal with sound problems. 
<mikey_> Now there's issues about whether a user level application can start a session at all 
<jcristau> i wouldn't expect xinit from an existing X session to work, as a regular user?
<mikey_> I can get arround it by getting people to turn on user level x session management but I don't know if that is a security risk
<RAOF> I presumed there's an implicit sudo in there :)
<mikey_> No
<mikey_> Sorry I was typing as you were. Hope that explains where I am
<RAOF> I think ck-launch-session is going to stop working properly, isn't it?  consolekit is starting to require the sessions be set up with all the trimmings - vt, display number, etc.
<mikey_> Also there's a problem that when I exit openbox now something takes down the first x session as well
<RAOF> What is âuser level x session managementâ in this context?
<mikey_> Sorry, you can tell X that users can start and stop sessions without sudo
<mikey_> I'm just looking for the change now, as I can rememebr exactly which file you cange
<RAOF> Right.  /usr/bin/X is setuid, and from memory the wrapper has some authorisation hooks.
<mikey_> sudo dpkg-reconfigure x11-common
<mikey_> and choose "anyone" to enable X privileges
<RAOF> mikey_: I'm not entirely sure what you're looking to achieve.  We're not deliberately breaking this sort of thing, but its also not something that we (or many upstreams) particularly think of either.
<mikey_> I was hoping to knock out a strategy that was more in keeping with the way that these things were intended to work. Since there is an issue with gaming on ubuntu. 
<RAOF> The way that this *should* be fixed is by fixing whatever's wrong with compiz, basically.
<mikey_> I've asked the compiz people a couple of years ago if they intended to make some workaround for games but nothing has been forthcoming.
<RAOF> What is the actual problem?
<mikey_> They said they were.
<mikey_> Many games, particularly using Wine. Crash when run under Compiz or don't work at all
<RAOF> Can you give some examples?  I've not run into any of these problems, but I haven't got a particularly extensive gaming library.
<mikey_> Well, I've not tried many games under compiz for a while as I've been using my approach
<mikey_> But I just started up the first game that came to mind Oblivion using wine
<mikey_> and while it ran the fullscreen did not cover the unity pannel
<RAOF> Ah, fullscreen.
<RAOF> The state that X forgot.
<RAOF> So, *that* is just a window management bug in compiz.
<RAOF> And sometimes the way to have things fixed is to fix them.  There's not a huge difference in difficulty between fiddling around with running extra X sessions and fixing bugs in compiz.
<mikey_> Same issue on other wine games (just checked) so a wine compiz issue. 
<mikey_> In the past there've been issues where wine games were in fact transparent.
<RAOF> And that was almost certainly a wine bug :)
<mikey_> No compiz
<mikey_> Well... compiz and maybe wine was misslabeling 
<RAOF> Probably would have happened with another compositor too; wine was probably filling its windows with a transparent colour and not noticing because that only takes effect under a compositor.
<mikey_> I think actually it was thinking the window was a menu
<mikey_> as I had transparent menus at the time
<RAOF> Possible, if you set up compiz to make menus transparent.
<mikey_> But like I say, things may have change a lot over the last couple of years since I used wine games under compiz but increased crashes also were an issue. 
<mikey_> The second session made that kind of problem no problem at all.
<RAOF> Yeah, but it's not a particularly wonderful solution.  Specifically, it's not something that we'll do by default.
<mikey_> OK.
<mikey_> Can you give me any pointers to coping with session management if I continue to try to run an app that does this?
<mikey_> So would you recommend not enabling user level session management on security grounds? 
<RAOF> No, not particularly.
<mikey_> Do you know what it is that is killing the first x session when I exit the second?
<mikey_> I guess GDM
<RAOF> I wouldn't think so, but it's possible I guess.
<RAOF> You're not starting an X server that gdm knows about.
<RAOF> It *might* be consolekit playing around on you.
<mikey_> How is a session started properly under Ubuntu at the moment? (Or where can I read about it?)
<RAOF> As I said, I think you're going to need to use something more clever than ck-launch-session soon
<RAOF> mikey_: X servers are started by the display manager, as are login sessions; check the lightdm source for details, pretty much.
<mikey_> Can I interact with the display manager to request a new session or do I need to reimplement what it's doing?
<RAOF> You possibly could?  It'd be moderately involved, I think.
<mikey_> OK. Thank you for your help
<Sarvatt> RAOF: doh, thats a nasty mesa bug to have on the alpha 2 image
<ScottK> tjaalton: I can't find any evidence of a plymouth related -nr and I do see a background being set in kubuntu_63_ksplash_fix.diff, but I'm not sure if that's the same background setting or not.
<ScottK> So I think it's OK, but not sure.
<tjaalton> ScottK: yeah, good
<hyperair> Sarvatt: does sna in xorg-edgers somehow cause dri2 to stop working?
<ricotz> Sarvatt, hello
<ricotz> is it normal that the nvidia blob get broken a lot these days? or is my system messed up? rebuild the blob package solved the problem lately
<Sarvatt> hyperair: nope shouldn't be related, if anything I might have messed up one of the packages for natty? can ya pastebin your Xorg.0.log?
<hyperair> Sarvatt: Xorg.0.log shows dri2 present.
<Sarvatt> ricotz: oneiric nvidia in the archive? I have no clue, still have yet to try it after the multiarch stuff but i've got an alpha 2 image downloading now
<hyperair> Sarvatt: glxgears on the other hand... seems to not get redirected.
<hyperair> Sarvatt: so when i move the glxgears window around, it gets left behind just like pre-dri2 times
<hyperair> and when i activate some compiz animation it gets left behind as well
<Sarvatt> hyperair: LIBGL_DEBUG=verbose glxinfo output please
<Sarvatt> hyperair: hrm that got fixed recently
<hyperair> eh?
<hyperair> http://paste.debian.net/122245/
<hyperair> also, wine seems to have artifacts with snb things.
<Sarvatt> the glxgears sticking around until you stop moving the window got fixed recently
<hyperair> i see
<Sarvatt> hyperair: amd64 right
<hyperair> yeah
<Sarvatt> hyperair: you need to install the 32 bit mesa libs for it to work
<hyperair> hmm
<hyperair> does mesa support multiarch yet?
<hyperair> in xorg-edgers?
<Sarvatt> edgers and oneiric yeah
<hyperair> oo nice.
<Sarvatt> natty and oneiric in edgers
<ricotz> ricotz, yes, the oneiric package, the glx module cant be loaded
<ricotz> Sarvatt, Â°
<ricotz> ^
<ricotz> oops
<hyperair> Sarvatt: do i need to get rid of ia32-libs?
<Sarvatt> hyperair: nope it shouldn't even look for things where that gets installed anymore
<hyperair> okay.
<Sarvatt> hyperair: add uhh
<Sarvatt> foreign-architecture i386 to /etc/dpkg/dpkg.conf
<hyperair> something foreign..
<hyperair> aha
<hyperair> okay
<hyperair> and apt?
<Sarvatt> then sudo apt-get update and sudo apt-get install libgl1-mesa-dri:i386
<Sarvatt> hopefully it'll pull everything it needs in
<hyperair> okay
<hyperair> let's see..
<hyperair> aptitude update doesn't seem to be pulling in i386 things
<hyperair> i think some apt option is also needed.
<jcristau> Sarvatt: err, why is that needed for glxgears/compiz?
<Sarvatt> ricotz: to be honest i haven't even looked at multiarch on the blobs yet and am not sure whats going on, got an image downloading to install on my nvidia box right now
<Sarvatt> it isn't, was for wine
<jcristau> ah.
<hyperair> Sarvatt: Apt::Architectures
<jcristau> i knew i was missing something :)
<Sarvatt> he's using software rendering and getting artifacts, but i'm sure he wants to be using hardware acceleration so needs the 32 bit stuff :P
<jcristau> ack
<ricotz> Sarvatt, ok :)
<Sarvatt> glxinfo looks fine there hyperair, the glxgears problem you mentioned was fixed last week sometime though, have you not restarted X in a week?
<hyperair> Sarvatt: nah, my laptop just locked up and i've restarted
<hyperair> stupid mode switching
<Sarvatt> hyperair: ugh you said natty right?
<hyperair> yea natty
<Sarvatt> hyperair: hopefully it wasn't a compiz update in oneiric that fixed it then..
<hyperair> ._.
<hyperair> hmmmmmmmmmmmmmmmm
<hyperair> lemme poke smspillaz.
<hyperair> oh wait he's in the same timezone as me. probably asleepn ow
<Sarvatt> i dont know what fixed it, mentioned it to ickle and went off to dublin and it was fixed sometime last week in the updates
<hyperair> hmm
<hyperair> i see.
<Sarvatt> err maybe it was http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=b460b9645451af84136c5daebbc00c7545de67f4
<Sarvatt> whats your x-x-v-intel version
<Sarvatt> 2:2.15.0+git20110706.0be47f45-0ubuntu0sarvatt here
<Sarvatt> i'd put money on it being an old xserver-xorg-video-intel, that problem started with http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=c3b1a0d7046a83b6daec03e5a562116e3adf3c71
<hyperair> *** 2:2.15.0+git20110706.0be47f45-0ubuntu0sarvatt~natty 0
<hyperair> Sarvatt: ^^
<hyperair> Sarvatt: urgh, multiarch on natty seems pretty broken.
<Sarvatt> hyperair: I feared as much :( you're the first person i've spoken to that's tried it, guess i'll  be dropping multiarch and forking the packaging for crap to keep natty up to date in the end..
<hyperair> heh
<Sarvatt> ricotz: so what are you doing when it dies? you said it happened when you upgraded stuff?
<Sarvatt> looks like its working ok here
<Sarvatt> ricotz: nevermind reproduced it, filing a bug
<ricotz> Sarvatt, what is the problem?
<bjsnider> ricotz, howcome not many gnome3 updates for natty recently?
<Sarvatt> ricotz: not sure yet, this is a mess
<Sarvatt> http://bugs.launchpad.net/bugs/807209
<ubot4> Launchpad bug 807209 in nvidia-graphics-drivers (Ubuntu) "Lost glx after first upgrade from oneirc alpha 2 install (affects: 1) (heat: 6)" [Undecided,New]
<ricotz> Sarvatt, alright, i will follow it, i suspected binutils (pulled from thin air ;))
<ricotz> bjsnider, hmm, it isnt planned to update it to 3.1.x -- it would need a whole lot of unstable updates
<Sarvatt> Setting up libgl1-mesa-glx (7.11~1-0ubuntu3) ...
<Sarvatt> update-alternatives: renaming x86_64-linux-gnu_xorg_extra_modules slave link from /usr/lib/xorg/extra-modules to /usr/lib/x86_64-linux-gnu/xorg/extra-modules.
<Sarvatt> hrm
<Sarvatt> xserver is still trying to load from /usr/lib/xorg/extra-modules first
<ricotz> bjsnider, and might break a lot other things after G_CONST_RETURN and new gtk+3 deprecations
<ricotz> Sarvatt, hmm, it could have happen on mesa updates
<ricotz> brb
<Sarvatt> yeah that makes sense
<Sarvatt> [     8.172] (==) ModulePath set to "/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules"
<Sarvatt> whats up with apport being useless btw
<Sarvatt> bryceh: ?
<bryceh> Sarvatt, ?
<Sarvatt> didn't attach anything to that bug i just filed
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/807209
<ubot4> Launchpad bug 807209 in nvidia-graphics-drivers (Ubuntu) "Lost glx after first upgrade from oneirc alpha 2 install (affects: 1) (heat: 6)" [High,New]
<bryceh> ah, nvidia
<bjsnider> Sarvatt, so then if you reinstall nvidia-current the problem should be fixed, if it's only broken alternatives
<bryceh> Sarvatt, were there any error messages printed to console?
<Sarvatt> darn i've already rebooted since then but i dont believe so
<bryceh> Sarvatt, do you have xdiagnose installed?
<Sarvatt> it was a clean install, not sure, let me hook it back up
<bryceh> Sarvatt, try filing a bug against xorg or xserver-xorg-video-intel and see if that works properly
<bryceh> Sarvatt, aside from the move from xorg to xdiagnose I haven't uploaded any changes to the apport hooks
<bryceh> they've been working ok in my tests but some of the changes could easily break things in specific cases (i.d. proprietary drivers)
<Sarvatt> bryceh: yep no xdiagnose on an alpha 2 install
<bryceh> ok, so that's probably what the problem is
<bryceh> maybe xorg needs to depend on xdiagnose more forcefully?
<bryceh> tjaalton, ^^?
<Sarvatt> xserver-xorg should depend on it no?
<Sarvatt> oh xorg instead
<Sarvatt> thats what ubuntu-desktop depends on, and that pulls in x11-common, which has a recommends for xdiagnose that isn't getting pulled in
<bryceh> yeah
<bryceh> why would it not pull in an x11-common recommend?
<Sarvatt> only pulls in recommends of things it depends on directly maybe?
<bryceh> maybe slangasek would know
<bryceh> Sarvatt, anyway, meanwhile, can you manually install xdiagnose and confirm then that bugs are reported correctly?
<Sarvatt> bryceh: xorg depends on xfonts-scalable and that isn't pulled in either so i guess it should just be moved to depends
<Sarvatt> sure one sec i'll file a new one
<bryceh> I'm going to upload a new xdiagnose 0.7 probably early next week, with some semi-substantial changes
<Sarvatt> bryceh: yep it works, updated that bug
<Sarvatt> btw its in universe still
<bryceh> ??
<Sarvatt> it downloaded xdiagnose from universe
<bryceh> maybe that's why it didn't get pulled in?
<Sarvatt> .proc.driver.nvidia.gpus.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/0'
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/807209 apport info on that
<ubot4> Launchpad bug 807209 in nvidia-graphics-drivers (Ubuntu) "Lost glx after first upgrade from oneirc alpha 2 install (affects: 1) (heat: 8)" [High,New]
<Sarvatt> cursor theme in use? that might be a bit too much info :)
<bryceh> Jun 18 00:04:26 <bryce> tjaalton, btw on upgrading to latest I notice xorg didn't pull in xdiagnose; does it need stro\
<bryceh> nger than Recommends?
<bryceh> Jun 18 00:05:36 <tjaalton>      bryce: it is, and it got installed here though
<bryceh> Jun 18 00:05:44 <bryce> hmm
<bryceh> Jun 18 00:05:53 <tjaalton>      recommends should be enough
<bryceh> Jun 18 00:06:35 <tjaalton>      if your apt is configured to install recommended packages (which is on by default sinc\
<bryceh> e a couple of years)
<Sarvatt> maybe the installer uses different defaults
<bryceh> Jun 18 00:07:09 <bryce> total defaults on this system, fresh install as of 2 days ago
<bryceh> Jun 18 00:07:15 <tjaalton>      ok
<bryceh> Jun 18 00:07:29 <tjaalton>      I'll check my logs
<bryceh> Jun 18 00:08:15 <tjaalton>      ah I had it installed already
<bryceh> but we didn't look into it  beyond that :-/
<Sarvatt> bryceh: cool beans, just sucks we're going to get a bunch of alpha 2 bugs with no apport info :P
<bryceh> maybe
<bryceh> this might explain why we've got relatively few gpu hang bugs on -intel
<Sarvatt> for sure
<bryceh> not a big deal; we'll get plenty more soon
<cnd> bryceh, RAOF: every time I try lightdm it fails to work for me
<cnd> mouse and kb don't work
<cnd> I found out today that the X server doesn't have any input devices
<cnd> it does under gdm though
<Sarvatt> cnd: i had to pin udev to the natty version on one of my machines to get around that.. :(
<bryceh> cnd, hmm worked for me when I poked at it last week
<cnd> Sarvatt, interesting...
<cnd> Sarvatt, I'll try that out
<Sarvatt> cnd: got an ssd in that machine?
<cnd> Sarvatt, no
<bryceh> there have been some bug reports about with lightdm, it'll make X SIGQUIT when you first hit a '2' or enter
<Sarvatt> ok that was my running guess, booting too fast since it doesn't happen on a second identical e6420 minus the SSD
<Sarvatt> i should have swapped the drives before giving it to RAOF to see if it had the same problem
<cnd> Sarvatt, natty udev doesn't help...
<cnd> $ sudo udevadm trigger
<cnd> that makes it work
<cnd> well, it made mouse work
<Sarvatt> err yeah, no keyboard or anything before lightdm starts and can't interact with the system at all, thats different from when lightdm didn't give me devices
<cnd> kb doesn't...
<Sarvatt> sorry, got the symptoms confused, i had the lightdm problem a long time ago and it fixed itself about 3 weeks ago
<cnd> my kb doesn't come up, perhaps because there's no udev event for it?
<cnd> so now gdm won't come up
<cnd> and lightdm is still broken...
<bryceh> anything in /var/log/gdm /var/log/lightdm of relevance?
<cnd> which log file should I look in in /var/log/gdm?
<bryceh> like :0.log
<Sarvatt> dont suppose there's anything useful in /var/log/lightdm/lightdm.log?
<Sarvatt> err guess i should read scrollback before asking lol
<bryceh> also, sorry if you already mentioned it but does keyboard work on vt console?
<Sarvatt> he probably cant even switch to a vt to check
<bryceh> oh true
<Sarvatt> i couldn't when i had that problem
<cnd> I'm ssh'd in, so I can chvt
<bryceh> cnd, umm...  ok so presumably you can get into grub on boot?  can you boot into a recovery session and just verify kernel input is working outside X?
<cnd> I can type into a vt
<bryceh> ok
<cnd> I know kernel input works
<cnd> or at least it did until I dist-upgraded today
<cnd> and I've had the lightdm issue for quite some time
<bryceh> ah ok, guess I missed that
<bryceh> maybe I should back up and ask, what have you narrowed the problem down to?
<Sarvatt> cnd: does it work if like, you boot with text instead of splash into recovery and continue past that to skip all the plymouth stuff?
<cnd> hmmm, RAOF did stuff to this machine at the sprint
<cnd> said he took off fglrx
<cnd> but something seems odd
<cnd> well, I thought maybe he didn't remove the fglrx lines from Xorg.conf, but I think I'm just seeing a standard error about not finding fglrx
<bryceh> "did stuff" - do you mean, with the objective of fixing input?  or that the input breakage started after that?
<bryceh> yeah that's innocuous
<cnd> no, with the objective of fixing 3d so unity would run :)
<bryceh> if fglrx is removed you shouldn't need xorg.conf
<cnd> hmm, from dmesg:
<cnd> [  395.259525] gdm-simple-slav[1310]: segfault at 0 ip 00007f89d2fc9f15 sp 00007fff4ec516f0 error 4 in libnss_compat-2.13.so[7f89d2fc6000+8000]
<bryceh> I wouldn't think that would affect input
<cnd> yeah, I think that's the cause of gdm not working
<cnd> well, I have two issues now
<cnd> input doesn't work in lightdm
<cnd> and gdm doesn't work at all
<cnd> so this segfault is likely the issue for gdm
<cnd> but I still don't know what's up with lightdm
<bryceh> ok, the gdm issue sounds unrelated to X, but I'm curious about the lightdm issue
<bryceh> did you spot anything pertinent in the lightdm logs?
<cnd> nothing I can tell
<cnd> but the log is so short
<bryceh> also, did the input breakage start after RAOF's changes or before?
<cnd> :0.log that is
<Sarvatt> cnd: encrypted home directory?
<cnd> I dunno if they're filtering out warning messages?
<cnd> Sarvatt, no encryption
<cnd> bryceh, the input breakage has existed ever since I upgraded to natty
<Sarvatt> https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/805154
<cnd> about a month ago
<ubot4> Launchpad bug 805154 in gdm (Ubuntu) "gdm-simple-slave crashed with SIGSEGV in _nss_compat_getpwnam_r() (affects: 13) (dups: 6) (heat: 88)" [Medium,Triaged]
<cnd> Sarvatt, thanks!
<Sarvatt> oddly i had the lightdm no input thing and used gdm for a week and it was fixed by the first lightdm upgrade in june where i switched back
<cnd> so I can fix the lightdm issue for mice by calling udevadm trigger
<cnd> but kb still doesn't work
<Sarvatt> after you run udevadm trigger does the keyboard work if you stop and start lightdm again?
 * Sarvatt is out of ideas :P
<cnd> nope
<cnd> where's the udev code in xorg-server?
<cnd> I can't remember
<bryceh> pastebin your Xorg.0.log and xinput stuff
<Sarvatt> config/udev.c
<cnd> bryceh, log: http://paste.ubuntu.com/639763/
<cnd> oops, wrong log
<cnd> wait, that's the right one
<cnd> I have a phantom X server running
<cnd> bryceh, xinput list: http://paste.ubuntu.com/639764/
<cnd> now it shows the AT translated keyboard
<cnd> but it doesn't work...
<cnd> using xinput test-xi2 I get raw key press and releases
<cnd> bryceh, so apparently I get KeyRelease, but not KeyPress events
<cnd> there's somethign in the server that is witholding keypress
<cnd> now that I think of it, I had the same problem way back in natty
<cnd> when I was running xorg-edgers
<cnd> there was a change to something related to keyboard support
<cnd> like xkb stuff
<cnd> and it caused this
<bryceh> hmm
<cnd> so perhaps now oneiric is updated to whatever was broken when I was running xorg-edgers before
 * cnd was hoping it was a fluke...
<cnd> back then I tried to step through the server to figure it out
<cnd> and I got lost
<cnd> that's not a good sign...
 * bryceh browses through xserver patches
<cnd> I got into the xkb stuff and I had no clue what was going on
<bryceh> 208_switch_on_release.diff ?
<bryceh> that fiddles with keypress behavior... roughly around the timeframe you mention... maybe try disabling that
<cnd> bryceh, ok, I'll try it
<bryceh> although, you mentioned you have a phantom X session?  Could it be stealing keyboard input?
<cnd> I killed it
<cnd> but this occurs when it's a clean boot
<cnd> so I don't think that's it
<bryceh> ok
<cnd> ok, time to take the dog out while it compiles :)
<bryceh> yeah that's the only xserver patch that looks close to relevant
<bryceh> cnd, oh btw would appreciate your look at 504_exevent_proximity_null_ptr_check.patch some time
<cnd> bryceh, where's that patch?
<bryceh> xorg-server-git-ubuntu/debian/patches/208_switch_on_release.diff
<cnd> bryceh, no, the one you want me to look at?
<bryceh> cnd, https://bugs.launchpad.net/ubuntu/+bug/764700
<ubot4> Launchpad bug 764700 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in utouch_frame_sync() (affects: 1) (heat: 14)" [High,Triaged]
<cnd> bryceh, that's not related to any multitouch or gesture stuff right?
<cnd> the patch seems fine, but I don't understand why there would be proximity events for a device without a proximity class
<bryceh> cnd, yeah the backtrace the guy posted doesn't match to what he mentioned earlier that involved utouch
<bryceh> but it's not obvious why it would fail on the proximity stuff
<cnd> bryceh, the only note I'd make is that the 5xx serios of patches are intended to be gesture/multitouch
<cnd> and this isn't
<bryceh> anyway, guess we can see what the user finds testing it
<cnd> so should it be a 2xx patch?
<bryceh> yeah, but that'd require redoing the MT patches
<bryceh> (I think)
<bryceh> if the patch pans out, we could do that; not worth the bother until we know if it works
<cnd> yeah
<cnd> I didn't think that patch touched the MT stuff
<bryceh> cnd, btw looking at your Xorg.0.log it appears you have two keyboards?
<cnd> no, only one
<cnd> what is the second kb you see?
<bryceh> one appears to be attached to event4, the other is on event3
<bryceh> [   925.109] (II) HID 413c:8161: Configuring as keyboard
<bryceh> [   925.109] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/input/input4/event4"
<bryceh> [   925.109] (II) XINPUT: Adding extended input device "HID 413c:8161" (type: KEYBOARD)
<bryceh> and
<bryceh> [   925.280] (II) config/udev: Adding input device AT Translated Set 2 keyboard (/dev/input/event3)
<bryceh> [   925.280] (**) AT Translated Set 2 keyboard: Applying InputClass "evdev keyboard catchall"
<bryceh> [   925.280] (II) Using input driver 'evdev' for 'AT Translated Set 2 keyboard'
<cnd> not sure what that is
<cnd> the first one
<bryceh> bet it's some other device being mis-detected as a keyboard
<cnd> yeah
<bryceh> the touchscreen maybe?
<cnd> bryceh, http://www.linux-usb.org/usb.ids says it's a Dell Integrated Keyboard
<bryceh> [   925.108] (**) HID 413c:8161: Applying InputClass "evdev keyboard catchall"
<cnd> it could be the extra function keys at the top
<cnd> media buttons
<bryceh> mm, yeah that seems more likely
 * bryceh thinks
<bryceh> well, I'm sketchy on if it's even a problem, but maybe try putting in a udev rule to disable or switch drivers on that, and see if things work any better?
<bryceh> cnd, do the media keys do anything?  :-)
<bryceh> I wonder if xinput --remove-master would do anything useful
<bryceh> cnd, anyway, that's my guess as to the problem.  probably Xi or evdev messing up
<cnd> bryceh, removing that patch didn't help :(
<cnd> bryceh, I think it's inside the server since I'm getting keyrelease but not keypress
<cnd> I do see rawkeypress though
<cnd> so the keypress events are being sent to the server
<cnd> they're just being dropped somewhere
<bryceh> hmm
<tjaalton> Sarvatt, bryceh: if xdiagnose is in universe there's no way it's going to be installed by default. My desktop got installed as natty, enabled universe and this week upgraded to oneiric; xdiagnose got pulled in like it should
<bryceh> tjaalton, it wasn't seeded.  cjwatson fixed it for  us about an hour ago
<tjaalton> bryceh: ah good, well it had to move to main first?
<tjaalton> so it seems
<bryceh> tjaalton, yeah apparently there's multiple levers to be pulled, and I closed the MIR before the last one had been pulled
<tjaalton> right
<tjaalton> cnd: testing your xserver now :)
<bryceh> tjaalton, any ideas on where to go with debugging cnd's missing keypresses?  Sarvatt and I are out of clues
<bryceh> xtrace wouldn't be useful in this case, would it?
<tjaalton> well, if cnd can't figure it out how could I :)
<bryceh> tjaalton, so you think he should speak with our resident X input expert, eh?
<tjaalton> skimmed through the backlog pretty quickly, I'll have another look after this wacom test
<tjaalton> bryceh: well.. :)
<bryceh> that's the problem with learning too much about X.org
<RAOF> If the keypresses are being eaten in the server...
<bryceh> you learn too much and then when you run into X problems you get referred back to yourself
<tjaalton> but, I've never heard of that happening.. sounds really weird
<cnd> yeah, I'm perplexed
<bryceh> cnd,  xinput list --long | pastebinit
<cnd> probably the worst place to have a bug in the xserver is in keyboard handling :)
<cnd> based on what I've heard of xkb
<RAOF> There does seem to be some oddness there; your various jack devices seem to keep confusing evdev and causing it to unload.
<bryceh> otoh with keyboard bugs there's a fair chance of a pre-existing patch out there
<cnd> bryceh, http://paste.ubuntu.com/639789/
<RAOF> I'd just like to assert that everything was working fine when I handed it back to cnd at the sprint :P
<tjaalton> cnd: wacom fixed!
<cnd> RAOF, I had it using gdm :)
<cnd> tjaalton, \o/
<cnd> this is a lightdm issue
<bryceh> interesting - http://people.freedesktop.org/~whot/evtest/
<tjaalton> cnd: whot gave me some ideas earlier today, so I tried to backport some stuff from master, but it turned out to bee a bit too complex trying to match it with this version
<tjaalton> bryceh: apt-get install evtest
<cnd> tjaalton, for handling the wacom issue?
<tjaalton> cnd: yeah
<tjaalton> I think this case is handled in master
<cnd> yeah, anything dealing with cursor or mouse input doing weird stuff likely can't be helped by whot until we get XI 2.1 merged upstream :(
<tjaalton> but the functions have changed too much, and soon it became minigolf time so I gave up
<cnd> heh
<cnd> tjaalton, bryceh, RAOF: I can't seem to push a commit to git.debian.org
<cnd> did the alioth switchover affect ssh access?
<tjaalton> cnd: check your .git/config, change the host to git.d.o
<tjaalton> then it should work
<cnd> tjaalton, everything looks good there...
<tjaalton> hmm, .ssh/known_hosts then?
<cnd> and I can't ssh to git.debian.org like I used to be able to
<tjaalton> what does it complain?
<cnd> Permission denied (publickey).
<cnd> fatal: The remote end hung up unexpectedly
<bryceh> generic error
<bryceh> cnd, tried checking out a fresh new branch and pushing from that?
<tjaalton> that error is from ssh though
<cnd> bryceh, my remote url is set up correctly
<cnd> and the error does seem to come from ssh
<tjaalton> could you paste that nevertheless :)
<cnd> oh wait...
<cnd> I'm cndougla-guest on alioth
<cnd> cause of their weird username rules
<tjaalton> right
<tjaalton> but surely you've pushed there before?
<tjaalton> not from the same machine?
<cnd> aha, it worked!
<cnd> ok, I managed to get *something* done today :)
<cnd> I hate being blocked by silly things like keyboard not working
<tjaalton> hehe :)
<cnd> bryceh, I just committed a patch as 504
<cnd> just fyi
<tjaalton> so the kbd works in a vt?
<cnd> yeah
<tjaalton> hum, you tested with gdm already, noticed that you said it happens only with lightdm?
<tjaalton> uh, nonsentence
<tjaalton> getting late!
<cnd> tjaalton, it used to work in gdm, when gdm actually worked
<cnd> gdm doesn't work anymore
<tjaalton> oh, works here though
<cnd> that's great :)
<tjaalton> just start plain x with xterm
<tjaalton> isn't it :)
<cnd> anyone know how to manually start my normal user session?
<cnd> something like startx
<RAOF> xinit gnome-session ?
<tjaalton> yeah that might work
<cnd> I'm not authorized
<cnd> but sudo xinit unity is coming up
<cnd> I'm sure it's running as the root user though...
<cnd> oh what failure...
<tjaalton> xinit -- gnome-session :1
<tjaalton> as the user
<tjaalton> without 'gnome-session' it just runs an xterm
<tjaalton> didn't try with g-s
<cnd> as root?
<tjaalton> no wait
<tjaalton> xinit gnome-session -- :1
<tjaalton> use your username
<tjaalton> uh
<tjaalton> non-root
<tjaalton> :)
<cnd> hmm?
<tjaalton> does 'xinit -- :1' work?
<cnd> not as myself
<cnd> only as root
<tjaalton> oh
<tjaalton> is lightdm running
<tjaalton> ?
<cnd> I'm trying to get around lightdm
<cnd> or are you saying I can run lightdm first
<tjaalton> yes, separate xservers
<cnd> and then run something else to kick it through to my desktop?
<tjaalton> maybe xinit works since I have my real desktop running too
<tjaalton> dunno..
<cnd> is there another lightweight DM I can run?
<tjaalton> xdm
<cnd> of course :)
<tjaalton> lightestdm
<tjaalton> +''
<cnd> gah!
<cnd> no kb there either
<tjaalton> ouch
<cnd> somewhere the dev gods are pointing and laughing...
<tjaalton> check /etc/default/keyboard, does it have the XKB*-values on it?
<cnd> yeah
<tjaalton> I can run xinit just fine even without any X running, as a user
<tjaalton> anyway..
<cnd> hmm
<cnd> tjaalton, what groups are you a part of?
<tjaalton> adm dialout cdrom plugdev lpadmin admin sambashare
<tjaalton> some of which I've added myself
<cnd> nothing there stands out
<tjaalton> plugdev is maybe the most useful of them
<RAOF> tjaalton: Have you configured x11-common to allow unfettered access to the X server?  It's got 3 settings - root, at console, and everyone.
<tjaalton> RAOF: good point, console. I think it's the default?
<tjaalton> cnd: run 'xinit xev', see if X thinks it gets any events from the keyboard
<cnd> RAOF, just found that through a google search
<cnd> I was able to get to an xterm
<cnd> xev gives keypress and keyrelease
<cnd> what's the unity 2d session called?
<tjaalton> unity-2d
<tjaalton> ah
<tjaalton> gnome-session --session=ubuntu-2d
<cnd> hmm, "xinit unity-2d" didn't work
<tjaalton> so plain xterm works?
<cnd> tjaalton, yes
<cnd> now I need to figure out how to set the session using xinit
<cnd> xinit gnome-session --session=ubuntu-2d doesn't work
<cnd> bad command line option
<tjaalton> yeah, put -- in between
<cnd> then it thinks it's a server option
<cnd> well, put '--' in between where?
<tjaalton> xinit gnome-session -- --session=ubuntu-2d
<cnd> yeah, then it thinks it's a server option
<tjaalton> according to the manpage that should be ok
<tjaalton> oh
<tjaalton> argh, right
<bryceh> xinit gnome-session -- /usr/bin/X --session=ubuntu-2d  ?
<cnd> I think I got it
<cnd> I made a shell script
<tjaalton> cnd: just put 'gnome-session --session=ubuntu-2d' in your .xinitrc
<tjaalton> right
<cnd> and put "gnome-session --session=ubuntu-2d"
<cnd> and did xinit <script>
<tjaalton> yep
<cnd> ok, I finally have a desktop again
<cnd> now I can get back to work
<tjaalton> and if you put that as ~/.xinitrc you'd start it with just 'xinit'
<cnd> why does ubuntu one *always* crash
<cnd> all the time, incessantly
<tjaalton> so keyboard in gnome works too, meaning it's just lightdm that refuses to work?
<cnd> and the "ignore future crashes" thing doesn't work
<cnd> I think it's just lightdm and xdm
<tjaalton> ok
<tjaalton> still, weird
<RAOF> I wonder if lightdm starts the server in a particularly weird way?
#ubuntu-x 2011-07-08
<bryceh>  /etc/lightdm/Xsession
<RAOF> That doesn't actually start the server, though.
<bryceh> well it's just  /usr/bin/X :0 -auth /var/run/lightdm/authority/0 -nolisten tcp vt7
<bryceh> compared with /usr/bin/X :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-jn8cMJ/database -nolisten tcp vt7
<cnd> could the -nr have something to do with it?
<RAOF> Unlikely; that just turns on BGNoneRoot.
<RAOF> Which interacts not at all with input.
<cnd> are we 100% sure?
<cnd> is there a way I could check it?
<RAOF> Woo!  More intel fbc.
<Sarvatt> RAOF: what are you thinking, --with-extra-module-dir="/usr/lib/${DEB_HOST_MULTIARCH}/xorg/extra-modules"
 * Sarvatt saw the xorg-server task opened up
<RAOF> Sarvatt: Indeed I am.
<RAOF> Well, actually, --with-extra-module-dir="/usr/lib/${DEB_HOST_MULTIARCH}/xorg/extra-modules,/usr/lib/xorg/extra-modules\
<RAOF> "
<Sarvatt> i'm not sure that it'll take 3, hmm
<bryceh> cnd, heh lp #807306 just came in
<ubot4> Launchpad bug 807306 in xorg (Ubuntu) "[oneiric] Keyboard & mouse not working in X (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/807306
<bryceh> looks like you're not alone
<Sarvatt> in kvm? hmm that should be easy to reproduce
<Sarvatt> will check tomorrow's daily live
<RAOF> Sarvatt: Looks like X should handle as many comma-delimited components to that path as we want.
<Sarvatt> kvm -cdrom oneiric-desktop-i386.iso  -boot d -m 512 --vga vmware
<Sarvatt> love how easy that is
<Sarvatt> oh? thought i read it wouldn't in the patch, my bad
<Sarvatt> awesome, if thats all it takes it'd be easy
<RAOF> The patch doesn't change how the string is parsed at all, and the parser seems to loop over the strtok components, soâ¦ :)
<RAOF> Hm.  Multiarching stuff is an excellent way to discover locally installed cruft.
<RAOF> âWhat do you mean you can't resolve shlibdeps for /usr/lib/libpixman?  Oh, it's now in /usr/lib/x86_64-linux-gnu/?  What's that local copy doing there?â
<tjaalton> bryceh: the logfile on that bug shows no input devices
<RAOF> Which would make it Sarvatt's âudev doesn't fire for input devicesâ bug.
<bryceh> also cirrus.  ick
<tjaalton> that's what kvm has
<tjaalton> cirrus, that is
<bryceh> XAA yum
<tjaalton> most of them do just that :)
<bryceh> is there a bug # for sarvatt's udev bug?
<tjaalton> i've not seen that before
<RAOF> I'm not sure if he actually filed it.
<RAOF> It looks like it's time for your old friend, deadly neurotoxin.
<tjaalton> happy boozing :)
<tseliot> RAOF: still around?
<Sarvatt> cnd: did you ever try downgrading lightdm?
<cnd> Sarvatt, lightdm never worked for me
<cnd> so I wouldn't know which version to try?
<Sarvatt> yeah but this is happening to more people now post alpha 2 so it might have just been reintroduced
<Sarvatt> checking
<Sarvatt> 0.4.1-0ubuntu1
<seb128> Sarvatt, what bug?
<Sarvatt> seb128: the one you guys are talking about, cnd hit it after an upgrade about 18 hours ago too
<seb128> which is 2 hours early than the bug report
<seb128> i.e 10utc yesterday
<Sarvatt> but he had it back in may as well and had been using gdm this whole time
<seb128> it's not lightdm
<seb128> kenvandine said on #ubuntu-desktop he gets it with startx
<Sarvatt> gnome-session --session=ubuntu-2d in ~/.xinitrc and an xinit works
<cnd> I get it with xdm too
<Sarvatt> ah
<Sarvatt> ok then nevermind :)
<seb128> <kenvandine> i am guessing udev
<seb128>  maybe udev gets the plugin event and configures the device
<seb128>  confirmed, re-plugging in the mouse and keyboard worked
<seb128>  but doesn't work at boot
<seb128> <kenvandine> looking at the X logs, it isn't finding input devices
<Sarvatt> https://launchpad.net/bugs/807306 is another bug, apparently we should be able to reproduce it in kvm with today's daily-live
<ubot4> Launchpad bug 807306 in xorg (Ubuntu) "[oneiric] Keyboard & mouse not working in X (affects: 2) (heat: 14)" [Medium,Incomplete]
<seb128> jibel says he doesn't get it
<Sarvatt> oh no daily live today, darn
<Sarvatt> alpha 2 is fine it was something updated just after
<jibel> we have a list of package updated in bug 807538
<jibel> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/807538/+attachment/2197590/+files/history.log
<ubot4> Launchpad bug 807538 in linux (Ubuntu) (and 2 other projects) "Keyboard and touchpad problems (affects: 1) (heat: 10)" [Medium,Incomplete] https://launchpad.net/bugs/807538
<ubot4> Launchpad bug 807538 in linux (Ubuntu) (and 2 other projects) "Keyboard and touchpad problems (affects: 1) (heat: 10)" [Medium,Incomplete]
<seb128> that one has an xorg server update
<Sarvatt> thats natty?
<jibel> no oneiric, but looks like a mutant
<seb128> that's a natty to oneiric upgrader
<seb128> would be nicer to find somebody who has the issue on oneiric to oneiric update
<Sarvatt> i did oneiric alpha 2 installs on 2 machines and just fully updated them and they are fine
<Sarvatt> https://lists.ubuntu.com/archives/oneiric-changes/2011-July/004255.html hrm
<Sarvatt> that also has /etc/nsswitch.conf in it and libnss was crashing with gdm, wonder if its related
<Sarvatt> cnd: dbus?
<cnd> Sarvatt, what about dbus?
<Sarvatt> it had a huge update and switched to upstart, wondering if something got left around on upgrades breaking things that arent there on a fresh install
<cnd> hmm
<cnd> let me know if you can think of something for me to try
<Sarvatt> so the emails from people trying to use xorg-edgers on debian are getting a bit out of hand, I wonder if launchpad will ever support debian PPAs.. I'd be more than happy to maintain a debian version of it but our xserver and mesa are so drasically different you can't just use it that way anymore for the past few years. I use debian-unstable debian/ for everything but xserver mesa intel nouveau ati synaptics and evdev so that stuff wouldn't change bu
<Sarvatt> t thats like the majority of the usage by far
<bryceh> Sarvatt, seriously?  how many people trying to do that?
<Sarvatt> enough to make me think it'd be worth maintaining a debian specific version when I dont use it :P just counted 31 emails this week, usually people leaving ubuntu for debian over unity and wanting the same thing they used to have (wait until they get gnome 3 pulled in automatically) lol
<bryceh> oh yeah, the unity dissidents will probably die down in time
<bryceh> Sarvatt, probably if you don't do it, if there's enough demand someone will volunteer on the debian side to do something similar
<bryceh> and if not... tough titties ;-)
<bryceh> I'd like to know why so many people run -edgers... it sort of implies we're missing something in the distro itself
<Sarvatt> because you get things like 20% speed improvements overnight and its drastically less unstable than people think, that matters to gamers :)
<Sarvatt> but the person who cares about that is probably more willing to forgive a bug they hit than someone who just expects the desktop to work perfectly
#ubuntu-x 2011-07-09
<bjsnider> you're missing something in the distro if there's a 20% speed improvement
<bryceh> performance optimizations have tended to be at the root cause of a fair number of the freeze bugs we get
<Sarvatt> 6 months between releases, 3-4 month windows where the newer versions have to be released between to even get considered, hundreds of commits modifying the code giving those kinds of improvements so it cant just be backported, etc
<Sarvatt> yep that too :)
<bryceh> if upstream were better at making those sorts of things configurable, it'd help
<bjsnider> maybe x-updates is too conservative
<bryceh> or if upstream didn't delete all of the existing code as soon as they've finished writing something new
<bryceh> bjsnider, I think it's more a labor limitation there.  we could definitely be more active at updating that if we had more time
<Sarvatt> probably but I have more than I can handle alone just doing xorg-edgers and thats what I'm most interested in
<bjsnider> i still send stuff in there lol
<bjsnider> i guess i'm the only one
<Sarvatt> lots of things to worry about in there too, things arent as self contained once you move out of the luxury of the binary drivers :P
<bryceh> bjsnider, keep it up :-)
<bryceh> we should look for new recruits, too.  I used to be more active at snaring people and pulling them into the team
<bjsnider> well, maybe there should just be one ppa and a "let the buyer beware" attitude towards it
<Sarvatt> to update a ddx you need to update libdrm usually and screw up other things (hello nouveau), update mesa you potentially regress tens of other drivers, that kind of crap
<bryceh> Sarvatt, yep.  Also, a lot of the improvements are in the kernel drm or mesa, which are hard to do in -updates
<bryceh> mesa rc1 already, nice.
<bryceh> Sarvatt, regarding bug #807306 here's a list of packages the guy upgraded - https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/807306/+attachment/2198342/+files/dpkg.txt
<ubot4> bryceh: Error: Bug #807306 is private.
<bryceh> Sarvatt, there's a minor udev update in there and a major xserver update.  He tested the kernel update and it seems innocent.  Could it be an xserver bug?
<stefanlsd> is the prop nvidia / multiarch sorted yet, or still broken. missing xorg-edgers...
#ubuntu-x 2011-07-10
<Sarvatt> RAOF: hope thats not going in the dell, expect problems with the vertex 3 :)
<Sarvatt> RAOF: dont try to put a retail bios on it to fix it btw
<linux-beginner-h> Hi, I would like to try wayland on kubuntu... but I can't install it because of broken dependencies (libcairo2-dev)
<linux-beginner-h> it's kubuntu 11.4
<Sarvatt> looks like the no keyboard/mouse bug is hitting debian too, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633441
<ubot4> Debian bug 633441 in udev "xserver-xorg-core: No keyboard after fresh install" [Important,Open]
<RAOF> Sarvatt: Oh, really?  What sort of problems with the vertex 3?
<Sarvatt> RAOF: besides like 80% of the laptops out there not working with it? :P
<Sarvatt> check the ocz forums
<RAOF> Sarvatt: Well, it seems to work here.
<Sarvatt> \o/ e6420 was one that specifically didnt work when I was shopping
<Sarvatt> maybe it has a newer firmware on it out of the box by now
<RAOF> I can always throw it in a desktop, I guess :)
<RAOF> Well, it installs, boots, and installs packages as fast as a tmpfs on my x200s.
<RAOF> So now all I need to do is get a power cable so I can power both it and my irc bouncer at the same time :)
#ubuntu-x 2012-07-02
<mlankhorst> RAOF: yeah but that was after that comment he put in :)
<mlankhorst> I just wanted to know if there was a way to say 'hold on until I have more info I don't want to risk it getting upstream'
<mlankhorst> s/upstream/in updates/
<mlankhorst> oh timing
<mlankhorst> RAOF: yeah but that was after that comment he put in. I just wanted to know if there was a way to say 'hold on until I have more info I don't want to risk it getting released'
<mlankhorst> RAOF: can synaptics be sru'd?
<RAOF> mlankhorst: Yes; failing anything else, I'll get to it on my SRU team day tomorrow.
<seb128> RAOF, mlankhorst: what's the deal with those workitems?
<seb128> [raof] Switch on SNA for -intel in quantal post-alpha1 once it's had a week to bake in -edgers: TODO
<seb128> [bryce] Forward SNA-related -intel bugs to Intel between alpha1 and alpha2: BLOCKED
<seb128> [ubuntu-x-swat] Evaluate shippability of SNA for -intel in quantal pre-alpha-2: BLOCKED
<seb128> [raof] Drop libgl1-mesa-swx11 and 8bit/16bit osmesa packages from mesa post-alpha1: TODO
<seb128>  
<seb128> we are past post-alpha1 ;-)
<seb128> we are post-alpha2!
<seb128> do you know why the BLOCKED as well? what is blocking?
<RAOF> I may be missing some context here?
<seb128> RAOF, sorry, https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-xorg-general
<seb128> RAOF, those are work items from that spec
<seb128> RAOF, I just noticed reviewing the list that they seemed to be "post a1" items and we are post a2 ... so I was wondering what's the status on thelm
<tjaalton> seb128: sna just got enabled in edgers last week
<tjaalton> so slightly behind schedule there
<mlankhorst> RAOF: lets drop swx11 and enable vdpau then?
<tjaalton> and the other task is blocked because of that
<tjaalton> let the debian bug reporter sort out the packaging bits first?
<tjaalton> that's why it got reverted from our mesa
<tjaalton> handling hw-specific config files is not trivial
<mlankhorst> oh k
<mlankhorst> fairly sure mesa no longer uses config files though
<mlankhorst> or at least had an attempt to use autoconf more
<tjaalton> /etc/XvMCConfig or what it was called
<tjaalton> not for vdpau
<mlankhorst> that's used by the xvmc wrapper
<tjaalton> the patch enabled that too
<mlankhorst> it could be moved towards loading xvmc lib based on driver like vdpau does
<mlankhorst> but dropping xvmc altogether sounds like a better plan
<tjaalton> yeah, not much useful these days
<RAOF> mlankhorst: Yup. That can me my reward after processing the SRU queue tomorrow :)
<mlankhorst> ah k
<seb128> tjaalton, mlankhorst, RAOF: can somebody update the workitems to reflect the new target? is a3 realistic?
<mlankhorst> should be easy
<mlankhorst> RAOF: ugh for copyright notice what is preferred?
<mlankhorst>  * Copyright Â© 2012 Canonical
<mlankhorst> good enough?
<tjaalton> Ltd.
<tjaalton> there's probably some template on wiki.c.c
<tjaalton> or just copy from elsewhere
<mlankhorst> hm ok :)
<mlankhorst> I finished my initial dma-buf-mgr stub, surprisingly little survived of my initial code. Now to hook it up..
<ogra_> so i got this new machine ... with two radeon 6670 cards and three monitors ...
<ogra_> apparently to use all three across the two cards i need to enable xinerama ... which then disables composite ... 
<ogra_> is there any reason that we build our xserver in a way that excludes composite when xinerama is on ? i thought that was fixed in 1.10
<jcristau> it's not really
<ogra_> and what is http://cgit.freedesktop.org/xorg/xserver/commit/?id=84a14fab8f930ef1855444ae4e9e3e14ee008328 ?
<ogra_> i thought that enabled it 
 * ogra_ was hoping it was only a build time switch we miss
<mlankhorst> and v2 sent to ml :)
<bryceh> ogra_, have you tried with the blob?
<cnd> bryceh: do you know when the quantal X server is going to be uploaded?
<bryceh> cnd, do you mean 1.12?  That went u p last week
<cnd> bryceh: oh great!
<cnd> I just got back from a small vacation
<bryceh> cnd, we expect to continue pulling upstream versions off and on through to the 1.13 release
<cnd> so I didn't notice
<bryceh> cnd, welcome back!
<cnd> oh, quantal will be 1.13?
<cnd> that makes fixing upstream bugs easier :)
<bryceh> well, that's the target, but we'll keep options open until we can bang on it and make sure it's safe
<cnd> yeah
<cnd> I'm going to be trying to fix an upstream bug today, so us being on 1.12 now is nice
 * bryceh nods
<bryceh> mlankhorst, reminds me; you now can start rolling the LTS point release scripts to set up those 12.x PPAs now
<mlankhorst> bryceh: ah was still busy with dma-buf synching but got to the point where I like the api :)
<mlankhorst> do you mean 12.x straight or renamed?
<bryceh> mlankhorst, renamed
<mlankhorst> oh sure, will do!
<mlankhorst> bryceh: kept myself busy with the synching problem, found a nice solution for deadlocks on free, simply wait until deferred fput patches hit mainline, problem goes away by itself there. The synching api itself will be done by a renamed and slightly modified version of ttm reservation.
<bryceh> mlankhorst, cool
<bryceh> mlankhorst, do those fput patches make any sense to think about SRUing to precise?
<mlankhorst> probably not, but it will be in the backported kernel
 * bryceh nods
<bryceh> ok sounds good
<mlankhorst> there's only 1 opportunity for deadlocking now in dma-buf and that should be solved by not taking the lock there.
<ricotz> bryceh, hi :)
<ricotz> bryceh, could you push a rebuild of nvidia-blob for abi 12 in quantal?
<tjaalton> tseliot's business
<tjaalton> actually
<tjaalton> mlankhorst: you uploaded nvidia the last time?
<tjaalton> ricotz: they should be fine, no?
<mlankhorst> tjaalton: nope?
<mlankhorst> but yeah should have been rebuilt
<tjaalton> i'm not sure if they use the automatic stuff
<tjaalton> but hardcoded values
<ricotz> tjaalton, currently not
<ricotz> it just needs and rebuild
<ricotz> and/an
<tjaalton> https://lists.ubuntu.com/archives/quantal-changes/2012-June/003202.html
<tjaalton> how come that didn't fix it then
<ricotz> tjaalton, 302.17
<tjaalton> that's not in quantal
<ricotz> https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/302.17-0ubuntu1
<tjaalton> ok, well that was uploaded even later, so
<Sarvatt> he uploaded straight to ubuntu when x was in proposed?
<ricotz> Sarvatt, probably
<tjaalton> ok
<ricotz> tjaalton, fact is it depends on abi 11 instead of 12 ;)
<ricotz> so i hope someone could push a rebuild
<jcristau> if a rebuild changes that, something's broken
<ricotz> jcristau, it automatically picks up the abi version provided by xserver-xorg-dev, what is broken with that?
<tjaalton> the blob doesn't automatically gain new abi
<jcristau> it's a blob.  you know the abi versions it supports statically
<jcristau> it doesn't depend on what you build against at all
<ricotz> the packaging does it that way
<jcristau> then the packaging is screwed up.
<ricotz> so this would need to be changed then
<tjaalton> i've downloaded it
<ricotz> i am not here to argue about this, i am just saying nvidia-blob is not installable in this condition and a rebuild against the newer xserver fixes it
<ricotz> despite the fact that the packaging might need some rethinking in this case
<Sarvatt> jcristau: i very much agree, but its like that so its not installable when it doesn't support the new abi in the gui driver installer
<tjaalton> hm?
<bryceh> %-)
<tjaalton> i can push the rebuild
<tjaalton> and worry about the packaging later..
<ricotz> tjaalton, thanks
<tjaalton> nice, firefox and tbird both taking ~80% cpu
<tjaalton> ok both were due to the leapsecond mess
#ubuntu-x 2012-07-03
<bryceh> anyone know if NVIDIA put out a new -96 yet?
<Sarvatt> seems pretty safe to say nvidia-96 is dead, its been a year since the last release
<bjsnider> that's too bad, as it's such a great driver
<mlankhorst> morning
<mlankhorst> Aw my keyboard died, one of the support legs snapped of. Finally enough motivation to buy a new one since this was a really damn good logitech keyboard. :)
<mlankhorst> RAOF: just xf86-modesetting was added right?
<RAOF> mlankhorst: Between Precise and Quantal? I think so, yes.
<tjaalton> has the renaming postfix been decided? or do we just use what the kernel has? (-lts-q)
<tjaalton> * -lts-quantal
<mlankhorst> think we just follow lts-quantal
<tjaalton> yeah, good
<tjaalton> shorter names :)
<mlankhorst> it was just s/backport-// anyhow
<tjaalton> yup
<tjaalton> wonder if we can just sync libx11 now
<mlankhorst> I'm really hoping.. can we make libdrm-nouveau1 be separately installable so we could upgrade libdrm instead of needing a rename?
<mlankhorst> I could make the package for it
<tjaalton> remember that this would need to be done for every backport series
<tjaalton> sru'ing libdrm
<RAOF> We always need to upgrade/rename libdrm anyway; we only test the *whole* stack in ubuntu+1
<mlankhorst> yeah I know
<RAOF> If we cherry-pick bits of the stack we lose some of the benefit of that testing.
<RAOF> Thinking of libdrm, why aren't we on 2.4.35 again?
<mlankhorst> nouveau
<RAOF> Changes ABI. Does it bump SONAME, or do we need to beat someone with a seal?
<RAOF> A *baby* seal.
<RAOF> My quick ls suggests that it does the sensible thing and is now libdrm_nouveau.so.2.
<RAOF> Which is entirely parallel installable with libdrm_nouveau.so.1, right?
<RAOF> I guess we don't get to rebuild mesa, though.
<mlankhorst> and that would really be the problem
<mlankhorst> don't get to rebuild libdrm_nouveau1a either
<tjaalton> cnd: I'm syncing both libx11 and libxi, looks like the upstream versions have everything we need
<mlankhorst> cnd: yay synaptics 1.6.2 is in -proposed finally
<Sarvatt> RAOF: it bumps soname but it doesnt ship the old version anymore which our mesa needs until august
<RAOF> Sarvatt: Right. The first would be fine; we'd just keep libdrm-nouveau1a around in the archive until everything had settled down. It's the latter bit that's the problem.
<Sarvatt> give it a few days, airlied already bugged darktama about that
<Sarvatt> they need to update f17 :)
<mlankhorst> i think they added a hack there for it though :\
<RAOF> There's always the option of embedding libdrm-noueveau1a's source in mesa. :)
<Sarvatt> oh speak of the devil
<Sarvatt> 1 hour ago http://pkgs.fedoraproject.org/gitweb/?p=libdrm.git;a=shortlog;h=refs/heads/f17
<mlankhorst> oh so it did land
<mlankhorst> Sarvatt: Well do you want to update libdrm or shall I?
<tjaalton> nice little patch :)
<Sarvatt> mlankhorst: 4am and whisky o'clock here, safe to assume the latter unless tomorrow :)
<mlankhorst> heh sure
<mlankhorst> ok uploaded renamed base packages, if they work I'll upload drivers again :)
<mlankhorst> RAOF: can you upload 'xorg'? I updated the git tree for x1.12
<tjaalton> he's probably asleep by now
<mlankhorst> ah k, can you?
<tjaalton> yep
<mlankhorst> I verified the synaptics sru, uploaded libdrm to a local ppa for testing tomorrow, renamed xorg-server seems to have built succesfully, so I'm uploading all the renamed drivers and call it a day. :-)
<erappleman> is there any easy way to deal with libdrm-nouveau1a/2 collisions?
<erappleman> the packages don't play nice if i use oibaf's ppa
<jcristau> who's oibaf
<mlankhorst> erappleman: working on it :\
<mlankhorst> https://launchpad.net/~mlankhorst/+archive/ppa didn't test yet
<mlankhorst> tomorrow
<ricotz> mlankhorst, i dont think that's what he is talking about, this is just a messed up packaging while putting nouveau.2 in nouveau1a package
<ricotz> https://launchpad.net/~oibaf/+archive/graphics-drivers/+sourcepub/2495386/+listing-archive-extra
<mlankhorst> oh
<mlankhorst> that should really not be attempted, even
<`rand`> Bug: I upgraded to 12.04 and was disappointed to learn that the Sticky Keys feature has lost some functionality.  Specifically, pressing a modifier key twice no longer "locks" it, in Xkb terms; latching still works, but it's much more tedious.  Which package (or packages) would I need to look at to correct this?
<`rand`> I guess, more generally, which package (or packages) control the core keyboard functionality for X and/or Ubuntu?  It's not just Unity, but even Awesome--which could enable sticky keys through the use of the xkbset package in prior versions--no longer works.  The regression is frustrating and I would love to help fix it.
<tjaalton> it's in the accessibility features
<tjaalton> system settings, a11y, writing..
<tjaalton> seems to work just fine
<tjaalton> `rand`: ^
<tjaalton> pretty sure we would've heard about it by now if it was generally broken
<`rand`> check bug 998877 on launchpad.
<ubottu> Launchpad bug 998877 in Ubuntu "Sticky keys disabled when pressed twice" [Undecided,Confirmed] https://launchpad.net/bugs/998877
<tjaalton> ok
<bryceh> just shoved in xdiagnose 2.9.  This changes the gpu lockup udev rule to hopefully eliminate false lockup reports.  but not entirely sure what it'll do, so keep an eye out for oddities with freeze bug reporting and let me know.
<tjaalton> okie
<`rand`> bryceh: Was that to me?
<bryceh> no
<`rand`> ah, thanks.
<`rand`> tjaalton: which WM are you using?
<bryceh> I'm not really sure what exactly does the sticky keys thing.  xkeyboard-config is the source package for keyboard mapping issues, but haven't run across anything about sticky keys there.  I'd suggest asking one of the accessibility folks who deal with that functionality more regularly.
<`rand`> Thanks bryceh.  It has something to do with modifying XkbStateRec, but I'm not sure where I would need to do that.
<tjaalton> `rand`: i misread your description, sticky keys work but not that particular use case I guess
<`rand`> I tried apt-get source xkbset, but it only gives me the .h files for the helper functions that modify it. :/
<`rand`> tjaalton: it's all good, I just want to fix it.  I'm using 10.10 now until I can.
<tjaalton> so it happens with plain Awesome, ie. no gnome bits running?
<`rand`> It no longer works in Awesome, sadly--no Gnome bits.
<tjaalton> then it's probably something in the xserver that changed
<`rand`> emacs is my preferred editor, so the regession was obvious immediately.
<tjaalton> amazing, no changes to the package since 2006
<`rand`> Is X hosted on git?
<tjaalton> cgit.freedesktop.org
<`rand`> thanks!
<tjaalton> among many other bits
<`rand`> I'll clone the xserver repo and look through it.  What was the last commit for 11.10?  12.04?  That'll help me narrow my search.
<`rand`> Hah--just saw my "hosted on git?"  Meant github. :)
<mlankhorst> oh just 1 package failed to build in q-lts-backport
<tjaalton> so works on 11.10, not on 12.04?
<`rand`> correct.
<mlankhorst> https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport/+build/3627065 yuck :S
<tjaalton> hmm, well it too had at least some version of the multitouch work
<tjaalton> mlankhorst: oh, did it build on quantal?
<mlankhorst> tjaalton: probably, was using the source package from quantal
<mlankhorst> but it might have been copied over..
<mlankhorst> tjaalton: I'm going to investigate tomorrow at least
<tjaalton> right, since the input drivers weren't rebuilt against the new server, since the abi should be the same. could be something else too
<tjaalton> i might just as well update wacom, though there aren't that many changes
<tjaalton> 0.16 should be out soon
<mlankhorst> but yeah nice point that it didn't build with quantal too, should have come up with that if i was more awake :)
<Sarvatt> 101_fix_build_against_frankenserver.patch just needs to be disabled, same thing that happened in synaptics
<tjaalton> ah
<mlankhorst> Sarvatt: sure will do that tomorrow, I guess I'm just the first to rebuild it :)
<tjaalton> i'll upload it to quantal now
<tjaalton> there is xf86-input-wacom-0.15.99.1 but i've not time to test it before vacation, so dropping the patch will have to do
<tjaalton> mlankhorst: wait, where did you get -0ubuntu3?
<tjaalton> I only see -0ubuntu2
<mlankhorst> its a rebuild which bumps it
<mlankhorst> iirc
<tjaalton> it's not in quantal
<tjaalton> my git has 2
<mlankhorst> tjaalton: I mean I think the rename script bumped it
<tjaalton> ahh ok
<tjaalton> that's wrong :)
<mlankhorst> yeah but i dont feel like clicking 50 times to rename it once more, next version
<tjaalton> well it'll be messy if it stays like that
<mlankhorst> it won't, just on the list of things to fix with x1.13
<cnd> bryceh: whot said we need to update our keyboard driver to 1.6.1
<cnd> https://bugs.freedesktop.org/show_bug.cgi?id=50683
<ubottu> Freedesktop bug 50683 in Server/General "Black screen with "AutoAddDevices" "Off"" [Major,Resolved: notourbug]
<tjaalton> in precise?
<tjaalton> quantal has it
<cnd> yeah, I think in precise
<tjaalton> it has 1.6.0
<cnd> the bug report is from a lubuntu 12.04 user
<bryceh> cnd, is there a ubuntu bug for that?  we'd need one for SRU
<bryceh> cnd, is there a specific patch I could pull, in case a point release update is not in the cards?
<tjaalton> 20beb15d24b5f8ab194b94f7e29f49e91ea38a8b probably
<tjaalton> only five commits there
<cnd> whot said something about unresolve symbol xf86IsPC98
<tjaalton> "Remove calls to xf86IsPc98()"
<tjaalton> same :)
<cnd> yeah, that looks right :)
<bryceh> ok
<cnd> whot said we may also need http://cgit.freedesktop.org/xorg/driver/xf86-input-keyboard/commit/?id=38e4defe795776479594825859e101cd7cb5aa17
<cnd> it's the commit right before
<cnd> nm, he says not to worry about it
<tjaalton> cnd: hey, there was some talk about a sticky key regression since 11.10.. think it could be due to the input changes?
<cnd> dunno
<tjaalton> ok, just a thought
<`rand`-AFK> tjaalton: still here--I'm checking it now. :)
<`rand`> Be back tomorrow--hopefully with a solution!
<bryceh> umm
<bryceh> tjaalton, looking closer now at the upstream bug report, the guy saw his failure after enabling xorg-edgers on precise
<bryceh> so SRUing this to precise is not the right solution
<bryceh> this needs to have -keyboard 1.6.1 added to xorg-edgers
<bryceh> cnd, ^^
<cnd> bryceh: ahh, ok, thanks :)
<cnd> bryceh: do we have warnings to tell people to file bugs in LP and not upstream when they use edgers?
<cnd> I don't know where we would put a warning like that though...
<cnd> maybe in the ppa description
<cnd> since that is shown when you want to add the ppa now
<bryceh> cnd, no in fact we do the opposite
<cnd> we ask people to file upstream bugs?
<bryceh> yup.  purpose of edgers is to track upstream and provide packages of the upstream stuff to make testing easier
<bryceh> we close out bugs about edgers problems if filed in LP.
<cnd> well, that commit in xf86-input-keyboard was from last october
<cnd> if we're going to tell people to file bugs upstream, we probably need to keep in sync better
 * bryceh nods
<bryceh> -keyboard in edgers is 1:1.6.1+git20120703.dd6f110c-0ubuntu0sarvatt~precise 
<cnd> hmm...
<cnd> then what's going on...
<bryceh> updated 47 min ago
<cnd> oh, just updated :)
<cnd> yay
#ubuntu-x 2012-07-04
<Sarvatt> bryceh: yeah sorry, i haven't been putting keyboard into edgers which was the problem
<Sarvatt> i actually resurrected that dead package a few releases ago with a sync..
<Sarvatt> it wasnt in lucid
 * Sarvatt kicks self for https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-keyboard/+bug/680049
<ubottu> Launchpad bug 680049 in xserver-xorg-input-keyboard (Ubuntu) "Sync xserver-xorg-input-keyboard 1:1.5.0-1 (universe) from Debian experimental (main)" [Wishlist,Fix released]
<RAOF> Who uses -keyboard, anyway?
<bryceh> nokidding
<Sarvatt> hurd?
<Sarvatt> :)
<RAOF> Does the doko's AC100 still use -keyboard, or has nvidia joined the evdev generation?
<Sarvatt> evdev was fine on that when i last used one in dublin
<bjsnider> Sarvatt, https://launchpad.net/~thebernmeister/+archive/indicator-ppa-download-statistics
<bjsnider> that supposedly is an indicator that provides ppa download numbers
<bjsnider> so you can track edgers and w hatnot
<Sarvatt> bjsnider: holy crap, with how slow querying the info is off launchpad i'm scared to try it :)
<Sarvatt> 50% cpu usage for 2 hours at a time to update it ftw
<Sarvatt> giving it a shot now though, thanks for the heads up because it looks neat :)
<bjsnider> to update what?
<Sarvatt> download statistics?
<bjsnider> ok, that's a bit of a problem
<bjsnider> i hope you report that to wgrant or somebody
<bjsnider> whoops, he's actually in this channel
<Sarvatt> it was actually really fast
<Sarvatt> and xorg-edgers lost a crapton of users :)
<Sarvatt> 8k amd64 downloads of openchrome that hasnt been updated since feb and automatically installed, 7.7k on i386, was closer to 45k total in 10.10
<wgrant> Sarvatt: 50% CPU usage!?
<wgrant> that doesn't sound like a Launchpad problem :)
<Sarvatt> nah was talking about a real old crappy script, sorry for the ping :)
<wgrant> Note that there's a hole in the download stats from May 21 to June 25 that will be filled in in the next couple of weeks.
<RAOF> You know what's not super-fast? An atom building mesa.
<bjsnider> Sarvatt, any idea why the user count went down?
<tjaalton> bryceh: heh, indeed
<mlankhorst> morning
<mlankhorst> RAOF: try an atom building x over nfs
<mlankhorst> on wireless :-)
<mlankhorst> hm, should the renamed version be oldversion~precise1 or oldversion-precise1, I can only do the former with --force-bad-version but I don't know if it will break anything or not..
<mlankhorst> one way to find out I suppose
<tjaalton> the latter would be newer than "oldversion"
<tjaalton> which breaks upgrades
<mlankhorst> tjaalton: yeah but I don't know if anything will subtly break by resetting version to below the previous changelog entry
<maxb> That happens all the time with backports
<tjaalton> mlankhorst: no, it'll still upgrade from precise
<tjaalton> that's how sru's are versioned too
<mlankhorst> ah k
<tjaalton> hmm
<mlankhorst> yeah I don't expect to be able to upgrade from xorg q stack to q afterwards, but maybe r will be possible with q stack
<tjaalton> maxb: what do you mean, having to use --force-bad-version?
<tjaalton> wonder why that's needed tho, since it's a valid version
<maxb> having changelog versions less than the previous
<tjaalton> ah
<tjaalton> yes, more common there than -updates
<tjaalton> because of the policy
<mlankhorst> well dch won't complain if you do it by hand :-)
<tjaalton> oh it's dch.. then ignore the warning :)
<mlankhorst> tjaalton: yeah using the xorg-pkg-tools rename scripts, fixed them to add ~precise1 to version instead of bumping it
<tjaalton> yep, sounds about right
<mlankhorst> I should probably have to re-upload them all to fix it for all packages
<tjaalton> you can't, if the version is older
<tjaalton> not on the same ppa
<mlankhorst> even if deleted?
<tjaalton> nope
<mlankhorst> why did wacom just say accepted then?
<mlankhorst> (although that build failed on all)
<tjaalton> which versions?
<tjaalton> the old & new
<mlankhorst> think original was 1:0.14.0-0ubuntu3+rename2.1, now 1:0.14.0-0ubuntu3~precise1
<tjaalton> hm, weird
<tjaalton> maybe launchpad got updated then
<tjaalton> because I'm certain that wasn't possible before
<mlankhorst> same
<tjaalton> wgrant: hey, you should know ^ :)
<mlankhorst> else I wouldn't mind if the whole ppa was flushed out, I could just re-upload it
<tjaalton> this is great news if it's true, since a simple mistake could render a package useless on a ppa
<tjaalton> before, that is
<wgrant> tjaalton: If you wait a few hours after deleting you can upload an older version.
<wgrant> It's always been the case.
<wgrant> Although it used to take a day or so.
<wgrant> But you can still never upload the same version again.
<tjaalton> oh
<mlankhorst> oh that's fine, I still have almost the full domain of natural numbers after ~precise1 :-)
<tjaalton> don't waste them :)
<RAOF> You've got more; you've got the set of terminating decimals!
<RAOF> Technically that would be a ring.
<RAOF> (It's not closed under division, so it's not a field)
<RAOF> Which obviously means it's a proper subset of the rationals ;)
<mlankhorst> oh right testing frankendrm
<mlankhorst> xf86-video-nouveau with new nouveau works
<mlankhorst> RAOF: you weren't kidding about mesa hardcoding pkg-config calls.. eep
<mlankhorst> mesa seems to link with old nouveau abi
<mlankhorst> oh failure, something tries to link against new libdrm_nouveau.so
<mlankhorst> RAOF: at least.. MOST things were hardcoding drm_nouveau pkgconfig, others just did -ldrm_nouveau directly
<mlankhorst> sigh, does fglrx overwrite some part of X too?
<jcristau> glx
<jcristau> should be all
<jcristau> well and libGL
<mlankhorst> yeah looks like I'll have to reinstall precise on other system and test https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1009629
<ubottu> Launchpad bug 1009629 in xorg-server (Ubuntu) "Xorg crashed with SIGSEGV in DeliverRawEvent()" [High,Fix committed]
<mlankhorst> I suspect user error but still
<tseliot> mlankhorst: let me check
<tseliot> mlankhorst: if users use the NVIDIA installer or the AMD installer (without generating deb packages) and overwrite our libraries, then yes, it can be a bit of a problem...
<mlankhorst> tseliot: yeah probably what's happening here, the annoying part is that the fglrx installer can create .deb files and most of  the time they work
<mlankhorst> which would sidestep this
<tseliot> mlankhorst: yes, which is why I work on that part of the AMD installer...
<mlankhorst> tseliot: I just realized that I should see it as positive, more people testing than appearing on first sight. :)
<tseliot> heh
#ubuntu-x 2012-07-05
<LLStarks> tjaalton, re the ppa bullet of the hybrid graphics spec, airlied now has a how-to for building prime: http://people.freedesktop.org/~airlied/prime-notes.txt there's also arch build scripts now: https://github.com/Samsagax/prime-AUR
<LLStarks> it all works
<mlankhorst> tjaalton: I'm waiting until the api is settled first, no good packaging it yet
<tjaalton> LLStarks: yup, what mlankhorst said :)
<mlankhorst> plus hoping to get the synch stuff in kernel for 3.6 which might be too optimistic, but still aiming for it
<tjaalton> also, i bet it's better in august when i'm back
<mlankhorst> we'll see
<mlankhorst> netboot first, then some more kernel testing, I fear that I have to reboot so many times today it will make sense to optimize that.
<mlankhorst> welp, seems I had 3 to 4 different places where I kept all kinds of xorg packages in various states of freshness
<RAOF> Heh
<mlankhorst> down to 4 now, prime tree, debian git, original quantal stack and renamed :)
<mlankhorst> ergh, too damned hot
<mattgriffin> just filed pad.lv/1021393 and happy to help debug if anyone is available. thanks!
<tjaalton> does downgrading xserver-xorg-core make it work again?
<mattgriffin> tjaalton: to https://launchpad.net/ubuntu/+source/xorg-server/2:1.11.4-0ubuntu10.2/+build/3470874 ?
<mattgriffin> tjaalton: i tried downgrading to xserver-xorg-core_1.11.4-0ubuntu10.2_amd64.deb but that didn't fix it
<mattgriffin> tjaalton: i was going to try to downgrade xserver-common but can only find an i386 build. where can i find an amd64 build?
<tjaalton> that's mostly just a metapackage
<mattgriffin> tjaalton: so downgrading isn't worth trying?
<mattgriffin> or it's okay to try the i386 version?
<tjaalton> don't bother
<mlankhorst> weeee more dma
<Sarvatt> OOPS-de3dc66a98c00d0e8904d5ad19f82462
<Sarvatt> darn, bot doesn't send me a link to the oops decoder anymore :)
<Sarvatt> sorry for the noise
 * mlankhorst puts Sarvatt in a sg list
<mlankhorst> timeouts for launchpad seem really low which is probably the issue here
<tjaalton> pushed a patch to xorg-server for precise
<tjaalton> apparently fixes bug 921236
<ubottu> Launchpad bug 921236 in xserver-xorg-input-evdev (Ubuntu) "[12.04 Xorg, xserver 1.11.3] Dual monitor, after entering password, mouse pointer stuck on LHS of screen, no desktop." [High,Confirmed] https://launchpad.net/bugs/921236
<tjaalton> is there something else, or should I just upload to -proposed?
<tjaalton> guess I'll upload then :)
<tjaalton> would be nice to get the input refresh from 1.12.3 when it's released
<tjaalton> for 12.04.1
<mlankhorst> tjaalton: isn' t the xserver still in -proposed state?
<tjaalton> nope
<tjaalton> hmm wait
<tjaalton> right, .3 is in updates
<mlankhorst> ah sure go for it then
<mlankhorst> didn't expect it that fast :)
<tjaalton> uhh :) https://launchpad.net/xserver
<mlankhorst> https://launchpad.net/xorg-server
<tjaalton> yeah
<`rand`> I've been comparing the xserver code from Merkat, Ocelot, and Pangolin to try finding the sticky keys error--and argh!  I need to finally learn C--or at least get a good IDE that can locate function definitions.  I see XkbClearAllLatchesAndLocks defined as an extern in xkbsrv.h--but where is it actually defined?
<jcristau> that's what ctags is for
<jcristau> xkb/xkbActions.c
<`rand`> ty, jcristau--again, I need to finally learn C. :)
<jcristau> sounds like a good plan :)
<jcristau> then again, xkb is probably not the best introduction
<jcristau> possibly the worst possible one actually
<`rand`> true, but I need sticky keys working properly for Pangolin to be useful. :)
<bjsnider> tjaalton, so, it seems that the 3.5-rc4 kernel is bulletproof here
<bjsnider> regarding 999910 that is
<tjaalton> bjsnider: ok, did you have a way to reproduce it at will?
<bjsnider> no, not really
<bjsnider> but i've been using this kernel for a few days and no problems
<bjsnider> i'll keep using it until quantal probably
<tjaalton> i heard of someone on X230 that ran -27 for several days until it hung 
<bjsnider> mine never lasted more than a day
<tjaalton> would be great to find more fixes :)
<tjaalton> to backport
<tjaalton> though at some point we'll probably just tell people to use the backport kernel
<tjaalton> but 12.04.1 will be at least a bit more stable
#ubuntu-x 2012-07-06
<mlankhorst> morning!
<RAOF> Aloha!
<mlankhorst> finally to a point where I can check if things explode or not :)
<bryceh> Sarvatt, heard any complaints so far about switching on SNA?
<Sarvatt> bryceh: err, it hasnt been usable here on any machine, but no direct complaints outside of mine :)
<bryceh> Sarvatt, is that due to sna or edgers or something else?
<Sarvatt> every daily update fixes one bug and introduces another
<Sarvatt> SNA
<bryceh> hrm
<bryceh> Sarvatt, should we hold off on enabling it then?
<Sarvatt> uxa is fine
<Sarvatt> bryceh: until 2.20 for sure, it usually stabilizes for releases
<mlankhorst> Sarvatt: no surprises there :-)
<Sarvatt> even ickle said he's holding off recommending people using it until 2.20
<mlankhorst> wow
<mlankhorst> I'm having fun deadlocking atm :P
<Sarvatt> <ickle> Sarvatt: just waiting for 2.20.0 before going nuts with people trying it ;-)
<bryceh> Sarvatt, ok thanks.
<bryceh> Sarvatt, is it worthwhile for us to keep testing it, or should we just drop consideration of it until 2.20?
<bryceh> Sarvatt, and have you heard any eta on 2.20?
<Sarvatt> in ubuntu directly?
<bryceh> yeah
<Sarvatt> bryceh: they usually do it right before mesa releases for their quarterly stuff, asking ickle now though
<bryceh> 2.19 was 2 months ago, and looks like they go 2-4 months per release, so guessing it'll appear within the quantal development timeframe
<Sarvatt> bryceh: errr
<bryceh> however if it's so churny in edgers now, I'm wondering if it's just not going to be stable enough for us.
<Sarvatt> so ickle is saying soon, very soon, as soon as he has a build fix for hotplug server changes
<Sarvatt> guess i better start filing some bugs :)
<bryceh> no kidding
<bryceh> well, we can decide at alpha3.  But we got bit adopting the new 2d accel architectures too early the last two times
<Sarvatt> totally, SNA seems totally crazy to me with how much churn it has still every single day
<bryceh> yeah when you said that, it flipped a warning flag to me
<bryceh> Sarvatt, hmm I guess the real question is, should we consider it FAILED for the 1-week edgers test, and cancel the alpha2-alpha3 testing, or should we give it another week in edgers, or...?
<bryceh> I've got edgers installed on a couple of my machines and haven't noticed problems but haven't been using them much this past week
<Sarvatt> bryceh: tough call, 2.20 may work better, but I'm firmly in the mindset that just having the xorg.conf option is good enough for now until its more stable
<Sarvatt> (and defaulting to UXA)
<bryceh> Sarvatt, I think that's probably the sanest thing to do
<bryceh> Sarvatt, would you mind writing up a short description of your week with sna for the blueprint?  just mention the types of bugs you've encountered, and that ickle indicated sna wasn't considered ready for wide usage until 2.20?
<Sarvatt> sure, digging up the blueprint
#ubuntu-x 2012-07-07
<thomas_> hi there, 302.17 broke my external monitors connected via docking station and display port. i didn't find anything in the bug reports, is that a known problem?
<deffrag> Hello! I've been noticing abnormal behavior in Ubuntu 12.04. My system's GUI and keyboard suddenly freezes but it doesn't freezes movement of mouse, audio playback and ssh access. I cannot click on anything, change to tty0-6, caps lock on/off gives no indication. I'm not able to understand this type of behavior. Can anyone help me identify the problems and fix them please?
<JanC> deffrag: did you try what they said in bug #1015015 ?
<ubottu> Launchpad bug 1015015 in xserver-xorg-video-intel (Ubuntu) "Xorg freezes once a day, mouse and SSH still works" [High,Incomplete] https://launchpad.net/bugs/1015015
<deffrag> JanC: Uh-huh. Yes, I'm trying it
<JanC> actually, I think there was an X update today, not sure it was related
<deffrag> JanC: I'm connected to the problem system via ssh and having difficulty using command line to try what's suggested in the comments. Could you help me enable the -proposed repository, and install the kernel found there from command-line?
<JanC> the GUI doesn't work when you reboot it?
<deffrag> Well, I can reboot but using hard reset I don't want to stop one of my important tasks which is still running as per top.
<JanC> well, to use the new X you would have to restart the session anyway...
<deffrag> Then I think I'll have to wait
<JanC> it's a GUI task still running?
<deffrag> Yes, as per top but nothing on display
<deffrag> Its also assigned to upload some data, which I can see the system is doing from the router stats
<JanC> I hope it saves the results automatically  ;)
<deffrag> Yes, me too:)
<JanC> waiting for it to end and then remembering you need to click te save button would suck  :P
<deffrag> Yes, but in this case it will most likely save the work
#ubuntu-x 2013-07-01
<mlankhorst> Hello, world!\n
<llstarks> hey mlankhorst 
<mlankhorst> morning
<llstarks> did your fencing work make it to sumit and airlied in time for 3.11?
<mlankhorst> not the fencing itself, it wasn't planned for it
<mlankhorst> but the wound/wait mutexes did
<llstarks> does this allow in-order frames?
<mlankhorst> not yet
<mlankhorst> intel needs to be modifiied to support fencing internally first
<mlankhorst> and what I did was a hack to only support it on the command submission buffers
<llstarks> cool
<mlankhorst> but it should be possible, it just means disintegrating the dev_struct lock in intel that currently protects everything
<llstarks> you lost me heh. drm and 3am don't mix
<llstarks> going through your just-now commits and the 3.11 merges. looks nice
<mlankhorst> everything in for-airlied and for-airlied-next is queued
<mlankhorst> rework-v11 is going through core/locking
<llstarks> i'll go through the mutex stuff in the morning when i'm rested enough to trace it. always enjoyed mutexes and spinlocks when learning c
<mlankhorst> llstarks: https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=core/mutexes
<mlankhorst> Those lockdep tests saved my life once already, when one of the core maintainers had a locking selftest failure when he merged another mutex patch that wasn't adjusted for the w/w mutex changes. :P
<RAOF> mlankhorst: Oh, hai! You wouldn't happen to know off the top of your head how I stop the outputless x-x-v-ati from binding on my hybrid system?
<mlankhorst> RAOF: erm not from head, you could disable autoAddGPU
<mlankhorst> that disables the initial scan at least :P
<tjaalton> hmm the soft cursor with mir is kinda distracting :P
<tjaalton> also doesn't seem to use mouse acceleration
<RAOF> tjaalton: It should use acceleration; it's using the full X input stack.
<tjaalton> RAOF: the x cursor does, but the big soft one doesn't
<RAOF> You mean the big partially-transparent one?
<tjaalton> yes
<RAOF> That's the hardware cursor. Yes, indeed, it doesn't have mouse acceleration.
<tjaalton> ah, i heard it was software.. anyway, ok
<RAOF> The X cursor is software.
<tjaalton> so I got it backwards then
<RAOF> Right.
<RAOF> Also, does that cursor move for you? It doesn't with synaptics. At least once X starts.
<tjaalton> it does with the thinkpad nipple
<RAOF> Ah, evdev's not exclusive then.
<tjaalton> suspend seems to fail with xmir
<RAOF> As in: fails to suspend, or fails to resume?
<tjaalton> fails to suspend
<RAOF> The latter might be failure on our part to do the intricate VT dance
<tjaalton> though this is a quirky old thinkpad so it might be something else
<RAOF> Does it try to suspend?
<tjaalton> yeah, the crescent moon is blinking
<RAOF> <shrug>
<RAOF> Interesting.
<tjaalton> hmm, hitting the hotkey-combo "freezes" the machine, meaning it changes vt
<tjaalton> oh, now it suspended fine
<tjaalton> resume worked
<tjaalton> so.. quirky old laptop :)
<ricotz> mlankhorst, hi :)
<ricotz> mlankhorst, i am hoping you can get pixman updated to 0.30
<mlankhorst> ricotz: ideally through debian first
<ricotz> mlankhorst, right, altough you updated 0.28 in debian git for ubuntu only too
<mlankhorst> yeah but that was due to freeze
<ricotz> ok
<RAOF> Hah. xf86-video-ati doesn't work particularly well when you hand the fd of an i915 device.
<RAOF> Who'd've thought?
<mlankhorst> RAOF: I caught a kernel panic in nouveau that way
<RAOF> mlankhorst: What, handing a nouveau fd off to i915 or something?
<mlankhorst> yeah
<mlankhorst> I'm running a torture test on nouveau for some fun
<mlankhorst> running the max-texture-size piglit test until things break
<smartboyhw> bryce, private message?
<Sarvatt> ricotz: go figure, right after you updated https://devtalk.nvidia.com/default/topic/549155
<llstarks> dammit nvidia, still no egl?
<llstarks> they put out wddm1.3 drivers for windows 8.1 but oh no, experimental stuff for linux is offlimits
<ricotz> Sarvatt, hehe, i knew it
#ubuntu-x 2013-07-02
<tjaalton> mlankhorst: what was the motivation for 716e08fb054e in mesa? :)
<tjaalton> nothing in changelog
<tjaalton> merging from debian and it causes issues
<mlankhorst> tjaalton: files didn't exist any more
<tjaalton> hmm ok I see
<tjaalton> might come back if we give in to building libosmesa separately again
<mlankhorst> not sure if we should, beh i need to figure out what is wrong
<tjaalton> hmm osmesa is built the same way on debian too
<tjaalton> but it's the swx11 targets that put files there
<tjaalton> anyway, fixing the osmesa build not to link to shared glapi should be configurable
<tjaalton> or just disable it altogether, as it doesn't make much sense
<mlankhorst> meh I want to figure out why osmesa doesn't work right first
<tjaalton> isn't that obvious?
<mlankhorst> libglapi exists, so it looks more like a linking fail in osmesa if it doesn't work
<mlankhorst> of osmesa, that is
<mlankhorst> simple linking works just fine on saucy, hm lets see with nvidia-319
<mlankhorst> tjaalton: still works for me with nvidia-319 installed too on saucy
<mlankhorst> 32-bits and 64-bits
<mlankhorst> extern int OSMesaGetCurrentContext;
<mlankhorst> int main() { return OSMesaGetCurrentContext; }
<tjaalton> ok then
<mlankhorst> works on quantal too, maybe their configuration was just broken
<tjaalton> 9.1.4 uploaded
<tjaalton> and again, powerpc ftbfs..
<mlankhorst> link?
<tjaalton> 9.1.1-0ubuntu2
<tjaalton> enabled llvm to work around it :P
<mlankhorst> heheehheheh
<tjaalton> didn't bother to check at this point how it's built on debian
<mlankhorst> it's fallout from the shared mesa stuff, I think
<tjaalton> ah, right
<tjaalton> http://launchpadlibrarian.net/143988643/mesa_9.1.3-0ubuntu4_9.1.4-0ubuntu1.diff.gz if you care
<mlankhorst> only thing I care about is finishing sru first
<mlankhorst> oh looks like my xbmc fixed to vdpau got in
<mlankhorst> nouveau E[   PFIFO][0000:01:00.0] read fault at 0x0000f00000 [PAGE_NOT_PRESENT] from PCOPY1/PCOPY1 on channel 0x005fce0000 [DRM]
<mlankhorst> weee
<mlankhorst> I really need to figure out what is going on there
#ubuntu-x 2013-07-03
<MCR_> Sarvatt, hi - are you here ?
<MCR_> Sarvatt, ricotz (hi, btw): Yesterday's update of xorg-edgers PPA on Raring breaks multiple Compiz plugins...
<ricotz> MCR_, i guess you are suspecting the mesa update then?
<MCR_> Yeah :(
<MCR_> ricotz, it is quite bad this time
<ricotz> MCR_, i see, you want to give some more information then
<MCR_> ricotz, EZoom mouse cursor zooming is broken and the cube looks completely weird...
<MCR_> ricotz, I have no idea how everything worx with xorg 1.14...
<ricotz> MCR_, ok, more like your hardware setup
<MCR_> fglrx, ATI 6950
<ricotz> MCR_, you are using the canonical x-staging ppa
<MCR_> noooooo
<ricotz> ah
<MCR_> tried it once, but was a bad experience
<ricotz> so you are not actually using mesa!
<MCR_> the strange thing is that it broke with yesterdays update
<MCR_> I am not sure what exactly broke it
<ricotz> would be better if you track down the actual package which broke things
<MCR_> ok
<ricotz> since while you are using fglrx it doesnt make much sense that xedgers broke it with the recent updates
<MCR_> it is quite strange, but I am (quite) sure it was the xorg-edgers update...
<MCR_> first update yesterday broke it really bad -> ezoom was having 3fps on my setup
<MCR_> today's update (libdrm) has fixed it up a bit and ezoom is fast again, but the cursor zooming is broken
<MCR_> what parts of x is fglrx utilizing ?
<ricotz> MCR_, actually none of mesa/drm update should effect your fglrx setup
<MCR_> well that is really strange then
<ricotz> you are sure you are actually runnning fglrx?
<MCR_> yes
<MCR_> OpenGL version string: 4.2.12217 Compatibility Profile Context 9.012
<MCR_> OpenGL vendor string: Advanced Micro Devices, Inc.
<MCR_> OpenGL renderer string: AMD Radeon HD 6900 Series
<ricotz> which package version is that? "dpkg -l | grep fglrx"
<MCR_> ii  fglrx                                         2:12.104-0ubuntu1
<MCR_> ii  fglrx-dev                                     2:12.100~beta7-0ubuntu1~xedgers~raring1
<MCR_> it is the latest beta fglrx AFAIR
<ricotz> MCR_, could you try fglrx-13 ?
<MCR_> I still use the latest beta driver, because the release driver was making problems last time I tried
<MCR_> but I'll try some other fglrx versions
<ricotz> (it is weird that you have different versions of fglrx/fglrx-dev)
<MCR_> I installed the beta manually...
<MCR_> I guess the dev version is from the PPA
<ricotz> ok, if you want beta7 then you dont currently have it
<MCR_> maybe it helps to remove the -dev completely
<MCR_> woot ?
<ricotz> pick a consistent combination https://launchpad.net/~xorg-edgers/+archive/ppa/+packages?field.name_filter=fglrx&field.status_filter=published&field.series_filter=raring
<MCR_> maybe the version just shows up wrong, I am sure I have installed the beta driver from the AMD page, but thanks I'll try some things...
<ricotz> MCR_, you manually installed the driver?
<MCR_> ricotz, yes
<ricotz> ah you mean to build the deb out of the installer?
<MCR_> sh ./AMD-driver-installer-from-AMD.sh --buildandinstallpkg Ubuntu/raring
<ricotz> ok, this is kind of unsupported then imo
<MCR_> ah, maybe that is the problem
<MCR_> I have this driver running for several months with xorg-edgers PPA together without any problems up to yesterday
<ricotz> MCR_, did you say in the past that you are using the fglrx packages from xedgers?
<MCR_> I certainly did, but then some time I could not reach you and it was a bit outdated in the PPA or so (I do not remember exactly)
<MCR_> then I installed the one from AMD directly
<ricotz> ok, you better revert your setup to the official raring package then, and go from there fixing it
<MCR_> ricotz, thanks 4 your time - AMD and their versioning -> everything is called differently
<ricotz> MCR_, what is the lasted fglrx driver?
<MCR_> ricotz, haha -> that is a really good qu
<ricotz> their versioning is really messed up
<MCR_> I just know that I used the latest beta, then 12.6 ? came out (the one with buffer_age support)
<ricotz> 13.6 beta > 13.101
<MCR_> I tried it, but it was reaaaaally slow
<ricotz> 13.10 > 13.100 (internal version)
<MCR_> then I switched back to the latest beta, which still was older than the regular driver they released
<MCR_> also directly from AMD
<ricotz> amd-driver-installer-13.10-x86.x86_64.run (of 5th june)
<MCR_> (I had to remove the stupid beta branding again)
<MCR_> which I already have a script in my main home dir for... ;)
<MCR_> I'll try fglrx-13 now
<ricotz> fglrx-13 is (13.6 beta > 13.101)
<MCR_> I have overclocked my GPU also, that is why I try to not change the driver too often...
<ricotz> (but the 13.10 release is newer of course)
<MCR_> I'll try fglrx-13 from the PPA ?
<MCR_> or is that a bad idea
<MCR_> which is the latest supported by xorg-edgers ?
<ricotz>  fglrx-installer-13 - 2:13.101~beta-0ubuntu1~xedgers~raring1 (13.6 beta)
<ricotz> good luck for now, i need to go
<MCR_> ok, cool -> should be the same I am running now (without buffer_age support AFAIR) -> Thanks 4 your help, ricotz  !
<MCR_> ricotz, just FYI: fglrx-13 is a catastrophe, a disaster on my hardware, slow as sh*t (on 6950 at least)
<MCR_> and with the same OpenGL gfx problems :(
<MCR_> ricotz, just FYI: tested latest beta from AMD directly (==fglrx-13 from the PPA) -> slow and buggy also, but EZoom works much better than with the one from PPA, although it should be the same ?!
<MCR_> Unigine valley runs slow at around 60% from the fps feeling, with the 12.x beta series I had over 1000 points in the benchmark, now 725 :(
<MCR_> I guess the only solution for me is to purge xorg-edgers PPA and use 12.x beta again...
<MCR_> I cannot stand slow 3d gfx, especially when it is that ugly, slow and broken on higher-end hardware. Inacceptable 4 me.
<MCR_> back with ultra-high performance and without bugs, on fglrx 12.11-beta and with purged xorg-edgers PPA on R
<MCR_> Valley Score: 1117 :)
#ubuntu-x 2013-07-04
<MCR_> ricotz, hi. Just FYI: Solved my issues with (old) fglrx 12.11-beta. For comparison: Valley Score 1117, with fglrx-13 around 700 points there and a lot of gfx problems...
<Sarvatt> MCR_: there havent been any updates in xorg-edgers that would affect fglrx in many many months
<Sarvatt> so is 13.whatever slower on whatever release you're testing 12.11-beta on? thats worth trying if you havent
<MCR_> Sarvatt, that is strange. Yes, 13.x is much slower here and also creates visual bugs (many of them).
<MCR_> HD 6950 hardware
<MCR_> Sarvatt, I might drop fglrx in the near future anyway as radeon seems to improve steadily...
<MCR_> and scrolling and other things were already better than with fglrx...
<MCR_> for example, 3 displays with radeon -> no problem
<MCR_> 3 displays with fglrx -> not working
<MCR_> and I have video 6 outputs (2xHDMI 4xDP) on my card
<Sarvatt> what release and what DE? there was a unity upgrade on 6-25 that might be problematic if it was raring, and there was a kubuntu upgrade at the same time
<MCR_> Raring, Compiz trunk, Unity 7 -> but I'm updating daily and it broke 2 or 3 days ago
<MCR_> Sarvatt, with purged xorg-edgers ppa and downgraded fglrx to 12.11-beta everything is fast and bug-free again (just FYI)...
<MCR_> I'm out, c ya.
<mlankhorst> oh so that's the osmesa bug..
<mlankhorst> oh..
<mlankhorst> easy to fix, too!
<mlankhorst> I'm going to slap someone if they suggest fixing it by doing another build round, if I'm not mistaking removing 4 lines is enough to fix this..
<mlankhorst> http://paste.debian.net/14404/
<mlankhorst> hm no, needs some more, I need to figure out how gl does it
#ubuntu-x 2013-07-05
<Guest54061> suddenly i am not able to setup my second monitor with arandr, did something break recently?
<a5m0> my mini-displayport is only puting out some redlines on my second monitor, just started doing this yesterday, anyone seen funky stuff with intel 4000 drivers?
#ubuntu-x 2013-07-07
<tball> Hello
<tball> I want to build the xserver-xorg-video-ati xorg-edgers packages with a different compile configuration. Can I do that?
<tball> I did try set export DEB_BUILD_OPTIONS="--with-gallium-drivers=r600 --enable-vdpau" before running dpkg-buildpackage -rfakeroot
<tball> , but that didn't work.
<tjaalton> tball: it doesn't need those
<tjaalton> options, it already uses gallium and libvdpau when available
<tball> tjaalton: It says: Failed to open VDPAU backend libvdpau_r600.so: cannot open shared object file: No such file or directory
<tjaalton> what says?
<tball> tjaalton: Sorry. vdpauinfo
<tjaalton> it's built from mesa, but looks like not enabled currently
<tball> tjaalton: So I don't need to rebuild mesa?
<tball> or do I
<tjaalton> you do
<tball> tjaalton: That leads to my initial question :) How do I set a configuration flag, when building a dep?
<tball> from xorg-edgers. Since I can't find a configuration field within the rules file
<tball> ahh forget it. Found it
<tball> Sorry for being a bit slow this morning
<tjaalton> you build mesa, not -ati
<tjaalton> and just edit debian/rules
#ubuntu-x 2014-06-30
<michiel81> Hello, anyone here that has any experience installing a usb touch controller with a resistive touch screen?
<michiel81> I got it to register touch input but somehow it won't let me calibrate it
<ogra_> did you try with xinput-calibrator ?
<michiel81> yeah
<michiel81> and added the calibration info to 10-evdev.conf
<michiel81> However the touch controller itself isn't recognized as such, when i used some command to read out /dev/input/event2 and 3 it showed me it was detected as 'tablet input'
<michiel81> So i used modprobe to add the quirks to hidusb
<michiel81> On a basic ubuntu installation it only registers 'mouse click' and no movement. After the modprobe i was able to get it to move.
<michiel81> The hid/vid of the touch controller itself are 1bfd:3050
<michiel81> When i checked the compatibility list for HID_USB it did show some devices from 1bfd (touchpack) but not the hardware id which was 3050
<michiel81> Any other tips ogra_?
<ogra_> not really ... 
<ogra_> usually the guys around here should have deeper insight 
<ogra_> probably they are all on vacation :P
<michiel81> Haha, just my luck to try this stuff now .. :)
<michiel81> Been trying things for the last week
<michiel81> it's doing my head in
<michiel81> When i first had some sort of touch response i was so happy.
<tjaalton> %config(noreplace) %{_sysconfdir}/pki/pki.conf
<tjaalton> uh?
<pepee> hi. I'm preventively reporting a bug:  https://bugs.freedesktop.org/show_bug.cgi?id=66452
<ubottu> Freedesktop bug 66452 in Drivers/Gallium/r600 "JUNIPER UVD accelerated playback of WMV3 streams does not work" [Normal,Resolved: fixed]
<pepee> http://cgit.freedesktop.org/mesa/mesa/commit/?id=5b4e2db12d9b45e898a8eb6599d928504ffd30c3
<pepee> mesa 10.2 (IIRC) disable VC1_SIMPLE and VC1_MAIN decoders in radeon, and it may cause instability if used
<pepee> anyone?
<tjaalton> fixed in utopic
<tjaalton> which has 10.2.1
<pepee> yeah, but I mean, this will, sooner or later, be reported by trusty users
<pepee> so I guess it'd be better to simply disable it
<tjaalton> make sure it'll get in 10.1.x then
<pepee> the system locks completely...
<pepee> well, radeon devs already know, but I don't know if they will backport it
<tjaalton> ask them
<pepee> http://patchwork.freedesktop.org/patch/27128/
<pepee> well, I guess it will be backported
<tjaalton> if someone does the work
<pepee> sorry for wasting your time
<pepee> I wish I could, I'm not a dev, just an user
#ubuntu-x 2014-07-02
<lolek> Hi everybody, I think I've found a bug in Ubuntu Xorg but before I'll report this I'd like to ask you for confirmation
<lolek> the problem occurs when I connect external screen, then compiz cpu usage is increased to 40-60% and the system becomes unusable
<lolek> I'm running ubuntu 14.04 with latest updates
#ubuntu-x 2016-07-09
<andoma> I've seen some problems which may or may not be related to Compiz, i'm not sure. When running an OpenGL application (anyone will do, glxgears for example) with nvidias proprietary drivers there seem to be a freeze of display updates (sometimes up to half a second) when changing focus between windows 
<andoma> Seen on ubuntu 16.04 (both with unity session and with Gnome flashback compiz-session)
#ubuntu-x 2017-07-03
<mamarley> ricotz: I forgot to mention it, but I do have 384.47 ready.  This time they are in https://launchpad.net/~mamarley/+archive/ubuntu/staging3/+packages because NVIDIA didn't release an ARM build at first and LP wouldn't let me reupload a different orig.tar.gz to the same PPA as before.  The only difference from 381.xx as far as packaging goes is that they changed the Vulkan ICD file to have the field for the driver file replaced at install time 
<mamarley> depending on whether GLVND was used or not.  I put a sed command in debian/rules to handle this.
<ricotz> mamarley, nice! will try to get to it
#ubuntu-x 2017-07-05
<mamarley> ricotz: Did you ever get around to looking at 384.47?
<ricotz> mamarley, sorry, not yet
#ubuntu-x 2019-07-01
<ricotz> tjaalton, hi :), do you know if llvm-toolchain-8 will enter bionic-updates eventually? https://launchpad.net/ubuntu/+source/llvm-toolchain-8/1:8-3~ubuntu18.04.1
<tjaalton> ricotz: yes, if someone would test the other mesa bug
<tjaalton> the release manager promised to, some time ago
<tjaalton> the original plan was to get these in early..
<tjaalton> now last mesa of the series is out and could be pushed instead
<ricotz> tjaalton, I see
#ubuntu-x 2019-07-04
<ricotz> tjaalton, hi, are you testing kernel 5.2 on eoan yet?
<ricotz> I am curious if there are reports of freezes on e.g. skylake iris 540?
<mamarley> ricotz: Not tjaalton, but I am running 5.2 on eoan on a NUC with an Iris 540 as my HTPC and I haven
<mamarley> 't had any issues with it.
<ricotz> mamarley, hi, I see, to be more precise it is a XPS13 9350 here which shows issues
<ricotz> seeing it with this build (and previous ones) https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable/+packages?field.name_filter=&field.status_filter=published&field.series_filter=eoan
<tjaalton> ricotz: nope
