Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #85337 > unrolled thread

Re: Debian Policy 4.1.4.0 released

Back to article view | Back to linux.debian.devel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Debian Policy 4.1.4.0 released Ben Finney <bignose@debian.org> - 2018-04-07 02:40 +0200
    Re: Debian Policy 4.1.4.0 released Andreas Tille <andreas@an3as.eu> - 2018-04-07 08:10 +0200
      Re: Debian Policy 4.1.4.0 released Stuart Prescott <stuart@debian.org> - 2018-04-07 09:10 +0200
      Re: Debian Policy 4.1.4.0 released Sébastien Villemot <sebastien@debian.org> - 2018-04-07 09:30 +0200
    Re: Debian Policy 4.1.4.0 released Ole Streicher <olebole@debian.org> - 2018-04-07 11:00 +0200
      Re: Debian Policy 4.1.4.0 released Adam Borowski <kilobyte@angband.pl> - 2018-04-07 13:30 +0200
        Re: Debian Policy 4.1.4.0 released Ole Streicher <olebole@debian.org> - 2018-04-07 14:00 +0200
          Re: Debian Policy 4.1.4.0 released Sean Whitton <spwhitton@spwhitton.name> - 2018-04-07 18:10 +0200
            Re: Debian Policy 4.1.4.0 released Ole Streicher <olebole@debian.org> - 2018-04-07 21:00 +0200
              Re: Debian Policy 4.1.4.0 released Andreas Metzler <ametzler@bebt.de> - 2018-04-08 08:00 +0200
                Re: Debian Policy 4.1.4.0 released Ole Streicher <olebole@debian.org> - 2018-04-08 11:20 +0200
                  Re: Debian Policy 4.1.4.0 released Andreas Tille <andreas@an3as.eu> - 2018-04-11 15:20 +0200
                    Re: Debian Policy 4.1.4.0 released Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-04-11 15:30 +0200
                      Re: Debian Policy 4.1.4.0 released Andrey Rahmatullin <wrar@debian.org> - 2018-04-11 15:40 +0200
                      Re: Debian Policy 4.1.4.0 released Andreas Tille <andreas@an3as.eu> - 2018-04-11 16:20 +0200
                        Re: Debian Policy 4.1.4.0 released Russ Allbery <rra@debian.org> - 2018-04-11 23:10 +0200
                          Re: Debian Policy 4.1.4.0 released Paul Wise <pabs@debian.org> - 2018-04-12 04:20 +0200
                            Re: Debian Policy 4.1.4.0 released Russ Allbery <rra@debian.org> - 2018-04-12 04:30 +0200
                              Re: Debian Policy 4.1.4.0 released Paul Wise <pabs@debian.org> - 2018-04-12 04:40 +0200
                            Re: Debian Policy 4.1.4.0 released Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-04-12 15:10 +0200
                      Bug#515856: Debian Policy 4.1.4.0 released Russ Allbery <rra@debian.org> - 2018-04-11 23:00 +0200
                        Bug#515856: Debian Policy 4.1.4.0 released Sean Whitton <spwhitton@spwhitton.name> - 2018-04-12 00:10 +0200
                          Bug#515856: Debian Policy 4.1.4.0 released Jonathan Nieder <jrnieder@gmail.com> - 2018-07-02 23:10 +0200
                            Bug#515856: Debian Policy 4.1.4.0 released Sean Whitton <spwhitton@spwhitton.name> - 2018-07-02 23:20 +0200
                              Bug#515856: Debian Policy 4.1.4.0 released Jonathan Nieder <jrnieder@gmail.com> - 2018-07-02 23:40 +0200
                                Re: get-orig-source and standardized source repacking (was: Debian  Policy 4.1.4.0 released) Andreas Tille <andreas@an3as.eu> - 2018-07-06 08:20 +0200
                                  Re: get-orig-source and standardized source repacking (was: Debian  Policy 4.1.4.0 released) Paul Wise <pabs@debian.org> - 2018-07-06 08:50 +0200
                                  Re: get-orig-source and standardized source repacking (was: Debian  Policy 4.1.4.0 released) Simon McVittie <smcv@debian.org> - 2018-07-06 09:30 +0200
                                    Re: get-orig-source and standardized source repacking Ben Finney <bignose@debian.org> - 2018-07-06 12:20 +0200
                                    Re: get-orig-source and standardized source repacking (was: Debian  Policy 4.1.4.0 released) Wouter Verhelst <wouter@debian.org> - 2018-07-06 15:40 +0200
                                    Re: get-orig-source and standardized source repacking (was: Debian  Policy 4.1.4.0 released) Adam Borowski <kilobyte@angband.pl> - 2018-07-06 16:40 +0200
                            Bug#515856: Debian Policy 4.1.4.0 released Russ Allbery <rra@debian.org> - 2018-07-03 01:50 +0200
                        Re: Bug#515856: Debian Policy 4.1.4.0 released Andreas Tille <andreas@an3as.eu> - 2018-04-12 08:30 +0200
                          Re: Bug#515856: Debian Policy 4.1.4.0 released Russ Allbery <rra@debian.org> - 2018-04-12 18:50 +0200
                            Re: Bug#515856: Debian Policy 4.1.4.0 released Andreas Tille <andreas@an3as.eu> - 2018-04-12 20:10 +0200
      Re: Debian Policy 4.1.4.0 released Paul Wise <pabs@debian.org> - 2018-04-07 13:50 +0200
        Re: Debian Policy 4.1.4.0 released Ole Streicher <olebole@debian.org> - 2018-04-07 15:10 +0200
          Re: Debian Policy 4.1.4.0 released Paul Wise <pabs@debian.org> - 2018-04-08 01:30 +0200
            Re: Debian Policy 4.1.4.0 released Ole Streicher <olebole@debian.org> - 2018-04-08 11:20 +0200
    Re: Debian Policy 4.1.4.0 released KAction@gnu.org - 2018-04-07 23:50 +0200
      Re: Debian Policy 4.1.4.0 released Sean Whitton <spwhitton@spwhitton.name> - 2018-04-08 00:40 +0200
        Re: Debian Policy 4.1.4.0 released Mike Gabriel <mike.gabriel@das-netzwerkteam.de> - 2018-04-08 13:30 +0200
      Re: Debian Policy 4.1.4.0 released Russ Allbery <rra@debian.org> - 2018-04-09 01:50 +0200

Page 1 of 3  [1] 2 3  Next page →

#85337 — Re: Debian Policy 4.1.4.0 released

Sean Whitton <spwhitton@spwhitton.name> 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 ``debian/watch`` and uscan instead.

Especially for this, my ‘debian/rules’ files thank you.

-- 
 \        “Institutions will try to preserve the problem to which they |
  `\                             are the solution.” —Clay Shirky, 2012 |
_o__)                                                                  |
Ben Finney

[toc] | [next] | [standalone]

#85338

Hi,

On Sat, Apr 07, 2018 at 10:35:02AM +1000, Ben Finney wrote:
> Sean Whitton <spwhitton@spwhitton.name> 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 really like to have this consistent approach but it seems I've
missed how uscan can spot new versions in for instance untagged VCS or
download files with changing content but no version number.  Is there
some way to do this with something else than a manually craftet script?

Kind regards

     Andreas.

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#85339

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 how uscan can spot new versions in for instance untagged VCS or
> download files with changing content but no version number.  Is there
> some way to do this with something else than a manually craftet script?

yes, d/watch can use the qa.debian.org fakeupstream service to create a fake new release for every 
commit. I use this on projects that have very occasional (bugfix-only) commits and don't seem to be 
interested in actually making releases any more:

https://sources.debian.org/src/svn-all-fast-export/1.0.10+git20160822-3/debian/watch/


opts="uversionmangle=s/.*date=(\d{4})-(\d\d)-(\d\d)T.*/1.0.10+git$1$2$3/, \
    filenamemangle=s/.*date=(\d{4})-(\d\d)-(\d\d)T.*/1.0.10+git$1$2$3.tar.gz/" \
    https://qa.debian.org/cgi-bin/fakeupstream.cgi?upstream=github_commits_package_json/svn-all-fast-export/svn2git \
    .*/archive/(.*\.tar\.gz?.*)

A version 1.0.10+git20180406 would therefore appear from a commit made yesterday and if I were to package 
and upload that version, that would also be the upstream part of the version string I'd use. With uscan 
integration, tools like the UDD Maintainer Dashboard also show when new commits are made.

(Thanks to Paul Wise for creating this a couple of years ago when I was musing on how to track this sort 
of upstream)

cheers
Stuart

-- 
Stuart Prescott    http://www.nanonanonano.net/   stuart@nanonanonano.net
Debian Developer   http://www.debian.org/         stuart@debian.org
GPG fingerprint    90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

[toc] | [prev] | [next] | [standalone]

#85340

[Multipart message — attachments visible in raw view] — view raw

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 <spwhitton@spwhitton.name> 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 really like to have this consistent approach but it seems I've
> missed how uscan can spot new versions in for instance untagged VCS or
> download files with changing content but no version number.  Is there
> some way to do this with something else than a manually craftet script?

Since devscripts 2.18.1, uscan is able to track the HEAD of a git a repository.

See the section titled "direct access to the git repository (HEAD)" in
uscan(1) for an example. It is possible to choose how to customize how the
upstream version string is created using the "pretty" option.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org

[toc] | [prev] | [next] | [standalone]

#85342

Ben Finney <bignose@debian.org> writes:
> Sean Whitton <spwhitton@spwhitton.name> 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 ``debian/watch`` and uscan instead.
>
> Especially for this, my ‘debian/rules’ files thank you.

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?

Best regards

Ole

[toc] | [prev] | [next] | [standalone]

#85343

On Sat, Apr 07, 2018 at 10:40:42AM +0200, Ole Streicher wrote:
> Ben Finney <bignose@debian.org> writes:
> > Sean Whitton <spwhitton@spwhitton.name> 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.
> 
> 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?

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.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 
⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC?
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#85345

Adam Borowski <kilobyte@angband.pl> writes:
> On Sat, Apr 07, 2018 at 10:40:42AM +0200, Ole Streicher wrote:
>> Ben Finney <bignose@debian.org> writes:
>> > Sean Whitton <spwhitton@spwhitton.name> 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.
>> 
>> 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?
>
> 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
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 thing we can do.

Best

Ole

[toc] | [prev] | [next] | [standalone]

#85348

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Sat, Apr 07 2018, Ole Streicher wrote:

> Adam Borowski <kilobyte@angband.pl> 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
> 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 thing we can do.

See discussion in #515856.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#85350

Sean Whitton <spwhitton@spwhitton.name> writes:
> On Sat, Apr 07 2018, Ole Streicher wrote:
>
>> Adam Borowski <kilobyte@angband.pl> 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
>> 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 thing we can do.
>
> See discussion in #515856.

Maybe I didn't read it too carefully, but I didn't find the argument why
get-orig-source is not kept for the cases where uscan doesn't do the
job.

And when I extrapolate from my packages, this is not an exceptionally
rare case.

Best regards

Ole

[toc] | [prev] | [next] | [standalone]

#85355

Ole Streicher <olebole@debian.org> wrote:
> Sean Whitton <spwhitton@spwhitton.name> 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 thing we can do.

>> See discussion in #515856.

> Maybe I didn't read it too carefully, but I didn't find the argument why
> get-orig-source is not kept for the cases where uscan doesn't do the
> job.

> And when I extrapolate from my packages, this is not an exceptionally
> rare case.

Imho Sean's last mail sums it up pretty well
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515856#94

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

[toc] | [prev] | [next] | [standalone]

#85358

Andreas Metzler <ametzler@bebt.de> writes:
> Ole Streicher <olebole@debian.org> wrote:
>> Sean Whitton <spwhitton@spwhitton.name> 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 thing we can do.
>
>>> See discussion in #515856.
>
>> Maybe I didn't read it too carefully, but I didn't find the argument why
>> get-orig-source is not kept for the cases where uscan doesn't do the
>> job.
>
>> And when I extrapolate from my packages, this is not an exceptionally
>> rare case.
>
> 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/watch exists, otherwise
use get-orig-source. Sounds pretty simple and straigt-forward. If it
fails, I had a starting point where to debug (usually just a missing
dep). I see no reaso why this should be given up.

Cheers

Ole

[toc] | [prev] | [next] | [standalone]

#85442

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/watch exists, otherwise
> use get-orig-source. Sounds pretty simple and straigt-forward. If it
> fails, I had a starting point where to debug (usually just a missing
> dep). I see no reaso why this should be given up.

I agree with Ole.  While I took over some ideas from this thread how to
get rid of some get-orig-source targets by using mode=git I think it
makes perfectly sense to define a target name that should be used in
case uscan can not be used exclusively to fetch upstream source.  I can
not see in how far definition of the target name will harm - but from
the point of team maintenance it helps to know where to look first to
download a new upstream version.

BTW, I have standardized all my packages to

get-orig-source:
	. debian/get-orig-source

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-orig-source .

If we do not provide *code* to get the upstream source and just settle
to some (however vague) description in d/README.source random package
developers who might work on a package will end up with different
results.  This should not be the outcome of a policy change.

Kind regards

      Andreas.

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#85443

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-orig-source .
> 
> If we do not provide *code* to get the upstream source and just settle
> to some (however vague) description in d/README.source random package
> developers who might work on a package will end up with different
> results.  This should not be the outcome of a policy change.

I'm not sure why you would change from a rules target to a custom
script.

There is an argument that rules-as-makefile is not the ideal interface
and implementation strategy, but I doubt that here and now is the
right time to be making an accidental transition away from that.

If the only reason is that the docs for the target are being removed
from policy, then:

(i) The fact that a target is no longer documented in policy does not
mean it should not be provided; the fact that a target is being
removed from policy does not mean it should be removed from packages.
It means merely that the target's purpose and inclusion should be
reconsidered.

(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.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

[toc] | [prev] | [next] | [standalone]

#85444

[Multipart message — attachments visible in raw view] — view raw

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 something.
That would require deciding what should the target do first.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#85446

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 uscan can not fetch the upstream source it
> >     is recommended to provide a script debian/get-orig-source .
> > 
> > If we do not provide *code* to get the upstream source and just settle
> > to some (however vague) description in d/README.source random package
> > developers who might work on a package will end up with different
> > results.  This should not be the outcome of a policy change.
> 
> I'm not sure why you would change from a rules target to a custom
> script.

I personally did it since you can save a lot of syntax things like "; \"
at end of lines etc.  I would not make it a common rule but I became
simply used to it.
 
> There is an argument that rules-as-makefile is not the ideal interface
> and implementation strategy, but I doubt that here and now is the
> right time to be making an accidental transition away from that.

The argument of the bug report was that dh does not know the target.
Since d/rules is usually interpretet by dh I understand the arguing
to not describe something that can not be interpreted by dh.
 
> If the only reason is that the docs for the target are being removed
> from policy, then:
> 
> (i) The fact that a target is no longer documented in policy does not
> mean it should not be provided; the fact that a target is being
> removed from policy does not mean it should be removed from packages.
> It means merely that the target's purpose and inclusion should be
> reconsidered.

Yes.
 
> (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.

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 uscan) seems
important to me,

A wording that makes bug reports of high severity possible saying:

   Package is using get-orig-source instead of uscan

is fine for me. 

Kind regards

       Andreas.

-- 
http://fam-tille.de

[toc] | [prev] | [next] | [standalone]

#85454

Andreas Tille <andreas@an3as.eu> 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 uscan) seems
> important to me,

Rather than documenting this fallback in Policy, why not add that fallback
directly to uscan?

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#85460

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` ignores that fallback, that should be fine I guess though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#85461

Paul Wise <pabs@debian.org> 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 long as `uscan --safe`
> ignores that fallback, that should be fine I guess though.

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 fallback from the source package.  But happy to let
whoever implements this pick their strategy.  :)

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#85463

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 fallback from the source package.  But happy to let
> whoever implements this pick their strategy.  :)

That would break tools that supervise the output of uscan and other
tools, pass fake ttys to the tools and run multiple tools at the same
time. For e.g. `check-all-the-things -j2` would have uscan waiting
forever on that prompt. The existing uscan --safe option should be
enough here though, no need for interactive input.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#85471

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 think safety should be the default, so I have filed
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895546

Thanks,
Ian.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.devel

csiph-web