Re: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system

[Javier Fernández-Sanguino Peña]

On Fri, Feb 17, 2006 at 11:55:22PM +0100, Guerkan Senguen wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: freebsd-manpages
>   Version : 6.0
>   Upstream Author : The FreeBSD Project
> * URL : 
> ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.0-RELEASE/manpages/
> * License : see bottom
>   Description : Manual pages for a GNU/kFreeBSD system
>  This package contains a selection of manual pages from FreeBSD that are
>  useful in a GNU/kFreeBSD system:
>   2 = System calls (functions provided by the kernel)
>   4 = Special files (usually found in /dev)
>   9 = Kernel routines
>  .
>  The man pages describe syntaxes of several system files.

Wouldn't this package conflict with the 'manpages' package (which provides
them for GNU/Linux) and with the manpages provided by other (core) packages?
Or are all manpages going to be renamed so that there is no filename conflict
under /usr/share/man/man{2,4}?

Regards

Javier


signature.asc
Description: Digital signature

Re: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system

[Kevin Mark]

On Sat, Feb 18, 2006 at 09:02:57AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> On Fri, Feb 17, 2006 at 11:55:22PM +0100, Guerkan Senguen wrote:
> > Package: wnpp
> > Severity: wishlist
> > 
> > * Package name: freebsd-manpages
> >   Version : 6.0
> Wouldn't this package conflict with the 'manpages' package (which provides
> them for GNU/Linux) and with the manpages provided by other (core) packages?
> Or are all manpages going to be renamed so that there is no filename conflict
> under /usr/share/man/man{2,4}?
> 
> Regards
> 
> Javier

Hi,
if 'manpages' are GFDL and freebsd-manpages is under a bsd license, then
if freebsd-manpages CAN replace manpages and GFDL docs are removed, then there
will be no conflict.
cheers,
Kev
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal | debian.home.pipeline.com |
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
| my keysever: pgp.mit.edu   | my NPO: cfsg.org |


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Robert Millan]

On Fri, Feb 17, 2006 at 08:14:38PM -0500, Michael Poole wrote:
> 
> Then please work to revise [Removed false premise fallacy]

Last time your argument was that free NDIS drivers exist, so the situation is
analogous to wine.  Nobody bothered to check, but it turns out that only one
free driver exists, and it's pretty pointless since it's a port of something we
already have.

Ok, quoting:

Social Contract:

  "We will never make the system require the use of a non-free component."

Policy:

"2.2.2 The contrib section

[...]
Examples of packages which would be included in contrib are:

*  [...]
*  wrapper packages or other sorts of free accessories for non-free 
programs.
"

> Without something to work on, an assembler is just as useless as
> ndiswrapper.  Which package(s) in main depend on nasm?

You can check that yourself.  I guess a few dozens.

> Why not file a
> bug report against it, demanding that it be moved to contrib?

Because it's free software that processes asm input, and there is a significant
amount of useful, free i386 asm that makes nasm necessary ?

I'll ask again:  Is the purpose of ndiswrapper running non-free drivers?  If it
isn't, show me a free, non-toy, non-POC driver that would prove otherwise.

(That is a rhetorical question.  Lack of any answer will probably help you
understand why contrib exists.)

-- 
Robert Millan


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

Re: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system

[David Weinehall]

On Sat, Feb 18, 2006 at 03:30:38AM -0500, Kevin Mark wrote:
> On Sat, Feb 18, 2006 at 09:02:57AM +0100, Javier Fern?ndez-Sanguino Pe?a 
> wrote:
> > On Fri, Feb 17, 2006 at 11:55:22PM +0100, Guerkan Senguen wrote:
> > > Package: wnpp
> > > Severity: wishlist
> > > 
> > > * Package name: freebsd-manpages
> > >   Version : 6.0
> > Wouldn't this package conflict with the 'manpages' package (which
> > provides them for GNU/Linux) and with the manpages provided by other
> > (core) packages?  Or are all manpages going to be renamed so that
> > there is no filename conflict under /usr/share/man/man{2,4}?
> > 
> > Regards
> > 
> > Javier
> 
> Hi,
> if 'manpages' are GFDL and freebsd-manpages is under a bsd license,
> then if freebsd-manpages CAN replace manpages and GFDL docs are
> removed, then there will be no conflict.

a.) The manpages packages does not (AFAIK) contain any GFDL docs;
it's not provided by FSF, since they have a strange aversion
against manpages, and an even stranger predilection for info
pages...

b.) The package itself does not *need* to conflict with the manpages
package, since it provides manpages for 4, 5, and 7,
(and manpages-dev provides 2, and 3).

Replaces: manpages, manpages-dev

is needed though.

HOWEVER, since manpages-dev presumably contains documentations for
interfaces that are Linux specific, it might make sense to have a
Conflicts: manpages, manpages-dev
anyway.  This would mean that users of Debian GNU/FreeBSD would lose
the manual-pages for glibc though (since they are also in manpages-dev).
Maybe the manpages source package should be split into more binary
packages? manpages (generic stuff for all Debian systems),
manpages-linux (Linux specific things, like sysfs), manpages-linux-dev
(Linux specific programming interfaces).


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


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

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Jose Carlos Garcia Sogo]

El sáb, 18-02-2006 a las 09:40 +0100, Robert Millan escribió:
> On Fri, Feb 17, 2006 at 08:14:38PM -0500, Michael Poole wrote:
> > 
> > Then please work to revise [Removed false premise fallacy]
> 
> Last time your argument was that free NDIS drivers exist, so the situation is
> analogous to wine.  Nobody bothered to check, but it turns out that only one
> free driver exists, and it's pretty pointless since it's a port of something 
> we
> already have.
> 
> Ok, quoting:
> 
> Social Contract:
> 
>   "We will never make the system require the use of a non-free component."


  And ndiswrapper does not require it. It will only be useless without a
driver, not a non-free driver. At most you could ask for it to be
removed as "useless piece of software" (which is not and we have a lot
of that in Debian is some way or other).

  BTW, if we start being more intregrist than those burning consulates
because of some drawings, we should start by removing GPG signatures and
md5sums from main, as those are invariant bits.

  Cheers, 

-- 
Jose Carlos Garcia Sogo
   [EMAIL PROTECTED]


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Re: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system

[Kevin Mark]

On Sat, Feb 18, 2006 at 09:42:19AM +0100, David Weinehall wrote:
> On Sat, Feb 18, 2006 at 03:30:38AM -0500, Kevin Mark wrote:
> > On Sat, Feb 18, 2006 at 09:02:57AM +0100, Javier Fern?ndez-Sanguino Pe?a 
> > wrote:
> > > On Fri, Feb 17, 2006 at 11:55:22PM +0100, Guerkan Senguen wrote:
> > > > Package: wnpp
> > > > Severity: wishlist
> > > > 
> > > > * Package name: freebsd-manpages
> > > >   Version : 6.0
> > > Wouldn't this package conflict with the 'manpages' package (which
> > > provides them for GNU/Linux) and with the manpages provided by other
> > > (core) packages?  Or are all manpages going to be renamed so that
> > > there is no filename conflict under /usr/share/man/man{2,4}?
> > > 
> > > Regards
> > > 
> > > Javier
> > 
> > Hi,
> > if 'manpages' are GFDL and freebsd-manpages is under a bsd license,
> > then if freebsd-manpages CAN replace manpages and GFDL docs are
> > removed, then there will be no conflict.
> 
> a.) The manpages packages does not (AFAIK) contain any GFDL docs;
> it's not provided by FSF, since they have a strange aversion
> against manpages, and an even stranger predilection for info
> pages...
> 
> b.) The package itself does not *need* to conflict with the manpages
> package, since it provides manpages for 4, 5, and 7,
> (and manpages-dev provides 2, and 3).
> 
> Replaces: manpages, manpages-dev
> 
> is needed though.
> 
> HOWEVER, since manpages-dev presumably contains documentations for
> interfaces that are Linux specific, it might make sense to have a
> Conflicts: manpages, manpages-dev
> anyway.  This would mean that users of Debian GNU/FreeBSD would lose
> the manual-pages for glibc though (since they are also in manpages-dev).
> Maybe the manpages source package should be split into more binary
> packages? manpages (generic stuff for all Debian systems),
> manpages-linux (Linux specific things, like sysfs), manpages-linux-dev
> (Linux specific programming interfaces).
> 
Hi David,
after a brief inspection, it seem 'manpages' are under various and
sundry licenses (none are GFDL) which is good. But with the change from
kernel-image to linux-image as one recognition of Debians' intent to be
more inclusive of non-linux thingy, should there be a change in the
installation path and notation inside man pages as to their kernel
origin? (like .../man/linux/ and .../man/bsd/) This would allow
simultaneous installtion and would allow someone on either system to be
able to read man pages from other systems. I doubt there was ever a *nix
system that envisioned bsd and linux stuff being installed on the same
system x-)
Cheers,
Kev
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal | debian.home.pipeline.com |
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
| my keysever: pgp.mit.edu   | my NPO: cfsg.org |


signature.asc
Description: Digital signature

cflow: replace upstream part by GNU cflow

[Bart Martens]

Hello,

I want to replace the upstream part of cflow by GNU cflow.  Any comments
on that are welcome on this bug report : http://bugs.debian.org/353192

Regards,

Bart Martens


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

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Wouter Verhelst]

On Sat, Feb 18, 2006 at 09:40:26AM +0100, Robert Millan wrote:
> I'll ask again:  Is the purpose of ndiswrapper running non-free drivers?  If 
> it
> isn't, show me a free, non-toy, non-POC driver that would prove otherwise.

Does the lack of a free driver which can be used with ndiswrapper mean
that it is impossible to use ndiswrapper with such a free driver, should
one eventually be written?

If there is a brand shiny new file format of which the spec has been
fully disclosed and published in an RFC, though no free editors exist
(yet) for the format, does that make the format non-free?

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Robert Millan]

On Sat, Feb 18, 2006 at 12:49:48PM +0100, Wouter Verhelst wrote:
> On Sat, Feb 18, 2006 at 09:40:26AM +0100, Robert Millan wrote:
> > I'll ask again:  Is the purpose of ndiswrapper running non-free drivers?  
> > If it
> > isn't, show me a free, non-toy, non-POC driver that would prove otherwise.
> 
> Does the lack of a free driver which can be used with ndiswrapper mean
> that it is impossible to use ndiswrapper with such a free driver, should
> one eventually be written?

You can apply this argument to every single package in contrib.  

  "If a free driver/datafile/whatever existed, it would be possible to run Foo
  without requiring non-free stuff, therefore it belongs to main"

Is your point that contrib should therefore be empty and has no reason for
existance?

If not, please explain me the difference between ndiswrapper and all the other
packages that belong to contrib and already are in.

-- 
Robert Millan


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

Re: Bug#353277: ndiswrapper in main

[Jérôme Marant]

Robert Millan <[EMAIL PROTECTED]> writes:

> Is your point that contrib should therefore be empty and has no reason for
> existance?
>
> If not, please explain me the difference between ndiswrapper and all the other
> packages that belong to contrib and already are in.

Contrib is for free packages that have a real "Depends:" or
"Recommends:" dependency on a non-free package.

If there isn't any reason for ndiswrapper to depends on a non-free
package, then there is no reason to move it to contrib.

-- 
Jérôme Marant

Re: AT&T Korn Shell

[Josh Hurst]

On 7/13/05, Andrew Porter <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-07-13 at 14:44 +0100, Andrew Porter wrote:
> > AT&T have released the source to ksh93 under the CPL (Common Public
> > Licence)
> >
> > Are there any plans to create a debian package ?
>
> Bah - just found a package in unstable for it already :)
>
> /me tips hat to Oliver Kiddle

Does the Debian ksh93 package include libast and libshell?
--
Josh

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Michael Poole]

Robert Millan writes:

> Policy:
> 
> "2.2.2 The contrib section
> 
> [...]
> Examples of packages which would be included in contrib are:
> 

Here's the part that you left out:

 * free packages which require contrib, non-free packages or packages
   which are not in our archive at all for compilation or execution,
   and

> *  wrapper packages or other sorts of free accessories for non-free 
> programs.
> "
> 
> > Without something to work on, an assembler is just as useless as
> > ndiswrapper.  Which package(s) in main depend on nasm?
> 
> You can check that yourself.  I guess a few dozens.
> 
> > Why not file a
> > bug report against it, demanding that it be moved to contrib?
> 
> Because it's free software that processes asm input, and there is a 
> significant
> amount of useful, free i386 asm that makes nasm necessary ?

But nasm requires such assembly for useful execution!  This is the
same situation as ndiswrapper.  Neither are very useful unless you use
them with software that is not in main.  They both *compile* and
*execute* without extra software, which is all that policy requires.

You are the one who insists that the execution must be "free, non-toy,
non-POC", and that is why I said that if you want to change the state
of things, you should revise the DFSG or policy.

Michael Poole


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

Re: Bug#353277: ndiswrapper in main

[John Hasler]

Jose Carlos Garcia Sogo writes:
> ...we should start by removing GPG signatures and md5sums from main, as
> those are invariant bits.

GPG signatures and md5sums are not licensed under non-free terms (in fact,
they are probably not protected by copyright at all).  You are free to
change and/or redistribute them.
-- 
John Hasler


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

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Anthony Towns]

On Sat, Feb 18, 2006 at 08:46:53AM -0500, Michael Poole wrote:
> But nasm requires such assembly for useful execution!  

Dude, you're on crack. First, there's apparently free software in
main that you can compile with nasm to your heart's content, namely
crystalspace, drip, e3, effectv, extipl, flac, hermes1, libgpeg-mmx,
libopenspc, mknbi, motion, pearpc, psemu-video-x11, sbm, scummvm,
syslinux, visualboyadvance, vlc, xmms-openspc, zinf, and zsnes.

But even if that weren't the case, nasm is an assembler -- it doesn't
rely on assembler code to do anything useful, its purpose is to translate
assembler code. ndiswrapper isn't a driver compiler, it's a wrapper to
allow existing drivers to run on Linux. If there aren't any free ones,
or the free ones are useless toys, then it belongs in contrib because
its purpose is to allow you to run non-free software.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Michael Poole]

Anthony Towns writes:

> But even if that weren't the case, nasm is an assembler -- it doesn't
> rely on assembler code to do anything useful, its purpose is to translate
> assembler code. ndiswrapper isn't a driver compiler, it's a wrapper to
> allow existing drivers to run on Linux.

This apparently means that you object to translation at the binary
level but not translation at the source level.  I guess that's
reasonable in a general sense, it's just not a distinction that policy
or the DFSG makes.

Michael Poole


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

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Josselin Mouette]

Le samedi 18 février 2006 à 09:59 -0500, Michael Poole a écrit :
> Anthony Towns writes:
> 
> > But even if that weren't the case, nasm is an assembler -- it doesn't
> > rely on assembler code to do anything useful, its purpose is to translate
> > assembler code. ndiswrapper isn't a driver compiler, it's a wrapper to
> > allow existing drivers to run on Linux.
> 
> This apparently means that you object to translation at the binary
> level but not translation at the source level.  I guess that's
> reasonable in a general sense, it's just not a distinction that policy
> or the DFSG makes.

Come on, please stop arguing with random, unsuited comparisons, and use
common sense : what's the purpose of ndiswrapper without non-free
drivers to use it on? We've always put things of the like in contrib,
and if we stop doing it, we can remove contrib entirely.

Why are you trying so hard to keep it in main? Putting it in contrib
doesn't mean we'd stop supporting it. If this is about availability "by
default", you'd better work on d-i so that it can load drivers from
contrib and non-free if provided, instead of trying to put each and
every driver with a firmware or another non-free bit in main.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Michael Poole]

Josselin Mouette writes:

> Le samedi 18 février 2006 à 09:59 -0500, Michael Poole a écrit :
> > Anthony Towns writes:
> > 
> > > But even if that weren't the case, nasm is an assembler -- it doesn't
> > > rely on assembler code to do anything useful, its purpose is to translate
> > > assembler code. ndiswrapper isn't a driver compiler, it's a wrapper to
> > > allow existing drivers to run on Linux.
> > 
> > This apparently means that you object to translation at the binary
> > level but not translation at the source level.  I guess that's
> > reasonable in a general sense, it's just not a distinction that policy
> > or the DFSG makes.
> 
> Come on, please stop arguing with random, unsuited comparisons, and use
> common sense : what's the purpose of ndiswrapper without non-free
> drivers to use it on? We've always put things of the like in contrib,
> and if we stop doing it, we can remove contrib entirely.

What's the purpose of an assembler without assembly code to use it on?
Despite Anthony's claim, I see no packages that can use nasm out of
the box, which means it needs software not in main to perform its
intended use (which seems to be the objection to ndiswrapper).

If you want to move ndiswrapper to contrib, I expect the next step is
to do the same to libflash, for the same reasons.  Next: natively
compile all Java packages in main and move interpreter and compilers
for Java bytecode to contrib.  After all, the point of Java is to
allow the running of non-free software.  Mono and DotGNU would get the
same treatment.  Right?

Michael Poole

Re: Bug#353277: ndiswrapper in main

[Goswin von Brederlow]

Robert Millan <[EMAIL PROTECTED]> writes:

> On Fri, Feb 17, 2006 at 12:40:10PM -0500, Andres Salomon wrote:
>> On Fri, 2006-02-17 at 18:00 +0100, Robert Millan wrote:
>> [...]
>> > 
>> > First, I couldn't find any reference to a "GPLed NDIS driver" in 
>> > ndiswrapper's
>> > website, like Michael Poole asserts:
>> > 
>> >   http://lists.debian.org/debian-devel/2005/01/msg00381.html
>> > 
>> 
>> I assume he was talking about the CIPE driver; it's linked right from
>> the main ndiswrapper page.
>
> I see.  From http://cipe-win32.sourceforge.net/ :
>
>   "CIPE-Win32 is a port of Olaf Titz's CIPE package from Linux to Windows NT."
>
> I think this is the cipe-source package in debian.  If this driver is already
> available, there's no much point in using it via ndiswrapper.
>
> Is there any other free ndis driver?

The availability to do this is enough even if there are other
(possibly better) ways to do the same. One free driver _in_ Debian and
the package should stay in main.

But does the cipe-source build or ship the windows driver for use with
ndiswraper? I doubt that.

Which means you need some software (even if it is free) from outside
Debian for ndiswraper. That makes it contrib imho.

MfG
Goswin


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

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Lars Wirzenius]

la, 2006-02-18 kello 10:43 -0500, Michael Poole kirjoitti:
> What's the purpose of an assembler without assembly code to use it on?

It can be used, for example, to assemble code you write yourself. That
is, after all, the primary purpose of programming tools: to help
programmers develop programs.

> Despite Anthony's claim, I see no packages that can use nasm out of
> the box, which means it needs software not in main to perform its
> intended use (which seems to be the objection to ndiswrapper).

Anthony listed a number of packages that require nasm for building. That
is a clear case of nasm being used by packages in main.

Nasm and ndiswrapper are in not comparable in any way that makes it
useful to argue that ndiswrapper should be kept in main.

-- 
Fundamental truth #3: Communication is difficult.


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

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Sat, Feb 18, 2006 at 05:04:54PM +0100, Goswin von Brederlow wrote:
> > I see.  From http://cipe-win32.sourceforge.net/ :
> >   "CIPE-Win32 is a port of Olaf Titz's CIPE package from Linux to Windows 
> > NT."
> > I think this is the cipe-source package in debian.  If this driver is 
> > already
> > available, there's no much point in using it via ndiswrapper.
> > Is there any other free ndis driver?
> The availability to do this is enough even if there are other
> (possibly better) ways to do the same. One free driver _in_ Debian and
> the package should stay in main.

Can the non developers on this list please stop posting as though they're
in a position to make global policy decisions for Debian?

> But does the cipe-source build or ship the windows driver for use with
> ndiswraper? I doubt that.

Even if it does, it shouldn't do so if there's no point to running the
driver through ndiswrapper. Stuff in contrib is free software, that
happens to be only useful in making non-free software work. There's no
shame in that; it just means RMS won't bother running it.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Anthony Towns]

On Sat, Feb 18, 2006 at 09:59:07AM -0500, Michael Poole wrote:
> Anthony Towns writes:
> > But even if that weren't the case, nasm is an assembler -- it doesn't
> > rely on assembler code to do anything useful, its purpose is to translate
> > assembler code. ndiswrapper isn't a driver compiler, it's a wrapper to
> > allow existing drivers to run on Linux.
> This apparently means that you object to translation at the binary
> level but not translation at the source level.  I guess that's
> reasonable in a general sense, it's just not a distinction that policy
> or the DFSG makes.

You have no idea what you're talking about. Which isn't surprising,
considering you're apparently not a developer, maintainer, applicant or
any other sort of regular contributor to Debian. In future, if you've
got questions, please ask, rather than degrading the quality of the lists
by doing the Usenet troll thing of posting authoritative statements that
are complete wrong in order to get other people to correct you.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Mike Hommey]

On Sat, Feb 18, 2006 at 05:04:54PM +0100, Goswin von Brederlow
> The availability to do this is enough even if there are other
> (possibly better) ways to do the same. One free driver _in_ Debian and
> the package should stay in main.
> 
> But does the cipe-source build or ship the windows driver for use with
> ndiswraper? I doubt that.
> 
> Which means you need some software (even if it is free) from outside
> Debian for ndiswraper. That makes it contrib imho.

Are there any free MSWord files in main ? No ? Then please move
antiword and similar tools to contrib.

Mike


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

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Michael Poole]

Anthony Towns writes:

> On Sat, Feb 18, 2006 at 09:59:07AM -0500, Michael Poole wrote:
> > Anthony Towns writes:
> > > But even if that weren't the case, nasm is an assembler -- it doesn't
> > > rely on assembler code to do anything useful, its purpose is to translate
> > > assembler code. ndiswrapper isn't a driver compiler, it's a wrapper to
> > > allow existing drivers to run on Linux.
> > This apparently means that you object to translation at the binary
> > level but not translation at the source level.  I guess that's
> > reasonable in a general sense, it's just not a distinction that policy
> > or the DFSG makes.
> 
> You have no idea what you're talking about. Which isn't surprising,
> considering you're apparently not a developer, maintainer, applicant or
> any other sort of regular contributor to Debian. In future, if you've
> got questions, please ask, rather than degrading the quality of the lists
> by doing the Usenet troll thing of posting authoritative statements that
> are complete wrong in order to get other people to correct you.

I was dragged into this conversation because someone cited, in a
duplicate bug report, an email that I wrote more than a year ago.
Please do not confuse that with "doing the Usenet troll thing".  But
if you want to make Debian even more hostile to people on the
"outside", continue along your current path.

Michael Poole


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

Re: Bug#353277: ndiswrapper in main

[Brett Parker]

On Sat, Feb 18, 2006 at 05:36:37PM +0100, Mike Hommey wrote:
> On Sat, Feb 18, 2006 at 05:04:54PM +0100, Goswin von Brederlow
> > The availability to do this is enough even if there are other
> > (possibly better) ways to do the same. One free driver _in_ Debian and
> > the package should stay in main.
> > 
> > But does the cipe-source build or ship the windows driver for use with
> > ndiswraper? I doubt that.
> > 
> > Which means you need some software (even if it is free) from outside
> > Debian for ndiswraper. That makes it contrib imho.
> 
> Are there any free MSWord files in main ? No ? Then please move
> antiword and similar tools to contrib.

*points at abiword and openoffice.org*

-- 
Brett Parker


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

Re: Bug#353277: ndiswrapper in main

[Michael Poole]

Brett Parker writes:

> On Sat, Feb 18, 2006 at 05:36:37PM +0100, Mike Hommey wrote:
> > On Sat, Feb 18, 2006 at 05:04:54PM +0100, Goswin von Brederlow
> > > The availability to do this is enough even if there are other
> > > (possibly better) ways to do the same. One free driver _in_ Debian and
> > > the package should stay in main.
> > > 
> > > But does the cipe-source build or ship the windows driver for use with
> > > ndiswraper? I doubt that.
> > > 
> > > Which means you need some software (even if it is free) from outside
> > > Debian for ndiswraper. That makes it contrib imho.
> > 
> > Are there any free MSWord files in main ? No ? Then please move
> > antiword and similar tools to contrib.
> 
> *points at abiword and openoffice.org*

Those are (arguably) different because they let users create software
in those formats, instead of just processing existing software.

Michael Poole


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

Change .rm to mp3 or wav file

[Peter Khwatenge]

Do you have a program that can change .rm to mp3 or wave files? If yes, how can I get one?     Thanks     Peter  [EMAIL PROTECTED]   
		 Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars.

Re: Change .rm to mp3 or wav file

[Michael Banck]

Hi,

On Sat, Feb 18, 2006 at 09:29:52AM -0800, Peter Khwatenge wrote:
> Do you have a program that can change .rm to mp3 or wave files? If
> yes, how can I get one?

This question is inappropriate for this list, please ask on
[EMAIL PROTECTED]


thanks,

Michael


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

Re: Bug#353277: ndiswrapper in main

[Josselin Mouette]

Le samedi 18 février 2006 à 17:36 +0100, Mike Hommey a écrit :
> > Which means you need some software (even if it is free) from outside
> > Debian for ndiswraper. That makes it contrib imho.
> 
> Are there any free MSWord files in main ? No ? Then please move
> antiword and similar tools to contrib.

If you want to follow that (totally unsuited) line of reasoning, I'm
sure we can find free MSWord files in main. I've already encountered
some in documentation directories of some sources.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Olaf Titz]

> > First, I couldn't find any reference to a "GPLed NDIS driver" in 
> > ndiswrapper's
> > website, like Michael Poole asserts:
> >
> >   http://lists.debian.org/debian-devel/2005/01/msg00381.html
> >
>
> I assume he was talking about the CIPE driver; it's linked right from
> the main ndiswrapper page.

Why on earth would anyone want to run the Windows version of a native
Linux app under a Windows emulation under Linux? :-)

The Windows CIPE is linked from the ndiswrapper home page apparently
as a reference to understand NDIS, which makes more sense to me.

Olaf


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

Re: Bug#353381: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system

[Joe Smith]

Sorry to change the topic, but looking at some of the manpages in the 
"manpages" package,
and some of the pages in the "manpages-dev" causes me no notice some pages 
that look like they probably should be in a different package.


ld-linux(8)
ld-linux.so(8)
 These probably belong in libc6 which appears to be the provider of 
ld-linux.so


sync(8)
 This should be deleted. Coreutils (the provider of the sync utility) 
provides sync(1) for that utility.


tzselect(8)
This should be removed. it duplicates tzslect(1) (which i presume is 
provided by the package providing tzselect)


ksoftirqd(9)
 I'm pretty sure this does not belong in the manpage package.


As for manpages-dev, it would seem more logical for the linux syscall 
manpages to be part of linux, and the library documentation to be a part of 
the libraries that provide the documented functions.




If somebody with more time can check on these and, if they are valid, file 
bugs, I would appreciate it, as I do not have the time right now. 




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

Re: Change .rm to mp3 or wav file

[Kevin Mark]

On Sat, Feb 18, 2006 at 09:29:52AM -0800, Peter Khwatenge wrote:
> Do you have a program that can change .rm to mp3 or wave files? If yes, how 
> can I get one?
>
>   Thanks
>
>   Peter
>   [EMAIL PROTECTED]
Hi Peter,
there is software to do this but your questions should be asked on the
debian-user list where questions like these are answered. This list is
not used to answer question about using Debian but about making the
Debian distribution.
Cheers,
Kev
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal | debian.home.pipeline.com |
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
| my keysever: pgp.mit.edu   | my NPO: cfsg.org |


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Arthur de Jong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Sat, 18 Feb 2006, Josselin Mouette wrote:
Come on, please stop arguing with random, unsuited comparisons, and use 
common sense : what's the purpose of ndiswrapper without non-free 
drivers to use it on? We've always put things of the like in contrib, 
and if we stop doing it, we can remove contrib entirely.


The purpose of ndiswrapper is to run non-free Windows drivers on Linux. 
The same is more or less true for wine and dosemu (otherwise we would 
probably make a native version of said apps).


Would the situation change (contrib-wise) if ndiswrapper were integrated 
into the kernel? Would we want to split the ndiswrapper part to contrib 
then?


- -- 
- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong --

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFD95rRVYan35+NCKcRAk9/AKCz0PEtSLrjUfa2JHUSxFp1GC3yGwCg5gfT
S18zHSeAQGSETSaZfkyPmps=
=f4Pu
-END PGP SIGNATURE-


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

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Josselin Mouette]

Le samedi 18 février 2006 à 23:08 +0100, Arthur de Jong a écrit :
> Would the situation change (contrib-wise) if ndiswrapper were integrated 
> into the kernel? Would we want to split the ndiswrapper part to contrib 
> then?

In this case, the ndiswrapper functionality would become optional for
the kernel package, just like e.g. w32codecs for xine.

The same goes for a driver with a firmware.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Marco d'Itri]

On Feb 18, Josselin Mouette <[EMAIL PROTECTED]> wrote:

> The same goes for a driver with a firmware.
Drivers do not have a firmware, hardware devices do.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Hendrik Sattler]

Am Samstag, 18. Februar 2006 23:08 schrieb Arthur de Jong:
> On Sat, 18 Feb 2006, Josselin Mouette wrote:
> > Come on, please stop arguing with random, unsuited comparisons, and use
> > common sense : what's the purpose of ndiswrapper without non-free
> > drivers to use it on? We've always put things of the like in contrib,
> > and if we stop doing it, we can remove contrib entirely.
>
> The purpose of ndiswrapper is to run non-free Windows drivers on Linux.
> The same is more or less true for wine and dosemu (otherwise we would
> probably make a native version of said apps).

An example: Inno Setup for creating self-extracting installers for win32 has a 4-clause BSD style license but needs Borland Delphi to compile. How would you make a native application (the command line utility would suffice)?
I let it run with wine to create a distribution of a software for windows (using the very useful mingw32 packages).

Same goes for dosemu that can run freedos.

Those two do not compare to ndiswrapper.

> Would the situation change (contrib-wise) if ndiswrapper were integrated
> into the kernel? Would we want to split the ndiswrapper part to contrib
> then?

Ndiswrapper will never be integrated into the kernel. However, I see drivers in linux that need non-free parts (=firmware) to run. Do those now go to contrib?
Ndiswrapper probably is better compared to such drivers than to wine or dosemu.

If you have to go by some laws but want mostly firmware driven hardware, you cannot have it all open source with a free license. You wouldn't have the proper compiler anyway.
Maybe Debian should take one or two steps back to the point where it only requires source for something that can actually be compiled with something in Debian.
For the rest, it should only matter if it's actually distributable. And yes, this is not much related to the ndiswrapper discussion.

HS

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Josselin Mouette]

Le samedi 18 février 2006 à 23:34 +0100, Marco d'Itri a écrit :
> On Feb 18, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> 
> > The same goes for a driver with a firmware.
> Drivers do not have a firmware, hardware devices do.

Really? So all these drivers that come with an integrated firmware don't
really exist? They are only in my head, right, I have to call the
doctor.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Josselin Mouette]

Le samedi 18 février 2006 à 23:37 +0100, Hendrik Sattler a écrit :
> Maybe Debian should take one or two steps back to the point where it
> only requires source for something that can actually be compiled with
> something in Debian.

Ahem... so, to force the trait, you mean we could distribute any kind of
shareware that needs Visual C++ to build?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Hendrik Sattler]

Am Samstag, 18. Februar 2006 23:43 schrieb Josselin Mouette:
> Le samedi 18 février 2006 à 23:37 +0100, Hendrik Sattler a écrit :
> > Maybe Debian should take one or two steps back to the point where it
> > only requires source for something that can actually be compiled with
> > something in Debian.
>
> Ahem... so, to force the trait, you mean we could distribute any kind of
> shareware that needs Visual C++ to build?

You definitely didn't get the point! It's about the target architecture, not 
the system. Even if you actually _have_ the source, you could not compile 
with _any_ compiler you have at hand.
And why would you want to ship programs targetted for Windows with Debian? 
They don't integrate into the unix directory layout anyway, thus making no 
sense as a package...

And you want to write a compiler for this one chip to compile this
single peace of firmware? You must have a lot of time ;)

So let me make it more precise: only source for something that can actually be 
compiled and runs on a system's host CPU.
Me just doesn't get the rationale behind differing between firmware in a PROM 
and firmware that the driver loads into the hardware. There is none.

HS

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Josselin Mouette]

Le dimanche 19 février 2006 à 00:30 +0100, Hendrik Sattler a écrit :
> So let me make it more precise: only source for something that can actually 
> be 
> compiled and runs on a system's host CPU.
> Me just doesn't get the rationale behind differing between firmware in a PROM 
> and firmware that the driver loads into the hardware. There is none.

I wonder why all people go on trying to build up tons of different
fallacious reasonings to keep firmwares in main. Non-free is here for a
reason, we just have to use it. Technical solutions to have the driver
in the kernel or in contrib, and the firmware in non-free, exist.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Josselin Mouette]

Le dimanche 19 février 2006 à 00:30 +0100, Hendrik Sattler a écrit :
> Me just doesn't get the rationale behind differing between firmware in a PROM 
> and firmware that the driver loads into the hardware. There is none.

Oh, and please, dear trolls, stop raising the firmwares-in-main banner
in each and every single thread. This is getting tiring.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Steve Langasek]

On Sat, Feb 18, 2006 at 08:24:32PM +0100, Olaf Titz wrote:
> > > First, I couldn't find any reference to a "GPLed NDIS driver" in 
> > > ndiswrapper's
> > > website, like Michael Poole asserts:

> > >   http://lists.debian.org/debian-devel/2005/01/msg00381.html

> > I assume he was talking about the CIPE driver; it's linked right from
> > the main ndiswrapper page.

> Why on earth would anyone want to run the Windows version of a native
> Linux app under a Windows emulation under Linux? :-)

Because they're a developer of that app and they want to test the Windows
port before releasing?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Bug#353381: ITP: freebsd-manpages -- Manual pages for a GNU/kFreeBSD system

[Russ Allbery]

Joe Smith <[EMAIL PROTECTED]> writes:

> Sorry to change the topic, but looking at some of the manpages in the
> "manpages" package, and some of the pages in the "manpages-dev" causes
> me no notice some pages that look like they probably should be in a
> different package.

Your points about sync(8) and tzselect(8) seem reasonable on the surface,
but the rest of this seems to be disregarding the fact that manpages and
manpages-dev are not native packages.  Those man pages are included in
that package because they're maintained together upstream in a
distribution that Debian packages.

There are various reasons why the man pages for libc interfaces are in a
separate package that probably aren't worth getting into; suffice it to
say that libc upstream is probably not going to incorporate and maintain
the relevant man pages.  Also, it makes less sense than it sounds to
include the section two man pages with Linux rather than separately in the
manpages-dev package; the userspace API is often not exactly the system
call exposed by the kernel, since libc mediates the system call and often
does some rejiggering of data types in the process.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Marco d'Itri]

On Feb 19, Josselin Mouette <[EMAIL PROTECTED]> wrote:

> I wonder why all people go on trying to build up tons of different
> fallacious reasonings to keep firmwares in main.
Because it's good for Debian and is good for our users.

> Non-free is here for a
> reason, we just have to use it. Technical solutions to have the driver
It would not be Debian anymore then.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Thomas Bushnell BSG]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Feb 19, Josselin Mouette <[EMAIL PROTECTED]> wrote:
>
>> I wonder why all people go on trying to build up tons of different
>> fallacious reasonings to keep firmwares in main.

> Because it's good for Debian and is good for our users.

Regardless, we already have a commitment: to remove non-DFSG bits from
the main archive.

We already had a GR on this, and rejected a second GR to reverse the
first.  Now is the time for you to graciously decide that you have
been outvoted.



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

Re: Bug#353277: ndiswrapper in main

[Thomas Bushnell BSG]

Hendrik Sattler <[EMAIL PROTECTED]> writes:

> You definitely didn't get the point! It's about the target architecture, not 
> the system. Even if you actually _have_ the source, you could not compile 
> with _any_ compiler you have at hand.

This is not what the DFSG says.  The DSFG says that all the source
should be available.  It does not give any limitations about whether
you happen to be able to compile it with the compilers you have at
hard.  And heck, you might well have a compiler for the target
architecture.

Thomas


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

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Michael Poole]

Josselin Mouette writes:

> Le dimanche 19 février 2006 à 00:30 +0100, Hendrik Sattler a écrit :
> > So let me make it more precise: only source for something that can actually 
> > be 
> > compiled and runs on a system's host CPU.
> > Me just doesn't get the rationale behind differing between firmware in a 
> > PROM 
> > and firmware that the driver loads into the hardware. There is none.
> 
> I wonder why all people go on trying to build up tons of different
> fallacious reasonings to keep firmwares in main. Non-free is here for a
> reason, we just have to use it. Technical solutions to have the driver
> in the kernel or in contrib, and the firmware in non-free, exist.

Sure.  The unfortunate side effect is that some reasonable fraction of
people who would use those drivers cannot install from install media
that contain only Debian.  They require bits of non-free.  As is often
pointed out, Debian has chosen (twice) to make life hard for those
users.  I guess the preferred solution for them is to just use some
other distribution.

Michael Poole

Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Henning Makholm]

Scripsit Gunnar Wolf <[EMAIL PROTECTED]>
> Xavier Roche dijo [Mon, Feb 13, 2006 at 10:55:57AM +0100]:

>> So a cat is a software, or a hardware ? Do I have to provide the sources
>> (the DNA full sequence) if I want to give a kitten to someone, following
>> the "free" spirit ? :p

> A cat is not licensed under a viral license ;-) And, more important,
> is not covered by copyright law

Even more important: Debian does not distribute kittens at all.

-- 
Henning Makholm "... and that Greek, Thucydides"


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

Re: Bug#353277: ndiswrapper in main

[Thomas Bushnell BSG]

Michael Poole <[EMAIL PROTECTED]> writes:

> Sure.  The unfortunate side effect is that some reasonable fraction of
> people who would use those drivers cannot install from install media
> that contain only Debian.  They require bits of non-free.  As is often
> pointed out, Debian has chosen (twice) to make life hard for those
> users.  I guess the preferred solution for them is to just use some
> other distribution.

We have chosen to have a free operating system.  

That means, of course, that hardware which can only be supported by a
non-free driver, is not supported by Debian.  

It means that file formats which can only be read by non-free
software, are not supported by Debian.  

It means that network protocols which are only implemented by non-free
software, are not supported by Debian.  

It means that languages, which can only be processed by non-free
compilers and interpreters, are not supported by Debian.

Why should the first of these be granted some special exemption?

The preferred solution, of course, is to do the hard work of
supporting such things with free software!

Second to that, the next-best solution is *not to buy such hardware*,
*not to rely on such formats*, *not to use such protocols*, *not to
write code in such languages*.

Thomas



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

Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Benjamin Seidenberg]

Henning Makholm wrote:


Scripsit Gunnar Wolf <[EMAIL PROTECTED]>
 


Xavier Roche dijo [Mon, Feb 13, 2006 at 10:55:57AM +0100]:
   



 


So a cat is a software, or a hardware ? Do I have to provide the sources
(the DNA full sequence) if I want to give a kitten to someone, following
the "free" spirit ? :p
 



 


A cat is not licensed under a viral license ;-) And, more important,
is not covered by copyright law
   



Even more important: Debian does not distribute kittens at all.

 


Hmmm...

[EMAIL PROTECTED]:~$ ls -l /bin/cat
-rwxr-xr-x 1 root root 16744 2005-11-16 08:17 /bin/cat
[EMAIL PROTECTED]:~$

I guess we just don't deal in juveniles?

Benjamin



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

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Josselin Mouette]

Le dimanche 19 février 2006 à 01:52 +0100, Marco d'Itri a écrit :
> On Feb 19, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> 
> > I wonder why all people go on trying to build up tons of different
> > fallacious reasonings to keep firmwares in main.
> Because it's good for Debian and is good for our users.

It is good for our users to lie to them by pretending our operating
system full of non-modifiable bits is free?

> > Non-free is here for a
> > reason, we just have to use it. Technical solutions to have the driver
> It would not be Debian anymore then.

The project has chosen to keep non-free, remember? Or are you telling
this was a decorative decision and that your fellow developers only want
to have non-free without anything in it?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Josselin Mouette]

Le samedi 18 février 2006 à 21:32 -0500, Michael Poole a écrit :
> > I wonder why all people go on trying to build up tons of different
> > fallacious reasonings to keep firmwares in main. Non-free is here for a
> > reason, we just have to use it. Technical solutions to have the driver
> > in the kernel or in contrib, and the firmware in non-free, exist.
> 
> Sure.  The unfortunate side effect is that some reasonable fraction of
> people who would use those drivers cannot install from install media
> that contain only Debian.  They require bits of non-free.  As is often
> pointed out, Debian has chosen (twice) to make life hard for those
> users.  I guess the preferred solution for them is to just use some
> other distribution.

Please stop these lies. I repeat: technical solutions do exist. For
hardware unnecessary at installation's first stage, it is only a matter
of making non-free available. For hardware necessary for the first
stage, it would be possible to make the installer load udebs from
alternate sources, but the people who'd be interested in it are
spreading lies on debian-devel instead of working on the code.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Peter Samuelson]

[Hendrik Sattler]
> Me just doesn't get the rationale behind differing between firmware
> in a PROM and firmware that the driver loads into the hardware.
> There is none.

Good, then we can stop talking about including it in main.  We don't
ship hardware, so if firmware is part of the hardware, we don't need to
ship it either.  If it's part of the hardware, then it is the hardware
vendor's responsibility, not Debian's, to make sure it is available.

(It might be nice, for the convenience of the hardware vendors, to
produce some sort of specification for CD layouts and metadata so that
they can provide firmware to their customers in a way that's easy to
use with Debian.)


signature.asc
Description: Digital signature