Re: plagiarism of reiserfs by Debian

[Henrique de Moraes Holschuh]

On Sat, 19 Apr 2003, Travis Crump wrote:
> all that was removed was *code* that gets compiled.  If the maintainer 
> cannot arbitrarily change any code he wants, then it is not clear that 
> the program is DFSG-free.

THEN it is not DFSG-free, and needs to be dropped from Debian, or upstream
needs to change the copyright.

Note that I am NOT talking about reiser* here, I didn't check it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Bug#189566: amavisd-new: bad interaction with package amavis-ng

[Henrique de Moraes Holschuh]

On Sat, 19 Apr 2003, Ernst Kloppenburg wrote:
> yes. So maybe one of the packages should have its amavisd renamed.

I have no problem with that (heck, it is a daemon). But this does not
solve the entire Debian-wide problem that the amavis-* packages hit.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Bug#189566: amavisd-new: bad interaction with package amavis-ng

[Henrique de Moraes Holschuh]

On Sun, 20 Apr 2003, Brian May wrote:
> On Fri, Apr 18, 2003 at 08:51:51PM -0400, David B Harris wrote:
> > Share an initscript between them, if that's possible?
> 
> No, that would cause more problems trying to rename
> the existing amavisd-new conffile.

Agreed.  This is not something we should be doing at all.

This is actually a big, ugly mess, for which the only sane alternative
is to have a package-specific binary for amavisd-new or amavis-ng (actually,
if we're going to do it the proper and fix-the-damn-thing-once-and-for-all
way, ALL amavis packages).

It is also a damn hole in Debian policy.  That one I will propose a fix
to:  scripts that are conffiles MUST test if the package is in the installed
state, and that test MUST either be done by checking for the presence of a
*file* (and no other filesystem object!) that is specific for that package
only in the entire distribution, or by querying the packaging system.

We really should have a very fast script to query if a package is installed.

> lrwxrwxrwx root/root 0 2003-04-06 05:15:36 ./usr/sbin/amavisd -> 
> ../bin/amavis
> 
> Why is this symlink required?
> 
> Why does amavis-ng need to have two names?

Looks like amavis-ng has both the amavis client and server functionalities
built-in the same executable. If it "decides" what it should be doing based
on its calling name...

Anyway, yuck. I am glad I am using and co-maintaining amavisd-new now :)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: old lib still needed

[Junichi Uekawa]

> I am curious, how are we (err, Debian) supposed to deal with old
> libraries? I have been using uvscan by NAI, and aside from its being
> non-free it unfortunately depends on libstdc++ 2.8, which was previously
> available through the package libstdc++2.8_2.90.29-2.deb. This doesn't
> seem to be available anywhere now, for which reason I am hanging on to
> my local copy.

It should be possible to obtain copies from previous releases,
like Debian 2.2, or 2.1.
As far as I know, 
Debian 2.2 is available through normal mirrors still, and 
Debian 2.1 is available at archive.debian.org.

It is difficult to maintain old copies since tools evolve, and 
most old libraries now don't build from source on current Debian systems,
depending on some special behavior of old compilers, etc.


regards,
junichi

Re: plagiarism of reiserfs by Debian

[Glenn Maynard]

Trimmed CC: little; I can't imagine why this should go to -testing ...

On Sun, Apr 20, 2003 at 02:49:36AM +0200, Marcel Weber wrote:
> All I can say to this is: use what you like, resp. if you don't like 
> bloated software or spamware do not use it. My point is, that it should 
> be a right of the original authors of the software to include credits. 
> If someone else does a complete rewrite of the software, okay than we 
> can discuss it, but if the rewrite means only the removal of the 
> credits it is questionable.

This is irrelevant.  We're not questioning whether Hans Reiser has the
right to license his own software to prohibit the removal of large
messages.  The questions being asked are:

1. Is software licensed in the manner Hans intends DFSG-free?  That is,
is it DFSG-free to require that interactive programs output a full
page of sponsorship information?  (That's a question for debian-legal.)
If not, it can not be distributed in Debian and will be relegated to
non-free.

2. Is the software licensed consistently?  If not, it's probably not
legally safe to distribute at all, and will be removed entirely unless
Hans clarifies the licensing.

Another question that comes to mind: has ReiserFS used code from projects
licensed under the GPL?  If so, he can not, in fact, place this extra
restriction, as it would be in violation of GPL clause 6.  This isn't a
special issue for programs under completely different licenses; they know
they're not GPL-compatible and don't use GPL code.  However, when people
use "modified" GPL licenses, they often don't realise that they can no
longer use code from other GPL projects.

> But first of all, before we continue this discussion: What exactly has 
> been removed? A readme file, the outputs during boot time, the outputs 
> of mkfs.reiserfs? Has this output any impact on the usability of the 
> software, so that there were good reasons the remove it? Has the 
> license been violated by removing the credits?

It's been suggested that the removed message is the one referenced in
this bug report:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=152547

Impact and "good reasons" don't matter.  Debian requires that users be
granted the right to do certain things regardless of whether they have
"good reasons".  If Hans doesn't want to grant those rights to users,
that's may be his choice, but Debian won't distribute his software.

-- 
Glenn Maynard

Re: plagiarism of reiserfs by Debian

[Branden Robinson]

On Sun, Apr 20, 2003 at 01:24:09AM +0200, Wouter Verhelst wrote:
> Op za 19-04-2003, om 22:51 schreef Lukas Geyer:
> > the issue seems to be the fix of #152547. If we are not allowed to
> > remove a screenful of advertising from the output of a program, then
> > this unduly restricts the freedom to distribute modified versions.
> 
> Uhm.
> 
> From the GPL, section 2:
> 
> 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.)
> 
> Otherwise put: if the program shows the 'no warranty' clause from the
> GPL at startup, you may not remove it. Although a 'no warranty' message
> is certainly not the same as a list of sponsors, they both require some
> messages being printed for legalese reasons. I, personally, see nothing
> wrong with that; it certainly doesn't result in software being non-free.

I disagree.  Some people on the debian-legal list feel that GPL 2c is
only barely tolerable from a DFSG-freeness standpoint, and some also
feel that it is ambiguously worded (see the debian-legal archives for
the gory details -- it's in the "PHPNuke license" thread, which is
huge).

GPL 2c only requires the presence of a copyright notice, warranty
disclaimer, notice that the work is licensed under the GNU GPL, and
instructions on how to view the license text.

A list of sponsors is none of these.  Preservation of such is not
required by the GNU GPL itself.  Therefore this material can be removed
under the permissions granted in section 2.  If such a restriction is de
facto being imposed by the copyright holder, then the work is not
actually licensed under the GPL, but rather the GNU GPL plus extra
restrictions, and as a result is not GPL-compatible.  If the work
dynamically links to or otherwise incorporates other copyright holders'
GPLed works, then as a consequence of section 7 of the GNU GPL, Debian
cannot distribute this work *at all*.  Not even in non-free.

Of course, to put this discussion in proper perspective, given some of
the provisions of the "GNU Free Documentation License"[1], it may be
that a future version of the GNU GPL permits copyright holders to compel
the display of arbitrary amounts of material on program startup.  GNU
Emacs, for instance, may be altered to display the GNU Manifesto in the
scratch buffer at startup, and it may be against the terms of this
future version of the GNU GPL to defeat this behavior.  So, the sort of
thing the author of the work in question is doing may actually be
perceived by the FSF as a good thing, and future versions of their
licenses may not only support it, but encourage it.

If all of this sounds surprising to people on debian-devel, I suggest
they subscribe to, or review the archives of, the debian-legal mailing
list.

[1] http://www.gnu.org/copyleft/fdl.html

-- 
G. Branden Robinson|  We either learn from history or,
Debian GNU/Linux   |  uh, well, something bad will
[EMAIL PROTECTED] |  happen.
http://people.debian.org/~branden/ |  -- Bob Church


pgp61cPNX1LUi.pgp
Description: PGP signature

GDM is ancient version

[Juhapekka Tolvanen]

Package: gdm
Version: 2.2.5.5-2


That version of gdm is fscking ancient! maintainer of that package
really needs a clue. I got version 2.4.1.3-1woody1 with these apt-lines:

deb 
http://ftp.acc.umu.se/mirror/mirrors.evilgeniuses.org.uk/debian/backports/woody/
gnome2.2/
deb http://mirror.raw.no/ gnome2.2/


-- 
Juhapekka "naula" Tolvanen * * http colon slash slash iki dot fi slash juhtolv
"Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur,
adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et
dolore magnam aliquam quaerat voluptatem."  Cicero

Re: Do we need policy changes?

[Junichi Uekawa]

> >> Thank you for your time, and you want to tell me I'm paranoid, don't
> >> bother, it is not worth your time :) Better tell me what I might have
> >> missed in the observing the subject.
> AS> A point. What *is* yours?
> 
> The point is actually that debÑan (and others) doesn't care much about
> internationalization, no matter what they say. I'm just trying to be
> diplomatic,înot to risk a 'Do It Yourself' Answer. I'd like to have
> solutions.
> 

That's a very interesting answer.
At least I do care about internationalization, and I do 
some work on that respect; and it has been improving.

At least, Japanese support has become very good.



regards,
junichi

gap4 is huge - how to split?

[Peter van Rossum]

Gap4 is a computer algebra system, specifically designed for working
in group theory. The version in Debian is slightly out of date
and orphaned; I have posted an ITA earlier today.

Gap4 is quite big and I could use some advice on how to split it up.

Upstream, gap4 (version 4.3) is distributed in two tar-balls, currently
gap4r3.tar.gz (47Mb) and fix4r3n4.tar.gz (1.1Mb). The second one basically
contains patches. (There are also contributed packages for gap; I'll see
if it is worthwhile to distribute those as well.)

In Debian, gap4 (version 4.2) is currently distributed as 6 source packages
giving 8 binary packages:

gap4 (4.4Mb) (giving binary packages gap4 (3.8Mb), gap4-gac (2.0Mb), 
gap4-test (0.2Mb)) gap4-doc-dvi (1.1Mb), gap4-doc-html (0.8Mb),
gap4-doc-ps (2.1Mb), gap4-gdat (16.7Mb), gap4-tdat (6.8Mb).

(As an aside, if you sum the sizes of all the source packages, you
only get to 31.9Mb. I don't know yet if gap really grew by 15Mb from
version 4.2 to version 4.3 or if something else is going on).

The reason for this splitting up is, I think, that whenever there is an
upstream bug fix release, the huge tables (in -gdat and -tdat) and the
documentation is unlikely to change.

However, looking through the bugfixes for version 4.3, this seems to be false.
Well, the documentation didn't change, but the tables did.

So I'm inclined to simplify packaging by making only a single source
package (and still the same binary packages - the tables and the documentation
are architecture independent, of course). This would mean superfluous uploads
of the documentation binary packages whenever upstream has a bug fix
release, but those are relatively small. The tables would have to be
renewed anyway, it seems.

Can anyone think of a reason why I shouldn't do this?

Peter van Rossum <[EMAIL PROTECTED]>

Re: old lib still needed

[Federico Sevilla III]

On Sun, Apr 20, 2003 at 05:15:23AM +0300, Juhapekka Tolvanen wrote:
> % netscape
> netscape: error while loading shared libraries:
> libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file
> or directory
> 
> That is Netscape 4.8 and I still need it to testing my WWW-pages.
> 
> In testing and unstable that file is inside none of those packages. In
> stable (Woody) it is in package called "libstdc++2.9-glibc2.1". So,
> please, include that package in next version of Debian, too.

I am curious, how are we (err, Debian) supposed to deal with old
libraries? I have been using uvscan by NAI, and aside from its being
non-free it unfortunately depends on libstdc++ 2.8, which was previously
available through the package libstdc++2.8_2.90.29-2.deb. This doesn't
seem to be available anywhere now, for which reason I am hanging on to
my local copy.

I know it would be ideal for users like myself to convince NAI to use an
acceptably recent version of libstdc++, but I just thought I'd wonder
out loud if there's anything we can do to provide old libraries in
Debian for poor folk who have to use software like NAI uvscan.

 --> Jijo

-- 
Federico Sevilla III  : http://jijo.free.net.ph  : When we speak of free
Network Administrator : The Leather Collection, Inc. : software we refer to
GnuPG Key ID  : 0x93B746BE   : freedom, not price.

Re: plagiarism of reiserfs by Debian

[Craig Dickson]

Chris Cheney <[EMAIL PROTECTED]> wrote:

> First of all emacs is pure bloat so who cares what it does...

Don't be an ass. There are a lot of people who would say the same of
KDE, so it's silly for one of the main Debian KDE maintainers to be
saying such a thing.

Craig

Re: Proposed handling of generated configuration files (Re: stop the "manage with debconf" madness)

[Matt Zimmerman]

On Sun, Apr 20, 2003 at 04:11:29AM +0200, Tore Anderson wrote:

>   I fully agree that as many questions as possible should be asked before
>   unpacking the package.  And I also agree it would better if the "replace
>   the configuration file" questions also came at that point of the
>   upgrade, but unfortunately, that isn't the status quo.
> 
>   dpkg asks for permission to overwrite conffiles *after* having unpacked
>   the package in question -- and therefore you cannot dist-upgrade 300
>   packages, answer all questions, then take lunch and expect it to be
>   finished when you're back.  The upgrade will most likely stop after
>   unpacking a package with a new conffile.

While this is true, it isn't inherent in the design.  conffile prompting
could presumably be moved to the preconfiguration stage with relative ease.
With dynamically generated configuration files, this is impossible for all
but the simple substitution case.

-- 
 - mdz

old lib still needed

[Juhapekka Tolvanen]

% netscape
netscape: error while loading shared libraries:
libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file
or directory

That is Netscape 4.8 and I still need it to testing my WWW-pages.

In testing and unstable that file is inside none of those packages. In
stable (Woody) it is in package called "libstdc++2.9-glibc2.1". So,
please, include that package in next version of Debian, too.


-- 
Juhapekka "naula" Tolvanen * * http colon slash slash iki dot fi slash juhtolv
"Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur,
adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et
dolore magnam aliquam quaerat voluptatem."  Cicero

Re: Proposed handling of generated configuration files (Re: stop the "manage with debconf" madness)

[Tore Anderson]

* Tore Anderson

 >>  I see your problem when you insist on asking on asking all questions
 >>  at the configure stage -- personally, I don't think delaying the actual
 >>  generating of the configuration file (and asking the question about
 >>  overwriting the old file) to the postinst stage is *that* bad.

* Matt Zimmerman

 > This is the sort of input that I was soliciting.  Personally, I think that
 > preconfiguration is very important, since it _greatly_ simplifies initial
 > installation and upgrades (where a large number of questions are asked) and
 > allows the rest of the installation to proceed unattended in the absence of
 > errors.

  I fully agree that as many questions as possible should be asked before
 unpacking the package.  And I also agree it would better if the "replace
 the configuration file" questions also came at that point of the upgrade,
 but unfortunately, that isn't the status quo.

  dpkg asks for permission to overwrite conffiles *after* having unpacked
 the package in question -- and therefore you cannot dist-upgrade 300
 packages, answer all questions, then take lunch and expect it to be
 finished when you're back.  The upgrade will most likely stop after
 unpacking a package with a new conffile.

  As you probably know, preconfiguration is handled by apt-extracttemplates,
 while the conffile mechanism is dpkg's turf.  Therefore it would require
 major changes to apt/dpkg to make those conffile questions appear at the
 same time as all the other questions asked by apt-extracttemplates.  I
 don't see that change happening in the near future.

  So, where does that leave us?  dpkg's "Can I overwrite this conffile?"
 questions are asked some time between the package is unpacked and the
 postinst is started.  ucf's equivalent questions is asked in the
 postinst, which of course is slightly later in the process, but I
 highly doubt that a regular user would notice any difference.

  Hence, as ucf isn't especially worse than dpkg itself when it comes
 to interrupting upgrades after apt-extracttemplates has preconfigured
 packages, I don't think ucf's prompt in the postinst is that much of
 a problem.  YMMV.

-- 
Tore Anderson

Re: plagiarism of reiserfs by Debian

[Glenn McGrath]

On Sat, 19 Apr 2003 23:13:59 +0200
Anders Widman <[EMAIL PROTECTED]> wrote:

>  Wow..  what  an  reaction  :).  Hans's  original message was that the
>  credits  were  not included with the distributed files, nothing else.
>  Or am I completely mistaken?

I interpret his original message as saying his software if licensed
under a derivative of the GPL that requires an "obnoxious" advertising
clause.

It makes the license open to various interpretation as to its legality.

Maybe the license is contradicatory with regard to adding new clauses.

Maybe the license is incompatable with the GPL, for the same reasons that the
original BSD license is.

He opened a can of worms


Glenn

Bug#189773: ITP: pork -- Console-based AOL Instant Messenger client

[Ari Pollak]

Package: wnpp
Version: unavailable; reported 2003-04-19
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: pork
  Version : 0.7.0
  Upstream Author : Ryan McCabe <[EMAIL PROTECTED]>
* URL : http://pork.ojnk.net
* License : GPL
  Description : Console-based AOL Instant Messenger client

 pork is an ncurses-based AOL instant messenger client. It uses the
 OSCAR protocol (the one the windows client uses) to access AIM. Pork
 features Perl scripting; an online help system; the ability to
 configure nearly all aspects of the program's look-and-feel; an alias
 system; and a powerful, fully-configurable key binding system. It
 supports being logged in with more than one screen name at the same
 time. The default look-and-feel of the client is modeled after the
 ircII IRC client. Anyone comfortable using ircII (or any clients
 derived from it -- e.g., epic, BitchX, etc.) will feel comfortable 
 using pork.

- -- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux darth 2.4.21-pre5 #1 Sun Mar 2 20:39:17 EST 2003 i686
Locale: LANG=C, LC_CTYPE=C

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

iD8DBQE+ofYowO+u47cOQDsRAsG5AJ4l+knKwpt2YsaUwKtZmdWQUx/3GQCeMMNj
LUlKsZwkwfFixRMDaiSRZaY=
=W7lR
-END PGP SIGNATURE-

Re: Do we need policy changes?

[Nikolai Prokoschenko]

Andrew Suffield <[EMAIL PROTECTED]> wrote:
>> Thank you for your time, and you want to tell me I'm paranoid, don't
>> bother, it is not worth your time :) Better tell me what I might have
>> missed in the observing the subject.
AS> A point. What *is* yours?

The point is actually that debÑan (and others) doesn't care much about
internationalization, no matter what they say. I'm just trying to be
diplomatic,înot to risk a 'Do It Yourself' Answer. I'd like to have
solutions.

-- 
Nikolai Prokoschenko 
[EMAIL PROTECTED] / Jabber: [EMAIL PROTECTED]

Re: plagiarism of reiserfs by Debian

[Matt Zimmerman]

On Sat, Apr 19, 2003 at 09:18:54PM -0400, Matt Zimmerman wrote:

> On Sat, Apr 19, 2003 at 08:07:03PM +0400, Hans Reiser wrote:
> 
> > Please explain your reasons for removing the credits and attributions 
> > from the reiserfs utilities in violation of our copyright.
> 
> It appears that, in all likelihood, the credits were inadvertently omitted,
> and not intentionally removed.  In the reiserfsprogs distribution, there is a
> file COPYING which contains as the software license a verbatim copy of the
> GPL, while these credits are in a separate README.  I am confident that if
> you contact the maintainer of the package (Ed Boraas <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED], or via the bug tracking system), he will
> gladly observe your wishes and include this file with the documentation.

After reading further into this thread, I see that I misunderstood which
content you were referering to (a specific reference would have been
helpful).  This seems to relate to Debian bug #152547.

-- 
 - mdz

Re: plagiarism of reiserfs by Debian

[Matt Zimmerman]

On Sat, Apr 19, 2003 at 08:07:03PM +0400, Hans Reiser wrote:

> Please explain your reasons for removing the credits and attributions 
> from the reiserfs utilities in violation of our copyright.

It appears that, in all likelihood, the credits were inadvertently omitted,
and not intentionally removed.  In the reiserfsprogs distribution, there is a
file COPYING which contains as the software license a verbatim copy of the
GPL, while these credits are in a separate README.  I am confident that if
you contact the maintainer of the package (Ed Boraas <[EMAIL PROTECTED]>,
[EMAIL PROTECTED], or via the bug tracking system), he will
gladly observe your wishes and include this file with the documentation.

-- 
 - mdz

Re: plagiarism of reiserfs by Debian

[Marcel Weber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Sonntag, 20.04.03, um 01:06 Uhr (Europe/Zurich) schrieb Chris Cheney:
First of all emacs is pure bloat so who cares what it does... Vim has
one line about Ugandan orphans at startup, until now I didn't even
notice it was there. If had been pages of crap like what is spewed from
mkfs.reiserfs it would have probably been removed as well, unless it
was against Vim's license, which happens not to be GPL. As far as I can
tell if it annoyed someone enough it is legal under Vim's license to
remove the Uganda message as well, they only require the license text
itself to remain with the application.  A GPLv3 allowing spamware would
be very annoying, I hope it doesn't happen. If anything this stupid
reiserfs spamware should be spewed before the program runs, not after,
so that the user can see what actually occured without having to scroll
back up, which depending on their console type might be difficult.
Chris

All I can say to this is: use what you like, resp. if you don't like 
bloated software or spamware do not use it. My point is, that it should 
be a right of the original authors of the software to include credits. 
If someone else does a complete rewrite of the software, okay than we 
can discuss it, but if the rewrite means only the removal of the 
credits it is questionable.

But first of all, before we continue this discussion: What exactly has 
been removed? A readme file, the outputs during boot time, the outputs 
of mkfs.reiserfs? Has this output any impact on the usability of the 
software, so that there were good reasons the remove it? Has the 
license been violated by removing the credits?

Marcel
- ---
PGP / GPG Key:  http://www.ncpro.com/GPG/mmweber-at-ncpro-com.asc
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (Darwin)
iD8DBQE+oe6k1EXMUTKVE5URAnmyAKCTpeRYv6c45/3NpK7/jFZvxa6hIACgw8OX
VFGEUd3wnUNsuzu0JQTAXcY=
=ZQWW
-END PGP SIGNATURE-

Re: Proposed handling of generated configuration files (Re: stop the "manage with debconf" madness)

[Matt Zimmerman]

On Sun, Apr 20, 2003 at 02:20:00AM +0200, Tore Anderson wrote:

> * Matt Zimmerman
> 
>  > As was explained in detail, in order to do anything useful with that
>  > information, it is necessary to be able to show the user the proposed
>  > changes to the configuration file.  It is completely unhelpful to say:
>  >
>  > "You have modified this configuration file, and it has also been updated
>  > by the package maintainer.  Do you want to replace it with the version
>  > provided by the package maintainer?"
>  >
>  > Without showing the user the new version.
> 
>   Of course, this question will be shown in the postinst, if the generated
>  file differs from the previously generated one and the user has modified
>  the one in /etc.

Yes, and this was the main question that I brought up at the end of my
original message: is it worth sacrificing preconfiguration, or is there a
better way?  So far, there is no clear consensus.

>  I see your problem when you insist on asking on asking all questions at
>  the configure stage -- personally, I don't think delaying the actual
>  generating of the configuration file (and asking the question about
>  overwriting the old file) to the postinst stage is *that* bad.

This is the sort of input that I was soliciting.  Personally, I think that
preconfiguration is very important, since it _greatly_ simplifies initial
installation and upgrades (where a large number of questions are asked) and
allows the rest of the installation to proceed unattended in the absence of
errors.

-- 
 - mdz

Re: foo has reached testing, removing versioned build-depends?

[Brian May]

On Sat, Apr 19, 2003 at 03:50:23PM +0100, Colin Watson wrote:
> I've read the changelog and the bug report closed by that earlier
> change, and removing the version still makes no sense. If earlier
> versions of debiandoc-sgml produce incorrect output, as reported, then
> the versioned build-dep should be left there, as it will help people
> trying to build with older versions to know what the problem is.

Its not always that black and white.

For instance (and I haven't checked in this case) maybe the version in
stable is OK...

This is something I don't like about build-depends, if a broken version
of a library appears in unstable, then people will set the build-depends
to require the fixed version (or greator), when the version of the
library in stable never had any problems to start off with.
-- 
Brian May <[EMAIL PROTECTED]>

Re: Proposed handling of generated configuration files (Re: stop the "manage with debconf" madness)

[Tore Anderson]

* Matt Zimmerman

 > As was explained in detail, in order to do anything useful with that
 > information, it is necessary to be able to show the user the proposed
 > changes to the configuration file.  It is completely unhelpful to say:
 >
 > "You have modified this configuration file, and it has also been updated
 > by the package maintainer.  Do you want to replace it with the version
 > provided by the package maintainer?"
 >
 > Without showing the user the new version.

  Of course, this question will be shown in the postinst, if the generated
 file differs from the previously generated one and the user has modified
 the one in /etc.

  I was more thinking along the lines of a question such as:

You are upgrading from version 1.23 of package foo.  Starting from this
   version, the configuration file layout has changed drastically, and your
   old one cannot be used.  May I generate a new file based on your previous
   answers and autodetection tools, overwrite your old configuration file,
   and save the old one to /etc/foorc.dpkg-old?

  but I realise that's probably not what you had in mind.

* Tore Anderson

 >>   What am I missing?

* Matt Zimmerman

 > Generating configuration files using non-Essential tools (including tools
 > contained in the package being configured), the preference to ask all
 > questions at preconfiguration time, and the necessity of displaying
 > proposed changes before asking the user to confirm them.

  I see your problem when you insist on asking on asking all questions at
 the configure stage -- personally, I don't think delaying the actual
 generating of the configuration file (and asking the question about
 overwriting the old file) to the postinst stage is *that* bad.

  All the other questions can be asked at configure phase, though.

-- 
Tore Anderson

Re: Bug#189566: amavisd-new: bad interaction with package amavis-ng

[Brian May]

On Fri, Apr 18, 2003 at 08:51:51PM -0400, David B Harris wrote:
> Share an initscript between them, if that's possible?

No, that would cause more problems trying to rename
the existing amavisd-new conffile.

On Sat, Apr 19, 2003 at 09:06:58AM +0200, Ernst Kloppenburg wrote:
> yes. So maybe one of the packages should have its amavisd renamed.

I had some other ideas on how to fix the problem, then I looked at the
amavis-ng package:

lrwxrwxrwx root/root 0 2003-04-06 05:15:36 ./usr/sbin/amavisd -> 
../bin/amavis

Why is this symlink required?

Why does amavis-ng need to have two names?
-- 
Brian May <[EMAIL PROTECTED]>

Re: plagiarism of reiserfs by Debian

[Steve Langasek]

On Sun, Apr 20, 2003 at 01:24:09AM +0200, Wouter Verhelst wrote:
> Op za 19-04-2003, om 22:51 schreef Lukas Geyer:
> > the issue seems to be the fix of #152547. If we are not allowed to
> > remove a screenful of advertising from the output of a program, then
> > this unduly restricts the freedom to distribute modified versions.

> Uhm.

> From the GPL, section 2:

> 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.)

> Otherwise put: if the program shows the 'no warranty' clause from the
> GPL at startup, you may not remove it. Although a 'no warranty' message
> is certainly not the same as a list of sponsors, they both require some
> messages being printed for legalese reasons. I, personally, see nothing
> wrong with that; it certainly doesn't result in software being non-free.

The choice of the word "legalese" seems appropriate here; whereas the
GPL requirement is a concession to the legal reality that one must
actively disclaim warranty in some jurisdictions to avoid lawsuits from
users (who needn't agree to the GPL in full in order to use the
software), there is no such *legal* justification for a requirement that
credits be listed in the program's output.  Therefore, while most would
concede that authors shouldn't have to expose themselves to legal
liability in order to release free software, it's not so obvious that a
requirement to list credits in the output of a running program is
necessarily DFSG-free.

-- 
Steve Langasek
postmodern programmer


pgpqafQCfrxqw.pgp
Description: PGP signature

Re: bad postinst in kernel-images

[Keith Owens]

On Sun, 20 Apr 2003 09:54:53 +1000, 
Brian May <[EMAIL PROTECTED]> wrote:
>modutils >= 2.4.17 is not available for woody. You
>have two options: 2.4.15 for stable or 2.4.21 for unstable.
>
>This means you would have to recompile 2.4.21.
>
>Recompiling is easy, I have a version at
>http://www.microcomaustralia.com.au/debian/pool/main/m/modutils/>.
>You can use this for testing purposes.
>
>It does not solve the issue though that the versions of the packages as
>supplied with woody might be broken.
>
>We don't really want to force all woody users to upgrade to unstable
>before we are ready to release just to get working binutils+modutils
>combination, do we?

This is the required patch backported to modutils 2.4.15.  Apply it to
woody.  I am surprised that this is necessary, Wichert knew about this
problem when binutils was first upgraded.

Index: 15.14/depmod/depmod.c
--- 15.14/depmod/depmod.c Fri, 01 Mar 2002 11:39:06 +1100 kaos 
(modutils-2.4/24_depmod.c 1.17 644)
+++ 15.14(w)/depmod/depmod.c Sun, 20 Apr 2003 10:07:11 +1000 kaos 
(modutils-2.4/24_depmod.c 1.17 644)
@@ -1059,12 +1059,9 @@ static int addksyms(char *file_syms)
if (!isspace(*line))/* Adressless symbol? */
p = strtok(NULL, " \t\n");
/* The second word is either the symbol name or a type */
-   if (p && strlen(p) == 1) { /* System.map */
+   if (p && p[0] && !p[1]) { /* System.map */
is_mapfile = 1;
-   if (*p != '?')
-   p = NULL;
-   else
-   p = strtok(NULL, " \t\n");
+   p = strtok(NULL, " \t\n");
} else { /* /proc/ksyms copy */
if (p && strtok(NULL, " \t\n"))
p = NULL;
@@ -1082,7 +1079,7 @@ static int addksyms(char *file_syms)
if (!isspace(*line))/* Adressless symbol? */
p = strtok(NULL, " \t\n");
if (is_mapfile) {
-   if (*p != '?')
+   if (!p || !p[0] || p[1])
continue;
p = strtok(NULL, " \t\n");
/* Sparc has symbols like '.div' that need to be

Re: Do we need policy changes?

[Eduard Bloch]

#include 
* Andrew Suffield [Sun, Apr 20 2003, 12:29:49AM]:
> On Sun, Apr 20, 2003 at 12:26:04AM +0200, Nikolai Prokoschenko wrote:
> > Thank you for your time, and you want to tell me I'm paranoid, don't
> > bother, it is not worth your time :) Better tell me what I might have
> > missed in the observing the subject.
> 
> A point. What *is* yours?

Read. Just read and try with imagination. 
=> Better, flexible and _smooth_ i18n in debian-desktop. Something
userfriendly but not easy to achieve without conditional dependencies,
debconf config with controllable queue order and some other things I
have already told about in the past :(

MfG,
Eduard.
-- 
Es sind aber die Schmutzigsten, von denen man sagt, daß sie mit allen Wassern
gewaschen sind.


pgpDFBc4kGrvd.pgp
Description: PGP signature

Re: Proposed handling of generated configuration files (Re: stop the "manage with debconf" madness)

[Brian May]

On Sat, Apr 19, 2003 at 03:14:34PM -0400, Matt Zimmerman wrote:
> - Provide 3-way merge functionality to incorporate changes without losing
>   modifications in the common case (I hear this is coming for conffiles as
>   well)

Great!

Actually what I would like (and is similar in ways to the above) is to
be able to get two diffs:

1. What did I change in my config file since the last update?
2. What did the package maintainer change since the last update?

So if the next version of the package comes with, say a totally
different format, currently you will get a huge diff file between your
file and the upstream file.

This makes it hard to realize "but I only changed one setting!", and
that transferring to the new configuration might actually be a very easy
task, of just copying that one setting across.
-- 
Brian May <[EMAIL PROTECTED]>

Re: stop abusing debconf already

[Joey Hess]

Andre Luis Lopes wrote:
> Hmm, future plans really seems to be quite interesting. Is there a
> mailing list dedicated to discussing debconf ideas and implementation I
> could subscribe to ?
> 
> I saw that there's a link to an ancient "Config" mailing list at
> kitenet, but it seems not to be active anymore since all that I can see
> from its recent archives are lots of spam.
> 
> Better integration with dpkg, a SQL backend, debconf-2.0 and almost
> everything which was said in future plans seems to be too much
> interesting for us to be out of the fun :-)
> 
> Maybe a debian-debconf mailing list could be created in order to host
> future debconf discussions ?

Yes the config list is dead. Why don't you set up a list on alioth. 

debconf-2.0 is only waiting on the latest debconf getting into testing
before we begin that transition. All the rest is waiting on someone to
do the work.

-- 
see shy jo


pgpm6V81JoUl8.pgp
Description: PGP signature

Re: bad postinst in kernel-images

[Brian May]

On Sat, Apr 19, 2003 at 08:34:06PM +1000, Keith Owens wrote:
> binutils was changed around July 15 2002.  Unfortunately the binutils
> Changelog does not mention the change, nor does it say which releases
> of binutils were issued around that time.  Does upgrading to modutils
> >= 2.4.17 fix your problem?  If so, the n this is a prely Debian
> dependency problem.

modutils >= 2.4.17 is not available for woody. You
have two options: 2.4.15 for stable or 2.4.21 for unstable.

This means you would have to recompile 2.4.21.

Recompiling is easy, I have a version at
http://www.microcomaustralia.com.au/debian/pool/main/m/modutils/>.
You can use this for testing purposes.

It does not solve the issue though that the versions of the packages as
supplied with woody might be broken.

We don't really want to force all woody users to upgrade to unstable
before we are ready to release just to get working binutils+modutils
combination, do we?
-- 
Brian May <[EMAIL PROTECTED]>

Re: plagiarism of reiserfs by Debian

[Steve Langasek]

On Sat, Apr 19, 2003 at 04:25:57PM -0600, Andreas Dilger wrote:

> I'm sure all the FSF/Debian folks would be thrilled if someone changed the
> code in [x]emacs to not output anything about the GPL at startup, or if vim
> didn't include any info about helping Ugandan orphans.

> I'm not saying that I've ever liked the verbosity of the messages in
> mkreiserfs, but at the same time I wouldn't ever remove them out of
> courtesy to the author, regardless of whether it is in the license or not.

Debian never encourages anyone to violate the license of an application,
and rarely encourages disregarding the wishes of the author -- the
difference is that sometimes, if we aren't able to disregard the wishes
of the author without violating the license, the software is non-free.

-- 
Steve Langasek
postmodern programmer


pgprkYfnVdWcW.pgp
Description: PGP signature

Re: Do we need policy changes?

[Andrew Suffield]

On Sun, Apr 20, 2003 at 12:26:04AM +0200, Nikolai Prokoschenko wrote:
> Thank you for your time, and you want to tell me I'm paranoid, don't
> bother, it is not worth your time :) Better tell me what I might have
> missed in the observing the subject.

A point. What *is* yours?

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgphMM5Ly7Ruo.pgp
Description: PGP signature

Re: plagiarism of reiserfs by Debian

[Wouter Verhelst]

Op za 19-04-2003, om 22:51 schreef Lukas Geyer:
> the issue seems to be the fix of #152547. If we are not allowed to
> remove a screenful of advertising from the output of a program, then
> this unduly restricts the freedom to distribute modified versions.

Uhm.

From the GPL, section 2:

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.)

Otherwise put: if the program shows the 'no warranty' clause from the
GPL at startup, you may not remove it. Although a 'no warranty' message
is certainly not the same as a list of sponsors, they both require some
messages being printed for legalese reasons. I, personally, see nothing
wrong with that; it certainly doesn't result in software being non-free.

That said, the screenfull of messages indeed is a nuisance; could they
be replaced by a reference to them? I'd think of something like
'development of ReiserFS was sponsored by multiple third parties; please
see  for details', or maybe 'development
of ReiserFS was sponsored by ; please
see  for details' if your contracts don't
allow for removal of those names from the output...

-- 
wouter at grep dot be
"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts." 
  -- National Geographic Channel, in a documentary about large African beasts.


signature.asc
Description: Dit berichtdeel is digitaal gesigneerd

Re: Proposed handling of generated configuration files (Re: stop the "manage with debconf" madness)

[Matt Zimmerman]

On Sun, Apr 20, 2003 at 01:05:18AM +0200, Tore Anderson wrote:

>   As far as I know, ucf is created exactly for this purpose; to mimic
>   dpkg's conffile handing.  I assume you want to know if the configuration
>   file is unmodified prior to asking all the debconf questions, and making
>   use of such a command in the ucf package would unfortunately require a
>   pre-dependency.

A pre-dependency?  We're talking about .config here, not .preinst.  As was
explained in detail, there is no way to get access to tools in non-essential
packages from .config.

>  However, such a test would be very simple (basically just checking if the
>  md5sum of the configuration file matches the one recorded in ucf's
>  hashfile), so it could easily be included in the config script.

As was explained in detail, in order to do anything useful with that
information, it is necessary to be able to show the user the proposed
changes to the configuration file.  It is completely unhelpful to say:

"You have modified this configuration file, and it has also been updated by
the package maintainer.  Do you want to replace it with the version provided
by the package maintainer?"

Without showing the user the new version.

>   What am I missing?

Generating configuration files using non-Essential tools (including tools
contained in the package being configured), the preference to ask all
questions at preconfiguration time, and the necessity of displaying proposed
changes before asking the user to confirm them.

-- 
 - mdz

Re: Proposed handling of generated configuration files (Re: stop the "manage with debconf" madness)

[Tore Anderson]

* Matt Zimmerman

 > Did you read my sample configuration scenario (xserver-xfree86),
 > or the threads that I referenced?  They explain in more detail.

  I did, and I can't see why ucf can't be done for this purpose,
 too;

 > As I said, I am suggesting we mimick the conffile mechanism.  conffiles
 > are not parsed, but their modification is noticed.  My proposed system
 > would not prevent the user from using the menu-driven configuration; it
 > would simple offer them a choice about whether to generate a new
 > configuration using the dialogs, or to preserve their existing configuration.
 > This choice would only be necessary if the file had been modified by hand.

  As far as I know, ucf is created exactly for this purpose; to mimic dpkg's
 conffile handing.  I assume you want to know if the configuration file is
 unmodified prior to asking all the debconf questions, and making use of such a
 command in the ucf package would unfortunately require a pre-dependency.
 However, such a test would be very simple (basically just checking if the
 md5sum of the configuration file matches the one recorded in ucf's hashfile),
 so it could easily be included in the config script.

  After you've conclusided that you can overwrite the configuration
 file (possibly by asking the user if the not modified check was
 negative), you just write the configuration file outside of /etc
 and call ucf on it.  Possibly with UCF_FORCE_CONFNEW if you've
 asked explicit permission.

  What am I missing?

-- 
Tore Anderson

Re: plagiarism of reiserfs by Debian

[Chris Cheney]

On Sat, Apr 19, 2003 at 04:25:57PM -0600, Andreas Dilger wrote:
> On Apr 19, 2003  16:55 -0400, Ben Collins wrote:
> > > all that was removed was *code* that gets compiled.  If the maintainer 
> > > cannot arbitrarily change any code he wants, then it is not clear that 
> > > the program is DFSG-free.
> > 
> > Amen. Making part of the code immutable is not what I call free
> > software. What if I want to use parts of the code and I respect the
> > copyright and license...does that mean I also have to take this part of
> > the code and output the credits? What if environment doesn't provide a
> > way to output the credits. What if I am implementing the reiser tools on
> > an embedded system that will never show any such output?
> 
> I'm sure all the FSF/Debian folks would be thrilled if someone changed the
> code in [x]emacs to not output anything about the GPL at startup, or if vim
> didn't include any info about helping Ugandan orphans.

First of all emacs is pure bloat so who cares what it does... Vim has
one line about Ugandan orphans at startup, until now I didn't even
notice it was there. If had been pages of crap like what is spewed from
mkfs.reiserfs it would have probably been removed as well, unless it
was against Vim's license, which happens not to be GPL. As far as I can
tell if it annoyed someone enough it is legal under Vim's license to 
remove the Uganda message as well, they only require the license text
itself to remain with the application.  A GPLv3 allowing spamware would
be very annoying, I hope it doesn't happen. If anything this stupid
reiserfs spamware should be spewed before the program runs, not after,
so that the user can see what actually occured without having to scroll
back up, which depending on their console type might be difficult.

Chris

Re: plagiarism of reiserfs by Debian

[Michael Stone]

On Sat, Apr 19, 2003 at 11:13:59PM +0200, Anders Widman wrote:
Wow..  what  an  reaction  :).  Hans's  original message was that the
credits  were  not included with the distributed files, nothing else.
Or am I completely mistaken?
Who knows. The original message was an non-specific rant.
Mike Stone

Do we need policy changes?

[Nikolai Prokoschenko]

Hello,

I really don't know how to express what I want to say :) It has come
to my mind a few days ago when the Vera fonts were released to public.
My problem was: everybody was acting like mad, screaming "at last,
some good fonts for linux!", whereas, as far as I remember, these
fonts lacks many many scripts, starting with the simpliest ones like
Cyrillic. I don't even want to mention double-width characters. The
same with some GPL'ed fonts release newly (don't remember the name,
something starting with a 'd') - nothing except latin1. Same with
otherwise excellent Knoppix-CD (OK, it's not a Debian release, but a good
example of not caring about i18n and l10n): if you start it with the
Russian interface, the fonts are plain ugly - nothing was made to
ensure anti-aliasing for example.

What I think about is some regulated way to care about the needs of
international debian users. Let's take an example: some
programmîplays badly along with UTF-8 and therefore can't be properly
used by me, as I need e.g. both German and Russian. I can as well file
a bug against it, but it wouldn't matter much, as the maintainer would
just say 'it's not supported upstream' and nothing would happen. Other
situation would arise, if something like interoperability in different
language environments had been (I'm just speculating) a part of Debian
Policy. In that case, package at least could have been marked as
'non-functioning under non-latin circumstances' and this could
possibly lead to exclusion from Debian, or separating it into a
diffenrent part of debian (like non-US is) etc. This way, a possible
user could be warned in advance and maybe lead to the break-through
for Unicode.

Thank you for your time, and you want to tell me I'm paranoid, don't
bother, it is not worth your time :) Better tell me what I might have
missed in the observing the subject.

-- 
Nikolai Prokoschenko 
[EMAIL PROTECTED] / Jabber: [EMAIL PROTECTED]

Re: plagiarism of reiserfs by Debian

[Daniel Burrows]

On Sat, Apr 19, 2003 at 11:54:36PM +0200, Eduard Bloch <[EMAIL PROTECTED]> was 
heard to say:
> #include 
> I cannot see what exactly he was talking about. The only serios thing
> that has been removed in the Debian package is his spam (for
> SuSE&MP3.com) from the mkreiserfs executable code.
> 
> I cannot see a big CREDITS file in the package with author names that we
> could add to debian/copyright, and I fail to see what the zero-byte
> AUTHORS file is good for.

  He apparently stuck this information in the reiserfsprogs README, which
is not distributed in the Debian binary package for some reason.  Since he
wasn't specific in his original comments, I have no idea whether or not this
is what he was referring to.

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
| He was the kind of man who can use  |
| the word "personnel" and mean it.   |
|  -- Terry Pratchett, _The Light Fantastic_  |
\ Be like the kid in the movie!  Play chess! -- http://www.uschess.org ---/

Re: plagiarism of reiserfs by Debian

[Andreas Dilger]

On Apr 19, 2003  16:55 -0400, Ben Collins wrote:
> > all that was removed was *code* that gets compiled.  If the maintainer 
> > cannot arbitrarily change any code he wants, then it is not clear that 
> > the program is DFSG-free.
> 
> Amen. Making part of the code immutable is not what I call free
> software. What if I want to use parts of the code and I respect the
> copyright and license...does that mean I also have to take this part of
> the code and output the credits? What if environment doesn't provide a
> way to output the credits. What if I am implementing the reiser tools on
> an embedded system that will never show any such output?

I'm sure all the FSF/Debian folks would be thrilled if someone changed the
code in [x]emacs to not output anything about the GPL at startup, or if vim
didn't include any info about helping Ugandan orphans.

I'm not saying that I've ever liked the verbosity of the messages in
mkreiserfs, but at the same time I wouldn't ever remove them out of
courtesy to the author, regardless of whether it is in the license or not.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: plagiarism of reiserfs by Debian

[Francesco Paolo Lovergine]

On Sat, Apr 19, 2003 at 09:40:07PM +0300, Jarno Elonen wrote:
> 
> Additionally, it might be a good idea to provide a shoreter list of authors 
> in 
> addition to the detailed one for easier copying to 'standard copyright files' 
> like 'copying' in Debian.
> 

GNU folks generally use a Credits file for those kind of things.

-- 
Francesco P. Lovergine

Re: Proposed handling of generated configuration files (Re: stop the "manage with debconf" madness)

[Matt Zimmerman]

On Sat, Apr 19, 2003 at 09:41:58PM +0200, Tore Anderson wrote:

>   Hey, you just described how how ucf can be used.

I am aware of ucf.  I described some things that ucf does, and some things
that it does not.

>   Lo and behold!  We've just achieved your goals, using tools already in
>   the archive!

Not exactly.

>   Exactly what you wanted, yes?

Did you read my sample configuration scenario (xserver-xfree86), or the
threads that I referenced?  They explain in more detail.

-- 
 - mdz

ITA: gap4 -- computer algebra system for groups + related packages

[petervr]

retitle 188800 ITA: gap4 -- computer algebra system
retitle 188803 ITA: gap4-doc-dvi -- DVI-Docu files for GAP4
retitle 188801 ITA: gap4-doc-html -- HTML-Documentation for GAP4
retitle 188798 ITA: gap4-doc-ps -- Postscript files for GAP4
retitle 188802 ITA: gap4-gdat -- Group data libraries for GAP4
retitle 188799 ITA: gap4-tdat -- Table data libraries for GAP4
thanks

I intend to adopt gap4, a computer algebra system for group theory,
and the related packages. 

There is a new upstream version of gap4 (4.3, bugfix release 4, instead
of 4.2 that is in our archives), so I'll try to build that version.
Also, the current version of gap is released under the GPL (gap3 was not
and maybe version 4.2 was not either). 

Peter van Rossum <[EMAIL PROTECTED]>

Re: plagiarism of reiserfs by Debian

[Eduard Bloch]

#include 
* Ben Collins [Sat, Apr 19 2003, 05:09:58PM]:

> >  Wow..  what  an  reaction  :).  Hans's  original message was that the
> >  credits  were  not included with the distributed files, nothing else.
> >  Or am I completely mistaken?
> 
> Sorry, I had read into some other peoples comments and made a bad
> assumption about what this was refering to. So this is just about a file
> that is in /usr/share/doc/...? If so, I can't see what all the fuss is
> about. Just put the file back in.

I may be mistaken too, but having looked trough the .diff.gz two times,
I cannot see what exactly he was talking about. The only serios thing
that has been removed in the Debian package is his spam (for
SuSE&MP3.com) from the mkreiserfs executable code.

I cannot see a big CREDITS file in the package with author names that we
could add to debian/copyright, and I fail to see what the zero-byte
AUTHORS file is good for.

So IMO it is Hans who should take some valium and rethink the whole
issue.

MfG,
Eduard.
-- 
Hallo Frauennamenannehmer!

Re: stop abusing debconf already

[Steve Langasek]

On Sat, Apr 19, 2003 at 08:17:16PM +0100, Matt Ryan wrote:
> > Or maybe realize that Joey might perhaps know what he's talking about
> > with regard to debconf ... you could go find the text of his talk at the
> > last Debian Conference if you like.

> I realise he has an opinion on how things should be done. Depending on your
> own viewpoint this may be more influential than others as he is the author
> of the tool. As far as I'm concerned I'll use debconf how I please and if
> that's against the 'pure' view of others (ie/ *never* call it a registry)
> then its just hard luck.

Um, no.  *Policy* says that it may not be used as a registry.

- Debconf answers are stored in /var/cache/debconf.  Under the FHS,
  which is a mandatory part of Policy, the rules for /var/cache are that
  "[the] application must be able to regenerate or restore the data", and
  "the cached files can be deleted without data loss." *This precludes
  using debconf as a registry, and is by design*.  Since the position of
  the debconf maintainer is that debconf should not be used as a
  registry, if you use it as a registry then *your* package, not
  debconf, is in violation of Policy.
- Policy section 11.7.3 requires that "local changes [to configuration
  files] must be preserved during a package upgrade".  Using debconf as
  a registry implies giving precedence to debconf over the contents of
  an edited configuration file.  THIS IS A VIOLATION OF POLICY.
  Therefore, even if you resolve the above issue, Policy only allows you
  to use debconf as a registry *for information that is never written to
  a config file*.

I'm not sure why you think Joey's expertise doesn't qualify him to make
pronouncements about the use of debconf.  Unlike you, he at least gets
the answer right.

-- 
Steve Langasek
postmodern programmer


pgphbIX36Wg9R.pgp
Description: PGP signature

Re: stop abusing debconf already

[Colin Walters]

On Sat, 2003-04-19 at 15:17, Matt Ryan wrote:
> > Or maybe realize that Joey might perhaps know what he's talking about
> > with regard to debconf ... you could go find the text of his talk at the
> > last Debian Conference if you like.
> 
> I realise he has an opinion on how things should be done. Depending on your
> own viewpoint this may be more influential than others as he is the author
> of the tool. As far as I'm concerned I'll use debconf how I please and if
> that's against the 'pure' view of others (ie/ *never* call it a registry)
> then its just hard luck.

No offense, but I think you joined the wrong project, then.

Re: plagiarism of reiserfs by Debian

[Anders Widman]

>> all that was removed was *code* that gets compiled.  If the maintainer 
>> cannot arbitrarily change any code he wants, then it is not clear that 
>> the program is DFSG-free.

> Amen. Making part of the code immutable is not what I call free
> software. What if I want to use parts of the code and I respect the
> copyright and license...does that mean I also have to take this part of
> the code and output the credits? What if environment doesn't provide a
> way to output the credits. What if I am implementing the reiser tools on
> an embedded system that will never show any such output?

> What about programs that execute the reiserfs tools (like bootup
> scripts)...are they not allowed to redirect or filter this output?

> If any of this is questionable, then I suspect reiserfs tools isn't DFSG
> compliant and belongs in non-free with all it's flakiness.


 Wow..  what  an  reaction  :).  Hans's  original message was that the
 credits  were  not included with the distributed files, nothing else.
 Or am I completely mistaken?



PGP public key: https://tnonline.net/secure/pgp_key.txt

Re: stop abusing debconf already

[Colin Watson]

On Sat, Apr 19, 2003 at 08:17:16PM +0100, Matt Ryan wrote:
> Colin Watson wrote:
> > Or maybe realize that Joey might perhaps know what he's talking about
> > with regard to debconf ... you could go find the text of his talk at the
> > last Debian Conference if you like.
> 
> I realise he has an opinion on how things should be done. Depending on your
> own viewpoint this may be more influential than others as he is the author
> of the tool. As far as I'm concerned I'll use debconf how I please and if
> that's against the 'pure' view of others (ie/ *never* call it a registry)
> then its just hard luck.

Remember that the thread which spawned this is about configuration file
handling which goes against policy. I think that's the guts of the
brokenness.

> Policy is what matters not the opinion of some jumped up developers!

BTW the opinion of this jumped-up developer is "please don't send me
private copies of posts to mailing lists". Thanks.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: plagiarism of reiserfs by Debian

[Ben Collins]

On Sat, Apr 19, 2003 at 11:13:59PM +0200, Anders Widman wrote:
> >> all that was removed was *code* that gets compiled.  If the maintainer 
> >> cannot arbitrarily change any code he wants, then it is not clear that 
> >> the program is DFSG-free.
> 
> > Amen. Making part of the code immutable is not what I call free
> > software. What if I want to use parts of the code and I respect the
> > copyright and license...does that mean I also have to take this part of
> > the code and output the credits? What if environment doesn't provide a
> > way to output the credits. What if I am implementing the reiser tools on
> > an embedded system that will never show any such output?
> 
> > What about programs that execute the reiserfs tools (like bootup
> > scripts)...are they not allowed to redirect or filter this output?
> 
> > If any of this is questionable, then I suspect reiserfs tools isn't DFSG
> > compliant and belongs in non-free with all it's flakiness.
> 
> 
>  Wow..  what  an  reaction  :).  Hans's  original message was that the
>  credits  were  not included with the distributed files, nothing else.
>  Or am I completely mistaken?

Sorry, I had read into some other peoples comments and made a bad
assumption about what this was refering to. So this is just about a file
that is in /usr/share/doc/...? If so, I can't see what all the fuss is
about. Just put the file back in.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: Proposed handling of generated configuration files (Re: stop the "manage with debconf" madness)

[Anthony DeRobertis]

On Sat, 2003-04-19 at 15:41, Tore Anderson wrote:

> cat << _eof > /usr/share/fnord/managed-conffiles/fnord.cf

/var


signature.asc
Description: This is a digitally signed message part

Re: plagiarism of reiserfs by Debian

[Lukas Geyer]

Florian Weimer <[EMAIL PROTECTED]> writes:

> Hans Reiser <[EMAIL PROTECTED]> writes:
> 
> > You'll note that ReiserFS anticipated the GNU GPL V3 by including
> > clauses that forbid removal of credits in its license, and for a long
> > time I have been telling Stallman that he needs to get V3 of the GPL
> > out the door.
> 
> Oh, I think it's natural to assume that these clauses are superfluous
> because the GPL explicitly states that a distributor "may not impose
> any further restrictions on the recipients' exercise of the rights
> granted herein".  If these clauses were of any legal relevance, your
> software wouldn't be redistributable at all.
> 
> Just don't use the GPL for your software if you don't like it, but
> don't complain if anyone misunderstands your homemade license
> mishmash.

Well, usually we also try to use common sense, syllogism and rocket
science to find out what the author's intent was. Fortunately Hans
Reiser made his intent clear by posting this statement to
debian-devel. The only consequence I can see is to move reiserfsprogs
to non-free. For those who have not followed the discussion and such,
the issue seems to be the fix of #152547. If we are not allowed to
remove a screenful of advertising from the output of a program, then
this unduly restricts the freedom to distribute modified versions.

Cheers,
Lukas

P.S.: Cc'ed to debian-legal, which is probably the better place to
discuss this.

-- 
Give a man an answer, and he's satisfied today. Teach him to program,
and he will be frustrated for the rest of his life. 

Re: plagiarism of reiserfs by Debian

[Ben Collins]

On Sat, Apr 19, 2003 at 08:24:21PM +0100, Matt Ryan wrote:
> > Now I hope you stop with your trolling and consider speaking
> > respectfully to us. I am pretty sure that if you emailed the maintainer
> > of the package and pointed out the facts to him, he would revert the
> > change.
> 
> Dude,
> 
> You really need to calm down. Twice now recently you have opened your
> mouth and stuck your foot in when there really wasn't any need to. Take a
> Valium and do something less stressful.

Are you talking to me?

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: plagiarism of reiserfs by Debian

[Ben Collins]

> all that was removed was *code* that gets compiled.  If the maintainer 
> cannot arbitrarily change any code he wants, then it is not clear that 
> the program is DFSG-free.

Amen. Making part of the code immutable is not what I call free
software. What if I want to use parts of the code and I respect the
copyright and license...does that mean I also have to take this part of
the code and output the credits? What if environment doesn't provide a
way to output the credits. What if I am implementing the reiser tools on
an embedded system that will never show any such output?

What about programs that execute the reiserfs tools (like bootup
scripts)...are they not allowed to redirect or filter this output?

If any of this is questionable, then I suspect reiserfs tools isn't DFSG
compliant and belongs in non-free with all it's flakiness.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Re: why do we care about configuration files?

[Anthony DeRobertis]

On Sat, 2003-04-19 at 02:42, Manoj Srivastava wrote:

>   Or, simply generate the file using debconf or whatever, and
>  call ucf directly; then ucf handles storing the md5sum and comparing
>  it for you seamlessly.

/me uses "staying up too late" as an excuse for that one...


signature.asc
Description: This is a digitally signed message part

Re: Proposed handling of generated configuration files (Re: stop the "manage with debconf" madness)

[Tore Anderson]

* Matt Zimmerman

 > There was a more recent discussion about the same idea.  A summary of the
 > goals:
 >
 > - Don't try to parse every program's configuration file format
 >
 > - Notice that a non-conffile, autogenerated configuration file has been
 >   modified by the user, and don't lose their changes
 >
 > - Provide 3-way merge functionality to incorporate changes without losing
 >   modifications in the common case (I hear this is coming for conffiles as
 >   well)
 >
 > - Use debconf for prompting
 >
 > - Have all packages do this using a standard toolset, so that all prompting
 >   is consistent and well-translated, and certain defaults can be set
 >   globally (see the threads below for more discussion about this)

  Hey, you just described how how ucf can be used.  Here's a crash course on
 how to use it in package "fnord"'s maintainer scripts:

  fnord.config:
db_input fnord/something_that_has_no_good_default_answer
db_go

  fnord.postinst:
db_get fnord/something_that_has_no_good_default_answer
cat << _eof > /usr/share/fnord/managed-conffiles/fnord.cf
# configuration file for fnord.

setting_with_acceptable_default1 = quux
setting_with_acceptable_default2 = zoot

# this variable hasn't got any good default.
variable_with_no_good_default = $RET
_eof
db_stop
ucf /usr/share/fnord/managed-conffiles/fnord.cf /etc/fnord.cf < /dev/tty

  Lo and behold!  We've just achieved your goals, using tools already in
 the archive!

  If /usr/share/fnord/managed-conffiles/fnord.cf changes, because of
 a dpkg-reconfigure where the user gives another answer, or a upgrade
 where the template has been changed by the maintainer (or a combination),
 and the user has changed /etc/fnord.cf, ucf will pop up a question which
 closely resembles dpkg's counterpart:

Configuration file `/void/home/tore/ucftest/cf'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
Y or I  : install the package maintainer's version
N or O  : keep your currently-installed version
  D : show the differences between the versions
(...)

  Local modification will be kept, if the user wants them to be!  So
 there's no reason anyone to supply configuration files with comments
 such as "## don't edit this file; it belongs to the maintainer scrips!",
 even if the file is dynamically created.  The user doesn't need to know
 that whether or not not a conffile or a ucf-handled configuration file.

  But wait!  There's more! -- if you supply the --three-way option to ucf
 in your postinst, the rest of ucf's question looks like this:

3 or T  : show a thre way difference between current, older,
  and new versions of the file
  M : Do a 3 way merge between current, older,
  and new versions of the file [Very Experimental]

  Exactly what you wanted, yes?

-- 
Tore Anderson

Status of mICQ code audit

[Martin Loschwitz]

Hello Martin and Robert,

can you please inform the list and me about the current status of the 
mICQ code audit you two wanted to do? It's been a while and I didn't 
hear anything further from you since then.

However, since it is my principle to finish the things I've started, 
i'm writing this mail now. I'd be happy if I could get an answer.

-- 
  .''`.   Martin Loschwitz   Debian GNU/Linux developer
 : :'  :  [EMAIL PROTECTED][EMAIL PROTECTED]
 `. `'`   http://www.madkiss.org/people.debian.org/~madkiss/
   `- Use Debian GNU/Linux 3.0!  See http://www.debian.org/


pgpKKa5PJBJE5.pgp
Description: PGP signature

Re: New project proposal: debian-lex

[Ralf Hildebrandt]

* Sami Haahtinen <[EMAIL PROTECTED]>:

> > "lex" is the better word, as it is not only known in English, but also
> > in most other (roman) Languages for law.
> 
> Oh right, in finland there is a site finlex.fi, which is ofcouse
> obviously a site that contains the finnish law. This is the first time
> i've even heard the definition for 'lex', i support naming it
> debian-law, so that it's clear for the non-lawyers too.

You forget that "lex, legis (f.)" is well known with lawyers. They'll
immedialtely recognize it, since so many laws are of roman origin and
many latin terms occur.

-- 
Ralf Hildebrandt (Im Auftrag des Referat V a)   [EMAIL PROTECTED]
Charite Campus MitteTel.  +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax.  +49 (0)30-450 570-916
AIM: ralfpostfix

Re: New project proposal: debian-lex

[Andreas Barth]

* Jarno Elonen ([EMAIL PROTECTED]) [030419 21:05]:
> > "lex" is the better word, as it is not only known in English, but also
> > in most other (roman) Languages for law.

> The first things "lex" brings in my mind are "lexicon" and parser generators 
> like 'flex'.

Well, that's for you as an computer expert. If I ask an only-user with
an university graduate, he will probably say law.


Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C
   Fachbegriffe des Schienenverkehrs #1 von Marc Haber in dasr
   Alles wird billiger: 50 % Preiserhöhung für Stammkunden.

Re: plagiarism of reiserfs by Debian

[Matt Ryan]

> Now I hope you stop with your trolling and consider speaking
> respectfully to us. I am pretty sure that if you emailed the maintainer
> of the package and pointed out the facts to him, he would revert the
> change.

Dude,

You really need to calm down. Twice now recently you have opened your
mouth and stuck your foot in when there really wasn't any need to. Take a
Valium and do something less stressful.


Matt.

Re: stop the "manage with debconf" madness

[Matt Ryan]

> Secondly, this isnot a witch hunt. What is being done is that
>  a policy violation in older practice is being pointed
>  out. Alternatives are being discussed; a witch hunt would have
>  involved mass RC bug filings.

The TEX discussion is definitely in witchunt territory. Maintainers (on the
whole) try to make the best job they can of the packaging of their programs.
What is not helpful is when a developer gets a bad case of NOMUS (Not On My
UNIX System) and goes off on one about how perfectly the world would be if
everyone agreed with their narrow definition of the 'correct' way to do
things. The recent /run debate was another example of this virulent disease
taking hold amongst the vocal developer cabal.

Diversity is what keeps the human race going...


Matt.

Re: stop abusing debconf already

[Matt Ryan]

> Or maybe realize that Joey might perhaps know what he's talking about
> with regard to debconf ... you could go find the text of his talk at the
> last Debian Conference if you like.

I realise he has an opinion on how things should be done. Depending on your
own viewpoint this may be more influential than others as he is the author
of the tool. As far as I'm concerned I'll use debconf how I please and if
that's against the 'pure' view of others (ie/ *never* call it a registry)
then its just hard luck.

Policy is what matters not the opinion of some jumped up developers!


Matt.

Re: stop abusing debconf already

[Colin Watson]

On Sat, Apr 19, 2003 at 12:36:04PM -0400, Joey Hess wrote:
> Andre Luis Lopes wrote:
> > Could you (or someone else) give me a hint on where one could find
> > Joey's talk ? I've already tried googling for it and looking at [1] but
> > couldn't find it.
> 
> Hmm, I don't have it online that I know of, it was mostly extemporaneous
> anyway. (Here, I've linked the slides online at 
> http://kitenet.net/~joey/debconf-debconf)

I thought there was a video recording of it - that'd be Scott Dier's
department, wouldn't it?

-- 
Colin Watson  [EMAIL PROTECTED]

Re: New project proposal: debian-lex

[Sami Haahtinen]

On Sat, Apr 19, 2003 at 07:24:55PM +0200, Andreas Barth wrote:
> * David Goodenough ([EMAIL PROTECTED]) [030419 19:20]:
> >> [debian-lex]
> > In England there is a move to remove all the Latin and obscure language
> > from the Law, so I would suggest that the project should be called
> > Debian-law not Debian-lex.
> 
> "lex" is the better word, as it is not only known in English, but also
> in most other (roman) Languages for law.

Oh right, in finland there is a site finlex.fi, which is ofcouse
obviously a site that contains the finnish law. This is the first time
i've even heard the definition for 'lex', i support naming it
debian-law, so that it's clear for the non-lawyers too.

Regards, Sami

 -- Law should serve the people, thus people should understand the law.

-- 
  -< Sami Haahtinen >-
  -[ Notify immediately if you do not receive this message ]-
-< 2209 3C53 D0FB 041C F7B1  F908 A9B6 F730 B83D 761C >-

Re: plagiarism of reiserfs by Debian

[Travis Crump]

Marcel Weber wrote:
Hans, I hope that the removal of these credits was a mistake and that 
they're going to be included in future releases of testing. ReiserFS is 
a really fine piece of software and anyone who helped with it's 
development should have the right to be credited if he or she wants so.

Perhaps someone should file a bug against this.
Regards
Marcel

You mean a bug report like 
?  Oh, wait... 
 What if someone wanted to write a gtk frontend to mkreiserfs?  The 
credit would be similarly removed from the user's sight.  It would 
probably me right to put the message in the about window of this 
hypothetical program, but it wouldn't have the same visiblity as the 
credit now has since users rarely look at the about window.  Ultimately, 
all that was removed was *code* that gets compiled.  If the maintainer 
cannot arbitrarily change any code he wants, then it is not clear that 
the program is DFSG-free.

Proposed handling of generated configuration files (Re: stop the "manage with debconf" madness)

[Matt Zimmerman]

On Sat, Apr 19, 2003 at 02:07:04PM +0100, Matt Ryan wrote:

> Personally I use the ask-about-overwrite question in debconf because the
> last time this thread came up the only sensible solution was put forward
> in the attached email. Now, I'm all for a better solution when it is
> determined what that is, *but* I'm not for a witch hunt based on what was
> seen to be previous best practice.

There was a more recent discussion about the same idea.  A summary of the
goals:

- Don't try to parse every program's configuration file format

- Notice that a non-conffile, autogenerated configuration file has been
  modified by the user, and don't lose their changes

- Provide 3-way merge functionality to incorporate changes without losing
  modifications in the common case (I hear this is coming for conffiles as
  well)

- Use debconf for prompting

- Have all packages do this using a standard toolset, so that all prompting
  is consistent and well-translated, and certain defaults can be set
  globally (see the threads below for more discussion about this)

I have a clear idea of how I would implement this (and even some code), and
I think that these are all achievable.  The one thing which would be
sacrificed is preconfiguration.

Since autogenerated configuration files, unlike conffiles, require
non-essential tools in order to build them, this work generally needs to be
done in the postinst.  This means that we can't know what the "new"
configuration file looks like until the package is being configured.  And
there's no sense prompting the user ahead of time when they can't see what
the changes look like (Do you want to overwrite your modifications with some
random garbage I can't show you now? [Yes/No]).

Consider xserver-xfree86, whose current debconf setup can use autodetection
data from mdetect and read-edid, but this cannot work unless these packages
are installed when xserver-xfree86's .config script runs.  There is no
dependency relationship which can provide this guarantee (and it doesn't
sound like a very good idea to have one), so I don't see much of a way
around this.  However, I think that with suitable defaults and priority
settings, the above goals might be worth a sacrifice.  Of course, if someone
can think up a way to make this work _correctly_ (in terms of user
experience) with preconfiguration, that would be fabulous.

Prompting about these configuration files in postinst would be no better or
worse than the current conffile mechanism, though as Branden pointed out in
the previous discussion, the conffile prompting could, in theory, be done at
preconfiguration time, since the conffile itself is available in the deb.
Generated configuration files, however, are not.

What do folk think about this tradeoff?  Or is there a way around it?

References:

http://lists.debian.org/debian-devel/2002/debian-devel-200210/msg01572.html
http://lists.debian.org/debian-x/2002/debian-x-200210/msg00417.html

-- 
 - mdz

Re: imlib-linked-with-libpng3

[Steve Langasek]

On Fri, Apr 18, 2003 at 10:10:54PM -0500, Chris Cheney wrote:
> Why not simply make a imlib1p that conflicts with old imlib1 and rebuild
> the remaining 11 sources that still use imlib1 with old libpng2? There
> are fewer that would cause trouble in that batch, afaict only: chameleon,
> ebview, endeavour, pixelize, vertex.

> chameleon - dead upstream. (no website anymore)
> ebview- no idea since its japanese.
> endeavour - might work with gtk2? upstream is alive.
> pixelize  - dead upstream. (last release 2000-01-17)
> vertex- might work with gtk2? upstream is alive.

> kdegraphics requires being able to link to imlib with png3 to work due
> to png symbol collisions.

> Why aren't we working to get rid of libpng2 anyway, libpng3 isn't even
> current anymore.

png3 and png12-0 are supposed to be completely compatible; the choice of
one over the other is upstream insanity instigated by Red Hat.  So while
working to get rid of png2 is probably a good idea, forcing png3-using
packages to rebuild against png12-0 is not.

> Sources
> ---
> libpng2- 134
> libpng3-  23
> libpng12-0 - 185

-- 
Steve Langasek
postmodern programmer


pgpbvqOl0fh0a.pgp
Description: PGP signature

re:whats up???

[Lou Dog]

whats up with you? havent talked to you in awhile, same thing here pretty much. 

I am updating some info on the website and need your help. Can you hook me up 
with some info about your local skateshop and or skatepark? We are still adding 
skateparks to the list so if yours isnt in there let me know and we will add 
it. We are also going to start listing skate shops as well and if you can give 
me info on at least 2 skateshops and 1 skatepark I would really appreciate it. 
Here is the info I need:
Name of Shop:
Address/City/State of Shop:
Phone Number of Shop:
Website Address of Shop:
Email Address of Shop:
Cool I also just got done redesigning the site, let me know what you think of 
it.
http://www.stedb.com/dbm83/l.php?3175&381607
thanks 
Louie Baur


Switch to HTML version:
http://www.stedb.com/dbm83/msgtype.php?type=1&email=381607&emailing=5296

We hope you enjoyed receiving this email, but if you no longer wish to 
receive our emails please click here:
http://www.stedb.com/dbm83/un.php?5296&381607

^

  

Re: plagiarism of reiserfs by Debian

[Jarno Elonen]

> I'd hardly call it plagiarism. Your copyright is, by will of our own
> policy and to abide by authors wishes, distributed with the tools in
> /usr/share/doc//copyright.

Ah.. I guess Hans is referring to the author list in README?
The package maintainer probably looked at COPYING (contains GPL, as usual) and 
AUTHORS (an empty file) and didn't realize that README was actually an 
important addendum to the license and omitted the file from the package by 
mistake.

To prevent such problems in the future, perhaps the ReiserFS project could 
move the deviations from GPL from README to the beginning of COPYING and move 
the author list to AUTHORS?

Additionally, it might be a good idea to provide a shoreter list of authors in 
addition to the detailed one for easier copying to 'standard copyright files' 
like 'copying' in Debian.

- Jarno

Re: New project proposal: debian-lex

[Jarno Elonen]

> > In England there is a move to remove all the Latin and obscure language
> > from the Law, so I would suggest that the project should be called
> > Debian-law not Debian-lex.
>
> "lex" is the better word, as it is not only known in English, but also
> in most other (roman) Languages for law.

The first things "lex" brings in my mind are "lexicon" and parser generators 
like 'flex'.

- Jarno

Re: plagiarism of reiserfs by Debian

[Thomas Viehmann]

Marcel Weber wrote:
> I think Hans has a good point. The inclusion of credits is something
> that should be respected. Free software does not mean that you can do
> what you want with a piece of code, but that you're allowed to use,
> modify and redistribute it freely, respecting it's license.
IMHO
a) It is unfortunate that copyright in the doc dir doesn't list the full
   copyright (at least in my version) that is in README, but only mentiones
   GPL. Also, I think that the credits should be put somewhere in the doc
   directory.
b) The licensing information certainly ist misleading: The first line says
   GPL 2, period. Then there's lengthy information for assigning copyright
   of patches. After that, there is that funny "nothing ... shall be interpreted
   to allow you to fail to fairly credit me, or to remove my credits ...",
   which I'd probably interpret as "you cannot distribute without something
   that says...".
c) Someone running fsck because he has trouble with his hard drive probably
   doesn't want to see the history of mankind from the beginning to the
   creation of reiser v3. The patches to the source seem to be making
   reiserfsck behave more like other fsck (e.g. adding -y), so I can understand
   why someone would remove them. (In fact, if I have a (insert your favorite
   language items here) broken reiserfs I probably don't want to know who
   sponsored the breakage and lose ** lines of scrollback messages for that.)
   So it's only reasonable to move the stuff. No other author of any piece of
   GPL'd software I know of has such obnoxious sponsorship messages. In fact,
   they are hindering usability of the tools.
d) At least the noninclusion of README is probably an honest mistake and a
   friendly email would 100% suffice.

Cheers

T.


pgpY1XGzdylk0.pgp
Description: PGP signature

Re: plagiarism of reiserfs by Debian

[Florian Weimer]

Hans Reiser <[EMAIL PROTECTED]> writes:

> You'll note that ReiserFS anticipated the GNU GPL V3 by including
> clauses that forbid removal of credits in its license, and for a long
> time I have been telling Stallman that he needs to get V3 of the GPL
> out the door.

Oh, I think it's natural to assume that these clauses are superfluous
because the GPL explicitly states that a distributor "may not impose
any further restrictions on the recipients' exercise of the rights
granted herein".  If these clauses were of any legal relevance, your
software wouldn't be redistributable at all.

Just don't use the GPL for your software if you don't like it, but
don't complain if anyone misunderstands your homemade license
mishmash.

Re: plagiarism of reiserfs by Debian

[Marcel Weber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi
First I have to say, that I even did not realize, that the credits had 
been removed.

I think Hans has a good point. The inclusion of credits is something 
that should be respected. Free software does not mean that you can do 
what you want with a piece of code, but that you're allowed to use, 
modify and redistribute it freely, respecting it's license.

Even a credit that goes into the direction of a commercial has to be 
respected, if the license forbids it's removal. The same way we (the 
debian population) insist on the proper use of the most common GPL V2, 
so other licences have to be respected as well. How would we complain 
if a company like Microsoft would include GPL based software in their 
products without mentioning and crediting it. And anyone who fears that 
free software could become commercial sponsored software must exclude 
this kind of software from the distribution instead of violating 
licences.

Hans, I hope that the removal of these credits was a mistake and that 
they're going to be included in future releases of testing. ReiserFS is 
a really fine piece of software and anyone who helped with it's 
development should have the right to be credited if he or she wants so.

Perhaps someone should file a bug against this.
Regards
Marcel
Am Samstag, 19.04.03, um 18:07 Uhr (Europe/Zurich) schrieb Hans Reiser:
Please explain your reasons for removing the credits and attributions 
from the reiserfs utilities in violation of our copyright.

You'll note that ReiserFS anticipated the GNU GPL V3 by including 
clauses that forbid removal of credits in its license, and for a long 
time I have been telling Stallman that he needs to get V3 of the GPL 
out the door.

By the way, does Debian support as a matter of principle the 
decrediting of Stallman and KDE by RedHat?  I had really expected this 
from RedHat, not Debian, when I wrote those clauses.

In the academic world, this is called plagiarism.  In the academic 
world, knowledge is shared but fairly credited.  The GPL is born of 
the academic tradition.

--
Hans

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


- ---
PGP / GPG Key:  http://www.ncpro.com/GPG/mmweber-at-ncpro-com.asc
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (Darwin)
iD8DBQE+oY821EXMUTKVE5URAqQrAKCvtbJ/cP1B6J0ZzB2b1KtFPdP4YQCeIyY/
ls+MGfkxc3Kpt+Soe/31hjs=
=zc6y
-END PGP SIGNATURE-

Re: stop the "manage with debconf" madness

[Steve Langasek]

On Sat, Apr 19, 2003 at 11:11:59AM -0500, Steve Greenland wrote:
> On 18-Apr-03, 10:28 (CDT), Steve Langasek <[EMAIL PROTECTED]> wrote: 
> > If the package maintainers are correctly using the debconf priorities,
> > and the admin has chosen a debconf priority that accurately reflects
> > their preferences, why do you care?  By definition, any prompts at
> > priority medium or lower have reasonable defaults,

> If it has a reasonable default, then it should be defaulted. You should
> not ask questions about it. That's what Debian policy says. If you don't
> like this, then get policy changed. 

I agree that turning a config file into a non-conffile *just* so you can
ask medium- and low-priority questions is a bad thing.  But in the case
where there are already questions that need to be asked because there
are no reasonable defaults, throwing in some medium- and low-priority
questions doesn't hurt anything at all.

As for policy, please provide a reference to the section that says
maintainers are prohibited from providing greater configurability for
users who elect for it.  I must be overlooking that section.

> In particular, if you start asking questions about defaultable
> configuration values, then you can't make the file a conffile. Debian
> conffile handling is one of the great things about Debian. Breaking that
> is A Bad Thing(tm).

There are many other reasons why one might need to have a non-conffile
config file.  The generalization that "all debconf prompts for
medium-priority questions lead to gratuitous non-conffiles" is not
helpful.

> > > That's it. Any other use is a clear violation of Debian configuration
> > > file policy. In particular, using debconf to modify existing
> > > configuration files, whether conffiles or not, is wrong.

> > This claim is not reflected in our actual policy.  It's perfectly valid
> > for a maintainer script to make changes to non-conffile config file in
> > response to a user's expression of assent.

> But only if that assent is obtained each and every time, not by checking
> what the admin answered 8 months ago on the original install.

Certainly.

> And the whole thing is better handled using conffiles, where I can 
> diff and merge the changes, when it's convenient for me, rather than 
> hiding them scripts in the middle of a massive upgrade.

In many cases, yes, conffiles are preferable.  In the cases where I use
debconf, I don't think so.  There are still many configuration settings
on the system for which there is no sane default, and maintainers should
not be discouraged from dealing with these settings in a
policy-conformant manner.  Indeed, some of my debconf-based config file
handling is among the most satisfying code I've written for Debian --
certainly far outstripping upstream's own ability to handle
configuration and upgrade issues.  Clearly, your experience differs.
Are there specific packages you could point out that might be worth
looking at in this context, with the hope of helping the maintainers
improve them?

-- 
Steve Langasek
postmodern programmer


pgpHamcprfWyN.pgp
Description: PGP signature

Re: New project proposal: debian-lex

[Daniel Burrows]

On Sat, Apr 19, 2003 at 06:23:13PM +0200, Christian Surchi <[EMAIL PROTECTED]> 
was heard to say:
> On Sat, Apr 19, 2003 at 05:57:42PM +0200, Andreas Tille wrote:
> > > I am interested in coordinating a new sub-project called Debian-Lex,
> > Could you please explain the naming "lex" for non English speakers?
> 
> It's latin, not english. :-) It means "law".

  I strongly urge you to change it to something like "Debian-Law", or
everyone will think you're creating a subproject for regexp-based
tokenizers :-)  (or maybe libraries, which was my second guess from your
subject line)

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
|The only thing worse than infinite recursion |
|is infinite recursion.   |
\ Be like the kid in the movie!  Play chess! -- http://www.uschess.org ---/

Re: stop abusing debconf already

[Andre Luis Lopes]

On Sat, Apr 19, 2003 at 12:36:04PM -0400, Joey Hess wrote:
> Andre Luis Lopes wrote:
> > Could you (or someone else) give me a hint on where one could find
> > Joey's talk ? I've already tried googling for it and looking at [1] but
> > couldn't find it.
> 
> Hmm, I don't have it online that I know of, it was mostly extemporaneous
> anyway. (Here, I've linked the slides online at 
> http://kitenet.net/~joey/debconf-debconf)

Hmm, future plans really seems to be quite interesting. Is there a
mailing list dedicated to discussing debconf ideas and implementation I
could subscribe to ?

I saw that there's a link to an ancient "Config" mailing list at
kitenet, but it seems not to be active anymore since all that I can see
from its recent archives are lots of spam.

Better integration with dpkg, a SQL backend, debconf-2.0 and almost
everything which was said in future plans seems to be too much
interesting for us to be out of the fun :-)

Maybe a debian-debconf mailing list could be created in order to host
future debconf discussions ?

-- 
++--++
||  André Luís Lopes   [EMAIL PROTECTED]   ||
||  Debian-BR Project  http://debian-br.cipsga.org.br   ||
||  Public GPG KeyID   9D1B82F6 ||
||  Keyserver  wwwkeys.eu.pgp.net   ||


pgpYjkZRfPmmY.pgp
Description: PGP signature

Re: plagiarism of reiserfs by Debian

[Glenn McGrath]

On Sat, 19 Apr 2003 20:07:03 +0400
Hans Reiser <[EMAIL PROTECTED]> wrote:

> You'll note that ReiserFS anticipated the GNU GPL V3 by including 
> clauses that forbid removal of credits in its license, and for a long 
> time I have been telling Stallman that he needs to get V3 of the GPL
> out the door.

Please provide a link that supports your assertian about a GPL v3.

"The BSD License Problem""obnoxious BSD advertising clause"
http://www.gnu.org/philosophy/bsd.html



Glen

Re: New project proposal: debian-lex

[Andreas Barth]

* David Goodenough ([EMAIL PROTECTED]) [030419 19:20]:
>> [debian-lex]

> In England there is a move to remove all the Latin and obscure language
> from the Law, so I would suggest that the project should be called
> Debian-law not Debian-lex.

"lex" is the better word, as it is not only known in English, but also
in most other (roman) Languages for law.


Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C
   Fachbegriffe des Schienenverkehrs #1 von Marc Haber in dasr
   Alles wird billiger: 50 % Preiserhöhung für Stammkunden.

Re: plagiarism of reiserfs by Debian

[Ben Collins]

On Sat, Apr 19, 2003 at 08:07:03PM +0400, Hans Reiser wrote:
> Please explain your reasons for removing the credits and attributions 
> from the reiserfs utilities in violation of our copyright.
> 
> You'll note that ReiserFS anticipated the GNU GPL V3 by including 
> clauses that forbid removal of credits in its license, and for a long 
> time I have been telling Stallman that he needs to get V3 of the GPL out 
> the door.
> 
> By the way, does Debian support as a matter of principle the decrediting 
> of Stallman and KDE by RedHat?  I had really expected this from RedHat, 
> not Debian, when I wrote those clauses.
> 
> In the academic world, this is called plagiarism.  In the academic 
> world, knowledge is shared but fairly credited.  The GPL is born of the 
> academic tradition.

I'd hardly call it plagiarism. Your copyright is, by will of our own
policy and to abide by authors wishes, distributed with the tools in
/usr/share/doc//copyright.

Now, I've never heard of such a copyright clause in your tools and I am
quite sure that the individual maintainer of the package did not
intentionally go against such clauses. Not to mention that the acts of
that single maintainer of the software you wrote is not the will of the
entire Debian project.

Now I hope you stop with your trolling and consider speaking
respectfully to us. I am pretty sure that if you emailed the maintainer
of the package and pointed out the facts to him, he would revert the
change.



-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo   - http://www.deqo.com/

Bug#189689: ITP: libapache-mod-auth-radius -- Apache module for RADIUS authentication

[Fabio Massimo Di Nitto]

Package: wnpp
Version: unavailable; reported 2003-04-19
Severity: wishlist

* Package name: libapache-mod-auth-radius
  Version : 1.5.7
  Upstream Author : Alan DeKok <[EMAIL PROTECTED]>
* URL : ftp://ftp.freeradius.org/pub/radius/
* License : Apache Software License 1.1
  Description : Apache module for RADIUS authentication

 An apache module for authenticating users against information stored
 in a RADIUS server

Regards
Fabio

Re: libc6 (security) update does not restart system-services?

[Bob Proulx]

Bernd Eckenfels wrote:
> GOTO Masanori wrote:
> > So everytime we have to restart all binaries which use a library
> > involving security-problem.  In additionm this problem affects not
> > only debian packages, but user-built binaries.
> 
> Well, this is why it is most often described in the security advisory.

It seems to me that while there is the reputation "Rebooting is for
adding new hardware" that sometimes rebooting is also for security and
other updates.  I have been training people that Debian does not
*force* a reboot at the time that the update is made but allows the
admin to schedule a reboot at their convenience for critical library
updates such as glibc, use your judgement.  Coming from other system
which force a reboot for almost any update this is seen as a breath of
fresh air.  (No, amazingly I am not talking about MS here, but rather
HPUX which has many gratuitous reboots when swinstall'ing updates.)

> To be shure one can eighter use "init 1" and get back to multi user
> mode,

Basically moving through 'init 1' is almost the same as a reboot.  It
just preserves your uptime stats.  :-)  I would not move through
'init 1' programatically.

> or use tools like "lsof" or my package of "memstat" to find loaded
> and deleeted libraries.

I believe this process to be much to complicated to be used
successfully in the general case.  You would need to match each
running process back to a /etc/init.d restart methodology.  These
frequently do not have a one to one mapping.  You could design a new
methodology to be added to policy which packages with running daemons
would need to register themselves to ensure a proper restart.  So much
work would be needed to make this happen smoothly.

> This is also good to do on a regular interval if you update your systems for
> no security reasons:
> 
> - it will free memory and will make the filesystem get rid of open/deleted
> files, which can cause problems like the inability to remount ro or messages
> like "setting dtime of deleted inode" on fsck.

Except for the uptime wars (2 years 2 weeks!, between power outs here)
I generally reboot servers monthly.  This has the added benefit that
it also ensures that the servers will boot cleanly and an admin has
not broken something with a manual tweak.

Bob


pgpSFjTrHWZtw.pgp
Description: PGP signature

Re: New project proposal: debian-lex

[David Goodenough]

On Saturday 19 April 2003 17:23, Christian Surchi wrote:
> On Sat, Apr 19, 2003 at 05:57:42PM +0200, Andreas Tille wrote:
> > > I am interested in coordinating a new sub-project called Debian-Lex,
> >
> > Could you please explain the naming "lex" for non English speakers?
>
> It's latin, not english. :-) It means "law".

In England there is a move to remove all the Latin and obscure language
from the Law, so I would suggest that the project should be called
Debian-law not Debian-lex.

Regards

David

Re: stop abusing debconf already

[David B Harris]

On Sat Apr 19, 11:18am -0500, Steve Greenland wrote:
> On 19-Apr-03, 06:47 (CDT), Steve Kowalik <[EMAIL PROTECTED]> wrote: 
> > At  7:22 pm, Saturday, April 19 2003, Denis Barbier mumbled:
> > > I do not understand exactly what is good and bad use of debconf.
> > > For instance all questions asked by the debconf package have good default
> > > values, so there is no reason to prompt user, a configuration file is
> > > enough.  So what am I missing?
> > > 
> > Well, not all use of debconf is bad. For example, libnet-perl is a terrible
> > misuse of debconf, *but* it can be remedied by dropping the priority of the
> > questions from medium to low.
> 
> Huh? If all the questions it asks can be converted to priority low, then
> that means there are reasonable defaults, and therefore IT SHOULDN'T BE
> USING DEBCONF AT ALL.
> 
> How hard is this?  What is so unclear about Policy on this topic?

From debconf-devel(8): "low: Very trivial items that have defaults that
will work in the vast majority of cases; oinly control freaks see
these."


pgpWKYL2Wz8BY.pgp
Description: PGP signature

Re: New project proposal: debian-lex

[Michael Banck]

On Sat, Apr 19, 2003 at 05:57:42PM +0200, Andreas Tille wrote:
> On 19 Apr 2003, Jeremy Malcolm wrote:
> > I am interested in coordinating a new sub-project called Debian-Lex,
> Could you please explain the naming "lex" for non English speakers?

s/English/Latin/

cheers,

Michael

Re: New project proposal: debian-lex

[Christian Surchi]

On Sat, Apr 19, 2003 at 05:57:42PM +0200, Andreas Tille wrote:
> > I am interested in coordinating a new sub-project called Debian-Lex,
> Could you please explain the naming "lex" for non English speakers?

It's latin, not english. :-) It means "law".

-- 
Christian Surchi, [EMAIL PROTECTED], [EMAIL PROTECTED] |   ICQ 
www.debian.org - www.softwarelibero.it - www.firenze.linux.it| 38374818
Bank error in your favor.  Collect $200.

Re: stop abusing debconf already

[Joey Hess]

Andre Luis Lopes wrote:
> Could you (or someone else) give me a hint on where one could find
> Joey's talk ? I've already tried googling for it and looking at [1] but
> couldn't find it.

Hmm, I don't have it online that I know of, it was mostly extemporaneous
anyway. (Here, I've linked the slides online at 
http://kitenet.net/~joey/debconf-debconf)

-- 
see shy jo


pgpCvDzqK9Bd0.pgp
Description: PGP signature

Re: stop abusing debconf already

[Steve Greenland]

On 19-Apr-03, 06:47 (CDT), Steve Kowalik <[EMAIL PROTECTED]> wrote: 
> At  7:22 pm, Saturday, April 19 2003, Denis Barbier mumbled:
> > I do not understand exactly what is good and bad use of debconf.
> > For instance all questions asked by the debconf package have good default
> > values, so there is no reason to prompt user, a configuration file is
> > enough.  So what am I missing?
> > 
> Well, not all use of debconf is bad. For example, libnet-perl is a terrible
> misuse of debconf, *but* it can be remedied by dropping the priority of the
> questions from medium to low.

Huh? If all the questions it asks can be converted to priority low, then
that means there are reasonable defaults, and therefore IT SHOULDN'T BE
USING DEBCONF AT ALL.

How hard is this?  What is so unclear about Policy on this topic?

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: stop the "manage with debconf" madness

[Manoj Srivastava]

>> On Sat, 19 Apr 2003 14:07:04 +0100,
>> Matt Ryan <[EMAIL PROTECTED]> said: 

 > Personally I use the ask-about-overwrite question in debconf
 > because the last time this thread came up the only sensible
 > solution was put forward in the attached email. Now, I'm all for a
 > better solution when it is determined what that is, *but* I'm not
 > for a witch hunt based on what was seen to be previous best
 > practice.

I'm sorry that all of us can't participate in all the
 discussions on -devel, and some times the optimal solutions are not
 reached. But when these solutions were starting to get implemented, I
 did point out the policy violations, and even filed a few serious
 bugs about them. I did not have the time or the energy then to do
 much more.

Around the same time, ucf was written to allow one to manage a
 configuration file, allowing one to generate configuration files on
 the fly, and still afford the user changes dpkg like protection. 

In any case, pointing to an old discussion on -devel is not a
 justification for not preserving user changes. Asking the admin
 whether one may violate Debian policy ought not to be a license to do
 as one wishes. 

Secondly, this isnot a witch hunt. What is being done is that
 a policy violation in older practice is being pointed
 out. Alternatives are being discussed; a witch hunt would have
 involved mass RC bug filings. 

Debconf did not suddenly give people a reason to not preserve
 user changes; amd we had already rejected destruction of user changes
 before (one could have written a mainainter script in 1995 that asked
 the user once, populated a file in /var/lib/, and forever destroyed
 user changes, way before debconf).

manoj
-- 
Pardon this fortune.  Database under reconstruction.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: stop the "manage with debconf" madness

[Steve Greenland]

On 18-Apr-03, 10:28 (CDT), Steve Langasek <[EMAIL PROTECTED]> wrote: 
> If the package maintainers are correctly using the debconf priorities,
> and the admin has chosen a debconf priority that accurately reflects
> their preferences, why do you care?  By definition, any prompts at
> priority medium or lower have reasonable defaults,

If it has a reasonable default, then it should be defaulted. You should
not ask questions about it. That's what Debian policy says. If you don't
like this, then get policy changed. 

In particular, if you start asking questions about defaultable
configuration values, then you can't make the file a conffile. Debian
conffile handling is one of the great things about Debian. Breaking that
is A Bad Thing(tm).

> > That's it. Any other use is a clear violation of Debian configuration
> > file policy. In particular, using debconf to modify existing
> > configuration files, whether conffiles or not, is wrong.
> 
> This claim is not reflected in our actual policy.  It's perfectly valid
> for a maintainer script to make changes to non-conffile config file in
> response to a user's expression of assent.

But only if that assent is obtained each and every time, not by checking
what the admin answered 8 months ago on the original install. And the
whole thing is better handled using conffiles, where I can diff and
merge the changes, when it's convenient for me, rather than hiding them
scripts in the middle of a massive upgrade.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: debconf review of cvsd (was Re: stop abusing debconf already)

[Joey Hess]

One more thing that I didn't notice until purging the package. In the
purge question, you refer to "selecting yes" and "answering no". Don't
do that, some debconf frontends do not use yes or no; the user might be
staring at a check box when they see that text. Just ask the question,
something like (changebarred):

  You may choose to remove the chroot jail but you will also
  loose all the repositories inside the chroot jail. If you have not
| backed up your repositories you want to keep, do not remove it now;
| manually remove it later once your repositories are safe.

| If you do chose to remove the chroot directory, all directories under
| it will be removed, even if they are on another filesystem.

  If you choose to keep the chroot jail please note that the cvsd user
  and group will be removed so uid and gid file information may no longer
  be consistent.

And while it's probably ok to default it to true, the postrm should
catch the db_input return code, and if the question is not displayed, do
not remove anything (and say something to stderr about it maybe). Think
of someone in noninteractive mode..


Good use of a debconf substitution in that last question, BTW.

-- 
see shy jo


pgpJf89k6aw5V.pgp
Description: PGP signature

plagiarism of reiserfs by Debian

[Hans Reiser]

Please explain your reasons for removing the credits and attributions 
from the reiserfs utilities in violation of our copyright.

You'll note that ReiserFS anticipated the GNU GPL V3 by including 
clauses that forbid removal of credits in its license, and for a long 
time I have been telling Stallman that he needs to get V3 of the GPL out 
the door.

By the way, does Debian support as a matter of principle the decrediting 
of Stallman and KDE by RedHat?  I had really expected this from RedHat, 
not Debian, when I wrote those clauses.

In the academic world, this is called plagiarism.  In the academic 
world, knowledge is shared but fairly credited.  The GPL is born of the 
academic tradition.

--
Hans

debconf review of cvsd (was Re: stop abusing debconf already)

[Joey Hess]

Arthur de Jong wrote:
> Ok, could you review my cvsd package for me for correct debconf usage and
> tell me what you do and don't like?

Thanks for taking advantage of that offer. (So far you're the only one.)
I am ccing this to -devel just because.

All of the debconf questions are pretty well worded and clear, but
there's always room for improvement:

 - I'm not sure why you capitalized "Chroot" in the second sentence of the
   cvsd/rootjail question (and in the short description of that question)
   and "filehierarchy" probably needs a space in it.

 - cvsd/rootjail:
   s/zero (0)/0/  # Apparently writing it out has the possibility to make
  # someone enter the number the wrong way so why not just
  # not write it out?

 - cvsd/nice:
   s/too much/too many/

 - cvsd/listen:
   s/cvsd will listen on/on which cvsd will listen/ 
  # Avoid dangling preposition

  - Though it's pretty obvious what you mean by "RootJail" in the
cvsd/repositories question, that is in fact the first time that
particular term has been used. Also, you could use a debconf
substitution here to substitute in the user's choce of the chroot jail
directory directly into the question, to remind them what it is. Oh you 
also use the inconsistently capitalized "rootjail" in cvsd/usedebconf.
Wouldn't just "chroot jail" be better? Or at least some consistency
there and with the "Chroot jail" term in cvsd/rootjail.

  - cvsd/limits:
s/to limit of pserver process./of pserver process to limit:/

  - Most of the questions have short descriptions that do not end in
punctuation, and this has unfortunate results in some debconf frontends,
like this:

Location of Chroot jail /var/lib/cvsd

It's better to put a colon or a question mark at the end.

  - It's sort of odd that you use spaces to separate multiple items in one
question, and then colons to separate them in the next.

  - It was not clear to me in the cvsd/limits question what would be the
result of picking any of those limits. At first I thought it would
enable some kind of hard-coded limits, which made me not want to mess
with it. I see reading that templates file that it in fact enables a
whole set of additional questions about the limits. Noting that you'll
ask these questions in cvsd/limits would be a good idea.

  - cvsd/limit_coredumpsize:
s/filesize/file size/  # don't invent terminology
s/coredump/core dump/  # I know, it sucks when one's spacebarbreaks :-)

  - cvsd/limit_cputime:
s/prevent too much cpu time allocated/prevent too much cpu time from being 
allocated/
s/amount of seconds cputime/amount of cpu time/ 
   # it is not just in seconds form, and "seconds cputime" is 
   # incorrect English.

  - I was fairly confused by cvsd/limit_memorylocked, because I thought that
only programs run as root could lock memory, and why would cvs want to?
Was this just added for (over)completeness?

  - cvsd/limit_maxproc:
s/Cvs/cvs/  # for consistency with every other mention of the program
# including other starts of sentences

  - You have no translations for the debconf templates in the package. The
DDTP project has a complete German translation at
http://ddtp.debian.org/debconf/source/cvsd. Of course you may want to
make the above changes first, and wait for an updated translation..


If I reconfigure cvsd, pick all the limits, and take the default value
for everything else, it exits with code 20:

debconf (developer): <-- GET cvsd/limits
debconf (developer): --> 0 coredumpsize, cputime, datasize, filesize,
memorylocked, openfiles, maxproc, memoryuse, stacksize, virtmem
debconf (developer): <-- GET cvsd/limit_coredumpsize cputime datasize filesize 
memorylocked openfiles maxproc memoryuse stacksize virtmem 
debconf (developer): --> 20 Incorrect number of arguments
zsh: exit 20DEBCONF_DEBUG=. dpkg-reconfigure cvsd

Looks like a bug.. After doing this I also did not see all the limits
stuff in cvsd.conf, it had only these config items:

Uid cvsd
Gid cvsd
PidFile /var/run/cvsd.pid
RootJail /var/lib/cvsd
MaxConnections 10
Nice 1
Listen * 2401


You support backing up; very good job there!


Looking at your priorities, I'm not sure why the maximum connection
limit is at priority medium. Surely there is a sane default, and so it
could be low priority? I'm iffy about asking about the jail directory at
medium priority; I suppose many people will want to configure that, but
/var/lib/cvsd seems reasonable. Medium is probably ok. I agree with your
use of high priority for the repositories question, and all the rest
look nice and low.

> I've set it up to ask first whether to use debconf to manage configuration
> of /etc/cvsd/cvsd.conf (not a conffile). If the user chooses to not use
> debconf, he's on his own (an example cvsd.conf is provided).

Of course this is where in my opinion you lose. First of all, as Colin
pointe

Re: stop abusing debconf already

[Andre Luis Lopes]

On Sat, Apr 19, 2003 at 03:46:32PM +0100, Colin Watson wrote:


> Or maybe realize that Joey might perhaps know what he's talking about
> with regard to debconf ... you could go find the text of his talk at the
> last Debian Conference if you like.


Could you (or someone else) give me a hint on where one could find
Joey's talk ? I've already tried googling for it and looking at [1] but
couldn't find it.

[1] http://www.debconf.org

-- 
++--++
||  André Luís Lopes   [EMAIL PROTECTED]   ||
||  Debian-BR Project  http://debian-br.cipsga.org.br   ||
||  Public GPG KeyID   9D1B82F6 ||
||  Keyserver  wwwkeys.eu.pgp.net   ||


pgplhDHN8iHcp.pgp
Description: PGP signature

Re: libc6 (security) update does not restart system-services?

[Bernd Eckenfels]

On Sun, Apr 20, 2003 at 12:05:49AM +0900, GOTO Masanori wrote:
> So everytime we have to restart all binaries which use a library
> involving security-problem.  In additionm this problem affects not
> only debian packages, but user-built binaries.

Well, this is why it is most often described in the security advisory.

To be shure one can eighter use "init 1" and get back to multi user mode, or
use tools like "lsof" or my package of "memstat" to find loaded and deleeted
libraries.

This is also good to do on a regular interval if you update your systems for
no security reasons:

- it will free memory and will make the filesystem get rid of open/deleted
files, which can cause problems like the inability to remount ro or messages
like "setting dtime of deleted inode" on fsck.

Greetings
Bernd
-- 
  (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: New project proposal: debian-lex

[Andreas Tille]

On 19 Apr 2003, Jeremy Malcolm wrote:

> I am interested in coordinating a new sub-project called Debian-Lex,
Could you please explain the naming "lex" for non English speakers?

In general I really like your idea because I think those internal
projects are an important way to fit the needs of our users.  I
would recommend to read the slides of my talk about internal projects
and also follow rhe link to the Subproject HOWTO.

Good luck with your project

  Andreas.

--
Mankind must put an end to war before war puts an end to mankind.
John F. Kennedy

Re: foo has reached testing, removing versioned build-depends?

[Colin Watson]

On Sat, Apr 19, 2003 at 03:43:56PM +0200, Bill Allombert wrote:
> On Sat, Apr 19, 2003 at 10:44:52AM +0200, Marcelo E. Magallon wrote:
> >  [ obDebianDevel: just in case this has become popular beleif or
> >something like that ]
> > 
> >  from menu's 2.1.7-3 changelog:
> > 
> >   * debiandoc-sgml 1.1.75 has reached testing so remove the versionned
> > Build-Depends.
> > 
> >  what gave you the idea that because debiandoc-sgml 1.1.75 is now in
> >  testing, you can remove the versioned build-depends?  Unless the
> >  comment is misleading, menu still depends on at least that version of
> >  debiandoc-sgml to build, doesn't it?
> 
> Read the reason why the debiandoc-sgml *versioned* build-dep was added
> latter on in the changelog, and check the control file, and then go back
> and I will give an explanation.

I've read the changelog and the bug report closed by that earlier
change, and removing the version still makes no sense. If earlier
versions of debiandoc-sgml produce incorrect output, as reported, then
the versioned build-dep should be left there, as it will help people
trying to build with older versions to know what the problem is.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: stop abusing debconf already

[Joey Hess]

Steve Kowalik wrote:
> Well, not all use of debconf is bad. For example, libnet-perl is a terrible
> misuse of debconf, *but* it can be remedied by dropping the priority of the
> questions from medium to low.

At least libnet-perl is actually asking questions and preserving some
(though not all) user changes to libnet.cfg. Michael's idea to add
a gateway question is probably sufficient to solve the too many
questions thing. I'd be just as happy if it only asked about stuff that
really needs to be configured, such as ftp passive mode though.

> Another bad example is binutils, which spits
> out that silly note even during a new install.

Yes.

> If you test that $2 is empty,
> don't print it. Unfortunately, I don't want to point out a good usage of
> debconf, since I'd only be ringing my own bell.

I'll ring it for you: xringd is one of the better users of debconf I
have seen, and it gets everything right.


The problem is that with debconf, even 10% of packages getting it wrong
make the whole system into crap. And probably closer to 70% of packages
are currently getting it wrong..

-- 
see shy jo


pgpKTvmvVG4yb.pgp
Description: PGP signature

Re: libc6 (security) update does not restart system-services?

[GOTO Masanori]

At Fri, 18 Apr 2003 17:24:17 +0200,
Markus Amersdorfer wrote:
> On Fri, 18 Apr 2003 13:06:07 +0900
> GOTO Masanori <[EMAIL PROTECTED]> wrote:
> > > - /var/lib/dpkg/info/libc6.postinst checks for "$1" ==
> > >   "configure"
> > >   (which is the case when updating, isn't it?). If true it
> > >   afterwards checks if "$2" is lower than "2.1.95-1" (I assume this
> > >   corresponds to the previously installed version) and _only if this
> > >   the case_ it restarts most of the services.
> > > 
> > > Woody comes with libc6 2.2.5-11.5, so the section about restarting
> > > services is never reached.
> > > 
> > > This leaves the machine vulnerable as all services use the old
> > > library until restarted.
> > >
> > > Shouldn't the services be restarted when installing a new
> > > libc-version? What reasons would there be not to restart services?
> > 
> > Restarting services is needed only once: upgrading from 2.2.x to
> > 2.3.x.  The reason is simple.  NSS (Name Service Switch) is much
> > changed, and it becomes incompatible between 2.2 and 2.3.
> > 
> > So if you use woody server, not sarge, then you have no need to
> > restart services.  If you use libc6 2.2.x, it's not related.
> 
> So restarting services is necessary when upgrading from 2.2.x to 2.3.x
> to make sure everything works fine (as e.g. the example of xdm you
> mention below). When staying with basically the same version and
> "simply" doing a security-update, there are no compatability-problems,
> of course, so everything keeps running smoothly.
> 
> But my concern is that running programs such as system services use the
> old libraries instead of the new one as long as they continue running,
> don't they? If they do the security bug is still exploitable though the
> new libraries are already installed on the system.

Yes, right, good point.  This is not only glibc issue; this problem
affects all library packages.  The old libraries are remove-pending
state on the file system, and reside in applications.

So everytime we have to restart all binaries which use a library
involving security-problem.  In additionm this problem affects not
only debian packages, but user-built binaries.

I have to warn all users who believe that we needs only "apt-get
upgrade, yeah, that's all folks!" concept.  It's not true for this
library upgrade issue.

From our glibc upgrade experience, it's difficult to restart packages
which have specific problem automatically...  The simple method to
detect old libraries are to use lsof, so debian package system can
warn for users "there are old libraries which has security problem, so
you should restart these binaries".  I don't know there is good way to
fix this problem.

> > > If everything _is_ designed not to restart the services, I suppose
> > > telling the users to take care of that theirselves would be a good
> > > idea for example using a simple "echo" in the post-install script
> > > (or similar).
> > 
> > The restarting message is not sufficient for you?
> 
> Of course, but the message is only shown if the services _are_ to be
> restarted (which is only when doing a major version update). 
> Services are not restarted by the security update though I think they
> should be (as stated above).
> 
> If I'm wrong, please correct me. :)

I think you confuse two issue.  One is generic problem as I write
above (memory resident libraries issue).  Another is glibc NSS start
problem as I write below.

Or did you point the messages which are not appeared in
libc6.postinst when you upgraded from 2.2 to 2.3 ?

> > BTW, I plan to dupload 2.3.1-17 that has preinst message to choose
> > libc6 upgrade or not.  It's needed because for example xdm cannot
> > authenticate after installing libc6, but we cannot restart xdm with
> > postinst automatically (user's X11 session is destroyed).  I add
> > messages in next 2.3.1-17 as they have to restart xdm with their hand.
> > If you have requests about restarting messages, please tell me.
> 
> Though I don't know enough about the detailed processes running inside
> the library packages: Sounds great. :)
> Perhaps it's possible to delay installation of the libraries until the
> next reboot? The user would have the chance to have the libraries
> installed "instantly" (which would break xdm), "automatically at the
> next reboot" (is that what you meant above?) or "not at all" at the
> moment (though I currently can't think of a good reason why to do that).

You said about "generic problem (memory resident libraries issue)",
and I don't think it should be.  Delay installation everytime requires
system reboot.  But some users know it needs only application restart.

In addition, it's only applied in upgrade between the same library
version.  If this delayed installation is introduced for glibc, then
upgrade from woody to sarge breaks all binaries.  Sarge packages
depends on glibc 2.3.x, and it can't run under woody's glibc 2.2.5
environment.  If you run sarge/sid /bin/ls under woody glibc 2.2.5,
t

Re: stop abusing debconf already

[Colin Watson]

On Sat, Apr 19, 2003 at 02:08:27PM +0100, Matt Ryan wrote:
> Joey Hess wrote:
> >Enough already.
> >
> >Folks, if you don't stop abusing debconf with useless notes that belong
> >in README.Debian and config file overwriting, I will stop maintaining
> >it. 
> >
> >Stop slapping incorrect uses of debconf in everywhere. Feel free to run
> >any package using debconf by me before you upload it, or take the time
> >to understand yourself how things should work.
> 
> Great, helpful input to the debate. Let me see...
> 
> 1) Toys
> 2) Pram
> 3) Throw
> 4) Profit?

Or maybe realize that Joey might perhaps know what he's talking about
with regard to debconf ... you could go find the text of his talk at the
last Debian Conference if you like.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: stop abusing debconf already

[Joey Hess]

Denis Barbier wrote:
> On Fri, Apr 18, 2003 at 07:14:19PM -0400, Joey Hess wrote:
> > Enough already.
> > 
> > Folks, if you don't stop abusing debconf with useless notes that belong
> > in README.Debian and config file overwriting, I will stop maintaining
> > it. 
> > 
> > Stop slapping incorrect uses of debconf in everywhere. Feel free to run
> > any package using debconf by me before you upload it, or take the time
> > to understand yourself how things should work.
> 
> I do not understand exactly what is good and bad use of debconf.
> For instance all questions asked by the debconf package have good default
> values, so there is no reason to prompt user, a configuration file is
> enough.  So what am I missing?

The only reasons debconf itself asks those questions still are:

- example of how debconf works
- they _are_ overridable with the config file, in an appropriate way
- it's not asked at new installs anyway
- people are used to that

I did have some bad ideas about how debconf could be used back years ago
when I wrote it. Those debconf questions (and some really ill-advised
stuff slrn used to do) were the result.

-- 
see shy jo


pgpede47N4y44.pgp
Description: PGP signature

New project proposal: debian-lex

[Jeremy Malcolm]

I am interested in coordinating a new sub-project called Debian-Lex,
which would be Debian for Lawyers, akin to the Debian-Med, Debian-Jr and
DebianEdu projects.  Hopefully, these sub-projects will evolve into
Bdale's idea of flavours (flavors, but I'm Australian) of Debian.

I am a lawyer and also an IT consultant, which makes me one of a small
handful of people who have a foot firmly in both camps.  I have written
for my local Law Society's magazine on free software for the legal
office, but the lack of a packaged Linux system for lawyers does seem to
be impeding the take-up of Linux within law firms, particularly on the
desktop. 

The Debian-Lex project would in part just contain some obvious
selections from the existing pool such as OpenOffice.org, Evolution and
Gnotime, but it would also need some other packages that aren't yet in
Debian such as SQL-Ledger (although this has been ITP'd), and I intend
to put together a database schema that will serve as the basis for a
legal client and matter database.

If there are no major objections within the developer community I will
liaise with the appropriate people to get this moving, and post for
expressions of interest to the debian-users list to see if there are any
other lawyers out there who would like to help.

-- 
JEREMY MALCOLM <[EMAIL PROTECTED]> Personal: http://www.malcolm.id.au
Providing online networks of Australian lawyers (http://www.ilaw.com.au)
and Linux experts (http://www.linuxconsultants.com.au) for instant help!
Disclaimer: http://www.terminus.net.au/disclaimer.html. GPG key: finger.




signature.asc
Description: This is a digitally signed message part