headers
Marcelo E. Magallon | 1 Sep 2005 01:25
Picon
Favicon

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

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=unstable&arch=i386

 You'll notice:

    usr/X11R6/lib/debug/libGL.so.1          libdevel/xlibmesa-gl-dbg
    usr/X11R6/lib/libGL.so.1                libs/xlibmesa-gl
    usr/lib/dbg/i686/mmx/cmov/libGL.so.1    libs/libgl1-mesa-dbg
    usr/lib/dbg/libGL.so.1                  libs/libgl1-mesa-dbg
    usr/lib/debug/libGL.so.1                libdevel/xlibmesa-gl-dbg
    usr/lib/i686/mmx/cmov/libGL.so.1        libs/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)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Biebl | 1 Sep 2005 03:20
Favicon

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

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Stone | 1 Sep 2005 04:07
Gravatar

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

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.
Permalink | Reply | 0 comments |
headers
Michel Dänzer | 1 Sep 2005 04:35
Picon
Favicon

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

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?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marcelo E. Magallon | 1 Sep 2005 05:55
Picon
Favicon

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

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcelo E. Magallon | 1 Sep 2005 06:00
Picon
Favicon

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

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
Permalink | Reply | 0 comments |
headers
Aurelio Turco | 1 Sep 2005 10:17
Picon
Picon
Favicon

Security hole in xdm/xlogin?

As specified in man xdm, I tried setting

   xlogin.Login.allowRootLogin: false

in /etc/X11/xdm/Xresources

but it doesnt work; root can still login via xdm.
Permalink | Reply | 0 comments |
headers
Daniel Stone | 1 Sep 2005 06:58
Gravatar

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

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
X Strike Force SVN Repository Admin | 1 Sep 2005 21:38

X Strike Force XFree86 SVN commit: r2293 - branches/4.3.0

Author: fjp
Date: 2005-09-01 14:38:33 -0500 (Thu, 01 Sep 2005)
New Revision: 2293

Removed:
   branches/4.3.0/sarge/
Log:
4.3.0.dfsg.1-14 was not released from trunk, but from the sid branch;
therefore the creation of this sarge branch was incorrect

--

-- 
To UNSUBSCRIBE, email to debian-x-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org
Permalink | Reply | 0 comments |
headers
X Strike Force SVN Repository Admin | 1 Sep 2005 21:41

X Strike Force XFree86 SVN commit: r2294 - branches/4.3.0

Author: fjp
Date: 2005-09-01 14:41:35 -0500 (Thu, 01 Sep 2005)
New Revision: 2294

Added:
   branches/4.3.0/sarge/
Removed:
   branches/4.3.0/sid/
Log:
Rename sid branch to 'sarge' as this corresponds to 4.3.0.dfsg.1-14;
having a sid branch for xfree86 no longer serves any purpose.

Copied: branches/4.3.0/sarge (from rev 2292, branches/4.3.0/sid)

--

-- 
To UNSUBSCRIBE, email to debian-x-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org
Permalink | Reply | 0 comments |

Gmane