Bug#762456: ITP: ejabberd-contrib -- user-contributed modules for ejabberd
Package: wnpp Severity: wishlist Owner: Philipp Huebner * Package name: ejabberd-contrib Version : 0.2014.09.22 Upstream Author : ProcessOne * URL : https://github.com/processone/ejabberd-contrib * License : GPL 2+ Programming Lang: Erlang Description : user-contributed modules for ejabberd ejabberd-contrib ships some user-contributed modules for ejabberd, a distributed, fault-tolerant Jabber/XMPP server written in Erlang. . Currently this package contains only the following modules, more might be included when requested: * mod_admin_extra * mod_muc_admin -- 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/20140922131741.16946.18370.report...@emmagan.debalance.de
Bug#762459: ITP: bareos -- Backup Archiving Recovery Open Sourced
Package: wnpp Severity: wishlist Owner: Bareos Packaging Team * Package name: bareos Version : 14.2.1 Upstream Author : Bareos GmbH & Co. KG * URL : http://www.bareos.org * License : AGPL-3 Programming Lang: C Description : Backup Archiving Recovery Open Sourced Bareos is a set of programs to manage backup, recovery and verification of computer data across a network of computers of different kinds. . It is efficient and relatively easy to use, while offering many advanced storage management features that make it easy to find and recover lost or damaged files. Due to its modular design, Bareos is scalable from small single computer systems to networks of hundreds of machines. -- 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/20140922133831.31420.37665.reportbug@nana
Proper notation for common licenses
Hi all, I am seeking clarification how a proper license paragraph for copyright format 1.0 should be written. A while ago I have started to use this format [1] for common licenses when I saw that fellow maintainers did the same. I was recently informed that this format warrants a reject by the FTP team as announced at [2] and [3]. However I am not aware of recent rejected packages due to this kind of notation. I am wondering if those announcements from 2006 are still valid for copyright format 1.0 which seems to contradict [2] and states in [4] "Otherwise, this field should either include the full text of the license(s) or include *a pointer* to the license file under /usr/share/common-licenses." In addition Debian Policy §12.5 states: "Packages distributed under the Apache license (version 2.0), the Artistic license, the GNU GPL (versions 1, 2, or 3), the GNU LGPL (versions 2, 2.1, or 3), and the GNU FDL (versions 1.2 or 1.3) should *refer* to the corresponding files under /usr/share/common-licenses,[119] *rather than quoting them* in the copyright file." What do we gain by quoting common licenses in debian/copyright over and over again? Regards, Markus [1] Examples: License: GPL-2+ On Debian systems, the complete text of the GNU General Public License version 2 can be found in "/usr/share/common-licenses/GPL-2". License: GPL-2 On Debian systems, the complete text of the GNU General Public License version 2 can be found in "/usr/share/common-licenses/GPL-2". License: Apache-2.0 On Debian systems, the complete text of the Apache version 2.0 license can be found in "/usr/share/common-licenses/Apache-2.0". [2] https://lists.debian.org/debian-devel-announce/2006/03/msg00023.html [3] http://ftp-master.debian.org/REJECT-FAQ.html [4] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-field signature.asc Description: OpenPGP digital signature
Re: Proper notation for common licenses
On Mon, Sep 22, 2014 at 06:15:08PM +0200, Markus Koschany wrote: > What do we gain by quoting common licenses in debian/copyright over and > over again? We don't quote (i.e. include the *full* text of) common licenses over and over again, that's precisely what /usr/share/common-licenses is for, and this has been that way even before machine readable copyrights. (In other words: Sorry, I don't understand your question). -- 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/20140922163636.ga10...@cantor.unex.es
Re: Proper notation for common licenses
On 22.09.2014 18:36, Santiago Vila wrote: > On Mon, Sep 22, 2014 at 06:15:08PM +0200, Markus Koschany wrote: >> What do we gain by quoting common licenses in debian/copyright over and >> over again? > > We don't quote (i.e. include the *full* text of) common licenses over > and over again, that's precisely what /usr/share/common-licenses is for, > and this has been that way even before machine readable copyrights. > > (In other words: Sorry, I don't understand your question). > I was referring to the FTP master announcement from 2006 which claimed that version 1 is a requirement for debian/copyright but version 2 is wrong. The question is why is the simplified version 2 wrong when a pointer should be sufficient? Example: Version 1: License: GPL-2+ This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or any later version. . This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. . You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA . On Debian systems, the complete text of the GNU General Public License, version 2, can be found in /usr/share/common-licenses/GPL-2. Version 2: License: GPL-2+ On Debian systems, the complete text of the GNU General Public License version 2 can be found in "/usr/share/common-licenses/GPL-2". signature.asc Description: OpenPGP digital signature
Re: Proper notation for common licenses
Quoting Markus Koschany (2014-09-22 19:25:20) > On 22.09.2014 18:36, Santiago Vila wrote: >> On Mon, Sep 22, 2014 at 06:15:08PM +0200, Markus Koschany wrote: >>> What do we gain by quoting common licenses in debian/copyright over >>> and over again? >> >> We don't quote (i.e. include the *full* text of) common licenses over >> and over again, that's precisely what /usr/share/common-licenses is >> for, and this has been that way even before machine readable >> copyrights. >> >> (In other words: Sorry, I don't understand your question). >> > > I was referring to the FTP master announcement from 2006 which claimed > that version 1 is a requirement for debian/copyright but version 2 is > wrong. The question is why is the simplified version 2 wrong when a > pointer should be sufficient? > > Example: > > Version 1: > > License: GPL-2+ > This program is free software; you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > the Free Software Foundation; either version 2 of the License, or > any later version. > . > This program is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > GNU General Public License for more details. > . > You should have received a copy of the GNU General Public License > along with this program; if not, write to the Free Software Foundation, > Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > . > On Debian systems, the complete text of the GNU General Public > License, version 2, can be found in /usr/share/common-licenses/GPL-2. > > Version 2: > > License: GPL-2+ > On Debian systems, the complete text of the GNU General Public License > version 2 can be found in "/usr/share/common-licenses/GPL-2". Version 2 neither contains nor references "a verbatim copy of its copyright information" as required by Poicy - only its "distribution license" (which is only half of what Policy requires verbatim copy of). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Proper notation for common licenses
On 22/09/14 17:15, Markus Koschany wrote: > A while ago I have started to use this > format [1] for common licenses when I saw that fellow maintainers did > the same. > > [1] Examples: > > License: GPL-2+ > On Debian systems, the complete text of the GNU General Public > License version 2 can be found in "/usr/share/common-licenses/GPL-2". You are right that it is not required to quote the text of the GNU GPL. To be clear that we're talking about the same thing, the text of the GNU GPL is a lengthy document with (as of version 3) a "Preamble", 17 numbered sections of "Terms and Conditions", and an appendix "How to Apply These Terms to Your New Programs". However, these couple of paragraphs: This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. (or similar for v2) are not the GPL. That's just the (conventional form of the) license grant: the thing that gives you permission to distribute this work under the GPL. The point headed "Its not enough to have the following two-liner" in https://lists.debian.org/debian-devel-announce/2006/03/msg00023.html appears to be intended to be a requirement to reproduce the license grant in the copyright file, even if the work is under the GPL or another license in common-licenses. I'm not sure why the ftp-masters require the license grant to be copied into the copyright file, and it would be nice if there was wording in (capital P) Policy backing this up, or a definitive statement from the ftp-masters saying that, yes, they require license grants to be quoted even if the license text does not need to be copied (and preferably why); but at the moment the email to which you referred is as canonical a statement of (small p) policy as we have. For BSD and other highly permissive licenses, the license grant and the full license text are typically the same thing; for longer licenses like (L)GPL, GFDL, Creative Commons, Apache, MPL, etc., the license grant is somewhere between a couple of lines and a couple of paragraphs, the full license text is a multi-page thing, and it's a significant space-saving to be able to point into common-licenses (if allowed) even if you have to quote the license grant. Also note that (at least as far as I've gathered from Debian project folklore, and I'd appreciate a ftp-master ruling on this one way or the other) the license grant you're meant to reproduce is the one that the copyright holder actually wrote, not the one that is standard/recommended/conventional for the license. openarena-data contains a couple of files with very truncated GPL license grants: License: short-GPL-2 "released under the gpl v2 license (read COPYING)" . You can find the GPL license text on a Debian system under /usr/share/common-licenses/GPL-2. License: even-shorter-GPL-2 "License: GPLv2" . You can find the GPL license text on a Debian system under /usr/share/common-licenses/GPL-2. I'm not sure how that interacts with license grants that are more vague than we'd really like (e.g. a top-level COPYING file, no per-file notices, and a statement somewhere that the work is under the license in COPYING), which are particularly common in games and other non-commercial projects maintained by people who don't necessarily understand the finer points of licensing. It would be great if the ftp-masters could confirm whether what I've said in this mail is true, and the reasoning behind it. Regards, S -- 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/54207f17.3050...@debian.org
Re: Proper notation for common licenses
On 22/09/14 18:48, Jonas Smedegaard wrote: > Quoting Markus Koschany (2014-09-22 19:25:20) >> Version 1: >> >> License: GPL-2+ >> This program is free software; you can redistribute it and/or [...] >> This program is distributed in the hope that it will be [...] >> You should have received a copy of the GNU General Public License [...] >> On Debian systems, [...] >> >> Version 2: >> >> License: GPL-2+ >> On Debian systems, the complete text of the GNU General Public License >> version 2 can be found in "/usr/share/common-licenses/GPL-2". > > Version 2 neither contains nor references "a verbatim copy of its > copyright information" as required by Poicy - only its "distribution > license" (which is only half of what Policy requires verbatim copy of). I assume what Markus meant is that the full copyright file would have one or more DEP-5 Files paragraphs with a one-line License, like Files: examples/* Copyright: © 2012 Mickey Mouse © 2012-2014 Minnie Mouse © 2014 Donald Duck License: GPL-2+ in both cases, followed by either the "version 1" or "version 2" DEP-5 standalone license paragraph as above, with the choice between his "version 1" or "version 2" being the intended outcome of this thread. Or are you saying you consider the license grant quoted in "version 1" to be part of the "copyright information" in Policy? S -- 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/54208100.9080...@debian.org
Bug#762496: RFP: typerep -- Runtime types for OCaml
Package: wnpp Severity: wishlist * Package name: typerep Version : 111.17.00 Upstream Author : Jane Street Capital LLC * URL or Web page : https://github.com/janestreet/typerep * License : Apache-2.0 Description : Runtime types for OCaml This package is needed by newer versions of the Core library -- 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/87zjdr4ccf@msgid.hilluzination.de
Bug#762504: RFP: pa-bench -- OCaml syntax extension for writing inline benchmarks
Package: wnpp Severity: wishlist * Package name: pa-bench Version : 111.28.00 Upstream Author : Jane Street Capital LLC * URL or Web page : https://github.com/janestreet/pa_bench * License : Apache-2.0 Description : OCaml syntax extension writing inline benchmarks This package is needed by newer versions of the Core library -- 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/87h9zz49hp@msgid.hilluzination.de
Bug#762505: RFP: pa-test -- OCaml syntax extension for writing inline tests
Package: wnpp Severity: wishlist * Package name: pa-test Version : 111.08.00 Upstream Author : Jane Street Capital LLC * URL or Web page : https://github.com/janestreet/pa_test * License : Apache-2.0 Description : OCaml syntax extension for writing inline tests This package is needed by newer versions of the Core library -- 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/87fvfj49hb@msgid.hilluzination.de
Bug#762506: RFP: enumerate -- OCaml quotation expanders for enumerating finite types
Package: wnpp Severity: wishlist * Package name: enumerate Version : 111.08.00 Upstream Author : Jane Street Capital LLC * URL or Web page : https://github.com/janestreet/enumerate * License : Apache-2.0 Description : OCaml quotation expanders for enumerating finite types This package is needed by newer versions of the Core library. -- 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/87fvfjuxb9@msgid.hilluzination.de
Re: apache2 issues
On 29 July 2014 19:04, Jeroen Dekkers wrote: > As far as I can see this is a bug in the apache2 packaging. The httpd > virtual package should be provided by the apache2 package, not the > apache2-bin package, because the apache2-bin package doesn't provide a > working webserver. Bug report I just filed about this: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756361 Ok, this bug was fixed, leading me to re-investigate this again. > It isn't very easy to specify what httpd-wsgi should mean, because > some WSGI servers are full webservers with WSGI support such as apache > and others like gunicorn are only supposed to run behind a proxying > server such as apache or nginx (similar to for example php-fpm). > > So as far as I can see, the correct dependency should be: > > Depends: libapache2-mod-wsgi | httpd-wsgi, apache2 | httpd > > So it also possible to run other webservers. > I just noticed there is still another potential problem. With the above, either libapache2-mod-wsgi (Python2 only) or libapache2-mod-wsgi-py3 (Python3 only) will satisfy the depends. Does this mean I should also depend on both python-* and python3-*? Even though only one will ever get used? What happens if the package only has Python2 or Python3 support, not both? To me, it is starting to look like we need two virtual packages for httpd-wsgi - one for Python2, and one for Python3. Then I can explicitly set use one my Depends (e.g. Python3), and not worry about supporting the other Python version (e.g. Python2). -- Brian May
Re: Proper notation for common licenses
Quoting Simon McVittie (2014-09-22 22:05:20) > On 22/09/14 18:48, Jonas Smedegaard wrote: >> Quoting Markus Koschany (2014-09-22 19:25:20) >>> Version 1: >>> >>> License: GPL-2+ >>> This program is free software; you can redistribute it and/or [...] >>> This program is distributed in the hope that it will be [...] >>> You should have received a copy of the GNU General Public License [...] >>> On Debian systems, [...] >>> >>> Version 2: >>> >>> License: GPL-2+ >>> On Debian systems, the complete text of the GNU General Public License >>> version 2 can be found in "/usr/share/common-licenses/GPL-2". >> >> Version 2 neither contains nor references "a verbatim copy of its >> copyright information" as required by Poicy - only its "distribution >> license" (which is only half of what Policy requires verbatim copy >> of). > > I assume what Markus meant is that the full copyright file would have > one or more DEP-5 Files paragraphs with a one-line License, like > > Files: > examples/* > Copyright: > © 2012 Mickey Mouse > © 2012-2014 Minnie Mouse > © 2014 Donald Duck > License: GPL-2+ > > in both cases, followed by either the "version 1" or "version 2" DEP-5 > standalone license paragraph as above, with the choice between his > "version 1" or "version 2" being the intended outcome of this thread. > Or are you saying you consider the license grant quoted in "version 1" > to be part of the "copyright information" in Policy? Sorry - I meant that full _licensing_ was not verbatim copied - i.e. what you call "license grant" in your other post. Your other post is spot on - let's continue that part of the thread and just ignore my confusing scribblings here. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: apache2 issues
Quoting Brian May (2014-09-23 08:02:22) >On 29 July 2014 19:04, Jeroen Dekkers <[1]jer...@dekkers.ch> wrote: > > As far as I can see this is a bug in the apache2 packaging. The httpd > virtual package should be provided by the apache2 package, not the > apache2-bin package, because the apache2-bin package doesn't provide a > working webserver. Bug report I just filed about this: > [2]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756361 > >Ok, this bug was fixed, leading me to re-investigate this again. > > > It isn't very easy to specify what httpd-wsgi should mean, because > some WSGI servers are full webservers with WSGI support such as apache > and others like gunicorn are only supposed to run behind a proxying > server such as apache or nginx (similar to for example php-fpm). > > So as far as I can see, the correct dependency should be: > > Depends: libapache2-mod-wsgi | httpd-wsgi, apache2 | httpd > > So it also possible to run other webservers. > >I just noticed there is still another potential problem. >With the above, either libapache2-mod-wsgi (Python2 only) >or libapache2-mod-wsgi-py3 (Python3 only) will satisfy the depends. >Does this mean I should also depend on both python-* and python3-*? Even >though only one will ever get used? >What happens if the package only has Python2 or Python3 support, not both? >To me, it is starting to look like we need two virtual packages for >httpd-wsgi - one for Python2, and one for Python3. Then I can explicitly >set use one my Depends (e.g. Python3), and not worry about supporting the >other Python version (e.g. Python2). Isn't that an implementation detail? Is Python version relevant for the on-the-wire WSGI protocol? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
