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