[00:19] <RAOF> tjaalton: Bah, sorry; should have built with -sa obviously.  The tarballs are in the archive, or uscan will grab them.  I'll push them now if you ilke.
[00:21] <RAOF> I didn't push many of those packages to git, since they're basically a pre-sync from experimental.
[00:23] <RAOF> And no-change rebuilds of packages sync'd from Debian also don't warrant an ubuntu branch.
[00:42] <Sarvatt> RAOF: he was talking about the ones that were merged in debian-experimental git but not released in experimental, i got em all though
[00:43] <RAOF> Sarvatt: Yeah, thanks.
[00:43] <Sarvatt> or did you have those in that huge pile of drivers?
[00:44] <RAOF> I had those in the huge pile of drivers, but I didn't build with -sa
[00:45] <Sarvatt> oh bah, i should have looked!
[00:46] <RAOF> 'sok.
[00:46] <RAOF> I think we might be one sync from Debian down.
[00:47] <Sarvatt> openchrome needs an xsfbs update (thats in video-all so its important)
[00:48] <Sarvatt> i put in sync requests for geode and chips this morning
[00:51] <asac> RAOF: will you upload xorg soon ;)?
[00:52] <RAOF> asac: So soon as to be _in the past_ !
[00:52] <asac> RAOF: https://edge.launchpad.net/ubuntu/+source/xorg/+changelog
[00:53] <asac> or is that source dead?
[00:54] <RAOF> Oh, right.
[00:54] <RAOF> No, it's not yet uploaded.
[00:54] <RAOF> Yes, soon :)
[00:54]  * RAOF thought Timo had uploaded it last night.=
[00:56] <asac> lol
[00:56] <asac> very good. if you do it now i can get my xorg packages back in the morning ;)
[00:56] <asac> all will be fine. i just keep it running ;)
[00:57] <asac> ttyt
[01:09] <bryceh> heya RAOF, how're things going?
[01:11] <RAOF> bryceh: Busy busy busy!
[01:12] <bryceh> :-)
[01:13] <bryceh> RAOF, hey I was wondering if you could help me with an X problem.
[01:13] <RAOF> Sure.
[01:13] <bryceh> I dropped my laptop in the bathtub, and now all I get is a garbled screen when I turn it on
[01:13] <bryceh> should I dry it off before turning it on?
[01:13] <RAOF> Yes.
[01:13] <RAOF> But more.
[01:13] <RAOF> You should find a chemical fire extinguisher.
[01:14] <bryceh> hehe
[01:14] <RAOF> Hook it up to the fan outlet, and empty the extinguisher through it.
[01:14] <bryceh> would it help if I installed more proprietary drivers?  I have installed all the proprietary video drivers I could find online.  still it doesn't work.
[01:14] <RAOF> That will collect all the water, and leave you with a shiny, clean laptop interior!
[03:05] <RAOF> Aww, man.  Sitting in front of the heater.  So much better!
[05:56] <tjaalton> RAOF: hey, yeah I left xorg out because openchrome was missing, but was too tired to mention it here :)
[05:57] <RAOF> That's ok.  Openchrome & xorg is on the way.
[05:57] <tjaalton> great
[05:58] <RAOF> Thanks for all the sponsoring.
[05:58] <tjaalton> np
[05:59] <RAOF> Hm.  Can you ack the -chips sync request?  bug #615496
[05:59] <ubot4> Launchpad bug 615496 in xserver-xorg-video-chips (Ubuntu) "Sync xserver-xorg-video-chips 1:1.2.3-1 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/615496
[05:59] <tjaalton> better yet, I can "sync" it
[06:00] <tjaalton> what was that command again...
[06:00] <RAOF> That would also work :)
[06:00] <RAOF> I think you need to grab ubuntu-dev-tools from bzr; then it's syncpackage, IIRC.
[06:01] <tjaalton> yeah I have the old script which should work as well.. letsssee
[06:03] <tjaalton> huh, the script fails if there's an epoch, which doesn't show on the link
[06:03] <tjaalton> oh well, it's just a wget & debsign away
[06:04] <tjaalton> hrm, can't dput without .changes
[06:06] <tjaalton> ah, the script extracts and rebuilds the source
[06:11] <tjaalton> RAOF: bah, confirmed the sync request instead, now breakfast :)
[06:11] <RAOF> Have deliciousness!
[06:11] <tjaalton> dunno how to unsub the sponsors team
[06:11] <RAOF> If you're not on the sponsors team, you can't.
[06:11] <RAOF> If you are, then I think it's a red ‘-’ next to the team subscription.
[06:33] <tjaalton> yeah, I'm not
=== ara_ is now known as ara
[09:36] <alf__> Sarvatt: Hi! I have attached an alternative debdiff to debian #587771 with the changes you proposed.
[09:36] <ubot4> Debian bug 587771 in cairo "Package cairo-perf utilities" [Wishlist,Open] http://bugs.debian.org/587771
[10:14] <cnd> RAOF, Sarvatt: are you aware of any issues with radeon cards and the latest x uploads yesterday?
[10:15] <cnd> the screen on this dell laptop is all corrupted and unusable
[10:15] <cnd> I can't even get to a VT :(
[10:26] <cnd> I just did a full apt-get dist-upgrade and reboot and things seem ok
[10:27] <cnd> so maybe it was just some weird stale package
[10:31] <Sarvatt> tjaalton: wget http://sarvatt.com/downloads/ack-sync && ./ack-sync -e sarvatt@ubuntu.com 615496 -k yourkeyid
[10:31] <Sarvatt> tjaalton: oh nevermind its fix released now :)
[10:46] <ara> RAOF, any ETA for ABI?
[10:46] <ara> RAOF, morning, by the way, sorry 0:-)
=== yofel_ is now known as yofel
[11:38] <vish> tseliot: hi, what is the variable xthickness in the gtk context menu patch? is it configurable? or..
[11:38] <vish> http://bugzilla-attachments.gnome.org/attachment.cgi?id=165743
[11:39] <tseliot> vish: I'm not sure but I think it's something that the theme decides
[11:40] <tseliot> vish: why?
[11:40] <vish> tseliot: i was asked what that was on #gtk+
[11:47] <tseliot> vish: so, yes, I think what I said is correct. It's part of the gtk style and it can be defined in gtkrc
[11:48] <vish> tseliot: yeah , so seems we might need an update to the patch?
[11:48] <tseliot> vish: why?
[11:48] <tseliot> what did they say?
[11:48] <vish> tseliot: there is a new comment on the bug.. as to why we need the xthickness
[11:49] <tseliot> vish: ok, let me have a look
[11:50] <vish> tseliot: thanks.
[12:10] <njin> hy all
[12:11] <njin> someone around?
[12:18] <Sarvatt> ara: do you mean the new xserver? it's in already, proprietary drivers arent updated though because they dont work with it
[12:19] <ara> Sarvatt, OK, thanks for the update
[12:24] <tseliot> Sarvatt, ara: I'll update the Nvidia driver soon. At least nvidia-current works with the new X
[12:24] <Sarvatt> oh it does? \o/
[12:24] <tseliot> yes, it's ABI compatible
[12:24] <Sarvatt> 256.44?
[12:24]  * tseliot nods
[12:25] <tseliot> I might upload it today
[12:56] <ara> tseliot, thanks!
[12:56] <tseliot> np
[15:25] <tseliot> Sarvatt, jcristau: it looks like /usr/share/xserver-xorg/serverminver is no longer in xserver-xorg-dev. Do you know why? Has it been replaced with something else?
[15:26] <tseliot> maybe I should have a look at how open source (graphics) driver packages bump the server video abi automatically
[15:27] <Sarvatt> it was deprecated a long time ago and  finally removed in the new xserver
[15:28] <Sarvatt> http://git.debian.org/?p=pkg-xorg/xsfbs.git;a=summary
[15:30] <gord> hi all, seems no nvidia binary driver supports xorg 1.9, are we going to stick with 1.9 in maverick and hope that nvidia come out with a driver that supports it? or maybe have some packaging magic to fix it?
[15:32] <Sarvatt> gord: ppa://ubuntu-x-swat/x-updates
[15:32] <Sarvatt> tseliot says 256.44 works, nvidia said they were going to put out a xserver 1.9 compatible one back in june
[15:33] <tseliot> I'm working on the nvidia package and I'll upload it as soon as I'm done with this packaging issue
[15:33] <tseliot> well, Nvidia told me that
[15:34] <gord> running 256.44 here, grabbed it from the xorg-edgers ppa, doesn't seem to work. xorg says the ABI is broken in xorg.log
[15:34] <Sarvatt> ah it's waiting to build still, i guess it'll fail because of the serverminver thing. i fixed that a few uploads ago to that ppa but lost it when i resynced to the ubuntu packaging
[15:35] <Sarvatt> tried IgnoreABI? maybe tseliot has a newer nvidia release that works or something
[15:36] <Sarvatt> try adding Option "IgnoreABI" "true" to your xorg.conf?
[15:36] <tseliot> Sarvatt: was that package built against the new X?
[15:36] <tseliot> if not, it could try to remove X
[15:37] <gord> yeah i was going to try ignoreABI but i assumed that might be a bad idea ;) i'll give that a shot
[15:37] <tseliot> but I guess we're facing a different problem here
[15:37] <Sarvatt> the one i just uploaded was but it hasn't built yet, the one in xorg-edgers was from the start
[15:38] <Sarvatt> gord: let me know if it works if you can, I can't test it
[15:38] <tseliot> maybe let's wait for that package to build then?
[15:38] <Sarvatt> it wont build because of the serverminver thing
[15:39] <tseliot> ok, let me fix that, then we'll try
[15:43] <Sarvatt> one sec will give you a diff
[15:43] <tseliot> I'm rebuilding locally
[15:44] <tseliot> it was just a matter a copy & paste from -intel
[15:44] <tseliot> Sarvatt: ^
[15:47] <tseliot> nice, it built
[15:48] <Sarvatt> http://sarvatt.com/downloads/nvidia.patch
[15:48] <Sarvatt> oh i shoulda looked first :)
[15:48] <tseliot> thanks anyway
[15:49] <Sarvatt> i didn't make an orig.tar.gz for the nvidia package in x-updates because i got burned unable to update since they differed with the archive version last time :D
[15:52] <tseliot> Sarvatt: yes, just wait a little bit and you won't have to upload the tarball
[15:55] <Sarvatt> no worries man, thanks for doing that! was just mentioning why the package was messed up :P
[15:58] <Sarvatt> jcristau: is it safe to update protos in unstable or should these go into experimental? gl, render, video, x11, kb, xext
[16:04] <gord> Sarvatt, can confirm that adding ignoreAPI to the serverflags section gets me up and running with .44 :)
[16:04] <gord> ignoreABI*
[16:04] <Sarvatt> woohoo
[16:30] <tseliot> gord: what architecture do you use? amd64 or i386?
[16:30] <gord> tseliot, amd64
[16:31] <tseliot> gord: would you like to try my package without the ignoreABI option?
[16:32] <gord> tseliot, sure
[16:35] <Sarvatt> wow what the heck happened to power usage, i've been tethered to a power cord for the past 2 months so i hadn't noticed maverick is using ~4 watts more idle
[16:35] <Sarvatt> thats a lot when i was only using ~6.7 watts idle before in lucid
[16:36] <tseliot> gord: ok, I'm uploading my package to my personal webspace. I'll let you know when it's ready
[16:37] <gord> Sarvatt, do you have beam.smp running when you look at top? its destroying power usage all over. related to ubuntu one and gwibber (couchdb)
[16:37] <gord> tseliot, sure thing
[16:37] <Sarvatt> nope i purged those a long time ago for killing battery
[16:38] <Sarvatt> nothing really using cpu and a really low amount of wakeups/second in powertop (around 80 or so)
[16:48] <bryceh> Sarvatt, ubuntu-one was sucking down a lot of power on my system until I got rid of it
[16:52] <johanbr> Sarvatt, could be https://bugs.launchpad.net/ubuntu/+source/linux/+bug/524281
[16:52] <ubot4> Launchpad bug 524281 in linux-2.6 (Debian) (and 1 other project) "Tens of wakes per second in "[kernel scheduler] Load balancing tick" on Core 2 Duo even with only 1 core enabled (affects: 88) (dups: 1) (heat: 550)" [Unknown,Incomplete]
[16:54] <Sarvatt> i dont have any ubuntuone or gwibber packages installed. i figured it out though, normally i unloaded a bunch of modules on battery and i didn't that time, my webcam and wired NIC suck up a ton of power
[16:54] <Sarvatt> haha "tens of wakeups"
[16:54] <johanbr> at least for me, it's more like hundreds
[16:54] <Sarvatt> it was close to 800/second here just in load balancing tick up to 2.6.35-14.19
[16:54] <Sarvatt> but 2.6.35-14.20 fixed that
[16:55] <johanbr> 22.0% (421.6)   [extra timer interrupt]
[16:55] <Sarvatt> are you using -14.20?
[16:55] <johanbr> hmm...no 
[16:55] <johanbr> I'll have to try that
[16:56] <bryceh> Sarvatt, oh yeah webcam sucked power hard for me too
[16:56] <johanbr> even when not in use?
[16:57] <Sarvatt> johanbr: http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdiff;h=396e894 is in 2.6.35-14.20, it made a HUGE difference
[16:57] <bryceh> Sarvatt, you know what we need is a little applet to optimize power with all these tricks
[16:57] <Sarvatt> yeah its over 1W here not in use
[16:57] <Sarvatt> goes right down unloading the module
[16:57] <johanbr> bryceh, I vaguely remember Richard Hughes working on something like that
[16:58] <johanbr> possibly as part of gnome-power-manager
[16:59] <Sarvatt> pm-utils does a bunch of it now, a bunch of the stuff i use isn't something most people would want and a gui would be nice.. things like unloading wired NIC's, card readers, webcams, enabling wifi power savings modes and stuff
[17:01] <Sarvatt> i even went so far as hacking up my bios on this netbook to enable lower screen brightness settings that flicker and use sata mode
[17:02] <Sarvatt> there's a crazy amount of efi variables not exposed on the OEM bios pages for most laptops that you can manually enable
[17:04] <tseliot> gord: please try this package (remember to comment out IgnoreABI line in your xorg.conf): http://albertomilone.com/ubuntu/nvidia-current_256.44-0ubuntu1_amd64.deb
[17:28] <gord> tseliot, that package doesn't seem to work when i have my ignoreABI line commented out - re-adding the line works fine though
[17:29] <tseliot> gord: ok, thanks for testing. I'll talk to Nvidia again
[17:30] <gord> np
[17:32] <Sarvatt> bryceh: in case you want to fill this out some more and send it to xorg-devel - http://sarvatt.com/downloads/patches/0001-Spelling-fix-in-help-docs.patch
[17:33] <Sarvatt> it's our only delta over debian
[17:33] <Sarvatt> (in x11-xserver-utils)
[17:36] <Sarvatt> oh good git send-email works fine sending from other authors, sorry for sending that to you but it cc-ed you automatically and i wanted to see what happened
[17:36] <bryceh> Sarvatt, ok thanks yeah feel free to send it in; it's pretty trivial
[17:38] <Sarvatt> ok to add your signed-off-by then? is the email right?
[17:38] <bryceh> yep
[17:50] <asac> RAOF: my friend ;)
[17:51] <asac> RAOF: https://wiki.linaro.org/Platform/UserPlatforms/2010-08-10 please search for RAOF here ;)
[18:06] <Sarvatt> mesa makes me a bit nervous, since they skipped a release cycle 7.8->7.9 is going to be a huge change and there are going to be much potential for regressions with the new glsl2 stuff (that isn't even getting merged for a few weeks yet) up until the very last minute. not to mention we'd need to somehow get mesa demos packaged and uploaded in debian and brought over by tomorrow? :) aside from the demos problem it'll take a few days redoing the bu
[18:06] <Sarvatt> ild system for all of the egl/gles/etc changes in 7.9
[18:10] <Sarvatt> since mesa demos needs seperate packaging its a good time to review what other demos would be useful to package up (and create man pages for) outside of glxgears/glxinfo
[18:14] <bjsnider> Sarvatt, i managed to backport the nvidia-current built scripts to pre-lucid distros
[18:15] <Sarvatt> darnit, i wrote up a patch for jockey to add IgnoreABI to serverflags for nvidia last time I went through this in edgers but I can't find it
[18:17] <Sarvatt> bjsnider: but they can use the .run's! :D lucky buggers
[18:22] <bryceh> Sarvatt, how about dropping glxgears from the default install ;-)
[18:25] <Sarvatt> it already is :)
[18:26] <Sarvatt> 7 packages depend on mesa-utils, can't just not package glxinfo at all :(
[18:27] <Sarvatt> mesa-utils is in universe and i've had to get on the net to install it off of livecd's since last december
[18:39] <bjsnider> yeah, they can use the .runs and overwrite a bunch of mesa files
[19:30] <Q-FUNK> do the maverick drivers need to depend only upon videoabi or also on inputabi?
[19:30] <Q-FUNK> sorry, video drivers
[19:33] <Q-FUNK> Sarvatt: would you have a minute to help me with this?
[19:48] <Sarvatt> Q-FUNK: http://sarvatt.com/downloads/geode.patch
[19:48] <Q-FUNK> Sarvatt: well, I have a slightly more elaborate idea in mind to maintain backportability :)
[19:50] <Q-FUNK> Sarvatt: http://pastebin.com/TvUyjw3T
[19:50] <Sarvatt> squeeze should work with that since serverminver was deprecated awhile back but yeah older wont work without more fiddling
[19:51] <Q-FUNK> however, for some reason, it barfs, complaining about a missing "then" statement, even though it's there.
[19:51] <Sarvatt> is there any reason for there to be an explicit ${xserver:Depends} on geode-dbg since it already depends on -geode which depends on that?
[19:52] <Q-FUNK> to depend upon xserver-xorg-core-dbg
[19:53] <Q-FUNK> we'd normaly have matching versions for core and -dbg, but you never know
[19:55] <Q-FUNK> hm. I really wonder what makes it think that the "then" statement is missing.
[20:01] <Sarvatt> how far back are you planning on backporting it?
[20:06] <Q-FUNK> http://pastebin.com/Ci18SR4F
[20:07] <Q-FUNK> at least lucid
[20:08] <Q-FUNK> hopefully older, but I'm not holding my breath for that, because of e.g. gcc << 4.3
[20:08] <Q-FUNK> hm.  barfs on that last IF
[20:16] <Sarvatt> darn thats right, lucid didn't get xserver 1.7.6.901 in time :(
[20:18] <Sarvatt> i'm messing with it trying to get it going too but haven't had any luck so far
[20:28] <Q-FUNK> the above *would* work, exept that I forgot that we're dealing with m4, rather than bourne, syntax.
[20:36] <Q-FUNK> http://pastebin.com/HejstSVf
[20:36] <Q-FUNK> darn. I'm still stuck on that last IF statement.  make complains of a missing IF
[20:56] <Sarvatt> Q-FUNK: how about something like this? http://sarvatt.com/downloads/geode.patch
[20:58] <Sarvatt> whoops reuploaded it, forgot something
[20:59] <Sarvatt> can add the -dbg thing back i just dropped it while i was testing
[21:00] <Sarvatt> looks good on current maverick, need to see what happens  on lucid though
[21:01] <Sarvatt> Depends: libc6 (>= 2.7), xorg-video-abi-8.0, xserver-xorg-core (>= 2:1.8.99.904)
[21:01] <Sarvatt> Provides: xserver-xorg-video-8, xserver-xorg-video-amd
[21:05] <Q-FUNK> shouldn't that ifeq go the other way around?
[21:06] <Q-FUNK> ifeq (our string) then use the full videodep?
[21:09] <Sarvatt> /usr/share/xserver-xorg/videodrvdep doesn't exist in lucid so it'll be true there and use the old variables and false if it exists and use the new ones
[21:09] <Sarvatt> i just reused whats used in all the other xsfbs packages
[21:10] <Sarvatt> and instead of erroring out saying you need to update xorg-server to 1.7.6.901+ use the old substvars
[21:11] <Q-FUNK> hm, it seems to interpret the expanded $VIDEODEP as an equate statement to compare
[21:14] <Q-FUNK> on systems that have the newer file, that is
[21:16] <Sarvatt> oh whoops it should be VIDDRIVER_PROVIDES = xserver-xorg-video-$(VIDEOABI), xorg-driver-video
[21:17] <Sarvatt> i get the feeling i missed something else there :)
[21:18] <Sarvatt> maybe not, i dont see xserver:Depends used in current packages
[21:25] <Q-FUNK> http://pastebin.com/8dz5fZQG
[21:27] <Q-FUNK> doesn't like the way VIDEODEP expands
[23:02] <Q-FUNK> Sarvatt: I think I got a winner.
[23:16] <Q-FUNK> now, I just need this uploaded to debian/unstable && sync'ed into maverick and we're set. :)
[23:27] <yofel> should bug 616023 be reassigned to nvidia-graphics-drivers?
[23:27] <ubot4> Launchpad bug 616023 in xorg (Ubuntu) "nVidia card : X won't start since 1.9 update, no screens found (affects: 5) (heat: 24)" [Undecided,New] https://launchpad.net/bugs/616023
[23:51] <RAOF> yofel: That should be against nvidia-graphics-drivers, and tselliot's next upload of nvidia-current should fix it.
[23:51] <yofel> thanks
[23:53] <RAOF> asac: I'm not sure what you mean by “mesa test program” there - do you mean the mesa-demos?
[23:57] <RAOF> asac: As in - something like glxgears, but testing egl, gles, etc?