/srv/irclogs.ubuntu.com/2008/06/02/#ubuntu-x.txt

pwnguindoes anyone know what the hell is going on in bug #188787?05:24
pwnguinalso, where'd the bot go?05:27
tjaaltonpwnguin: didn't look at it closely, but the new package should fix that?07:34
pwnguinit might07:36
pwnguinwacom's changelogs are pretty vague and i dont build directly from them07:37
pwnguinis there a way to get a unified diff from a cvs repo?07:37
pwnguinreporter says it might not always work, but there's nothing in the upstream bugtracker07:40
tjaaltonpwnguin: use -u08:20
tjaaltontseliot: what files/dirs were you referring to that nvidia can't ship?09:02
tseliottjaalton: there are a few things09:15
tseliottoo many "patches" dirs09:15
tseliote.g. we don't need a patches dir in debian.binary09:16
tseliotwe don't need a Makefile09:16
tseliotor a devfs.devices09:16
tseliotor nvidia_supported, etc.09:18
tjaaltonyou mean we don't have to patch the modules?09:18
tjaaltonever :)09:19
tjaaltonif they don't break anything, I'd keep them there09:19
tjaaltonto make the diff smaller09:19
tjaaltonhaven't looked inside the tarball yet09:19
tseliotwe have a patches folder in debian.binary and 3 patches-related dirs in debian09:20
tselioterr not in debian09:20
tseliotin the main directory09:20
tseliotactually we might want to keep only the one in debian.binary09:21
tseliotand we'll also have to get rid of nvidia-settings since it's maintained separately09:22
tjaaltoncommented out already09:23
tseliotand I'm not comfortable with having a separate package such as nvidia-glx-ia3209:23
tjaaltonthe debian version does not have any debian/patches dir09:23
tjaaltonit's not included in my version09:24
tjaaltonif you looked at the diff09:24
tseliotI applied the diff. Maybe something went wrong09:24
tjaaltonon top of which?09:24
tjaaltonit's against the debian package09:24
tseliotthe -4 revision of the package in unstable09:25
tjaaltonright09:25
tjaaltonlook at debian/control09:25
tseliotcontrol.in?09:25
tjaaltonboth09:25
tseliotyou're right the ia32 package is commented out09:26
tjaaltonpatches.save or patches.dpatch.save are not used09:27
tjaaltonthe debian maintainer _might_ want to clean it up a bit..09:27
tseliotdid you move such libraries to another dir in nvidia-glx in the debian/rules?09:27
tjaaltonyes09:27
tjaaltonusr/lib3209:27
tseliotok, perfect09:27
tjaaltonjust open the diff, it's easier to see the changes :)09:27
tseliotok, I'll use Kompare to do so09:30
tjaalton"less" is enough09:30
tseliotyes, I know but Kompare lets me browse through the files and see the changes, it's nice09:33
tseliotalso we might want to remove the diversions created by both nvidia-glx-new and nvidia-glx-new-envy, etc.09:34
tseliots/to remove/try to remove/09:35
tseliotsince the -envy flavour should be a dummy package in Intrepid which will point to our packages (and to Mario's)09:36
tjaaltonthose should be removed by the packages itself09:36
tjaaltonin postrm or so09:36
tseliotI was thinking of dist-upgrades, etc.09:37
tseliotI want to make sure that we don't break upgrades from Hardy to Intrepid, no matter what09:37
tjaaltonok so they are not touched on upgrade09:38
tjaaltoncurrently09:38
tseliotand we'll have to be very careful about the Conflicts/Replaces in the control file09:40
tseliotnot that I need to remind you of this09:40
tseliot;)09:40
tseliotshall we make an additional package which contains a tarball such as the one which is currently provided by nvidia-kernel-source?09:42
tjaaltonwhy?09:42
tseliotI'm asking you since nvidia-kernel-source will only contain the DKMS part09:42
tjaaltonagain, why? :)09:42
tseliotwhy what?09:43
tjaaltonwhy can't it have both the source and dkms stuff?09:43
tjaaltonwhy another package?09:43
tseliotshould we put the same source twice in the same package?09:44
tjaaltonI don't understand..09:44
tseliotthe dkms source contains the content of that tarball + dkms.conf and other stuff09:44
tjaaltonah ok09:44
tjaaltonthat's enough imho09:45
tseliotand it will be installed to /usr/src09:45
tseliotok, agreed09:45
tseliotdo you think that Debian will ever accept our changes to this package?09:46
tjaaltonno idea09:47
tseliotwhen the package is ready I would like to put the latest release of the nvidia driver since it removes the need of a hacky patch and improves hardware support09:49
Q-FUNKhm. seems that bryce's geode 2.9.0-1ubuntu2.1 doesn't work whereas my own package does.10:32
Q-FUNKthis realy should have been done as per the debian 2.9.0-3 package10:34
Q-FUNKcould video-all be updated to pull geode instead of amd?10:34
Q-FUNKamd really is a transitional package, nowadays10:34
Q-FUNKincluding in hardy10:35
jcristauwhat's the point? it's not like the transitional package is going away from hardy10:36
Q-FUNKremoving the transitional package also removes -all10:40
jcristauthen don't remove it :)10:41
Q-FUNK:-P10:41
Q-FUNKthat kinda spoils the concept of transitional package now, doesn't it?10:41
jcristaumaybe, but i don't quite see why that would warrant an update in a released version10:43
jcristaujust my opinion, though10:43
Q-FUNKok, it seems that the short answer is:  trying to maintain any sort of backward-compatibility with the old -amd driver makes LTSP fail on Geode hardware.13:02
Q-FUNKthe simplest way to really fix hardy is to make video-all Depends on -geode >= 2.9.0-3 and Conflicts on -amd (any version)13:04
jcristauuh13:07
jcristauthat sounds wrong13:07
Q-FUNKhow so?13:09
jcristauhow does ltsp fail?13:10
Q-FUNKjcristau: the reverse-compatibility links between amd_drv.so and geode_drv.so break it13:15
Q-FUNKditto if there's a link between amd.ids and geode.ids13:16
jcristauthere should not be an amd.ids13:17
Q-FUNKwhy not?  13:18
Q-FUNKcreates additional PCI ID conflicts as a result of the symbolic link?13:19
jcristaupci id conflicts are not an issue13:19
jcristauthe server will just pick the first one it finds13:19
Q-FUNKwhy not then?13:20
jcristauyou still haven't replied to my first question though. how does ltsp fail?13:20
jcristaubecause it's useless13:20
Q-FUNKfails to launch X13:20
jcristauhow13:20
jcristau'it fails' is somewhat vague...13:20
Q-FUNKif the symbolic links are there, X won't detect the Geode LX and falls back to console.13:21
jcristaumeh13:21
jcristauthat still doesn't give any detail13:21
Q-FUNKif the symbolic links are gone, X launches as expected13:21
Q-FUNKand uses the corrects driver13:21
jcristauhave a log/config?13:22
Q-FUNKnope13:22
jcristauthen get one13:22
Q-FUNKgood luck on thta one. it all happens in a ramdisk.13:22
jcristauthat's like the first step for any problem with x13:22
Q-FUNKexcept that here, simply A/B testing shows thta removing the symbolic links fixes it.13:23
jcristauyou said you were dumped to the console. pretty sure you can get logs from there13:23
Q-FUNKno need to investigate any further.13:23
Q-FUNKno13:24
Q-FUNKLTSP disables console login and doesn't set any password for the squashfs that is used to get LDM 13:25
tjaaltonhttp://www.googlefight.com/index.php?lang=en_GB&word1=TTM&word2=GEM13:43
tseliotLOL13:46
tjaaltonhmm, http://www.googlefight.com/index.php?lang=en_GB&word1=translation+table+maps&word2=graphics+execution+manager13:47
=== kees_ is now known as kees
jcristauyou might want to remove xserver-xorg-video-newport from ubuntu20:03
jcristau(see debian bug 393709)20:07
ubottuDebian bug 393709 in xserver-xorg-video-newport "xserver-xorg-video-newport: video-newport should only exist on mips" [Wishlist,Closed] http://bugs.debian.org/39370920:07
tjaaltonx-x-v-all should be changed too20:09
jcristauright20:10
bryceI just checked in a change to s/-amd/-geode/ to that20:10
jcristaui removed the -newport dependency in 1:7.3+1120:10
tormodwhich package should ship xmesa.h from mesa? xserver needs it, but it was rejected for instance from mesa-common-dev in a Debian bug report.21:09
brycetormod: I don't know...  I'd have guessed mesa21:53
tormodbryce: yes, but which binary package?21:53
tormodmaybe it should be included in the server itself now21:54
=== rzr is now known as RzR
=== RzR is now known as rZr
brycetormod: libgl1-mesa-dev maybe?22:30
brycetormod: hmm mesa-common-dev might be better22:30
tormodbryce, yes other files from the same source dir ends up there.22:37
brycemaybe tjaalton or jcristau could have something more useful to advise22:43
tormodthe related bug is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=35401923:08
ubottuDebian bug 354019 in mesa-common-dev "mesa-common-dev: doesn't contain xmesa.h" [Normal,Closed] 23:08
Q-FUNKhowdy23:24
Q-FUNKhttp://mentors.debian.net/debian/pool/main/x/xserver-xorg-video-geode/xserver-xorg-video-geode_2.9.0-4.dsc23:27
Q-FUNKI'm thinking of removing the symbolic links to -amd completely and instead warn people who still have "amd" in their xorg.conf to change it to "geode".23:28
bryceo_O23:29
Q-FUNKI know23:30
Q-FUNKbut further testing shows that 2.9.0-ubuntu2.1 doesn't fix it.  the real fix is to remove the symbolic links completely, otherwise LTSP still barfs23:31
Q-FUNKand it's easy enough to reply to eventual bug reports about standalone host by pointing to a simple Device change from "amd" to "geode" than to keep this in a half-broken state.23:32
Q-FUNKmy first guess with 2.9.0-3 at debian was to move the symbolic links to the transitional -amd package, but this would only work if -video-all is made to no longer depend on -amd and instead depend on -geode23:33
Q-FUNKthen people upgrading from Gutsy would get -geode as a byproduct up upgrading -amd and/or -all, would also get the symbolic links if they run on a standalone host, but since -all doesn't pull -amd anymore, then LTSP would always work23:34
Q-FUNKand so changing -all to depend only on geode, rather than -amd, and adopting 2.9.0-3 for hardy would be the most reasonable course of action.23:35
Q-FUNKfor debian, the above -4 makes more sens,e since we've never had -amd in the first place.23:36
bryceI've checked in that change to git this morning23:36
Q-FUNKbut we are too late for the hardy.1 release, right?23:37
bryceyup23:37
Q-FUNK:(23:37
Q-FUNKany way we can push 2.9.0-3 and -all with -geode instead of -amd into proposed for hardy.2 ?23:38
bryce dunno23:39
bryceI guess I'd rather hold off until we know for certain what the fix is23:39
bryceit seems like there's been too many sru's for this -geode change, each time "this will definitely fix it", but it didn't23:40
bryceI don't know what the .2 release schedule is, but presumably it's a ways off.  So better to focus on getting this fixed properly in intrepid and validate the solution definitively on all affected hardware, and *then* do an SRU23:41
Q-FUNKwell, changing the dependency in -all had been discussed before. I still don't even known how hardy.0 even shipped with the dependency still on -amd.23:44
Q-FUNKand keeping the symbolic links in -geode wasn't my idea of a fix either.23:45
Q-FUNKit rather was pitti's idea to keep all files within the established 2.8.0 packaging's idea.23:46
Q-FUNKand since 2.8.0 was released with the symbolic links in -geode rather than -amd, he opposed changing that for 2.9.023:47
brycenonetheless, I think we need to get it fixed and validated in intrepid before talking about sru's.23:49
bryceeven if we know changes are needed (like the -all change), it should be easy enough to test in intrepid first.  If it turns out that more is needed, then there seems little point in pushing an incomplete solution to hardy, esp. since 8.04.2 is a ways off anyway.23:50
Q-FUNKtrue, that23:51
Q-FUNKI'm still sad that the -all change didn't go thru23:51

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!