/srv/irclogs.ubuntu.com/2008/05/29/#ubuntu-x.txt

bryceanyone know if/when debian will be packaging mesa 7.1rc1?02:15
bryceaha, deb Bug#46555402:16
bryce"The mesa master branch is02:17
bryceprobably still too much of a moving target now for us to spend too much02:17
brycetime on it."02:17
tjaaltonhmm, tseliot not here07:38
tjaaltonI think it would be wise to base the split nvidia* on the debian versions, and just maintain a diff with DKMS and stuff07:44
tjaaltonand scrap the old LRM baggage completely07:45
brycewow07:53
tjaaltonhm?07:55
bryceoh just that this would be a pretty profound change07:56
tjaaltonwell, it's split anyway07:56
tjaaltonand the original version is from debian07:56
tjaaltonand diverged _a_lot_ since :)07:57
bryceah07:57
brycehey, it's sounding like gem won't be ready for intrepid, according to yong07:58
tjaaltonsurprise07:58
tjaaltonhm, if we could persuade the debian nvidia maintainers to accept our patches, then debian could use jockey too08:03
tjaaltoncurrently it's not there08:03
tjaaltoni mean jockey not in debian08:04
tjaaltontseliot: hi, I've looked at your packages and I have a suggestion :)09:13
tseliottjaalton: shoot09:13
tjaaltontseliot: scrap everything, and build our diff on top of the debian packages09:13
tjaaltonfor various reasons09:13
tseliottjaalton: ok but they use the nvidia-kernel package09:14
tjaaltonwe can comment that out09:14
tjaaltonnon-issue09:14
tjaaltonthey might be interested in DKMS btw09:16
tseliottjaalton: are we going to keep the nvidia-glx-ia32 for 64bit?09:16
tjaaltonand jockey, although it would have to be installed by default to be useful09:16
tjaaltondon't know yet09:16
tseliotso you're suggesting that we try to contribute upstream09:17
tjaaltonwe can filter whatever doesn't suit us09:17
tjaaltonyes09:17
tjaaltonthey have the same bugs :)09:17
tseliotnot a bad idea ;)09:17
tjaaltonupstream being debian09:17
tseliotof course09:17
tjaaltonthey have a group on alioth, and a mailing list09:18
tseliotI will keep the nvidia-modaliases packages though09:18
tjaaltonsure09:18
tjaaltonalso, it might be nice to include the old changelog as changelog.Ubuntu.old or something09:19
tseliotthis wouldn't be a problem09:19
tjaaltonI don't understand what the -ia32 packages are for09:21
tseliotwe'll have to deal with the diversions created by both the Ubuntu lrm and the lrm-envy09:21
tseliottjaalton: the 32bit compatibility libraries for 64bit systems09:21
tjaaltonwell, I don't see a /emul dir on my system09:21
tseliotwe don't have that package in Ubuntu09:22
tseliotwe package those libraries differently09:22
tjaaltonright, in /usr/lib3209:22
tseliotexactly09:22
tseliotthe 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 envy09:24
tjaaltondpkg -c will tell09:25
tseliotmmm...09:26
tjaaltonat least they include cuda09:26
tseliotand so do I09:26
tjaaltonlrm doesn't09:27
tjaaltontrust me, it'll pay off :)09:27
tseliotI added the support for CUDA to my packages and a number of people depend on me for CUDA.09:28
tjaaltonfunny that there are no bugs about adding that to lrm09:28
tseliotthe packages which I gave to you are in fact based on my lrm-envy09:29
tjaaltonsince I didn't notice there was such a beast09:29
tjaaltonso lrm not having cuda was not intentional09:29
tseliottjaalton: it was reported in some other bug. I should have reported the problem myself09:29
tseliotwith a patch09:29
tseliotbut I have bad memory09:30
tjaaltonbygones09:30
bryceahhh internet back09:30
tseliotbryce: congrats :-P09:31
tseliottjaalton: did you have a look at the nvidia/debian.binary of the debian package?09:32
tjaaltontseliot: yes, it's newer09:32
tseliotdevfs.devices?09:33
tjaaltonas you see, the lrm version is based on an old debian version09:33
tjaaltondoesn't seem to be used at all09:34
tjaaltonso it doesn't matter09:35
tseliotdid  you see the nvidia-glx.init?09:36
tseliotporting 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 know09:37
tseliotenough09:37
tseliot(which I don't know enough)09:37
tseliottjaalton: do you see my point?09:38
tjaaltonjust don't use what doesn't concern us09:38
tjaaltonthe initscript seems like a good example.. messing with the links09:39
tjaaltoner, no?09:39
tseliotand how do I know what doesn't concern us ;) ?09:39
tjaaltonby auditing the package and testing things :)09:39
tseliotthat's what worries me most...09:39
tseliot:-/09:41
tjaaltonbah, it's a walk in the park09:41
tjaalton+like09:41
tseliota park filled with serial-killers... :-P09:42
tjaaltonheh09:43
tjaaltonI'll do a preliminary merge with 169.1209:44
tseliotto tell the truth I used to deal with the debian nvidia-glx packages for envy legacy but they have changed so much...09:45
tseliotwait will this replace the nvidia-glx and break Intrepid?09:46
tjaaltonbreak?09:46
tseliotif a user is running Intrepid and uses nvidia-glx09:46
tjaaltonthat would have to be solved anyway09:46
tseliotoh, I forgot that the driver doesn't work if Intrepid uses kernel 2.6.25 anyway09:47
tjaaltonthe debian version has a patch for it09:47
tseliotwe'll have to remove the patch and put the latest NVIDIA driver instead09:48
tjaaltonwhy?09:48
tseliotbecause it doesn't need that patch and the output in the log doesn't look like a hacky patch was applied09:49
tjaaltonuh09:49
tseliotI tried 2.6.25 and 169.12 with the patch on Hardy09:49
tjaaltonfirst priority is to get a package ready09:50
tjaaltonthen maybe make it work09:50
tseliotyou're the expert on merges09:50
tseliotI have never done any09:50
tjaaltonwe 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
tseliotof course, one step at a time09:51
tseliotgetting the package to work on Hardy would have the highest priority09:52
tjaaltonthis is not going to get int hardy09:52
tjaalton-t09:52
tjaaltonso why should it?09:52
tseliots/Hardy/Intrepid/09:52
tjaaltonafter we know the contents look good09:53
tseliotwe definitely don't want it in Hardy09:53
tseliotsince a lot will change09:53
tjaaltonwell that's a no-brainer09:53
tseliotwhat's the deadline for merges?09:58
brycefor intrepid we have months09:58
=== seb128_ is now known as seb128
tseliotI would like to make sure that I can adapt the packages for Ubuntu before we introduce a package for which I could be blamed09:59
tseliotthis is my concern09:59
tjaaltonI don't understand09:59
tjaaltonwho else would upload these?09:59
tseliotbut if we have months, can you wait for me to adapt the package before you do the merge?09:59
tjaaltonwhat do you mean by "adapting"10:00
tseliotremoving the crap and making sense of it10:00
tjaaltonI'm doing that?10:00
tjaaltonwhen it's ready I'll do a debdiff so you can have a look if the DKMS stuff is ok10:01
tjaaltonmerging your package from yesterday with the debian on10:01
tjaalton*one10:01
tseliotok, now I'm lost. Are you going to do all the work?10:01
tjaaltonfor one package, then it should be copying only10:02
tseliotmaybe I didn't understand what you're trying to tell me10:02
tjaaltonwhat else is there to merge :)(10:02
tjaalton-(10:02
brycehttp://www.ubuntu-trading.com/10:02
tjaaltonno sound for flash -> no flash :)10:03
tseliottjaalton: 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
tjaaltontseliot: correctomundo :)10:05
tseliottjaalton: I thought you were telling me to throw away what I did and start from scratch with the debian package.10:06
tjaaltontseliot: exactly :)10:06
tjaaltonstill confused? :)10:06
tjaaltonie. I'm porting our changes on top of the debian package10:06
tjaaltonwhich means throwing away all the lrm baggage10:07
tjaaltonand just maintain a (hopefully) small diff on top of the debian package10:07
tseliotok, let's see if it's doable. I'm curious about the result10:08
tseliotdoable = sensible to do so10:08
tseliotnow it's a bit clearer to me ;)10:08
* tseliot wants an Ubuntu cola10:10
* tjaalton wants working flash10:10
tjaaltontseliot: nvidia-glx (<< 170.12+2.6.24.500-500.24), shouldn't that be nvidia-glx-new?10:16
tseliotit's not necessary10:18
tseliotsince it provides nvidia-glx10:19
tjaaltonok, I'll sort them later10:19
tseliotit = nvidia-glx-new10:19
tjaaltonPackage: nvidia-glx10:21
tjaaltonConflicts: nvidia-glx-src, nvidia-xconfig, nvidia-glx10:21
tjaalton:)10:21
tjaaltonhow can a package conflict itself, hmm10:21
bryceeww10:22
tjaaltonthat's from tseliot's preliminary package, don't worry :)10:22
jcristautjaalton: policy 7.3, see "A special exception"10:23
bryce*yawn*  ok, bedtime for me.  cya all tmrrw10:23
tjaaltonbryce: night10:23
tseliotbryce: night10:24
tjaaltonjcristau: oh, so it _is_ useful10:24
jcristauyes10:24
tjaaltonhmm I should print the policy10:25
tjaaltondevel reference is printed already10:26
tseliottjaalton: I have to do work for the parser now. If you have questions, just ping me.10:35
tjaaltonk10:35
tjaaltonhm, the debian nvidia package is full of duplication11:59
tjaaltonnot that it matters much, but still11:59
tjaaltonand the -dev package doesn't divert anything, instead conflicts with the mesa version12:00
tjaaltonwhich makes sense12:00
tseliottjaalton: conflicts and replaces or just conflicts?12:30
tjaaltonconflicts12:36
tjaaltonno, replaces too12:36
tseliotthis makes sense12:36
tjaaltonalso provides libgl-dev12:37
tseliototherwise it would just refuse to install the package12:37
tjaaltonso, C/R/P: libgl-dev12:37
* tseliot goes to have lunch12:37
tseliotlater12:37
tjaaltonseeya12:37
tseliottjaalton: ok, so the package will replace mesa. Wouldn't this make it harder to go back to an open source driver?13:39
tseliotit is also true that currently we have to reinstall mesa after we uninstall, say, the nvidia driver13:40
tjaaltonno, just the -dev packaeg13:40
tjaaltonpackage13:40
tjaaltonthat's not true13:40
tseliotyes, that's what I meant13:40
tjaaltonhuh?13:40
tjaaltonI don't follow :)13:40
tjaaltonremoving the diversion moves the mesa library back13:41
tjaaltonthe dev-package does not divert, instead it conflicts with libgl-dev13:41
tseliotcurrently we have to do something like this: sudo apt-get install --reinstall  libgl1-mesa-glx libglu1-mesa  libgl1-mesa-dri13:42
tjaaltonnope13:42
tseliotbut yes, you are referring to the -dev package13:42
tjaaltonat least that shouldn't be necessary13:42
tjaaltonno..13:42
tseliottrust me, it is necessary13:42
tjaaltontrust me it's not13:42
tjaaltonlibgl1-mesa-dev (which provides libgl-dev) ships only headers13:43
tseliotok, it's not but if you want mesa to work properly it is necessary13:43
tjaaltonno :)13:43
tseliotas I said "you are referring to the -dev package"13:43
tseliottherefore it's ok13:43
tjaaltonit's not possible to have a mixed environment13:44
tjaaltonie. mesa headers and nvidia libs13:44
tjaaltonor vice versa13:44
tseliotwe're talking about different things I guess. Let's just go ahead and pretend that nothing happened ;)13:45
tjaaltonok..13:45
tjaaltonsigh, I'll fix the debian packaging bugs while at it13:47
tjaaltonduplication and some wrong paths in non-critical places13:47
tseliotin my package or in the debian one?13:48
tjaaltondebian13:48
tjaaltonwhy would I beat the dead horse? :)13:48
tjaalton(sorry)13:48
tseliot:-D13:48
tseliotkeep in mind that now I know what you look like... be careful :-P13:52
tjaaltonnoo.. my pretty face13:52
tseliothehehe13:53
jcristaufwiw i just updated our xcompmgr package. don't know who would handle the merge on the ubuntu side.15:01
tjaaltonI believe it's ripe for a sync15:01
jcristauok cool15:04
jcristauexperimental 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
tjaaltontseliot: ok, got halfway through, have to continue tomorrow ->15:47
tseliottjaalton: are you trying to say that, unlike myself, you have a life and therefore you can't keep working on the package today? :-P15:53
tseliottjaalton: seriously, no hurry here. I'm still working on the parser ;)15:54
tjaaltontseliot: correct, wife and two kids waiting.. and a brother-in-law who has issues with his XP machine (duh..)15:58
tseliothave a lot of fun with XP then ;) (i.e. just reinstall it)15:59
tjaaltoni guess it's infected by malware or something which makes it "slow"16:00
tjaaltonjoy16:00
tjaaltonat least it has a linux installation too16:01
tseliotif you install Norton you can make the computer slow without the malware. Yay!16:01
tjaaltonwell, it has that too16:01
tseliotLOL16:01
tjaaltonshould be smaller than f*ck-secure16:01
tseliotmalware is a feature16:02
tjaaltonit's a brand new machine, so it only took a month to get hosed16:02
tseliotheck16: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 hardy16:15
Q-FUNKanybody available to grab geode 2.9.0-1ubuntu3 from my PPA and push it into hardy-proposed ?19:42
brycewhat does this mean?22:26
bryce dpkg-genchanges  >../xserver-xorg-video-geode_2.9.0-1ubuntu2.1_amd64.changes22:26
brycedpkg-genchanges: failure: cannot read files list file: No such file or directory22:26
jcristaudebian/files doesn't exist?22:27
* bryce touches22:28
brycenope...  maybe something needs to be inside it22:29
bryceno, that can't be22:29
jcristauwhat are you trying to do?22:30
bryceoh Q-FUNK posted a -geode update for hardy-proposed, so am just trying to pbuilder it22:35
bryceodd; if I touch debian/files and then do dpkg-genchanges manually it works22:35
bryceah wait22:35
jcristaushouldn't it be dpkg-genchanges -S then?22:36
brycehrm22:36
bryceI get the same results22:37
brycewhat usually goes into debian/files?22:38
brycehmm interesting; after running debuild -S, debian/files gets removed22:39
tjaaltonit's cleaned22:45
jcristauit's created by dpkg-gencontrol when you build binary packages22:47
brycehere's the full output http://pastebin.com/m64214c0622:49
brycemaybe the "real" error is that it's not doing anything for 'build' and 'binary'22:49
jcristauheh, yeah, that looks pretty broken22:50
brycesource taken from http://ppa.launchpad.net/q-funk/ubuntu/pool/main/x/xserver-xorg-video-geode/22:52
bryceI get the same thing if I pbuilder the .dsc file from that url22:52
james_wdoes it have binary-arch and binary-theotherone the wrong way around?22:52
brycenot sure; it's using cdbs so it's a bit different than I'm used to22:53
jcristaucdbs is black magic22:54
jcristauoften broken black magic, at that22:54
* bryce diffs against what's already in the archive22:55
bryceah, differences22:56
brycehttp://pastebin.com/m7a3575bf22:57
james_wuh22:59
james_wI don't know what problem he was having, but that's not the fix.22:59
brycehmm, something is just odd with the .dsc provided23:03
bryceI'll redo from scratch; the debdiff against hardy is just a one liner23:03
brycetjaalton: can you build the .dsc at http://ppa.launchpad.net/q-funk/ubuntu/pool/main/x/xserver-xorg-video-geode/ ?23:10
tjaaltonbryce: heh, no23:24
brycetjaalton: ok so not just me23:24
brycetjaalton: I am also unable to build the -geode that is currently in hardy-proposed23:24
bryceI've bumped it back to Q-FUNK23:25
brycetjaalton: hmm, I can't build the -geode in intrepid that's sync'd from debian either23:28
bryceI suspect jcristau's last comment is correct23:29
tjaaltonyep, they are all hosed23:29
jcristauthe one on ppa seems to build fine on sid23:29
tjaaltonjcristau: 1u3?23:30
jcristauyeah23:30
tjaaltonhmmh23:30
tjaaltonnot on my hardy23:30
tjaaltonand why am I debugging this :)23:31
bryceI've tried against both hardy and intrepid23:31
tjaaltonoh, I'm building on amd6423:34
tjaaltondon't know if that should matter23:34
bryceme too23:34
bryceI'll try i38623:34
tjaaltonyep, works there23:35
tjaaltonheh, control only lists i386 :)23:35
tjaaltonso it's fine23:35
bryceahh23:35
jcristauheh23:38
brycesilly me, setting up this new multi-platform multi-distro build system and then using it to confuse myself ;-)23:39
bryceok it all builds fine, I'll upload23:40
tjaaltoncol23:40
tjaalton+o23:40
tjaaltonI guess there's no distribution for a 486SX @25MHz and "a few" MB of memory :)23:44
tjaaltonwith some graphical UI23:45
jcristauone from 10 years ago23:45
jcristau;)23:45
tjaaltonheh23:45
tjaaltonyeah I've got this ancient laptop that has W95 on it.. and my daughter somehow likes it better than my thinkpad23:46
tjaaltonbut it feels a bit sluggish, so..23:47
brycexubuntu?23:48
tjaaltonno chance :)23:48
tjaaltoneven damnsmalllinux needs at least a 486DX with 16MB23:49
tjaaltonand it only has a floppy drive plus "a small" HD23:49
brycetjaalton: maybe let her drink juice next to the computer?  not sure23:51
jcristauor milk23:52
tjaaltonhaha23:53
tjaaltonhttp://users.tkk.fi/~tjaalton/foo/_DSC4922_web.jpg23:53
tjaaltonthere it is23:53
brycehehe23:54
brycelotta pink23:54
brycehey, paint your thinkpad pink23:54
tjaaltonthe current installation has star wars in it23:54
tjaaltonI actually have a couple of old T2x series23:54
tjaaltonand pink paint!23:55
brycethere you go, problem solved!23:55
tjaaltonindeed, need to grab one from work and start decorating23:55
jcristauhaha. the jamstudio driver is utterly broken23:55
tjaaltonand sooo popular23:56
tormodtjaalton: there was this RT OS demo on a floppy, incl web browser. qix or something like that. but it's not linux.23:56
tjaaltontormod: hmm that might be fun23:56
jcristau#if XORG_VERSION_CURRENT >= XF86_VERSION_NUMERIC(3,9,0,0,0)23:57
jcristau#define XFREE86_V4 123:57
jcristau#endif23:57
tormodI think it can run on anything. but the name, anyone?23:57
jcristauand then all the code is under #ifdef XFREE86_V423:57
tjaaltontormod: qnx?23:57
tormodtjaalton: I guess that's right23:58
tormodI 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!