#ubuntu-x 2006-07-10
<fabbione> morning guys
<fabbione> LOCK xorg-server
<fabbione> once this is done we can do drivers and so on
<fabbione> dpkg-checkbuilddeps: Unmet build dependencies: mesa-swx11-source (>> 6.4.0)
<fabbione> dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting.
<fabbione> dpkg-buildpackage: (Use -d flag to override.)
<fabbione> W T F
<fabbione> this merge is almost insanbe
<fabbione> Mithrandir: ping?
<Mithrandir> uh, what package is that?
<Mithrandir> xorg-server?
<fabbione> Mithrandir: yeah that's not the problem really
<Mithrandir> what's the problem then?  Having to get mesa merged first?
<fabbione> Mithrandir: i need you to merge xkeyboard-config: and Depends on xorg-server_1.0.2-9 or higher
<Mithrandir> why?
<fabbione> that mesa thing is just a package rename. It doesn't really bother me
<Mithrandir> xkeyboard-config should be fine as-is.
<fabbione> xkeyboard-config -> our /etc/X11/xkb
<fabbione> debian /usr/share/X11/xkb
<fabbione> i can change the server to point to our path
<fabbione> but it's another diversion
<Mithrandir> please just do that, I'm not going to move the conffiles there just yet.  It'll take a bit of time to work that bit out.
<fabbione> ok
<fabbione> new server is on the way up
<fabbione> i think i did a mistake when merging one of the first packages with a lot of C/F/R
<fabbione> the versions were too tight against our versions
<fabbione> an upload to -security or -updates would break
<fabbione> server is up
<fabbione> all drivers are basically unlocked now
<fabbione> there is one important bit we want to look at
<fabbione> Debian is using some xserver-video-all provide/depends stuff
<fabbione> our is called s/video/driver
<fabbione> the server as it is understands both
<fabbione> but we should be able to drop drivers to be in sync with Debian
<Mithrandir> xorg depends on -driver, though.
<fabbione> Mithrandir: yes, but it provides -driver-all
<Mithrandir> what provides driver-all?
<fabbione> and the server Depends: on driver-all | driver | video-all | video
<fabbione> xorg does
<Mithrandir> oh, it probably does, yes.
<fabbione> it's a meta pacakge more than a provides
<fabbione> so start changing xorg and then all drivers to provide/have -video- instead of -drivers- and i will be able to drop -drivers- from -server
<Mithrandir> sure, sounds easy enough.
<fabbione> yeps
<fabbione> it just needs to be done by who will do single drivers
<fabbione> i also strongly suggest that who does the ati driver to talk to airled and/or benh
<fabbione> since we were using a special -stable branch with extra bug fixes
<Mithrandir> then do -ati last?
<fabbione> i might..
<fabbione> or actually.. we could get it directly from 7.1
<fabbione> or the last one released standalone
<fabbione> that would be even better
<fabbione> hey Rodrigo
<rodarvus> hey fabbione
<rodarvus> you were supposed to be sleeping by now
<rodarvus> or at least suffering the effects of huge beer last night :D
<fabbione> rodarvus: it's 1 pm here :)
<fabbione> i had only 3 beers
<fabbione> but it was very hard to wake up today
<fabbione> rodarvus: a small /msg to update you
<fabbione> the server is up
<fabbione> so now you can do all driver
<fabbione> just be careful of what i pasted to you
* rodarvus reads
<fabbione> -> food
<fabbione> bbl
<rodarvus> fabbione, Mithrandir: xorg already has the machinery to understand xserver-xorg-video-*, then?
<rodarvus> so, basically
<rodarvus> add Replaces: xserver-xorg-driver-<driver>
<rodarvus> Conflicts: xserver-xorg-driver-<driver>
<rodarvus> (i.e., no need for Provides:, then)
<rodarvus> I'll be back in 20 minutes
<rodarvus> If I have the nod by then, I'll start with the drivers right away
<fabbione> rodarvus: no xorg doesn't.
<fabbione> xorg needs that change but it needs to be coordinated
<fabbione> xorg source generates a binary called xserver-xorg-driver-all that Depends: on all driver
<fabbione> that package needs to be changed to xserver-xorg-video-all
<fabbione> each driver Provides: xserver-xorg-driver
<fabbione> these need to be changed to xserver-xorg-video
<fabbione> once this is all done i can change the server to -video- only
<Mithrandir> just do the change, we don't need to transition this now.
<Mithrandir> as long as it'll all be fixed in a day or so.
<rodarvus> ok, /me proceeds with drivers
<rodarvus> it should be doable to have them all ready by the end of day today
<Mithrandir> rodarvus: how is the driver merge going?  Should I help out?
<rodarvus> its supposed to be pretty easy, but I've just started downloading stuff
<rodarvus> Mithrandir: up to you, really - maybe I can "raise the flag" if I find myself in trouble in the next two-three hours
<Mithrandir> ok, feel free to
<Mithrandir> you're doing -video, right?  I can do the few -input ones we need
<rodarvus> sure, great
<Mithrandir> fabbione: I'm grabbing -evdev
<fabbione> Mithrandir: go ahead
<fabbione> it's all your
<Mithrandir> lucky me. :-P
<fabbione> clearly
<rodarvus> NEW: xserver-xorg-video-apm_1.0.1.5-2ubuntu1.dsc
<rodarvus>  OK: xserver-xorg-video-apm_1.0.1.5.orig.tar.gz
<rodarvus>  OK: xserver-xorg-video-apm_1.0.1.5-2ubuntu1.diff.gz
<rodarvus> do I need to poke someone to manually accept NEW packages, or does it happen automatically?
<rodarvus> I suppose not, as they are for main
<fabbione> actually
<fabbione> we will also need to get rid of their -driver- counterparts while you switch
<fabbione> rodarvus: NEW is not an issue
<fabbione> please tell ftp-masters that all the *-video-* are the old *-drivers-*
<fabbione> so that they get accepted and sent to the proper pool
<fabbione> s/pool/component
<fabbione> keep track of all of them
<fabbione> once we get there, we will need to remove the old *-drivers-*
<rodarvus> fabbione: do I need to do that *right away*, or only after uploading all *-video-* ?
<fabbione> up to you
<fabbione> actually..
<Mithrandir> rodarvus: tell Scott and Colin about it at least, since they're the ones doing most of NEW atm.
<fabbione> hmm
<fabbione> i don't think we can force people to update to the new driver until we remove the old one from archive
<fabbione> because we don't have versioned Provide or something
<Mithrandir> it'll happen once xorg depends on the new one.
<fabbione> or we need to change the Depends: -drivers- into -video-
<fabbione> exactly
<fabbione> we can do that at last
<rodarvus> *nods*
<fabbione> so it won't be painful
<Mithrandir> hmm, the server ABI is the same still, right?
<Mithrandir> so we won't get into hilarity there?
<fabbione> 1:0.99.2+cvs.20051025-1 <-old
<fabbione> 1:0.99.2-1 <-old
<fabbione> make the last one new
<fabbione> but it's the same abi.. i am pretty sure
<fabbione> we carry the same patches
<Mithrandir> let's hope so.
<fabbione> on the same source
<fabbione> i am running it
<fabbione> if it was different it would have exploded
<Mithrandir> not necessarily.
<fabbione> well it's even the same .orig.tar.gz
<fabbione> md5sum checked :)
<Mithrandir> true.
<fabbione> and same patches
<Mithrandir> we'll see if it all blows up or not, then.
<fabbione> so i don't see how it could break the abi
<fabbione> exactly
<Mithrandir> it'll for 7.1, iirc.
<fabbione> yes mostlikely
<fabbione> Mithrandir: do you have any idea at what speed 7.1 is entering experimental?
<Mithrandir> not really.
<Mithrandir> I've been looking for gravity for the last few days, but he has eluded me.
<rodarvus> -apm, -ark, -chips, -cirrus, -cyrix, -dummy uploaded as NEW
<rodarvus> LOCK on -fbdev, -glint, -i128, -740, -810
<rodarvus> (all updated on x-pkgs)
<rodarvus> -fbdev, -glint, -i128, -i740 uploaded as NEW
<rodarvus> working on -i810 now
<fabbione> hmmm
<fabbione> i am a bit puzzled
<fabbione> most of these drivers don't have patches
<fabbione> what are you merging exactly?
<rodarvus> Added Conflicts:, Replaces: xserver-xorg-driver-glint
<rodarvus> for most of them is basically this
<fabbione> oh right
* fabbione HEAD -> WALL
<rodarvus> possibly sync would be better to describe the changelog entries
<fabbione> yeah
<fabbione> we will be able to sync sometimes after we will do a new LTS release
<fabbione> because i assume we don't want dapper customers to have to go trough edgy[0..N]  to get to a new LTS version
<rodarvus> at least I hope they won't ;)
<fabbione> so we will need to support dapper -> new LTS version direct update.. i guess
<rodarvus> for sure
<fabbione> if that's the case we need to keep this stuff around for a long time
<rodarvus> given the timeframe of LTS support, "forever"
<fabbione> almost
<rodarvus> fabbione: do you remember package changes from 5 years ago? :)
<fabbione> rodarvus: no, that's why a proper changelog is important
<rodarvus> I agree
<fabbione> we should probably write the changes somewhere we can look at in 5 years
<fabbione> or who for us can look them up
<fabbione> not that i care if somebody will replace me
<fabbione> it will suck to be them..
<ogra> launchpad ....
<fabbione> xserver-xorg-driver-apm (rodarvus, NEW xserver-xorg-video-apm)
<fabbione> xserver-xorg-driver-ark (rodarvus, NEW xserver-xorg-driver-ark)
<rodarvus> I'm writing all changes to the changelog - you mean write them somewhere else (such as wiki), so they know exactly all kinds of quirks they'll have to support for "lts 2"?
<fabbione> spot the error ;)
<rodarvus> haha
<rodarvus> what error? :)
<rodarvus> argh
<ogra> :)
<fabbione> rodarvus: i think we should just take notes that the changes we kept in dapper -> edgy are the same that we will need to preserve between dapper and LTS 2
* rodarvus bangs head against wall repeatedly
<ogra> shit happens
<fabbione> ahahha
<fabbione> rodarvus: you fixed the only good one :OP
<rodarvus> x-pkgs fixed
<rodarvus> fabbione: yeah, thats why I blowed my head against the wall :)
<fabbione> rodarvus: there are 2 drivers you want to skip for now... -ati and sunffb iirc
<fabbione> ati for sure.. sunffb i need to check
<rodarvus> nods
<rodarvus> but note that sunffb is not present in debian, I think
<fabbione> yes it is
<fabbione> for the ati one i need to speak with benh and airlied on #xorg-devel
<fabbione> because our source was made up a -stable bug fix only cvs branch
<fabbione> and i need to make sure debian has our fixe
<fabbione> +s
<fabbione> for the sunffb the one we have works
<fabbione> the one from xorg doesn't
<fabbione> so we might want to preserve that source
<rodarvus> sure
<fabbione> rodarvus: how are you doing with the merges?
<rodarvus> fabbione: halfway done
<rodarvus> its very likely that I'll have all video synced today
<fabbione> rodarvus: ok, just remember that the 13 of July is deadline for merges
<fabbione> and we need to finish by that time
<rodarvus> *nods*
<rodarvus> actually, I was thinking about this earlier today
<rodarvus> the deadline for merges basically means its going to be very hard to get X7.1 into Edgy
<fabbione> let's worry about one thing at a time. We need to merge ASAP
<fabbione> 7.1 might come as UVF exception
<rodarvus> fabbione: merges/syncs are my current worry - as I said, it was just a thought :)
<fabbione> rodarvus: yeps... let's worry about one thing at a time for now
<fabbione> jumping from 7.0 to 7.1 can probably be done in half day
<rodarvus> (just for reference)
<rodarvus> -Package: xserver-xorg-driver-newport
<rodarvus> -Architecture: any
<rodarvus> +Package: xserver-xorg-video-newport
<rodarvus> +Architecture: alpha amd64 arm hppa hurd-i386 i386 ia64 kfreebsd-i386 m68k mips mipsel netbsd-i386 powerpc
<fabbione> yeah that's ok
<fabbione> tho it builds also on sparc...
<fabbione> or there are more?
<fabbione> anyway it's fine as it is
<fabbione> we can sort out the arch mess (if any) later on as bug fixing
<rodarvus> changelog is here:
<rodarvus>    * Don't build on sparc. Partial port of
<rodarvus>      sparc/103_sparc_dont_build_useless_drivers.diff.
<rodarvus> xserver-xorg-driver-nv is newer than xserver-xorg-video-nv
<rodarvus> I'll merge their debian/ directory into our package
<rodarvus> fabbione: what is your feeling about our packaging having non-dfsg-compliant code?
<rodarvus> this is currently the case for (at least) -mga and -rendition
<rodarvus> debian strips the non-free code of them, for reference
* rodarvus plays safe
<rodarvus> we can add this code on a later release if so agreed
<fabbione> do not strip it
<fabbione> leave it there
<rodarvus> oh
<rodarvus> I uploaded it as NEW (stripping the source code)
<rodarvus> I'll ask Kamion & Keybuk to reject upload of -rendition and -mga, and reupload them with the binary blobs
<rodarvus> just for reference, -tga is also not built on sparc anymore
<rodarvus> family time, I'll be back later to merge/sync the rest of the drivers
#ubuntu-x 2006-07-11
* rodarvus is about to crash
<rodarvus> guys, status update so you can continue tomorrow morning ;)
<rodarvus> all xserver-xorg-driver-* NEW packages are uploaded, but with a few considerations:
<rodarvus> 1. I haven't received any email about -ati (nor it shows on my "uploaded package list" - don't know why
<rodarvus> 2. it was possible to almost-merge -ati, keeping only a small patch (the rest of the changes was already present on debian package, which was newer version)
<rodarvus> 3. -sunffb has our source code, as agreed with fabbione
<rodarvus> 4. -mga and -rendition are dfsg-compliant. talking with fabbione on #ubuntu-x earlier today, fabbione says this is not necessary - in this case I believe we should Reject these two packages from NEW and reupload them, with binary blobs included
<rodarvus> I asked mdz to Reject them for me, but no news yet (up to you guys, if you want to reupload them before I arrive - I can do that tomorrow morning, but will be in UTC-3 timezone)
<rodarvus> anyhow, x-pkgs is updated, as usual - I believe we can move on and update xorg, plus accept the *-video-* packages
<rodarvus> good night all :)
<fabbione> somebody wants to look at #52538
<fabbione> i can't reproduce it here and i am not feeling good
<fabbione> so i am going to crash in bed right now
<fabbione> bah there fixed
!lilo:*! hi all....harassment attack on tor connections....new connects are mostly blocked atm
!lilo:*! apologies for the inconvenience
!lilo:*! (the problem only affects tor connects....apologies for the inconvenience, and thank you for your patience)
<Kamion> rodarvus: rejected -mga and -rendition at your request
<Kamion> rodarvus: shouldn't xserver-xorg-video-s3 provides: xserver-xorg-video?
<Kamion> (not a NEW blocker though)
<Kamion> rodarvus: ditto -sunffb
<rodarvus> good morning
<rodarvus> Kamion: thanks for the approvals and rejects
<rodarvus> you're right, -s3 and -sunffb are supposed to have Provides: xserver-xorg-video
<rodarvus> I'll upload new releases of them in a minute
<rodarvus> (and prepare NEW -mga & -rendition too)
<Mithrandir> rodarvus: have you begun looking at -input-* yet?
<rodarvus> Mithrandir: no, I plan to do that in one hour, likely, as soon as I finish with *-video-*
<rodarvus> (probably less time)
<rodarvus> strange, xserver-xorg-video-ati really didn't show up on NEW, nor I received any email about it (yes, I have the .upload here :) )
<Mithrandir> ok, goodie.
<Kamion> rodarvus: http://librarian.launchpad.net/3336896/shhSW96LMQZLlmZi4xaLb3Kx0JK.txt
<Kamion> which is bizarre
<Kamion> oh, you're already looking into it on ##soyuz1.0, ok
<rodarvus> Kamion: soyuz says the package wasn't signed, which is quite strange - as package signing is an automatic part of the build
<Kamion> right
<Kamion> well, no, it doesn't say it wasn't signed, it says it can't find the public key
<rodarvus> anyway, I'm rebuilding it now, and will double check it is correctly signed before the new upload
<rodarvus> even worse :)
<rodarvus> I only have one private key here
<Mithrandir> so, what's the plan for the fonts mess?  Move fonts, make them depend on the newer server where the paths are hard coded and then update everything else?
<fabbione> Mithrandir: you can either leave them where they are or move them
<fabbione> we could just hardencode in the server the different paths we did use in the past
<Kamion> I'd move them and leave a transitional symlink behind
<fabbione> and clean up the configs
<Kamion> or what fabbione sai
<Kamion> d
<fabbione> Kamion: no need of a symlink
<fabbione> i did check it here
<Kamion> yeah, that might be less pain than a symlink
<Mithrandir> ok, let's hardcode the paths for now.
<Kamion> server> and libfontenc or whatever it is
<Mithrandir> unless somebody complains?
<Mithrandir> fabbione: is it trivial to find where it's hardcoded or can you do it?  (Yes, I realise you're sick ATM)
<Kamion> I definitely merged some library that had a hardcoded font path
<fabbione> i see no point in complaining. it's like adding another set of Path in the config
<fabbione> they just get skipped if non-valid or empty
<fabbione> Mithrandir: yes, it's really easy. there is already a patch in debian/patches for that
<fabbione> Mithrandir: and yes i would love to go back to sleep
<Mithrandir> fabbione: ok, cheers.  Go back to sleep, then
<fabbione> Mithrandir: but you can start doing the transition. How has this server has both paths already
<fabbione> either in the config
<fabbione> or hardcoded
<fabbione> once we finish the transition you can clean up dexconf to not write them at all
<fabbione> or write them both and remove the hardencoding
<fabbione> or any combination
<fabbione> anyway
* fabbione &
<Mithrandir> anyway, the fonts will be built-in soon so the server won't have to care.
<rodarvus> Kamion: I've seen you approved -ati already, thanks
<rodarvus> I also uploaded -s3 and -sunffb with correct provides
<rodarvus> (they were already accepted too)
<rodarvus> and finally, -mga & -rendition, which are sitting in NEW
* Mithrandir wonders why his xfonts-base suddenly didn't contain any files.
<Kamion> hmm, there's an argument that the microcode in those drivers should live in restricted
<Kamion> but it's an argument I don't really care to have right now
<Kamion> that way lies a big smelly can of worms
<rodarvus> Kamion: *nods*, thats why I "played it safe" in the first upload
<rodarvus> Mithrandir: did you touched any of the *-input-* packages?
<rodarvus> (apparently at least -mouse and -evdev were uploaded)
<Mithrandir> rodarvus: I did those two merges yesterday, yes.
<rodarvus> Mithrandir: do you mind if I continue with the rest? (or you plan to do them yourself?)
<Mithrandir> no, please do
<rodarvus> I will
<rodarvus> am I the only one with uninstallable package 'xorg'?
<rodarvus> (which in turn is depending on old xfont-* packages + libgl1-mesa-glx)
<rodarvus> if not, is anyone else already working on fixing this?
<rodarvus> build on sparc failed for xserver-xorg-video-newport and xserver-xorg-video-i810 -> https://launchpad.net/+builds/+build/226238 and https://launchpad.net/+builds/+build/226253
<rodarvus> but both packages above don't even have "sparc" in the list of architectures to be built on (and this is on purpose)
<rodarvus> do we need to blacklist build of these packages on sparc somewhere else, or just let it be this way?
<Mithrandir> no, you're not the only one.
<Mithrandir> yes, they'll need to be added to a blacklist.  Just ignore that for now.
<Kamion> the blacklist in question is called Packages-arch-specific (or PaS); infinity can edit it for you when he's aroun
<Kamion> d
<rodarvus> Mithrandir: and regarding fonts, are you (or someone else) working on them?
<Mithrandir> I was planning on starting with them unless you beat me to it.
<rodarvus> I'm working on *-input-* now, but can change to fonts if its more urgent
<Mithrandir> nah, just do -input-* first.
<rodarvus> ok
<rodarvus> Kamion: I'll ask inifinity when he's around, thanks!
<Mithrandir> ok, I have a patch which codes in the correct font path, including legacy paths.
<Kamion> libraries too?
<Mithrandir> doing the server first, but I'll poke the library while the server's compiling
<Mithrandir> meh, it'll change the API of libfontenc.
<Mithrandir> but then , libfontenc just cares about the encoding directore.
<Mithrandir> directory, even
<Kamion> maybe that can be flag-dayed
<Kamion> (ugh)
<rodarvus> -acecad, -aiptek, -calcomp, -digitaledge manually synced (and uploaded). -citron automatic sync requested
<rodarvus> LOCK on the next five input drivers
<Mithrandir> Kamion: I wonder if all accesses to encodings is going through libfontenc or not..
<Mithrandir> the server itself doesn't seem to care.
<rodarvus> -dmc, -dynapro, -elographics, -fpit, -hyperpen manually synced (and uploaded)
<rodarvus> LOCK on the rest of the xserver-xorg-input-* packages
<rodarvus> (all updated on x-pkgs, just in case)
<rodarvus> Mithrandir: ping
<rodarvus> I'm merging xserver-xorg-input-synaptics now
<rodarvus> debian has a new upstream version (0.14.5) and we have 0.14.3
<rodarvus> but we have a patch specific for ALPS devices, which is not applied (at least not completely)
<rodarvus> into their version
<rodarvus> do you suggest we manually merge this patch, or leave it for now?
<rodarvus> also note that, if we do merge, I won't be able to test it myself
<rodarvus> fabbione, Kamion, Mithrandir: is any of you against me doing the move from xserver-xorg-driver-all to xserver-xorg-video-all? If so, please say something in the next three hours :)
<rodarvus> otherwise, I plan to upload xorg-7.0.22ubuntu2 (with this change) at 20:10 UTC
<rodarvus> btw, I have already opened the support request to move bugs from *-driver-* to *-video-*
<rodarvus> https://launchpad.net/products/malone/+ticket/1179
!lilo:*! more GNAA-style denial of Tor connections through abuse of the facility....new connections are currently suspended
!lilo:*! apologies to our regular tor users for the difficulties
<rodarvus> xorg_7.0.22ubuntu2 uploaded (as per instructions of mdz)
<rodarvus> libxfont-1.0.0-4ubuntu2 (compiled with FreeType 2) uploaded too
<rodarvus> xserver-xorg-input-synaptics sync requested
<rodarvus> if necessary, we can add our alps patch (or parts of it) again later
#ubuntu-x 2006-07-12
<Kamion> xorg accepted
<fabbione> rodarvus: before killing -driver- we need to change also fglrx and nvidia
<fabbione> s/we/you :P
<Mithrandir> rodarvus: how's the mesa merge coming along?
<fabbione> Mithrandir: how is the xfonts merge coming?
<fabbione> xorg depends on xfonts-base (>= 1.0.0-1)
<fabbione> but the latter is not there
<Mithrandir> I know, working on it, but I want to test the full stack locally before uploadin
<Mithrandir> +g
<fabbione> yup..
<Mithrandir> the X server is done, I think, but xfonts-100dpi FTBFS for some reason.
<fabbione> fair enough :) i was only asking
<fabbione> ok...
<Mithrandir> rodarvus_: 11:41 < Mithrandir> rodarvus: how's the mesa merge coming along?
<fabbione> hmmm
<fabbione> xserver-xorg-video-all(sparc)
<fabbione> i am pretty sure i know why
<fabbione> some drivers are not built on sparc anymore
<Mithrandir> just fix that and upload xorg, then?
<fabbione> yes i need to figure first what's missing :)
<fabbione> apt-get has been sucking 100% of CPU for a while now :)
<Mithrandir> GRRRRRRR
<Mithrandir> xfonts-encodings build-deps on xfonts-utils and xfonts-utils depends on xfonts-encodings.
<Kamion> yep, needs manual bootstrap
<Mithrandir> nope, should be fine.
<Mithrandir> dapper's xfonts-utils contains mkfontscale which is what's needed.
<Kamion> ah ok
<Mithrandir> so, if I change libfontenc to use the new encodings path + conflict with the current xfonts-base, we should be fine?  We should then be able to just sync xfonts-*, including -utils and -encodings.
<Mithrandir> does that sound semi-sane?
<fabbione> Mithrandir: #52737 is for you :)
<Mithrandir> *shrug*.  Such bug reports are so useless at this time.
<fabbione> no shit :)
<fabbione> xorg needs to drop video-tga and video-newport on sparc to be installable again
<fabbione> can i take i lock on those?
<fabbione> on xorg
<fabbione> or is somebody working on it?
<Mithrandir> please do
* fabbione does
<Mithrandir> fabbione: do you know which tool is responsible for writing out the fonts.cache-1 files?
<Mithrandir> oh, we need to fix fontconfig too. :-/
<fabbione> fc-cache ?
<fabbione> me and fonts are like satan and the holy water
<fabbione> i am dropping -drivers- from xorg-server too
<fabbione> so the upgrade to the new one is forced
<Mithrandir> fine
<fabbione> there done
* Mithrandir crosses his fingers and hopes this doesn't blow up in interesting ways.
<fabbione> ok all done my side
* Mithrandir grumbles
<Mithrandir> fc-cache and update-fonts-dir leaves droppings in the fonts dirs.
<rodarvus_> good morning
<rodarvus_> fabbione: I'll change fglrx and nvidia this morning (probably first thing in my queue)
<rodarvus_> Mithrandir: it seems infinity wanted to merge mesa, so I was waiting for him to join irc to talk to him if he is still interested (or even already working) on mesa
<rodarvus_> if not, I'll do it as soon as I have an answer from him
* Mithrandir ponders how to attack this problem
<fabbione> rodarvus: they are not urgent.. just coordinate it with infinity
<rodarvus> fabbione: *nods*
<rodarvus> do you know if he gave any signs of life today already?
<fabbione> i didn't see him around no
<rodarvus> indeed, I couldn't find him either
<rodarvus> hope all is well
<Mithrandir> ok, libfontenc uploaded again
<rodarvus> btw, I mentioned this in #ubuntu-devel but I think I forgot to mention here, so here goes
<rodarvus> yesterday I uploaded a version of libxfont, with a patch (which was also added to the unstable branch)
<rodarvus> to compile it with FreeType 2.2
<rodarvus> local tests said it works fine, but of course, I'm no libxfont or freetype expert
<rodarvus> debian was not bitten by this problem because they upgraded to freetype after last recompilation of libxfont 1.0
<rodarvus> also, btw, libxfont 1.1+CVS is already uploaded to experimental, as part of XOrg 7.1 migration
<Mithrandir> ok
<Mithrandir> If I happened to put:
<Mithrandir> http://paste.ubuntu-nl.org/17819 in xfonts-utils.postinst.  Would anybody be sorry?
<Mithrandir> I think that's all we need in the way of migration, really.
<Mithrandir> apart from that, I think we can sync xfonts-* from Debian then.
<Kamion> xfonts-encodings synced and newed
<Mithrandir> cheers
<rodarvus> I have an Edubuntu meeting (first one with Richard Weideman) in two minutes - I'll be mostly not paying attention to other stuff for the next hour
<Mithrandir> ok
<Mithrandir> ok, new xfonts-utils uploaded.  Let's cross fingers and hope all this works well
<rodarvus> Hooray!
<fabbione> rodarvus: how is going the mesa merge?
<fabbione> rodarvus: it's the only big one left that i can see in the merge list for X
<rodarvus> fabbione: its not, yet
<rodarvus> first thing on my todo list, though
<rodarvus> I guess I'll just proceed with it, without talking with infinity :/
<fabbione> please do
<fabbione> we will review the package all together
<fabbione> and let's get over it
<rodarvus> I'm still doing Edubuntu work for the next 20-30 minutes, but will get to it ASAP
<fabbione> thanks
<rodarvus> no, thank YOU
<rodarvus> quick reboot, I'll be right back
<fabbione> rodarvus: ping mesa?
<Kamion> so, er, Mithrandir apparently forgot to actually make that change
<Kamion> (xfonts-utils)
<Kamion> the interdiff only has the changelog
* Kamion copies and pastes it from paste.ubuntu-nl.org
<Kamion> yay professional code handling practices ;-)
<rodarvus> fabbione: I'm preparing lunch, will continue the merge as soon as I return
<Kamion> ok, xfonts-utils going up again now
<rodarvus> fabbione: just to keep you informed - I'm working on the mesa merge, but it is surely not something I'll be able to deliver in "half an hour"
<rodarvus> its probably work for two, maybe three hours for a first draft version
<fabbione> rodarvus: yes i could guess that, but we to get it done before the meeting tomorrow
<rodarvus> *nods* I agree
<Kamion> is xfonts-scalable going away? it's the last thing generated by xfonts-core
<Kamion> and I don't think I've seen it go by
<Kamion> oh, no, it's in unstable, new source
<Kamion> mind if I sync it?
<Kamion> syncing ...
<fabbione> Kamion: no idea... flip a coin
<Mithrandir> Kamion: gah.  I suck.
<Mithrandir> Kamion: also, thanks.
<Kamion> no worries
<Mithrandir> well, I'm off to read a book on the couch, or something.
<rodarvus> oh
<rodarvus> fun stuff
<rodarvus> shader/arbprogparse.c:3864: internal compiler error: Segmentation fault
<rodarvus> Please submit a full bug report,
<rodarvus> with preprocessed source if appropriate.
<rodarvus> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
<rodarvus> For Debian GNU/Linux specific bug reporting instructions,
<rodarvus> see <URL:file:///usr/share/doc/gcc-4.1/README.Bugs>.
<Mithrandir> rodarvus: You Are Winn0r.
<rodarvus> any idea how long mesa builds are supposed to last on a reasonably current machine?
<Mithrandir> https://launchpad.net/+builds/+build/190768 claims vernadsky used 25 minutes.
<rodarvus> its taking huh... longer than that here :)
<fabbione> rodarvus: mesa is like an elephant :)
<rodarvus> fabbione: just a status update - I'm only doing a local test build, to check if everything builds (and works) as expected
<fabbione> rodarvus: i am fine with that
<rodarvus> if all goes well, I'll be able to upload to people.ubuntu.com the debdiffs for you guys to take a look
<fabbione> it appears we don't have that many hours left, but you want to ask mdz
<rodarvus> ok, merged mesa is available at -> http://people.ubuntu.com/~rodarvus/mesa/
<rodarvus> debdiff from debian is http://people.ubuntu.com/~rodarvus/mesa/mesa_6.4.1-0ubuntu8-to-mesa_6.4.2-1ubuntu1.patch.gz
<rodarvus> debdiff from ubuntu is http://people.ubuntu.com/~rodarvus/mesa/mesa_6.4.2-1-to-mesa_6.4.2-1ubuntu1.patch.gz
<rodarvus> (second one is rather large, though, as its a different upstream version)
<rodarvus> fabbione: please take a look there, if you are still online :)
<fabbione> rodarvus: yes.. in a few minutes.. please ask also on -devel to look at it
<rodarvus> I will
<fabbione> rodarvus: i was told it was a difficult merge, so more eyes > *
<rodarvus> it wasn't soooo hard, actually
<rodarvus> unless I missed something obvious
<fabbione> rodarvus: you missed the obvious... :)
<rodarvus> !!
<fabbione> old: mesa-swrast-source
<fabbione> new: mesa-swx11-source
<rodarvus> its not replacing/conflicting the old package?
<fabbione> same for a big bunch of other binaries and libs
<fabbione> Package: mesa-swx11-source
<fabbione> Section: libdevel
<fabbione> Architecture: all
<fabbione> Description: Mesa software rasteriser source -- development support files
<fabbione> nope
<rodarvus> fabbione: for the libs its supposed to be there
<fabbione> right
<fabbione> sorry..
<rodarvus> debian/control & debian/changelog updated
<fabbione> i can't see anything else wrong
<fabbione> it looks ok here
<fabbione> your call for an upload
<fabbione> and make sure to be around for the next few hours after the upload
<fabbione> or users will start to knock on your front door
<rodarvus> :)
<rodarvus> haha
<rodarvus> I will
<rodarvus> fabbione: thanks a lot!
<fabbione> rodarvus: no problem at all dude...
<rodarvus> fabbione: oh
<rodarvus> I forgot to ask you one question
<fabbione> go ahead
<rodarvus> you mentioned earlier today (or yesterday, I forgot)
<rodarvus> that I needed to update the binary drivers for ati and nvidia
<rodarvus> which packages are these?
<fabbione> rodarvus: it's linux-restricted-modules-2.6.17
<rodarvus> I totally forgot to do them before
<rodarvus> glup
<fabbione> it's a PITA package
<fabbione> let's look at it tomorrow
<fabbione> it's not urgent as i said
<rodarvus> *nods*
<rodarvus> thanks again
<rodarvus> and have a goog night!
<fabbione> goog? cool .. i will ;)
<rodarvus> good :)
<rodarvus> haha
#ubuntu-x 2006-07-13
[xur1z(n=chris@60.234.164.212)]  help
<rodarvus> fabbione: I'm curious to know what exactly have you changed to let mesa build without lesstiff support
<rodarvus> that build system looks really non-intuitive
<fabbione> rodarvus: kill the B-D and Depends. remove glw- reference from debian/libmap.dir (or something like that)
<fabbione> there was also the option to remove the entries from debian/rules but that would have exploded in future merges
<rodarvus> oh, I didn't changed debian/libmap.dir
<fabbione> rodarvus: that's how i noticed it
<rodarvus> fabbione: oh, btw I also would like to prepare nvidia and ati binary drivers as first task for today
<fabbione> there is the debian/README-you-stupid-maintainer-that-wants-to-do-customs ;)
<fabbione> note that i saw that after modifying everything possible before :P
<rodarvus> haha
<fabbione> rodarvus: looking at the nvidia and fglrx stuff
<fabbione> rodarvus: ok i have done l-r-m
<fabbione> l-r-m as in linux-restricted-modules
<fabbione> that has nvidia and fglrx
<rodarvus> nice, thanks!
<rodarvus> I'll want to see the debdiff of this change as soon as its available on the archive :)
<fabbione> cocktastic
<fabbione> pitti did upload -4 as me
<fabbione> now i need to wait for his -4 to propagate and upload -5
<fabbione> Setting up xorg (7.0.22ubuntu3) ...
<fabbione> Setting up x-window-system-core (7.0.22ubuntu3) ...
<fabbione> root@gordian:~#
<fabbione> so afaict mesa and fonts are ok now
<fabbione> modulo ppc and sparc that are missing mesa
<rodarvus> *nods*
<rodarvus> just for reference, debian has most (but 4) of our x apps inside xbase-clients
<rodarvus> if we decide to merge with them, we'd just need to conflicts/obsolete these packages and adopt xbase-clients
<fabbione> rodarvus: how many of them are newer than the ones we have?
<rodarvus> the other 4 apps need no manual merge (they have basically the same content here and there)
<fabbione> meaning.. is it worth to do it?
<rodarvus> fabbione: about twelve, I think
<rodarvus> the main reason for doing this is that we'd basically never have trouble maintaining these packages again in the future :)
<fabbione> right
<rodarvus> they also have patches for some of these applications
<fabbione> well just do it
<fabbione> make sure you look into other packages too
<fabbione> iirc source: xorg has a dummy package called xbase-clients
<fabbione> that depends on the splitted ones we have
<rodarvus> yes, it has
<fabbione> so the transition needs to be done properly
<rodarvus> we'd need to upload xorg together with the new xbase-clients
<rodarvus> ok, I'll try to have everything ready for upload as soon as Knot 1 is uploaded
<rodarvus> (shouldn't be hard at all, actually)
<fabbione> yeps
<fabbione> no, but we have some Depends: Conflicts: Replaces all around for the split
<fabbione> so joining them again might be interesting
<rodarvus> is it doable at all?
<fabbione> yes it is
<fabbione> it's just a matter of making sure that the upgrade path is clean
<rodarvus> good :)
<Mithrandir> yeah, please just get the apps merged; we shouldn't need to ever touch those again.
<rodarvus> fabbione: regarding xserver-xorg-input-elographics (just to make sure I'm not doing something wrong) I'll check if it is seeded in the correct places (with the other main -input- drivers)
<rodarvus> and update xsever-xorg-input-all to depend on it (which is not the case currently)
<rodarvus> right?
<fabbione> rodarvus: there was xorg depending on it.
<fabbione> only on i386
<fabbione> be careful that you don't need it for all arches
<fabbione> but yeah do as you feel it's best
<fabbione> (after knot 1 is out)
<rodarvus> xorg is not depending on it, (on the current version at least)
<rodarvus> just rebuilt it locally minutes ago to test
<fabbione> source: xorg
<fabbione> and the Depends: are arch dependent
* fabbione -> bed
<fabbione> good night
<rodarvus> fabbione: good night!
#ubuntu-x 2006-07-14
* IRCD=dancer CAPAB CHANTYPES=# EXCEPTS INVEX CHANMODES=bdeIq,k,lfJD,cgijLmnPQrRstz CHANLIMIT=#:20 PREFIX=(ov)@+ MAXLIST=bdeI:50 MODES=4 STATUSMSG=@ KNOCK NICKLEN=16 :are supported by this server 
* SAFELIST CASEMAPPING=ascii CHANNELLEN=30 TOPICLEN=450 KICKLEN=450 KEYLEN=23 USERLEN=10 HOSTLEN=63 SILENCE=50  are supported by this server
-NickServ(NickServ@services.)- This nickname is owned by someone else
-NickServ(NickServ@services.)- If this is your nickname, type /msg NickServ IDENTIFY <password>
* [#canonical-support]  Bad channel key
* #ubuntu-server  You can't join that many channels
-ChanServ(ChanServ@services.)- [#ubuntu]  Welcome to #ubuntu! Please have a look at the FAQ: http://wiki.ubuntu.com/CommonQuestions
!alindeman:*! Hi all!  The splits that just occured were my fault--I caught a file being unsafely written at an intermediate point and generated an invalid configuration file, causing some servers to fail.  Everything was restored quickly, but if you notice problems, please /msg an on-duty staffer in /stats p
#ubuntu-x 2007-07-09
<ubotu> New bug: #47880 in xorg (main) "Boot fails after loading kernel, black screen during install Dapper" [Medium,Incomplete]  https://launchpad.net/bugs/47880
<ubotu> New bug: #48199 in xorg (main) "multimon crashes Xorg" [Medium,New]  https://launchpad.net/bugs/48199
<ubotu> New bug: #48367 in xserver-xorg-driver-i810 (main) "Too much red on TV or any video avi/mpeg" [Medium,Incomplete]  https://launchpad.net/bugs/48367
<ubotu> New bug: #56813 in xorg (main) "During install get blackscreen" [Medium,Incomplete]  https://launchpad.net/bugs/56813
<ubotu> New bug: #124946 in xserver-xorg-video-intel (main) "DVI modes set wrongly (and weirdly: 640x481!), worked in 2.0.0-1feisty1" [Undecided,New]  https://launchpad.net/bugs/124946
#ubuntu-x 2007-07-10
<ubotu> New bug: #118453 in Ubuntu "intermittent hangs - white screen only (dup-of: 109643)" [Undecided,New]  https://launchpad.net/bugs/118453
<ubotu> New bug: #120262 in xorg (main) "Genius Tablet (used to work as wacom) does not work anymore on hotplug" [Undecided,Confirmed]  https://launchpad.net/bugs/120262
<ubotu> New bug: #125116 in xserver-xorg-video-amd (universe) "please sync from Debian unstable to Gutsy (universe)" [Undecided,New]  https://launchpad.net/bugs/125116
<jcristau> fwiw, i think xserver-xorg-video-nv 1:2.1.2-2 should be syncable
<ubotu> New bug: #125128 in xserver-xorg-video-intel (main) "display is blurry and too tall at 400 x 1050" [Undecided,New]  https://launchpad.net/bugs/125128
#ubuntu-x 2007-07-11
<ubotu> New bug: #125217 in xserver-xorg-video-ati (main) "beryl freezes when 24bit depth used" [Undecided,New]  https://launchpad.net/bugs/125217
<ubotu> New bug: #124761 in xorg (main) "[gutsy alternate tribe2 cd]  Although a 16 Bit resolution is chosen in installer menu, xorg tries to use 24 Bit" [Undecided,New]  https://launchpad.net/bugs/124761
<bryce_> heya tepsipakki, I'm guessing you're still tied up with school and such, but I'd like to chat with you some time about the xorg 7.3 work.  I've been looking at updating the xorg and libx11 packages, so would like to get your thoughts there.
<bryce_> tepsipakki, also, I wanted to check on your own plans, since I worry I must be stepping on toes here, and would like to coordinate with you better
<tepsipakki> bryce_: hey.. yeah, I'll continue my vacation tomorrow, so it's been quite busy at work for the past week, trying to make sure our feisty-installations work well :)
<tepsipakki> besides, I think you don't have to worry about other peoples' toes :)
<tepsipakki> but libx11.. on feisty it doesn't use the xcb-stuff at all, because of the problems we hit back then
<bryce_> ah yes
<tepsipakki> but most of them should be sorted by now
<bryce_> ok; I've gone through the libx11 update mostly, and just need to go through patches
<bryce_> so any advice on patches would be appreciated
<tepsipakki> I think java is the one that breaks without any patches, rest should be fine by now
<bryce_> I saw at least one is upstream (the security patch)
<tepsipakki> hmm, jcristau is not here now
<bryce_> I see he's been busy with lots of new packages, so most of the new things on my todo list 
<bryce_> I can just pull from debian :-)
<tepsipakki> java apps crashed having an assertion failure, so libx11 was patched because of that (and then later changed not to use xcb at all)
<tepsipakki> yeah
<tepsipakki> he should know better where debian is with libx11/xcb/java
<tepsipakki> the problem is a static library inside java, and the current package in debian should have a script which patches java to not use it or something
<tepsipakki> but that can't be done for the user in the package
<bryce_> ah
<tepsipakki> the current xorg-server in debian has a patch which should fix the vesa-crashes on r5xx hardware
<tepsipakki> that and dropping the patch I added for vesa
<bryce_> I hear 1.3.99 is coming soon
<tepsipakki> which is from fedora (mode-heuristics or something), but it quite doesn't work right. without it should be fine for most
<tepsipakki> yes, that's way cool
<bryce_> excellent, I'll take a peek at that r5xx patch; I know there's quite a few bug reports on that
<tepsipakki> damn, missed lunchtime (crappy selection here during summer.. every place closes at 14)
<bryce_> oops
<tepsipakki> well, there are two grocer's nearby.. I'll manage :)
<bryce_> btw, I started a thread on ubuntuforums.org for xorg testing
<bryce_> it attracted some attention, but I think more recruitment is needed
<tepsipakki> also, I'm waiting for the x11-xsession-utils to pass NEW, then the x11-* packages are uploaded to unstable, and perhaps in ubuntu too (replacing all the individually package apps)
<tepsipakki> yes I noticed
<tepsipakki> I haven't used the forums much
<tepsipakki> ..at all, to be precise :)
<bryce_> yeah I'm not really a forums person myself
<bryce_> however it appeared that that's where the audience was, so figured I'd give it a shot
<bryce_> do you know if there is already a ubuntu-x mailing list somewhere?
<tepsipakki> the "r5xx" patch for the server is the 41_vbe_filter_less.diff, which makes the server not to drop modes too early before they have a chance being validated
<tepsipakki> no mailing list, maybe it would be useful
* bryce_ nods
<bryce_> I'll plan on looking into setting one up
<tepsipakki> nice
<bryce_> I'm also planning on learning how to use the new PPA system for posting proposed .debs for folks to test
<tepsipakki> PPA? I've missed that one
<bryce_> "personal package archives" - it's in beta.  It seems to be like posting debs to your people.ubuntu.com/~name/ space, but more formalized.  It's in beta, but I've had several people suggest using it
<tepsipakki> oh, cool
<tepsipakki> about my plans; I'll continue pushing the changes (especially in xorg-the-package) to debian, and hopefully starting bugwork again in August..
<tepsipakki> but the next three weeks I'll be offline ;)
<tepsipakki> err, two actually
<bryce_> heya jcristau 
<bryce_> tepsipakki, sounds good
<bryce_> tepsipakki, this is fine; my plans for coming weeks are to get bulletproof-x implemented and integrated into xorg, and continue getting packages updated
<bryce_> I probably won't get much bug work done, but by August when things are frozen I'll definitely be joining you in bug hunting :-)
<jcristau> hi bryce_ 
<tepsipakki> jcristau: what's the situation with libx11/xcb for unstable atm?
<tepsipakki> and hi :)
<jcristau> hi tepsipakki 
<jcristau> tepsipakki: it needs a fix for https://bugs.freedesktop.org/show_bug.cgi?id=11390
<ubotu> Freedesktop bug 11390 in Lib/Xlib "Locking hooks not called from software built against non-XCB Xlib without XTHREADS" [Blocker,New]  
<jcristau> which is what's breaking java
<tepsipakki> oh, the ball is on xlib's court again :)
<jcristau> it took a long time to get the sun people to react, but once they did the issue was found pretty quickly
<tepsipakki> looks like it, yeah
<jcristau> the less nice part is that the bug doesn't have a trivial fix, as xlib/xcb assumes that the locking hooks are called
<tepsipakki> that's too bad
<jcristau> yeah, pretty annoying
<bryce_> what/who would it take to get this fixed?
<tepsipakki> it's already assigned, so I believe it's being worked on
<tepsipakki> since it's a showstopper
<bryce_> ok cool.
<bryce_> interesting, I didn't realize bart massey was involved in this...  I run into him a lot since we're both in Portland
<jcristau> last time i asked josh about this bug, he said this:
<jcristau> 20:22:38 < jcristau> JoshTriplett: is there any progress on https://bugs.freedesktop.org/show_bug.cgi?id=11390 ?
<ubotu> Freedesktop bug 11390 in Lib/Xlib "Locking hooks not called from software built against non-XCB Xlib without XTHREADS" [Blocker,New]  
<jcristau> 20:23:22 < JoshTriplett> jcristau: Some.  The dent in the nearest wall has become deeper, and my head has become flatter. :)
<jcristau> also, jamey got married recently, which didn't help get this fixed ;)
<bryce_> is this the correct git?  http://cgit.freedesktop.org/xcb/wiki.git/  If so, looks like the code hasn't been touched in a while
<jcristau> it'd probably be in libX11, but yeah, there's nothing new in the repo
<bryce_> hmm, looks the same here - http://gitweb.freedesktop.org/?p=xcb.git;a=summary
<jcristau> the libxcb repo is http://cgit.freedesktop.org/xcb/libxcb/ not /wiki
<jcristau> but xlib/xcb lives in http://cgit.freedesktop.org/xorg/lib/libX11/
* bryce_ nods
<bryce_> looks like Jamey Sharp has done some XCB related work recently as well
<bryce_> although like you said, nothing within the past month
<jcristau> someone needs to find how to fix the bug before pushing code out :)
<jcristau> there's also http://bugs.debian.org/429147 which has been reported recently. i've forwarded the patch to the xcb guys, so we'll see
<bryce_> ok cool, guess I'll just stay tuned
<ubotu> New bug: #122762 in xserver-xorg-video-via (main) "Please provide a 3D driver for Unichrome PRO IGP using "restricted drivers"" [Undecided,New]  https://launchpad.net/bugs/122762
<ubotu> New bug: #125269 in xorg-server "[PATCH]  Fix Xorg rendering when using a Composite Manager" [Undecided,Fix committed]  https://launchpad.net/bugs/125269
#ubuntu-x 2007-07-12
<ubotu> New bug: #18489 in xorg (main) "mice detected as imps2 not as ps2++" [Medium,Triaged]  https://launchpad.net/bugs/18489
<ubotu> New bug: #125387 in xserver-xorg-video-nv (main) "Please upgrade to xserver-xorg-video-nv 2.1.2 to support the remaining 8X00 mobile cards" [Undecided,New]  https://launchpad.net/bugs/125387
<ubotu> New bug: #125422 in luit (universe) "Luit doesn't find locale.aliases" [Undecided,New]  https://launchpad.net/bugs/125422
<ubotu> New bug: #118218 in xserver-xorg-input-mouse (main) "[Dapper]  Cannot capture mouse" [Undecided,Incomplete]  https://launchpad.net/bugs/118218
<ubotu> New bug: #124146 in xserver-xorg-input-mouse (main) "Intermittent focus problems" [Undecided,New]  https://launchpad.net/bugs/124146
<ubotu> New bug: #125584 in xserver-xorg-video-intel (main) "does not work on hp compaq i915gm" [Undecided,New]  https://launchpad.net/bugs/125584
#ubuntu-x 2007-07-13
<ubotu> New bug: #125756 in xserver-xorg-input-evdev (main) "When using evdev keyboard shortcuts go to vt and kill the Xserver" [Undecided,New]  https://launchpad.net/bugs/125756
<ubotu> New bug: #125760 in xserver-xorg-video-amd (universe) "Please sync xserver-xorg-video-amd (universe) from Debian unstable (main)" [Undecided,New]  https://launchpad.net/bugs/125760
<ubotu> New bug: #125763 in xserver-xorg-video-amd (universe) "Please sync xserver-xorg-video-amd (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/125763
<ubotu> New bug: #125834 in xorg (main) "Please remove wacom config from xorg.conf" [Undecided,New]  https://launchpad.net/bugs/125834
<pwnguin> god
<pwnguin> people whine too much about that
<pwnguin> and its the same guy
<pwnguin> !wacom
<ubotu> Sorry, I don't know anything about wacom - try searching on http://bots.ubuntulinux.nl/factoids.cgi
#ubuntu-x 2007-07-14
<ubotu> New bug: #112518 in xorg-server (main) "Switch User freezes at blank screen" [Undecided,New]  https://launchpad.net/bugs/112518
<ubotu> New bug: #125914 in xorg (main) "[Gutsy Tribe 2]  nv xorg module not working on MacBook Pro rev.3 (sant rosa)" [Undecided,New]  https://launchpad.net/bugs/125914
<ubotu> New bug: #125915 in xorg (main) "[Gutsy Tribe 2]  nv not working on MacBook Pro rev.3 (santa rosa)" [Undecided,New]  https://launchpad.net/bugs/125915
<ubotu> New bug: #126008 in xserver-xorg-driver-vesa (main) "X won't start on ATI card without fglrx" [Undecided,New]  https://launchpad.net/bugs/126008
<ubotu> New bug: #126047 in linux-restricted-modules-2.6.20 (restricted) "Atheros wifi kernel modules refuse to load under 2.6.20-16-generic" [Undecided,New]  https://launchpad.net/bugs/126047
#ubuntu-x 2007-07-15
<ubotu> New bug: #122209 in xserver-xorg-driver-vesa "Cycling through display modes fails with vesa driver and NVIDIA 8400M GS." [High,New]  https://launchpad.net/bugs/122209
<ubotu> New bug: #126074 in xserver-xorg-video-unichrome (universe) "xserver-xorg-video-unichrome" [Undecided,New]  https://launchpad.net/bugs/126074
<ubotu> New bug: #74012 in compiz "Compiz crashes with two X-screens" [Unknown,Confirmed]  https://launchpad.net/bugs/74012
#ubuntu-x 2008-07-07
<tseliot> ï»¿tjaalton: bump what?
<tseliot> I can't drop the Provides, otherwise the packages wouldn't replace each other
<tseliot> ok, maybe you can send me an email about this
<m-c> bryce: I believe you are quoted in the latest Phoronix article.  http://www.phoronix.com/scan.php?page=news_item&px=NjU3Mw  I wanted to add my two cents, in case your opinion is to can BulletProofX.
<m-c> I wanted to say that the ability of a novice to get into a GUI, launch Xchat or Firefox, regardless of how messed up the x-configuration is due to kernel updates or other strange x-auto-config tools, well, I feel getting a basic X GUI up in those cases is one of Ubuntu's biggest advantages.
<m-c> Anyway, good luck with all the important work here.  And I hope the integration of the new AMD/Novell open 3D "radeon" and "radeonHD" drivers goes well, for the next ubuntu release.  Kind regards.
<tseliot> tjaalton: can you explain me what you meant by ABI bump last night? ABI bump for what? The kernel?
<tjaalton> they Provide: xserver-xorg-video-2
<tjaalton> which is useful if you only want to have the binary driver installed
<tjaalton> so probably the best fix would be to add a build-dep on xserver-xorg-dev and generate the abiver like the rest of the drivers do
<tjaalton> because then the same package would be easier to backport (if someone would like that)
<tjaalton> ie. don't hardcode the abiver
<tjaalton> and that's the video-abi version of the xserver
<tseliot> tjaalton: I had never noticed this thing before. Would I just have to add that build-dep without touching the rest?
<tjaalton> tseliot: you need to change the rules too. see any free driver package how it's done
<tjaalton> they use the xsfbs-stuff, but you can just copy a few lines straight to the rules
<tseliot> tjaalton: which part of this file? http://pastebin.com/m7a8358f6
<tseliot> this is the rules of the Intel driver
<tjaalton> include debian/xsfbs/xsfbs.mk
<tjaalton> see that
<tseliot> yes
<tseliot> and that's it?
<tjaalton> theres a function 'serverabi'
<tseliot> ok, I see it
<tjaalton> copy that in rules, and call it from binary-arch:
<tjaalton> should work
<tseliot> ok, I can do it
<tseliot> thanks :-)
<tjaalton> you don't need the "xinpdriver" line
<tseliot> where?
<tjaalton> from the function
<tjaalton> oh and also see the control file
<tjaalton> there's Provides: $(xviddriver:Provides)
<tseliot> I don't see any ï»¿xinpdriver. Yes, I will have a look at the control file
<tjaalton> in xsfbs.mk..
<tseliot> ah, I should have paid more attention to the path of the include in rules
<tseliot> ok, I will add that folder too
<tjaalton> it's enough to just copy the function/rule to debian/rules
<tseliot> ok, only serverabi then?
<tjaalton> yes
<tseliot> which package should the debian/$(PACKAGE).substvars be created for?
<tjaalton> the one with the driver
<tjaalton> ie. the one with the current Provides...
<tjaalton> replace xserver-xorg-video-2 with $(xviddriver:Provides)
<tseliot> nvidia-<VER>-kernel-source
<tjaalton> no, it's nvidia-glx-VER which provides that
<tseliot> ah, ok
<tseliot> and that's it?
<tjaalton> pretty much
<tseliot> I won't have to include the mk file since I will just copy the function I need, right?
<tjaalton> right
<tseliot> I don't think we can backport the drivers without effort since the patches which I wrote are specific to 2.6.26 kernels
<tseliot> Maybe from Intrepid+1 to Intrepid...
<tjaalton> well, it's still one step less to do manually
<tseliot> sure
<BUGabundo_work1> tseliot: hi there
<BUGabundo_work1> bryce: any news on nVidia driver for 2.6.26 ?
<BUGabundo_work1> tseliot: http://www.albertomilone.com/driver.html link is dead
<tseliot> ï»¿BUGabundo_work1: we're still testing the drivers
<BUGabundo_work1> thanks
<BUGabundo_work1> oh he went way
<tjaalton> bryce: I've done a small script for just that.. input drivers ready for upload
<tjaalton> well, still waiting for ia64
<tjaalton> video drivers ready as well
<tjaalton> bbl, gone to play some ultimate ->
<bryce> heya alex-weej
<bryce> alex-weej: I missed you earlier, but yes I think I could mentor you on the color profile work 
<bryce> tjaalton: ok cool, let me know where I could help
<alex-weej> bryce: wicked, i'll work a bit on the spec/whiteboard more and ping you when i'm done if that's cool?
<bryce> great :-)
<tormod> tjaalton: hi, I built the server from git (1.5 branch) and now I need "AllowEmptyInput" for mouse and keyboard to work. is the input hotplugging not up to task?
 * tormod has to run
<tjaalton> bryce: heh, it's just about pressing the red button :)
<tjaalton> bryce: actually, you could merge the video drivers that we have changed
<tjaalton> or just add a note about a rebuild
<tjaalton> but don't upload just yet
<tjaalton> gone again.. ->
<tjaalton> tormod: so you don't have any inputdevice-sections on the xorg.conf?
<tjaalton> (I'm back)
<tormod> tjaalton: hi, I tried both without xorg.conf and with the autogenerated one (I think it had a mouse and a keyboard section)
<tjaalton> tormod: strange, it works on my laptop..
<tjaalton> input-hotplug is another story..
<tormod> I also tried replugging the keyboard and mouse without luck. only the AEI option worked.
<tormod> I guess it is the last commit in xserver: http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.5-branch&id=c30f36c8c1dfd85deaf1c109823a1f15dd218ac7
<tjaalton> whee, xorg-server built on all archs
<tormod> do you have that one on your laptop?
<tjaalton> tormod: no, rc5
<tormod> that would explain it
<tjaalton> and that's also in the archive
<tjaalton> so there's a bug? let sascha know about it :)
<tormod> that's my question, is it a bug in xserver or is it the Hardy stuff that needs something special?
<tormod> do you know Sascha's irc nick?
<tjaalton> no I don't ..
<Kano> hi tjaalton , why does intrepid have got a fbdev override entry in xorg.conf which prevents x from starting on many systems?
<tjaalton> Kano: it's not set on i386/amd64
<Kano> well i installed it today
<Kano> and there was an override flag there which was not on hardy
<tjaalton> check xserver-xorg.postinst and find out why it's set
<Kano> it is
<Kano> ppc might need it but nothing else
<tjaalton> check the postinst..
<Kano> it is your package, check it
<tjaalton> uh
<tjaalton> no
<tjaalton> I don't have hardware where it's broken. you find out why it is and report back
<tjaalton> it's not like xorg has changed..
<tjaalton> something else has
<Kano> also i dont think that it will work with your kernel config anyway
<Kano> because vesafb is disabled and for uvesafb the user mode tools are missig
#ubuntu-x 2008-07-08
<Kano> but i would just remove the added line,more easy...
<tjaalton> tga fixed
<tjaalton> need to check what drivers to drop from video/input-all
<tjaalton> at least cyrix, imstt, magictouch
<tjaalton> oh well, something for the morning.. night
<bryce> http://www.phoronix.com/scan.php?page=news_item&px=NjU3Mw
<tjaalton> heh
<tjaalton> ok, xorg uploaded
<Q-FUNK> what would be the correct package for bug #245500 ?
<ubottu> Launchpad bug 245500 in xserver-xorg-video-geode "Jigdo cannot build ubuntu-8.04.1-alternate-i386.iso: .jigdo file refers to missing package" [Undecided,Confirmed] https://launchpad.net/bugs/245500
<Q-FUNK> was reassigned to -geode but the issue is that 8.04.1 jigdo files point to an older version that is not what ships with hardy+1
<tjaalton> Q-FUNK: btw, cyrix is going to be dropped from intrepid, since it's deprecated and doesn't build against 1.5
<tjaalton> but you probably knew that already :)
<Q-FUNK> tjaalton: understood and expected.  afaik, nsc won't build against 1.5 either
<tjaalton> seems like it did
<Q-FUNK> ideally, the milestone to merge back GX1 support into -geode would happen now, so that we can fix this permanently, but it's only scheduled to happen in december...
<Q-FUNK> it did?
<Q-FUNK> was there a new nsc that fixes this?
<tjaalton> no it's still 2.8.3
<Q-FUNK> afaik, upstream purposely made it fail in git, because the nsc build succeeds but it produces a non-usable binary
<tjaalton> but geode hardcodes the ABI?
<tjaalton> (xserver-xorg-video-2)
<tjaalton> ok, unusable is fine :)
<Q-FUNK> -geode has all the latest #ifdef so it builds fine against 1.5
<tjaalton> yeah but the Provides: didn't update
<tjaalton> check how the other drivers grab the correct abiversion from xserver-xorg-dev
<Q-FUNK> what should it be?  not -2 anymore?
<tjaalton> 2.9
<Q-FUNK> ok
<tjaalton> but ideally the package should set it dynamically on build
<Q-FUNK> right
<Q-FUNK> IIRC I had decided to avoid parsing those version files from -dev to make it possible to build on Etch but, now that Lenny enters the freeze, I could just as easily upgrade that.
<tjaalton> etch didn't have those?
<Q-FUNK> etch provides 1.0 and didn't use those 3 files for the api and abi versions
<tjaalton> ok
<Q-FUNK> similar to ... feisty, IIRC
<tjaalton> well, it's still trivial to backport
<Q-FUNK> or maybe the ubuntu equivalent would go as far as edgy
<tjaalton> so video-all should drop the dep on nsc?
<Q-FUNK> but now that lenny is about to release, I could replace my -dev version parsing trick in debian/rules with using the normal 3 files for driver versions
<Q-FUNK> tjaalton: you can still keep nsc in principle, but I vaguely recall something about it not properly building on 1.5, from the x.org bugzilla
<tjaalton> well, it's not on my list of failed modules, so.. :)
<tjaalton> it's fine for now
<Q-FUNK> ok
<tjaalton> since it doesn't block video-all
<Q-FUNK> alright
<Q-FUNK> jcristau: is lenny expected to release with 1.4 or 1.5 ?
<jcristau> 1.4
<Q-FUNK> alright. thanks for the confirmation
<Q-FUNK> do we have a name yet for Lenny+1 ?
<jcristau> no
<Q-FUNK> ok
<jcristau> bryce: your intel changelog says you don't build reg_dumper because pciaccess isn't in main, but surely that's not true anymore?
<tjaalton> Q-FUNK: want me to fix geode for now?
<tjaalton> the abiver
<Q-FUNK> tjaalton: I could upload one to debian/experimental, from which you can sync, if that works for you.
<tjaalton> Q-FUNK: sure, that's better
<tseliot> tjaalton: as regards the serverabi for nvidia-glx-<ver>, shall I add the version to the build-dep on xserver-xorg-dev in the control file?
<tseliot> if yes, which version?
<tseliot> (for Intrepid)
<tjaalton> tseliot: put (>= 2:1.4) like the other drivers have
<tseliot> tjaalton: like this? Build-Depends: xserver-xorg-dev (>=2:1.4.1~git20080131-1ubuntu4)
<tjaalton> 2:1.4 is enough
<tseliot> ok, thanks
<tjaalton> Q-FUNK: what's the ETA for the upload? geode is blockin livecd builds :)
<tjaalton> Q-FUNK: maybe I'll upload a hardcoded fix now to get it in ASAP, we can sync later
<Q-FUNK> tjaalton: I could do it now, if I find a sponsor
<tjaalton> Q-FUNK: aren't you a DD?
<tjaalton> um, DM
<Q-FUNK> unfortunately not
<tjaalton> ok, your wikipage says so :)
<Q-FUNK> tjaalton: yeah, because they didn't have a word for non-DD back then
<tjaalton> ah ok
<Q-FUNK> nor did they have separate upoad rights for maintainers. 
<tjaalton> I'll upload a fix and we can sync after alpha1
<tjaalton> uh alpha2
<Q-FUNK> I aksed to be added to DM now, but it might take a few days to process
<Q-FUNK> and that's assuming that there won't be any protest 
<Q-FUNK> tjaalton: experimental package uploaded to mentors and awaiting sponsr
<Q-FUNK> http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=xserver-xorg-video-geode
<tjaalton> Q-FUNK: ok, thanks
<tseliot> tjaalton: the serverabi function seems to work well :-) I'll give you credit for this and for the initial merge in the changelog
<tjaalton> tseliot: ok, cool :)
<tjaalton> I'll try a dist-upgrade from hardy with your ppa
<tseliot> tjaalton: I haven't updated my ppa yet
<tseliot> I'll do it ASAP
<tjaalton> ok thanks
<superm1> bryce, hum... circular dependencies? http://paste.ubuntu.com/25935/
<superm1> just transient caused by updates, or is something actually broke?
<superm1> nvm it must have been transient, as it just went away from apt-get update
<tjaalton> you need to change the Provides of fglrx
<superm1> what to/
<tjaalton> currently it Provides: xserver-xorg-video-2, change that to 2.9
<tjaalton> which is the new video-ABI version
<superm1> so xserver-xorg-video-2.9?
<tjaalton> or, do what tseliot did and change the packaging to get that dynamically :)
<tjaalton> (like all the other drivers do)
<tjaalton> that would work
<tjaalton> for now
<superm1> well there is no provides in the source package right now
<superm1> i'll take a look at what tseliot did then and add it
<tjaalton> oh
<superm1> what does this actually do?
<tjaalton> it would allow to have only fglrx installed
<tseliot> superm1: I haven't committed the changes yet. I'll send you a link to the source code ASAP
<superm1> that sounds like a bad idea :)
<tjaalton> heh
<tjaalton> :)
<tjaalton> you can leave it out if you like
<tjaalton> I thought the error was due to that
<superm1> well in principle it should be there though
<superm1> so i'll get that in place
<superm1> the error was because i did an intrepid CD build last night while the mirror was in a weird state 
<superm1> tseliot, cool thx
<tjaalton> ah, right
<tjaalton> tseliot: what's the ETA of the ppa update?
<tseliot> tjaalton: I'm about to build the packages locally on Intrepid 64. Then I'll have to test them. After that I'll upload them to my PPA. However I will have to bump to ubuntu2
<tseliot> tjaalton: I'll ping as soon as they are ready, ok?
<tseliot> ping you
<tjaalton> tseliot: pl
<tjaalton> uh
<tjaalton> *ok
<tjaalton> bryce: the greedy patch for intel makes the server to segfault, see bug 246581
<ubottu> Launchpad bug 246581 in xserver-xorg-video-intel "X server crash in libfb.so when EXA is enabled" [High,Triaged] https://launchpad.net/bugs/246581
<tjaalton> bryce: so, either disable it now or forward port it
<tjaalton> *for now
<bryce> jcristau: yes, but I left it off since I was building the driver on hardy.  I'll put reg_dumper back on in a subsequent upload once my intrepid build environment is working properly
<bryce> tjaalton: ok on it
<tjaalton> bryce: actualy, it's fixed already :)
<tjaalton> +l
<tjaalton> forgot to tell..
<bryce> oh whoops
<bryce> looks like -via is failing to build
<bryce> hrm, I really need to get my intrepid pbuilder working
<tjaalton> bryce: yeah I was wrong about the sync.. it hasn't been ported to pciaccess, so it should be removed from the archive
<bryce> ../../src/via_driver.h:216: error: expected specifier-qualifier-list before 'pciVideoPtr'
<bryce> yeah that looks like a pciaccess issue.  which is why it built fine on my hardy environment but not in the build system
<tjaalton> but it doesn't matter if it won't build, since openchrome is the default
<bryce> right
<bryce> would be nice to have as an alternative though, but oh well
<tjaalton> bah, openchrome is a fork of it :)
<bryce> ok I'll put in a remove request on it
<bryce> well we can dream Via would update it some day, can't we?  ;-)
<tjaalton> nah, they should open the specs like they promised
<bryce> bug #246676
<ubottu> Launchpad bug 246676 in xserver-xorg-video-via "Please remove -via from the archive" [Undecided,New] https://launchpad.net/bugs/246676
<tjaalton> rock
<bryce> tjaalton: did you see #245888 already?
<bryce> maybe that one is fixed now
<tjaalton> no, compiz is broken on at least i965
<tjaalton> the problems in the last messages are the ones that intel/vesa had/has
<bryce> this report is for i915, and another with radeon 9200
<tjaalton> there  are two bugs upstream about this
<tjaalton> and they have been ignored for quitesome time now
<tjaalton> +" "
<bryce> hm, give me those bugs, and I'll bug my contacts to get them some attention
<bryce> but breakfast first.  bbiab
<tjaalton> yes, I'll dig them up 
<tjaalton> bryce: ok, freedesktop bug 14441 and freedesktop bug 15477
<ubottu> Freedesktop bug 14441 in Drivers/DRI/i965 "Compiz shows only black screen on i965" [Normal,Assigned] http://bugzilla.freedesktop.org/show_bug.cgi?id=14441
<ubottu> Freedesktop bug 15477 in General "full screen is white when use compiz" [Normal,Reopened] http://bugzilla.freedesktop.org/show_bug.cgi?id=15477
<tjaalton> funny that the other bug was filed by an intel engineer..
<bryce> thanks
<bryce> yeah intel can be weird
<tjaalton> :)
<bryce> btw, do you know if we have bugs in LP corresponding to these?
<bryce> tjaalton: in 14441 from the last comment it sounds like timo found a way to work around the issue?
<bryce> his comment is a bit ambiguous though
<tjaalton> 245888 is the same as fd.o 15477
<tjaalton> added to that bug
<bryce> sort of sounds like that one is due to DRI2 changes
<bryce> ok, emailed Yong.
<bryce> bbiab
<tjaalton> yes, something broke DRI1
<tjaalton> but when that bug is fixed, 14441 kicks in
<bryce> back
<tjaalton> bryce: fedora seems to have dropped the "xaa-evict-pixmaps" -patch, probably because XAANoOffscreenPixmaps is now the default
<bryce> ok, think we should too?
<bryce> does it cause any issues keeping it?
<tjaalton> I don't think it makes a difference in one way or another
<tjaalton> sweet, input properties
<bryce> btw, over this past weekend I worked up a new bug status script thingee
<bryce> http://people.ubuntu.com/~bryce/Milestones/milestones_current.html
<bryce> this one's for milestones, and is not Xorg-specific
<bryce> still a WIP.
<tjaalton> looks promising
#ubuntu-x 2008-07-09
<BUGabundo> hi guys
<BUGabundo> I'm getting: E: /var/cache/apt/archives/xserver-xorg_1%3a7.4~0ubuntu1_amd64.deb: subprocess new pre-removal script returned error exit status 1
<tjaalton> BUGabundo: you need to give the full log, that doesn't say much
<BUGabundo> well its what I got from todays update-manager, tjaalton
<BUGabundo> where can I get the full log?
<BUGabundo> found it 
<BUGabundo> on the details arrow
<BUGabundo> where should I make this available?
<tjaalton> BUGabundo: somewhere like paste.ubuntu.com
<BUGabundo> opening
<BUGabundo> lol
<BUGabundo> FF 3.1 just exploded
<BUGabundo> just a sec
<tjaalton> better use the stable version ;)
<BUGabundo> lol
<BUGabundo> it would be great if update-manager log window would allow copy-paste
<BUGabundo> I guess I'll have to do a dpkg --conf to get the log
<tjaalton> no need
<BUGabundo> http://paste.ubuntu.com/26159/
<tjaalton> they are somewhere
<BUGabundo> maybe in some /var/log
<tjaalton> well there you go
<BUGabundo> I'll search for it
<tjaalton> something broke your debconf
<BUGabundo> got it on /var/log/apt/term.log
<BUGabundo> debconf: DbDriver "config": could not open /var/cache/debconf/config.dat
<BUGabundo> is this it?
<tjaalton> yes
<BUGabundo> I cleared the folder I tried again
<BUGabundo> here is what I got
<BUGabundo> http://paste.ubuntu.com/26160/
<BUGabundo> I'm going to unistall ntop
<BUGabundo> seems to be too much trouble
<BUGabundo> seems to be fine now
<BUGabundo> thanks tjaalton
<tjaalton> so you deleted config.dat?
<BUGabundo> or I got a corrupt file
<BUGabundo> I deleted the folder and made a new one
<tjaalton> check the size of var: 'df -h /var'
<BUGabundo> /dev/sda1             9.3G  6.6G  2.2G  76% /
<tjaalton> ok so that's not it
<tjaalton> but that file.. now you've lost all the debconf data
<BUGabundo> ohh
<BUGabundo> can I reinstal it?
<tjaalton> it holds configuration data from many packages, so it's not that easy to recover I think
<tjaalton> what files do you have in that directory?
<BUGabundo> currently?
<tjaalton> yes
<BUGabundo> !ls /var/cache/debconf
<ubottu> BUGabundo: Error: I am only a bot, please don't think I'm intelligent :)
<BUGabundo> grrr
<BUGabundo> bad pidgin
<BUGabundo> config.dat and .dat.old; passwords.dat ; templates.dat and .dat.old
<BUGabundo> oh and I love this one
<BUGabundo> linux-backports-modules-intrepid-generic:
<BUGabundo>  Depends: linux-backports-modules-2.6.26-3-generic  but it is not installable
<tjaalton> what size does the config.dat* have?
<BUGabundo> 1.9k
<tjaalton> and .old?
<BUGabundo> same
<tjaalton> ok, so it's broken
<BUGabundo> W: Failed to fetch ftp://darkstar.ist.utl.pt/pub/ubuntu/archive/pool/universe/n/nvidia-settings/nvidia-settings_1.0+20080304-0ubuntu3_amd64.deb   Size mismatch
<BUGabundo> great way to start the day
<BUGabundo> lol
<tjaalton> the archive is broken
<tjaalton> use a better mirror
<BUGabundo> bahh.. I'll just reinstall the laptop when alpha 2 comes out
<BUGabundo> this is the best portugues mirror
<BUGabundo> and I have main too.
<BUGabundo> let me just comment that line
<tjaalton> in that case wait for it to update
<BUGabundo> this machine was dist-update from hardy to ibex
<BUGabundo> on the 12th of june.... around the inicial date for alpha1
<BUGabundo> there weren't even seeds for update-manager -d
<tjaalton> tseliot: a question about the nvidia driver. what happens when the new driver version is changed? does nvidia-glx-177 (and only that) update nicely to -1xx?
<tjaalton> the other versions don't have that problem, since the major version does not change
<tjaalton> tseliot: I'll send an email
<tjaalton> umm, maybe no problem after all.. 
<tjaalton> I'll ask pitti to be sure
<tseliot> tjaalton: we're still discussing the solution. I have written a script which should make the whole process smooth
<tseliot> this might be included in a different package, say, nvidia-kernel-common, and talk to debconf.
<tseliot> oh, pitti has already replied
<tjaalton> tseliot: the thing is, do we want to let those running the latest version upgrade directly or not
<tjaalton> or should we introduce a new version every time nvidia bumps their ABI (and remove the previous one from the archive)
<tjaalton> note that I'm not talking about -71, -96, -173
<tjaalton> keeping a same name for the latest driver would upgrade the driver when a new version is available, without any magic
<tseliot> ï»¿tjaalton: keeping the same name ï»¿for the latest driver would be ok if NVIDIA stopped dropping the support for certain card series
<tjaalton> then introduce new hardcoded versions
<tjaalton> like -173
<tjaalton> which would replace the last same-name version that supported the device
<tseliot> if we had a reliable way to distinguish between graphics cards series
<tjaalton> or maybe I'm missing something
<tseliot> that would be doable
<tseliot> currently, all we can do
<tseliot> keep the names as -173. etc. and rely on hardware detection
<tseliot> performed by Jockey, EnvyNG, or that new package
<tjaalton> I mean if they do that, make every nvidia-glx upgrade to nvidia-glx-VER, and those that want the latest, install by hand (and notify) or let update-manager/jockey do the thinking
<tseliot> ï»¿tjaalton: this would screw a lot of users too
<tjaalton> how?
<tseliot> since nvidia-glx doesn't support all the models of -new
<tseliot> etc.
<tjaalton> I'm not talking about -new
<tseliot> in the future
<tseliot> we'll have a database
<tseliot> and we'll be able to introduce metapackages
<tseliot> which would do exactly what you suggest
<tjaalton> I'm just thinking this is getting a bit overengineered..
<tseliot> ï»¿tjaalton: if you have a look at the emails that we forwarded to you, you will see that it took us some time to come to an agreement
<tseliot> on this
<tjaalton> it's a long thread :)
<unggnu> hi all
<tseliot> hi
<unggnu> bryce: could you please check Bug 246835
<ubottu> unggnu: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/246835/+text)
<tseliot> ï»¿tjaalton: yes, I know ;)
<unggnu> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/246835
<tjaalton> unggnu: what about it?
<ubottu> unggnu: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/246835/+text)
<unggnu> tjaalton: Something has fixed upstream but the ubuntu patch is still applied
<unggnu> in the intel driver
<tjaalton> unggnu: it still works fine :)
<unggnu> Seems so :)
<unggnu> just shouldn't get lost
<tjaalton> none of the 1900+ bugs are lost
<tjaalton> we just ignore them :P
<tjaalton> "la la la can't see you.."
<unggnu> :-D
<tjaalton> maybe I could drop that
<tjaalton> for alpha2
<unggnu> There are too much bugs for two? men so I just wanted to point on this one since it even should be easy to fix
<unggnu> maybe three, don't know :)
<unggnu> Btw. does the new Xorg input hotplugging recognizes the correct keyboard layout?
<tjaalton> no
<unggnu> Then there is a problem if xorg.conf will be removed from intrepid.
<tjaalton> there's no magic, HAL needs to know about the layout somehow
<tjaalton> of course
<tjaalton> it won't happen before it works
<unggnu> There was a discussion with the timezone and everything else could be handled through the GUI I guess but I don't know
<unggnu> In the past changing keyboard layout in Gnome doesn't work so well.
<tjaalton> that should work, but also gdm should have the correct layout..
<tjaalton> otherwise it could happen that your password doesn't work, with us layout anyway
<tjaalton> been there
<unggnu> So the touchpad scrolling detection problem is fixed in new Xorg?
<tjaalton> no idea
<Ng> how can the input hotplug know the layout btw, do USB keyboards expose that?
<jcristau> Ng: no
<unggnu> timezone maybe, don't know
<jcristau> you still need to configure it
<tjaalton> Ng: that was discussed at UDS, but very few devices support that
<jcristau> timezone has nothing to do with keyboard layout
<Ng> afaics there would be no way to infer it
<tjaalton> if only the hal-script approach would work..
<tjaalton> so you can feed HAL with the data from, say, console-setup
<unggnu> What is with the environment language variable? Maybe gdm could have an flag where you can change the keyboard layout on the fly.
<Ng> unggnu: language isn't a good indicator of keyboard layout, and may actually be a really bad one
<unggnu> Console keyboard layout even works without xorg.conf of course so there have to be a way :)
<tjaalton> locale and layout don't always match..
<unggnu> yeah, your are right. Just the country code like us or something like that.
<tjaalton> I mean you might want to use another locale with some other layout
<unggnu> How does the console get the layout?
<tjaalton> console-setup
<tjaalton> and xserver-xorg.postinst uses that (on ubuntu)
<unggnu> maybe that could be used for an xorg.conf free setup
<tjaalton> exactly my point
<unggnu> :)
<tjaalton> but it's pointless to generate yet-another file (the hal .fdi)
<tjaalton> hence the proposal of a HAL-script that would read the values and inject them to HAL
<unggnu> Do you have a link for enabling input hotplugging in Intrepid?
<tjaalton> nope
<tjaalton> just copy the example fdi file from.. gimmeasec
<tjaalton> /usr/share/doc/hal/examples/
<tjaalton> 10-x11-input.fdi
<unggnu> thx
<tjaalton> that doesn't have the magic about the keymap though
<unggnu> sure
<unggnu> If this works only a good graphical modeline generator for faulty hardware is needed imho.
<unggnu> displayconfig-gtk changes to much imho and has to be manually installed
<tjaalton> and input properties is implemented upstream.. goodbye ugly sharedmem-hacks of synaptics :)
<tjaalton> it's about to be deprecated
<tjaalton> so don't rely on it too much :)
<unggnu> I know
<unggnu> that's why a modeline generator is needed
<Ng> imho having to generate a modeline is a bug ;)
<Ng> I do wonder if the xinput stuff could key the layout of the first keyboard off the console layout and then have a nice easy way to let users change the layouts for additional keyboards, but I bet simple USB keyboards don't have any uniquely identifying information in them :/
<unggnu> Ng: Maybe we could move the hardware upstream ;)
<Ng> heh
<jcristau> tjaalton: the keymap stuff is in /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi
<tjaalton> jcristau: oh right
<jcristau> so copying that to /etc/hal/fdi/policy/ and customizing the layout would work
<tjaalton> yes
<bryce> morningh
<crevette> hello
<crevette> I just bought a thinkpad with a intel card, and it seems to me the performance are not terrific
<crevette> for example scrolling inside firefox the page reader.google.com is not really smooth
<crevette> I've look the xorg.conf file and is it really small, no driver directive or such
<jcristau> crevette: the x server detects your video card so it doesn't need to be in xorg.conf
<crevette> yeah, this is what I understand, I used to have a complete Xorg back in my early days of linux
<crevette> I didn 't follow closely the Xorg development
<crevette> so I though the intel X3100 was a rather well supported chip
<crevette> I saw there is choice between EXA and XAA acceleration; and I saw related bug about that and intel. could it be related?
<jcristau> yes, it could
<crevette> I could test this repo http://people.ubuntu.com/~bryce/Testing/intel/hardy-i386/ ?
<crevette> hello
<crevette> I'm back
<tormod> hi, you guys with Intel chips, does glplanet (from xscreensaver-gl-extra) run dog slow?
 * tormod tries to understand bug 198272
<ubottu> Launchpad bug 198272 in xscreensaver "glplanet is very slow for no apparent reason" [Undecided,Incomplete] https://launchpad.net/bugs/198272
<tjaalton> don't have my intel laptop around to test that
<crevette> tormod: I have my thinkpad
<crevette> tormod: it works rather fine here
<tormod> crevette: thanks, what card do you have?
<crevette> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c)
<tormod> crevette, I guess you're using the i965 mesa driver (xdriinfo will tell) but the reporter use i915.
<crevette> ah, I admit I don't know a lot
<crevette> I just bought this laptop
<crevette> baptiste@oak:~$ xdriinfo 
<crevette> Screen 0: i965
<tormod> crevette: I know pretty much nothing about intel as well :) thanks for trying out.
<tormod> I would like to provide test packages for a potential ati SRU (bug #204483). Since I already have a newer version in my PPA I can not use it. Can someone else house it?
<ubottu> Launchpad bug 204483 in xserver-xorg-video-ati "[Hardy] Closing Laptop lid corrupts screen and beeps" [Undecided,Fix released] https://launchpad.net/bugs/204483
<tormod> or maybe it can go straight to hardy-proposed ?
<tormod> night
#ubuntu-x 2008-07-10
<soren> Erm... I get a white screen when I log into GNOME in Intrepid. What am I doing wrong?
<soren> GDM looks fine.
<tjaalton> disable compiz
<tjaalton> it's broken on intel
<soren> :(
<tjaalton> 965 at least
<soren> Ok.
<soren> Thanks.
<soren> This will be fixed at some point, I presume?
 * soren kinds of likes compiz.
<tjaalton> there are two bugs and they were marked as blockers for mesa 7.1 yesterday, so yes they'll get fixed soon :)
<soren> Fantastic. Thanks.
 * soren hugs tjaalton 
<tjaalton> the white screen one already has a fix, but then you'd end up with a black screen with some corrupt graphics :)
 * tjaalton hugs soren back
 * soren ponders the semantics of "fix" :)
<tjaalton> ok, patch :)
<tjaalton> two, actually
<bryce> tjaalton: I heard back from Intel on this
<bryce> Yong:
<bryce> I just reproduced #14441 on 965G with tip of xserver1.5, mesa, drm, xf86-video-intel.  A quick way to resolve it is commenting out
<bryce>     if (pI830->useEXA)
<bryce>         pDRIInfo->texOffsetStart = I830TexOffsetStart;
<bryce> in xf86-video-intel/src/i830_dri.c. Then compiz works.  You can ask Ubuntu guys for more test.
<bryce> For #15477, It doesn't happen on G965. We may need to find a 945 box to look at it.
<bryce> - Peng
<bryce> night.
<tjaalton> commenting that out breaks other setups
<tjaalton> the workaround is already mentioned on the bug
<tjaalton> 15477 does happen on 965
<tjaalton> but for that bug there already are patches
<tjaalton> oh, night :)
<pwnguin> heh
<pwnguin> i filled up my / partition
<pwnguin> oops
<pwnguin> fun finding random crap on cleanup
<pwnguin> XFree86.0.log
<tjaalton> now, let's clear all l-r-m* from nvidia/fglrx bugs and let tseliot and superm1 have some fun :P
<tjaalton> a great way to boost my lp karma 
<pwnguin> man, if you just mark them all invalid
<pwnguin> you will earn a new top score on the "people pwnguin is angry at" table
<tjaalton> hah
<pwnguin> pvalli does that and it ticks me off
<pwnguin> i just love getting told my bug is a dupe, but if i want to know WHICH one, i should just go look it up myself
<tseliot> ï»¿tjaalton: ï»¿I'll have a lot of fun then ;)
<pwnguin> btw
<pwnguin> this might be a good time to point out that there is an upstream bug tracker email address
<pwnguin> and that launchpad apparently supports this
<tjaalton> pwnguin: what benefit does it give?
<pwnguin> a feeling that at least we tried?
<pwnguin> plus, if we used it there might be an incentive to use something smarter on their end
<tjaalton> ok, so does bugzilla have such a feature (email)?
<pwnguin> I dont understand the motivation of the question
<tjaalton> upstreams tend to use bugzilla
<pwnguin> nvidia is upstream
<tjaalton> so where to send the bug
<tjaalton> ah
<pwnguin> you've got this backwards i think
<tjaalton> yeah, but they want that people run their script
<tjaalton> hehe
<pwnguin> LP does have an email, but that wasnt the point
<pwnguin> tjaalton: the installer script or some crazy bug report script?
<tjaalton> some crazy ..
<pwnguin> fun
<tjaalton> nvidia-bug-report.sh
<tjaalton> tseliot: yes, you'll have a party of the century ;)
<tjaalton> it never ends
<bryce> tjaalton: does the patch on 15477 look ok for inclusion in our packages?
<bryce> (good morning btw!)
<tjaalton> bryce: morning bryce! yes, it does, but it's pointless without a fix for 14441 :)
<tseliot> bryce: you're going on a vacation soon, right? May I ask how long it will last? (so that I know when I can bug you again about phase 1)
<bryce> tjaalton: ok, I highlighted the 14441 issues back to them
<bryce> tseliot: next week will be the distro sprint in London, then I'll be on vacation the week after that
<tseliot> ok, thanks
<bryce> I can't promise I'll get anything useful done during the sprint; most of the time is meetings and talking with other devs about bugs and such
<tseliot> ï»¿bryce: no problem, in the meantime I'll do my part ;)
<bryce> awesome
<bryce> tjaalton: btw, do you have any ideas on #246585?  I was trying to help mdz on it yesterday
<bryce> tjaalton: it appears the new -vesa doesn't report its screens correctly to gdk.  I've dug through the code from the gdk side of things yesterday, but am thinking to look at it from the -vesa side, but am not sure what angle to approach it
<tjaalton> bryce: the driver is very simple.. I believe the client code is doing something wrong here
<bryce> jcristau observed it seems that vesa seems to be using xinerama or thinking its using xinerama
<tjaalton> hmm
<tjaalton> I bet fedora is seeing something similar then
<bryce> yeah I've been through the driver source; I doubt the bug is there, but I also dug down pretty deep in gdk and didn't spot it
<tjaalton> compared vesa logs from hardy with the one from that bug.. nothing apparent in sight
<tjaalton> I'll subscribe ubuntu-x to fglrx-installer/nvidia* bugmail
<mario_limonciell> tseliot, hum are you seeing seg faults starting X now on intrepid w/ nvidia too?
<mario_limonciell> fglrx most definitely broke in the last day or two (bug 247376)
<ubottu> Launchpad bug 247376 in fglrx-installer "undefined symbols when trying to load fglrx" [Critical,Triaged] https://launchpad.net/bugs/247376
<tjaalton> so fglrx doesn't work with xserver 1.5
<tjaalton> either
<tjaalton> nvidia -173 and -177 work
<tjaalton> but -71 and -96 don't
<mario_limonciell> well i wonder why i'm segfaulting then on this box w/ 177
<mario_limonciell> i see the splash screen and then the X server dies
<tjaalton> splash screen of what?
<tjaalton> usplash?
<mario_limonciell> nvidia splash screen
<tjaalton> ok, so it's not the same then
<tjaalton> maybe -177 is just buggy ;)
<mario_limonciell> but yeah usplash is a mess on a bunch of boxes too
<tjaalton> right...
<tjaalton> let's get plymouth!
<mario_limonciell> the weird thing with the nvidia segfault, there are no errors in the log except not being able to load dri2
<tjaalton> (plymouth == the new boot-candy for fedora10, using kernel modesetting)
<mario_limonciell> i only know it's a segfault from starting X on it's own
<mario_limonciell> ah 
<mario_limonciell> and that's what's breaking usplash?
<tjaalton> no, it's not in ubuntu :)
<mario_limonciell> oh phew.
<tjaalton> possibly some framebuffer madness
<tseliot> ï»¿mario_limonciell: sorry, I haven't updated my Intrepid system yet. I'll do it tomorrow
<mario_limonciell> tseliot, yeah hopefully it's easily resolvable.  i've only got one intrepid nvidia system up and running.  unfortunately all the other ones i have still are fglrx
<mario_limonciell> so SOL for a bit there
<tseliot> tjaalton: ï»¿plymouth == works only with Intel?
<bryce> *sigh* ETOOMANYBUGS
<tjaalton> tseliot: yes, currently
<tjaalton> http://katzj.livejournal.com/432586.html
<tseliot> ï»¿mario_limonciell: did you try with Disable "dri2" in the Module section of your xorg.conf?
<mario_limonciell> i didn't know disable was a valid keyword
<tjaalton> the warning is harmless
<mario_limonciell> i'll give that a shot
<tseliot> ï»¿mario_limonciell: it's in man xorg.conf
<tjaalton> oh, that screencast is using vesafb, not modesetting
<tjaalton> so it has multiple fallbacks
<tseliot> ï»¿mario_limonciell: let me know how it goes
<tseliot> tjaalton: ok, it's a sensible idea then
<tjaalton> bryce: i'm with you man..
<mario_limonciell> tseliot, well no more dri2 error (duh), but still segfaulting
<tjaalton> mario_limonciell: have you tried -173?
<mario_limonciell> yeah i just rolled back to it fearing something in 177 went wacky
<tjaalton> what the hell to do with nvidia/fglrx bugs that are a) old b) have no logs c) no idea what chip the user has
<tjaalton> going through lrm-2.6.15
<mario_limonciell> apport is off by default now...
<mario_limonciell> so no logs via apport
<bryce> tjaalton: have xserver upgrades always been this rough?  I don't recall the 1.4 update triggering this many serious issues
<pwnguin> didnt everything dangerous fall out of 1.4?
<tjaalton> bryce: nah, the vendors are just lazy
<tseliot> ï»¿mario_limonciell: does it help if you do startx -- -ignoreABI ?
<bryce> tjaalton: for old lrm bugs, I'd just let them know the bug's out of date and won't be further investigated here, and kindly ask that they re-test with hardy and report against $package if it still occurs
<tjaalton> "kindly".. forget about it then :)
<bryce> *short*
<bryce> s/h/n/
<tjaalton> ah, monty python on the telly
<tjaalton> hehe
<bryce> on the plus side, I'm finding myself getting pretty good at gdb
<tseliot> ï»¿tjaalton: I receive a lot of emails which say only "I used Envy and now my card doesn't work" :-P
<bryce> tseliot: all of our Xorg bugs go that way :-)
<bryce> except s/Envy/<$package>/
<bryce> fun fun
<mario_limonciell> tseliot, well very odd, but i reinstalled 177 again (after downgrading to 173) and it appears to be working now?
<tseliot> ï»¿bryce: we should just learn how to read our users' thought, that's all...
<bryce> I dream about making a web interface with some regex's to detect if they've included Xorg.0.log, mentioned a crash but not included a backtrace, etc. etc. and have some nice checkboxes (and 'check-all') so us triagers can process those stub bug reports faster
<mario_limonciell> tjaalton, well i don't know that i would say they are lazy, but there was no predictable release date for xorg 1.5
<tseliot> ï»¿mario_limonciell: did you do rmmod and modprobe before restarting the Xserver?
<mario_limonciell> tseliot, yeah i did
<mario_limonciell> so it's very hard to get your schedule together when you don't have a stable list of changes for the ABI and such
<tjaalton> mario_limonciell: and there still isn't but yeah
<tseliot> ï»¿mario_limonciell: ok, naive question
<bryce> btw, I talked with AMD yesterday.  
<mario_limonciell> about xorg 1.5 support?
<tjaalton> but fedora9 has been out two months, so either they have no fedora users or something is really wrong
<bryce> they're working on implementing xrandr 1.2 for fgrx 8.53, which is slated to be released in Sept
<tjaalton> sweet
<bryce> betas will be released to testers next month
<mario_limonciell> bryce, er well i'm not sure you should be mentioning that with ubuntulog sitting around...
<tjaalton> sssh
<tjaalton> :)
 * bryce shushes up
<bryce> actually I'm not sure it's private.  maybe you know differently though
<mario_limonciell> well it's not been announced anywhere in the past
<tseliot> ï»¿mario_limonciell: we are the ones who signed an NDA, not Bryce
<mario_limonciell> tseliot, it's not been announced to the beta list either
<mario_limonciell> but I had thought there was a 3 way NDA via AMD/Canonical/Dell as well
<mario_limonciell> anyhow though.  did they talk about xorg 1.5 support?  randr 1.2 is kinda useless without xorg 1.5 :)
<bryce> heh, I'm saying no more without a go-ahead ;-)
<tjaalton> works just fine from 1.3 onwards :)
<bryce> but I've requested clarification on it
<mario_limonciell> haha okay
<bryce> have I ever mentioned how much I hate secrets?
<tseliot> :-)
<mario_limonciell> yeah i wish that they would publicly comment on this kind of stuff
<mario_limonciell> what would you call the "contours" that are showing in this image: http://imagebin.org/22276 ?
<bryce> banding
<mario_limonciell> because that only happens with the 'ati' driver
<mario_limonciell> not with the fglrx
<bryce> yeah we used to have that in inkscape with gradient patterns
<mario_limonciell> what causes it?
<bryce> color interpolation bugs, 
<bryce> numerical issues in gradient printing code
<bryce> btw, is that background a png or a svg?
<mario_limonciell> its the default ubuntu one
<bryce> ok so a png
<mario_limonciell> this was a hardy install upgraded to intrepid (before fglrx broke)
<bryce> see if you can reproduce it in inkscape - draw a circle and color it with a gradient
<mario_limonciell> er well i crashed inkscape trying to fill it with a gradient :)
<mario_limonciell> ill try again
<bryce> could also try gimp
<bryce> inkscape crashes are quite rare though; I'll bet backtracing that crash would give some handy info 
<mario_limonciell> yeah inkscape definitely does it too
<mario_limonciell> i did it with a big red circle gradienting to white
<mario_limonciell> theoretically linearly
<bryce> ok, that rules out it being just a png issue then
<mario_limonciell> i'll put all this info into a bug then
<mario_limonciell> its in bug 243372 now
<ubottu> mario_limonciell: Bug 243372 on http://launchpad.net/bugs/243372 is private
<mario_limonciell> bah
<mario_limonciell> okay it shouldnt be private :)
<mario_limonciell> bug 243372
<ubottu> Launchpad bug 243372 in xserver-xorg-video-ati "RadeonHD 3670, unable to show entire color scheme" [Undecided,New] https://launchpad.net/bugs/243372
<tjaalton> there, lrm-2.6.15 cleared and unsubscribed
<tjaalton> ~45 bugs less to worry about
<Awsoonn> thought you might be in here Bryce :)
<Awsoonn>  bug #242990
<ubottu> Launchpad bug 242990 in xorg "xorg does not synchronize to vertical refresh" [Undecided,New] https://launchpad.net/bugs/242990
<Awsoonn> I can't tell if it is my monitors ghosting or if I really do see what he sees, but what say you an that bug?
<bryce> looking
<Awsoonn> domo
<bryce> Awsoonn: does it make a difference if compiz is enabled/disabled?
<Awsoonn> let me disable and see
<Awsoonn> more noticeable when disabled
<bryce> hmm, well without seeing a screenshot it sounds like https://bugs.launchpad.net/ubuntu/+bug/96991, but that should go away with compiz is disabled
<Awsoonn> oh! here we go!
<ubottu> Launchpad bug 96991 in xorg-server "3D stuff breaks with Compiz:  Redirected Direct Rendering is needed in DRI" [Unknown,Fix released] 
<Awsoonn> I took a screenshot of it
<Awsoonn> I can't believe that worked. :) let me attach it
<Awsoonn> *posted*
<bryce> hmm
<Awsoonn> Is there somewhere that I should tell xorg to use vsync?
<bryce> well, you can specify it in xorg.conf
<bryce> what you might want to do is compare your monitor's documented rates against what's listed in Xorg.0.log to see if something's misdetected
<bryce> or try swapping monitors, if that's easier
<bryce> I notice in the Xorg.0.log there's some warnings about pipe-A issues, so you could setting that option (google launchpad for 'Pipe-A' quirk)
<bryce> however that usually exhibits itself as a crash on lid close, not like this
<bryce> I'd encourage you to post your Xorg.0.log, for comparison against the original reporter's
<bryce> also, it couldn't hurt to test booting Intrepid alpha-1 or alpha-2 when it's out, just in case this issue's already fixed upstream
<bryce> if it's a mis-detection of sync rate, you could also try the NoDDC option 
<Awsoonn> my Section "Monitor" contains nothing for a refresh rate, is that anything?
<bryce> that just means you're letting xserver autodetect it
<bryce> which works 99% of the time :-)
<Awsoonn> Screen resolution settings window shows that it is set at..... 50Hz
<bryce> oh, also another approach if you suspect modeline issues, is to try alternate resolutions and refresh rates
<bryce> modeline bugs tend to be specific to one particular setting
<Awsoonn> interesting that the nvidia settings tool says I'm at 60 Hz
<bryce> you can also use 'ddcprobe' and 'get-edid | parse-edid' to check things
<bryce> oh you're using nvidia?  the log shows intel...
<bryce> yeah there's a known bug with -nvidia where it reports wrong refresh rates
<Awsoonn> my montiors report 60Hz as well
<Awsoonn> those logs are the OP's
<bryce> nVidia knows about the bug (I think it's in their release note and/or faq), but I don't know of any plans they have to fix it
<Awsoonn> so MY issue is nvidia, but his is something else you think?
<bryce> it's quite possible
<bryce> it's very typical for unrelated bugs to have similar symptoms
<bryce> and this gets confusing especially when the symptoms are described in text, rather than screenshots
#ubuntu-x 2008-07-11
<bryce> in any case, treating the bug as a driver-specific bug is more likely to be acted on upstream, than if it's left a generic xserver bug
<bryce> see my comment on the bug report
<Awsoonn> the OP has 5 machines though.
<Awsoonn> xx
<bryce> right, but since he included only one log, and no screenshots, he's not proven it's the same bug on each system
<bryce> his report is vague
<bryce> like, is he using the same xorg.conf on all of them?
<bryce> is he using the same brand of monitor?  (in which case it could be a monitor bug)
<bryce> he asserts, "The correct approach, to my understanding, is to hold all updates until the screen has finished its refresh cycle." but without a reference or detailed explanation that sounds speculative
<Awsoonn> rock on, so on some computers, there is no tearing then?
<bryce> well, maybe I'm misunderstanding the problem, but generally with a fast video card you don't notice things like that
<bryce> (not to the degree that it'd show up in a screenshot anyhow)
<bryce> if the complaint is simply the repainting algorithm that X uses... well that's probably more for a discussion upstream than a bug report against ubuntu
<Awsoonn> is there a way that I might prove this in a driver issue? I want to tell x not to use the nvidia driver
<bryce> sure, switch to "nv" in xorg.conf, or "vesa", and try reproducing it
<bryce> or if you're using "nv", try the -nvidia binary driver
<Awsoonn> I tried on another system with an older Gforce2 and got the same 'error' screenshot.
<Awsoonn> will do
<Awsoonn> I'll be back :) 
<Awsoonn> bryce, something decently interesting happened, the screenshot shows tearing even with Vesa
<Awsoonn> what else can I try to further pinpoint the bug? would you like my xorg.conf? 
<Awsoonn> I also have an x700 ati card that could be tested as well if need be.
<Awsoonn> I hope this isn't too bothersome, I am enjoying learning more about X. ^_^
<bryce> Awsoonn: not sure, perhaps ask on the xorg-devel@ list?
<bryce> Awsoonn: maybe one thing that would help would be to write up the description of the problem more specifically.
<bryce> like, list out the exact steps to reproduce it
<bryce> tjaalton: is vesa supposed to support xrandr 1.2 calls?
<tjaalton> bryce: not sure but don't think so
<bryce> tjaalton: I traced through the code on the -vesa gdk bug more today.  It's failing during an init_xrandr12 call
<bryce> or, rather, the invalid data is entering during an init_randr12() call...  it crashes a little later on when it tries to dereference a pointer generated due to the invalid data
<bryce> it's a bit perplexing how little return value checking there is in gdk amongst its x11 wrapper calls
<bryce> anyway, I forwarded the bug with as much research as I'd done, up to debian.  deb #455884
<bryce> no that's not right
<bryce> Bug#490258
<tjaalton> it will end up upstream..
<tjaalton> but who knows
<bryce> sure that's fine.  I almost sent it up to xorg myself but I'm not 100% sure it is X, vs. just gdk
<tjaalton> debian doesn't have xserver 1.5 etc available yet, but other distros do. there doesn't seem to be a bug about it upstream yet
<tjaalton> could be interesting to see if 1.3.0 patched to build has these problems
<jcristau> the init_randr12 stuff was added in gtk 2.13
<tjaalton> ah ok :)
<jcristau> would be interesting to know exactly what XRRGetScreenResources() returns
<jcristau> this is probably not a bug in the driver, fwiw
<bryce> jcristau: here's the rep I was getting back:
<bryce> (gdb) info locals
<bryce> info = <value optimized out>
<bryce> rep = {type = 1 '\001', status = 160 'ï¿½', sequenceNumber = 12, length = 8, timestamp = 2229926, crtc = 0, mmWidth = 0, 
<bryce>   mmHeight = 0, connection = 0 '\0', subpixelOrder = 5 '\005', nCrtcs = 1, nModes = 4, nPreferred = 0, nClones = 0, 
<bryce>   nameLength = 7}
<bryce> nbytes = 28
<bryce> nbytesRead = 28
<bryce> xoi = <value optimized out>
<jcristau> is the crash reproducible with Xephyr?
<jcristau> i get sensible stuff from libXrandr on xephyr. guess i'll have to try with vesa. or find the bug in gtk.
<Ng> how well would we expect to work on a Radeon HD3200?
<Ng> (also called 780G in some circles, I'm told)
<Ng> someone just installed on a machine with such a card and other than VESA, is either getting crashes or entire X failures depending on which driver they go with
<tjaalton> Ng: hardy?
<Ng> yeah
<tjaalton> tormod has a backport of the -ati driver, maybe try that
<Ng> ok, ta
<joumetal> What could be done to bug 246557?
<ubottu> Launchpad bug 246557 in meta-kde4 "ati 9200SE, DVI, vesa, KDE4 crashes on login" [Undecided,New] https://launchpad.net/bugs/246557
<jcristau> bryce: confirmed the bug, reassigned to the server
<bryce> jcristau: thanks
<jcristau> bryce: filed the bug upstream, https://bugs.freedesktop.org/show_bug.cgi?id=16674
<ubottu> Freedesktop bug 16674 in Server/general "[regression] RRScanOldConfig fails to associate output and crtc" [Normal,New] 
<bryce> jcristau: excellent, thanks
#ubuntu-x 2008-07-12
<ScislaC> bryce: I take it that I should expect to not be able to get my fglrx drivers to currently work with the X related changes, correct? (I just don't want to invest time trying to fix if I shouldn't)
<pwnguin> Is there a way to query the HW database or ubuntu.com weblogs for information on display sizes and DPI?
<pwnguin> or anything else for that matter
#ubuntu-x 2008-07-13
<crevette> hello
#ubuntu-x 2009-07-06
<ripps> My radeon 9600 pro's dri has been disabled in kernel 2.6.31-1 in Karmic, can somebody help?
<Sarvatt> add radeon.modeset=0 to the grub boot line
<ripps> Sarvatt: so it's a KMS issue?
<Sarvatt> it'll be fixed in 2.6.31-2.15 that apw's already built on a PPA and should be uploaded soon, KMS was turned on by default without the userspace to support it
<ripps> Sarvatt: okay, I edited my grub.cfg, I'm rebooting now
<Sarvatt> https://edge.launchpad.net/~apw/+archive/daily
<Sarvatt> did it work ripps?
<Sarvatt> wow that cant be right, 0 bug emails today on ubuntu-x?
<pwnguin> independence day hangovers
<ripps> Sarvatt: the radeon.modeset=0 thing worked, I apparently didn't install the Kernel correctly, I just finished that now
<levonshe> good morning all,
<levonshe> good day, What is wrong with DRI  openchrome-via, VX800 - the dri/card0 is not created, and  modprobe via gives : no MTRR for b0000000,10000000 found
<tjaalton> the via module is more or less obsolete
<tjaalton> there's a new one in the works, but no idea when it'll be in the kernel
<TheMuso> If a kernel version, say 2.6.29 is used with current X, will those drivers like intel still work if the kernel doesn't have KMS enabled?
<TheMuso> By current X, I mean what is currently in karmic.
<tjaalton> sure
<tjaalton> uxa performance might suffer though
<TheMuso> Ok thanks tjaalton.
<levonshe> hello all, please explain the error I have trying to work with DRI/DRM on VX800 mtrr: no MTRR for b0000000,10000000 found, as a consecuence no /dev/dri/cardX is created ??
<tormod> sarvatt, what should we do about radeon kms in xorg-edgers now? we can ship a modprobe.d file in libdrm...
<jcristau> might be better to ship it with the ddx
<tormod> it should not matter as long as people install all or none of the packages
<tormod> the thing is, our -ati source package does not know if it is kms or not
<tormod> only the libdrm is special, with its --experimental-radeon-api
<jcristau> you can run old ddx with new libdrm though..
 * jbarnes looks for pitti
<Sarvatt> whats wrong that needs a change tormod? i would assume anyone wanting to use kms would know to add radeon.modeset=1 to grub, it works fine with the stock kernel with or without KMS for me
<tormod> well if we assume they know that, we're fine :)
<tormod> Sarvatt, btw do you have a package update round in the pipeline?
<tjaalton> it'll be the default anyway, an dshipping temporary conffiles is problematic
<Sarvatt> i just got in, will do it now
<tormod> we don't care so much about proper conffiles handling in xorg-edgers :)
<tjaalton> ok then :s
<tormod> tjaalton, when will it be the default ?
<jcristau> not doing proper conffiles handling there means people might get broken stuff when/if they go back to stock ubuntu, no?
<jcristau> (maybe not in that case, but still)
<tormod> I don't think it will be a problem if we use a unique file name
<tormod> or will it stay?
<jcristau> if nothing removes it, it will stay
<tormod> so in the case we add one, we should delete it in an prerm then I suppose
<tormod> but never mind, if we'll have kms as default soon, I don't care so much
<Sarvatt> ugh mozilla build bots of doom are running
<Sarvatt> Estimated build start: 	in 5 hours
<jbarnes> arg claws mail and its plugins still aren't built properly
<jbarnes> just upgraded and claws is new but the html2 viewer plugin wasn't rebuilt so it broke
<tormod> Sarvatt, ugh x 2, my system is so broken with rendering errors now, can't wait :)
<tjaalton> tormod: once userland in karmic catches up
<tormod> tjaalton, yeah I figured that :) but when might that happen?
 * bryce reads pitti's gdm breakage email and wonders how everything got buggy so quickly from really stable a couple weeks ago
<bryce> btw, someone has implemented a wacom configuration gui tool and emailed me about it - http://www.gtk-apps.org/content/show.php/Wacom+Control+Panel?content=104309 but I didn't see the source code posted so am following up.
<tjaalton> tormod: dunno, is there a release coming up?
<jbarnes> did anyone ever figure out the appearance props "doesn't let me enable compiz" bug?
<tormod> the -ati releases do not come often this days, but maybe they will rubber-stamp one as soon as kms seems not too broken
<jbarnes> works fine from a terminal...
<bryce> tormod, alex has been good about stamping releases when we've asked him to in the past
<bryce> I'm not sure he works to a release schedule, just sets release numbers when things look stable
<tormod> bryce, ok so do we have any feature-freeze deadline or so for radeon kms?
<tormod> bryce, yes also think he does it like that
<tormod> Sarvatt, est. build time is down to one hour :)
<Sarvatt> ugh x3!! gdm upgrade killed X and i lost all my chat log history from last session lol
<bryce> tormod, yep at the start of karmic I set Sept 7th as the deadline for driver version updates
<tormod> Sarvatt, I got bitten too :)
<tjaalton> Sarvatt: screen ftw
 * tormod actually got bitten a couple of times...
<tormod> bryce, that sounds like an ocean of time :)
<jbarnes> Sarvatt: same thing just happened to me too
<jbarnes> Sarvatt: any news on the "appearance dialog won't let me enable compiz" bug?
<tormod> bryce, and I guess driver version update in this case includes a minor thing like switching to kms ;)
<bryce> ;-)
<Sarvatt> nope, havent seen anything jbarnes. i switched to mutter so i havent looked into it lately, i'm sorry :(
<jbarnes> np just curious
<Sarvatt> do you have metacity running? i was able to use appearance preferences by running metacity --replace, killing the extra "metacity" that was causing 100% cpu usage, then doing it in the preferences settings
<Sarvatt> its leaving an extra metacity process running for some reason starting anything with --replace now
<Sarvatt> ugh, fun, time for another 6 hour drm/mesa/ati compile session on the powerpc to update this stuff :D
<Sarvatt> are we hurting anything by not having a libdrm-radeon1.symbols? or does it matter since libdrm-radeon1 has only existed during 2.4.11? i dont know how to generate one from scratch
<jcristau> it doesn't hurt. just make sure you have proper shlibs
<Sarvatt> wow, that was embarassing.. turns out my git pulls since the 0703 libdrm update were pulling into ../ instead of the current directory so none of the updates got applied. fixed that up just now by recreating everything. I need to work on a hook to integrate this into auto-xorg-git to avoid that kind of problem, we've been doing libdrm by hand since there are so many changes, easier to just keep debian/ around between updates than pull 
<Sarvatt> origin/ubuntu
<Sarvatt> should have noticed the diff only had the changelog updated sooner
<Sarvatt> tormod: had to wipe radeon-kms because of the libdrm problem, different arches have really long waits and it was pulling the screwed up one because the fixed ones hadnt been published yet, will be fixed soon because the mozilla/chromium stuff is almost done for amd64
<Sarvatt> ppas arent detecting the depwait state and rebuilding when the dependencies can be met so no point repackaging things with bumped dependencies because I'd have to babysit the rebuild button anyway :D
<Sarvatt> i386 is fine on edgers and xorg-testing at any rate
<Sarvatt> will probably have to reupload later for amd64 if the things in the queue arent spaced out enough
<jbarnes> arg!!
<jbarnes> today must be X crash day
<bryce> merry X-crash day jbarnes
<RAOF> It's not "upgrade GDM from a VT day"?
<Sarvatt> at least it wont happen again next GDM upgrade :D
<Sarvatt> and the upgrade continues running even though it kills X and doesnt restart it
<tormod> yes it seems the upgrade finishes anyway, because an apt-get install afterwards does nothing
#ubuntu-x 2009-07-07
<Sarvatt> ahhh crap, video ABI bump in xserver master now :(
<bryce> erf
<Sarvatt> "These old interfaces are no longer supported by the server, removing them requires bumping the video driver ABI. Note that this is not guaranteed to be the last change in ABI version 6. "
<Sarvatt> thats where I switch back to using server 1.6 branch/edgers methinks :D
<Sarvatt> looks like theres a cleaner fix for the fbdev problem now too http://cgit.freedesktop.org/xorg/xserver/commit/?id=43ee8d2ead862f84a4526a472519663ef27a8d6a
<bryce> hrm
<Sarvatt> did you get those messages about the nvidia and fglrx patches bryce?
<Sarvatt> we cant use it that way, when you have a default xorg.conf it does walk the table from that list and only tries the first thing in there
<Sarvatt> so when i boot with the patches applied and the default xorg.conf from now, it only tries fglrx or nvidia and gives up
<Sarvatt> guess we could delete xorg.conf on upgrade if it matches a default's hash, but the people that edit it and dont explicitly add a driver to the device section will still fail
<bryce> Sarvatt, no, which patches?
<bryce> oh those patches
<Sarvatt> the 104 and 105 patches we just added that change around the device tables in xf86AutoConfig.c
<bryce> heh, well good we tested them only in xorg-edgers
<Sarvatt> yup lol
<bryce> yeah I was wondering at the time if it would mis-interact with when xorg.conf was present
<Sarvatt> i only noticed because i was setting up an ibook to play with radeon KMS
<bryce> no, deleting xorg.conf would be an ugly kludge.  this needs to work properly in both cases.
<Sarvatt> tjaalton was saying it didnt use those tables at all if there was an xorg.conf but its pretty clear it does after testing it since its trying to load fglrx and failing, I am no programmer so I couldnt just follow the source to see what happens
<bryce> yeah there's a different code path for both cases
<Sarvatt> maybe if theres no pci ids folder defined its different is all I can think of
<Sarvatt> we could maybe add more placeholder definitions to xorg.conf so it tries more than one entry?
<Sarvatt> i didnt test that yet
<Sarvatt> if theres anything you'd like me to test just let me know, i left the patches on my powerpc machine's xserver so i could test potential fixes out easier
<RAOF> Sarvatt: Hurray!  More fglrx & nvidia pain with ABI changes?
<Sarvatt> yup! fun!
<Sarvatt> i'm switching to server 1.6 branch on all my machines now :D
<RAOF> Thinking of which, libdrm is updated in git to get us a Karmic nouveau update.
<Sarvatt> libdrm doesnt compile right now if you are thinking about pulling upstream git
<RAOF> I'm not; I'm talking about the ubuntu branch of libdrm.git on alioth.
<RAOF> 2.4.11 + the 4 git commits needed to support the 0.0.14 nouveau interface.
<Sarvatt> yeah i was just saying that incase you were because libdrm-radeon1 would be nice to have at some point with KMS being enabled in karmic now, but thats not really important because it also requires mesa 7.6 which wont be in karmic anytime soon
<RAOF> And radeon KMS isn't enabled by default again now.
<bryce> dinner... bbs
<RAOF> Mmm.  nouveau has lost the last of it's non-randr12 codepath.
<tjaalton> Sarvatt: meh, not good
<popey> bryce: any chance you could please take a look at bug 393510 for me, I'm trying to figure out if it is indeed an xorg or kernel issue, and if it's xorg, would a gdb debug be helpful?
<ubottu> Launchpad bug 393510 in xserver-xorg-video-intel "X crashes when I touch the mouse pad" [Undecided,New] https://launchpad.net/bugs/393510
<tjaalton> popey: get a backtrace with gdb to see where it breaks
<popey> doing that now
<popey> is it good enough to get the "easy" one from apport?
<popey> https://wiki.ubuntu.com/X/Backtracing as per the top of that page?
<tjaalton> never done that.. it depends on the output ;)
<tjaalton> if it's useful or not
<popey> ok, will do the gdb way then
<popey> I know that works :)
<tjaalton> yeah
<popey> thanks
<popey> libgl1-mesa-dri-dbg looks just like libg11-mesa-dri-dbg on my screen 
<popey> l/1
<tjaalton> that's probably not needed
<bryce> popey, when you say "system crash" do you mean that X "freezes"?
<popey> bryce: yes, x goes nuts with the display panel blinking madly
<bryce> popey, looking at your logs I'm not seeing any of the normal stuff that suggests a crash
<popey> maybe crash isn't the word, x becomes unusable
<bryce> ok, gdb may not be useful in this case (but continue collecting it if it's not too hard, you never know)
<popey> black screen with flickering and "interference" at the top
<popey> ok, will do
<bryce> ok sounds more like a freeze-with-corruption.  standby
<popey> i note lots of spurious keys coming from the mouse pad
<popey> in dmesg
<bryce> https://wiki.ubuntu.com/X/Troubleshooting/Freeze has some general tips for debugging freezes
<popey> thanks
<bryce> popey, ok attach your dmesg to the bug report that shows those spurious keys
<popey> http://launchpadlibrarian.net/28629975/dmesg.txt
<bryce> popey, also, a lot of freeze bugs got resolved in going to karmic, so it would be REALLY useful if you could boot the karmic live cd (or upgrade) and see if that resolves the problem
<popey> would you recommend an alpha bryce or a daily build?
<bryce> tjaalton, do you have any clues on those key press errors?
<bryce> [  893.052606] atkbd.c: Unknown key pressed (raw set 2, code 0x8 on isa0060/serio0).
<bryce> [  893.052613] atkbd.c: Use 'setkeycodes 08 <keycode>' to make it known.
<bryce> [  893.054005] atkbd.c: Unknown key pressed (raw set 2, code 0x0 on isa0060/serio0).
<bryce> [  893.054011] atkbd.c: Use 'setkeycodes 00 <keycode>' to make it known.
<popey> thats coming from the mouse
<bryce> popey, for intel graphics, Alpha-2 was really solid
<popey> ok, will try that
<popey> thanks for the help, it's appreciated. It's for a machine that a friend of mine (the guy who filed the bug) is rebuilding for a woman whose son got the windows install infected 
<bryce> popey, *nod*
<bryce> popey, for what it's worth, Jaunty with Intel graphics kind of ended up sucking pretty bad
<popey> yeah, i have an intel laptop myself :(
<bryce> popey, either Jaunty or Karmic Alpha-2 are probably better choices if you go with a default install
<popey> am now on karmic, which is a much more pleasant place for many reasons
<bryce> popey, Jaunty can often be improved a lot by reverting to 2.4 or upgrading using xorg-edgers
<bryce> er, "either Intrepid or Karmic Alpha-2..."
<popey> karmic looking to fix the jaunty issues?
<bryce> yep
<bryce> karmic seems to be extraordinarily solid for intel graphics
<popey> good good
<tjaalton> bryce: nope, doesn't ring a bell
<popey> the way it should be :)
<bryce> :-)
<popey> haha, typical, can't get the damn thing to crash now :)
<Ng> karmic is indeed splendiforously wonderful on my 965 :)
<Ng> hope it's the same on my new G45 ;)
<tjaalton> popey: do you still need those options for the kernel?
<popey> tjaalton: i will try without, but the internal keyboard seems wired up strangely
<popey> ok, this is odd, the only thing that has changed (other than updates for 9.04 today) is its now not plugged into the mains
<tjaalton> popey: ah, so you can't make it crash with 9.04 now?
<popey> not at the moment
<tjaalton> k..
<popey> which is a little frustrating
<popey> running x under gdb shouldn't change the behaviour should it?
<tjaalton> shouldn't
<Ng> but it will :)
<popey> i have removed all the kernel boot options, and rebooted, no issues at all
<popey> i can only imagine that the latest kernel update fixed this. could someone set that bug to fix released?
<tjaalton> ok, done :)
<Duke`> strange... during my last boot, DRM failed to open the gfx card (i945GM)
<Sarvatt> so you have no drm now, or rebooting again fixed it?
<Sarvatt> err no dri, sorry
<Duke`> no dri... I rebooted and it loaded fine, this time
<Duke`> like a random bug
<Duke`> hardware not ready on time, or dunno what... :p
<bryce> morning
<Sarvatt> morning bryce
<bdmurray> bryce: bug 395700 has a patch you might be interested in
<ubottu> Launchpad bug 395700 in libdrm "Update libdrm-nouveau for 0.0.14 drm interface" [Medium,Triaged] https://launchpad.net/bugs/395700
<bryce> bdmurray, cool thanks
<Sarvatt> RAOF already added it to libdrm on origin/ubuntu on debian git
<Sarvatt> shouldnt dh_makeshlibs -plibdrm-nouveau1 -V'libdrm-nouveau1 (>= 2.4.5)' -- -c4 be updated as well with that?
<Sarvatt> man i really need to sit down and read up more on lib packaging
<bryce> yeah no clue
<Sarvatt> new symbols were added so i imagine it should be bumped to 2.4.11
<tjaalton> yes
<tormod> sarvatt: no mouse/touchpad (yay for assistive technologies like numpad mousing)
<Sarvatt> lol someone just mentioned xserver-xorg-input-all not getting pulled in in #ubuntu-devel too
<tormod> so the stock live CD is also broken?
<Sarvatt> i just chrooted into the livecd and theres no input packages besides evdev
<tormod> if you reroll the iso, consider removing usplash also
<Sarvatt> yep no xserver-xorg-input-all package installed
<Sarvatt> and i dont see why that is because its a depends  in the xorg metapackage
<tormod> is xorg installed? :)
<Sarvatt> yes
 * tormod tries to resize the pidgin window using the keyboard
<Sarvatt> oh i have source for  1:7.4+3ubuntu3, lets see if its in 3ubuntu4 thats broken
<Sarvatt> nevermind it is 3ubuntu4 that i have
<tjaalton> jcristau: ^^, xserver-xorg depends on -evdev first, then -input-all |Â -input-4, meaning that by installing -evdev the latter dependency is already satisfied, thus -input-all won't get installed
<Sarvatt>  xserver-xorg-input-all | xserver-xorg-input-4,
<Sarvatt> ^^ what he said :D
<tjaalton> -evdev should be moved after -input-all |Â -input-4
<Sarvatt> so i'll just add xserver-xorg-input-all to the build script tormod
<tjaalton> it was like that in jaunty
 * jbarnes wonders why pulseaudio periodically makes a "bump" sound
<tjaalton> jbarnes: it turns off the amp
<Sarvatt> HDA power savings probably
<jbarnes> happens every few minutes though, it's not just a one time thing
<jbarnes> maybe hda and pulse are fighting.. hda turns off the amp, pulse later turns it back on
<Sarvatt> jbarnes remove the powersave line from snd-hda-intel in /etc/modprobe.d/alsa-base.conf
<jbarnes> cool I'll try that
 * tormod found an old usb mouse
<Sarvatt> why not just install xserver-xorg-input-all tormod?
<tormod> what can I do to make X (re)discover the touchpad after install it?
<Sarvatt> sudo rmmod psmouse && sudo modprobe psmouse
<tormod> thanks
<tormod> Sarvatt, that worked! rocking
 * tormod throws mouse away
<Sarvatt> darn, cant reuse the DELPACKAGES env variable stuff without wiping edit/ since it fails doing the apt-get purge openoffice* that is already deleted
<Sarvatt> so no usplash purge this cd, but input is installed :D
<Sarvatt> should purge the brltty junk and printing/scanning support to save another 100MB off the iso size really :D
<Sarvatt> but people might actually try to install off the cd and ubuntu-desktop would be gone that way, dunno how that would work
<Sarvatt> wow, mozilla/chromium updates seem to be getting worse every day - Estimated build start:  	in 7 hours
<Sarvatt> tormod: uploading the new cd now -- http://sarvatt.com/downloads/xorg-edgers-0.16-i386.iso
<Sarvatt> ack no wonder theres a 7 hour wait -- https://edge.launchpad.net/builders/
<Ng> man, first X crash on new laptop :(
<Ng> nothing in logs, not even a segfault notice in dmesg
<RAOF> tjaalton: Re the dh_makeshlibs above - Aren't the correct versioned dependencies generated by the versioning on the symbols in libdrm-nouveau1.symbols?  If not, why does that file exist?
<jcristau> tjaalton: can you either file a bug, or commit the change yourself?  that way i don't have to keep track.
<tjaalton> jcristau: I can commit it myself
<tjaalton> RAOF: the symbols file is used to remind the packager to bump the shlibs :)
<jcristau> i don't know how the various package managers resolve dependencies, so if you think changing the ordering works, then go for it
<tjaalton> it used to be like that in jaunty
<tjaalton> and I remember changing it in December or so
<tjaalton> ah, it was in February.. it's a mystery why I didn't push it to debian back then
<Sarvatt> anyone know a way to parse a large number of bootchart logs and make a graph of overall boot times out of it?
<Sarvatt> hooo boy, its going to be fun figuring out how to reencode all audio output to an ac3 stream to switch my htpc to linux. i dont even know where to start with that one
<Sarvatt> sorry, didnt mean to say that in here, silly irc client switching where it sends when someone disconnects
<jbarnes> Sarvatt: the new sound blasters can do that in hw
<Sarvatt> yeah i'm gonna have to look into getting something with dolby digital live built in and hope it works in linux i guess :D
<jbarnes> the sound blaster I have works ok with linux
<jbarnes> though the fancy stuff like ac3 transcode aren't supported yet I think (though I havne't looked too hard)
<Sarvatt> i'm guessing i can do it with pulseaudio, or just force it somehow in xbmc.. in windows i do it through ffmpeg so i imagine i can do it in linux too
<Sarvatt> ahhah mplayer -ao alsa:device=iec958 -ac hwac3 <file>
<jbarnes> cool
<jbarnes> I just have my amp do it for stereo streams
<jbarnes> my new amp can do quite a few fancy things with non-7.1 streams
#ubuntu-x 2009-07-08
<RAOF> tjaalton: I'm _fairly_ sure that I don't have to bump shlibs on libdrm-nouveau1, and that the symbols file supercedes that.  Building the DDX against the un-bumped libdrm-nouveau1 picks up a correct versioned dependency of 2.4.11-0ubuntu2, which is what's in the symbols file.
<RAOF> Hm.  FSVO "correct" :)
<tjaalton> RAOF: don't add the packaging version to the shlibs
<tjaalton> hmm
<RAOF> But the symbols were added in that Ubuntu revision; they're _not_ in 2.4.11
<tjaalton> right
<tjaalton> scratch that
<RAOF> Ok.  How do I change my committer name & email in git?
<RAOF> So, the ubuntu branch in libdrm should be good to go.
<Sarvatt> hmm anyone know if radeon HD3300 IGP is supported by fglrx?
<Sarvatt> sweet, pciid 9614 so it is
<Sarvatt> anyone have a fglrx supported system that could test if this patch works for 2.6.31 support for fglrx-installer? http://sarvatt.com/downloads/900_fglrx_31_compat.patch.txt
<Sarvatt> my only ati is a powerpc
<Sarvatt> regarding https://bugs.edge.launchpad.net/bugs/394985
<ubottu> Ubuntu bug 394985 in fglrx-installer "fglrx: Unknown symbol find_task_by_vpid" [High,Confirmed]
<Sarvatt> go figure, xserver 1.6.2 right after i go and make the livecd :D
<Sarvatt> ah it wont build today anyway -- i386      456 builds waiting in queue 
<tjaalton> RAOF: right, according to the dpkg-shlibdeps manpage, it'll look up the symbols file first if it exists, so just having it should be enough
<RAOF> tjaalton: That is the behaviour I saw in my tests, yes.
<jcristau> RAOF: git config --global user.name 'foo bar'; git config --global user.email foo.bar@example.com
<RAOF> Ta
<Ng> hrm, is xserver-xorg-input-synaptics not in the default install?
<jcristau> Ng: see scrollback
<Ng> ah
<Ng> I thought I'd gotten lucky and bought a laptop with an unsupported touchpad
<Ng> now I have to go and disable it in the bios ;)
<Ng> ahh fantastic, disabling the touchpad via gnome doesn't break the trackpoint's mouse buttons like it used to \o/
<popey> hah, never knew there was such an option
<popey> just unticked 'Enable touchpad' then realised i didnt have a mouse
<popey> spacebar to the rescue
<Ng> hehe
<Ng> it should really say "erm, I can only see one input device, are you *really* sure?"
<levonshe> hello all,  Please help me with the next problem :CHROME(0): [dri] DRIScreenInit failed. I have VIX VX800 graphic card, I see in  dmesg that drm module is loaded succesfully, but /dev/dri/card0 is not created, why ??? ([drm] Initialized drm 1.1.0 20060810), 
<tjaalton> levonshe: because the drm module is crap, like I said
<tjaalton> and probably doesn't support your card
<levonshe> tjaalton, since I do not know much about acceleration, you mean this graphic card does can not do direct rendering, so xvmc is not possible ??
<tjaalton> levonshe: what's the pci-id of the card?
<tjaalton> levonshe: lspci -nn | grep VGA
<tjaalton> I guess it's 1106:1122, in which case it's not supported
<tjaalton> and it's a chrome9 chip
<levonshe> tjaalton, you was right, it is indeed 1106:1122. Do you have any info if this board is going to be supported in the near future, other chrome9 boards have atleast 2D acceleration?
<tjaalton> levonshe: probably not even in 9.10
<tjaalton> but AIUI the newttm is now merged in 2.6.31 and that should make it easier to push the new driver upstream
 * hyperair grumbles about compiz eating up 2G of GEM memory *instantly* upon startup
<hyperair> wtf happened?!
 * hyperair pokes Sarvatt 
<hyperair> hmmm not mesa, not drm
<hyperair> must be xorg-server
<hyperair> aha it is xorg-server
<tormod> wow, google chrome OS. wow. are they gonna use X on it?
<tormod> Steve B must be throwing a lot of chairs today
<Sarvatt> http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.6-branch&id=c859b736d1d23c5dc2f53958b1e76660e6d45018
<Sarvatt> hmm
<Sarvatt> intel not building because of that commit
<Sarvatt> http://launchpadlibrarian.net/28792374/buildlog_ubuntu-karmic-i386.xserver-xorg-video-intel_2%3A2.7.99.901%2Bgit20090708.0402f4f3-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
<Sarvatt> what a headache to wake up to :D
<Sarvatt> hyperair: downgrade xserver if you can
<tjaalton> they all should fail to build
<Sarvatt> i'm stumped unless i go and revert that commit from xserver
<jcristau> i suspect there'll be an 1.6.3 soon :)
<Sarvatt> ahhh i should have read the chat log for #xorg-devel, looks like you guys were talking about it already
<Sarvatt> yeah i'll revert it for now, then wait the 12 hours for it to build and reupload intel and ati and it'll probably be fixed in server1.6 branch by then. wish you could turn off PPAs so people dont download broken stuff :D
<jbarnes> Sarvatt: what did I miss?  the memory eating bug?
<Sarvatt> intel ddx not building against xserver 1.6.2 and things being broken using intel compiled against 1.6.1.902, dont upgrade edgers stuff yet if you havent today :D
<jbarnes> too late :)
<Sarvatt> uploaded the fix for xserver so intel will build but theres a 12 hour queue on launchpad
 * Ng wonders why i386 is so backed up
<Sarvatt> oh crap
<Sarvatt> its 2 pm
<Ng> I know a lot of the PPA buildds dropped out in the last couple of days, but that's surprisingly unbalanced
<Sarvatt> mozilla/chromium build bots beat me
<Sarvatt> so maybe closer to 24 hours
<Sarvatt> https://edge.launchpad.net/builders/
<Sarvatt> its because theres like 1/4 the normal amount of builders
<Ng> yeah they come and go as the hardware is used eleswhere, it just seems odd that i386 is significantly more behind than amd64
<Ng> but it could juts be that the i386 hardware pool was depleted more significantly
<Sarvatt> it probably got stuck compiling gcc's or something that takes a long time like that, or theres a large amount of generic arch builds queued up since those build on i386 (just guessing here)
<Sarvatt> i dont get how amd64's queue got so low with only 3 builders now that you mention it
<tjaalton> Ng: aren't you tending those :)
<Ng> tjaalton: we're nominally responsible, but the hardware is shared, so if the other users need it there's nothing we can do about it :)
<Sarvatt> [Disabled] 	thorium 	AUTO 	(113, 'No route to host')  ?
<Sarvatt> thats a new one
<tjaalton> Ng: ah, ok :)
<Ng> Sarvatt: that happens a fair bit, it means that buildd has been reclaimed for something else and isn't routable on the PPA network anymore
<Ng> Sarvatt: oh good point, the arch:all stuff builds on i386 afair
<Sarvatt> hopefully its just that there are a ton of things from the translations ppa or that keyring PPA in the queue that'll go by fast or something
<Sarvatt> http://lists.x.org/archives/xorg-devel/2009-July/001338.html
<bryce> heya
<Sarvatt> heyo bryce
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/metacity/+bug/389686
<ubottu> Ubuntu bug 389686 in metacity "compiz --replace fails to kill metacity, resulting in cpu overload" [High,Triaged]
 * Sarvatt cheers
<Sarvatt> wow chromium alone takes 1.5 hours per build and is building 12 times? theres only 12 builders, no wonder
<superm1> why does it build 12 times?
<Sarvatt> 4 seperate distros, 3 arches per distro
<superm1> oh yeah trying to build for all supported ubuntu releases; makes sense
<superm1> i think it's silly that lpia is still on the PPAs for karmic+
<superm1> would much rather see that turned into another couple i386 builders
<superm1> oh Sarvatt, regarding that fglrx patch you posted, I highly doubt that would work.  pid is not an integer in pid_task, but a struct
<superm1> it might compile an load, but that code path would be broke
<Ng> superm1: why is it silly for lpia to be there? it's a supported arch
<bryce> jbarnes, hey btw did anyone get to porting the pci quirks over to the kernel?
<jbarnes> bryce: some of the quirks are ported
<jbarnes> edid and some of the tv & lvds stuff afaik
<jbarnes> though our tv detection is better in the kernel I think
<bryce> ok
#ubuntu-x 2009-07-09
<Sarvatt> eww, nasty crash when using nvidia binary drivers with fullscreen flash in firefox 3.5 https://bugzilla.mozilla.org/show_bug.cgi?id=469439
<ubottu> Mozilla bug 469439 in Plug-ins "Crash when enabling fullscreen flash video [@ @0x110430 ]" [Critical,Assigned]
<superm1> Ng, because for karmic it's not getting any care to "keep" working per UDS discussions
<superm1> its just around in case it needs to be revived because it's easier to keep the arch up and "running" than re-bootstrapping it
<superm1> Sarvatt, apparently that happens with AMD drivers too apparently
<superm1> if you LD_PRELOAD libGL.so.1 it works okay though
<Sarvatt> hmm something changed.. xserver-xorg-video-intel_2.7.99.901+git20090708.40e7c950-0ubuntu0sarvatt.dsc: Version older than that in the archive. 2:2.7.99.901+git20090708.40e7c950-0ubuntu0sarvatt <= 2:2.7.99.901+git20090708.0402f4f3-0ubuntu0sarvatt
<bryce> you've got two git pulls with the same date
<Sarvatt> used to be able to upload new source when the commit id was higher
<Sarvatt> 40e7 > 0402 part i meant
<bryce> 402 > 40 ?
<Sarvatt> not just ignoring the 0 either
<Sarvatt> xserver-xorg-video-ati_6.12.99+git20090708.8c03c1fd-0ubuntu0sarvatt.dsc: Version older than that in the archive. 1:6.12.99+git20090708.8c03c1fd-0ubuntu0sarvatt <= 1:6.12.99+git20090708.0519f15a-0ubuntu0sarvatt
<Sarvatt> stopped reading past the . or something?
<bryce> possibly, not sure
<Sarvatt> will have to look over the huge dpkg changelogs
<Sarvatt> odd that the .r1 trick still works
<Sarvatt>  OK: xserver-xorg-video-ati_6.12.99+git20090708.r1.8c03c1fd.orig.tar.gz
<Sarvatt> ahh ati is still broken because of the dri2 abi changes, guess i'll manually go in and change all DRI2BufferPtr to DRI2Buffer2Ptr to fix it
<hyperair> Sarvatt: downgraded and it works.
<Sarvatt> hyperair: things are fixed now, or at least they should be
<hyperair> Sarvatt: great! lemme go test
<Sarvatt> just ati still broken, not sure if i want to kludge it or wait for the real fix that'll probably get commited right after i upload
<hyperair> heh
<Sarvatt> changing everything in src/radeon_dri2.c to DRI2Buffer2Ptr works but im not sure which parts i should leave unchanged for the non xserver 1.6.2 situation
<hyperair> i'd say wait then =\
<Sarvatt> mesa and libdrm moving to bzr?
<Sarvatt> just got a bunch of ** Branch linked: lp:ubuntu/karmic/mesa
<hyperair> O_o
<RAOF> Oh, sweet lord, please yes!
<RAOF> Deliver me from git.
 * Sarvatt groans
 * hyperair groans too
<Sarvatt> oh you're one of "them" :D
<RAOF> I can use git, but all sorts of parts of it are still wrong.
<hyperair> i'd say the same about bzr =\
<Sarvatt> do you use KDE too?
<RAOF> Such as not having a monotone versioning scheme :)
<Sarvatt> i'm just teasing, please dont get offended :)
<hyperair> you mean revision numbers?
<RAOF> hyperair: bzr certainly has its flaws; I just don't run into them as often.
<RAOF> hyperair: Yes, I mean revision numbers.
<hyperair> RAOF: i kinda like git's better. at least when you look at a commit ID, it is *unique*
<RAOF> And I think bzr's flaws are in a different direction to git's, generally.
<hyperair> unlike bzr's
<hyperair> commit #10 can mean one commit on one repo, another on another repo, and yet another on another repo
<Sarvatt> i just spent way too much time wrapping my head around git and am partial to it
<RAOF> Stockhlom syndrome :P
<hyperair> i spent more time wrapping my head around svn than git =\
<hyperair> mostly because i had never used a vcs before that
<RAOF> hyperair: I guess so.  I find "trunk, r2013" makes more sense than <insert 128bit SHA hash>
<Sarvatt> i like to pretend svn never existed personally LOL
<RAOF> Eh.  Until I tried to use branches, I was quite happy with svn.
<hyperair> RAOF: i just find it a little confusing after merges
<RAOF> Once I _did_ try branches... oh. my. lord.
<hyperair> lol
<hyperair> i was happy with svn until i found bzr
<hyperair> simply because it allows you to have a local repository
<RAOF> git log should default to topological sort, too. :)
<hyperair> rather than having to create a repository elsewhere, and then checking out
<hyperair> git's power comes from custom aliases =p
<hyperair> alias log into log --graph and you'll be happy =D
<Sarvatt> until you go to git log > ChangeLog :D
<RAOF> But it's not the default, so people do silly things like insist you rebase rather than merge so that you don't add commits that appear to be in a release without actually being in a release.
<hyperair> well you can dump your git log --graph into the ChangeLog and then see the topology in the ChangeLog =D
<hyperair> RAOF: who is this "people" O_o
<RAOF> GStreamer.
<hyperair> club those people in the head then
<tjaalton> bzr.. meh
<hyperair> git - 2; bzr - 1.
<hyperair> =D
<tjaalton> I guess the branches were done automatically
<jonathan__> Can some1 help me or point me in the right direction of the 845GV drivers?
<Sarvatt> they're called xserver-xorg-video-intel and installed by default
<jonathan__> I have " unknown " for my display stuff
<Sarvatt> are you using KMS?
<jonathan__> so everythings stuck 800x600 and i'm a n00b at that
<jonathan__> this*
<Sarvatt> what ubuntu release?
<jonathan__> 9.04
<Sarvatt> there's updates available in this PPA you can try https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates
<jonathan__> thanks a ton
<Sarvatt> if that doesnt work theres even newer updates in another PPA but it'll uproot all of X so it'd be good to see if those work first
<Sarvatt> https://launchpad.net/~xorg-edgers/+archive/ppa
<bryce> http://people.ubuntu.com/~pgraner/IMG00152-20090709-1001.jpg
<Sarvatt> eww! whats that bryce?
<Sarvatt> that looks like the cursor corruption I get on intel in the middle of the screen :D
<bryce> Sarvatt, some bug pgraner (kernel team manager) discovered after updating this morning
<Sarvatt> whats it a bug in? was that just booting up?
<bryce> guess so, I don't have any details other than the photo
<bryce> I suggested he log a bug report
<jonathan__> -_- all this is confusing. ubuntu + stoned = bad idea.
<Sarvatt> add the PPA sources to your /etc/apt/sources.list, sudo apt-get update then sudo apt-get upgrade
<Sarvatt> then reboot
<jonathan__> Should i mention this is my first time using linux...... ever lol
<jcristau> jonathan__: can you put your /var/log/Xorg.0.log on a pastebin?
<jonathan__> 1 sec
<Sarvatt> open up a terminal in applications - accessories - terminal
<jonathan__> I know about terminal
<jonathan__> well not a lot, just its the command thingy lol
<Sarvatt> sudo nano /etc/apt/sources.list
<jcristau> that might give an idea as to why you only get that resolution
<Sarvatt> yeah what jcristau said :)
<jcristau> before you mess with random ppa packages :)
<jcristau> (ok, not random, but still)
<jonathan__> lol
<jonathan__> http://apoboc.pastebin.com/d57634d82
<tjaalton> that's not intel, but openchrome
<tjaalton> the one in 9.04 is full of fail, modesetting-wise
<jonathan__> confused already lol
<Sarvatt> you have VIA graphics not intel graphics
<jcristau> Sarvatt: there's a "does xorg-edgers work well on debian/sid ?" question on debian-x.  do you know of a reason it wouldn't?
<jonathan__> lame, My pc case says NEW! intelRextreme graphics 845gv lol
<jonathan__> what a peice
<Sarvatt> xserver and mesa are built differently mainly, they might have the extra mesa bits installed from debian if they go that route
<Sarvatt> but there are a few people using it fine over on the phoronix forums
<jcristau> that's just libGLw though, iirc.  nothing uses that :)
<Sarvatt> yeah :D
<Sarvatt> we use origin/debian-unstable or experimental for debian/ on everything else so it shouldnt be a big deal
<jonathan__> alright I can handle this 800x600 for a cpl days, Just going to buy an nvidia card
<tjaalton> you can force the resolution in /etc/X11/xorg.conf
<tjaalton> google for more
<tjaalton> or man xorg.conf
<Sarvatt> theres an updated openchrome on x-updates, looking into it now to see if theres any fixes lately we can bring in on there
<tjaalton> the randr1.2-branch was applied a bit too late for jaunty
<tjaalton> and development seems a bit slow these days :/
<Sarvatt> eww svn
<tjaalton> Sarvatt: indeed..
<Sarvatt> too bad he left, it probably would get fixed updating from jauntys to x-updates openchrome looking at the revision history
<bryce> Sarvatt, on bug 385832 do we just need to pull that patch in?
<ubottu> Launchpad bug 385832 in xserver-xorg-video-intel "[i965gm] lower reslutions no longer available on LVDS with 2.7.99 (KMS)" [Low,Triaged] https://launchpad.net/bugs/385832
<Sarvatt> nope i'm pretty sure it was part of a larger patch series
<Sarvatt> but that was the specific commit so i quoted it
<bryce> ah gotcha, so in that case maybe we should just pull in the git20090702 snapshot into karmic.  what do you think?
<Sarvatt> it was a 6 part patch series with the 5 commits before it, i dont know whats needed
<Sarvatt> sounds good :)
<bryce> on it
<Sarvatt> the dpms fix is really important IMO
<Sarvatt> and thats in there
<bryce> ok
<bryce> yeah let me know what bugs get fixed by this, and I'll make sure they're mentioned in the changelog
<Sarvatt> if you pulled a newer one you could just do a no change rebuild whenever xserver is updated, but it'll require updating intel whenever xserver is updated if you do 0702
<Sarvatt> i mentioned a bunch in the x-updates changelog if it helps any
<Sarvatt> ahh mostly for the dpms thing i guess, lets see
<Sarvatt> i'll dupe the xrandr modes ones to Bug #385832
<ubottu> Launchpad bug 385832 in xserver-xorg-video-intel "[i965gm] lower reslutions no longer available on LVDS with 2.7.99 (KMS)" [Low,Triaged] https://launchpad.net/bugs/385832
<bryce> great
<bryce> yeah your changelog is about perfect
<bryce> I'll merge it with our previous changelog
<bryce> oh also I usually itemize the specific patches that were dropped, for extra clarity
<Sarvatt> good to know, will do that in the future. still learning the ropes :)
<bryce> yep, you're doing good :-)
<bryce> Sarvatt, have you thought about applying for MOTU?  I think you're pretty much ready
<Sarvatt> yeah I have been looking into that but I've had my hands full lately, plus I felt a little awkward about it because I've only been in the community for 3 months.. I think I'll take some time out today and put some effort into applying if you say that :)
<bryce> you've done considerably more than the typical motu applicant, you're definitely well qualified.
<bryce> Sarvatt, how many people have sponsored uploads for you, besides me?
<Sarvatt> noone
<Sarvatt> just the 5 uploads from you
<bryce> ok, so maybe that's something we could kick up a bit
<bryce> also I'll definitely vouch for you, but it usually helps a lot to have several sponsors since they like multiple sources of feedback about an applicant
<bryce> Sarvatt, so what you could do is look through http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html for little things needing merges, and post debdiffs, and then ask for upload sponsoring from me, tjaalton, superm1, and one or two others
<Sarvatt> i think there was a builder problem in the last mesa upload that you sponsored from me http://launchpadlibrarian.net/28787457/buildlog_ubuntu-karmic-armel.mesa_7.5~rc4-1ubuntu3_FAILEDTOBUILD.txt.gz
<Sarvatt> Session terminated, killing shell...make: *** [binary-arch] Terminated
<Sarvatt>  ...killed.
<Sarvatt> Build killed with signal 15 after 150 minutes of inactivity
<bryce> dah
<bryce> weird, I've not seen that particular build failure before.  Was it only arm that failed or any other platforms?
<Sarvatt> was just looking at my uploads and saw it failed on armel, that looks transient though and i dont see any problems with the build
<bryce> it's probably not a big deal that arm failed, it's rather new
<bryce> ok I think we can ignore it.  afaik X doesn't work on arm yet anyway
<Sarvatt> eww, really? I'm looking into an arm platform to buy to work with things
<bryce> on that merge page, the "Notes" title links to a wiki page where you can list status/notes about merges you work on, or todo items about the merges that are needed
<bryce> if you look at the history of that Notes page you can see examples from timo and I
<bryce> yeah I think arm is framebuffer only
<Sarvatt> ah thanks for the heads up! sorry I was sidetracked looking into mesa there when you said it :)
<bryce> Sarvatt, with the merges, the red links are good opportunities (esp. the minor drivers, those are usually easy), and also packages that are showing to have a git snapshot might be worth refreshing with a newer snapshot
<Sarvatt> oh nice, you have this page automatically updating? I thought you just took a snapshot in time when you linked it on ubuntu-x
<bryce> right it updates automatically
<bryce> (three times an hour)
<Sarvatt> there are quite a few things with git snapshots that have had releases upstream I imagine, they went and tagged releases on a ton of things this past week
<bryce> yeah, I noticed
<bryce> so this is actually a really good point to be working towards MOTU
<bryce> those upstream versions will get packaged by Debian soonish (typically they do them within a week or so if there's nothing funky)
<bryce> a lot we can file sync requests for, but there will be a bunch that need manual merges
<bryce> good practice :-)
<Sarvatt> thank you very much again for all of the help bryce, I appreciate you going out of your way to help me with this
<bryce> not a problem :-)
 * bryce --> lunch bbiab
<jcristau> might take some time to get stuff in debian, since brice and i are on vac
<Sarvatt> hyperair: this your problem? https://bugs.edge.launchpad.net/bugs/287215
<ubottu> Ubuntu bug 287215 in xserver-xorg-input-evdev "xmodmap settings not getting honored when keyboard devices are hotplugged" [Medium,Triaged]
<Sarvatt> might be worthwhile syncing pixman from debian experimental, it reenables SIMD extensions on arm
<Sarvatt> considering i think ubuntu is only targetting armv6 and higher in the first place unlike debian who needed to disable it because runtime detection wasnt working before
<tjaalton> Sarvatt: pixman with xserver 1.6 has issues
<tjaalton> pixman 0.15.x I mean
<Sarvatt> darn it, i should have checked the lists before uploading a new 15.15, getting this too http://lists.x.org/archives/xorg/2009-July/046366.html
<Sarvatt> ah i think i saw something about a regression on 1.6 branch with 15.x on the lists
<Sarvatt> now that you mention it
<tjaalton> can't find the reference anymore though
<tjaalton> the recent video driver updates were pretty irrelevant, btw
<Sarvatt> me neither, checked xorg and xorg-devel for the past 3 months hmm
<Sarvatt> yeah i know, it was just to pad a motu application :D most stuff was just the loader symbol lists getting removed
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=22484
<ubottu> Freedesktop bug 22484 in libpixman "Notification area icons are not displayed" [Normal,New]
<Sarvatt> there it is, notification icons not showing
<Sarvatt> comment 10
<tjaalton> eah
<tjaalton> +y
#ubuntu-x 2009-07-10
<james_w> yay, new -intel, thank you
<bryce> james_w, yep, hope it's stable.  Was looking like the number of issues fixed by updating it was greater than my interest in continuing to cherrypick ;-)
<james_w> well, it closed the bug that I thought was mine, so I'll be happy if that was the case
<james_w> I'll hopefully be able to suspend next time I'm away from home :-)
<bryce> yeah the suspend fix was the biggie
<bryce> I was a bit aggressive at guessing on some bugs that I *think* are going to be fixed.  I figure the users will be bold in reopening the bugs if I'm wrong :-)
<james_w> yeah, I don't think you'll have a problem with that :-)
<james_w> I saw Jesse's post on possibly being able to capture a GPU dump when it freezes, that would be great
<Sarvatt> i made sure every bug closer i added to the dpms off fix was fixed for the original reporter by the update in x-updates, resume from suspend would be more in a kernel fix i would think unless dpms is getting turned off before suspend for some reason? there was a fix for most peoples suspend/resume problems in 2.6.31-rc2 and 2.6.30.1
<bryce> james_w, yeah I need to pull that patch and take a look at it
<bryce> Sarvatt, yeah I actually went and added several more bug#'s on top of yours.  I'm sure yours are accurate, but less confident on mine :-)
<james_w> Sarvatt: I could suspend and resume fine, but I had no X afterwards, and dpms would sometimes lead to the same thing as well
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9e06dd39f2b6d7e35981e0d7aded618686b32ccb
<Sarvatt> ah, any idea if it only happen when compiz was enabled james_w?
<james_w> I'm happy to have the bug marked as fixed either way, as I never did what I should and invested the time to delve in to the problem
<james_w> if it's not fixed then I will do so
<james_w> yeah, I never tried without it actually
<james_w> -intel has been too solid otherwise so far for me in karmic that I never thought to try without it :-)
<Sarvatt> theres someone reporting that 965+ isnt resuming right with compiz enabled still even after the ordering fix but he hasnt been able to figure out why
<james_w> I'm 945 for what it's worth
<Sarvatt> ah good
<Sarvatt> do you use KDE?
<Sarvatt> i think KDE locks the session and does a dpms off on suspend
<Sarvatt> seemed like most of the people having problems with it were using KDE, thats why I filed one of the bugs against acpi-support because it was using the screenblank script in there under KDE causing problems, getting rid of the screenblank script and letting just KDE handle dpms fixed it for a few people before it was fixed in the driver
<Sarvatt> that was just for people with hangs on lid close though
<james_w> nah, GNOME
<Sarvatt> heads up btw
<Sarvatt> Setting up xserver-xorg-core (2:1.6.99.1+git20090709.e8121033-0ubuntu0sarvatt) ...
<Sarvatt> dpkg: warning: obsolete option '--print-installation-architecture', please use '--print-architecture' instead.
<Sarvatt> whenever xserver gets updated, new dpkg change
<Sarvatt> xorg-server/debian/xsfbs/xsfbs.sh:ARCHITECTURE="$(dpkg --print-installation-architecture)"
<Sarvatt> ah it'll be pulled in from debian anyway http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=7deebf983f53c505bc25171ab77fdc408f250a6e
<Sarvatt> adding patches on top of the current xserver will give the error though (not that it hurts anything)
<bryce> :-)  <kees> "Launchpad can now import code from Git repositories." whoa
<kees> bryce: http://blog.launchpad.net/bazaar/git-imports
<bryce> kees: bryce@chideok:/tmp$ bzr branch lp:xserver-xorg-video-intel
<bryce> bzr: ERROR: Invalid url supplied to transport: "lp:xserver-xorg-video-intel": xf86-video-intel has no default branch.
<bryce> hrm
<james_w> woop, seems to be fixed. Thanks all
<Sarvatt> bryce: do you have to link it first somewhere?
<bryce> probably
<bryce> james_w, nice :-)
<Sarvatt> https://code.edge.launchpad.net/+code-imports/+new
<Sarvatt> bzr branch lp:ubuntu/karmic/mesa and libdrm work
<bryce> Sarvatt, sweet!
<kees> ~[6~[6~[6~[6~/win 13
<kees> argh
<Sarvatt> speak of the devil, they fixed that bug in pixman tjaalton -- http://cgit.freedesktop.org/pixman/commit/?id=0fce356762864572ae126733f657600fbb9116ce
<tjaalton> Sarvatt: nice
<tjaalton> FYI, I'll be more or less offline the next two weeks..
<tjaalton> bryce: ^^
<tjaalton> here's hoping that 1.7beta is released by then ;)
<bryce> tjaalton, okay hope it's for something fun :-)
<tjaalton> bryce: yeah, back to vacation. tomorrow I'll participate in a rowing contest, but just for fun
<tjaalton> 60km on a boat with seven pairs and a captain
<tjaalton> my butt will be sore :/
<tjaalton> other than that it's just lazying at the summer cottage
<bryce> ah good, was worrying a bit you might be rowing to Ireland for some plundering ;-)
<tjaalton> yeah, there must be some viking blood in my veins :)
<Ng> ooh, -intel update
<RAOF> Yeah, with bonus crazy 60Hz mode.
<hyperair> crazy 60Hz mode?
<bryce> RAOF, you mean return of vblank sync?
<RAOF> bryce: No, I mean trying to drive my LVDS with a 60Hz mode that the display doesn't like one bit.
<RAOF> There'll be a bug filed with cool screenshots.
<bryce> ok
<apw> Sarvatt, how far away do we think the ati kms userspace support is?
<ScottK> james_w: It looks like dontzap is still setting xorg.conf, but that doesn't have the effect in Karmic that it did in Jaunty.  Do you know how that's supposed to be set now?
<james_w> through the keyboard layout
<james_w> so it's now per-user and doesn't require an X restart
<ScottK> I see.
<ScottK> tseliot: Did you plan on updating dontzap?
<tseliot> ScottK: yes, sure
<jcristau> what's the use for dontzap at this point?
<ScottK> jcristau: Making ctal-alt-backspace work.
<jcristau> well, no
<jcristau> the gnome kbd applet does that
 * ScottK doesn't use Gnome.
<jcristau> the kde kbd applet, then
<tseliot> the last time I tested it, setting dontzap with setxkbmap didn't work
<ScottK> jcristau: It doesn't support that.
<tseliot> in Karmic but it worked in Fedora
<jcristau> tseliot: so fix the server to have DontZap off by default
<tseliot> jcristau: isn't it off by default again now?
<jcristau> it is upstream and in fedora
<tseliot> in the past we used what upstream decided so as to minimise maintenance
<ScottK> tseliot: I built xserver-xorg-input-synaptics for karmic in my PPA with your patch for settling the touchpad down and it's made a huge difference with my mini 10v
<tseliot> ScottK: yes, unfortunately it can't be upstreamed as it's very specific to the mini 10v
<ScottK> tseliot: Thanks for the patch.
<tseliot> james_w: does setxkbmap work for you to enable/disable zapping in Karmic? (I'm still using jaunty)
<james_w> Haven't tried actually
<tseliot> ScottK: it's my job (OEM) ;)
<ScottK> tseliot: Just because you got paid to do it doesn't mean I can't appreciate it.
<tseliot> tjaalton: ^^ (setxkbmap)
<tseliot> ScottK: I'm glad it helped :-)
<ScottK> I'll also look at the KDE systemsetting module and see how hard that would be to patch instead.
<ScottK> Maybe maco will do it since she want's to improve her C++
<james_w> ScottK: you don't need to
<james_w> as I see it
<ScottK> How so?
<james_w> I could confirm if I could fathom the way through this twisty path
<james_w> the magic of good software design :-)
<james_w> where will ./kcontrol/kxkb/kxkb_part.cpp end up?
<james_w> or how can I access that part I mean?
<maco> do what?
<ScottK> maco: We're discussing making dontzap work for KDE in Karmic
<maco> it doesnt?
<james_w> doesn't work for anyone in karmic
<maco> oh. good to know, i was just about to try it
<maco> since suddenly, today, my vga claims to have nothing connected to it. which is a lie. and it worked on wednesday
<maco> and no, this isnt the 13 hours ago upload of -intel. im still on the version from a few days ago. and randomly deciding to ignore my VGA port after resuming from suspend isn't a first :-/
<tseliot> I wanted to set the xkb option in xorg.conf and use setxkbmap to apply settings without having to restart X. This way it's DE agnostic
<jcristau> that's because there's no need for it in karmic... if the default is changed to off in the server, and kde/gnome both use libxklavier, they'll just have the option in their applet already
<jcristau> and things will just work
<ScottK> jcristau: OK.  So how come I don't have this option then?
<jcristau> i don't know.  i don't use kde :)
<ScottK> jcristau: OK.  So there is work to do and I'm trying to understand what.
<ScottK> james_w: That should be in systemsettings
<james_w> found it
<james_w> Only-Show-In=kde for half of the parts used by systemsettings is a bit odd
<tseliot> I think I found it
<tseliot> click on  Regional & Language
<ScottK> james_w: KDE gets yelled at for 'duplicate' menu entries if stuff like that isn't done.
<ScottK> tseliot: Yes?
<tseliot> there's a label which says "Command" and then there's a text entry which says something like setxkbmap -model pc104 -layout it,es -variant ,
<james_w> it only shows
<james_w> in the system settings though doesn't it?
<james_w> not found it in my menu
<james_w> http://people.ubuntu.com/~jamesw/layout.png
<ScottK> Interesting.
<ScottK> I have that section, but it's greyed out/locked.
<tseliot> james_w: did you set the xkb option manually?
<james_w> you need to "Enable keyboard layouts" on the first tab there
<ScottK> Ah
<tseliot> james_w: or was the "Key sequence to kill the X server" already there?
<james_w> I did nothing
<james_w> just chased down the GNOME stack and then up the KDE stack to find where the equivalent settings are
<tseliot> nice, so, problem solved?
<tseliot> when X is updated
<ScottK> Interesting.  Works too.
<ScottK> james_w: Very nice.  Thanks.
<ScottK> tseliot: Yes.  Problem solved.
<tseliot> ScottK: ok, so we can remove my patch from kdebase
<tseliot> \o/
<ScottK> tseliot: Yes.
<maco> key sequence to kill the X server is in the Advanced tab
<tseliot> jcristau: do you know if gnome has something similar in its xkb applet?
 * tseliot hopes so
<jcristau> tseliot: it does
<ScottK> So the remaining question is xfce?
<jcristau> that uses xklavier as well
<tseliot> great, this means that we can drop dontzap (the package)
<tseliot> \o/
<jcristau> so it should just work, reading the options from /usr/share/X11/xkb/evdev.xml
<razor7> hello..iá¸¿ quite confused about ATi drivers...can anyone help? Thenka a lot!
<razor7> hello..i'm quite confused about ATi drivers...can anyone help? Thanks a lot!
<razor7> Hello I have an ATi x1950pro video card, but there is no more support from ATi/AMD since they say that this 2 years old card (worth u$s 200 at buytime) is no longer supported by ATi
<razor7> In this repo I see theese two drivers:
<razor7>     fglrx-installer - 2:8.620-0ubuntu3~jaunty
<razor7>     xserver-xorg-video-ati - 1:6.12.2-0ubuntu1~xup~1 
<razor7> I have added the repo and installed xserver-xorg-video-ati - 1:6.12.2-0ubuntu1~xup~1, but the program glmark just hangs wit message "Segmnentation fault"
<superm1> tseliot, why can't that patch be upstreamed?
 * ScottK wonders too.
<ScottK> While Mini 10v is where it really helps it seems like a generally good idea.
<tseliot> superm1: because it's a workaround. A generic solution can't be found as the touchpad doesn't support multi-finger detection and reports some weird finger width/pressure values
<ScottK> tseliot: Are there cases where the values it supresses are valid with other hardware?
<tseliot> ScottK: yes
<superm1> tseliot, so if that's the case, why not just try to detect the specific model of this one, and only do the weird stuff on this one then?
<tseliot> superm1: I thought about that too but I doubt that upstream would include it
<superm1> tseliot, well it's not like it's some archaic wanna-be synaptics touchpad.  it's a real synaptics touchpad that just reacts a little differently than others.
<ScottK> tseliot: I'd settle for something we could ship in our package as a quirk.
<superm1> so i can't see why upstream wouldn't want to see it fully functional albeit with a separate code path for its quirks
<tseliot> ScottK: that could be done
<tseliot> superm1: I'm not upstream ;) but I can ask them
<ScottK> Upstream is better, but if it's something we can at least get in the archive, that'll help a lot of users.
<tseliot> here's the bug report in upstream's bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=21614
<ubottu> Freedesktop bug 21614 in Input/synaptics "Touchpad cursor jumps when two fingers are used" [Normal,New]
<tseliot> my second patch will be adopted (well, sooner or later): http://bugs.freedesktop.org/show_bug.cgi?id=21613
<ubottu> Freedesktop bug 21613 in Input/synaptics "Property to make part of the touchpad insensitive to movements" [Enhancement,Assigned]
<superm1> so both patches help it in different ways then, or are these two separate problems?
<tseliot> yes
<superm1> i suppose i worded that poorly, did you mean yes to the former or latter?
 * tseliot missed the "or"
<tseliot> yes, they are separate problems
<superm1> ah okay
<superm1> so the first one is what would need such a case statement to flag on the broken model #
<tseliot> yep
<tseliot> superm1: if you want you can add a comment in the 1st report and ask upstream directly about adding the quirk
<superm1> tseliot, so the thing is i think that's actually a problem on all synaptics touchpads though, is it not?
<superm1> i'm on a studio 1340 right now, and the same thing happens, but it's not as frequent because the buttons aren't built into the pad
<tseliot> superm1: no as there are different kinds of Synaptics touchpads
<superm1> but if i touch the top right and bottom left corners of the "pad" it will happen just the same
<tseliot> superm1: therefore, if the touchpad has multi-finger detection (not emulation), a different solution can be found
<superm1> ah
<Sarvatt> jbarnes: seen this? xrandr broke in UMS somewhere between git20090630.cec9fc6f and git20090701.1e4784bf https://bugs.edge.launchpad.net/ubuntu/+source/xrandr/+bug/394490
<ubottu> Ubuntu bug 394490 in xrandr "xrandr: Configure crtc 0 invalid time" [Undecided,Confirmed]
<jbarnes> Sarvatt: hm, maybe 7e79fc?
<jbarnes> from fdo bug #19578
<ubottu> Launchpad bug 19578 in initramfs-tools "initramfs-tools: can't install from scratch" [High,Fix released] https://launchpad.net/bugs/19578
<Sarvatt> actually it might have been something in the xserver update at the same time
<Sarvatt> http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.6-branch&id=8d65439d5c950ea01ec8e1e4dd989aff0fb4c3f0
<jbarnes> ah possible yeah
<Sarvatt> uploaded that on july 1st
<Sarvatt> yeah for sure it is an xserver problem, sorry about that jbarnes. one guy reverted to xserver-xorg-video-intel_2%3a2.7.99.901+git20090611.6d062e9e-0ubuntu0sarvatt~jaunty_i386.deb
<Sarvatt> and still had the problems
<Sarvatt> when it was working before
<jbarnes> cool
<jbarnes> should be reported upstream if it hasn't been already
<bryce> jbarnes, btw I finally went through all the 8xx reports that confirmed their problem on karmic alpha-2 and sent them up.  There were actually fewer than I initially estimated since some were dupes, and others were mis-tested.
<bryce> there's another dozen tested/confirmed of 9xx bugs I'll be sending up hopefully today
<Sarvatt> if its dri support in KMS dont they need mesa 7.6?
<bryce> and then there's another 120 which no one's replied at all, that we can probably just close :-)  -- but I'm going to give them a couple more weeks to respond
<jbarnes> bryce: cool
<Sarvatt> do you want us to test the newer pixman on edgers server 1.6 branch at all? or any other packages that might have problems getting updated?
<Sarvatt> yep for sure this is a problem in xserver 1.6.2 that will pop up when karmic updates to it https://bugs.edge.launchpad.net/bugs/394490
<ubottu> Ubuntu bug 394490 in xorg-server "xrandr: Configure crtc 0 invalid time" [Undecided,Confirmed]
<Sarvatt> i'm knee deep in a ton of packaging and need to get it uploaded asap and am working at the same time if anyone else wouldnt mind upstreaming it, will try to do it later tonight if not
<Sarvatt> uploading mesa on a 15kb/second cellphone connection is fun :)
<RAOF> There we go.  One funky scanout bug filed at bug #398026
<ubottu> Launchpad bug 398026 in xserver-xorg-video-intel "[GM45] Default 60Hz display mode drives LVDS incorrectly" [Undecided,New] https://launchpad.net/bugs/398026
<Sarvatt> hmmmm http://launchpadlibrarian.net/28897374/buildlog_ubuntu-karmic-amd64.xserver-xorg-video-intel_2%3A2.7.99.901%2Bgit20090710.4e4b947f-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz
<Sarvatt> http://cgit.freedesktop.org/xorg/xserver/commit/?id=aafcae79d17c1f802bc880d2142af7171fed75d8 ....?
<Sarvatt> compiles fine on i386 but fails everywhere else
#ubuntu-x 2009-07-11
<RAOF> Ah, the joys of !IA32
<Sarvatt> hmm xf86int10.h isnt included in xserver-xorg-dev anymore
<Sarvatt> maybe i need to build with --enable-int10-module even though its supposed to default to enabled
<Sarvatt> darn, even with it xf86int10.h isnt included in xserver-xorg-dev anymore
<Sarvatt> oh I see why, makefile is screwed up
<Sarvatt> anyone using mutter?
<Sarvatt> i'm getting a flood of [  598.220073] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 in dmesg every second when i use it
<Duke`> hum still no menu drawn in blender with intel...
<Sarvatt> yep been 6 months now without menus here :)
<Sarvatt> hmm, if i make a new user i can start compiz fine via appearance preferences, must have a broken setting somewhere..
#ubuntu-x 2009-07-12
<Sarvatt> my psmouse issues have regressed to where i need to rmmod psmouse and modprobe it again every boot now :(
<Sarvatt> http://sarvatt.com/downloads/dmesg.txt
<Sarvatt> hmm, had to use windows for a bit there and that portable ubuntu that runs a colinux kernel and xming xserver with hardy on top of it in windows is pretty darn interesting.. I dont like how Xming is charging for windows xserver/mesa updates though
<Sarvatt> was funny being able to run linux firefox side by side with the windows one and seeing just how bad windows font rendering is :D
<RAOF> No hinting FTW.
<Sarvatt> i like full hinting!
<Sarvatt> have to read up more on how that all works, outside of not having accelerated GL it was pretty much full speed and no different than running stuff natively
<Sarvatt> ah i guess the xserver license does allow charging for binaries after all
<RAOF> Sarvatt: Yup.  The X server license is a "do whatever" onee.
<jcristau> Sarvatt: every free software license allows charging for binaries :)
<Sarvatt> I was up in the air about downloading said binaries obtained from someone who purchased them :)
<Sarvatt> wow... xbmc packaging is sketchy.. this is going to take some work updating
<Sarvatt_> darn, lost brightness keys on this laptop with nvidia too.. wheres devicekit-backlight at? :)
<crevette> hi there
<crevette> does someone have blackflash in its display in karmic? I have a intel chip
<crevette> I suspect a gpm problem
<Sarvatt_> i'm so confused, they're building ffmpeg in xbmc without cmov support and not including most codecs in it, and its installing it into /usr/local/ in the build scripts...
<Sarvatt_> what do you mean blackflash crevette?
<Sarvatt_> screen darken when you hold down backspace?
<crevette> sarvatt, my display becomes black a ten of second or so
<Sarvatt_> could it just be the compiz visual bell?
<crevette> in a random manner
<crevette> I'm just use metacity
<Sarvatt_> do you have visual bell enabled for metacity?
<crevette> no
<Sarvatt_> ahh ok
<Sarvatt_> oops
<Sarvatt_> i said /apps/general/metacity in gconf-editor but it started with a / :D
<crevette> I think I should launch a dbus-monitor and log all
<Sarvatt_> does the screen blank until you do something even when its not idle? or its just a random black screen that goes away on its own?
<crevette> the latter
<Sarvatt_> thats really odd, havent seen or heard of anything like that
<crevette> and sometimes after this "black flash" the backlight value is reset to a darker value
<Sarvatt_> nothing you can think of that triggers it? pressing a certain key or something?
<Sarvatt_> only plugged in or on battery too?
<crevette> hmmm, in both cases it happens
<hyperair> Sarvatt_: http://paste2.org/p/320240 <-- does this ring any bells? =\
<hyperair> basically X crashes after google earth is closed.
<hyperair> while clicking on some icons in gnome do
<Sarvatt_> looks like we need to update x11-xserver-utils whenever we bump xserver to 1.6.2 -- https://bugs.launchpad.net/bugs/394490
<ubottu> Ubuntu bug 394490 in xorg-server "xrandr: Configure crtc 0 invalid time" [Undecided,Confirmed]
<Duke`__> I see that xorg-edgers is now providing pm-utils
#ubuntu-x 2010-07-12
<Takyoji> Is there any further information that I should (and am able to) disclose for this bug report? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/604192
<ubot4> Launchpad bug 604192 in xserver-xorg-video-intel (Ubuntu) "Screen goes blank and flashes vertical stripes on 1s interval (affects: 1) (heat: 6)" [Undecided,Confirmed]
<RAOF> Sarvatt: Rock on, dude, thanks!  We've been publically targetting xserver 1.9 since UDS, and it looks like it's going to be in a better state than 1.8 anyway.
<RAOF> Takyoji: An i845 chip?  Dear lord, I'm surprised it works at all :/
<RAOF> Takyoji: If you're prepared to do a bunch of work, though, that bug looks like it would be amenable to a regression analysis via bisection.
<Takyoji> out of curiosity, how would it not be able to work? :P
<Takyoji> also, is there any specific guide(s) available for regression analysis?
<RAOF> Hm.
<RAOF> I'm not sure if we've got a bisection howto page on the wiki.  Let me check.
<RAOF> Takyoji: The basic principle would be to: (a) Check which component is broken (options here are xserver-xorg-video-intel, the kernel, mesa, or libdrm).
<RAOF> (b) Check out the git source of that component, and run "git bisect" to rebuild it at different points between 9.10 and 10.04 to work out precisely when it broke.
<RAOF> Takyoji: https://wiki.ubuntu.com/X/Bisecting is a bit of an overview; there's also the bisecting mesa page linked from there.
<Takyoji> ahh, alrighty
<Takyoji> So I don't even have to overlook the source code then; just simply find what exact revision broke it?
<RAOF> Right.
<RAOF> You can do that without needing to know anything about the source.
<RAOF> First off, though, you need to know which component broke, so you'll want to try each of the 9.10 components in 10.04, one at a time.
<Takyoji> So first I have to verify which component it even is, before going through bisecting, correct?
<RAOF> Takyoji: Yes.  Because you need to be able to identify a good point and a bad point in the same source.
<RAOF> Then you can run a bisection over that git history.  If you don't have a good *and* a bad point in the same git source then you can't checkout the commit half way between, work out whether it's good or bad, and then repeat.
<RAOF> Alright ladies and gentlemen!  Let your i8xx gpus feast on the joy that is https://edge.launchpad.net/~raof/+archive/aubergine
<RAOF> Everyone *else* who feels like a test could ensure that it doesn't break your working Intel GPU.
<Duke`> what's the difference with xorg-edgers?
<RAOF> The re-introduction of a legacy, non-GEM UMS codepath.
<RAOF> ie: work around the various longstanding breakages on i8xx cards which were caused by assuming various bits of the hardware actually worked by not using it.
<bryyce> \o/
<vish> do we install the nvidia-settings package by default for all nvidia users?
<tseliot> vish: the nvidia packages recommend nvidia-settings
<tseliot> it's treated as a dependency
<vish> tseliot: ah ok , thanks
<tseliot> vish: BTW did the gtk guys reply to your request to integrate my patch for that papercut now that we know that Orca would work fine?
<vish> tseliot: yeah , i'll have to poke ebassi again today..
<tseliot> vish: ah, good
<vish> he was the one who requested review from accessibility folks
<tseliot> ok, let's see if he decides to include the patch now or if he has further requests
<scar_> what's the most stable 2.6.35 kernel? I've tried the one that comes with mavrick alpha2 and I've tried lucid with linux-image-2.6.35-7-generic-pae. I know this is bit off topic but I'm trying to test xorg-edgers' nouveau driver so I need a 2.6.35 kernel
#ubuntu-x 2010-07-13
<RAOF> Everyone should have at least 2 machines.  That way, when X dies with an EQ overflow, you can grab interesting data :)
<Kano> when will libdrm 2.4.21 be in maverick? thats required for libva for intel
<Kano> its in debian experimental already
<jcristau> when somebody gets around to it, i guess
<jcristau> i don't think libva is anyone's priority
<Kano> the other requirement is kernel 2.6.35, that would be fine already
<Dr_Jakob> Sarvatt: Hey
<Dr_Jakob> Sarvatt: pushed a fix for http://pastebin.com/6LBMjuEV to mesa some hours ago.
<Sarvatt> Dr_Jakob: updated mesa uploading now
<Dr_Jakob> does it include 04453a32?
<Sarvatt> includes everything on master at the moment
<Sarvatt> up to 962da13ba30d66bd8b9a28ba5f06c66ceec1ce92
<Dr_Jakob> ok thanks
<Dr_Jakob> Sarvatt: ok so 2D should work with the new driver, there is a weird bug with dlopen that is stopping 3D now.
<Sarvatt> haven't finished installing it yet but 2D was working last I tried - http://sarvatt.com/downloads/vmwgfx.txt
<Dr_Jakob> hmm wierd maybe you didn't build with LLVM then..
<Dr_Jakob> Or maybe that was before we started using llvm for software vertex shading.
<Dr_Jakob> Oh well
<Dr_Jakob> It should work, haven't tested the LLVM part other then building it and checking the symbols.
#ubuntu-x 2010-07-14
<RAOF> Gah.  Stupid -nr patch
<Sarvatt> what's wrong RAOF?
<Sarvatt> RAOF: need a refreshed -nr patch for 1.9? i've got one in edgers
<Sarvatt> or were you merging intel and needing to refresh the copy-fb patch?
<tseliot> Sarvatt, RAOF: when do you plan to upload xserver 1.9?
<Sarvatt> just a rough guess at a month or so from now
<tseliot> in time for alpha 3?
<Sarvatt> doubt it'll be there by then
<Sarvatt> oh august 5th, maybe
<Sarvatt> i thought that was closer
<Sarvatt> it's pretty much ready to go outside of a few patch refreshes needed
<tseliot> ah, good
<Sarvatt> I actually just got permission to backport support for the latest xorg 1.9 release candidate to the 256.* series of drivers, so hopefully we'll be able to get a beta version of that out soon.
<Sarvatt> aaronp said that \o/
<tseliot> Sarvatt: that's good news, I knew they were working on it
<tseliot> Sarvatt: let me know when it's ready and I'll sponsor the upload
<tseliot> Sarvatt: the mesa packages in xorg-edgers don't set alternatives, do they?
<Sarvatt> yeah they do, didn't want to break anything
<tseliot> Sarvatt: ok, so they should work with proprietary drivers (just for testing experimental releases)
<Sarvatt> yepyep
<tseliot> great
<Sarvatt> tseliot: reason i'm giving a long estimate is because theres still a few problems that will probably be fixed by then, like I dont believe tslib works so arm people will be unhappy, and a few drivers like evdev and synaptics haven't had releases compatible with it yet
<tseliot> oh, that definitely makes sense
<Sarvatt> worried about the arm video drivers too and it'd probably be better to bring it in sooner to get it fixed up in that regard..
<Sarvatt> i dont even know what they are, know theres an omapfb and a dovefb one at least
<tseliot> right, the arm mess...
<jcristau> people care about tslib?
<Sarvatt> yeah arm people, not to mention egl clutter only works with tslib
<Sarvatt> i know someone was screwing with egl clutter on arm because thats was the whole reason we packaged the egl stuff in mesa up
<jcristau> wtf
<jcristau> the toolkit shouldn't care what X driver is in use
<Sarvatt> hmm yeah that doesn't make sense, it's got to use an actual tslib lib not the x input driver since the egl backend doesn't use X?
<Sarvatt> libts i guess
<jcristau> yeah that would make more sense
<Riemervdzee> Good evening
<Sarvatt> these "foobar crashed with SIGSEGV in XF86DRIQueryVersion()" sure are annoying :)
<Sarvatt> every single one is just them having fglrx installed but not using fglrx
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=crashed+with+SIGSEGV+in+XF86DRIQueryVersion() -- argh i've already closed at least 20
<Sarvatt> oh more than half of those are private so it doesn't look as bad if you cant see those :)
<Sarvatt> i'm duping everything to https://bugs.edge.launchpad.net/ubuntu/+source/fglrx-installer/+bug/545257 before i close it this time
<ubot4> Launchpad bug 545257 in fglrx-installer (Ubuntu) "gnome-screensaver-gl-helper crashed with SIGSEGV in XF86DRIQueryVersion() (affects: 85) (dups: 21) (heat: 238)" [Medium,New]
#ubuntu-x 2010-07-15
<RAOF> Sarvatt: Nah, the -nr patch itself wasn't the issue.  The issue was updating -intel's patch for 2.12+legacy.
<RAOF> Sarvatt: Oh, and does unity crash the X server for you (in mesa, dri2 flush paths) with 1.9 + intel 2.12?
<Sarvatt> do i have to run a unity session to crash it?
<Sarvatt> i just ran unity and got a crapload of errors and the bar is blank, first time running it
<Sarvatt> it didnt crash though
<Sarvatt> RAOF: sorry, shoulda pinged you about that :)
<RAOF> You might.
<RAOF> I haven't yet done much investigation.
<Sarvatt> how did you crash it?
<Sarvatt> lemme try a session, need to reboot for this new kernel anyway
<RAOF> Run 1.9 + 2.12+legacy, from gdm select UNE session.
<RAOF> Boom!  X crash, mesa, invalidate buffers.
<Sarvatt> http://paste.ubuntu.com/463747/
<Sarvatt> got your 2.12+legacy packaged anywhere?
<Sarvatt> brb rebooting into unity
<RAOF> In raof/aubergine, yeah.
<Sarvatt> no crash
<Sarvatt> but it doesn't work
<Sarvatt> it's in a little 640x480 or so area inside my real resolution
<Sarvatt> and you cant see anything but a few buttons at that size
<RAOF> Hm.  Might be +leagacy breakage, then.
<RAOF> or even legacy.
<RAOF> Legacy is sitting in the raof/aubergine PPA if you want to try it.
<RAOF> You'll need to rebuild against 1.9 obviously.
<Sarvatt> got a backtrace on the crash by any chance?
<RAOF> In fact, you'll need to build locally *anyway*, as the PPA hasn't yet built.
<Sarvatt> even just the xorg.0.log one
<RAOF> http://paste.ubuntu.com/463755/
<RAOF> Is not very good.
<Sarvatt> are you using UMS?
<RAOF> No, not then.
<RAOF> Wait a sec, I'll get a proper backtrace.
<RAOF> http://paste.ubuntu.com/463759/ is a better one.
<Sarvatt> looks like mesa to me
<Sarvatt> does it happen with this in ~/.drirc? http://paste.ubuntu.com/463762/
<Sarvatt> doubt i'll be able to reproduce it, no 965's handy :(
<RAOF> The problem is that drawable->driContextPriv->driverPrivate is NULL at that point.
<RAOF> Hah.\
<RAOF> Well, that theory's nice and easily confirmed.
<RAOF> Intel swap events be broken!
<RAOF> Quadrapassel does the same thing.
<Sarvatt> anything non clutter crash it? :)
<RAOF> Not so far :)
<Sarvatt> CLUTTER_DEBUG=disable-swap-events work?
<Sarvatt> clutter has *so many* debugging env variables
<RAOF> I'm just trying with 2.12 from experimental.
<Sarvatt> tried edgers already?
<RAOF> Ba baw.
<RAOF> No, haven't tried edgers.
<RAOF> Nope.  CLUTTER_DEBUG=disable-swap-events quadrapassel aint a winner.
<RAOF> My guess is that edgers will work, because it'll have a newer mesa built.
<Sarvatt> ahhhhh ok i thought you were using edgers + that intel
<RAOF> Nah.
<Sarvatt> might want to try dropping 102-disable-page-flipping-v2.patch too for the heck of it to be closer to whats in git
<RAOF> Tried that; bug's still there.
<RAOF> Well, rather, bug where the system locks after some period of time is still there; dunno about the clutter crash :)
<Sarvatt> do you have a compiled mesa demos handy by any chance?
<Sarvatt> or uncleaned old 7.8 mesa source tree?
<Sarvatt> can ya see if glxgears_fbconfig crashes you too? :)
<Sarvatt> oh man i miss my irc bouncer, brb again legacy is done compiling
<Sarvatt> I can't even start X with legacy on 945
<Sarvatt> it just silently dies after initializing HW cursor
<Sarvatt> only tried KMS though
<RAOF> Have you checked the gdm log?  There's a good chance it's dying with a missing symbol, which would be written to the gdm log, not the xorg log.
<RAOF> Also, that's rather annoying.  'Twas working here on 965!
<Sarvatt> oh duh
<Sarvatt> X: ../../dix/pixmap.c:118: AllocatePixmap: Assertion `pScreen->totalPixmapSize > 0' failed.
<RAOF> Oh, crud.
<RAOF> Did I not push the refreshed nr patch?
<Sarvatt> nr patch was disabled
<RAOF> On your X server, or 101_copy_fb in the DDX?
<Sarvatt> ddx
<Sarvatt> i think intel legacy is the longest ddx compile now
<RAOF> It builds 3 drivers + an acceleration architecture, cut it some slack :)
<Sarvatt> RAOF: yep that was it, can't reproduce the unity/quadrapassel crash on though on edgers with 945 :(
<Sarvatt> now to break things!
<RAOF> Well, edgers is now installing, so I can check soon.
<Sarvatt> what mesa were you using again? 7.8.2 or the maverick one?
<RAOF> The maverick one.
<Sarvatt> is it me or is mesa 7.9 really late? i think the intel people are waiting for the glsl2 stuff before pushing it
<Sarvatt> so much has changed in it and it seems like 7.8 is dying
<RAOF> I was expecting it to be branched, given than 7.9.0 should be considered 7.9rc1 on past form.
<Sarvatt> idr has been doing the releasing and if they're waiting for the glsl2 stuff i don't know that we'll even see it in time for maverick?
<Sarvatt> it was in lockstep with the intel quarterly releases for awhile there I mean
<RAOF> Stupid X says: Lunch time!
<trinikrono> hey guys
<trinikrono> can anyone speak to me about what is needed to triage those pesky i845g bugs
<trinikrono> i am working on two so far and was wondering what you guys would need
<TeaRex> Hi
<TeaRex> A question
<TeaRex> nvidia-current-dev from the ubuntu-x ppa is incompatible with sdl1.2-dev on lucid.
<TeaRex> any chance this will be changed?
<tseliot> libsdl1.2-dev ?
<TeaRex> The reason seems to be that sdl1.2-dev depends on mesa
<TeaRex> yes libsdl1.2-dev
<tseliot> you can try the latest version of nvidia-current and nvidia-current -dev from maverick
<tseliot> it should work
<TeaRex> thnks
<tseliot> np
<TeaRex> dumb question noobie i guess, where and what is maverick?
<tseliot> maverick is the next release of Ubuntu
<TeaRex> OK i see.
<TeaRex> Didn't even know it had a name yet.
<TeaRex> thanks i will check it out
<TeaRex> have a nice day
<steveire> Is it possible to use kubuntu with two monitors with the default driver?
<steveire> I think I have an nvidia card, and I have the nuoveau driver.
<jcristau> yes
<jcristau> (modulo driver bugs, of course)
<steveire> What do I have to do? My second screen is blank and the system settings screens module doesn't find it.
<steveire> 'This module is only for configuring systems with a single desktop spread across multiple monitors. You do not appear to have this configuration.'
<jcristau> pastebin the output of xrandr somewhere
<steveire> http://dpaste.com/218467/
<steveire> jcristau: Anything relevant there?
<jcristau> either you have 2 identical monitors, or the driver is confused
<steveire> The monitors are the same AFAIK
<jcristau> well this says the driver thinks it has enabled 2 monitors
<steveire> And that should be enough to configure it to be a 'double width workspace'? (you can see I don't know the jargon)
<jcristau> 'xrandr --output DVI-I-2 --right-of DVI-I-1' should extend the desktop
<jcristau> instead of cloning it
<jcristau> but if your second screen is blank then something's wrong already
<steveire> The liveCD cloned it, but when I rebooted the right screen was blank,
<alf__> Hi all! Is there any chance of getting a new package build of mesa to fix LP #600243?
<ubot4> alf__: Bug 600243 on http://launchpad.net/bugs/600243 is private
<alf__> No it is not: 
<alf__> libegl1-mesa-dev needs to depend on other -dev packages
<Sarvatt> alf__: what are you building that doesn't have xserver-xorg-dev in the build deps?
<steveire> Rebooting that machine didn't help anyway...
<alf__> Sarvatt: GL/GLESv2 benchmarks
<Sarvatt> thats kind of silly, egl can be used without X too
<jcristau> pushed that patch to git
<steveire> Any other bright ideas for me to get dual screens?
<jcristau> alf__: thanks
<steveire> Or even debug why I don't even get cloning after installing, while I do before
<jcristau> steveire: check the kernel logs for both, see if you spot a difference
<steveire> How? Where are they?
<jcristau> dmesg
<jcristau> alf__: i have a hard time caring about egl on hurd ;)
<alf__> jcristau: I share your sentiments, just wanted to be thorough :)
<alf__> Sarvatt: Yes, indeed EGL should be usable without X. But why are all these dependencies in the .pc files in the first place?
<Sarvatt> alf__: i can't upload it unfortunately (and i've been trying to get libdrm sponsored for a month already), sorry :(
<alf__> Sarvatt: No worries
<jcristau> Sarvatt: it's silly that you're still not core dev
<Sarvatt> been working on it in maverick, i didn't actually upload much to ubuntu in the past
<tseliot> Sarvatt: do you only need to upload a new libdrm?
<tseliot> or is there anything else?
<Sarvatt> http://sarvatt.com/downloads/merges/libdrm/
<Sarvatt> well alf__'s mesa fix
<steveire> jcristau: Installed version: http://pastebin.com/rDDLkwia liveCD version: http://pastebin.com/cbAyRsQj
<steveire> I don't know what kind of differences I need to look for
<Sarvatt> mesa needs a merge anyway but i dont have the battery power to test build it at the moment, would be easier to just add his mesa-common-dev dep changes to the current one
<jcristau> steveire: don't know either.  best would be to file a bug, and/or try with a newer kernel
<Sarvatt> ppa builds are backed up 3+ days now too
<Sarvatt> steveire: have you tried a maverick livecd by any chance?
<tseliot> Sarvatt: ok, I can upload alf's change. Did you test libdrm?
<steveire> Sarvatt:  I have not
<Sarvatt> tseliot: yeah, it's been in x-updates as well
<tseliot> Sarvatt: ah, I tested it on my main computer then
<tseliot> Sarvatt: ok, I'll sponsor both things then
<Sarvatt> thank you a ton tseliot!
<tseliot> np
<alf__> Sarvatt, jcristau, tseliot: Thanks a lot!
<tseliot> alf__: thanks to you ;)
<tseliot> all uploaded
<tseliot> Sarvatt: shall I update only the mesa git branch?
<tseliot> jcristau: can you check if I still have an account on alioth, please?
<tseliot> it looks like I don't...
<jcristau> uid=229885(tseliot-guest) gid=229885(tseliot-guest) groups=229885(tseliot-guest),41008(pkg-xorg),81008(scm_pkg-xorg)
<tseliot> I forgot the "-guest" part, sorry
<tseliot> it's been while since I've used alioth's git branches
<tseliot> the connection timed out, I guess I made too many attempts...
<jcristau> should be fine in 10 minutes or so, they're using fail2ban on alioth :/
<tseliot> ok, thanks
<steveire_> Where is the button on https://bugs.launchpad.net/ for reporting a new bug?
<steveire_> I got the no-redirect link. How do I answer the question 'In what package did you find this bug' if the problem is that a dual screen setup works in a livecd and not after installation.
<Sarvatt> just run ubuntu-bug xorg
<steveire_> I'll put xorg in that box then.
<Sarvatt> am I really wrong? - https://bugs.launchpad.net/bugs/578038
<ubot4> Launchpad bug 578038 in libxext (Ubuntu) "libext6 does not create symlink in /usr/lib on amd64 (affects: 1) (heat: 6)" [Undecided,Incomplete]
 * Sarvatt must not be understanding the situation
<jcristau> Sarvatt: submitter is mistaken
<jcristau> that bug should be marked invalid
<Sarvatt> hmm, i thought they had to be in bug control to change the status away from invalid, guess not
<jcristau> looks like i was allowed to move it back
<Sarvatt> thanks jcristau, he probably wouldn't have believed me and it would have been an open/close war if i closed it again myself :)
<Sarvatt> jcristau: can you set a bug to wont fix status? if not i can just do that if he does again if anything
<jcristau> no idea
<ernstp> I can't start gnome with xorg-edgers on lucid, getting:
<ernstp> nautilus: symbol lookup error: /usr/lib/libcairo.so.2: undefined symbol: pixman_image_composite32
<ernstp> can't compile cairo after installing libpixman(-dev) from xorg-edgers either
<ernstp> Sarvatt, do you know anything about what that could be?
<ernstp> on amd64
<ernstp> oh there was a new cairo build 16 minutes ago...
<jcristau> that's a broken dependency.
<ernstp> right, but why?
<jcristau> *shrug*
<jcristau> because shit happens
<ernstp> well, wierd...
<ernstp> gonna see if the new cairo upload helps the situation
<ernstp> damnit, it didn't help
<ernstp> does xorg-edgers work for anyone on lucid?
<bryce2> jcristau, broken due to cjwatson's apt breakage from earlier this morning?
<ernstp> bryce2, hi! any idea about the cairo/pixman breakage?
<bryce2> ernstp, notta clue
<bryce2> ernstp, I saw an email from cjwatson that everything was broken from building earlier today.  dunno any details
<ernstp> bryce2, for me it's been broken like that for a couple of weeks
<bryce2> oh, must be something unrelated
<ernstp> (xorg-edgers on lucid, the missing pixman_image_composite32 symbol)
<ernstp> I'm curious if xorg-edgers works for anyone on lucid... ?
<jcristau> means you have an old pixman
<jcristau> that symbol is included in pixman 0.18
<ernstp> I have pixman 0.19 from xorg edgers
<ernstp> when that occurs
<jcristau> then make sure you don't also have an older one in /usr/local
<jcristau> because this sure sounds like pebcak
<ernstp> jcristau, oooh, there is something in /usr/local indeed!
<ernstp> jcristau, thanks a lot :-)
#ubuntu-x 2010-07-16
<bjsnider> Sarvatt, ping
<yofel> hm, what's upstream for nvidia-settings? (I'm wondering where to send the patch on bug 604525 to)
<ubot4> Launchpad bug 604525 in nvidia-settings (Ubuntu) (and 1 other project) "nvidia-settings "Configure Display Device" menu should be drop-down list instead of dialog box (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/604525
<hyperair> Sarvatt: [ 13004.621] (II) intel(0): Kernel page flipping support detected, enabling
<hyperair> thankfully the hangs seem minor enough that i can get back in by using ssh
<RAOF> Yeah, Sarvatt said he was going to drop that patch to get closer to git.
<RAOF> Damn, what has happened to all the amd64 PPA buildds?
<hyperair> RAOF: take a look at https://launchpad.net/builders
<RAOF> Hah.  The kernel thwarts me again!
<hyperair> lol
<RAOF> Have you tried the intel-legacy DDX?
<hyperair> what's that?
<ricotz> RAOF, hello
<RAOF> hyperair: https://edge.launchpad.net/~raof/+archive/aubergine/+packages
<RAOF> ricotz: Hello.
<ricotz> are there some currently known issues with nouveau in maverick?
<RAOF> hyperair: It's essentially a gem-less DDX grafted onto 2.12 for those not using KMS.
<RAOF> ricotz: Not known by me particularly.  Are you going to tell me of one? :)
<hyperair> RAOF: ah i see. but why would i not want to use KMS?
<RAOF> hyperair: Because you've got an i8xx card, and GEM has been a one-way ticket to random GPU hangs.
<RAOF> That's not why _you'd_ want it, that's why someone would want it.
<hyperair> RAOF: no, i've got an i965 card.
<hyperair> ah i see.
<ricotz> i cant start a normal x session, xorg.0.log say "no screens found", is there some race condition between kms and gdm or something?
<RAOF> And _I'd_ like you to test it, so it can go upstream and we can have rainbow-dancing unicorns.
<RAOF> ricotz: Care to pastebin dmesg & Xorg.0.log?
<ricotz> it seems to work after a xserver reinstall so ureadahead it triggered, i think
<hyperair> RAOF: test how? just install it and leave things be?
<RAOF> hyperair: Yup.
<hyperair> or do i have to disable KMS?
<RAOF> Well, you can try disabling KMS.
<RAOF> And checking that it doesn't explode horribly.
<hyperair> heh okay.
<hyperair> i'll give it a go.
<RAOF> But even just installing it and finding the KMS works fine is useful.
<RAOF> s/the/that/g
<hyperair> i'll give it a go once your amd64 builds are done.
<ricotz> RAOF, http://paste.pocoo.org/show/238186/ - http://paste.pocoo.org/show/238187/
<ricotz> RAOF, it happens with maverick packages and edgers
<RAOF> So, the very first thing I see is that you're using xorg-edgers ;)
<ricotz> yes, but i am getting the same error without edgers
<RAOF> Hm.
<RAOF> As they say in the movies: let me check my notes.
<ricotz> RAOF, ok
<ricotz> RAOF, xorg.failsafe.log of x which is working right now - http://paste.pocoo.org/show/238191/
<dupondje> nouveau is broken atm in maverick ?
<RAOF> Apparently the answer is âyesâ
<RAOF> ricotz: Just for my own amusement, can you get a non-edgers Xorg.0.log?
<ricotz> RAOF, can you confirm this problem? ok, this will take some time
<dupondje> https://launchpad.net/ubuntu/+source/libdrm/2.4.21-1ubuntu1/+build/1874547
<dupondje> could this be the reason ?
<RAOF> No, that's not going to be the reason.
<RAOF> I'll update my nouveau laptop & see if this happens locally.
<ricotz> RAOF, mhh, now i got it with my intel laptop
<dupondje> its broken since yesterday evening somewhere ..
<dupondje> dunno what got upgraded since then
<RAOF> dupondje: Learn to love the Ubuntu Software Centre.
<RAOF> Fire it up, and hit âhistoryâ
<RAOF> Tada!  An answer to the question: what upgraded since last night :)
<dupondje> i'm not on my broken laptop atm :) can't check
<ricotz_> RAOF, for me it started before yesterday
<dupondje> I updated @ around 16:00 and rebooted, everything was fine.
<RAOF> ricotz_: You've got the same problem with an intel laptop?
<RAOF> I'm *definitely* not seeing it, then.
<ricotz_> i am just getting the nouveau log
<ricotz_> RAOF, ok, first boot after "downgrade" http://paste.plurk.com/show/280757/
<ricotz_> second boot http://paste.plurk.com/show/280758/
<dupondje> second looks quite the same error like I got ...
<ricotz_> RAOF, with intel http://paste.plurk.com/show/280759/
<RAOF> Ok.  So it looks a lot like libdrm is broken for you.
<RAOF> Or, possibly, the kernel.
<dupondje> I rebooted after kernel upgrade, and then it still worked ...
<RAOF> Does this only happen with 2.6.35-8-generic?
<dupondje> no
<RAOF> Hah, too slow.
<ricotz_> it also happened with -7
<ricotz_> on intel it seemed to start with -8
<RAOF> Ok, I've got  a newer libdrm 'cause I'm testing the legacy DDX.  I'll downgrade that and see.
<RAOF> Nope, still works fine here.
<RAOF> What versions of libdrm, libdrm-intel, libdrm-nouveau, kernel, DDX, and xserver are you using?
<ricotz> the current maverick versions
<dupondje> same here ...
<RAOF> So, 2.4.20-1ubuntu2, 2.6.35-8-generic, intel 2.11.0, and 1.8.2RC2?
<dupondje> can't check atm :(
<RAOF> Got an xorg.conf?
<ricotz> libdrm 2.4.20-2ubuntu1 - kernel 35-8 - intel 2:2.11.0-1ubuntu2 - xserver-xorg 2:1.8.1.902-0ubuntu2
<ricotz> no
<RAOF> I need to run some errands - I'll ponder this while I do so, and while the nouveau lappy is updating.
<ricotz> ok, np
<dupondje> ricotz: amd64 or i386 ?
<ricotz> both amd64
<dupondje> you also RAOF  ?
<RAOF> dupondje: Yup.  amd64
<ricotz> RAOF, any progress? using nomodeset gets it to work
<RAOF> ricotz: For values of âworkâ equal to âuses vesa insteadâ, I presume :)
<RAOF> It doesn't help that I can't reproduce this locally :/
<ricotz> oh you are right this disables nouveau
<ricotz> so it might be a hardware specific problem
<RAOF> It shouldn't be.
<ricotz> i tested kernel 35.7-11 which works on the first boot, and freezes on the second
<RAOF> It's not entirely obvious why drmGetBusid is returning "" rather than âpci:0000:01:00.0â, though.
<RAOF> Works on the first boot, fails on the second?
<RAOF> I don't suppose that if you log off and log in again it works?
<ricotz> no i need to reboot, like i said, it seems to be related to some trigger which is called after a new kernel/x installation
<ricotz> like ureadahead which delays some things
<dupondje> after kernel upgrade it was still working here ... tho only 1 reboot, so might have been lucky ;)
<RAOF> Can you confirm that?  Delete /var/lib/ureadahead/pack and it'll re-profile for you.
<ricotz> RAOF, will try that
<RAOF> You know what?  I need to get a big, beefy desktop machine to build stuff on.
<ricotz_> RAOF, i have restarted now couple times, deleting this ureadahead pack file seems to resolve it
<RAOF> Can you give me two dmesg logs â one that has worked and one that hasn't?
<ricotz_> is the "var.run.pack" introduced recently?
<RAOF> You get one pack per filesystem.
<RAOF> The root filesystem gets âpackâ; the others get âboot.packâ, âusr.packâ, etc.
<ricotz_> ok, then it is fine
<ricotz> RAOF, FAIL: http://paste.pocoo.org/show/238215/ - GOOD: http://paste.pocoo.org/show/238216/
<ricotz> i hope these are the right ones (after rebooting this much)
<RAOF> Wait - the *second* one is good?
<ricotz> this is the current boot
<RAOF> Oh, of course.  ureadahead.  *That's* why udev would be starting some 12 seconds earlier in the second trace.
<RAOF> So, I'd guess that if you removed âsplashâ from your kernel command line, this would work.
<ricotz> it seems to work already
<RAOF> Even without deleting the pack?
<RAOF> You had a problem before - are you suggesting that this has magically fixed itself? :)
<ricotz> yes, i have deleted it twice, but not the third time
<ricotz> i will reboot again to be sure
<ricotz_> ok, there is it again :(
<dupondje> https://launchpad.net/ubuntu/+source/libdrm/2.4.21-1ubuntu1/+build/1874547 is build ... maby install ? :)-
<RAOF> I'd be surprised if that fixed it.
<steveire> Is there any other useful information I can put in this bug report? https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/606001
<ubot4> Launchpad bug 606001 in xorg (Ubuntu) "Dual screen setup does not work after installation (affects: 1) (heat: 6)" [Undecided,New]
<ricotz_> RAOF, removing "splash" doesnt work
<RAOF> Well that's put a crimp in an otherwise damn-fine theory :)
<RAOF> Dump a file containing âFRAMEBUFFER=yâ into /usr/share/initramfs-tools/conf.d ?  That'll get the drm module added to the initramfs, which should make loading it (a) faster and (b) independent of ureadahead.
<ricotz_> ok
<RAOF> steveire: What have you done to try and get a dual-head display?
<steveire> RAOF: I have opened system settings and gone to the 'monitors' section, which tells me I do not have 2 monitors.
<RAOF> steveire: Also, running âapport-collect 606001â will attach all sorts of tasty information.
<steveire> "This module is only for configuring systems with a single desktop spread across multiple monitors. You do not appear to have this configuration."
<RAOF> Ok.  That would be useful information to have on the bug :)
<ricotz_> RAOF, patching initramfs works
<RAOF> Consistently?
<ricotz_> i will reboot a third time, but fsck might do some things here
<ricotz_> i need to reset the fscheck count
<steveire> RAOF: Is that apport thing interactive? Can I see the info it sends back before it does?
<steveire> http://dpaste.com/218731/
<RAOF> steveire: I think so, from memory.
<RAOF> You want to give it access - it'll upload xorg.0.log, dmesg, etc.
<steveire> It implies it will upload more than that. unspecified 'private data'
<steveire> And it doesn't tell me if I can review it or not.
<RAOF> No, that means that it will be able to write to bugs you've marked as âprivateâ
<ricotz_> RAOF, ok, two working reboots
<steveire> RAOF: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/606175 I can't run apport-collect yet
<ubot4> Launchpad bug 606175 in apport (Ubuntu) "apport-collect does not tell me what it will do (affects: 1) (heat: 6)" [Undecided,New]
<RAOF> steveire: I've just checked - it will show you what it'll send.
<steveire> RAOF: This post http://blog.grossmeier.net/2009/03/02/apport-collect-just-what-you-wanted/ says it works without any other interaction with the reporter
<steveire> The man page is also not very clear on it http://man.he.net/man1/apport-collect
<RAOF> Well, I've just checked with a report on staging, and it pops up the âhere's the stuff we'll be reportingâ page.
<RAOF> Possibly if you run it without X it doesn't do that, but it's generally pretty careful to ensure you can easily find out what data is being reported.
<ricotz> RAOF, so it looks like a race condition, something has gotten slower or faster so this problem appears
<RAOF> Right.
<ricotz> now nouveau is loaded 1 second ealier, but initrd is 16MB now
<RAOF> Because it's got all the drm modules in it, yeah.
<RAOF> Plus plymouth
<steveire> I don't see why it needs 'write access' to read dmesg...
<RAOF> It needs write access to your *launchpad* account.
<RAOF> Otherwise it can't add anything to the bug, obviously!
<RAOF> Is that not obvious from the messages - both in the terminal, and the launchpad message?
<RAOF> steveire: Well, I guess it's clearly not obvious, or you wouldn't be asking the question.  If you can think of a better wording, feel free to add it to the apport bug you just submitted.
<steveire> RAOF: Ok, well I ran the tool
<RAOF> steveire: Ok, now I'm confused.  Only one of your shiny, fancy dell monitors is showing an image?
<RAOF> steveire: As far as X is concerned, they should be both lit up and running.
<jcristau> means the kernel is confused, afaict
<RAOF> I guess so.
 * RAOF heads to dinner.
<steveire> That's correct. Only one of them is useful. The other is completely blank
<RAOF> steveire: I don't suppose running âxrandr --output DVI-I-2 --right-of DVI-1-1â does anything?
<ara> hello all!
<ara> in the middle of a big X upload?
<ara> I think I upgraded and rebooted at the wrong time :)
<ara> my X won't boot anymore 
<steveire> stephen@chimera:~$ xrandr --output DVI-I-2 --right-of DVI-1-1
<steveire> xrandr: cannot find output "DVI-1-1"
<jcristau> steveire: DVI-I-1, not DVI-1-1
<steveire_> That command borked my workstation once I'd fixed the 1 to an I
<steveire_> All my windows disappeared, and I had fragments of plasmoids in different places and nothing worked. I had to hard-reset
<steveire_> And now it's having a hard time booting.
<RAOF> Well, at least it had some impact, even if it wasn't particularly good. :/
<RAOF> ara: No - the next flurry of X will be xserver 1.9, which I won't upload until it stops crashing with clutter apps.
<RAOF> Gah, too slow.
<jcristau> maybe mark it as blocking 1.9 in bugzilla?
<jcristau> where "it" is the bug you filed
<RAOF> I wasn't sure if I should do that - I guess I could.
<steveire> I'm wondering if I should try again. You know that xkcd comic with the lightning machine?
<RAOF> Heh.
<RAOF> âHm.  I wonder if it does that *every* timeâ
<steveire> What is the command supposed to do?
<tseliot> steveire_: I found kde 4 to act in a weird way when using multiple screens. None of this can be reproduce in gnome, at least here
<RAOF> That's meant to make one of your displays left of the other - IE: de-clone them
<RAOF> I certainly found that KDE4 didn't deal particularly well with multiple heads.  It didn't go totally bananas, though.
<RAOF> jcristau: Incidentally, I'm thinking of attending XDS, and I was wondering what you thought.
<steveire> Maybe I'll install ubuntu-desktop and see what happens. Even the boot splash only appears on one screen though.
<RAOF> ara: No - the next flurry of X will be xserver 1.9, which I won't upload until it stops crashing with clutter apps.
<RAOF> steveire: Which is strange, given that it worked on the livecd.
<RAOF> jcristau: Bug marked as blocking.
<jcristau> i think this xds is the first time i might be able to attend
<steveire> Indeed.
<dupondje> is the x-issue fixed already ? or bugreport / workaround ? That I can boot my computer again this evening :)
<jcristau> whatever "the x-issue" means...
<RAOF> dupondje: If you add the drm module to your initramfs you'll avoid the race condition.
<RAOF> ricotz: Did you file a bug, incidentally?
<ricotz> RAOF, no, i havent
<RAOF> Please do so - I can't fix that race off the top of my head, so a bug will be needed.
<ricotz> RAOF, will do, as soon i can
<ricotz> RAOF, what about this bug report https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/459639
<ubot4> Launchpad bug 459639 in xorg-server (Ubuntu) "[Karmic] X server starts randomly in failsafe when starting from cold boot (affects: 6) (heat: 42)" [High,Confirmed]
<jcristau> karmic?
<dupondje> and not only from cold boot imo :)
<ricotz> yeah, i will file a new one
<RAOF> And a huge muddle of multiple âX doesn't startâ bugs.
<RAOF> Handy hint: the binary blob not starting is *almost always* a different bug to any free driver not starting :)
<seb128> http://launchpadlibrarian.net/52029105/buildlog_ubuntu-maverick-i386.clutter-gtk-0.10_0.10.4-0ubuntu3_FAILEDTOBUILD.txt.gz
<seb128> is that libgl installability issue known?
<ricotz> RAOF, https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/606244
<ubot4> Launchpad bug 606244 in xorg-server (Ubuntu) "X doesn't find a screen and is not starting due a race condition (affects: 1) (heat: 6)" [Undecided,New]
<RAOF> seb128: clutter-gtk builds fine locally.  I guess it could be an i386 issue?
<seb128> I figure it out now
<seb128> I newed libkms1 to universe yesterday
<seb128> I've promoted it now, should be fixed after the next publisher run
<seb128> would be nice to document new libraries in the changelog though
<seb128> so we know what to do when newing them
<seb128> Sarvatt, ^
<RAOF> Aaah, the newer libdrm.  Right.
<yofel> short question, what's upstream for nvidia-settings? (where to send a patch..)
<seb128> or to use -v to list debian changes
<RAOF> That obviously hasn't hit my amd64 mirror yet.
<RAOF> Well, back to packing.
<tseliot> yofel: you can contact Aaron plattner
<yofel> where?
<tseliot> you can have a look at whatever commit in git an see his address: http://cgit.freedesktop.org/~aplattner/nvidia-settings/commit/?id=655fb95354fdfb7ffe5f44f0341c132165b0c983
<tseliot> what kind of change is that?
<yofel> bug 604525
<ubot4> Launchpad bug 604525 in nvidia-settings (Ubuntu) (and 1 other project) "nvidia-settings "Configure Display Device" menu should be drop-down list instead of dialog box (affects: 1) (heat: 10)" [Wishlist,Confirmed] https://launchpad.net/bugs/604525
<tseliot> aah, that one
<tseliot> yes, feel free to send Aaron a patch
<yofel> was asking as launchapd doesn't tell me where to find upstream..
<yofel> thanks
<tseliot> seb128: I didn't notice that there were new libraries when I tested/sponsor the upload. So it's my bad too
<seb128> tseliot, that's ok, I figure what the issue was now ;-)
<tseliot> good
<dupondje> RAOF: so its a kernel bug? But why is it broken for -7 and -8 since today ? and it worked without issues for days on -7 ? :)
<dupondje> somebody else hitting the https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/606244 bug ?
<ubot4> Launchpad bug 606244 in linux (Ubuntu) "X doesn't find a screen and is not starting due a race condition (affects: 2) (heat: 12)" [Undecided,New]
<tseliot> maybe you should try the latest libdrm
<dupondje> yea indeed :)
<dupondje> i'm not @ home, so I can't test
<dupondje> but I commented the bug
<tseliot> ok
<dupondje> https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/606244
<ubot4> Launchpad bug 606244 in libdrm (Ubuntu) "X doesn't find a screen and is not starting due a race condition (affects: 2) (heat: 12)" [Undecided,Fix released]
<dupondje> like I tough
<dupondje> libdrm and its fixed :)
<tseliot> very good
<tseliot> thanks for testing
<ricotz> dupondje, the problem is i was hitting this bug also with edgers ppa
<ricotz> where libdrm was up2date for some time
<dupondje> ricotz: so you still have it with newest libdrm ?!
<dupondje> feel free to re-open then btw :)
<Sarvatt> the stuff in the section of the changelog you quoted was already in the previous libdrm dupondje 
<dupondje> mmmm weird it started working then after libdrm update here ..
<dupondje> Sarvatt: previous version was 2.4.20-2ubuntu1, now its 2.4.21-1ubuntu1
<dupondje> the changelog section is in 2.4.20-3 ..
<Sarvatt> yeah I know, but I did the abi bump stuff from 2.4.20-3 in 2.4.20-2ubuntu1 before they did it in debian, thats why we didn't bother merging 2.4.20-3
<dupondje> ah but 2.4.20-2ubuntu1 gives +      03_revert_abi_change.diff - Obsolete
<dupondje> anyway it was broken here, and libdrm update resolved it ... so something must be changed ;)
<Sarvatt> your initrd got rebuilt with the FRAMEBUFFER=Y maybe? :)
<dupondje> well no :s
<dupondje> it didn't even regenerated my initrd :)
<dupondje> was getting completely the same error as ricotz 
<Sarvatt> i dont see anything in libdrm that would have affected that
<dupondje> [    51.454] drmOpenByBusid: drmGetBusid reports  => when it was broken
<dupondje> [    25.539] drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
<dupondje> now
<dupondje> :)
<dupondje> ricotz: did you try libdrm_2.4.21-1 ?
<Sarvatt> that happens when the kernel drm isn't ready when the ddx is trying to start
<dupondje> look, I gonne try to reboot some times, to see if it still works :)
<Sarvatt> do you guys have agp cards by any chance?
<dupondje> Seems like i've been very lucky, that the first boot after libdrm upgrade worked :p
<dupondje> https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/606244
<dupondje> so not fixed ... :)
<ubot4> Launchpad bug 606244 in libdrm (Ubuntu) "X doesn't find a screen and is not starting due a race condition (affects: 2) (heat: 12)" [Undecided,New]
<Sarvatt> do you guys have agp cards by any chance?
<dupondje> in my old computer yes :)
<ricotz> dupondje, i havent tried it with the maverick version, i am using edgers which gave me the same error
<ricotz> Sarvatt, it is a PCIs card
<ricotz> PCIe
<dupondje> its laptop here, so euh pcie bus also I bet
<ricotz> dupondje, so you are still getting the error?
<ricotz> dupondje, nm ;)
<dupondje> yep :s
<dupondje> been very lucky that just after the libdrm reboot it worked :p
<dupondje> the reboot after I upgraded libdrm .. :)
<ricotz> yes, like i said before the first boot after some kernel/x changes it works
<dupondje> I also see kernel bug in boot: [   33.758638] BUG: unable to handle kernel NULL pointer dereference at 00000000000003c0
<dupondje> :p
<dupondje> [   33.758809] Process plymouthd (pid: 375, threadinfo ffff880037e28000, task ffff880037d38000)
<ricotz> brb
<hyperair> Sarvatt: i've observed something rather interesting.once i'm past the first GPU hang, (ssh in and forcefully kill X and restart gdm), it doesn't hang any more.
<hyperair> Sarvatt: also, the first hang happens very quickly after logging in, within the first 5 hours or so.
<hyperair> my current uptime is 15h. Xorg's uptime is 12h
<hyperair> er wait. 11h 23m
<bryce2>  Sarvatt, tseliot, if lp #567007 sounds like a useful launchpad feature, mind clicking 'Affects me too'?  The more people marked as it affects them, the more likely it'll be to get on the Launchpad team's planning list when work starts on search improvement
<ubot4> Launchpad bug 567007 in malone "User-specific default tag search parameters (affects: 1) (heat: 3)" [Low,Triaged] https://launchpad.net/bugs/567007
<Sarvatt> done, that would be a nice feature :)
<Darxus> There's a fix for bug #541492.  It involves 5 source packages (one of which is linux).  What needs to be done to get them in Maverick?
<ubot4> Launchpad bug 541492 in xserver-xorg-video-intel (Ubuntu Lucid) (and 2 other projects) "MASTER: [i845] GPU lockup (apport-crash) (Should KMS be blacklisted?) (affects: 77) (dups: 30) (heat: 523)" [High,Triaged] https://launchpad.net/bugs/541492
<dupondje> everything seem to crash now :s
<dupondje> ricotz: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606393 you have this also ?
<ubot4> Launchpad bug 606393 in linux (Ubuntu) "BUG: unable to handle kernel NULL pointer dereference at 00000000000003c0 (affects: 1) (heat: 6)" [Undecided,New]
<ricotz> dupondje, yes, this is plymouthd trying
<ricotz> dupondje, should be the same problem which causes X to fail
<bjsnider> Sarvatt, remember that issue with nvidia-current where it's creating two modprobe.conf files?
<Sarvatt> bjsnider: ya want tseliot, but yeah I remember it :)
<bjsnider> what i don't understand is, the alternatives are putting one of the files by a link into the /etc/modprobe.d directory, the one without the alias, and yet the system behaves as though it knows about the alias
<Sarvatt> look at the dkms.conf
<Sarvatt> DEST_MODULE_NAME[0]="nvidia-current"
<Sarvatt> guessing thats why
<bjsnider> yeah, the module is built as nvidia-current
<bjsnider> but the xorg.conf says nvidia
<bjsnider> without the alias the system should fail to load that module because it doesn't exist
<bjsnider> and it intermittently does so
<bjsnider> but for some reason it works most of the time. i can't see why.
<Sarvatt> the xorg.conf doesn't have anything to do with it though, the ddx module is still nvidia_drv
<bjsnider> then what is the alias used for?
<Sarvatt> it only loads if it wasn't loaded by udev already at startup but yeah i thought it might run into the same problem because thats hardcoded to load nvidia.ko and dkms is just renaming it to nvidia-current.ko instead of aliasing nvidia to nvidia-current
<Sarvatt> it's still built as nvidia.ko by dkms just installed as nvidia-current.ko after
<bjsnider> without the alias i have tried modprobe nvidia, and the response is no such module exists
<Sarvatt> you'd need to change that DEST_MODULE_NAME to nvidia and alias nvidia nvidia-current to do that
<bjsnider> $ lsmod|grep nvidia
<bjsnider> nvidia              11105770  38
<Sarvatt> the module is nvidia-current.ko though, its confusing :(
<bjsnider> i think what you have here is the dx module is being renamed so that each nvidia module can be built and installed at the same time
<bjsnider> i'm fairly sure putting driver "nvidia" in the xorg.conf file is the same as saying modprobe nvidia
<Sarvatt> the xorg.conf driver you pick specifies which _drv to load bjsnider, nothing to do with kernel modules
<Sarvatt> the X driver can load kernel modules though
<Sarvatt> those nvidia_drv.so's are swapped around with the /usr/lib/xorg/extra-modules alternative pointing to the different driver's directories
<Sarvatt> xf86LoadKernelModule() does it, i see that in nvidia_drv.so. it'll be trying to load nvidia that doesn't exist probably if it hasn't already been loaded by udev before
<bryce2> tjaalton, BEL?
#ubuntu-x 2010-07-17
<Sarvatt> hrm, someone from vmware requested dropping vmwgfx from the kernel config
<Dr_Jakob> Sarvatt: from the main one yes.
<Dr_Jakob> Sarvatt: John or Thomas?
<Dr_Jakob> Its not really ready to be used as default, but I think we are fine with user being able to get it from the ppa.
<Sarvatt> Dr_Jakob: from the kernel, it wont be available in the ppa because it's dropped already but it sounds like its in vmware tools anyway
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+bug/606139
<ubot4> Launchpad bug 606139 in linux (Ubuntu) "Request to disable vmwgfx driver in default config (affects: 1) (heat: 8)" [Medium,Fix released]
<Dr_Jakob> Sarvatt: don't you compile your own kernel for the ppa?
<Sarvatt> nope, I copy the ones from the latest dev release back to the last stable release and 2.6.35-9 that i just copied to lucid already has it disabled
<Dr_Jakob> ah
<Sarvatt> i should probably start though I guess
<Sarvatt> hmm, plymouth in maverick is all kinds of busted for me as well from the last few days worth of updates
<Sarvatt> looks like grubs doing it's gfxpayload=keep thing again
<Sarvatt> [    3.119637] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
<Sarvatt> [    3.119709] Console: switching to colour dummy device 80x25
<Sarvatt> [    3.120478] Console: switching to colour frame buffer device 128x37
<Sarvatt> screen stays off, cant boot unless i press escape to remove the broken splash before X starts
<Sarvatt> guess this is what dupondje and ricotz were hitting this morning
<Sarvatt> efifb that grub was using before was fixed last time it was using gfxpayload=keep but looks like its using vesa now and that doesn't work - [    0.430032] fb0: VESA VGA frame buffer device
<Sarvatt> well if anyone comes in saying they are unable to boot maverick tell them to use the vesafb=sucks kernel parameter :)
<yofel> hi, anyone an idea what would cause bug 605837 ?
<ubot4> Launchpad bug 605837 in linux (Ubuntu) "After recent updates, X will no longer start with the Nvidia driver on maverick (affects: 2) (heat: 1581)" [Undecided,New] https://launchpad.net/bugs/605837
<Sarvatt> yofel: try booting with vesafb=sucks added to grub? or change gfxpayload=keep to gfxpayload=text
<dupondje> Sarvatt: already found out in what part the bug is exactly ? is it in the drivers itself ? or in drm ?
<Sarvatt> its vesafb not handing over to the kms fb right for some people on intel at least, for nouveau its udev not loading the nouveau module and you're getting the normal drm not ready stuff from the ddx trying to load it
<dupondje> so for nouveau its an udev bug ?
<Sarvatt> looks like it doesn't load nouveau before x starts if you use vesafb
<Sarvatt> plus plymouth is just plain busted with vesafb + kms
<Sarvatt> not sure, i'm saying what it looks like to me
<Sarvatt> vesafb=sucks or gfxpayload=text works fine here
<Sarvatt> it'll probably be busted for a long time btw so you might want to use one of those for now :)
<dupondje> hÃ©hÃ© i'll do that :)
<dupondje> I tought you would have fixed it by monday ;)
<Sarvatt> no way, he wants to collect data on it and its far from trivial to fix :)
<Sarvatt> i mean it can be fixed trivially but he wants to actually fix it instead of just disabling the option again
<dupondje> well yea indeed 
<dupondje> better fix it good then use a workaround
<Sarvatt> and of course his machine is fine with it like last time it was enabled and all of mine are broken :(
<dupondje> laptop is broken here also :(
<dupondje> anyway ;) workaround is activated :)
<Sarvatt> did it work?
<dupondje> dunno :) need to reboot for that, but i'm @ work atm
<dupondje> removing /var/lib/ureadahead/pack and the nreboot was also a workaround :p
<dupondje> its a bug with alot of workarounds it seems :)
<Sarvatt> vesafb=sucks + FRAMEBUFFER=Y is my favorite, dont need no stinkin vesafb when you have kms
<dupondje> maby we should make a wiki page with the workarounds :)
<dupondje> as alot of bugs are created with same issue now
#ubuntu-x 2010-07-18
<coz_> hey guys... sometimes... as in at this moment  clean install of lucid  ...firefox bookmarks scroll extreemely slowly 
<coz_> any solutions to this?  I know its nvidia 
<tjaalton> bryceh: "BEL"?
<trinikrono> hey guys i can use some help to triage some xserver-xorg-video-intel bugs
#ubuntu-x 2011-07-11
<bryceh> RAOF, lead on a mesa patch for a gpu hang - https://bugs.launchpad.net/bugs/807440
<ubot4> Launchpad bug 807440 in xserver-xorg-video-intel (Ubuntu) "[i965gm] GPU lockup (affects: 1) (heat: 6)" [Undecided,New]
<bryceh> RAOF, might check if that could/should be backported to natty too
<RAOF> Cool.
<RAOF> What is everyone doing working on Sunday afternoon, anyway?  You're here poking mesa bugs, Didier uploaded unity-2d, â¦
<bryceh> RAOF, guilty :-)
<jussi> Hi all, is there a command I can give that will give the EDID output from my monitor ?
<jcristau> xrandr --prop
<jussi> thanks
<jussi> jcristau: double thanks. thats _exactly_ what I was after :)
<bjsnider> Sarvatt, what's the bug number for the no keyboard/mouse thing?
<albert23> bug 807306
<ubot4> Launchpad bug 807306 in udev (Ubuntu Oneiric) (and 1 other project) "[oneiric] Keyboard & mouse not working in X (affects: 24) (dups: 3) (heat: 136)" [High,Confirmed] https://launchpad.net/bugs/807306
<albert23> bjsnider: ^
<bjsnider> thanks
<Sarvatt> so digging through some old debian bugs from may and looks like sysvinit needs to be 2.88 to populate /run and have things work, having this screwed up /run with just motd in it around from the latest base-files might be causing it? cnd: did you try sudo mv /run{,.bak} and reboot?
<cnd> Sarvatt, to fix which bug(s)?
<Sarvatt> no mouse/keyboard
<cnd> Sarvatt, ok, I'll try that in a bit
<cnd> thanks!
<Sarvatt> cnd: thanks a ton, i tried desperately to reproduce it and gave up.. 6 machines with fresh alpha 2 then updated, and 2 of those doing a natty to oneiric dist upgrade and all were fine :(
<Sarvatt> initramfs-tools 0.99 is what mounts /run as tmpfs and crap too and we dont even have that
<cnd> hmm
<Sarvatt> cnd: jackpot
<Sarvatt> kenvandine tried it, removing /run made it work again
<Sarvatt> err, bryceh already pointed it out on the bug, only /run/udev is needed apparently :P
<cnd> cool
<bryceh> cnd, Sarvatt, yeah root caused on #807306
<bryceh> downgrading base-files might undo the damage
<bryceh> slangasek plans to tackle the sysvinit merge ~today
<Sarvatt> nope downgrading wont clean up /run from what I can see
<Sarvatt> <Sarvatt> [18:20:08] https://lists.ubuntu.com/archives/oneiric-changes/2011-July/004255.html hrm
<Sarvatt> that makes me want a drink, that was friday.. wish i followed up on it more :)
<bryceh> Sarvatt, deleting it?
<bryceh> er, +deleting it?
<Sarvatt> bet i can reproduce it on all the sytems after this udev 172 update that creates /run/udev
<Sarvatt> you have to have updated udev after base-files was installed to reproduce it before, there wasn't a udev update for a month..
<bryceh> Sarvatt, seen any bugs with flash video causing large X cpu usage (>75%)?
<Sarvatt> haven't seen any bugs, thats what flash does so not surprised :P
<bryceh> Sarvatt, if you can reproduce it, mind testing this fix?  https://code.launchpad.net/~rsalveti/ubuntu/oneiric/base-files/run-transition/+merge/67444
<bryceh> if it is confirmed as solving it, I can upload it as the fix
<bryceh> well, as temporary fix
<bryceh> Sarvatt, plunked it into a PPA too - https://launchpad.net/~bryce/+archive/lime
<Sarvatt> bryceh: sorry I went out at EOD and just got back, lets see..
<Sarvatt> bryceh: i dont think this is going to have any effect, the udev package itself is trying to use /run if it exists even if things arent already migrated to it, and this isnt going to remove /run so it'll be the same?
<Sarvatt> i dont even know if i can reproduce it, let me move /run/udev back and see if it happens
<Sarvatt> udev 167-2 from debian had the fix we'd need to fix it, udev (167-2) unstable; urgency=high   * Only use /run if it is a tmpfs. (Closes: #621036, #620995)
<Sarvatt> afaik
<Sarvatt> adding /run is what broken it in other words, not removing the creation of /var/run because that already existed here anyway
<Sarvatt> brb rebooting into it
<Sarvatt> bryceh: no luck
<Sarvatt> your base-files + /run/udev existing = broken
<Sarvatt> everyone that updates oneiric is broken atm because udev was updated
<Sarvatt> if /run exists udev package updates install crap to /run/udev instead of /dev/.udev, but the rest of the world is still expecting to use /dev/.udev
<bryceh> hrm
<Sarvatt> bryceh: the libc6 bug is different
<Sarvatt> that might indeed fix that one
<Sarvatt> udev will still be broken though
<Sarvatt> base-files isn't creating the base file system layout on a normal apt-get upgrade, /var/run already exists here
<RAOF> Wheee!  No udev love for me!
<bryceh> RAOF, move aside /run/udev
<RAOF> Or just plug/unplug the keyboard and mouse :)
<Sarvatt> real easy to do on a laptop and all :)
<bryceh> it's our Bug of the Day
<bryceh> (see scrollback in just about any channel)
<RAOF> Sarvatt: I've gone all standing-desky, so I do have an external keyboard/mouse to prod. ;)
<RAOF> You could probably also trigger udev events to fix it, too; you can get to a VT by switching the keyboard into raw mode.
<RAOF> While we're on Bug Of The Day, has anyone else's /dev/dri permissions been wrong?
<RAOF> That might also be udev, I guess, but could be consolekit failing to set the acl properly.
#ubuntu-x 2011-07-12
<Sarvatt> RAOF: i saw 2 people talking about that bug but haven't been hit by it, guessing it comes from udev being screwed?
<RAOF> Yeah.
<Sarvatt> crw-rw----+ 1 root video 226, 0 2011-07-11 18:49 /dev/dri/card0
<RAOF> Pretty much nothing that wants to talk ot hardware is working for me; dri, pulseaudio, etc.
<RAOF> Yeah.  No + for me :)
<Sarvatt> pulseaudio is definitely the udev problem
<Sarvatt> you updated to the latest and moved /run out of the way?
<RAOF> Nah.
<Sarvatt> wonder why it didnt take out your input devices but did for other people
<RAOF> Oh, it did.
<RAOF> I just plugged them back in.
<Sarvatt> ah gotcha
<Sarvatt> move /run man, it'll fix the world :P
<Sarvatt> heck even moving /run and dpkg-reconfigure udev might fix it without rebooting
<Sarvatt> or sudo service udev restart
<tjaalton> umm, someone changed wayland to source 3.0 format?
<tjaalton> cosme.ddiaz
<ricotz> tjaalton, doesnt look like 3.0 to me
<ricotz> tjaalton, http://people.ubuntu.com/~ricotz/wayland/
<tjaalton> ricotz: well there wa a bug marked fixed with the changelog claiming so, among other things
<tjaalton> was
<ricotz> tjaalton, yeah, but it doesnt includes a "source/format", so it is still handled as 1.0
<ricotz> also it failed to build
<tjaalton> ok then
<ricotz> tjaalton, maybe you could have a look at my package
<ricotz> i dont think the old version really serves a purpose
<tjaalton> work with debian
<ricotz> this way mesa could build against it to generate wayland-gl
<tjaalton> i'm not really that interested, yet anyway :)
<ricotz> i see
<bryceh> I'm interested
<ricotz> ;)
<bryceh> ricotz, there's a few things we need to do
<bryceh> we need to update to a newer snapshot
<bryceh> the package needs broken into two different packages to match upstream
<ricotz> bryceh, i know
<ricotz> http://people.ubuntu.com/~ricotz/wayland/
<ricotz> and wayland-demos depends on mesa wayland-gl backend
<bryceh> ricotz, did you build and run this snapshot?
<ricotz> bryceh, i build it, but i dont ran it since the lack of a proper mesa build here
<Sarvatt> ricotz: and the mesa build needs wayland-dev to build now.. :P
<ricotz> Sarvatt, yes
<ricotz> ... and wayland-demos need mesa wayland backend :P
<ricotz> bryceh, upload it if you like, but the changelog doesnt contain the packaging changes
<bryceh> ricotz, thanks, I'll do some work on it
<ricotz> ok
<Sarvatt> ohhh ok i thought wayland was needing mesa and mesa was needing wayland to build, that doesn't look so bad
<Sarvatt> was having xorg state tracker nightmares all over again
#ubuntu-x 2011-07-13
<horstle> nice, instant nvidia update
<horstle> :D
<ricotz> horstle, oh, you mean a 280.04 package?
<bryceh> RAOF, so... wayland-demos needs wayland-egl from mesa.  thoughts?
<RAOF> We MIR wayland, enable wayland-egl in mesa, and win?
<bryceh> optimist ;-)
<bryceh> well, was more asking if you'd started on the MIR yet
<bryceh> er, wondering
<RAOF> Oh!  I thought you were doing that.\
<RAOF> Communication.
<RAOF> I haz it.
<bryceh> aha
<bryceh> ok, not a big deal
 * bryceh mirrs
<RAOF> How do our wayland packages compare with debian's?  Are we based on them yet?
<bryceh> yeah I did the merge work yesterday
<bryceh> the binary packages were done differently than us, that made it interesting.  but it's up and installable and all.
<bryceh> wayland-demos is ready to go too, but won't build without wayland-egl
<RAOF> I'll check that the wayland we've got now is new enough to build wayland-egl in mesa.
<bryceh> looks like it is; you had to disable it in the 7.11~1-0ubuntu1 merge at least
<bryceh> er, wow I misread your comment
<RAOF> Yeah.  I disabled it in Debian because it wasn't new enough ;)
<bryceh> the uploaded wayland is from june 10, and is the same snapshot version debian used, so if they're building mesa with that, then it should be good to go.
<RAOF> Let's play with some mesa.  Wrangling with the finer points of binary-blob licensing is getting old.
<RAOF> bryceh: No dice; mesa's been updated to use a newer libwayland than we have.  I can patch that back, or we can update wayland.
<bryceh> seriously?
<RAOF> Yeah.
<bryceh> what's the error?
<RAOF> Specifically: âwayland-drm.c:101:16: error: âstruct wl_bufferâ has no member named âclientââ
<bryceh> probably easier to update wayland; there's only about a dozen commits we're missing
<bryceh> however I'm curious how debian packaged mesa without hitting that
<RAOF> They didn't; when I updated to a newer 7.11 snapshot I had to disable it.
<RAOF> The 7.11~1 upload isn't uploaded yet, though.
#ubuntu-x 2011-07-14
<bryceh> ah
<bryceh> anyway, mir is at https://bugs.launchpad.net/ubuntu/+source/wayland/+bug/810217
<ubot4> Launchpad bug 810217 in wayland (Ubuntu) "Main Inclusion Request for wayland protocol package (affects: 1) (heat: 8)" [Undecided,New]
<RAOF> Funkyawesome.
<RAOF> Bloody hell.  Less cold, more coffee please!
<RAOF> Man.  Intel are getting serious about linux driver debugging.  Would you like to attach a debugger to your shader code?  Certainly, sir!
<ScottK> That sounds promising.
<ScottK> (the Intel part, not the less cold part)
<bryceh> a bit ironic that I was waiting on doing wayland until mesa was newer, and now mesa is too new so I have to update wayland
<bryceh> go go interdependencies
<bryceh> looks like mesa needs http://cgit.freedesktop.org/wayland/wayland/commit/?id=a56c0455717c4772e8e4b78e56af439ccd2356af
<bryceh> in wayland
<bryceh> which is only 3 revisions after what debian snapshotted
<bryceh> RAOF, would you mind slapping that patch into your wayland and see if it then enables mesa to build proper?
<bryceh> RAOF, or alternatively, looks like commit 0cb356dd5c93f745bb1b17987d206a24ab708f31 in mesa could be reverted
<RAOF> Not at all.
<bryceh> both patches by the same guy, guessing they go together
<RAOF> At this point we're probably better off with a newer wayland than with reverting mesa.
<bryceh> yeah
<bryceh> if it's just that one commit as I suspect, I may be lazy and just slip that into wayland's patches/
<bryceh> ah, nope... we do need some of these other patches
<bryceh> RAOF, I'll have a newer wayland package in the hopper in a minute
<RAOF> Yeah, that failed.
<bryceh> is this an insane version number for a new snapshot?  0.1.0~0+gitaa7bbb21-0ubuntu1
<bryceh> oh, I should include the date
<bryceh> 0.1.0~0+git20110629.aa7bbb21-0ubuntu1
 * bryceh squints
<bryceh> RAOF, look ok to you?
<RAOF> I think Debian are going for serial snapshot names, with the git commit in the changelog.
<Sarvatt> maybe just the date and the sha in the changelog
<RAOF> So, 0.1.0~1
<RAOF> And I'd like it to be acceptable to Debian for diff-minimisation purposes ;)
<bryceh> well, won't 0.1.0~1 conflict with whatever they choose to use as a tarball?
<RAOF> That  also has the plesant side effect of making 0.1.0~rc1 > 0.1.0~$DIGITS
<RAOF> Um, yes.  Of course it will conflict.  Silly me!
<bryceh> I could go with 0.1.0~0+1-0ubuntu1 or 0.1.0~0.1-0ubuntu1
<RAOF> Either are good with me.
<bryceh> wayland_0.1.0~0.1-0ubuntu1_source.changes uploaded
<RAOF> bryceh: Where's the wayland?  I can't see it in either launchpad or in git.
<RAOF> bryceh: Bah, false alarm.  I need to learn to read launchpad better.
<bryceh> ubuntu branch on alioth
<RAOF> No rule to make target `/usr/lib/gcc/x86_64-redhat-linux/4.6.0/include/stddef.h'
<RAOF> That's an interesting architecture :)
<RAOF> Now, what in the nine circles of hell is causing it.
<Sarvatt> RAOF: screwed up tarball, making one from git works..
<RAOF> Odd.
<RAOF> Ah, no.
<RAOF> I see.
<Sarvatt> RAOF: hmm whats in debian-experimental is going to need --disable-gallium-gbm or install the pipe drivers, no?
<Sarvatt> oh nevermind was merged after rc1
 * bryceh waves
<Sarvatt> anyone else using nvidia on oneiric that's updated in the last few days? we might have a problem https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/810647
<ubot4> Launchpad bug 810647 in nvidia-graphics-drivers (Ubuntu) "[10de:08a0] nvidia isn't loading (affects: 1) (heat: 6)" [High,Confirmed]
<Sarvatt> couple people saying its not working
 * Sarvatt has a machine updating to see
<Sarvatt> heyo bryce!
<bryceh> heya Sarv
<bryceh> so many bugs
<Sarvatt> yeah oneiric is going crazy the past few weeks
<bryceh> X isn't too bad yet - http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/totals-oneiric-workqueue.svg
<bryceh> but we're probably going to start seeing an increase by this point
#ubuntu-x 2011-07-15
<hyperair> this is strange
<hyperair> all of a sudden my disable backlight key stops working completely
<hyperair> and now after ~5 days of uptime, my screen just blacks out completely
 * hyperair wonders if xorg-edgers is at fault
<ricotz> tseliot, hello, you may like to update the nvidia driver there is a new release available http://de.download.nvidia.com/XFree86/Linux-x86_64/275.19/NVIDIA-Linux-x86_64-275.19-no-compat32.run http://de.download.nvidia.com/XFree86/Linux-x86/275.19/NVIDIA-Linux-x86-275.19.run
<tseliot> ricotz: is it the stable release?
<ricotz> tseliot, yes, http://www.nvidia.de/object/linux-display-ia32-275.19-driver-de.html
<tseliot> ricotz: ok then, I'll update the driver. Thanks for the news
<ricotz> great, thank you
<ricotz> i may upload 280.04 to edgers
<bjsnider> there's a flash fix. i'm going to put this in x-updates
<tseliot> right
<tseliot> bjsnider: wait, just don't use my code in Natty, as we don't have multi-arch support in natty
<bjsnider> don't worry. i am using the correct build scripts
<tseliot> good
<bjsnider> tseliot, did you ever talk to nvidia about the behaviour of the driver when it encounters the preinstall script?
<tseliot> bjsnider: yep, and I suggested a way to make sure that whatever the installer installs doesn't conflict with our packages
<tseliot> but it will require changes to the installer
<bjsnider> to the nvidia-installer?
<tseliot> and I'm waiting for their feekback
<tseliot> *feedback
<tseliot> yes
<bjsnider> i see
<tseliot> so that we can have distro hooks which make it use a certain installation path and even install alternatives
<tseliot> so that, for example, we can switch between our packages and whatever the nvidia-installer installs without effort
<sithlord48> i have a problem w/ the newest intel driver for 11.04 (xcrack ppa) version. i have black backgrounds on some labels and checkbox text, the most noticeable are dolphin's places bar and teh kdm login screen
<Sarvatt> yay, got x-backports working on amd64. can't believe I forgot debian/libdrm-dev.links..
<Sarvatt> 10 hour queue for the libdrm build though before I can upload mesa/x-x-v-intel, ugh
<bjsnider> we need more ppa builders
<ricotz> +1 =)
<bjsnider> i mean some people, like rictoz for example, send 300 packages per day in for building.
<ricotz> mhh :\ -- 8 packages ;)
<ricotz> and i am not building mozilla or chromium :P
<bjsnider> it's all the fault of the mozilla team and fta?
<ricotz> these builds are taking quite long, so yeah -- but of course there are quite less builders as usual
#ubuntu-x 2011-07-16
<NeedHelp_> Hi, I've got a problem with session startup - takes a long time, most of which xorg appears to do nothing
<NeedHelp_> About 2-3 minutes
<hyperair> Sarvatt: about that dri2 glxgears bug... it's still around.
#ubuntu-x 2011-07-17
<Sarvatt> nothing like X crashing when you're 4 pages into a launchpad bug survey full of many paragraphs of responses, no way in heck i'm doing that again :P
<Sarvatt> looks like Fatal server error: [ 33157.688] Wrong event type 0. is back in mesa master
<Sarvatt> was fixed by http://cgit.freedesktop.org/mesa/mesa/commit/?id=a95ec18549b677b5e9912ca9e2c92df5cfef3b4e for a few months there on natty
<bryceh> Sarvatt, :-/
<RAOF> Sarvatt: Nice cat pictures, by the way :)
#ubuntu-x 2012-07-09
<mlankhorst> "Hello, world!\n"
<mlankhorst> does pre-sandy bridge even allow snooped access?
<mlankhorst> woops wrong channel :)
<mlankhorst> .. running kernel with kmemcheck is scary
<mlankhorst> RAOF: great success :D
<mlankhorst> dmabufmgr seems to work
<mlankhorst> i adapted the code for nouveau to use the hardware for waiting
<mlankhorst> which turned into a 800 line patch :s
<RAOF> Huge success!
<mlankhorst> RAOF: yeah was just tracking 2 bugs today, first one was in my test program with how I marked intel relocations. I needed a noop for testing, but it ended up executing the address as command, second one was probably due to some stuff not firing in idle stait, and workaround was adding some busyloops
<mlankhorst> eg schedtool ... 'while true; do true; done' on all cpus
<RAOF> :)
<mlankhorst> http://people.canonical.com/~mlankhorst/prime-sync/ full patchset, probably best to use drm-intel-next-queue git tree
<mlankhorst> i wanted to grab the delayed fput git tree too, but it hangs early on in boot
<jwi> a hacky max_cstate=0? ;)
<RAOF> I may have to get you to give me some pointers for what needs to be done on the radeon side. That might be a fun project at 2am when ZoÃ«'s crying :)
<mlankhorst> RAOF: oh I could do it easily myself
<mlankhorst> RAOF: anyhow you need to create a read-only mapping and add a wait-ge op for a dma-buf
<mlankhorst> well, either read-only or userspace inaccessible..
<mlankhorst> ive glanced through the documentation so I know r600 supports the operations at least
<mlankhorst> but the easiest case is adapting i915
<mlankhorst> oh btw, DON'T create a gem object for your sync bo, it will deadlock
<mlankhorst> besides that radeon uses ttm so there's no real  need for involving gem
<mlankhorst> RAOF: night 
<RAOF> Good night :)(
#ubuntu-x 2012-07-10
<mlankhorst> morning
<mlankhorst> RAOF: could you upload libdrm to debian experimental and then sync to ubuntu?
<RAOF> No, because I can't upload to Debian; tjaalton could though :)
<mlankhorst> tjaalton?
<RAOF> Who happens to be on holiday
<mlankhorst> aww
 * RAOF should really become a DD
<mlankhorst> same
<RAOF> I *could* take what's in git/debian-experimental and upload it to Ubuntu, though :)
<mlankhorst> yeah but was hoping to have the automagic sync magic do its job after that
<RAOF> Well, Debian Import Freeze is in effect, so the autosync is no longer going to be running.
<mlankhorst> ah sure then just upload to ubuntu
<RAOF> We'll need to manually sync anyway :)
<mlankhorst> 2.4.37 has both libdrm_nouveau's and with a small patch mesa will build again
<RAOF> *and* new mesa will build!
<mlankhorst> quantally
<mlankhorst> (and probably a 2 liner patch would allow old xf86-video-nouveau to build)
<mlankhorst> RAOF: ok pushed changes for mesa.git too
<RAOF> Does xf86-video-nouveau also build correctly? Your changes wrangle the old libdrm into the source tree, right?
<mlankhorst> yeah the trick is that only old libdrm_nouveau dependent packages require changes
<mlankhorst> and that I didn't change soname
<mlankhorst> libdrm_nouveau1.so links to libdrm_nouveau.so.1
<mlankhorst> libdrm_nouveau.so to libdrm_nouveau.so.2
<mlankhorst> same for libdrm_nouveau(1,).pc
<RAOF> So our existing xf86-video-nouveau package will build happily against libdrm_nouveau.so.2, right?
<mlankhorst> yep
<mlankhorst> oh that would require an upload to kill the drm patch
<mlankhorst> you're right
<RAOF> Heh
<RAOF> But it's not going to break at runtime; the existing package will *work*, it's just that rebuilds will require a little finangling.
<mlankhorst> yeah
<mlankhorst> that was my whole goal
<mlankhorst> I wanted to be able to compile upstream without any changes to source to make it easier for users
<RAOF> A noble goal.
<mlankhorst> fedora renamed libdrm_nouveau.so.2 to libdrm_nouveau2.so.2 but since upstream didn't recognise it and no headers conflict it was ok not to do that
<RAOF> I wonder why they did that?
<mlankhorst> was done by their nouveau maintainer, probably less concern about compatability :)
<RAOF> Yeah :)
<mlankhorst> time to figure out git-send-email from canonical address and submit for review
<mlankhorst> and submitted for review :)
<mlankhorst> RAOF: can you look at the patches I posted on ml?
<mlankhorst> lkml or dri-devel
<RAOF> mlankhorst: I'll take a look at them tomorrow
<mlankhorst> oh great x1.13 has all the prime bits :)
<mlankhorst> hey bryceh 
<bryceh> hey
 * bryceh hehs the ubuntu wayland brouhaha on slashdot
<mlankhorst> bryceh: you know I should propose something outrageous but with enough insanity that it sounds plausible next uds
<mlankhorst> and then laugh at the press it generates
<bryceh> mlankhorst, totally.  I scheme up ideas all the time :-)
<bryceh> mlankhorst, only problem is that then when you *don't* deliver the crazy thing, then they just gloat that you "failed"
<mlankhorst> The only way the MS Surface will kill the iPad is if it drops on one!
<mlankhorst> :D
<mlankhorst> bryceh: and nah i don't get the blame then
<seb128> bryceh, hey
<seb128> bryceh, do you think that getting libxrandr-utils ready and porting the GNOME stuff this cycle seems realistic?
<seb128> bryceh, I'm wondering if we should postpone the GNOME porting part, it seems like to me that if we get the lib ready this cycle it would already be good, then we can port next cycle?
<bryceh> seb128, ok that sounds good
<bryceh> if I have a package 1.0.2-0ubuntu2 in precise, and am SRUing a new upstream release 1.0.3, would the numbering for the precise-proposed upload be just 1.0.3-0ubuntu1 or should it be something like 1.0.2*really1.0.3-ubuntu-1? 
<maxb> Well, no 'really' - that's only when the upstream version needs to be reduced
<maxb> SRUs don't generally get new upstream releases at all, so I'm not sure there's a solid convention
<maxb> 1.0.3-0ubuntu1 would collide with the normal versioning of an upload to quantal
<maxb> So my guess would be something like 1.0.3-0ubuntu0.1 or -0ubuntu0precise1
<seb128> bryceh, what maxb wrote
<seb128> usually people use 1.0.3-0ubuntu0.1
<bryceh> seb128, great thanks
<bryceh> maxb, right, thanks.
#ubuntu-x 2012-07-11
<thomas__> Good morning, is there a change to get the 302.16 nvidia-graphics-driver package from archives or so?
<ricotz> mlankhorst, hi, i guess you forgot to git add 14-libdrm_nouveau1.diff in debian git?
<mlankhorst> woops probably
<mlankhorst> fixed
<mlankhorst> RAOF: can you push new libdrm to quantal?
<RAOF> mlankhorst: Certainly; it doesn't appear to be in alioth git, though?
<mlankhorst> debian-experimental?
<RAOF> Oh, that's right; it's debian-experimental.
<RAOF> Sorry
<RAOF> mlankhorst: Looks good to me; have a libdrm upload.
<mlankhorst> ok I pushed the missing patch ricotz pointed out to mesa too so you can push that as well
<mlankhorst> what about x-v-nouveau, branch off to experimental too?
<mlankhorst> it would just be bumping to libdrm >= 2.4.34 and commenting out the drm patch
<mlankhorst> RAOF: I think I asked tjaalton to upload the xorg pkg for x1.12 too, but I don't see it in quantal-changes, can I check somewhere what happened to it?
<mlankhorst> also my turn to get on internet's finest news source today
<tjaalton> mlankhorst: howdy, and whoops
<tjaalton> looks like i somehow forgot about that one
<mlankhorst> ah k
<mlankhorst> I'm uploading the renamed x1.12 stack for precise again and going to work on x1.13 tomorrow since first -rc has come out :)
<tjaalton> uploading
<mlankhorst> thanks!
<tjaalton> wonders of an N9, fingerterm, screen and ssh to my home workstation :)
<mlankhorst> tjaalton: during uds I had to add wake-on-lan to that
<mlankhorst> but I have a small apple bluetooth keyboard now
<tjaalton> i have it always on
<ricotz> mlankhorst, you can take a look at https://launchpad.net/~ricotz/+archive/unstable/+packages
<tjaalton> btw, Jolla :)
<mlankhorst> tjaalton: indeed, I'm going to buy it as soon as it becomes available
<mlankhorst> with no other information lol
<mlankhorst> i don't know specs, I don't know price
<tjaalton> hehe, my thoughts exactly
<tjaalton> mlankhorst: hmm you added the mesa nouveau patch to the ubuntu branch?
<mlankhorst> tjaalton: yeah I did now
<tjaalton> i mean the numbering suggests it was meant for debian
<mlankhorst> tjaalton: it is
<mlankhorst> I'm planning on putting the whole new stack in debian-experimental including mesa 8.0.4
<tjaalton> ah, so you'll add it there when it works for us?
<tjaalton> i'll stop now :)
<mlankhorst> well debian is in freeze
<tjaalton> experimental is open
<mlankhorst> yeah that's why there :)
<tjaalton> ok then :)
<ricotz> mlankhorst, btw, this is the buildfix http://lists.x.org/archives/xorg-devel/2012-July/032638.html, if you want to go for 1.13rc1
<mlankhorst> ricotz: ah ty :)
<mlankhorst> oh..
<mlankhorst> my xorg packages are stuck between firefox/thunderbird daily builds
<mlankhorst> and libreoffice is building as well
<RAOF> mlankhorst: âGood morningâ, says launchpad,  I'
<RAOF> mlankhorst: âGood morningâ, says launchpad, âI've tried to build libdrm on armel and armhf and failed. How do you like *them* apples!â
<mlankhorst> sigh I'll see if I can upgrade my pandaboard to quantal
<RAOF> Or just build in a chroot.
<RAOF> mk-sbuild!
<mlankhorst> NO! I have a pandaboard and I will use it
<mlankhorst> :P
<RAOF> mk-sbuild *on* the pandaboard!
<mlankhorst> could you pastebin the failure btw? I'm tired about to sleep
<RAOF> I'll forward you the mail.
<RAOF> Go and have a sleep. :)
<mlankhorst> yeah was just reviewing rob clark's response to my dmabufmgr code
<mlankhorst> well actually his attempt at doing fencing, mine was horrible :)
<RAOF> âº
<mlankhorst> RAOF: well looks like a 1 line fix..
<RAOF> Oh, that's good.
<mlankhorst> figure out what release introduced omap_bo_dmabuf@Base and add it to debian/libdrm-omap1.symbols
<mlankhorst> well I'll be working less tomorrow seems later than I thought, good night :)
<RAOF> Heh.
<RAOF> Night1
<bryceh> had a chance to look at my mesa 8.0.3 sru?
<RAOF> Not yet, sorry.
<RAOF> I'll just add -radeon support to ppa:ubuntu-desktop/system-compositor, then do that review.
<mlankhorst> I just re-uploaded base to https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport/+packages
<mlankhorst> probably drivers tomorrow morning
<bryceh> RAOF, cool sounds good
<bryceh> mlankhorst, excellent
<mlankhorst> RAOF: could you upload the libdrm change needed to fix arm or want me to do it in the morning?
<bryceh> once 8.0.4 is in debian I'll pull that into quantal, maybe we can sru that too in a few weeks
#ubuntu-x 2012-07-12
<RAOF> mlankhorst: I can fix that.
<mlankhorst> bryceh: I added a 14*.diff to ubuntu branch for newer libdrm, but it's intended for debian too, I wanted to upload the whole x1.13 stack tomorrow and upgrade all video drivers on debian
<bryceh> ok
<mlankhorst> in debian-experimental
<mlankhorst> but after that back to dmabuf stuff, I want a working solution preferably soon so it can live in linux-next long enough for merge window hopefully
<RAOF> That'd be good.
<mlankhorst> there are some changes that would be nice to have in -next like deferred fput
<mlankhorst> but yeah I completely underestimated how much work it was going to be to really complete this :)
<bryceh> RAOF, how's system compositor going?  I saw the status updates on the blueprint, which sounded like it's got a long row to hoe.  However I also read in the slashdot comments that it's going to maim kittens, level small towns, and generally mark an end to computing as we know it?
<mlankhorst> not to mention drown puppies
<RAOF> And cause freak hurricanes.
<bryceh> :-D
<mlankhorst> but phoronix seemed to have picked up on my dmabufmgr code quickly
<RAOF> The bits that are left shouldn't be *too* hard.
<RAOF> Phoronix: everyone's favourite mailing list aggregator!
<mlankhorst> nah it's lacking the feature where it links to the source
<bryceh> but it makes up for it with beer references
<mlankhorst> can't drink alcohol any more due to meds, not sure if I miss it..
<mlankhorst> actually I do miss the taste, none of the alcohol free beer here is any good, in germany however :)
<RAOF> It's probably a technical challenge to create good tasting alcohol free beer.
<mlankhorst> I think the more likely answer is that there's less of a market for it
<bryceh> I had a coffee roaster describe what the process is for making decaf beans.  It's amazing there's any taste at all.
<RAOF> Probably a combination of the two.
<RAOF> bryceh: Using crazy solvents, or submerging them in supercritical COâ?
<RAOF> (Incidentally, supercritical COâ is pretty awesome)
<bryceh> I forget the exact process but yeah they extract all the stuff from the bean, chemically remove the caffeine, then smoosh it back into the bean.  Something like that anyway.
<RAOF> 6.14.99~really6.14.5+git20120712.gitg8dc07e6-0~systemcompositor1. It's the world's longest version string!
<mlankhorst> RAOF: backported ~precise1~ppa1
<RAOF> W: xserver-xorg-video-ati-dbg: package-has-long-file-name 103 (112) > 80
<RAOF> It has officially triggered a lintian warning :)
<mlankhorst> I think this would be longer still: xserver-xorg-video-ati-lts-quantal-dbg 6.14.99~really6.14.5+git20120712.gitg8dc07e6-0~precise1~ppa1
<RAOF> Yes. Yes it would.
<mlankhorst> but if you want i can try to append ~systemcompositor1 to that
<RAOF> Aaand everything should now be system-compositor-capable. Back to base for debriefing and cocktails.
<RAOF> Or possibly coffee and mesa SRU review.
<tjaalton> duh, there was a security update to xorg-server, which doesn't have the change for bug 921236. could someone roll out a new version for -proposed?
<ubottu> Launchpad bug 921236 in xorg-server (Ubuntu Precise) "[12.04 Xorg, xserver 1.11.3] Dual monitor, after entering password, mouse pointer stuck on LHS of screen, no desktop." [High,Fix committed] https://launchpad.net/bugs/921236
<mlankhorst> morning
<mlankhorst> tjaalton: do you still need a new version rolled out for xorg-server?
<mlankhorst> RAOF: ok I updated ubuntu-precise with the security update again, can the xserver sru be pushed out again?
<mlankhorst> yikes, 10 hour queue on xserver..
<Sarvatt> ricotz: great, that newer mesa is busted on intel
<Sarvatt> craploads of DRM_IOCTL_I915_GEM_CONTEXT_CREATE failed: Invalid argument and the unity panel doesn't work
<ricotz> Sarvatt, i havent looked into it, but i noticed some areas not refreshing
<ricotz> ^ with gnome-shell
<ricotz> it is working though
<ricotz> although it broke xserver master build ;)
<ricotz> Sarvatt, grr, weston already needs a newer mesa :\
<ricotz> Sarvatt, http://cgit.freedesktop.org/mesa/mesa/diff/include/EGL/eglmesaext.h?id=e6a33570b73aa56c87818d7f67a122d4427b7841
<Sarvatt> great DRM_IOCTL_I915_GEM_CONTEXT_CREATE is only in drm-intel-next-queued
<ricotz> Sarvatt, uh, but it is proposed for 3.5?
<Sarvatt> note to self: stop updating crap when it's time for an intel quarterly release
<ricotz> hmm :\
<Sarvatt> so i guess i'll go back to a checkout from the 8th, then cherry-pick those wayland commits..
<ricotz> Sarvatt, reverting the introduction of DRM_IOCTL_I915_GEM_CONTEXT_CREATE, is not an option?
<Sarvatt> i dont know where it broke and its a freaking nightmare patching this to build out of tree, but apparently it wasn't broken in an 0708 checkout RAOF did for the system compositor ppa :)
<ricotz> hmm, i see
<ricotz> Sarvatt, i dont see any reference to DRM_IOCTL_I915_GEM_CONTEXT_CREATE
<ricotz> Sarvatt, it is probably caused by libdrm
<ricotz> http://cgit.freedesktop.org/mesa/drm/commit/?id=a5b2946889471f6075852949f90f660e43b68532
<ricotz> Sarvatt, http://cgit.freedesktop.org/mesa/mesa/commit/?id=860d5bdf984730f69cd19b4f7145f3c84b57d33d
<ricotz> Sarvatt, try just to revert this ^
<mlankhorst> Sarvatt: hm should we try to sru all the X packages that aren't core X but used by X to reduce breakage when switching stacks?
<osiris> will adding the x-swat ppa get my old nvidia card's HW acceleration going again ? running ubuntu 12.04 with a nvidia geforce 4 fx 5200
<osiris> I understand this is an issue with the newer version of xorg not playing nice with the 173 driver
<Sarvatt> RAOF: does that 0708 mesa in the system compositor ppa actually work for you on intel? because it doesn't here, unity panel is blank
<ricotz> Sarvatt, RAOF, to be specific unity3d ;)
<bjsnider> osiris, have you tried the nouveau driver?
<RAOF> Sarvatt: You mean, unity doesn't display any icons? That's a unity bug, I think.
<RAOF> Sarvatt: At least, people who weren't (AFAIK) using the system-compositor PPA were also complaining about it.
<mlankhorst> RAOF: we should have a discussion about sru'ing libdrm at one point :)
<RAOF> What needs to be SRUd there?
<mlankhorst> i think it would make more sense if we sru all the libraries that would need an update explicitly surrounding X so the core X packages + mesa package itself can be swapped easier
<mlankhorst> so all the X drivers + X server + Xorg package itself would be renamed
<RAOF> I don't think that's likely to happen.
<RAOF> Or, rather, policy explicitly forbids it, and unless there's a really good reason I don't think the policy will be amended.
<RAOF> mlankhorst: I though libdrm was easy enough to rename (adding in a bonus plymouth-rename, which is annoying, but not critical)?
<mlankhorst> RAOF: it's actually easy to rename, but hard to upgrade
<mlankhorst> things break apart rather quickly
<RAOF> Hm. What upgrade paths were we supporting, again?
<mlankhorst> I would guess upwards mostly, but it just breaks too fast leaving a chance of leaving system unbootable
<mlankhorst> since it's core
#ubuntu-x 2012-07-13
<mlankhorst> a system stuck between libdrm and libdrm-lts-quantal isn't pretty to repair..
<mlankhorst> x stack itself is a lot easier, worst case you remove the entire xorg-server-core package and all drivers and install 'xorg' again
<RAOF> Yeah.
<RAOF> It shouldn't be *too* hard to ensure it doesn't get wedged half-way between, though.
<osiris> bjsnider, i think thats the driver i have running now. that is the default that comes with installation, correct ?
<bjsnider> osiris, yes
<osiris> then yes, it is working that way, sans HW accel
<bjsnider> if you install libgl1-mesa-dri-experimental you will get hw accel
<bjsnider> and you can get vsync with Option "GLXVBlank" "on" in xorg.conf device section
<tjaalton> mlankhorst: i see you updated xserver for precise, thanks :)
<tjaalton> bjsnider: that package is basically empty iirc, the nouveau dri drivers are included in the main package
<mlankhorst> RAOF: speaking of which can you upload the new xorg-server package to proposed?
<Sarvatt> RAOF: everyone complaining is on sandybridge and newer intel and an 0529 mesa checkout works fine, just a heads up in case you see complaints about the system compositor ppa not showing icons or alt+tab thumbnails in unity :)
<mlankhorst> ok now lets see if this patch will boot or not \o/
<mlankhorst> scarily, it does
<mlankhorst> glxgears uses 10% cpu, Xorg 20%
<mlankhorst> 35042 frames in 5.0 seconds = 7008.062 FPS
#ubuntu-x 2012-07-15
<scientes> 00:0d.0 VGA compatible controller: NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2)
<scientes> had been broken 3d-wise since right before precise freeze
<scientes> using nvidia drivers
<scientes> i tried using 3.5 kernel and 302 driver "built" from quantal
<scientes> nouveau is really bad, and the new nouveau for this card in mesa 8.1, crashes X alot
<scientes> i use to get great stability and performance with nvidia driver before it broke
<bjsnider> i'm assuming you submitted a bug to nvidia about this. what did they say?
<scientes> no i didn't
<bjsnider> ok well it's their driver
<scientes> yes i understand
<scientes> if nouveau worked for me i would love to use that
<bjsnider> looks like you have an nforce chipset, which doesn't help
<scientes> yes, its a new mesa driver in 8.1
<scientes> but it had very acceptable performance with the nvidia driver..once
<scientes> include precise, but then it broke about a month before release
<scientes> yeah their site is too difficult to register with
#ubuntu-x 2013-07-08
<Sarvatt> ricotz: planning on doing something with those llvm 3.3 packages whenever they publish or is it ok if i upload todays mesa?
<ricotz> Sarvatt, feel free to upload a mesa with enabled radeonsi which uses llvm-3.3 ;)
<Sarvatt> ...which is useless until glamor is also in there.. :P
<Sarvatt> still 2 more hours till llvm is done, ugh
<ricotz> hmm, i see -- a git stack rebuild would be nice too though
<ricotz> Sarvatt, it will land in dep wait, so it would be fine
<Sarvatt> got it all ready but i'll wait out the llvm builds so it doesn't take until tomorrow to build due to the retry.
<Sarvatt> also heh the ones i had ready from earlier wouldn't have built anyway,  llvm-3.2-dev (>= 1:3.2repack-7~) [amd64 i386 kfreebsd-amd64 kfreebsd-i386 armhf powerpc]
<ricotz> Sarvatt, hehe, right bump those to llvm-3.3
<ricotz> and don't forget the tweak in debian/rules
<Sarvatt> yeah i just dropped 2 hunks from mesa-9.2.patch, adjusted the build deps, and changed ac_cv_path_LLVM_CONFIG=llvm-config-3.3
<ricotz> :)
<Sarvatt> well lets see if it builds on saucy first while i'm waiting
<ricotz> i dropped "building against the proposed pocket"
<Sarvatt> so are you planning on patching all the drivers for xwayland support? :P
<Sarvatt> or just turning it on in xserver and let people do that on their own?
<Sarvatt> looks like RAOF's branches from a year ago are the canonical ones for ati and nouveau on http://wayland.freedesktop.org/xserver.html ....
<ricotz> Sarvatt, yeah, of course those patch-sets should be added, at least for the main three drivers
<Sarvatt> those shouldn't even work with xserver 1.14, are there updated branches wherever you got the 1.14 xwayland?
<ricotz> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/?h=xwayland
<ricotz> the server patch is a rebase of http://cgit.freedesktop.org/xorg/xserver/log/?h=xwayland-1.12
<Sarvatt> doesn't apply to git
<ricotz> huh?
<Sarvatt> doesn't look like a trivial change either.. maybe better off with another ppa for the older drivers
<Sarvatt> top 3 commits on http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/?h=xwayland don't apply to git intel
<ricotz> ok
<ricotz> Sarvatt, hehe, https://launchpad.net/ubuntu/+source/llvm-toolchain-3.3/1:3.3-3/+build/4762052 :\
<Sarvatt> tell me theres another upload... lol
<ricotz> https://launchpad.net/ubuntu/+source/llvm-toolchain-3.3/1:3.3-3
<ricotz> there isnt 
<Sarvatt> clang test failures, if only that didn't get shoved in the same package..
<ricotz> hmm, you could push to the raring pocket, after adding the elf dep ;)
<Sarvatt> good thing amd64 failed because of the missing libelf
<ricotz> yeah, that would have been a multiarch hell
<Sarvatt> uploaded raring, lessee if that works..
<ricotz> Sarvatt, alright, i pinged Adam about llvm
<ricotz> Sarvatt, hmm :\ /usr/lib/x86_64-linux-gnu/libLLVM-3.3.so
<Sarvatt> oh no, dont tell me he forked the llvm-3.3 packaging without the llvm-3.2 packaging fix for the third time
<ricotz> Sarvatt, looks like it
<Sarvatt> :(
<Sarvatt> was fixed in llvm-3.2, then it moved on to llvm-toolchain-3.2 without the fix, that got fixed now its in llvm-toolchain-3.3...
<ricotz> feel free to push mesa without radeonsi, if you feel it is worth having it earlier
<ricotz> (i didnt expect that to happen again)
<ricotz> bbl
#ubuntu-x 2013-07-10
<hyperair> how do i increase the pointer acceleration of an input device using the polynomial profile?
<hyperair> ugh
<hyperair> X has rss=3309080
 * hyperair groans
<hyperair> +k
<hyperair> weirdly enough, it seems to be counted as cache
<hyperair> no wait..
<hyperair> VmallocTotal:   34359738367 kB
<hyperair> yeah it is under Cached
<hyperair> after drop_caches=3, i still get a huge number in the Cached line in meminfo
 * hyperair pokes Sarvatt
<a5m0> anyone else having crazy X memory usage? i went xubuntu 12.04 -> 13.04 last night and X memory usage keeps ballooning until it crashes
<bryce> a5m0, usually that's due to application misbehavior.
<tjaalton> likely flash
<a5m0> bryce: i force closed the flash process in chrome but I'm watching /usr/bin/X keep climbing in virt anrd res
<a5m0> i wonder if it's something about the new chrome 28 :/
<bryce> a5m0, find out steps to reproduce it on clean boots, then isolate what application causes it, and then if you really want to dig into it, hook it up to xtrace and see what it's doing.
<Sarvatt> kaay, now i'm hitting it too on raring after rebooting into about 2 weeks worth of updates
<Sarvatt> looks like its chrome here
<Sarvatt> looks like i got booted and kept on talking, did my previous messages go through asking if you used xorg-edgers a5m0?
<ScottK> Don't see it.
<Sarvatt> ah thanks. there's definitely something fishy going on with xorg-edgers, its fine without that and wasn't chrome related in the end. trying to isolate it now
<Sarvatt> a5m0, hyperair: it's xserver-xorg-video-intel, glad it was caught before he releases 2.21.12.. I'll file a bug upstream
<a5m0> Sarvatt: awesome i'm not just a batshit noob
<a5m0> i am indeed on xorg-edgers, with the 3.10 mainline kernel as well
<tjaalton> Sarvatt: just file it on lp, ickle will pick it up :)
<tjaalton> thouhg b.fd.o is of course nicer
<tjaalton> -gh
<Sarvatt> i'm trying to figure out where it started, glad i have all these packages lying around making bisecting easy :P pmed him though
<Sarvatt> ppa-purging xorg-edgers then only upgrading x-x-v-intel brings the problem back, thats why i'm sure
<tjaalton> cool
<Sarvatt> why do these things that take a few hours have to pop up at EOD
<tjaalton> it's by-design
<mlankhorst> it's to give you work for tomorrow and make you glad you called EOD
<Sarvatt> he posted on lp earlier saying he's going to release 2.21.12 asap if no bugs are found
<mlankhorst> so what :p
<tjaalton> we get another release to skip :)
<Sarvatt> a5m0: the 0703 x-x-v-intel in your /var/cache/apt/archives/ works
<Sarvatt> if you want to downgrade
<Sarvatt> lol!
<Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=d935912d9c13ec8cf4f641c55846714d4e9ba929
<Sarvatt> ....already fixed, i just haven't updated today
<Sarvatt> hyperair, a5m0: its uploaded, should be published in about 30 minutes, going to need to restart to fix it
<hyperair> yay
#ubuntu-x 2013-07-11
<a5m0> woo rebooting now
<Sarvatt> i havent rebooted yet to switch away from 0703 that works but it should work, if not let me know
<Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=66742 made it pretty dang obvious, same thing was needed to reproduce it (flash videos on chrome)
<ubottu> Freedesktop bug 66742 in Driver/intel "[sna] Memory leak in commit "sna: Flush blt copies if no operations pending"" [Major,Resolved: fixed]
<a5m0> Sarvatt: looks like it's working right now, thanks!
<Sarvatt> a5m0: cool beans, thanks for checking it
 * hyperair starts up some youtube video for good measure
#ubuntu-x 2014-07-09
<mlankhorst> Prf_Jakob: [  2281.803] (WW) vmware(0): Failed to initialize Gallium3D Xa. No render acceleration available.
<mlankhorst> any idea why i would get that on utopic?
<mlankhorst> seems to happen with mesa 10.2.3 too
<mlankhorst> on a related note, does vmware player have 3d acceleration or do you need vmware client or better?
#ubuntu-x 2015-07-06
<hyperair> Sarvatt: is chromium's webgl broken for you on vivid?
<tjaalton> hyperair: is for me at least, used to work.. can't repro a bug anymore
<hyperair> repro what bug?
<tjaalton> skylake hang
<tjaalton> yep, downgrading to 41 made webgl work again
#ubuntu-x 2015-07-07
<hyperair> tjaalton: chromium 41 misses some security updates though
<tjaalton> i only use it for testing
<hyperair> ah, i see
<hyperair> makes sense then.
#ubuntu-x 2016-07-15
<soee> mamarley: NVIDIA 367.35 Released, Supports 8K H.265 Video Decoding
 * mamarley slaps soee around a bit with a large trout.
<soee> ;D
<mamarley> That said, I have been expecting this all week. :)
<mamarley> ricotz: nvidia-graphics-drivers-367.35 is packaged in ppa:mamarley/staging.  nvidia-settings is in ppa:mamarley/updates this time because I accidentally uploaded an incorrect orig.tar.gz to staging and I couldn't overwrite it.
#ubuntu-x 2016-07-16
<Guy1524> hello
<Guy1524> anybody there
<mamarley> soee: You probably already noticed, but nvidia and nvidia-settings 367.35 are in graphics-drivers/ppa. :)
<soee> mamarley: yup, have it installed, thanks :)
<mamarley> Some people have been complaining about a black screen on bootup and needing to VT-switch before it starts working.  I haven't seen that though; perhaps because I have DRM KMS modesetting enabled.
<soee> uhm, i just couldn't reboot normally as it ended with black screen
<soee> but hard reset and system boots just fine now
#ubuntu-x 2017-07-11
<ricotz> mamarley, hi, I copied 384 -- https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa/+build/13070583
<ricotz> mamarley, also everytime you seems to be adding stray files, like the obsolete debian/dkms_nvidia/dkms.conf
<mamarley> I'm not sure where those are coming from; I'm definitely not adding them manually.  I will look at the armhf failure.
<mamarley> Looks like the armhf driver doesn't have a Vulkan ICD at all, causing the failure when it tries to sed the library name.  I will wrap that sed command in "ifneq ($(DEB_BUILD_ARCH),armhf)"
<mamarley> ricotz: Actually, I did figure out where the garbage dkms.conf is coming from.  It looks like it gets put there when I do a full build to produce .debs, but never gets cleaned up.  Should I add a command to remove it in the override_dh_clean section in rules?
<tseliot1> mamarley: override_dh_clean already calls regen-from-templates
<tseliot1> that should give you a new dkms.conf
<mamarley> tseliot1: It does; the problem is that the old one doesn't seem to get removed.
<mamarley> I deleted them manually for this upload, but they come back whenever I run a local build.
<ricotz> mamarley, create the source-package before you do a test-build
<mamarley> OK
<mamarley> ricotz: I uploaded the package with the armhf fix to https://launchpad.net/~mamarley/+archive/ubuntu/staging3/+packages and everything built.  Should I go ahead and copy it to the main PPA?
<ricotz> mamarley, yes, please do
<mamarley> Done
#ubuntu-x 2019-07-10
<ricotz> mamarley, hi
<ricotz> I noticed you already prepared 430.34 :)
<ricotz> nvidia-settings looks not good though, while only eoan requires the 05_add_polkit_support.patch which implies screen-resolution-extra (>= 0.18~)
<mamarley> ricotz: OK.  I will fix that.  I also couldn't figure out that relocation issue that is causing the FTBFS on some architectures on older releases.  It says it needs to be compiled with -fPIC, but it already seems to be.
<ricotz> tseliot1, doesn't apply disable_fstack-clash-protection_fcf-protection.patch
<ricotz> I mean fails to apply
<tseliot1> ricotz: that's weird, let me try again
<tseliot1> ricotz: nvidia-graphics-drivers-430_430.34-0ubuntu2 works now. I moved the line away from the line where the version was specified. Now it applies cleanly to both 430.34 and 430.26
<tseliot1> thanks for letting me know
#ubuntu-x 2020-07-10
<soee> hi, will there be 450.57 build for focal?
