'bzr init-repo .' crashes for lack of module bz2. Help, please!

'bzr init-repo .' crashes for lack of module bz2. Help, please!

[Alan Mackenzie]

Hi, emacs!

I've just installed bazaar-2.0.3 on my Debian G/L box; I did this by
downloading the source tarball, unpacking it and running 'python
setup.py install' as root.  Before doing this, I had downloaded and
unpacked http://effbot.org/zone/element-index.htm as hinted in the file
INSTALL.

On doing 'bzr init-repo .' bzr crashes with:

  bzr: ERROR: exceptions.ImportError: failed to load bzrlib.repofmt.groupcompress_repo.RepositoryFormat2a: No module named bz2

, followed by a backtrace.

It seems my installation of bzr was somehow incomplete, despite
following the instructions in bzr's INSTALL.

Would somebody help me, please.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: 'bzr init-repo .' crashes for lack of module bz2. Help, please!

[Karl Fogel]

Alan Mackenzie <acm@muc.de> writes:
> I've just installed bazaar-2.0.3 on my Debian G/L box; I did this by
> downloading the source tarball, unpacking it and running 'python
> setup.py install' as root.  Before doing this, I had downloaded and
> unpacked http://effbot.org/zone/element-index.htm as hinted in the file
> INSTALL.
>
> On doing 'bzr init-repo .' bzr crashes with:
>
>   bzr: ERROR: exceptions.ImportError: failed to load bzrlib.repofmt.groupcompress_repo.RepositoryFormat2a: No module named bz2
>
> , followed by a backtrace.
>
> It seems my installation of bzr was somehow incomplete, despite
> following the instructions in bzr's INSTALL.
>
> Would somebody help me, please.

Urgk.  I'm not familiar with that one, sorry.  I suggest asking on

  bazaar {_AT_} lists.ubuntu.com

(assuming the usual technique of doing an Internet search for the error
hasn't produced anything useful).

-K

Re: 'bzr init-repo .' crashes for lack of module bz2. Help, please!

[David De La Harpe Golden]

Alan Mackenzie wrote:

> Would somebody help me, please.

What debian version are you running? Probably lenny (current stable), as 
etch (current oldstable) is about to EOL.

Firstly, bzr 2.0.2 is currently packaged in  debian lenny-backports.
http://packages.debian.org/lenny-backports/bzr
Dunno if 2.0.2->2.0.3 matters much.  But using a nicely packaged 
backport is likely to be less painful.

Note 2.0.3 is packaged in debian unstable.

As regards your error:

 > No module named bz2

Hmm. Module bz2 is bundled with python since python 2.3
Can you type "python" to get a python repl, then type "import bz2" to 
try to import it?  If that fails, there's something broken
with your python - though presumably you're using the debian
packaging of it?

Re: 'bzr init-repo .' crashes for lack of module bz2. Help, please!

[Alan Mackenzie]

Hi, David,

Thanks for the reply!

On Mon, Dec 28, 2009 at 11:05:15PM +0000, David De La Harpe Golden wrote:
> Alan Mackenzie wrote:

> >Would somebody help me, please.

> What debian version are you running? Probably lenny (current stable), as 
> etch (current oldstable) is about to EOL.

I've got an old Debian Sarge with a hosed package management system.
That's why I always build from source.

> Firstly, bzr 2.0.2 is currently packaged in  debian lenny-backports.
> http://packages.debian.org/lenny-backports/bzr
> Dunno if 2.0.2->2.0.3 matters much.  But using a nicely packaged 
> backport is likely to be less painful.

> Note 2.0.3 is packaged in debian unstable.

> As regards your error:

> > No module named bz2

> Hmm. Module bz2 is bundled with python since python 2.3
> Can you type "python" to get a python repl, then type "import bz2" to 
> try to import it?

Thanks!  I'd assumed that bz2 was part of bzr (similar name), but it
really is part of Python.  My previous build of Python hadn't built bz2.

So I downloaded Python-2.6.4 this morning and built it.  It failed to
build bz2, the sole diagnostic being:

    Failed to find the necessary bits to build these modules:
    _bsddb             _hashlib           _sqlite3
    _ssl               _tkinter           bsddb185
    bz2                dbm                gdbm
    readline           sunaudiodev
    To find the necessary bits, look in setup.py in detect_modules() for
    the module's name.

The sole "necessary bit" for bz2 appears to be bz2module.c, which exists
in the Python source tree.  It appears not to have been compiled (there
is no bz2module.o).  There is nothing else helpful in the build
procedure's stdout or stderr.  Any ideas?

> If that fails, there's something broken with your python - though
> presumably you're using the debian packaging of it?

No.  My package manager is totally hosed.  Yes.  My python is broken.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: 'bzr init-repo .' crashes for lack of module bz2. Help, please!

[Andreas Schwab]

Alan Mackenzie <acm@muc.de> writes:

> The sole "necessary bit" for bz2 appears to be bz2module.c, which exists
> in the Python source tree.  It appears not to have been compiled (there
> is no bz2module.o).  There is nothing else helpful in the build
> procedure's stdout or stderr.  Any ideas?

Most likely you lack bzip2.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: 'bzr init-repo .' crashes for lack of module bz2. Help, please!

[Alan Mackenzie]

On Tue, Dec 29, 2009 at 09:19:06PM +0100, Andreas Schwab wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > The sole "necessary bit" for bz2 appears to be bz2module.c, which
> > exists in the Python source tree.  It appears not to have been
> > compiled (there is no bz2module.o).  There is nothing else helpful in
> > the build procedure's stdout or stderr.  Any ideas?

> Most likely you lack bzip2.

No, I have bzip2 (used it this morning on the Python tarball), including,
in particular, /usr/lib/libbz2.so.1.0.2 (with an appropriate symlink with
a truncated name).

> Andreas.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: 'bzr init-repo .' crashes for lack of module bz2. Help, please!

[David De La Harpe Golden]

Alan Mackenzie wrote:
> On Tue, Dec 29, 2009 at 09:19:06PM +0100, Andreas Schwab wrote:
>> Alan Mackenzie <acm@muc.de> writes:
> 
>>> The sole "necessary bit" for bz2 appears to be bz2module.c, which
>>> exists in the Python source tree.  It appears not to have been
>>> compiled (there is no bz2module.o).  There is nothing else helpful in
>>> the build procedure's stdout or stderr.  Any ideas?
> 
>> Most likely you lack bzip2.
> 
> No, I have bzip2 (used it this morning on the Python tarball), including,
> in particular, /usr/lib/libbz2.so.1.0.2 (with an appropriate symlink with
> a truncated name).
>

Just in case: and the relevant bz2 header /usr/include/bzlib.h  ?
Would probably be in package libbz2-dev in debian.

Re: 'bzr init-repo .' crashes for lack of module bz2. Help, please!

[Alan Mackenzie]

Hi, David,

On Tue, Dec 29, 2009 at 11:49:15PM +0000, David De La Harpe Golden wrote:
> Alan Mackenzie wrote:
> >On Tue, Dec 29, 2009 at 09:19:06PM +0100, Andreas Schwab wrote:
> >>Alan Mackenzie <acm@muc.de> writes:

> >>>The sole "necessary bit" for bz2 appears to be bz2module.c, which
> >>>exists in the Python source tree.  It appears not to have been
> >>>compiled (there is no bz2module.o).  There is nothing else helpful
> >>>in the build procedure's stdout or stderr.  Any ideas?

> >>Most likely you lack bzip2.

> >No, I have bzip2 (used it this morning on the Python tarball),
> >including, in particular, /usr/lib/libbz2.so.1.0.2 (with an
> >appropriate symlink with a truncated name).

> Just in case: and the relevant bz2 header /usr/include/bzlib.h  ?
> Would probably be in package libbz2-dev in debian.

I was lacking this file, so I downloaded and built the latest version of
bzip2.  I still get the same error message, which I don't understand,
namely:

    bzr: ERROR: exceptions.ImportError: failed to load bzrlib.repofmt.groupcompress_repo.RepositoryFormat2a: No module named bz2

Presumably "bzrlib.repofmt.groupcompress_repo" means the file
.../bzrlib/repofmt/groupcompress_repo.py, but what, exactly, is a "module
named bz2"?  What is its filename, where is bzr (or Python?) looking for
it?

I've tried, but failed, to submit a bug report for this.  The maintainers
of bzr use a tool called "Launchpad", which uses a gaudy log-in script
which breaks horribly on my ancient Firefox.  To submit a bug about
Launchpad, you've got to use, er, Launchpad.  Talk about sub-optimal
intelligence.  ;-(

I'd really like to get all this difficult stuff fixed so that I can get
back to something nice and easy like CC Mode.  ;-(

Here is the entire diagnostic from my attempt to run 'bzr init-repo .'.
Further help would be most appreciated:

*************************************************************************

acm@acm:~/emacs/emacs.bzr$ bzr init-repo .
bzr: ERROR: exceptions.ImportError: failed to load bzrlib.repofmt.groupcompress_repo.RepositoryFormat2a: No module named bz2

Traceback (most recent call last):
  File "/usr/local/lib/python2.6/site-packages/bzrlib/commands.py", line 842, in exception_to_return_code
    return the_callable(*args, **kwargs)
  File "/usr/local/lib/python2.6/site-packages/bzrlib/commands.py", line 1037, in run_bzr
    ret = run(*run_argv)
  File "/usr/local/lib/python2.6/site-packages/bzrlib/commands.py", line 654, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/usr/local/lib/python2.6/site-packages/bzrlib/builtins.py", line 1788, in run
    format = bzrdir.format_registry.make_bzrdir('default')
  File "/usr/local/lib/python2.6/site-packages/bzrlib/bzrdir.py", line 3452, in make_bzrdir
    return self.get(key)()
  File "/usr/local/lib/python2.6/site-packages/bzrlib/bzrdir.py", line 3402, in helper
    bd.repository_format = _load(repository_format)
  File "/usr/local/lib/python2.6/site-packages/bzrlib/bzrdir.py", line 3387, in _load
    raise ImportError('failed to load %s: %s' % (full_name, e))
ImportError: failed to load bzrlib.repofmt.groupcompress_repo.RepositoryFormat2a: No module named bz2

bzr 2.0.3 on python 2.6.4 (Linux-2.6.8-i686-with-debian-3.1)
arguments: ['/usr/local/bin/bzr', 'init-repo', '.']
encoding: 'ISO-8859-1', fsenc: 'ISO-8859-1', lang: 'en_GB'
plugins:
  launchpad            /usr/local/lib/python2.6/site-packages/bzrlib/plugins/launchpad [2.0.3]
  netrc_credential_store /usr/local/lib/python2.6/site-packages/bzrlib/plugins/netrc_credential_store [2.0.3]

*** Bazaar has encountered an internal error.  This probably indicates a
    bug in Bazaar.  You can help us fix it by filing a bug report at
        https://bugs.launchpad.net/bzr/+filebug
    including this traceback and a description of the problem.

*************************************************************************

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: 'bzr init-repo .' crashes for lack of module bz2. Help, please!

[David De La Harpe Golden]

Alan Mackenzie wrote:
> Hi, David,
> 
> On Tue, Dec 29, 2009 at 11:49:15PM +0000, David De La Harpe Golden wrote:
>> Alan Mackenzie wrote:
>>> On Tue, Dec 29, 2009 at 09:19:06PM +0100, Andreas Schwab wrote:
>>>> Alan Mackenzie <acm@muc.de> writes:
> 
>>>>> The sole "necessary bit" for bz2 appears to be bz2module.c, which
>>>>> exists in the Python source tree.  It appears not to have been
>>>>> compiled (there is no bz2module.o).  There is nothing else helpful
>>>>> in the build procedure's stdout or stderr.  Any ideas?
> 
>>>> Most likely you lack bzip2.
> 
>>> No, I have bzip2 (used it this morning on the Python tarball),
>>> including, in particular, /usr/lib/libbz2.so.1.0.2 (with an
>>> appropriate symlink with a truncated name).
> 
>> Just in case: and the relevant bz2 header /usr/include/bzlib.h  ?
>> Would probably be in package libbz2-dev in debian.
> 
> I was lacking this file, so I downloaded and built the latest version of
> bzip2. 

And rebuild python against this version, right, with "bz2" absent from
the list of modules that failed to build this time due to failure to 
"find the necessary bits"? Does the "python" to
get a python repl then "import bz2" test succeed now?

Maybe there's a way to turn on more verbosity during python
building.  I can see the relevant bundled extension module building 
during python "make" output as follows:

...
building 'bz2' extension
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall 
-Wstrict-prototypes -I. -I/usr/local/src/Python-2.6.4/./Include -I. 
-IInclude -I./Include -I/usr/local/include 
-I/usr/local/src/Python-2.6.4/Include -I/usr/local/src/Python-2.6.4 -c 
/usr/local/src/Python-2.6.4/Modules/bz2module.c -o 
build/temp.linux-x86_64-2.6/usr/local/src/Python-2.6.4/Modules/bz2module.o
gcc -pthread -shared 
build/temp.linux-x86_64-2.6/usr/local/src/Python-2.6.4/Modules/bz2module.o 
-L/usr/local/lib -lbz2 -o build/lib.linux-x86_64-2.6/bz2.so
building 'pyexpat' extension
...


> I still get the same error message, which I don't understand,
> namely:
> 
>     bzr: ERROR: exceptions.ImportError: failed to load bzrlib.repofmt.groupcompress_repo.RepositoryFormat2a: No module named bz2
> 
> Presumably "bzrlib.repofmt.groupcompress_repo" means the file
> .../bzrlib/repofmt/groupcompress_repo.py, but what, exactly, is a "module
> named bz2"? 

In this case, it means a python extension "module" being a python 
binding to libbz2 (*).  Such extensions are atypical python modules 
implemented as C libs rather than python. The C code uses the python C 
implementation's ("cpython") C API to act like a python module to python 
code running under that implementation, providing additional 
python-callable functions and python-usable data types.  It's actually a 
pretty typical way of extending scripting languages implemented in C, 
though python has now also introduced the more Lisp-conventional "FFI" 
approach for such things in module "ctypes" (just mentioning for 
completeness).
http://docs.python.org/extending/index.html
http://docs.python.org/library/ctypes.html

(*) bzr is presumably using bzip2 compression internally.

 > What is its filename, where is bzr (or Python?) looking for
> it?
> 

python is looking for it, in the python module search path probably, 
since it's not finding the extension module bz2.  But it's IMO pretty
definitely the normal python-bundled extension module bz2 you need.

On a successful python installation, it'll probably be somewhere
like
/usr/local/lib/python2.6/lib-dynload/bz2.so

Re: 'bzr init-repo .' crashes for lack of module bz2. Help, please!

[Alan Mackenzie]

Hi, David,

On Thu, Dec 31, 2009 at 05:04:41PM +0000, David De La Harpe Golden wrote:
> Alan Mackenzie wrote:

> >I was lacking this file [bzlib.h], so I downloaded and built the
> >latest version of bzip2. 

> And rebuild python against this version, right, with "bz2" absent from
> the list of modules that failed to build this time due to failure to 
> "find the necessary bits"? Does the "python" to
> get a python repl then "import bz2" test succeed now?

That's what I did, and no "import bz2" didn't succeed.  However, it did
once I'd remembered to do "make install" on the newly build Python.

[ .... ]

> >I still get the same error message, which I don't understand,
> >namely:

> >    bzr: ERROR: exceptions.ImportError: failed to load
> >    bzrlib.repofmt.groupcompress_repo.RepositoryFormat2a: No module
> >    named bz2

> >Presumably "bzrlib.repofmt.groupcompress_repo" means the file
> >.../bzrlib/repofmt/groupcompress_repo.py, but what, exactly, is a "module
> >named bz2"? 

> In this case, it means a python extension "module" being a python 
> binding to libbz2 (*).  Such extensions are atypical python modules 
> implemented as C libs rather than python. The C code uses the python C 
> implementation's ("cpython") C API to act like a python module to python 
> code running under that implementation, providing additional 
> python-callable functions and python-usable data types.  It's actually a 
> pretty typical way of extending scripting languages implemented in C, 
> though python has now also introduced the more Lisp-conventional "FFI" 
> approach for such things in module "ctypes" (just mentioning for 
> completeness).
> http://docs.python.org/extending/index.html
> http://docs.python.org/library/ctypes.html

Thanks for this explanation.

I've now got bzip2, Python and bzr installed and talking to each other,
such that I can carry on with the BzrForEmacsDevs on the Emacs wiki.
Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: 'bzr init-repo .' crashes for lack of module bz2. Help, please!

[Tassilo Horn]

Alan Mackenzie <acm@muc.de> writes:

Hi Alan,

> I've now got bzip2, Python and bzr installed and talking to each
> other, such that I can carry on with the BzrForEmacsDevs on the Emacs
> wiki.  Thanks!

I'm just curious, but why didn't you just reinstall your system instead
of working around your broken package manager, thereby deferring that
task only a bit into the future?  I'd go nuts with such a severely
broken system. :-)

Bye,
Tassilo

Re: 'bzr init-repo .' crashes for lack of module bz2. Help, please!

[Alan Mackenzie]

Hi, Tassilo,

On Sun, Jan 03, 2010 at 07:16:33PM +0100, Tassilo Horn wrote:
> Alan Mackenzie <acm@muc.de> writes:

> I'm just curious, but why didn't you just reinstall your system instead
> of working around your broken package manager, thereby deferring that
> task only a bit into the future?  I'd go nuts with such a severely
> broken system. :-)

I didn't think of reinstallation, but wouldn't have done it anyway.  It's
just too unpredictable in how much work it would need to restore it to
proper working.  My PC works, and it's only a minor inconvenience to
build from source code.  Most tarballs' error messages are easier to
understand than Python's.

It is an old Debian system ("sarge") and I find its full screen packaging
utility "aptitude" too baroque for my taste - it's almost as complicated
to use as "mutt" (email client), and that amount of complication is
excessive for a utility I might use two or three times a year.  I want a
straightforward command line packaging system, so I'm going with gentoo
on my next system.

> Bye,
> Tassilo

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: 'bzr init-repo .' crashes for lack of module bz2. Help, please!

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
> It is an old Debian system ("sarge") and I find its full screen packaging
> utility "aptitude" too baroque for my taste - it's almost as complicated
> to use as "mutt" (email client), and that amount of complication is
> excessive for a utility I might use two or three times a year.  I want a
> straightforward command line packaging system

Note that aptitude also works as a command line tool, if you give it a
command when invoking instead of just saying "aptitude".
(e.g. "sudo aptitude install XXX" etc)

> so I'm going with gentoo on my next system.

If you want to avoid baroqueness, gentoo may not be the best choice...

-Miles

-- 
Acquaintance, n. A person whom we know well enough to borrow from, but not
well enough to lend to.

Re: 'bzr init-repo .' crashes for lack of module bz2. Help, please!

[Jason Rumney]

On 04/01/2010 08:06, Miles Bader wrote:
> Alan Mackenzie<acm@muc.de>  writes:
>    
>> It is an old Debian system ("sarge") and I find its full screen packaging
>> utility "aptitude" too baroque for my taste - it's almost as complicated
>> to use as "mutt" (email client), and that amount of complication is
>> excessive for a utility I might use two or three times a year.  I want a
>> straightforward command line packaging system
>>      
> Note that aptitude also works as a command line tool, if you give it a
> command when invoking instead of just saying "aptitude".
> (e.g. "sudo aptitude install XXX" etc)
>    

Additionally, Debian includes apt-get, which is a command line tool that 
performs the same tasks as aptitude.

Re: 'bzr init-repo .' crashes for lack of module bz2. Help, please!

[Alan Mackenzie]

Hi, Jason,

On Mon, Jan 04, 2010 at 08:13:54AM +0800, Jason Rumney wrote:
> On 04/01/2010 08:06, Miles Bader wrote:
> >Alan Mackenzie<acm@muc.de>  writes:

> >>It is an old Debian system ("sarge") and I find its full screen
> >>packaging utility "aptitude" too baroque for my taste - it's almost
> >>as complicated to use as "mutt" (email client), and that amount of
> >>complication is excessive for a utility I might use two or three
> >>times a year.  I want a straightforward command line packaging system

> >Note that aptitude also works as a command line tool, if you give it a
> >command when invoking instead of just saying "aptitude".  (e.g. "sudo
> >aptitude install XXX" etc)

> Additionally, Debian includes apt-get, which is a command line tool
> that performs the same tasks as aptitude.

It is all these alternatives, with the rather mushy relationships between
them, the mass of background stuff you've got to know, and the hidden
trapdoors, which put me off Debian.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: 'bzr init-repo .' crashes for lack of module bz2. Help, please!

[Tassilo Horn]

Alan Mackenzie <acm@muc.de> writes:

Hi Alan,

> I want a straightforward command line packaging system, so I'm going
> with gentoo on my next system.

That's what I use since about 5 years, too, and basically I'm very
satisfied with it.  But a few month ago, I skrewed the gentoo package
manager (don't ever delete /var/db/), but restoring was pretty easy.
Backing up /etc and my $HOME, 12 hours of compilation time, and the
system was as it was before again...  The initial setup overhead is
pretty big, though.

One nice thing with gentoo is that they have a very helpful and
responsive emacs crew.

Another source distro you might want to have a look at is SourceMage
GNU/Linux, which seems to be even a bit nearer to LFS.

Bye,
Tassilo

Re: 'bzr init-repo .' crashes for lack of module bz2. Help, please!

[Richard Stallman]

If you use Gentoo, you have to work really hard to avoid installing
non-free software.  Someone recently told me that some
innocent-sounding package pulled in some non-free fonts, and he found
out about this because the font package wanted him to agree to an EULA.

Gentoo GNU/Linux and non-free packages (was: 'bzr init-repo .' crashes for lack of module bz2. Help, please!)

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

> If you use Gentoo, you have to work really hard to avoid installing
> non-free software.

Indeed, Gentoo also ships non-free packages and has no simple switch to
tell the package manager to never install non-free packages.  But at
least when installing a package, you can easily get a list of it and its
dependencies including the licenses.

And if there are free alternatives, some packages recommend you to use
those instead.  For example, when trying to install Adobe Flash, you are
told, that it is non-free and a source for various security risks, and
that you might want to try GNU gnash instead.

And another thing: It's quite easy to get a list of all installed
packages sorted by their licenses with

  eix -I --format-compact \
    '<licenses>: <category>/<name><installedversions:INSTFORMAT>\n' \
    -c | sort | less

> Someone recently told me that some innocent-sounding package pulled in
> some non-free fonts, and he found out about this because the font
> package wanted him to agree to an EULA.

Hm, using the command above, it seems that those fonts must be
Microsoft's corefonts package, which is free to use and distribute, but
you may not modify them.  (For fonts, that's nearly acceptable, except
if that EULA wouldn't forbid to derive a new font with a new name from
those fonts.)

Anyway, using

  equery depends media-fonts/corefonts

I gathered the information that this package was installed as an
optional dependency of ImageMagick.  So I removed the USE flag
(something like a configure option) for that package, which triggered
that dependency, and now it's gone.

Summing up: it's not very hard to keep a Gentoo system clean from
non-free stuff, but in general I'd welcome it if all non-free stuff
would be moved to some separate non-free repository, which users would
have to subscribe to manually.

Bye,
Tassilo

Re: Gentoo GNU/Linux and non-free packages

[Ulrich Mueller]

[Apologies for being off-topic in emacs-devel, but I think that I must
answer this.]

>>>>> On Mon, 04 Jan 2010, Richard Stallman writes:

> If you use Gentoo, you have to work really hard to avoid installing
> non-free software.

Do you know this from first experience, or is it only hearsay?

> Someone recently told me that some innocent-sounding package pulled
> in some non-free fonts, and he found out about this because the font
> package wanted him to agree to an EULA.

This is clearly not intended behaviour, and the person should have
reported a bug to the Gentoo bugtracker.

Generally, we have a Social Contract (similar to Debian's) that says
that Gentoo will never depend upon a piece of software unless it
conforms to a free licence. [1]

Also, the newest version of our package manager, portage-2.2,
introduced an "ACCEPT_LICENSE" feature that allow users to filter
packages by their licence. For example, with the following setting:

   ACCEPT_LICENSE="@FSF-APPROVED @OSI-APPROVED"

the package manager would only see packages whose licences have been
approved by the FSF or the OSI (the sets of licences being defined
in [2]).

Ulrich

[1] <http://www.gentoo.org/main/en/contract.xml>
[2] <http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/license_groups?view=markup>

Re: Gentoo GNU/Linux and non-free packages

[Richard Stallman]

    > If you use Gentoo, you have to work really hard to avoid installing
    > non-free software.

    Do you know this from first experience, or is it only hearsay?

Neither: I got a personal report from someone.  Since I won't install
non-100%-free distros, this is as close to it as I could get.

    > Someone recently told me that some innocent-sounding package pulled
    > in some non-free fonts, and he found out about this because the font
    > package wanted him to agree to an EULA.

    This is clearly not intended behaviour, and the person should have
    reported a bug to the Gentoo bugtracker.

I will suggest to him that he report it.

I hope that Gentoo will also decide not to include ports for nonfree
packages.  Whether people use such programs is their responsibility,
but whether we point them at such programs is our responsibility.

Re: Gentoo GNU/Linux and non-free packages (was: 'bzr init-repo .' crashes for lack of module bz2. Help, please!)

[Richard Stallman]

    Indeed, Gentoo also ships non-free packages and has no simple switch to
    tell the package manager to never install non-free packages.  But at
    least when installing a package, you can easily get a list of it and its
    dependencies including the licenses.

This enables you to achieve, with a lot of effort,
what free distros do automatically.

Re: Gentoo GNU/Linux and non-free packages (was: 'bzr init-repo .' crashes for lack of module bz2. Help, please!)

[Jonas Bernoulli]

On Tue, Jan 5, 2010 at 21:45, Richard Stallman <rms@gnu.org> wrote:
>    Indeed, Gentoo also ships non-free packages and has no simple switch to
>    tell the package manager to never install non-free packages.  But at
>    least when installing a package, you can easily get a list of it and its
>    dependencies including the licenses.
>
> This enables you to achieve, with a lot of effort,
> what free distros do automatically.

From a manpage about configuring the development version of portage (the
default package manager of Gentoo):

	ACCEPT_LICENSE = [space delimited list of licenses or groups]
		This  variable  is used  to  mask  packages  based on  licensing
		restrictions.  It make  contain  both license  and group  names,
		where  group names  are prefixed  with the  '@'  symbol. License
		groups   are   defined   in   the   license_groups   file   (see
		portage(5)). In addition  to license and group names,  the * and
		-* wildcard  tokens are  also supported.  Refer to  GLEP  23 for
		further                                              information:
		http://www.gentoo.org/proj/en/glep/glep-0023.html.
		Defaults to the value of * -@EULA.
		Examples:
		# Accept any license
		ACCEPT_LICENSE="*"
		# Accept any license except the "public-domain" license
		ACCEPT_LICENSE="* -public-domain"
		# Only accept licenses in the FSF-APPROVED license group
		ACCEPT_LICENSE="-* @FSF-APPROVED"

The rational can be found in the mentioned "glep":

    http://www.gentoo.org/proj/en/glep/glep-0023.html

So provided that you use the development (which works just fine for a lot of
people) it is not very hard to move away from non-free software. Thought the
default is something else. Just add this to /etc/make.conf:

    ACCEPT_LICENSE="-* @FSF-APPROVED"

After that portage will inform you of installed packages that are "masked", in
this case because of license issues.  Then it is mostly a mater of removing
these packages which isn't hard to do, and you don't have to do it all at once.

At one point this will become standard.  So while Gentoo isn't there yet it's
moving.

-- Jonas

Re: Gentoo GNU/Linux and non-free packages (was: 'bzr init-repo .' crashes for lack of module bz2. Help, please!)

[Richard Stallman]

Under the plans you described, it will be easier to omit the non-free
packages from Gentoo.  But Gentoo will still lead users towards
non-free packages, which is a bad thing to do.

See gnu.org/distros for more explanation about this.

Re: Gentoo GNU/Linux and non-free packages

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

> Under the plans you described, it will be easier to omit the non-free
> packages from Gentoo.  But Gentoo will still lead users towards
> non-free packages, which is a bad thing to do.

Well, when searching with the package manager, it still lists non-free
packages, but they are masked due to their license, and you cannot
install them, and for sure, the package manager won't install them as a
dependency of some other package.

The package manager also tells you where the license is located on your
disk, so you can read it, decide on your own, and add exceptions for
individual packages.  For example, I allow "GPL-2 with classpath
exception" for the OpenJDK IcedTea java distribution, and the TeX and
LPPL licenses for the TeXLive distribution, although at least the latter
two are not GPL compatible (but still free).

I also accept the non-free skype license for skype, because I'm forced
to use it at work...

> See gnu.org/distros for more explanation about this.

,----
| Gentoo
| ======
|
| Gentoo makes it easy to install a number of nonfree programs through
| their primary package system.
`----

Well, that hardly qualifies as an still standing argument.  As soon as
the new package manager version is stable, it's only a matter of what
defaults the Gentoo devs choose as acceptable licenses.  I guess, they
will choose only FSF and OSI approved licenses.  Then, you will have a
free system guaranteed.

Of course, still a user can add an exception for an individual package
he simply is forced to use, because there are no free alternatives, like
some driver for a hardware device [1].  With gNewSense, he would install
that manually and circumvent the package manager.  With Gentoo, he adds
an exception and then the package manager does the install.  That has
the big advantage, that he can be absolutely sure that he can remove
that piece of software without leaving anything over that might be
harmful to his system, as soon as a free alternative becomes available.

Bye,
Tassilo
__________
[1] Yes, sure, you should avoid any hardware that doesn't run with only
    free drivers, but that can be impossible, because i.e. your company
    buys your computer and you have to influence on that.  In that case,
    a nearly free system is the best you can get, and much better than
    using a completely proprietary OS.

Re: Gentoo GNU/Linux and non-free packages

[Richard Stallman]

From what you've said, even with the license filter activated, Gentoo
GNU/Linux will still tantalize users with non-free programs they might
install.  That doesn't seem satisfactory.  Furthermore, use of the
license filter will be optional.  If a person goes look at the Gentoo
site with a view to installing it, unless he is already convinced that
proprietary software is bad, he won't use the license filter.  And
then Gentoo might lead him to install lots of non-free programs.

This is not what I developed GNU for.

    | Gentoo makes it easy to install a number of nonfree programs through
    | their primary package system.
    `----

    Well, that hardly qualifies as an still standing argument.  As soon as
    the new package manager version is stable, it's only a matter of what
    defaults the Gentoo devs choose as acceptable licenses.  I guess, they
    will choose only FSF and OSI approved licenses.

Are you saying that the Gentoo developers might soon delete all the
ports for non-free programs from Gentoo?  That could make it a 100%
free distro, and we might be able to endorse it.  (We would have to
check for blobs in their version of Linux.)

But that sounds too good to be true, so I suspect there is a
misunderstanding of some sort.  Perhaps you mean that the Gentoo
developers will decide not to install the nonfree programs on their
own machines.  That would be the right thing to do, for their own
freedom's sake.  But it would not alter the problem with Gentoo, which
is that it steers users towards nonfree programs.

Nonfree software is an injustice.  The aim of our work is to eliminate
that injustice.  We must never treat nonfree software as a solution,
because that would imply it isn't the problem.

Re: Gentoo GNU/Linux and non-free packages

[Marek Aaron Sapota]

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

On Thu, Jan 07, 2010 at 05:49:13PM -0500, Richard Stallman wrote:
>     Well, that hardly qualifies as an still standing argument.  As soon as
>     the new package manager version is stable, it's only a matter of what
>     defaults the Gentoo devs choose as acceptable licenses.  I guess, they
>     will choose only FSF and OSI approved licenses.
> 
> Are you saying that the Gentoo developers might soon delete all the
> ports for non-free programs from Gentoo?  That could make it a 100%
> free distro, and we might be able to endorse it.  (We would have to
> check for blobs in their version of Linux.)

Gentoo devs have already chosen - by default it is everything that
doesn't require explicit agreement from user and this aren't only FSF
and OSI approved licenses. As reference:

http://bugs.gentoo.org/show_bug.cgi?id=152593

It is possible to use only Free Software with Gentoo but it isn't that
easy:
- packages have non-free dependences, sometimes programs compile fine
  without them, but they are pulled in anyway
- some free "alternatives" are only in additional repositories
- predefined license groups (for example FSF approved) are not complete
- some packages have wrong licenses (usually license is named after the
  package even if it really is for example GPL)

Gentoo isn't even close to being a Free Distribution in FSF sense, I
have no idea why some people treat it as such.

Happy hacking
Marek Aaron Sapota

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Gentoo GNU/Linux and non-free packages

[Tassilo Horn]

Marek Aaron Sapota <maarons@gnu.org> writes:

Hi Marek,

> It is possible to use only Free Software with Gentoo but it isn't that
> easy:
> - packages have non-free dependences, sometimes programs compile fine
>   without them, but they are pulled in anyway

What do you mean with "pulled in".  I tried to install a package that
has a non-free dependency, and portage 2.2 told me it cannot install it,
because this dependency is masked by my license restriction.

> - some free "alternatives" are only in additional repositories

Usually, this occurs if a package simply doesn't work for most users, or
no maintainer has been found yet.

> - predefined license groups (for example FSF approved) are not
>   complete

Indeed, currently GPL-1 and LGPL-2 are missing.  But that will surely be
fixed as soon as the overall mechanics are stable.

> - some packages have wrong licenses (usually license is named after the
>   package even if it really is for example GPL)

This applies to many modular X11 packages, but work is in progress to
fix that.  And of course, this will never make a non-free package
installable if you've set your ACCEPT_LICENSE to match only free
licenses.  It will prevent installing those programs although they might
be free.  The other way round would be a showstopper, but this way it's
only a little inconvenience.

> Gentoo isn't even close to being a Free Distribution in FSF sense, I
> have no idea why some people treat it as such.

Hm, I don't know how extensively you have tested, but using

  ACCEPT_LICENSE="-* @FSF-APPROVED @OSI-APPROVED"

I'm simply not able to let the package manager install something that's
not free.  If there is a possibility, this would clearly qualify as a
bug.  If there are some, please give me a recipe, so that I can report
it.

Bye,
Tassilo

Re: Gentoo GNU/Linux and non-free packages

[Marek Aaron Sapota]

[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]

On Fri, Jan 08, 2010 at 10:30:15AM +0100, Tassilo Horn wrote:
> Marek Aaron Sapota <maarons@gnu.org> writes:
>
> Hi Marek,
>
> > It is possible to use only Free Software with Gentoo but it isn't
> > that
> > easy:
> > - packages have non-free dependences, sometimes programs compile
> > fine
> >   without them, but they are pulled in anyway
>
> What do you mean with "pulled in".  I tried to install a package that
> has a non-free dependency, and portage 2.2 told me it cannot install
> it,
> because this dependency is masked by my license restriction.

I mean that I can not install a package only because it has a non-free
dependency even if it works fine without it - for example X.Org and Wine
pull in non-free fonts. Inconvenience that makes your system less
powerful if you want to only use Free Software.

>
> > - some free "alternatives" are only in additional repositories
>
> Usually, this occurs if a package simply doesn't work for most users,
> or
> no maintainer has been found yet.

Icedtea is in an overlay even if it works perfectly.

>
> > - predefined license groups (for example FSF approved) are not
> >   complete
>
> Indeed, currently GPL-1 and LGPL-2 are missing.  But that will surely
> be
> fixed as soon as the overall mechanics are stable.
>
> > - some packages have wrong licenses (usually license is named after
> > the
>
> This applies to many modular X11 packages, but work is in progress to
> fix that.  And of course, this will never make a non-free package
> installable if you've set your ACCEPT_LICENSE to match only free
> licenses.  It will prevent installing those programs although they
> might
> be free.  The other way round would be a showstopper, but this way
> it's
> only a little inconvenience.

Indeed - it makes it inconvenient to use only Free Software with Gentoo.

To be a Free Distribution Gentoo would have to show commitment to Free
Software and they clearly don't. They treat the system as complete
including non-free software and that is why using it without non-free
components is inconvenient. Before the system works equally good without
non-free packages I don't see any option of Gentoo being listed. This is
a difference of "user can be free" and "distribution cares that users
are free".

Happy hacking
Marek Aaron Sapota

PS. To clear up I use Gentoo and I use ACCEPT_LICENSE almost since it
got implemented.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Gentoo GNU/Linux and non-free packages

[Tassilo Horn]

Marek Aaron Sapota <maarons@gnu.org> writes:

Hi Marek,

>> > - packages have non-free dependences, sometimes programs compile
>> > fine without them, but they are pulled in anyway
>> 
>> What do you mean with "pulled in".  I tried to install a package that
>> has a non-free dependency, and portage 2.2 told me it cannot install
>> it, because this dependency is masked by my license restriction.
>
> I mean that I can not install a package only because it has a non-free
> dependency even if it works fine without it - for example X.Org and
> Wine pull in non-free fonts.

I've just checked xorg-x11, and it has only hard dependencies to fonts
licensed under the MIT license or public domain.  I guess, I've set some
use flag, which enables this additional dependency.

Use "equery depends <non-free font>" to check, what packages tries to
pull it in, and what use flag is responsible.

>> > - some free "alternatives" are only in additional repositories
>> 
>> Usually, this occurs if a package simply doesn't work for most users,
>> or no maintainer has been found yet.
>
> Icedtea is in an overlay even if it works perfectly.

I use icedtea6-bin from the main gentoo portage tree.  Additionally,
portage prefers it over sun-jdk.  It's possible, that there's a source
distribution of icedtea in some repository, but the binary is there in
the main tree.

>> This applies to many modular X11 packages, but work is in progress to
>> fix that.  And of course, this will never make a non-free package
>> installable if you've set your ACCEPT_LICENSE to match only free
>> licenses.  It will prevent installing those programs although they
>> might be free.  The other way round would be a showstopper, but this
>> way it's only a little inconvenience.
>
> Indeed - it makes it inconvenient to use only Free Software with
> Gentoo.

I agree, but that will get better.

> To be a Free Distribution Gentoo would have to show commitment to Free
> Software and they clearly don't.

The social contract does:

,----[ http://www.gentoo.org/main/en/contract.xml ]
| We will release our contributions to Gentoo as free software, metadata
| or documentation, under the GNU General Public License version 2 (or
| later, at our discretion) or the Creative Commons - Attribution /
| Share Alike version 2 (or later, at our discretion).  Any external
| contributions to Gentoo (in the form of freely-distributable sources,
| binaries, metadata or documentation) may be incorporated into Gentoo
| provided that we are legally entitled to do so.  However, Gentoo will
| never /depend/ upon a piece of software or metadata unless it conforms
| to the GNU General Public License, the GNU Lesser General Public
| License, the Creative Commons - Attribution/Share Alike or some other
| license approved by the Open Source Initiative (OSI).
| 
| Note: We are considering extending the above clause to require that
| all core Gentoo components must conform to a license approved by the
| OSI *and* Free Software Foundation (FSF).
`----

Bye,
Tassilo

[Sorry for the resent, Marek!]

Re: Gentoo GNU/Linux and non-free packages

[Marek Aaron Sapota]

[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]

On Fri, Jan 08, 2010 at 12:56:13PM +0100, Tassilo Horn wrote:
> I've just checked xorg-x11, and it has only hard dependencies to fonts
> licensed under the MIT license or public domain.  I guess, I've set some
> use flag, which enables this additional dependency.

I've just checked what I have removed from the ebuild: Bigelow & Holmes
fonts - they are now labelled as MIT licensed. Unless the license was
changed recently it is incorrect, this fonts didn't permit changing them
if I remember right. 

Reference from webmasters at gnu.org:
By Karl Berry:
One thing I noticed scrolling through the package list at
http://www.dragora.org/os/current/ReleaseNotes.txt was the
lucidatypewriter fonts. Unless Bigelow & Holmes made an unusual
exception I am not aware of (please confirm/deny?), I don't think it's
free. They have never allowed modification of any of their fonts,
bitmap or outline -> hence nonfree. Do you know if it's in gnewsense?

and also by Karl Berry:
As for the Lucida Sans Typewriter fonts, Chuck said that he has to check
his records to be completely sure, which may take a few days. But he is
pretty sure that modification is not allowed, or at most is limited to
translation to other bitmap fonts. Given that, and that the fonts
aren't in gNewSense, I think it's pretty safe to say they should be
removed.

> > Indeed - it makes it inconvenient to use only Free Software with
> > Gentoo.
> 
> I agree, but that will get better.

I hope it will but now it isn't good enough.

> 
> > To be a Free Distribution Gentoo would have to show commitment to Free
> > Software and they clearly don't.
> 
> The social contract does:

In practice try installing Netbeans and see how it fails on proprietary
dependences.

Happy hacking
Marek Aaron Sapota

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Gentoo GNU/Linux and non-free packages

[Tassilo Horn]

Marek Aaron Sapota <maarons@gnu.org> writes:

> On Fri, Jan 08, 2010 at 12:56:13PM +0100, Tassilo Horn wrote:
>> I've just checked xorg-x11, and it has only hard dependencies to fonts
>> licensed under the MIT license or public domain.  I guess, I've set some
>> use flag, which enables this additional dependency.
>
> I've just checked what I have removed from the ebuild: Bigelow & Holmes
> fonts - they are now labelled as MIT licensed. Unless the license was
> changed recently it is incorrect, this fonts didn't permit changing them
> if I remember right. 

Is that the correct license?

  http://www.xfree86.org/current/LICENSE11.html

Looks quite MIT-style to me.  Do what you want, but keep this copyright
notice.

>> > To be a Free Distribution Gentoo would have to show commitment to
>> > Free Software and they clearly don't.
>> 
>> The social contract does:
>
> In practice try installing Netbeans and see how it fails on
> proprietary dependences.

I only had a brief look, but it seems it fails because of the license
groups aren't complete yet.  I checked some required but license masked
packages, and they were all free, although not GPL compatible,
e.g. CDDL, Apache...

Oh, well, there are some of those jsr packages (Java Specification
Request).  As far as I understand from

  http://en.wikipedia.org/wiki/Java_Community_Process

those are reference implementations to new java features, which might
eventually be included in the java language spec.

What would be interesting, is to know if the usual netbeans installer
comes with and installs those proprietary addons.  If yes, then we
should thank Gentoo for making us aware of those.

Bye,
Tassilo

Re: Gentoo GNU/Linux and non-free packages

[Marek Aaron Sapota]

[-- Attachment #1: Type: text/plain, Size: 2735 bytes --]

On Fri, Jan 08, 2010 at 03:44:50PM +0100, Tassilo Horn wrote:
> Marek Aaron Sapota <maarons@gnu.org> writes:
> 
> > On Fri, Jan 08, 2010 at 12:56:13PM +0100, Tassilo Horn wrote:
> >> I've just checked xorg-x11, and it has only hard dependencies to fonts
> >> licensed under the MIT license or public domain.  I guess, I've set some
> >> use flag, which enables this additional dependency.
> >
> > I've just checked what I have removed from the ebuild: Bigelow & Holmes
> > fonts - they are now labelled as MIT licensed. Unless the license was
> > changed recently it is incorrect, this fonts didn't permit changing them
> > if I remember right. 
> 
> Is that the correct license?
> 
>   http://www.xfree86.org/current/LICENSE11.html
> 
> Looks quite MIT-style to me.  Do what you want, but keep this copyright
> notice.

Looks like the license that was there before.
From this license:
The Font Software may not be modified, altered, or added to, and in
particular the designs of glyphs or characters in the Fonts may not be
modified nor may additional glyphs or characters be added to the Fonts.
This License becomes null and void when the Fonts or Font Software have
been modified.

So non-free.

> 
> >> > To be a Free Distribution Gentoo would have to show commitment to
> >> > Free Software and they clearly don't.
> >> 
> >> The social contract does:
> >
> > In practice try installing Netbeans and see how it fails on
> > proprietary dependences.
> 
> I only had a brief look, but it seems it fails because of the license
> groups aren't complete yet.  I checked some required but license masked
> packages, and they were all free, although not GPL compatible,
> e.g. CDDL, Apache...

Even when you add this free licenses to your ACCEPT_LICENSE it fails.

> 
> Oh, well, there are some of those jsr packages (Java Specification
> Request).  As far as I understand from
> 
>   http://en.wikipedia.org/wiki/Java_Community_Process
> 
> those are reference implementations to new java features, which might
> eventually be included in the java language spec.

Still they are non-free, I don't know how gNewSense packages Netbeans
but it does so avoiding non-free software can be done. Gentoo ebuild it
pulls sun-jdk instead of using icedtea.

> 
> What would be interesting, is to know if the usual netbeans installer
> comes with and installs those proprietary addons.  If yes, then we
> should thank Gentoo for making us aware of those.
> 
> Bye,
> Tassilo
> 
> 

Some of default Netbeans modules are non-free, they are installed with
usual installer and with ebuild version (though this can be changed
using use flags).

Happy hacking
Marek Aaron Sapota

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Gentoo GNU/Linux and non-free packages

[Yavor Doganov]

Tassilo Horn wrote:
> Hm, I don't know how extensively you have tested, but using
> 
>   ACCEPT_LICENSE="-* @FSF-APPROVED @OSI-APPROVED"

This is far from sufficient for an entirely free GNU distro (which all
distros should be, in an ideal world), because there are packages are
basically under a free license, but include component or two that are
clearly non-free, or have dependencies that are non-free.

Unless Gentoo strips the tarballs to exclude such components, tweaks
the .ebuilds and dependencies accordingly, etc., this new feature of
the package manager is not a solution.

Then comes the problem with incompatible licenses, which Gentoo
doesn't seem to pursue at all -- it'll happily compile whatever
combination of USE flags if it's technically possible.  (I might be
wrong here.)  While less severe than distributing and even silently
installing non-free software behind users' back, this is an issue that
should not be ignored.


BTW, this sub-thread seems to be off-topic on emacs-devel.

Re: Gentoo GNU/Linux and non-free packages

[Marek Aaron Sapota]

[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]

On Fri, Jan 08, 2010 at 05:23:03PM +0200, Yavor Doganov wrote:
> Tassilo Horn wrote:
> > Hm, I don't know how extensively you have tested, but using
> > 
> >   ACCEPT_LICENSE="-* @FSF-APPROVED @OSI-APPROVED"
> 
> This is far from sufficient for an entirely free GNU distro (which all
> distros should be, in an ideal world), because there are packages are
> basically under a free license, but include component or two that are
> clearly non-free, or have dependencies that are non-free.

That will be tracked down by portage, it won't install a GPL-ed package
if it has proprietary dependences.

> 
> Unless Gentoo strips the tarballs to exclude such components, tweaks
> the .ebuilds and dependencies accordingly, etc., this new feature of
> the package manager is not a solution.
> 
> Then comes the problem with incompatible licenses, which Gentoo
> doesn't seem to pursue at all -- it'll happily compile whatever
> combination of USE flags if it's technically possible.  (I might be
> wrong here.)  While less severe than distributing and even silently
> installing non-free software behind users' back, this is an issue that
> should not be ignored.
> 

The use flag combinations can be limited, though I think this would be
upstream package problem - use flags are only more or less --enable-foo
--disable-bar passed to configure script.

> 
> BTW, this sub-thread seems to be off-topic on emacs-devel.
> 
> 

I agree, also this discussion is pointless until Gentoo improves some
things so let's end it.

Happy hacking
Marek Aaron Sapota

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Gentoo GNU/Linux and non-free packages

[Tassilo Horn]

Marek Aaron Sapota <maarons@gnu.org> writes:

>> BTW, this sub-thread seems to be off-topic on emacs-devel.
>
> I agree, also this discussion is pointless until Gentoo improves some
> things so let's end it.

Good, I'm leaving for a week of snowboarding in France, right now. :-)

Bye,
Tassilo

Re: Gentoo GNU/Linux and non-free packages

[David Kastrup]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Marek Aaron Sapota <maarons@gnu.org> writes:
>
>>> BTW, this sub-thread seems to be off-topic on emacs-devel.
>>
>> I agree, also this discussion is pointless until Gentoo improves some
>> things so let's end it.
>
> Good, I'm leaving for a week of snowboarding in France, right now. :-)

While the U.S. is still merely waterboarding...

-- 
David Kastrup

Re: Gentoo GNU/Linux and non-free packages

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

>     | Gentoo makes it easy to install a number of nonfree programs
>     | through their primary package system.
>     `----
>
>     Well, that hardly qualifies as an still standing argument.  As
>     soon as the new package manager version is stable, it's only a
>     matter of what defaults the Gentoo devs choose as acceptable
>     licenses.  I guess, they will choose only FSF and OSI approved
>     licenses.
>
> Are you saying that the Gentoo developers might soon delete all the
> ports for non-free programs from Gentoo?

No, what I've meant is that the Gentoo developers might choose a default
setting of the license filter, which only accepts packages that are
completely free, e.g. packages with licenses approved by the FSF or OSI.

> That could make it a 100% free distro, [...]

I think, that such a default setting of the license filter would qualify
as 100% free.  The difference with gNewSense then is only that with
Gentoo, you can add an exception if you rely on some non-free driver and
let the package manager install it.  With gNewSense, you would install
that manually with the risk, that you might not be able to erase it
completely later on.

> [...] and we might be able to endorse it.

Well, I think you could endorse it with a short explanation in any case,
as soon as the version of the package manager supporting this feature
becomes stable.  If a Gentoo user then puts

  ACCEPT_LICENSE="-* @FSF-APPROVED @OSI-APPROVED"

into his /etc/make.conf, he can be sure that the package manager only
installs packages that are 100% free.

Bye,
Tassilo

Re: Gentoo GNU/Linux and non-free packages

[Richard Stallman]

    I think, that such a default setting of the license filter would qualify
    as 100% free.

It is possible that installing Gentoo with this filter setting would
not directly install nonfree software -- assuming the developers have
not overlooked any.  For instance, does their version of Linux include
firmware "blobs"?

However, merely having an option which avoids nonfree software does
not make a distribution something ok to recommend.  Most computer
users have not learned to value their freedom; if we steer them
towards Gentoo we would probably lead them to install nonfree
software.

See gnu.org/distros for an explanation of this and the rest of our
criteria for endorsing distributions.

Re: Gentoo GNU/Linux and non-free packages

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

>     Indeed, Gentoo also ships non-free packages and has no simple
>     switch to tell the package manager to never install non-free
>     packages.  But at least when installing a package, you can easily
>     get a list of it and its dependencies including the licenses.
>
> This enables you to achieve, with a lot of effort,
> what free distros do automatically.

Please have a look at Jonas' and Ulrich's messages [1].  I wasn't aware
of the new Gentoo mechanism of accepting only free licenses.  With that,
you can have a completely free system with no effort.

Bye,
Tassilo
__________
[1] Message-ID: <201bac3a1001051610t25a1a767v79398943193c3e89@mail.gmail.com>
    Message-ID: <19267.87.538073.863392@a1i15.kph.uni-mainz.de>