Re: get-orig-source and standardized source repacking (was: Debian Policy 4.1.4.0 released)

Hello, On Thu, Jul 05 2018, Russ Allbery wrote: > Reintroducing the same target with the same name but with a stricter > definition would almost certainly make a bunch of those packages > buggy. I'm dubious that it's worth disrupting whatever local workflow > that they already have around

Re: get-orig-source and standardized source repacking (was: Debian Policy 4.1.4.0 released)

On Fri, Jul 06, 2018 at 08:27:13AM +0100, Simon McVittie wrote: > On Fri, 06 Jul 2018 at 08:16:12 +0200, Andreas Tille wrote: > > Just yesterday > > I had an example where the upstream download archive is lacking some > > files from upstream SVN which need to be merged in to enable building > >

Re: get-orig-source and standardized source repacking (was: Debian Policy 4.1.4.0 released)

On Fri, Jul 06, 2018 at 08:27:13AM +0100, Simon McVittie wrote: > On Fri, 06 Jul 2018 at 08:16:12 +0200, Andreas Tille wrote: > > Just yesterday > > I had an example where the upstream download archive is lacking some > > files from upstream SVN which need to be merged in to enable building > >

Re: get-orig-source and standardized source repacking (was: Debian Policy 4.1.4.0 released)

On Fri, 06 Jul 2018 at 08:16:12 +0200, Andreas Tille wrote: > Just yesterday > I had an example where the upstream download archive is lacking some > files from upstream SVN which need to be merged in to enable building > the software[1]. This often happens in Autotools packages whose upstream

Re: get-orig-source and standardized source repacking (was: Debian Policy 4.1.4.0 released)

On Fri, Jul 6, 2018 at 2:16 PM, Andreas Tille wrote: > I fully share your view that the optimal situation would be if uscan > would be some kind of wrapper around whatever code would be needed to > create the source tarball. Since I share this view I once started to > hack Files-Excluded into

Re: get-orig-source and standardized source repacking (was: Debian Policy 4.1.4.0 released)

Hi Russ, On Thu, Jul 05, 2018 at 10:49:29AM -0700, Russ Allbery wrote: > Andreas Tille writes: > > > My main point is that README.source is just text and no code that I can > > run and test. That's different from my proposal. > > I can definitely see the merits of clear automation the process

Re: get-orig-source and standardized source repacking (was: Debian Policy 4.1.4.0 released)

Andreas Tille writes: > My main point is that README.source is just text and no code that I can > run and test. That's different from my proposal. I can definitely see the merits of clear automation the process of transforming an upstream release into a tarball usable for Debian packaging

Re: Debian Policy 4.1.4.0 released

On Wed, Jul 04, 2018 at 10:26:20PM +0100, Sean Whitton wrote: > >Provide get-orig-source target if (and only if) uscan would fail. > > > > The previous discussion seem to show a tendency that this bug will be > > at best tagged wontfix which for the moment prevents me from calling > >

Re: Debian Policy 4.1.4.0 released

On Tue, Jul 03, 2018 at 01:35:49PM +0200, Andreas Tille wrote: > Not really, I do not want to use README.source or something like this. > I have a *personal* policy: I will not sponsor any package if there is > no code I could run that recreates the source tarball. May be I'm to > strict and the

Re: Debian Policy 4.1.4.0 released

Hello Andreas, On Tue, Jul 03 2018, Andreas Tille wrote: > I would love to create a new bug report but this would rather be: > >Provide get-orig-source target if (and only if) uscan would fail. > > The previous discussion seem to show a tendency that this bug will be > at best tagged wontfix

Re: Bug#515856: Debian Policy 4.1.4.0 released

On Tue, Jul 03, 2018 at 03:43:19PM +0200, Andreas Tille wrote: > On Tue, Jul 03, 2018 at 12:20:28PM +0200, Bill Allombert wrote: > > On Mon, Jul 02, 2018 at 04:40:43PM -0700, Russ Allbery wrote: > > > > > > This is one of the cases that now has a better solution and more standard > > > tools than

Re: Bug#515856: Debian Policy 4.1.4.0 released

On Tue, Jul 03, 2018 at 04:11:14PM +0200, Bill Allombert wrote: > > When the new copyright format was introduced, it was agreed there > would be no compulsion to migrate to the new copyright format. > > There is nothing that prevent to add Files-Excluded stanzas to old > format copyright files

Re: Bug#515856: Debian Policy 4.1.4.0 released

On Tue, Jul 03, 2018 at 12:20:28PM +0200, Bill Allombert wrote: > On Mon, Jul 02, 2018 at 04:40:43PM -0700, Russ Allbery wrote: > > > > This is one of the cases that now has a better solution and more standard > > tools than the get-orig-source target, specifically Files-Excluded in > >

Re: Bug#515856: Debian Policy 4.1.4.0 released

Hi, On 07/03/2018 01:20 PM, Bill Allombert wrote: > How many packages are using Files-Excluded ? 1781 Using codesearch.d.o [1] to look through the debian/copyright files, then running curl -s https://codesearch.debian.net/results/2d02749753b89563/packages.json | jq -r '.Packages[]' | wc -l

Re: Bug#515856: Debian Policy 4.1.4.0 released

On Mon, Jul 02, 2018 at 04:40:43PM -0700, Russ Allbery wrote: > Jonathan Nieder writes: > > > Context: I have run into a few packages that used the +dfsg convention > > without documenting what they removed from the tarball and I was not > > able to locally update them. :( > > This is one of

Re: Debian Policy 4.1.4.0 released

Hi Sean, On Tue, Jul 03, 2018 at 09:59:55AM +0100, Sean Whitton wrote: > [trimming the CC a bit; Russ and Ian read -devel] > > Hello Jonathan, Andreas, > > I don't think that what either of you have said is a response to the > reasons that there were for removing this optional target from

Re: Debian Policy 4.1.4.0 released

> Git mode for uscan helps as well in many cases. Is the git mode currently broken? I keep getting the error message "fatal: Not a valid object name" when fetching a new release: $ uscan --download-version 9.2.25 uscan: Newest version of jetty9 on remote site is 9.2.25, specified download

Re: Debian Policy 4.1.4.0 released

[trimming the CC a bit; Russ and Ian read -devel] Hello Jonathan, Andreas, I don't think that what either of you have said is a response to the reasons that there were for removing this optional target from Policy. The thought driving this is that not every trick in a Debian package

Re: Debian Policy 4.1.4.0 released

Hi Russ, On Mon, Jul 02, 2018 at 04:40:43PM -0700, Russ Allbery wrote: > Jonathan Nieder writes: > > > Context: I have run into a few packages that used the +dfsg convention > > without documenting what they removed from the tarball and I was not > > able to locally update them. :( > > This is

Re: Debian Policy 4.1.4.0 released

Jonathan Nieder writes: > Context: I have run into a few packages that used the +dfsg convention > without documenting what they removed from the tarball and I was not > able to locally update them. :( This is one of the cases that now has a better solution and more standard tools than the

Re: Debian Policy 4.1.4.0 released

Hi, Sean Whitton wrote: > On Mon, Jul 02 2018, Jonathan Nieder wrote: >> I'm a bit confused: wasn't it already specified pretty precisely? > > Please take a look through the bug's discussion. It's explained why the > wording was not thought to be good enough. Thanks. This looks like a classic

Re: Debian Policy 4.1.4.0 released

Hello Jonathan, On Mon, Jul 02 2018, Jonathan Nieder wrote: > I'm a bit confused: wasn't it already specified pretty precisely? Please take a look through the bug's discussion. It's explained why the wording was not thought to be good enough. -- Sean Whitton signature.asc Description: PGP

Re: Debian Policy 4.1.4.0 released

Hi, Sean Whitton wrote: > On Wed, Apr 11 2018, Russ Allbery wrote: >> I'm pretty reluctant to specify this sort of optional target that >> works differently in every package that uses it back in Policy because >> it's really not standardized, nor do I think it's possible to >> standardize. If

Re: Bug#515856: Debian Policy 4.1.4.0 released

On Thu, Apr 12, 2018 at 09:39:39AM -0700, Russ Allbery wrote: > > After the removal I will surely stick to my personal policy but for an > > explanation who to implement it in a somehow standardized way I need do > > add extra information now. > > You would already have to add some extra

Re: Bug#515856: Debian Policy 4.1.4.0 released

Andreas Tille writes: > I think additional information in README.source is a very helpful thing > to have. However, my *personal* policy for sponsoring a package is that > I will not sponsor a package that comes without a method that enables me > automatically to reproduce the

Re: Debian Policy 4.1.4.0 released

Paul Wise writes ("Re: Debian Policy 4.1.4.0 released"): > uscan is used in situations where one does not want arbitrary code > >from source packages automatically run by uscan. As long as `uscan > --safe` ignores that fallback, that should be fine I guess though.

Re: Bug#515856: Debian Policy 4.1.4.0 released

On Wed, Apr 11, 2018 at 01:54:58PM -0700, Russ Allbery wrote: > Ian Jackson writes: > > > (ii) You make a very good argument that policy should continue to give > > guidance for this kind of situation. The target should probably be > > put back in policy, but

Re: Debian Policy 4.1.4.0 released

On Thu, Apr 12, 2018 at 10:27 AM, Russ Allbery wrote: > Personally, I'd probably add an interactive prompt warning about the > dangers and stressing that the source package needs to be trusted if stdin > and stdout are connected to a tty, and otherwise fail and require some > flag to use the

Re: Debian Policy 4.1.4.0 released

Paul Wise writes: > On Thu, Apr 12, 2018 at 5:02 AM, Russ Allbery wrote: >> Rather than documenting this fallback in Policy, why not add that >> fallback directly to uscan? > uscan is used in situations where one does not want arbitrary code from > source packages automatically

Re: Debian Policy 4.1.4.0 released

On Thu, Apr 12, 2018 at 5:02 AM, Russ Allbery wrote: > Rather than documenting this fallback in Policy, why not add that fallback > directly to uscan? uscan is used in situations where one does not want arbitrary code from source packages automatically run by uscan. As long as `uscan --safe`

Re: Bug#515856: Debian Policy 4.1.4.0 released

Hello, On Wed, Apr 11 2018, Russ Allbery wrote: > I'm pretty reluctant to specify this sort of optional target that > works differently in every package that uses it back in Policy because > it's really not standardized, nor do I think it's possible to > standardize. If we really want to write

Re: Debian Policy 4.1.4.0 released

Andreas Tille writes: > That is exactly what I wanted to express. I do not mind the actual > implementation but writing down in policy that there should be some > common interface to obtain the upstream source as a fallback to uscan > (and only as fallback if there is really

Re: Bug#515856: Debian Policy 4.1.4.0 released

Ian Jackson writes: > (ii) You make a very good argument that policy should continue to give > guidance for this kind of situation. The target should probably be > put back in policy, but with an explicit note saying it's not normally > desirable, or something.

Re: Bug#515856: Debian Policy 4.1.4.0 released

On Wed, Apr 11, 2018 at 03:49:17PM +0100, Ian Jackson wrote: > Bill Allombert writes ("Re: Bug#515856: Debian Policy 4.1.4.0 released"): > > I wonder, maybe uscan could support debian/get-orig-source as a last > > resort ? > > Only if you pass --trust-source o

Re: Bug#515856: Debian Policy 4.1.4.0 released

Bill Allombert writes ("Re: Bug#515856: Debian Policy 4.1.4.0 released"): > I wonder, maybe uscan could support debian/get-orig-source as a last > resort ? Only if you pass --trust-source or something. Currently I think (hope!) the damage that can be done by a bad uscan config i

Re: Debian Policy 4.1.4.0 released

On Wed, Apr 11, 2018 at 02:29:25PM +0100, Ian Jackson wrote: > Andreas Tille writes ("Re: Debian Policy 4.1.4.0 released"): > > In other words: I'm fine with removing the target in rules and replace > > it by: > > > > If there are reasons why us

Re: Bug#515856: Debian Policy 4.1.4.0 released

On Wed, Apr 11, 2018 at 03:18:32PM +0200, Andreas Tille wrote: > On Sun, Apr 08, 2018 at 10:58:53AM +0200, Ole Streicher wrote: > > > > > > Imho Sean's last mail sums it up pretty well > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515856#94 > > > > I have read this, but it does not

Re: Debian Policy 4.1.4.0 released

On Wed, Apr 11, 2018 at 02:29:25PM +0100, Ian Jackson wrote: > (ii) You make a very good argument that policy should continue to give > guidance for this kind of situation. The target should probably be > put back in policy, but with an explicit note saying it's not normally > desirable, or

Re: Debian Policy 4.1.4.0 released

Andreas Tille writes ("Re: Debian Policy 4.1.4.0 released"): > In other words: I'm fine with removing the target in rules and replace > it by: > > If there are reasons why uscan can not fetch the upstream source it > is recommended to provide a script debian/get

Re: Debian Policy 4.1.4.0 released

On Sun, Apr 08, 2018 at 10:58:53AM +0200, Ole Streicher wrote: > > > > Imho Sean's last mail sums it up pretty well > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515856#94 > > I have read this, but it does not convince me. My rule to get the > upstream packagage was always: use uscan, if

Re: Debian Policy 4.1.4.0 released

kact...@gnu.org writes: > It breaks my workflow ;) I use pristine-tar(1) to store orig tarballs > with their upstream signature in git. > dpkg-buildpackage(1) do not extract orig.tar.gz from `pristine-tar' > automatically, so I add `get-orig-source' rule that invokes > `pristine-tar(1)' with

Re: Debian Policy 4.1.4.0 released

Hi Sean, On So 08 Apr 2018 00:36:45 CEST, Sean Whitton wrote: Hello, On Sun, Apr 08 2018, kact...@gnu.org wrote: It breaks my workflow ;) I use pristine-tar(1) to store orig tarballs with their upstream signature in git. You can continue to use your target. this is good news. Thanks

Re: Debian Policy 4.1.4.0 released

Andreas Metzler writes: > Ole Streicher wrote: >> Sean Whitton writes: >>> On Sat, Apr 07 2018, Ole Streicher wrote: > [...] Sure, but why do we give up a common rule? I think the cases where d/watch does not work are not

Re: Debian Policy 4.1.4.0 released

Paul Wise writes: > On Sat, Apr 7, 2018 at 8:49 PM, Ole Streicher wrote: > >> I have a number of "uncommon" upstreams: > > It would be really nice if these folks could switch to something more > standard. Have they considered using a version control system for a > start? I

Re: Debian Policy 4.1.4.0 released

Ole Streicher wrote: > Sean Whitton writes: >> On Sat, Apr 07 2018, Ole Streicher wrote: [...] >>> Sure, but why do we give up a common rule? I think the cases where >>> d/watch does not work are not so rare (at least I have quite a number >>> of

Re: Debian Policy 4.1.4.0 released

On Sat, Apr 7, 2018 at 8:49 PM, Ole Streicher wrote: > I have a number of "uncommon" upstreams: It would be really nice if these folks could switch to something more standard. Have they considered using a version control system for a start? > * aladin, download

Re: Debian Policy 4.1.4.0 released

Hello, On Sun, Apr 08 2018, kact...@gnu.org wrote: > It breaks my workflow ;) I use pristine-tar(1) to store orig tarballs > with their upstream signature in git. You can continue to use your target. -- Sean Whitton signature.asc Description: PGP signature

Re: Debian Policy 4.1.4.0 released

[2018-04-07 10:35] Ben Finney > Sean Whitton writes: > > > I just pushed Debian Policy 4.1.4.0 to sid. Thank you to the ~20 > > people who contributed to this release, which includes several first > > time contributors of patches. > > […] > > > >

Re: Debian Policy 4.1.4.0 released

Sean Whitton writes: > On Sat, Apr 07 2018, Ole Streicher wrote: > >> Adam Borowski writes: >>> get-orig-source merely isn't described by the Policy any more, it is >>> no different from an arbitrary private target you have in >>> debian/rules. >>

Re: Debian Policy 4.1.4.0 released

Hello, On Sat, Apr 07 2018, Ole Streicher wrote: > Adam Borowski writes: >> get-orig-source merely isn't described by the Policy any more, it is >> no different from an arbitrary private target you have in >> debian/rules. > > Sure, but why do we give up a common rule? I

Re: Debian Policy 4.1.4.0 released

Paul Wise writes: > On Sat, Apr 7, 2018 at 4:40 PM, Ole Streicher wrote: > >> I have some packages where the version is not encoded in the file name, >> but must be extracted from the file content. Shall one keep >> get-orig-source here to be consistent, or what would be the

Re: Debian Policy 4.1.4.0 released

Adam Borowski writes: > On Sat, Apr 07, 2018 at 10:40:42AM +0200, Ole Streicher wrote: >> Ben Finney writes: >> > Sean Whitton writes: >> >> 4.9 >> >> The ``get-orig-source`` rules target has been removed. Packages >> >>

Re: Debian Policy 4.1.4.0 released

On Sat, Apr 7, 2018 at 4:40 PM, Ole Streicher wrote: > I have some packages where the version is not encoded in the file name, > but must be extracted from the file content. Shall one keep > get-orig-source here to be consistent, or what would be the right > solution here? If uscan can find the

Re: Debian Policy 4.1.4.0 released

On Sat, Apr 07, 2018 at 10:40:42AM +0200, Ole Streicher wrote: > Ben Finney writes: > > Sean Whitton writes: > >> 4.9 > >> The ``get-orig-source`` rules target has been removed. Packages > >> should use ``debian/watch`` and uscan instead. >

Re: Debian Policy 4.1.4.0 released

Ben Finney writes: > Sean Whitton writes: >> I just pushed Debian Policy 4.1.4.0 to sid. Thank you to the ~20 >> people who contributed to this release, which includes several first >> time contributors of patches. >> […] >> >> 4.9 >> The

Re: Debian Policy 4.1.4.0 released

On Sat, Apr 07, 2018 at 08:02:11AM +0200, Andreas Tille wrote: > On Sat, Apr 07, 2018 at 10:35:02AM +1000, Ben Finney wrote: > > Sean Whitton writes: > > > > > > 4.9 > > > The ``get-orig-source`` rules target has been removed. Packages > > > should use

Re: Debian Policy 4.1.4.0 released

Hi Andreas >> > 4.9 >> > The ``get-orig-source`` rules target has been removed. Packages >> > should use ``debian/watch`` and uscan instead. >> >> Especially for this, my ‘debian/rules’ files thank you. > > While I really like to have this consistent approach but it seems I've > missed

Re: Debian Policy 4.1.4.0 released

Hi, On Sat, Apr 07, 2018 at 10:35:02AM +1000, Ben Finney wrote: > Sean Whitton writes: > > > > 4.9 > > The ``get-orig-source`` rules target has been removed. Packages > > should use ``debian/watch`` and uscan instead. > > Especially for this, my ‘debian/rules’

Re: Debian Policy 4.1.4.0 released

Sean Whitton writes: > I just pushed Debian Policy 4.1.4.0 to sid. Thank you to the ~20 > people who contributed to this release, which includes several first > time contributors of patches. > […] > > 4.9 > The ``get-orig-source`` rules target has been removed.