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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
22 matches
Mail list logo
