[02:15] <bryce> anyone know if/when debian will be packaging mesa 7.1rc1?
[02:16] <bryce> aha, deb Bug#465554
[02:17] <bryce> "The mesa master branch is
[02:17] <bryce> probably still too much of a moving target now for us to spend too much
[02:17] <bryce> time on it."
[07:38] <tjaalton> hmm, tseliot not here
[07:44] <tjaalton> I think it would be wise to base the split nvidia* on the debian versions, and just maintain a diff with DKMS and stuff
[07:45] <tjaalton> and scrap the old LRM baggage completely
[07:53] <bryce> wow
[07:55] <tjaalton> hm?
[07:56] <bryce> oh just that this would be a pretty profound change
[07:56] <tjaalton> well, it's split anyway
[07:56] <tjaalton> and the original version is from debian
[07:57] <tjaalton> and diverged _a_lot_ since :)
[07:57] <bryce> ah
[07:58] <bryce> hey, it's sounding like gem won't be ready for intrepid, according to yong
[07:58] <tjaalton> surprise
[08:03] <tjaalton> hm, if we could persuade the debian nvidia maintainers to accept our patches, then debian could use jockey too
[08:03] <tjaalton> currently it's not there
[08:04] <tjaalton> i mean jockey not in debian
[09:13] <tjaalton> tseliot: hi, I've looked at your packages and I have a suggestion :)
[09:13] <tseliot> tjaalton: shoot
[09:13] <tjaalton> tseliot: scrap everything, and build our diff on top of the debian packages
[09:13] <tjaalton> for various reasons
[09:14] <tseliot> ﻿tjaalton: ok but they use the nvidia-kernel package
[09:14] <tjaalton> we can comment that out
[09:14] <tjaalton> non-issue
[09:16] <tjaalton> they might be interested in DKMS btw
[09:16] <tseliot> tjaalton: are we going to keep the nvidia-glx-ia32 for 64bit?
[09:16] <tjaalton> and jockey, although it would have to be installed by default to be useful
[09:16] <tjaalton> don't know yet
[09:17] <tseliot> so you're suggesting that we try to contribute upstream
[09:17] <tjaalton> we can filter whatever doesn't suit us
[09:17] <tjaalton> yes
[09:17] <tjaalton> they have the same bugs :)
[09:17] <tseliot> not a bad idea ;)
[09:17] <tjaalton> upstream being debian
[09:17] <tseliot> of course
[09:18] <tjaalton> they have a group on alioth, and a mailing list
[09:18] <tseliot> I will keep the nvidia-modaliases packages though
[09:18] <tjaalton> sure
[09:19] <tjaalton> also, it might be nice to include the old changelog as changelog.Ubuntu.old or something
[09:19] <tseliot> this wouldn't be a problem
[09:21] <tjaalton> I don't understand what the -ia32 packages are for
[09:21] <tseliot> we'll have to deal with the diversions created by both the Ubuntu lrm and the lrm-envy
[09:21] <tseliot> tjaalton: the 32bit compatibility libraries for 64bit systems
[09:21] <tjaalton> well, I don't see a /emul dir on my system
[09:22] <tseliot> we don't have that package in Ubuntu
[09:22] <tseliot> we package those libraries differently
[09:22] <tjaalton> right, in /usr/lib32
[09:22] <tseliot> exactly
[09:24] <tseliot> the only problem which I see with taking the packages from debian (other than the effort itself) is that I don't know if they miss some library, etc. with respect to the packages which I made for envy
[09:25] <tjaalton> dpkg -c will tell
[09:26] <tseliot> mmm...
[09:26] <tjaalton> at least they include cuda
[09:26] <tseliot> and so do I
[09:27] <tjaalton> lrm doesn't
[09:27] <tjaalton> trust me, it'll pay off :)
[09:28] <tseliot> I added the support for CUDA to my packages and a number of people depend on me for CUDA.
[09:28] <tjaalton> funny that there are no bugs about adding that to lrm
[09:29] <tseliot> the packages which I gave to you are in fact based on my lrm-envy
[09:29] <tjaalton> since I didn't notice there was such a beast
[09:29] <tjaalton> so lrm not having cuda was not intentional
[09:29] <tseliot> tjaalton: it was reported in some other bug. I should have reported the problem myself
[09:29] <tseliot> with a patch
[09:30] <tseliot> but I have bad memory
[09:30] <tjaalton> bygones
[09:30] <bryce> ahhh internet back
[09:31] <tseliot> bryce: congrats :-P
[09:32] <tseliot> tjaalton: did you have a look at the nvidia/debian.binary of the debian package?
[09:32] <tjaalton> tseliot: yes, it's newer
[09:33] <tseliot> devfs.devices?
[09:33] <tjaalton> as you see, the lrm version is based on an old debian version
[09:34] <tjaalton> doesn't seem to be used at all
[09:35] <tjaalton> so it doesn't matter
[09:36] <tseliot> did  you see the nvidia-glx.init?
[09:37] <tseliot> porting it to Ubuntu and adding DKMS might not be a problem but I'm not sure about the effort to maintain something which I don't know
[09:37] <tseliot> enough
[09:37] <tseliot> (which I don't know enough)
[09:38] <tseliot> tjaalton: do you see my point?
[09:38] <tjaalton> just don't use what doesn't concern us
[09:39] <tjaalton> the initscript seems like a good example.. messing with the links
[09:39] <tjaalton> er, no?
[09:39] <tseliot> and how do I know what doesn't concern us ;) ?
[09:39] <tjaalton> by auditing the package and testing things :)
[09:39] <tseliot> that's what worries me most...
[09:41] <tseliot> :-/
[09:41] <tjaalton> bah, it's a walk in the park
[09:41] <tjaalton> +like
[09:42] <tseliot> a park filled with serial-killers... :-P
[09:43] <tjaalton> heh
[09:44] <tjaalton> I'll do a preliminary merge with 169.12
[09:45] <tseliot> to tell the truth I used to deal with the debian nvidia-glx packages for envy legacy but they have changed so much...
[09:46] <tseliot> wait will this replace the nvidia-glx and break Intrepid?
[09:46] <tjaalton> break?
[09:46] <tseliot> if a user is running Intrepid and uses nvidia-glx
[09:46] <tjaalton> that would have to be solved anyway
[09:47] <tseliot> oh, I forgot that the driver doesn't work if Intrepid uses kernel 2.6.25 anyway
[09:47] <tjaalton> the debian version has a patch for it
[09:48] <tseliot> we'll have to remove the patch and put the latest NVIDIA driver instead
[09:48] <tjaalton> why?
[09:49] <tseliot> because it doesn't need that patch and the output in the log doesn't look like a hacky patch was applied
[09:49] <tjaalton> uh
[09:49] <tseliot> I tried 2.6.25 and 169.12 with the patch on Hardy
[09:50] <tjaalton> first priority is to get a package ready
[09:50] <tjaalton> then maybe make it work
[09:50] <tseliot> you're the expert on merges
[09:50] <tseliot> I have never done any
[09:51] <tjaalton> we have a version that is known, so mixing things up with a new version doesn't seem like a good idea at this point :)
[09:51] <tseliot> of course, one step at a time
[09:52] <tseliot> getting the package to work on Hardy would have the highest priority
[09:52] <tjaalton> this is not going to get int hardy
[09:52] <tjaalton> -t
[09:52] <tjaalton> so why should it?
[09:52] <tseliot> s/Hardy/Intrepid/
[09:53] <tjaalton> after we know the contents look good
[09:53] <tseliot> we definitely don't want it in Hardy
[09:53] <tseliot> since a lot will change
[09:53] <tjaalton> well that's a no-brainer
[09:58] <tseliot> what's the deadline for merges?
[09:58] <bryce> for intrepid we have months
[09:59] <tseliot> I would like to make sure that I can adapt the packages for Ubuntu before we introduce a package for which I could be blamed
[09:59] <tseliot> this is my concern
[09:59] <tjaalton> I don't understand
[09:59] <tjaalton> who else would upload these?
[09:59] <tseliot> but if we have months, can you wait for me to adapt the package before you do the merge?
[10:00] <tjaalton> what do you mean by "adapting"
[10:00] <tseliot> removing the crap and making sense of it
[10:00] <tjaalton> I'm doing that?
[10:01] <tjaalton> when it's ready I'll do a debdiff so you can have a look if the DKMS stuff is ok
[10:01] <tjaalton> merging your package from yesterday with the debian on
[10:01] <tjaalton> *one
[10:01] <tseliot> ok, now I'm lost. Are you going to do all the work?
[10:02] <tjaalton> for one package, then it should be copying only
[10:02] <tseliot> maybe I didn't understand what you're trying to tell me
[10:02] <tjaalton> what else is there to merge :)(
[10:02] <tjaalton> -(
[10:02] <bryce> http://www.ubuntu-trading.com/
[10:03] <tjaalton> no sound for flash -> no flash :)
[10:04] <tseliot> tjaalton: let's see if I got it right. You will try to merge the package which I gave you with the one in debian and I will have to review the result. Is this correct?
[10:05] <tjaalton> tseliot: correctomundo :)
[10:06] <tseliot> ﻿tjaalton: I thought you were telling me to throw away what I did and start from scratch with the debian package.
[10:06] <tjaalton> tseliot: exactly :)
[10:06] <tjaalton> still confused? :)
[10:06] <tjaalton> ie. I'm porting our changes on top of the debian package
[10:07] <tjaalton> which means throwing away all the lrm baggage
[10:07] <tjaalton> and just maintain a (hopefully) small diff on top of the debian package
[10:08] <tseliot> ok, let's see if it's doable. I'm curious about the result
[10:08] <tseliot> doable = sensible to do so
[10:08] <tseliot> now it's a bit clearer to me ;)
[10:10]  * tseliot wants an Ubuntu cola
[10:10]  * tjaalton wants working flash
[10:16] <tjaalton> tseliot: nvidia-glx (<< 170.12+2.6.24.500-500.24), shouldn't that be nvidia-glx-new?
[10:18] <tseliot> it's not necessary
[10:19] <tseliot> since it provides nvidia-glx
[10:19] <tjaalton> ok, I'll sort them later
[10:19] <tseliot> it = nvidia-glx-new
[10:21] <tjaalton> Package: nvidia-glx
[10:21] <tjaalton> Conflicts: nvidia-glx-src, nvidia-xconfig, nvidia-glx
[10:21] <tjaalton> :)
[10:21] <tjaalton> how can a package conflict itself, hmm
[10:22] <bryce> eww
[10:22] <tjaalton> that's from tseliot's preliminary package, don't worry :)
[10:23] <jcristau> tjaalton: policy 7.3, see "A special exception"
[10:23] <bryce> *yawn*  ok, bedtime for me.  cya all tmrrw
[10:23] <tjaalton> bryce: night
[10:24] <tseliot> ﻿bryce: night
[10:24] <tjaalton> jcristau: oh, so it _is_ useful
[10:24] <jcristau> yes
[10:25] <tjaalton> hmm I should print the policy
[10:26] <tjaalton> devel reference is printed already
[10:35] <tseliot> tjaalton: I have to do work for the parser now. If you have questions, just ping me.
[10:35] <tjaalton> k
[11:59] <tjaalton> hm, the debian nvidia package is full of duplication
[11:59] <tjaalton> not that it matters much, but still
[12:00] <tjaalton> and the -dev package doesn't divert anything, instead conflicts with the mesa version
[12:00] <tjaalton> which makes sense
[12:30] <tseliot> ﻿tjaalton: conflicts and replaces or just conflicts?
[12:36] <tjaalton> conflicts
[12:36] <tjaalton> no, replaces too
[12:36] <tseliot> this makes sense
[12:37] <tjaalton> also provides libgl-dev
[12:37] <tseliot> otherwise it would just refuse to install the package
[12:37] <tjaalton> so, C/R/P: libgl-dev
[12:37]  * tseliot goes to have lunch
[12:37] <tseliot> later
[12:37] <tjaalton> seeya
[13:39] <tseliot> ﻿tjaalton: ok, so the package will replace mesa. Wouldn't this make it harder to go back to an open source driver?
[13:40] <tseliot> it is also true that currently we have to reinstall mesa after we uninstall, say, the nvidia driver
[13:40] <tjaalton> no, just the -dev packaeg
[13:40] <tjaalton> package
[13:40] <tjaalton> that's not true
[13:40] <tseliot> yes, that's what I meant
[13:40] <tjaalton> huh?
[13:40] <tjaalton> I don't follow :)
[13:41] <tjaalton> removing the diversion moves the mesa library back
[13:41] <tjaalton> the dev-package does not divert, instead it conflicts with libgl-dev
[13:42] <tseliot> currently we have to do something like this: sudo apt-get install --reinstall  libgl1-mesa-glx libglu1-mesa  libgl1-mesa-dri
[13:42] <tjaalton> nope
[13:42] <tseliot> but yes, you are referring to the -dev package
[13:42] <tjaalton> at least that shouldn't be necessary
[13:42] <tjaalton> no..
[13:42] <tseliot> trust me, it is necessary
[13:42] <tjaalton> trust me it's not
[13:43] <tjaalton> libgl1-mesa-dev (which provides libgl-dev) ships only headers
[13:43] <tseliot> ok, it's not but if you want mesa to work properly it is necessary
[13:43] <tjaalton> no :)
[13:43] <tseliot> as I said "﻿you are referring to the -dev package"
[13:43] <tseliot> therefore it's ok
[13:44] <tjaalton> it's not possible to have a mixed environment
[13:44] <tjaalton> ie. mesa headers and nvidia libs
[13:44] <tjaalton> or vice versa
[13:45] <tseliot> we're talking about different things I guess. Let's just go ahead and pretend that nothing happened ;)
[13:45] <tjaalton> ok..
[13:47] <tjaalton> sigh, I'll fix the debian packaging bugs while at it
[13:47] <tjaalton> duplication and some wrong paths in non-critical places
[13:48] <tseliot> in my package or in the debian one?
[13:48] <tjaalton> debian
[13:48] <tjaalton> why would I beat the dead horse? :)
[13:48] <tjaalton> (sorry)
[13:48] <tseliot> :-D
[13:52] <tseliot> keep in mind that now I know what you look like... be careful :-P
[13:52] <tjaalton> noo.. my pretty face
[13:53] <tseliot> hehehe
[15:01] <jcristau> fwiw i just updated our xcompmgr package. don't know who would handle the merge on the ubuntu side.
[15:01] <tjaalton> I believe it's ripe for a sync
[15:04] <jcristau> ok cool
[15:05] <jcristau> experimental had a very old version, so i got 1.1.4 to sid (and redid all the packaging so i wouldn't have to try to understand cdbs...)
[15:05] <tjaalton> :)
[15:47] <tjaalton> tseliot: ok, got halfway through, have to continue tomorrow ->
[15:53] <tseliot> ﻿tjaalton: are you trying to say that, unlike myself, you have a life and therefore you can't keep working on the package today? :-P
[15:54] <tseliot> ﻿tjaalton: seriously, no hurry here. I'm still working on the parser ;)
[15:58] <tjaalton> tseliot: correct, wife and two kids waiting.. and a brother-in-law who has issues with his XP machine (duh..)
[15:59] <tseliot> have a lot of fun with XP then ;) (i.e. just reinstall it)
[16:00] <tjaalton> i guess it's infected by malware or something which makes it "slow"
[16:00] <tjaalton> joy
[16:01] <tjaalton> at least it has a linux installation too
[16:01] <tseliot> if you install Norton you can make the computer slow without the malware. Yay!
[16:01] <tjaalton> well, it has that too
[16:01] <tseliot> LOL
[16:01] <tjaalton> should be smaller than f*ck-secure
[16:02] <tseliot> malware is a feature
[16:02] <tjaalton> it's a brand new machine, so it only took a month to get hosed
[16:03] <tseliot> heck
[16:14] <maks_> where do i find current backported ati drivers for hardy?
[16:15] <maks_> have a collegue with a r600 that "works" under flgrx but is only semi happy with the 6.8.0 radeon that got included in hardy
[19:42] <Q-FUNK> anybody available to grab geode 2.9.0-1ubuntu3 from my PPA and push it into hardy-proposed ?
[22:26] <bryce> what does this mean?
[22:26] <bryce>  dpkg-genchanges  >../xserver-xorg-video-geode_2.9.0-1ubuntu2.1_amd64.changes
[22:26] <bryce> dpkg-genchanges: failure: cannot read files list file: No such file or directory
[22:27] <jcristau> debian/files doesn't exist?
[22:28]  * bryce touches
[22:29] <bryce> nope...  maybe something needs to be inside it
[22:29] <bryce> no, that can't be
[22:30] <jcristau> what are you trying to do?
[22:35] <bryce> oh Q-FUNK posted a -geode update for hardy-proposed, so am just trying to pbuilder it
[22:35] <bryce> odd; if I touch debian/files and then do dpkg-genchanges manually it works
[22:35] <bryce> ah wait
[22:36] <jcristau> shouldn't it be dpkg-genchanges -S then?
[22:36] <bryce> hrm
[22:37] <bryce> I get the same results
[22:38] <bryce> what usually goes into debian/files?
[22:39] <bryce> hmm interesting; after running debuild -S, debian/files gets removed
[22:45] <tjaalton> it's cleaned
[22:47] <jcristau> it's created by dpkg-gencontrol when you build binary packages
[22:49] <bryce> here's the full output http://pastebin.com/m64214c06
[22:49] <bryce> maybe the "real" error is that it's not doing anything for 'build' and 'binary'
[22:50] <jcristau> heh, yeah, that looks pretty broken
[22:52] <bryce> source taken from http://ppa.launchpad.net/q-funk/ubuntu/pool/main/x/xserver-xorg-video-geode/
[22:52] <bryce> I get the same thing if I pbuilder the .dsc file from that url
[22:52] <james_w> does it have binary-arch and binary-theotherone the wrong way around?
[22:53] <bryce> not sure; it's using cdbs so it's a bit different than I'm used to
[22:54] <jcristau> cdbs is black magic
[22:54] <jcristau> often broken black magic, at that
[22:55]  * bryce diffs against what's already in the archive
[22:56] <bryce> ah, differences
[22:57] <bryce> http://pastebin.com/m7a3575bf
[22:59] <james_w> uh
[22:59] <james_w> I don't know what problem he was having, but that's not the fix.
[23:03] <bryce> hmm, something is just odd with the .dsc provided
[23:03] <bryce> I'll redo from scratch; the debdiff against hardy is just a one liner
[23:10] <bryce> tjaalton: can you build the .dsc at http://ppa.launchpad.net/q-funk/ubuntu/pool/main/x/xserver-xorg-video-geode/ ?
[23:24] <tjaalton> bryce: heh, no
[23:24] <bryce> tjaalton: ok so not just me
[23:24] <bryce> tjaalton: I am also unable to build the -geode that is currently in hardy-proposed
[23:25] <bryce> I've bumped it back to Q-FUNK
[23:28] <bryce> tjaalton: hmm, I can't build the -geode in intrepid that's sync'd from debian either
[23:29] <bryce> I suspect jcristau's last comment is correct
[23:29] <tjaalton> yep, they are all hosed
[23:29] <jcristau> the one on ppa seems to build fine on sid
[23:30] <tjaalton> jcristau: 1u3?
[23:30] <jcristau> yeah
[23:30] <tjaalton> hmmh
[23:30] <tjaalton> not on my hardy
[23:31] <tjaalton> and why am I debugging this :)
[23:31] <bryce> I've tried against both hardy and intrepid
[23:34] <tjaalton> oh, I'm building on amd64
[23:34] <tjaalton> don't know if that should matter
[23:34] <bryce> me too
[23:34] <bryce> I'll try i386
[23:35] <tjaalton> yep, works there
[23:35] <tjaalton> heh, control only lists i386 :)
[23:35] <tjaalton> so it's fine
[23:35] <bryce> ahh
[23:38] <jcristau> heh
[23:39] <bryce> silly me, setting up this new multi-platform multi-distro build system and then using it to confuse myself ;-)
[23:40] <bryce> ok it all builds fine, I'll upload
[23:40] <tjaalton> col
[23:40] <tjaalton> +o
[23:44] <tjaalton> I guess there's no distribution for a 486SX @25MHz and "a few" MB of memory :)
[23:45] <tjaalton> with some graphical UI
[23:45] <jcristau> one from 10 years ago
[23:45] <jcristau> ;)
[23:45] <tjaalton> heh
[23:46] <tjaalton> yeah I've got this ancient laptop that has W95 on it.. and my daughter somehow likes it better than my thinkpad
[23:47] <tjaalton> but it feels a bit sluggish, so..
[23:48] <bryce> xubuntu?
[23:48] <tjaalton> no chance :)
[23:49] <tjaalton> even damnsmalllinux needs at least a 486DX with 16MB
[23:49] <tjaalton> and it only has a floppy drive plus "a small" HD
[23:51] <bryce> tjaalton: maybe let her drink juice next to the computer?  not sure
[23:52] <jcristau> or milk
[23:53] <tjaalton> haha
[23:53] <tjaalton> http://users.tkk.fi/~tjaalton/foo/_DSC4922_web.jpg
[23:53] <tjaalton> there it is
[23:54] <bryce> hehe
[23:54] <bryce> lotta pink
[23:54] <bryce> hey, paint your thinkpad pink
[23:54] <tjaalton> the current installation has star wars in it
[23:54] <tjaalton> I actually have a couple of old T2x series
[23:55] <tjaalton> and pink paint!
[23:55] <bryce> there you go, problem solved!
[23:55] <tjaalton> indeed, need to grab one from work and start decorating
[23:55] <jcristau> haha. the jamstudio driver is utterly broken
[23:56] <tjaalton> and sooo popular
[23:56] <tormod> tjaalton: there was this RT OS demo on a floppy, incl web browser. qix or something like that. but it's not linux.
[23:56] <tjaalton> tormod: hmm that might be fun
[23:57] <jcristau> #if XORG_VERSION_CURRENT >= XF86_VERSION_NUMERIC(3,9,0,0,0)
[23:57] <jcristau> #define XFREE86_V4 1
[23:57] <jcristau> #endif
[23:57] <tormod> I think it can run on anything. but the name, anyone?
[23:57] <jcristau> and then all the code is under #ifdef XFREE86_V4
[23:57] <tjaalton> tormod: qnx?
[23:58] <tormod> tjaalton: I guess that's right
[23:59] <tormod> I been trying to build xserver 1.5 on git mesa... oh dear.