From owner-ogl-sample@oss.sgi.com Wed Jul 5 07:17:30 2000 Received: by oss.sgi.com id ; Wed, 5 Jul 2000 07:17:20 -0700 Received: from mail1.worldcom.ch ([212.74.176.11]:26614 "EHLO mail.worldcom.ch") by oss.sgi.com with ESMTP id ; Wed, 5 Jul 2000 07:17:03 -0700 Received: from cyberbotics.com ([212.74.183.57]) by mail.worldcom.ch (8.9.3+Sun/8.9.3) with ESMTP id QAA12503; Wed, 5 Jul 2000 16:17:01 +0200 (MET DST) Message-ID: <39634637.D481745@cyberbotics.com> Date: Wed, 05 Jul 2000 16:29:11 +0200 From: Olivier Michel Organization: Cyberbotics Ltd. X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.6-16apmac ppc) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com, mesa3d-dev@lists.sourceforge.net Subject: Re: [ogl-sample] SGI SI GLU integration References: <200006282102.OAA13880@bluevoid.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Good news: It was a bit tricky, but I successfully built 2 RPM binary packages (for i386) ogl-sample-glu-1.3.04JUL00-1.i386.rpm and mesa-without-glu-3.3.04JUL00-1.i386.rpm I am not sure the names and version numbering are fine, but that's just a first trial. You may use rpm -Uvh with --nodeps or --force to get them installed properly on differents Linux distros I could test it on Suze 6.4, Redhat 6.0 and Slackware 7.0 and seemed to work properly: the tesselator doesn't crash my app any more :) These packages are available at ftp://ftp.cyberbotics.com (you may also download the other packages to test my app: webots). I finally found the real problem with building the SGI libGLU from the current CVS: In the file glue.c, the functions static const char *__glNURBSErrorString( int errno ) and static const char *__glTessErrorString( int errno ) should not be defined as static because they are used by error.c. This cause the libGLU.so doesn't work at runtime because it doesn't find these functions called by error.c (which are local to glue.c). So, the fix is pretty simple: just remove the static keyword for these two functions in glue.c Again, since I have no write access to the CVS, I hope someone could do it for me. Moreover I had to hack the glu.h problem by hand. Thanks, -Olivier From owner-ogl-sample@oss.sgi.com Thu Jul 13 07:31:46 2000 Received: by oss.sgi.com id ; Thu, 13 Jul 2000 07:31:37 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:32798 "EHLO mail.valinux.com") by oss.sgi.com with ESMTP id ; Thu, 13 Jul 2000 07:31:20 -0700 Received: from jens2.cmn.net ([207.174.125.34] helo=valinux.com) by mail.valinux.com with esmtp (Exim 2.12 #6) id 13Ck1M-0001o8-00 for ogl-sample@oss.sgi.com; Thu, 13 Jul 2000 07:31:25 -0700 Message-ID: <396DC560.690C686B@valinux.com> Date: Thu, 13 Jul 2000 07:34:24 -0600 From: Brian Paul Organization: VA Linux Systems, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com Subject: [ogl-sample] GL_CLIENT_ALL_ATTRIB_BITS vs GL_ALL_CLIENT_ATTRIB_BITS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing The 1.2 spec and the RedBook has GL_ALL_CLIENT_ATTRIB_BITS but the SI (and Mesa) uses GL_CLIENT_ALL_ATTRIB_BITS instead. Which is it supposed to be? -Brian From owner-ogl-sample@oss.sgi.com Thu Jul 13 08:48:17 2000 Received: by oss.sgi.com id ; Thu, 13 Jul 2000 08:48:07 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:17437 "EHLO mail.valinux.com") by oss.sgi.com with ESMTP id ; Thu, 13 Jul 2000 08:47:48 -0700 Received: from jens2.cmn.net ([207.174.125.34] helo=valinux.com) by mail.valinux.com with esmtp (Exim 2.12 #6) id 13ClDR-000427-00; Thu, 13 Jul 2000 08:47:57 -0700 Message-ID: <396DD74E.6043121F@valinux.com> Date: Thu, 13 Jul 2000 08:50:54 -0600 From: Brian Paul Organization: VA Linux Systems, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com CC: mesa3d-dev@lists.sourceforge.net Subject: Re: [ogl-sample] SGI SI GLU integration References: <200006282102.OAA13880@bluevoid.com> <39634637.D481745@cyberbotics.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Olivier Michel wrote: > > Good news: It was a bit tricky, but I successfully built 2 RPM binary > packages (for i386) > > ogl-sample-glu-1.3.04JUL00-1.i386.rpm and > mesa-without-glu-3.3.04JUL00-1.i386.rpm > > I am not sure the names and version numbering are fine, but that's just > a first trial. > > You may use rpm -Uvh with --nodeps or --force to get them installed > properly on differents Linux distros I could test it on Suze 6.4, Redhat > 6.0 and Slackware 7.0 and seemed to work properly: the tesselator > doesn't crash my app any more :) > > These packages are available at ftp://ftp.cyberbotics.com (you may also > download the other packages to test my app: webots). > > I finally found the real problem with building the SGI libGLU from the > current CVS: > > In the file glue.c, the functions > > static const char *__glNURBSErrorString( int errno ) > > and > > static const char *__glTessErrorString( int errno ) > > should not be defined as static because they are used by error.c. This > cause the libGLU.so doesn't work at runtime because it doesn't find > these functions called by error.c (which are local to glue.c). > > So, the fix is pretty simple: just remove the static keyword for these > two functions in glue.c > > Again, since I have no write access to the CVS, I hope someone could do > it for me. > > Moreover I had to hack the glu.h problem by hand. Olivier, What's the status on this project? -Brian From owner-ogl-sample@oss.sgi.com Thu Jul 13 10:30:27 2000 Received: by oss.sgi.com id ; Thu, 13 Jul 2000 10:30:08 -0700 Received: from adsl-63-204-9-35.dsl.snfc21.pacbell.net ([63.204.9.35]:28430 "EHLO bluevoid.com") by oss.sgi.com with ESMTP id ; Thu, 13 Jul 2000 10:29:43 -0700 Received: (from blythe@localhost) by bluevoid.com (8.9.3/8.9.3) id KAA29701 for ogl-sample@oss.sgi.com; Thu, 13 Jul 2000 10:29:42 -0700 Date: Thu, 13 Jul 2000 10:29:42 -0700 From: blythe@bluevoid.com Message-Id: <200007131729.KAA29701@bluevoid.com> To: ogl-sample@oss.sgi.com Subject: Re: [ogl-sample] GL_CLIENT_ALL_ATTRIB_BITS vs GL_ALL_CLIENT_ATTRIB_BITS Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing | The 1.2 spec and the RedBook has GL_ALL_CLIENT_ATTRIB_BITS but the | SI (and Mesa) uses GL_CLIENT_ALL_ATTRIB_BITS instead. | | Which is it supposed to be? Should follow the spec. Note that the SI does have GL_MAX_CLIENT_ATTRIB_STACK_DEPTH. -david From owner-ogl-sample@oss.sgi.com Thu Jul 13 16:01:18 2000 Received: by oss.sgi.com id ; Thu, 13 Jul 2000 16:00:59 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:21049 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 13 Jul 2000 16:00:41 -0700 Received: from arioch.engr.sgi.com (arioch.engr.sgi.com [130.62.54.161]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA05737 for ; Thu, 13 Jul 2000 16:06:23 -0700 (PDT) mail_from (shreiner@arioch.engr.sgi.com) Received: (from shreiner@localhost) by arioch.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA03395; Thu, 13 Jul 2000 15:59:34 -0700 (PDT) From: Dave Shreiner MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 13 Jul 2000 15:59:33 -0700 (PDT) To: ogl-sample@oss.sgi.com Cc: mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] Re: [ogl-sample] SGI SI GLU integration X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14702.18725.695165.906701@arioch.engr.sgi.com> Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Hi all, I've checked in the changes that Olivier Michel suggested for fixing glue.c, and cleaned up the variable and function naming to reduce the confusion (__gl -> __glu), just for cliarity's sake. These changes have been checked into the CVS depot, but we haven't rolled a new tarball yet (soon, I promise). I'm working to clean up the header file generation, particularly the OpenGL 1.0 compatibility lines that appear in glu.h, and I'd like to move the _GLfuncptr define from gl.h and into glu.h, since there's nothing in GL proper that requires function pointers. Thanx, Dave --------------------------------------------------------------------- Dave Shreiner Silicon Graphics, Inc. (650) 933-4899 From owner-ogl-sample@oss.sgi.com Sat Jul 15 03:44:40 2000 Received: by oss.sgi.com id ; Sat, 15 Jul 2000 03:44:31 -0700 Received: from oe39.law9.hotmail.com ([64.4.8.96]:65036 "HELO hotmail.com") by oss.sgi.com with SMTP id ; Sat, 15 Jul 2000 03:43:57 -0700 Received: (qmail 80904 invoked by uid 65534); 15 Jul 2000 10:43:27 -0000 Message-ID: <20000715104327.80903.qmail@hotmail.com> X-Originating-IP: [195.131.0.202] From: "Ruslan Abdikeev" To: Subject: [ogl-sample] Registry of extensions in tar-gzip Date: Sat, 15 Jul 2000 14:30:27 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Dear Sirs, Is it possible to publish the registry of OpenGL extensions in one compressed file? Thank you for advance, Ruslan Abdikeev mailto:ruslan_abdikeev@hotmail.com From owner-ogl-sample@oss.sgi.com Thu Jul 20 01:53:21 2000 Received: by oss.sgi.com id ; Thu, 20 Jul 2000 01:53:11 -0700 Received: from mail1.worldcom.ch ([212.74.176.11]:25073 "EHLO mail.worldcom.ch") by oss.sgi.com with ESMTP id ; Thu, 20 Jul 2000 01:52:40 -0700 Received: from cyberbotics.com ([212.74.183.57]) by mail.worldcom.ch (8.9.3+Sun/8.9.3) with ESMTP id KAA00572; Thu, 20 Jul 2000 10:51:56 +0200 (MET DST) Message-ID: <3976C0AB.E1C1828F@cyberbotics.com> Date: Thu, 20 Jul 2000 11:04:43 +0200 From: Olivier Michel Organization: Cyberbotics Ltd. X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.6-16apmac ppc) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com CC: mesa3d-dev@lists.sourceforge.net Subject: Re: [ogl-sample] SGI SI GLU integration References: <200006282102.OAA13880@bluevoid.com> <39634637.D481745@cyberbotics.com> <396DD74E.6043121F@valinux.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Hello, Sorry, I was off last week and I am just back from holidays reading my 142 e-mails... Apparently Dave commited a number of changes I requested. However, it is apparently not yet complete (since the glu.h header is not yet fixed, it still includes the OpenGL 1.0 compatibility lines), but I guess Dave is currently working working on that... Hence my RPM .spec file doesn't work yet from the CVS source (the glu.h file still needs to be patched by hand). However, I can provide all what I have: 1) The method to patch the glu.h and build the rpm from my modified .spec file. This might be useful to build binary rpms for other platforms. I will send them upon request. 2) The binary package for linux i386 (it is already available from ftp://ftp.cyberbotics.com as mentioned in a previous e-mail, along with a RPM package for Mesa without its GLU). Otherwise, we have to wait for Dave to fix the glu.h problem and to add/merge my RPM .spec file to the CVS tree. I will rebuild the binary RPMs for linux i386 for both SGI SI GLU and Mesa core GL (without GLU) as soon as Mesa-3.3 is out. However, I would appreciate if they could be hosted somewhere else than on my ftp site (since it cannot support high traffic). By the way, how should I name the final versions of those packages ? mesa-without-glu-3.3-1.i386.rpm and sgi-si-glu-1.3-1.i386.rpm, or simply Mesa-3.3-1.i386.rpm and sgi-glu-1.3-1.i386.rpm ? Another option could be to merge Mesa and SGI GLU into a single RPM binary package named Mesa-with-sgi-glu-3.3-1.i386.rpm or simply Mesa-3.3-1.i386.rpm (in this case, the RPM build process will be a bit more tricky, but that's not a problem for me). Personaly, I like the idea of the Mesa-3.3-1.i386.rpm containing everything, but this might be conficting with other versions using Mesa GLU. By the way, Brian, will you officially drop Mesa GLU, i.e., remove it from Mesa distribution and recommanding to use SGI GLU instead ? -Olivier Brian Paul wrote: > > Olivier Michel wrote: > > > > Good news: It was a bit tricky, but I successfully built 2 RPM binary > > packages (for i386) > > > > ogl-sample-glu-1.3.04JUL00-1.i386.rpm and > > mesa-without-glu-3.3.04JUL00-1.i386.rpm > > > > I am not sure the names and version numbering are fine, but that's just > > a first trial. > > > > You may use rpm -Uvh with --nodeps or --force to get them installed > > properly on differents Linux distros I could test it on Suze 6.4, Redhat > > 6.0 and Slackware 7.0 and seemed to work properly: the tesselator > > doesn't crash my app any more :) > > > > These packages are available at ftp://ftp.cyberbotics.com (you may also > > download the other packages to test my app: webots). > > > > I finally found the real problem with building the SGI libGLU from the > > current CVS: > > > > In the file glue.c, the functions > > > > static const char *__glNURBSErrorString( int errno ) > > > > and > > > > static const char *__glTessErrorString( int errno ) > > > > should not be defined as static because they are used by error.c. This > > cause the libGLU.so doesn't work at runtime because it doesn't find > > these functions called by error.c (which are local to glue.c). > > > > So, the fix is pretty simple: just remove the static keyword for these > > two functions in glue.c > > > > Again, since I have no write access to the CVS, I hope someone could do > > it for me. > > > > Moreover I had to hack the glu.h problem by hand. > > Olivier, > > What's the status on this project? > > -Brian From owner-ogl-sample@oss.sgi.com Thu Jul 20 07:34:04 2000 Received: by oss.sgi.com id ; Thu, 20 Jul 2000 07:33:54 -0700 Received: from nat-su-33.valinux.com ([198.186.202.33]:4904 "EHLO mail.valinux.com") by oss.sgi.com with ESMTP id ; Thu, 20 Jul 2000 07:33:23 -0700 Received: from jens2.cmn.net ([207.174.125.34] helo=valinux.com) by mail.valinux.com with esmtp (Exim 2.12 #6) id 13FHNb-0006sQ-00; Thu, 20 Jul 2000 07:32:51 -0700 Message-ID: <39770039.40CF9DB0@valinux.com> Date: Thu, 20 Jul 2000 07:35:53 -0600 From: Brian Paul Organization: VA Linux Systems, Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com CC: mesa3d-dev@lists.sourceforge.net Subject: Re: [ogl-sample] SGI SI GLU integration References: <200006282102.OAA13880@bluevoid.com> <39634637.D481745@cyberbotics.com> <396DD74E.6043121F@valinux.com> <3976C0AB.E1C1828F@cyberbotics.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Olivier Michel wrote: > > Hello, > > Sorry, I was off last week and I am just back from holidays reading my > 142 e-mails... > Apparently Dave commited a number of changes I requested. However, it is > apparently not yet complete (since the glu.h header is not yet fixed, it > still includes the OpenGL 1.0 compatibility lines), but I guess Dave is > currently working working on that... > Hence my RPM .spec file doesn't work yet from the CVS source (the glu.h > file still needs to be patched by hand). However, I can provide all what > I have: > > 1) The method to patch the glu.h and build the rpm from my modified > .spec file. This might be useful to build binary rpms for other > platforms. I will send them upon request. > > 2) The binary package for linux i386 (it is already available from > ftp://ftp.cyberbotics.com as mentioned in a previous e-mail, along with > a RPM package for Mesa without its GLU). > > Otherwise, we have to wait for Dave to fix the glu.h problem and to > add/merge my RPM .spec file to the CVS tree. > > I will rebuild the binary RPMs for linux i386 for both SGI SI GLU and > Mesa core GL (without GLU) as soon as Mesa-3.3 is out. However, I would > appreciate if they could be hosted somewhere else than on my ftp site > (since it cannot support high traffic). You shouldn't have to wait for a Mesa release to put out the SI GLU package. I was hoping to release Mesa 3.2.1 and 3.3 this week but a last-minute bug regression in evaluators is postponing that, probably until after SIGGRAPH. Dave's probably busy preparing for SIGGRAPH too. So, I might be two weeks before we're all ready. > By the way, how should I name the final versions of those packages ? > > mesa-without-glu-3.3-1.i386.rpm and sgi-si-glu-1.3-1.i386.rpm, or simply > Mesa-3.3-1.i386.rpm and sgi-glu-1.3-1.i386.rpm ? I prefer the later. > Another option could be to merge Mesa and SGI GLU into a single RPM > binary package named Mesa-with-sgi-glu-3.3-1.i386.rpm or simply > Mesa-3.3-1.i386.rpm (in this case, the RPM build process will be a bit > more tricky, but that's not a problem for me). I'd rather keep the packages separate. I expect that the GLU package won't be updated as often as Mesa. Also, it would make the Mesa package smaller. > Personaly, I like the idea of the Mesa-3.3-1.i386.rpm containing > everything, but this might be conficting with other versions using Mesa > GLU. By the way, Brian, will you officially drop Mesa GLU, i.e., remove > it from Mesa distribution and recommanding to use SGI GLU instead ? Yes, I'd like to drop Mesa's GLU at some point but I haven't worked out the details. -Brian From owner-ogl-sample@oss.sgi.com Thu Jul 20 08:59:24 2000 Received: by oss.sgi.com id ; Thu, 20 Jul 2000 08:59:14 -0700 Received: from mail1.worldcom.ch ([212.74.176.11]:11648 "EHLO mail.worldcom.ch") by oss.sgi.com with ESMTP id ; Thu, 20 Jul 2000 08:58:54 -0700 Received: from cyberbotics.com ([212.74.183.57]) by mail.worldcom.ch (8.9.3+Sun/8.9.3) with ESMTP id RAA09839; Thu, 20 Jul 2000 17:58:12 +0200 (MET DST) Message-ID: <39772493.E2E997BE@cyberbotics.com> Date: Thu, 20 Jul 2000 18:10:59 +0200 From: Olivier Michel Organization: Cyberbotics Ltd. X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.6-16apmac ppc) X-Accept-Language: en MIME-Version: 1.0 To: ogl-sample@oss.sgi.com CC: mesa3d-dev@lists.sourceforge.net Subject: Re: [ogl-sample] SGI SI GLU integration References: <200006282102.OAA13880@bluevoid.com> <39634637.D481745@cyberbotics.com> <396DD74E.6043121F@valinux.com> <3976C0AB.E1C1828F@cyberbotics.com> <39770039.40CF9DB0@valinux.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ogl-sample@oss.sgi.com Precedence: bulk Reply-To: ogl-sample@oss.sgi.com Return-Path: X-Orcpt: rfc822;ogl-sample-outgoing Brian Paul wrote: > > Olivier Michel wrote: > > > > Hello, > > > > Sorry, I was off last week and I am just back from holidays reading my > > 142 e-mails... > > Apparently Dave commited a number of changes I requested. However, it is > > apparently not yet complete (since the glu.h header is not yet fixed, it > > still includes the OpenGL 1.0 compatibility lines), but I guess Dave is > > currently working working on that... > > Hence my RPM .spec file doesn't work yet from the CVS source (the glu.h > > file still needs to be patched by hand). However, I can provide all what > > I have: > > > > 1) The method to patch the glu.h and build the rpm from my modified > > .spec file. This might be useful to build binary rpms for other > > platforms. I will send them upon request. > > > > 2) The binary package for linux i386 (it is already available from > > ftp://ftp.cyberbotics.com as mentioned in a previous e-mail, along with > > a RPM package for Mesa without its GLU). > > > > Otherwise, we have to wait for Dave to fix the glu.h problem and to > > add/merge my RPM .spec file to the CVS tree. > > > > I will rebuild the binary RPMs for linux i386 for both SGI SI GLU and > > Mesa core GL (without GLU) as soon as Mesa-3.3 is out. However, I would > > appreciate if they could be hosted somewhere else than on my ftp site > > (since it cannot support high traffic). > > You shouldn't have to wait for a Mesa release to put out the SI GLU > package. Sure. It is already available on ftp://ftp.cyberbotics.com and is not likely to change when Mesa-3.3 is out. I will eventually rebuild it if bug fixes are commited. > I was hoping to release Mesa 3.2.1 and 3.3 this week but a last-minute > bug regression in evaluators is postponing that, probably until after > SIGGRAPH. Dave's probably busy preparing for SIGGRAPH too. > > So, I might be two weeks before we're all ready. All right. > > By the way, how should I name the final versions of those packages ? > > > > mesa-without-glu-3.3-1.i386.rpm and sgi-si-glu-1.3-1.i386.rpm, or simply > > Mesa-3.3-1.i386.rpm and sgi-glu-1.3-1.i386.rpm ? > > I prefer the later. That's fine for me. > > Another option could be to merge Mesa and SGI GLU into a single RPM > > binary package named Mesa-with-sgi-glu-3.3-1.i386.rpm or simply > > Mesa-3.3-1.i386.rpm (in this case, the RPM build process will be a bit > > more tricky, but that's not a problem for me). > > I'd rather keep the packages separate. I expect that the GLU package > won't be updated as often as Mesa. Also, it would make the Mesa package > smaller. > > > Personaly, I like the idea of the Mesa-3.3-1.i386.rpm containing > > everything, but this might be conficting with other versions using Mesa > > GLU. By the way, Brian, will you officially drop Mesa GLU, i.e., remove > > it from Mesa distribution and recommanding to use SGI GLU instead ? > > Yes, I'd like to drop Mesa's GLU at some point but I haven't worked > out the details. > > -Brian It's not easy because the demos and examples need a GLU to work... -Olivier