Bug#255270: xfree86: libglide3 has now ia64 and amd64 support

2004-07-17 Thread Matthew Wilcox
On Sat, Jul 17, 2004 at 05:43:06AM +0200, Guillem Jover wrote:
 Could someone with an amd64, ia64 or alpha (I'll take care of i386)
 and a 3Dfx card with any of the following chipsets:
 
   Voodoo Banshee, Voodoo 3, Voodoo 4 or Voodoo 5

I don't *think* you're going to get any takers on ia64.  I think the
workstations have all shipped with ATI or NVidia cards to date.

-- 
Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception. -- Mark Twain




Bug#255270: xfree86: libglide3 has now ia64 and amd64 support

2004-07-17 Thread Duraid Madina

Matthew Wilcox wrote:

On Sat, Jul 17, 2004 at 05:43:06AM +0200, Guillem Jover wrote:


Could someone with an amd64, ia64 or alpha (I'll take care of i386)
and a 3Dfx card with any of the following chipsets:

Voodoo Banshee, Voodoo 3, Voodoo 4 or Voodoo 5


I put a PCI voodoo 3 in this ia64 box (HP zx6000) and it failed (hard - 
the BIOS hung). I very much doubt the other voodoo cards would work, 
unless they have firmware that _doesn't_ set the I'm a VGA card PCI bits.


Anyhow, let this be a warning to anyone else crazy enough to try

Duraid




Bug#255270: xfree86: libglide3 has now ia64 and amd64 support

2004-07-17 Thread David Mosberger
 On Sat, 17 Jul 2004 05:40:31 +0100, Matthew Wilcox [EMAIL PROTECTED] 
 said:

  Matthew On Sat, Jul 17, 2004 at 05:43:06AM +0200, Guillem Jover wrote:
   Could someone with an amd64, ia64 or alpha (I'll take care of i386)
   and a 3Dfx card with any of the following chipsets:

   Voodoo Banshee, Voodoo 3, Voodoo 4 or Voodoo 5

  Matthew I don't *think* you're going to get any takers on ia64.  I think the
  Matthew workstations have all shipped with ATI or NVidia cards to date.

We use to demo OpenGL hw accel with a Merced workstation with a Voodoo
3 card (I think it was Voodoo 3).  Unfortunately, the card is a 5V PCI
card which cannot be used in the zx1-based workstations anymore, so I
stopped using it.

--david




Re: warning

2004-07-17 Thread libero . adsl
Gentile Cliente,

se desidera maggiori informazioni sulle offerte Libero ADSL visiti il sito 
http://internet.libero.it o chiami il 159;

se è già nostro cliente e ha bisogno di assistenza la invitiamo a visitare il 
sito www.155.it o a chiamare l'155.

Grazie per l'attenzione.

Lo Staff di Libero ADSL



Processed: Re: Bug#259215: mozilla-firefox: firefox fails to start with 'Xlib: connection to :0.0 refused by server'

2004-07-17 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]:

 severity 259215 normal
Bug#259215: mozilla-firefox: firefox fails to start with 'Xlib: connection to 
:0.0 refused by server'
Severity set to `normal'.

 reassign 259215 xdm
Bug#259215: mozilla-firefox: firefox fails to start with 'Xlib: connection to 
:0.0 refused by server'
Bug reassigned from package `mozilla-firefox' to `xdm'.

 thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)



Processed: merging, take 2

2004-07-17 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]:

 severity 259786 wishlist
Bug#259786: xserver-xfree86: Mouse is blocking
Severity set to `wishlist'.

 merge 259786 237395
Bug#237395: netcfg: Please give choice of whether to try DHCP
Bug#259786: xserver-xfree86: Mouse is blocking
Mismatch - only Bugs in same state can be merged:
Values for `package' don't match:
 #237395 has `netcfg';
 #259786 has `xserver-xfree86'

 quit smoking today
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)



Bug#259639: xserver-xfree86: [ati] X starts a bit, then returns to console; [drm:radeon_unlock] *ERROR* Process 1389 using kernel context 0

2004-07-17 Thread Michel Dänzer
On Fri, 2004-07-16 at 14:00 +0200, Shot wrote:
 
  I googled some more and did `chmod ug+s /usr/bin/X11/XFree86`:
  
  [EMAIL PROTECTED]:~$ ll /usr/bin/X11/XFree86
  -rwsr-sr-x  1 root root 1745388 2004-07-07 17:07 /usr/bin/X11/XFree86
  
  Now, the `XFree86 ... gnome-session` starts X and puts me on the
  spotted gray background with the usual X cursor (and nothing more
  happens, I have to kill the server with Ctrl-Alt-Backspace), while
  `startx` still doesn't work, in the same way it didn't before the
  chmod (that is - shows the background for a second or two and drops
  me back to the commandline).
 
 Ok, I checked some more things and the current situation is this:
 
 `startx` issued form the root's console puts me in root's GNOME
 `sudo startx` with suided XFree86 puts me in root's GNOME
 `sudo startx` without suided XFree86 stops at the gray screen
 
 It seems it's something with the access
 privileges, I just can't put my finger on it...

The initial problem wasn't this but that your session exits immediately.
You need to find out why.


-- 
Earthling Michel Dänzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer




Bug#259828: tabs mangled to spaces when copying from xterm

2004-07-17 Thread Thomas Dickey
On Fri, Jul 16, 2004 at 09:18:14PM -0400, Lee Revell wrote:
   It seems like the mouse thing would be easy, if a click starts inside a
   tab, that tab is part of the selection region.  Same policy as clicking
   on a space, you just treat tab as a big space.  Then again I have never
   hacked a terminal program so I can't really say.
  
  It's more complicated than that.  xterm stores tabs expanded, and uses
  that in repainting (iirc, essentially the proposed patch set a bit at
  the beginning of the tab, so all that was left was to make the selection
  mechanism work).
 
 Ah, ok.  Well, someone will fix this eventually.  Maybe I will make a
 feature request for gnome terminal.  Thanks for the info.

no problem (I may, on review of the patch I have, decide it's simpler to
finish off than I would be thinking late on a Friday...)

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgp6gf0CoIgef.pgp
Description: PGP signature


Bug#259639: xserver-xfree86: [ati] X starts a bit, then returns to console; [drm:radeon_unlock] *ERROR* Process 1389 using kernel context 0

2004-07-17 Thread Shot
Hello.

Michel Dänzer:

 On Fri, 2004-07-16 at 14:00 +0200, Shot wrote:
  
  Ok, I checked some more things and the current situation is this:
  
  `startx` issued form the root's console puts me in root's GNOME
  `sudo startx` with suided XFree86 puts me in root's GNOME
  `sudo startx` without suided XFree86 stops at the gray screen
  
  It seems it's something with the access
  privileges, I just can't put my finger on it...
 
 The initial problem wasn't this but that your session exits immediately.
 You need to find out why.

You're right; all the fiddling with suid bits, setting XAUTHORITY
variable to /home/shot/.Xauthority and running sudo ended with
my user's ~/.Xauthority being root:root and having .Xauthority-c
and -l files created in /home/shot. At least I got rid of the
[drm:radeon_unlock] dmesg error by commenting out the dri module
and adding Option DRI False to my graphic card settings.
I moved my ~/.Xauthority to something else and it got recreated
as shot:shot, so at least here everything seems ok.

Today I got the (er, obvious...) idea of trying to run X/GNOME
as another regular user (marta), and so far I know this:

root's `startx` and `XFree86 :0 -nolisten tcp -dpi 100  sleep 2 
DISPLAY=:0.0 gnome-session` put him in a working GNOME.

marta's `startx` puts her in GNOME, and she could `XFree86...` *once* to
get to GNOME, but subsequent tries end with the Cannot move old logfile
/var/log/XFree86.0.log.old fatal error. This account never ran X
before today.

shot's `startx` ends up in that immediate session exit, while
`XFree86...` gives the same Cannot move old logfile error.

Cheers,
-- Shot (Piotr Szotkowski)
-- 
.--- http://shot.pl/ --- http://shot.pl/hovercraft/ --- -- -
| The above comment may be extremely inflamatory.
| For your protection, it has been rot13'd twice.
| -- JWhitlock, /.
`-  --- -- -



Bug#259639: xserver-xfree86: [ati] X starts a bit, then returns to console; [drm:radeon_unlock] *ERROR* Process 1389 using kernel context 0

2004-07-17 Thread Shot
Hello.

Shot:

 shot's `startx` ends up in that immediate session exit, while
 `XFree86...` gives the same Cannot move old logfile error.

Sigh. So I've finally learned about the ~/.xsession-errors
file, and, sure enough, at the end of it was the line

** (gnome-session:13910): WARNING **: Unable to read ICE authority file: 
/home/shot/.ICEauthority

After chmodding ~/.ICEauthority from root:root to shot:shot everythings
works again. Sorry for taking your time and filing an important
bug against the wrong package; all I can say in my defense is that
~/.ICEauthority must've somehow chagned to root:root around the same
time I upgraded X to 4.3.0.dfsg.1-6.

Thanks again for your time and please close this bug.

Cheers,
-- Shot (Piotr Szotkowski)
-- 
.--- http://shot.pl/ --- http://shot.pl/hovercraft/ --- -- -
| Like most computer techie people, I'll happily spend 6 hours
| trying to figure out how to do a 3 hour job in 10 minutes.
| -- Rev. James Cort, alt.sysadmin.recovery
`-  --- -- -



Bug#232357: mkdirhier patch

2004-07-17 Thread Justin Pryzby
The attached script fixes the problem by adding a conditional.  Its not
a beautiful solution, but the original has similar workarounds:

(# IFS parsing is broken)

Someone should forward upstream (whatever that is these days) and
beautify to taste.  The original complaint is at [1].

Justin

PS.  Greetings from Potsdam, NY, USA!

References

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=141347

#!/bin/sh
# $Xorg: mkdirhier.sh,v 1.3 2000/08/17 19:41:53 cpqbld Exp $
# Courtesy of Paul Eggert

newline='
'
IFS=$newline

case ${1--} in
-*) echo 2 mkdirhier: usage: mkdirhier directory ...; exit 1
esac

status=

for directory
do
case $directory in
'')
echo 2 mkdirhier: empty directory name
status=1
continue;;
*$newline*)
echo 2 mkdirhier: directory name contains a newline: 
\`\`$directory''
status=1
continue;;
///*) prefix=/;; # See Posix 2.3 path.
//*) prefix=//;;
/*) prefix=/;;
-*) prefix=./;;
*) prefix=
esac

IFS=/
set x $directory
case $2 in
*/*)# IFS parsing is broken
IFS=' '
set x `echo $directory | tr / ' '`
;;
esac
IFS=$newline
shift

for filename
do
path=$prefix$filename

if [ $path == / ]; then prefix=$path;
else prefix=$path/;
fi;

shift

test -d $path || {
paths=$path
for filename
do
if [ -n $filename -a $filename != . ]; 
then
path=$path/$filename
paths=$paths$newline$path
fi
done

mkdir $paths || status=$?

break
}
done
  done

exit $status


signature.asc
Description: Digital signature


Processed: tagging 232357

2004-07-17 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]:

 tags 232357 upstream patch confirmed
Bug#232357: xutils: [mkdirhier] creates wrong path
There were no tags set.
Tags added: upstream, patch, confirmed


End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)



Bug#259996: xterm: keybinding tables in manpage

2004-07-17 Thread Sebastian Kapfer
Package: xterm
Version: 4.3.0.dfsg.1-6
Severity: normal

The keybinding tables in the xterm manpage don't format correctly here.
It seems like the newline characters aren't interpreted by groff.

It looks like this:

   The default bindings in the VT102 window are:
Shift KeyPress Prior:scroll‐back(1,halfpage) \n  
 Shift KeyPress Next:scroll‐forw(1,halfpage) \n 
 Shift KeyPress Select:select‐cursor‐start()

(more mess here...)


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.6-nexus-14
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8

Versions of packages xterm depends on:
ii  libc6 2.3.2.ds1-13   GNU C Library: Shared libraries an
ii  libexpat1 1.95.6-8   XML parsing C library - runtime li
ii  libfontconfig12.2.3-1generic font configuration library
ii  libfreetype6  2.1.7-2.1  FreeType 2 font engine, shared lib
ii  libice6   4.3.0.dfsg.1-6 Inter-Client Exchange library
ii  libncurses5   5.4-4  Shared libraries for terminal hand
ii  libsm64.3.0.dfsg.1-6 X Window System Session Management
ii  libxaw7   4.3.0.dfsg.1-5 X Athena widget set library
ii  libxext6  4.3.0.dfsg.1-5 X Window System miscellaneous exte
ii  libxft2   2.1.2-6FreeType-based font drawing librar
ii  libxmu6   4.3.0.dfsg.1-5 X Window System miscellaneous util
ii  libxpm4   4.3.0.dfsg.1-6 X pixmap library
ii  libxrender1   0.8.3-7X Rendering Extension client libra
ii  libxt64.3.0.dfsg.1-6 X Toolkit Intrinsics
ii  xlibs 4.3.0.dfsg.1-5 X Window System client libraries m
ii  xlibs-data4.3.0.dfsg.1-5 X Window System client data

-- no debconf information



Bug#256442: [ATTACHED] iBook G4 British keymap

2004-07-17 Thread Branden Robinson
On Thu, Jul 15, 2004 at 01:36:51PM +0100, Sam Halliday wrote:
 Branden Robinson wrote:
  I am not opposed to having an XkbOption called altwin:macosx, for
  example, for people who seek Mac OS X compatibility, but I am skeptical
  that this should be the default.
 
 i like this. how can it be implemented?

You'd add a section to /etc/X11/xkb/symbols/altwin that will look much like
the others, and update /etc/X11/xkb/rules/xfree86{,.lst,.xml} to know about
it.

However, to get the modifier mappings working right, it looks like we'll
have to backport a feature from XFree86 CVS that was committted in late
2003.

-- 
G. Branden Robinson| If the jury can count higher than
Debian GNU/Linux   | two, the case will fail.
[EMAIL PROTECTED] | -- Tom Lane, on Forgent's claim of
http://people.debian.org/~branden/ |a patent on JPEG


signature.asc
Description: Digital signature


Bug#257142: xutils: makedepend looks for stddef.h, stdarg.h (and others) in wrong directories

2004-07-17 Thread Branden Robinson
On Fri, Jul 16, 2004 at 11:47:06AM +0200, Fred JEAN wrote:
 Branden Robinson a écrit :
 Can you provide a reproduction recipe for this bug, please?

 Sorry , I'm not an expert...
 I'm not sure to understand  what you want !
 
 Here is the whole story :
 I tried to install the ncarg libraries 
 (http://ngwww.ucar.edu/ng4.3/index.html) from sources using the standard 
 step by step procedure described in the INSTALL file, after having 
 installed debian packages for required X11 libraries.
 
 During the 'make everything' of the install process of those libraries, 
 I noticed the warnings mentionned in my email.
 
 Hope this help you
 
 Thanks for your help

Yes, this looks like enough for other people to duplicate your problem for
themselves.

Thanks for following up!

-- 
G. Branden Robinson|
Debian GNU/Linux   |   Extra territorium jus dicenti
[EMAIL PROTECTED] |   impune non paretur.
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature


Bug#239510: marked as done (xterm: [-+]rv command-line options and reverseVideo resource seem to have no effect)

2004-07-17 Thread Debian Bug Tracking System
Your message dated Sat, 17 Jul 2004 15:08:31 -0500
with message-id [EMAIL PROTECTED]
and subject line Bug#239510: xterm: Reverse video specification broken
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 23 Mar 2004 02:51:45 +
From [EMAIL PROTECTED] Mon Mar 22 18:51:45 2004
Return-path: [EMAIL PROTECTED]
Received: from glockenspiel.complete.org [69.10.152.57] 
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1B5c13-0007Gq-00; Mon, 22 Mar 2004 18:51:45 -0800
Received: from localhost (localhost [127.0.0.1])
by glockenspiel.complete.org (Postfix) with ESMTP id 1D70B35
for [EMAIL PROTECTED]; Mon, 22 Mar 2004 20:51:49 -0600 (CST)
Received: from glockenspiel.complete.org ([127.0.0.1])
by localhost (glockenspiel [127.0.0.1]) (amavisd-new, port 10025)
with ESMTP id 20304-03 for [EMAIL PROTECTED];
Mon, 22 Mar 2004 20:51:47 -0600 (CST)
Received: from erwin.complete.org (unknown [12.149.180.20])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN erwin.complete.org, Issuer John Goerzen -- Root CA 
(verified OK))
by glockenspiel.complete.org (Postfix) with ESMTP id A33D7469
for [EMAIL PROTECTED]; Mon, 22 Mar 2004 20:51:43 -0600 (CST)
Received: from katherina.lan.complete.org (katherina.lan.complete.org 
[10.200.0.4])
by erwin.complete.org (Postfix) with ESMTP
id 5AFF91688; Mon, 22 Mar 2004 20:51:33 -0600 (CST)
Received: by katherina.lan.complete.org (Postfix, from userid 1000)
id C19553E028; Mon, 22 Mar 2004 20:51:33 -0600 (CST)
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: John Goerzen [EMAIL PROTECTED]
To: Debian Bug Tracking System [EMAIL PROTECTED]
Subject: xterm: Reverse video specification broken
X-Mailer: reportbug 2.53
Date: Mon, 22 Mar 2004 20:51:33 -0600
Message-Id: [EMAIL PROTECTED]
X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at complete.org
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_12 
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-7.0 required=4.0 tests=BAYES_00,HAS_PACKAGE 
autolearn=no version=2.60-bugs.debian.org_2004_03_12
X-Spam-Level: 

Package: xterm
Version: 4.3.0-7
Severity: normal

Hello,

xterm, on startup, always displays black text on a white background.
That is, the following three commands do the exact same thing:

xterm
xterm -rv
xterm +rv

Also, specifying XTerm*reverseVideo: true does not alter the startup
colors.

However, selecting reverse video from the middle-mouse-button menu will
toggle the colors.

I'm somewhat puzzled.

-- John

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.4
Locale: LANG=C, LC_CTYPE=C

Versions of packages xterm depends on:
ii  libc6   2.3.2.ds1-11 GNU C Library: Shared libraries an
ii  libexpat1   1.95.6-8 XML parsing C library - runtime li
ii  libfontconfig1  2.2.2-1  generic font configuration library
ii  libfreetype62.1.7-2  FreeType 2 font engine, shared lib
ii  libice6 4.3.0-7  Inter-Client Exchange library
ii  libncurses5 5.4-2Shared libraries for terminal hand
ii  libsm6  4.3.0-7  X Window System Session Management
ii  libxaw7 4.3.0-7  X Athena widget set library
ii  libxext64.3.0-7  X Window System miscellaneous exte
ii  libxft2 2.1.2-6  FreeType-based font drawing librar
ii  libxmu6 4.3.0-7  X Window System miscellaneous util
ii  libxpm4 4.3.0-7  X pixmap library
ii  libxrender1 0.8.3-7  X Rendering Extension client libra
ii  libxt6  4.3.0-7  X Toolkit Intrinsics
ii  xlibs   4.3.0-7  X Window System client libraries m
ii  xlibs-data  4.3.0-7  X Window System client data

-- no debconf information

---
Received: (at 239510-done) by bugs.debian.org; 17 Jul 2004 20:08:32 +
From [EMAIL PROTECTED] Sat Jul 17 13:08:32 2004
Return-path: [EMAIL PROTECTED]
Received: from dhcp065-026-182-085.indy.rr.com (sisyphus.deadbeast.net) 

Bug#258874: xbase-clients: startx hangs on startup with configured network which isn'tconnected

2004-07-17 Thread Branden Robinson
On Fri, Jul 16, 2004 at 08:57:10AM +0300, Micha Feigin wrote:
 On Wed, Jul 14, 2004 at 02:16:00AM -0500, Branden Robinson wrote:
  On Wed, Jul 14, 2004 at 02:13:58AM -0500, Branden Robinson wrote:
Running startx -- :1 when another session of X is already running will
not hang BTW.
  
  Something just occurred to me.
  
  If my guess is right, this will break exactly the same way if you do this:
  
  startx -- :1 -nolisten tcp
  
  Please try that.
 
 This has the exact same behavior as startx -- :1 or running wdm (I am
 guessing you wanted me to run the full .xsession here and not just an
 xterm as before). It locks up when no cable is plugged in and there is
 no X already running (if X is already running on another display it
 doesn't lock).
 
 It shouldn't be something in .xsession thats locking since wdm also
 locks and X locks right on startup before .xsession has a time to be run.
 
 I tried another thing and just ran X alone (/usr/bin/X11/X), not through
 startx. It also locks up on the network timeout. It seems that X the
 culprit that's trying to resolve the hostname either when it shouldn't or
 in a wrong manner (bypassing /etc/hosts).

Okay; my theory was wrong.  I am running out of ideas.

-- 
G. Branden Robinson|  A fundamentalist is someone who
Debian GNU/Linux   |  hates sin more than he loves
[EMAIL PROTECTED] |  virtue.
http://people.debian.org/~branden/ |  -- John H. Schaar


signature.asc
Description: Digital signature


Bug#259996: xterm: keybinding tables in manpage

2004-07-17 Thread Thomas Dickey
On Sat, Jul 17, 2004 at 10:00:13PM +0200, Sebastian Kapfer wrote:
 Package: xterm
 Version: 4.3.0.dfsg.1-6
 Severity: normal
 
 The keybinding tables in the xterm manpage don't format correctly here.
 It seems like the newline characters aren't interpreted by groff.
 
 It looks like this:
 
The default bindings in the VT102 window are:
 Shift KeyPress Prior:scroll???back(1,halfpage) \n  
  Shift KeyPress Next:scroll???forw(1,halfpage) \n 
  Shift KeyPress Select:select???cursor???start()
 (more mess here...)

I believe that's not groff, but the preprocessing stage that substitutes the
section number, etc.

(I don't see a cause for the \xE2\x80\x90 (UTF-8) since the original and
processed files I can look at don't have any sign of that).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


pgp0Zismjq1kN.pgp
Description: PGP signature


Bug#255270: xfree86: libglide3 has now ia64 and amd64 support

2004-07-17 Thread Branden Robinson
[Apolgies for the big CC -- I have no idea who's subscribed to which
lists.  I'm reading this via [EMAIL PROTECTED].]

On Sat, Jul 17, 2004 at 02:48:54PM +1000, Duraid Madina wrote:
 Matthew Wilcox wrote:
 On Sat, Jul 17, 2004 at 05:43:06AM +0200, Guillem Jover wrote:
 
 Could someone with an amd64, ia64 or alpha (I'll take care of i386)
 and a 3Dfx card with any of the following chipsets:
 
 Voodoo Banshee, Voodoo 3, Voodoo 4 or Voodoo 5
 
 I put a PCI voodoo 3 in this ia64 box (HP zx6000) and it failed (hard - 
 the BIOS hung). I very much doubt the other voodoo cards would work, 
 unless they have firmware that _doesn't_ set the I'm a VGA card PCI bits.
 
 Anyhow, let this be a warning to anyone else crazy enough to try

I wonder if it would be possible to run such a card as the secondary card.

Or would the problem you describe happen anyway, even with an
IA64(EFI?)-friendly video card also in the machine?

-- 
G. Branden Robinson|  I came, I saw, she conquered.
Debian GNU/Linux   |  The original Latin seems to have
[EMAIL PROTECTED] |  been garbled.
http://people.debian.org/~branden/ |  -- Robert Heinlein


signature.asc
Description: Digital signature


Bug#255270: xfree86: libglide3 has now ia64 and amd64 support

2004-07-17 Thread Duraid Madina

Branden Robinson wrote:

[Apolgies for the big CC -- I have no idea who's subscribed to which
lists.  I'm reading this via [EMAIL PROTECTED].]
I put a PCI voodoo 3 in this ia64 box (HP zx6000) and it failed (hard - 
the BIOS hung). I very much doubt the other voodoo cards would work, 
unless they have firmware that _doesn't_ set the I'm a VGA card PCI bits.


I wonder if it would be possible to run such a card as the secondary card.

Or would the problem you describe happen anyway, even with an
IA64(EFI?)-friendly video card also in the machine?


On zx1 systems (including the HP zx2000 and zx6000, the only 
workstation Itanium systems currently made) I suspect the machine 
might die anyway when X tries to initialize the second card (i.e. when 
the int10 module tries to run the card's BIOS) - assuming it doesn't get 
initialized earlier.


Having said that, it's entirely possible that on other systems, such as 
anything with the rather common E8870 chipset, things might work OK.


Shouldn't someone just write a glide-OpenGL wrapper and be done with it? ;)

Duraid