On Tue, May 30, 2006 at 04:06:40PM -0400, P.C. Chan wrote:
> Comparing I830DRIRec definition from xf86-video-i810-1.5.1.0 and Mesa-6.4.1,
> the former has the extra:
>
> drmSize rotatedSize;
> drm_handle_t rotatedbuffer;
>
> Hence they would be different in size and uncompatible.
Th
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
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 Br
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'
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 pri
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 mos
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:
--- libxklavier-2.2.orig/libxklavier/xklavier_co
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-
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 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 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 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 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 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 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, Mar 26, 2005 at 03:58:39PM -0500, Michel Dänzer wrote:
> I think the GLw stuff should really be in its own package, which
> could then depend on the Motif stuff. Is there anything at all in
> Debian that uses GLw?
Too much overhead, IMO. We are talking about 5 files (3 from my POV)
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?
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 name
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
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: 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
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
>> 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
>> 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
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
>> 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
>> 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
>> 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
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
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 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
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
>> Sven Luther <[EMAIL PROTECTED]> writes:
> Package: xlibmesa-glu-dev
> Replaces: mesag-dev (>> 5.0.0-1), [...]
Replaces mesag-dev? What did I miss?
--
Marcelo
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
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 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
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
>> 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]
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
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
>> 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
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
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
>> 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
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.
> >
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.
> >
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 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 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 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:
> 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 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 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 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 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 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 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 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 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 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 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 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: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 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 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 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: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
>> 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 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
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.
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
>> 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
>> 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
[ 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
[ 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 ar
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 set
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 se
>> 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
>> 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 affor
>> 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 affo
>> 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
>> 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" 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 mone
>> 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 mon
>> 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
>> "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 fami
>> "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 accura
>> 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
>> 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 tem
>> 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:
> /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 s
1 - 100 of 251 matches
Mail list logo
