Re: filters: Licence problems

[Ben Pfaff]

Marcus Brinkmann <[EMAIL PROTECTED]> writes:

   On Sun, Jan 24, 1999 at 08:36:58PM +0100, Vincent Renardias wrote:
   > "This program is catware.  If you find it useful in any way, pay for this
   > program by spending one hour petting one or several cats."
   > 
   > I'm indeed not quite sure 'catware' qualifies as DFSG-free.

   The obvious problem is that it is not clear if distributing, copying,
   modifying, selling is allowed.

Depends on the cat :-)

Re: Debian logo & its license

[John Hasler]

Andrew G . Feinberg writes:
> Why in the world do we need to license something as trivial as a _logo_?

I wrote:
> We don't.

Darren Benham writes:
> Of course we do.  Otherwise we'd have to grant permission to every
> tom-dick-harry that wanted to use it in any way-shape-form.

I meant, of course, that we don't need an elaborate specially written
license with elaborate restrictions.  "Debian grants permission to every
tom-dick-harry that wants to use this logo in any way-shape-form" would be
quite adequate.

Or don't license it: just use it on Debian stuff and grant individual
licenses on a case by case basis.  I doubt that you will be swamped by all
the requests.

What does FreeBSD do about their logo (or mascot, or whatever)?
-- 
John HaslerThis posting is in the public domain.
[EMAIL PROTECTED]  Do with it what you will.
Dancing Horse Hill Make money from it if you can; I don't mind.
Elmwood, Wisconsin Do not send email advertisements to this address.

Re: filters: Licence problems

[Raul Miller]

Ben Pfaff <[EMAIL PROTECTED]> wrote:
> Depends on the cat :-)

Indeed.

Now all we need is a way of petting /bin/cat, and we can automate payment.

-- 
Raul

Re: boot disk question/suggestion

[Jim Pick]

Ossama Othman <[EMAIL PROTECTED]> writes:

> Can the 2.1/2.2 kernels handle a gigabyte of memory?

Yes.

For more than 1GB, go to:

  http://humbolt.geo.uu.nl/Linux-MM/more_than_1GB.html

There was a lot of discussion about this on the linux-kernel mailing
list lately.

> Also, I remember reading somewhere that the 2.1/2.2 kernels can
> handle swap partitions greater than 128MB.  Is this also true?

I think so.

Cheers,

 - Jim

Re: Debian logo & its license

[James A. Treacy]

On Sun, Jan 24, 1999 at 06:20:49PM -0600, John Hasler wrote:
> 
> Or don't license it: just use it on Debian stuff and grant individual
> licenses on a case by case basis.  I doubt that you will be swamped by all
> the requests.
> 
I'm glad to see you volunteer to take respond to requests that come in and
check up that they are using the logo in a responsible way. Even with the
existing license (and a valid expiry date) I have probably handled 20 requests
for use of the logo in the last 6 months.

I will be rather happy to see a permanent license in place.

Jay Treacy

Re: Reality check!

[Adam Klein]

On Sun, Jan 24, 1999 at 04:17:16PM -0500, Steve Dunham wrote:
> "M.C. Vernon" <[EMAIL PROTECTED]> writes:
> 
> > I would see this as a RH-style - so a rather bloated kernel which includes
> > lots of stuff as standard, and asks them the pertinent questions all at
> > once at the beginning, and then gets on with it.
> 
> Excuse me, but RedHat actually boots on my laptop because the kernel
> is _less_ bloated than Debian's kernel. Debian's install disk doesn't
> boot.  Red Hat uses a zImage kernel, Debian uses bzImage because it's
> too big for zImage.

IIRC, for slink, the default kernel is a zImage.

Re: Debian logo & its license

[Andrew Dvorak]

Antti-Juhani Kaijanaho wrote:

> >On Sat, Jan 23, 1999 at 10:35:50PM -0600, Andrew G . Feinberg wrote:
> > Larry Ewing and Tux. You don't see him writing a license, do you?

> The picture of Tux is licensed freely for any use as long as Larry
> Ewing is mentioned.  Don't know about modification, though.

On http://www.isc.tamu.edu/~lewing/linux/index.html, it states" Permission to 
use
and/or modify this image is granted provided you acknowledge me
[EMAIL PROTECTED] and The GIMP if someone asks."

Andrew Dvorak.
"Experience is the worst teacher; you fail the test first and learn the
instructions afterwards." --Ambrose Bierce, "The Devil's Dictionary"

Re: filters: Licence problems

[Zephaniah E, Hull]

On Sun, Jan 24, 1999 at 07:52:34PM -0500, Ben Pfaff wrote:

> Depends on the cat :-)

Mrowl?

Zephaniah E. Hull..
(Who is peering at the humans oddly.. (=:])
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 PGP EA5198D1-Zephaniah E, Hull <[EMAIL PROTECTED]>-GPG E65A7801
Keys available at http://whitestar.soark.net/~warp/public_keys.
   CCs of replies from mailing lists are encouraged.


pgpMvrU1BCBtJ.pgp
Description: PGP signature

Re: getting kernel 2.2 into slink

[robbie]

Hi

I think it would be great for Debian to get 2.2 in to slink, even if it is
priority extra. Debian would then be the first distribution to include
2.2. It wouldn't make the distribution unstable, because 2.0 would still
be installed by default.

Regards


 -- 

Robbie Murray

Re: getting kernel 2.2 into slink

[Vincent Renardias]

On Sun, 24 Jan 1999 [EMAIL PROTECTED] wrote:

> I think it would be great for Debian to get 2.2 in to slink, even if it is
> priority extra. Debian would then be the first distribution to include
> 2.2. It wouldn't make the distribution unstable, because 2.0 would still
> be installed by default.

That would be cheating ;)

-- 
- Vincent RENARDIAS  [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux:   http://www.openhardware.orgLogiciels du soleil: -
- http://www.fr.debian.orgOpen Hardware: http://www.ldsol.com -
---
-"Microsoft est à l'informatique ce que le grumeau est à la crépe..." -

Re: Debian logo & its license

[John Hasler]

James A. Treacy writes:
> Even with the existing license (and a valid expiry date) I have probably
> handled 20 requests for use of the logo in the last 6 months.

Doesn't seem like many considering that the present license encourages
requests.  Do you really think that forty people a year would enquire about
using a logo which has not been offered to them?

> I will be rather happy to see a permanent license in place.

Fine.  Propose one and I'll second the motion and vote for it.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: Crypto software that *is* exportable from the USA

[James R. Van Zandt]

Paul Sheer wrote:
>I remember someone was maintaining the debian release of this software
>(although then, it did not support encryption). Please get the latest
>version from:
>   ftp://lava.obsidian.co.za/pub/mirrordir/US/

I maintain the Debian package of mirrordir.  The last version I
packaged was 0.9.29.  I have not packaged any of the (many) more
recent versions because:

 - I would not be able to include the new crypto features in the package
   anyway due to US export laws. (Debian packages are binary only, and
   FTP connectivity is not assured, so the "download sources from
   South Africa" model does not work.)  The non-us archive could host
   an up-to-date version, but someone else would have to maintain it.

 - Most of the recent releases have been bug fixes of crypto features.
   Besides the above problem with crypto, it does not appear stable.

 - The last time I checked, mirrordir fails its own self check routine
   due to a security check.  However, the situation it complains about
   looks okay to me.


  - Jim Van Zandt

Debian history timeline

[David Welton]

I recall some interest in generating a debian history timeline sort of
thing here - does anyone know the status of that?  A friend of mine is
interested in putting it on a poster...

Thanks,
-- 
David Welton  http://www.efn.org/~davidw 

Debian GNU/Linux - www.debian.org

Re: Debian logo & its license

[Joey Hess]

Jonathan P Tomer wrote:
> is the name debian a registered trademark?

I think so.

> if it is, wouldn't it be sensible to do the same for the logo?

I agree. I think trademarking the logo will allow us to prevent misuse and
at the same time allow us to give it a DFSG-free copyright.

-- 
see shy jo

Re: getting kernel 2.2 into slink

[Jim Lynch]

Hi Joey and *...

I have noticed something in 2.2.0* that has potential to break scripts that
add net routes. If I don't include "netmask " in the route commands,
it tells me "SIOCADDRT: Invalid argument".

Relevent versions:

basically everything is recent slink, except
kernel-image-2.2.0-pre1-i586 (custom compiled; .config available upon req)
netbase 3.11-1.2

-Jim

Re: filters: Licence problems

[Avery Pennarun]

My answer to exercise 1:  since you have quoted text, rule (2) says you must
not comply with rule (6), but rule (3) says you must comply with all even
rules (including, presumably, 6).  This seems to imply that no message
containing quotations would be allowed.

I'm not sure if that's only true when you start with one or more implicit
assumption, but then again, I'm not sure if you complied with rule (6)
anyway.

So I guess it sounds like a pretty decent set of arbitrary rules.  I second
the motion, and hereby propose that we apply them to debian-devel as well. 
We can call them the "Debian Grumpy Pooper Guidelines (DGPG)."

Have fun,

Avery



On Sun, Jan 24, 1999 at 10:04:45PM +0100, Marcus Brinkmann wrote:

> On Sun, Jan 24, 1999 at 01:50:21PM -0500, Raul Miller wrote:
> > David Welton <[EMAIL PROTECTED]> wrote:
> > > If you are indeed serious... technically, you are right, of course,
> > > but I think people are really going to think we are just a bunch of
> > > grumpy party-poopers if we seriously start to get anal about obviously
> > > silly licenses like this..:->
> > 
> > Perhaps we need a new list: debian-grumpy-party-poopers?
> > 
> > [With a nice long legal document indicating what's appropriate
> > traffic for the list, of course.]
> 
> (0) Every mail has to follow rule (0), (1), (2) and (3).
> (1) Any mail which starts with one or more implicit assumption has to follow
> rules (4) to (7).
> (2) Mails with quoted text must not fulfill rule (6) but (8).
> (3) Mails which carries a valid FQDN must comply with all even rules.
> 
> (4) Do NOT apologize for what you said, thought, wrote or assumed.
> (5) Do NOT try to make people happy.
> (6) Do NOT rant, flame, lie, hypocry or whine.
> (7) The number of letters divided by the number of words must be less than
> the number of columns divided by the number of lines.
> (8) End your message with a signature which uses figlet to summarize your
> final position.
> (9) This rule is obsolete and should not be used in any way.
> 
> (42) If you have come so far, you have the right to get the answer of the
>  universe. Have a deep breath and start all over again, this time reading
>  more carefully.
> 
> Exercise 1: Examine if this mail could be sent to
> debian-grumpty-party-poppers.
> Exercise 2: Write three DIN A4 pages about the breakdown of the society by
> overdoses of microwaves.
> 
> Marcus
> 
> -- 
> "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ 
> Marcus Brinkmann   http://www.debian.orgmaster.debian.org
> [EMAIL PROTECTED]for public  PGP Key
> http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   PGP Key ID 36E7CD09
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
> 
> 

Re: Debian logo & its license

[Max Hyre]

   All:

   Please pardon my non-developer comment, but one thing about the license has
bothered me for a while, and I've seen no else bring it up:

   Do we really want to limit the maximum size of an entity that can display
the license?

   Points 2, 3, & 4 of the license state, roughly, that you may not display
the logo unless half of the entity (software, info, or service) must be
related to or derived from Debian.  Thus any product, or service
organization, large enough to comprise all of Debian plus that amount of
something else plus one bit, can no longer use the logo.  So, Walnut Creek's
FTP server (cdrom.com) is out of luck.  So's the 13-CD release of Linux
Developer's Resource, and IBM, &c., &c., &c.  (So's Microsoft...hmm, maybe
that's the point. :-)

   Don't we want to specify that if they use the logo, they must
include/service/know about/deal with _at_least_half_of_Debian_?  That way,
anyone displaying the logo is fairly clueful about us, but not inherently
limited in the amount of what they can offer.


Fading back into the shadows...

Max Hyre

Don't bother cc:ing me---I'll get it out of the mailing-list archives
tomorrow night...

Re: filters: Licence problems

[Zephaniah E, Hull]

On Sun, Jan 24, 1999 at 11:43:33PM -0500, Avery Pennarun wrote:
> 
> My answer to exercise 1:  since you have quoted text, rule (2) says you must
> not comply with rule (6), but rule (3) says you must comply with all even
> rules (including, presumably, 6).  This seems to imply that no message
> containing quotations would be allowed.

Ahh, but rule (3) does not require us to follow rule (3), as such we do
not have to comply with rule (6)...

Zephaniah E, Hull..

> 
> Avery

-- 
 PGP EA5198D1-Zephaniah E, Hull <[EMAIL PROTECTED]>-GPG E65A7801
Keys available at http://whitestar.soark.net/~warp/public_keys.
   CCs of replies from mailing lists are encouraged.


pgpsgbyn6HLBS.pgp
Description: PGP signature

Re: the Great X Reorganization, package splits, and renaming

[Branden Robinson]

On Sun, Jan 24, 1999 at 12:52:19PM +, Jules Bean wrote:
> 2) Branden doesn't like xfnt-* hanging around.  We agree.

I don't just dislike it hanging around on people's machines, I dislike
having to keep the packages around at all, even just as compatibility
packages.

> 3) However, if someone were to create xfnt-* packages which *Depend* on
> the corresponding xfont-* package, then the user will automatically
> install the new xfont-*, which will in turn automatically deinstall the
> xfnt-*, so the cruft doesn't hang around.
> 
> Branden, do you object to this last?

Yes, but if it gets to the point where someone else will do it if I don't,
then I will do it.

I'd still rather we explored alternatives.

-- 
G. Branden Robinson  |   Measure with micrometer,
Debian GNU/Linux |   mark with chalk,
[EMAIL PROTECTED]   |   cut with axe,
cartoon.ecn.purdue.edu/~branden/ |   hope like hell.


pgpRTjcFGK3GT.pgp
Description: PGP signature

DFSG v2 Draft #5

[Darren Benham]

Here we go again.  There weren't many comments or suggestions on the last
version so I think we're getting close to a formal proposal to change.  Note,
we've removed the clause that requires the copyrights to be displayed during
execution.  It doesn't affect the GPL as version 2.  Are there any
license/packages that it DOES affect?

Remember, the parts in  will be removed in the final version.  We've
just included them as comments as we work this out.

There could still be problems, even spelling errors.  As they say, release
early release often.
 start 
  Debian Free Software Guidelines
  ---

  Anthony Towns <[EMAIL PROTECTED]>
 Darren Benham <[EMAIL PROTECTED]>

draft version 2.5.2 25 January 1999


---


Copyright Notice


 copyright ©1999 Anthony Towns & Darren Benham

 This document is free software; you may redistribute it verbatim in
 any format. You may modify this document and redistribute it in any
 form so long as you change the title of this document. You may use
 parts of this document for any purpose.

 This is distributed _without any warranty_; without even the implied
 warranty of merchantability or fitness for a particular purpose.

 This document, in it's source form, exists in DebianDoc format. _Parts
 marked  are notes and questions and not part of the actual
 document. They will be removed in the final work._


---


Contents


 1.Introduction
 1.1.  Application

 2.Requirements
 2.1.  Use
 2.2.  Source Code
 2.3.  Distribution
 2.4.  Modified and Derived Software
 2.5.  Termination of License

 3.Restrictions
 3.1.  Notices of Authorship
 3.2.  Misrepresentation of Authors
 3.3.  License of Derived Works
 3.4.  Restrictions on charges (deprecated)
 3.5.  Availability of source code
 3.6.  Integrity of the Original Work

 4.Notes
 4.1.  Deprecated
 4.2.  Non-binding Requests
 4.3.  Weaker Restrictions
 4.4.  Source Code
 4.5.  Example Licenses


---


1. Introduction 


 The Debian Free Software Guidelines define what it means for software
 to be free as far as the Debian project is concerned. Software that
 follows these guidelines is termed "DFSG-free".

 These guidelines are separated into two sections: a list of freedoms
 we require of DFSG-free software and a list of restrictions on those
 freedoms that we are willing to accept.


1.1. Application


 These guidelines are intended to be applied to software programs, that
 is, machine-readable programs that instruct a computer how to perform
 specific tasks, its source code, and any other items included with the
 original source distribution.


---


2. Requirements 



2.1. Use 
-

 Anyone must be able to use the software in any way without paying a
 fee or royalty or performing special actions.

 

 

 


2.2. Source Code 
-

 Source code must be freely available.

 


2.3. Distribution 
--

 Anyone must be able to give away or sell copies of the executables and
 sources without paying a fee or royalty. However, nobody can be
 required to distribute the software.

 

 


2.4. Modified and Derived Software 
---

 Anyone must be able to use and distribute the software (source or
 executables) with modifications and anyone must be able to distribute
 software that uses parts of the licensed source.

 


2.5. Termination of License 


 The license must remain valid until the licensee terminates it or
 violates the terms of the license

 


---


3. Restrictions 



3.1. Notices of Authorship 
---
 The license may require the copyright, license, and any associated
 disclaimers be prominently displayed in the modified software or any
 derived software. The license may require such notices to be
 displayed: (in order of preference) 

* wherever the modified/derived software displays copyrights

* in the source code or documentation

* in advertising materials (deprecated)

 

 

Re: DFSG v2 Draft #5

[Chris Lawrence]

A few minor nits (many stylistic):

On Jan 24, Darren Benham wrote:
>  This document, in it's source form, exists in DebianDoc
 

should be its (the possessive of it) not it's (short for "it is")

> 2.1. Use 
> -
> 
>  Anyone must be able to use the software in any way without paying a
>  fee or royalty or performing special actions.

"performing special actions" seems a bit vague.  How about "... a fee
or royalty.  In addition, it must not obligate users to perform any
additional actions (such as advertising their use of the software)."

>  The license must remain valid until the licensee terminates it or
>  violates the terms of the license

Needs a period (full stop) at the end of the line.

> 3.3. License of Derived Works 
> --
> 
>  The license can require modified and derived software be distributed
>  under the same license or the general requirement "any compatible
>  license."

I'd recommend using 'general requirement of "any compatible license."'

>  The license may also require the license of modified and derived
>  software be restricted to the same license or to any license that
>  meets these software has the choice of license as long as they meet
>  these guidelines.

I think your sentence got mangled here. "...the same license or to any
license that meets these guidelines."

>  The license my not impose restrictions on third-party software that
>  merely resides on the same system or distribution as the licensed
>  software.

distribution -> medium


Chris
-- 
=
|   Chris Lawrence|  The Linux/m68k FAQ |
|  <[EMAIL PROTECTED]>   |http://www.linux-m68k.org/faq/faq.html   |
| | |
|Amiga A4000/060 with |Watch Babylon 5 on TNT   |
| Linux/m68k 2.1.127  |   <*> http://tnt.turner.com/babylon5/ <*>   |
=

Re: DFSG v2 Draft #5

[David Welton]

Would it be prudent at this juncture to start discussing why we will
vote against this?  Or do people whish to finalize the format before
we discuss why we think it should be voted down?

(no offense for all the work being put into it, but I like the
original, thankyou very much)

Thanks,
-- 
David Welton  http://www.efn.org/~davidw 

Debian GNU/Linux - www.debian.org

Re: DFSG v2 Draft #5

[Buddha Buck]

I have two comments...

> 3.2. Misrepresentation of Authors 
> --
> 
>  The license may restrict the use of names and trademarks of the
>  copyright holders in association with modifications of the original
>  software.
> 
>  
> 
>the copyright holders even to promote something derived from the
>  original software>
...
> 3.6.2. Versioning and Renaming 
> ---
> 
>  Modified software may be required to use a version number or name
>  different than the official release.
> 

Are these two clauses redundant?  And should 3.6.2 be interpreted to 
extend to other identifiers besides name or number (such as icon used 
in a GUI to identify the software, or a logo affiliated with the 
software)?

Second...


[EMAIL PROTECTED] said:
> 3.3. License of Derived Works  --
...
>  The license may also require the license of modified and derived
>  software be restricted to the same license or to any license that
>  meets these software has the choice of license as long as they
> meet
>  these guidelines.

>   
...

This looks like the result of a bad cut-and-paste job.  I have tried, 
and I can't even understand what it was supposed to mean.  Could this 
be clarified in the final version?

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Platforms

[Darren Benham]

-BEGIN PGP SIGNED MESSAGE-

I've received two platform statements from the canidates to put on the web page
so, they're up.  If you go to http://www.debian.org/vote/1999/vote_0001 you'll
find a list of them.  Or you will within a day or two.  They've been uploaded,
now they have to filter through the make system

=
* http://benham.net/index.html <><  *
*  * -BEGIN GEEK CODE BLOCK- ---*
*Darren Benham * Version: 3.1   *
*  <[EMAIL PROTECTED]>  * GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++>*
*   KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS--   *
*   Debian Developer   * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++   *
*  <[EMAIL PROTECTED]>  * G++>G+++ e h+ r* y+*
*  * --END GEEK CODE BLOCK-- ---*
=

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv

iQCUAwUBNqwti7bps1lIfUYBAQHmowP0CmI1Jw21Op+0drVKmYXNKde1WPT8AL/e
wbRhfh3MpLE9Y1v0O5KOCGJ2YzJFjYpGYKmrznpdnLih9kEmbcIK8A+d2R0R+6gW
SPm47rcUluFRJXOrZut8J49icHQHMdOZOyFdJMog8OXaNmBjQldWvzB4HzQ3sa9g
n8NDkt9urw==
=qJHU
-END PGP SIGNATURE-

Re: DFSG v2 Draft #5

[Chris Lawrence]

On Jan 25, David Welton wrote:
> Would it be prudent at this juncture to start discussing why we will
> vote against this?  Or do people whish to finalize the format before
> we discuss why we think it should be voted down?

I think you (or we) can discuss the merits of the proposal now (that
seems to be the reason why we're critiquing drafts).  I personally
support it because the current DFSG, while mercifully brief, doesn't
have the "checklist" approach that this proposal seems to have (and a
DFSG-compliance checklist seems to be what most developers would need
in evaluating a new license).

IMHO we should also be discussing how the vote on this proposal will
be structured.  My understanding is that there are multiple DFSG
revision proposals "out there", even though this one is the only one
being currently hashed out on the list.

My voting structure proposal is (using preference voting):

[ ] Retain current DFSG
[ ] Revised DFSG proposal by A and B
[ ] Revised DFSG proposal by C
...
[ ] None of the above alternatives is acceptable

(I have no idea what quasilegal effect "None of the above" would have,
since it cannot be taken as an endorsement of the existing
DFSG... perhaps it would mean that the Social Contract as interpreted
by individual developers would govern what packages are acceptable,
subject to a majority vote to overrule that decision.)


Chris
-- 
=
| Chris Lawrence |   My home page:  |
|<[EMAIL PROTECTED]>|http://www.clark.net/pub/lawrencc/|
||  |
|  Amiga A4000/060 with  |   Visit the Amiga Web Directory  |
|   Linux/m68k 2.1.127   |  http://www.cucug.org/amiga.html |
=

Re: DFSG v2 Draft #5

[Anthony Towns]

On Sun, Jan 24, 1999 at 11:08:14PM -0800, Darren Benham wrote:
> 3.3. License of Derived Works 
> --
>  The license can require modified and derived software be distributed
>  under the same license or the general requirement "any compatible
>  license."

>  The license may also require the license of modified and derived
>  software be restricted to the same license or to any license that
>  meets these software has the choice of license as long as they meet
>  these guidelines.

I'm not sure I like either of these -- I find them more confusing than just
"The license may require derived works be licensed in a particular way, as
long as derived works can still be distributed under these guidelines", and
I'm not really sure what we're trying to avoid here.

There are a few cases worth thinking about:

* The GPL requires all future versions to be distributed under the
  GPL, essentially. This is okay, because you can require the same
  license, essentially.

* Modifications released under the QPL 0.92 are available to anyone
  under the terms of the QPL, and to Troll under terms "You can do
  whatever you want with this, as long as you release new software
  that incorporates it under the QPL as well as however else".

  But this seems to come under the "release under the same license"
  clause anyway.

The current DFSG says "You've got to be allowed to release modifications
under the original license".

Perhaps we should just leave it like that, with the justification that
``just as free software programmers shouldn't have to be rich to be able
to contribute to your code base, they shouldn't have to be lawyers either.
A simple license is a good one.''

Are there any licenses that can't just say ``if you make some
modifications, just leave the license as is. if you _really_ care,
you can also do such-and-such...'' ?

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. PGP encrypted mail preferred.

``Like the ski resort of girls looking for husbands and husbands looking
  for girls, the situation is not as symmetrical as it might seem.''


pgpPSLykF0IdR.pgp
Description: PGP signature

Re: DFSG v2 Draft #5

[Darren Benham]

-BEGIN PGP SIGNED MESSAGE-


On 25-Jan-99 Buddha Buck wrote:
> I have two comments...
> 
>> 3.2. Misrepresentation of Authors 
>> --
> ...
>> 3.6.2. Versioning and Renaming 
>> ---
> 
> Are these two clauses redundant?  And should 3.6.2 be interpreted to 
> extend to other identifiers besides name or number (such as icon used 
> in a GUI to identify the software, or a logo affiliated with the 
> software)?
No, the first refers to using the author's name (such as Buddha Buck or Darren
Benham).  The second refers to the name of the software it's self (grep or
sendmail).


> Second...
> 
> 
> [EMAIL PROTECTED] said:
>> 3.3. License of Derived Works  --
> ...
> 
> This looks like the result of a bad cut-and-paste job.  I have tried, 
> and I can't even understand what it was supposed to mean.  Could this 
> be clarified in the final version?
> 
It'll have to be.  That's one section nobody likes.  I decided to post the
draft with that section, basicly, messed up to get comments on the rest.  This
section is supposed to allow a sofware package to say that if someone modifies
it or uses code from it in their own software, the resulting software must also
be DFSG-free.

Geez, even my explanation isn't good... Maybe it's just the hour...
I'll take a crack at that tomarrow.
=
* http://benham.net/index.html <><  *
*  * -BEGIN GEEK CODE BLOCK- ---*
*Darren Benham * Version: 3.1   *
*  <[EMAIL PROTECTED]>  * GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++>*
*   KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS--   *
*   Debian Developer   * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++   *
*  <[EMAIL PROTECTED]>  * G++>G+++ e h+ r* y+*
*  * --END GEEK CODE BLOCK-- ---*
=

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv

iQCVAwUBNqw1RLbps1lIfUYBAQGHLAP/f3hGzpGWRMVoIVNFDIztNeXzv1nlB/8g
H6Fo7+QEdHONQWtECMoizm0zeJUBjM+zBQKOLLBRAx4icS/hdlm8cF1UpIT5tsRZ
IQkLDbMMPdUi7FVwhq3SLlXZp3HZQmxqmzxeWAzl2KZobrTvsfD/YXsDEG+AZFH7
UnqFgMWbQ1I=
=WZf0
-END PGP SIGNATURE-

Re: DFSG v2 Draft #5

[Darren Benham]

-BEGIN PGP SIGNED MESSAGE-


On 25-Jan-99 David Welton wrote:
> Would it be prudent at this juncture to start discussing why we will
> vote against this?  Or do people whish to finalize the format before
> we discuss why we think it should be voted down?

Ummm... I suppose you could if you want to.. but I'd rather wait, personally,
until the format has been finalized... I'll probably ignore any statment that
was blatant "absolute no" and not "maybe, just maybe if" until after the formal
proposal... 

There are enough people who *do* want the change that I think the vote would be
benificial if, for no other reason, than to settle the issue once and for all
so I'd rather put my energy into getting to that vote, first, before spending
any on convincing people to vote for or against it when it's done.

=
* http://benham.net/index.html <><  *
*  * -BEGIN GEEK CODE BLOCK- ---*
*Darren Benham * Version: 3.1   *
*  <[EMAIL PROTECTED]>  * GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++>*
*   KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS--   *
*   Debian Developer   * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++   *
*  <[EMAIL PROTECTED]>  * G++>G+++ e h+ r* y+*
*  * --END GEEK CODE BLOCK-- ---*
=

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv

iQCVAwUBNqw3f7bps1lIfUYBAQEZFwP6A7s96I8EYxUKwrb9IMD39RuFTG9hHopa
dJB4+ofj7mn2VaGq3wa/vB1xA3hb29BlgrzBHKgDVHlK4CJ+PY7HO/fmjt4HfY1F
hKDNH5bs7KgZVbiCNCpxZ+M9mMPsE0dGnOAHo4bBKC5sh0XntTxlwU6+kQxgIB3P
PlP/Emeu0sE=
=pJTV
-END PGP SIGNATURE-

Re: DFSG v2 Draft #5

[Darren Benham]

-BEGIN PGP SIGNED MESSAGE-


On 25-Jan-99 Chris Lawrence wrote:
> IMHO we should also be discussing how the vote on this proposal will
> be structured.  My understanding is that there are multiple DFSG
> revision proposals "out there", even though this one is the only one
> being currently hashed out on the list.
> 
> My voting structure proposal is (using preference voting):
> 
> [ ] Retain current DFSG
> [ ] Revised DFSG proposal by A and B
> [ ] Revised DFSG proposal by C
> ...
> [ ] None of the above alternatives is acceptable
> 

I envision it as being:

 [ ] ORIGINAL Draft
 [ ] Draft w/o patch clause
 [ ] Draft w/o advertising clause
 [ ] Draft w/o both clauses
 [ ] Current DFSG
 [ ] FURTHER Discussion (required by constitution)




- -- 
=
* http://benham.net/index.html <><  *
*  * -BEGIN GEEK CODE BLOCK- ---*
*Darren Benham * Version: 3.1   *
*  <[EMAIL PROTECTED]>  * GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++>*
*   KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS--   *
*   Debian Developer   * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++   *
*  <[EMAIL PROTECTED]>  * G++>G+++ e h+ r* y+*
*  * --END GEEK CODE BLOCK-- ---*
=

-BEGIN PGP SIGNATURE-
Version: 2.6.3a
Charset: noconv

iQCVAwUBNqw4PLbps1lIfUYBAQEFwAP/XVtTUurR3n5BvuxShF5+xrIdRByDxI4w
aRVNOjZ0CgoXrCAkeRpuA6S0B3Y2qtzd7t7nX77jUU6wCQUE6yJ9mrNgXLKevXQv
gfBVyW72RNA6jyxs3T0HOySAfGPJCVkp+f95ex47ocXLhW3kMjhdfpAAdSzt4zcT
Qs80QzGMekk=
=iLG9
-END PGP SIGNATURE-

X-fonts and fonts.alias

[Milan Zamazal]

What's the current policy about adding new names into fonts.alias in a
directory shared by more Debian packages?

Thanks for any advise.

Milan Zamazal

Re: DFSG v2 Draft #5

[Buddha Buck]

> -BEGIN PGP SIGNED MESSAGE-
> 
> 
> On 25-Jan-99 Buddha Buck wrote:
> > I have two comments...
> > 
> >> 3.2. Misrepresentation of Authors 
> >> --
> > ...
> >> 3.6.2. Versioning and Renaming 
> >> ---
> > 
> > Are these two clauses redundant?  And should 3.6.2 be interpreted to 
> > extend to other identifiers besides name or number (such as icon used 
> > in a GUI to identify the software, or a logo affiliated with the 
> > software)?
> No, the first refers to using the author's name (such as Buddha Buck or Darren
> Benham).  The second refers to the name of the software it's self (grep or
> sendmail).

I should have seen that... What confused me about 3.2 was the mention 
of "trademarks" in connection with what may be restricted.

OK, then what about my second question about those parts...

Should other identifiers, like icons or logos affiliated with a 
software, be able to be restricted in the same way as names?

I can write a DFSG-compliant license that says "If you distribute 
derived works of the WidgetFactory game, they must not be named 
'WidgetFactory'."  That is allowed by 3.6.2.  Could I go farther to say 
in addition "...and they must be modified to use a different logo that 
those included in the WidgetFactory*.xpm source files."  The purpose is 
the same as requiring a name-change: to protect the integrity of the 
"original" software.


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

-- 
 Buddha Buck  [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

dpkg port to HP-UX

[Fabrizio Polacco]

[please reply to me or to debian-devel, as I am subscribed only to it]

Hi everybody,
If I remember well, some time ago someone posted his results on a port 
of dpkg to HP-UX.
Now I have to evaluate packaging systems for that platform, and I would
like to push a Free solution, a debian one specifically (because it's 
the best :-).
If someone has hints or examples, please contact me, as it would help 
me greatly if I can present real cases and/or working code.

Thank you,
fab
-- 
| [EMAIL PROTECTED]   [EMAIL PROTECTED]   [EMAIL PROTECTED]
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
| [EMAIL PROTECTED] gsm: +358 40 707 2468

Re: Debian history timeline

[Mike Orr]

On Sun, Jan 24, 1999 at 09:33:00PM -0600, David Welton wrote:
> I recall some interest in generating a debian history timeline sort of
> thing here - does anyone know the status of that?  A friend of mine is
> interested in putting it on a poster...

The Linux Weekly News folx have come out with a Linux timeline for 1998.
http://lwn.net/1999/features/1998timeline/

It would be cool to have something like that for Debian.  Both to show
people, and also to remind ourselves how far we've progressed, and to
compare how long it took to get from stage A to B and B to C.

-- 
-Mike Orr, [EMAIL PROTECTED]

Re: Crypto software that *is* exportable from the USA

[Paul Sheer]

>  - I would not be able to include the new crypto features in the package
>anyway due to US export laws.

no, the US version contains no crypto code.

> (Debian packages are binary only, and

Both the source and binary US versions of mirrordir contain no crypto
code.

>FTP connectivity is not assured, so the "download sources from
>South Africa" model does not work.) 

I will set it to only download when the crypto stuff is used, so that
ordinary usage does not cause an automatic ftp transfer of the scripts.
When users discover the security features, they can then bother with not
having ftp connectivity.
Is this OK?

> 
>  - Most of the recent releases have been bug fixes of crypto features.
>Besides the above problem with crypto, it does not appear stable.

There have been some very important bug fixes in the ftp code. Also, the
crypto stuff is now quite stable.

-paul

Re: dpkg port to HP-UX

[loic]

Fabrizio Polacco wrote:

> Now I have to evaluate packaging systems for that platform, and I would
> like to push a Free solution, a debian one specifically (because it's
> the best :-).

We do think the same... (we do the same thing:)
I'm setting up a dpkg package manager under solaris...
...But the porting work has already been done.

Good luck,
Loic.

(And maybe contact Julian Bean about it; look at his message on debian-dpkg,
http://www.debian.org/Lists-Archives/debian-dpkg-9812/msg00021.html)

Re: DFSG v2 Draft #5

[Joseph Carter]

On Mon, Jan 25, 1999 at 01:24:13AM -0800, Darren Benham wrote:
> 
> On 25-Jan-99 Chris Lawrence wrote:
> > IMHO we should also be discussing how the vote on this proposal will
> > be structured.  My understanding is that there are multiple DFSG
> > revision proposals "out there", even though this one is the only one
> > being currently hashed out on the list.
> > 
> > My voting structure proposal is (using preference voting):
> > 
> > [ ] Retain current DFSG
> > [ ] Revised DFSG proposal by A and B
> > [ ] Revised DFSG proposal by C
> > ...
> > [ ] None of the above alternatives is acceptable
> > 
> 
> I envision it as being:
> 
>  [ ] ORIGINAL Draft
>  [ ] Draft w/o patch clause
>  [ ] Draft w/o advertising clause
>  [ ] Draft w/o both clauses
>  [ ] Current DFSG
>  [ ] FURTHER Discussion (required by constitution)

Please include URLs, there are SO MANY different proposals we really
should give people pointers to exactly which they're voting on.


-- 
"I'm working in the dark here."  "Yeah well rumor has it you do your best
work in the dark."
   -- Earth: Final Conflict

Re: dpkg port to HP-UX

[Jules Bean]

On Mon, 25 Jan 1999, loic wrote:

> Fabrizio Polacco wrote:
> 
> > Now I have to evaluate packaging systems for that platform, and I would
> > like to push a Free solution, a debian one specifically (because it's
> > the best :-).
> 
> We do think the same... (we do the same thing:)
> I'm setting up a dpkg package manager under solaris...
> ...But the porting work has already been done.
> 
> Good luck,
> Loic.
> 
> (And maybe contact Julian Bean about it; look at his message on debian-dpkg,
> http://www.debian.org/Lists-Archives/debian-dpkg-9812/msg00021.html)

In that message I merely express an interest - it's a cool idea.

In fact, I think Ben Collins has a working system on Solaris - check out
earlier emails in the same thread.

Jules

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka | [EMAIL PROTECTED]  |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/

Re: dpkg port to HP-UX

[Hamish Moffatt]

On Mon, Jan 25, 1999 at 10:41:20AM +0200, Fabrizio Polacco wrote:
> [please reply to me or to debian-devel, as I am subscribed only to it]
> 
> Hi everybody,
> If I remember well, some time ago someone posted his results on a port 
> of dpkg to HP-UX.
> Now I have to evaluate packaging systems for that platform, and I would
> like to push a Free solution, a debian one specifically (because it's 
> the best :-).

Hmmm. swinstall (HP-UX native I think) seems to support dependencies.
It's pretty ugly though and I don't know if there's a command line version.


Hamish
-- 
Hamish Moffatt VK3TYD  [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org

Re: the Great X Reorganization, package splits, and renaming

[Michael Stone]

Quoting Branden Robinson ([EMAIL PROTECTED]):
[snip more discussion of xfnt packages]
> I'd still rather we explored alternatives.

For how much longer? I don't think I've heard of anything else that has
a chance of working. (Did I miss something?) Alternatives have been
talked about for a while now, and IMHO it's time to actually do
something so it can be tested before (if?) slink actually releases.

Mike Stone



pgpBjYtm2Qdra.pgp
Description: PGP signature

Re: DFSG v2 Draft #5

[Ben Collins]

On Mon, Jan 25, 1999 at 01:16:13AM -0600, Chris Lawrence wrote:
> > 2.1. Use
> > -
> >
> >  Anyone must be able to use the software in any way without paying a
> >  fee or royalty or performing special actions.
>
> "performing special actions" seems a bit vague.  How about "... a fee
> or royalty.  In addition, it must not obligate users to perform any
> additional actions (such as advertising their use of the software)."

How about "... a fee or royalty, or taking special considerations to
meet the software's license."

--
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED]
-- -- - - - ---   --- -- The Choice of the GNU Generation

Re: Reality check!

[Enrique Zanardi]

On Sun, Jan 24, 1999 at 05:46:00PM -0800, Adam Klein wrote:
> On Sun, Jan 24, 1999 at 04:17:16PM -0500, Steve Dunham wrote:
> > Excuse me, but RedHat actually boots on my laptop because the kernel
> > is _less_ bloated than Debian's kernel. Debian's install disk doesn't
> > boot.

Ahem, _Which_ "Debian's install disk"?

That's why we have _tecra_ install disks... (except on boot-floppies_2.1.4
we have had those in every boot-floppies version since May 1997, Debian 1.2).

> > Red Hat uses a zImage kernel, Debian uses bzImage because it's
> > too big for zImage.
> 
> IIRC, for slink, the default kernel is a zImage.

Well, it still doesn't work on some laptops...
 
--
Enrique Zanardi[EMAIL PROTECTED]

Re: DFSG v2 Draft #5

[Ben Collins]

On Mon, Jan 25, 1999 at 03:32:30AM -0500, Buddha Buck wrote:
> > No, the first refers to using the author's name (such as Buddha Buck or 
> > Darren
> > Benham).  The second refers to the name of the software it's self (grep or
> > sendmail).
>
> I should have seen that... What confused me about 3.2 was the mention
> of "trademarks" in connection with what may be restricted.
>
> OK, then what about my second question about those parts...
>
> Should other identifiers, like icons or logos affiliated with a
> software, be able to be restricted in the same way as names?
>
> I can write a DFSG-compliant license that says "If you distribute
> derived works of the WidgetFactory game, they must not be named
> 'WidgetFactory'."  That is allowed by 3.6.2.  Could I go farther to say
> in addition "...and they must be modified to use a different logo that
> those included in the WidgetFactory*.xpm source files."  The purpose is
> the same as requiring a name-change: to protect the integrity of the
> "original" software.

That's a very good point. My personal opinion is that we should allow
authors to protect Trademarks in this way _only_ in derived or modified
versions. If you want to distribute the pristine source, the author
should allow you to distribute it with Trademarks and all. I'm sure if
some one took the Linux kernel source and derived some strange off the
wall new kernel from it, Linus wouldn't be too happy with it being
called Linux any more.

--
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED]
-- -- - - - ---   --- -- The Choice of the GNU Generation

Re: Debian logo & its license

[Thomas Adams]

On Sun, Jan 24, 1999 at 03:37:57AM +0100, Marcus Brinkmann wrote:

> to either of these animals. We have our own message, too. We are
> constructors. We take the work of thousands of people and put them together.
> Shouldn't this be reflected by the logo, too?

You mean like a penguin wearing a hard hat?

Re: bzip2 compressed files

[Russell Coker]

On Fri, 22 Jan 1999, you wrote:
>> I believe that eventually bzip2 support should be added to dselect and
>> dpkg (I would like to have packages such as xbooks compressed by bzip2).
>
>That would be nice as an additional option...
>
>> I doubt that 180K would be added if it became base_2.2.tbz2, in fact
>> it would probably be smaller.
>
>...but I wouldn't do that *and* remove that .tgz completely, or
>hhaving all the .debs converted to tbz2.

I agree, we're not ready for that yet.  However we only need bzip2 in the base
if we have bzip2 compressed .deb packages in the main sections.  If only
xbooks, dictionaries, and bible references are bzip2 compressed then most people
won't need bzip2.

>BTW if we leave the tgz-inside debs along with tbz2-inside ones, the
>mirror list would shorten, because it would double (already alarming :)
>archive size.

Definately not!  Maybe we should have two copies of the package files and
contents files as they get downloaded more often.  However I strongly believe
that packages such as xbooks should only be available with bzip2 compression.

--
I am in London and would like to meet any Linux users here.
I plan to work in London for 6 months and then I might move to some other
place where the pay is good.

Re: dpkg port to HP-UX

[Ben Collins]

On Mon, Jan 25, 1999 at 10:37:31AM +, Jules Bean wrote:
> On Mon, 25 Jan 1999, loic wrote:
>
> > Fabrizio Polacco wrote:
> >
> > > Now I have to evaluate packaging systems for that platform, and I would
> > > like to push a Free solution, a debian one specifically (because it's
> > > the best :-).
> >
> > We do think the same... (we do the same thing:)
> > I'm setting up a dpkg package manager under solaris...
> > ...But the porting work has already been done.
> >
> > Good luck,
> > Loic.
> >
> > (And maybe contact Julian Bean about it; look at his message on debian-dpkg,
> > http://www.debian.org/Lists-Archives/debian-dpkg-9812/msg00021.html)
>
> In that message I merely express an interest - it's a cool idea.
>
> In fact, I think Ben Collins has a working system on Solaris - check out
> earlier emails in the same thread.

Yes, he was talking about the very same port :) In fact if any one is
interested, I've dumped the stuff at:

ftp://marcus.seva.net/pub/debian/debian-solaris-sparc/

This stuff may not work that well, and may very well need some extra
care in getting it to work properly (read, it runs, but may not take
sunos'isms into account). My final work on this hardcodes a prefix of
/usr/larc so it may be awhile till I can setup some base pkg's that use
the standard directories. Please don't expect me to answer too many
questions about it, as it is only for those poor developers that need a
better soltion than pkgadd, and pkgrm, but can't use GNU/Linux in the
work place for one reason or another.

NOTE: the main sunos'ism to overcome:

echo "#!/bin/sh" > /usr/bin/ldconfig
chmod 755 /usr/bin/ldconfig

Any one know if GNU ldso can be compiled for Solaris without requiring
glibc to be compiled for it? (I hate having to work with sunos ldso).

--
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED]
-- -- - - - ---   --- -- The Choice of the GNU Generation

Re: the Great X Reorganization, package splits, and renaming

[Santiago Vila]

On Mon, 25 Jan 1999, Branden Robinson wrote:

> On Sun, Jan 24, 1999 at 12:52:19PM +, Jules Bean wrote:
> > 3) However, if someone were to create xfnt-* packages which *Depend* on
> > the corresponding xfont-* package, then the user will automatically
> > install the new xfont-*, which will in turn automatically deinstall the
> > xfnt-*, so the cruft doesn't hang around.
> > 
> > Branden, do you object to this last?
> 
> Yes, but if it gets to the point where someone else will do it if I don't,
> then I will do it.
> 
> I'd still rather we explored alternatives.

I think it got to that point. The upgrade should be smooth, and I think 
this is important enough for the credibility of Debian, so if you don't
create those dummy packages, I will probably do.


However, I have still a question: It is really *so* important for you to
rename the packages *now*, when dpkg does not support it in an elegant way?

Would not be much easier, simpler, creates less confusion and trouble,
etc. not to rename them for now?

If creating a problem makes it to have an ugly solution, why don't
just eliminate both the ugly solution and the problem?

-- 
 "d5fe503881811b001c67a618b2f084e1" (a truly random sig)

Gmod bugs

[Riku Voipio]

Hello everyone

There are several bug reports on (x)gmod which currently render it
useless. Unless nobody wants to fix it, I won't object if it will
be removed from atleast slink. I've got still 66 mornings left
military service, so I'm VERY engaded until 2.4.1999.

Have an ice day,

Private Voipio

-- 
"One World, One Web, One Program" - Microsoft Promotional Ad
"Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitler

Re: the Great X Reorganization, package splits, and renaming

[Branden Robinson]

On Mon, Jan 25, 1999 at 12:59:00PM +0100, Santiago Vila wrote:
> On Mon, 25 Jan 1999, Branden Robinson wrote:
> > Yes, but if it gets to the point where someone else will do it if I don't,
> > then I will do it.
> > 
> > I'd still rather we explored alternatives.
> 
> I think it got to that point.

Well, of course *you* would say that.  You'd rather there were no
discussion at all, and that things were done your way without question.

I want to hear from people other than you about it.

> The upgrade should be smooth, and I think 
> this is important enough for the credibility of Debian, so if you don't
> create those dummy packages, I will probably do.

You have yet to explain what will BREAK if people continue to use the old
font packages.  Not in the future, RIGHT NOW.  How will the upgraders be
inconvenienced?  Which of their programs will break?  Tell me.  If you can
come up with something concrete, I'll yield with no further argument.

I'm not going to place your sense of packaging esthetics above my own.

> However, I have still a question: It is really *so* important for you to
> rename the packages *now*, when dpkg does not support it in an elegant way?
> 
> Would not be much easier, simpler, creates less confusion and trouble,
> etc. not to rename them for now?
> 
> If creating a problem makes it to have an ugly solution, why don't
> just eliminate both the ugly solution and the problem?

That horse is already out of the barn.  Anybody who's been tracking
slink or potato already has knowledge of the new packages in dpkg's
database.

It would compound the error to reverse the name change.

Package: xfntbase
Provides: xfonts-base
?

I think not.

Pretending the Great Reorg didn't happen isn't a viable strategy, either.
If renaming the font packages proves to be an unmitigated disaster, then I
will accept the responsibility for it.  But I'm not going to pretend I
didn't do it by disowning versions -2 through -8 of slink/potato X.

But you very greatly exaggerate the consequences of leaving the old font
packages around.

I knew the xbase situation was intolerable and I didn't put up much of a
fight about it.

The xfnt* situation is quite tolerable.

-- 
G. Branden Robinson  |   "Why do we have to hide from the police,
Debian GNU/Linux |   Daddy?"
[EMAIL PROTECTED]   |   "Because we use vi, son.  They use
cartoon.ecn.purdue.edu/~branden/ |   emacs."


pgpVvSK1aqrs4.pgp
Description: PGP signature

Re: No intend to package vbox

[Paul Slootman]

On Sat 23 Jan 1999, Craig Sanders wrote:
> On Wed, Jan 20, 1999 at 11:36:23AM +0100, Paul Slootman wrote:
> 
> > isdnutils  contains the basic isdnctrl, ipppd stuff needed for 
> > networking
> > isdnmonitoring isdnlog, imon, xisdnload, ... that sort of thing
> > isdndocs   the faqs and other docs
> > isdnvbox   vbox
> > 
> > If anyone has better suggestions (I haven't really thought hard about
> > this yet) I'd like to hear them (please include reasoning).
> 
> i like the idea.  i don't use vbox or isdnlog at all.  
> 
> 'isdnmon' is probably a better name than 'isdnmonitoring'.

Yeah, except I have this feeling there's some program called isdnmon out
there, in which case it's confusing.

> also, i've been meaning to submit a bug report about the following:
> 
> one thing that would be really great would be if isdnutils could be
> upgraded WITHOUT taking down any running ippp connections. it's a bit

There's already a wishlist bug outstanding on this topic (#29255).
Sometime, when I have the time... :(


Paul Slootman
-- 
home: [EMAIL PROTECTED] | work: [EMAIL PROTECTED] | debian: [EMAIL PROTECTED]
http://www.wurtel.demon.nl | Murphy Software,   Enschede,   the Netherlands

Re: the Great X Reorganization, package splits, and renaming

[Santiago Vila]

On Mon, 25 Jan 1999, Branden Robinson wrote:

> You have yet to explain what will BREAK if people continue to use the old
> font packages.  Not in the future, RIGHT NOW.

Oh, you have yet to explain why a clock bomb is *not* a bad thing.
"Surely, it will exploit, but not now" ;-)

> How will the upgraders be inconvenienced?  Which of their programs will 
> break?  Tell me.  If you can
> come up with something concrete, I'll yield with no further argument.

It's already broken, just that the break will only show the first time the
new packages become different in any way to the old ones.

In the clock bomb example, the clock bomb is *always* bad, not
only when it does explode.

Please, don't talk about "release notes". We have a very good packaging
system, there should not be "release notes" for the upgrade. We are aiming
at non-interactive installs and upgrades, but unfortunately your sense of
aesthetics (to rename a few packages) seems to be more important than
that.

> I'm not going to place your sense of packaging esthetics above my own.

Well, please note that it's you who started talking about aesthetics.

First, you said "I believe the new names are less cryptic".
This creates the problem of the upgrading process.

I propose a solution (which is the only *viable* solution, since we can't
guarantee that dpkg will be changed), and you say it's uglier than the
hell.

> [...]
> It would compound the error to reverse the name change.
> 
> Package: xfntbase
> Provides: xfonts-base
> ?
> 
> I think not.

At least this would be *much* better than the current state of things.

> Pretending the Great Reorg didn't happen isn't a viable strategy, either.
> [...]

Splitting a package is ok, as long as you preserve the functionality
of existing users, and this is already done.

Renaming packages gratuitously is not ok if it creates a problem for which
there is not a solution.

-- 
 "4253e339c8453a56f6cf478d4911ef52" (a truly random sig)

Proposal: increasing mirror security

[Brandon Mitchell]

After seeing some trojan horses being spread and Martin trying to make
sure xisp can be verified as secure on the debian-user list, I started
thinking of how to secure our mirrors.  The thought I had was to make pgp
signatures of the package files and save them as Packages.pgp.  This will
not interfear with the current package files, therefore we are still
backwards compatable.  Then apt could check for a pgp file and verify it
for the user.  If it fails, it could just warn the user and ask to
continue.  This would require: a) gnu's version of pgp to work (so that we
don't request non-free software to get the free software) and the bad part
b) someone to be at the console when generating packages files to type
the pgp password.  Note that a trojan horse can only be added by a trusted
user (i.e. the package maintainer or an ftp site maintainer) unless the
upstream source compromised.

Thoughts?
Brandon

+---  ---+
| Brandon Mitchell * [EMAIL PROTECTED] * http://bhmit1.home.ml.org/ |
| The above is a completely random sequence of bits, any relation to |
|   an actual message is purely accidental.  |

Re: DFSG v2 Draft #5

[Raul Miller]

Darren Benham <[EMAIL PROTECTED]> wrote:
>  This document is free software; you may redistribute it verbatim in
>  any format. You may modify this document and redistribute it in any
>  form so long as you change the title of this document. You may use
>  parts of this document for any purpose.

This seems to conflict, in scope, with 1.1 -- I'll pose a couple other
examples where I'm not sure about 1.1 once I get there.

>  The Debian Free Software Guidelines define what it means for software
>  to be free as far as the Debian project is concerned. Software that
>  follows these guidelines is termed "DFSG-free".

No problem here, but contrast it with point 2.2.

> 1.1. Application
> 
> 
>  These guidelines are intended to be applied to software programs, that
>  is, machine-readable programs that instruct a computer how to perform
>  specific tasks, its source code, and any other items included with the
>  original source distribution.

So a set of GIMP bump maps is not software?  How about wave tables which
represent midi instruments for some sound card?

[bump maps can be any graphical image loadable by the gimp.  wave tables
can be sound samples.  The point being that the difference between code
and data depends on your point of view, and that as technology is developed
we're going to find our point of view drifting.]

If we're going to have some kinds of files which can be redistributed
without meeting these guidelines, I'd prefer to have them explicitly
described -- and then we still need guidelines for what kind of license
we expect on those files.

> 2.1. Use 
> -
> 
>  Anyone must be able to use the software in any way without paying a
>  fee or royalty or performing special actions.

This gets confusing if you consider modification and distribution as
forms of use.

> 2.2. Source Code 
> -
> 
>  Source code must be freely available.

Is this a recursive reference to this document?

[I think the point is that the source code for a DFSG-free executable
must also be DFSG-free.  However, there's no definition for source code,
so cases like the original source is compiled into unreadable C are
going to be ambiguous.]

> 3.1. Notices of Authorship 
> ---
>  The license may require the copyright, license, and any associated
>  disclaimers be prominently displayed in the modified software or any
>  derived software. The license may require such notices to be
>  displayed: (in order of preference) 
> 
> * wherever the modified/derived software displays copyrights
> 
> * in the source code or documentation
> 
> * in advertising materials (deprecated)
> 
>  
> 
>current licenses?>

This seems to imply that the emacs license can't prohibit someone
from removing its copyright display at load time.  [Because that's
where the >>unmodified<< software displays copyrights.]

> 3.3. License of Derived Works 
> --
> 
>  The license can require modified and derived software be distributed
>  under the same license or the general requirement "any compatible
>  license."

You might want to define "compatible".  [Remember how the old Qt license
said it was compatible with the GPL, even though the converse wasn't
true?]

-- 
Raul

Intent to package gnome-xml, RealTimeBattle, Pike, PiGTK

[Fredrik Hallenberg]

gnome-xml is an xml-library needed for the new version of Dia. As far as i
know gnome-xml can only be found in the gnome-cvs.

RealTimeBattle is a programming game similar to CRobots. 
http://realtimebattle.netpedia.net/

Pike 0.6.110. This a object-oriented script language used by the web server
Roxen. There already is roxen-pike package, but this contains an older
version of pike needed by Roxen. In the future (according to the new
maintainer of Roxen) the roxen-pike package will be merged with the Roxen
package. The pike0.6 package will conflict with roxen-pike until this is
fixed. Tommi Leino <[EMAIL PROTECTED]> has made a pike0.6 but haven't been
able to upload it. He has allowed me to take over the package.

PiGTK, GTK+ module for Pike.
http://www.pike-community.org/sites/pigtk/

-- 
Fredrik Hallenberg [EMAIL PROTECTED]
http://www.lysator.liu.se/~hallon  [EMAIL PROTECTED]

dpkg --print-architecture [WAS: Release-critical Bugreport for January 25, 1999]

[Marcelo E. Magallon]

On Mon, Jan 25, 1999 at 12:15:11AM -0600, BugScan reporter wrote:

> Package: emacs20 (main)
> Maintainer: Rob Browning <[EMAIL PROTECTED]>
>   28177  dpkg --print-architecture requires gcc   
>   
> 
> Package: xlib6 (main)
> Maintainer: Branden Robinson <[EMAIL PROTECTED]>
>   31610  xlib6: requires gcc but declares no dependency (dpkg 
> --print-gnu-build-architecture?)

Aren't this two the same kind of bug?  Having no idea why the maintainer
chose this particular way to implement this, wouldn't it be easier to put
this information *on the script* at *compile-time*?

Something like

ARCH := $(shell dpkg --print-gnu-build-architecture)

debian/whatever.postinst: debian/whatever.postinst.in
sed -e 's/@ARCH@/$(ARCH)/' $< > $@

Are there any drawbacks with this approach?  If I'm reading the scripts
correctly, the intent is to find out the architecture of the host that will
be *using* the packages, not the architecture of the host where the packages
are being *installed* (it would be interesting to know how/if cross-arch
installations are feasible, they _are_ possible via --force-architecture)


Marcelo

Re: Intent to package gnome-xml, RealTimeBattle, Pike, PiGTK

[Vincent Renardias]

On Mon, 25 Jan 1999, Fredrik Hallenberg wrote:

> gnome-xml is an xml-library needed for the new version of Dia. As far as i
> know gnome-xml can only be found in the gnome-cvs.

gnome-xml is already packaged (binary packages: libxml0 and libxml-dev).
I needed it to package gnumeric.

Cordialement,

-- 
- Vincent RENARDIAS  [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux:   http://www.openhardware.orgLogiciels du soleil: -
- http://www.fr.debian.orgOpen Hardware: http://www.ldsol.com -
---
-"Microsoft est à l'informatique ce que le grumeau est à la crépe..." -

Re: kernel 2.2.0, portmap, ipx and so on

[H.J. Lu]

> 
> I can very well understand them.  First of all some Linux distributors have
> been creative in the past and have moved rc[0-6].d/ and init.d/ to
> interesting places like /sbin/ or /etc/rc.d/, probably just to be
> ``different'' from a real System V.  Just one of the small but annoying
> differences between various UNIX flavours.

Agreed. All the Linux distributors should get together to choose one
directory for those rc scripts. I really don't care too much it is
exactly the same as Solaris. But I prefer something under /etc. RedHat
uses /etc/rc.d and Debian uses /etc. /etc/rc.d makes things easier to
control.

BTW, it would nice to standardize on package names and the numbers
accociated with each packages too.

> 
> I actually don't like the pile of symlinks that a SysV Init usually has
> quite messy; a text file for the configuration or maybe one per package to
> make things easier for package managers would have easier to manipulate.
> 

Symlinks may be a little messy. But it does provide support for run level
very nicely. A single text file or one per package is very bad. Since there
may be dependencies among packages, we have to start them in certain
order and new packages may be installed at any time. Symlinks works quite
well here. It is very convenient for packages with rc scripts. I really
appreciate that feature while working on knfsd.


-- 
H.J. Lu ([EMAIL PROTECTED])
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]

Re: dpkg --print-architecture [WAS: Release-critical Bugreport for January 25, 1999]

[Jules Bean]

On Mon, 25 Jan 1999, Marcelo E. Magallon wrote:

> On Mon, Jan 25, 1999 at 12:15:11AM -0600, BugScan reporter wrote:
> 
> > Package: emacs20 (main)
> > Maintainer: Rob Browning <[EMAIL PROTECTED]>
> >   28177  dpkg --print-architecture requires gcc 
> > 
> > 
> > Package: xlib6 (main)
> > Maintainer: Branden Robinson <[EMAIL PROTECTED]>
> >   31610  xlib6: requires gcc but declares no dependency (dpkg 
> > --print-gnu-build-architecture?)
> 
> Aren't this two the same kind of bug?  Having no idea why the maintainer
> chose this particular way to implement this, wouldn't it be easier to put
> this information *on the script* at *compile-time*?
> 
> Something like
> 
> ARCH := $(shell dpkg --print-gnu-build-architecture)
> 
> debian/whatever.postinst: debian/whatever.postinst.in
>   sed -e 's/@ARCH@/$(ARCH)/' $< > $@

This seems like a workable solution, for slink.

For potato, we will have a new tool, dpkg-architecture, which will solve
this problem more completely (see policy archives).

Jules

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka | [EMAIL PROTECTED]  |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/

Re: Proposal: increasing mirror security

[Brandon Mitchell]

[ hope you don't mind me cc'ing the list, but I think I didn't detail an
  important point. ]

On Mon, 25 Jan 1999, Vincent Murphy wrote:

>  i would favour another field in the .deb package format which contains a
> signature, which can be used by apt or whatever to verify that it is
> genuine.  however, i understand that modifying the package format isn't a
> viable solution where backward-compatability is a priority.

Ok, there could be a package by package basis.  I was going for the
simpler pgp signature of the entire Packages file itself.  Since the
packages file contains md5sums, there is a decent check on package by
package basis already in apt.

Thanks for seeing this,
Brandon

+---  ---+
| Brandon Mitchell * [EMAIL PROTECTED] * http://bhmit1.home.ml.org/ |
| The above is a completely random sequence of bits, any relation to |
|   an actual message is purely accidental.  |

Re: Debian history timeline

[Wichert Akkerman]

Previously David Welton wrote:
> I recall some interest in generating a debian history timeline sort of
> thing here - does anyone know the status of that?  A friend of mine is
> interested in putting it on a poster...

Quoting Will Lowe, Nov 3, 1998:
> I've just cvs-committed a new version of the project-history document;
> changes will show up on the DDP webpage
> (http://www.debian.org/~elphick/ddp/) whenever the cron job that updates
> them runs.

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpZR4YUfNc5T.pgp
Description: PGP signature

Re: the .app extension on (some) wmaker apps

[Marcelo E. Magallon]

On Sat, Jan 23, 1999 at 06:10:36PM -0500, [EMAIL PROTECTED] wrote:

> I'm trying to package wmsysmon.app -- but I'm not sure about the .app that
> *some* wmaker apps get -- I'm not sure if I should have the package as
> wmsysmon.app or just wmsysmon.

[ There are so many wm* packages showing up will need a wm-policy thing ]

The current situation I'm handling: wmmail up to 0.59 used a regular
configuration file. The next version uses a Proplist file... do I just
ignore the user and tell him to hand-upgrade the configuration, or do I
write a mapper? The second option looks really promising, and I've been
working on that on my so-called-free time, partly because I don't see any
need to upgrade to 0.62 (it has some rough edges) and partly because I know
the problem is going to show up more and more often.  Two minutes after I
wrote the first line of the mapper, I realized it wasn't going to be a nice
ride, and I need a perl wrapper for libProplist functions.

Thing is 0.62 builds wmmail.app which breaks the dock after upgrade. IMHO,
we can ditch the .app suffix but then again, many many docs will mention
SomeApp.app and not SomeApp (case is another popular problem with this
apps); also, it's becoming increasingly popular among authors to use
/usr/local/GNUstep/Apps/SomeApp.app/ (/usr/lib/GNUstep/Apps/SomeApp.app/ in
Debian) and put BINARIES there. Look in WPrefs.app, and you'll find there's
a link in there to ../../../../X11R6/bin (I'm going to change that to
../../../../../bin/X11) I'm still pondering a WPrefs.app link, too.

Back to this planet, I thougth wmsysmon was already packaged, wasn't it?

> The tarball is wmsysmon.app, but the binary that gets built is wmsysmon.

> I built an (undocumented) manpage for wmsysmon.app -- but lintian gives me
> a "binary with no manpage" since the binary doesn't have the .app --
> hr

call the manpage wmsysmon then (it would be neat if you could actually write
a manpage and send that upstream); there's nothing wrong with
wmsysmon.app_.org.tar.gz (the source package has to be called
wmsysmon.app). The binary package can be named wmsysmon or wmsysmon.app. I
would choose the second if that's the upstream name for the app, which is
another source of trouble: wm.apps' upstream authors dodn't seem to be
consistent with themselves.

> Should I leave the package as .app, but have the binary/manpage as-is
> (wmsysmon)?

I don't see a problem with that.


Marcelo

Re: Intent to package gnome-xml, RealTimeBattle, Pike, PiGTK

[Martin Bialasinski]

>> "FH" == Fredrik Hallenberg <[EMAIL PROTECTED]> writes:

FH> Pike 0.6.110.

FH> PiGTK, GTK+ module for Pike.
FH> http://www.pike-community.org/sites/pigtk/

So you package up both of these ? Great.

About Roxen: Roxen can be compiled with pike 0.6. Is there a need for
both versions 0.5? Maybe this makes things easier.

Actually the next version will come with pike 0.6.

Ciao,
Martin

Re: filters: Licence problems

[Marcelo E. Magallon]

On Sun, Jan 24, 1999 at 11:43:33PM -0500, Avery Pennarun wrote:

[ interesting solution to exercise 1, which I'm not quoting to avoid rule
  (2), but I have to comply with anyway because I want this message to make
  its way to debian-devel, or debian-humour if it existed ]

According to rule (0) you have to comply with (1), (2) and (3).  From the
text of rule (3), which I won't quote because of the previously expressed
reasons, it seems as if it will always hold because the messages have to
make it somehow to the lists and (3) doesn't say which DN has to be a FQDN
so it applies to each and every one of them.

Because of rule (3), (2) applies, but that was already the case according to
(0). Since the text of (2) doesn't invalidate (6) but just says (8) also
applies but (6) is no longer a requierement, it doesn't conflict with (3)
which says (6) a requierement.

Having cleared that problem, (2) applies because Marcus quoted Raul and
David. (3) applies because of the reasons exposed in the previous paragraph.
Taking that into account, (4), (6), (8) and (42) apply. (1) applies because
Marcus assumed Raul was serious about the need for a nice long legal
document indicating what's appropriate traffic for the
debian-grumpy-party-poopers list. (5) and (7) apply because of this.

It is not clear whether or not Marcus was trying to make someone happy (5)
with that message, but one could argue he was making Raul happy because he
was fulfilling the request for a nice long legal document indicating what's
appropiate traffic for the debian-grumpy-party-poopers list.

The number of letters (2111) divided by the number of words (328) in the
message is roughly 6.4; the number of colums over the number of lines is
1.7, so this goes against (7) (I'd like to understand what this rule tries
to address -- force short messages or force the use of short words?)

I can produce a signature like Marcus' with figlet, so that's ok with (8)
but I don't think Marcus' signature summarizes his position.

(9) doesn't apply.

(42) is not a rule.


IMO the message doesn't comply with the rules it defines.

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Alan Cox]

> I thought the purpose of this project (at least the FHS) is to create a 
> standard
> of what the filesystem should look like, not necessarily what it currently 
> looks
> like. Just because `Everyone is doing it' (tm) doesn't mean it's right.
> Personally, I want Linux to be clean and elegant in its implementation, so if
> that means breaking from convention and putting mail in /var/mail, so be it. I
> for one don't know the answer. Whatever the answer is should be the right one,
> not just the one people are doing.

If all the vendors think /var/mail is stupid then its perhaps time for the
FHS to ask "ok why.. is there a problem, did we make a bad choice, or did
we simply fail to explain the reasons /var/mail is good"

Re: DFSG v2 Draft #5

[Gregor Hoffleit]

On Mon, Jan 25, 1999 at 08:48:36AM -0500, Raul Miller wrote:
> Darren Benham <[EMAIL PROTECTED]> wrote:
> > 3.1. Notices of Authorship 
> > ---
> >  The license may require the copyright, license, and any associated
> >  disclaimers be prominently displayed in the modified software or any
> >  derived software. The license may require such notices to be
> >  displayed: (in order of preference) 
> > 
> > * wherever the modified/derived software displays copyrights
> > 
> > * in the source code or documentation
> > 
> > * in advertising materials (deprecated)
> > 
> >  
> > 
> >   >  current licenses?>
> 
> This seems to imply that the emacs license can't prohibit someone
> from removing its copyright display at load time.  [Because that's
> where the >>unmodified<< software displays copyrights.]

Umm, upon re-reading the GPL, I get a little bit sceptical about this
section 3.1. If I want to modify a GPLed work, the GPL makes the following
restriction:

  "2. You may modify your copy or copies of the Program or any portion
  of it, thus forming a work based on the Program, and copy and
  distribute such modifications or work under the terms of Section 1
  above, provided that you also meet all of these conditions:"

  ...
  
  "c) If the modified program normally reads commands interactively
  when run, you must cause it, when started running for such
  interactive use in the most ordinary way, to print or display an
  announcement including an appropriate copyright notice and a
  notice that there is no warranty (or else, saying that
  you provide a warranty) and that users may redistribute the
  program under these conditions, and telling the user how to
  view a copy of this License.  (Exception: if the Program itself
  is interactive but does not normally print such an announcement, 
  your work based on the Program is not required to print
  an announcement.)"

Furthermore, the appendix "How to Apply These Terms to Your New Programs"
says:

  "If the program is interactive, make it output a short notice like this
  when it starts in an interactive mode:

  Gnomovision version 69, Copyright (C) 19yy name of author
  Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type
  `show w'. This is free software, and you are welcome to redistribute
  it under certain conditions; type `show c' for details.


IMHO this restriction is much stronger than what 3.1 allows ("The license
may require such notices to be displayed: ... wherever the modified/derived 
software displays copyrights"). In the above example, the GPL would forbid
to remove the copyright notice that's displayed after executing the
program, while the proposed 3.1 would require that I have the right to do
this.

IMHO this makes the GPL non-free.


On a separate note, since this started the discussion about this point,
(I must sound like an advocatus diaboli ;-): What happened if the Zope
people would replace their "attribution button" with a copyright notice,
and modified Zope so that this notice (e.g. "Zope Copyright (C) 1999
Digital Creations, www.zope.org") would be displayed on the first page of
every session ? Couldn't they use a similar clause like the GPL to 
reject any modification of Zope that would remove this copyright notice ?
Zope is certainly a program that "reads commands interactively when run",
so they could mostly copy this requirement from the GPL.


Gregor

Re: DFSG v2 Draft #5

[Darren Benham]

On 25-Jan-99 Joseph Carter wrote:
> Please include URLs, there are SO MANY different proposals we really
> should give people pointers to exactly which they're voting on.
> 
No proposals have been made, yet.  Just drafts offered for posting.  So far, it
looks like only several different versions of the one proposal will be offered
(and the current DFSG, too).

-- 
=
* http://benham.net/index.html <><  *
*  * -BEGIN GEEK CODE BLOCK- ---*
*Darren Benham * Version: 3.1   *
*  <[EMAIL PROTECTED]>  * GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++>*
*   KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS--   *
*   Debian Developer   * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++   *
*  <[EMAIL PROTECTED]>  * G++>G+++ e h+ r* y+*
*  * --END GEEK CODE BLOCK-- ---*
=


pgplNUUZaFDin.pgp
Description: PGP signature

Re: Proposal: increasing mirror security

[Lalo Martins]

On Jan 25, Brandon Mitchell decided to present us with:
> The thought I had was to make pgp signatures of the package
> files and save them as Packages.pgp. This will not interfear
> with the current package files, therefore we are still
> backwards compatable. Then apt could check for a pgp file and
> verify it for the user. If it fails, it could just warn the
> user and ask to continue.

Sounds good, as long as I can shut it off :-) Also, it should
use the keyring in developers-keyring or one that comes with
apt, otherwise the point is moot (anyone who can upload a .deb
with a trojan can upload a Packages.pgp with a signature)

> This would require: a) gnu's version of pgp to work (so that we
> don't request non-free software to get the free software)

Here we go again. This would have the problem of requiring all
developers to switch to gpg.

OTOH, we could just sign all packages with a same key ("the
Debian key"); when dinstall verifies the signature and md5sum in
the .changes file, it signs the package and updates
Packages.pgp). One added advantage of this is that apt only has
to care about one key - it may even have it hardwired if gpg
permits.

> and the bad part b) someone to be at the console when
> generating packages files to type the pgp password.

Huh? You don't need the passphrase to verify signatures.

[]s,
   |alo
   +
--
  I am Lalo of deB-org. You will be freed.
 Resistance is futile.

http://www.webcom.com/lalo  mailto:[EMAIL PROTECTED]
 pgp key in the web page

Debian GNU/Linux   --http://www.debian.org

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Daniel Quinlan]

Alan Cox <[EMAIL PROTECTED]> writes:

> If all the vendors think /var/mail is stupid then its perhaps time
> for the FHS to ask "ok why.. is there a problem, did we make a bad
> choice, or did we simply fail to explain the reasons /var/mail is
> good"

Well, I've been told that Debian, Red Hat, SuSE, PHT, and Caldera are
all still using /var/spool/mail.  This may be because most
distributions haven't completely updated for FHS 2.0.  Of course, that
might be due to the /var/spool/mail change.

The only software (that I know of) that has switched over to /var/mail
is glibc.

I am leaning towards backing out the change in FHS 2.1.  I think it's
a small long-term loss, and definitely a cop-out, but my hope is that
now there will be a more serious review of FHS 2.1 by distributions
before it is released.

The one thing I think people have forgotten is that FHS is not just
trying to codify current practice.  If that was the case, we'd all
still be using /etc for system binaries, there wouldn't be a standard
directory for many things (like log files and documentation), we'd
still use /usr/man/cat? for performatted manual pages, etc.

Before reverting to /var/spool/mail, the practical question to ask
distributions is:

  If we explicitly allow /var/mail to be a symbolic link to
  /var/spool/mail (or whereever), will you *consider* changing
  programs to reference /var/mail instead of /var/spool/mail?
  Upgraded systems would not need to have their mount point changed,
  and old programs that reference /var/spool/mail would be okay for
  one year.

New systems would need to have a /var/spool/mail -> /var/mail symbolic
link for about two years.

- Dan

Re: Proposal: increasing mirror security

[Jason Gunthorpe]

On Mon, 25 Jan 1999, Brandon Mitchell wrote:

> for the user.  If it fails, it could just warn the user and ask to
> continue.  This would require: a) gnu's version of pgp to work (so that we
> don't request non-free software to get the free software) and the bad part
> b) someone to be at the console when generating packages files to type
> the pgp password.  Note that a trojan horse can only be added by a trusted
> user (i.e. the package maintainer or an ftp site maintainer) unless the
> upstream source compromised.

I would prefer to use the idea of a trusted site (like ftp.debian.org) to
fetch package file MD5 summs from, that way we do not get involed with the
sticky issue of cyrpto hooks. Automatic PGP signing has at least a few
problems, it requires that a key be placed on master that can be used
automatically by scripts (ie insecure) and it requires that the clients
know exactly which key to expect so changing keys becomes difficult.. 

We are not very vunerable to the sort of attacks we have heard of, someone
could go onto a mirror and could change a file and change the Packages
file but they would have to do that every single day!

Jason

Re: Proposal: increasing mirror security

[Jim Pick]

Lalo Martins <[EMAIL PROTECTED]> writes:

> OTOH, we could just sign all packages with a same key ("the
> Debian key"); when dinstall verifies the signature and md5sum in
> the .changes file, it signs the package and updates
> Packages.pgp).

I prefer this method.  Then we have less key distribution worries.

Cheers,

 - Jim

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[t . sippel-dau]

The keyboard of Daniel Quinlan emitted at some point in time:

> Before reverting to /var/spool/mail, the practical question to ask
> distributions is:
> 
>   If we explicitly allow /var/mail to be a symbolic link to
>   /var/spool/mail (or whereever), will you *consider* changing
>   programs to reference /var/mail instead of /var/spool/mail?
>   Upgraded systems would not need to have their mount point changed,
>   and old programs that reference /var/spool/mail would be okay for
>   one year.

Ten years.

> New systems would need to have a /var/spool/mail -> /var/mail symbolic
> link for about two years.

Ditto.

Software development may change fast, and many software developers will
change quickly in this case.  Documentation is much mmore difficult, and
what is actually used by users takes much longer again.

Since /var/mail and /var/spool/mail are "out there", it will not be
possible to use the "loosing" path for anything else for many years.

Thomas

*   Why not use metric units and get it right first time, every time ?
*
*   email: cmaae47 @ imperial.ac.uk

DPL Platforms

[Darren Benham]

I have added a third platform to the web page at
http://www.debian.org/vote/1999/vote_0001 and it should show up in the next day
or so.

Remember, as you read these platforms, if you wish to change your vote, just
send the ballot again with the required changes.  The vote system will replace
the old vote (preserving a record incase there's questions) with the new vote.

If you need a new ballot: the lastest ballot can be sent to you by sending
email to "[EMAIL PROTECTED]" with "leader99" as the subject.

--  
=
* http://benham.net/index.html <><  *
*  * -BEGIN GEEK CODE BLOCK- ---*
*Darren Benham * Version: 3.1   *
*  <[EMAIL PROTECTED]>  * GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++>*
*   KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS--   *
*   Debian Developer   * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++   *
*  <[EMAIL PROTECTED]>  * G++>G+++ e h+ r* y+*
*  * --END GEEK CODE BLOCK-- ---*
=


pgpQcXnScvKFP.pgp
Description: PGP signature

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Daniel Quinlan]

t sippel-dau <[EMAIL PROTECTED]> writes:

> Ten years.

Are you serious?  The Linux community has already made larger changes
in far far less time.  We're talking about modifying one or two lines
in 10 or 20 source packages (like src RPMs).

It was several years ago already that we dropped some of the symbolic
links that shipped with Linux systems circa FSSTND 1.0 (such as /usr/spool).

- Dan

Re: bzip2 compressed files

[Josip Rodin]

On Mon, Jan 25, 1999 at 11:49:43AM +, Russell Coker wrote:
> >...but I wouldn't do that *and* remove that .tgz completely, or
> >hhaving all the .debs converted to tbz2.
> 
> I agree, we're not ready for that yet.  However we only need bzip2 in the
> base if we have bzip2 compressed .deb packages in the main sections.
> If only xbooks, dictionaries, and bible references are bzip2 compressed
> then most people won't need bzip2.

Yes, but the bible (king james') is in main, and so are RFCs and xbooks.
If you'd want to make a fresh installation of debian from a CD, you'd
need bzip2 to decompress these -=> bzip2 would *have* to be in base or
dselect/dpkg would give 'Error 1' and quit when they encountered such
.debs. And making these packages Depend: on bzip2 is dumb.
If you propose putting these (and some other) large packages in some other
directory in the main archive and them compressing them with bzip2, fine,
but that is something different.

> >BTW if we leave the tgz-inside debs along with tbz2-inside ones, the
> >mirror list would shorten, because it would double (already alarming :)
> >archive size.
> 
> Definately not!

Not all people can afford to give more than 10 GB only for a doubled Debian
archive.

> Maybe we should have two copies of the package files and contents files
> as they get downloaded more often.

Certainly. We should submit a wishlist bug against dpkg/dselect to support
these bzip2 compressed files. Even if it had to be a dselect-bzip2 package.

> However I strongly believe that packages such as xbooks should only be
> available with bzip2 compression.

Yes, they are rather huge. Maybe a new section, like the one that was
proposed by people who'd like to upload vast amounts of geographical (and
other kinds of) data.

I'd vote for opening a new directory, ftp.debian.org/debian/data/ or
something like that, with subsections like 'doc', 'geo', 'space' etc.

--
enJoy -*/\*- http://jagor.srce.hr/~jrodin/

Re: DFSG v2 Draft #5

[Darren Benham]

On 25-Jan-99 Raul Miller wrote:
> This seems to conflict, in scope, with 1.1 -- I'll pose a couple other
> examples where I'm not sure about 1.1 once I get there.

No.  This document is meant to cover software... not itself.  Some of your
other comments seem to try to make the same application.

>> 1.1. Application
>> 
>> 
>>  These guidelines are intended to be applied to software programs, that
>>  is, machine-readable programs that instruct a computer how to perform
>>  specific tasks, its source code, and any other items included with the
>>  original source distribution.
> 
> So a set of GIMP bump maps is not software?  How about wave tables which
> represent midi instruments for some sound card?

If they're not part of a software package, no... atleast not how it was
written.  The main idea was to keepdocuments (such as this one), specs, logo
s and such from being covered.  If there are things that you think SHOULD be
covered that wouldn't be under this paragraph, let me know.


> can be sound samples.  The point being that the difference between code
> and data depends on your point of view, and that as technology is developed

Right, that's why we want to define a line between software and
data/non-software.  (We do include data that's part of the original software
package). That line can be shifted, if you have some suggestion.  One of the
entanglements we wanted to avoid here is the idea of "what is the source of a
spec-document or what is the source of a jpeg". 

> If we're going to have some kinds of files which can be redistributed
> without meeting these guidelines, I'd prefer to have them explicitly
> described -- and then we still need guidelines for what kind of license
> we expect on those files.
Yes.  We probably need something on non-software, too, but we'd have resolve
some of the questions like, "what is source".  That's one of the debates I
remember about GPL'd documents.

[re: the term use.  I got a little cut-happy]
> This gets confusing if you consider modification and distribution as
> forms of use.
The terms modification, distribution and derivation are all explicitly used. 
That *could* be stated somewhere but is it needed to be?

>> 2.2. Source Code 
>> -
>> 
>>  Source code must be freely available.
> 
> Is this a recursive reference to this document?

Not really.  We're trying to say "the user has to be able to get the source
without being charged."  Much of the rest of the document here that deals with
source code, states source code.

> [I think the point is that the source code for a DFSG-free executable
> must also be DFSG-free.  However, there's no definition for source code,
> so cases like the original source is compiled into unreadable C are
> going to be ambiguous.]

Sure there is... check the 4th section.

>> 3.1. Notices of Authorship 
>> ---
>>  >  current licenses?>
> 
> This seems to imply that the emacs license can't prohibit someone
> from removing its copyright display at load time.  [Because that's
> where the >>unmodified<< software displays copyrights.]
Umm that *could* be interpreted that way... I don't know the emacs license
so I can't comment beyond that.


>> 3.3. License of Derived Works 
>> --
>> 
>>  The license can require modified and derived software be distributed
>>  under the same license or the general requirement "any compatible
>>  license."
> 
> You might want to define "compatible".  [Remember how the old Qt license
> said it was compatible with the GPL, even though the converse wasn't
> true?]
I know.  This is the worse section of the document right now and we're all
still wrangling over it.

-- 
=
* http://benham.net/index.html <><  *
*  * -BEGIN GEEK CODE BLOCK- ---*
*Darren Benham * Version: 3.1   *
*  <[EMAIL PROTECTED]>  * GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++>*
*   KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS--   *
*   Debian Developer   * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++   *
*  <[EMAIL PROTECTED]>  * G++>G+++ e h+ r* y+*
*  * --END GEEK CODE BLOCK-- ---*
=


pgpaNUaRJvs9K.pgp
Description: PGP signature

Re: Proposal: increasing mirror security

[Bear Giles]

Jason wrote:
> 
> I would prefer to use the idea of a trusted site (like ftp.debian.org) to
> fetch package file MD5 summs from, that way we do not get involed with the
> sticky issue of cyrpto hooks.

What about:

1. Every package already contains MD5 checksum.

2. Each section contains two new files.  The first is a list
   of (package name, checksum, signer, signed checksum).  
   The signer would be the packager, who presumably already has 
   PGP/GPG.  The packager, in turn, would normally be the package 
   maintainer.  But this isn't necessarily always true, to the 
   system needs to be flexible enough to handle a more general case.

   The second file is list of (signers, public keys).  With
   offical packages, this list is already published in a package --
   something which must be considered "dirty" until we find some
   other way to verify it.  However we *could* sign this list by 
   a trusted public key which is available from a canonical site,
   e.g., ftp.debian.org.  This key should rarely change, so people 
   will rarely need to ping the site.
   
Authentication is then fairly simple:

1. Verify we have the current top-level public key, or download it.

2. Verify the signature on the list of signers with #1.

3. Verify the MD5 checksum signatures for each package with #2.

4. For each package, verify that the three MD5 checksums match.
   (Signed checksum, package checksum, and computed checksum).

   
This system has several benefits:

1. It eliminates the chokepoint of checking ftp.debian.org for
   all signatures and/or checksums.  It's entirely self-validating
   once you have that particular trusted key.

2. It only requires signatures by two parties.  Packagers,
   who are presumably entering their pass phrases already,
   and the list of signers.  That list would only change as
   maintainers are added or change their keys.

3. If you allow multiple top-level signers, it can support
   packages which use .deb format but aren't offical debian
   packages.  E.g., I've created "debian" packages at work
   to manage internal tools used by my employer.  These companies
   were small enough that everyone who used these packages knew me
   and could easily verify the package, but that's not true in 
   many packages. 
   
> and it requires that the clients
> know exactly which key to expect so changing keys becomes difficult.

More precisely, they need to know who did the signature.  Propogation
of changed keys is a separate problem which must be addressed in any
protocol.

> We are not very vunerable to the sort of attacks we have heard of, someone
> could go onto a mirror and could change a file and change the Packages
> file but they would have to do that every single day!

But how many people will download the packages in the meanwhile?

Bear Giles
[EMAIL PROTECTED]

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Erik Troan]

On Mon, 25 Jan 1999, Daniel Quinlan wrote:

> New systems would need to have a /var/spool/mail -> /var/mail symbolic
> link for about two years.

No, forever. Red Hat is promising an upgrade path for a lot longer then two
years -- we've already provided upgradeable distributions for 3.5.

Erik

---
|   "For the next two hours, VH1 will be filled with foul-mouthed,|
|  crossdressing Australians. Viewer discretion is advised."  |
| |
|   Linux Application Development  --  http://www.redhat.com/~johnsonm/lad|

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Erik Troan]

On Mon, 25 Jan 1999, Daniel Quinlan wrote:

> > Ten years.
> 
> Are you serious?  The Linux community has already made larger changes
> in far far less time.  We're talking about modifying one or two lines
> in 10 or 20 source packages (like src RPMs).

You seem to be ignoring the upgrade issue. Allowing in-place upgrades
necessetates /var/spool/mail to exist in some form.

Erik

---
|   "For the next two hours, VH1 will be filled with foul-mouthed,|
|  crossdressing Australians. Viewer discretion is advised."  |
| |
|   Linux Application Development  --  http://www.redhat.com/~johnsonm/lad|

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Daniel Quinlan]

Daniel Quinlan <[EMAIL PROTECTED]> writes:

>> New systems would need to have a /var/spool/mail -> /var/mail symbolic
>> link for about two years.

Erik Troan <[EMAIL PROTECTED]> writes:

> No, forever. Red Hat is promising an upgrade path for a lot longer then two
> years -- we've already provided upgradeable distributions for 3.5.

I said "new systems", not systems that are being upgraded.

> You seem to be ignoring the upgrade issue. Allowing in-place upgrades
> necessetates /var/spool/mail to exist in some form.

I'm not ignoring it, I just don't think it's a problem.

If today's in-place upgrades don't allow /var/spool/mail to be a
symbolic link, then they are broken.  The same would be true for
/var/mail on a system that still mounted the spool on /var/spool/mail.

Dan

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[H. Peter Anvin]

> >> New systems would need to have a /var/spool/mail -> /var/mail symbolic
> >> link for about two years.
> 
> Erik Troan <[EMAIL PROTECTED]> writes:
> 
> > No, forever. Red Hat is promising an upgrade path for a lot longer then two
> > years -- we've already provided upgradeable distributions for 3.5.
> 
> I said "new systems", not systems that are being upgraded.
> 
> > You seem to be ignoring the upgrade issue. Allowing in-place upgrades
> > necessetates /var/spool/mail to exist in some form.
> 
> I'm not ignoring it, I just don't think it's a problem.
> 
> If today's in-place upgrades don't allow /var/spool/mail to be a
> symbolic link, then they are broken.  The same would be true for
> /var/mail on a system that still mounted the spool on /var/spool/mail.

I think interoperability requires that they be compatible as long as
possible, preferrably indefinitely.  I would suggest:

1. REQUIRE /var/mail and /var/spool/mail to both exist, and be
   aliases.
2. RECOMMEND future use of /var/mail throughout.
3. DEPRECATE the use of /var/spool/mail.

I don't see a need for abolishing the link /var/spool/mail any time
soon; it has to remain reserved namespace indefinitely anyway.

-hpa

Re: Uploaded lilo 21-3.1 (source i386) to master [NMU]

[Bernd Eckenfels]

thanks for the NMU without asking the maintainer FIRST, AGAIN :-///

Note: the last upload of this package was last month and there is no reason
for a quick uplaod since there are no critical warnings pending for FROZEN.

Thanks for the patches anyway, I will include them in my working copy. Would
be better if you mailed them to me DIRECTLY.

Greetings
Bernd

On Mon, Jan 25, 1999 at 12:17:29AM +0100, Vincent Renardias wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> 
> Format: 1.5
> Date: Sun, 24 Jan 1999 21:38:58 +0100
> Source: lilo
> Binary: lilo lilo-doc
> Architecture: source i386
> Version: 21-3.1
> Distribution: unstable
> Urgency: low
> Maintainer: Vincent Renardias <[EMAIL PROTECTED]>
> Description: 
>  lilo   - LInux LOader - The Classic OS loader can load Linux and others
>  lilo-doc   - LInux LOader - The Classic OS loader can load Linux and others 
> [d
> Changes: 
>  lilo (21-3.1) unstable; urgency=low
>  .
>* NMU to fix the bug #7570 I reported on Feb 22nd 1997
>  (include real doc instead of the TeX source).
>* Include manpage for activate (Bug #10526,#8641).
>* Include manpage for keytab-lilo.pl (Bug #10526).
>* Add a link to undocumented.7.gz for liloconfig which has
>  no manpage.
>* Close #20049 (This functionality is handled by syslinux,
>  not lilo).
>* Fork a lilo-doc package to include the Postscript documentation.
>* Have lilo Suggests: lilo-doc.
>* Set severity of bug #29987 to fixed: When lilo.conf contains a passwd
>  and is not mode 600, it displays a proheminent warning.
>* Set severity of bug #7629 to fixed: This is a perfectly legal option,
>  given that the Debian policy is not to install lilo in the MBR by
>  default.
>* Reassign bugs #5198, #8280 and #10526 to the package manpages since
>  this is where lilo.8 lives. (Does anybody know why BTW?!)
>* Put some (hopefully) usefull comments in the default lilo.conf
>  (Fix bug #25174).
>* Include Adam Heath <[EMAIL PROTECTED]>'s patch to add the new
>  BOOT_VAR variable (Fix bug #30458).
>* lintian cleaned:
>  - fix typo. in description.
>  - don't install QuickInst with executable bit set.
>  - include lilo.8 manpage (will open a BR on manpages so it
>  doesn't provide it anymore).
>* Correct the lilo.8 manpage (Fix bug #5198) with patch from BR #10526.
> Files: 
>  40be6e4910897d85051edc21d1b42d17 614 base important lilo_21-3.1.dsc
>  4e19bc93778d23b5c234127ea286ea08 17002 base important lilo_21-3.1.diff.gz
>  91da175d22cfd666eefd8f547000ea75 179936 base important 
> lilo-doc_21-3.1_i386.deb
>  36d959ea87abd3da095b0ef27ee5c6e4 100844 base important lilo_21-3.1_i386.deb
> 
> -BEGIN PGP SIGNATURE-
> Version: 2.6.3ia
> Charset: noconv
> 
> iQCVAwUBNquojw+bo1sI1mwpAQEIMAP/Rr54+FM5tjJe5hm3/SgRSOJ9MR3WLxXU
> kGagCGV2/eWNaxUPa/w/kzePhBvNHyFZGTqM85BIN4r9h7BpoDQfFIuBEI9p1EeL
> GUpUeJ0uui7bUI7VixopcDCGUfmvq5HcJClcHRPbhUoxTUoXlVem2JWiuIhLzhPw
> P+Lq/yKzTHc=
> =BgRf
> -END PGP SIGNATURE-
> 
> 
> 

-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: DFSG v2 Draft #5

[Darren Benham]

On 25-Jan-99 Gregor Hoffleit wrote:
> On a separate note, since this started the discussion about this point,
> (I must sound like an advocatus diaboli ;-): What happened if the Zope
> people would replace their "attribution button" with a copyright notice,
> and modified Zope so that this notice (e.g. "Zope Copyright (C) 1999
> Digital Creations, www.zope.org") would be displayed on the first page of
> every session ? Couldn't they use a similar clause like the GPL to 
> reject any modification of Zope that would remove this copyright notice ?
> Zope is certainly a program that "reads commands interactively when run",
> so they could mostly copy this requirement from the GPL.

As long as Zope put the notice in automagicly... heck, the button would
probably be acceptable as long as it was put in automaticly.


-- 
=
* http://benham.net/index.html <><  *
*  * -BEGIN GEEK CODE BLOCK- ---*
*Darren Benham * Version: 3.1   *
*  <[EMAIL PROTECTED]>  * GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++>*
*   KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS--   *
*   Debian Developer   * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++   *
*  <[EMAIL PROTECTED]>  * G++>G+++ e h+ r* y+*
*  * --END GEEK CODE BLOCK-- ---*
=


pgp4AGvho8MeE.pgp
Description: PGP signature

LSH (GPL'd SSH)

[Ben Collins]

I've just looked over some of the code for the latest LSH snapshot
(1-21-99) and it seems to be turning into a decent program. It is lacking
some critical features (listed below), but once they are implemented, we
may want to consider this our ssh replacement (the final blow to the
non-free software we use, after qmail and pgp are gone).

I'm wondering if some of our non-US developers could assist in the project
since we have a vested interest in it's completion. I myself am going to
start providing patches to what I am legally allowed to send them (from
the US) which means no crypto code for me to hack (let's not break into a
crypto law discussion please).

The URL for the site is:
http://www.net.lut.ac.uk/psst/

Mailing list subscription and archives:
[EMAIL PROTECTED]
http://www.roads.lut.ac.uk/lists/psst/

This is a quick list of what I can see that LSH needs to have in order for
us to start using it (that it doesn't have now, but they plan on
implementing):

1) Better key generation tools
2) Key-Auth support
3) pty allocation (currently no tty is allocated, which means you can exec
commands, but you get no controlling terminal).
4) Scp type wrapper

There's probably alot more that they could use help on, but these stuck
out to me as priority tasks (their agenda may be different, but by their
mailing list archives, they were very open to any patches that helped).

NOTE: For those that are on the ball, they do seem to be considering
removing idea from the base source and having it as a seperate module
(similar to GnuPG's approach).

Thanks,
  Ben

-- 
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED]
-- -- - - - ---   --- -- The Choice of the GNU Generation

Re: Reality check! [was: Re: Debian goes big business?]

[Craig Sanders]

On Sat, Jan 23, 1999 at 08:00:06PM +0100, Paul Seelig wrote:
> On Sat, 23 Jan 1999, Steve Shorter wrote:
> 
> > Since when has the purpose of debian been to appease the interests
> > of the mass of unskilled consumers? There are lots of dists that are
> > trying to do that. I'm sure they will do a good job of introducing
> > newbies to Linux. But I never thought that was the purpose of
> > Debian.
>
> Please don't let's start *this* kind of discussion yet again.  It's
> *not* about appeasing to the masses of unskilled consumers.  It's
> about increasing ease of installation, use and maintenance.

installing debian could be made a little easier and faster - mostly by
having non-interactive installs.

how, exactly, do you think that it could be made easier to use and
maintain?

i hope you haven't fallen for the myth that a GUI config is inherently
easier than a text file config, because that is simply not true.  GUI
configuration tools are simpler for simple tasks but range from harder
to impossible when it comes to more complex tasks.

(note i said "simpler" and not "easier". they're not the same thing -
simpler does not always mean easier)

this is inherent in the nature of simplified GUI configuration tools
- they achieve their simplicity by constraining the range of choices.
if the GUI programmer hasn't thought of and written a dialog for a
particular configuration then it can't be done.

even worse: all of the linux/unix gui config tools that i have looked at
will lose valuable information from hand-crafted configuration files.


> Skilled people definitely benefit from such time saving aspects in
> their daily jobs.  Even professionals don't want to always have to
> deal with things which explicitly require a professional.  Excellence
> in design doesn't necessarily have to result in awkwardness.

'awkwardness' is subjective. for configuring a program, i find
anything other than editing a well-commented text file with vi to be
extremely awkward and difficult, especially when the machine i am
configuring is at the other end of a flooded modem or isdn link. 

i don't want to have to take my hands off the keyboard and click on
half-a-dozen OK buttons or icons or dialog boxes just to change one
little thing in a config file. i want to be able to comment out certain
parts of the configuration while trialling new options or to leave them
in there as documentation/historical record.


> The fact that even the "mass of unskilled consumers" benefit from this
> is a completely different issue.

"make a system easy enough for an idiot to use and only an idiot will
want to use it"

there are other dists which cater quite well to the "mass of unskilled
consumers". debian caters well for the skilled and for those who are
willing to learn.

debian should make it easier to learn, and therefore easier to make the
transition from unskilled newbie to skilled systems administrator - but
it should do this with good documentation and wrapper scripts where
necessary (e.g. stuff like sendmailconfig and to a lesser extent, the
fmirror config wrapper that i wrote)

> The point is that what's good for unskilled people can be equally good
> for skilled people who no by themselves how to provoke trouble if they
> really want it. ;-)

i find that very very hard to believe. what is good for unskilled people
is to constrain their options so that they don't get overwhelmed by new
information and the multitude of choices available. that is NOT good for
skilled people...in fact, it is extremely annoying and frustrating.


> > Debian IMHO should be aimed toward the skilled technical user and
> > those who are already Linux skilled. There is no other dist that is
> > trying to fill this role. [ ... ]
>
> Where's the problem (other than that *you* don't care) to make Debian
> comfortable even for "the skilled technical user"?  Hey, i'm skilled
> enough to handle all this stuff but it would be *really* nice if i
> wouldn't need to have to be skilled to be able to to certain standard
> tasks which should rather be automated.

then write scripts to automate them. if your scripts are good enough
and of general use then submit them to the maintainer of the relevant
packages(s). problem solved.

i haven't yet had a debian developer reject any of the wrapper scripts
that i have written to automate or simplify administration tasks. all
have been more than happy that someone else is willing to do some work
to make their package even better. the trick is to write your contrib
stuff so that it works for you, and then re-write it so that it is
generally useful for a lot of people...then submit it to the package
maintainer.

that may seem like a lot of extra work, just to use a package...but in
many cases, it's a lot LESS work than re-implementing your custom stuff
every time a package is upgraded. that's a strong incentive to share
your improvements.



> Yes, i've learned my share and now what?  Do i still have to use a
> system which lets me explici

Re: Uploaded lilo 21-3.1 (source i386) to master [NMU]

[Vincent Renardias]

On Mon, 25 Jan 1999, Bernd Eckenfels wrote:

> thanks for the NMU without asking the maintainer FIRST, AGAIN :-///

No problem, I will mail you next time.

> Note: the last upload of this package was last month and there is no reason
> for a quick uplaod since there are no critical warnings pending for FROZEN.

1/ I reported 2 years ago a bug (#7570) that could be fixed in 5
minutes and just got bored to wait.

2/ lilo also had ~10 other bugs that could be easily fixed and since lilo
is such a critical part of the Debian system it should be as bugfree as
possible.

3/ In march 98, Peter Maydell took the time to write nice manpages
for activate(8) and keytable-lilo.pl(8). Not having taken 3 minutes to
include them in 9 months is just plainly unjustified and disrespects his
work.

I considered these 3 points as a good reason to make an upload.

> Thanks for the patches anyway, I will include them in my working copy. Would
> be better if you mailed them to me DIRECTLY.

I usually wait for the package to be installed to send the NMU patch to
the Bug Tracking System which is why you haven't got it yet.

> Greetings
> Bernd
> 
> On Mon, Jan 25, 1999 at 12:17:29AM +0100, Vincent Renardias wrote:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > 
> > Format: 1.5
> > Date: Sun, 24 Jan 1999 21:38:58 +0100
> > Source: lilo
> > Binary: lilo lilo-doc
> > Architecture: source i386
> > Version: 21-3.1
> > Distribution: unstable
> > Urgency: low
> > Maintainer: Vincent Renardias <[EMAIL PROTECTED]>
> > Description: 
> >  lilo   - LInux LOader - The Classic OS loader can load Linux and others
> >  lilo-doc   - LInux LOader - The Classic OS loader can load Linux and 
> > others [d
> > Changes: 
> >  lilo (21-3.1) unstable; urgency=low
> >  .
> >* NMU to fix the bug #7570 I reported on Feb 22nd 1997
> >  (include real doc instead of the TeX source).
> >* Include manpage for activate (Bug #10526,#8641).
> >* Include manpage for keytab-lilo.pl (Bug #10526).
> >* Add a link to undocumented.7.gz for liloconfig which has
> >  no manpage.
> >* Close #20049 (This functionality is handled by syslinux,
> >  not lilo).
> >* Fork a lilo-doc package to include the Postscript documentation.
> >* Have lilo Suggests: lilo-doc.
> >* Set severity of bug #29987 to fixed: When lilo.conf contains a passwd
> >  and is not mode 600, it displays a proheminent warning.
> >* Set severity of bug #7629 to fixed: This is a perfectly legal option,
> >  given that the Debian policy is not to install lilo in the MBR by
> >  default.
> >* Reassign bugs #5198, #8280 and #10526 to the package manpages since
> >  this is where lilo.8 lives. (Does anybody know why BTW?!)
> >* Put some (hopefully) usefull comments in the default lilo.conf
> >  (Fix bug #25174).
> >* Include Adam Heath <[EMAIL PROTECTED]>'s patch to add the new
> >  BOOT_VAR variable (Fix bug #30458).
> >* lintian cleaned:
> >  - fix typo. in description.
> >  - don't install QuickInst with executable bit set.
> >  - include lilo.8 manpage (will open a BR on manpages so it
> >  doesn't provide it anymore).
> >* Correct the lilo.8 manpage (Fix bug #5198) with patch from BR #10526.
> > Files: 
> >  40be6e4910897d85051edc21d1b42d17 614 base important lilo_21-3.1.dsc
> >  4e19bc93778d23b5c234127ea286ea08 17002 base important lilo_21-3.1.diff.gz
> >  91da175d22cfd666eefd8f547000ea75 179936 base important 
> > lilo-doc_21-3.1_i386.deb
> >  36d959ea87abd3da095b0ef27ee5c6e4 100844 base important lilo_21-3.1_i386.deb
> > 
> > -BEGIN PGP SIGNATURE-
> > Version: 2.6.3ia
> > Charset: noconv
> > 
> > iQCVAwUBNquojw+bo1sI1mwpAQEIMAP/Rr54+FM5tjJe5hm3/SgRSOJ9MR3WLxXU
> > kGagCGV2/eWNaxUPa/w/kzePhBvNHyFZGTqM85BIN4r9h7BpoDQfFIuBEI9p1EeL
> > GUpUeJ0uui7bUI7VixopcDCGUfmvq5HcJClcHRPbhUoxTUoXlVem2JWiuIhLzhPw
> > P+Lq/yKzTHc=
> > =BgRf
> > -END PGP SIGNATURE-
> > 
> > 
> > 
> 
> -- 
>   (OO)  -- [EMAIL PROTECTED] --
>  ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
>   o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
> (OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
> 

-- 
- Vincent RENARDIAS  [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux:   http://www.openhardware.orgLogiciels du soleil: -
- http://www.fr.debian.orgOpen Hardware: http://www.ldsol.com -
---
-"Microsoft est à l'informatique ce que le grumeau est à la crépe..." -

Re: Reality check! [was: Re: Debian goes big business?]

[Craig Sanders]

On Sat, Jan 23, 1999 at 07:14:35PM +, thomas lakofski wrote:

> As an experienced Debian user, I'll second these sentiments.  Since
> buzz I've been waiting for the Debian installation process to become
> a (as it should be) 30 minute process, hopefully with some tools
> included for mass installations.  I use Debian myself exclusively but
> have to hesitate before recommending it to others new to Linux because
> the process of getting started is harder than it should be.

improvements can certainly be made in the rescue-disk install scripts. i
think everyone agrees that they're not perfect.

however, the biggest problem is not a matter of easy vs hard. it is a
matter of scale. it takes a long time to run dselect when there are over
2000 packages in debian.

for mass production of machines, there are tools which can make that
faster (see my reply to paul for a summary of the process i use).

> I also am disappointed with the attitude of some people towards making
> these things easier to do.  Is it some kind of techno-snobbery, maybe?

i think it's more practicality than snobbery.

there aren't any 'easy' configuration tools which don't achieve their
simplicity at the price of flexibility.

> Making things easier does not necessitate dumbing-down things for more
> competent users.

if you, or anyone else, can implement an easier way without dumbing
things down then it will be received very happily. unfortunately, nobody
has yet come up with such a thing.

> Once up and running, a Debian system is far more maintainable than the
> alternatives -- a great factor in on-going ease of use.

agreed. and one of the reasons that debian is more maintainable is
because we haven't taken the easy way out and replaced text-file
configuration with semi-adequate gui/menu-based configuration.


> Can some focus be brought to getting there with similar ease?  I've
> been with Debian for over 2 years now and would be sad to have to
> abandon it in the long run because of 'we don't do that' politicking
> instead of pragmatism amongst developers.

there's two sides to that coin. debian's way is to do it Right.  To do
something right is hard, a lot harder than doing it wrong.

i would like it if debian had a "right" solution to easier configuration
(and for some packages we do...look at sendmailconfig for example)...but
i would much rather nothing than doing it wrong.

implementing a bad "solution" now would make it much more difficult
(nearly impossible) to migrate to a good solution in the future.

craig

--
craig sanders

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Theodore Y. Ts'o]

I keep hearing people claim that distribution folks are saying "ick",
but I haven't heard any technical reasons besides, "Moving spool
directories is hard".  When I and others have pointed out that moving
the spool directory isn't required; just a symlink, I have heard dead
silence.  So the lack of technical discussion, but just a stony-silence
"No!" is rather disappointing as far as I'm concerned.

I think we should require that new applications use /var/mail, and that
backwards compatibility symlinks should exist.

If we must back out /var/mail (for no good technical reason that I can
determine), then at the very least I think we should state that there
that for all compliant distributions, /var/mail *MUST* be a valid way of
reaching the spool directory (i.e., there should be a symlink there, or
where the spool directory actually lives) and that it be permissible for
applications to use /var/mail to find the mail directory (but that
applications that want to keep using /var/spool/mail would not be
considered obsolete).

At least that way applications that want to use the same dirctory as the
vast majority of other Unix systems will work without needing a special
case for Linux.  However, I would much rather see us adopt the full,
correct solution, rather than this half-measure.

- Ted

Re: Proposal: increasing mirror security

[Wichert Akkerman]

If people really want to be able to verify package integrity we might as
well go the whole way. Ian Jackson posted (1.5 years ago I think) a
proposal that would secure the complete stage from building a package to
distribution on the mirrors.

You might want to look that up in the list archives.

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpFq7sZVNzcv.pgp
Description: PGP signature

Re: Proposal: increasing mirror security

[Brandon Mitchell]

On Mon, 25 Jan 1999, Lalo Martins wrote:

> Sounds good, as long as I can shut it off :-) Also, it should
> use the keyring in developers-keyring or one that comes with
> apt, otherwise the point is moot (anyone who can upload a .deb
> with a trojan can upload a Packages.pgp with a signature)

The only person that can upload a Packages.pgp file is the mirror 
maintainer.  The explination is below.

> > This would require: a) gnu's version of pgp to work (so that we
> > don't request non-free software to get the free software)
> 
> Here we go again. This would have the problem of requiring all
> developers to switch to gpg.

I definately messed up this point, the only thing that is signed is the
_packages file_, not the individual packages.  The only person with gpg is
the mirror maintainer.  Actaully, as long as gpg is compatable with pgp,
that doesn't even matter and the apt user simply picks what they want to
install.

> > and the bad part b) someone to be at the console when
> > generating packages files to type the pgp password.
> 
> Huh? You don't need the passphrase to verify signatures.

Not verify, create.  The pgp signature is for the packages file, not the
developers packages themselves.  This just means the process of moving
files from incoming to the tree needs to have a person at the console
because after the file is moved and the Packages and Packages.gz file are
created, the Packages file needs a pgp signature stored in Packages.pgp.
A less secure version would be to have the Packages.pgp file generated
automatically.

Sorry about the confusion,
Brandon

+---  ---+
| Brandon Mitchell * [EMAIL PROTECTED] * http://bhmit1.home.ml.org/ |
| The above is a completely random sequence of bits, any relation to |
|   an actual message is purely accidental.  |

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

[Kragen Sitaker]

On Mon, 25 Jan 1999, Erik Troan wrote:
> On Mon, 25 Jan 1999, Daniel Quinlan wrote:
> 
> > New systems would need to have a /var/spool/mail -> /var/mail symbolic
> > link for about two years.
> 
> No, forever. Red Hat is promising an upgrade path for a lot longer then two
> years -- we've already provided upgradeable distributions for 3.5.

. . . which is good, because there are probably many people out there
like me who have something approximating Red Hat 3.2 systems from
secondhand CDs.

Ten or fifteen years is probably reasonable.

Interfaces should stay fairly stable.

Has anyone compared Linux's signal.h (the one that actually lists the
signal numbers) to the signal.h from Version 6 Unix for the PDP-11?
There are 22 years of difference, but it looks like about a year.  :)

-- 
<[EMAIL PROTECTED]>   Kragen Sitaker 
Computers are the tools of the devil. It is as simple as that. There is no
monotheism strong enough that it cannot be shaken by Unix or any Microsoft
product. The devil is real. He lives inside C programs. -- [EMAIL PROTECTED]

DFSG: list restrictions, not freedoms

[Chris Waters]

Rather than attempt to list all the freedoms that Debian guarantees, why
not list the *restrictions* on freedom that we do allow, and say that
any other restrictions violate our guidelines.

IOW, instead of saying, "we allow this, we forbid this, we allow
this...", simply say, "we forbid all restrictions except these"

No need to mention, e.g., discrimination; if it's not a listed
restriction, it's an unacceptable restriction.

A preliminary outline of acceptable restrictions:

1.  Credit where credit is due.  (copyright notices, etc.)
2.  Continued freedom ((L)GPL, MPL, QPL, etc.).
3.  Identity (artistic)
4.  "Non-contaminating" non-commercialism (artistic)
5.  Integrity ("patch-clause" -- deprecated)

These obviously need to be fleshed out and pinned down a little.  Number
one needs to be chopped off somewhere around (either including or
excluding) the terms of the BSD license.  And we can drop the patch
clause if desired.  But I think this approach of listing acceptable
restrictions on our freedoms is probably the most clear.  I think it
might help make the DFSG brief and to-the-point.

Comments?
-- 
Chris Waters   [EMAIL PROTECTED] | I have a truly elegant proof of the
  or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.