Hi Aaron,
On Thu, May 25, 2006 at 03:01:07PM -0400, Aaron M. Ucko wrote:
backfires badly, yielding unusable binary packages. In addition, the
new approach seems to be major overkill -- whereas 6.4.1-0.4 shipped
349 files totalling ~7.6M, 6.4.2-1 ships 1060 files totalling ~18.3M.
Ah,
On Wed, May 24, 2006 at 02:02:22PM +0100, Andy Parkins wrote:
As it turns out this problem is caused by the snapshot builds using
outdated Xorg 6.9 sources that are incompatible with the current i915
driver from Mesa. i915 snapshots 20060123 and older should still be
OK.
So I guess
Hi,
On Mon, May 22, 2006 at 09:39:14PM -0400, David Nusinow wrote:
Now that Xorg 7.1 is out, we need to work out some plan for actually
uploading 6.5 to the archive. My current plan is to stage 7.1 in
experimental very soon, and then when it's stabilized move it to
unstable. Since Brian
On Thu, May 04, 2006 at 06:14:13PM +0200, Michael Banck wrote:
the attached patch fixes this problem in the most elegant way I could
come up with given the make-me-harder attitude of mesa's
debian/rules. If somebody has a better suggestion, I'd be happy to
know :)
Whatever. If don't
On Wed, Apr 19, 2006 at 10:35:44AM +0200, Michel Dänzer wrote:
Mesa 6.5 is a development release with known problems. Should that be
allowed to migrate to testing? It's my impression that the semantics
you seem to attribute to sid have mostly shifted to experimental and
that sid is mostly
On Wed, Apr 19, 2006 at 06:58:55PM +1000, Drew Parsons wrote:
The Xprint server has OpenGL support which is switched by identifying
the mesa source. I'm not entirely certain what it's for, I presume
it's for grabbing a snapshot of the current GL image in a window, for
sending to a
Package: libxklavier10
Version: 2.2-2
Severity: grave
Justification: renders package unusable
Tags: patch
This fixes a bug that has been bothering a rather large ammount of
people. AFAICS libxklavier can't do zilch without this fix.
The patch:
---
On Thu, Sep 01, 2005 at 02:58:19PM +1000, Daniel Stone wrote:
Right. My solution for that was to split them into a separate
mesa-utils source package, with a slightly hacked Makefile. They
build just fine independently.
Ah, you mean the utils! The demos are shipped in a separate
On Sat, Sep 03, 2005 at 05:30:52PM -0400, Michel Dänzer wrote:
I tried building from SVN:
[...]
mkdir -p debian/stamp/ touch debian/stamp/target-gl-debian-debug
dh_testdir
chmod +x debian/shadowtree
rm -f -rf build/gl-debian-debug-i386
debian/shadowtree
On Wed, Aug 31, 2005 at 02:41:05AM +0200, Michael Biebl wrote:
It seems that mesa (6.3.2) as well as xorg (6.8.2) both provide a
GL/GLU implemetation.
If you look at:
On Wed, Aug 31, 2005 at 10:35:55PM -0400, Michel Dänzer wrote:
Is this an attempt to smooth the transition from the xorg
packages to the mesa ones and in the course of the X
modularisation to get completely rid of the GL/GLU code in xorg
(and the libgl*-xorg packages) and use
On Thu, Sep 01, 2005 at 12:07:46PM +1000, Daniel Stone wrote:
Sorry, I've really just not had any time recently, and there are some
things I wanted to clean up before I fired off to you (e.g. the
Build-Dep on glut, which introduced horrible Build-Deps and other
hilarity which meant that
On Mon, Jul 18, 2005 at 09:00:13PM -0400, Nathanael Nerode wrote:
...but wait. If this is the case, isn't there a potential problem
when a C++ program uses libGLU? Couldn't we end up with conflicting
symbols from two different versions of libstdc++, one linked into
libGLU and the other
On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote:
Also, for those who aren't aware, the new xorg packages now in
unstable are also implicated in the C++ transition, because libGLU is
implemented in C++.
Keyword: implemented.
All of GLU's interfaces are C, not C++, so
On Sat, Jul 16, 2005 at 03:24:50PM -0700, Steve Langasek wrote:
Oh, ugh. I think the XSF was essentially following Ubuntu's lead
here; no one realized, or thought to check, that the C++ bits weren't
exported as part of the ABI.
Ah... that was my guess...
David, do you want me to put
On Sat, Mar 26, 2005 at 02:51:01AM -0500, Branden Robinson wrote:
This file is a private implementation file, therefore the P.
I'm not sure I can honor this request and be consistent with existing
Debian practice.
Uhm... I meant that as in this particular case the file is named like
On Sat, Mar 26, 2005 at 03:06:44AM -0500, Branden Robinson wrote:
the GLw library shipped with the xlibmesa-gl-dev package uses
Motif (both 1.2 and 2), so some sort of dependency should be
declared on lesstif2-dev (Depends, Suggests, Recommends).
Can you elaborate, please?
Sure
Package: xlibmesa-gl-dev
Version: 4.3.0.dfsg.1-9
Severity: normal
File: /usr/include/GL/GLwDrawAP.h
See subject.
This file is a private implementation file, therefore the P.
Marcelo
PS: In case you are wondering if I have too much time in my hands, no,
I don't. I was trying to figure
Package: xlibmesa-gl-dev
Version: 4.3.0.dfsg.1-9
Severity: normal
Hi,
the GLw library shipped with the xlibmesa-gl-dev package uses Motif
(both 1.2 and 2), so some sort of dependency should be declared on
lesstif2-dev (Depends, Suggests, Recommends).
Marcelo
Package: xlibosmesa4
Version: 4.3.0.dfsg.1-10
Severity: grave
File: /usr/X11R6/lib/libOSMesa.so.4
Justification: renders package unusable
Hi,
perhaps serious is more appropriate, since it's the dependencies that
are wrong.
$ objdump -T /usr/X11R6/lib/libOSMesa.so.4.0 | grep UND | grep -v
On Tue, Jun 29, 2004 at 11:08:39AM -0500, Branden Robinson wrote:
I think changing Debian's shipping sample implementation at this
point, when we're -- err -- about to release would be a bad idea.
LOL
err... sorry... this is not -curiosa... I take that LOL back, my
apologies.
Marcelo
netbrain [EMAIL PROTECTED] writes:
I cant run anything that requires opengl, the programs will open but
bothing will show. i consulted #debian at irc.debian.org and a bloke
called penguin24 said it was a bug when compiling with a newer gcc.
im a newbie so i don't know so much about it.
netbrain [EMAIL PROTECTED] writes:
I cant run anything that requires opengl, the programs will open but
bothing will show. i consulted #debian at irc.debian.org and a bloke
called penguin24 said it was a bug when compiling with a newer gcc.
im a newbie so i don't know so much about it.
Hi Branden,
Please Cc: me, I'm not subscribed.
I'm seding this to the list because I want to have a public record of
this. I have pointed this out several times over the last few years to
you (e.g., bug#107149), and it seems this keeps coming back.
Do this for me, will you?
0. Take the
Hi Branden,
Please Cc: me, I'm not subscribed.
I'm seding this to the list because I want to have a public record of
this. I have pointed this out several times over the last few years to
you (e.g., bug#107149), and it seems this keeps coming back.
Do this for me, will you?
0. Take the
Daniel Stone [EMAIL PROTECTED] writes:
Yes, but it's not Xinerama's problem, and I don't see why it should be
bending over backwards to support people using it from another language.
I certainly won't be including this patch in my tree.
Because that's the polite way of coding C header
Branden Robinson [EMAIL PROTECTED] writes:
We could just as well ask why we bother to ship xlibmesa*, then.
I would like to know why the answers to your question and the above
should be different.
The best answer I can come up with? Because someone is bound to create
a CD which
Michel Dänzer [EMAIL PROTECTED] writes:
Because the libGL provided by mesag3 doesn't seem to be able to load the
DRI drivers (though that might just be a matter of how it's built).
Brian (?) mentioned something about building that capability on the
mesa libraries a long time ago. I don't
Sven Luther [EMAIL PROTECTED] writes:
Package: xlibmesa-glu-dev
Replaces: mesag-dev ( 5.0.0-1), [...]
Replaces mesag-dev? What did I miss?
--
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hi Sven,
On Thu, Feb 13, 2003 at 01:47:52PM +0100, Sven Luther wrote:
Definitively, this improved the situation, but it still fails on
alpha with :
Error on dynamically loaded library: /usr/X11R6/lib/libGLU.so.1:
symbol __gxx_personality_v0, version CXXABI_1.2 not defined in file
On Thu, Feb 13, 2003 at 02:22:22PM +0100, Sven Luther wrote:
I removed all the xlibmesa packages, and tried to install the mesa
packages. There is a mesa-dev packages, and libglu-mesa and
libglu-mesa-dev packages, but no mesa 5.0.0 package providing libgl.
Uhm...
Package: mesag3
On Thu, Feb 13, 2003 at 03:00:39PM +0100, Sven Luther wrote:
Notice that apt-get install mesag-dev complains that mesa-common-dev
is not going to be installed.
Does it? I admit I have only installed the packages using dpkg -i ...
I'll check what going on.
That said, suppose i build my
Sven Luther [EMAIL PROTECTED] writes:
Package: xlibmesa-glu-dev
Replaces: mesag-dev ( 5.0.0-1), [...]
Replaces mesag-dev? What did I miss?
--
Marcelo
Hi Sven,
On Thu, Feb 13, 2003 at 01:47:52PM +0100, Sven Luther wrote:
Definitively, this improved the situation, but it still fails on
alpha with :
Error on dynamically loaded library: /usr/X11R6/lib/libGLU.so.1:
symbol __gxx_personality_v0, version CXXABI_1.2 not defined in file
On Thu, Feb 13, 2003 at 02:22:22PM +0100, Sven Luther wrote:
I removed all the xlibmesa packages, and tried to install the mesa
packages. There is a mesa-dev packages, and libglu-mesa and
libglu-mesa-dev packages, but no mesa 5.0.0 package providing libgl.
Uhm...
Package: mesag3
On Thu, Feb 13, 2003 at 02:50:25PM +0100, Sven Luther wrote:
BTW, why is mesag3 not called libgl-mesa ? And i agree that the 3 is
more confusing than something else.
The way I see it, people using mesa (instead of xlibmesa) have a reason
for that and renaming the package would make
On Thu, Feb 13, 2003 at 03:00:39PM +0100, Sven Luther wrote:
Notice that apt-get install mesag-dev complains that mesa-common-dev
is not going to be installed.
Does it? I admit I have only installed the packages using dpkg -i ...
I'll check what going on.
That said, suppose i build my
I'm sorry about the somewhat out of place reply, but I wanted to point
something out and this is most relevant place I could find.
Herbert Xu [EMAIL PROTECTED] writes:
Shared library packages carry part of the soname in their names so
that multiple versions can be installed simultaneously.
Branden Robinson [EMAIL PROTECTED] writes:
Please do spell it out. If XFree86 didn't crib its GLU from the Mesa
project, where did it come from?
Mesa ships the same GLU as XFree86, and both come from the SGI OpenGL
SI.
Look in xc/extras/ogl-sample, e.g. README.XF86:
This is an
I'm sorry about the somewhat out of place reply, but I wanted to point
something out and this is most relevant place I could find.
Herbert Xu [EMAIL PROTECTED] writes:
Shared library packages carry part of the soname in their names so
that multiple versions can be installed simultaneously.
Please keep me on the Cc:
chris horn. [EMAIL PROTECTED] writes:
relocation error: /usr/lib/libGLU.so.1: undefined symbol:
__gxx_personality_v0
That's mighty bad.
That symbol comes from libstdc++
I get it with several applications (xawtv, xscreensaver and cube, to name a
few). It
On Fri, Feb 07, 2003 at 01:31:24PM +1100, Daniel Stone wrote:
Sure, so isn't it funny that the current actual Mesa packages aren't
called mesag5*?
That's Marcelo's call.
JFTR, no, I won't start calling these packages mesa5 (if I ever rename
these package, rest assured that I'm going
On Sat, Feb 08, 2003 at 02:52:35PM -0500, Branden Robinson wrote:
The package version will be the same as for every other binary
package that is generated by the XFree86 source package, so it can't
be communicated there.
JFYI, if that's the argument, you can start by renaming
On Tue, Feb 11, 2003 at 08:01:20PM +1100, Daniel Stone wrote:
JFYI, if that's the argument, you can start by renaming xlibmesa3-glu
then. 3 is certainly not the major, minor or whatever version number
of that library, since it doesn't really have anything to do with Mesa.
It
On Fri, Feb 07, 2003 at 01:31:24PM +1100, Daniel Stone wrote:
Branden already answered you, and so did I. The significance lies in
the major version. It's obviously meaningful to Mesa, if they
continue to bump *major* versions, it must mean they're doing
something pretty ... well, major,
On Thu, Feb 06, 2003 at 09:05:54AM +0100, Sven Luther wrote:
Merging Mesa 5 in the XFree86 tree will happen RSN
XFree86 4.3.0 will not ship with Mesa 5.
I forgot the smily :-)
It will certainly take Internet ages.
--
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
On Thu, Feb 06, 2003 at 05:14:57PM +0100, Michel Dänzer wrote:
You dodged my vital question again:
lol, vital... some people take Debian too seriosly ;-)
'How is the major Mesa version number relevant for the xlibmesa
package name?'
It isn't. Going from memory, the changes between 3
On Fri, Feb 07, 2003 at 01:31:24PM +1100, Daniel Stone wrote:
Branden already answered you, and so did I. The significance lies in
the major version. It's obviously meaningful to Mesa, if they
continue to bump *major* versions, it must mean they're doing
something pretty ... well, major,
On Wed, Feb 05, 2003 at 09:27:28AM +1100, Daniel Stone wrote:
Marcelo was wondering why I bumped the name to xlibmesa4-* for my
packages, and I pointed out that having xlibmesa3-*, for Mesa 4,
would be horrifically stupid and misleading.
JFTR, no, I wasn't. Michel was courteous enough to
On Thu, Feb 06, 2003 at 09:05:54AM +0100, Sven Luther wrote:
Merging Mesa 5 in the XFree86 tree will happen RSN
XFree86 4.3.0 will not ship with Mesa 5.
I forgot the smily :-)
It will certainly take Internet ages.
--
Marcelo
On Thu, Feb 06, 2003 at 05:14:57PM +0100, Michel Dänzer wrote:
You dodged my vital question again:
lol, vital... some people take Debian too seriosly ;-)
'How is the major Mesa version number relevant for the xlibmesa
package name?'
It isn't. Going from memory, the changes between 3
On Wed, Feb 05, 2003 at 09:27:28AM +1100, Daniel Stone wrote:
Marcelo was wondering why I bumped the name to xlibmesa4-* for my
packages, and I pointed out that having xlibmesa3-*, for Mesa 4,
would be horrifically stupid and misleading.
JFTR, no, I wasn't. Michel was courteous enough to
On Mon, Feb 03, 2003 at 11:24:43AM +1100, Daniel Stone wrote:
OK, so why don't you give me a hand instead of being obtuse for the
hell of it. Why was the 3 there, originally?
Heh.
The Mesa packages used to provide a library called libMesaGL.so.3. At
some point Brian (Paul) realized this
On Mon, Feb 03, 2003 at 01:26:40AM +0100, Michel Dänzer wrote:
After some more thinking, xlibmesa-gl1 might be better because it
allows xlibmesa-gl-dev to naturally keep its name.
Personally I don't have strong feelings against changing the package
names. It shouldn't break anything
On Mon, Feb 03, 2003 at 11:24:43AM +1100, Daniel Stone wrote:
OK, so why don't you give me a hand instead of being obtuse for the
hell of it. Why was the 3 there, originally?
Heh.
The Mesa packages used to provide a library called libMesaGL.so.3. At
some point Brian (Paul) realized this
On Mon, Feb 03, 2003 at 01:26:40AM +0100, Michel Dänzer wrote:
After some more thinking, xlibmesa-gl1 might be better because it
allows xlibmesa-gl-dev to naturally keep its name.
Personally I don't have strong feelings against changing the package
names. It shouldn't break anything
Hi Michel,
thanks for the Cc: ...
Michel Dänzer [EMAIL PROTECTED] writes:
I still don't get it. There's no incompatibility between
xlibmesa3-gl, xlibmesa4-gl and xlibmesa5-gl to come, so what's the
point of the different names? The worst thing IMHO is
x-window-system-core
On Sun, Feb 02, 2003 at 03:09:11PM +0100, Sven Luther wrote:
And because the autobuilders don't like virtual build dependencies,
which is, i think, a worse problem.
Please. That's a weak argument. If any package providing a virtual
package is a good as the next one, you can pick anyone.
Michel Dänzer [EMAIL PROTECTED] writes:
Shouldn't be a problem because nothing outside of the xfree86 source
package should depend on the xlibmesa packages directly (or deal with
it)?
You just have to convince apt that replacing the then dissapeared foo3
by foo1 just because the later
On Mon, Feb 03, 2003 at 10:00:23AM +1100, Daniel Stone wrote:
The 3 in 4.2.1's xlibmesa packages, and hence the 4 in my 4.2.99.x
xlibmesa packages, reflects the major version of Mesa used.
uhm... why? That doesn't make any sense at all.
--
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL
On Mon, Feb 03, 2003 at 10:26:05AM +1100, Daniel Stone wrote:
I'm not having packages with a misleading name. I'm keeping up status
quo until I see a good reason to change current (and expected)
behaviour. So far you haven't provided one.
Neither have you.
As per policy, that number
On Mon, Feb 03, 2003 at 11:16:40AM +1100, Daniel Stone wrote:
Why the Mesa packages carry a 3 is also historical baggage and most
people seem to be unaware why that 3 is there in the first place.
Yes, and it's been carried through.
Like I said... most people are unaware of why that 3
Hi Michel,
thanks for the Cc: ...
Michel Dänzer [EMAIL PROTECTED] writes:
I still don't get it. There's no incompatibility between
xlibmesa3-gl, xlibmesa4-gl and xlibmesa5-gl to come, so what's the
point of the different names? The worst thing IMHO is
x-window-system-core
On Sun, Feb 02, 2003 at 03:09:11PM +0100, Sven Luther wrote:
And because the autobuilders don't like virtual build dependencies,
which is, i think, a worse problem.
Please. That's a weak argument. If any package providing a virtual
package is a good as the next one, you can pick anyone.
Michel Dänzer [EMAIL PROTECTED] writes:
Shouldn't be a problem because nothing outside of the xfree86 source
package should depend on the xlibmesa packages directly (or deal with
it)?
You just have to convince apt that replacing the then dissapeared foo3
by foo1 just because the later
On Mon, Feb 03, 2003 at 10:00:23AM +1100, Daniel Stone wrote:
The 3 in 4.2.1's xlibmesa packages, and hence the 4 in my 4.2.99.x
xlibmesa packages, reflects the major version of Mesa used.
uhm... why? That doesn't make any sense at all.
--
Marcelo
On Mon, Feb 03, 2003 at 10:21:22AM +1100, Daniel Stone wrote:
uhm... why? That doesn't make any sense at all.
Hysterical raisins, presumably.
The raisins explain the 3 but not the 4.
--
Marcelo
On Mon, Feb 03, 2003 at 10:26:05AM +1100, Daniel Stone wrote:
I'm not having packages with a misleading name. I'm keeping up status
quo until I see a good reason to change current (and expected)
behaviour. So far you haven't provided one.
Neither have you.
As per policy, that number
On Mon, Feb 03, 2003 at 11:16:40AM +1100, Daniel Stone wrote:
Why the Mesa packages carry a 3 is also historical baggage and most
people seem to be unaware why that 3 is there in the first place.
Yes, and it's been carried through.
Like I said... most people are unaware of why that 3
Branden Robinson [EMAIL PROTECTED] writes:
Can someone who doesn't speak English help the submitter of bug 86179 to
make himself clear?
Err... I guess you mean someone who speaks Japanese, but that's
irrelevant. I think he's saying that if he logs in to the machine
using xdm, the X
Attached is a series on messages from dri-users, the DRI users' list.
Basically the DRM modules in 4.1.0 are not in sync with 2.4.7. I
haven't checked, I don't use the mentioned .debs. It would be helpful
if someone can deny or confirm this, as it would create more trouble for
users trying to
[ Please observe Mail-Followup-To: if you don't mind, I susbcribe to *and*
read debian-x, I don't need another copy on my inbox ]
Mike A. Harris [EMAIL PROTECTED] writes:
Basically the DRM modules in 4.1.0 are not in sync with 2.4.7. I
THis is correct. 4.1.0 DRM and 4.0.3 are not
Attached is a series on messages from dri-users, the DRI users' list.
Basically the DRM modules in 4.1.0 are not in sync with 2.4.7. I
haven't checked, I don't use the mentioned .debs. It would be helpful
if someone can deny or confirm this, as it would create more trouble for
users trying to
[ Please observe Mail-Followup-To: if you don't mind, I susbcribe to *and*
read debian-x, I don't need another copy on my inbox ]
Mike A. Harris [EMAIL PROTECTED] writes:
Basically the DRM modules in 4.1.0 are not in sync with 2.4.7. I
THis is correct. 4.1.0 DRM and 4.0.3 are not
Warren Turkal [EMAIL PROTECTED] writes:
Do you all think you could package up the DRI kernel modules from the
x source tree? I don't even know where to get them.
http://people.debian.org/~mmagallo/dri/ has the DRM sources for both
4.0.3 and 4.1.0. You'll also find a drm.patch file
Michel D?nzer [EMAIL PROTECTED] writes:
And no, run the latest and greatest kernel is not an option for most
people.
The current DRM code doesn't even build with 2.2 if you mean that.
I know, but no, I don't mean that. In the current status some people
just can't afford to
Michel Dänzer [EMAIL PROTECTED] writes:
http://www.xfree86.org/~alanh/
until it's merged into the Linux kernel.
Actually the xfree86 packages should provide a modules-dri-src kind of
package. That would stop much of this madness. And no, run the
latest and greatest kernel is not an
Michel D?nzer [EMAIL PROTECTED] writes:
And no, run the latest and greatest kernel is not an option for most
people.
The current DRM code doesn't even build with 2.2 if you mean that.
I know, but no, I don't mean that. In the current status some people
just can't afford to
Joey Hess [EMAIL PROTECTED] writes:
I wonder if there is a reasonable key combination to type an acute
accent (0xb4) on a (us) keyboard. If so, it wouldn't hurt to mention it.
Multi_key,',' = ´, is the the correct character?
--
Marcelo | If it wasn't for the fun and money, I
Joey Hess [EMAIL PROTECTED] writes:
I wonder if there is a reasonable key combination to type an acute
accent (0xb4) on a (us) keyboard. If so, it wouldn't hurt to mention it.
Multi_key,',' = ´, is the the correct character?
--
Marcelo | If it wasn't for the fun and money, I
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
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
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,
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
Jon Pennington [EMAIL PROTECTED] writes:
/tmp/ccEMh1hu.o(.text+0x32a): undefined reference to `OSMesaCreateContext'
/tmp/ccEMh1hu.o(.text+0x35c): undefined reference to `OSMesaMakeCurrent'
/tmp/ccEMh1hu.o(.text+0x4f5): undefined reference to `OSMesaDestroyContext'
Hmmm... please submit
Jon Pennington [EMAIL PROTECTED] writes:
/tmp/ccEMh1hu.o(.text+0x32a): undefined reference to `OSMesaCreateContext'
/tmp/ccEMh1hu.o(.text+0x35c): undefined reference to `OSMesaMakeCurrent'
/tmp/ccEMh1hu.o(.text+0x4f5): undefined reference to `OSMesaDestroyContext'
Hmmm... please submit
[EMAIL PROTECTED] writes:
Is there any trouble with an old matrox millenium (2Mo+2Mo)?
Other than the fact that that card won't do any kind of hardware
accelerated 3D rendering on Linux, no, it's a really good card. Still
one of the best ones at what it does. Only G200 and up do
[EMAIL PROTECTED] writes:
Is there any trouble with an old matrox millenium (2Mo+2Mo)?
Other than the fact that that card won't do any kind of hardware
accelerated 3D rendering on Linux, no, it's a really good card. Still
one of the best ones at what it does. Only G200 and up do
Seth Arnold [EMAIL PROTECTED] writes:
[Branden, also note that I would find the XFree86.?.log file more useful
if it date-time stamped once in a while similar to crontab's --mark--
facility -- consider asking the good people at xf86 to add such a
feature to help debugging. If the 1000
Scott Dier [EMAIL PROTECTED] writes:
Uh. uh. ah. uh. Are you trying to say that windowed opengl with
multiple opengl contexts and 2d-apps side-by-side doesn't work on most
pc cards? Nvidia cards do it fine.
No. He's saying that you have to pay attention to what you are doing
at the
Seth Arnold [EMAIL PROTECTED] writes:
[Branden, also note that I would find the XFree86.?.log file more useful
if it date-time stamped once in a while similar to crontab's --mark--
facility -- consider asking the good people at xf86 to add such a
feature to help debugging. If the 1000
Scott Dier [EMAIL PROTECTED] writes:
Uh. uh. ah. uh. Are you trying to say that windowed opengl with
multiple opengl contexts and 2d-apps side-by-side doesn't work on most
pc cards? Nvidia cards do it fine.
No. He's saying that you have to pay attention to what you are doing
at the
Alexander Hvostov [EMAIL PROTECTED] writes:
Package: mesag3-glide2 (debian/main)
Maintainer: Marcelo E. Magallon [EMAIL PROTECTED]
74471 Open GL xscreensavers cause X to hang with 3DFX cards.
I need help with this bug, I can't test
Joseph Carter [EMAIL PROTECTED] writes:
modes (which anyone who has seen me work in X knows I spend 30% of my time
in 640x480 or lower due to unreadably small, aliased fonts in things like
Netscape..)
Just as a hint, Galeon let's you change the scaling of the fonts on a
per page basis.
Zephaniah E. Hull [EMAIL PROTECTED] writes:
You simply CAN NOT use mesag3-glide2 on a V3 with X4, it won't work.
Uhm. Why?
(if I'm going to be maintaining this, I'd like to know why it doesn't
work with a specific setup, in particular, I'd like to know if this is
a bug in mesa or a bug
Joseph Carter [EMAIL PROTECTED] writes:
Neither. It's that the X server and Glide2 would have to cooperate in
order to let you do it. As of XFree4, X no longer knows how to talk to
Glide2, but does know how to talk to Glide3. Evil, eh?
Then why does it work for V1 and V2?
What you
Zephaniah E. Hull [EMAIL PROTECTED] writes:
My rough naming scheme is as follows: xlibmesa3-dri, xlibmesa-dri-dev,
xlibosmesa3-dri, xlibosmesa-dri-dev, and xserver-dri.
I would drop the xlibosmesa packages. libOSMesa is a software only
client side off-screen rendering library.
The 4
I'm sorry, I forgot one important bit.
Zephaniah E. Hull [EMAIL PROTECTED] writes:
My rough naming scheme is as follows: xlibmesa3-dri, xlibmesa-dri-dev,
xlibosmesa3-dri, xlibosmesa-dri-dev, and xserver-dri.
You might want to provide
Zephaniah E. Hull [EMAIL PROTECTED] writes:
It might be possible to get X to search a different module path first,
but all examples of that turn out to be very ugly in the config file,
I'll keep poking.
Ah, yes, that's actually cleaner. For the X server, you could change
the symlink in
BugScan reporter [EMAIL PROTECTED] writes:
Package: mesag3-glide2 (debian/main)
Maintainer: Marcelo E. Magallon [EMAIL PROTECTED]
74471 Open GL xscreensavers cause X to hang with 3DFX cards.
I need help with this bug, I can't test this as I don't have TDFX
hardware.
--
Marcelo
1 - 100 of 191 matches
Mail list logo
