Re: glibc2.0-2.1 incompatibility: _xstat?
Marco d'Itri [EMAIL PROTECTED] writes: Is there a workaround, so that I can continue to use these libraries? Write a small shared library providing _xstat and preload it. I wrote this to do that, unfortunely it wasn't enough for my program (a program compiled with the Portland Groups' fortran compiler) but maybe it is for others. Usage is something like LD_PRELOAD=libxstat.so ./myoldlibcprogram. ;;; xstat.s ;;; ;;; cc -c xstat.s ;;; ld -shared -soname libxstat.so.0 -o libxstat.so xstat.o -lc .text .globl _xstat .globl _lxstat .globl _fxstat .globl _xmknod _xstat: .weak _xstat .weak __xstat _lxstat: .weak _lxstat .weak __lxstat _fxstat: .weak _fxstat .weak __fxstat _xmknod: .weak _xmknod .weak __xmknod
Packages containing RFCs
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.txt.gz
Re: Packages containing RFCs
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
Re: Packages containing RFCs
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
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 @@
ttdebian/copyright/tt 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 a
href=http://release.debian.org/removing-non-free-documentation;tt
+ http://release.debian.org/removing-non-free-documentation/tt/a.
+
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
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 http://www.gnu.org/licenses/why-not-lgpl.html. /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
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
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
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?
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?
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?
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?
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?
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?
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.30view=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?
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.30view=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?
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?
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?
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
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
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
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
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, insert other IETF acronyms 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
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
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
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
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]
Re: Outdated config.{sub,guess} package list
Michal Čihař ni...@debian.org writes:
Dne Sat, 25 Apr 2009 07:10:24 +0300
Peter Eisentraut pete...@gmx.net 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?]
Roger Leigh rle...@codelibre.net 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?]
Philipp Kern tr...@philkern.de writes: On 2009-05-11, Brian May b...@snoopy.debian.net 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?]
Jakub Wilk uba...@users.sf.net writes: * Simon Josefsson si...@josefsson.org, 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: Second call for votes for the debian project leader election 2007
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...
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?
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: intent to hijack gsasl
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: nethack -- Doesn't purge all files after piuparts Install+Upgrade+Purge test
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 !
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
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
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
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
Neil Williams codeh...@debian.org writes: On Fri, 16 Jan 2009 08:45:12 +0100 Kjeldgaard Morten m...@bioxray.au.dk 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
James Vega james...@debian.org writes: On Thu, Jan 15, 2009 at 4:55 PM, markus schnalke mei...@marmaro.de wrote: [2009-01-15 22:37] Michael Goetze mgoe...@mgoetze.net 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
Neil Williams codeh...@debian.org writes: On Fri, 16 Jan 2009 13:24:58 +0100 Simon Josefsson si...@josefsson.org wrote: Neil Williams codeh...@debian.org 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
Johannes Wiedersich johan...@physik.blm.tu-muenchen.de 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
Bernd Eckenfels e...@lina.inka.de 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: Requirement for a “proper manpage” for every command
Ben Finney ben+deb...@benfinney.id.au 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: Parallel build results
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]
corrupt zip/tar archives in the repository?
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]
Mass bug filing: corrupt zip/tar archives in the repository?
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
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
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
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: Fun with libtool and cross-builds
Wookey woo...@wookware.org 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: sslv2 and openssl 1.0
If there are any packages that uses SSLv2 by default you might want to file a security bug to get them fixed. I believe SSLv2 is really that bad, it just gives a false sense of security. /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/87mxk5hi3i@latte.josefsson.org
Re: Crypto consolidation in debian ?
Roger Leigh rle...@codelibre.net writes: On Wed, Apr 27, 2011 at 09:30:05AM -0700, Russ Allbery wrote: Bastien ROUCARIES roucaries.bast...@gmail.com writes: Patches to WebAuth to support NSS are welcome, but I'm sure not going to bother. Seems like a waste of time to me. If I were going to port to any other crypto library, I'd port to gcrypto, not NSS. See also that suse consider to port to nss http://old-en.opensuse.org/SharedCertStore That's fine. They can send me patches too if they want. :) I'm still not interested; I'd rather put whatever time I had into making gnutls and gcrypto better, particularly since I think FIPS certification is just a money-making racket. libgcrypt has some horrendous bugs which upstream refuse to fix, for example the broken behaviour relating to setuid binaries discussed previously here, and the hard coded behaviour which makes it unsuitable for use in general programs. See libgcrypt brain dead? 3c5cf5261003081534s5202413dw4d93c80db1a30...@mail.gmail.com Until these major issues are fixed, it's simply unusable. It appears to be usable by a lot of projects and people, so that seems like an exaggeration. If I have understood Werner correctly, he believes that it is the setuid binaries that are broken and should be fixed. /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/87vcxy34kj@latte.josefsson.org
Re: Crypto consolidation in debian ?
m...@linux.it (Marco d'Itri) writes: On Apr 27, Bastian Blank wa...@debian.org wrote: On Tue, Apr 26, 2011 at 07:20:55PM +0200, Marco d'Itri wrote: The reason is that the kind of entities which require FIPS 140 probably also tend to require corporate vendor support, which we do not provide. What is FIPS 140 and why is this important? It is a certification required by USG and many financial customers. For what it's worth, libgcrypt was in FIPS evaluation long time ago and may even be certified by now. /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/87zkna34qf@latte.josefsson.org
Re: Crypto consolidation in debian ?
Roger Leigh rle...@codelibre.net writes: This is the root cause, I think. libgcrypt was developed as part of gnutls, and although it's a separate library, it's insufficiently generalised. It's implicitly doing things the way gnutls wanted them doing, and rather than making the library completely general and moving special case logic into the callers (or only doing it upon specific request), we're in the situation we have now: breakage. Libgcrypt was designed for GnuPG, not GnuTLS. Btw, for these and other reasons, recent versions of GnuTLS support the GNU Nettle backend as well as Libgcrypt. It would be great if Debian could move to it, although GNU Nettle depends on GMP which is LGPLv3+. /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/87k4eazb0w@latte.josefsson.org
Re: Best practice for cleaning autotools-generated files?
Enrico Weigelt weig...@metux.de writes: * Henrique de Moraes Holschuh h...@debian.org schrieb: I'm (as upstream) using serval macros in their own .m4 files (eg. in ./m4/, maybe even sorted into subdirs). Can autoreconf figure out the required search pathes all on its own ? The problem is that autoreconf offers NO command line options for you to pass the required -I parameters for aclocal, nor is there a way to encode that information in the one place where it could conveniently live (configure.ac) AFAIK. So, more precisely: autoreconf lacks an important feature would like to see. I don't think this is the case -- others have already explained how to achieve the goals above. If you still believe something is missing in autoreconf, please report it to upstream so it can be fixed. /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/87sjsp643z@latte.josefsson.org
Re: libgcrypt brain dead?
Brian May br...@microcomaustralia.com.au 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.
Mats Erik Andersson mats.anders...@gisladisker.se 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
Joerg Jaspert jo...@debian.org 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: Non-free IETF RFC/I-Ds in source packages
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
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
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
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 URL: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
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 rfc-editor@rfc-editor.org Subject: Re: Copyright and copying conditions for RFC 1510? To: Simon Josefsson [EMAIL PROTECTED] Cc: RFC Editor rfc-editor@rfc-editor.org 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
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
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
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
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]
Re: Archive signing key for 2007?
Anthony Towns aj@azure.humbug.org.au 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: Bug#580221: ITP: python-libssh2 -- python-libssh2 is a python binding for libssh2 library.
Frank Lin PIAT fp...@klabs.be 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)
Michael Banck mba...@debian.org 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
Hans-J. Ullrich hans.ullr...@loop.de 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
Peter Grasch gra...@simon-listens.org writes: Package: wnpp Severity: wishlist Owner: Peter Grasch gra...@simon-listens.org * Package name: simon Version : 0.3.0 Upstream Author : Peter Grasch gra...@simon-listens.org * 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
Samuel Thibault sthiba...@debian.org 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
Peter Grasch gra...@simon-listens.org 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
Peter Grasch gra...@simon-listens.org 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=6t=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
Peter Grasch gra...@simon-listens.org 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
debian/copyright, DEP5 and SPDX
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
Michael Shuler mich...@pbandjelly.org 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.
Russ Allbery r...@debian.org 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
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
Paul Wise p...@debian.org 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
Florian Weimer f...@deneb.enyo.de 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
Florian Weimer f...@deneb.enyo.de 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? http://www.gnu.org/licenses/gcc-exception.html 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
Julien Cristau jcris...@debian.org 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
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: Minified javascript files
Thomas Goirand z...@debian.org 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
Vincent Bernat ber...@debian.org writes: ❦ 19 août 2012 15:11 CEST, Bernhard R. Link brl...@debian.org : 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
Pau Garcia i Quiles pgqui...@elpauer.org writes: On Sun, Aug 19, 2012 at 8:10 PM, Simon Josefsson si...@josefsson.org 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
Andreas Tille andr...@an3as.eu 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
Andreas Tille andr...@an3as.eu 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
Damien Raude-Morvan draz...@drazzib.com 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.
Christoph Anton Mitterer cales...@scientia.net 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.
Christoph Anton Mitterer cales...@scientia.net 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
Re: (seemingly) declinging bug report numbers
Marco Nenciarini mnen...@debian.org 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
Re: GnuTLS in Debian
FWIW, I support moving forward with #6. /Simon You wrote: My gut reaction was that #5 or #6 are the best option (leaning to #6). However I guess I don't understand what making something a system library effects the license? Andreas Metzler ametz...@debian.org wrote: Hello, Debian ist still relying heavily on GnuTLS 2.12.x, and I do not think this is sustainable for much longer. State of Play: - In July 2011 with version 3.0 [1] GnuTLS switched to Nettle as only supported crypto backend. Nettle requires GMP. GnuTLS and Nettle are available under LGPLv2.1+. GMP used to be licensed LGPLv2.1+ ages ago but upgraded to LGPLv3+ in version 4.2.2 (released September 2007). Therefore GnuTLS 3.x cannot be used by GPLv2 (without or later clause) software which is the main reason most of Debian is still using GnuTLS 2.x. Problems: - GnuTLS 2.12.x is dated. It is upstream's old-old-old stable release (followed by 3.[012].x). The latest bugfix release happened in February 2012, later security fixes have not been solved by releases but by patches in GIT. GnuTLS 2.12.x does not work with the recently released gcrypt 1.6.0. Therefore we will need keep another old library version around. (I doubt that GnuTLS upstream will port GnuTLS 2.12.x to newer gcrypt.) How to continue from here/solve this: - #1 Fork LGPLv2.1+ GMP (version 4.2.1) for Debian. #2 Fork GnuTLS 2 for Debian. #3 Hope that GMP is relicensed to GPL2+/LGPLv3+ #4 Hop nettle switches to a different arbitrary precision arithmetic library. #5 Declare GMP to be a system library. #6 Move to GnuTLS3, drop GnuTLS2. Packages which cannot use GnuTLS3 for license reasons will need to drop TLS support or be relicensed or be ported to a different TLS library. Personal comments: - I do not think #1 and #2 are realistic given Debian's manpower issues. Also #1 would stop working at all if nettle required newer GMP features. (I have not checked whether this is already the case.) I have given up on #3 and do not think it will happen. GMP upstream has been made aware of the issue in 2011 [2] and has not shown any intention of a license change. #4 is just here for completeness sake. #5 was how Fedora looked at the OpenSSL library issue. Since Debian has another viewpoint on OpenSSL I somehow doubt we would use it for GMP. Fedora is discussing the issue in https://bugzilla.redhat.com/show_bug.cgi?id=986347. There is automatically generated depency tree with the problematic packages highlighted crosslinked in the bugreport[3]. Debian does not have the infrastructure to do something similar, but I guess gnutls usage is more widespread. Summary: - Afaict it boils down to #6. But perhaps I have missed something obvious. Comments welcome. cu Andreas [1] Version 2.11.1 (released 2010-09-14) used nettle as /prefered/ crypto backend, however gcrypt was still supported as alternative. [2] http://gmplib.org/list-archives/gmp-bugs/2011-February/002178.html http://gmplib.org/list-archives/gmp-devel/2011-May/001952.html [3] http://people.redhat.com/nmavrogi/fedora/out.fedora.txt -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- 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/20131223234308.7f717...@latte.josefsson.org
Bug#745139: ITP: libykneomgr -- Yubico YubiKey NEO Manager library and tool
Package: wnpp Severity: wishlist * Package name: libykneomgr Version : 0.1.2-1 Upstream Author : Simon Josefsson si...@yubico.com * URL : http://opensource.yubico.com/libykneomgr/ * License : LGPLv3+ Section : utils This is a C library to interact with the YubiKey NEO. There is a command line tool ykneomgr for interactive use. It supports querying the YubiKey NEO for firmware version, operation mode (OTP/CCID) and serial number. You may also mode switch the device and manage applets (list, delete and install). The Debian package is available on mentors for review: https://mentors.debian.net/package/libykneomgr Source code for the Debian package is available here: https://github.com/Yubico/libykneomgr-dpkg /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/20140418130442.6316e...@latte.josefsson.org
Re: Unicode 7.0 released - some packages contain outdated embedded data copies
Paul Wise p...@debian.org 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 ani...@debian.org 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
