Re: Testing/mesademos
Jon Pennington [EMAIL PROTECTED] writes: Absolutely! This is what I meant to say. Oh, sorry, I missunderstood. Shipping the mesademos package in binary form does not make any sense. There are too many libGL implementations floating around for that. Actually, this is a tempting reason to ship them as binaries. The program *can not* fail with "undefined symbol foobar". If it does, either the program is badly broken or the OpenGL implementation used to compile it is even more broken. But no, I'm not going to do this for this reason. Why compress them at all? Policy. I would install the files on /usr/shared/doc/mesademos/examples, which makes them documentation, which falls under this: Any additional documentation that comes with the package may be installed at the discretion of the package maintainer. Text documentation should be installed in a directory `/usr/share/doc/package', where package is the name of the package, and compressed with `gzip -9' unless it is small. -- Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing/mesademos
On Sat, Apr 07, 2001 at 10:26:13AM +0200, Marcelo E. Magallon wrote: Jon Pennington [EMAIL PROTECTED] writes: snip Shipping the mesademos package in binary form does not make any sense. There are too many libGL implementations floating around for that. Actually, this is a tempting reason to ship them as binaries. The program *can not* fail with "undefined symbol foobar". If it does, either the program is badly broken or the OpenGL implementation used to compile it is even more broken. But no, I'm not going to do this for this reason. A better reason would be because they are very handy for debugging and benchmarking the OpenGL implementations. For instance gears is a /very/ standard benchmark, and one of the first things I like people to run if they are having problems with the DRI drivers. Zephaniah E. Hull. snip -- Marcelo -- PGP EA5198D1-Zephaniah E. Hull [EMAIL PROTECTED]-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Upholder Seen on the back of a T-Shirt: "I am a bomb technician. If you see me running, try to keep up." PGP signature
Re: Testing/mesademos
On Sat, Apr 07, 2001 at 10:26:13AM +0200, Marcelo E. Magallon wrote: Jon Pennington [EMAIL PROTECTED] writes: Absolutely! This is what I meant to say. Oh, sorry, I missunderstood. It looked that way :) Shipping the mesademos package in binary form does not make any sense. There are too many libGL implementations floating around for that. Actually, this is a tempting reason to ship them as binaries. The program *can not* fail with "undefined symbol foobar". If it does, either the program is badly broken or the OpenGL implementation used to compile it is even more broken. But no, I'm not going to do this for this reason. Like Zeph said, though, the packages are most useful in source *because* you can use different libGL implementations to compile them. As I understand it (and I'm probably wrong), libGL implementations vary in the DRI project from one family of drivers to the next. Shipping binaries simply isn't a good idea the way I see it. (I smoke a lot of crack, though, so don't quote me) Why compress them at all? Policy. I would install the files on /usr/shared/doc/mesademos/examples, which makes them documentation, which falls under this: Any additional documentation that comes with the package may be installed at the discretion of the package maintainer. Text documentation should be installed in a directory `/usr/share/doc/package', where package is the name of the package, and compressed with `gzip -9' unless it is small. I see. Have you considered a better place for this to go? What about converting it from a Documentation class package to something that would fit under /usr/share/mesademos or similar? I'm going to contradict myself here What about going ahead and shipping them as a binary that *would* fit under /usr/bin or similar; going on and compiling them against the standard shipping Mesa package. This would mean that people using alternate libGLs would have to become familiar with dpkg-buildpkg (actually, I usually just use `apt-get source -b packagename'), but that may be a smaller price to pay in the long run. /contradiction -- -=|JP|=-"This space intentionally left blank." Jon Pennington | Debian 2.4 -o) [EMAIL PROTECTED] | Auto Enthusiast/\\ Kansas City, MO, USA| Proud Husband and Father _\_V -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
XFree86 4.0.3-0pre1v1 available for testing
As of this writing only i386 is available. I'm working on powerpc and
sparc for v2.
Architecture porters should note that the MANIFEST file for your arch will
need updating (see debian/402-to-403-MANIFEST-change), as will the
*.{dirs,files,links}.$(ARCH) files in some cases. *.files* are no longer
allowed to have anything but plain files in them.
The binary-arch and binary-indep rules are now idempotent. (Together, they
still take about 5 minutes to run on an IDE-based P3/800.) What this means
is that you can make changes on the "Debian side" of things without having
to rerun the install rule, let alone the build rule.
Otherwise, read the changelog and have fun!
Format: 1.7
Date: Sat, 7 Apr 2001 17:50:14 +
Source: xfree86
Binary: xserver-common xlibs-dev xfs xfree86-common xfonts-pex xlibmesa-dev xspecs
xlibmesa3 xfonts-cyrillic xlibmesa3-dbg xserver-xfree86 xlibs-dbg libxaw6 libxaw7
xterm xvfb xfonts-scalable xfonts-75dpi xlib6g proxymngr libxaw6-dev libdps1-dbg
xlib6g-dev xfonts-base xutils libxaw7-dev xnest xlibs libxaw6-dbg lbxproxy libxaw7-dbg
xbase-clients xprt xlibosmesa3 xlibosmesa-dev twm xfwp xlibosmesa3-dbg xfonts-100dpi
xdm libdps-dev libdps1
Architecture: source all i386
Version: 4.0.3-0pre1v1
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description:
lbxproxy - Low Bandwidth X (LBX) proxy server
libdps-dev - Display PostScript (DPS) client library development files
libdps1- Display PostScript (DPS) client library
libdps1-dbg - Display PostScript (DPS) client library (unstripped)
libxaw6- X Athena widget set library (version 6)
libxaw6-dbg - X Athena widget set library (version 6) (unstripped)
libxaw6-dev - X Athena widget set library development files (version 6)
libxaw7- X Athena widget set library
libxaw7-dbg - X Athena widget set library (unstripped)
libxaw7-dev - X Athena widget set library development files
proxymngr - X proxy services manager
twm- Tab window manager
xbase-clients - miscellaneous X clients
xdm- X display manager
xfonts-100dpi - 100 dpi fonts for X
xfonts-75dpi - 75 dpi fonts for X
xfonts-base - standard fonts for X
xfonts-cyrillic - Cyrillic fonts for X
xfonts-pex - fonts for minimal PEX support in X
xfonts-scalable - scalable fonts for X
xfree86-common - X Window System (XFree86) infrastructure
xfs- X font server
xfwp - X firewall proxy server
xlib6g - pseudopackage providing X libraries
xlib6g-dev - pseudopackage providing X library development files
xlibmesa-dev - XFree86 version of Mesa 3D graphics library development files
xlibmesa3 - XFree86 version of Mesa 3D graphics library
xlibmesa3-dbg - XFree86 version of Mesa 3D graphics library (unstripped)
xlibosmesa-dev - Mesa/XFree86 offscreen rendering library development files
xlibosmesa3 - Mesa/XFree86 offscreen rendering library
xlibosmesa3-dbg - Mesa/XFree86 offscreen rendering library (unstripped)
xlibs - X Window System client libraries
xlibs-dbg - X Window System client libraries (unstripped)
xlibs-dev - X Window System client library development files
xnest - nested X server
xprt - X print server
xserver-common - files and utilities common to all X servers
xserver-xfree86 - the XFree86 X server
xspecs - X protocol, extension, and library technical specifications
xterm - X terminal emulator
xutils - XFree86 utility programs
xvfb - virtual framebuffer X server
Closes: 74520 76214 77067 82328
Changes:
xfree86 (4.0.3-0pre1v1) unstable; urgency=low
.
* new upstream version (including some post-4.0.3 fixes)
* patch #002: remove specification of randomFile (Closes: #74520,#76214)
* patch #100: moved to held-patches since I hand-hacked all the non-free
stuff out of the Type1 font directory before generating the orig tarball
* patch #501: moved to held-patches since the xf86sym.c file has changed a
great deal and it is not immediately obvious to me what should be done for
m68k. Christian Steigies, please take a look at this.
* patch #600: removed the patch to xf86sym.c; it looks like this has
been applied upstream (Phil Blundell, you may want to confirm this)
* patches #700,701: removed; applied upstream
* patches #000,002,005,009,011,013,015: resynced with upstream
* massive overhaul of all maintainer scripts
- more canonical shell constructs in some places
- complete audit of actions taken when the maintainer scripts are called
with various arguments (see chapter 6 of the Debian Policy Manual)
- greatly reduce amounts of duplicate code by using a placeholder for
my "shell library"
- removed a few bits of logic that were present just to handle broken
upgrade scenarios between various pre-slink and pre-potato versions of
Re: XFree86 4.0.3-0pre1v1 available for testing
On Sat, Apr 07, 2001 at 03:17:19PM -0500, Branden Robinson wrote: As of this writing only i386 is available. I'm working on powerpc and sparc for v2. Hrm, forgot to mention this part: deb http://people.debian.org/%7Ebranden/ woody/$(ARCH)/ deb-src http://people.debian.org/%7Ebranden/ woody/source/ -- G. Branden Robinson | Debian GNU/Linux| If God had intended for man to go about [EMAIL PROTECTED] | naked, we would have been born that way. http://www.debian.org/~branden/ | PGP signature
Re: XFree86 4.0.3-0pre1v1 available for testing
On Sat, Apr 07, 2001 at 04:33:26PM -0500, Branden Robinson wrote: From: Branden Robinson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: XFree86 4.0.3-0pre1v1 available for testing Mail-Followup-To: [EMAIL PROTECTED] Mail-Copies-To: nobody On Sat, Apr 07, 2001 at 03:17:19PM -0500, Branden Robinson wrote: As of this writing only i386 is available. I'm working on powerpc and sparc for v2. Hrm, forgot to mention this part: deb http://people.debian.org/%7Ebranden/ woody/$(ARCH)/ deb-src http://people.debian.org/%7Ebranden/ woody/source/ Only have i386 available here, but works fine here. Tested sawfish, kde 2.1.x, and numerous applications. Best of all ... AA and regular font support with kde seems much improved. Not sure if X causes this or KDE .. either way, works very well for me. uname -a Linux home-desktop 2.4.3-ac3 #1 Wed Apr 4 17:39:45 CDT 2001 i686 unknown Gordon Sadler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dri and shared memory
Hello, I have installed the new dri packages, and at last I have 3gl, I am getting ~100 fps with the evas_test on my g400. but I do have on problem. With enlightenment and imlib1 it can't seem to detect the shared memory, which also seems to cause the latest version of gnome panel crash as well. Can anyone give me any ideas on how to resolve this problem -- Gordon Heydon [EMAIL PROTECTED]
Re: Testing/mesademos
Jon Pennington [EMAIL PROTECTED] writes: Absolutely! This is what I meant to say. Oh, sorry, I missunderstood. Shipping the mesademos package in binary form does not make any sense. There are too many libGL implementations floating around for that. Actually, this is a tempting reason to ship them as binaries. The program *can not* fail with undefined symbol foobar. If it does, either the program is badly broken or the OpenGL implementation used to compile it is even more broken. But no, I'm not going to do this for this reason. Why compress them at all? Policy. I would install the files on /usr/shared/doc/mesademos/examples, which makes them documentation, which falls under this: Any additional documentation that comes with the package may be installed at the discretion of the package maintainer. Text documentation should be installed in a directory `/usr/share/doc/package', where package is the name of the package, and compressed with `gzip -9' unless it is small. -- Marcelo
Re: Testing/mesademos
On Sat, Apr 07, 2001 at 10:26:13AM +0200, Marcelo E. Magallon wrote: Jon Pennington [EMAIL PROTECTED] writes: snip Shipping the mesademos package in binary form does not make any sense. There are too many libGL implementations floating around for that. Actually, this is a tempting reason to ship them as binaries. The program *can not* fail with undefined symbol foobar. If it does, either the program is badly broken or the OpenGL implementation used to compile it is even more broken. But no, I'm not going to do this for this reason. A better reason would be because they are very handy for debugging and benchmarking the OpenGL implementations. For instance gears is a /very/ standard benchmark, and one of the first things I like people to run if they are having problems with the DRI drivers. Zephaniah E. Hull. snip -- Marcelo -- PGP EA5198D1-Zephaniah E. Hull [EMAIL PROTECTED]-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Upholder Seen on the back of a T-Shirt: I am a bomb technician. If you see me running, try to keep up. pgpKY7QES64kK.pgp Description: PGP signature
Re: Testing/mesademos
On Sat, Apr 07, 2001 at 10:26:13AM +0200, Marcelo E. Magallon wrote: Jon Pennington [EMAIL PROTECTED] writes: Absolutely! This is what I meant to say. Oh, sorry, I missunderstood. It looked that way :) Shipping the mesademos package in binary form does not make any sense. There are too many libGL implementations floating around for that. Actually, this is a tempting reason to ship them as binaries. The program *can not* fail with undefined symbol foobar. If it does, either the program is badly broken or the OpenGL implementation used to compile it is even more broken. But no, I'm not going to do this for this reason. Like Zeph said, though, the packages are most useful in source *because* you can use different libGL implementations to compile them. As I understand it (and I'm probably wrong), libGL implementations vary in the DRI project from one family of drivers to the next. Shipping binaries simply isn't a good idea the way I see it. (I smoke a lot of crack, though, so don't quote me) Why compress them at all? Policy. I would install the files on /usr/shared/doc/mesademos/examples, which makes them documentation, which falls under this: Any additional documentation that comes with the package may be installed at the discretion of the package maintainer. Text documentation should be installed in a directory `/usr/share/doc/package', where package is the name of the package, and compressed with `gzip -9' unless it is small. I see. Have you considered a better place for this to go? What about converting it from a Documentation class package to something that would fit under /usr/share/mesademos or similar? I'm going to contradict myself here What about going ahead and shipping them as a binary that *would* fit under /usr/bin or similar; going on and compiling them against the standard shipping Mesa package. This would mean that people using alternate libGLs would have to become familiar with dpkg-buildpkg (actually, I usually just use `apt-get source -b packagename'), but that may be a smaller price to pay in the long run. /contradiction -- -=|JP|=-This space intentionally left blank. Jon Pennington | Debian 2.4 -o) [EMAIL PROTECTED] | Auto Enthusiast/\\ Kansas City, MO, USA| Proud Husband and Father _\_V
XFree86 4.0.3-0pre1v1 available for testing
As of this writing only i386 is available. I'm working on powerpc and
sparc for v2.
Architecture porters should note that the MANIFEST file for your arch will
need updating (see debian/402-to-403-MANIFEST-change), as will the
*.{dirs,files,links}.$(ARCH) files in some cases. *.files* are no longer
allowed to have anything but plain files in them.
The binary-arch and binary-indep rules are now idempotent. (Together, they
still take about 5 minutes to run on an IDE-based P3/800.) What this means
is that you can make changes on the Debian side of things without having
to rerun the install rule, let alone the build rule.
Otherwise, read the changelog and have fun!
Format: 1.7
Date: Sat, 7 Apr 2001 17:50:14 +
Source: xfree86
Binary: xserver-common xlibs-dev xfs xfree86-common xfonts-pex xlibmesa-dev
xspecs xlibmesa3 xfonts-cyrillic xlibmesa3-dbg xserver-xfree86 xlibs-dbg
libxaw6 libxaw7 xterm xvfb xfonts-scalable xfonts-75dpi xlib6g proxymngr
libxaw6-dev libdps1-dbg xlib6g-dev xfonts-base xutils libxaw7-dev xnest xlibs
libxaw6-dbg lbxproxy libxaw7-dbg xbase-clients xprt xlibosmesa3 xlibosmesa-dev
twm xfwp xlibosmesa3-dbg xfonts-100dpi xdm libdps-dev libdps1
Architecture: source all i386
Version: 4.0.3-0pre1v1
Distribution: unstable
Urgency: low
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description:
lbxproxy - Low Bandwidth X (LBX) proxy server
libdps-dev - Display PostScript (DPS) client library development files
libdps1- Display PostScript (DPS) client library
libdps1-dbg - Display PostScript (DPS) client library (unstripped)
libxaw6- X Athena widget set library (version 6)
libxaw6-dbg - X Athena widget set library (version 6) (unstripped)
libxaw6-dev - X Athena widget set library development files (version 6)
libxaw7- X Athena widget set library
libxaw7-dbg - X Athena widget set library (unstripped)
libxaw7-dev - X Athena widget set library development files
proxymngr - X proxy services manager
twm- Tab window manager
xbase-clients - miscellaneous X clients
xdm- X display manager
xfonts-100dpi - 100 dpi fonts for X
xfonts-75dpi - 75 dpi fonts for X
xfonts-base - standard fonts for X
xfonts-cyrillic - Cyrillic fonts for X
xfonts-pex - fonts for minimal PEX support in X
xfonts-scalable - scalable fonts for X
xfree86-common - X Window System (XFree86) infrastructure
xfs- X font server
xfwp - X firewall proxy server
xlib6g - pseudopackage providing X libraries
xlib6g-dev - pseudopackage providing X library development files
xlibmesa-dev - XFree86 version of Mesa 3D graphics library development files
xlibmesa3 - XFree86 version of Mesa 3D graphics library
xlibmesa3-dbg - XFree86 version of Mesa 3D graphics library (unstripped)
xlibosmesa-dev - Mesa/XFree86 offscreen rendering library development files
xlibosmesa3 - Mesa/XFree86 offscreen rendering library
xlibosmesa3-dbg - Mesa/XFree86 offscreen rendering library (unstripped)
xlibs - X Window System client libraries
xlibs-dbg - X Window System client libraries (unstripped)
xlibs-dev - X Window System client library development files
xnest - nested X server
xprt - X print server
xserver-common - files and utilities common to all X servers
xserver-xfree86 - the XFree86 X server
xspecs - X protocol, extension, and library technical specifications
xterm - X terminal emulator
xutils - XFree86 utility programs
xvfb - virtual framebuffer X server
Closes: 74520 76214 77067 82328
Changes:
xfree86 (4.0.3-0pre1v1) unstable; urgency=low
.
* new upstream version (including some post-4.0.3 fixes)
* patch #002: remove specification of randomFile (Closes: #74520,#76214)
* patch #100: moved to held-patches since I hand-hacked all the non-free
stuff out of the Type1 font directory before generating the orig tarball
* patch #501: moved to held-patches since the xf86sym.c file has changed a
great deal and it is not immediately obvious to me what should be done for
m68k. Christian Steigies, please take a look at this.
* patch #600: removed the patch to xf86sym.c; it looks like this has
been applied upstream (Phil Blundell, you may want to confirm this)
* patches #700,701: removed; applied upstream
* patches #000,002,005,009,011,013,015: resynced with upstream
* massive overhaul of all maintainer scripts
- more canonical shell constructs in some places
- complete audit of actions taken when the maintainer scripts are called
with various arguments (see chapter 6 of the Debian Policy Manual)
- greatly reduce amounts of duplicate code by using a placeholder for
my shell library
- removed a few bits of logic that were present just to handle broken
upgrade scenarios between various pre-slink and pre-potato versions of
the
Re: XFree86 4.0.3-0pre1v1 available for testing
On Sat, Apr 07, 2001 at 03:17:19PM -0500, Branden Robinson wrote: As of this writing only i386 is available. I'm working on powerpc and sparc for v2. Hrm, forgot to mention this part: deb http://people.debian.org/%7Ebranden/ woody/$(ARCH)/ deb-src http://people.debian.org/%7Ebranden/ woody/source/ -- G. Branden Robinson | Debian GNU/Linux| If God had intended for man to go about [EMAIL PROTECTED] | naked, we would have been born that way. http://www.debian.org/~branden/ | pgpSV8lIDDFHL.pgp Description: PGP signature
Re: Testing/mesademos
On Sat, Apr 07, 2001 at 12:38:18PM -0700, Jon Pennington wrote: On Sat, Apr 07, 2001 at 10:26:13AM +0200, Marcelo E. Magallon wrote: Jon Pennington [EMAIL PROTECTED] writes: Absolutely! This is what I meant to say. Oh, sorry, I missunderstood. It looked that way :) Shipping the mesademos package in binary form does not make any sense. There are too many libGL implementations floating around for that. Actually, this is a tempting reason to ship them as binaries. The program *can not* fail with undefined symbol foobar. If it does, either the program is badly broken or the OpenGL implementation used to compile it is even more broken. But no, I'm not going to do this for this reason. Like Zeph said, though, the packages are most useful in source *because* you can use different libGL implementations to compile them. As I understand it (and I'm probably wrong), libGL implementations vary in the DRI project from one family of drivers to the next. Shipping binaries simply isn't a good idea the way I see it. (I smoke a lot of crack, though, so don't quote me) Errm, a GL program compiled against /any/ libGL should work with any other libGL, if this is not the case then something is VERY broken. Of course, in this respect, the nVidia libGL is severely broken shit in the respect that if you compile a program against it you can't use that program with any other libGL, however those are not in Debian so we don't have to worry about it. (=:] Zephaniah E. Hull. -- -=|JP|=-This space intentionally left blank. Jon Pennington | Debian 2.4 -o) [EMAIL PROTECTED] | Auto Enthusiast/\\ Kansas City, MO, USA| Proud Husband and Father _\_V -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- PGP EA5198D1-Zephaniah E. Hull [EMAIL PROTECTED]-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. Microsoft is a cross between the Borg and the Ferengi. Unfortunately, they use Borg to do their marketing and Ferengi to do their programming. -- Simon Slavin in asr pgptK7KLj3SdS.pgp Description: PGP signature
Re: XFree86 4.0.3-0pre1v1 available for testing
On Sat, Apr 07, 2001 at 04:33:26PM -0500, Branden Robinson wrote: From: Branden Robinson [EMAIL PROTECTED] To: debian-x@lists.debian.org Subject: Re: XFree86 4.0.3-0pre1v1 available for testing Mail-Followup-To: debian-x@lists.debian.org Mail-Copies-To: nobody On Sat, Apr 07, 2001 at 03:17:19PM -0500, Branden Robinson wrote: As of this writing only i386 is available. I'm working on powerpc and sparc for v2. Hrm, forgot to mention this part: deb http://people.debian.org/%7Ebranden/ woody/$(ARCH)/ deb-src http://people.debian.org/%7Ebranden/ woody/source/ Only have i386 available here, but works fine here. Tested sawfish, kde 2.1.x, and numerous applications. Best of all ... AA and regular font support with kde seems much improved. Not sure if X causes this or KDE .. either way, works very well for me. uname -a Linux home-desktop 2.4.3-ac3 #1 Wed Apr 4 17:39:45 CDT 2001 i686 unknown Gordon Sadler
Re: Testing/mesademos
Zephaniah E. Hull [EMAIL PROTECTED] writes: For instance gears is a /very/ standard benchmark Yes, I know, I'm hand picking a few of the programs to provide them as binaries... gears is, well, something someone early on picked as a benchmark because it's fillrate bound (more accurately, at the default resolution I'm at the border between what my card can do and what my CPU can do, I guess you can call that luck). texenv is incredibly useful if you want to check things are ok (or that they behave the way you think they do). gloss and multiarb are also useful to check things are ok. At any rate I don't think everything in there is or general interest. If you have more suggestions... -- Marcelo
Re: Testing/mesademos
Jon Pennington [EMAIL PROTECTED] writes: Like Zeph said, though, the packages are most useful in source *because* you can use different libGL implementations to compile them. As I understand it (and I'm probably wrong), libGL implementations vary in the DRI project from one family of drivers to the next. No, they don't. They all use, atm, Mesa 3.4.1 as the basic renderer, some provide more hooks for hardware rendering, some provide less, but all use the same entry points, which is exactly my argument: a binary compiled with OpenGL foo is *not* *allowed* to fail with undefined symbols when run with OpenGL bar. If it does, either the program is broken (i.e., it's doing something it should not do, namely, linking extensions at compile time, there's glXGetProcAddressARB, learn to use it, damn it) or OpenGL foo is broken. I compiled and uploaded packages using xlibmesa-dev back when there was no xlibmesa-dev in woody, and noone even noticed. I see. Have you considered a better place for this to go? What about converting it from a Documentation class package to something that would fit under /usr/share/mesademos or similar? Well, the way I see it, it's documentation, not data. I *could* put them on /usr/src, but that's stretching it. -- Marcelo
