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
> > reportbug
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
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
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 Policy
> 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
ve
[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
maintainer's
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
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 get-o
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
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 s
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 we
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.
I thin
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 fallb
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 run by uscan. As
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` igno
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 no chance to use usc
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
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 someth
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 debia
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 d
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 prop
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 for
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 so rare (at least I have quite a number
of them), and keepi
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 asked, but this did not
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 them), and keeping them unified is not the worst t
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 http://aladin.unistra.fr/java/down
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
[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.
> > […]
> >
> > 4.9
> > The ``get-orig-source`` rules target
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.
>>
>> Sure, but why do we give up a common rule? I t
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 think the cases where
>
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 right
>> solution here
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
>> >> should use ``debian/watch`` and uscan instead.
>> >
>> > Especiall
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 r
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.
> >
> > Especially for this, my ‘debian/rules’ fi
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 ``get-orig-source`` rules target has been removed. Pa
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 ``debian/watch`` and uscan instead.
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
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’ files thank you.
While I
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. Packages
> should use ``de
39 matches
Mail list logo
