Re: DEP-5 (copyright file format) ... gap with practice
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
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
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
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
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
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
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
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
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
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
Quoting Russ Allbery (2014-09-10 06:38:21) Osamu Aoki os...@debian.org 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 http://www.gnu.org/licenses/. 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 MERCHANTABILITY, FITNESS
Re: DEP-5 (copyright file format) ... gap with practice
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
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
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
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
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
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
Osamu Aoki os...@debian.org 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) http://www.eyrie.org/~eagle/ -- 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
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
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
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
