Re: DEP-5 (copyright file format) ... gap with practice

[Jonathan Dowland]

On Thu, Sep 18, 2014 at 05:03:07PM -0400, David Prévot wrote:
> Why do you believe repacking upstream tarball should be the default
> behavior (especially when, as already pointed before, “You *should*
> upload packages with a pristine source tarball if possible”)?

I don't suppose I'll have much support for this, but in short: at
present, upstream tarball repacking is a relatively uncommon thing,
which means DDs have to dust the cobwebs off their mental manual (or
the actual manual) every time they either have to repack an upstream
source or interact with a repacked source. This is one of many things
which contribute to making Debian packaging complex and tricky for
newcomers.

If we repacked every tarball as a matter of course, then our
procedures are simpler: we've reduced the branching factor by one.

If we repacked by default then some of the things we'd like to do
with repacking, but put off because it's not worth repacking for
them alone, such as getting rid of some of the autoconf/automake
cruft (which is ignored/overwritten by use of dh-autoreconf etc.)
might be more widespread.

-- 
Jonathan Dowalnd


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140920213516.GA5577@debian

Re: DEP-5 (copyright file format) ... gap with practice

[Jonas Smedegaard]

Quoting Paul Wise (2014-09-19 05:46:12)
> On Thu, Sep 18, 2014 at 2:26 PM, Jonathan Dowlandwrote:
>
>> But how do you feel about the slightly different situation of 
>> shipping a pristine tarball but not performing an autoreconf (etc 
>> etc) prior to ./configure -- thus deviating from the "normal" process 
>> of building that package from source? At least it's very clear how an 
>> autoconf-output-stripped tarball is going to be built.
>
> We should be moving towards this:
>
> Pristine upstream tarballs.
> 
> Build tools automatically removing generated files (including 
> autotools files) and unmodified embedded code copies (including 
> autotools related files, m4 macros etc).

Agreed, but we must still respect copyright and licensing for all code 
that we distribute - also what we distribute in source form, even if 
regenerated during build.

How do we ensure that we respect copyright and licensing if we do not 
even bother to register what it is?

If some copyright and licensing need no "verbatim copy verbatim copy of 
its copyright information and distribution license", I believe that 
should be explicitly stated in Debian Policy §12.5 (and I guess that's 
also what ftpmasters would need for changing their current practise).


 - 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: DEP-5 (copyright file format) ... gap with practice

[Paul Wise]

On Thu, Sep 18, 2014 at 2:26 PM, Jonathan Dowlandwrote:

> But how do you feel about the slightly different situation of shipping a
> pristine tarball but not performing an autoreconf (etc etc) prior to
> ./configure -- thus deviating from the "normal" process of building that
> package from source? At least it's very clear how an
> autoconf-output-stripped tarball is going to be built.

We should be moving towards this:

Pristine upstream tarballs.

Build tools automatically removing generated files (including
autotools files) and unmodified embedded code copies (including
autotools related files, m4 macros etc).

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6ebnstktznzzynwtsmrwa2roaqffya2nk9dezcysd8...@mail.gmail.com

Re: DEP-5 (copyright file format) ... gap with practice

[David Prévot]

Hi,

Le 18/09/2014 02:28, Jonathan Dowland a écrit :

> what about
> extending uscan to have a list of autoconf-like files that it automatically
> excludes by default (override-able of course), saving people from listing
> the exact same files in Files-Excluded: for every autotools-using package?

Why do you believe repacking upstream tarball should be the default
behavior (especially when, as already pointed before, “You *should*
upload packages with a pristine source tarball if possible”)? Having
uscan making it easier to repack upstream tarball when it is *actually*
sensible shouldn’t be a good excuse to repack every upstream tarball by
default just because it’s easy…

Regards

David



signature.asc
Description: OpenPGP digital signature

Re: DEP-5 (copyright file format) ... gap with practice

[Jonathan Dowland]

On Mon, Sep 15, 2014 at 04:51:19PM +0200, Andreas Tille wrote:
> Just for the sake of interest:  Is there any reason not to use uscan?
> (I hope the answer will not be "since I need to remove files from
> upstream source.")

This wouldn't help those not using uscan, of which I am one, but what about
extending uscan to have a list of autoconf-like files that it automatically
excludes by default (override-able of course), saving people from listing
the exact same files in Files-Excluded: for every autotools-using package?


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140918062833.GA29551@debian

Re: DEP-5 (copyright file format) ... gap with practice

[Jonathan Dowland]

On Wed, Sep 10, 2014 at 12:27:58AM -0400, David Prévot wrote:
> On the other hand, it defeats the principle of least surprise.
> Distributing a different upstream tarball in Debian than upstream, just
> because, seems plain wrong. Even the dev-ref agrees: “You *should*
> upload packages with a pristine source tarball if possible”.

But how do you feel about the slightly different situation of shipping a
pristine tarball but not performing an autoreconf (etc etc) prior to
./configure -- thus deviating from the "normal" process of building that
package from source? At least it's very clear how an
autoconf-output-stripped tarball is going to be built.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140918062638.GB27586@debian

Re: DEP-5 (copyright file format) ... gap with practice

[Andrey Rahmatullin]

On Mon, Sep 15, 2014 at 04:51:19PM +0200, Andreas Tille wrote:
> > > Not sure how that's a lot of work since uscan does all the magic for
> > > you.  
> > I don't use uscan to download tarballs for packages I maintain. Not to
> > mention time required to fill in the Files-Excluded field.
> Just for the sake of interest:  Is there any reason not to use uscan?
For upstreams not using git I already have the new tarball downloaded
before I start working on it. uscan just doesn't have a place in my
workflows, it is necessary only when working on random packages from other
people.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: DEP-5 (copyright file format) ... gap with practice

[Andreas Tille]

Hi,

On Wed, Sep 10, 2014 at 10:48:22AM +0600, Andrey Rahmatullin wrote:
> On Tue, Sep 09, 2014 at 05:40:46PM -0400, Michael Gilbert wrote:
> > Not sure how that's a lot of work since uscan does all the magic for
> > you.  
> I don't use uscan to download tarballs for packages I maintain. Not to
> mention time required to fill in the Files-Excluded field.

Just for the sake of interest:  Is there any reason not to use uscan?
(I hope the answer will not be "since I need to remove files from
upstream source.")

Kind regards

 Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140915145119.ge6...@an3as.eu

Re: DEP-5 (copyright file format) ... gap with practice

[Stefano Zacchiroli]

On Wed, Sep 10, 2014 at 11:48:38PM +0900, Osamu Aoki wrote:
> The debmake command (in python) offers such copyright file
> verification against the current source files by running it in the
> source tree as.

Thanks Osamu, I meant to check the implementation before replying, but
ran out of time before doing that --- so better ask here directly and
let others know than forget about this :)

Is debamake's implementation of this feature based on the same corpus of
"well-known license paragraphs" than that mentioned in this thread
earlier on? If so, I'd say that it would be best not to scatter that
corpus of information in multiple places, as divergences might be quite
annoying.

Or is debmake only comparing past debian/copyright declarations by the
maintainer with the licenses it can currently infer from the upstream
package? That would be tremendous help for the maintainer, but it's a
different issue than the one we are discussing here.

Finally, it's great that debmake can help maintainer with this, but
unfortunately that won't help maintainers which are not using debmake.
Given that lintian is a tool that all maintainers are supposed to use
(and also a tool for which we have a project-wide monitoring
infrastructure at lintian.d.o), I believe it'd be much better to
integrate in lintian these warnings, than to have them emitted by
various tools which are opt-in for individual maintainers.

That said, I'll definitely start playing with debmake -k on my own
packages and see how it goes :-)
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: DEP-5 (copyright file format) ... gap with practice

[Osamu Aoki]

Hi here is an example:

On Wed, Sep 10, 2014 at 11:48:38PM +0900, Osamu Aoki wrote:
...
> $ debmake -k
...
=== debian/copyright checked for 90 data ===
Pattern #00: *
  File: data/symbol.txt
- GPL-2+
+ BSD-3-Clause

Pattern #00: *
  File: depcomp
config.sub
m4/intltool.m4
config.guess
compile
py-compile
missing
- GPL-2+
+ GPL-2.0+ with autoconf exception

Pattern #00: *
  File: ltmain.sh
- GPL-2+
+ GPL-2.0+ with libtool exception

Pattern #00: *
  File: icons/Makefile.am
data/Makefile.am
- GPL-2+
+ LGPL-2.0+

Pattern #00: *
  File: install-sh
- GPL-2+
+ MIT

Pattern #00: *
  File: m4/intlmacosx.m4
m4/lib-prefix.m4
m4/po.m4
m4/ltoptions.m4
po/Makefile.in.in
src/Makefile.in
m4/Makefile.in
config.rpath
icons/Makefile.in
Makefile.in
aclocal.m4
m4/lt~obsolete.m4
m4/gettext.m4
setup/Makefile.in
m4/ltsugar.m4
m4/ltversion.m4
m4/lib-link.m4
m4/iconv.m4
m4/nls.m4
m4/lib-ld.m4
data/Makefile.in
configure
m4/progtest.m4
INSTALL
m4/libtool.m4
- GPL-2+
+ PERMISSIVE

Pattern #00: *
  File: po/zh_CN.po
po/ko.po
- GPL-2+
+ _SAME_

... Maybe I need to update some of my old packages but that is a lot of
thankless work...

Osamu


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140910145441.GA11298@goofy.local

Re: DEP-5 (copyright file format) ... gap with practice

[Osamu Aoki]

Hi,

On Wed, Sep 10, 2014 at 10:20:06AM +0200, Stefano Zacchiroli wrote:
> How about using your snippet to improve our packaging work-flows
> instead? For instance, we can have a lintian check that verifies if
> those files are present in the source package and emit a warning if they
> are not listed (with the correct license) in debian/copyright.
  ^^

The debmake command (in python) offers such copyright file verification
against the current source files by running it in the source tree as.

$ debmake -k

Its manpage goes as:
 -k, --kludge
 compare the debian/copyright file with the source and exit.

 The debian/copyright file must be organized to list the generic
 file patterns before the specific exceptions.

 ·   -k: basic output style

 ·   -kk: verbose output style

It will most likely give you a nice list of such files noting changes of
license and missing licenses.

I am wondering if it is really useful or not for the case of
auto-generated permissive files.  If dropping those files is the
accepted standard behavior (even if it is not codified after this
discussion), I am thinking of dropping those files from the emitted
default output list of -k and template copyright file it generates
unless specifically asked.

Osamu

PS: 
The copyright phrase parser of the debmake command is much tighter than
the licensecheck (in perl) one.


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140910144838.GB8886@goofy.local

Re: DEP-5 (copyright file format) ... gap with practice

[Stefano Zacchiroli]

On Wed, Sep 10, 2014 at 10:01:42AM +0200, Jonas Smedegaard wrote:
> How about - instead of codifying into Polict that some licensing is ok 
> to ignore (which sounds very wrong to me) we instead recognize that some 
> pattern of files are very commonly the same across packages: Add a DEP-5 
> snippet to /usr/share/common-licenses that is always assumed included in 
> debian/copyright of any package.
> 
> Concretely I propose the attached file for that.

Thanks a lot for your snippet!, I find it very helpful.

OTOH, the proposal of shipping it under /usr/share/common-licenses/
violates the self-containedness of copyright information, which is a
nice property to have.  (To some extent we already violate that property
by shipping some full license texts under /usr/share/common-licenses/,
but at least the information about the mapping file<->license names is
currently expected to be available in the packages themselves.)

How about using your snippet to improve our packaging work-flows
instead? For instance, we can have a lintian check that verifies if
those files are present in the source package and emit a warning if they
are not listed (with the correct license) in debian/copyright.

Note that, thanks to the semantics of DEP-5, it is possible to do this
properly and avoid false positives also in the few cases where the files
are present in the source package but do not need explicit mention
(e.g., because their license matches the more general license of the
rest of the package).

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: DEP-5 (copyright file format) ... gap with practice

[Jonas Smedegaard]

Quoting Russ Allbery (2014-09-10 06:38:21)
> Osamu Aoki  writes:
>
>> It may be good to have a set of specifically defined file types for
>> exclusion in DEP-5 policy.  Then we can skip listing them in the
>> copyright file.  The helper script can generate a template for the
>> copyright file in line with the actual practice and not to contradict
>> with the DEP-5 policy.
>
> The general rule of thumb appears to be that, provided that the files 
> are DFSG-free and don't pose any surprises or conflicts, there's no 
> need to exhaustively document any source files that are only used as 
> part of the build system and don't contribute code to the binary 
> package.
> 
> I've wanted to document this explicitly in Policy for a while, but the 
> blocker is that I've never been able to get anyone to commit to a 
> clear enough rule that it felt like something we could put in Policy.  
> For example, I'm not sure if it applies to the build system in 
> general, or if it's specifically for Autoconf, Automake, Libtool, and 
> friends, which have very well-known and standard license behavior and 
> are common across vast swaths of the archive.
> 
> If we had a concrete rule, we could document it in Policy.
> 
> Personally, I just document the licenses of all of those files in my 
> debian/copyright files, but I also automated that (with a truly awful 
> and horrible Perl script).  And I'm not sure that documentation is 
> really of much use.

I do the same: document all those licenses in debian/copyright.  And 
also noticed a strong pattern of those files when doing that across 
maybe 50 packages.

How about - instead of codifying into Polict that some licensing is ok 
to ignore (which sounds very wrong to me) we instead recognize that some 
pattern of files are very commonly the same across packages: Add a DEP-5 
snippet to /usr/share/common-licenses that is always assumed included in 
debian/copyright of any package.

Concretely I propose the attached file for that.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Files: lt*.m4
Copyright: 2004-2005,2007-2009, Free Software Foundation
License: GAP

Files: aclocal.m4
 config.guess
 config.sub
 compile
 depcomp
 missing
Copyright: Free Software Foundation, Inc.
License: GPL-2+ with Autoconf exception
 As a special exception to the GNU General Public License, if you
 distribute this file as part of a program that contains a
 configuration script generated by Autoconf, you may include it under
 the same distribution terms that you use for the rest of that program.

Files: ltmain.sh
 libtool.m4
Copyright: Free Software Foundation, Inc.
License: GPL-2+ with Libtool exception
 As a special exception to the GNU General Public License, if you
 distribute this file as part of a program or library that is built
 using GNU Libtool, you may include this file under the same
 distribution terms that you use for the rest of that program.

Files: configure
Copyright: Free Software Foundation, Inc.
License: GAP~configure

Files: install-sh
Copyright: X Consortium
License: Expat~X with X exception
 Except as contained in this notice, the name of the X Consortium shall
 not be used in advertising or otherwise to promote the sale, use or
 other dealings in this Software without prior written authorization
 from the X Consortium.

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, 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.
Comment:
 On Debian systems the 'GNU General Public License' version 2 is located
 in '/usr/share/common-licenses/GPL-2'.
 .
 You should have received a copy of the 'GNU General Public License'
 along with this program.  If not, see .

License: Expat~X
 Permission is hereby granted, free of charge, to any person obtaining a
 copy of this software and associated documentation files (the
 "Software"), to deal in the Software without restriction, including
 without limitation the rights to use, copy, modify, merge, publish,
 distribute, sublicense, and/or sell copies of the Software, and to
 permit persons to whom the Software is furnished to do so, subject to
 the following conditions:
 .
 The above copyright notice and this permission notice shall be included
 in all copies or substantial portions of the Software.
 .
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 M

Re: DEP-5 (copyright file format) ... gap with practice

[Michael Gilbert]

On Wed, Sep 10, 2014 at 12:48 AM, Andrey Rahmatullin wrote:
>> another clear benefit is reduced package cruft.
> The only thing that is reduced is the size of the orig tarball.

People do actually do review package source changes (think every
release team unblock, security analysis, etc.), and the hugeness of
autotools diff is more often than not rather burdensome.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANTw=MPBCrq5J8yTvkQm1eHnwv6tM=VCnDoQpWn2EQ=08xu...@mail.gmail.com

Re: DEP-5 (copyright file format) ... gap with practice

[Andrey Rahmatullin]

On Tue, Sep 09, 2014 at 05:40:46PM -0400, Michael Gilbert wrote:
> >> You could always use the Files-Excluded field to make uscan remove
> >> those files from the upstream tarball,
> > Too much work (at least when you are not repacking the tarball for other
> > reasons) for absolutely no gain.
> Not sure how that's a lot of work since uscan does all the magic for
> you.  
I don't use uscan to download tarballs for packages I maintain. Not to
mention time required to fill in the Files-Excluded field.

> One benefit is less time on copyright file research/review, and
People actually check licenses for autotools generated files?

> another clear benefit is reduced package cruft.
The only thing that is reduced is the size of the orig tarball.

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140910044822.gb29...@belkar.wrar.name

Re: DEP-5 (copyright file format) ... gap with practice

[Charles Plessy]

Le Mon, Sep 08, 2014 at 08:12:01PM +0200, Jonas Smedegaard a écrit :
> 
> Quoting Osamu Aoki (2014-09-08 17:38:41)
> > DEP-5 as defined in http://dep.debian.net/deps/dep5/ does not have any 
> > clause allowing us to skip license entries for certain class of files.
> 
> I believe the "problem" is not DEP-5 but Debian Policy.

Hi Osamu and Jonas,

the final authority to decide what debian/copyright must contain is the FTP
team.  There is a long-standing tolerance for not documenting the files
autogenerated by the autotools system, but it has not been formally codified,
so the Policy can not reflect this flexibility.

Note that for the M4 macros, some do not come from the autotools system, and
while one may find packages in the Debian archive where the license and
copyright of these files has been omitted, my gut feeling is that it is not
compliant with the FTP team's views on the debian/copyright file.

But the best is that you ask for a first-hand recommendation from the FTP
team.  If you get an answer, you are welcome to forward it to #462996 or
open a new bug so that we can reflect it in the Policy.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140910044423.gc24...@falafel.plessy.net

Re: DEP-5 (copyright file format) ... gap with practice

[Russ Allbery]

Osamu Aoki  writes:

> It may be good to have a set of specifically defined file types for
> exclusion in DEP-5 policy.  Then we can skip listing them in the
> copyright file.  The helper script can generate a template for the
> copyright file in line with the actual practice and not to contradict
> with the DEP-5 policy.

The general rule of thumb appears to be that, provided that the files are
DFSG-free and don't pose any surprises or conflicts, there's no need to
exhaustively document any source files that are only used as part of the
build system and don't contribute code to the binary package.

I've wanted to document this explicitly in Policy for a while, but the
blocker is that I've never been able to get anyone to commit to a clear
enough rule that it felt like something we could put in Policy.  For
example, I'm not sure if it applies to the build system in general, or if
it's specifically for Autoconf, Automake, Libtool, and friends, which have
very well-known and standard license behavior and are common across vast
swaths of the archive.

If we had a concrete rule, we could document it in Policy.

Personally, I just document the licenses of all of those files in my
debian/copyright files, but I also automated that (with a truly awful and
horrible Perl script).  And I'm not sure that documentation is really of
much use.

> ( I think the following must not be skipped.)
> (  LGPL-2.0+)
> (  * m4/vapigen.m4  )

I think it's fine to skip that as well if one skips any of this, since it
doesn't pose any more license issues than any of the rest of the files you
list.  (Actually, it probably just converts to GPL-2 or GPL-3 for the
purposes of generating the build system, given the license of the source
of the rest of the output files to which it contributes.)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wq9c6qf6@hope.eyrie.org

Re: DEP-5 (copyright file format) ... gap with practice

[David Prévot]

Hi,

Le 09/09/2014 17:40, Michael Gilbert a écrit :
> On Tue, Sep 9, 2014 at 8:40 AM, Andrey Rahmatullin wrote:

>>> You could always use the Files-Excluded field to make uscan remove
>>> those files from the upstream tarball,
>> Too much work (at least when you are not repacking the tarball for other
>> reasons) for absolutely no gain.

> One benefit is less time on copyright file research/review,

On the other hand, it defeats the principle of least surprise.
Distributing a different upstream tarball in Debian than upstream, just
because, seems plain wrong. Even the dev-ref agrees: “You *should*
upload packages with a pristine source tarball if possible”.

https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#repackagedorigtargz

Regards

David



signature.asc
Description: OpenPGP digital signature

Re: DEP-5 (copyright file format) ... gap with practice

[Michael Gilbert]

On Tue, Sep 9, 2014 at 8:40 AM, Andrey Rahmatullin wrote:
>> You could always use the Files-Excluded field to make uscan remove
>> those files from the upstream tarball,
> Too much work (at least when you are not repacking the tarball for other
> reasons) for absolutely no gain.

Not sure how that's a lot of work since uscan does all the magic for
you.  One benefit is less time on copyright file research/review, and
another clear benefit is reduced package cruft.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANTw=mnsnyjinwj7znpd9pmev+mrz+tso2da8j1awodhyne...@mail.gmail.com

Re: DEP-5 (copyright file format) ... gap with practice

[Andrey Rahmatullin]

On Mon, Sep 08, 2014 at 07:31:02PM -0400, Michael Gilbert wrote:
> > DEP-5 as defined in  http://dep.debian.net/deps/dep5/ does not have any
> > clause allowing us to skip license entries for certain class of files.
> >
> > In practice, many packages lack entries for autotools generated files
> > which come with very permissive license with mostly identical but not
> > quite the same copyright phrases which reqire us to quote them
> > separately.
> >
> > I am talking about autotools files such as:
> > PERMISSIVE
> >  * */Makefile.in
> >  * m4/*.m4
> >  * configure
> >  * INSTALL
> >  * aclocal.m4
> > GPL-2.0+ with autoconf exception
> >  * compile
> >  * depcomp
> >  * missing
> >  * py-compile
> >  * test-driver
> >  * m4/introspection.m4
> >  * m4/intltool.m4
> > GPL-2.0+ with libtool exception
> >  * ltmain.sh
> > GPL-3.0+ with autoconf exception
> >  * config.sub
> >  * config.guess
> > MIT
> >  * install-sh
> You could always use the Files-Excluded field to make uscan remove
> those files from the upstream tarball, 
Too much work (at least when you are not repacking the tarball for other
reasons) for absolutely no gain.


-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140909124044.ga20...@belkar.wrar.name

Re: DEP-5 (copyright file format) ... gap with practice

[Michael Gilbert]

On Mon, Sep 8, 2014 at 11:38 AM, Osamu Aoki wrote:
> Hi,
>
> DEP-5 as defined in  http://dep.debian.net/deps/dep5/ does not have any
> clause allowing us to skip license entries for certain class of files.
>
> In practice, many packages lack entries for autotools generated files
> which come with very permissive license with mostly identical but not
> quite the same copyright phrases which reqire us to quote them
> separately.
>
> I am talking about autotools files such as:
> PERMISSIVE
>  * */Makefile.in
>  * m4/*.m4
>  * configure
>  * INSTALL
>  * aclocal.m4
> GPL-2.0+ with autoconf exception
>  * compile
>  * depcomp
>  * missing
>  * py-compile
>  * test-driver
>  * m4/introspection.m4
>  * m4/intltool.m4
> GPL-2.0+ with libtool exception
>  * ltmain.sh
> GPL-3.0+ with autoconf exception
>  * config.sub
>  * config.guess
> MIT
>  * install-sh

You could always use the Files-Excluded field to make uscan remove
those files from the upstream tarball, then use dh-autoreconf (or
symlinks for e.g. config.sub and config.guess) to recover them at
build time.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANTw=mm2lqhhckiejq4q7qj+ethi3uuxmor9s9hfvtoyhfc...@mail.gmail.com

Re: DEP-5 (copyright file format) ... gap with practice

[Jonas Smedegaard]

Hi Osamu,

Quoting Osamu Aoki (2014-09-08 17:38:41)
> DEP-5 as defined in http://dep.debian.net/deps/dep5/ does not have any 
> clause allowing us to skip license entries for certain class of files.

I believe the "problem" is not DEP-5 but Debian Policy.

One of the goals of DEP-5 was to only be about syntax - its strict 
format simply reveals what is the case also without DEP-5: "permission 
to skip license for certain class of files" is not allowed by Debian 
Policy §3.2:

> Every package must be accompanied by a verbatim copy of its copyright 
> information and distribution license in the file 
> `/usr/share/doc//copyright'

If you somehow read above as magically excluding copyrightprotected 
material with very permissive licensing and/or easy to regenerate, then 
you should be able to read DEP-5 equally sloppy. ;-)


> In practice, many packages lack entries for autotools generated files 
> which come with very permissive license with mostly identical but not 
> quite the same copyright phrases which reqire us to quote them 
> separately.

Right, and that's a (mild only, evidently) violation of Policy.

I have heard the argument that the code is not important, because it can 
be automatically regenerated.

In my opinion we should cover all code that we ship.  If upstream 
tarball is too bloated, then strip parts not actually needed...:

 * autotools-generated files
 * documentation
 * compacted Javascript and CSS files
 * convenience code copies


 - 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

DEP-5 (copyright file format) ... gap with practice

[Osamu Aoki]

Hi,

DEP-5 as defined in  http://dep.debian.net/deps/dep5/ does not have any
clause allowing us to skip license entries for certain class of files.

In practice, many packages lack entries for autotools generated files
which come with very permissive license with mostly identical but not
quite the same copyright phrases which reqire us to quote them
separately.

I am talking about autotools files such as:
PERMISSIVE
 * */Makefile.in
 * m4/*.m4
 * configure
 * INSTALL
 * aclocal.m4
GPL-2.0+ with autoconf exception
 * compile
 * depcomp
 * missing
 * py-compile
 * test-driver
 * m4/introspection.m4
 * m4/intltool.m4
GPL-2.0+ with libtool exception
 * ltmain.sh
GPL-3.0+ with autoconf exception
 * config.sub
 * config.guess
MIT
 * install-sh

( I think the following must not be skipped.)
(  LGPL-2.0+)
(  * m4/vapigen.m4  )

FTP master people seem not to worry such loose practice of drop listing
them.

This gap between policy and practice is the problem for tools handling
it.

My debmake package is one of it.  It helps to
 * create the template copyright file and 
 * check the previous copyright file against the updated source tree.
Currently my debmake package pedantically lists and requires them per
policy; and generates the long template copyright file.(*1)

By having such useless entries per policy is not really useful for the
license compliance check purpose and requires extra editorial work for
no real benefit.  (More noise!)

It may be good to have a set of specifically defined file types for
exclusion in DEP-5 policy.  Then we can skip listing them in the
copyright file.  The helper script can generate a template for the
copyright file in line with the actual practice and not to contradict
with the DEP-5 policy.

Regards,

Osamu

(*1) The ibus package used the debmake and lists such files.


signature.asc
Description: Digital signature