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 | 24 comments |
headers
Marc 'HE' Brockschmidt | 1 Sep 2005 01:29
Picon
Favicon

Re: To Linux or not to Linux

Yavor Doganov <yavor <at> doganov.org> writes:
> On Wed, 31 Aug 2005 07:35:23 -0600, Wesley J. Landaker wrote:
>> That and--it will make most of us cringle--when other kernels are popular, 
>> you'll hear lots of stuff like:
> The reason for calling it GNU (ok, GNU/Linux as the the other ports are
> not yet in a releasable state) is to enable people to find out how
> everything started and read www.gnu.org, understand the reasons, and
> eventually agree with them and why not, start to contribute and spread the
> freedom.

This is more or less valid, but please think of the context - in this
case, people should find the way to the *Debian* homepage and find out
about Debian. Especially since there are some problems between Debian
and the FSF that are still not resolved.

That's why I don't care if we call our distribution Debian Linux, Debian
GNU/Linux, Debian GNU or Debian GNU/kFreeBSD (I mean, we provide the
usual GNU userland for it, right?)

Marc
--

-- 
BOFH #409:
The vulcan-death-grip ping has been applied.
Permalink | Reply | 1 comment |
headers
Wesley J. Landaker | 1 Sep 2005 02:24
X-Face
Favicon
Gravatar

Re: To Linux or not to Linux

On Wednesday 31 August 2005 09:49, Yavor Doganov wrote:
> On Wed, 31 Aug 2005 07:35:23 -0600, Wesley J. Landaker wrote:
> > That and--it will make most of us cringle--when other kernels are
> > popular, you'll hear lots of stuff like:
>
> The reason for calling it GNU (ok, GNU/Linux as the the other ports are
[...]
> By calling it simply "Linux" you mislead the people -- they will know
[...]

Which was kind of my point; Linux is already a term that has been overloaded 
far too much, so we should be careful in our naming if we want to avoid 
dialogs like the one I made up from becoming more of reality than they 
already are. =)

--

-- 
Wesley J. Landaker <wjl <at> icecavern.net> <xmpp:wjl <at> icecavern.net>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2
Permalink | Reply | 0 comments |
headers
Steve McIntyre | 1 Sep 2005 02:14
Favicon

Re: mass bug filing on packages that are blocking use of cdebconf

Joey Hess wrote:

...

>Steve McIntyre <93sam <at> debian.org>
>   cvs
>   nas
>   seyon

New versions of all three uploaded tonight to fix this...

--

-- 
Steve McIntyre, Cambridge, UK.                                steve <at> einval.com
"Because heaters aren't purple!" -- Catherine Pitt
Permalink | Reply | 0 comments |
headers
Robert Collins | 1 Sep 2005 02:35

Re: arch, svn, cvs

On Wed, 2005-08-31 at 00:17 +0200, martin f krafft wrote:
> Could you please elaborate on this?

Hmm. Where to start :0. perhaps with storage. bzr currently stores the
different variations of each file that is versioned in 'stores', which
are a collection of files named by their hash, gzipped. (Its been doing
this since January). We're about to migrate to using a thing called a
'weave', which linear time annotation with respect to the number of line
variations in a file. Once we've done this transition, the storage will
look somewhat like sccs. When a commit occurs, a minimum of 2 file
alterations occur:
- we create a new 'revision' file which records the date, user, log
message, and a reference to an inventory of the tree at the time of the
commit.
- we append the hash of the revision to the revision-history file in
the .bzr directory.
- If the shape of the tree has changed - if files have been altered or
added or deleted - then we record a new inventory for the tree, which
has the full shape of the tree. The storage we use works fine on
windows, Mac OS X, and on Un*x. It also works happily over sftp and http
- no smart server is required. (We have plans for an optional smart
server post release).

So this looks rather like a 'snapshot' based system. However, we use
persistent unique file identifiers to track renames and to allow merging
between branches with files that have been renamed, without needing to
calculate back in time for the current name of the file. (This was one
of the key things GNU Arch does that bazaar-NG has incorporated).

Merges are tracked at both the file and revision level - a file has
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wesley J. Landaker | 1 Sep 2005 02:39
X-Face
Favicon
Gravatar

Re: To Linux or not to Linux

On Wednesday 31 August 2005 17:29, Marc 'HE' Brockschmidt wrote:
> That's why I don't care if we call our distribution Debian Linux, Debian
> GNU/Linux, Debian GNU or Debian GNU/kFreeBSD (I mean, we provide the
> usual GNU userland for it, right?)

Another interesting point is that if we lambaste people for using "Linux" to 
refer to free operatings systems based on most of GNU, and Linus' kernel, 
we also ought to be careful what we call "GNU", since if you, for instance, 
run Debian, and you say, "I run nothing but GNU" (implying you don't use 
other popular operating systems like FreeBSD, MS Windows or Mac OSX) you're 
just as innaccurate as if you said, "I run nothing but Linux" (implying the 
same thing). 

I see a lot of push for "It's not Linux, it's GNU!"; but that isn't really 
any more accurate, unless you *really are* running GNU. Just something to 
think about. =)

(Personally, I'm usually happy to just call it "Debian" when promoting it's 
use -- we'd still be Debian even if we replaced all GNU software with 
alternative implementations.)

--

-- 
Wesley J. Landaker <wjl <at> icecavern.net> <xmpp:wjl <at> icecavern.net>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2
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 | 1 comment |
headers
Joey Hess | 1 Sep 2005 03:28
Picon
Favicon
Gravatar

Re: mass bug filing on packages that are blocking use of cdebconf

Javier Fernández-Sanguino Peña wrote:
> >    spellcast
> 
> Spellcast 1.0-19 was uploaded Aug 6th 2005 and does not use debconf anymore.

joey <at> dragon:~>apt-cache show spellcast | egrep Version\|Depends
Version: 1.0-19
Depends: debconf, gettext, libc6 (>= 2.3.2.ds1-21), libx11-6 | xlibs (>> 4.1.0)
         ^^^^^^^

--

-- 
see shy jo
Permalink | Reply | 1 comment |
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 | 8 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 | 8 comments |

Gmane