Re: mesag3 - xlibmesa-gl / libgl1-mesa-dri - xlibmesa-dri / libglu1-mesa - libglu1-xorg

2005-09-04 Thread Marcelo E. Magallon 
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 tarball.

 The programs in progs/util are not generally useful.  I could include
 them as examples in mesa-common or something like that.

 And I don't know where glxinfo is going to end up.  It's certainly not
 included with mesa atm.

  The problem with Mesa Build-Depping on glut is so:
* mesa depends on glut to build, which depends on libgl1-mesa-dev
* buildd goes to install libgl1-mesa-dev to fulfill B-Ds
* libgl1-mesa-dev deps mesa-common-dev (= ${Source-Version})
* mesa-common-dev version n is in the archive from the maintainer
  upload
* but libgl1-mesa-dev for, say, hppa, is still n-1
 - uninstallable B-Ds

 Uhm, are we talking about mesa (not mesademos)?

Mesa-6.3.2$ find ! -type d -print0 | xargs -r0 grep glut.h
./Makefile: $(DIRECTORY)/include/GL/glut.h  \
./docs/download.html:a 
href=http://www.opengl.org/resources/libraries/glut.html;
./docs/README.WINDML:- src/ugl/ugl_glutshapes.c
./include/GL/gl.h: * including only glut.h, since glut.h depends on windows.h.
./include/GL/gl.h: * glut.h or gl.h.
./include/GL/uglglutshapes.h:/* uglglutshapes.h - Public header GLUT Shapes */
./progs/util/dumpstate.c:#include GL/glut.h
./progs/util/glstate.c:#include GL/glut.h
./progs/util/glutskel.c:#include GL/glut.h

 Like I said before, those programs are not generally useful, at least
 not in compiled form.

  As a short-term move, since we don't have Glide support in 6.3
  anyway, I just disabled the Glide packages and moved the headers
  across.

 I decided that Glide is too much of a hassle.  It will probably work
 again in 6.4, that's true, but I have decided to carry with the plan I
 had sketched a couple of years ago:

* Regular drivers are built from the mesa package
* Troublesome drivers (not being kept up to date, etc) are built
  from a second source package (mesa-legacy)
* Whenever a new Mesa upstream is released, I look at it, if nothing
  breaks (and this has happened multiple times -- recall that mesa
  uses a x.y.z scheme, where odd y means in development) then I
  make an upload of the source package mesa to unstable
* If one of the weird drivers breaks in the new upstream, then
  figure out if it's because of some small change.  If that's the
  case fix it.  If not (as is the case with glide in 6.3) then
  move the driver to the mesa-legacy package.
* Once I figure the driver is being actively maintained, move it
  back to mesa

 In this way I keep the same set of binary packages, meaning that users
 won't be missing functionality, and I can keep the maintained drivers
 up to date.

 The mesa source package is structured in such a way that it allows for
 building either mesa or mesa-legacy, after tweaking debian/control, of
 course.  There's a small duplication of code (the mesa and mesa-legacy
 tarballs are sometimes the same file, sometimes not), but taking into
 account that the binary packages are *much* larger than the source I
 don't think that's something to gripe about.

 Cheers,

-- 
Marcelo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: mesag3 - xlibmesa-gl / libgl1-mesa-dri - xlibmesa-dri / libglu1-mesa - libglu1-xorg

2005-09-04 Thread Marcelo E. Magallon 
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-debug-i386

 Ah, sorry about that.

 I reworked a few parts of debian/rules and forgot to take the optimized
 builds into account.

 It's fixed now.

I just need to know if they work fine with the current X server in
unstable or if I need to wait for the 6.9 X server.
  
  FWIW, we generally try to preserve backwards compatibility, so they
  *should* work with the X server in sid. The r200 driver from Mesa CVS
  certainly works here, although I'm not using the DDX driver from
  xserver-xorg either. :)

 Ok, I'll try that on the hardware I have (i815 I think).

  The attached patch adds the IMO appropriate Conflicts:, Replaces: and
  Provides: for libgl1-mesa-dri{,-dev}.

 Oh, thanks, I forgot those, too :-P

And co-maintaining is always welcomed.
  
  Okay, do you intend to use the pkg-mesa-devel list?

 Sure.

-- 
Marcelo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: mesag3 - xlibmesa-gl / libgl1-mesa-dri - xlibmesa-dri / libglu1-mesa - libglu1-xorg

2005-09-04 Thread Michel Dänzer 

[ Moving to pkg-mesa-devel, please follow up there only ]

On Sun, 2005-09-04 at 11:12 -0600, Marcelo E. Magallon wrote: 
 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-debug-i386
 
  Ah, sorry about that.
 
  I reworked a few parts of debian/rules and forgot to take the optimized
  builds into account.
 
  It's fixed now.

Indeed, thanks. However, building the i8* drivers doesn't make much
sense on powerpc, how about something like the attached patch?

Also, I think the mach64 (and possibly r300) driver(s) should be in a
separate package with a strong warning about the security risks. For
mach64, the DRI support in the DDX won't be enabled by default in the
foreseeable future anyway.


 I just need to know if they work fine with the current X server in
 unstable or if I need to wait for the 6.9 X server.
   
   FWIW, we generally try to preserve backwards compatibility, so they
   *should* work with the X server in sid. The r200 driver from Mesa CVS
   certainly works here, although I'm not using the DDX driver from
   xserver-xorg either. :)
 
  Ok, I'll try that on the hardware I have (i815 I think).

The drivers don't seem to get linked against libdrm, so its symbols are
unresolved. The r200 driver works fine with
LD_PRELOAD=/usr/lib/libdrm.so.1 though.


-- 
Earthling Michel Dänzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer

Re: mesag3 - xlibmesa-gl / libgl1-mesa-dri - xlibmesa-dri / libglu1-mesa - libglu1-xorg

2005-09-04 Thread Daniel Stone 
On Sun, 2005-09-04 at 09:04 -0600, Marcelo E. Magallon wrote:
 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 tarball.

Ah, yes, sorry.

  The programs in progs/util are not generally useful.  I could include
  them as examples in mesa-common or something like that.
 
  And I don't know where glxinfo is going to end up.  It's certainly not
  included with mesa atm.

Hm?  progs/xdemos/glxinfo.c.

   The problem with Mesa Build-Depping on glut is so:
 * mesa depends on glut to build, which depends on libgl1-mesa-dev
 * buildd goes to install libgl1-mesa-dev to fulfill B-Ds
 * libgl1-mesa-dev deps mesa-common-dev (= ${Source-Version})
 * mesa-common-dev version n is in the archive from the maintainer
   upload
 * but libgl1-mesa-dev for, say, hppa, is still n-1
  - uninstallable B-Ds
 
  Uhm, are we talking about mesa (not mesademos)?

Yeah.

 Mesa-6.3.2$ find ! -type d -print0 | xargs -r0 grep glut.h
 ./Makefile: $(DIRECTORY)/include/GL/glut.h  \
 ./docs/download.html:a 
 href=http://www.opengl.org/resources/libraries/glut.html;
 ./docs/README.WINDML:- src/ugl/ugl_glutshapes.c
 ./include/GL/gl.h: * including only glut.h, since glut.h depends on windows.h.
 ./include/GL/gl.h: * glut.h or gl.h.
 ./include/GL/uglglutshapes.h:/* uglglutshapes.h - Public header GLUT Shapes */
 ./progs/util/dumpstate.c:#include GL/glut.h
 ./progs/util/glstate.c:#include GL/glut.h
 ./progs/util/glutskel.c:#include GL/glut.h
 
  Like I said before, those programs are not generally useful, at least
  not in compiled form.

Hrm.  glxinfo still wants to link against libglut; I guess this is just
an artefact of the build system.

   As a short-term move, since we don't have Glide support in 6.3
   anyway, I just disabled the Glide packages and moved the headers
   across.
 
  I decided that Glide is too much of a hassle.  It will probably work
  again in 6.4, that's true, but I have decided to carry with the plan I
  had sketched a couple of years ago:
 
 * Regular drivers are built from the mesa package
 * Troublesome drivers (not being kept up to date, etc) are built
   from a second source package (mesa-legacy)
 * Whenever a new Mesa upstream is released, I look at it, if nothing
   breaks (and this has happened multiple times -- recall that mesa
   uses a x.y.z scheme, where odd y means in development) then I
   make an upload of the source package mesa to unstable
 * If one of the weird drivers breaks in the new upstream, then
   figure out if it's because of some small change.  If that's the
   case fix it.  If not (as is the case with glide in 6.3) then
   move the driver to the mesa-legacy package.
 * Once I figure the driver is being actively maintained, move it
   back to mesa
 
  In this way I keep the same set of binary packages, meaning that users
  won't be missing functionality, and I can keep the maintained drivers
  up to date.
 
  The mesa source package is structured in such a way that it allows for
  building either mesa or mesa-legacy, after tweaking debian/control, of
  course.  There's a small duplication of code (the mesa and mesa-legacy
  tarballs are sometimes the same file, sometimes not), but taking into
  account that the binary packages are *much* larger than the source I
  don't think that's something to gripe about.

Okay, this sounds fine to me.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: mesag3 - xlibmesa-gl / libgl1-mesa-dri - xlibmesa-dri / libglu1-mesa - libglu1-xorg

2005-09-03 Thread Michel Dänzer 
On Wed, 2005-08-31 at 21:55 -0600, Marcelo E. Magallon wrote:
 On Wed, Aug 31, 2005 at 10:35:55PM -0400, Michel Dänzer wrote:
 
 2) Someone with the proper hardware should test the several
(there's at least 8 of them IIRC) drivers that ship inside the
-dri package with the current (6.8) and future (6.9, 7.0) x.org
server.
   
   I'll gladly test the r200 driver once it's built on powerpc and the
   libgl1 issue mentioned above is solved.
 
  Can you just try the drivers?  I mean dpkg -x or something like that.

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-debug-i386
ln -sf debian-debug-i386 build/gl-debian-debug-i386/configs/current
if test gl != gl ; then mkdir -p build/gl-debian-debug-i386/lib/ ; ln
-sf ../../gl-debian-debug-i386/lib/libGL.so
build/gl-debian-debug-i386/lib/ ; fi
make -C build/gl-debian-debug-i386/src SRC_DIRS=mesa
make[1]: Entering directory
`/home/michdaen/debian/mesa-svn/trunk/build/gl-debian-debug-i386/src'
Making sources for debian-debug-i386
mkdir ../lib
make[2]: Entering directory
`/home/michdaen/debian/mesa-svn/trunk/build/gl-debian-debug-i386/src/mesa'
make[3]: Entering directory
`/home/michdaen/debian/mesa-svn/trunk/build/gl-debian-debug-i386/src/mesa'
make[4]: Entering directory
`/home/michdaen/debian/mesa-svn/trunk/build/gl-debian-debug-i386/src/mesa/x86'
cc -I../../../include/GL -I../../../include -I.. -I../main -I../math
-I../glapi -I../tnl -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L
-D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DUSE_XSHM -DPTHREADS
-I/usr/X11R6/include -DDEBUG -DMESA_DEBUG -ansi -pedantic -Wall -fPIC
-std=c99 -mcpu=i686 -msse -mfpmath=sse -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM gen_matypes.c -o gen_matypes
cc1: error: invalid option ‘sse’
cc1: error: invalid option ‘fpmath=sse’
gen_matypes.c:1: error: bad value (i686) for -mcpu= switch
[...]

(Keep in mind this is on powerpc)

I took a look at debian/rules, but it isn't obvious to me what the best
way to fix this is.

  I just need to know if they work fine with the current X server in
  unstable or if I need to wait for the 6.9 X server.

FWIW, we generally try to preserve backwards compatibility, so they
*should* work with the X server in sid. The r200 driver from Mesa CVS
certainly works here, although I'm not using the DDX driver from
xserver-xorg either. :)


  SVN is svn://svn.debian.org/svn/pkg-mesa/mesa/trunk and patches are
  most welcomed (BTS is easier, but my @d.o address should be fine).

The attached patch adds the IMO appropriate Conflicts:, Replaces: and
Provides: for libgl1-mesa-dri{,-dev}.


  And since I've got your attention Michel, if you figure there's an
  optimization for PowerPC that actually has some visible impact, I'll be
  glad to include that, too.  Please read debian/README.build.

Thanks for the pointer, but unfortunately, I can't think of anything
offhand.

  I really wish I had a PowerPC where I could port the optimized TL
  functions, PowerPC asm is *really* nice :-)

Yeah, that'd be very cool. :)


  And co-maintaining is always welcomed.

Okay, do you intend to use the pkg-mesa-devel list?


-- 
Earthling Michel Dänzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer
Index: debian/control
===
--- debian/control	(revision 26)
+++ debian/control	(working copy)
@@ -52,6 +52,9 @@
 Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, libglu1-mesa | libglu1
+Conflicts: libgl1
+Replaces: libgl1
+Provides: libgl1
 Description: A free implementation of the OpenGL API -- DRI runtime
  This version of Mesa provides hardware accelerated rendering
  capabilities via the Direct Rendering Interface (DRI) infraestructure.
@@ -62,6 +65,9 @@
 Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, libc6-dev, mesa-common-dev (= ${Source-Version}), libgl1-mesa-dri (=${Source-Version})
+Conflicts: libgl-dev
+Replaces: libgl-dev
+Provides: libgl-dev
 Description: A free implementation of the OpenGL API -- DRI development support files
  This version of Mesa provides hardware accelerated rendering
  capabilities via the Direct Rendering Interface (DRI) infraestructure.

Re: mesag3 - xlibmesa-gl / libgl1-mesa-dri - xlibmesa-dri / libglu1-mesa - libglu1-xorg

2005-09-01 Thread Daniel Stone 
On Wed, 2005-08-31 at 22:00 -0600, Marcelo E. Magallon wrote:
 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 the Arch: all build *had* to come last,
   etc).  I'll try to get it to you this week.
 
  Oh, you got me there.
 
  On GLUT?  I didn't spot that one.  The demos depend on GLUT, but I
  haven't updated those yet.

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.

The problem with Mesa Build-Depping on glut is so:
  * mesa depends on glut to build, which depends on libgl1-mesa-dev
  * buildd goes to install libgl1-mesa-dev to fulfill B-Ds
  * libgl1-mesa-dev deps mesa-common-dev (= ${Source-Version})
  * mesa-common-dev version n is in the archive from the maintainer
upload
  * but libgl1-mesa-dev for, say, hppa, is still n-1
   - uninstallable B-Ds

As a short-term move, since we don't have Glide support in 6.3 anyway, I
just disabled the Glide packages and moved the headers across.

  But don't rush, I was just wondering if the email got lost :-)

No, not at all.

  Please do check the 6.3.2 packages, I suspect we have fixed the same
  things each on our own.  I introduced another of those .map hacks for
  the drivers.  I also tried to make it easier to disable building some
  of the targets, guessing that other distros aren't interested in the
  more exotic ones.

Oh, excellent.  We're still building all the targets, but yeah.  I did a
bit of .map hacking for the drivers, allowing you to restrict things to
prefix and postfix.

I'll hopefully get to having a look at your packages tomorrow.  Again,
sorry I've been so slack, but I just haven't had any time.

Cheers,
Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: mesag3 - xlibmesa-gl / libgl1-mesa-dri - xlibmesa-dri / libglu1-mesa - libglu1-xorg

2005-08-31 Thread Marcelo E. Magallon 
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.1searchmode=searchfilescase=sensitiveversion=unstablearch=i386

 You'll notice:

usr/X11R6/lib/debug/libGL.so.1  libdevel/xlibmesa-gl-dbg
usr/X11R6/lib/libGL.so.1libs/xlibmesa-gl
usr/lib/dbg/i686/mmx/cmov/libGL.so.1libs/libgl1-mesa-dbg
usr/lib/dbg/libGL.so.1  libs/libgl1-mesa-dbg
usr/lib/debug/libGL.so.1libdevel/xlibmesa-gl-dbg
usr/lib/i686/mmx/cmov/libGL.so.1libs/mesag3
usr/lib/libGL.so.1  libs/libgl1-mesa-dri,
x11/nvidia-glx [non-free],
libs/xlibmesa-gl,
libs/mesag3

 (I have to upload the fix for the dbg thing, it's in svn now)

 xlibmesa-gl provides the DRI drivers shipped with the X.org X-server.

 mesag3 provides the software rasterizer shipped with mesa.

 nvidia-glx provides the hardware-accelerated driver for NVIDIA
 hardware (a second package is needed to support older NVIDIA hardware)

 libgl1-mesa-dri provides the DRI drivers that have been incorporated
 into Mesa upstream and which were formerly distributed only with the
 X-server.

 The GLU package is, uhm, I don't know.  At some point I talked with
 Branden about it, but we never did anything.  The xfree86 (and now the
 x.org) are the ones duplicating that code.  And this has nothing to do
 with some my turf/your turf thing.  It was more of a this code
 works, that code doesn't thing.  All three packages (libglu1-mesa,
 libglu1-xorg, xlibmesa-glu) are optional.  The -xorg thing is cute, but
 someone missed the point of -mesa (and I'm probably to blame).  -mesa
 is there because at some point there were two implementations shipped
 with Mesa.  The one by Brian Paul and the one from the OpenGL SI
 provided by SGI, so there were two packages (libglu1-mesa and
 libglu1-sgi).  The -sgi one was provided by a package that never made
 it thru the NEW queue and after some months I got sick of waiting and
 removed the package from the queue, so it never actually made it to the
 archive.  Anyways, it happened that at some other point Brian removed
 his implementation, fixed bugs in the SGI one and shipped that with
 Mesa.  That's why nowadays the -mesa package provides the SGI
 implementation.

 AFAIK, the -xorg package is byte for byte the same thing as the -mesa
 package.

  IIRC the xorg GL/GLU code is based on (older) mesa code.

 Mesa is merged every now and then into the X tree.  For example the 6.3
 release has been merged into the 6.9 X.org tree.  But in *general* Mesa
 contains code that's newer than whatever is in the X tree.

  Why this duplication of code and which of this two implementations is
  the preferred one?

 It depends

 What hardware do you have and what do you want to do?

 On some machines I have NVIDIA hardware because it's the only hardware
 that supports current OpenGL features both in the hardware and in its
 driver (a recent Radeon card is useless to me if it supports OpenGL 1.5
 but its driver doesn't, which is the case with the DRI drivers).

 On other machines I have some Intel embedded POS, which can use the
 Mesa drivers.  I haven't had the chance to actually test the
 libgl1-mesa-dri with the X.org xserver packages, but as far as I can
 see from the docs, it should work.  Be my guest and beat me to it if
 you want.

 And on some situations I actually *want* the Mesa software rasterizer,
 which I use by installing the GL driver to an adecuate location and
 setting LD_LIBRARY_PATH accordingly.

  Could I replace the xorg packages with the mesa packages without ill
  effects resp. without loss of functionality?

 You mean replacing xlibmesa-gl by libgl1-mesa-dri?  It should work, but
 haven't tested it.

 If it works, it should gain functionality, not lose it.

 Performance is something else :-]

  I noticed that Ubuntu renamed mesag3-libglu1-mesa and
  xlibmesa-gl-libgl1-xorg.

 Hopefully libglu1-mesa is a typo on your side.  The driver provided by
 mesag3 is a software rasterizer and the package *should* be named
 something like libgl1-mesa-soft (or swr or whatever, something that at
 least gives a hint about the type of driver it provides)

 Daniel approached me about renaming and I told him that I didn't have a
 strong position in either way (renaming or not renaming).  In general I
 avoid cosmetic package renames, which is what this is.  I mean, there's
 hardly enough people around who even remember why mesag3 is called
 that, and there's less people around who can actually argue for a name
 change with something not cosmetic (and no, your policy says so card
 isn't good enough, since my upgrade path one beats yours to death).

Re: mesag3 - xlibmesa-gl / libgl1-mesa-dri - xlibmesa-dri / libglu1-mesa - libglu1-xorg

2005-08-31 Thread Michael Biebl 
Thanks for your answers, Marcelo.

   I noticed that Ubuntu renamed mesag3-libglu1-mesa and
   xlibmesa-gl-libgl1-xorg.
 
  Hopefully libglu1-mesa is a typo on your side.  The driver provided by
  mesag3 is a software rasterizer and the package *should* be named
  something like libgl1-mesa-soft (or swr or whatever, something that at
  least gives a hint about the type of driver it provides)

You're right. It's not libglu1-mesa but libgl1-mesa. While my Debian
unstable box still has a mesag3 package, a current Ubuntu Breezy only
has a package libgl1-mesa, which conflicts with mesag3 and provides the
virtual package mesag3. Same for xlibmesa-gl. This package was
renamed/replaced by libgl1-xorg and is now completely removed from
Ubuntu Breezy. It seems there were many renamings lastly in Ubuntu
Breezy(1):
mesag3-libgl1-mesa
xlibmesa-gl-libgl-xorg
xlibmesa-glu-libglu1
and new packages
libglu1-mesa providing libglu1
libgl1-mesa-dri providing libgl1-dri

x-window-system-core in Ubuntu Breezy now depends on
libgl1-mesa-dri/libgl1-mesa/libglu1-mesa while as in unstable it is
xlibmesa-dri/xlibmesa-gl/liblu1-xorg.
I got the impression that this is an attempt to get a consistent naming
scheme as a first step in order to prepare for the X11R6.9/X11R7.0
release. IIRC X11R6.9 and X11R7.0 will use an installed mesa package to
provide OpenGL functionality and will not need it's own copy of mesa
anymore.
Maybe I'm completely wrong and I only got confused a little bit by all
this package renamings lately.


Cherrs,
Michael

(1) I know that this is d-d and not the ubuntu m-l. It just seems that
the Ubuntu packages for X are slightly ahead of Debian and I just
wondered if Debian will take the same path.

-- 

E-Mail: [EMAIL PROTECTED]
WWW: http://www.teco.edu/

TecO (Telecooperation Office) Vincenz-Priessnitz-Str.1
University of Karlsruhe 76131 Karlsruhe, Germany



signature.asc
Description: OpenPGP digital signature

Re: mesag3 - xlibmesa-gl / libgl1-mesa-dri - xlibmesa-dri / libglu1-mesa - libglu1-xorg

2005-08-31 Thread Daniel Stone 
On Wed, 2005-08-31 at 17:25 -0600, Marcelo E. Magallon wrote:
  Daniel also said he'd send a package via email which I never got, so I
  went ahead and did my own thing.  (No Matt, I'm not happy with the idea
  of fishing patches out of some random, cluttered, and very unusable
  webpage; everything I've fixed in Mesa over the years has found its way
  to Brian Paul in the format he wants it over the channels he wants it,
  so I expect the same from my downstreams).

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 the Arch: all build *had* to come last, etc).
I'll try to get it to you this week.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: mesag3 - xlibmesa-gl / libgl1-mesa-dri - xlibmesa-dri / libglu1-mesa - libglu1-xorg

2005-08-31 Thread Michel Dänzer 
On Wed, 2005-08-31 at 17:25 -0600, Marcelo E. Magallon wrote:
 On Wed, Aug 31, 2005 at 02:41:05AM +0200, Michael Biebl wrote:
 
  The GLU package is, uhm, I don't know.  At some point I talked with
  Branden about it, but we never did anything.  The xfree86 (and now the
  x.org) are the ones duplicating that code.  And this has nothing to do
  with some my turf/your turf thing.  It was more of a this code
  works, that code doesn't thing.  All three packages (libglu1-mesa,
  libglu1-xorg, xlibmesa-glu) are optional.  The -xorg thing is cute, but
  someone missed the point of -mesa (and I'm probably to blame).  -mesa
  is there because at some point there were two implementations shipped
  with Mesa.  The one by Brian Paul and the one from the OpenGL SI
  provided by SGI, so there were two packages (libglu1-mesa and
  libglu1-sgi).  The -sgi one was provided by a package that never made
  it thru the NEW queue and after some months I got sick of waiting and
  removed the package from the queue, so it never actually made it to the
  archive.  Anyways, it happened that at some other point Brian removed
  his implementation, fixed bugs in the SGI one and shipped that with
  Mesa.  That's why nowadays the -mesa package provides the SGI
  implementation.
 
  AFAIK, the -xorg package is byte for byte the same thing as the -mesa
  package.

And I've suggested getting rid of xlibmesa-glu{,-dbg,-dev} several
times, without success. However, this will happen automatically with
X.Org 7.0, see below.


   Why this duplication of code and which of this two implementations is
   the preferred one?
 
  It depends
 
  What hardware do you have and what do you want to do?
 
  On some machines I have NVIDIA hardware because it's the only hardware
  that supports current OpenGL features both in the hardware and in its
  driver (a recent Radeon card is useless to me if it supports OpenGL 1.5
  but its driver doesn't, which is the case with the DRI drivers).

OT_plugThere's a vendor provided driver for these cards that supports
current OpenGL features as well./OT_plug


   Could I replace the xorg packages with the mesa packages without ill
   effects resp. without loss of functionality?
 
  You mean replacing xlibmesa-gl by libgl1-mesa-dri?  It should work, but
  haven't tested it.

It would have to Conflicts-Replaces-Provides libgl1 for that to work.


   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 mesa directly as an external library?  If there is
   such a transition how will it take place?
 
  Not currently, or at least not one that I know of.

X.Org will indeed no longer ship copies of the Mesa bits as of 7.0.
That'll be an automatic transition so to speak. :)


  2) Someone with the proper hardware should test the several (there's at
 least 8 of them IIRC) drivers that ship inside the -dri package with
 the current (6.8) and future (6.9, 7.0) x.org server.

I'll gladly test the r200 driver once it's built on powerpc and the
libgl1 issue mentioned above is solved.


  My interest in the mesa package comes from the fact that I develop
  OpenGL-based applications, which is why I picked it up when it was
  orphaned and why I've been maintaining it for the last few years.

And you've been doing a great job, keep it up. But if you could use a
helping hand, I wouldn't mind co-maintaining or something. No request,
just an offer.


-- 
Earthling Michel Dänzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer

Re: mesag3 - xlibmesa-gl / libgl1-mesa-dri - xlibmesa-dri / libglu1-mesa - libglu1-xorg

2005-08-31 Thread Marcelo E. Magallon 
On Thu, Sep 01, 2005 at 03:20:10AM +0200, Michael Biebl wrote:

  x-window-system-core in Ubuntu Breezy now depends on
  libgl1-mesa-dri/libgl1-mesa/libglu1-mesa while as in unstable it is
  xlibmesa-dri/xlibmesa-gl/liblu1-xorg.

 If that's right, that's broken, too.

 It should at most recommend libgl1-mesa-dri | libgl1.  There's really
 no reason to pull OpenGL with the X Window System.  There are small
 systems which really don't need it.

  I got the impression that this is an attempt to get a consistent
  naming scheme as a first step in order to prepare for the
  X11R6.9/X11R7.0 release. IIRC X11R6.9 and X11R7.0 will use an
  installed mesa package to provide OpenGL functionality and will not
  need it's own copy of mesa anymore.

 Probably, which in itself is not wrong.

-- 
Marcelo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: mesag3 - xlibmesa-gl / libgl1-mesa-dri - xlibmesa-dri / libglu1-mesa - libglu1-xorg

2005-08-31 Thread Marcelo E. Magallon 
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 mesa directly as an
 external library?  If there is such a transition how will it
 take place?
   
Not currently, or at least not one that I know of.
  
  X.Org will indeed no longer ship copies of the Mesa bits as of 7.0.
  That'll be an automatic transition so to speak. :)

 For that to happen we just need to figure out how the drivers interact
 with each other (I mean the DRI bits in the X server with the
 client-side DRI bits shipped by Mesa 6.3).

2) Someone with the proper hardware should test the several
   (there's at least 8 of them IIRC) drivers that ship inside the
   -dri package with the current (6.8) and future (6.9, 7.0) x.org
   server.
  
  I'll gladly test the r200 driver once it's built on powerpc and the
  libgl1 issue mentioned above is solved.

 Can you just try the drivers?  I mean dpkg -x or something like that.
 I just need to know if they work fine with the current X server in
 unstable or if I need to wait for the 6.9 X server.

 The reason I ask this is because the mesa packages take some time to
 build (~ 30 minutes on my PC and I really don't want to know how long
 on other architectures), so I'd prefer to make as few uploads as
 possible.  I have already spotted a couple of problems with the -1
 release.

 SVN is svn://svn.debian.org/svn/pkg-mesa/mesa/trunk and patches are
 most welcomed (BTS is easier, but my @d.o address should be fine).

 And since I've got your attention Michel, if you figure there's an
 optimization for PowerPC that actually has some visible impact, I'll be
 glad to include that, too.  Please read debian/README.build.

 I really wish I had a PowerPC where I could port the optimized TL
 functions, PowerPC asm is *really* nice :-)

 That goes for the AMD64 folk, too.

  And you've been doing a great job, keep it up. But if you could use a
  helping hand, I wouldn't mind co-maintaining or something. No
  request, just an offer.

 Since Mesa suddenly includes a lot more drivers that I can't test, I'd
 really appreciate even a heads up it's working fine with this
 hardware.

 And co-maintaining is always welcomed.

-- 
Marcelo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: mesag3 - xlibmesa-gl / libgl1-mesa-dri - xlibmesa-dri / libglu1-mesa - libglu1-xorg

2005-08-31 Thread Marcelo E. Magallon 
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 the Arch: all build *had* to come last,
  etc).  I'll try to get it to you this week.

 Oh, you got me there.

 On GLUT?  I didn't spot that one.  The demos depend on GLUT, but I
 haven't updated those yet.

 But don't rush, I was just wondering if the email got lost :-)

 Please do check the 6.3.2 packages, I suspect we have fixed the same
 things each on our own.  I introduced another of those .map hacks for
 the drivers.  I also tried to make it easier to disable building some
 of the targets, guessing that other distros aren't interested in the
 more exotic ones.

-- 
Marcelo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]