dri bug with 32bit emu
dri works fine using 32/32 kernel/user and 64/64, but not 64/32. i don't know anything about dri, but it's a binary interface where userland (xserver?) summits cmds and data to be sent to the 3d card, right? then it needs 32<->64 translation, just like ioctls. has anyone done any work on this? does anyone know how much work it would take to fix? -- Tom Vier <[EMAIL PROTECTED]> DSA Key ID 0x15741ECE
Re: unison 2.9.1 segfault on amd64
On Sat, Jul 24, 2004 at 03:42:34PM -0400, David Dumas wrote: > When I try to synchronize my laptop (running debian i386 unstable) > with my desktop (running debian amd64 unstable) the unison process on > the desktop segfaults just before starting to update files. > > Is anyone else experiencing this problem? > > (BTW I mentioned before that there isn't a segfault in debian amd64 > that recompiling with gcc 3.4 doesn't fix. I must now retract that > statement, though 3.4 is still the right way to go.) Not all bugs are bugs in gcc. Most of them are actually bugs in the programs that isn't 64 bit clean. Anyway, I suggest you file a bug against the package. This might be amd64 specific or it might be more general 64 bit problem. Kurt
unison 2.9.1 segfault on amd64
When I try to synchronize my laptop (running debian i386 unstable) with my desktop (running debian amd64 unstable) the unison process on the desktop segfaults just before starting to update files. Is anyone else experiencing this problem? (BTW I mentioned before that there isn't a segfault in debian amd64 that recompiling with gcc 3.4 doesn't fix. I must now retract that statement, though 3.4 is still the right way to go.)
VLC: no video displayed
I having trouble with VLC. When I use the vlc player I unable to see video while playing a certain wmv file, but the same file when played in wxvlc the video is displayed with out any problem. Has anyone else noticed similar problems. Thanks, Bharath --- Bharath Ramesh <[EMAIL PROTECTED]> http://csgrad.cs.vt.edu/~bramesh
Re: amd64 <-> x86_64
* Robert Millan ([EMAIL PROTECTED]) wrote: > On Fri, Jul 23, 2004 at 08:58:48PM +0200, Kurt Roeckx wrote: > > DEB_HOST_ARCH=amd64 > > DEB_HOST_GNU_CPU=x86_64 > > > This are the correct values. > > How do you determine when a value is correct? All I have seen so far are > arbitrary marketing decisions. Funny, the tech ctte ruled on it, with quite a few reasons outlined in their ruling. You might read it sometime. I'm mildly amused that you feel their decision is an 'arbitrary marketing decision'. > > This is also what the official dpkg > > returns since a few days ago. > > After all the hassle with the dpkg maintainers and the technical comitte, I'd > have never expected the amd64 porters to defend a naming scheme based on what > official dpkg returns. The point is that it returns what it does now because of the technical committee ruling and the desire of the porters. > > DEB_HOST_GNU_CPU is the the GNU tools use. They use x86_64 on > > The GNU tools (i.e. config.sub) accept both, so it's not an issue. The kernel also uses x86_64, as I recall. Certainly this is the arrangement that works and is being used currently. I see no justification for changing it. Stephen signature.asc Description: Digital signature
Re: amd64 <-> x86_64
* Robert Millan ([EMAIL PROTECTED]) wrote: > So your point is that "dual namings are not that bad". Ok. Now, how is this > dual naming actualy _better_ than the former scheme: > > DEB_HOST_ARCH = "x86-64" > DEB_HOST_GNU_CPU = "x86_64" > > To my eyes, the former scheme was at least consistent. If your answer is that > for some reason "amd64" is preferable to "x86-64", how is it the same reason > does not apply to "x86_64"? amd64 is preferred for DEB_HOST_ARCH. DEB_HOST_GNU_CPU isn't something we control. This has been discussed in great detail on this list in the past. I encourage you to review the archives and threads of that discussion. Stephen signature.asc Description: Digital signature
Re: amd64 <-> x86_64
On Fri, Jul 23, 2004 at 08:58:48PM +0200, Kurt Roeckx wrote: > > It returns: > > DEB_HOST_ARCH=amd64 > DEB_HOST_GNU_CPU=x86_64 > This are the correct values. How do you determine when a value is correct? All I have seen so far are arbitrary marketing decisions. > This is also what the official dpkg > returns since a few days ago. After all the hassle with the dpkg maintainers and the technical comitte, I'd have never expected the amd64 porters to defend a naming scheme based on what official dpkg returns. > DEB_HOST_GNU_CPU is the the GNU tools use. They use x86_64 on The GNU tools (i.e. config.sub) accept both, so it's not an issue. -- Robert Millan (Debra and Ian) (Gnu's Not (UNiplexed Information and Computing System))/\ (kernel of *(Berkeley Software Distribution))
Re: amd64 <-> x86_64
On Fri, Jul 23, 2004 at 02:54:19PM -0400, Stephen Frost wrote: > * Robert Millan ([EMAIL PROTECTED]) wrote: > > Now that the technical comitte has ruled in favour of 'amd64' for the debian > > archname (DEB_HOST_ARCH variable), I wonder what will happen with the other > > dpkg-architecture variables, which are actualy much more important than > > the architecture name dpkg uses internaly to identify debian ports. > > DEB_HOST_ARCH = "amd64" > DEB_HOST_GNU_CPU = "x86_64" > etc. > > Users and developers can understand it. It's hardly a 'dual naming', > and if you're going to be concerned about it being one go look at all of > the *other* 'dual naming's we have in Debian already. So your point is that "dual namings are not that bad". Ok. Now, how is this dual naming actualy _better_ than the former scheme: DEB_HOST_ARCH = "x86-64" DEB_HOST_GNU_CPU = "x86_64" To my eyes, the former scheme was at least consistent. If your answer is that for some reason "amd64" is preferable to "x86-64", how is it the same reason does not apply to "x86_64"? -- Robert Millan (Debra and Ian) (Gnu's Not (UNiplexed Information and Computing System))/\ (kernel of *(Berkeley Software Distribution))
