[00:15] <ripps> Hmm... the launchpad kernel ppa now supplies maverick kernel backports for lucid
[00:18] <Sarvatt> not supported on the desktop though unfortunately
[00:18] <Sarvatt> but thats not saying not to use it :)
[00:18] <Sarvatt> nouveau wont work though
[00:18] <RAOF> Unless you like fbdev
[00:19] <Sarvatt> i went 3 days once using fbdev on top of kms without realizing it :)
[00:19]  * Sarvatt is running xts against xorg-edgers, woohoo
[01:40] <Sarvatt> bah, For Linux hosts, make sure the host has a video card that can run accelerated OpenGL 2.0.
[01:40] <Sarvatt> no wonder i couldn't get vmware 3D running on this netbook
[01:47] <RAOF> That's going to cut down significantly on who can use it.
[01:48] <Sarvatt> enabled the fake opengl 2.0 support on i915, now it fails the same way it does with a windows host..
[01:49] <Sarvatt> gdm spawns it like 20 times and gives up, falls back to failsafe
[01:51] <Sarvatt> http://pastebin.com/j16SVuG1
[01:52] <Sarvatt> the drm:vmw_fb_setcolreg crap in dmesg is just from when it gives up trying to start a real X and launches failsafe fbdev on top of vmwgfx
[01:53] <Sarvatt> maybe the 2.6.35-rc2 vmwgfx will work
[01:54] <Sarvatt> we cant exactly ship vmwgfx/svga with mesa, I mean it needs X to build, and X needs mesa to build.. lol
[01:57] <Sarvatt> Dr_Jakob: any ideas what I'm doing wrong? do things only work with specific versions or something?
[02:29] <Kangarooo> Sarvatt: ? i finally got xcrash with ppa bugsbugs should i add it to that bug or send on irc? for me it looks like theres nothing but i dont know about gdb anything
[05:29] <Sarvatt> oh wow I totally screwed up the fglrx 10.5 packaging in x-updates, needed another patch and i messed up the patch rules for the one i added even :)
[05:29] <Sarvatt> all fixed up now
[05:32] <Sarvatt> does nvidia need patches to build on 2.6.34?
[05:41] <RAOF> We really need to reduce the number of patches we apply to X.
[05:41] <RAOF> I don't think it does; last I checked everything worked swimmingly.
[06:01] <Sarvatt> anyone around to accept this sync request? https://bugs.edge.launchpad.net/ubuntu/+source/libxprintutil/+bug/589528
[06:01] <ubot4> Launchpad bug 589528 in libxprintutil (Ubuntu) "Sync libxprintutil 1:1.0.1.xsf1-3 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
[06:01] <Sarvatt> going through bryce's versions-current
[06:13] <Sarvatt> also https://edge.launchpad.net/bugs/589530
[06:13] <ubot4> Launchpad bug 589530 in xserver-xorg-video-vesa (Ubuntu) "Sync xserver-xorg-video-vesa 1:2.3.0-3 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
[06:14] <Sarvatt> is there any way I can request syncs using my ubuntu email address? they show up as my main email address since I can't put the @ubuntu.com first because it breaks forwarding
[06:15] <Sarvatt> syncpackage rocks, wish I had upload rights :)
[06:20] <Sarvatt> ok https://edge.launchpad.net/bugs/589531 was the lastthat are straight syncs
[06:20] <ubot4> Launchpad bug 589531 in xserver-xorg-video-mga (Ubuntu) "Sync xserver-xorg-video-mga 1:1.4.11.dfsg-4 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
[06:21] <Sarvatt> updated the wiki with notes on what needs merged still, probably should have them ready before xorg-server is uploaded
[06:22] <RAOF> did I not already request a vesa sync?
[06:26] <Sarvatt> ah found some more
[06:26] <Sarvatt> yea
[06:26] <Sarvatt> https://edge.launchpad.net/bugs/589535
[06:26] <ubot4> Launchpad bug 589535 in xf86-input-evtouch (Ubuntu) "Sync xf86-input-evtouch 0.8.8-4 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
[06:28] <RAOF> That doesn't need a sync bug?  0.8.8-3build1 should be a candidate for autosync
[06:29] <Sarvatt> ah maybe autosync hasn't been run since the 15th?
[06:32] <RAOF> That seems a long time.
[06:35] <Sarvatt> hmm vmmouse in debian doesn't have the fixes in it
[06:35] <Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-input-vmmouse/
[06:37] <Sarvatt> this can be dropped right? xserver-xorg-video-r128 (6.8.1-2ubuntu1) lucid; urgency=low  * Bump xserver-xorg-video-r128 conflicts/replaces xserver-xorg-video-ati    version to match the version in Hardy for Hardy -> Lucid upgrades
[06:38] <RAOF> Yes.
[06:38] <Sarvatt> filing that one too then
[06:44] <Sarvatt> oopsed 6 times now :)
[06:45] <Sarvatt> pain in the butt cus it gets the changelog wrong and i have to delete the huge history
[06:45] <Sarvatt> OOPS-1616ED613
[06:45] <ubot4> https://lp-oops.canonical.com/oops.py/?oopsid=1616ED613
[06:46] <RAOF> Leaving -intel (merged, not uploaded), -ati (merged, not uploaded, build-depends on new xserver), -nouveau (updated, not uploaded, b-d on new xserver), synaptics (merged?, not uploaded).
[06:47] <Sarvatt> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/versions-current.html  https://wiki.ubuntu.com/X/PackageNotes
[06:47] <Sarvatt> versions-current grabs it off the package notes wiki
[06:47] <Sarvatt> i think
[06:48] <Sarvatt> ah there we go https://edge.launchpad.net/bugs/589540
[06:48] <ubot4> Launchpad bug 589540 in xserver-xorg-video-r128 (Ubuntu) "Sync xserver-xorg-video-r128 6.8.1-3 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
[07:00] <Sarvatt> jcristau: do you guys want the vmmouse fixes that arent in a released version yet or should we just add patches in ubuntu?
[07:02] <Sarvatt> can't sync that because you guys dont have the fix for https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-vmmouse/+bug/545298 but its in upstream git
[07:02] <ubot4> Launchpad bug 545298 in xserver-xorg-input-vmmouse (Ubuntu Lucid) (and 1 other project) "left mouse button unresponsive when running as VMware server guest (affects: 4)" [High,Fix released]
[07:06] <Sarvatt> bryceh: hmm some packages missing from versions-current? tslib, omapfb?
[07:07] <Sarvatt> tslib one is nasty because xserver specifically breaks the version we have
[07:07] <Sarvatt> oh nevermind its synced already, just  in dep wait
[07:16] <Sarvatt> xinput we can just hold off till the next one which has the fix, 1.5.2 that was just released
[07:19] <Sarvatt> it's important that we have evdev ready ASAP after xserver goes in, is it really a good idea to redo the whole sync process for it again after? just lookedat your evdev sync request
[07:34] <RAOF> Sarvatt: What do you mean?  If we sync evdev now it'll sit nicely in depwait until xserver is built, then work.
[07:35] <Sarvatt> yeah but they just unscribed and asked you to resubscribe after xserver goes in, have to wait for all that to go through :)
[07:36]  * Sarvatt is glad he didnt mention it would be in depwait in all those other syncs
[07:37] <RAOF> Not all of those syncs will depwait.
[07:37] <Sarvatt> well all the drivers will
[07:38] <Sarvatt> *everything* is xserver >= 1.7.6.901 for the xsfbs changes, thats why i had to upload 100+ packages to edgers to update crap
[07:39] <RAOF> Ok.  When I was checking, some didn't dep on that, because they hadn't had the xsfbs change.
[07:39] <Sarvatt> even if you had xserver 1.8.1 before xsfbs still gives you an error saying needs >= 1.7.6.901 if you dont have the new xsfbs
[07:40] <Sarvatt> looks like theres going to be a big round  of lib updates soon for all those locking fixes
[07:40] <RAOF> Hooray!
[07:40] <RAOF> And the dropping of non-xcb, apparently.
[07:41] <Sarvatt> not sure if its frowned upon to update things in unstable at the moment
[07:42] <Sarvatt> a git checkout of vmmouse in unstable would be nice because they are hit by that bug too
[07:42] <Sarvatt> also xproto
[07:42] <Sarvatt> needed for xserver 1.9
[07:43] <Sarvatt> i updated macros xutils-dev, hope I don't get beaten for that :)
[07:44] <RAOF> You could probably pop up in debian-x.  Debian probably don't care about xserver 1.9 in unstable (but would for experimental)
[07:46] <jcristau> what vmmouse fixes?
[07:46] <Sarvatt> only matching event devices
[07:47] <Sarvatt> it was also matching /dev/input/mouse as well and was screwed up in the released one
[07:47] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-vmmouse/+bug/545298 and http://cgit.freedesktop.org/xorg/driver/xf86-input-vmmouse/commit/?id=1d1c0514158abb66388ee4eb44764d201203a863
[07:47] <ubot4> Launchpad bug 545298 in xserver-xorg-input-vmmouse (Ubuntu Lucid) (and 1 other project) "left mouse button unresponsive when running as VMware server guest (affects: 4)" [High,Fix released]
[07:47] <jcristau> k
[07:48] <jcristau> then yeah we'll probably want that
[07:49] <Sarvatt> would it be better to just cherry pick that commit, add it as a patch, or just pull from upstream?
[07:50] <Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-input-vmmouse/
[07:50] <Sarvatt> your two commits + a .gitignore update on top of that fix
[08:18] <jcristau> whichever you prefer
[08:35] <Sarvatt> just test building it before i push it to be sure
[08:38] <Sarvatt> okie :) thanks, starting to get the hang of working on the debian branches
[09:18] <Dr_Jakob> Sarvatt: hmm that looks weird, is that all in the ppa so I can try it out?
[09:20] <Sarvatt> yeah it's all in the ppa, I installed a fresh lucid, added the PPA, did a sudo apt-get update && sudo apt-get dist-upgrade, installed linux-image-2.6-34-5-generic libkms1 and libgl1-mesa-dri-gallium, echo "blacklist vga16fb" | sudo tee /etc/modprobe.d/blacklist-framebuffer.conf && sudo update-initramfs -u -k 'all' and then rebooted and installed the vmware tools and rebooted again
[09:27] <Sarvatt> reinstalled the vmware tools I mean at the end there
[09:27] <Sarvatt> they were already installed from the easy installer, but messed up from the new kernel
[09:28] <Sarvatt> i could send an image if you want too :)
[09:41] <Dr_Jakob> Hmmm
[09:41] <Dr_Jakob> Does it work without the tools?
[09:43] <Sarvatt> didn't try that, lets see
[09:45] <Dr_Jakob> Also does it work without 3D?
[09:45] <Dr_Jakob> That is if you disable 3D in the host?
[09:45] <Sarvatt> yeah it works fine without 3D
[09:46] <Sarvatt> the vmctl message in xorg.0.log says no 2D or 3D or fallback debug but everything else enabled in that situation
[09:46] <Dr_Jakob> Does it say "Using libkms backend"?
[09:46] <Sarvatt> yup
[09:47] <Dr_Jakob> Right thats good
[09:47] <Sarvatt> and dirty and whatever the other one was
[09:47] <Dr_Jakob> Also 2D acceleration will never be enabled even with 3D...
[09:47] <Dr_Jakob> Its more like deacceleration currently :-/
[09:49] <Sarvatt> uninstalling tools didnt make a difference, still like 20 attempts to start hanging right after EXA until it gives up and loads failsafe fbdev
[09:50] <Dr_Jakob> I will take a look sometime next week
[09:50] <Dr_Jakob> At least 2D works, so that we don't complete break things for users...
[09:52] <Sarvatt> hopefully its just a packaging problem or something
[10:06] <Sarvatt> RAOF: merge xserver on monday sound like a plan?
[10:07] <RAOF> I'm already half way there.
[10:08] <Sarvatt> doing it today sounds like a recipe for disaster and probably better to wait for debian and do 1.8.1.901, i'm testing out the experimental build right now
[10:08] <RAOF> Just looking at actually fixing bug #519019 - the patch half-reviewed on xorg-devel (appears to) work.
[10:08] <ubot4> Launchpad bug 519019 in libdbusmenu (Ubuntu) "indicator-applet crashed with SIGSEGV after initial evolution setup (affects: 1) (heat: 10)" [Medium,Fix released] https://launchpad.net/bugs/519019
[10:08] <Sarvatt> just because this *will* break things for many people on a weekend :)
[10:08] <RAOF> Heh. 519049
[10:08] <RAOF> Right.
[10:09] <RAOF> I'd also merged 1.8.1.901
[10:11] <Sarvatt> hmm synaptics needs a few more fixups
[10:12] <RAOF> Works for me™
[10:13] <RAOF> :)
[10:15] <Sarvatt> forgot to add the udev dependency back after the merge :)
[10:21] <Sarvatt> err, crap, sorry! didn't mean to change the changelog that way.
[10:21] <Sarvatt> ah well you gotta change it again to release anyway :)
[10:22] <Sarvatt> so what's your workflow with gbp?
[11:02] <RAOF> git-buildpackage -S; sbuild -d maverick ../whatever
[11:03] <RAOF> It just annoys me when I do that and gbp fails with “why aren't you on master, fool!”
[11:04] <Sarvatt> can't you just export the default?
[11:05] <Sarvatt> (or put it in a local .conf or something)
[11:06] <RAOF> You can, but if you export the default, then when you try building on the debian branch it complains.
[11:07] <RAOF> It's really a per-branch configuration; you can't have it anywhere else and have gbp do the right thing.
[11:07] <Sarvatt> debuild -S instead? :D
[11:10] <RAOF> Well, debuild -S -i, I guess.
[11:12] <Sarvatt> or DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i" in ~/.devscripts
[11:12] <RAOF> Right.
[11:12] <RAOF> I guess since xsf doesn't generally use the interesting parts of git-buildpackage that would work fine.
[11:13] <Sarvatt> yeah thats what threw me off, didn't understand why the gbp outside of nouveau
[11:13] <jcristau> Sarvatt: that and -I for xorg and the app bundles
[11:15] <Sarvatt> well I have DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I.bzr -I.svn -I.git" in mine
[11:15] <jcristau> you could make that -i -I :)
[11:15] <RAOF> Incidentally, why *doesn't* the xsf tend to use the interesting bits of git-buildpackage?  I find it nice and convenient to have everything in the one place.  When it works, of course.
[11:15] <Sarvatt> yeah set that back before I knew that :)
[11:16] <Sarvatt> it looks like it used to
[11:16] <jcristau> RAOF: because it didn't exist when we started using git, and i haven't gotten around to looking at it
[11:16] <RAOF> Fair crack o' the whip
[11:17] <Sarvatt> what features do you want RAOF? i can look into it, was doing that as we speak actually :)
[11:18] <RAOF> Basically, using the upstream-branch + pristine-tar features makes it easier to pick up and work on (or to send to sponsors).  Then you just need to clone the repo and git-buildpackage.
[11:18] <RAOF> No hunting around for the right .orig.tar.gz :)
[11:20] <hyperair> RAOF: there's a per-branch debian/gbp.conf which i've been using for maintaining my crapton of ppas
[11:21] <RAOF> hyperair: Indeed there is - that's what Sarvatt's been asking me about: why I've been adding them when I touch a package :)
[11:21] <hyperair> RAOF: aaah i see.
[11:21] <hyperair> RAOF: but it's only within the VCS isn't it?
[11:22] <RAOF> What do you mean?  It ends up in the source package, because it's in the debian/ directory.  Also, it ends up in everyone's checkouts.
[11:24] <hyperair> RAOF: ah, you didn't add the extra -i =p
[11:25] <hyperair> to builder, i mean
[11:26] <hyperair> if debuild gets -i gbp.conf it'll get rid of gbp.conf for you
[11:26] <RAOF> Well, I guess you could do that.
[11:27] <jcristau> hyperair: it's one more manual step for everyone, for what seems to be a pretty small gain
[11:27] <noobish> came across a build problem while installing x-swat's fglrx package. The dkms make operation fails with 2 errors: 1. include/linux/utsrelease.h does not exist and kernel includes do not match current kernel (they are versioned as "" instead of "2.6.34-020634-generic).
[11:27] <RAOF> I don't think there's any particular reason not to have it in the source package.
[11:27] <noobish> I did not reboot after upgrading the kernel
[11:27] <noobish> is that an easy kill?
[11:28] <RAOF> Last time I tried fglrx didn't build against the more recent kernel.
[11:29] <hyperair> jcristau: it's in the conf. what's manual about it?
[11:29] <RAOF> Which is, I guess, what you're seeing.
[11:29] <noobish> RAOF: I already had to manually edit 2 patch files just to get this far
[11:29] <hyperair> jcristau: but i get what you mean about the small gain part. i think gbp should have it on by default
[11:29] <noobish> and as I recall I had the same error with 2.6.32
[11:31] <noobish> oh, I did reboot after the kernel upgrade. So why would /lib/modules/{kernel}/build/include "not match current kernel"?
[11:37] <RAOF> Black magic.
[11:37] <noobish> this is what I suspected
[11:37] <RAOF> :)
[11:38] <noobish> I will put more garlic strands around the cpu
[11:43] <noobish> well there's a new fglrx build being minted in 6 hours anyway that specifically mentions the arch patch for 2.6.34, so I'll try again in the morning
[13:04] <Sarvatt> so yeah, if anyone wants to clone all of the pkg-xorg stuff - http://sarvatt.com/downloads/graball.sh
[13:04] <Sarvatt> adds the upstream remotes to everything but apps too
[13:05] <Sarvatt> just change USERNAME at the top :D
[13:06] <lucazade> Sarvatt is this correct? http://www.phoronix.com/forums/showpost.php?p=131953&postcount=9
[13:06] <jcristau> it's on phoronix, so probably not
[13:06] <lucazade> lol
[13:06] <Sarvatt> what he said :)
[13:07] <Sarvatt> looks right
[13:07] <Sarvatt> emgd looks to  be iegd
[13:07] <Sarvatt> i've never been able to download iegd but it looks like its called emgd in iegd going by google
[13:08] <lucazade> emgd + gallium3D or + xpsb3D blob?
[13:08] <Sarvatt> no its totally seperate
[13:08] <Sarvatt> iegd/emgd has nothing to do with xpsb
[13:09] <lucazade> ok 
[13:09] <Sarvatt> the 2 branches of psb are xpsb and gallium supporting
[13:09] <lucazade> perfect
[13:09] <lucazade> now is clear
[13:10] <lucazade> emgd will have his 3D support
[13:10] <jcristau> clear is not the word i would have used
[13:10] <lucazade> me too, but my english is poor
[13:11] <Sarvatt> emgd looks like its iegd, just the iegd parts are called iegd for PC devices and emgd for embedded devices not meant to be in netbooks and crap that they ended up getting put in making people suffer :)
[13:11] <lucazade> i'll wait for these marvelous drivers!
[13:12] <Sarvatt> i'm sure they'll be out some day but will need a bunch of reworking for ubuntu's libgl mess
[13:12] <Sarvatt> cus they have to support xserver 1.7 if they are going to support RHEL6 :)
[13:13] <Sarvatt> the IEGD release is supposed to be out this month
[13:14] <Sarvatt> but it might skip xserver 1.7 and go to 1.8 and have 1.7 support later for RHEL, I dunno
[13:14] <Sarvatt> i doubt very much they are gonna make it work with the alternatives crap
[13:14] <Sarvatt> but that'll be easy enough to work around as long as the drivers are out
[13:16] <lucazade> thanks Sarvatt for the info
[13:17] <Sarvatt> the second number in the release version for the "open source" version of the psb driver tells what line its for, 0 for dri1/xpsb 1 for dri2/gallium
[13:17] <Sarvatt> the mrst ones are 3
[13:18] <Sarvatt> like 5.0.xxxxx.x 5.1.xxxxx.x 5.3.xxxxxx.x
[13:18] <lucazade> yep
[13:21] <Sarvatt> man this script takes a *year* to finish :)
[13:22] <Sarvatt> doh, how'd I forget xserver!
[13:22] <Sarvatt> ...and xorg meta
[13:23] <Sarvatt> anyway now to make one to package and upload everything to xorg-edgers
[14:39] <Sarvatt> woo baby, got the monster of all ppa update scripts almost done, updating to 1.9 will be a breeze
[15:28] <Sarvatt> ugh, I'm going to feel like the mozilla/chromium ppa's if i run this regularily :) all protos for 2 distros took about 10 minutes to package and upload in a script
[15:32] <jcristau> bug 496817 should be closed
[15:32] <ubot4> Launchpad bug 496817 in xinput (Ubuntu) "xinput no longer works to set-ptr-feedback after the latest Xserver upgrade in Lucid (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/496817
[15:33] <jcristau> bug 507305 should be moved to the server or evdev
[15:33] <ubot4> Launchpad bug 507305 in xinput (Ubuntu) "Unable to slow mouse sufficiently (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/507305
[15:36] <jcristau> bug 523890 is likely invalid, if the events come from the same kernel device then there's nothing X can do
[15:36] <ubot4> Launchpad bug 523890 in xinput (Ubuntu) "XInput2 not separating Synaptics touchkey events from trackpad & trackpoint (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/523890
[15:37] <jcristau> and bug 529745 should be moved to synaptics
[15:37] <ubot4> Launchpad bug 529745 in xinput (Ubuntu) "[Suggestion] Enable TrackPoint middle scroll by default (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/529745
[18:00] <Sarvatt> do you upload to debian with dput too?
[18:01] <Sarvatt> err, guess thats a silly question, nothing from this script would go anywhere in debian
[18:02] <Sarvatt> almost done making this automatic X packaging script and have it abstract enough that it'll work for debian as well, maybe I'll add a build option and make it do the same as X.Org's build.sh only packaging/installing each thing as it goes
[18:05] <hyperair> Sarvatt: you dput to debian, but your .changes file must be a _<arch>.changes, rather than a _source.changes
[18:05] <hyperair> Sarvatt: because debian sucks and doesn't support source-only uploads.
[18:06] <Sarvatt> I was being a bonehead and thinking debian had other places they could dput :)
[18:06] <hyperair> hey it's entirely possible =p
[18:06] <Sarvatt> (to reuse the PPA upload code)
[18:07] <hyperair> i've heard of some people who have set up mini-buildds
[18:07] <Sarvatt> i woulda been done with this hours ago if i didn't  keep abstracting things away to make it more genericlol
[18:07] <hyperair> which are uploaded to using dput, of course.
[18:07] <hyperair> abstraction is the way to go \o/
[18:07]  * hyperair struggles with his 2.6.35 kernel
[18:07] <hyperair> i've been attempting to compile this for 5 days now.
[18:08] <Sarvatt> https://edge.launchpad.net/~sarvatt/+archive/dumping that was about 3 minutes worth, the code to upload ~dist-1 versions wasn't working but those take like 1/10th the time as the main ones
[18:08] <hyperair> first i run into all kinds of merge conflicts, then compilation errors, then panics.
[18:08] <Sarvatt> hah, whatcha merging?
[18:08] <hyperair> bfs, phc, aufs2, apparmor
[18:08] <hyperair> er what else was there..
[18:09] <Sarvatt> i spent 8 hours compiling a 2.6.35-pre rc1 with gcc-4.5 and -march=atom just to have it have that damn udev bug
[18:09] <hyperair> lol
[18:09] <Sarvatt> and i was stupid and symlinked all the examples from kernel-package so i got all these weird grub entries now
[18:10] <hyperair> lol!
[18:10] <hyperair> i symlinked initramfs and grub
[18:10] <Sarvatt> that worked?
[18:10] <Sarvatt> grub_conf?
[18:10] <hyperair> grub_conf?
[18:10] <hyperair> O-o
[18:10] <Sarvatt> thats what its called here
[18:10] <Sarvatt> what version kernel-package?
[18:11] <hyperair> i called it zz-grub
[18:11] <Sarvatt> 12.033 here
[18:11] <hyperair> eh i copied it not linked it
[18:11] <Sarvatt> was the example called grub_conf I mean?
[18:11] <hyperair> oh i got rid of that
[18:11] <hyperair> i made my own
[18:11] <hyperair> it just has two lines
[18:11] <hyperair> #!/bin/sh
[18:11] <hyperair> exec update-grub
[18:12] <hyperair> =D
[18:12] <hyperair> ah the initramfs one is linked.
[18:12] <Sarvatt> hah
[18:12] <Sarvatt> ok
[18:12] <Sarvatt> thanks for the tips, i never have time to sit down and read that labrynth man page
[18:13] <hyperair> lol
[18:13] <hyperair> i don't even remember what manpage anymore
[18:13] <hyperair> wait, there was a manpage?
[18:13] <Sarvatt> man kernel-package
[18:13] <hyperair> i just took a look at the examples and made my own
[18:13] <hyperair> ah that
[18:13] <Sarvatt> and man kernel-pkg.conf and man kernel-img.conf
[18:14] <hyperair> for some reason, i can't seem to get it to stop poking git when it begins to compile though. results in a crapload of I/O =_=
[18:14] <Sarvatt> lol you compile with ccache on an encrypted home directory dont you?
[18:14] <vish> hmm , how to avoid the udevd bug from the mainline kernel?
[18:14] <hyperair> Sarvatt: on top of btrfs.
[18:14] <Sarvatt> vish: its gone now
[18:14] <hyperair> Sarvatt: which sucks grandly on dm-crypt
[18:14] <vish> Sarvatt: the .35 doesnt have it?
[18:15] <hyperair> Sarvatt: which is why i'm so desperate to get my hands on the new kernel (i've added a patch which gives dm-crypt multicpu capabilities)
[18:15] <Sarvatt> i think it went away mid 2.6.35-rc1?
[18:15] <vish> ah , i was on .34.. yay
[18:15] <hyperair> what udevd bug?
[18:15] <Sarvatt> really though ccache on an encrypted home totally kills the benefits of ccache, probably makes it even worse lol
[18:15] <hyperair> pfft
[18:15] <Sarvatt> it was respawning udev constantly using 100% cpu
[18:16] <hyperair> ccache is still faster when recompiling
[18:16] <Sarvatt> vish: check phoronix i'm sure he posted when it was fixed :)
[18:16] <hyperair> especially since git likes to screw up my time stamps
[18:16]  * vish checks phoronix :)
[18:16] <Sarvatt> what version kernel-package hyperair?
[18:17] <Sarvatt> i dunno if you know but the later 12.xxx ones you dont have to make-kpkg clean
[18:17] <hyperair> Sarvatt: er the one in lucid.
[18:17] <Sarvatt> if it fails or something
[18:17] <hyperair> Sarvatt: and i haven't used make-kpkg clean in a looooooooooooooooooong time.
[18:17] <Sarvatt> ah lol
[18:17] <hyperair> it still generates a crapload of I/O when rebuilding though
[18:17] <hyperair> with the older make-kpkg i used to do rm -rf debian conf.vars
[18:17] <hyperair> that was good enough, and left my .o files in place
[18:19] <hyperair> unfortunately, bumping up the kernel revision that i appended to my kernel version caused make and ccache to go berserk and recompile everything.
[18:57]  * hyperair wonders if Sarvatt is also getting frequent hard-locks with image frozen on screen
[18:58] <Sarvatt> nope
[18:58] <Sarvatt> not frequent at any rate, maybe 2 in a week?
[18:58] <Sarvatt> both times when installing a kernel lol
[18:58] <hyperair> Sarvatt: i'm getting it several times a day >_>
[18:58] <hyperair> maybe i'll downgrade..
[21:15] <Sarvatt> hyperair: hanging with the same image on the screen and the system hard locked up and unresponsive?
[21:15] <hyperair> Sarvatt: yeah, and ping fails too.
[21:20] <Sarvatt> yup same crash i get randomly then :(
[21:24] <hyperair> heh
[21:24] <hyperair> Sarvatt: what's it caused by?
[21:24] <hyperair> Sarvatt: you disabled page flipping, didn't you?
[21:24] <Sarvatt> dang ickle is trying to figure out the reason why intel couldn't start compiz at == max texture size and our silly patch screwed him up :D
[21:24] <Sarvatt> yeah I did but its still happening sometimes too, a crapload less than without the patch
[21:27] <hyperair> hmm i see.
[21:28] <hyperair> finally! my kernel finished compiling!
[21:28]  * hyperair installs
[21:29] <Sarvatt> hyperair: i think i saw a bug about it but i'm really busy at the moment, will try to dig it up in a few
[21:31] <Sarvatt> oh man this is awesome
[21:31] <hyperair> ?
[21:32] <Sarvatt> http://sarvatt.com/downloads/update-ppa.sh
[21:33] <Sarvatt> updates every pkg-xorg package just about, keeps track if theres anything new upstream after the first run and doesn't upload if theres not, builds packages for 2 dists at a time
[21:33] <hyperair> heheh
[21:33] <hyperair> that's cool stuff =p
[21:34] <hyperair> shell scripts win =p
[21:34] <Sarvatt> gotta upload my hooks because they're really different than whats in xorg-pkg-tools
[21:36] <Sarvatt> incoming 100+ updates to xorg-edgers while theres already a huge queue :)
[21:43] <Sarvatt> holyyy crap, that was some amazing timing
[21:44] <Sarvatt> battery died not a minute after i uploaded the script to my server there, it and the backup got zeroed out
[21:47] <hyperair> lol
[21:47] <hyperair> that's nice
[21:47] <hyperair> xD
[23:36] <Sarvatt> RAOF: so can you find anyone to help with the merge fest on monday? we're going to have a ton of people accepting broken upgrades and complaining and none of my sync requests are going through because they want to wait until the server is uploaded...
[23:53] <Sarvatt> took almost an hour to update all video drivers with the script, atom is sloooow
[23:55] <Sarvatt> hmm, stopped updating lucid ones about halfway through