[00:22] <bryce> git clone git://git.freedesktop.org/git/xorg/driver/xf86-video-ati
[01:02] <Q-FUNK> bryce: howdy
[01:03] <bryce> heya
[01:08] <Q-FUNK> bryce: for intrepid, simply syncing -nsc and -geode from debian should do it.  since tonight, we have what we need there.
[01:09] <Q-FUNK> (as long as intrepid's -video-all depends on geode, instead of amd)
[01:10] <Q-FUNK> fixing hardy still remains an issue.
[01:13] <Q-FUNK> my PPA has backports in the build queue, but getting them admitted as SRU might be an issue.
[10:48] <mvo> tjaalton: do you have any snapshot of current drm/mesa? I was told it supports r500 now pretty well and I'm curious to try it
[13:12] <tjaalton> mvo: no I haven't managed to package those yet, but promised to have a look later today
[13:12] <mvo> ok, cool
[13:14] <tjaalton> actually, debian-experimental has drm-snapshot, and mesa 7.1rc1 if you are impatient ;)
[13:14] <mvo> hm, that sounds promising
[13:16] <tjaalton> I've got xorg-server halfway done, but it requires the new mesa which in turn requires newer drm..
[13:19] <mvo> where do you usually put that stuff, in your ppa? or is there a x-force ppa?
[13:27] <tjaalton> mvo: both exist, but so far I've just uploaded to the distribution. this time might be different though, since the new stable drm (which should be enough for r5xx) is not released yet etc
[13:44] <tjaalton> hum, maybe I should by upgrading my other laptop to intrepid
[13:44] <tjaalton> +start
[13:50] <tjaalton> ouch, 1h40min
[13:56] <tseliot> tjaalton: did you try the driver?
[14:02] <tjaalton> tseliot: no, not yet
[14:06] <tjaalton> tseliot: where was it again?
[14:07] <mvo> tjaalton: if you do that, make sure to install findutils first before you do the upgrade
[14:07] <mvo> (install/upgrade findutils)
[14:08] <tjaalton> mvo: oh, thanks for the hint :)
[14:08] <tseliot> tjaalton: the PPA is here: https://launchpad.net/~lrm-intrepid/+archive
[14:12] <mvo> (bug #234345
[14:12] <ubottu> Launchpad bug 234345 in findutils "xargs: xargs.c:443: main: Assertion `bc_ctl.arg_max <= (131072-2048)' failed." [Critical,Confirmed] https://launchpad.net/bugs/234345
[14:15] <tjaalton> mvo: oh that one..
[14:15] <mvo> yeah, we have a workaround but its not yet in intrepid
[14:15] <tjaalton> tseliot: hmm, misleading team name, since nvidia is not in lrm anymore :)
[14:16] <tseliot> tjaalton: its name will remind us of the good old times :-P
[14:18] <tjaalton> tseliot: the diff looks strange. the whole changelog should be there, right?
[14:18] <tjaalton> oh, sorry..
[14:18] <tjaalton> debian.binary
[14:19] <tseliot> Mario says that it works for him
[14:20] <tjaalton> cool
[14:22] <tjaalton> the resulting nvidia-glx doesn't seemt to have an epoch, so what about if you should upgrade the old package which had an epoch?
[14:26] <tjaalton> hmm, maybe I missed something
[14:28] <tjaalton> yep, they are there
[14:29] <tseliot> the current package is epoched
[14:32] <tseliot> have a look at the debian/rules
[14:33] <tjaalton> yes, saw that
[14:46] <tjaalton> I have to try it on my home desktop, since the test machine at work is not powered on
[14:47] <tjaalton> and that needs to wait a couple of hours due to a birthday party :/
[14:47] <tjaalton> so, ->
[14:48] <tseliot> ok
[17:14] <bdmurray> tjaalton: it looks to me like bug 185311 might be fixed in debian and I've just added that bug watch
[17:15] <ubottu> Launchpad bug 185311 in libxcb "hardy, locking assertion failure, xorg/libsdl" [High,Confirmed] https://launchpad.net/bugs/185311
[17:50] <pwnguin> tjaalton: should I close bug #236696?
[17:50] <ubottu> Launchpad bug 236696 in wacom-tools "Please merge wacom-tools from latest Debian unstable" [Undecided,New] https://launchpad.net/bugs/236696
[18:53] <tjaalton> bdmurray: yes, it should be closed. sloppy locking was on by default already on hardy, but somehow that bug went unnoticed..
[18:54] <tjaalton> pwnguin: sure go ahead, I forgot to add the bug closure
[18:58] <tjaalton> bdmurray: umm ok, I've actually forwarded that one upstream, and they've made a set of patches which would make libxcb to never use locking, but it's not applied to master yet
[18:58] <tjaalton> but sloppy locking should work in the meantime
[19:03] <bdmurray> tjaalton: okay, any there any test packages available?
[19:04] <tjaalton> bdmurray: not that I know of..
[19:09] <tjaalton> bdmurray: just to be clear; seems that sloppy locking doesn't work around every situation, since people still seem to get them with certain apps
[19:10] <pwnguin> hence the term sloppy...
[19:12] <tjaalton> heh, right
[21:07] <bryce> heya
=== solarion is now known as Solarion
[22:48] <tjaalton> hey bryce 
[23:05] <bryce> tjaalton: hey btw what is the reason for removing lesstif-dev as a dependency for mesa, vs. MIRing lesstif to main?
[23:06] <pwnguin> hmm. its not good when the kernel guys are happy that their build fails
[23:06] <bryce> (I just want to make sure the rationale is listed in the changelog)
[23:06] <tjaalton> bryce: lesstif isn't wanted in main..
[23:07] <bryce> tjaalton: just because it's ugly&big, or other reasons?
[23:07] <tjaalton> security risk of some sort I guess
[23:08] <tjaalton> well, "risk" meaning "work"
[23:08] <bryce> ok cool
[23:08] <pwnguin> http://www.ohloh.net/projects/273
[23:08] <pwnguin> "small team"
[23:08] <bryce> kees: offhand do you know what the security concerns are around lesstif?  (If not, that's fine, I'll just list it as 'security concerns' for now)
[23:08] <bryce> heya pwnguin
[23:09] <bryce> pwnguin: heh.  of course, such could be said about nearly any of the X11 libs ;-)
[23:10] <bryce> tjaalton: also, are the GLw libs disabled in mesa due to lesstif-dev dependence, or are there other reasons?
[23:10] <pwnguin> the last release of lesstif was 2 years ago
[23:10] <tjaalton> bryce: because of that
[23:11] <kees> bryce: off hand, it's just that it's a large code base without much active development
[23:11] <bryce> excellent, thanks everyone
[23:11] <bryce>     - Drop lesstif-dev from Build-Depends since it's a universe component
[23:11] <bryce>       that Ubuntu doesn't want in main due to security concerns about it
[23:11] <bryce>       (it's a large codebase without active development - last release >2
[23:11] <bryce>       yrs ago).
[23:23] <tjaalton> bryce: merging mesa? I'm weeding out all the unnecessary patches from xserver 1.5.. gonna take a while
[23:40] <bryce> ok
[23:41] <bryce> yeah I'm not merging new mesa, just updating us to debian
[23:42] <bryce> I might have a go at updating xorg after that.  Was looking at it last night.
[23:53] <tormod> it's a lot of fun all of these mesa/xserver changes... :) I pushed the xorg-edgers repo to 7.1RC and 1.5, but gave up xserver master for a while.
[23:55] <tormod> and now launchpad went down some seconds before the 45minutes mesa build finished... wonder if it's "frozen" or must be restarted