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-co
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 l
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 s
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 t
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 thi
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 rea
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
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 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, majo
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
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 xlibmesa3-
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.
> >
>> 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
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 simultaneou
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
> fe
>> 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
Vers
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 upgrad
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 m
>> 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 hea
>> 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 whi
>> 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
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-co
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 l
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 P
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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Troub
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 s
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 t
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 thi
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 rea
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
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
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, majo
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
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 xlibmesa3-
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.
> >
>> 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
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 simultaneou
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
> fe
>> 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
Vers
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 upgrad
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 m
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 figur
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 GLIBC
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 "tr
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 pu
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 oth
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.
Marcel
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 f
>> 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 abo
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 f
>> 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 abo
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:
http://packages.debian.org/cgi-bin/search_contents.pl?word=libGL.so.1&searchmode=searchfiles&case=sensitive&version=unst
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 package
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 tha
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 tarb
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 build/gl-debian-
>> Seth Arnold <[EMAIL PROTECTED]> writes:
> Terry, a few quick comments -- first, Utah-glx is in the past. While
> their work may have been nifty at one point, and for people running
> 3.3.x perhaps necessary, XF 4.0.1 has a *much* easier GL system.
Grmpf!
Do you know what DRI currently su
>> Terry 'Mongoose' Hendrix II <[EMAIL PROTECTED]> writes:
> pissed off. An overnight upgrade of gtk shouldn't break my x server.
As the gtkglarea maintainer (and since you hinted it's the OpenGL
subsystem what broke) I feel this is somehow my fault... could you
please elaborate on this?
-
>> Seth Arnold <[EMAIL PROTECTED]> writes:
> Well, I am at least partially correct in the sense that Utah-GLX does
> not work with 4.0.1. It only works with versions of 3.3.x; a version
> most decidedly much older than 4.0.1. That is my definition of 'past' --
> something that once upon a time
>> Gordon Sadler <[EMAIL PROTECTED]> writes:
> However, my issue is not HOW to fix it, but rather after fixing it
> it does not stay fixed. Every upgrade requires me to again dpkg-
> reconfigure xserver-common. That was the thought behind my bug, maybe
> Branden doesn't quite realize what I me
>> Seth Arnold <[EMAIL PROTECTED]> writes:
> * Marcelo E. Magallon <[EMAIL PROTECTED]> [001212 16:39]:
> > [...] and Utah's has some advantages for some people.
>
> And the one person who has seemed to be effected thus far did not take
> the time an
[Don't Cc me, I'm on the list]
>> Terry 'Mongoose' Hendrix II <[EMAIL PROTECTED]> writes:
> It seems to be that gtk depends on X 4.0.1+, and that caused my working
> xserver to be purged and replaced. Still, I want to be able to use
> 3.3.6-18 and utah packages for G400 and G200 - and they'
>> Seth Arnold <[EMAIL PROTECTED]> writes:
> * Marcelo E. Magallon <[EMAIL PROTECTED]> [001213 00:21]:
> > But the question still remains: why should a user put packages on
> > hold before an upgrade? He's got a working configuration, and AFAICS
>
>> Branden Robinson <[EMAIL PROTECTED]> writes:
> This guy doesn't even say what he wants.
It's amazing how one learns to read between lines...
> Im using X4 and cant have working quake and other games in fullscreen
> mode on my voodoo banshee (people from rh 7.0 can do this) this is
> ver
>> Terry 'Mongoose' Hendrix II <[EMAIL PROTECTED]> writes:
> I think the only people it "works for" are just playing games or are
> on UP systems. I haven't found anyone yet that can run a
> multicontext and/or windowed GL application yet on MGA DRI. Thanks
> for your input, as I'm tracking
>> Terry 'Mongoose' Hendrix II <[EMAIL PROTECTED]> writes:
> > "UP systems"? I can't make that one out.
>
> UniProcessor
doh.
> I'm gald it works on your UP athlon, but that doesn't help SMP users. =)
/me schedules a marchine swap for the Radeon...
I'll see if I can get something out.
[ Don't reply to me, just to debian-x@lists.debian.org, which is, btw,
not a users list, see the charter in http://lists.debian.org/ ]
>> Branden Robinson <[EMAIL PROTECTED]> writes:
> Hi. Wonder if I can get an answer to this question. I need to compile
> the source debs (4.0.x) into binarie
>> "Marcelo E. Magallon" <[EMAIL PROTECTED]> writes:
> > I'm gald it works on your UP athlon, but that doesn't help SMP users. =)
>
> /me schedules a marchine swap for the Radeon...
>
> I'll see if I can get something out. The one
a. Read xbase-clients' description
b. Read xutils' description
c. Read dlocate's description
Tralala,
>> Branden Robinson <[EMAIL PROTECTED]> writes:
> Someone please tell this person how to read package descriptions.
>
> - Forwarded message from Chris Gahan <[EMAIL PROTECTED]> -
Hi,
I was just browsing the FHS 2.2 public review document and found this:
759 3.7.5.2 Specific Options
760
761 The following files, or symbolic links to files, must be in /etc/X11 if
762 the corresponding subsystem is installed:
763
764 Xconfig The configuration file for early versions
>> Jon Pennington <[EMAIL PROTECTED]> writes:
> I was under the impression that the XFree86 rules would override FHS
> rules, at least until FHS is back up to speed on what applications
> need to run.
a) I don't get whay you mean; b) this is FHS "getting up to speed"
> In accordance with t
>> Mark Montague <[EMAIL PROTECTED]> writes:
> I saw and fixed something similar-- on looking with ldd, I found that
> it ld.so was finding /usr/lib/libc5-compat/libXmu.so.6 before
> /usr/X11R6/lib/libXmu.so.6.
That *should* be ok. The dynamic linker should be able to tell that
the librari
>> Mark Montague <[EMAIL PROTECTED]> writes:
> % strings /usr/lib/libc5-compat/libXmu.so.6 | grep libc.so
using readelf (or objdump) is more accurate, e.g.:
$ readelf -d /usr/X11R6/lib/libX11.so.6.2 | grep NEEDED
0x0001 (NEEDED) Shared library: [libc.so.6]
> So it
>> 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 thi
>> 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 ca
>> 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 b
>> "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
>> 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
>> "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.
>
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
xc/programs/Xserver/hw/xfree86/os-support/linux
>> "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 sy
>> 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
>> 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
>> [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 accele
>> 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 su
>> 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 temp
>> "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 accurat
>> 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 famil
>> 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 mone
1 - 100 of 251 matches
Mail list logo
