Bug#1075715: ITP: cppi/1.18 -- adjusts or checks indentation of C and C++ preprocessor directives

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: cppi
  Version : 1.18-1
  Upstream Author : Jim Meyering, FSF, et al
* URL : https://www.gnu.org/software/cppi/
* License : GPL-3+
  Programming Lang: C
  Description : adjusts or checks indentation of C and C++ preprocessor 
directives

 GNU cppi adjusts or checks the indentation of C and C++ preprocessor
 directives in a file.
 .
 Indent the C preprocessor directives in FILE to reflect their nesting
 and ensure that there is exactly one space character between each #if,
 #elif, #define directive and the following token, and write the result
 to standard output.  The number of spaces between the `#' and the following
 directive must correspond to the level of nesting of that directive.

I intend to maintain this package on Salsa at
https://salsa.debian.org/debian/cppi

/Simon


signature.asc
Description: PGP signature

Re: Bug#1074175: netkit-rwho: remove for trixie?

[Simon Josefsson]

Hi.

Most tools from netkit are candidates for migration to GNU InetUtils,
and rwho(d) may be another one -- see email and bug report below.
Cc'ing debian-devel to have broader discussion.

First, I think we need to understand the rationale for doing anything
about 'netkit-rwho': do we want to do something because 1) it is not
maintained upstream? or 2) because it is an insecure design?, or 3)
something else?

I believe that like telnet and ftp the second argument is not convincing
enough: sometimes you need these implementations for various strange
things, and it is poor style to dictate what people must do with their
software.  The position I've taken in GNU InetUtils is that it is better
for users to offer maintained tools and include a notice that they are
insecure, rather to offer un-maintained tools and refuse to work further
on them because they are insecure, putting users into a worse situation
than before.  Some people may disagree, and instead believe it is better
to actively kill old things rather than continue support them.  This is
a subjective decision, and if people are willing to do the work to keep
things alive, I think it is better to let them than to refuse this
contribution.

So, are our reason for doing anything about netkit-rwho really because
netkit upstream is not maintained?

If so, then one option is to add a rwho(d) implementation to GNU
InetUtils and let that replace the netkit implementation in Debian.
Historically, netkit tools have often had unclear or weird license
situation, so my preference is to import rwho(d) from some of the BSD
and to make that build for a wide variety of architectures and platforms
like we do with other tools in GNU InetUtils.  The BSD implementations
are usually not intended to be portable, and often have some minor flaw
that makes them troublesome to build on Debian -- we fix those issues in
GNU InetUtils.

That said, introducing yet another fork into the ecosystem shouldn't be
done lightly, so we should explore some way to pool resources (like I've
tried to establish with tnftp(d) maintainers when we have joint bugs).
I haven't analyzed what rwho(d) implementations are out there.  I see
NetBSD/FreeBSD has one still in -current, but OpenBSD removed it during
5.x.  Are people aware of any other implementations worth considering?

What do you think?

/Simon

Gürkan Myczko  writes:

> rwho(d) is a design from a different time, when networks were
> trusted, and so on. It seems to me, we should and could stop
> shipping it for trixie.
>
> I'm raising this bug now, to:
> 1) establish awareness
>
> I was long aware of this, as I was using rwhod/ruptime when networks
> were not split into thousand networks...
>
> 2) auto-rm it from trixie
>
> I'd rather have a migration path, not binary compatible, but
> functionality compatible
>
> 3) give people time to chime in / secure replacements to show up
>
> Please have a look at https://github.com/alexmyczko/rutpime (there's
> an ITP for it, and it has
> been in new queue several times:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013361
>
> After a while I intend to clone this bug to ftp.debian.org for
> removal from unstable.
>
> Please do not remove it if possible. I really wish to have a migration
> path for this, but well
> we're waiting for ftp team.
>
> Best,
> Alex
>
> Chris
>
>


signature.asc
Description: PGP signature

Re: Accepting DEP14?

[Simon Josefsson]

Chris Hofstaedtler  writes:

> On Fri, 16 Aug 2024 23:36:31 +0200, gregor herrmann wrote:
>> IMO, and from discussions in the Debian Perl Group, the blocker is
>> the conversion of existing repos, both on salsa (which should be
>> doable via the API as suggested in the sketches mentioned above) and
>> also locally for hundreds of developer machines [git fails horribly
>> on the upstream/ → upstream/latest change].
>
> I want to echo this pain. When changing the layout it seems almost
> better to start from scratch.
>
> Additionally, in my opinion debian/latest is a mistake we should not
> recommend.

+1

I'm happily working on packages with many different git styles, and I'm
building packages for different suites and vendors: the 'debian/latest'
naming style has not contributed to my work flow.

I do understand the original rationale, I think, since it feels ugly to
put an experimental upload on a debian/unstable git branch.

However I think there are two kind of experimental uploads that are
different in nature:

   1) uploads to experimental that test things intended for sid quite
   soon (maybe architecture build testing like we just did for
   'libmceliece'), and

   2) complete odd-ball uploads that is known to break things, but
   needed for some other experimentation that may be multi-months while
   there could be uploads going into unstable (like we did for the Go
   grpc package during the last months).

I believe for the use-case 1) it is better to use debian/unstable
immediately and for 2) it is better to have one branch debian/unstable
and one branch debian/experimental.  I'm missing what positive effects
arise from using a debian/latest branch.

Maybe this could be clarified in DEP14 that 'debian/latest' is only
recommended for use instead of 'debian/unstable' for 1)-style uploads.
I still wonder if it is actually wortwhile to rescue 'debian/latest'
though.  I've often used 'debian/unstable' instead for this purpose,
since the 1)-style uploads are not uncommon for me.

I think the core problem is that there really is no reasonable concept
of "latest" branch for a Debian package.  There are just many different
versions targetted at different suites or vendors, each of them having
their own meaning of what is latest.

/Simon


signature.asc
Description: PGP signature

Re: Accepting DEP14?

[Simon Josefsson]

Andrey Rakhmatullin  writes:

> On Sat, Aug 17, 2024 at 12:20:16PM +0200, Andreas Tille wrote:
>> My personal preference would be if we make a pristine-tar branch default
>> since this is what I observed in the wide majority of cases.
>
> Note that there are different opionons whether pristine-tar is
> needed/viable/useful. There is at least one objective fact that it's hard
> to keep working.

Did anyone consider a way to only store meta-information about the
source tarballs in the debian/ tree?

I'm thinking the SHA-256 checksum of the tarball should be recorded and
be part of the signed debian.tar.xz upload.

For example, libidn2's debian/source/artifact could contain:

Checksums-SHA256: 
4c21a791b610b9519b9d0e12b8097bf2f359b12f8dd92647611a929e6bfd7d64 2155214 
libidn2_2.3.7.orig.tar.gz

Or something like that.

If the debian/ tree contained a SHA-256 checksum of the upstream release
artifact, it could be used to locate and retrieve the tarballs using any
mechanism available, reducing the need for pristine-tar which is fragile
(how many checks that the checksum of the pristine-tar tarball matches
what's in the debian archive?).

It would also strengthen the integrity of the resulting archive, since
then there is some way to look at a *.debian.tar.* and git debian/
sub-directory and understand what the intended source code it applies to
are.

Manually curating the release artifact checksums is what many other
packaging systems do, and I think it is a good pattern.

/Simon


signature.asc
Description: PGP signature

Bug#1079669: ITP: libntruprime -- Streamlined NTRU Prime (sntrup) microlibrary

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: libntruprime
  Version : 20240825
  Upstream Authort: Daniel J. Bernstein
* URL : https://libntruprime.cr.yp.to/
* License : LicenseRef-PD-hp OR CC0-1.0 OR 0BSD OR MIT-0 OR MIT
  Programming Lang: C
  Description : Streamlined NTRU Prime (sntrup) microlibrary

libntruprime is a microlibrary for the Streamlined NTRU Prime
cryptosystem. Streamlined NTRU Prime (sntrup) is a lattice-based
cryptosystem with the following features:

 - Stability: Almost all details of sntrup match a May 2016
   publication. The only exceptions are small changes to encoding and
   hashing published in April 2019.

 - Patent-freeness: April 2019 predates almost all post-quantum
   patents. Analyses of various lattice patents filed before April 2019
   indicate no problems for sntrup.

 - Deployment: The popular OpenSSH tool switched to sntrup761 by default
   in April 2022, following initial integration of sntrup into TinySSH.

 - Affordability: Keys and ciphertexts are about 1KB for sntrup761, and
   computations are fast.

 - Careful design: Subject to the requirement of being a small
   lattice-based cryptosystem, sntrup is systematically designed to
   eliminate unnecessary complications in security review. It eliminates
   decryption failures, for example, and eliminates cyclotomics. The
   cryptosystem has never needed a security patch.

 - Risk management: A much higher sntrup1277 security level is fully
   supported, and is recommended whenever 2KB keys and ciphertexts are
   affordable, to reduce risks from improvements in lattice attacks.

 - Flexibility: The sntrup design allows a full spectrum of tradeoffs
   between size and security level, so applications with intermediate
   size limits aren't forced into much lower security levels. Six
   different sizes have been selected for support.

libntruprime has a very simple stateless API based on the SUPERCOP API,
with wire-format inputs and outputs, providing functions that directly
match the KEM operations provided by the sntrup specification, such as
functions

sntrup1277_keypair
sntrup1277_enc
sntrup1277_dec

for the sntrup1277 KEM.

Internally, libntruprime includes implementations designed to work
portably across CPUs, and implementations designed for higher
performance on Intel/AMD CPUs with AVX2 instructions. libntruprime
includes automatic run-time selection of implementations.

libntruprime is intended to be called by larger multi-function libraries
(such as traditional cryptographic libraries), including libraries in
other languages via FFI. The idea is that libntruprime takes
responsibility for the details of sntrup computation, including
optimization, timing-attack protection, and (in ongoing work)
verification, freeing up the calling libraries to concentrate on
application-specific needs such as protocol integration. Applications
can also call libntruprime directly.

I hope to maintain this at https://salsa.debian.org/jas/libntruprime

/Simon


signature.asc
Description: PGP signature

Re: Non-free IETF RFC/I-Ds in source packages

[Simon Josefsson]

Simon Josefsson <[EMAIL PROTECTED]> writes:

> Bug #390664 inspired me to look in source packages for IETF RFC/I-D's
> too, and the situation seem to be more problematic.  I've put a list
> of packages in testing (as of a few days ago, my mirror is slow) that
> appear to contain IETF RFC or I-D's at:
>
> http://josefsson.org/bcp78broken/ietf-in-src.txt
>
> There are certainly false positives in that list (I know of some), and
> some have already been reported.  The regexp I used was:
>
> -e rfc[0-9]+\.txt \
> -e draft-.*[0-9][0-9]\.txt \
>
> But still, that's 73 source packages.
>
> I will try to go through them and report bugs, but I could use help in
> analysing the packages for false positives.  Perhaps a page on
> wiki.debian.org could be used to co-ordinate this.

I've created a wiki page to co-ordinate the effort, see:

http://wiki.debian.org/NonFreeIETFDocuments

In particular, I'd like help on improving the bug report template.

Unless it turns it is a bad idea to do so (thoughts welcome!), I'll
send the bug reports next weekend.

I've cc:ed debian-devel to reach a wider audience.

/Simon


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

Re: Non-free IETF RFC/I-Ds in source packages

[Simon Josefsson]

Gervase Markham <[EMAIL PROTECTED]> writes:

> Simon Josefsson wrote:
>> http://wiki.debian.org/NonFreeIETFDocuments
>
> A useful thing to add to that page would be simple instructions on how
> those authoring IETF documents could make them available under a
> DFSG-free licence (presumably in parallel to the IETF one) - perhaps
> some sample boilerplate text to include.

Good idea!

I've added two new sections to the wiki page:

1. Template for license to include in RFCs. [1]

2. Template for e-mail to request additional rights from RFC
authors. [2]

The text is just in draft form, so please review it.  Possibly, we
could use something simpler in [2], or even in [1] too.

/Simon

[1]:

x. Copying conditions

The author(s) agree to grant third parties the irrevocable
right to copy, use and distribute the work, with
or without modification, in any medium, without royalty,
provided that, unless separate permission is granted,
redistributed modified works do not contain misleading
author, version, name of work, or endorsement information.

[2]:

Subject: Requesting additional rights to RFC 

Dear Author,

The Debian GNU/Linux distribution wishes to incorporate the
IETF RFC  as part of its distribution, and to allow
users to develop, modify and evolve the document.

Because the authors of contributions to the IETF standards retain
most intellectual property rights with respect to such contributions
under IETF policies in effect during the development of RFC , and
because you are an author of said document, the Debian community hereby
requests that you kindly agree to release your contributions in
RFC  under the license below, for inclusion in Debian.

I agree to grant third parties the irrevocable
right to copy, use and distribute the work, with
or without modification, in any medium, without royalty,
provided that, unless separate permission is granted,
redistributed modified works:

 (a) do not contain misleading author, version, name
 of work, or endorsement information, and

 (b) do not claim endorsement of the modified work by
 the Contributor, or any organization the
 Contributor belongs to, the Internet Engineering
 Task Force (IETF), Internet Research Task Force
 (IRTF), Internet Engineering Steering Group
 (IESG), Internet Architecture Board (IAB),
 Internet Assigned Numbers Authority (IANA),
 Internet Society (ISOC), Request For Comments
 (RFC) Editor, or any combination or variation of
 such terms (including without limitation the
 IETF "4 diamonds" logo), or any terms that are
 confusingly similar thereto, and

 (c) remove any claims of status as an Internet
 Standard, including without limitation removing
 the RFC boilerplate.

The IETF suggests that any citation or excerpt of
unmodified text reference the RFC or other document from
which the text is derived.

To indicate that you agree to these terms, please reply to this e-mail
and quote the license above and indicate that you agree to this.

If you prefer another widely recognized free license instead, such
as the revised BSD license, the GPL, the MIT/X11 license, that
is also fine.

 Sincerely yours,
   Simon Josefsson


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

Re: Bug#393411: Source package contains non-free IETF RFC/I-D's

[Simon Josefsson]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Simon Josefsson ([EMAIL PROTECTED]) [061016 13:19]:
>> I went over many packages looking for names of likely non-free files,
>> and there may be false positives.  If this is the case for your
>> package, I'm sorry for the noise.
>
> Sorry, but that is unacceptable behaviour.

Do you have suggestions to improve the situation?

The false positives so far seem to be one file
(draft-morgan-ident-ext-04.txt) that contains two license statements
in the file, and one packages for which this was already fixed in
unstable.

The first case is probably difficult to fully prevent, even manual
inspection might miss something like that.

The second problem seems to be generic.  The reason I looked at
packages in testing was that they are the packages that are going to
be released, and if I look at what's in unstable, it seems that I
might miss what's going to be in etch (e.g., e2fsprogs seems to be
frozen, and the version in unstable now doesn't seem to be going into
etch).

Should I look at packages in unstable, and only if the package is
frozen, look at the one in testing, instead?

I've described how my scripts work in more detail on:
http://wiki.debian.org/NonFreeIETFDocuments
Any comment or improvements to them would be appreciated.

/Simon


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

Re: Mass-filing RC bugs about IETF RFC license based on file name

[Simon Josefsson]

Petter Reinholdtsen <[EMAIL PROTECTED]> writes:

> [Simon Josefsson]
>> Do you have suggestions to improve the situation?
>
> I would suspect manual inspection of each file, and only file bugs for
> the files with real license problems.  Using the file name to guess
> about the existence of a serious bug is not acceptable.
>
> How many bugs did you file?  A quick look in
> http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]>
> indicate 67 bugs.

Yes, that's all of them.

>> The false positives so far
>
> So far.  How many of these cases did you manually inspect?

About half of them before submitting, which actually did include both
the false positives.  For the first case, I missed the license note in
the file itself (there was nothing in copyright), and the second case
was that I used the package in testing instead of the one in unstable.
As it happens, for this particular package, the package in unstable
still contained non-free IETF files, so the bug report was correct.

I pruned a few packages that contained files such as rfc* or where
the file was named like an RFC, but did not actually contain the RFC
contents.

I'll go through the rest of the files now, to make sure I've went over
all of them manually.

/Simon


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

Re: Mass-filing RC bugs about IETF RFC license based on file name

[Simon Josefsson]

I've reviewed the copyright file for the 66 bugs that I reported,
manually, and I also inspected at least one claimed non-free file in
each package.  I should have done this from the start, but I felt
(over-)confident that there wouldn't be false positives.

I found one file that likely is a false positive, in the quagga (bug
#393411) package.  It isn't clear if the file draft-zebra-00.txt is
from IETF or not, and has no standard copyright notice nor license.
It has the same boilerplate and look as an IETF draft, but the
reference to IETF have been removed.  Most likely, this was a false
positive, and I'll explain this in the bug tracker, and change it to a
wishlist bug to explain this in the copyright file.

libdatetime-format-mail-perl (bug #393382) is the next closest to a
false positive that I came.  The files (RFC 822 and RFC 2822) does not
contain the entire RFC, but they contain an extract from the RFCs.
The IETF lawyer has interpreted the RFC 2026 license to permit code
extracts from RFCs, but these extracts contains texts as well, so I
believe they are not OK.

For bug #393377, the jta package, bug #393421, the xrn package, and
bug #393386, the libemail-find-perl package, the source package
contains (only) old rfcs.  The files do not have any copyright notice
or license statement in them, and the copyright file doesn't mention
the files either.  But those RFCs were published before 1989, and may
thus be assumed to be in the public domain.  However, I've asked the
RFC editor about this situation before [1], and they claim earlier
RFCs are covered by the more recent copyright statement anyway.  So
without more information, I think those two bug reports are correct
anyway.

For some packages, the problem may have been fixed in unstable, like
for openldap2.3 and e2fsprogs, but the report made sense anyway, for
different reasons.  For openldap2.3, the package in unstable was not
fully fixed, and for e2fsprogs, the package in testing is frozen so a
fixed package in unstable doesn't help.

Btw, for subversion, the copyright file gives a 404:
<http://packages.qa.debian.org/s/subversion.html>.  Probably a
temporary problem...

/Simon

[1]  Old e-mail:

From: RFC Editor 
Subject: Re: Copyright and copying conditions for RFC 1510?
To: Simon Josefsson <[EMAIL PROTECTED]>
Cc: RFC Editor 
Date: Mon, 16 Dec 2002 11:07:28 -0800

Simon,

The copyright statement applies retroactively.  Please follow the
instructions as stated at:

   ftp://ftp.rfc-editor.org/in-notes/rfc-editor/rfc-copyright-story

Thank you.

RFC Editor


On Sun, Dec 15, 2002 at 10:38:30AM +0100, Simon Josefsson wrote:
> rfc1510.txt does not mention copyright or copying condition. Does the
> copyright notice in
> 
> ftp://ftp.rfc-editor.org/in-notes/rfc-editor/rfc-copyright-story
> 
> apply retroactively?  If not, do you know who owns the copyright of
> the document and what the copying conditions are?
> 
> Thanks.


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

Re: Bug#393411: Source package contains non-free IETF RFC/I-D's

[Simon Josefsson]

Martin Zobel-Helas <[EMAIL PROTECTED]> writes:

> Hi Simon,
>
> On Mon, Oct 16, 2006 at 01:48:50PM +0200, Simon Josefsson <[EMAIL PROTECTED]> 
> wrote:
>
>> Andreas Barth <[EMAIL PROTECTED]> writes:
>> 
>> > * Simon Josefsson ([EMAIL PROTECTED]) [061016 13:19]:
>> >> I went over many packages looking for names of likely non-free files,
>> >> and there may be false positives.  If this is the case for your
>> >> package, I'm sorry for the noise.
>> >
>> > Sorry, but that is unacceptable behaviour.
>> 
>> Do you have suggestions to improve the situation?
>
> Reading and understanding 7.1.1 of the Developer's Reference.
>
> There it says:
> | If you report more than 10 bugs on the same topic at once, it is
> | recommended that you send a message to debian-devel@lists.debian.org
> | describing your intention before submitting the report, and mentioning
> | the fact in the subject of your mail.
>
> Common understanding of this is, that the Subject of an E-Mail should
> contain the the words "Mass Bug Filing".

I did post one week ago to the list and mentioned that 73 source
packages were affected, and that I'll file bugs unless someone
objects:

http://thread.gmane.org/gmane.linux.debian.devel.legal/27498/focus=27568

Mass-filing bugs regarding this has also been discussed before:

http://thread.gmane.org/gmane.linux.debian.devel.legal/25993/focus=99847

If the common understanding is that the Subject: should include "Mass
bug filing", perhaps that could be codified in the Developer's
Reference, to avoid similar problems in the future.

I'd agree that I should have manually checked all files before
submitting the reports, though.

/Simon

PS.  For some reason, both posts ended up in the g.l.d.d.legal
hierarchy on gmane, but they were posted to debian-devel, which the
pages themselves also indicate.


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

Source package contains non-free IETF RFC/I-D's

[Simon Josefsson]

Some raised a concern with false positives in my reports -- and also
tagged all the bugs with etch-ignore.  I went through all bug reports
manually yesterday (see earlier mail), but I also realized that it
would be possible to do this automatically, to provide further
assurance that the bugs indicate real and confirmed problems.

I've updated my script to do this, view it last on the page:
http://wiki.debian.org/NonFreeIETFDocuments

The script will run md5sum on the RFC/I-D in source packages, and
compare them against a known-real repository (rsync'ed against
ftp.rfc-editor.org).

The output of the script is very long, so I won't include it here.  An
URL to it is:
http://josefsson.org/bcp78broken/debian-ietf-documents-diff.txt

To parse the output yourself, look for lines beginning with 'pkg'.
Those denote the start of a new package with potential problems.
After that there will be lines such as 'tar xfz...' and two MD5 sums.
If the MD5 sums match, it will print MATCH.  If the MD5 sums mismatch,
it will print MISMATCH.  If it can't find a known-good file to compare
with, it prints FETCH-FAIL.

Some statistics:
  74 packages
 401 MATCH, i.e., the RFC in the source package is an authentic RFC
  79 MISMATCH, i.e., the RFC differ from the authentic RFC
   6 FETCH-FAIL

Note that this does _not_ mean that there were 79 false positives in
my reports.  Nothing I did today indicates that there are any more
false positives except (possibly) draft-zebra-00.txt that I found
manually yesterday.

The FETCH-FAIL's are few and easy to analyze:

FETCH-FAIL draft-davis-dasl-protocol-00.txt
FETCH-FAIL spf-draft-20040209.txt
FETCH-FAIL spf-draft-200405.txt
FETCH-FAIL rfc.txt
FETCH-FAIL rfc.txt
FETCH-FAIL draft-zebra-00.txt

I can't find the first document anywhere on the Internet, possibly the
filename is incorrect, although it looks like a submitted IETF
document.  spf-* were submitted through the IETF under other names.
rfc.txt is a dummy file.  draft-zebra-00.txt was the likely false
positive I found manually yesterday.

The MISMATCH'es are more interesting to analyze, and indicate a
variety of reasons.

As can be seen in the file, just a few pages down, one reason is that
the RFC in the source package differs from the authenticate RFC!
E.g., typos has been corrected.  Modifying the document is not
permitted by the IETF license, so these files do not seem to be
legally distributable at all, not even in non-free.

Several files differ trivially, such as removed/added initial/terminal
newlines, or changing multiple newlines into one newline.

At least one file differ due to RCS $Id$ tags.

In the DateTime-Format-Mail archive, the files differ substantially
because the source package only contains a small excerpt from the RFC,
instead of the entire RFC.

Some files differ because I can't compare them to the real document,
because the IETF used to put a "RIP-notice" that the document has
expired using the same filename.  The diff output for all of them
suggests that these are real IETF documents, though.

/Simon


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

Re: Bug#393411: Source package contains non-free IETF RFC/I-D's

[Simon Josefsson]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
>> The second problem seems to be generic.  The reason I looked at
>> packages in testing was that they are the packages that are going to
>> be released, and if I look at what's in unstable, it seems that I
>> might miss what's going to be in etch (e.g., e2fsprogs seems to be
>> frozen, and the version in unstable now doesn't seem to be going into
>> etch).
>>
>> Should I look at packages in unstable, and only if the package is
>> frozen, look at the one in testing, instead?
>
> You should check the packages in testing.

This is what I'm doing now.

> Then check the packages in unstable.

I'm doing this step manually now.

> Note what packages fixed the problem in unstable, file an RC bug for
> the testing version and close it for the unstable version. That then
> reflects the reality and will keep track of the problem.

Hm, I know how to submit a bug for the version in testing (this is
what I've done), but I don't know how to close it for the unstable
version.  How do I do that?

> Note what packages started to be buggy in sid. Hopefully none.

Exactly -- I intend to mirror and check unstable for regressions in
this area.  I submitted a lintian check for this, if something like it
can be installed, it would also help avoid this problem in the future.

/Simon


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

Re: Source package contains non-free IETF RFC/I-D's

[Simon Josefsson]

On 17 okt 2006, at 18.47, Luk Claes wrote:


Some statistics:
  74 packages
 401 MATCH, i.e., the RFC in the source package is an authentic RFC
  79 MISMATCH, i.e., the RFC differ from the authentic RFC
   6 FETCH-FAIL


Note that not all authentic RFC documents have the same license,  
some of them

are probably even DFSG compliant...


Can you name one such license that is DFSG-free?

RFC's published before 1989 may be in the public domain, since they  
don't contain a copyright notice, but the RFC editor claim that the  
new copying conditions apply retroactively.


RFC's published after 1989 are protected by copyrights, but as far as  
I know, none of the RFC licenses are free.  The RFC 2026 and the RFC  
3978 licenses has been discussed before.  That leaves, I believe,  
only the license specified by RFC 1602, which reads:


"Copyright (c) ISOC (year date).  Permission is granted
to reproduce, distribute, transmit and otherwise
communicate to the public any material subject to
copyright by ISOC, provided that credit is given to the
source.  For information concerning required

That appears to be non-free.

I note that RFC 1602 do seem to give the ISOC the right to release  
those RFCs under a liberal license:


 l.   Contributor agrees to grant, and does grant to ISOC, a
  perpetual, non-exclusive, royalty-free, world-wide right
  and license under any copyrights in the contribution to
  reproduce, distribute, perform or display publicly and
  prepare derivative works that are based on or incorporate
  all or part of the contribution, and to reproduce,
  distribute and perform or display publicly any such
  derivative works, in any form and in all languages,  
and to

  authorize others to do so.

Perhaps talking to ISOC about this would help.


So there can be more than 79 false positives...


I don't yet see any way for that to hold.

/Simon


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

Packages containing RFCs

[Simon Josefsson]

This was originally on debian-legal, but it was suggested to ask here
before mass-filing bug reports.  Opinions?  Should we file bugs for
this?  What severity?

MJ Ray <[EMAIL PROTECTED]> writes:

> I think you should file bug reports, but I think you should ask a
> wider or higher audience (maybe -devel or -release) before mass-filing.
> Most of those bugs look serious (debian-policy s2.1+2.2) to me.
> I can't remember if anyone is coordinating [NONFREE-DOC] bugs.

Here's the rest of my original e-mail:

I just noticed that heimdal-docs contained copies of RFCs, which I
believe are licensed under a non-free license, so I filed bug #364860.

Then I looked at what other packages in testing may have the same
problem, and the list below is what I found.  It is not that large,
and better than I would expect.

Should we file bug reports for these packages, or is there a better
way to handle this?  What severity should I use?

Some additional filtering should probably be done, some earlier RFC
are (I believe) in the public domain.

Thanks,
Simon

usr/lib/GNUstep/System/Library/Documentation/Developer/rfc1459.txt [84]libs/gnu
usr/share/doc/araneida/doc/rfc2388.txt.gz   [148]web/araneida
usr/share/doc/araneida/doc/rfc2616.txt.gz   [149]web/araneida
usr/share/doc/camstream-doc/tech/rfc959.txt.gz  [161]doc/camstream-
usr/share/doc/cl-aserve/rfc2396.txt.gz  [162]web/cl-aserve
usr/share/doc/cl-irc/doc/rfc2810.txt.gz [163]devel/cl-irc
usr/share/doc/cl-irc/doc/rfc2811.txt.gz [164]devel/cl-irc
usr/share/doc/cl-irc/doc/rfc2812.txt.gz [165]devel/cl-irc
usr/share/doc/cl-irc/doc/rfc2813.txt.gz [166]devel/cl-irc
usr/share/doc/dhcp3-common/doc/rfc1542.txt.gz   [173]net/dhcp3-comm
usr/share/doc/dhcp3-common/doc/rfc2131.txt.gz   [174]net/dhcp3-comm
usr/share/doc/dhcp3-common/doc/rfc2132.txt.gz   [175]net/dhcp3-comm
usr/share/doc/dhcp3-common/doc/rfc2485.txt.gz   [176]net/dhcp3-comm
usr/share/doc/dhcp3-common/doc/rfc2489.txt.gz   [177]net/dhcp3-comm
usr/share/doc/dhcp3-common/doc/rfc951.txt.gz[178]net/dhcp3-comm
usr/share/doc/erlang-doc-html/html/lib/megaco-3.0.1/doc/standard/rfc3015.txt.gz
usr/share/doc/freeradius/rfc/rfc1157.txt.gz [195]net/freeradius
usr/share/doc/freeradius/rfc/rfc1227.txt.gz [196]net/freeradius
usr/share/doc/freeradius/rfc/rfc1448.txt.gz [197]net/freeradius
usr/share/doc/freeradius/rfc/rfc1901.txt.gz [198]net/freeradius
usr/share/doc/freeradius/rfc/rfc1905.txt.gz [199]net/freeradius
usr/share/doc/freeradius/rfc/rfc2058.txt.gz [200]net/freeradius
usr/share/doc/freeradius/rfc/rfc2059.txt.gz [201]net/freeradius
usr/share/doc/freeradius/rfc/rfc2138.txt.gz [202]net/freeradius
usr/share/doc/freeradius/rfc/rfc2139.txt.gz [203]net/freeradius
usr/share/doc/heimdal-docs/standardisation/rfc1508.txt.gz   [205]net/heimdal-do
usr/share/doc/heimdal-docs/standardisation/rfc1509.txt.gz   [206]net/heimdal-do
usr/share/doc/heimdal-docs/standardisation/rfc1510.txt.gz   [207]net/heimdal-do
usr/share/doc/heimdal-docs/standardisation/rfc1750.txt.gz   [208]net/heimdal-do
usr/share/doc/heimdal-docs/standardisation/rfc1831.txt.gz   [209]net/heimdal-do
usr/share/doc/heimdal-docs/standardisation/rfc1964.txt.gz   [210]net/heimdal-do
usr/share/doc/heimdal-docs/standardisation/rfc2078.txt.gz   [211]net/heimdal-do
usr/share/doc/heimdal-docs/standardisation/rfc2203.txt.gz   [212]net/heimdal-do
usr/share/doc/heimdal-docs/standardisation/rfc2228.txt.gz   [213]net/heimdal-do
usr/share/doc/heimdal-docs/standardisation/rfc2478.txt.gz   [214]net/heimdal-do
usr/share/doc/heimdal-docs/standardisation/rfc2743.txt.gz   [215]net/heimdal-do
usr/share/doc/heimdal-docs/standardisation/rfc2744.txt.gz   [216]net/heimdal-do
usr/share/doc/heimdal-docs/standardisation/rfc3244.txt.gz   [217]net/heimdal-do
usr/share/doc/heimdal-docs/standardisation/rfc3961.txt.gz   [218]net/heimdal-do
usr/share/doc/heimdal-docs/standardisation/rfc3962.txt.gz   [219]net/heimdal-do
usr/share/doc/ircd-irc2/rfc1459.txt.gz  [221]net/ircd-irc2
usr/share/doc/ircd-irc2/rfc2810.txt.gz  [222]net/ircd-irc2
usr/share/doc/ircd-irc2/rfc2811.txt.gz  [223]net/ircd-irc2
usr/share/doc/ircd-irc2/rfc2812.txt.gz  [224]net/ircd-irc2
usr/share/doc/ircd-irc2/rfc2813.txt.gz  [225]net/ircd-irc2
usr/share/doc/ircd-ircu/rfc1413.txt.gz  [226]net/ircd-ircu
usr/share/doc/lksctp-tools-doc/rfc2960.txt.gz   [357]doc/lksctp-too
usr/share/doc/lksctp-tools-doc/rfc3257.txt.gz   [358]doc/lksctp-too
usr/share/doc/lksctp-tools-doc/rfc3286.txt.gz   [359]doc/lksctp-too
usr/share/doc/lksctp-tools-doc/rfc3309.tx

Re: Packages containing RFCs

[Simon Josefsson]

I went over the package list more carefully, and it seems the only two
public domain RFCs that are included in Debian testing:

usr/share/doc/dhcp3-common/doc/rfc951.txt.gznet/dhcp3-common
usr/share/doc/camstream-doc/tech/rfc959.txt.gz  doc/camstream-doc

The following packages appear to contain IETF RFCs/drafts, and I'll
file bug reports for them:

comm/sendpage-common
devel/cl-irc
doc/doc-iana
doc/erlang-doc-html
doc/libpt-doc
doc/lksctp-tools-doc
editors/xemacs21-basesupport
interpreters/cl-s-base64
interpreters/cl-s-http-server
libs/gnustep-netclasses
libs/libsasl2
mail/fml
mail/messagewall
net/atftpd
net/bidentd
net/dhcp3-common
net/freeradius
net/heimdal-docs
net/ircd-irc2
net/ircd-ircu
net/openswan
net/stunnel
net/zenirc
text/xml2rfc
web/araneida
web/cl-aserve
web/phpgroupware-calendar

The complete file list below.

/Simon

usr/lib/GNUstep/System/Library/Documentation/Developer/rfc1459.txt 
libs/gnustep-netclasses
usr/share/doc/araneida/doc/rfc2388.txt.gz   web/araneida
usr/share/doc/araneida/doc/rfc2616.txt.gz   web/araneida
usr/share/doc/atftpd/rfc1350.html   net/atftpd
usr/share/doc/atftpd/rfc2090.html   net/atftpd
usr/share/doc/atftpd/rfc2347.html   net/atftpd
usr/share/doc/atftpd/rfc2348.html   net/atftpd
usr/share/doc/atftpd/rfc2349.html   net/atftpd
usr/share/doc/bidentd/rfc1413.gznet/bidentd
usr/share/doc/cl-aserve/rfc2396.txt.gz  web/cl-aserve
usr/share/doc/cl-irc/doc/rfc2810.txt.gz devel/cl-irc
usr/share/doc/cl-irc/doc/rfc2811.txt.gz devel/cl-irc
usr/share/doc/cl-irc/doc/rfc2812.txt.gz devel/cl-irc
usr/share/doc/cl-irc/doc/rfc2813.txt.gz devel/cl-irc
usr/share/doc/dhcp3-common/doc/rfc1542.txt.gz   net/dhcp3-common
usr/share/doc/dhcp3-common/doc/rfc2131.txt.gz   net/dhcp3-common
usr/share/doc/dhcp3-common/doc/rfc2132.txt.gz   net/dhcp3-common
usr/share/doc/dhcp3-common/doc/rfc2485.txt.gz   net/dhcp3-common
usr/share/doc/dhcp3-common/doc/rfc2489.txt.gz   net/dhcp3-common
usr/share/doc/erlang-doc-html/html/lib/megaco-3.0.1/doc/standard/rfc3015.txt.gz 
doc/erlang-doc-html
usr/share/doc/freeradius/rfc/draft-sterman-aaa-sip-00.txt.gz net/freeradius
usr/share/doc/freeradius/rfc/pppext-eap-sim-12.txt.gz   net/freeradius
usr/share/doc/freeradius/rfc/rfc1157.txt.gz net/freeradius
usr/share/doc/freeradius/rfc/rfc1227.txt.gz net/freeradius
usr/share/doc/freeradius/rfc/rfc1448.txt.gz net/freeradius
usr/share/doc/freeradius/rfc/rfc1901.txt.gz net/freeradius
usr/share/doc/freeradius/rfc/rfc1905.txt.gz net/freeradius
usr/share/doc/freeradius/rfc/rfc2058.txt.gz net/freeradius
usr/share/doc/freeradius/rfc/rfc2059.txt.gz net/freeradius
usr/share/doc/freeradius/rfc/rfc2138.txt.gz net/freeradius
usr/share/doc/freeradius/rfc/rfc2139.txt.gz net/freeradius
usr/share/doc/heimdal-docs/standardisation/draft-ietf-krb-wg-rfc1510ter-00.txt.gz
 net/heimdal-docs
usr/share/doc/heimdal-docs/standardisation/rfc1508.txt.gz   net/heimdal-docs
usr/share/doc/heimdal-docs/standardisation/rfc1509.txt.gz   net/heimdal-docs
usr/share/doc/heimdal-docs/standardisation/rfc1510.txt.gz   net/heimdal-docs
usr/share/doc/heimdal-docs/standardisation/rfc1750.txt.gz   net/heimdal-docs
usr/share/doc/heimdal-docs/standardisation/rfc1831.txt.gz   net/heimdal-docs
usr/share/doc/heimdal-docs/standardisation/rfc1964.txt.gz   net/heimdal-docs
usr/share/doc/heimdal-docs/standardisation/rfc2078.txt.gz   net/heimdal-docs
usr/share/doc/heimdal-docs/standardisation/rfc2203.txt.gz   net/heimdal-docs
usr/share/doc/heimdal-docs/standardisation/rfc2228.txt.gz   net/heimdal-docs
usr/share/doc/heimdal-docs/standardisation/rfc2478.txt.gz   net/heimdal-docs
usr/share/doc/heimdal-docs/standardisation/rfc2743.txt.gz   net/heimdal-docs
usr/share/doc/heimdal-docs/standardisation/rfc2744.txt.gz   net/heimdal-docs
usr/share/doc/heimdal-docs/standardisation/rfc3244.txt.gz   net/heimdal-docs
usr/share/doc/heimdal-docs/standardisation/rfc3961.txt.gz   net/heimdal-docs
usr/share/doc/heimdal-docs/standardisation/rfc3962.txt.gz   net/heimdal-docs
usr/share/doc/ircd-irc2/rfc1459.txt.gz  net/ircd-irc2
usr/share/doc/ircd-irc2/rfc2810.txt.gz  net/ircd-irc2
usr/share/doc/ircd-irc2/rfc2811.txt.gz  net/ircd-irc2
usr/share/doc/ircd-irc2/rfc2812.txt.gz  net/ircd-irc2
usr/share/doc/ircd-irc2/rfc2813.txt.gz  net/ircd-irc2
usr/share/doc/ircd-ircu/rfc1413.txt.gz  net/ircd-ircu
usr/share/doc/ircd-ircu/rfc1459.unet.gz net/ircd-ircu
usr/share/d

Re: Packages containing RFCs

[Simon Josefsson]

Florian Weimer <[EMAIL PROTECTED]> writes:

> * Simon Josefsson:
>
>> text/xml2rfc
>
> From the debian/copyright file:
>
> | The software is released under the following license.  Note that the
> | output produced by xml2rfc may include more restrictive copyright
> | statements, to conform with ISOC and IETF requirements.  This is why
> | some of the compiled example files are shipped with nominally non-free
> | copyright statements, even though the conditions given below still
> | apply.
>
> And a typical BSD-style license follows.
>
> (Non-free material has already been removed from the distribution.)

Ah, thanks, I was just about to file a report about it.

Does the BSD-license apply to RFC 2629 (included in the package) as
well?  Presumably all contributors:

   The author gratefully acknowledges the contributions of: Alan
   Barrett, Brad Burdick, Brian Carpenter, Steve Deering, Patrik
   Faltstrom, Jim Gettys, Carl Malamud, Chris Newman, Kurt Starsinic,
   and, Frank Strauss.

would have to agree to that license too, if they contributed a
significant part of the document.

/Simon


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

Re: Packages containing RFCs

[Simon Josefsson]

Riku Voipio <[EMAIL PROTECTED]> writes:

> On Friday 28 April 2006 13:34, Simon Josefsson wrote:
>> The following packages appear to contain IETF RFCs/drafts, and I'll
>> file bug reports for them:
>
> As per good mass filing practices, can you create a linda/lintian test out of
> your method you used to search for the rfc's ? This would have several
> advantages: 
>
> 1) Active maintainers will fix the problem before you start your mass filing.
> 2) It will be harder to accidentally re-introduce the rfc files when upstream 
> releases new tarballs, or when new packages are added to archive.

Good idea!

My method was to look for files named ^.*/rfc[0-9]+.(html|txt)(.gz)?$.

I think the patch to lintian below achieve this, but I have no idea
whether it is a good idea.  I'll report this to as a lintian bug.

/Simon

--- files.orig  2006-04-28 16:07:01.0 +0200
+++ files   2006-04-28 16:07:20.0 +0200
@@ -464,6 +464,11 @@
tag "extra-license-file", "$file";
 }
 
+#  non-free RFC files
+if ($file =~ m,.*/rfc[0-9]+(\.(txt|html(\.gz|\.bz2)?))?$,i) {
+   tag "non-free-rfc-file", "$file";
+}
+
 
 #  plain files
 if ($perm =~ m/^-/) {
--- files.desc.orig 2006-04-28 16:07:06.0 +0200
+++ files.desc  2006-04-28 16:05:11.0 +0200
@@ -352,6 +352,14 @@
  debian/copyright file.  This usually makes it unnecessary
  for the package to install this information in other places as well.
 
+Tag: non-free-rfc-file
+Type: warning
+Ref: policy 2.2
+Info: This filename looks like an IETF RFC.  The IETF RFCs are not
+ licensed under a DFSG free license, so they should not be part of
+ packages in main.  See also http://release.debian.org/removing-non-free-documentation";>
+ http://release.debian.org/removing-non-free-documentation.
+
 Tag: non-standard-toplevel-dir
 Type: error
 Info: The Filesystem Hierarchy Standard forbids the installation of new


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

Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes

[Simon Josefsson]

Frank Küster <[EMAIL PROTECTED]> writes:

> Michael Banck <[EMAIL PROTECTED]> wrote:
>
>> On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote:
>>> also sprach Kari Pahula <[EMAIL PROTECTED]> [2006.05.11.1535 +0200]:
>>> > * License : GPL v2 or later
>>> 
>>> That will make it pretty useless for non-GPL applications. 
>>
>> Non-GPL compatible applications, you mean?
>
> Which non-GPL license can I choose for a software that uses this
> library? 

Any license that is compatible with the GPL, such as the revised BSD
license.

>> Seconds, since when do we consider the GPL to be viral?
>
> Don't know about you, but the FSF does - it has created the LGPL because
> of this.

That doesn't mean libraries shouldn't be licensed under the GPL, see
.

/Simon


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

Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes

[Simon Josefsson]

Frank Küster <[EMAIL PROTECTED]> writes:

> Simon Josefsson <[EMAIL PROTECTED]> wrote:
>
>> Frank Küster <[EMAIL PROTECTED]> writes:
>>
>>> Michael Banck <[EMAIL PROTECTED]> wrote:
>>>
>>>> On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote:
>>>>> also sprach Kari Pahula <[EMAIL PROTECTED]> [2006.05.11.1535 +0200]:
>>>>> > * License : GPL v2 or later
>>>>> 
>>>>> That will make it pretty useless for non-GPL applications. 
>>>>
>>>> Non-GPL compatible applications, you mean?
>>>
>>> Which non-GPL license can I choose for a software that uses this
>>> library? 
>>
>> Any license that is compatible with the GPL, such as the revised BSD
>> license.
>
> But the software is a derivative work of the GPL.  Doesn't it need to be
> licensed under the GPL, too?

As a derived work of a GPL'd work, the aggregate is covered by the GPL
license.  But the source code files doesn't have to be licensed under
the GPL.  If someone replace the calls to the GPL'd library in the BSD
code with calls to a BSD library, they don't have to distribute the
new package under the GPL.

/Simon


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

Re: Another gnutls ABI change / (small) mass bug filing

[Simon Josefsson]

Matthias Urlichs <[EMAIL PROTECTED]> writes:

> Hi,
>
> gnutls changed their ABI again.
...
> Gnutls in Debian is properly versioned (as opposed to Upstream, which
> dropped the versioning script for no good reason), and thus I am

The change was discussed on the mailing list:

http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/464

If you had reported this problem to us, we would fix it.

Thanks,
Simon



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

Re: Another gnutls ABI change / (small) mass bug filing

[Simon Josefsson]

Matthias Urlichs <[EMAIL PROTECTED]> writes:

>> The change was discussed on the mailing list:
>> 
>> http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/464
>> 
>> If you had reported this problem to us, we would fix it.
>> 
> Sorry about that -- I didn't read the list consistently.
> My fault. :-/
>
> I'll send a patch.

Excellent!  It would be nice to have a standard mechanism to do symbol
versioning for libraries, right now it require some ad-hoc m4 autoconf
stuff that I'd rather avoid.

Thanks,
Simon


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

Interest in packaging GNU Shishi and GNU Generic Security Service?

[Simon Josefsson]

Hi.  I'd like to get in contact with someone who would be interested
in creating and supporting Debian packages for my Kerberos 5
implementation, and its related GSS-API library.  Web pages are
available at:

http://www.gnu.org/software/shishi/
http://www.gnu.org/software/gss/

Shishi and GSS can be used by GNU SASL, GNU Mailutils, Fetchmail, Curl
and maybe other projects.

It would be good if you are familiar with MIT Kerberos or Heimdal in
general, and their Debian packages in particular.

One advantage with my Kerberos 5 implementation compared to
MIT/Heimdal is that it support Kerberos 5 over TLS, which means that
you can use X.509 or (work in progress) OpenPGP keys, rather than
passwords to get a Kerberos ticket.

Thanks,
Simon


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

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Simon Josefsson]

"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:

> On Mon, Aug 29, 2005 at 03:43:43PM +0200, Simon Josefsson wrote:
>> One advantage with my Kerberos 5 implementation compared to
>> MIT/Heimdal is that it support Kerberos 5 over TLS, which means that
>> you can use X.509 or (work in progress) OpenPGP keys, rather than
>> passwords to get a Kerberos ticket.
>
> Oooh, that's neat. Will this work with, say, an OpenPGP smart card as
> well?

Yes, that is the intention, and I'm currently working on that.  Werner
Koch jas sent me a few smart cards and a reader, so I'm playing with
this setup.

Regards,
Simon


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

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Simon Josefsson]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
>> Hi.  I'd like to get in contact with someone who would be interested in
>> creating and supporting Debian packages for my Kerberos 5
>> implementation, and its related GSS-API library.  Web pages are
>> available at:
>
>> http://www.gnu.org/software/shishi/
>> http://www.gnu.org/software/gss/
>
>> Shishi and GSS can be used by GNU SASL, GNU Mailutils, Fetchmail, Curl
>> and maybe other projects.
>
> I *might* be interested in this, although I'm fairly busy at the moment.
> But I certainly have a strong interest in good Kerberos implementations
> and have a lot of experience with the existing packages.
>
> I'd be very interested in making sure that it can co-exist with MIT
> Kerberos on the same system, since I can't really switch away from MIT
> Kerberos for my own personal use, but I'd want to have it installed to be
> able to easily test.
>
> Certainly, if multiple people are interested in working on this, I'd be
> glad to be part of a maintainer team.

Having you as a co-maintainer would be great.

I expect the initial packaging to be simple, it is just a './configure
&& make install' package.  Part of the 'make install' procedure should
be duplicated in the apt install scripts, for the KDC side, but that
part is not important.  I think it is more important to simply get the
library and binaries packaged.  How to better co-exist with MIT and
Heimdal is something that will need to be figured out along the way.

If there is interest in the idea, improving the GSS library to be able
to dlopen the MIT or Heimdal GSS libraries is an idea I have been
playing with.  Then Debian packages (like gsasl, fetchmail, curl,
mailutils, etc, that support GSS) would only have to be linked with
GNU GSS, and the user can, during run-time through a configuration
file, decide which actual implementation should be used.  GNU GSS
would then merely be a shim between MIT, Heimdal or Shishi.  Then
enabling GSS in more packages would be simpler, without having a
strong dependency on just one of MIT, Heimdal or Shishi.

Thanks,
Simon


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

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Simon Josefsson]

"J. Bruce Fields" <[EMAIL PROTECTED]> writes:

> On Tue, Aug 30, 2005 at 09:32:58AM +0200, Simon Josefsson wrote:
>> I expect the initial packaging to be simple, it is just a './configure
>> && make install' package.  Part of the 'make install' procedure should
>> be duplicated in the apt install scripts, for the KDC side, but that
>> part is not important.  I think it is more important to simply get the
>> library and binaries packaged.  How to better co-exist with MIT and
>> Heimdal is something that will need to be figured out along the way.
>> 
>> If there is interest in the idea, improving the GSS library to be able
>> to dlopen the MIT or Heimdal GSS libraries is an idea I have been
>> playing with.  Then Debian packages (like gsasl, fetchmail, curl,
>> mailutils, etc, that support GSS) would only have to be linked with
>> GNU GSS, and the user can, during run-time through a configuration
>> file, decide which actual implementation should be used.  GNU GSS
>> would then merely be a shim between MIT, Heimdal or Shishi.  Then
>> enabling GSS in more packages would be simpler, without having a
>> strong dependency on just one of MIT, Heimdal or Shishi.
>
> Have you looked at the libgssapi package at
> http://www.citi.umich.edu/projects/nfsv4/linux/ ?
>
> Currently we're just using this for the NFS rpcsec_gss implementation,
> but we split it out into a separate library thinking it might be used as
> you describe above.

I've seen it now, although it wasn't available when I created my GSS
implementation back in 2003.  Certainly co-operation would be good,
and it looks like we have similar goals.  But GSS is a GNU project so
it would require the normal copyright assignment procedure.

Thanks,
Simon


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

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Simon Josefsson]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
>> Having you as a co-maintainer would be great.
>
>> I expect the initial packaging to be simple, it is just a './configure
>> && make install' package.  Part of the 'make install' procedure should
>> be duplicated in the apt install scripts, for the KDC side, but that
>> part is not important.  I think it is more important to simply get the
>> library and binaries packaged.  How to better co-exist with MIT and
>> Heimdal is something that will need to be figured out along the way.
>
> There is an open bug against MIT Kerberos (#213316) asking that it use the
> alternatives system.  Originally this was for Java packages, which
> thankfully have stopped using alternatives to manage their broken version
> of kinit, but it's still appealing to coexist with Heimdal.  I don't want
> to add it only in MIT Kerberos, but if the Heimdal folks are also
> interested, I think it would be worthwhile.
>
> I don't know if Shishi conflicts with any binary names in Heimdal or MIT
> Kerberos; I haven't checked yet.  If so, alternatives looks even more
> appealing.
>
> The dev packages for Heimdal and MIT Kerberos conflict and that can't
> really be fixed.  Whether Shishi would also conflict is an interesting
> question.  I expect that the GSSAPI dev package would.
>
> Are you implementing the same API as MIT Kerberos, the same API as
> Heimdal, or something else yet again?

Shishi can co-exist with either of MIT or Heimdal.  It doesn't use a
similar API at all.  The library has a clean name space (shishi_*).
The tools doesn't conflict with any (to me) known tools.

I don't think the GSSAPI dev package would conflict; it places header
files in $prefix/include/gss/ and the library is called libgss to
avoid conflicting.  However, as it implement the standard GSS API, the
namespace do conflict, so you can't link directly to more than one
GSS-library at the same time.

I'm carefully avoiding conflicting with any existing Kerberos
implementation, but I'm considering adding functions to read the
MIT/Heimdal configuration file, to simplify things for the user.  I'm
not sure more compatibility than that is useful.

Thanks,
Simon


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

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Simon Josefsson]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Tue, Aug 30, 2005 at 08:01:41PM +0200, Simon Josefsson wrote:
>> Shishi can co-exist with either of MIT or Heimdal.  It doesn't use a
>> similar API at all.  The library has a clean name space (shishi_*).
>> The tools doesn't conflict with any (to me) known tools.
>
>> I don't think the GSSAPI dev package would conflict; it places header
>> files in $prefix/include/gss/ and the library is called libgss to
>> avoid conflicting.  However, as it implement the standard GSS API, the
>> namespace do conflict, so you can't link directly to more than one
>> GSS-library at the same time.
>
> Please add support for ELF symbol versioning, so that the usual
> namespace problems can be avoided.

I have added support for it in CVS.

> I notice from
> <http://josefsson.org/cgi-bin/viewcvs.cgi/shishi/README?rev=1.30&view=markup>
> that this lib is distributed under the terms of the GPL only, so I have
> my doubts that it's particularly useful for Debian to adopt it.  Is
> there any particular reason that GNU shishi is not made available under
> the LGPL?

Some reasons are given in [1].  I don't quite follow.  Is there a
problem with GPL'd software in Debian?

[1] http://www.gnu.org/licenses/why-not-lgpl.html

Thanks,
Simon


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

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Simon Josefsson]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Simon Josefsson <[EMAIL PROTECTED]> writes:
>> Steve Langasek <[EMAIL PROTECTED]> writes:
>
>>> I notice from
>>> <http://josefsson.org/cgi-bin/viewcvs.cgi/shishi/README?rev=1.30&view=markup>
>>> that this lib is distributed under the terms of the GPL only, so I have
>>> my doubts that it's particularly useful for Debian to adopt it.  Is
>>> there any particular reason that GNU shishi is not made available under
>>> the LGPL?
>
>> Some reasons are given in [1].  I don't quite follow.  Is there a
>> problem with GPL'd software in Debian?
>
> The problem is that you're drastically limiting what other software can
> use the library.  For example, there would be no way that Debian could
> link Cyrus SASL with shishi, because Cyrus SASL is used by a wide variety
> of other packages including some that are not GPL-compatible.  No package
> that uses shishi could also use OpenSSL.  No package that uses shishi
> could, as I understand it, use it as part of an Apache module.  There are
> lots of other, similar cases.

I see, right.  I note that a similar problem already exist, because
Heimdal links with OpenSSL.  So it appears that code licensed under
GPL could not link with Heimdal.  (A rdepend suggest e.g. lsh-server
contain GPL code that link with OpenSSL through Heimdal)

> As a result, shishi is going to basically be a curiosity, not a serious
> Kerberos alternative for Debian.  Given the difficulty involved in
> building multiple versions of packages to allow a choice of Kerberos
> implementations (if you look through Debian, you'll find that the ability
> to use Heimdal or MIT Kerberos exclusively is already rather spotty and
> some significant packages are only really maintained with one or the
> other), the addition of licensing problems means that there's basically no
> motivation for anyone to try to use shishi.

One motivation would be to get the unique features that Shishi has
that the other Kerberos implementation has.  E.g., non-ASCII support,
X.509/OpenPGP authentication through GnuTLS.

> Most of the motivations for making a library GPL rather than LGPL do not
> apply to shishi, since no one is going to free their software just to be
> able to use shishi.  They're going to shrug and just use MIT Kerberos or
> some other implementation with a permissive license instead.

You have a point, and I'll consider switching to LGPL for the core
library.  Perhaps a model like the one for GnuTLS is appropriate,
where the unique features has been separated into a GPL'd library.

Thanks,
Simon


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

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Simon Josefsson]

"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:

> On Tue, Aug 30, 2005 at 08:01:41PM +0200, Simon Josefsson wrote:
>> Shishi can co-exist with either of MIT or Heimdal.  It doesn't use a
>> similar API at all.  The library has a clean name space (shishi_*).
>> The tools doesn't conflict with any (to me) known tools.
>
> But I take it that it can still use the same ticket files etc.?

No, those formats were too limited.  I needed to store tickets for
multiple principals.  Reading/writing the MIT/Heimdal ticket/hostkey
files as a compatibility feature would be possible, though, and is on
the todo-list.

> I'm not sure if adding Shishi support to $whatever_program is a
> process that would be very useful (given what time it took to get
> Kerberos support into those programs the first time), but having
> Shishi kinit and perhaps libpam-shishi would be interesting for
> smart card use.

Agreed.  I don't want programs to be changed to support Shishi
directly.  Rather, applications should be written to use GSS-API.
Shishi can be used through GSS-API.

There is a Shishi kinit, and a PAM module is shipped with Shishi too.

Some older protocols, e.g. telnet and rsh, doesn't support GSS-API,
and they will have to support Shishi directly.  But maybe few care
about those protocols.  In any case, I have written patches for GNU
InetUtils that use Shishi directly:

http://josefsson.org/shishi/feg-inetutils/

I have submitted the patches up-stream, and while nobody has objected,
they haven't been installed yet.

Fortunately, SSH uses GSS-API directly, and I have patches LSH to
support GSS/Shishi:

http://josefsson.org/gss/gss-lsh.html

It still use an older version of the protocol, when IETF publish the
final protocol I'll update the patch.  Using the GSS implementation
from MIT/Heimdal with my patch is possible and works too.  Although
since LSH is GPL it is probably not possible to distribute binaries
linked to Heimdal.

Thanks,
Simon


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

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Simon Josefsson]

Russ Allbery <[EMAIL PROTECTED]> writes:

>>> other), the addition of licensing problems means that there's basically no
>>> motivation for anyone to try to use shishi.
>>
>> One motivation would be to get the unique features that Shishi has that
>> the other Kerberos implementation has.  E.g., non-ASCII support,
>> X.509/OpenPGP authentication through GnuTLS.
>
> Maybe.  My experience, having run a large Kerberos realm for over a decade
> now and having fought with countless applications to get Kerberos support,
> is that this really isn't on anyone's radar.  It's hard enough just to get
> them to look at Kerberos in the first place.

Sure.  And re-licensing to LGPL is certainly a possibility.

However, when I re-licensed GNU SASL from GPL to LGPL, after similar
requests, it didn't bring me any benefits.  People who said they would
use and contribute to the project if it was LGPL never showed up after
the license changed.  Further, all application that use GNU SASL today
appear to be licensed under GPL anyway.  The license change meant a
lot of work, separating the core package from the library, and it
didn't pay off.  I have considered reverting back to GPL, so that GNU
SASL can use some libraries that are licensed under GPL (such as
libksba, a X.509 library).  So forgive me if I'm skeptic when people
who aren't using my software come to me and claim that it would be
better for me if I changed my license.  So far, those claims doesn't
appear to have been valid for me.

> Anyway, I'm still interested.  I'm really busy at the moment and have some
> other things that I have to finish before I can reasonably start a new
> project, but it does sound like the packaging effort would be fairly
> simple and I'd like to have shishi around to play with.

Yes, I think an initial Shishi package should be simple to create.  It
doesn't have to create a working KDC installation on-the-fly, like
'make install' does.

Thanks,
Simon


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

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Simon Josefsson]

Russ Allbery <[EMAIL PROTECTED]> writes:

> The software area in which you're writing code is fairly mature and even
> standardized.  Pretty much everything that does SASL uses Cyrus SASL.

It is not even that good, plenty of applications implement their own
SASL code.  A quick ldd $bin|grep sasl suggest Kmail, Korn, Evolution
(Camel), Mozilla, Fetchmail, Exim, Gnus...

> But the situation from a distribution standpoint is much different.
> It's a huge amount of work (and work that's generally not worth the
> effort) for Debian to build all Kerberos-using packages against
> multiple libraries, and it's confusing for our users to have to
> choose between different packages.  It's also proven in practice to
> not be horribly maintainable.

I think that is a problem that should be improved regardless of
whether Shishi is added or not.  Using a meta-gss library, that would
dlopen other GSS-API implementations based on configuration files,
appear to be a feasible solution.  Then all Debian packages can easily
enable GSS support, linking to that small meta-GSS library, and don't
care about distributing multiple packages for Heimdal, MIT or Shishi.
This also solve the problem if someone want GSS-API _and_ TLS support,
right now some packages exist in *-gssapi and *-openssl3 versions.  So
I don't think adding Shishi to this mix complicate matter, rather it
may prod people into actually solving the original problem.

> On top of that, since this is authentication software, it often goes
> through a much tighter change management process and is handled far more
> conservatively.  For instance, there's no way that I'd deploy Shishi as
> the KDC for stanford.edu for at least another five years, just because
> Shishi isn't mature in the way that MIT Kerberos is.  This is nothing
> against the quality of the code, which I've not even looked at, but comes
> from a very conservative attitude towards changes to the core
> authentication infrastructure.  Large sites aren't going to want to be the
> sites that encounter the interesting problems.

I hear you.

Thanks,
Simon


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

Effort to change IETF's copying conditions for RFCs

[Simon Josefsson]

Hi everyone!

I know the copying conditions of IETF RFC's has been a concern for
Debian in the past, and that the RFCs has been removed from the
official archive (?), so I thought this would be of some interest to
you.  I am trying to influence the IETF to change the copying
conditions on RFCs to make them more free software friendly.

I explain the current problems, and I try to put together a proposed
update, and I have a petition online at:

http://josefsson.org/bcp78broken/

If you support this effort, or want to help, please sign the petition
or lend me some help!  Help with drafting the new license terms is
especially needed.

If the entire Debian organization want to support this effort, that
would be excellent, but just having a few Debian developers sign it
would help.

Thanks,
Simon


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

Re: Effort to change IETF's copying conditions for RFCs

[Simon Josefsson]

Florian Weimer <[EMAIL PROTECTED]> writes:

> * Simon Josefsson:
>
>> I explain the current problems, and I try to put together a proposed
>> update, and I have a petition online at:
>>
>> http://josefsson.org/bcp78broken/
>
> Very nice, thanks.
>
> I think you might get broader support in the vendor community if you
> make the license for modified copying non-copyleft.

Yes, that is the intention.  Requiring a copyleft license is likely to
meet with disapproval from too many people, for various reasons.

Thanks,
Simon


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

Re: Effort to change IETF's copying conditions for RFCs

[Simon Josefsson]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Wesley J Landaker <[EMAIL PROTECTED]> writes:
>> On Thursday 06 October 2005 06:57, Simon Josefsson wrote:
>
>>> I know the copying conditions of IETF RFC's has been a concern for
>>> Debian in the past, and that the RFCs has been removed from the
>>> official archive (?),
>
> If they haven't been yet, they will have to be for etch, at least all of
> the RFCs that are under the standard IETF IPR policy.  They don't allow
> modification and redistribution of modified versions, and therefore do not
> meet DFSG#3.

Yes.  I couldn't find them when I did a 'apt-cache search' so I assume
they were gone.  I recall a series of packages, rfc1-499, rfc500-999
or similar before.

>>> so I thought this would be of some interest to you.  I am trying to
>>> influence the IETF to change the copying conditions on RFCs to make
>>> them more free software friendly.
>
>> This would be great to get this clarified, as I believe the RFCs were
>> always intended to be available for unlimited distribution. I totally
>> support lobbying to get the the IETF to make it clear. =)
>
> Unlimited distribution isn't the problem.  Modification and redistribution
> of modified versions is the problem, and that restriction was apparently
> intentional.  So unfortunately, it's more than just a matter of getting
> the IETF to be clearer.

Getting them to be clearer is the first step.  Right now, I don't
think BCP78 even say what the IETF intend it to say.  Perhaps we can
convince them of the utility of permitting redistribution of modified
versions too.

Thanks,
Simon


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

Re: Effort to change IETF's copying conditions for RFCs

[Simon Josefsson]

Paul TBBle Hampson <[EMAIL PROTECTED]> writes:

> On Thu, Oct 06, 2005 at 11:16:03PM -0700, Russ Allbery wrote:
>> Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
>>> On Thu, 06 Oct 2005, Russ Allbery wrote:
>
 Unlimited distribution isn't the problem.  Modification and
 redistribution of modified versions is the problem, and that
 restriction was apparently
>
>>> If the IETF allows modified versions that are *RENAMED*, then it would
>>> meet the DFSG.  They can even restrict the renaming to "something that
>>> makes it clear that this is not an RFC, STD, >> here>"...
>
>> Right, I know.  Apparently it was intentional on the part of the IETF to
>> not even allow that.  Don't look at me; I think it's a stupid decision.
>
>> I'm not saying we can't get them to change it, or that we shouldn't try,
>> or anything else that discouraging.  I'm just saying that it isn't solely
>> a misunderstanding or lack of clarity; there really is an underlying
>> disagreement here.
>
> If the IETF doesn't even want people distributing modified, clearly
> indicated derived works, then how do people work on 'bis' versions of
> RFCs? eg. 2326bis, 'draft-ietf-mmusic-rfc2326bis-02.txt' is the old
> version I have lying around here now, which is clearly a derived work of
> RFC2326.

The license permit publishing derived works through the IETF process.

> Of course, this might be an IETF document, and _they_ are free to modify
> their own documents. I don't know that much about the IETF's processes,
> but it seems that denying the right to derive works from IETF standards
> documents is counterproductive, while restricting the naming of derived
> works to avoid confusion is understandable.

Yes.  I don't know how to achieve one without the other.  I'm not sure
why the IETF appear so afraid of someone taking a RFC, modifying it
and claiming it is the canonical version.  It won't happen because it
is pointless to do so.  And even if someone where to do it, the IETF
could simply sue them for claiming the IETF support something it
doesn't.  There is no need to restrict RFC copying permissions.

> Then again, do we want people forking RFCs? ^_^

Well, if the IETF doesn't permit modification of technical
specifications that the free software community needs, we will write
our own technical specifications that we can use.  They may not be as
complete as the RFC, but they will serve its point of documenting the
part of the protocol that end-users will have to care about.  If that
happens, the IETF has started to lose authority over protocol
standardization, so I think it would be in the best interest of IETF
to change their copying permissions.

Thanks,
Simon


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

Re: Effort to change IETF's copying conditions for RFCs

[Simon Josefsson]

Florian Weimer <[EMAIL PROTECTED]> writes:

> * Simon Josefsson:
>
>>> I think you might get broader support in the vendor community if you
>>> make the license for modified copying non-copyleft.
>>
>> Yes, that is the intention.  Requiring a copyleft license is likely to
>> meet with disapproval from too many people, for various reasons.
>
> But isn't the "this notice [...] preserved" part problematic?

Yes, I suppose you are right.  I have changed the license into:

The Contributor grants third parties the right to
copy and distribute the Contribution, with or without
modification, in any medium, without royalty.  If the
Contribution is modified, any claims of endorsement or
official status by the IETF or ISOC must be removed.

Is that ok?  Any other comments?

Thanks.

> | The Contributor grants third parties the right to copy and distribute
> | the Contribution, with or without modification, in any medium,
> | without royalty, provided that the copyright notice and this notice
> | are preserved, and that any claims of being the authorative RFC are
> | removed.


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

Re: Effort to change IETF's copying conditions for RFCs

[Simon Josefsson]

Florian Weimer <[EMAIL PROTECTED]> writes:

> * Peter Samuelson:
>
>>> * Simon Josefsson:
>>> > The Contributor grants third parties the right to
>>> >   copy and distribute the Contribution, with or without
>>> >   modification, in any medium, without royalty.  If the
>>> >   Contribution is modified, any claims of endorsement or
>>> >   official status by the IETF or ISOC must be removed.
>>
>> [Florian Weimer]
>>> Sure, but this might not be acceptable to ISOC, which might want to
>>> see a "Portions Copyright (C) 200x The Internet Society" in derived
>>> works.
>>
>> I don't see a conflict there.  A copyright notice is not a claim of
>> endorsement or official status - it's particularly clear that this is
>> not the case if only "portions" are copyrighted by some standards body.
>
> I didn't mean that, sorry.
>
> The potential problem I see is that Simon's new permission does not
> require attribution at all, not even the plain copyright statement.

I received some feedback from the IPR WG, resulting in this wording:

The Contributor grants third parties the right to
copy and distribute the Contribution, with or without
modification, in any medium, without royalty.  The IETF
requests that any citation or excerpt of unmodified text
reference the RFC or other document from which the text is
derived. If the text is modified in any way other than
translation, any claim of endorsement by the IETF or status
within its document series must be removed.

This doesn't mention the copyright notice, but if the IETF is
satisfied with that wording, I think it is fine for me as well.

Is that license acceptable to the Debian community?

Thanks,
Simon


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

Re: Effort to change IETF's copying conditions for RFCs

[Simon Josefsson]

John Hasler <[EMAIL PROTECTED]> writes:

> Simon Josefsson writes:
>> Is that license acceptable to the Debian community?
>
> Looks fine to me.  Is it going to be retroactive?

It is a good question.  The RFC Editor has claimed that the RFC 2026
license apply to older RFCs too, in particular RFC 1510 which
concerned me at the time enough so that I asked them.  I wonder if
that action is really legal, but if it is, it may be doable again.

Also, RFCs with the new license doesn't include the license template
itself, it just reference BCP 78.  So if BCP 78 is updated, perhaps it
automatically apply to RFCs that simply reference BCP 78.  I doubt the
legality of that too.

FYI: I will travel to the next IETF meeting and discuss this problem
in the IPR WG.  I will create a presentation and ask for feedback on
it on this list.  I have also significantly revised
<http://josefsson.org/bcp78broken/> and the I-D that goes together
with the page.  Please read it and tell me what you think.  If you can
explain matters like this to a wide audience, your help would be very
welcome...  I want the document to be as neutral as possible, while
still explaining that things are currently problematic.

The actual license text has only changed slightly though.  My proposed
license reads:

c.  The Contributor grants third parties the right to copy and
distribute the Contribution, with or without modification, in
any medium, without royalty.  The IETF requests that any
citation or excerpt of unmodified text reference the RFC or
other document from which the text is derived. If the text is
modified in any way other than translation, any claim of
endorsement by the IETF or status within its document series
must be removed.

Thanks,
Simon


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

Re: Effort to change IETF's copying conditions for RFCs

[Simon Josefsson]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
>> Also, RFCs with the new license doesn't include the license template
>> itself, it just reference BCP 78.  So if BCP 78 is updated, perhaps it
>> automatically apply to RFCs that simply reference BCP 78.  I doubt the
>> legality of that too.
>
> Is that comparable to GPLs 'or any later version'?

Perhaps.  It may actually mean "only the latest version" though, the
reference is for BCP 78 and at any given time there is only canonical
BCP 78.  Older versions of the same document doesn't apply,
presumably.

I think this matter should be raised with the IPR WG as well...

Cheers,
Simon


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

corrupt zip/tar archives in the repository?

[Simon Josefsson]

While recursively unpacking source archives in the debian repository
(see [1]), I noticed a small number of packages that contain corrupt
zip/tgz archives.  Logs from unpacking them are available from:

http://josefsson.org/broken-debian-origs/

The error messages are mixed in the output due to different buffering
for stdout vs stderr.  Searching for ' ' helps to find the real errors.

A dd-list of the 14 packages is included below.

Some of the corrupt archives may actually be appropriate.  I could
imagine that a corrupt archive can be included in a package to test
regressions for a compressor, or similar self-test reasons.  However,
that should be the exception, and I think the majority (if not all) of
these packages actually contains unintentionally corrupt archives.

Some of the corrupt archives is the *.orig.tar.gz archive itself, and
before noticing that this was a generic problem I reported this against
the 'e3' package, see
.

This problem could also be due to bugs in tar, gzip or unzip, although I
find that somewhat unlikely.

I think it would be nice if there weren't corrupt archives in the
package pool, but I'm not sure if others consider this a real problem.

What do you think about reporting these as wishlist bugs?

Thanks,
/Simon

[1] http://git.josefsson.org/?p=debian-rfc-search.git;a=summary

Daniel Leidert (dale) <[EMAIL PROTECTED]>
   apbs (U)

Masayuki Hatta (mhatta) <[EMAIL PROTECTED]>
   blender
   blender (U)

Michael Banck <[EMAIL PROTECTED]>
   apbs (U)

Fathi Boudra <[EMAIL PROTECTED]>
   strigi (U)

Ludovic Brenta <[EMAIL PROTECTED]>
   gnat-glade

Adrian Bridgett <[EMAIL PROTECTED]>
   xstarfish

Cyril Brulebois <[EMAIL PROTECTED]>
   blender (U)

Paul Cager <[EMAIL PROTECTED]>
   maven2 (U)

LI Daobing <[EMAIL PROTECTED]>
   apbs (U)

Debian Java Maintainers <[EMAIL PROTECTED]>
   maven2

Debian KDE Extras Team <[EMAIL PROTECTED]>
   strigi

Debichem Team <[EMAIL PROTECTED]>
   apbs

Dirk Eddelbuettel <[EMAIL PROTECTED]>
   r-cran-xml

Turbo Fredriksson <[EMAIL PROTECTED]>
   roxen4

Thomas Goirand <[EMAIL PROTECTED]>
   dtc

Wouter van Heyst <[EMAIL PROTECTED]>
   blender (U)

Georges Khaznadar <[EMAIL PROTECTED]>
   wims-extra

Bastian Kleineidam <[EMAIL PROTECTED]>
   optcomplete

Mark Purcell <[EMAIL PROTECTED]>
   strigi (U)

Roger So <[EMAIL PROTECTED]>
   im-sdk
   im-sdk (U)

Akira TAGOH <[EMAIL PROTECTED]>
   im-sdk (U)

Wouter Verhelst <[EMAIL PROTECTED]>
   nbd

Paweł Więcek <[EMAIL PROTECTED]>
   e3


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

Mass bug filing: corrupt zip/tar archives in the repository?

[Simon Josefsson]

There weren't much response on this.  I'll go through these bugs now and
file them as wishlist bugs.  Any objections?

/Simon

Simon Josefsson <[EMAIL PROTECTED]> writes:

> While recursively unpacking source archives in the debian repository
> (see [1]), I noticed a small number of packages that contain corrupt
> zip/tgz archives.  Logs from unpacking them are available from:
>
> http://josefsson.org/broken-debian-origs/
>
> The error messages are mixed in the output due to different buffering
> for stdout vs stderr.  Searching for ' ' helps to find the real errors.
>
> A dd-list of the 14 packages is included below.
>
> Some of the corrupt archives may actually be appropriate.  I could
> imagine that a corrupt archive can be included in a package to test
> regressions for a compressor, or similar self-test reasons.  However,
> that should be the exception, and I think the majority (if not all) of
> these packages actually contains unintentionally corrupt archives.
>
> Some of the corrupt archives is the *.orig.tar.gz archive itself, and
> before noticing that this was a generic problem I reported this against
> the 'e3' package, see
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473092>.
>
> This problem could also be due to bugs in tar, gzip or unzip, although I
> find that somewhat unlikely.
>
> I think it would be nice if there weren't corrupt archives in the
> package pool, but I'm not sure if others consider this a real problem.
>
> What do you think about reporting these as wishlist bugs?
>
> Thanks,
> /Simon
>
> [1] http://git.josefsson.org/?p=debian-rfc-search.git;a=summary
>
> Daniel Leidert (dale) <[EMAIL PROTECTED]>
>apbs (U)
>
> Masayuki Hatta (mhatta) <[EMAIL PROTECTED]>
>blender
>blender (U)
>
> Michael Banck <[EMAIL PROTECTED]>
>apbs (U)
>
> Fathi Boudra <[EMAIL PROTECTED]>
>strigi (U)
>
> Ludovic Brenta <[EMAIL PROTECTED]>
>gnat-glade
>
> Adrian Bridgett <[EMAIL PROTECTED]>
>xstarfish
>
> Cyril Brulebois <[EMAIL PROTECTED]>
>blender (U)
>
> Paul Cager <[EMAIL PROTECTED]>
>maven2 (U)
>
> LI Daobing <[EMAIL PROTECTED]>
>apbs (U)
>
> Debian Java Maintainers <[EMAIL PROTECTED]>
>maven2
>
> Debian KDE Extras Team <[EMAIL PROTECTED]>
>strigi
>
> Debichem Team <[EMAIL PROTECTED]>
>apbs
>
> Dirk Eddelbuettel <[EMAIL PROTECTED]>
>r-cran-xml
>
> Turbo Fredriksson <[EMAIL PROTECTED]>
>roxen4
>
> Thomas Goirand <[EMAIL PROTECTED]>
>dtc
>
> Wouter van Heyst <[EMAIL PROTECTED]>
>blender (U)
>
> Georges Khaznadar <[EMAIL PROTECTED]>
>wims-extra
>
> Bastian Kleineidam <[EMAIL PROTECTED]>
>optcomplete
>
> Mark Purcell <[EMAIL PROTECTED]>
>strigi (U)
>
> Roger So <[EMAIL PROTECTED]>
>im-sdk
>im-sdk (U)
>
> Akira TAGOH <[EMAIL PROTECTED]>
>im-sdk (U)
>
> Wouter Verhelst <[EMAIL PROTECTED]>
>nbd
>
> Paweł Więcek <[EMAIL PROTECTED]>
>e3
>
>
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Non-free IETF RFC/I-Ds in,source packages

[Simon Josefsson]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Brian May <[EMAIL PROTECTED]> writes:
>
>> No responses? No one cares enough to comment? Lets see if a change in
>> subject helps.
>>
>> Do the files created from the RFCs also have the same restrictive license
>> as the RFCs themselves?
>
> The text of the RFCs is copyrighted.  The mapping tables in the RFCs
> cannot be under US copyright law, and I believe copyright law in other
> countries is similar.  I'm guessing (I haven't looked closely) that what's
> happening here is that the build process is generating code from the
> tables in the RFC appendices.
>
> It should be fine if you strip the text of the RFC out in the Debian
> upstream source tarball and include only the tables that are used in the
> code generation process.  You can probably steal code from the Heimdal
> code generation process itself to do that automatically, and then run that
> script on new upstream tarballs to generate the Debian *.orig.tar.gz.

What you describe is roughly what my Libidn does, which also generates
code from the data tables in RFC 3454.  See the copyright related
discussion in the file itself:

http://git.savannah.gnu.org/gitweb/?p=libidn.git;a=blob;f=doc/specifications/rfc3454.txt;hb=HEAD

It contains some e-mail discussions with [EMAIL PROTECTED]

/Simon


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

Re: Non-free IETF RFC/I-Ds in,source packages

[Simon Josefsson]

Brian May <[EMAIL PROTECTED]> writes:

> Russ Allbery wrote:
>> This seems to imply that you no longer have a file named rfc3454.txt?  You
>> want to strip all the text out of that file except for the table, but
>> leave the table in the tree still named rfc3454.txt.
>>   
> This would imply understanding what needs to be extracted. For rfc3454.txt,
> it appears that the tables are all that required; presumably this
> means going through
> the tables manually and deleting and the many page headers that appear
> within,
> and hoping I haven't accidentally deleted a table row.

Right.  It appears legal to do this, since the tables aren't
copyrightable work.

> Unfortunately, rfc3492.txt looks more hairy, at quick glance it looks
> like the code extracts all of section 7.1 (open filename not hard
> coded in source):

In general, this is a different case because code is copyrightable and
you can't extract code from RFCs without permission.  Fortunately, this
particular RFC contains the following appendix:

B. Disclaimer and license

   Regarding this entire document or any portion of it (including the
   pseudocode and C code), the author makes no guarantees and is not
   responsible for any damage resulting from its use.  The author grants
   irrevocable permission to anyone to use, modify, and distribute it in
   any way that does not diminish the rights of anyone else to use,
   modify, and distribute it, provided that redistributed derivative
   works do not contain misleading author or version information.
   Derivative works need not be licensed under similar terms.

Thus it should be possible to include RFC 3492 in 'main' since it is
licensed under a DFSG free license.  If I recall correctly, at least
earlier discussions agreed that the license passed the DFSG.

The debian/copyright file should likely discuss these details.

Thanks,
Simon


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

Re: buildd path name length

[Simon Josefsson]

Florian Weimer <[EMAIL PROTECTED]> writes:

> Suppose that a package wants to create a UNIX domain socket as part of
> its test suite.  If the socket is created within the package build
> directory, this might fail because of the quite low path name length
> limit.  What is the correct way of dealing with this?  "mktemp -d" uses
> TMPDIR, which is potentially affected by the same issue.
>
> (My personal opinion is "fix the buildd", especially since none of the
> official buildds seems to use long path names, but there is
> disagreement.)

Can't the low path name length limit be fixed?  What restricts the
length?  Kernel, libc, filesystem, ...?

/Simon


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

Re: Archive signing key for 2007?

[Simon Josefsson]

Anthony Towns  writes:

> On Thu, Jan 11, 2007 at 11:51:21PM +0100, Javier Fern?ndez-Sanguino Pe?a 
> wrote:
>> I thought that the 2007 key was (based on [1]) supposed to be available
>> early in January and available in the debian-archive-keyring package. Which
>> doesn't seem to be the case.
>
> The key we'll be using (and indeed are already using) is available as:
>
>   http://ftp-master.debian.org/archive-key-4.0.asc
>
> It's expected to be valid until sometime after lenny is released.
>
> If you've upgraded a testing/unstable system in the past month or two,
> you'll find that key has been automatically added to your apt key list,
> after being verified by the normal trust path for upgraded packages --
> namely the current archive key you've been using, then the sha1sum of
> the Packages file and finally the md5sum of the apt package containing
> the updated key.

Interesting -- are there any formal procedures for the official
signing key?  I mean, how is the key generated, where is it stored,
who has access to it, is it on an online machine etc?

I think describing this would be useful, as a case-study of how to
manage an important key on a best-effort basis.

/Simon


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

Re: Second call for votes for the debian project leader election 2007

[Simon Josefsson]

Kalle Kivimaa <[EMAIL PROTECTED]> writes:

> Ben Pfaff <[EMAIL PROTECTED]> writes:
>> With Gnus+Mailcrypt, I was unable to vote with a signed but not
>> encrypted ballot.  The voting daemon claimed that there was some
>> kind of quoted-printable problem.  This surprised me: Gnus and
>> Mailcrypt have not caused problems for me with any previous
>> votes.  However, this is the only ballot I recall containing
>> non-ASCII characters, which could be the cause.
>
> As I used to have all my outgoing emails default to ISO 8859-1 charset
> I was unable to vote with Gnus+Mailcrypt until I changed the default
> to be ASCII. So, as I now had that same problem again, I'm guessing
> the problem is with Raphaël's non-ASCII e+umlaut, which makes Gnus use
> quoted-printable, which then isn't valid as seen by devotee (I'm
> guessing that Gnus encodes the signed mail and devotee wants to
> verify before decoding).

Mailcrypt doesn't, as far as I know, support PGP/MIME (RFC 3156).
PGP/MIME is the only standards-conforming way to do OpenPGP signatures
containing non-ASCII text.  Check your e-mail if it contains a
top-level Content-Type of multipart/signed.  If it doesn't, you used
the vanilla inline OpenPGP type.

Btw, an old rant on this topic:

http://josefsson.org/inline-openpgp-considered-harmful.html

In recent Gnus versions, PGP/MIME is supported natively.

/Simon


pgpK4zsLea2xq.pgp
Description: PGP signature

Re: The number of etch installations is rocketing...

[Simon Josefsson]

Fabio Tranchitella <[EMAIL PROTECTED]> writes:

> * 2007-04-12 11:29, Joey Hess wrote:
>> I wonder if it would be reasonable to make d-i hit one of two urls
>> depending on whether the user chose to enable popcon, and count the
>> results.
>
> Isn't this a violation of user's privacy? If the user hitted `No', this
> really means that he doesn't want to call home.

If the user hit enter on 'No' there could be another question asking
whether to just report that you installed a new machine.  The default
for that question would be 'Yes'.

Hm.  To reduce the number of questions asked during install, I suggest
having three options for the popcon question:

 [ ] No, don't use popcon
 [X] No, don't use popcon, but notify that you installed a new machine.
 [ ] Yes, use popcon

The middle option would be the default.  It would do a HTTP GET to
some debian.org machine.

However, this opens up for people setting up bots to destroy the
statistics...

/Simon


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

Re: GSASL Maintainer Missing in Action?

[Simon Josefsson]

Jorge Salamero Sanz <[EMAIL PROTECTED]> writes:

> On Thursday 14 June 2007 04:20:53 [EMAIL PROTECTED] wrote:
>> Two weeks ago I've sent an email no Yvan, asking if he was still
>> interested in maintaining those packages. Both have newer upstream
>> versions. There is a bug with a patch for libgsasl7 that was not
>> answered by Yvan. It is dated as of last December. libgasl7 and libntlm0
>> were last uploaded in March 2006 and June 2006, respectively. I've sent
>> another message to Yvan on Monday.
>
> i also sent him a mail more than a week ago without reply. i'd like to see 
> this lib updated on debian and i could help if you are looking for 
> co-maintainers.

I'm the upstream author, and there has been some API additions since the
version that's in Debian that may be useful for some applications, so
I'd like to see a new version of this package in Debian too.  If you
have any questions or problems when trying to upload an updated package,
I'd be happy to help.

/Simon


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

Re: nethack -- Doesn't purge all files after piuparts Install+Upgrade+Purge test

[Simon Josefsson]

Arnaud Fontaine <[EMAIL PROTECTED]> writes:

> Hello,
>
> Before I  maintain nethack-el, it  was not relying  on dh_installemacsen
> and startup file  was installed as /etc/emacs/site-start.d/50nethack.el.
> However,  it  now  relies  on  dh_installemacsen and  the  file  is  now
> installed as  /etc/emacs/site-start.d/50nethack-el.el, that's why  I got
> this bug report.
>
> I think that just renaming the file from 50nethack.el to 50nethack-el.el
> is  not the best  solution as  the former  file may  be still  there for
> unstable/testing users and it  would wipe possible modifications done in
> 50nethack-el.el. I'm wondering how I could handle that?

Why is the file called 50nethack-el.el?  Isn't it better to use the name
50nethack.el?  It seems more appropriate to me, and more consistent with
other files in that directory:

[EMAIL PROTECTED]:~$ ls -la /etc/emacs/site-start.d
total 44
drwxr-xr-x 2 root root 4096 2008-09-03 16:26 .
drwxr-xr-x 3 root root 4096 2007-12-12 22:05 ..
-rw-r--r-- 1 root root 1827 2006-01-06 08:19 00debian-vars.el
-rw-r--r-- 1 root root 1623 2008-01-03 16:34 50a2ps.el
-rw-r--r-- 1 root root  729 2008-01-22 05:35 50autoconf.el
-rw-r--r-- 1 root root  389 2006-04-13 15:47 50bbdb.el
-rw-r--r-- 1 root root  275 2008-01-25 11:00 50cmake.el
-rw-r--r-- 1 root root  409 2007-11-18 22:29 50devhelp.el
-rw-r--r-- 1 root root 1567 2008-05-21 18:24 50dictionaries-common.el
-rw-r--r-- 1 root root  740 2007-10-02 10:25 50gtk-doc-tools.el
-rw-r--r-- 1 root root  101 2007-06-07 22:40 50psvn.el
[EMAIL PROTECTED]:~$ 

/Simon


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

Re: Bug sprint !

[Simon Josefsson]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> Hi,
>
> there are currently 122 RC bugs remaining that affect both testing and
> unstable. We need to fix them NOW.
>
> However, in the permanent BSP state that has lasted for quite some time,
> people seem to lose focus on this urgent need for the release. So the
> idea is:
>   122 developers × 5 days = 122 RC bugs fixed
>
> The rules are : at the end of a 5-day period, the bug you are assigned
> must be closed in unstable or have a lenny-ignore tag. Otherwise this is
> a free-for-all.
>
> The first 5 developers to fix their bugs will be sent a box of home-made
> cookies. Those who can’t fix their bugs in 5 days will receive the visit
> of a release manager who will hit them with a rusty shovel.

Would using a gnuherds.org pledge on RC bugs be useful here?  Then
people can donate money to get RC bugs fixed in debian, and people who
fix the bug can claim the money.  The claims and pledges would be open,
which I think is important.

I understand there could be conflicts in agreeing on who actually closed
a particular RC bug though.  Hm.  Maybe voting could resolve that...

Just an idea.

/Simon


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

Re: [DRAFT] resolving DFSG violations

[Simon Josefsson]

William Pitcock <[EMAIL PROTECTED]> writes:

> On Wed, 2008-10-29 at 22:52 -0700, Thomas Bushnell BSG wrote:
>> But regardless, Debian has promised that Debian is only free software.
>
> Then why does Debian have non-free? Is that not part of Debian?

One way to resolve this dilemma is to realize that 'Debian' can refer to
two things: the project and the distribution.

Debian the operating system is free software since non-free/contrib is
not part of Debian (== main).

Debian the project is not (strictly) a free software project since it
contains and supports the non-free part.

Thus, a reasonable position for a free software supporter may be to
support the Debian operating system but not support the Debian project.

/Simon


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

Re: volunteers wanted for driving/finalizing a DEP on debian/copyright format

[Simon Josefsson]

Stefano Zacchiroli <[EMAIL PROTECTED]> writes:

> The solution to your problem already exists (actually, it has been
> *designed* for that): http://wiki.debian.org/Proposals/CopyrightFormat
> , it "just" needs someone with the energy of finalizing the proposal
> (most likely via a DEP), so that is stops being an ever changing wiki
> page.

This seems like an excellent idea, and seems in line with the comment at
the top of the current wiki page too.  I volunteer to help on this.
Maybe we can set up a vc repository to start working on the DEP?  The
wiki page can be used as a starting point, assuming the license is
acceptable.

/Simon


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

Re: volunteers wanted for driving/finalizing a DEP on debian/copyright format

[Simon Josefsson]

Noah Slater <[EMAIL PROTECTED]> writes:

> Hey,
>
> On Wed, Dec 03, 2008 at 12:25:20PM +0100, Simon Josefsson wrote:
>> Stefano Zacchiroli <[EMAIL PROTECTED]> writes:
>>
>> > The solution to your problem already exists (actually, it has been
>> > *designed* for that): http://wiki.debian.org/Proposals/CopyrightFormat
>> > , it "just" needs someone with the energy of finalizing the proposal
>> > (most likely via a DEP), so that is stops being an ever changing wiki
>> > page.
>>
>> This seems like an excellent idea, and seems in line with the comment at the
>> top of the current wiki page too.  I volunteer to help on this.  Maybe we can
>> set up a vc repository to start working on the DEP?  The wiki page can be 
>> used
>> as a starting point, assuming the license is acceptable.
>
> As one of the primary contributers to the copyright proposal I would obviously
> like to be involved in its ratification. I am guessing some of the other main
> contributers would like to be involved too.

Great, then maybe finding volunteers isn't actually a problem, as the
subject line implied.

> To get this started we need a mailing list and a repository, then we
> can place a notice on the wiki directing people to the mailing list
> and make the wiki page immutable so that there is no confusion.

Good idea.  Can't debian-legal be used for discussion though?
Alternatively, if a list is set up to discuss any DEP proposals.  A list
to discuss just the copyright file format specifications seems somewhat
overkill.  But maybe I'm wrong and the format will be discussed forever
and ever.

/Simon


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

Re: percentage of popcon submitters

[Simon Josefsson]

Neil Williams  writes:

> On Fri, 16 Jan 2009 08:45:12 +0100
> Kjeldgaard Morten  wrote:
>
>> >
>> > Thanks. Unless you setup some experimental method, any argument  
>> > should reduce
>> > to handwaving or extension of various particular examples..
>> 
>> Surely, it must be possible to get an estimate of the number of  
>> downloads of important packages and security updates? I know these  
>> downloads also are requested from mirror sites, but at least for the  
>> official mirror sites their relative activity must be known?
>
> How do you map the number of downloads to the number of users or
> machines?

It would establish an upper bound of well-administrated debian machines,
I think.

> I have dozens of chroots that I use for multiple reasons.

Good point.  I wonder how much these contribute to the overall
statistics though.  Alternatively, one could argue relatively convincing
that a chroot with a complete debian system should be counted as another
debian installation.  Compare with virtual machines, which is rather
similar to a chroot installation on a normal PC.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: percentage of popcon submitters

[Simon Josefsson]

James Vega  writes:

> On Thu, Jan 15, 2009 at 4:55 PM, markus schnalke  wrote:
>> [2009-01-15 22:37] Michael Goetze 
>>>
>>> before wild speculations ensues, you might want to specify what you
>>> really want to know: the percentage of people installing debian systems
>>> who use popcon (always/sometimes), or the percentage of installed
>>> machines that submit popcon data?
>>
>> Seems my wording was unclear.
>>
>> I want to know the percentage of installed machines that submit popcon
>> data.
>
> That requires knowing the number of computers that have Debian installed
> which, as has been discussed various times in the past on this list, is
> difficult to determine.

How about numbers for security.debian.org downloads?  That will measure
the number of well-administrated debian machines (except those
well-administrated machines that use other mirrors).

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: percentage of popcon submitters

[Simon Josefsson]

Neil Williams  writes:

> On Fri, 16 Jan 2009 13:24:58 +0100
> Simon Josefsson  wrote:
>
>> Neil Williams  writes:
>> 
>> >> Surely, it must be possible to get an estimate of the number of  
>> >> downloads of important packages and security updates? I know these  
>> >> downloads also are requested from mirror sites, but at least for the  
>> >> official mirror sites their relative activity must be known?
>> >
>> > How do you map the number of downloads to the number of users or
>> > machines?
>> 
>> It would establish an upper bound of well-administrated debian machines,
>> I think.
>
> No, merely the number of installations which is not the same, clearly.
>
> Chroots can be entirely temporary. I regularly hammer the mirrors to
> create test chroots last a matter of minutes. (Usually in a different
> architecture each time, hence a proxy isn't much help.)
>
> It's not just chroots either - don't forget issues of local mirrors.
> Download measurements cannot take account of whether the downloaded
> file is actually installed or merely copied into another repository.

It would still provides an upper bound, but the local mirror exception
is a good point.  So the number derived from security.debian.org
statistics would be 'an upper bound of the number of well-administrated
debian installation that do not use local security mirrors'.  I assume
this number is correlated to the number of real debian installations
(although I'm not sure we have a good definition of "real" here?).

Merely the number of distinct IP addresses downloading a particular
popular update from security.debian.org at least once would be
interesting.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: percentage of popcon submitters

[Simon Josefsson]

Johannes Wiedersich  writes:

> Simon Josefsson wrote:
>> Merely the number of distinct IP addresses downloading a particular
>> popular update from security.debian.org at least once would be
>> interesting.
>
> Did you think about thousands of computers having 'private ips' with
> some nat translation and/or local proxie? (I'm thinking of computer
> labs, companies, etc. not just the odd home user). Essentially all of
> the computers at our department share the same public IP.

Right, there are many reasons why such a number wouldn't be perfect, but
I still believe it would be interesting to know.  Especially if you plot
the trend in a graph to watch yearly changes.  If you get 10 such
indicator variables that likely are somehow correlated to the number of
machines (virtual or not) running debian plotted in a graph, and watch
the trends, that is likely to be the best measure we are likely to ever
get.  Or are there any better ideas on how to get a good estimate?

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: percentage of popcon submitters

[Simon Josefsson]

Bernd Eckenfels  writes:

> In article <87d4enbfqd@mocca.josefsson.org> you wrote:
>> It would establish an upper bound of well-administrated debian machines,
>> I think.
>
> It is a lower bound, since I guess there are more cases where more than one
> machine is updated. The case that you download without need or as a
> duplicate (With multiple IPs) is very low.

I've realized it is not a lower bound either, because some download
s.d.o packages to temporary chroots and pbuilds etc which should
probably not be counted as a debian machine.  Still, trying to get
numbers on the various statistics we can easily get at may improve
estimates and allow us to follow the trends.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: intent to hijack gsasl

[Simon Josefsson]

Jorge Salamero Sanz <[EMAIL PROTECTED]> writes:

> On Thursday 02 August 2007 21:06:10 Russ Allbery wrote:
>> Simon Josefsson helps maintain Debian packges for several of his other
>> packages (gss, shishi) and may be willing to help.  He's also generally
>> great about staying in touch with the Debian maintainers of his packages
>> and might know more about what's going on.  Have you talked to him about
>> this?  You may want to set up something like what we have with gss and
>> shishi where the Debian packaging is maintained on Savannah and Simon is a
>> listed co-maintainer.
>
> yes, he knows this hijack and he has suggested me to also take care of 
> libntlm0, maintained by the same missing person than gsasl.

FWIW, I also exchanged many e-mails with the earlier gsasl maintainer,
and he was about to add the NTLM stuff, but after that I never heard
anything again (although I don't recall sending any e-mails myself).

> simon is very helpfull with me, and yes, have him listed as co-maintainer is 
> great idea, we'll talk about that.

I don't care strongly here, I'm satisfied just sending bug reports about
things I miss.  Well, as long as there is someone as responsive as you
are in resolving the issues, of course...

Btw, perhaps we could discuss changing the GSS-API implementation that
gsasl use from libkrb53 to libgss0..  alternatively, providing a new
libgsasl-gss package for this purpose (although that would require
building the source twice).  I would find it very useful to be able to
use Shishi/GSS via GSASL.

/Simon


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

Re: seeking: Ian Jackson

[Simon Josefsson]

martin f krafft <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] expands to a greenend.org.uk address, and the mx for that
> domain refuses to accept my mail.
>
> : host
> mx-relay.chiark.greenend.org.uk[212.13.197.229] said: 550
> invalid MAIL-FROM: Error during DNS MX lookup for
> lapse.madduck.net: DNS alias found where canonical name wanted
> [Irritated] (in reply to RCPT TO command)
>
> Yes, lapse.madduck.net is a CNAME (*c*anonical *name*) to an MX RR,
> and that's RFC-compliant ttbomk. If it is not, I would appreciate if
> someone shoved the relevant sections into my face.

RFC 1034 section 3.6.2:

  Domain names in RRs which point at another name should always point at
  the primary name and not the alias.  This avoids extra indirections in
  accessing information.

See also RFC 1912 section 2.4:

   Don't use CNAMEs in combination with RRs which point to other names
   like MX, CNAME, PTR and NS.  (PTR is an exception if you want to
   implement classless in-addr delegation.)  For example, this is
   strongly discouraged:

   podunk.xx.  IN  MX  mailhost
   mailhostIN  CNAME   mary
   maryIN  A   1.2.3.4


   [RFC 1034] in section 3.6.2 says this should not be done, and [RFC
   974] explicitly states that MX records shall not point to an alias
   defined by a CNAME.  This results in unnecessary indirection in
   accessing the data, and DNS resolvers and servers need to work more
   to get the answer.  If you really want to do this, you can accomplish
   the same thing by using a preprocessor such as m4 on your host files.

There is some disagreement though:

http://www.mengwong.com/misc/rfc1912-is-wrong.html

/Simon


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

Re: Parallel build results

[Simon Josefsson]

Daniel Schepler <[EMAIL PROTECTED]> writes:

> I finally got through the test builds of all the source packages in sid for 
> i386 using dpkg-buildpackage -j3 on a dual core machine.  The results as 
> before are at http://people.debian.org/~schepler/build-logs/bymaint.html .  

Which said:

shishi: succeeded, but with jobserver warnings

and in the logs:

...
make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent
 make rule.
...

I believe I've fixed this in the debian package CVS.  The problem was
use of 'make' rather than '$(MAKE)' in rules.

Thanks,
Simon


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

Re: libgcrypt brain dead?

[Simon Josefsson]

Brian May  writes:

> Or is there another way?

There is the option of changing GnuTLS to use something other than
libgcrypt.  There are APIs for doing this dynamically in GnuTLS, and if
that is not sufficient (if you want to avoid linking to libgcrypt
entirely) we could also support e.g. GNU Nettle as the crypto library.
However some parts may be missing from GNU Nettle, e.g., entropy
gathering functionality, so that would have to be re-implemented.  This
option requires that someone contribute this code to GnuTLS, of course.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lje1pqub@mocca.josefsson.org

Re: Providing Webfs with GnuTLS-support.

[Simon Josefsson]

Mats Erik Andersson  writes:

> Hello,
>
> the package for the small web server Webfs has had SSL-support inactivated
> at least since July 2006, when #395873 began discussing migration to GnuTLS.
> Nothing ever happened, but now, having recently adopted the package, I am
> prepared to submit a new packaging of Webfs that does activate SSL/TLS
> by linking against GnuTLS.

Great!

> First off, is there some group or individual that has stated a willingness
> to perform a pre-release examination, in order that a GnuTLS-migration does
> not introduce security breaches, that had better be accounted for before
> any public package release? Or is the scrutiny during unstable and testing
> phases deemed sufficient?

Is there any particular reason you worry?  If not, I believe the normal
process is the best we can get.

> Secondly, my implementation uses a few compiler macros to enable an
> independent administrator to recompile the package with costumized
> settings. My present intention is to use code equivalent to
>
>#define WEBFS_CIPHERS "SECURE256"
>#undefine USE_TLS_COMPATIBILITY
>
> influensing code snippets
>
>gnutls_priority_init(&tls_priority_cache, WEBFS_CIPHERS, NULL);

Ideally, the priority string should come from a configuration file
rather than being hard coded.  Isn't there one?

Also, I'm not sure SECURE256 makes sense, it will reject RSA-SHA-1
signatures (because it has key bit length < 256).

I would strongly recommend sticking to "NORMAL" unless there is any
explicit reason not to.

>gnutls_session_enable_compatibility_mode(client_session);

This disables record padding, which seems like a bad idea to activate.

> Bearing in mind the behaviour of different webb clients, could there
> be relevant reasons to relax these to "NORMAL", and a default activation
> of compatibility mode? My initial impulse is to refrain from this.

I recommend to use NORMAL and not disable record padding.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r5nknzv1@mocca.josefsson.org

Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services disabled

[Simon Josefsson]

Joerg Jaspert  writes:

>>> Now, should the technician not be able to resurrect ries, our backup
>>> plan extends to have the disks shipped over and replace the ones
>>> currently in rietz.
>> I'm wondering if Debian has the resources (DSA, local admins and
>> hardware) to have a hot-swappable backup machine for ftpmaster, since
>> it does go down occasionally and when it does the downtime is fairly
>> disruptive to Debian.
>
> Well, this would mean:
> a) double ftpmaster. Just as a rough number, the new machine that is
>currently "in progress" has an estimated cost of 2 Dollar (if you
>take prices from HP Website. This is not what it will cost in the
>end, but it shows what category of stuff we have to get)
> b) Have the double space at our hoster.
> c) Run it with heartbeat, drbd and all that.
>
> Point c) is actually easy enough, even though im not DSA and can't decide
> for them to do it. But technically it would be a working setup, provided
> b) works out, as you really want  a *FAST* connection between the
> two. Which means local.
>
> The only trouble this setup has is that you have a pretty huge expensive
> machine always on and running, but not actually doing stuff for
> 99.% of the time. And usually the support pack we ordered
> provides a service that means getting machine back faster than this, so
> the question in the end is: Do we want the added complexity (and costs),
> or can we just stand a day or three of downtime? Its annoying, but world
> doesnt really die.

Is there any way to build a distributed service instead of relying on
one central machine (or two machines sitting next to each other)?

I don't know exactly what services are involved, but typically and
generally, when I deploy a server infrastructure, I try to setup (at
least) two machines at different geographical places that each can
provide the entire service.

The complexity in getting a heartbeat, drbd, etc solution to work can
easily eat up any downtime savings you plan to get.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fx3gg3dn@mocca.josefsson.org

Re: Bug#580221: ITP: python-libssh2 -- python-libssh2 is a python binding for libssh2 library.

[Simon Josefsson]

Frank Lin PIAT  writes:

> -
>  libssh2 is the thin library implementing client side of SSH2 protocol
>  as defined by Internet Drafts SECSH-TRANS, SECSH-USERAUTH,
>  SECSH-CONNECTION, SECSH-ARCH, SECSH-FILEXFER, SECSH-DHGEX,
>  SECSH-NUMBERS, and SECSH-PUBLICKEY
>  .
>  This boils down to the regular terminal, scp and SFTP sessions; port
>  forwarding; password, key-based and keyboard-interactive
>  authentication.
>  .
>  This package contains the python bindings libssh2. It is a fork and
>  rewrite of org.keyphrene.
> -
>
> Note that the two first paragraph are a pristine copy of libssh2
> description... the I18N teams should appreciate ;)

On the other hand, I don't think the libssh2 description is particularly
useful for a user.  The uppercase acronyms aren't friendly.  How about
something like this:

  libssh2 is a client-side C library implementing the SSH2 protocol
  with support for regular terminal, scp and SFTP sessions; port
  forwarding; password, key-based and keyboard-interactive
  authentication.
  .
  This package contains the python bindings libssh2. It is a fork and
  rewrite of org.keyphrene.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aasf4czv@mocca.josefsson.org

Re: Archive area for clamz (Amazon MP3 downloader)

[Simon Josefsson]

Michael Banck  writes:

> On Mon, May 31, 2010 at 05:13:51PM +, brian m. carlson wrote:
>> On Mon, May 31, 2010 at 07:03:16AM +0200, sean finney wrote:
>> > On Sun, May 30, 2010 at 09:40:48PM +, brian m. carlson wrote:
>> > > The difference is that those tools provide a reasonable level of
>> > > functionality with free data.  Weather information is in the public
>> > > domain because there's no originality to it.  Most programs that display
>> > > lyrics or album covers are music players, and there is free music
>> > > (available in our archive, no less) that they can usefully play.
>> > 
>> > so should amavis and spamassassin go to contrib because there aren't
>> > any documented DFSG-free virus and spam going through our mailservers?
>> 
>> I'll bite.  amavis and spamassassin handle emails, and there are in fact
>> emails that are free.  CVS commit emails for free software projects are
>> a great example of this.
>
> What about http://creativecommons.org/tag/amazon ?

Looking at the NIN album, it is CC-BY-NC-SA, which is not DFSG-free.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87typohr8w@mocca.josefsson.org

Re: Hydra is not really free

[Simon Josefsson]

"Hans-J. Ullrich"  writes:

> Hi guys! Good news! 
>
> Hydra is now beeing maintained again, and it is now free! Thanks to its 
> maintainer, hydra is now set under the GPLV3.
>
> Yeah! 
>
> Please take a look:
>
> http://freeworld.thc.org/thc-hydra/
>
> Maybe you might want to put it back into debian? Would be nice.

It seems like it links with OpenSSL.  Does it have a license exception
for this?  As far as I can see, it is pure GPLv3, which as far as I
understand would be incompatible with the OpenSSL license.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sk4mr76e@mocca.josefsson.org

Re: Bug#596511: ITP: simon -- Open source speech recognition

[Simon Josefsson]

Peter Grasch  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Peter Grasch 
>
>
> * Package name: simon
>   Version : 0.3.0
>   Upstream Author : Peter Grasch 
> * URL : http://www.simon-listens.org/
> * License : GPL, BSD, GFDL and Julius
>   Programming Lang: C, C++
>   Description : Open source speech recognition
>
>  With simon you can control your computer with your voice. You can 
>  open programs, URLs, type configurable text snippets, simulate 
>  shortcuts, control the mouse and keyboard and much more.
>  simon is not bound to any language and works with any dialect.
>  This project utilizes the open source large vocabulary continuous 
>  speech recognition engine Julius (this package ships its own 
>  modified version).

Is this intended for main?  Doesn't Julius rely on the non-free HTK
toolkit?

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y6b4ckiq@mocca.josefsson.org

Re: Bug#596511: ITP: simon -- Open source speech recognition

[Simon Josefsson]

Samuel Thibault  writes:

> Peter Grasch, le Tue 14 Sep 2010 22:22:42 +0200, a écrit :
>> I haven't really thought about it but the license shouldn't be an issue 
>> afaik.
>> 
>> This topic has come up multiple times already but have a look at theses 
>> discussions on why I think this should be ok:
>> Comment section: http://lwn.net/Articles/348361/
>
> « The HTK is, strictly speaking, no dependency of simon. It extends
> simon functionality: Without it is not possible to create speech mdoels
> but you can still use existing ones. »
>
> And can you modify one?  I guess you can't.  That's an issue.

Quoting further: "All HTK specific code is bundeled in the
simonspeechcompilation library (in one class) which could easily be
replaced by a GPL replacement - if there were any."

Peter, have you prepared a source *.deb yet?  It would be interesting to
look at the code to understand how critical the non-free component is.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87tyls9h3g@mocca.josefsson.org

Re: Bug#596511: ITP: simon -- Open source speech recognition

[Simon Josefsson]

Peter Grasch  writes:

>> Peter, have you prepared a source *.deb yet?  It would be interesting to
>> look at the code to understand how critical the non-free component is.
> Sure. There are complete packages in the Ubuntu ppa:
> https://launchpad.net/~grasch-simon-listens/+archive/simon/

The copyright file says:

This package consists of four differently licensed parts:
  * The documentation is under the GFDL (see below);
  * Julius (everything in the folder julius/) is coverd
by the Julius license (see below)
  * CMake modules are licensed under the BSD license
(see below)
  * Everything else is covered by the GPLv2

One conclusion from earlier discussions about the Julius license on
debian-legal was that it was non-free:

http://www.mail-archive.com/debian-le...@lists.debian.org/msg40898.html

The thread isn't completely clear to me what the exact problem is
though...

Is Julius dynamically linked to Simon?  I wonder whether GPLv2 is
compatible with the Julius license.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxrbz11k@mocca.josefsson.org

Re: Bug#596511: ITP: simon -- Open source speech recognition

[Simon Josefsson]

Peter Grasch  writes:

>  Hi!
>
>> One conclusion from earlier discussions about the Julius license on
>> debian-legal was that it was non-free:
>>
>> http://www.mail-archive.com/debian-le...@lists.debian.org/msg40898.html
>>
>> The thread isn't completely clear to me what the exact problem is
>> though...
> As far as I can work out the ambiguous advertising clause is the
> problem (as well as possibly clause 5 but that seems to be open for
> discussion).
>
> I agree that this clause is quite badly worded and already asked about
> it in the Julius forums (I am "bedahr"):
> http://julius.sourceforge.jp/forum/viewtopic.php?f=6&t=644-
>
> But I never got a reply.


OK.

>> Is Julius dynamically linked to Simon?  I wonder whether GPLv2 is
>> compatible with the Julius license.
> Yes it is. The simon license contains a special exception to allow this.
> This is also covered here:
> http://www.simon-listens.org/wiki/index.php/Licensing

It refers to 'under certain conditions as described in each individual
source file' but I cannot find conditions described in any of a random
sample I made of source code files in Simon?  Can you point to one file
that has the conditions?  All source code files that are built into a
package linked to Julius needs to have the exception, I believe,
otherwise the file is under the GPLv2+ only without the exception.

Also, any external GPL code that Simon links to needs to have the same
exception.  Is there any external GPL code?

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lj6vxisf@mocca.josefsson.org

Re: Bug#596511: ITP: simon -- Open source speech recognition

[Simon Josefsson]

Peter Grasch  writes:

>  Hi!
>
> Am 2010-09-21 16:39, schrieb Simon Josefsson:
>>>> Is Julius dynamically linked to Simon?  I wonder whether GPLv2 is
>>>> compatible with the Julius license.
>>> Yes it is. The simon license contains a special exception to allow this.
>>> This is also covered here:
>>> http://www.simon-listens.org/wiki/index.php/Licensing
>> It refers to 'under certain conditions as described in each individual
>> source file' but I cannot find conditions described in any of a random
>> sample I made of source code files in Simon?  Can you point to one file
>> that has the conditions?  All source code files that are built into a
>> package linked to Julius needs to have the exception, I believe,
>> otherwise the file is under the GPLv2+ only without the exception.
> You are right, I forgot that exception but added it to the two files
> of the one class coming in direct contact with Julius (it's used
> somewhere else too but there it just calls external programs).
>
>
>> Also, any external GPL code that Simon links to needs to have the same
>> exception.  Is there any external GPL code?
> Well of course - KDE.

I believe kdelibs is LGPL, so maybe you are OK.  It depends on what
parts of KDE is used.

> This is getting ridiculously frustrating. It's not that I don't think
> it's an important issue but I guess if you'd gather all involved
> parties and ask them if the current setup would be ok I am pretty sure
> everyone would agree. Oh well I guess that just comes with the
> territory.

I know the pain, I've ended up rewriting several projects because of
license problems with earlier implementations.  What I have learned is
that you should react to license issues as soon as possible, or you'll
end up investing a lot of work into something that needs to be
redesigned.

> I obviously can't hack this into simon 0.3.0 but for the next version,
> would it help if I split the Julius-interfacing part into a plugin
> that doesn't link to KDE? This would be the easiest option in my
> opinion but  as I understand it it would mean to distribute the plugin
> seperately?
>
> If Julius is not "free" in Debian eyes this would mean that simon
> becomes pretty much useless to be honest.

I don't really have an opinion whether it is free or not yet, but it
looks complicated.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87tylirfuc@mocca.josefsson.org

Re: Fun with libtool and cross-builds

[Simon Josefsson]

Wookey  writes:

> At this points it calls the linker and adds -L/usr/lib on the front -
> thereby adding this path in front of the default cross-compiler path.

Please try to debug where the -L/usr/lib comes from, I don't believe
libtool is adding this by itself but instead it is told to add it by
some incorrect .la file or similar.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ei7hx93u@latte.josefsson.org

Re: Requirement for a “proper manpage” for every command

[Simon Josefsson]

Ben Finney  writes:

> I'm having a conversation with a Debian packager regarding a manpage
> that, currently, is a mere placeholder saying “please see foocommand
> --help”, giving none of the useful information normally found in a
> manpage.
...
> I have submitted a manpage as a patch. However, that response pretty
> much guarantees that the maintainer won't be taking the initiative to
> keep the manpage up to date.

How about submitting a patch to use help2man instead?

http://www.gnu.org/software/help2man/

Then the man page will be kept up to date with --help output.

Possibly the document around the man page requirement could point to
help2man as a quick solution in case there is useful --help output but
no man page.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Outdated config.{sub,guess} package list

[Simon Josefsson]

Michal Čihař  writes:

> Dne Sat, 25 Apr 2009 07:10:24 +0300
> Peter Eisentraut  napsal(a):
>
>> Like lintian, your list falsely includes packages that use cdbs to build, 
>> which automatically updates config.{sub,guess}.
>
> If you don't build depend on autotools-dev, nothing can be updated (at
> least it was case for my package which uses dh).

Speaking of autotools-dev, that package seems somewhat outdated.
Upstream config.{sub,guess} is newer than what's in autotools-dev, for
example, and the /usr/share/doc/autotools-dev/README.Debian.gz
documentation does not accurately describe modern autotools.

I don't think overriding config.{sub,guess} in debian packaging is the
right solution without forwarding the problem report upstream.  It is
not a debian specific problem.

/Simon


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: What about default-syslog [Re: new release goal default-mta?]

[Simon Josefsson]

Roger Leigh  writes:

> I think it is a problem extending to all virtual packages, and I would
> like to see a more general solution which is applicable to all.  It
> might be worth revisiting past discussion, for example this thread:
>
> http://lists.debian.org/debian-devel/2006/08/msg01281.html
>
> (I've CCd -devel and -policy because it's a general issue which should
> ideally be in policy)
>
> The above discussion proposed a solution like default-mta.  At the time,
> I also wrote a sample "virtual-default" package which generated these
> -defaults packages for all virtual packages in the archive.  At the time
> I held off actually implementing this because Anthony Towns said he was
> implementing a better method in dpkg itself.  However, I've not seen any
> more about this other than that single time, and if mta-defaults is being
> created it looks like we are still looking for a solution.

I think the default-* idea is good.

The thread above mentions both 'inet-superserver' and
'mail-transport-agent-default'.

May I suggest that we use default-* for this?  It helps to improve the
namespace.

Or even debian-default-* to be more clear that this is debian specific.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Simon Josefsson]

Philipp Kern  writes:

> On 2009-05-11, Brian May  wrote:
>> On Fri, May 08, 2009 at 11:31:07PM +0200, Jens Peter Secher wrote:
>>> +1 for ssmtp
>> I found ssmtp couldn't cope with mail my various systems were
>> generating, something about fixed maximum buffer lengths from memory.
>
> Please not ssmtp.  If I recall it correctly I found no way to get it
> to send mail to a exim-based smarthost via TLS in a sane way.

What about msmtp?  http://msmtp.sourceforge.net/

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Simon Josefsson]

Jakub Wilk  writes:

> * Simon Josefsson , 2009-05-11, 12:55:
>>>>> +1 for ssmtp
>>>> I found ssmtp couldn't cope with mail my various systems were
>>>> generating, something about fixed maximum buffer lengths from memory.
>>>
>>> Please not ssmtp.  If I recall it correctly I found no way to get it
>>> to send mail to a exim-based smarthost via TLS in a sane way.
>>
>>What about msmtp?  http://msmtp.sourceforge.net/
> AFAIK msmtp does not support local mail delivery.

I suspect that is part of the design goal of msmtp.  Local mail delivery
can be handled by other tools, can't it?  Generally, it seems like a
good idea to separate these two separate tasks into different tools.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Unicode 7.0 released - some packages contain outdated embedded data copies

[Simon Josefsson]

Paul Wise  writes:

> Please ask your upstreams to remove the Unicode data files from their
> version control systems and source tarballs and instead check for and
> use external Unicode data files at build-time or run-time. Then your
> packages can Build-Depend or Depend on the unicode-data binary package.
> If your package converts the Unicode data to another format at build
> time you should add a Built-Using header to the relevant binary
> packages. The fntsample package is an example of how to do this.
...
> Anibal Monsalve Salazar 
>libidn (U)

This is a false positive -- libidn implements IDNA2003 (RFC3490 etc)
which has a hard dependency on Unicode 3.2.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738cbvyo8@latte.josefsson.org

Re: Trimming priority:standard

[Simon Josefsson]

Adam Borowski  writes:

> What would you guys say about cutting some cruft from priority:standard?

Yay.

> bind9-host dnsutils host libbind9-90 libdns100 libisc95 liblwres90

Is the BIND libraries pulled in just because of 'host'?  Seems rather
heavy to me.  Anyway, the 'host' package seems to be superseded by
'bind9-host' so the former could go?

/Simon


signature.asc
Description: PGP signature

Re: Trimming priority:standard

[Simon Josefsson]

Josh Triplett  writes:

> - make-guile.  More of a question than a recommendation for a change,
>   but why is this standard and make optional, rather than the other way
>   around?

Is this mostly about naming?  GNU Make has guile-support by default, so
I would say that 'make' should be with Guile and if desired for some
reason, there could be a 'make-noguile' that is built without guile.

A bigger question: is 'make' really necessary in priority:standard?
Presumably anything requiring it will depend on it.

> - mlocate.  We don't need a "locate" in standard; anyone who actually
>   uses locate (and wants the very significant overhead of running a
>   locate daemon) can easily install this.

+1

It is for desktops.

> - nfs-common and rpc-bind.  Anyone using NFS can install these, but NFS
>   is not anywhere close to common enough to appear in priority standard.

+1

Right now rpcbind is listening on the network in a default jessie
install, and I don't like that.

/Simon


signature.asc
Description: PGP signature

Re: Minified javascript files

[Simon Josefsson]

Thomas Goirand  writes:

> On 08/17/2012 09:40 AM, Paul Wise wrote:
>> On Fri, Aug 17, 2012 at 1:24 AM, Vincent Bernat wrote:
>>
>>   
>>> What I didn't know until recently is that the minified version in the
>>> source package should be removed (or the appropriate full version should
>>> be appended).
>>> 
>> Do we also require that for say, precompiled DLLs of GTK+ or SDL for
>> Windows platforms?
>>   
> I had the OpenSSL dll for windows embedded in one of my source packages,
> because there was some windows software together with it. I had to remove
> it completely, as I was asked to have the source code for it, and I found
> ridiculous to embed the sources of OpenSSL too.
>
> So yes, we have the problem for precompiled windows DLLs in a source
> package.

Interesting, that issue seems rather common.  Maybe a lintian check
could alarm packagers of this?

See below for a list of *.dll files in packages starting with 'a' only.
Overall, I found *.dll files in around 131 packages (of course not all
of those represent a problem).

/Simon

./abe_1.1.orig.tar.gz:abe-1.1/SDL.dll
./abe_1.1.orig.tar.gz:abe-1.1/SDL_mixer.dll
./activemq_5.6.0+dfsg.orig.tar.gz:activemq-5.6.0+dfsg/assembly/src/release/bin/win64/wrapper.dll
./alpine_2.02.orig.tar.gz:re-alpine-2.02/alpine/ldap32.dll
./alpine_2.02.orig.tar.gz:re-alpine-2.02/ldap/binaries/debug/ldap32.dll
./alpine_2.02.orig.tar.gz:re-alpine-2.02/ldap/binaries/debug/libldap.dll
./alpine_2.02.orig.tar.gz:re-alpine-2.02/ldap/binaries/release/ldap32.dll
./alpine_2.02.orig.tar.gz:re-alpine-2.02/ldap/binaries/release/libldap.dll
./altos_1.0.3.tar.gz:altos-1.0.3/altosui/Instdrv/NSIS/Plugins/InstDrv.dll
./antlr_2.7.7+dfsg.orig.tar.gz:antlr-2.7.7/examples/csharp/csharp_v1/Tools/runtime.dll
./antlr_2.7.7.orig.tar.gz:antlr-2.7.7/examples/csharp/csharp_v1/Tools/runtime.dll
./argyll_1.1.1.orig.tar.gz:argyll-1.1.1/libusbw/ddk_make/sources_dll
./argyll_1.1.1.orig.tar.gz:argyll-1.1.1/libusbw/libusb0.dll
./argyll_1.1.1.orig.tar.gz:argyll-1.1.1/libusbw/libusb0_x64.dll
./armadillo_0.9.52.orig.tar.gz:armadillo-0.9.52/examples/lib_win32/blas_win32_MT.dll
./armadillo_0.9.52.orig.tar.gz:armadillo-0.9.52/examples/lib_win32/lapack_win32_MT.dll
./atanks_5.5.orig.tar.gz:atanks-5.5/alleg42.dll
./atanks_5.5.orig.tar.gz:atanks-5.5/src/alleg42.dll


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3wx7s44@latte.josefsson.org

Re: Minified javascript files

[Simon Josefsson]

Vincent Bernat  writes:

>  ❦ 19 août 2012 15:11 CEST, "Bernhard R. Link"  :
>
>>> The difference is that we need to bug upstream about a file that we
>>> won't even use. There is no real bug (not even a licensing issue).
>>
>> They are distributing files without source, so everyone else can either
>> not just easily modify it or verify if it really does what it is
>> supposed to do. This is definitely a shortcoming in what upstream ships
>> and really something you should bug upstream about.
>
> The source is one link away. People wanting the source just have to
> click on the link in the header of the minified version. As for
> verification, having the source next to the minified version does not
> guarantee anything about the minified version, all the more that we
> don't have currently in Debian Wheezy a reliable minifier.

That seems problematic -- so even if the source is shipped, there is no
way to re-build the minified file?

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87boi64ut2@latte.josefsson.org

Re: Minified javascript files

[Simon Josefsson]

Pau Garcia i Quiles  writes:

> On Sun, Aug 19, 2012 at 8:10 PM, Simon Josefsson  wrote:
>
>>> As for
>>> verification, having the source next to the minified version does not
>>> guarantee anything about the minified version, all the more that we
>>> don't have currently in Debian Wheezy a reliable minifier.
>>
>> That seems problematic -- so even if the source is shipped, there is no
>> way to re-build the minified file?
>
> It really depends on using exactly the same version of the same
> minifier with exactly the same parameters (which you may not know) and
> even then you cannot be sure, e. g. a minifier may use generate
> shortened variable names randomly.

I believe differences like that are not important, compare how gcc
generate different binaries each time depending on parameters etc.
However, if a minified file is shipped that cannot be re-created at all
(due to no minifier) I don't think shipping source for the file is the
only problem.  Both source code and the tools needed to generate output
forms is needed for users to be able to use a modified version of the
program.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gsu4rfs@latte.josefsson.org

Re: Enabling uscan to simply remove files from upstream source

[Simon Josefsson]

Andreas Tille  writes:

> Files-Excluded:
>   docs/source/fonts/*
>   docs/source/javascripts/jquery-1.7.1.min.js
>   docs/source/javascripts/modernizr-2.5.3.min.js
...
> Regarding the implementation there was some uncertainity about the
> actual Perl module to use.  In the attached example script I decided to
> stick to Dpkg::Control and left the code for Parse::DebControl as a
> comment which could pretty easily could replace the other parser.  The
> code works for me however, there might be some remaining empty
> directories which I'm tempted to delete these as well via an "educated"
>
>find tmp -type d -empty -delete
>
> which means I would care for deleting only those directories that became
> empty by the previous removal process and not those directories which
> were originally empty in the tarball.  On the other hand we might simply
> go with those empty dirs that finally do not harm.
>
> Any further hints / remarks?

How about resolving the empty directory problem by permitting the
Files-Excluded to match directories?  Thus, if you want to remove the
docs/source/fonts/ hierarchy, you would instead write:

Files-Excluded:
   docs/source/fonts/
   docs/source/javascripts/jquery-1.7.1.min.js
   docs/source/javascripts/modernizr-2.5.3.min.js

I'm worried that empty directories may be present for other reasons, and
removing all of them would have bad side-effects.  I would prefer to not
remove empty directories over using the find-approach above, if my
proposal is not adopted.

Thanks for doing this, I believe that having an easy way to remove files
from upstream packages will save Debian package maintainers time and
frustration.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehn0ij15@latte.josefsson.org

Re: Enabling uscan to simply remove files from upstream source

[Simon Josefsson]

Andreas Tille  writes:

> On Tue, Aug 21, 2012 at 01:25:26PM +0200, Simon Josefsson wrote:
>> How about resolving the empty directory problem by permitting the
>> Files-Excluded to match directories?  Thus, if you want to remove the
>> docs/source/fonts/ hierarchy, you would instead write:
>> 
>> Files-Excluded:
>>docs/source/fonts/
>
> You can certainly do this but this would leave you with the chance
> that docs/source/ remains as empty directory.

Ah, right, I see.  Then if somebody finds that to be a problem, the
maintainer can change Files-Excluded to be docs/source/, surely?  I'm
just trying to keep the complexity low.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87txvwh22g@latte.josefsson.org

Re: Minified javascript files

[Simon Josefsson]

Damien Raude-Morvan  writes:

> IMHO, it's obvious that yui-compressor is not - anymore - the most
> efficient javascript minifier and better alternative exists. It's
> simply not used anymore by "big players" of Javascript libs (like
> jQuery) so it receives less attention (even from Yahoo for YUI).

What is upstream jQuery using?  Is it free software?

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d32jay22@latte.josefsson.org

Re: "X-" Prefixes deprecated by RFC 6648.

[Simon Josefsson]

Christoph Anton Mitterer  writes:

> Hey.
>
> Apart from the question whether this RFC is anyhow reasonable...
>
> On Thu, 2012-09-13 at 08:55 +0900, Charles Plessy wrote:
>> Category: Best Current Practice
> Can a BCP deprecate stuff which is standardised by RFCs from the
> standards track?

What RFCs are you thinking of?  The "X-" stuff was removed from e-mail
standards long time ago, IIRC.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mx0upc87@latte.josefsson.org

Re: "X-" Prefixes deprecated by RFC 6648.

[Simon Josefsson]

Christoph Anton Mitterer  writes:

> On Thu, 2012-09-13 at 10:18 +0200, Simon Josefsson wrote:
>> What RFCs are you thinking of?  The "X-" stuff was removed from e-mail
>> standards long time ago, IIRC.
> Well I don't have all RFCs in mind,... but weren't there others, that
> gave "x-" that meaning for e.g. MIME types or URI schemas?

I believe people have discovered that the x- scheme is a bad idea for
several reasons, and those reasons apply to MIME types and URI schemes
as well.  And possibly also what X- is used for in Debian.  RFC 6648
doesn't obsolete the earlier RFCs, but describe actions that should be
considered when the earlier RFCs are eventually updated.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehm5nkyz@latte.josefsson.org

debian/copyright, DEP5 and SPDX

[Simon Josefsson]

I just stumbled upon this initiative:

http://www.spdx.org/

It is a way to specify the licensing and copyright information (and
more) for software packages.  There is some overlap between
debian/copyright file and especially the DEP5 format.  Alas, the SPDX
format is XML based, an example for GNU CoreUtils is available here (but
it seems to be buggy, it should use 'GPL-3.0+' instead of 'GPL-3.0'):

http://www.spdx.org/system/files/coreutils.rdf_.xml

Adopting something like this for an entire distribution might be useful
but will require a lot of work.  Maybe the debian/copyright files could
be permitted to reference another file shipped with the package that
contains the complete information?

Possibly DEP5-compliant files could be generated from SPDX files.

I don't have any question or suggestion what to do with this, but I
thought some people here might find it interesting.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877h207b7m@latte.josefsson.org

Re: debian/copyright, DEP5 and SPDX

[Simon Josefsson]

Michael Shuler  writes:

> On 12/13/2011 09:17 AM, Simon Josefsson wrote:
>> Possibly DEP5-compliant files could be generated from SPDX files.
>
> This has come up in several DEP5 discussions over the past ~year, as
> well as several recent mentions:
>
> https://www.google.com/search?q=spdx+site%3Alists.debian.org

Thanks for pointers, I'm happy to see that there is already some planned
use here.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxavjn2b@latte.josefsson.org

Re: Clarifying the mandatory contents of the Debian copyright file.

[Simon Josefsson]

Russ Allbery  writes:

>> Note that "Copyright (C) 2008 Peter Miller" is different than "Copyright
>> (C) 2011 Peter Miller" is different than "Copyright (C) 1991, 2012 Peter
>> Miller", so the cross product is going to be substantial for long lived
>> projects, even when the number of contributors is small.
>
> I am absolutely certain that this is not the intention of DEP-5, and I
> would be in favor of modifying it to make that clear if you could identify
> the places where you got that mistaken impression.

I would support making this clearer by adding the example above to DEP5.
When I have written DEP5 copyright files, I have been uncertain about
this aspect too, but I can't point to anything directly in the document
that gave me this impression (nor to anything that would have given me
the reversed impression).  An example would probably have helped.

Thinking even further, maybe there should be a tutorial at the end of
DEP5 on how to convert an existing compliant debian/copyright file into
a DEP5-compliant debian/copyright file.  As far as I understand from
this discussion, it would be sufficient to merely make it syntactically
conform to the DEP5 file format, typically by folding the old data under
a 'Files: *' header.  If this is the case, and there is an example on
how to do it, this could trigger more DEP5 adoption.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hazt8g5w@latte.josefsson.org

libidn re-license

[Simon Josefsson]

I co-maintain the libidn package.  As upstream, I recently relicensed it
from LGPLv2+ to GPLv2+|LGPLv3+.  I'd like to upload the latest version
into Debian before Wheezy since a pretty nasty inifinte-loop bug has
been fixed.  However, I am not certain what should be done before
uploading a re-licensed package, so I am asking for guidance.  I have
looked at licenses of reverse dependencies, and I did found some
GPLv2-only packages.  That caused me to dual license the package instead
of going to LGPLv3+. (GPLv2-only and LGPLv3+ are incompatible.)  I am
not aware of any other license that could pose any problem with a
dual-licensed GPLv2+|LGPLv3+ package.  I didn't find any other obvious
problem when I looked at the reverse dependencies.

Is there any policy or best current practice about what needs to be done
in this situation?  Should I just upload to unstable and let people work
out license (in)compatibility later on?  I'm sure this must have come up
before for other packages that have been relicensed, but I couldn't find
any generic advice.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hay1r086@latte.josefsson.org

Re: libidn re-license

[Simon Josefsson]

Paul Wise  writes:

> I would suggest asking the FSF licensing folks and debian-legal.

Good point about debian-legal, I'll repost the question there.  I have
talked to the FSF and they suggest LGPLv3+ but will live with
dual-GPLv2+|LGPLv3+ if there are significant GPLv2-only applications in
the free software community, which there appears to be.

Thanks,
/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sjhkpyzg@latte.josefsson.org

Re: libidn re-license

[Simon Josefsson]

Florian Weimer  writes:

> * Simon Josefsson:
>
>> I co-maintain the libidn package.  As upstream, I recently relicensed it
>> from LGPLv2+ to GPLv2+|LGPLv3+.  I'd like to upload the latest version
>> into Debian before Wheezy since a pretty nasty inifinte-loop bug has
>> been fixed.
>
> Should we get that into stable-security, under the old license?

It wouldn't hurt, but I'm also not sure if it is worth the work.  If any
significant application triggered this particular code path, people
should have noticed the problem a long time ago.  It is at worst an
easily diagnozed DoS causing the library to busy-loop forever.  All the
pr29_* functions are affected, but they don't appear to be widely used.

>> (GPLv2-only and LGPLv3+ are incompatible.)
>
> Nowadays, almost all GPLv2-only programs link to library code licensed
> under the GPLv3 (with a linking exception on the library side), so we
> pretend that they are, at least to some degree.

How does that link exception look like?  I only recall seeing
suggestions to use the dual-GPLv2+|LGPLv3+ approach as a workaround
before.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k42wpyif@latte.josefsson.org

Re: libidn re-license

[Simon Josefsson]

Florian Weimer  writes:

 (GPLv2-only and LGPLv3+ are incompatible.)
>>>
>>> Nowadays, almost all GPLv2-only programs link to library code licensed
>>> under the GPLv3 (with a linking exception on the library side), so we
>>> pretend that they are, at least to some degree.
>>
>> How does that link exception look like?
>
> 
>
> I don't think the exception makes the version 3 code compatible with
> version 2.

That applies only to GPLv3, doesn't it?  Libidn is now GPLv2+|LGPLv3+.
I don't immediately see how that exception could be used here.  I
wouldn't want to s/GPLv3/GPLv2+|LGPLv3+/ on a document like that without
sanity checking by some legal entity.  I recall that the FSF and GCC
folks spent a lot of time working out that document.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gywqjqz@latte.josefsson.org

Re: libidn re-license

[Simon Josefsson]

Julien Cristau  writes:

> On Tue, Mar  6, 2012 at 20:35:53 +0100, Simon Josefsson wrote:
>
>> I co-maintain the libidn package.  As upstream, I recently relicensed it
>> from LGPLv2+ to GPLv2+|LGPLv3+.
>
> So maybe that's a stupid question, but... Why?  You didn't have enough
> license headaches?

Well, why not?  There was a reason the FSF published the LGPLv3 after
all.  Others have analyzed the reasons than I can (see for example [1]
and [2]).  The downsides (e.g., changing the license headers, and
discussions like this one) appears small in comparison to me.

/Simon

[1] http://eigen.tuxfamily.org/index.php?title=Licensing_FAQ
[2] http://www.winehq.org/pipermail/wine-devel/2007-July/058059.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87399kqiuq@latte.josefsson.org

Re: libidn re-license

[Simon Josefsson]

Thanks for several responses -- however the underlying question I had,
whether the upload the new package to unstable or not, was not resolved.
Does anyone see any reason to delay or abstain from the upload?  If not,
I'll do the upload within days.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762edlvob@latte.josefsson.org

Re: (seemingly) declinging bug report numbers

[Simon Josefsson]

Marco Nenciarini  writes:

> Il giorno gio, 11/10/2012 alle 02.46 +0200, Christoph Anton Mitterer ha
> scritto:
>> 
>> On the other hand, some worries are there that this could imply some
>> decline in Debian itself.
>> Well I still think Debian is the best distro out there for most (if not
>> all cases), even though I'd like to see it putting more emphasis on
>> security.
>
> I've seen recently several company I'm working with getting away from
> Debian in favor of Ubuntu because they have a LTS version. However I
> don't know if this is a general trend.

I can confirm the trend for a couple of organisations.  The primary
reason that I identified was the retirement of security support for
Lenny and that Lenny packages are removed from many Debian mirrors which
made it difficult to use Lenny machines.  IMHO, supporting an OS release
for only 3 years is not long enough.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sj9k23nt@latte.josefsson.org