/srv/irclogs.ubuntu.com/2009/06/25/#ubuntu-x.txt

tormod7.6 is more stable (in the non-crashing sense) than 7.4 here, finally those radeon lock-ups disappeared00:00
tormodfor instance google-earth was locking up the machine quite often in stock jaunty (and intrepid and...)00:01
Sarvattyou dont have the radeon_validate_bo assertion problems anymore? alot of other people do00:02
Sarvatti guess its ok when you have libdrm-radeon100:02
tormodno that got fixed for me (the compiz crasher). the others are playing sauerbraten :)00:03
Sarvatthttp://bugs.freedesktop.org/show_bug.cgi?id=2243800:03
tormodno I am talking DRI1 here00:03
ubottuFreedesktop bug 22438 in Drivers/DRI/r300 "radeon_common.c:1016: radeon_validate_bo: Assertion `radeon->state.validated_bo_count < 32' failed." [Major,New]00:03
tormodlast time I tried sauerbraten it could not even start, but that was a few releases back00:04
tormodand I would take a few assertion crashes over having the machine lock up :)00:04
tormodlock-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 OSes00:06
Sarvatttormod: 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=c84a384fdfdbaae61d91f9ba632b1df391dc28af00:06
Sarvatt(we've been dropping 04_osmesa entirely since the build changes)00:07
tormodhmm there was an -install option in there?00:07
Sarvattlooks 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 different00:10
tormodthis is a patch of a patch... it's hard to read .:)00:10
Sarvattin a hook00:10
tormodwell you don't want that 6.5.3 hardcoded00:11
Sarvattahh yeah maybe not looking at the full patch00:11
Sarvatt(was looking at the patch to the patch too lol)00:11
Sarvatthow about changing the install to  cd $(DEB_BUILD_DIR)/$* && sleep 5 && $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install00:12
Sarvatt-j1 didnt work00:13
tormodseems like that patch is just about refreshing the patch to applu00:13
tormod*apply00:13
Sarvattyeah it is, full thing just changes the version00:13
Sarvatti dont know why thats done at all00:14
tormodI don't think that sleep will help, because everything will run at the same time afterwards00:14
tormodI just don't get why things run in parallel when using -j100:16
Sarvattjbarnes: 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 :D00:26
jbarnesSarvatt: yay00:37
* maxb chuckles at bryce's xorg/fbdev patch naming :-)00:55
Sarvattthats the actual patch name from fedora :D http://cgit.freedesktop.org/xorg/xserver/commit/?id=aef6b904ebf0d7de6259058606c7c04ea177bda300:58
Sarvattbryce, i dont know if it helps any but https://edge.launchpad.net/%7Esarvatt/+archive/bugs/+sourcepub/658955/+listing-archive-extra01:16
bryceSarvatt, I *think* I've got the patches all in correctly now01:36
bryceSarvatt, I'll review your merge01:37
Sarvattthe orig.tar.gz is the upstream tarball, 04_osmesa_version.diff is the updated one from debian that was needed01:37
bryceSarvatt, are there bugs in launchpad that will be fixed by this upload?  We should probably reference the bugs from the changelog if so01:37
Sarvattyeah, quite alot i imagine01:39
Sarvattso many fixes between 7.4.1 and 7.4.401:40
Sarvattdoesnt help they are attributed to the individual drivers so its hard to look up on launchpad01:40
bryceyeah01:42
Sarvattis it smart enough to close bugs that have the upstream reports linked to fdo bugs?01:42
bryceno not that smart01:42
bryceso if those fdo/deb#'s have corresponding lp#'s, we'd need to insert those01:42
bryceSarvatt, I can take care of doing this01:46
Sarvattif i come up with any i'll let ya know, taking a look around01:57
bryceok cool02:01
bryceI'm going through bugs marked "fixed upstream"02:01
brycemost were fixed upstream well before 7.4.1 :-.02:01
Sarvattif something was reported against jaunty, but fixed in 7.4.1, what should I do? noticed a few fixed already in karmic02:12
Sarvattwell 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/35683202:15
ubottuUbuntu bug 356832 in mesa "[UXA] glxinfo crashed with SIGSEGV in glXGetFBConfigs()" [Medium,Confirmed]02:15
bryceif it's fixed in karmic, you can close the bug as fixed and we consider it done02:16
brycethere 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-free02:17
brycehowever, 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 out02:18
brycewhat I sometimes do02:18
bryceI'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:19
brycein 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 bugs02:20
Sarvattwow quite alot of bugs for that problem actually02:24
Sarvattit hits nvidia binary drivers alot, complains about missing glx implementation and segfaults02:28
Sarvatthttp://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_4_branch&id=d2f67910629d7f9b00ba127f2e869f02a72306d202:29
Sarvattbut its just glxinfo..02:29
bryceSarvatt, btw where did you see that debian had 7.4.4 packaged?02:29
bryceoh yeah I've seen that one before02:30
Sarvattdebian-unstable02:30
Sarvatthttp://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=summary02:30
bryceif you can confirm that's fixed, you can probably get tons of karma closing all of those bugs ;-)02:30
Sarvattwould that be something worth SRUing? its just glxinfo but apparently alot of things call glxinfo to check capabilities02:31
bryceSarvatt, 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
Sarvatti did it from the upstream tarball directly02:31
bryceI'd need to look at the patch...  if it looks innocuous enough, maybe02:31
bryceaha ok02:31
Sarvattdebian 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 release02:32
Sarvatt(thats why i saw 111 wasnt enabled)02:32
brycea couple of notes when doing upstream merges,02:33
brycefor numbering you should use -0ubuntu1, so that if debian puts out a -1 we can upgrade to it02:33
Sarvattah i just bumped it from what it was currently02:34
Sarvattwas wondering about that02:34
brycealso, 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 step02:35
brycethat's one of the reasons we usually prefer to merge from debian rather than just roll it ourselves02:35
bryceprobably not a big deal here since we're probably going to grab 7.5 soon anyway02:36
bryceso....02:40
Sarvattyeah its the final 7.4 release unless some super major bug hits (like compiz not being able to start was)02:40
Sarvattunderstood though02:40
bryceI think we should wait until 7.4.4-1 is out officially, and then merge from debian02:40
brycewe've got plenty of time until alpha-302:41
bryceI can roll in your fix for 379797 in the meantime though02:43
bryce...uploaded02:56
Sarvattshoot, cant upload something for jaunty-proposed to a PPA03:04
Sarvattshould I just change it to jaunty for the PPA but leave it jaunty-proposed in the debdiff?03:04
bryceyep03:05
Sarvattthere 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/25602103:07
ubottuUbuntu bug 256021 in mesa-utils "glxinfo crashed with SIGSEGV in __libc_start_main()" [Medium,Confirmed]03:08
Sarvatthits 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 thought03:16
brycewow03:22
bryceSarvatt, are you familiar with the SRU process?03:22
Sarvattno, sorry I winged it :(03:23
brycethere'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:23
Sarvattit 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:25
Sarvattwow03:32
Sarvatthttps://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/25760003:32
ubottuUbuntu bug 257600 in mesa "glxinfo crashed with SIGSEGV in __libc_start_main()" [Medium,Fix released]03:32
Sarvatttheres ANOTHER bug with 31 duplicates thats the same thing03:32
Sarvatti thought i was replying in the same bug03:32
Sarvattnow that was confusing03:33
Sarvattshoot! I forgot to add the LP closer to the changelog!03:34
Sarvattwhen adding 2 bugs, (LP #foo) (LP #foo2) or (LP #foo, foo2)?03:35
RAOFOh!  I see we have libdrm 2.4.11.  When did that happen?03:39
Sarvattmonth or so ago03:40
Sarvattnouveau needs post 2.4.11 stuff though03:40
RAOFYeah, I know.03:40
RAOFBut that's a simple patch away.03:40
RAOFIncidentally, 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 syntax03:43
bryceSarvatt, no permissions needed for doing the SRU stuff, it's mainly just writing a report in the description field, to discuss regression potential and stuff03:45
bryceSarvatt, https://wiki.ubuntu.com/StableReleaseUpdates has the complete directions03:45
brycethe 'Procedure' section is the main thing to look at03:45
bryceSarvatt, see bug #368049 as an example of how to fill out a bug's description for filing as an SRU03:48
ubottuLaunchpad bug 368049 in mesa "compiz crashes gnome desktop using default ati driver (radeon X600)" [High,Fix released] https://launchpad.net/bugs/36804903:48
RAOFThere we go.  Shiny new nouveau in xorg-edgers.04:06
* Sarvatt cheers04:07
RAOFWith a little backporting of libdrm-nouveau patches, this could happily go in Karmic.04:07
RAOF(Now that we don't need to replace the whole kernel :))04:08
Sarvattdunno why they didnt bump it to 2.4.12 yet, especially with the libdrm-radeon1 changes now too04:13
Sarvattit seems the releases are based on intel api updates only :)04:13
bryceRAOF, kewl04:29
RAOFbryce: Would you like me to whip up a libdrm revision adding the necessary libdrm-novueau patches in alioth git?04:31
RAOFSimply pull in 4 git revisions, inculding 2 nouveau.ko interface breaks ;)04:34
Sarvattthe symbol updates needed are in edgers libdrm too04:38
RAOFYeah.04:44
Sarvattwell thats not pretty http://cgit.freedesktop.org/mesa/mesa05:17
Sarvattoh was giving a repository not found error for a second there05:17
Sarvattahh need the trailing / now, my old link stopped working05:18
SarvattRAOF: copied them into edgers too, thought ya uploaded it there :D05:57
Sarvattwe dont really need the nouveau-kms PPA since you went and did that05:57
Sarvattack 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:00
Sarvattwow06:19
SarvattStatus: Currently building06:19
SarvattQueued: 12 hours ago06:19
SarvattStarted: 12 hours ago06:19
Sarvattbig difference compared to i386 Finished:   8 hours ago  (took 3 hours, 9 minutes, 31.8 seconds) 06:20
=== ripps_ is now known as ripps
hyperairohoho .31-rc1 is out =D14:01
walterheckhello, i am an utter x-noob. I have a feeling x is not picking up my video driver, as xorg.conf seems very empty15:04
walterheckthe section device only has one line in it: Identifier"Configured Video Device"15:05
walterhecki'm on jaunty and I have an intel X310015:05
hyperairSarvatt: i managed to get the sarvatt5 kernel to work correctly with modesetting.15:13
hyperairSarvatt: 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
hyperairheheh15:14
=== ccheney` is now known as ccheney
jbarnesSarvatt: ouch, package deps don't seem to be tracked properly so my gfx stack got hosed18:37
Sarvattjbarnes: what happened?19:23
jbarnesI updated libgl19:23
jbarneswhich didn't automatically pull in libgl-dri or xserver-xorg-core (for the libdri2.so module)19:23
jbarnesso dri2 failed to init19:23
Sarvattoh you manually tried to install mesa without using the whole PPA?19:26
jbarnesI used apt19:27
Sarvatti 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:31
jbarnesah that must have been it19:34
jbarnesI just used install and figured it would take care of things19:34
Sarvattahhh 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 there19:36
=== jbarnes_PDX is now known as jbarnes_
jbarnes_Sarvatt: sorry I missed that... my machine hung during dist-upgrade19:55
=== dazjorz_ is now known as dazjorz
Sarvattlibgl1-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
jbarnesSarvatt, ok20:43
Sarvattyou probably just had the old libgl1-mesa-dri hanging around messing things up after that20:44
Sarvattwoohoo aspire one fan control made it into 2.6.3120:45
Sarvattjbarnes: did you get it working now?20:45
jbarnesyeah I'm back up20:45
jbarneswith the latest bits + kms20:45
jbarnesyay20:45
Sarvattwhoa whats this Building armel build of eglibc 2.10.1-0ubuntu1~ppa6 in ubuntu karmic RELEASE [doko/toolchain] 20:53
Sarvattarm supported on PPAs now?? now i just need a darn arm netbook :)20:53
maxbSarvatt: doko has a special ppa for testing toolchain builds20:53
bryceSarvatt, yeah I noticed that too20:53
Sarvatt Building armel build of thunderbird 2.0.0.22+build1+nobinonly-0ubuntu2~ppa1 in ubuntu karmic RELEASE [mcasadevall/ppa] 20:54
Sarvattyeah i know about his toolchain PPA, i use it on all my machines20:54
Sarvatthmm well downgrading to mesa 7.4.1 from 7.6 built against dri2proto 2.1 isnt working for me, maybe i need to restart x21:01
jbarnesSarvatt: does the current edgers mesa have the memory leak fixes?21:03
Sarvattyep!21:03
jbarnesoh good21:03
jbarneswe'll see how bad this gets21:03
Sarvatti was cherry picking them from 7.5 branch for the few days it wasnt in master even21:03
jbarnescool21:03
jbarneslooks like I'm up to 600+M of gem objects so far though21:04
Sarvattwow21:04
Sarvatti'm using compiz and i'm at 138MB after 29 hours uptime..21:05
jbarnesnot bad21:05
Sarvattthat doesnt seem right21:05
Sarvattdid i not enable compiz lol21:05
Sarvattnope compiz is on21:06
Sarvattwow thats amazingly low...21:06
jbarnesmy 945 machine is pretty low too21:06
Sarvatti usually would be hovering around 500MB21:06
jbarneshasn't been up long though21:06
jbarnesmy g45 however... :(21:06
Sarvatterrr21:06
Sarvattrobert    6528  0.4  0.9  46628 14312 tty1     S+   Jun23  12:38 metacity --replace21:06
Sarvattlooks like im not using compiz, no wonder21:07
SarvattDISPLAY=:0 compiz --replace is still running on VT1, guess it fell back to metacity somewhere21:07
jbarnesI always leave wobbly windows on so I can tell :21:08
jbarnes:)\21:08
jbarnesah typing fail21:08
Sarvattwould 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 300mb21:09
Sarvattsomethings really screwed up on xserver master with compiz21:14
Sarvattahh maybe its http://cgit.freedesktop.org/xorg/xserver/commit/?id=3020b1d43e34fca08cd51f7c7c8ed51497d49ef3 need to update things21:16
* Sarvatt goes back to using mutter instead for GL compositing21:22
Sarvattcompiz is for sure running now and i have been opening/closing firefox with 15 tabs in a script for 20 minutes -- 158302208 object bytes21:32
Sarvattmaybe i should do some window wobbling to fill it up :)21:35
Sarvattsince when do gem objects go down21:36
Sarvattturned on wobbly and it dropped 20MB21:36
brycehuh21:42
Sarvattmust be part of the memory leak fixes from mesa and i didnt notice it until just now, it never used to go down ever21:43
Sarvattactually discarding objects now, hovering around 90021:46
jbarneswho should I harass about getting openconnect* included in ubuntu?21:48
jbarnesit's in debian unstable apparently...21:48
Sarvatti see a bug requesting it https://bugs.edge.launchpad.net/ubuntu/+source/openconnect/+bug/38802621:50
ubottuUbuntu bug 388026 in openconnect "Need package for openconnect VPN client" [Undecided,New]21:50
jbarnesah cool21:52
Sarvattwait21:53
Sarvattrobert@ubuntu-9{/opt/source/xorg-pkg-tools}:aptitude search openconnect21:53
Sarvattp   openconnect                                                   - Open client for Cisco AnyConnect VPN   21:53
jbarnesneed networkmanager-openconnect too21:53
Sarvattahh21:53
Sarvattopenconnect (0.98-2) unstable; urgency=low21:53
Sarvatt  * Disable the GTK+ UI, so that Network Manager support works.21:53
jbarneshah21:54
Sarvattit has network manager support with it21:54
Sarvatt2.01 in karmic21:54
Sarvattjust grabbed the source21:55
Sarvatt        mkdir --parents $(DEB_DESTDIR)/usr/lib/NetworkManager21:55
Sarvatt        mv $(DEB_DESTDIR)/usr/libexec/nm-openconnect-auth-dialog $(DEB_DESTDIR)/usr/lib/NetworkManager21:55
Sarvattare you using jaunty?21:55
jbarneskarmic21:55
Sarvatt# We don't enable the GTK+ UI because it conflicts with Network Manager.  If21:56
Sarvatt# this turns out to be a problem in the future so we'll have to build two21:56
Sarvatt# packages I guess.21:56
jbarnesI'll try it out21:56
Sarvattanyone have nvidia binary drivers compiling under 2.6.31-rc1?23:50
Sarvattah found a patch but nvnews forums are taking a year to load23:53
bryceSarvatt, they won't compile until Nvidia puts out new drivers 23:57
bryceor at least, they won't work23:57
brycesame with fglrx23:57
brycehas 2.6.31* been uploaded to karmic now?23:58
Sarvatttheres 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 drivers23:59
Sarvattnope not yet, guessing it wont be for awhile since so many drivers fail to build against it now23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!