[00:00] <tormod> 7.6 is more stable (in the non-crashing sense) than 7.4 here, finally those radeon lock-ups disappeared
[00:01] <tormod> for instance google-earth was locking up the machine quite often in stock jaunty (and intrepid and...)
[00:02] <Sarvatt> you dont have the radeon_validate_bo assertion problems anymore? alot of other people do
[00:02] <Sarvatt> i guess its ok when you have libdrm-radeon1
[00:03] <tormod> no that got fixed for me (the compiz crasher). the others are playing sauerbraten :)
[00:03] <Sarvatt> http://bugs.freedesktop.org/show_bug.cgi?id=22438
[00:03] <tormod> no I am talking DRI1 here
[00:03] <ubottu> Freedesktop bug 22438 in Drivers/DRI/r300 "radeon_common.c:1016: radeon_validate_bo: Assertion `radeon->state.validated_bo_count < 32' failed." [Major,New]
[00:04] <tormod> last time I tried sauerbraten it could not even start, but that was a few releases back
[00:04] <tormod> and I would take a few assertion crashes over having the machine lock up :)
[00:06] <tormod> lock-ups are probably under-reported. there's usually no log/debug information to find, and many people are used to it from other or older OSes
[00:06] <Sarvatt> tormod: think this is going to fix the osmesa build problems? http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=blobdiff;f=debian/patches/04_osmesa_version.diff;h=68c3db0a3e45f765c466d9c3e1666696e281b6c6;hp=108916c675c448e42478b1dca3aa4da9e87ecba9;hb=ec4c889266934372b158bf54cddb8ea99c82ad8b;hpb=c84a384fdfdbaae61d91f9ba632b1df391dc28af
[00:07] <Sarvatt> (we've been dropping 04_osmesa entirely since the build changes)
[00:07] <tormod> hmm there was an -install option in there?
[00:10] <Sarvatt> looks like it will to me :D if anything i'll add 04_osmesa_version.diff entirely from the debian patch so i can keep using origin/ubuntu because the things built are so different
[00:10] <tormod> this is a patch of a patch... it's hard to read .:)
[00:10] <Sarvatt> in a hook
[00:11] <tormod> well you don't want that 6.5.3 hardcoded
[00:11] <Sarvatt> ahh yeah maybe not looking at the full patch
[00:11] <Sarvatt> (was looking at the patch to the patch too lol)
[00:12] <Sarvatt> how about changing the install to  cd $(DEB_BUILD_DIR)/$* && sleep 5 && $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install
[00:13] <Sarvatt> -j1 didnt work
[00:13] <tormod> seems like that patch is just about refreshing the patch to applu
[00:13] <tormod> *apply
[00:13] <Sarvatt> yeah it is, full thing just changes the version
[00:14] <Sarvatt> i dont know why thats done at all
[00:14] <tormod> I don't think that sleep will help, because everything will run at the same time afterwards
[00:16] <tormod> I just don't get why things run in parallel when using -j1
[00:26] <Sarvatt> jbarnes: Zorael just confirmed the fix worked for him too so thats everyone I spoke to that had the dpms off hangs, good job on that patch and thanks :D
[00:37] <jbarnes> Sarvatt: yay
[00:55]  * maxb chuckles at bryce's xorg/fbdev patch naming :-)
[00:58] <Sarvatt> thats the actual patch name from fedora :D http://cgit.freedesktop.org/xorg/xserver/commit/?id=aef6b904ebf0d7de6259058606c7c04ea177bda3
[01:16] <Sarvatt> bryce, i dont know if it helps any but https://edge.launchpad.net/%7Esarvatt/+archive/bugs/+sourcepub/658955/+listing-archive-extra
[01:36] <bryce> Sarvatt, I *think* I've got the patches all in correctly now
[01:37] <bryce> Sarvatt, I'll review your merge
[01:37] <Sarvatt> the orig.tar.gz is the upstream tarball, 04_osmesa_version.diff is the updated one from debian that was needed
[01:37] <bryce> Sarvatt, are there bugs in launchpad that will be fixed by this upload?  We should probably reference the bugs from the changelog if so
[01:39] <Sarvatt> yeah, quite alot i imagine
[01:40] <Sarvatt> so many fixes between 7.4.1 and 7.4.4
[01:40] <Sarvatt> doesnt help they are attributed to the individual drivers so its hard to look up on launchpad
[01:42] <bryce> yeah
[01:42] <Sarvatt> is it smart enough to close bugs that have the upstream reports linked to fdo bugs?
[01:42] <bryce> no not that smart
[01:42] <bryce> so if those fdo/deb#'s have corresponding lp#'s, we'd need to insert those
[01:46] <bryce> Sarvatt, I can take care of doing this
[01:57] <Sarvatt> if i come up with any i'll let ya know, taking a look around
[02:01] <bryce> ok cool
[02:01] <bryce> I'm going through bugs marked "fixed upstream"
[02:01] <bryce> most were fixed upstream well before 7.4.1 :-.
[02:12] <Sarvatt> if something was reported against jaunty, but fixed in 7.4.1, what should I do? noticed a few fixed already in karmic
[02:15] <Sarvatt> well cant say for sure it was fixed in 7.4.1 for this one actually, would need a backtrace with dbg info, but they added a null pointer check to glXGetFBConfigs() that fixed glxinfo in 7.4.1 https://bugs.edge.launchpad.net/bugs/356832
[02:15] <ubottu> Ubuntu bug 356832 in mesa "[UXA] glxinfo crashed with SIGSEGV in glXGetFBConfigs()" [Medium,Confirmed]
[02:16] <bryce> if it's fixed in karmic, you can close the bug as fixed and we consider it done
[02:17] <bryce> there are rare circumstances where we might do an SRU backport for a fix, like if it is extraordinarily prevalent, extremely serious, and the patch is nearly guaranteed to be regression-free
[02:18] <bryce> however, mesa tends to be a bit fragile, and even innocuous looking patches often prove to have side effects we don't notice until it's rolled out
[02:18] <bryce> what I sometimes do
[02:19] <bryce> I'll mark the bug fixed, but open a Jaunty task, and comment "If anyone feels like filing an SRU on this, the fix looks like it might be backportable, but I haven't plans to do it myself."
[02:20] <bryce> in theory, if we magically got everything fixed in karmic and wanted to put time into doing jaunty backports, we could query for viable backport candidate bugs
[02:24] <Sarvatt> wow quite alot of bugs for that problem actually
[02:28] <Sarvatt> it hits nvidia binary drivers alot, complains about missing glx implementation and segfaults
[02:29] <Sarvatt> http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_4_branch&id=d2f67910629d7f9b00ba127f2e869f02a72306d2
[02:29] <Sarvatt> but its just glxinfo..
[02:29] <bryce> Sarvatt, btw where did you see that debian had 7.4.4 packaged?
[02:30] <bryce> oh yeah I've seen that one before
[02:30] <Sarvatt> debian-unstable
[02:30] <Sarvatt> http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=summary
[02:30] <bryce> if you can confirm that's fixed, you can probably get tons of karma closing all of those bugs ;-)
[02:31] <Sarvatt> would that be something worth SRUing? its just glxinfo but apparently alot of things call glxinfo to check capabilities
[02:31] <bryce> Sarvatt, ok, with the 7.4.4 merge you posted, was that off of debian's stuff, or is it one you merged yourself using the upstream tarball directly?
[02:31] <Sarvatt> i did it from the upstream tarball directly
[02:31] <bryce> I'd need to look at the patch...  if it looks innocuous enough, maybe
[02:31] <bryce> aha ok
[02:32] <Sarvatt> debian builds alot of stuff we dont so i thought it'd be better that way instead of doing it from git and altering everything, did it with the debian from your 1ubuntu4 release
[02:32] <Sarvatt> (thats why i saw 111 wasnt enabled)
[02:33] <bryce> a couple of notes when doing upstream merges,
[02:33] <bryce> for numbering you should use -0ubuntu1, so that if debian puts out a -1 we can upgrade to it
[02:34] <Sarvatt> ah i just bumped it from what it was currently
[02:34] <Sarvatt> was wondering about that
[02:35] <bryce> also, when we take this approach there is one downside, and that is our orig.tar.gz's usually differ, so we end up needing to do fakesyncs after that.  They're not hard, just an extra step
[02:35] <bryce> that's one of the reasons we usually prefer to merge from debian rather than just roll it ourselves
[02:36] <bryce> probably not a big deal here since we're probably going to grab 7.5 soon anyway
[02:40] <bryce> so....
[02:40] <Sarvatt> yeah its the final 7.4 release unless some super major bug hits (like compiz not being able to start was)
[02:40] <Sarvatt> understood though
[02:40] <bryce> I think we should wait until 7.4.4-1 is out officially, and then merge from debian
[02:41] <bryce> we've got plenty of time until alpha-3
[02:43] <bryce> I can roll in your fix for 379797 in the meantime though
[02:56] <bryce> ...uploaded
[03:04] <Sarvatt> shoot, cant upload something for jaunty-proposed to a PPA
[03:04] <Sarvatt> should I just change it to jaunty for the PPA but leave it jaunty-proposed in the debdiff?
[03:05] <bryce> yep
[03:07] <Sarvatt> there are over 25 bugs duped to this one and its such a little safe fix i figured it might be worth the time https://bugs.edge.launchpad.net/bugs/256021
[03:08] <ubottu> Ubuntu bug 256021 in mesa-utils "glxinfo crashed with SIGSEGV in __libc_start_main()" [Medium,Confirmed]
[03:16] <Sarvatt> hits people with nvidia binary drivers installed that arent using nvidia too, compiz and screensavers check glxinfo for support apparently (probably others too) so the segfaults arent as innocuous as i would have thought
[03:22] <bryce> wow
[03:22] <bryce> Sarvatt, are you familiar with the SRU process?
[03:23] <Sarvatt> no, sorry I winged it :(
[03:23] <bryce> there's some paperwork associated with it, I can take care of that for you, unless you'd like to go through it with my guidance?
[03:25] <Sarvatt> it would be useful to know but I can go over the wiki again to see what I missed (guessing subscribing a list to it?) or do I need to become a ubuntu member to do it?
[03:32] <Sarvatt> wow
[03:32] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/257600
[03:32] <ubottu> Ubuntu bug 257600 in mesa "glxinfo crashed with SIGSEGV in __libc_start_main()" [Medium,Fix released]
[03:32] <Sarvatt> theres ANOTHER bug with 31 duplicates thats the same thing
[03:32] <Sarvatt> i thought i was replying in the same bug
[03:33] <Sarvatt> now that was confusing
[03:34] <Sarvatt> shoot! I forgot to add the LP closer to the changelog!
[03:35] <Sarvatt> when adding 2 bugs, (LP #foo) (LP #foo2) or (LP #foo, foo2)?
[03:39] <RAOF> Oh!  I see we have libdrm 2.4.11.  When did that happen?
[03:40] <Sarvatt> month or so ago
[03:40] <Sarvatt> nouveau needs post 2.4.11 stuff though
[03:40] <RAOF> Yeah, I know.
[03:40] <RAOF> But that's a simple patch away.
[03:43] <RAOF> Incidentally, you could undoubtedly use the nouveau-kernel-source package I just pushed to the nouveau-kms PPA to do the same thing for radeon-kms, if you felt like not building entire kernel trees there.
[03:43] <bryce>  (LP: #foo, #foo2) is the right syntax
[03:45] <bryce> Sarvatt, no permissions needed for doing the SRU stuff, it's mainly just writing a report in the description field, to discuss regression potential and stuff
[03:45] <bryce> Sarvatt, https://wiki.ubuntu.com/StableReleaseUpdates has the complete directions
[03:45] <bryce> the 'Procedure' section is the main thing to look at
[03:48] <bryce> Sarvatt, see bug #368049 as an example of how to fill out a bug's description for filing as an SRU
[03:48] <ubottu> Launchpad bug 368049 in mesa "compiz crashes gnome desktop using default ati driver (radeon X600)" [High,Fix released] https://launchpad.net/bugs/368049
[04:06] <RAOF> There we go.  Shiny new nouveau in xorg-edgers.
[04:07]  * Sarvatt cheers
[04:07] <RAOF> With a little backporting of libdrm-nouveau patches, this could happily go in Karmic.
[04:08] <RAOF> (Now that we don't need to replace the whole kernel :))
[04:13] <Sarvatt> dunno why they didnt bump it to 2.4.12 yet, especially with the libdrm-radeon1 changes now too
[04:13] <Sarvatt> it seems the releases are based on intel api updates only :)
[04:29] <bryce> RAOF, kewl
[04:31] <RAOF> bryce: Would you like me to whip up a libdrm revision adding the necessary libdrm-novueau patches in alioth git?
[04:34] <RAOF> Simply pull in 4 git revisions, inculding 2 nouveau.ko interface breaks ;)
[04:38] <Sarvatt> the symbol updates needed are in edgers libdrm too
[04:44] <RAOF> Yeah.
[05:17] <Sarvatt> well thats not pretty http://cgit.freedesktop.org/mesa/mesa
[05:17] <Sarvatt> oh was giving a repository not found error for a second there
[05:18] <Sarvatt> ahh need the trailing / now, my old link stopped working
[05:57] <Sarvatt> RAOF: copied them into edgers too, thought ya uploaded it there :D
[05:57] <Sarvatt> we dont really need the nouveau-kms PPA since you went and did that
[06:00] <Sarvatt> ack nouveau-kernel-source is i386 only? that going to cause problems since it'll pull nouveau-kernel-source from karmic on lpia and x64?
[06:19] <Sarvatt> wow
[06:19] <Sarvatt> Status: 	Currently building
[06:19] <Sarvatt> Queued: 	12 hours ago
[06:19] <Sarvatt> Started: 	12 hours ago
[06:20] <Sarvatt> big difference compared to i386 Finished:  	 8 hours ago  (took 3 hours, 9 minutes, 31.8 seconds) 
=== ripps_ is now known as ripps
[14:01] <hyperair> ohoho .31-rc1 is out =D
[15:04] <walterheck> hello, i am an utter x-noob. I have a feeling x is not picking up my video driver, as xorg.conf seems very empty
[15:05] <walterheck> the section device only has one line in it: Identifier"Configured Video Device"
[15:05] <walterheck> i'm on jaunty and I have an intel X3100
[15:13] <hyperair> Sarvatt: i managed to get the sarvatt5 kernel to work correctly with modesetting.
[15:14] <hyperair> Sarvatt: turns out the offending part was the lines in /etc/initramfs-tools/modules (1915, intel_agp, and one more, which i've forgotten)
[15:14] <hyperair> heheh
=== ccheney` is now known as ccheney
[18:37] <jbarnes> Sarvatt: ouch, package deps don't seem to be tracked properly so my gfx stack got hosed
[19:23] <Sarvatt> jbarnes: what happened?
[19:23] <jbarnes> I updated libgl
[19:23] <jbarnes> which didn't automatically pull in libgl-dri or xserver-xorg-core (for the libdri2.so module)
[19:23] <jbarnes> so dri2 failed to init
[19:26] <Sarvatt> oh you manually tried to install mesa without using the whole PPA?
[19:27] <jbarnes> I used apt
[19:31] <Sarvatt> i dont quite understand, were you using edgers in the first place and an update screwed up? or did you just add it to your sources.list and only tried to install mesa and not do a full apt-get upgrade?
[19:34] <jbarnes> ah that must have been it
[19:34] <jbarnes> I just used install and figured it would take care of things
[19:36] <Sarvatt> ahhh yeah apt-get upgrade would have brought everything in at once, i guess i could start making the depends more strict so that doesnt happen in there
=== jbarnes_PDX is now known as jbarnes_
[19:55] <jbarnes_> Sarvatt: sorry I missed that... my machine hung during dist-upgrade
=== dazjorz_ is now known as dazjorz
[20:43] <Sarvatt> libgl1-mesa-dri is pulled in by a ubuntu metapackage and that gets upgraded right if you just do a apt-get upgrade, some individual mesa things like libgl1-mesa-glx dont depend on it because not everyone wants dri (like non linux arches that debian supports) 
[20:43] <jbarnes> Sarvatt, ok
[20:44] <Sarvatt> you probably just had the old libgl1-mesa-dri hanging around messing things up after that
[20:45] <Sarvatt> woohoo aspire one fan control made it into 2.6.31
[20:45] <Sarvatt> jbarnes: did you get it working now?
[20:45] <jbarnes> yeah I'm back up
[20:45] <jbarnes> with the latest bits + kms
[20:45] <jbarnes> yay
[20:53] <Sarvatt> whoa whats this Building armel build of eglibc 2.10.1-0ubuntu1~ppa6 in ubuntu karmic RELEASE [doko/toolchain] 
[20:53] <Sarvatt> arm supported on PPAs now?? now i just need a darn arm netbook :)
[20:53] <maxb> Sarvatt: doko has a special ppa for testing toolchain builds
[20:53] <bryce> Sarvatt, yeah I noticed that too
[20:54] <Sarvatt>  	Building armel build of thunderbird 2.0.0.22+build1+nobinonly-0ubuntu2~ppa1 in ubuntu karmic RELEASE [mcasadevall/ppa] 
[20:54] <Sarvatt> yeah i know about his toolchain PPA, i use it on all my machines
[21:01] <Sarvatt> hmm well downgrading to mesa 7.4.1 from 7.6 built against dri2proto 2.1 isnt working for me, maybe i need to restart x
[21:03] <jbarnes> Sarvatt: does the current edgers mesa have the memory leak fixes?
[21:03] <Sarvatt> yep!
[21:03] <jbarnes> oh good
[21:03] <jbarnes> we'll see how bad this gets
[21:03] <Sarvatt> i was cherry picking them from 7.5 branch for the few days it wasnt in master even
[21:03] <jbarnes> cool
[21:04] <jbarnes> looks like I'm up to 600+M of gem objects so far though
[21:04] <Sarvatt> wow
[21:05] <Sarvatt> i'm using compiz and i'm at 138MB after 29 hours uptime..
[21:05] <jbarnes> not bad
[21:05] <Sarvatt> that doesnt seem right
[21:05] <Sarvatt> did i not enable compiz lol
[21:06] <Sarvatt> nope compiz is on
[21:06] <Sarvatt> wow thats amazingly low...
[21:06] <jbarnes> my 945 machine is pretty low too
[21:06] <Sarvatt> i usually would be hovering around 500MB
[21:06] <jbarnes> hasn't been up long though
[21:06] <jbarnes> my g45 however... :(
[21:06] <Sarvatt> errr
[21:06] <Sarvatt> robert    6528  0.4  0.9  46628 14312 tty1     S+   Jun23  12:38 metacity --replace
[21:07] <Sarvatt> looks like im not using compiz, no wonder
[21:07] <Sarvatt> DISPLAY=:0 compiz --replace is still running on VT1, guess it fell back to metacity somewhere
[21:08] <jbarnes> I always leave wobbly windows on so I can tell :
[21:08] <jbarnes> :)\
[21:08] <jbarnes> ah typing fail
[21:09] <Sarvatt> would say it must have crashed and fell back to metacity somewhere, but it wouldnt have released the gem objects so i dont think it was ever running. just starting compiz put its over 300mb
[21:14] <Sarvatt> somethings really screwed up on xserver master with compiz
[21:16] <Sarvatt> ahh maybe its http://cgit.freedesktop.org/xorg/xserver/commit/?id=3020b1d43e34fca08cd51f7c7c8ed51497d49ef3 need to update things
[21:22]  * Sarvatt goes back to using mutter instead for GL compositing
[21:32] <Sarvatt> compiz is for sure running now and i have been opening/closing firefox with 15 tabs in a script for 20 minutes -- 158302208 object bytes
[21:35] <Sarvatt> maybe i should do some window wobbling to fill it up :)
[21:36] <Sarvatt> since when do gem objects go down
[21:36] <Sarvatt> turned on wobbly and it dropped 20MB
[21:42] <bryce> huh
[21:43] <Sarvatt> must be part of the memory leak fixes from mesa and i didnt notice it until just now, it never used to go down ever
[21:46] <Sarvatt> actually discarding objects now, hovering around 900
[21:48] <jbarnes> who should I harass about getting openconnect* included in ubuntu?
[21:48] <jbarnes> it's in debian unstable apparently...
[21:50] <Sarvatt> i see a bug requesting it https://bugs.edge.launchpad.net/ubuntu/+source/openconnect/+bug/388026
[21:50] <ubottu> Ubuntu bug 388026 in openconnect "Need package for openconnect VPN client" [Undecided,New]
[21:52] <jbarnes> ah cool
[21:53] <Sarvatt> wait
[21:53] <Sarvatt> robert@ubuntu-9{/opt/source/xorg-pkg-tools}:aptitude search openconnect
[21:53] <Sarvatt> p   openconnect                                                   - Open client for Cisco AnyConnect VPN   
[21:53] <jbarnes> need networkmanager-openconnect too
[21:53] <Sarvatt> ahh
[21:53] <Sarvatt> openconnect (0.98-2) unstable; urgency=low
[21:53] <Sarvatt>   * Disable the GTK+ UI, so that Network Manager support works.
[21:54] <jbarnes> hah
[21:54] <Sarvatt> it has network manager support with it
[21:54] <Sarvatt> 2.01 in karmic
[21:55] <Sarvatt> just grabbed the source
[21:55] <Sarvatt>         mkdir --parents $(DEB_DESTDIR)/usr/lib/NetworkManager
[21:55] <Sarvatt>         mv $(DEB_DESTDIR)/usr/libexec/nm-openconnect-auth-dialog $(DEB_DESTDIR)/usr/lib/NetworkManager
[21:55] <Sarvatt> are you using jaunty?
[21:55] <jbarnes> karmic
[21:56] <Sarvatt> # We don't enable the GTK+ UI because it conflicts with Network Manager.  If
[21:56] <Sarvatt> # this turns out to be a problem in the future so we'll have to build two
[21:56] <Sarvatt> # packages I guess.
[21:56] <jbarnes> I'll try it out
[23:50] <Sarvatt> anyone have nvidia binary drivers compiling under 2.6.31-rc1?
[23:53] <Sarvatt> ah found a patch but nvnews forums are taking a year to load
[23:57] <bryce> Sarvatt, they won't compile until Nvidia puts out new drivers 
[23:57] <bryce> or at least, they won't work
[23:57] <bryce> same with fglrx
[23:58] <bryce> has 2.6.31* been uploaded to karmic now?
[23:59] <Sarvatt> theres a patch to fix it that people have working, went through the same deal when i was using 2.6.30-rc1 that took awhile to get into the official drivers
[23:59] <Sarvatt> nope not yet, guessing it wont be for awhile since so many drivers fail to build against it now