[05:24] <pwnguin> does anyone know what the hell is going on in bug #188787?
[05:27] <pwnguin> also, where'd the bot go?
[07:34] <tjaalton> pwnguin: didn't look at it closely, but the new package should fix that?
[07:36] <pwnguin> it might
[07:37] <pwnguin> wacom's changelogs are pretty vague and i dont build directly from them
[07:37] <pwnguin> is there a way to get a unified diff from a cvs repo?
[07:40] <pwnguin> reporter says it might not always work, but there's nothing in the upstream bugtracker
[08:20] <tjaalton> pwnguin: use -u
[09:02] <tjaalton> tseliot: what files/dirs were you referring to that nvidia can't ship?
[09:15] <tseliot> tjaalton: there are a few things
[09:15] <tseliot> too many "patches" dirs
[09:16] <tseliot> e.g. we don't need a patches dir in debian.binary
[09:16] <tseliot> we don't need a Makefile
[09:16] <tseliot> or a devfs.devices
[09:18] <tseliot> or nvidia_supported, etc.
[09:18] <tjaalton> you mean we don't have to patch the modules?
[09:19] <tjaalton> ever :)
[09:19] <tjaalton> if they don't break anything, I'd keep them there
[09:19] <tjaalton> to make the diff smaller
[09:19] <tjaalton> haven't looked inside the tarball yet
[09:20] <tseliot> we have a patches folder in debian.binary and 3 patches-related dirs in debian
[09:20] <tseliot> err not in debian
[09:20] <tseliot> in the main directory
[09:21] <tseliot> actually we might want to keep only the one in debian.binary
[09:22] <tseliot> and we'll also have to get rid of nvidia-settings since it's maintained separately
[09:23] <tjaalton> commented out already
[09:23] <tseliot> and I'm not comfortable with having a separate package such as nvidia-glx-ia32
[09:23] <tjaalton> the debian version does not have any debian/patches dir
[09:24] <tjaalton> it's not included in my version
[09:24] <tjaalton> if you looked at the diff
[09:24] <tseliot> I applied the diff. Maybe something went wrong
[09:24] <tjaalton> on top of which?
[09:24] <tjaalton> it's against the debian package
[09:25] <tseliot> the -4 revision of the package in unstable
[09:25] <tjaalton> right
[09:25] <tjaalton> look at debian/control
[09:25] <tseliot> control.in?
[09:25] <tjaalton> both
[09:26] <tseliot> you're right the ia32 package is commented out
[09:27] <tjaalton> patches.save or patches.dpatch.save are not used
[09:27] <tjaalton> the debian maintainer _might_ want to clean it up a bit..
[09:27] <tseliot> did you move such libraries to another dir in nvidia-glx in the debian/rules?
[09:27] <tjaalton> yes
[09:27] <tjaalton> usr/lib32
[09:27] <tseliot> ok, perfect
[09:27] <tjaalton> just open the diff, it's easier to see the changes :)
[09:30] <tseliot> ok, I'll use Kompare to do so
[09:30] <tjaalton> "less" is enough
[09:33] <tseliot> yes, I know but Kompare lets me browse through the files and see the changes, it's nice
[09:34] <tseliot> also we might want to remove the diversions created by both nvidia-glx-new and nvidia-glx-new-envy, etc.
[09:35] <tseliot> s/to remove/try to remove/
[09:36] <tseliot> since the -envy flavour should be a dummy package in Intrepid which will point to our packages (and to Mario's)
[09:36] <tjaalton> those should be removed by the packages itself
[09:36] <tjaalton> in postrm or so
[09:37] <tseliot> I was thinking of dist-upgrades, etc.
[09:37] <tseliot> I want to make sure that we don't break upgrades from Hardy to Intrepid, no matter what
[09:38] <tjaalton> ok so they are not touched on upgrade
[09:38] <tjaalton> currently
[09:40] <tseliot> and we'll have to be very careful about the Conflicts/Replaces in the control file
[09:40] <tseliot> not that I need to remind you of this
[09:40] <tseliot> ;)
[09:42] <tseliot> shall we make an additional package which contains a tarball such as the one which is currently provided by nvidia-kernel-source?
[09:42] <tjaalton> why?
[09:42] <tseliot> I'm asking you since nvidia-kernel-source will only contain the DKMS part
[09:42] <tjaalton> again, why? :)
[09:43] <tseliot> why what?
[09:43] <tjaalton> why can't it have both the source and dkms stuff?
[09:43] <tjaalton> why another package?
[09:44] <tseliot> should we put the same source twice in the same package?
[09:44] <tjaalton> I don't understand..
[09:44] <tseliot> the dkms source contains the content of that tarball + dkms.conf and other stuff
[09:44] <tjaalton> ah ok
[09:45] <tjaalton> that's enough imho
[09:45] <tseliot> and it will be installed to /usr/src
[09:45] <tseliot> ok, agreed
[09:46] <tseliot> do you think that Debian will ever accept our changes to this package?
[09:47] <tjaalton> no idea
[09:49] <tseliot> when 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 support
[10:32] <Q-FUNK> hm. seems that bryce's geode 2.9.0-1ubuntu2.1 doesn't work whereas my own package does.
[10:34] <Q-FUNK> this realy should have been done as per the debian 2.9.0-3 package
[10:34] <Q-FUNK> could video-all be updated to pull geode instead of amd?
[10:34] <Q-FUNK> amd really is a transitional package, nowadays
[10:35] <Q-FUNK> including in hardy
[10:36] <jcristau> what's the point? it's not like the transitional package is going away from hardy
[10:40] <Q-FUNK> removing the transitional package also removes -all
[10:41] <jcristau> then don't remove it :)
[10:41] <Q-FUNK> :-P
[10:41] <Q-FUNK> that kinda spoils the concept of transitional package now, doesn't it?
[10:43] <jcristau> maybe, but i don't quite see why that would warrant an update in a released version
[10:43] <jcristau> just my opinion, though
[13:02] <Q-FUNK> ok, 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:04] <Q-FUNK> the 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:07] <jcristau> uh
[13:07] <jcristau> that sounds wrong
[13:09] <Q-FUNK> how so?
[13:10] <jcristau> how does ltsp fail?
[13:15] <Q-FUNK> jcristau: the reverse-compatibility links between amd_drv.so and geode_drv.so break it
[13:16] <Q-FUNK> ditto if there's a link between amd.ids and geode.ids
[13:17] <jcristau> there should not be an amd.ids
[13:18] <Q-FUNK> why not?  
[13:19] <Q-FUNK> creates additional PCI ID conflicts as a result of the symbolic link?
[13:19] <jcristau> pci id conflicts are not an issue
[13:19] <jcristau> the server will just pick the first one it finds
[13:20] <Q-FUNK> why not then?
[13:20] <jcristau> you still haven't replied to my first question though. how does ltsp fail?
[13:20] <jcristau> because it's useless
[13:20] <Q-FUNK> fails to launch X
[13:20] <jcristau> how
[13:20] <jcristau> 'it fails' is somewhat vague...
[13:21] <Q-FUNK> if the symbolic links are there, X won't detect the Geode LX and falls back to console.
[13:21] <jcristau> meh
[13:21] <jcristau> that still doesn't give any detail
[13:21] <Q-FUNK> if the symbolic links are gone, X launches as expected
[13:21] <Q-FUNK> and uses the corrects driver
[13:22] <jcristau> have a log/config?
[13:22] <Q-FUNK> nope
[13:22] <jcristau> then get one
[13:22] <Q-FUNK> good luck on thta one. it all happens in a ramdisk.
[13:22] <jcristau> that's like the first step for any problem with x
[13:23] <Q-FUNK> except that here, simply A/B testing shows thta removing the symbolic links fixes it.
[13:23] <jcristau> you said you were dumped to the console. pretty sure you can get logs from there
[13:23] <Q-FUNK> no need to investigate any further.
[13:24] <Q-FUNK> no
[13:25] <Q-FUNK> LTSP disables console login and doesn't set any password for the squashfs that is used to get LDM 
[13:43] <tjaalton> http://www.googlefight.com/index.php?lang=en_GB&word1=TTM&word2=GEM
[13:46] <tseliot> LOL
[13:47] <tjaalton> hmm, http://www.googlefight.com/index.php?lang=en_GB&word1=translation+table+maps&word2=graphics+execution+manager
[20:03] <jcristau> you might want to remove xserver-xorg-video-newport from ubuntu
[20:07] <jcristau> (see debian bug 393709)
[20:09] <tjaalton> x-x-v-all should be changed too
[20:10] <jcristau> right
[20:10] <bryce> I just checked in a change to s/-amd/-geode/ to that
[20:10] <jcristau> i removed the -newport dependency in 1:7.3+11
[21:09] <tormod> which 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:53] <bryce> tormod: I don't know...  I'd have guessed mesa
[21:53] <tormod> bryce: yes, but which binary package?
[21:54] <tormod> maybe it should be included in the server itself now
[22:30] <bryce> tormod: libgl1-mesa-dev maybe?
[22:30] <bryce> tormod: hmm mesa-common-dev might be better
[22:37] <tormod> bryce, yes other files from the same source dir ends up there.
[22:43] <bryce> maybe tjaalton or jcristau could have something more useful to advise
[23:08] <tormod> the related bug is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354019
[23:24] <Q-FUNK> howdy
[23:27] <Q-FUNK> http://mentors.debian.net/debian/pool/main/x/xserver-xorg-video-geode/xserver-xorg-video-geode_2.9.0-4.dsc
[23:28] <Q-FUNK> I'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:29] <bryce> o_O
[23:30] <Q-FUNK> I know
[23:31] <Q-FUNK> but 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 barfs
[23:32] <Q-FUNK> and 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:33] <Q-FUNK> my 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 -geode
[23:34] <Q-FUNK> then 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 work
[23:35] <Q-FUNK> and 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:36] <Q-FUNK> for debian, the above -4 makes more sens,e since we've never had -amd in the first place.
[23:36] <bryce> I've checked in that change to git this morning
[23:37] <Q-FUNK> but we are too late for the hardy.1 release, right?
[23:37] <bryce> yup
[23:37] <Q-FUNK> :(
[23:38] <Q-FUNK> any way we can push 2.9.0-3 and -all with -geode instead of -amd into proposed for hardy.2 ?
[23:39] <bryce>  dunno
[23:39] <bryce> I guess I'd rather hold off until we know for certain what the fix is
[23:40] <bryce> it seems like there's been too many sru's for this -geode change, each time "this will definitely fix it", but it didn't
[23:41] <bryce> I 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 SRU
[23:44] <Q-FUNK> well, 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:45] <Q-FUNK> and keeping the symbolic links in -geode wasn't my idea of a fix either.
[23:46] <Q-FUNK> it rather was pitti's idea to keep all files within the established 2.8.0 packaging's idea.
[23:47] <Q-FUNK> and since 2.8.0 was released with the symbolic links in -geode rather than -amd, he opposed changing that for 2.9.0
[23:49] <bryce> nonetheless, I think we need to get it fixed and validated in intrepid before talking about sru's.
[23:50] <bryce> even 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:51] <Q-FUNK> true, that
[23:51] <Q-FUNK> I'm still sad that the -all change didn't go thru