bryce | anyone know if/when debian will be packaging mesa 7.1rc1? | 02:15 |
---|---|---|
bryce | aha, deb Bug#465554 | 02:16 |
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." | 02:17 |
tjaalton | hmm, tseliot not here | 07:38 |
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:44 |
tjaalton | and scrap the old LRM baggage completely | 07:45 |
bryce | wow | 07:53 |
tjaalton | hm? | 07:55 |
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:56 |
tjaalton | and diverged _a_lot_ since :) | 07:57 |
bryce | ah | 07:57 |
bryce | hey, it's sounding like gem won't be ready for intrepid, according to yong | 07:58 |
tjaalton | surprise | 07:58 |
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:03 |
tjaalton | i mean jockey not in debian | 08:04 |
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:13 |
tseliot | tjaalton: ok but they use the nvidia-kernel package | 09:14 |
tjaalton | we can comment that out | 09:14 |
tjaalton | non-issue | 09:14 |
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:16 |
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:17 |
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:18 |
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:19 |
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:21 |
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:22 |
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:24 |
tjaalton | dpkg -c will tell | 09:25 |
tseliot | mmm... | 09:26 |
tjaalton | at least they include cuda | 09:26 |
tseliot | and so do I | 09:26 |
tjaalton | lrm doesn't | 09:27 |
tjaalton | trust me, it'll pay off :) | 09:27 |
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:28 |
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:29 |
tseliot | but I have bad memory | 09:30 |
tjaalton | bygones | 09:30 |
bryce | ahhh internet back | 09:30 |
tseliot | bryce: congrats :-P | 09:31 |
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:32 |
tseliot | devfs.devices? | 09:33 |
tjaalton | as you see, the lrm version is based on an old debian version | 09:33 |
tjaalton | doesn't seem to be used at all | 09:34 |
tjaalton | so it doesn't matter | 09:35 |
tseliot | did you see the nvidia-glx.init? | 09:36 |
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:37 |
tseliot | tjaalton: do you see my point? | 09:38 |
tjaalton | just don't use what doesn't concern us | 09:38 |
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:39 |
tseliot | :-/ | 09:41 |
tjaalton | bah, it's a walk in the park | 09:41 |
tjaalton | +like | 09:41 |
tseliot | a park filled with serial-killers... :-P | 09:42 |
tjaalton | heh | 09:43 |
tjaalton | I'll do a preliminary merge with 169.12 | 09:44 |
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:45 |
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:46 |
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:47 |
tseliot | we'll have to remove the patch and put the latest NVIDIA driver instead | 09:48 |
tjaalton | why? | 09:48 |
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:49 |
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:50 |
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:51 |
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:52 |
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:53 |
tseliot | what's the deadline for merges? | 09:58 |
bryce | for intrepid we have months | 09:58 |
=== seb128_ is now known as seb128 | ||
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? | 09:59 |
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:00 |
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:01 |
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:02 |
tjaalton | no sound for flash -> no flash :) | 10:03 |
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:04 |
tjaalton | tseliot: correctomundo :) | 10:05 |
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:06 |
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:07 |
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:08 |
* tseliot wants an Ubuntu cola | 10:10 | |
* tjaalton wants working flash | 10:10 | |
tjaalton | tseliot: nvidia-glx (<< 170.12+2.6.24.500-500.24), shouldn't that be nvidia-glx-new? | 10:16 |
tseliot | it's not necessary | 10:18 |
tseliot | since it provides nvidia-glx | 10:19 |
tjaalton | ok, I'll sort them later | 10:19 |
tseliot | it = nvidia-glx-new | 10:19 |
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:21 |
bryce | eww | 10:22 |
tjaalton | that's from tseliot's preliminary package, don't worry :) | 10:22 |
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:23 |
tseliot | bryce: night | 10:24 |
tjaalton | jcristau: oh, so it _is_ useful | 10:24 |
jcristau | yes | 10:24 |
tjaalton | hmm I should print the policy | 10:25 |
tjaalton | devel reference is printed already | 10:26 |
tseliot | tjaalton: I have to do work for the parser now. If you have questions, just ping me. | 10:35 |
tjaalton | k | 10:35 |
tjaalton | hm, the debian nvidia package is full of duplication | 11:59 |
tjaalton | not that it matters much, but still | 11:59 |
tjaalton | and the -dev package doesn't divert anything, instead conflicts with the mesa version | 12:00 |
tjaalton | which makes sense | 12:00 |
tseliot | tjaalton: conflicts and replaces or just conflicts? | 12:30 |
tjaalton | conflicts | 12:36 |
tjaalton | no, replaces too | 12:36 |
tseliot | this makes sense | 12:36 |
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 | 12:37 |
tseliot | tjaalton: ok, so the package will replace mesa. Wouldn't this make it harder to go back to an open source driver? | 13:39 |
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:40 |
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:41 |
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:42 |
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:43 |
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:44 |
tseliot | we're talking about different things I guess. Let's just go ahead and pretend that nothing happened ;) | 13:45 |
tjaalton | ok.. | 13:45 |
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:47 |
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:48 |
tseliot | keep in mind that now I know what you look like... be careful :-P | 13:52 |
tjaalton | noo.. my pretty face | 13:52 |
tseliot | hehehe | 13:53 |
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:01 |
jcristau | ok cool | 15:04 |
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:05 |
tjaalton | tseliot: ok, got halfway through, have to continue tomorrow -> | 15:47 |
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:53 |
tseliot | tjaalton: seriously, no hurry here. I'm still working on the parser ;) | 15:54 |
tjaalton | tseliot: correct, wife and two kids waiting.. and a brother-in-law who has issues with his XP machine (duh..) | 15:58 |
tseliot | have a lot of fun with XP then ;) (i.e. just reinstall it) | 15:59 |
tjaalton | i guess it's infected by malware or something which makes it "slow" | 16:00 |
tjaalton | joy | 16:00 |
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:01 |
tseliot | malware is a feature | 16:02 |
tjaalton | it's a brand new machine, so it only took a month to get hosed | 16:02 |
tseliot | heck | 16:03 |
maks_ | where do i find current backported ati drivers for hardy? | 16:14 |
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 | 16:15 |
Q-FUNK | anybody available to grab geode 2.9.0-1ubuntu3 from my PPA and push it into hardy-proposed ? | 19:42 |
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:26 |
jcristau | debian/files doesn't exist? | 22:27 |
* bryce touches | 22:28 | |
bryce | nope... maybe something needs to be inside it | 22:29 |
bryce | no, that can't be | 22:29 |
jcristau | what are you trying to do? | 22:30 |
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:35 |
jcristau | shouldn't it be dpkg-genchanges -S then? | 22:36 |
bryce | hrm | 22:36 |
bryce | I get the same results | 22:37 |
bryce | what usually goes into debian/files? | 22:38 |
bryce | hmm interesting; after running debuild -S, debian/files gets removed | 22:39 |
tjaalton | it's cleaned | 22:45 |
jcristau | it's created by dpkg-gencontrol when you build binary packages | 22:47 |
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:49 |
jcristau | heh, yeah, that looks pretty broken | 22:50 |
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:52 |
bryce | not sure; it's using cdbs so it's a bit different than I'm used to | 22:53 |
jcristau | cdbs is black magic | 22:54 |
jcristau | often broken black magic, at that | 22:54 |
* bryce diffs against what's already in the archive | 22:55 | |
bryce | ah, differences | 22:56 |
bryce | http://pastebin.com/m7a3575bf | 22:57 |
james_w | uh | 22:59 |
james_w | I don't know what problem he was having, but that's not the fix. | 22:59 |
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:03 |
bryce | tjaalton: can you build the .dsc at http://ppa.launchpad.net/q-funk/ubuntu/pool/main/x/xserver-xorg-video-geode/ ? | 23:10 |
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:24 |
bryce | I've bumped it back to Q-FUNK | 23:25 |
bryce | tjaalton: hmm, I can't build the -geode in intrepid that's sync'd from debian either | 23:28 |
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:29 |
tjaalton | jcristau: 1u3? | 23:30 |
jcristau | yeah | 23:30 |
tjaalton | hmmh | 23:30 |
tjaalton | not on my hardy | 23:30 |
tjaalton | and why am I debugging this :) | 23:31 |
bryce | I've tried against both hardy and intrepid | 23:31 |
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:34 |
tjaalton | yep, works there | 23:35 |
tjaalton | heh, control only lists i386 :) | 23:35 |
tjaalton | so it's fine | 23:35 |
bryce | ahh | 23:35 |
jcristau | heh | 23:38 |
bryce | silly me, setting up this new multi-platform multi-distro build system and then using it to confuse myself ;-) | 23:39 |
bryce | ok it all builds fine, I'll upload | 23:40 |
tjaalton | col | 23:40 |
tjaalton | +o | 23:40 |
tjaalton | I guess there's no distribution for a 486SX @25MHz and "a few" MB of memory :) | 23:44 |
tjaalton | with some graphical UI | 23:45 |
jcristau | one from 10 years ago | 23:45 |
jcristau | ;) | 23:45 |
tjaalton | heh | 23:45 |
tjaalton | yeah I've got this ancient laptop that has W95 on it.. and my daughter somehow likes it better than my thinkpad | 23:46 |
tjaalton | but it feels a bit sluggish, so.. | 23:47 |
bryce | xubuntu? | 23:48 |
tjaalton | no chance :) | 23:48 |
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:49 |
bryce | tjaalton: maybe let her drink juice next to the computer? not sure | 23:51 |
jcristau | or milk | 23:52 |
tjaalton | haha | 23:53 |
tjaalton | http://users.tkk.fi/~tjaalton/foo/_DSC4922_web.jpg | 23:53 |
tjaalton | there it is | 23:53 |
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:54 |
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:55 |
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:56 |
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:57 |
tormod | tjaalton: I guess that's right | 23:58 |
tormod | I been trying to build xserver 1.5 on git mesa... oh dear. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!