On Sat, Sep 10, 2016 at 04:42:25PM +0200, Dominique Dumont wrote:
> Turns out that including file:///usr/share/doc/debian-policy/upgrading-
> checklist.txt.gz in the error message works as well (this launches ark which
> lists a clickable file. That's 2 clicks instead of one, but still faster than
On Friday, September 9, 2016 11:14:09 AM CEST Holger Levsen wrote:
> I'd actually prefer if the text would point to
> /usr/share/doc/debian-policy/upgrading-checklist.txt.gz - alternativly
> maybe it could point to both the local file and the web URL.
I want the warning message to have a clikable
On Fri, 09 Sep 2016 at 18:11:05 +0200, Markus Koschany wrote:
> On 08.09.2016 21:54, Ralf Treinen wrote:
> > That is certainly not true for orphaned packages with minimal maintenance
> > by the QA team. At least when I do a QA upload I usually don't bump the
> > Standards-Version field, simply bec
On 08.09.2016 21:54, Ralf Treinen wrote:
> On Thu, Sep 08, 2016 at 05:28:18PM +0200, Markus Koschany wrote:
>> On 08.09.2016 14:30, Ian Jackson wrote:
>>> Emmanuel Bourg writes ("Re: Network access during build"):
That makes sense, but in this case what is the usefulness of the
Standards-
Emmanuel Bourg writes ("Re: Standards-Version field should be deprecated"):
> Le 8/09/2016 à 17:39, Russ Allbery a écrit :
> > If you're just automatically updating it without ever looking at how
> > Policy has changed, then yes, it's not useful. And I don'
On Fri, Sep 09, 2016 at 01:10:52PM +0200, Dominique Dumont wrote:
> On Thursday, September 8, 2016 8:39:01 AM CEST Russ Allbery wrote:
> > If Lintian says that the Standards-Version field is out of date, I then
> > open /usr/share/doc/debian-policy/upgrading-checklist.txt.gz, scroll down
> > to the
On Thursday, September 8, 2016 8:39:01 AM CEST Russ Allbery wrote:
> If Lintian says that the Standards-Version field is out of date, I then
> open /usr/share/doc/debian-policy/upgrading-checklist.txt.gz, scroll down
> to the current value of Standards-Version, and then read backwards to the
> top,
Le 8/09/2016 à 17:39, Russ Allbery a écrit :
> If you're just automatically updating it without ever looking at how
> Policy has changed, then yes, it's not useful. And I don't think it's
> very useful to publish.
That's indeed what happens most of the time. The set of packages
maintained by the
Hello,
On Thu, Sep 08, 2016 at 08:39:01AM -0700, Russ Allbery wrote:
> If Lintian says that the Standards-Version field is out of date, I then
> open /usr/share/doc/debian-policy/upgrading-checklist.txt.gz, scroll down
> to the current value of Standards-Version, and then read backwards to the
> t
On Thu, Sep 08, 2016 at 05:28:18PM +0200, Markus Koschany wrote:
> On 08.09.2016 14:30, Ian Jackson wrote:
> > Emmanuel Bourg writes ("Re: Network access during build"):
> >> That makes sense, but in this case what is the usefulness of the
> >> Standards-Version field? And more precisely, why is it
On Thu, Sep 08, 2016 at 06:37:33PM +0200, Markus Koschany wrote:
>
> On 08.09.2016 17:39, Russ Allbery wrote:
> >
> > Markus Koschany writes:
> >
> > >
> > > I have written a macro to update the Standards-Version field
> > > because it
> > > is such a boring task. Declaring compliance with the
[Please CC me on replies.]
Steve McIntyre wrote:
> Josh Triplett wrote:
> >Ian Jackson wrote:
> >> Editing the Standards-Version field is surely a small task, compared
> >> to the work of checking the policy updates against the package.
> >
> >Not necessarily. You can check Policy once for the di
Josh Triplett writes ("Re: Standards-Version field should be deprecated"):
> Ian Jackson wrote:
> > Editing the Standards-Version field is surely a small task, compared
> > to the work of checking the policy updates against the package.
>
> Not necessarily. Yo
On Thu, 08 Sep 2016, Moritz Mühlenhoff wrote:
> We could reduce the policy checklist to issues not covered/coverable by
> Lintian tests (which should be a rather small subset of overall policy
> changes).
Please don't. Feel free to annotate these, but don't remove them...
I would rather not depe
Josh Triplett schrieb:
> I do see value in documenting the version of Policy a package complies
> with. However, I can also imagine some approaches to eliminate the
> busywork.
We could reduce the policy checklist to issues not covered/coverable by
Lintian tests (which should be a rather small s
Josh Triplett wrote:
>Ian Jackson wrote:
>> Editing the Standards-Version field is surely a small task, compared
>> to the work of checking the policy updates against the package.
>
>Not necessarily. You can check Policy once for the differences
>introduced with a new version, determine quickly fr
Ian Jackson wrote:
> Editing the Standards-Version field is surely a small task, compared
> to the work of checking the policy updates against the package.
Not necessarily. You can check Policy once for the differences
introduced with a new version, determine quickly from the nature of the
change
Markus Koschany writes ("Standards-Version field should be deprecated"):
> > The field is useful because it shows the most recent version of the
> > policy that the package has been checked against. It is useful to
> > occasionally update packages to the latest standards, and the
> > Standards-Ver
On 08.09.2016 17:39, Russ Allbery wrote:
> Markus Koschany writes:
>
>> I have written a macro to update the Standards-Version field because it
>> is such a boring task. Declaring compliance with the Policy over and
>> over again by updating this field and mentioning it in the d/changelog,
>> doe
Markus Koschany writes:
> I have written a macro to update the Standards-Version field because it
> is such a boring task. Declaring compliance with the Policy over and
> over again by updating this field and mentioning it in the d/changelog,
> doesn't strike me as being a useful task. There are
20 matches
Mail list logo
